Our release standard
Evidence will ship with the product.
Our first kit is in development. There are no released product reports or customer performance claims on this page. This is the standard we are building toward.
A known starting point
Product and DUT source revisions, configuration hashes, dependency versions and the exact environment used for the run.
A named check
What was exercised, what was expected, what was observed, and whether the result passed, failed, was skipped or did not apply.
A replayable failure
The seed, transaction context, sampled cycle, trace and waveform needed to reproduce a finding.
Visible boundaries
The supported scope, coverage definitions, exclusions, known issues and any reviewed waivers.
Different findings need different explanations.
| Category | What it tells you |
|---|---|
| Protocol requirement | A sampled behavior conflicts with a specific interface rule, such as a response payload changing during a stall. |
| Register contract | The design differs from its declared behavior, such as a writable field or reset value. |
| Project expectation | A configured budget or assumption was exceeded. A response watchdog is an example; the chosen deadline is not an AXI protocol rule. |
| Testbench health | The stimulus, adapter or runner needs attention before the DUT result can be trusted. |
Byte-strobe behavior illustrates why this matters. A non-memory peripheral can have a valid policy that differs from a byte-mask register model. The check must use the declared policy rather than flag every difference as a protocol error.
The tests need a test, too.
We plan to pair correct reference designs with small, intentional faults: a response that drops VALID early, data that changes while stalled, or a write applied to the wrong register. Each fault must trigger the expected finding. An unrelated crash or timeout does not count.
Then the kit needs to work on independent designs. We will record setup effort and support interventions alongside the technical result. A demo passing on its own is only the beginning.
Read the denominator.
“All tests passed” describes a particular test set. Coverage needs a definition: which scenarios were counted, how many were exercised, and which were excluded. Neither statement establishes exhaustive correctness or certification.
As real samples and releases become available, their reports will identify the tested version and scope. Until then, a proposed report format is a design preview, not a measured result.
Technical reference: AMD AXI protocol-check descriptions. Our implemented check list will be reviewed against the applicable Arm specification.
What would make a report useful to your team?
Help us shape the first kit around an actual integration decision.
Join the pilot