Generate

Test Program Generation

From an ingested spec to a complete IG-XL project — Flow, TestInst, Limits, Binning and Pin Levels sheets, VBT modules, digital patterns — generated one requirement at a time and pushed through deterministic validators before an engineer sees it. The model drafts; the checkers decide.

Overview

Generation is not one large prompt. Each requirement gets its own draft, with test numbers owned by code — not by the model — so a hallucinated number cannot break the spec → program → STDF join. The drafts assemble into one project against a device profile the spec ingestion produced.

Test Generator page mid-run — Fig. 1 — The Test Generator: per-requirement progress, validator findings and repair status for a run against the TMP126 spec.

Serial and digital tests do not bit-bang. Where a requirement needs a pattern, the pipeline emits a real Pattern Generator .atp file deterministically from the protocol model, plus a thin VBT wrapper that starts it — the same engine that drives the interactive Pattern Generator page. The ChanMap sheet is emitted from the project's saved channel plan, so the program's channels match the board's by construction rather than by luck.

Generate, check, repair, present

Every run follows the same shape: generate, machine-check, repair at most twice, then present. A clean first generation makes zero extra LLM calls. A result that still fails after two repair rounds is presented with its findings — never silently shipped, never looped forever.

Fig. 2 — The repair loop. The validators are the judge; the model only proposes targeted revisions.

The checkers

Deterministic, cited, and shared with the interactive surfaces — the generator cannot pass a check the review pages would fail.

Check	Scope	What it catches
VBA validator	each VBT module	Documented instrument prohibitions and minimum settle times, drawn from the knowledge registry — a generation that waits less than the documented minimum is flagged with its source.
Cross-sheet validator	whole project	8 rules across Flow / TestInst / Limits / Binning / Pin Levels: argument ceilings, opcode allowlist, TName/TNum/Bin resolution, sheet cross-references, Tdelay sanity.
Instrument validation	VBT API usage	Grounded in the tester type library — constants, members and object paths are checked against the instrument's real API, not a remembered one.
Pattern-artifact gate	patterns	Every pattern the program starts must exist as an on-disk `.atp` — a referenced-but-missing pattern is a finding, not a surprise at the tester.
Offline preflight	whole project	A battery of checks over the whole assembled program — channel strings, pin references, capability ranges. Most were ratcheted from a real bench failure the vendor tools caught live. The VBA-syntax checks are the exception, and exist for the opposite reason: the vendor's validation step does not compile VBT at all, so those are an offline proxy for a compile no tool performs until the workbook is opened.
Device model	semantics	The generated program and its patterns replayed against a model of the DUT — catching the wrong register, a compare the device can never satisfy, or a measurement taken in a state the flow never established. Everything it cannot judge is declined with a reason, never passed quietly.

The knowledge behind the checks is a typed registry of UltraFLEX instrument behaviour, authored in our own words. Every entry cites its source document and carries a confidence tag — documented, inferred, partial or industry-standard — and the prompt's worked example is locked by test against a working reference programme.

How it works

Load the device profile.
Pins, rails and instruments come from the spec ingestion. If the profile has no pins, generation refuses to run — a program invented against imaginary pins is worse than no program.
Draft per requirement.
Each requirement becomes its own LLM draft, grounded with callable tester-knowledge tools. Test numbers and identifiers are assigned by code, not by the model.
Emit patterns deterministically.
Serial and digital tests get real .atp patterns from the protocol engine — cyclized vectors, not free-form bit-banging — plus a VBT wrapper that starts them.
Assemble and validate.
Drafts assemble into the full sheet set; the ChanMap binds to the saved channel plan. The validator battery runs and its report is stored as an artefact of the run.
Repair what failed, at most twice.
Findings go back to the model as a targeted critique — including the real part and API detail the finding names — then everything re-checks. Two rounds maximum.
Gate, then compile.
Offline preflight gates run before any bench dispatch. The final authority is IGLinkCL compiling the real workbook — and the platform labels which is which.

Project detail page with the generated program — Fig. 3 — The generated TMP126 program on the project page: sheets, VBT modules and pattern files, with requirement coverage alongside.

On the TMP126 demo

The 34-requirement TMP126 spec generates a complete program: 34 of 34 tests implemented, 100% requirement coverage, every test attributed to its pins — SCLK, SIO, CS, VDD and ALERT — and 24 deterministic SPI patterns emitted for the protocol, register and temperature-read tests. The 3-wire SPI interface, with its bidirectional SIO pin, is handled by the same protocol model the Pattern Generator page uses interactively.

Because the test numbers came from the spec and were never in the model's hands, the traceability dashboard joins all 34 tests back to their requirements — and forward to the board nets and production lots — without a single fuzzy match.

Structural validity is only half the question, though. Whether those 34 tests do what the spec asked of this device is answered by replaying them against a behavioural model of the TMP126 itself — see Device-Model Verification.

Honest boundary Offline-green is not tool-correct. The validators and preflight gates prove what they can prove offline; final compile authority remains IGLinkCL and IG-XL itself, and results are labelled accordingly. Every failure the real toolchain finds is ratcheted into a new offline check, so the gap only narrows.