Method
A prediction is not a result until something else has checked it.
This page is the long version: what the model does, what the calibration is for, what a gate means, and the architecture that lets an outside visitor run a real production PDK without ever touching it.
Forward model, run backwards under constraint.
A forward model predicts what a sizing will measure. Inverting it under the specification’s constraints turns “what will this do?” into “what should I build?”, which is the question a designer actually has.
The proposal step is cheap and the verification step is not, so the loop is arranged to spend the expensive one well: propose many, move each prediction by its own measured error, discard everything that then fails a gate on paper, and simulate what survives.
Different blocks want different learners. The charge-pump forward model is gradient-boosted trees; the VCO and divider models are transformers over tabular features. That choice is not cosmetic — a piecewise-constant learner extrapolates with a slope error, and knowing that is what makes the correction in the next section the right shape.
The constraint set is not advisory. A proposal that satisfies every constraint on the model’s own terms still routinely fails in simulation, and the four topologies published on the overview page differ mostly in how they fail: one runs out of headroom above a current, one undershoots everywhere, one cannot reach mid-band inside its power budget at all.
None of those were predicted by the optimiser reporting zero violations. They were found by running the loop.
Every number is quoted with the band measured where it sits.
A pooled error band flatters the range it was easy on and libels the range it was hard on. Bands here are cut by operating point, and a bin with too few points reads unproven rather than borrowing a wider one.
| Head | Quantity | Raw | Calibrated |
|---|---|---|---|
| Icp | pump current | 10.34 % | 5.31 % |
| P_pair | pair power | 9.46 % | 5.54 % |
| Ip_compliance | up-branch window | 0.94 % | 0.84 % |
| In_compliance | down-branch window | 1.15 % | 1.06 % |
Pooling hides the shape. The same pump-current band is 10.34 % over the whole range, 2.92 % at 85–100 µA and 11.14 % at 55–70 µA — so the pooled figure is wrong in both directions at once. Validation was taken out of sample, on a fresh current window with no hand-set margin: median error +0.77 %, against +8.6 % uncalibrated.
The stages, in order.
Nothing is reported from the model’s prediction. Heads are measured from the simulation that ran, and a head the loop cannot check is reported as unchecked rather than quietly inherited from training data.
Specification
spec_inputPump current, compliance window, power budget. Numbers inside published ranges — never a file, never code.
Inverse design
inverse_designA learned forward model is inverted under constraint to propose device sizing, then its own calibration moves the prediction by the error band measured for that operating bin.
Netlist render
netlist_renderA lab-authored template renders the deck. Parameters are bounds-checked numbers; nothing supplied from outside is interpolated into a simulator input.
Spectre verify
spectre_verifyThe candidate is simulated against the real foundry PDK, under a CPU and wall-clock ceiling, one job at a time so the department’s licence seats are never contended.
Extract
extractHeads are measured from the simulation, not read back from the model. A head the loop cannot check is reported as unchecked.
Rank
rank_resultCandidates are ranked by measured margin against every gate. What returns to the browser is metrics and plots — nothing else.
The compute host never listens.
There is no inbound port, no tunnel and no bastion into the machine that holds the PDKs. It polls a job table outward, does the work, and uploads a result. A visitor’s request and the machine’s reply never share a connection.
- 01
Browser
anywhere
Submits a template id and numeric parameters. Polls for status.
- 02
Portal
Vercel · pdx1
Authenticates, bounds-checks, writes a row. Holds no PDK and runs no simulator.
- 03
Job table
Postgres · us-west-2
The only thing both sides touch. Claims are atomic; the queue is the interface.
- 04
Worker
lab compute host
Polls outward every few seconds. Renders, runs, extracts, uploads. Never listens on a port.
Isolation
The worker runs as an account that belongs to none of the PDK groups and holds no access to the lab’s data volumes. That is verified by attempting the read as that account, never by reading permission bits — an earlier draft of this design did exactly that and reached the wrong conclusion. Each job runs under a CPU and memory ceiling and a wall-clock kill, inside a rootless container with only what it needs.
Shared licences
The simulator seats belong to a department, not to this project. Demo work is single-flight — one job at a time, the rest queued — so a visitor’s run can never contend with the group’s own simulations. If a licence checkout fails the job waits; it does not retry in a loop against a shared server.
What leaves the machine, and what does not.
This is the line that makes an approved outsider’s run equivalent to reading a published result, rather than equivalent to holding the PDK.
Leaves
- Derived metrics: the heads the loop measured, each with its calibrated band.
- Plots rendered on the host from those metrics.
- Pass or fail against each gate, and the margin.
- Which stage a run is in, and why it stopped if it stopped.
Never leaves
- Netlists, in any form, rendered or template.
- Model cards, device parameters, or anything read out of a PDK.
- Operating points and bias solutions.
- Raw simulator output — psf, raw, logs.
A bounded sweep is still a model-extraction channel if it is large enough, so the grids are coarse and quota is counted per account in runs rather than in requests.