Managing Time Constraints between Process Steps in Wafer Fabs

In wafer fabrication, it is not uncommon to have time constraints between process steps. That is, a lot must start processing at a later operation within some time window after completing processing at an earlier operation. A common example is a bake step that must be completed within some time window of the prior clean operation. Such constraints are also called queue time limits, time bound sequences, and time links. They are typically put in place by process engineers to improve yields in the fab. 

If the time constraint is violated, the lot must go back to the first operation in the sequence for reprocessing. When this happens, capacity is lost at tools running the first operation (increasing cycle time for all lots that use that tool), and cycle time of the reprocessed lot is increased by the reprocessing time. There is also increased variability in the arrival rate to the later operation. There can be intervening steps between the initial and final operation of a time constraint loop. These multistep systems are particularly difficult to manage. Even a system involving two steps holds considerable complexity. 

To accurately plan capacity for tools subject to time constraints, we need a way to estimate the percentage of lots that will be reprocessed. Operationally, fabs need to make dispatch or scheduling decisions that minimize the chance of the time constraint being violated. In this article, we will discuss capacity planning methods, then move on to operational issues, and close with a few recommendations for coping with time constraints in practice.

The capacity of a system is the maximum feasible arrival rate of work to the system, or, equivalently, the maximum achievable throughput rate of the system. The behavior of a time constrained system with more than two operations is difficult to predict except at very low tool utilizations. In the low utilization case, lots flow through with few delays, and are rarely sent back for reprocessing. At higher arrival rates, or for highly variable systems, time constrained systems can rapidly become unstable. Once a few lots are delayed enough to be sent back for reprocessing, these lots increase the arrival rate to the earlier tools. This in turn increases queuing delays and makes it more likely that other lots will be sent back. A “vicious cycle” ensues, making predicting system capacity difficult. 

Time constraint loops with intervening steps are difficult to predict and difficult to operate. We recommend avoiding them as much as possible. For the remainder of this article, we will focus on time constraints between two operations. 

Understanding the capacity of a time-constrained system, even with only two operations, requires understanding the distribution of lot cycle times (to understand the probability of any given lot being sent back). This distributional data would not typically be included in spreadsheet models. These models usually include, at best, static data such as average cycle times. Even queuing models rarely capture the entire distribution. Therefore, to fully understand the behavior of a time-constrained system, capacity planners would typically need to use simulation. 

In her earlier research, Jennifer Robinson developed a simple approximation for the probability of lots being reprocessed based on queuing formulas for time constrained systems involving two operations. She compared results from the approximation with results from a discrete event simulation for various system parameters. The approximation performed well in predicting the probability of reprocessing for highly variable systems. It provided an upper bound that could be included in spreadsheet capacity models. In the interest of space and complexity minimization, we will send those of you who are interested in the details of the approximation to the Winter Simulation Conference paper. 

Here are two final notes on the capacity planning research: 

1. The primary issue addressed here is the capacity impact on the first tool in the time constraint link. The loading of the final tool doesn’t change due to reprocessing (because lots are reprocessed only at the earlier operation), though the arrival distribution to the downstream tool might change. 
2. In her research, Jennifer did not capture the impact of downtime. While this was a reasonable and perhaps necessary omission in a research context, equipment downtime in practice has a huge impact on the operation of time constraint sequences.

It’s all well and good to have a model for predicting the average percentage of lots that will need to be reprocessed due to time constraint violations. In practice, what people running a fab want to do is ensure that lots are sent back for reprocessing as rarely as possible.

Reprocessing adds to lot cycle time, uses extra consumables, and takes up extra capacity. What we commonly see is fabs holding lots at the first operation in a time constraint loop, and only processing at that operation when they have reasonable confidence that the lot will make it all the way through without violating the time constraint. Policies for starting a lot on the upstream tool might look something like this:

• Don’t start lots at the upstream operation when the tool needed for the downstream operation is unavailable; and 
• Don’t start lots at the upstream operation when the WIP in front of the downstream operation is too high.

But of course, fabs being fabs, even these relatively straightforward policies become complex the closer we look. Questions must be addressed, such as:

• How high is “too high” for WIP at the downstream tool? How can we tell? 
• What dispatch rule is followed at the downstream tool? In the reentrant environment of the fab, how do we prioritize lots within time constraint loops at the downstream step over other lots that might be there for other steps? What happens if a hot lot comes through? Are we prepared to violate the time constraint for other lots to get a hand-carry lot through? In the FabTime dispatch module we have a reservation system, such that a spot can be reserved on the dispatch list for the downstream tool when the lot is processed on the upstream tool. But, of course, the reservation is no guarantee that the lot will arrive in time. 
• What if there are multiple downstream tools that could be used, and only one of them is down?
• What if the downstream tool is unavailable because of a PM, where we know when the PM is scheduled to finish? Should we count on that? Do we have any information to tell us when a tool in unscheduled downtime might come back up? 
• What if the downstream tool is a batch tool? How hard should we try to get enough lots through the upstream tool to form a batch?

It matters what the queue time limit is relative to the downstream operation’s process time, too, because that impacts how much of a queue we’ll allow to accumulate. If the time constraint is 24 hours, and the downstream step process time is 1 hour, we can afford to let multiple lots through. We would normally want to do that to avoid starving the downstream tool, especially if the upstream tool has reliability issues. However, in this case we wouldn’t want to let more than 24 lots wait at one time (and probably fewer because the downstream tool could go into unscheduled downtime in the next 24 hours).

Here are a few suggestions for minimizing the possibility of lots violating their time constraints.

• We heard previously from a newsletter subscriber that his or her fab attempted to require 100% uptime on the critical tools but acknowledged that such a requirement was not “functionally helpful.” Our suggestion is instead to focus maintenance teams on reducing the duration of any repair or PM time at the downstream tool. It’s not total availability that matters here, but minimizing the chance of the tool not being available when the time constrained lot arrives. This ties back to one of our general recommendations for improving fab cycle time, not grouping maintenance events. 
• Managing time constraint loops is also an excellent case for using alerts. In the FabTime software, alerts are set by individuals based on lot or tool status and are sent as short emails or text messages. We recommend setting an alert for any lots at the downstream step that are nearing their time constraint, so that these don’t slip through the cracks. 
• Communication, via alerts or some other method, should also be used to ensure that: 
  • Once a lot has started in a time constraint loop, no new PMs are scheduled; and 
  • Once a PM is scheduled, at least a longer PM, no new lots are started into the constraint loop. 
• Qualifying additional tools for the downstream step in a time constraint link will also, naturally, reduce the probability of violating the time limit. The probability of two tools going down at the same time is much smaller than the probability of just one tool going down. As with everything else in the fab, managing time constraints is hardest in the case of one-of-a-kind tools or single path operations. 
• Consider using the WIP Hours metric. WIP Hours measures the estimated hours of required processing time for WIP in queue at a tool. If you track WIP Hours (as we do in our software), you could set an alert for when WIP Hours at the downstream tool exceeds some value X (close to but not equal to the time constraint, perhaps considering tool availability in some way). You could then stop releasing WIP from the upstream tool, and re-start later based on some other trigger (WIP Hours went below value Y). An example is shown below.