For IG-XL test engineering teams

From spec to a checked IG-XL program.

Pick a spec and ATE·IQ writes the IG-XL program — 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 and lists any it cannot judge, repairs what the checks find, and hands you a project ready for IG-XL's offline simulator. Then the integrated IG-XL agent refines it with you, live in the workbook.

Request a walkthrough See generation →

Test numbers, names, sheets and patterns are written by code; the language model drafts the DC measurement code.
Judged by checkers, a device model and, when you choose, IG-XL's own offline simulator — rather than by the language model that wrote it.
ATE·IQ runs on your machine, and project data goes only where you point it: your LLM provider and any repository, Jama server or model endpoint you connect.

Pick a spec and generate: every requirement stays in view with its test number. Shown on an example project: a six-requirement read-back spec for an open-source I²C core.

Test program generation

Generate → check → verify → run.

One focused pass per requirement: serial and digital tests get a real, deterministic pattern file and the code that runs it, and DC tests get measurement code grounded in built-in IG-XL and UltraFLEX platform knowledge. Then the checkers decide, and the tests are replayed against a model of the device before you open the program.

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 requirementtest numbers, names, sheets and patterns written by code; the model drafts the DC measurement code
CheckVBT API, tester pre-flight, sheet structure, limits against the speca 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 that answers over ATE·IQ's own protocol; the model stays with you
RepairFindings go back to the model as targeted fixestwo rounds at most; what still fails arrives with its findings
RunOptionalRun it on IG-XL's offline simulatorIG-XL loads and runs the finished program; the datalog is reconciled test by test against the model's prediction

The device-model report of a run judged by a connected external model: 6 verified clean, 0 with findings, 0 not verified by model; determinism probes and four anchored register reads, each expected value matching; all six tests replayed clean; and the product's note that verdicts reproduce the attached model's behaviour, not its correctness against the device — The device-model report from the example project's run, with a public open-source I²C core connected as the external model: its determinism probes and self-test reads pass, then all six tests replay clean. The note underneath is the product's own: it calls any connected model a customer model (here, the public I²C core) and says the verdict reproduces that model, not the silicon. This example was assembled offline and not compiled; the simulator result below, 25 of 25 datalog rows as predicted, comes from the separate demonstration project, judged against its derived model.

The integrated IG-XL agent

Then refine it with the integrated IG-XL agent.

Load the generated project in IG-XL and carry on with the agent beside it. Open it from the ATE·IQ tab in Excel and it follows every sheet and the cell you are on, streamed every few seconds while connected, and re-reads the VBA editor's current state, unsaved edits included, as you work. Ask it to explain a test or change a limit: it answers with tools that compute rather than recall, stages the change with its before and after, and waits for your Apply.

Follows the program you have open, in Excel or loaded in IG-XL.
Every edit is previewed, applied on your click, and reversible.
VBA it drafts is checked against the IG-XL API before it is offered to you.

The ATE·IQ agent window beside Excel on Example_Program.xlsm: asked to tighten the upper limit of Iq_3V3_Active to 60 µA, it stages a one-cell change on the Flow sheet's Use-Limit row, 7.5E-05 to 6E-05 at Flow!L14, with Dismiss and Apply buttons — The agent's window beside Excel. Asked to tighten a limit, it stages the one-cell change on the Use-Limit row IG-XL reads, notes how close the example's placeholder value sits to the new limit, and waits for your Apply. Captured on an invented example program, not the one generated above; its remark about real silicon is the model's own reasoning from that placeholder value, not a measurement.

ATE·IQ Live Workbook following Example_Program.xlsm open in Excel: the Flow sheet and the tfIq_3V3_Active procedure ticked in the program tree, the procedure's VBA in the viewer, and the agent's answer giving the Use-Limit row the test is judged against, test 400, 0 to 6E-05 A — Live Workbook in the desktop app, following the same invented program. Two items ticked and one question asked: the agent explains the procedure from the VBA editor and reads its limit off the live Flow sheet, including the 60 µA limit once it is applied from the Excel pane above. The table in the answer is the model's rendering of that row.

The model drafts; the checkers decide.Pre-flight, the device model and IG-XL's own simulator judge the program; every join between spec, program, board and production is a deterministic engine the agent calls and explains.

IG-XL offline simulator

25 / 25 · Bin 1

datalog rows as predicted, from a generated 16-test program run by IG-XL itself¹

spec vs program

1 of 16 flagged

a spec limit tightened after generation, which the program never picked up¹

VBA review

33 rules

findings at the exact line, in Excel and on synced programs

¹ Demonstration project for a small motion sensor with a 4-wire SPI interface: synthetic data with defects planted on purpose, the tightened spec limit among them. The simulator run is a proof build — one site, simulated instruments, reads filled from the device model — so it is not a tester result.

Load boards

Read the board your EDA tool wrote. Check it against the program.

Allegro netlist and Fabmaster exports import natively, with no Cadence licence; IPC-2581, ODB++, Specctra DSN, KiCad and PDF schematics too. Every pin in the program's pin map is checked against the board's nets, the copper is measured, the 166-rule DIB check runs, and a DC operating-point check reports rail voltages at the DUT before the board is ever powered. Layout stays in your EDA tool; ATE·IQ never draws copper.

A real Allegro board, read from its Fabmaster export, in the layout tab at 3x zoom — A real Allegro 17 board, read from its public Fabmaster export, checked against a demonstration pin map that carries one planted miss.

Production data

The ground truth, parsed where it lands.

STDF V4 lots parse natively on the engineer's machine — yield by site and bin, Cpk, drift, wafer maps and outlier screens. The traceability dashboard joins every lot back onto the program and the spec and names the limit one of them no longer shares, and lot statistics become limit proposals that are never written for you.

Wafer map of a demonstration wafer: fails concentrated around the rim, and a lower-right cluster marked by the detector — Wafer 1 of the demonstration wafer-sort lot (synthetic data). Fails around the rim are the planted edge signature; the dashed box is a cluster the detector marks, and it also marks clusters on wafers where none was planted.

What you can ask the agent

The questions an IG-XL engineer brings to a program every day — answered from the program in front of you and the data behind it.

Debug mode

“Will this program compile?”

It runs ATE·IQ's offline pre-flight checks on the open program and lists what it checked, and what only IG-XL itself can confirm.

Edit mode

“What does this VBT procedure do?”

It reads the module's current source from the open editor, unsaved edits included, and looks up IG-XL API and instrument facts in its built-in knowledge before it proposes a VBA change.

Edit mode

“Write a helper module for this test.”

It drafts the VBA, checks it against the IG-XL API before proposing it, and stages the whole module for your review.

Debug mode

“Did the spec's new limits reach the program and the lots?”

It sets the spec, the program's flow limit and the limit each lot ran side by side, from the same reconcile the traceability dashboard uses, and names who owns each mismatch.

Debug mode

“Why is this lot failing?”

It reads the STDF — yield by site and bin, first-fail paretos, per-test Cpk and outliers — with deterministic tools, and builds a cause chain for the test you name.

Quality tab

“Review this VBA.”

Thirty-three rules review the modules, with findings at the exact line and a development or production profile to match the stage you are at.

The agent window opens in Edit mode, with the IG-XL knowledge tools and the workbook editor. Switch to Debug and it has all 35 tools and the project behind it. Live VBA, unsaved edits included, needs Excel's VBA project access, which the add-in installer turns on for your user; the Excel add-in installs per user with no admin rights. The agent's tools, and so its staged edits, need an Anthropic model today; with another provider the chat answers without them.

Shown on the demonstration project

The figures in this section, the simulator and spec-versus-program readouts marked ¹ and the wafer map above come from one demonstration project: a small motion sensor with a 4-wire SPI interface, taken from a structured spec to a generated program IG-XL ran, and on to nine STDF files of synthetic production data with defects planted on purpose — so every finding can be checked against what was put there. The generator and connected-model captures at the top of the page come from a separate example project for an open-source I²C core, and the agent captures from an invented example program; each caption says which.

Demonstration project · a small motion sensor with a 4-wire SPI interfacesynthetic lots · planted defects

Spec16 requirements6 DC parametric · 10 SPI functional, each with limits and a test number
Program10 IG-XL sheets · 16 tests · 12 pattern filesgenerated from the spec · cross-sheet validation 0 failures, 1 advisory · pre-flight clean
Device model16 / 16 replayed clean · 80 compare cycles, 0 mismatchesa stand-in derived from the register map and a transcribed electrical pack
IG-XL simulator25 / 25 datalog rows as predicted · Bin 1offline simulator, proof build: one site, simulated instruments, model-filled reads
Traceability16 / 16 joined spec → program → lot · 1 compliance errorthe planted guard band, added to the spec after generation, that the program never followed · presence on test number, not correctness
ProductionSite 3 at 79.2 % against 93–96 % on the other sitesthe first of three final-test lots, where a socket leak was planted

Yield by site in a demonstration final-test lot: sites 1, 2 and 4 between 93 and 96 per cent, site 3 at 79.2 per cent in red — Yield by site in the first final-test lot, as ATE·IQ draws it. The site-3 drop is the planted socket leak.

Everything in the box

Generate the program and refine it with the agent; read the load board it runs on and the lots it tests. The agent reaches all four.

Test programs

Spec to IG-XL project

Sheets, VBT and patterns keyed to the spec's test numbers, checked against the VBT API and the tester setup, with the model's draft repaired before you see it.

Test programs

Judged by a device model

A model derived from your register map, or one you connect over ATE·IQ's own protocol, with a kit to check the connection. What it cannot judge is listed, never passed.

Test programs

Run on IG-XL's offline simulator

IG-XL's own simulator loads and runs the finished program, and the datalog is reconciled test by test against the model's prediction.

IG-XL agent

Live program context

Sheets, VBA with unsaved edits and your cursor, streamed while you work.

IG-XL agent

Edits you approve

Fields, cell blocks and whole VBA modules — previewed, applied on your click, reversible.

IG-XL agent

IG-XL knowledge in your own assistant

The IG-XL knowledge tools also run as an MCP server for the AI assistant your team already uses.

Load boards

The formats your EDA tool exports

Allegro netlist and Fabmaster, IPC-2581, ODB++, Specctra DSN, KiCad and PDF schematics, read natively.

Load boards

Checks before first power

Pin match, the 166-rule DIB check, copper DRC and a DC operating-point solve of the board's rails.

Load boards

Board exports

Gerber and Excellon, a fab package, BOM, pick-and-place, KiCad and Specctra DSN, generated from the imported design.

Production data

STDF on your machine

Yield, bins, Cpk, paretos, outlier screens and wafer maps from the binaries themselves.

Production data

Spec, program and lots, checked for agreement

Limit drift between the three is named, with the artefact that owns each number.

Platform

Local-first, your LLM

Runs on the engineer's machine with Anthropic, an OpenAI-compatible gateway or Azure OpenAI, on your keys.

How it fits your flow

A production test program is never one file: the limits live in a spec, the program in an IG-XL workbook, the board in your EDA tool and the proof in STDF files. ATE·IQ generates the program from the spec, keeps all four in one workspace, joins them mechanically, and puts the agent where the engineer already works.

Fig. 1 — The loop. The program is generated from the spec and refined with the agent, where edits happen; each hop is reconciled by a deterministic engine, and the agent can reach every pillar's tools.

Boundaries

Offline is labelled offline: IG-XL remains the compile authority. A clean pre-flight is not IG-XL's verdict, and a simulator run — simulated instruments, one site, reads filled from the device model — is not a tester result, nor silicon. A simulator run needs IG-XL on the workstation or an IG-XL virtual machine.
A verdict is only as good as its model: a derived model agrees with the register map and electrical pack as transcribed, and a connected model's verdicts reproduce that model, so a wrong model gives wrong verdicts with full confidence. IG-XL never runs a connected model; the protocol is ATE·IQ's own and has been exercised on public third-party simulation models (a generic SPI-flash model and an open-source I²C core), with no customer model connected yet.
Repair is bounded: it can fix only what a check can see, it revises the model's draft for at most two rounds, and anything still failing is shown with its findings.
Proposals stay proposals: limit proposals never write a limit, and workbook edits wait for your Apply.
Missing data says so: a surface without its inputs reads awaiting data, not "clean".
The prose is the model's: the tools compute their figures deterministically, but the answer around them, tables included, is written by the language model you configured, so check a figure that matters against the tool. The MCP server runs from a source checkout today, not from an installed build.
It does not draw copper: ATE·IQ reads, views and verifies the load board; layout stays with the EDA tool that drew it.

Talk to us

The useful first conversation is a walkthrough on your device and your tester: a spec you already ship, turned into a checked IG-XL program and refined with the integrated agent — or the agent working in a workbook you already maintain. Tell us what you are working on and we will reply within one business day.

Request a walkthrough sales@ateiq.io