Device-Model Verification

Structural checks answer "is this a valid IG-XL program?" They cannot answer "does this program do what the spec asked, to this device?" — the question where real test-floor debug time goes.

The capability was proven the honest way: on a demonstration program for a small SPI temperature sensor — sheets, VBA and cross-sheet checks all clean — the model replay found four independent defect classes, each of which would have surfaced as a confusing failure at the tester.

None of those are visible to a compiler, a schema validator or a lint pass. They are meaning errors — and two were fixed structurally in the generator, so the same class cannot recur.

ATE·IQ does not invent the device. The model is an input, behind a small, explicit contract: anything that can answer as the part would can be the judge — and that model usually already exists, built by design and verification long before the test program.

Every verdict is reproducible, and none is issued unless the model first proves itself — what it cannot honestly judge is declined out loud, with no partial credit and no quiet degradation.

The device reads the wire

Verification runs on the real artefacts: the emitted .atp pattern is read bit by bit and parsed the way silicon would, with no help from its own annotations. Findings carry expected-versus-actual with units and a location, and each test starts from a production-realistic condition, not a fresh-from-reset part.

Where the model comes from

The fabricated instance

Digital behaviour will not answer an analog question, so ATE·IQ can layer a documented-envelope electrical stand-in over the model — every value carries its provenance into any finding. It unlocks the analog families a register model must decline — continuity, leakage and the like.

The strongest judge is the model your design and verification teams already maintain, connected as-is — your own RTL or SystemC, nothing rewritten, nothing leaving your infrastructure. Proven end to end on real third-party RTL: an SPI flash behavioural model and an open-source I²C slave core, unmodified under an HDL simulator, judging generated programs — one catching a deliberately wrong register value in the project's own map, both values named.

A model that cannot prove itself is refused, with the reason on screen; an unreachable one becomes a visible warning, never a silent substitution.

You always know who judged

A derived stand-in and your actual device model are different authorities, and the platform never lets them blur: every surface states who judged, and the generated program remembers its judge — a stale judge is caught loudly before dispatch.

The derived stand-in starts from files you already have. A CMSIS-SVD upload lands the register map ready to drive generation and the generic model — with its one caveat stated plainly: whether SVD's addressing matches your part's serial-bus addressing is a judgement the import cannot make for you. DC facts come from a guided datasheet-transcription editor with live validation — the DC facts become judgeable, each reading carrying its citation.

The judge itself is cross-checked against an independent simulator, waveform for waveform: where the connected setup can supply the simulator's own capture, each pattern test ships a cross-check waveform file — the tester's pattern and the simulator's capture, time-aligned in one standard VCD, openable in any waveform viewer — so an engineer can compare raw waveforms with their own eyes, independent of the replay's verdicts.

Every test ends in one of three explicit outcomes — verified, a located finding, or an honest decline, per test family, with the reason — and a declined check is never counted as a pass. The decline list is calibrated, not defensive: windowed supply-current measurements were declined exactly as long as they were unjudgeable, and became verifiable the moment they were not (§07).

Some families stay declined on principle: timing measurements — the replay is deliberately time-free; repeatability, drift and supply-rejection grades — real silicon statistics that no model stands in for; and checksum-protected frames, which it will refuse rather than guess.

The device model also cannot be satisfied instead of the existing checks: a result is clean only when every judge agrees, and a failed model self-test is never clean, because nothing was verified.

Every pattern-carrying test produces a full DV-style waveform, drawn from the same replay that judged it — the waveform you inspect cannot drift from the verdict: the stimulus the tester will drive, the device's modelled response, the part's internal state, and a frame table of what the pattern intended beside what the device parsed.

Measurements the pattern takes itself

Some measurements only mean something at a precise instant inside a running pattern — a supply current during a conversion, not before or after it. On UltraFLEX the pattern can pin that instant itself; ATE·IQ generates what that takes and verifies it, judging each sample against the test's limits in the state the part was actually in — with that state named in any failure.

A hand-built behavioural model is the deepest form of this, but not the entry price: any project with a register map — addresses, widths, reset values, fields — gets a generic register model stood up automatically, deep enough to judge register semantics and honest about everything a map does not describe. The metadata is yours and editable in the app — and when a program's semantics depend on something the map does not yet state, generation names the row to fix instead of guessing.

The 34-test demonstration program is generated, replayed and judged on every run, and the current run verifies clean: 27 tests verified, 6 declined with reasons, one carrying a warning, zero semantic errors — with all 22 pattern-carrying tests replaying at zero mismatched compare cycles. The first two defects in §01 were fixed in the generator, not patched in the output, so that class cannot recur.