2003 ITRS Factory Integration Factory Information Control Systems

2003 ITRS Factory Integration Factory Information & Control Systems (FICS) Backup Foils 1

Factory Information and Control System (FICS) Backup Outline 1. 2. 3. 4. 5. 6. 7. Contributors How Metrics were Selected Production Equipment Performance and Factory Operations Process Control Systems Engineering Chain AMHS Direct Transport Suggested University and Industry Research for 2004+ 2

Contributors to this Section § § § § § Ray Bunkofske (IBM) Jonathon Chang (TSMC) Gino Crispieri (ISMT) Jean-Francois Delbes (STM) Barbara Goldstein (NIST) Ton Govaarts (Philips) Arieh Greenberg (Infineon) Franklin Kalk (Du. Point Mask) Giant Kao (TSMC) Ya-Shian Li (NIST) § § § § § Leon Mc. Ginnis (Georgia Tech) Shantha Mohan (Kaveri, Inc. ) Eckhard Muller (M&W Zander) Richard Oechsner (Fraunhofer) Mark Pendleton (Asyst), Adrian Pyke (Middlesex) Lisa Pivin (Intel) Court Skinner (Consultant) KR Vadivazhagu (Infineon) Bob Wiggins (IBM) 3

How Metrics were selected § Almost every metric is a best in class or close to best in class l Sources are: Rob Leachman’s published 200 mm benchmarking data, Individual IC maker feedback, and I 300 I Factory Guidelines for 300 mm tool productivity § It is likely a factory will not achieve all the metrics outlined in the roadmap concurrently l l Individual business models will dictate which metric is more important than others It is likely certain metrics may be sacrificed (periodically) for attaining other metrics (Example: OEE/Utilization versus Cycle time) § The Factory Integration metrics are not as tightly tied to technology nodes as in other chapters such as Lithography l However, nodes offer convenient interception points to bring in new capability, tools, software and other operational potential solutions § Inclusion of each metric is dependent on consensus agreement We think the metrics provide a good summary of stretch goals for most companies in today’s challenging environment. 4

Production Equipment Performance & Factory Operations 5

Integrated FICS to Improve Equipment Performance ? GOAL: No Equipment Idle Time (“starvation”) if Material is available ? Improves output (w/ priority on “super hot lot”) through more effective equipment utilization ? Requires integrated equipment, scheduling/dispatching, AMHS, factory operations, and PM 1 a. 1 b. OHV UI a Process Equipment Process Chamber 2. b 4. 5. Processing nearly complete Equipment Controllers 3. Load port event signals carrier leaving OR Equipment event indicates that processing is nearly finished PM schedule checked to verify no PM is due Dispatcher selects highest priority lot for processing AMHS routes carrier to process equipment Next lot delivered to equipment before it starves Scheduling & Dispatching System Equipment Tracking System OHV UI Stocker SECS/GEM AMHS Control System Information Bus 6

Predictive PM to Improve Equipment Performance ? GOAL: Predict future PM time to have technician/consumables ready. Intelligently determine when to run PM based on lot priority & tool/downstream impact. ? Improve equip perf by optimizing Preventative Maintenance (PM) timing and avoiding unscheduled or last minute scheduled down time ? Requires integrated equipment, scheduling/dispatching, AMHS, and factory operations 1. OHV 2. 3. UI Process Chamber 4. 5. Process Equipment 6. Equipment data Equipment Controllers Equipment data indicates need for future Preventative Maintenance (PM) Scheduler determines when to PM the equipment PM is automatically scheduled in Equipment Tracking system Prior to PM time, Scheduler validates need (based on lot priority, tool impact, downstream impact) Technicians notified via page that specific PM is required Equipment finishes processing and is taken offline for PM Scheduling & Dispatching System Equipment Tracking System Paging System Information Bus 7

Process Control Systems 8

Continued Opportunities for APC to Improve Factory Productivity Goal Motivation SPC FDC Optimize performance to Process Spec Wafer cost Die Performance Prevent wafer/die loss & equipment damage Wafer cost Factory Output Reduce Wafer Rework Wafer cost Factory Output Faster Factory TPT (Throughput Time) New and normal product delivery Better Equipment Reliability Capital Cost Run to Run IM 1) Solutions can be applied in parallel 2) Objective is a Quantified Improvement to the Key Factory Goals 9/11/2001 9

Future Equipment & Automation Capabilities Development in 2001 [with standards]. Qualification/Production by 2005 Manufacturing Execution System (MES) Operations Data WIP Tool Control MCS Dispatch Integrated APC/Yield Data & Systems Run To Run FDC SPC Yield PCS SECS/GEM Control Line Equipment & Process Data Equipment Data Acquisition (EDA) Standards Line Today 100 variables @ 3 Hz each = 300 values per sec Automation System Capabilities 1. Data Sharable between APC applications 2. High data transfer rates 3. Single point configurations 4. Integrated yield, process control, and operational systems 5. Rapid application development (run to run algorithms, etc. ) 09/06/03 Future EDA Goal 500 variables @10 Hz each = 10, 000 values per sec Equipment Capabilities 1. Standardized data and connectivity 2. Fast sensor sampling & data transfer rates 3. Host ability to stop processing as needed 4. Graceful recovery when a fault occurs 5. Ability to change parameters and values between wafers 6. Wafer tracking all points within the tool 10

APC and Process Control Capabilities are Key Enablers for Agile Manufacturing More focus for agile manufacturing Current center of interest Physical Structure base control Eq. Process control info. Module Process Flow Steps A B Target values (Recipe Interpretati and major D parameter on into s) what Process Engineering C Device structure Optimization Control Information F/F APC 9/11/2001 equipment can execute Eq. A Eq. B Eq. Process performan ce adj info. Detailed Eq. Status info. Resource Consumption Management Time dependent performance change and compensation Machine-to-Machine Difference and Adjustment NPW Management and Control Chamber wet cleaning and Specification Eq. Maint. and Rules Manufacturing Experience 11

Fault Detection and Classification Prevent scrap or equipment damage Category Purpose Capability Definition Equipment Requirements System Requirements Roadmap Requirements Fault Detection and Classification (FDC) Prevent harm to product and/or equipment due to equipment operation while out of specification § Monitor equipment processing data to determine if the equipment is in spec § Shut down or pause equipment if out of spec § Accept changes from the Run to Run system to avoid inadvertent pauses to production §Real-time process sensors on process tools §Reporting of realtime data to host system §Handle large network volumes 10 -15 MB / sec, no single fail points §Redundant hardware, auto fail-over for both hardware and app’s §Scaleable apps and hardware, no redesign as system grows §Support ease of introduction of new applications §Modular applications with interfaces to allow data exchange §Support download of FDC models to equip §Ability to use standard commands to stop processing at various intervals % wafers processed while equipment is out of spec Potential Solution: Guidelines and Standards Target l Along with buffers and filters to reduce data traffic §Report lot, slot, waferid, recipe step and chamber level recipe name as SVID’s. §Ability to stop processing at various intervals via host command l l Immediately After this step After this lot After this wafer • ITRS Requirements include: • Defect Reduction: Particle density (particles / m 2) tied back to yield • Overall Equipment Efficiency – reduces MTTD (diagnose) • Add process repeatability ITRS Requirement: Equip Table Target 12

Run to Run Control Optimize performance to equipment processing specification Category Run to Run Control Purpose Capability Definition Realize the process specification § Independent of input conditions (wafer or previous process results) § Independent of some equipment conditions § Adjust process equipme nt process based on actual metrolog y results Equipment Requirements §Reporting of metrology data to host system §Supply data to determine relationship of end processing results to adjustable process parameters. l Historical detailed data required from equipment sensors §Ability to adjust key recipe parameters at various intervals via host command l l l Immediately After this step/wafer After this lot §Need to be able to correlate data to material (chamber level process recipe, lot, slot, wafer id) all the time from every tool – can’ t do this today System Requirements §Redundant hardware, auto fail-over for both hardware and app’s §Scaleable apps and hardware, no redesign as system grows §Support publish / subscribe architecture to ease introduction of new applications §Standard app interfaces Roadmap Requirements Coefficient of variation of key process parameters Cv = sigma/mean Potential Solution: Guidelines and Standards Target ITRS Requirement: • Primary ITRS Requirements is Coefficient of Variation for (ITRS examples): Equip Table Target • Litho – gate CD control (nm), Overlay Control (nm) • Diffusion – Oxide thickness and thickness control 13

Run to Run Control Optimize performance to equipment processing specification Category Run to Run Control Purpose Realize the process specification § Independent of input conditions (wafer or previous process results) § Independent of some equipment conditions Capability Definition § Adjust process equipment process based on actual metrology results § Communicate changes to the FDC system to avoid inadvertent pauses to production Equipment Requirements §Reporting of metrology data to host system §Supply data to determine relationship of end processing results to adjustable process parameters. l FICS Req’ts • Receive data • Calculate optimal parameter Historical detailed data required from equipment sensors §Ability to adjust key recipe parameters at various intervals via host command l l l Immediately After this step/wafer After this lot Potential Solution: Guidelines and Standards Target • Research Required: • modeling – e. g. multivariate control – relation of variables by process/tool (what key parameters affect output? ) ITRS Requirement: Equip Table Target 14

Integrated Metrology Reduce module level Throughput Time (TPT) Category Integrated Metrology Purpose Decrease module level TPT Capability Definition Equipment Requirements § Integrate metrology into the process equipment § Includes hardware and software §Hardware integration of process and metrology equipment l l §Software integration of metrology and process equipment l l Potential Solution: Guidelines and Standards Target Don’t increase footprint Interoperability Roadmap Requirements Reduction of: § Throughput time § Time for metrology feedback loop § Wafer handling and AMHS time § Floor space Single SECS/GEM interface for integrated metrology and process equipment “Smart Integration §Need to match IMM with each other & stand-alone equipment (repeatability) §Reliability/quality req’ts (support recalibration) • Primary • Factory Cycle time [days] per mask layer (hot lot and non-hot lot) • AMHS system throughput (moves / hour) • Secondary • Floor space effectiveness (activities / hour / m 2 or WIP turns / m 2) ITRS Requirement: Equip Table Target 15

Fault Detection and Classification (1/2) • Use Trace data collection (S 6 F 1) or poll (S 1 F 3/4) • Data collection frequency 1 -3 Hz through the SECS interface It is vital that the tools be able to report the chamber level process recipe, recipe step, lot number, slot number and wafer ID at the very beginning of wafer processing Host System FDC Module External Sensor Integration Optional IC Maker integrated External Sensor FDC Control • IC Makers integrate sensors and use proprietary interfaces where needed. • Tools need graceful shutdown options at various intervals (some exist, implementations vary) • Equipment parameter control & fault detection – ensure there are triggers to support immediate reaction Outside of Tool • FDC Modeling • FDC control configuration • External sensor and tool data integration by IC Maker FDC Data Level 0 FDC Assumptions: • FDC occurs outside the tool • Data collection through SECS interface for integrated sensors Step N UI Process Equipment SECS Interface used for most data collection and all control • Graceful Shutdown options required • Detailed wafer, recipe and chamber data required 16

Fault Detection and Classification (2/2) • Enables real-time control loops Host System Step N • Immediately, after this step, after this lot UI Process Equipment EE Interface • May also have off tool FDC and health monitoring in parallel to on tool FDC • OPEN: How does this interact with wafer to wafer control (FDC model may need to change with each wafer) FDC Control • IC Maker configures in-tool FDC control model and actions to be taken based on process via standard interface (if it exists) • Tool determines when model is violated, controls tool, and notifies host (in tool FDC case) • Historical and Summary Data collection through standard EE Interface (with high level linkage data) • Tools needs graceful shutdown options at various intervals FDC Signal Level 1 FDC Assumptions: • Some FDC may occur inside the tool (IC maker’s discretion) Outside of Tool • Host determines actions based on type of fault • Host issues control command EES Slow FDC Module SECS Interface used to control tool in the event of a fault Inside the Tool • FDC Models configured • FDC host signals configured • FDC actions may also be configured • Historical and Summary data storage and analysis • Detailed wafer and chamber data tracked 17

Run to Run Control (1/3) Level 0 L 2 L Run to Run Assumptions: • IC Maker configures control model based on process • Recipe adjustment calculations made using metrology data and other data from the equipment or process. • Recipe adjustment occurs outside the tool (recipe adjusted by the host and downloaded to the equipment) • Parameterized recipes supported on some equipment • Metrology data collected through the SECS interface Metro data collected via SECS interface Detailed wafer and chamber data required Equip Controller Models and Recipe Adjustment Process Equipment Equip Controller Feed Forward Control - Use preprocess metrology data to adjust processing for that lot Feedback Control - Use post metrology feedback data to adjust processing for the next lot Equip Controller Host System Step N+1 UI Metrology Equipment SECS Metrology Equipment UI Run to Run Control UI Step N SECS Step N-1 • Parameterized recipes required • Detailed wafer and chamber level data required Metro data collected via SECS interface 18

Run to Run Control (2/3) (Lot to Lot Case) • IC Maker configures control model based on process • Recipe parameter value calculations made using metrology data and other data from the equipment or process (occurs in the EEC). • Recipe parameter values are applied to base recipes inside the tool • Parameterized recipes utilized (supported on all equipment via SEMI standard) • Recipe parameters are recommended to the Host by the EEC • Recipe parameters downloaded to the equipment via the Host • Still need recipe download capability for base recipes • Metrology data collected through the EE interface • Executed values reported from equipment to EEC (with high level linkage data) Step N-1 UI Feedback Control - Use post metrology feedback data to adjust processing for the next lot Metro data collected via EE interface Detailed wafer and chamber data required Metrology Recipe Adjustment Equipment (Parameterized recipes required) Host System Equip Controller Recipe Parameter Control Step N Metro data collected via EE interface Equip Controller Factory Network Step N+1 UI UI Process Equipment SECS Run to Run Control Feed Forward Control - Use preprocess metrology data to adjust processing for that lot EE SECS EE Database Adaptor EES Recipe Recommendations EE Modular apps with open interfaces SECS Recipe Adjustment Models and Calculations Level 1 L 2 L Run to Run Assumptions (non integrated metrology case) EE Proposed Guidelines Metrology Equipment 19

Run to Run Control (3/3) (Wafer to Wafer Case) Level 2 W 2 W Run to Run Assumptions (IM only case) • Lot to Lot capabilities are same as level 1 • IC Maker configures control model based on process and downloads like a recipe via some download standard. • Recipe parameter value calculations made using metrology data and other data from the equipment or process (occurs in the tool). • Recipe parameter values are applied to base recipes inside the tool • Parameterized recipes utilized (supported on all equipment via SEMI standard) • Still need recipe download capability for base recipes • Metrology data collected through the EE interface • Any modification to the process parameters reported from equipment to EEC (with high level linkage data) • OPEN: Should internal communication between process part and metrology part be standardized? • IM means that the Metrology part is integrated with the process part of the tool • Both Hardware and Software EES EE Database Modular apps with open interfaces Integrated SECS and EE Interfaces for Process and Metrology Factory Network SECS Integrated Metro data and detailed wafer and chamber data collected via EE interface EE EE Network UI Parameterized recipes required Integrated Process and Metro Equip. Recipe and Model Selection and Download via SECS Interface Host System Equip Controller Integrated Metrology Module (not Bolt on) Recipe Adjustment Models, Calculations, Control 20

Integrated Metrology (1/1) Guideline: – Hardware integrated process and metrology tools shall also integrate their data collection and control systems. OK NG Standalone Off Tool EEC System In-Line Off Tool EEC System OK Integrated Off Tool EEC System EEC Network Individual EEC Lines Dual EEC Lines Process Tool Metrology Tool Individual SECS/GEM Lines Metrology Tool Dual SECS/GEM Lines Single EEC Line Process Tool Metrology Tool Single SECS/GEM Line Control Network Off Tool Control System Off Tool System Control 21

Integration Time for Equipment Control Systems (Run to Run algorithms) Must Decrease Perform Experiment / Analyze Results and Acquire “X” input create Process Model data Release to Factory Floor Time Not to scale Design of Experiment Acquire “Y” output data Build run to run Functional Test algorithm into of run to run the system algorithm Total Time (expected to decrease) Assumptions: • Run to Run algorithms are developed (not purchased) • Production tool time available for performing experiments • Run to Run Framework exists. Just need to add new algorithm • Able to reuse of business logic from other run to run algorithms • Wafer-level data available • Tool parameters can be modified • Process is stable Solutions to decrease: • If fundamental process models exist, then use historical data to decrease time to create new algorithm • Wafer Level Tracking; Slot tracking, & Storage/Retrieval of all data with Wafer ID reference • Integration of data analysis & Run to Run (APC) Framework • If data is available, then start with Analyzing Results • Decrease to 4 weeks • Must have enough variability in data • Solutions unknown to decrease below 4 weeks 22

Engineering Chain 23

New Products Need Faster Customer Delivery § § Challenge: Customers want new products delivered much faster Key Concept: The Engineering Chain integrates rapid, accurate, flexible data exchange from design to new chip delivery to the customer to ensure customer cycle times are met l l Engineering Chain = Design Reticle Integration Customer High Volume Different from supply chain management which focuses on volume production Data Transfer Planning and parallel activities to deliver Product Design Process Development Mask Fabrication Data Transfer Wafer Fab Data Transfer Packaging and Test Volume Run Customer Evaluation This is a Supply Chain Task Design Fix Design Improvement Legend Part of Supply Chain Not Engineering or Supply Chain 24

Engineering Chain vs. Supply Chain § § Engineering Chain Focus is on rapid new product, new process, and new procedures Success indicators include: l l l § § Design successes Time and cost to introduce new and changed parts Performance repeatability in high volume manufacturing Customer serviceability Quality of reticle, wafer, and final chip Maximize and manage IP use Information flow to support Idea → Design → Mask → Fab → Test Requires engineering data exchange “APC for the entire chain” A collaborative workflow § § Supply Chain Focus is on efficient high volume production Success indicators include: l l l § § Low wafer and parts cost Time and cost to make all parts for mass production Reduction in cost of inventory Flow of raw materials to finished goods Requires exchange of schedule and inventory data. Workflow is well understood; Low volume of data exchanged Both § Phases and elements include Source, Plan, Make, and Deliver § Efficiency, speed & Cost are essential 25

Critical Cycle Time and Cost Issues • Data translations • Data volume • Precise knowledge of design intent • Precise awareness of mask/process capabilities 26

Potential Solutions to Accelerate New Products 1. Faster data exchange using standard data models and structures between major operations 2. Improved methods and capabilities to match the process to the product on time 3. Improve execution and process control systems, analogous to the chip fab, in Mask Shops to deliver masks with 0% excursions ( requires improved systems, richer equipment data, etc. ) Mass Production Supply Chain (O 2 D) Sales Factory Order Promise WO SCP Shipping MES WIP Commerce Data Eqpt. Supplier Eqpt. Devmn’t Product Development Engineering Chain (T 2 M) Design Mask Devmn’t Process Devmn’t e-Diag Maintenance Support Eqpt. Configuration EE Data APC Recipe EES YMS Engineering Data 27

Engineering Chain Potential Solutions: SEMI Reticle Data Management Task Force Design Logic, circuit design Pattern design OPC Frame In-house processing Process engineering department Wafer manufacturing department Wafer fab. Mask manufacturing department Dummy generation DRC GDSII data transfer server Dummy Mask fab. Production control department Design department 4 Mask order sheet Inspection specification Frame specification approval, issue Inspection data Frame specification Acceptance Incomming QA 1 Data server ORC OPC generation Frame generation, frame specification EB conversion Mask order sheet Inspection specification Specification code registration 3 Transp ort Inspection data Inspection Recipe Mask shipment Standardization Scope 1 3 SEMI-WG-C Order Entry EB exposure 2 Pattern data are excluded from V 1. 0 5 2 4 SEMI-WG-B Recipe Maintenance Mask Inspection 5 SEMI-WG-A Defect/Repair/Review clustering Source: JEITA 28

Mask Shop Metrics § A key addition to the 2003 roadmap is the inclusion of Mask Shop metrics from a Factory Information and Control System perspective § The 2003 metrics represent a 1 st revision of analysis into this area. § In addition, we have included more detailed and refined mask shop metrics that are not quite ready for the 2003 publication, however, represent solid directions for 2004. § Mask file sizes per litho layer are increasing exponentially. This is causing the time to process the data required to write the masks to also increase exponentially. § While some of this cycle time can be reduced by advances in computing power, we believe that additional capabilities [algorithms, standardized data, etc. ] are needed to keep mask cycle times and associated costs in check 29

2003 Current Mask Shop Metrics Year of Production 2003 2004 2005 2006 2007 2008 2009 2012 2015 2018 Wafer Diameter 300 mm 300 mm 450 mm Optical Mask Data File size per Layer (GB) from Litho 144 216 324 486 729 1094 1640 N/A N/A EUVL Mask Data File size per Layer (GB) from Litho N/A N/A N/A 730 1096 2466 5550 12490 Time to send and load tapeout data into Mask Shop data system (hours) 5 -10 6 -12 6 -12 6 -12 Time for OPC calculations and data preparation for mask writer (days) 2. 55. 5 4 -8 4 -8 4 -8 OPC Time only (days) 2 -4 3 -6 3 -6 3 -6 FI Metric Explanation Time to send and load tape-out data into Mask Shop data system (hours) Time in hours to send data from mask designer to mask shop and load it into the OPC application. Time for OPC calculations and data preparation for mask writer (days) Time in hours to perform OPC calculations + Time in hours to convert the output of the OPC engine to the format the mask writer understands + Time in hours to transmit the data into the mask writing system OPC Time only (days) Time for OPC calculations only is the time in hours to perform the OPC calculations once the OPC application has received the tape-out data from the mask designer 30

2004 Proposed Mask Shop Metrics (Work in Progress – Metrics will be updated in the 2004 version to show better details) Year of Production 2003 2004 2005 2006 2007 2008 2009 2012 2015 2018 Wafer Diameter 300 mm 300 mm 450 mm Optical Mask Data File size per Layer (GB) from Litho 144 216 324 486 729 1094 1640 N/A N/A EUVL Mask Data File size per Layer (GB) from Litho N/A N/A N/A 730 1096 2466 5550 12490 Data Transfer from Designer to OPC (hours) 5 -10 6 -12 6 -12 6 -12 OPC Time only (days) 2 -4 3 -6 3 -6 3 -6 Send OPC results to Mask Developer (hours) 5 -20 7. 5 -30 7. 5 -30 Mask Data Prep (hours) 10 -18 15 -27 15 -27 15 -27 Loading mask data into mask writer (hours) 2 -4 3 -6 3 -6 3 -6 Key Notes: • These metrics show greater detail on the mask shop cycle time components and will be updated and refined for 2004. • Starting in 2005, mask processing time starts to grow exponentially with the file size and will take 250 to 511 days to process for each layer (see slide 34) unless improved computing power and new solutions are used. 31

2004 Proposed Mask Shop Metrics (Work in Progress – Metrics will be updated in the 2004 version to show better details) Metric Explanation Data Transfer from Designer to OPC (hours) Time in hours to send data from mask designer to Optical Proximity Correction (OPC) application. OPC Time only (days) Time in days to perform the Optical Proximity Correction (OPC) calculations once the OPC application has received the tape-out data Send OPC results to Mask Developer (hours) Time in hours to send data to Mask Developer Mask Data Prep (hours) Time in hours to convert the output of the Optical Proximity Correction (OPC) engine to the format the mask writer and mask inspection equipment understand Loading mask data into mask writer (hours) Time in hours to transmit the data into the mask writing equipment Key Notes: • These metrics show greater detail on the mask shop cycle time components and will be updated and refined for 2004. • Starting in 2005, mask processing time starts to grow exponentially with the file size and will take 250 to 511 days to process for each layer (see slide 34) unless improved computing power and new solutions are used. 32

Mask Operations - Cycle Time Reduction Required 1. 2. 3. 4. 5. Data Transfer from Designer to OPC Application OPC Calculations Send OPC results to Mask Developer (at network transfer rate of 0. 5 GB/hour) Mask Data Prep Loading mask data into mask writer Circuit Design rule checker OPC Application Mask Data Prep (prepare data for mask writer) Mask Writer Potential Solutions • OPC rule checker for circuit design to ensure it is possible to decorate the mask with OPC to provide the correct lines once imaged Timing for Potential Solutions Research 2004 -2005 Development 2006 Qualification/Pre-Production 2007 • Better data structures (hierarchical), compaction & bigger data pipes to decrease time for data transfer from OPC to Mask Data Prep • Need improved standard for specifying the mask specifications to decrease time to load data to Mask Writer • Leverage learning from operational simulation modeling in mask operations to reduce data and manufacturing cycle times 33

12, 500 Legend Best Case Cycle Time 400 Worst Case Cycle Time File Size • Solutions are needed to keep cycle times from exploding 10, 000 300 200 100 7, 500 • Target: Keep mask production cycle times at 2004 levels (4 -9 days per mask layer) 5, 000 2, 500 0 File Size in GB per mask layer Worst Case Mask Data Preparation Cycle Time (days) Mask Files and Cycle Times will Increase Exponentially unless New Solutions are Found 0 2003 2006 2009 2012 2015 2018 Key Notes: • Starting in 2005, mask processing time starts to grow exponentially with the file size and will take from 250 to 511 days to process for each layer unless improved computing power and new solutions are used. 34

AMHS Direct Transport 35

AMHS is Changing to an On-Time Delivery System Inter-Bay AMHS Intra and Inter Separate System Intra-Bay H/W Efforts Key Indicator Intra-Bay Equipment View Reduce WIP Unified System (Dispatcher Base) S/W Efforts Push Pull Re-Route Ave & Max Time Punctuality (On-Time) On-Time Delivery Capacity Planning Transfer Time (Ave & Max) Lot View Schedule WIP Unified System (Scheduler Base) Transfer Throughput Wafer Level Tracking 36

Direct Tool to Tool Transport Is Needed by 2004 § Objectives: l l Reduce product processing cycle time Increase productivity of process tools Reduced storage requirements (# of stocker) Reduced total movement requirements Many Direct Transport Concept Options S 1 S 2 S 3 S 4 S 5 S 6 S 7 S 8 T 1 T 2 T 4 T 5 T 6 T 8 T 3 T 7 Fully Connected OHV § Priorities for Direct Delivery: l l Super Hot Lots (< 1% of WIP) & Other Hot Lots (~5% of WIP) Ensure bottleneck equipment is always busy § Capability Needs l l Tools indicate that WIP is needed ahead of time Event driven dispatching Transition to a delivery time based AMHS Integrated factory scheduling capabilities S 1 S 2 S 3 T 1 T 2 S 4 T 3 T 4 S 5 S 6 S 7 T 5 T 6 S 8 T 7 T 8 OHV with Interbay Transport § Timing l l l Research Required 2001 -2003 Development Underway 2003 -2005 Qualification/Pre-Production 2004 -2006 Partially Connected OHV With Conveyor Interbay 37

Integrated FICS to Support Direct Transport ? GOAL: Reduce priority lot (“Super Hot Lots” & Other Hot Lots) cycle time through direct tool-to-tool moves without return to stocker ? Requires integrated equipment, MES (to maintain lot priority), scheduling/dispatching, PM schedule, Factory Operations and AMHS 1 a. 1 b. OHV 2. UI a Process Chamber 3. 4. Process Equipment b Processing nearly complete Equipment Controllers 5. Load port event signals carrier leaving OR Equipment event indicates that processing is nearly finished for priority lot PM schedule checked to verify no PM is due Equipment Tracking System ensures downstream tool is held available Dispatcher selects priority lot for processing AMHS routes carrier directly to process equipment UI Process Chamber Process Equipment SECS/GEM Scheduling & Dispatching System AMHS Control System Equipment Tracking System OHV Information Bus 38

Research Opportunities 39

Fab Operations and Design Modeling Laboratory § 300 mm discrete event simulation models currently available for download from Sematech are not accurate l l § Computing, software, and communication technologies have developed to the point where a new approach to fab simulation modeling is feasible. l § Fab operations (process tools, AMHS, lots, operations, setups, quals, etc) can be modeled explicitly (simulated) in software that interfaces directly with “real” fab planning and control systems. The industry needs a laboratory where the technologies and development issues associated with a true 300 mm “virtual fab” can be addressed in a neutral, pre-competitive setting. l l § Events associated with process tools are represented with reasonable fidelity, but events associated with fab planning / control systems are approximations. This simulation approach exposes the industry to significant economic risks, as design and operating decisions are based on simulation models that are known to be inaccurate. Employ available commercial software systems for fab planning and control. Develop and demonstrate the associated engineering tools for rapidly configuring this virtual fab (e. g. alternative fab layouts or AMHS strategies. ) Concern: Most of the commercially available tools do not support today’s needs. How to we plan for the future when current tools do not support current capabilities? 40

Future Research ¬ Data mining approach for managing Process Control & Factory Operations data F What are the key data items that data mining solutions must be able to extract & provide ? ¬ Modeling for Fault Detection and Run to Run Control F F What parameters are key to control (by process / by tool type)? What input parameters impact the output & how do they relate to one another (multivariate control)? F Factory workflow control F What business rules are needed between integration of key factory systems (MES, MCS, Scheduler, Dispatcher, Equip Tracking) to optimize processing? F Operational scenarios showing equip / FICS / AMHS interactions to support Tool-to-Tool moves (Direct Transport) F Include exception handling F Opportunities / improvements for Mask Operation cycle time F F What specific improvements can be made to address the opportunities identified by ITRS? What other opportunities are available to reduce cycle time or cost of Mask Operations? 41