FPSINPUT.RTG_ROUTE_STEPS

FACILITY

VARCHAR2(6)

Facility is included in almost every join in the DWH so this represents a definitive split. A route must have all steps on tools in the same facility. A tool must process all lots in the same facility. If your site has multiple buildings where lots run on routes using tools in multiple buildings then everything should be one facility. For example, multiple Fab buildings. But if your site has independent facilities like Fab and Test and Assembly where lot may progress from one to the next but on different routes then these should be different facilities. Since this column is in virtually every table it is critical that the value here is exactly matches what is in the MES if the MES has facility. Use facility_display for the display friendly name displayed in applications. See site_name comment for client/site/facility example. (* from FPSINPUT.GEN_FACILITIES)

ROUTE

VARCHAR2(256)

Route that has threading requirements (* from FPSINPUT.RTG_STEP_THREADING)

STEP

VARCHAR2(256)

A single processing step within a route representing a single tool visit. Step is often a very complex string and should rarely be displayed. Instead we should use process_display.

CARR_CATEGORY_RQD

VARCHAR2(17)

Required carrier category which if set must match carr_category in MHS_CARRIERS (* from FPSINPUT.RTG_DURABLES)

COMMON_STEP

VARCHAR2(50)

N

A display-friendly field that groups similar steps together for purposes of viewing the entire line. Typically the only duplicates within a single route will be optional ordered steps in the same segment. But we will often have steps across routes that share the same common step even though exact step definition is not identical. (* from FPSINPUT.RTG_COMMON_STEPS)

COUNT_AS_OPER_MOVE

CHAR(1)

If the use_count_as_oper_move_flag is set to Y in GEN_FACILITIES then we use this flag to determine oper moves instead of using moves from one operation to another.

EST_LINE_YIELD_PCT

NUMBER(6,3)

Estimated line yield percent for the route-step. Leave blank for the default of no loss expected. A value of 99.5 means we expected 1 unit out of 200 to be lost.

EST_REWORK_PCT

NUMBER(5,3)

Estimated percentage of lots completing this step which will go to rework. This is used for capacity modeling.

FUTURE_WIP_STEP

VARCHAR2(256)

FUTURE_WIP_STEP is for sequenced operations. The most common is the Diffusion clean-furnace sequence. Lots for the furnace always wait at the sink so there is technically never any WIP at the furnace operation. But we do not want to count it as Sby No WIP if there is WIP available at the sink. This tells us to link the steps so that we will report Standby Wip At Previous Related Step.

HIDE_FUT_IN_LOT_STEP_SUMMARY

CHAR(1)

Indicates whether future step records will be hidden in the Dashboard Lot History Summary table.

IS_INACTIVE_STEP

CHAR(1)

Since we now use RTG_ROUTE_STEPS_INACTIVE table, we should only include the active steps on each route in RTG_ROUTE_STEPS. Therefore this value must be set to N in the RTG_ROUTE_STEPS table but will be set appropriately to Y for inactive steps in the RTG_ROUTE_STEPS_PLUS table.

IS_STAGING_STEP

CHAR(1)

We expect large amounts of WIP and long cycle times at staging steps. We still calculate cycle time like any other step but the important difference is that lots currently at a staging step are not counted as normal coming lots to future steps. Instead we show them in a special column labeled From Staging.

IS_TW_USE

CHAR(1)

Applicable to TW routes only. If N (default), then this step is part of the process of building the test wafer. If Y, then this step is one at which the TW is used for process characterization by the owning module.

LINE_SECTION

VARCHAR2(32)

N

Large grouping of the line, e.g. FEOL, BEOL, Cu, etc. There should be only a handful of values for the entire facility - or if the facility only has one section then we can leave this column blank. (* from FPSINPUT.RTG_LINE_SECTIONS)

MOVE_TO_BANK

VARCHAR2(36)

If this step moves the lot to a bank then populate this with the name of the bank. Typically this is the last step on a production route but it can be in the middle of the route as well.

MSO_PROCESS

VARCHAR2(100)

Process definition for this step to be used by the Metrology Sampling Optimizer. MSO process is defined differently to avoid conflict with regular process and common step and because the definition can vary greatly from those concepts

OPERATION

VARCHAR2(50)

N

Operation is usually the primary level of routing in the MES and the level where the facility typically reports moves. FPS only allows one tool per step so our step is a lower level of routing than operation although both may be the same if the MES only allows one tool per operation. Note that because operation can include multiple steps and therefore multiple process families that we cannot have any association to equipment by operation. (* from FPSINPUT.RTG_OPERATIONS)

OPERATION_FAMILY

VARCHAR2(36)

N

Grouping of route-step that is completely dependent on routing information from MES. The primary use of this field is for filtering on Operations Dashboard. Unfortunately for our database structure and naming convention, this field no longer has any link to operation. This is because operation is used primarily for Oper Moves and it is normal for steps in an operation to belong to multiple MES routing groups. For example, a sink step and a furnace step and a measurement step are in the same operation but each step belongs to the appropriate sink/furnace/measurement MES routing groups which we store in operation family. Since Dashboard already uses both operation and operation_family extensively and independently, we decided not to rename either column but simply remove the link. Please note that operation family is similar to process family and in fact they are often the same. The key differences are that operation family has nothing to do with equipment and that comes straight from ETL with no complex logic. Process family is the link between routing and equipment for the Operations Dashboard and therefore has complex logic. (* from FPSINPUT.RTG_OPERATION_FAMILIES)

ORIG_FACILITY

VARCHAR2(6)

See comments in OTHER_FACILITY column

ORIG_FAC_ROUTE

VARCHAR2(256)

See comments in OTHER_FACILITY column

OTHER_FACILITY

VARCHAR2(6)

Used if the step is actually processed in another facility. For example, a lot may go to the Test facility for an electrical test in the middle of the Fab route. In this case, on the Fab route OTHER_FACILITY is set to Test. In the Test facility there will be a fake short route with only this single step and the ORIG_FACILITY and ORIG_FAC_ROUTE will be set to the name of the Fab facility and the Fab route. This case is distinguished by non-NULL values in ORIG_FACILITY, OTHER_FACILITY, and ORIG_FAC_ROUTE columns.

OVR_COMMIT_STEP_SEC

NUMBER(7)

See comments in OVR_TARGET_STEP_SEC column.

OVR_STEP_SEC_FOR_FUT

NUMBER(7)

For WIP_STEP_FUTURE cycle time predictions, we normally use the automatically calculated cycle time from CTM_SUMMARY as configured in ctm_column_for_wip_step_fut from GEN_FACILITIES (i.e. FULL, COMMIT, 7D_MED, 2D_WAVG, etc.). The ovr_step_sec_for_fut columns in RRS and WIP_STEP_FUTURE_OVR allow us to override this value with a manual value for a specified route-step or a specified lot-route-step. The ovr column from RRS is used in the CTM_SUMMARY logic so it will be the value of step_sec_nohold_for_wsf and step_sec_for_wsf_if_take in CTM_SUMMARY and RTG_ROUTE_STEPS_PLUS as well as the value in WIP_STEP_FUTURE. The ovr column from WSF_OVR is specific to the lot and therefore is only used in UPDATE_WIP_STEP_FUTURE so you will only see this value in WIP_STEP_FUTURE. In addition, a value in WSF_OVR indicates that the lot will TAKE at this step. If both are populated, WSF will use the more specific value by lot from WSF_OVR. The most common use of this column is to override the 10 second default for staging steps used by the Scheduler. Other than staging steps, we recommend using these overrides rarely.

OVR_TARGET_STEP_SEC

NUMBER(7)

We normally automatically calculate commit/target cycle times by weighting across steps based on historical information so that the total for the route equals the specified total for commit/target in RTG_PRDS. This column along with ovr_commit_step_sec allows us to override that automated calculation for certain route-steps with a specific value. We encourage leaving these columns blank.

PHOTO_LAYER

VARCHAR2(12)

The photo layer the step belongs to.

PROCESS

VARCHAR2(50)

N

Process defines what occurs at a step. Different steps can share the same process if they are identical. Process should normally determine allowed tools and recipe although it can be overridden by step, route, prd, lot, and experiment for exceptions. Each process is dynamically assigned to one or more eqp_type-process_family combinations with use_pct. One process_family is determined to be primary. If grouping is done correctly, a process should only be one eqp_group with no crossover. (* from FPSINPUT.RTG_PROCESSES)

RECURSIVE_LEVEL

NUMBER(2)

Levels of segments within a section

ROUTE_SECTION

VARCHAR2(32)

N

A large grouping of route steps used for line balance and should be set to contain at least a week of steps based on cycle time. Line balance uses this grouping instead of segment so that it can be configured independently from segment which is used in the Dashboard for display purposes, but they can also be set the same if desired. The section should be large in order to minimize the impact of short-term WIP distribution changes on step WIP targets because line balance calculates step WIP targets based on the WIP currently in each section.

ROUTE_SECTION_SORT

NUMBER(6)

N

Sequence number of route segment within a section

ROUTE_SEGMENT

VARCHAR2(36)

N

Route_segment allows for clear hierarchical segment organization for Segment Summary and Line Viewer on Dashboard. This is often referred to as stage and typically will come from the MES (as opposed to facility_segment which we will typically have to define for our purposes). We recommend that all routes in the same route family have the same route segments in the same order so that the Line Viewer by route family will be consistent but if this is not the case then we approximate the order as best we can.

RTG_PARM1

VARCHAR2(128)

RTG_PARM2

VARCHAR2(128)

RTG_PARM3

VARCHAR2(128)

RTG_PARM4

VARCHAR2(128)

RTG_PARM5

VARCHAR2(128)

SCH_CUSTOM_TARGET

NUMBER(5,2)

This is a numeric value that can be passed to the Scheduler for use in scoring lots. It will be the value used in the CUSTOM TARGET scoring evaluation

SCRIPT_ID

VARCHAR2(36)

This column references the name of script used to process lots at this step. Different MES use different terminology but the key to this column is its use to determine batches. Lots with the same script_id and same batch_criteria from RTG_TOOL_ASSIGNMENTS can be batched together. Therefore this is critical column for scheduling on batch tools.

SEQ_NUM

NUMBER(7,2)

N

Sequence number of step in route

SPEC_ID

VARCHAR2(36)

This column references the name of the specification used to process lots at this step. Unlike script_id, this column is not used for any FPS purpose other than reference and display.

STEP_CHOICE_BRANCH

VARCHAR2(256)

See comments for the step_choice_group column.

STEP_CHOICE_GROUP

VARCHAR2(256)

The step choice group and branch columns indicate that each lot must make a choice to visit only one of a group of steps. Both fields must be populated together. Step choice group is just a label to understand the meaning of the group of steps. Step choice branch is the important column indicating to which branch the step belongs. A common example is Litho where we can process on an integrated cell or a standalone track and stepper. Step 100 immediately prior to the Litho would have both fields blank. Step 101 is the integrated cell with step_choice_group set to Litho_Metal_1 and step_choice_branch set to Integrated. Step 102 is the track with step_choice_group set to Litho_Metal_1 and step_choice_branch set to Standalone. Step 103 is the stepper with step_choice_group set to Litho_Metal_1 and step_choice_branch set to Standalone. Step 104 immediately following would have both fields blank.

TW_USE_PURPOSE

VARCHAR2(16)

Brief definition of the use of test wafers at this step (ex: Etch Rate or Nitride Dum).