We write a lot about what optimized utility design produces — the smallest distribution that serves every tool within capacity. This post shows the two runs that produce it. Both walkthroughs below are real product runs on an illustrative demo fab, about twenty seconds each.
Auto-design: from candidate panels to the smallest set
The auto-design run answers the siting question: how many panels does this fab actually need, and where do they go? A human designer has to commit to a panel count early and make it work. The run does the opposite — it starts generous and earns its way down:
- Lay out candidates. Candidate panels for both substation trains spread across the grid — more than the fab will keep.
- Connect. Every tool connects to its closest feasible panel, so run lengths start short and stay honest.
- Consolidate and prune. The run consolidates load onto the fewest panels that keep runs short, then removes every panel left unused — in the demo, ten candidates become six panels.
- Balance. Paired tool models re-route so every model lands on both trains — redundancy is enforced by the run, not checked afterwards.
The end state is the one we keep coming back to on this blog: the smallest panel set that serves every tool, with the shortest runs the layout allows. Fewer panels means less switchgear, less cable, and less cleanroom floor given over to distribution — which is exactly the mechanism behind the 500-not-700 result on a leading-edge logic fab.
Auto-assign: every tool, the right panel, within the rules
Placing panels is half the job. The auto-assign run answers the wiring question: which tool lands on which panel? At fab scale that's thousands of assignments, and each one has to respect rules that a spreadsheet can't see all at once. The run holds three constraints simultaneously:
- Distance — every assignment takes the shortest feasible run, not the first workable one.
- Build zones — routing stays inside its zone, so the design that comes out is constructible as drawn: no runs cutting across Litho to save a meter on paper that installation gives back tenfold.
- Model balancing — paired tool models split across substation trains A and B. If both units of a model end up on one train, the run flags and re-routes it, so a single-train event can't take out an entire tool model.
A human checks redundancy at the end. The run enforces it the whole way through — a violated constraint isn't a finding, it's a re-route.
The redundancy panel at the end of the run is the part we'd point owners at. Every tool model, its unit IDs, and which train each unit landed on — as a computed, always-current fact of the model, not a row someone maintains. When the layout changes and the run repeats, that guarantee re-derives itself.
Where these runs fit
Both runs are stages of the loop we describe in How it works: capture the demands, optimize, apply the result to the living model, re-run on every change. The demos above are electrical; the same siting-and-sizing logic drives the mechanical side of the distribution, so every system and piece of equipment comes out of one engine with one set of assumptions. And because millions of configurations are evaluated on every optimization run, "re-run it after the layout change" is a click-scale decision, not a re-engineering project.
Today, our engineers operate these runs for you: send the tool layout and the utility demands, and the sized mechanical and electrical distribution comes back with the living model behind it.