Test program generation

From spec to a checked IG-XL project. Pick a spec and ATE·IQ™ writes the sheets, the VBT code and the digital patterns, with every test keyed to its requirement's test number. It checks the code, the tester setup and the limits, replays the tests against a model of the device (derived from your register map, or one you connect) and lists any it cannot judge. Then it hands you a checked project to load in IG-XL, refine with the IG-XL agent and run on IG-XL's offline simulator.

Input: A small motion sensor with a 4-wire SPI interface and a 16-requirement spec.
What ran: Taken from the spec to a program IG-XL ran: 10 IG-XL sheets · 16 tests in one VBT module (a flat program) · 12 pattern files.
What it found: Device model 16 / 16 replayed clean · 80 compare cycles, 0 mismatches. "Clean" means consistent with the register map and electrical pack as transcribed. IG-XL offline simulator 25 / 25 datalog rows as predicted · Bin 1 PASS. The simulator run uses IG-XL's offline simulator with simulated instruments on one site, with the device's serial reads supplied by its model; it is not a tester result.

The loaded spec stays in view, every requirement with its test number, and one click generates a program from all of them. Shown on an example project: a six-requirement read-back spec for an open-source I²C core.

From spec to project

Bring-up starts from a complete IG-XL project already keyed to the spec, not from a blank workbook.

Each requirement is written for its test type. Serial and digital tests get a real, deterministic pattern file and the code that runs it, never free-form vectors. Everything that can be derived is written by code; the language model is used where engineering judgement is needed. Where a saved channel plan exists, its picks land in the program's channel map exactly as chosen.

How a program is generatedone run · every step recorded

SpecRequirements with their test numbersfrom a datasheet or spec document, a requirements spreadsheet or a Jama Connect project
GenerateOne focused pass per requirementthe program's structure written by code; the model used only where judgement is needed
CheckThe code, the tester setup, the sheets and the limitsa program that fails pre-flight stops there, with its findings
VerifyTests replayed against a model of the deviceby default a model derived from your register map; what it cannot judge is listed, never passed
Verify · RTLOptionalA model you connect judges insteadsuch as the RTL your design team already simulates, through a small adapter on your side; the model stays with you
PresentA run page with every resultvalidation, per-requirement report, waveforms and logs, and the project to download
RunOptionalRun it on IG-XL's offline simulatorIG-XL loads and runs the finished program, and the datalog is reconciled test by test

Checked before you open it

The model drafts; the checkers decide. Every check result stays with the run, so a clean verdict can be audited and a failing one arrives with its evidence.

Check	What it catches
VBA against the IG-XL API	An instrument member or constant that does not exist, flagged before the code reaches the VB editor — along with documented settle times and prohibitions.
Pre-flight against the tester	Pins, channel types, instrument ranges and time sets checked against the configuration the program will run on. A program that fails stops there, with its findings.
Sheets that agree	Flow, TestInst, Binning, Levels and the time sets read together: names and numbers that do not resolve, unreachable bins, a missing pass or fail bin.
No looser than the spec	The program's limits against the spec's, in the same units. A program looser than the spec gets a named verdict on its run page.

A generation run page: the device model that judged it, the report, validation, waveforms, signals and logs tabs, and the per-requirement table — The run page is the record: which model judged the program, and what each requirement became. Validation, the device-model report, the waveforms, the signals and the logs are one tab away, and the whole project downloads in one click. Example project, assembled offline.

Judged by a model of the device

Before you open the program, its tests are replayed against a model of the device: by default one derived from the register map you already keep, or a simulation model you connect from your own side — the RTL your design team already runs, through a small adapter that answers ATE·IQ's questions. The model never leaves your hands, it has to prove itself before it judges, and any test it cannot judge is listed as not verified, never passed. Details on Device-Model Verification.

The device-model report of a run judged by a connected model: 6 verified clean, 0 with findings, 0 not verified, and the note that the verdict reproduces the connected model, not the silicon — The example project's run judged by a public open-source I²C core connected as the external model: all six tests replay clean. The note underneath is the product's own — a verdict reproduces the connected model, not the silicon.

The Waveforms tab for one I2C read test: START, address 0x3C, ACK, data and STOP phases on SCL and SDA, with the connected model's parse of each frame in the table below — The Waveforms tab for one test: the frames the pattern drives and the connected model's parse of them, cycle by cycle, with the frame table below. ATE·IQ draws this from the replay; the connection carries the model's answers, not waveforms.

Run it on IG-XL's offline simulator

Choose Run on simulator and IG-XL's own offline simulator loads and runs the finished program, so the program is judged by IG-XL rather than by the model that wrote it. The datalog is read back and reconciled test by test against the device model's prediction (agree, disagree or not run) on the run page. It can use the IG-XL installation on the engineer's workstation, or an IG-XL virtual machine.

On the demonstration project

A small motion sensor with a 4-wire SPI interface and a 16-requirement spec, taken from the spec to a program IG-XL ran.

Measured	Result
Requirements	16 — 6 DC, 10 SPI functional
Program	10 IG-XL sheets · 16 tests in one VBT module (a flat program) · 12 pattern files · cross-sheet validation 0 failures, 1 advisory · pre-flight clean
Device model	16 / 16 replayed clean · 80 compare cycles, 0 mismatches
IG-XL offline simulator	25 / 25 datalog rows as predicted · Bin 1 PASS
Traceability	16 / 16 joined spec → program → lot (presence on test number, not correctness) · 1 compliance error — a guard band tightened in the spec after generation, which the program never picked up

Demonstration project: synthetic production data with defects planted on purpose. "Clean" means consistent with the register map and electrical pack as transcribed. The simulator run uses IG-XL's offline simulator with simulated instruments on one site, with the device's serial reads supplied by its model; it is not a tester result. The demonstration program is flat, with all its tests in one VBT module; the generator now groups tests by default, one module per group.

Refine it with the IG-XL agent

Load the generated project in IG-XL and carry on with the IG-XL agent beside it. Ask it to explain a test or change a limit: it stages the change, shows the before and after, and you apply it from the agent window beside Excel or from ATE·IQ Chat. Ask whether the program will compile and it runs the same offline pre-flight on the open program, and tells you what only IG-XL itself can confirm.

Boundaries Offline checks prove structure and consistency, not intent. A clean pre-flight is not IG-XL's verdict, a simulator pass is not tester-correct, and neither is silicon-correct; final authority remains IG-XL on the tester and correlation on real parts, and each result is labelled with the verdict it came from. A verdict is only as good as the model behind it.