IC Maker Recipe Management Experiences - Sematech

Implementation Guidance
for
Recipe Management Using The
SEMI E139 “RaP” Standard
SEMATECH, the SEMATECH logo, AMRC, Advanced Materials Research
Center, ATDF, the ATDF logo, Advanced Technology Development Facility,
ISMI and International SEMATECH Manufacturing Initiative are servicemarks of
SEMATECH, Inc. All other servicemarks and trademarks are the property of
their respective owners.
All Clipart Copyright © 1998 Corel Corporation and its licensors. All rights
reserved.

RaP Has Arrived
The EEC Guidelines* identified recipe management
as a key area for development
• ISMI has driven the development of this new
recipe management capability
◦ ISMI Member Company input
◦ Open input through standards process
• RaP Standard - SEMI E139
◦ Recipe and Parameter Management
has been approved
• Successful ISMI Prototyping
◦ RaP “Early Learning” prototype completed
◦ Commercial prototype now in-work
* http://ismi.sematech.org/emanufacturing/eec.htm

The Industry Is Ready
• At SEMICON Europa, STMicroelectronics:
◦ “RaP is a key component to the realization of a Centralized
Recipe Management solution”
◦ “New Paradigm: Managing all human configurable data taking
part in the process repetition"
• At SEMICON West, AMD:
◦ “We have gone to great lengths to work around the limitations
of GEM-style recipe management”
◦ “We are all about process control, and RaP will enable more
sophistication”
◦ “We are requesting RaP now”
• Infineon is currently engaged with the ISMI RaP
prototyping project
◦ More on this at the next e-Manufacturing workshop

Factory Goals & Opportunities
$ Recipe Content Trusted
◦ Guarantee that the recipe on the equipment is exactly
the one the factory approved/downloaded/selected
◦ Download only once
$ Process Control Enhanced
◦ User defines which settings become job parameters and
when during processing they will be used
$ Number of Recipes Reduced
◦ If they are parameterized, fewer recipes are needed
$ Multi-Part Recipes Explicitly Supported
◦ Enabling a practical method for reuse of recipe components
◦ Ensuring all needed recipe components are available
$ Traceability of Recipes Enabled
◦ Unique identifiers assigned to recipe components
(and parameter values) are reportable via events
With RaP, equipment can support new, sophisticated
host-side recipe management systems

Improved Confidence
The right recipe will be used at the right time and
produce the expected results
• The recipe identity is assured
◦ Secured by the uuid* and checksum
• The recipe is valid
◦ Supported by a detailed verification process
• The correct subcomponents are used
◦ Recipe resolution supported
*universally unique identifier (ISO/IEC standard)

Parameterization Opportunities
There are many sources for parameter values
• Five types (there could be more)
◦ Feedback control
Run-to-run, wafer-to-wafer, downstream data
◦ Feed forward control
Product history, upstream data
◦ Equipment matching
Recipes shared between like equipment
◦ Recipe merging
For similar processes
◦ Runtime options
Discrete choices
– For example: select which chamber to use

Recipe Component Reuse
Multi-part Recipes
• RaP provides control
◦ What recipe components must be used
• RaP provides visibility
◦ What recipe components were used
• Confidence encourages reuse
◦ Multi-part recipes are safe to use
Equipment matching, Recipe merging
◦ Reuse of PDE’s saves time and effort
PDE (Process Definition Element) = Recipe Component

Traceability
• Make a record of what happened
◦ Which job was run on what material?
Which wafer at what step?
What PDE was used?
What parameter values were used?
– Note that the supplied values may change
wafer-to-wafer and step-by-step
• Traceability enables run-time flexibility
◦ More sophisticated processing
requires this flexibility
Multi-part recipes, complex flows
Run-to-run or wafer-to-wafer control
…

Guidance Is Needed
• SEMI Standards can supply only part of the design
approach for Recipe Management
◦ Host-side usage is not rigorously constrained
• Local implementers must supply the rest
◦ Equipment must prepare for all factory-usage approaches
SEMI E139 (RaP)
• Implementation Guidance
LOCAL
0% 100%
Design Approach
◦ Reduces the implementer’s decisions/increases commonality
SEMI E139 (RaP) GUIDANCE LOCAL
0% 100%

Driver: The RaP-Enabled Factory
We envision a tightly-controlled factory
This vision drives the RaP guidance
• The RaP-Enabled factory should
Know exactly which recipe to use
Constantly track which recipes are
resident on each equipment
Store a “golden” copy of each recipe
Manage the sets of parameter
values and sources of values
Perform the minimum steps to
ensure correct recipe usage
Collect the data to trace recipe
and parameter use
Facilitate user and equipment
interactions with the recipe store

Factory Level Guidance
• Trust But Verify (and avoid downloading)
◦ Trust that recipes on the equipment are OK
Universally unique ID and checksum protect
against unauthorized change
Recipes verified fully upon download and
by checksum before job execution
◦ Avoid extensive “double-checking” before
each process job
◦ Establish an audit procedure
Utilize equipment idle time
Verify a sampling of recipes
Compare the equipment copy against
the “golden” copy at the factory

Factory Level Guidance
• Act (not React)
◦ Be the system of record
Keep a golden copy of each recipe at the factory
◦ Actively track equipment recipe stores
Know what is there – minimize downloads
◦ Specify exactly which Recipe to use
Specify all components (PDE’s)
Do not allow equipment to use “latest” version

Factory Level Guidance
• Benefit from “indirect” PDE referencing
◦ Allows a PDE to be modified without
changing the referencing PDE(s)
◦ Makes multi-part
recipes more
manageable
Process Job
RCPSPEC/PPID
VariableParameters
o gid uid Map
o PDEparam1
o PDEparam2
o etc…
Master PDE
PDE
Reference the PDE
by its Group –
resolve at run-time
Referenced
PDE’s
{
PDE PDE PDE
PDE PDE PDE PDE

Factory Level Guidance
• Manage parameter value sets and
the sources of run-time adjustments
◦ Upstream, downstream, status, fixed sets, etc.
◦ Know who is authorized
◦ Know how to merge the values
• Do not assume only one source
PDE
Store
Recipe
Equipment
Matching
Feed
Forward Module 2
Down
Step A Step B
Measure
Feed
Back

Factory Level Guidance
• Prepare for traceability
◦ Activate the related data collection events
Each PDE use, each parameter value
Attach the key data items to these events
◦ Collect and store the data
Problem may not be detected immediately
◦ Create tools to analyze the data

Factory Level Guidance
• Eliminate any practice that changes
recipe content without ID change
◦ Parameterization should replace the
“change and download” practice for recipes
◦ Group concept should replace the
“same ID, different version” approach

How can equipment suppliers
support these RaP-enabled
factory capabilities?

Equipment Level Guidance
• Control key settings from PDE’s
◦ All chamber settings
◦ Image files and reference data sets
Some are too large for transfer
◦ Equipment constants
◦ Technician controlled calibration settings
Representing these values as a non-editable PDE
makes them traceable
Any setting that affects process outcome
should be represented by a PDE

Equipment Level Guidance
• Support user selected parameterization
◦ Parameters may be needed for purposes
you do not anticipate
Recall the “parameterization opportunities”
– Run-to-run, wafer-to-wafer, downstream data
– Product history, upstream data
– Recipes shared between like equipment
– Recipe merging for similar processes
– Discrete choices (esp. chamber selection)
…

Equipment Level Guidance
• Support meaningful collection events
◦ Processing events are not well standardized
◦ Provide events coinciding with the
beginning of execution of a PDE
Since PDE’s have varying scope, this might be
multiple collection events
◦ Provide appropriate data items that will tell
the user:
Which PDE was used in each situation
What parameter values were provided to the PDE
Each wafer at each step must be traceable

Conclusion
• The RaP standard provides opportunity
◦ New capabilities are available
• For successful Recipe Management
◦ Factory approach must be understood
◦ Equipment must support this approach
• This presentation is a beginning
◦ It represents our experience to date
• This guidance will be refined and updated
◦ Equipment support for RaP is developing
◦ ISMI is encouraging the initial factory
integration of RaP capabilities

RaP Guidance
Backup Foils

Factory Level Guidance
• Consider deploying RaP in
existing factories
◦ Applicable to 200 mm or 300 mm factories
◦ Can target “problem” equipment first
Parameterization needed, multi-part recipes
◦ RaP and older recipe systems can co-exist
Recipe management does not interact
between tool types
◦ Builds confidence and expertise in RaP
Establishes in-house competence for
the next new fab

Factory Level Guidance
• User-initiated remote transfer
◦ Allow equipment and editor to initiate upload
of new PDE’s
Consider storing such PDE’s in a holding area for
later check-in to the factory store
◦ Allow editor to initiate download of existing
PDE’s
Editing is normally based on existing recipes

Equipment Level Guidance
• Provide an off-tool editor
◦ Any non-production use of equipment
resources is lost opportunity
A separate editor UI on the tool takes floor space
◦ Engineer’s desk may not have network
access to the equipment
The off-tool editor should be independent
◦ Use RaP for Equipment-Editor Link
• Anticipate a supplier-independent editor
◦ Help to make this possible

Equipment Level Guidance
• Ease the Transition to RaP
◦ Updating an existing equipment can cause
problems for current recipe collections
Save the content of old recipes – just add a
PDEheader
Change of identity can be an issue for the factory
– The RaP identifier must be a uuid
– Save the old recipe ID as a supplierInfo field or in the
name attribute