advanced process control
Advanced process control is the layer of a fab that chooses what recipe the next lot will run, using what the last lot measured. It is not statistical process control, which watches a process and halts it when it misbehaves; APC moves the knobs while the line keeps running. A modern 300 mm logic fab carries somewhere between five thousand and fifty thousand independent control threads, one for each combination of tool, chamber, product and layer, and the overwhelming majority of them are the same small exponentially weighted moving average controller with different constants. The quantity that decides whether any of them earns its keep is not a gain, a filter weight, or a model order. It is the number of lots that pass between a wafer being processed and its measurement coming back, and that number is set by the metrology queue rather than by the control engineer.
```svg
```
**The exponentially weighted moving average is not a filter choice, it is the entire controller.** Model a single thread as an output that drifts: the measured result of lot k is an unknown offset plus a gain times the knob setting plus measurement noise, and the offset walks by a small amount every run as the chamber seasons, the target erodes or the bath ages. The controller estimates that offset by blending the newest residual with the previous estimate at weight lambda, then inverts its process model to pick the next setting. That is the whole algorithm, and it has been the whole algorithm since Sachs, Hu and Ingolfsson published run-by-run control in IEEE Transactions on Semiconductor Manufacturing in 1995. SEMI E133 standardises the framework the controller lives in and SEMI E30 GEM carries the messages, but neither standard specifies the math, because in practice there is only one piece of math. Commercial platforms — Applied Materials E3 and SmartFactory, PDF Solutions Exensio, Inficon FabGuard, Siemens Opcenter — differ almost entirely in how they thread, version and gate the controllers, not in what the controllers compute. Lambda is the single knob most engineers ever touch, and the folk wisdom around it, that a small lambda is a smooth controller and a large lambda a responsive one, is correct and almost irrelevant.
**The loop has a closed-form error, and that error splits into a term the controller owns and a term it cannot reach.** When the process gain in the model equals the true gain, the offset estimate does not depend on the knob at all, so the loop is exactly solvable rather than merely simulable. Writing the drift per run as delta and the measurement noise as sigma, and counting the metrology delay in lots as d, the mean squared error of the output settles at a value with two clean pieces:
$$\mathrm{MSE}(\lambda, d) \;=\; \delta^{2}\left(d + \frac{1}{\lambda}\right)^{2} \;+\; \frac{2\sigma^{2}}{2-\lambda}$$
The first term is squared steady-state bias, and it is the controller running permanently behind a drifting process by exactly delta times the quantity d plus one over lambda. The second term is measurement noise that the controller has copied onto the wafer by acting on it. Lambda pulls the two terms in opposite directions, which is why the error curve is a shallow bowl. The delay d sits inside the first term and nowhere else, and no choice of lambda removes it: even with lambda driven to its largest useful value the bias cannot fall below delta times d. A 200,000-run Monte Carlo of the same loop agrees with the closed form to better than one percent — at lambda 0.30 and a delay of 3 lots the simulation gives an RMS of 1.121 against the predicted 1.130, and at 12 lots it gives 1.321 against 1.328 — so the algebra can be trusted as the design tool it looks like.
**Retuning the filter is worth about one percent, and removing the queue is worth up to seventy.** Take a chamber drifting at 0.05 sigma per run, which is a realistic etch or CMP rate, and compare two interventions against a typical fixed-lambda 0.30 controller: pick the best possible lambda for the delay you have, or leave lambda alone and shorten the delay to a single lot.
| Metrology delay (lots) | Optimal lambda | Best achievable RMS (sigma) | Irreducible bias floor (sigma) | Gain from retuning lambda | Gain from cutting delay to 1 lot |
|---|---|---|---|---|---|
| 1 | 0.213 | 1.096 | 0.05 | 1.0% | — |
| 3 | 0.237 | 1.125 | 0.15 | 0.5% | 2.6% |
| 6 | 0.270 | 1.180 | 0.30 | 0.1% | 7.1% |
| 12 | 0.325 | 1.328 | 0.60 | 0.1% | 17.5% |
| 24 | 0.409 | 1.734 | 1.20 | 0.6% | 36.8% |
| 72 | 0.601 | 3.872 | 3.60 | 1.2% | 71.7% |
The retuning column never exceeds 1.2%, and at 6 and 12 lots of delay it rounds to nothing, because a fixed lambda of 0.30 already sits inside the flat bottom of the bowl for every delay a fab is likely to have. The delay column reaches 71.7%. An APC improvement program that spends a quarter arguing about filter weights and a footnote on sampling plans has inverted its own arithmetic. The correct order of operations is to shorten the measurement path first — more in-line metrology, smaller sampling skip, measure the first wafer instead of the last — and only then tune.
**Faster drift does not change that conclusion, it sharpens it.** Sweeping the drift rate shows the optimum lambda rising with both drift and delay while the flatness of the bowl survives. At 0.02 sigma per run the optimum runs from 0.11 at zero delay to 0.19 at 24 lots and the achievable RMS from 1.04 to 1.20. At 0.05 it runs 0.20 to 0.41 and 1.08 to 1.73. At 0.10 it runs 0.31 to 0.67 and 1.13 to 2.83. At 0.20 the optimum saturates at 1.00 and the RMS reaches 5.20, meaning the controller has stopped controlling. What that table really says is that delay and drift multiply. The same chamber drifting at 0.20 sigma per run holds an RMS of 1.30 at a one-lot delay and 5.20 at 24 lots — a factor of four, produced entirely by queue time. This is why a chamber that behaves on one product and misbehaves on another is usually not a chamber problem: the misbehaving product is the low-volume one, whose lots wait longer between measurements.
**Model error, not measurement noise, is what actually drives an APC loop unstable.** When the modelled gain differs from the true gain the offset estimate stops being open-loop and the system closes on itself, with characteristic polynomial z to the power d plus one, minus one minus lambda times z to the power d, plus lambda times the gain ratio minus one. Scanning that polynomial for the largest stable lambda gives a result that surprises people who expect delay to be uniformly dangerous. With the gain ratio at exactly 1.0, every lambda below 2 is stable at any delay whatsoever, because there is no feedback path to destabilise. At a gain ratio of 2.0 the ceiling on lambda is 0.995 and it does not move with delay at all. At 3.0 the ceiling collapses as the delay grows: 0.495 at zero delay, 0.280 at 3 lots, 0.165 at 6, 0.090 at 12 and 0.045 at 24. The consequence is a specific and very common failure. A loop with a threefold gain error and 24 lots of delay must run lambda below 0.045 to stay stable, but its error-optimal lambda is 0.409, and the forced retreat multiplies the bias term from 26 to 46 and costs 46% in RMS. Every fab has controllers that were turned down until the oscillation stopped and then never touched again; the oscillation was a model problem, and the detuning converted it into a permanent bias problem.
**Virtual metrology is worth building only when you can state in advance how wrong it is allowed to be.** A virtual metrology model predicts a measurement from chamber state — optical emission spectroscopy traces, RF match positions, gas flows, endpoint timing — using regression, gradient boosting or a Gaussian process, and its selling point is that it is instant. The question that decides the program is not how accurate the model is but how accurate it must be to beat the perfect measurement it replaces, and the closed form answers it directly by setting an instant estimate with error e against a perfect measurement arriving d lots late. At a delay of 3 lots, an instant estimate wins only if its error stays below 0.96 sigma, which is to say it must be almost as good as the CD-SEM. At 6 lots the bar is 1.59 sigma, at 12 lots 2.96 sigma, at 24 lots 6.43 sigma, and at 72 lots 28.21 sigma — a prediction six times noisier than the metrology tool still beats the tool. This explains the observed record cleanly. Virtual metrology succeeds on overlay, post-CMP thickness and film stress, where queues are long and sampling is sparse, and disappoints on steps that already carry integrated metrology, where the bar is a fraction of a sigma and no chamber-state model clears it. KLA, ASML, Lam Research and Tokyo Electron have all pushed measurement into the tool for exactly this reason: an in-situ sensor does not need to be good, it needs to be early.
**The hardest decision in an APC deployment is what counts as the same process.** A controller thread must be narrow enough that its offset is genuinely one number and wide enough that lots arrive often. Split by tool, chamber, product and layer and a fab with 4 tools, 3 chambers and 6 products on one layer has 72 threads; a line that measures one lot per hour then feeds each thread once every 72 hours, and the effective delay in the equation above becomes 72 rather than 1. Merge the threads and the estimate is polluted by real chamber-to-chamber differences, which appear to the loop as noise and get copied onto wafers. Nearly every large APC gain of the last decade came from resolving this tension rather than from better control math: shared offsets with per-chamber corrections, hierarchical models that pool across products, feedforward from incoming measurements so a lot does not have to wait for its own feedback, and context grouping rules that treat two products as one when their process response is genuinely identical.
```flowchart
{ "rows": [
{ "type": "nodes", "items": [
{ "title": "Lot processed", "sub": "recipe set by the controller's current offset estimate", "tone": "green" },
{ "title": "Metrology queue", "sub": "sampling skip, tool availability, thread width — this is d", "tone": "red" }
] },
{ "type": "arrow" },
{ "type": "group", "title": "Where the delay actually comes from, in the order worth attacking", "note": "each of these shortens d; none of them is a control-theory change", "items": [
{ "title": "Sampling plan", "sub": "measuring 1 lot in 12 makes d at least 12 before any queue", "tone": "red" },
{ "title": "Thread granularity", "sub": "4 tools x 3 chambers x 6 products = 72 threads, 72x the wait", "tone": "red" },
{ "title": "Metrology tool queue", "sub": "the only piece most improvement programs actually look at", "tone": "orange" },
{ "title": "Data path and gating", "sub": "review, disposition and upload latency after the measurement exists", "tone": "orange" }
] },
{ "type": "arrow" },
{ "type": "group", "title": "What to do once d is as small as it will go", "note": "worth at most 1.2% of RMS, and only now", "items": [
{ "title": "Retune lambda for the delay you have", "sub": "0.21 at 1 lot, 0.27 at 6, 0.41 at 24, 0.60 at 72", "tone": "green" },
{ "title": "Fix the process-gain model", "sub": "a 3x gain error caps lambda at 0.045 when d = 24", "tone": "green" },
{ "title": "Add virtual metrology where the bar is low", "sub": "at d = 24 an estimate 6.43 sigma noisy still wins", "tone": "green" }
] },
{ "type": "arrow" },
{ "type": "nodes", "items": [
{ "title": "Offset estimate updated", "sub": "bias floor remains drift x d, whatever lambda was chosen", "tone": "orange" }
] }
] }
```
Read advanced process control through a *latency* lens rather than a *controller* lens. The controller is a two-line recursion whose optimal tuning is flat enough that a single default serves an entire fab, and whose worst realistic mistuning costs about one percent. The delay between processing and measurement enters the error as a term nothing in the controller can cancel, scales that error by a factor of four across the range of queues real fabs run, and is determined by sampling plans, thread definitions, metrology capacity and data-path latency — four things owned by industrial engineering, not by control. When an APC program stalls, the useful question is almost never which filter is being used. It is how many lots go by before the loop finds out what it did.