FPSADMIN.EQP_CHAMBERS_CHGLOG

CHG_TIMESTAMP

TIMESTAMP(4)

N

For CHGLOG and automatic HIST tables, this is populated with SYSTIMESTAMP. This means that this record existed in the original table from this time until NEXT_CHG_TS. (* from FPSINPUT.EQP_PORT_HIST)

FACILITY

VARCHAR2(6)

N

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)

CHAMBER

VARCHAR2(19)

N

Chambers belong to a main tool, have a state which is independent of the main tool and other chambers on the same tool, and can have events logged against it. The difference between a chamber and a port is that a chamber processes lots while port is just a location. (* from FPSINPUT.EQP_CHAMBERS)

ACTION

VARCHAR2(1)

For CHGLOG and automatic HIST tables, this is I for insert or U for updated or D for delete. (* from FPSINPUT.EQP_PORT_HIST)

ASSUME_ALL_CH_USED_ON_BEG

CHAR(1)

Normally when we log a BEGIN event in WIP_EVENT_HIST to a chamber, we assume that only that chamber is used and we set only that chamber to PRD and keep the other chambers on the tool in SBY. However in some rare cases, usually on Litho cells, we want to treat the BEGIN like it was logged to the main tool and assume all chambers used and set all chambers to PRD. This flag allows us to do that. Note this flag has to be set for the chamber that logs the BEGIN event rather than the other chambers that we are assuming will be used. (* from FPSINPUT.EQP_CHAMBERS)

CH

VARCHAR2(1)

A single character to identify the chamber which must be unique with the tool. We concatenate the CH to get the string for CH_USED so it is helpful for diagnostic purposes if this single character is representative of the chamber (i.e. A for ET12CHA or 1 for MD27C1) because then the CH_USED string makes sense. However it is not required and if the chamber naming is inconsistent we might get use 1, 2, 3, etc. for the CH. (* from FPSINPUT.EQP_CHAMBERS)

CH_SHORT_DISPLAY

VARCHAR2(4)

Short display for the chamber displayed on Dashboard and reports as part of a list of chambers used. This should not include the tool name but only the chamber on the tool so if the chambers on ET11 are ET11CHA and ET11CHB1 and ET11CHB2 then this field should be A, B1, and B2. (* from FPSINPUT.EQP_CHAMBERS)

CH_TYPE

VARCHAR2(6)

This column is critical for sequential chamber tools where a wafer goes through multiple chambers. It identifies the type of chamber so two chambers with the same ch_type are identical and wafers can use either one. See comment on mfg_pct_per_ch column for an example. For independent chamber tools where all chambers are the same and each wafer goes to only one chamber then ch_type should be set to the default value CH so that ch_type_cnt is 1CH, 2CH, 3CH, etc. (* from FPSINPUT.EQP_CHAMBERS)

DB_MACHINE

VARCHAR2(64)

For CHGLOG and automatic HIST tables, this is populated with the HOST system variable from USERENV.

DB_OSUSER

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the OS_USER system variable from USERENV.

DB_USERNAME

VARCHAR2(30)

For CHGLOG and automatic HIST tables, this is populated with the USER system variable.

DESCRIPTION

VARCHAR2(256)

Tool desciption. This value is only used to display in the Dashboard. (* from FPSINPUT.EQP_TOOLS)

IS_ASSIST_CHAMBER

CHAR(1)

This indicates that the chamber assists the other primary chambers. If an assist chamber is in ch_allowed then at one least chamber of the ch_type must be up but as long as this is true then we ignore the assist chambers. We send only the non-assist chambers to the schedule as ch_to_sched. (* from FPSINPUT.EQP_CHAMBERS)

IS_LOCATION

CHAR(1)

Y means this chamber is an acceptable location for material to be stored and the chamber will be passed through as an allowed location to other relevant DWH objects. The default is N which means the chamber is not an acceptable location. (* from FPSINPUT.EQP_CHAMBERS)

IS_SEC_FOR_BEG_END

CHAR(1)

Set to Y to store begin and end events logged to this entity in the SEC_BEGIN_INST and SEC_END_INST columns in WIP_STEP_HIST. The common example is for steppers where the begin and end for the lot will be from the track but we also want to store the begin and end for the stepper. (* from FPSINPUT.EQP_CHAMBERS)

IS_VIRTUAL_CHAMBER

CHAR(1)

This flag determines whether a chamber is a virtual chamber on a tool. Virtual chambers are used for scheduling but are not tracked like real processing chambers or assist chambers in other applications. Virtual chambers exist in ETP but always contribute 0% towards the cluster calculation for the tool. An example of this usage would be to model each of the sources for an implanter as a virtual chamber, so the area would be able to log these chambers up and down as needed. When a source needs replacement, it can be logged down and the scheduler will not schedule lots needing that source, instead switching to one of the available sources. Another example would be modeling the robot as a virtual chamber on a tool. (* from FPSINPUT.EQP_CHAMBERS)

MFG_PCT_PER_CH

NUMBER(7,4)

This optional value is the mfg_pct of the tool when this chamber is the only chamber of its ch_type that is MFG (PRD or SBY) while all chambers of all other ch_types are MFG. This column applies to sequential chamber tools which have chambers of more than one ch_type and have multiple chambers with the same ch_type. The default if this column is not set is to assume that all ch_types are bottlenecks of the tool so if 3 of 4 chambers of one type are MFG then the mfg_pct for that type is 75. If 2 of 3 then 66.7% and so on. But typically one ch_type is the bottleneck which means that if a chamber of another type is NONMFG (ENG or UDT or SDT) then the mfg_pct of tool is better than the ratio. Let us say a tool has two clean chambers C1+C2 and three deposition chambers C3+C4+C5. C1+C2 have ch_type CLEAN while C3+C4+C5 are all DEP. If both C1+C2 are NONMFG then the mfg_pct of the tool is 0% regardless of the status of the DEP chambers because it has no CLEAN chamber. Similarly if all three of C3+C4+C5 are NONMFG then it is also 0%. Of course if all chambers are MFG then it is 100%. But if at least one chamber is MFG while at least one of the CLEAN chambers and at least one of the DEP chambers is MFG then the tool can still run albeit with a degraded throughput. By default if only one of C1+C2 is MFG then the mfg_pct of the ch_type CLEAN is 50%. Similarly if one of C3+C4+C5 is MFG then the mfg_pct of DEP is 33.3% and if two then 66.7%. Technically the default calculation is 100/n where n is the number of chambers of the ch_type. But if the CLEAN chambers are the bottleneck and only one DEP chamber is NONMFG then the throughput will exceed the default of 67% and this mfg_pct_per_ch value is an estimate of this. If the mfg_pct_per_ch for DEP is 40 that means the throughput will be 40% with one DEP chamber up and 80% with two DEP chambers up. So the mfg_pct of the ch_type is p * number of MFG chambers (but no more than 100 of course) and the mfg_pct of the tool is the minimum of the mfg_pct of each ch_type. One final note is that mfg_pct_per_ch is an approximation of the contribution of each chamber for all recipes but in reality each recipe can be different. If we know the throughput for the chamber combination for the recipe then we use that instead of the mfg_pct_per_ch. For example, if C4 is NONMFG, mfg_pct_per_ch tells us the tool mfg_pct is 80% and we use that 80% number if the tool is standby or if we do not know the throughput on C1+C2+C3+C5 for the recipe running. But if we know that recipe runs at 30 UPH with all five chambers but 27 UPH with C1+C2+C3+C5 then we set the tool mfg_pct to 90%. (* from FPSINPUT.EQP_CHAMBERS)

OVR_EQPTYPE_FOR_CAPACITY

VARCHAR2(50)

This is an alternative to shared parent tool that currently works only for custom reporting. This field tells us to count this chamber in a different eqp_type than its main tool for capacity modeling purposes. (* from FPSINPUT.EQP_CHAMBERS)

OVR_MSO_GROUP

VARCHAR2(64)

Overrides the default CH_TYPE for grouping of chambers to be used for rules in MSO that will allow for different rule configurations for chambers on the same tool. Will generally be used similar to chamber types, but this override field allows a grouping specific to MSO. (* from FPSINPUT.EQP_CHAMBERS)

OVR_PLAN_AVAIL

NUMBER(5,2)

Normally the planned availability set for each eqp_type applies to all chambers but for custom reporting only we can override the value for a specific chamber with this column. (* from FPSINPUT.EQP_CHAMBERS)

OVR_PLAN_UTIL

NUMBER(5,2)

Normally the planned utilization set for each eqp_type applies to all chambers but for custom reporting only we can override the value for a specific chamber with this column. (* from FPSINPUT.EQP_CHAMBERS)

OVR_SORT_ORDER

NUMBER(4)

The default sort order of chambers within a tool is to put assist and virtual chambers last then sort by ch_type then ch_short_display. To override this sort order just populate this optional column. If this is set for some chambers but not all on the tool then chambers where this is blank will be last sorted by the default order. (* from FPSINPUT.EQP_CHAMBERS)

SET_FILLIN_ALLOWED_IF_MFG

CHAR(1)

For chamber tools with multiple ch_types, we use either the RTG_TOOL_ASGN_LOT_xxx_PATHS table or ch_allowed to determine what ch_types are required for each lot/recipe. If we do not have paths or ch_allowed then our default logic is to assume that at least one chamber of each ch_type on the tool is required. That means that a lot/recipe would be blocked if all chambers of one ch_type are down. This can be inaccurate in either of two cases: 1) ch_type values are not set correctly in EQP_CHAMBERS, or 2) lot/recipe does not require all ch_types on the tool. If we are using Scheduler for this tool, we really need to configure the PATHS table or ch_allowed. But if not then setting this flag to Y for a chamber means that if we have no paths and no ch_allowed and this chamber is up that the lot will be allowed to process regardless of the status of other chambers on the tool. The est_ch_used in this case would be all chambers with this flag set which are up. Typically we would want to set this to Y for all non-assist chambers on a particular tool but we could also set just for the most important ch_type. (* from FPSINPUT.EQP_CHAMBERS)

SUBTOOL

VARCHAR2(16)

A subtool is an entity in the MES to which events can be logged that is between TOOL and CHAMBER. Subtool is rarely used. One example is when a chamber is part of a side which is part of a main tool and it is possible to log the side down which means you cannot use any chambers on that side. The side would be a subtool. (* from FPSINPUT.EQP_CHAMBERS)

TOOL

VARCHAR2(16)

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

TOOL_MFG_PCT_ALL_TYPE_NONMFG

NUMBER(7,4)

This column indicates tool mfg_pct if all chambers of the ch_type are NONMFG. It works in combination with ch_type, mfg_pct_per_ch, and subtool to allow us to calculate tool_pct for what we currently believe are all cases of chamber combinations. The common example here is a Litho cell which can still run in track-only mode if stepper is NONMFG but cannot run anything if track is NONMFG. Our default is to take the minimum mfg_pct of each type which would result is 0% for the tool if stepper was NONMFG. This column overrides that so if we set it to 60 for the stepper then we would consider the tool 60% even though only the track was MFG. Technically we would assign a tool_pct of 60 to the MFG track and then the remaining 40% to the NONMFG stepper. Another use for this column is when we have an extra chamber of a different ch_type that has limited use, perhaps just for R+D. Here we would set tool_mfg_pct_all_type_nonmfg to 100% and essentially ignore the chamber when it is NONMFG. In this special case, we can also set mfg_pct_per_ch to 0 to completely ignore it in any state. (* from FPSINPUT.EQP_CHAMBERS)

UPDATED_INST

DATE

Time when the record was updated according to the source data. Note this is not the time when the record was actually updated in this table - it will almost always be earlier. (* from FPSINPUT.GEN_FACILITIES)

UPDATE_PRD_TO_SBY_IF_NO_BEG

CHAR(1)

In our ETP logic, when a job begins, we guess what chambers will be used and set ch_proc_state to PRD-JOBBEG. Then when a chamber logs a BEGIN during the job we set that ch_proc_state to PRD-CHBEG and any other chambers which are still in PRD-JOBBEG to PRD-OTHBEG. Then when the job ends, we know that any chambers in PRD-OTHBEG were not used and we set them to SBY for the duration of the just completed job. But before we do this, we must check this flag. For a typical chamber tool this logic makes sense so the flag should be set to Y. But some examples of chambers where this does not make sense are chambers that are required for any processing or remain in a PRD state continuously or do not log chamber events. One example case where we do not want to make updates is for the track on a Litho cell where the track is continuously PRD but the stepper changes from SBY to PRD when starting each lot. If we did not check the flag then this logic would see that for this lot only the stepper logged a PRD event and we would assume that only the stepper was used which is wrong. So we set this flag to N for the track and keep it PRD. (* from FPSINPUT.EQP_CHAMBERS)

USE_CH_PRD_SBY_EVENTS_FOR_ETP

CHAR(1)

The default behavior for ETP is to set the chamber productive state during a job based on BEGIN and END events in WIP_WAFER_HIST. However on some chambers these events are not available so can set this flag to use PRD and SBY events from EQP_EVENT_HIST instead. (* from FPSINPUT.EQP_CHAMBERS)

USE_FOR_FIRST_LAST_WFR

CHAR(1)

This flag determines whether wafer events logged to the chamber should be considered for the first/last wafer begin/end columns which are calculated in WIP_LOTS_REALTIME and then saved to WIP_STEP_HIST upon completion of the step and then used in THP calculations. An example where this is set to Y for all chambers is a parallel chamber tool with all chambers of the same type where each wafer of the job goes to a different chamber. In this case we want the first_wafer_end_inst to be the first wafer end on any chamber. An example where this is set to N would be the stepper on a typical Litho cell where we want the first_wafer_end_inst to be the first wafer end on the track. If we mistakenly set this to Y for both the stepper and track then the first_wafer_end_inst would be the first wafer end on the stepper and the last_wafer_end_inst would be the last wafer end on the track and our average wafer interval would be way too long. (* from FPSINPUT.EQP_CHAMBERS)