Device-model verification
A program that compiles can still be wrong. It can read a register before the part is ready to answer, compare against a value the part never returns at that point in the flow, or measure supply current in a mode the flow never set. ATE·IQ™ checks the generated program and its patterns against a model of the device before any tester time is spent. The model is built from the register map you already keep, or it is one you connect from your own side, and every result names the model that judged it.
- Input
- A small motion sensor with a 4-wire SPI interface.
- What ran
- Checks the generated program and its patterns against a model of the device before any tester time is spent.
- What it found
- A model derived from the demonstration device's register map and electrical pack passed its self-test, then replayed all 16 tests clean — 80 compare cycles across the 12 pattern-carrying tests with 0 mismatches. "Clean" means consistent with the register map and electrical pack as transcribed.
Compiles is not correct
IG-XL tells you whether a program is valid. It cannot tell you whether the program reads the right register, in the right state, and compares against a value the part can actually return. That question is where test-floor debug time goes, and it is the one a device model answers.
| What a structural check sees | What a device model asks |
|---|---|
| Valid SPI patterns, correct sheet references | Does the command the pattern shifts in form the operation the requirement asked for, on the register it named? |
| A well-formed supply-current test with correct limits | Was the part in the power mode the measurement assumes when the meter read? |
| Read compares populated from the register map | Can the part return that value at that point in the flow, or does the compare pass by luck? |
| A limit row that validates | Does the value the model predicts land inside that limit, so a wrong limit fails in front of you rather than on the tester? |
Three plain outcomes
The model reads what the tester will actually send: each emitted pattern is decoded the way the part would parse it. Every test then ends in one of three outcomes — verified, it does what was asked and the model agrees with every compare; a finding, with the expected and actual values and where in the program the disagreement sits; or declined, with a reason. A declined check never counts as a pass, and a measurement taken with the device in the wrong state is a finding before its limits are compared.
The model proves itself before it judges: it runs a self-test first, and a failed self-test is never reported as clean. Every result names the model that judged it, and that record stays with the run.
Choose the judge
The model is an input, and ATE·IQ does not invent it. A model you connect outranks every other source. Otherwise a model derived from your register map judges register behaviour, reset values, write-then-read-back and the frames on the wire; a transcribed electrical pack adds steady-state DC checks such as continuity, leakage and supply current in a declared power mode.
| Start from | How |
|---|---|
| Register map | Import a CMSIS-SVD file, or paste a register table from a spreadsheet and confirm the columns ATE·IQ detects. Edit it on the project, next to the bus profile the patterns use. |
| Electrical pack | Enter the datasheet's DC figures in a guided editor that validates as you type. Each reading keeps its source, and that source appears in any finding that uses it. |
| Your own model | An adapter you run beside your simulation model answers ATE·IQ's questions over the endpoint you register. The model itself is never handed over. |
If a test depends on something the map does not describe (an unmapped address, a read longer than any register), the model declines that compare and names what is missing. It does not guess.
Connect your own model
Connecting the model your design or verification team already runs is a job you can check yourself: a kit with adapter skeletons, a specification of every question ATE·IQ asks, and a conformance script that tells you in your own terminal whether your adapter will be accepted. When ATE·IQ opens a model, the model has to prove itself: its identity, a reset that brings back its starting state, identical answers to identical questions. A model that fails is refused with the reason on screen. A transcript of every exchange is kept with the run, in your own project.
On the demonstration project
A model derived from the demonstration device's register map and electrical pack passed its self-test, then replayed all 16 tests clean — 80 compare cycles across the 12 pattern-carrying tests with 0 mismatches. On IG-XL's offline simulator the same program produced 25 / 25 datalog rows as predicted and binned Bin 1 PASS.
Demonstration project: a small motion sensor with a 4-wire SPI interface. "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.