data-dictionary

FPSBASE.SCH_P_CURR_TOOL_ASSIGNMENTS

Data Dictionary

>

FPSBASE Views

> FPSBASE.WIP_WAFER_HIST_LOOP

View FPSAPP.SCH_P_CURR_TOOL_ASSIGNMENTS

the list of lot assignments with process and tool

Column

Comment

FACILITY

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. (* inherited from FPSINPUT.GEN_FACILITIES)

SCHED_GROUP

This is the grouping of tools and processes which the FPS Scheduler schedules together. Since this is a parent of tool via tool->process_group and a parent of process via process->process_group, by definition each tool and each process can only be in one sched group. We need all related tools and processes to be in the same sched group for efficient scheduling. One example is sinks and furnaces because of queue times and batching. Another example is for smaller facilities like Assembly or Test where we might schedule the entire facility together. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

PROCESS_GROUP

Process group is the critical field where tools and processes come together for the purposes of Scheduler. Process group is in both EQP_TOOLS for the tools and in RTG_PROCESSES for processes. Ideally all tools that run the same set of processes with no crossover including back-up and emergency tools would be in the same process group but it is important to note that this is not technically required for Scheduler as long as all process groups are in the same sched group. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

LOT

A lot is a group of units that process together. Usually lot_id or lot_number in MES. All units in a lot are in the same carrier but there may be multiple lots in a carrier. (* inherited from FPSINPUT.WIP_LOTS_STATIC)

ROUTE

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

STEP

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. (* inherited from FPSINPUT.RTG_ROUTE_STEPS)

PROCESS

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. (* inherited from FPSINPUT.RTG_PROCESSES)

NUM_STEPS_AWAY

Number of steps away not including steps which we know will be skipped nor those which we estimate will be skipped at least x pct of the time. This x value is configurable in GEN_FACILITIES using the smp_pct_for_num_steps_away column. (* inherited from FPSBASE.WIP_STEP_FUTURE)

TOOL

Tool is generally just the main tool. The exception is when different entities on the tool run completely independently and it is physically impossible to run wafers of the same lot across multiple entities. In this exception case, we may want to assign the entities to different eqp_types and therefore we should define each entity as a tool. Please note that when we do this there is no indication whatsoever that these different entities are on the same tool. (* inherited from FPSINPUT.EQP_TOOLS)

CH_ALLOWED

List of chambers allowed using the single character CH from EQP_CHAMBERS. While the concepts of cap_entity (capacity entity) and ch_type are important to our logic we agreed that there is no RMS or EI or MES on the planet that understands these concepts. All of these systems go by tool and chambers allowed and therefore our input tables must do the same. We list all chambers that can run and then calculate subsets of these chambers based on CH_TYPE. If all chambers are the same type then we assume you can run on any one or more of the chambers allowed. If the chambers are different types then we assume that at least one chamber of each type is required to run. If you populate either RTG_TOOL_ASGN_LOT_xxx_PATH table then you can leave ch_allowed blank since it will not be used. However there is nothing wrong with populating ch_allowed as a backup plan. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

REQUIRE_ALL_CHAMBERS

This indicates that all chambers specified in CH_ALLOWED must be used. Normally we only require one chamber of each chamber type and can run with fewer chambers and a degraded throughput but not when this flag is set. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

CH_ASGN_RULES

String with complicated syntax indicating which chambers can be used by the Scheduler. For example, (A|B|C) means the lot can only run on chamber A or B or C but not all of chambers. For example, if it runs on A then no wafer from the same lot can run on B nor C. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

ZONES_ALLOWED

PERM_RANK

Permanent rank is typically loaded by ETL from a combination of the MES, recipe management system, and existing preference logic already used at the site. Possible values are in FPSADMIN.RTG_PERM_RANKS. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

PERM_RANK_COMMENT

Optional comment entered by user or system who last updated permanent rank (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

SCHED_WEIGHTS

This is how much weight to give the chamber path rank. When populated, this will override the weights for chamber path rank and tool assignment rank. If null, then Scheduler will take the value from the configuration table SCH_C_GROUP_PERM_RANKS. example 1: ovr_sched_weights is 40 -> the chamber path rank will have a weight of 40, regardless of what ovr_ch_path_rank is. example 2: ovr_sched_weights is null and ovr_ch_path_rank == "A" -> the chamber path rank will get the weight for "A" from SCH_C_GROUP_PERM_RANKS example 3: ovr_sched_weights is null and ovr_ch_path_rank is null-> the chamber path rank will use the tool assignment rank and get the weight from SCH_C_GROUP_PERM_RANKS (* inherited from FPSAPP.SCH_W_H_S_CH_PATH_ASSIGNMENTS)

ASSIGNMENT_RANK

this assignment rank will be used in the scheduler (* inherited from FPSAPP.SCH_W_H_S_TOOL_ASSIGNMENTS)

RQD_SETUP

Rqd_setup is determined by ovr_rqd_setup in RTG_TOOL_ASSIGNMENTS and use_process_as_rqd_setup and use_est_mach_rcp_as_rqd_setup from EQP_TYPES. The latter two columns allow us to easily specify for an eqp_type that setup times should be calculated by process or est_machine_recipe. For traditional setups that are a group of recipes we use ovr_rqd_setup. (* inherited from FPSBASE.WIP_LOT_HIST)

RECIPE

the recipe; the est_machine_recipe (* inherited from FPSINPUT.EQP_RECIPES)

BATCH_CRITERIA

Lots that can run on the same batch TOOL and have the same value of BATCH_CRITERIA can run together in a batch. Therefore this is a critical column for scheduling on batch tools. If BATCH_CRITERIA is not populated, Scheduler defaults to the assumption that any WIP with the same EST_MACHINE_RECIPE can be batched together. Keep in mind that many MESs have additional constraints on batching (for example, that all WIP in a batch has the same SCRIPT_ID) and these must be incorporated into BATCH_CRITERIA to ensure that the batches are allowed by the MES. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

BATCH_RULES

MAX_MERGE_NUM_LOTS

At some sites we schedule lots to be merged there can be limitations to the total number of additional lots that can be merged together in a single carrier. This limit maybe met without reaching the maximum number of wafers in the lot. If this number is set to 1 then another lot can be merged into the same carrier with this lot. 0 or null here means no lots can merge into this carrier (* inherited from FPSINPUT.EQP_TYPES)

MAX_BATCH_SIZE_CARRIERS

Maximum number of carriers which can be loaded together in a batch. This column must be populated and is used for ETP and for scheduling to determines whether the tool loads in batches. Non-batch tools will have a value of 1 and batch tools limited by units will be populated according to the comment in max_batch_size_units. This is not used for throughput calculation because we can have tools which load multiple carriers at once but whose throughput is calculated per unit. (* inherited from FPSINPUT.EQP_TYPES)

MAX_BATCH_SIZE_LOTS

The maximum number of lots allowed in one batch (* inherited from FPSINPUT.EQP_TYPES)

MAX_BATCH_SIZE_UNITS

Maximum number of units which can be loaded together in a batch for a tool where the batch size is limited by the number of units. This value should nearly always be greater than the standard lot size. If it is less, that means that standard lots must be split in order to run on this tool. This is rare but possible therefore we have no constraint and allow this value to be as small as 1. This column will be null for non-batch tools. For batch tools,There are three cases to consider here. The first case is where the limit is only on carriers which is most common. For example, a furnace can load up to 6 carriers regardless of the units in each carrier. In this case, max_bs_carriers is 6 and max_bs_units is null. The second case is where the limit is only on units. For example, the tool can load 100 wafers regardless of the number of carriers. In this case, max_bs_units and max_bs_carriers should both be 100 which indicates that we could theoretically load a full batch of 100 carriers each with one unit. The third case is where the limit is on both carriers and units. For example, you can load up to 4 carriers and up to 80 units (meaning you cannot load 4 carriers of 25 units each nor can you load 5 carriers of 15 wafers each). In this case, max_bs_carriers is 4 and max_bs_units is 80. (* inherited from FPSINPUT.EQP_TYPES)

MIN_BATCH_SIZE_CARRIERS

Minimum number of carriers which should be loaded together in a batch. Scheduler will do everything possible to wait for at least this many carriers before scheduling. (* inherited from FPSINPUT.EQP_TYPES)

MIN_BATCH_SIZE_LOTS

The minimum number of lots required in one batch (* inherited from FPSINPUT.EQP_TYPES)

MIN_BATCH_SIZE_UNITS

Minimum number of units which should be loaded together in a batch. Scheduler will do everything possible to wait for at least this many units before scheduling. (* inherited from FPSINPUT.EQP_TYPES)

MIN_BATCH_WAIT_MINS

Minimum amount of time that a group of lots MUST wait before scheduling a group of lots below the minimum batch size. This value must be populated for the Scheduler to apply minimum batch logic. Null means Scheduler will not evaluate minimum batch constraints. (* inherited from FPSINPUT.EQP_TYPES)

WAFERS_PER_DISC

This number is specifically used to calculate throughput on tools that run per disc rather than per unit or per batch. It is most commonly set to 13 or 17 for Implant tools. It must be set along with CAN_MULTIPLE_LOTS_SHARE_DISC. (* inherited from FPSINPUT.EQP_TYPES)

LOAD_SEC

For throughput purposes, we would like the begin event to be logged when the first wafer of the lot enters the tool so that we can accurately track theoretical cycle time (TCT) which starts at this point. If the tool logs as desired then this column will be 0 and it usually is. But some tools do not log the begin event until some amount of time later, for example after the pumping time. This column exists to account for this delay and it is the number of seconds from when the first wafer enters until the begin is logged. We simply add this time to the processing time to get the TCT. This is by eqp_type as we estimate that all recipes of all tools in the same eqp_type will be consistent in this behavior. Please note that unload_sec is similar for any time after the end event until the lot can be unloaded. (* inherited from FPSINPUT.EQP_TYPES)

UNLOAD_SEC

Seconds after the end is logged until the lot is available to be unloaded. This will often be 0. Unload_sec is added to the first_wafer_sec in throughput calculations. (* inherited from FPSINPUT.EQP_TYPES)

THP_VALUES_OVR

FIRST_UNIT_SEC

Time for one unit to process when the tool starts from a standby state. On a batch tool -- defined as a tool where all units process together and take the same time regardless of qty -- this is the time for the batch. See our complete throughput documentation for more details. (* inherited from FPSINPUT.THP_EXTERNAL)

UNIT_INT_SEC

BATCH_INT_SEC

NUM_DISCS_FOR_JOB

Number of discs used in the job as estimated by our throughput logic. (* inherited from FPSBASE.WIP_LOT_HIST)

THP_CH_TYPE_CNT

THP_FILLIN_GROUP

THP_MEMO

EXTL_MODEL_ID

EXTL_MODEL_STATE

EXTL_MODEL_EXPIRED_INST

to indicate when this model will be expired (* inherited from FPSAPP.SCH_W_H_S_TOOL_ASSIGNMENTS)

IS_IN_OVR

IS_USE_TOOL_ASGN_OVR_ONLY

This column is part of the Area Scheduler configuration. Please see Area Scheduler documentation for details. (* inherited from FPSINPUT.RTG_PROCESS_GROUPS)

IS_QUEUE_STOPPED

RQD_PORT_GROUP

Optional value if tool has different groups of ports, for example 150mm and 200mm. This indicates what is required for each lot and PORT_GROUP in EQP_PORTS indicates what ports can run this group. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

IS_EXCLUSIVE_CHAMBER

This indicates that the tool may not run other jobs on other standby chambers while this job is running. For example, a process uses only chamber B on a three chamber tool. Normally that means you can run another job that uses A and/or C. However when this job is running you cannot run anything on chamber A nor C. If A and/or C are down you can still run the process on B. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

IS_DURABLE_RQD

The scenario addressed here is when the recipe which requires a durable is allowed but the durable assignment is missing. We do not want to schedule lots without the durable but we could do this unless this flag is set to Y. Here are the four combinations for reference. 1) When is_durable_required is set to Y and there is a durable assigned then the Scheduler will schedule the lot using that durable. This is the normal Photo case. 2) When is_durable_required is set to Y and there is no durable assigned then the Scheduler will not allow the lot to be scheduled. This is important for Photo to not schedule without durable. 3) When is_durable_required is set to N and there is a durable assigned then the Scheduler will schedule the lot using that durable. You will notice that the flag actually does not matter when there is a durable assigned. That is this flag is not populated at some older sites so we cannot only look for the durable if this flag is set because then the Photo Scheduler would not schedule anything at these older sites. When is_durable_required is set to N and there is no durable assigned then the Scheduler will schedule the lot without a durable. This is the normal case for all groups outside of Photo. This would also be the case at the older sites for Photo except that we have some hardcoded logic at those sites to address this. Eventually we will transition all sites to use the is_durable_required flag. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

TOOL_BALANCE_RATIO

This is the ratio assigned to the tool by fpsbase.rtg_step_tool_balance_ratios (* inherited from FPSAPP.SCH_W_H_S_TOOL_ASSIGNMENTS)

ASGN_SCHED_SCORE1

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE1_COMMENT

This column should explain the score for ASGN_SCHED_SCORE1. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE2

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE2_COMMENT

This column should explain the score for ASGN_SCHED_SCORE2. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE3

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE3_COMMENT

This column should explain the score for ASGN_SCHED_SCORE3. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE4

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE4_COMMENT

This column should explain the score for ASGN_SCHED_SCORE4. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE5

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE5_COMMENT

This column should explain the score for ASGN_SCHED_SCORE5. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE6

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE6_COMMENT

This column should explain the score for ASGN_SCHED_SCORE6. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE7

This column is to provide a custom scheduler score based on the tool assignment. Each of the three ASGN_SCHED_SCORE columns will have a separate scheduler rule that takes the score value provided and passes it through as a score. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

ASGN_SCHED_SCORE7_COMMENT

This column should explain the score for ASGN_SCHED_SCORE7. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS_LOT)

LOT_ASGN_RATIO

This is the ratio of lot assignments by tool calculated by the DWH (* inherited from FPSAPP.SCH_W_H_S_TOOL_ASSIGNMENTS)

BADGE_HTML_COLOR

BALANCED_BATCH_TYPE

This parameter tells the scheduler whether and how the batch balance logic should be applied. Null means the logic is turned off. MATCH means that all lots in the balance group/pair must have unit quantities within this range. PREFER means that the scheduler should try to meet the criteria for MATCH, but if it cannot be met to add the next best lots to make a fuller batch. The maximum batch size for the process context must also be 4 lots/carriers if this value is not null. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

BALANCED_BATCH_QTY

When configured for balanced batching, this represents the maximum delta in unit quantity for lots to be considered balanced. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)

SCH_CUSTOM_SETUP_MSG

Allow users to define a custom message to display on top of a lot box. (* inherited from FPSINPUT.RTG_TOOL_ASSIGNMENTS)