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 requirement means here, and the architecture that lets an outside visitor run a real production PDK without ever touching it. Measured results are not on this site — they belong in a paper.

§ 01Inverse design

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, and the choice is not cosmetic: how a model is wrong when it leaves the data it was trained on determines the shape of the correction that can fix it, which is what the next section is about.

The constraint set is not advisory. A proposal that satisfies every constraint on the model’s own terms still routinely fails in simulation, and candidate topologies for the same block differ mostly in how they fail: one runs out of headroom, one undershoots across the board, one cannot reach the middle of its range inside its power budget at all.

None of that is predicted by an optimiser reporting zero violations. It is found by running the loop.

§ 02Calibration

A number is only as good as the band measured where it sits.

A pooled error band flatters the range the model was easy on and libels the range it was hard on. Bands here are cut by operating point, and a region with too few points reads unproven rather than borrowing a wider one.

A forward model is not equally wrong everywhere. Pooling its error into one figure hides that shape, and the pooled number is then simultaneously too pessimistic where the model was accurate and too optimistic where it was not — which is the worst of both, because a designer cannot tell which case they are in.

So each prediction is moved by the error measured for the region it sits in, and a region with too few points is reported as unproven rather than allowed to borrow a neighbour’s band.

A correction can only take out what is systematic. Where the error is bias, calibration removes most of it; where it is scatter, it removes almost nothing, and saying so is more useful than a tighter-looking claim.

Validation is taken out of sample — a fresh operating window, with no hand-set margin — because a band fitted and reported on the same data is not a band. Where a corrected band is still wider than the requirement it has to police, the model is recorded as screening only and is not used to choose between candidates.

§ 03Verification

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.

  1. Specification

    spec_input

    The quantities the block is asked to hit, as numbers inside published ranges — never a file, never code.

  2. Inverse design

    inverse_design

    A 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.

  3. Netlist render

    netlist_render

    A lab-authored template renders the deck. Parameters are bounds-checked numbers; nothing supplied from outside is interpolated into a simulator input.

  4. Spectre verify

    spectre_verify

    The candidate block is simulated on its own testbench 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.

  5. Extract

    extract

    Heads are measured from the simulation, not read back from the model. A head the loop cannot check is reported as unchecked.

  6. Rank

    rank_result

    Candidates are ranked by measured margin against every gate. What returns to the browser is metrics and plots — nothing else.

§ 04Architecture

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.

  1. 01

    Browser

    anywhere

    Submits a template id and numeric parameters. Polls for status.

  2. 02

    Portal

    Vercel · pdx1

    Authenticates, bounds-checks, writes a row. Holds no PDK and runs no simulator.

  3. 03

    Job table

    Postgres · us-west-2

    The only thing both sides touch. Claims are atomic; the queue is the interface.

  4. 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.

§ 05Disclosure

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.