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

2. Factory Information and Control System (FICS) Backup Outline
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+

3. 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 (DuPoint Mask)
Giant Kao (TSMC)
Ya-Shian Li (NIST)
Leon McGinnis (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)

4. How Metrics were selected
Almost every metric is a best in class or close to best in class
Sources are: Rob Leachman’s published 200mm benchmarking data, Individual IC maker feedback, and I300I Factory Guidelines for 300mm tool productivity
It is likely a factory will not achieve all the metrics outlined in the roadmap concurrently
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
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.

5. Production Equipment Performance & Factory Operations

6. 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 
OHV
OHV
1a. Load port event signals carrier leaving OR
1b. 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 UI UI
Process
Chamber a
Process
Equipment b
Stocker
Processing
nearly
complete
SECS/GEM   
Equipment
Controllers
Scheduling &
Dispatching System
Equipment
Tracking
System
AMHS Control
System
Information Bus

7. 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. 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
OHV  UI
Process
Chamber
Process
Equipment  
Equipment data   
Equipment
Controllers
Scheduling &
Dispatching System
Equipment
Tracking
System
Paging System
Information Bus

8. Process Control Systems

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

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

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

12. Fault Detection and Classification Prevent scrap or equipment damage
Category
Purpose
Capability Definition
Equipment Requirements
System
Requirements
Roadmap Requirements
Fault Detection and Classifi-cation (FDC)
Prevent harm to product and/or equipment due to equipment operation while out of specifi-cation
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 real-time data to host system
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
Immediately
After this step
After this lot
After this wafer
Handle large network volumes 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
ITRS Requirements include:
Defect Reduction: Particle density (particles / m2) tied back to yield
Overall Equipment Efficiency – reduces MTTD (diagnose)
Add process repeatability
ITRS Requirement:
Equip Table Target

13. Run to Run Control Optimize performance to equipment processing specification
Category
Purpose
Capability Definition
Equipment Requirements
System
Requirements
Roadmap Requirements
Run to Run Control
Realize the process specification
Independent of input conditions (wafer or previous process results)
Independent of some equipment conditions
Adjust process equipment process based on actual metrology results
Reporting of metrology data to host system
Supply data to determine relationship of end processing results to adjustable process parameters.
Historical detailed data required from equipment sensors
Ability to adjust key recipe parameters at various intervals via host command
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
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
Coefficient of variation of key process parameters
Cv = sigma/mean
Potential Solution:
Guidelines and Standards Target
ITRS Requirement:
Equip Table Target
Primary ITRS Requirements is Coefficient of Variation for (ITRS examples):
Litho – gate CD control (nm), Overlay Control (nm)
Diffusion – Oxide thickness and thickness control

14. Run to Run Control Optimize performance to equipment processing specification
Category
Purpose
Capability Definition
Equipment Requirements
FICS Req’ts
Run to Run Control
Realize the process specification
Independent of input conditions (wafer or previous process results)
Independent of some equipment conditions
Adjust process equipment process based on actual metrology results
Communicate changes to the FDC system to avoid inadvertent pauses to production
Reporting of metrology data to host system
Supply data to determine relationship of end processing results to adjustable process parameters.
Historical detailed data required from equipment sensors
Ability to adjust key recipe parameters at various intervals via host command
Immediately
After this step/wafer
After this lot
Receive data
Calculate optimal parameter
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

15. Integrated Metrology Reduce module level Throughput Time (TPT)
Category
Purpose
Capability Definition
Equipment Requirements
Roadmap Requirements
Integrated Metrology
Decrease module level TPT
Integrate metrology into the process equipment
Includes hardware and software
Hardware integration of process and metrology equipment
Don’t increase footprint
Interoperability
Software integration of metrology and process equipment
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)
Reduction of:
Throughput time
Time for metrology feedback loop
Wafer handling and AMHS time
Floor space
Potential Solution:
Guidelines and Standards Target
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 / m2 or WIP turns / m2)
ITRS Requirement:
Equip Table Target

16. Fault Detection and Classification (1/2)
Outside of Tool
FDC Modeling
FDC control configuration
External sensor and tool data integration by IC Maker
Level 0 FDC Assumptions:
FDC occurs outside the tool
Data collection through SECS interface for integrated sensors
Use Trace data collection (S6F1) or poll (S1F3/4)
Data collection frequency 1-3 Hz through the SECS interface
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
Host System
FDC
Module
SECS Interface used for most data collection and all control
FDC Data
External Sensor Integration Optional
FDC Control
Graceful Shutdown options required
Detailed wafer, recipe and chamber data required
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
Step N UI
IC Maker integrated External Sensor
Process
Equipment

17. Fault Detection and Classification (2/2)
Outside of Tool
Host determines actions based on type of fault
Host issues control command
Level 1 FDC Assumptions:
Some FDC may occur inside the tool (IC maker’s discretion)
Enables real-time control loops
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
Immediately, after this step, after this lot
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)
Host System
Slow FDC
Module
SECS Interface used to control tool in the event of a fault
FDC Signal
FDC Control
Inside the Tool
FDC Models configured
FDC host signals configured
FDC actions may also be configured
Process
Equipment
Step N UI
Historical and Summary data storage and analysis
Detailed wafer and chamber data tracked
Interface EE
EES

18. Detailed wafer and chamber data required
Run to Run Control (1/3)
Level 0 L2L 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
Parameterized recipes required
Detailed wafer and chamber level data required
Step N
Metrology
Equipment UI UI
Metrology
Equipment UI
Step N-1
Models and Recipe Adjustment
Step N+1
Process
Equipment
Detailed wafer and chamber data required
SECS
Equip
Controller
SECS
SECS
Equip
Controller
Equip
Controller
Feed Forward Control - Use preprocess metrology data to adjust processing for that lot
Metro data collected via SECS interface
Metro data collected via SECS interface
Run to Run Control
Feedback Control - Use post metrology feedback data to adjust processing for the next lot
Host System

19. Run to Run Control (2/3) (Lot to Lot Case)
Proposed Guidelines
Level 1 L2L Run to Run Assumptions (non integrated metrology 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)
Recipe Adjustment Models and Calculations
Modular apps with open interfaces
Recipe Recommendations
Host System
EES
Feed Forward Control - Use preprocess metrology data to adjust processing for that lot
Equip
Controller
Equip
Controller
Equip
Controller
Database
Adaptor EE
Database
Run to Run Control
Feedback Control - Use post metrology feedback data to adjust processing for the next lot
Recipe Parameter Control
Factory Network
SECS
Detailed wafer and chamber data required
SECS EE EE
SECS EE
Metro data collected via EE interface
Metrology
Equipment UI
Metro data collected via EE interface UI
Metrology
Equipment
Step N
Step N+1
Step N-1 UI
Recipe Adjustment (Parameterized recipes required)
Process
Equipment

20. Run to Run Control (3/3) (Wafer to Wafer Case)
Level 2 W2W 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
Modular apps with open interfaces EE
Database
Integrated SECS and EE Interfaces for Process and Metrology
Factory Network
EE Network EE
SECS
Recipe and Model Selection and Download via SECS Interface
Host System
Integrated Metro data and detailed wafer and chamber data collected via EE interface
Equip
Controller
Integrated Metrology
Module (not Bolt on) UI
Parameterized recipes required
Recipe Adjustment Models, Calculations, Control
Integrated
Process and
Metro Equip.

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

22. Integration Time for Equipment Control Systems (Run to Run algorithms) Must Decrease
Perform Experiment / Acquire “X” input data
Analyze Results and create Process Model
Release to Factory Floor
Time
Not to scale
Build run to run algorithm into the system
Functional Test
of run to run algorithm
Design of Experiment
Acquire “Y” output data
Total Time (expected to decrease)
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
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

23. Engineering Chain

24. 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
Engineering Chain = Design  Reticle  Integration  Customer  High Volume
Different from supply chain management which focuses on volume production
Planning and parallel activities to deliver
Data Transfer
Process Development
Product
Design
Mask
Fabrication
Packaging
and Test
Customer
Evaluation
Wafer Fab
Data
Transfer
Data
Transfer
Data
Transfer
This is a Supply Chain Task
Volume
Run
Design Fix
Design Improvement
Not Engineering or Supply Chain
Part of Supply Chain
Legend

25. Engineering Chain vs. Supply Chain
Focus is on rapid new product, new process, and new procedures
Success indicators include:
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:
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

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

27. Potential Solutions to Accelerate New Products
Faster data exchange using standard data models and structures between major operations
Improved methods and capabilities to match the process to the product on time
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.)
Supply Chain (O2D)
Sales
SCP
MES
Factory
Shipping WO
WIP
Order
Promise
Design
Commerce Data
Engineering Data
Engineering Chain (T2M)
e-Diag
Maintenance
Support
EE Data
EES
APC
Recipe
Eqpt. Configuration
Mass Production
Product Development
Process
Devmn’t
YMS
Mask
Eqpt.
Eqpt. Supplier

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

29. 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 1st 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

30. 2003 Current Mask Shop Metrics
Year of Production
2003
2004
2005
2006
2007
2008
2009
2012
2015
2018
Wafer Diameter
300mm
450mm
Optical Mask Data File size per Layer (GB) from Litho
144
216
324
486
729
1094
1640
N/A
EUVL Mask Data File size per Layer (GB) from Litho
730
1096
2466
5550
12490
Time to send and load tape-out data into Mask Shop data system (hours)
5-10
6-12
Time for OPC calculations and data preparation for mask writer (days)
4-8
OPC Time only (days)
2-4
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

31. 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
300mm
450mm
Optical Mask Data File size per Layer (GB) from Litho
144
216
324
486
729
1094
1640
N/A
EUVL Mask Data File size per Layer (GB) from Litho
730
1096
2466
5550
12490
Data Transfer from Designer to OPC (hours)
5-10
6-12
OPC Time only (days)
2-4
3-6
Send OPC results to Mask Developer (hours)
5-20
7.5-30
Mask Data Prep (hours)
10-18
15-27
Loading mask data into mask writer (hours)
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. 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.

33. Mask Operations - Cycle Time Reduction Required
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
Design
rule checker
OPC
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
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
Timing for Potential Solutions
Research
Development 2006
Qualification/Pre-Production 2007

34. Worst Case Mask Data Preparation
Mask Files and Cycle Times will Increase Exponentially unless New Solutions are Found
500
12,500
Worst Case Mask Data Preparation
Cycle Time (days)
Legend
Best Case Cycle Time
Worst Case Cycle Time
File Size
Solutions are needed to keep cycle times from exploding
400
10,000
300
7,500
File Size in GB per mask layer
Target: Keep mask production cycle times at 2004 levels (4-9 days per mask layer)
200
5,000
100
2,500
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.

35. AMHS Direct Transport

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

37. Direct Tool to Tool Transport Is Needed by 2004
Many Direct Transport Concept Options
Objectives:
Reduce product processing cycle time
Increase productivity of process tools
Reduced storage requirements (# of stocker)
Reduced total movement requirements
Priorities for Direct Delivery:
Super Hot Lots (< 1% of WIP) & Other Hot Lots (~5% of WIP)
Ensure bottleneck equipment is always busy
Capability Needs
Tools indicate that WIP is needed ahead of time
Event driven dispatching
Transition to a delivery time based AMHS
Integrated factory scheduling capabilities
Timing
Research Required
Development Underway
Qualification/Pre-Production S1 S2 T1 T2 S3 S4 T3 T4 S5 S6 T5 T6 S7 S8 T7 T8
Fully Connected OHV S1 S2 T1 T2 S3 S4 T3 T4 S5 S6 T5 T6 S7 S8 T7 T8
OHV with Interbay Transport
Partially Connected OHV
With Conveyor Interbay

38. 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  
OHV
1a. Load port event signals carrier leaving OR
1b. 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
OHV UI
Process
Chamber a UI
Process
Chamber
Process
Equipment b
Process
Equipment
Processing
nearly
complete  
Scheduling &
Dispatching System  
SECS/GEM
Equipment
Controllers
Equipment
Tracking
System
AMHS Control
System
Information Bus

39. Research Opportunities
ITRS Factory Integation TWG
2017/3/27
Research Opportunities
FITWG 2000

40. Fab Operations and Design Modeling Laboratory
300 mm discrete event simulation models currently available for download from Sematech are not accurate
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.
Computing, software, and communication technologies have developed to the point where a new approach to fab simulation modeling is feasible.
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 300mm “virtual fab” can be addressed in a neutral, pre-competitive setting.
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?

41. Future Research
Data mining approach for managing Process Control & Factory Operations data
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
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)?
Factory workflow control
What business rules are needed between integration of key factory systems (MES, MCS, Scheduler, Dispatcher, Equip Tracking) to optimize processing?
Operational scenarios showing equip / FICS / AMHS interactions to support Tool-to-Tool moves (Direct Transport)
Include exception handling
Opportunities / improvements for Mask Operation cycle time
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?