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?" That second question is where real test-floor debug time goes — and it is answerable offline, if you have a model of the device to ask.

The capability was proven the honest way: on a TMP126 program whose sheets, VBA and cross-sheet checks were all clean, the model replay found four independent defect classes — three of them live in the replayed run, the fourth demonstrated as a latent trap the same checks would have missed. Each 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. Two were then fixed structurally in the generator — so the same class cannot recur — and the fixes are locked by tests that replay the generator's real output through the model.

ATE·IQ does not invent the device. The model is an input, sitting behind a small, explicit contract: reset to a known state, prove yourself with a self-test, accept a clocked bus transaction and answer as the part would, report what you measure, take a forced condition. Anything that can answer those questions can be the judge.

That contract is the point. The executable model of a device usually already exists — design and verification teams build one long before the test program does — and it encodes the behaviour a test engineer otherwise has to re-derive by hand from a document. Plugging that model into the test side is what turns "the program looks valid" into "the part agrees with what the program does".

Whatever supplies it, the model is driven the same way. It is deliberately time-free: a conversion takes milliseconds, a pattern takes microseconds, so rather than invent timing precision it cannot justify, the replay advances device time only on explicit events — which keeps every verdict reproducible and pushes genuinely time-dependent questions into the honest-decline column where they belong. And before any verdict is issued the model must pass a mandatory self-test against known-good reference values. If that fails, nothing is claimed to be verified — no partial credit, no quiet degradation.

Where the model comes from

The fabricated instance

A model that describes digital behaviour will not answer an analog question. Where that is the case, ATE·IQ can layer a deterministic, seeded "manufactured part" over it: pin behaviour synthesized from the part's documented electrical envelope. Every value carries its provenance — a documented typical, a value synthesized from a documented limit, or an industry-standard assumption where the specification is silent — and that provenance travels into any finding it produces. It unlocks the analog families a register model alone must decline: clamp continuity, input leakage, output levels, power-on-reset and brownout thresholds, and a temperature-accuracy corner check that catches program limits tighter than the part's own guaranteed capability.

The strongest judge is the model your design and verification teams already maintain. ATE·IQ connects it as-is: an adapter wraps your RTL or SystemC behind a small, documented request/response protocol — reset, self-test, bus transaction in, answer out — and the project points at that adapter's endpoint. Nothing about your model is rewritten, and nothing about it leaves your infrastructure.

On the project page you enter the endpoint and an optional secret, and press Probe: the platform opens a session, requires the model to identify itself (a name and a build digest), probes it for determinism, and runs its self-test through the wire — showing you exactly what generation would attach. A model that will not identify itself or answers non-deterministically is refused, with the reason on screen; a model that fails its self-test can never verify anything — the failing check is shown, and no verdict is claimed against it. At generation time an unreachable model becomes a visible warning and the run proceeds on the derived stand-in — never silently.

The path is proven end to end on real third-party RTL: an SPI flash behavioural model and an open-source I²C slave core, both running unmodified under an HDL simulator, both judging generated programs through the same contract — including one catching a deliberately wrong register value in the project's own map, with both values named. Reference adapters ship with the platform, including one built on the standard Python co-simulation framework DV teams already use — designed so the same testbench retargets between simulators by changing a runner name.

You always know who judged

A stand-in derived from your uploads and your actual device model are different authorities, and the platform never lets the two blur. The project page states which one the next generation will attach — and every run, and the generated workbook itself, records the model's identity and digest.

The derived stand-in has a deliberately low entry price: files you already have.

• CMSIS-SVD upload — the machine-readable register description nearly every silicon vendor publishes. Load the .svd on the project's register-map card, pick the peripheral (derived peripherals resolve the way the format defines them), and the register map — addresses, widths, access, reset values, fields — lands ready to drive generation and the generic model. Every import states its one caveat plainly: SVD addresses are peripheral-relative offsets, and whether that matches your part's serial-bus addressing is an engineering judgement the import cannot make for you.
• Guided electrical-pack transcription — a datasheet-shaped editor for the DC table: currents entered in the unit the datasheet states them (nA/µA/mA, converted once, correctly), a citation field per row so every reading can name its source, and live validation that is the same check generation runs — what saves is what generation accepts. The result: supply-current modes, clamp, leakage, output levels and POR thresholds become judgeable, with each reading carrying its provenance tag.

A model-judged program does not depend on the model at run time. The model's answers — predicted read-backs, DC readings for the offline branch — are baked into the generated workbook as a plain VBA table, so the .igxlproj stays self-contained on the tester.

The table's preamble records generated against: model, digest — and that digest is a fence, not a caption. If your model changes and the program is regenerated, a stale baked table is caught loudly before dispatch rather than shipping answers from a model that no longer exists.

The model can also author the pattern's expected values directly: read compares are rewritten from the device's own parse of the transaction. When the model's answer disagrees with what the register map implied, the disagreement is surfaced as a warning naming both values — the pattern ships the model's answer, and the engineer adjudicates which source is wrong. That is precisely the demonstration above: a stale map value planted against real RTL was caught with values, then the model-authored expects converged the program to green.

When the model's adapter supplies the simulator's own session capture — as the reference RTL adapters do — each pattern test also ships a cross-check waveform file: the tester's pattern and the simulator's own signal capture, time-aligned in one standard VCD — two scopes, one time axis, openable in any waveform viewer. A capture the alignment cannot anchor is refused loudly, never guessed into place.

This is a third, independent check on top of the replay verdicts: the replay compares decoded values, the cross-check lets an engineer compare raw waveforms with their own eyes. A defect in the replay's decoding would be visible here as a waveform disagreement — which is the point of having it.

Verification runs on the real artefacts. The exact vector array the .atp pattern was emitted from is clocked, bit by bit, into the model — which parses the frame the way silicon would, with no help from the pattern's own annotations.

Each frame produces one of three families of finding, and every finding carries expected-versus-actual with units and a location:

• Frame structure — the device cannot parse what the pattern clocks: a command word that never completes, host-released bits where data must latch.
• Intent cross-check — the pattern says "write the high-limit register", but the first clocked bits parse as a different operation on a different address. This is the check that caught the missing command word.
• Expected values — every compare cycle is checked, bit-accurately, against what the device would actually drive, honouring masks and read-only or self-clearing bits.

State persists across frames within a test, so a write in one frame changes what a later frame reads back. Before each test the model is put in a production-realistic condition — the forced ambient the requirement states, and a device that has been powered and converting — rather than an unrealistically fresh-from-reset part.

Every test is scoped against the model's judging surface before a verdict is issued. A test the model cannot honestly judge is declined — loudly, with a reason — and a declined check is never counted as a pass.

The decline list is calibrated, not defensive. Windowed supply-current measurements were declined for exactly as long as their sample instant was unknowable — and became verifiable again the moment the pattern itself could pin it (§10).

The device model does not replace the existing checks, and it cannot be satisfied instead of them. A generation result is clean only when every judge agrees:

That structure is the defence against over-fitting to a single judge: a generator cannot satisfy the loop by gaming one checker. Model findings feed the existing repair loop rather than starting a second one — inside the same two-round budget — and findings against deterministically emitted artefacts are surfaced rather than re-prompted, because a defect in an emitter is fixed in code, not talked away by a language model.

Every pattern-carrying test in a run produces a full DV-style waveform, drawn from the same replay that judges it: the stimulus the tester will drive, the device's modelled response overlaid on it, the part's internal state, and a frame table of what the pattern intended beside what the device parsed.

The internal lanes are the part of this that no logic analyser gives you: the protocol state machine, the address pointer, each watched register's value changing at the exact cycle it latches, and the supply-current probe stepping between the device's documented operating states.

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 rather than leaving it to post-burst timing, and for the tests that need it ATE·IQ generates the pieces that make that work end to end, then verifies them.

Verification is the part that matters here. Because the replay knows the device's state at every cycle, it knows what state the part was in at the exact vector where the measurement was taken, and judges each sample against the test's limits accordingly — which is what turns "current measured somewhere in this burst" into a checkable claim.

A hand-built behavioural model is the deepest form of this, but it is not the entry price. Where a project carries a register map — addresses, widths, reset values, fields — ATE·IQ stands up a generic register model from it automatically: wrong-register detection, reset-value and read-back compares with reserved and self-clearing bits masked, and reads of live registers treated as capture-only rather than compared against a constant. Declare the device's bus framing as a project bus profile and that model parses the wire exactly the way the generator writes it; without one, both fall back to a generic address-and-data frame — and generation says so instead of implying the framing is confirmed.

The metadata that drives it is yours and editable in the app — which registers hold run-time state, which control bits self-clear, which bits a register walk must not toggle. 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 TMP126 program is generated, replayed and judged on every run. The current run verifies clean with no semantic errors outstanding:

All 22 pattern-carrying tests replay with zero mismatched compare cycles. Getting there was the point of the exercise: the first two defects in §01 were not patched in the generated output — they were fixed in the generator, so the emitter and the model now take the device's framing from one shared source and cannot drift apart. That class of defect is now caught at the source, and the demo program generates semantically correct without spending repair rounds on device semantics.