1

2003 ITRS Factory IntegrationFactory Information & Control Systems (FICS)

Backup Foils

2

Factory Information and Control System (FICS) Backup Outline

1. Contributors

2. How Metrics were Selected

3. Production Equipment Performance and Factory Operations

4. Process Control Systems

5. Engineering Chain

6. AMHS Direct Transport

7. 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

b

Integrated FICS to Improve Equipment Performance

ProcessEquipment

UI

OHV

Stocker

UI

OHV

AMHS ControlSystem

Scheduling &Dispatching System

Equipment Controllers

Information Bus

Processing nearly complete SECS/GEM

1a. Load port event signals carrier leaving OR

1b. Equipment event indicates that processing is nearly finished

2. PM schedule checked to verify no PM is due

3. Dispatcher selects highest priority lot for processing

4. AMHS routes carrier to process equipment

5. Next lot delivered to equipment before it starves

aProcess Chamber

GOAL: No Equipment Idle Time (“starvation”) if Material is availableImproves output (w/ priority on “super hot lot”) through more

effective equipment utilizationRequires integrated equipment, scheduling/dispatching, AMHS,

factory operations, and PM

Equipment Tracking System

7

Predictive PM to Improve Equipment Performance

ProcessEquipment

UI

OHV

Paging SystemScheduling &

Dispatching SystemEquipment Controllers

Information Bus

Equipment data

Process Chamber

1. Equipment data indicates need for future Preventative Maintenance (PM)

2. Scheduler determines when to PM the equipment3. PM is automatically scheduled in Equipment Tracking

system4. Prior to PM time, Scheduler validates need (based on lot

priority, tool impact, downstream impact)5. Technicians notified via page that specific PM is

required6. Equipment finishes processing and is taken offline for

PM

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

Equipment Tracking System

8

Process Control Systems

99/11/2001

Continued Opportunities for APC to Improve Factory Productivity

Goal Motivation SPC FDC Run to

RunIM

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

1) Solutions can be applied in parallel2) Objective is a Quantified Improvement to the Key Factory Goals

1009/06/03

SECS/GEM Control Line

Equipment Data Acquisition (EDA) Standards Line

Today100 variables @ 3 Hz each= 300 values per sec

Future EDA Goal500 variables @10 Hz each= 10,000 values per sec

Future Equipment & Automation CapabilitiesDevelopment in 2001 [with standards]. Qualification/Production by 2005

Automation System Capabilities1. Data Sharable between APC applications2. High data transfer rates3. Single point configurations4. Integrated yield, process control, and

operational systems5. Rapid application development (run to

run algorithms, etc.)

Equipment &Process Data

SPCRunTo

Run

FDC

Yield PCS

Integrated APC/Yield Data & Systems

OperationsData

WIP

Dispatch

Tool Control

MCS

Manufacturing Execution System (MES)

Equipment Capabilities1. Standardized data and connectivity2. Fast sensor sampling & data transfer rates3. Host ability to stop processing as needed4. Graceful recovery when a fault occurs5. Ability to change parameters and values

between wafers6. Wafer tracking all points within the tool

119/11/2001

APC and Process Control Capabilities are Key Enablers for Agile Manufacturing

ModuleFlow

A

ProcessSteps

C

D

B

Target values

(Recipe and major parameters)

Physical Structure base control

Process Engineering

Eq. A

Eq. Process control info.

Eq.B

Interpretation into what equipment can execute

F/FAPC

Device structureOptimization Control

Information

Current center of interest

Detailed Eq. Status

info.

Machine-to-Machine Difference and

AdjustmentNPW Management and

Control

Chamber wet cleaning and Specification

Time dependent performance change and

compensation

Eq. Maint. and Rules

Eq. Process performance adj info.

Copyright 2000 by Masato Fujita, Selete/Panasonic

Manufacturing Experience

Resource ConsumptionManagement

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 10-15 MB / sec, no single fail pointsRedundant hardware, auto fail-over for both hardware and app’sScaleable apps and hardware, no redesign as system growsSupport ease of introduction of new applicationsModular applications with interfaces to allow data exchangeSupport download of FDC models to equipAbility 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 Requirement:Equip Table Target

• ITRS Requirements include:• Defect Reduction: Particle density (particles / m2) tied back to yield• Overall Equipment Efficiency – reduces MTTD (diagnose)•Add process repeatability

13

Run to Run ControlOptimize 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’sScaleable apps and hardware, no redesign as system growsSupport publish / subscribe architecture to ease introduction of new applicationsStandard app interfaces

Coefficient of variation of key process parametersCv = sigma/mean

ITRS Requirement:Equip Table Target

Potential Solution:Guidelines and Standards 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 ControlOptimize 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

ITRS Requirement:Equip Table Target

Potential Solution:Guidelines and Standards Target

•Research Required:• modeling – e.g. multivariate control – relation of variables by process/tool (what key parameters affect output?)

• Receive data•Calculate optimal parameter

15

Integrated MetrologyReduce 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

ITRS Requirement:Equip Table Target

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)

16

Fault Detection and Classification (1/2)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

Outside of Tool•FDC Modeling•FDC control configuration•External sensor and tool data integration by IC Maker

ProcessEquipment

Step N

UI

FDCModule

FDCModule

Host System

FDC

Dat

a

FDC

Control

SECS Interface used for most data collection and all control

External Sensor Integration Optional

• Graceful Shutdown options required

• Detailed wafer, recipe and chamber data required

IC Maker integrated External Sensor

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

17

Fault Detection and Classification (2/2)

ProcessEquipment

Step N

UI

Slow FDCModuleHost System

FDC

Sig

nal FD

C C

ontrol

Outside of Tool•Host determines actions based on type of fault

•Host issues control command

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

EES

EE

Inte

rfac

e• Historical and Summary data storage and analysis

• Detailed wafer and chamber data tracked

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)

18

Run to Run Control (1/3)

MetrologyEquipment

UI ProcessEquipment

UI

MetrologyEquipment

Step N-1 Step N+1

Step N

Feedback Control - Use post metrology feedback data to adjust processing for the next lot

Feed Forward Control - Use preprocess metrology data to adjust processing for that lot

UI

Ru

n t

o R

un

Co

ntr

ol

Host System

EquipController

EquipController Equip

Controller

Metro data collected via SECS interface

SE

CS

SE

CS

SE

CS

Models and Recipe Adjustment

• Parameterized recipes required

• Detailed wafer and chamber level data required

Metro data collected via SECS interface

Detailed wafer and chamber data required

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

19

Run to Run Control (2/3) (Lot to Lot Case)

MetrologyEquipment

UI

ProcessEquipment

UI

MetrologyEquipment

Step N-1Step N+1Step N

UI

Feedback Control - Use post metrology feedback data to adjust processing for the next lot

Feed Forward Control - Use preprocess metrology data to adjust processing for that lot

Ru

n t

o R

un

Co

ntr

ol

SE

CS

SE

CS

SE

CS

Recipe ParameterControl

Recipe Adjustment (Parameterized recipes required)

Metro data collected via EE interface

Host SystemEquip

ControllerEquip

ControllerEquip

Controller

Factory Network

EE

EE

EE

EEDatabase

Dat

abas

eA

dap

tor

EES

Recipe Adjustment Models and Calculations

Recipe Recommendations

Metro data collected via EE interface

Detailed wafer and chamber data required

Modular apps with open interfaces

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)

20

Run to Run Control (3/3) (Wafer to Wafer Case)

IntegratedProcess andMetro Equip.

UI

SE

CS

Parameterized recipes required

Host System

EquipController

Factory Network

EE

EEDatabase

EES

Recipe Adjustment Models, Calculations, Control

Integrated Metro data and detailed wafer and chamber data collected via EE interface

Modular apps with open interfaces

Integrated MetrologyModule (not Bolt on)

Integrated SECS and EE Interfaces for

Process and Metrology

EE Network

Recipe and Model Selection and Download via

SECS Interface

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

21

Integrated Metrology (1/1)Guideline:

– Hardware integrated process and metrology tools shall also integrate their data collection and control systems.

Process Tool

MetrologyTool

MetrologyTool

Off ToolControl System

Standalone IntegratedIn-Line

DualSECS/GEM

Lines

SingleSECS/GEMLine

Individual SECS/GEM

Lines

Off Tool Control System Off Tool System Control

Process Tool

MetrologyTool

Process Tool

Control Network

SingleEECLine

DualEECLines

Individual EECLines

EEC Network

Off ToolEEC System

Off ToolEEC System

Off ToolEEC System

OK OKNG

22

Perform Experiment / Acquire “X” input data

TimeNot to scale

Integration Time for Equipment Control Systems (Run to Run algorithms) Must 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

Design of Experiment

Acquire “Y” output data

Analyze Results and create Process Model

Build run to run algorithm into the system

Functional Testof run to run algorithm

Release to Factory Floor

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

Total Time (expected to decrease)

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

ProductDesign

Mask Fabrication

Process Development Packaging

and TestCustomerEvaluation

VolumeRun

Design Fix

Design Improvement

Data Transfer

This is a Supply Chain Task

Data Transfer

Data Transfer

Data Transfer

Wafer Fab

Planning and parallel activities to deliver

Not Engineering or Supply Chain

Part of Supply Chain

Part of Supply ChainLegend

25

Engineering Chain vs. Supply Chain

Engineering 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 Products1. Faster data exchange using standard data models and structures

between major operations2. Improved methods and capabilities to match the process to the product

on time3. 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 ShippingWO

WIP

Order

Promise

Design

Commerce Data

Engineering Data

Engineering Chain (T2M)

e-Diag

Maintenance

Support

EE Data

EES

APC

Recipe

Eqpt. Configurati

on

Mass Production

Product Development

Process Devmn’t YMSMask

Devmn’t

Eqpt.Devmn’t

Eqpt. Supplier

28Source: JEITASource: JEITA

Pattern data are excluded from V1.0

Logic, circuit design

EB conversion

EB

exposure

Mask shipment

Mask order sheetInspection 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

Mask order sheetInspection specification

Wafer fab.

Mask fab.

1

3

2

5

4

Design

Process engineering department

Data server

GDSII data transfer server

ORC OPC generation

Inspection data

Inspection Recipe

Dummy generation

Mask Inspection

Specification code registrationFrame specificationapproval, issue

Pattern design

Dummy OPC Frame 1 3

2 4

5

StandardizationScope

Order Entry

Recipe Maintenance

Defect/Repair/Reviewclustering

SEMI-WG-C

SEMI-WG-B

SEMI-WG-A

Engineering Chain Potential Solutions: SEMI Reticle Data Management Task Force

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

Year of Production 2003 2004 2005 2006 2007 2008 2009 2012 2015 2018

Wafer Diameter 300mm 300mm 300mm 300mm 300mm 300mm 300mm 450mm 450mm 450mm

Optical Mask Data File size per Layer (GB) from Litho

144 216 324 486 729 1094 1640 N/A N/A N/A

EUVL Mask Data File size per Layer (GB) from Litho

N/A N/A N/A N/A N/A 730 1096 2466 5550 12490

Time to send and load tape-out data into Mask Shop data system (hours)

5-10 6-12 6-12 6-12 6-12 6-12 6-12 6-12 6-12 6-12

Time for OPC calculations and data preparation for mask writer (days)

2.5- 5.5

4-8 4-8 4-8 4-8 4-8 4-8 4-8 4-8 4-8

OPC Time only (days) 2-4 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6

2003 Current Mask Shop Metrics

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

Year of Production 2003 2004 2005 2006 2007 2008 2009 2012 2015 2018

Wafer Diameter 300mm 300mm 300mm 300mm 300mm 300mm 300mm 450mm 450mm 450mm

Optical Mask Data File size per Layer (GB) from Litho

144 216 324 486 729 1094 1640 N/A N/A N/A

EUVL Mask Data File size per Layer (GB) from Litho

N/A N/A 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 6-12 6-12 6-12 6-12 6-12 6-12

OPC Time only (days) 2-4 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6

Send OPC results to Mask Developer (hours)

5-20 7.5-30 7.5-30 7.5-30 7.5-30 7.5-30 7.5-30 7.5-30 7.5-30 7.5-30

Mask Data Prep (hours) 10-18 15-27 15-27 15-27 15-27 15-27 15-27 15-27 15-27 15-27

Loading mask data into mask writer (hours)

2-4 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6 3-6

2004 Proposed Mask Shop Metrics(Work in Progress – Metrics will be updated in the 2004 version to show better details)

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 Required1. Data Transfer from Designer to OPC Application

2. OPC Calculations 3. Send OPC results to Mask Developer (at network transfer rate of 0.5 GB/hour)4. Mask Data Prep 5. Loading mask data into mask writer

Timing for Potential SolutionsResearch 2004-2005Development 2006

Qualification/Pre-Production 2007

Circuit DesignDesign

rule checkerOPC

rule checker

OPC ApplicationMask 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

34

Mask Files and Cycle Times will Increase Exponentially unless New Solutions are Found

200

300

400

500

File

Siz

e in

GB

per

mas

k la

yer

7,500

10,000

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.

2003 2006 2009 2012 20182015

Wo

rst

Cas

e M

ask

Dat

a P

rep

arat

ion

C

ycle

Tim

e (d

ays)

100

5,000

0 0

2,500

12,500

• Target: Keep mask production cycle times at 2004 levels (4-9 days per mask layer)

• Solutions are needed to keep cycle times from exploding

LegendBest Case Cycle Time

Worst Case Cycle Time

File Size

35

AMHS Direct Transport

36

AMHS is Changing to an On-Time Delivery System

Intra and InterSeparate System

Unified System(Dispatcher Base)

Unified System(Scheduler Base)

TransferThroughput

Transfer Time(Ave & Max)

Punctuality(On-Time)

Intra-Bay

Inter-Bay

Intra-Bay

Push Pull

Re-RouteAve & Max

Time

Wafer LevelTracking

CapacityPlanning

On-TimeDelivery

AMHSAMHS Key IndicatorKey Indicator

EquipmentView

Lot View

H/W Efforts

S/W Efforts

Reduce WIP

Schedule WIP

37

Direct Tool to Tool Transport Is Needed by 2004

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 2001-2003 Development Underway 2003-2005 Qualification/Pre-Production 2004-2006

S1 S2

T1 T2

S3 S4

T3 T4

S5 S6

T5 T6

S7 S8

T7 T8

S1 S2

T1 T2

S3 S4

T3 T4

S5 S6

T5 T6

S7 S8

T7 T8

Fully Connected OHV

OHV with Interbay Transport

Partially Connected OHVWith Conveyor Interbay

Many Direct Transport Concept Options

38

Equipment Tracking System

Scheduling &

Dispatching System

b

Integrated FICS to Support Direct Transport

ProcessEquipment

UI

OHV

AMHS ControlSystem

Equipment Controllers

Information Bus

Processing nearly complete SECS/GEM

1a. Load port event signals carrier leaving OR1b. Equipment event indicates that processing

is nearly finished for priority lot2. PM schedule checked to verify no PM is

due3. Equipment Tracking System ensures

downstream tool is held available4. Dispatcher selects priority lot for

processing5. AMHS routes carrier directly to process

equipment

aProcess Chamber

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

ProcessEquipment

UI

OHV

Process Chamber

39

Research Opportunities

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?