Generate
PCB Generator
Describe the load board; the generator authors it against your spec. The prompt is joined with the project's ingested requirements, the model writes tscircuit source grounded in a cited ATE pattern library, the result compiles in-process and offline, and the same findings collector that powers the analysis hub drives a bounded repair loop before anything is presented.
Design-to-spec authoring
A load board is not a generic PCB — it exists to serve a test program. So the generator does not start from the prompt alone: it injects the project's test requirements as design context. A spec that forces 3 mA on an output pin, or measures supply current to microamp limits, changes what the board must contain — terminations, Kelvin sensing, decoupling — and the model sees those requirements before it places a single part.
What the model writes is tscircuit source — typed JSX that compiles to the same
canonical circuit-json every other design in ATE·IQ uses. The output is a
first-class design: it lands in the library with provenance llm,
renders through the multi-sheet schematic engine, and runs through the full
analysis hub like any imported board.
Grounded, not recalled
The model does not design from memory. Two libraries ground it:
| Library | Contents | Role |
|---|---|---|
| ATE pattern library | Load-board design patterns — form factors, decoupling schemes, grounding, Kelvin sensing, probe heads, routing conventions — each cited to its source and carrying a copy-paste tscircuit template. | What to design. |
| Reference parts library | A curated parts catalogue with real pin maps and footprint strings per part. | What to build it from — and, in repair, the ground truth a critique quotes. |
The parts library earns its keep in the repair loop. When a finding names a part, the repair critique inlines that part's real pins and footprint from the library — the model corrects against recorded data, not against its own recollection of a datasheet. Matching is precise by design: only a definite part-key match is inlined, never a fuzzy description guess.
Compile, check, repair, present
Every run follows the same bounded shape. Compilation is in-process and offline — no network, no external toolchain — and the checks are the same findings collector the analysis hub runs, so the generator cannot pass a check the review page would fail.
- Assemble the context.
Your prompt, the project's requirements, and the relevant ATE patterns — with their tscircuit templates — form the generation input.
- Author tsx.
The model writes tscircuit source. Parts come from the reference library where they exist; conventions come from the cited pattern set.
- Compile offline.
The tsx compiles to circuit-json in-process, with no network access. A compile failure is itself a finding.
- Run the collector.
The same machine-check stack the analysis hub uses — structural checks, ATE rules, DRC — runs over the compiled design.
- Repair, bounded.
Findings return to the model as a targeted critique, with real pin and footprint data inlined for any named part. Recompile, re-check. Two rounds maximum.
- Present honestly.
A clean result presents clean, having cost zero extra model calls. A result still failing after two rounds presents with its findings attached.
On the TMP126 demo
The TMP126 load board began as exactly this kind of run: the 34-requirement spec in context, the ATE pattern library supplying the series-termination, ESD-protection, decoupling and Kelvin force/sense conventions, and the compiled result landing in the library as a normal design — the one the PCB Designer, Board Intelligence and Traceability pages of this guide then work on.
Because generation targets the spec, the downstream joins hold: the board's nets carry the program's pin names, the channel flags come from the saved plan, and the traceability dashboard traces every test onto the generated copper.