Verification IP is not safety-rated. These are testbench components — no ASIL target, no FMEDA, no IP-XACT, no safety-mechanism interface. They exist to help you verify a design, not to carry a safety argument. The safety soft-IP catalog is over here.
A testbench built from the same assumptions as the design cannot find the assumptions that are wrong. Three cases from this catalog, each a class of defect a self-check is structurally incapable of reaching:
PCIe Gen 3 — nine defects, against a third-party commercial controller. Among them a Gen3 scrambler built as a Fibonacci LFSR where the specification requires the Galois form. Both realise the same polynomial, so it descrambles perfectly against itself and not at all against a real partner — invisible to any amount of self-testing, fatal on the first real link. Also a speed-change request advertised on the wrong Data Rate Identifier bit, a Polling exit with no minimum-transmit condition, and no Recovery re-entry at all.
MACsec — a latent register bug on an untested path. Writing the VIP’s own from-scratch output checks surfaced a release-path register in macsec_node that can start from a stale index. The block’s own testbenches never exercise that configuration, so nothing in its own suite could ever have hit it. Disclosed rather than quietly patched.
CAN FD — a bit-stuffing gap. Found by the CAN checker against our own can_fd, which had passed its native testbench cleanly for months. Fixed, then formally closed.
A testbench written by the team that wrote the design inherits that team’s reading of the specification. Where the reading is wrong, the design and the testbench are wrong in the same direction, and they agree with each other perfectly. The run passes. The bug ships. This is the single most common way a well-verified block still fails at interop.
A clean-room VIP breaks that symmetry. Every model here is written from the published standard by someone working from the standard alone, never from our RTL, so when the design misreads the spec the VIP disagrees — loudly, at the cycle where it happens.
The sharpest demonstration is not against our own RTL at all. The PCIe Gen 3 VIP was driven against a third-party commercial PCIe controller over a PIPE interface, and trained it to L0, through the 8 GT/s speed change and Link Equalization, and on to sustained Gen3. Reaching that found nine defects in our own models that the BFM pair’s self-check structurally could not — because two copies of the same assumption agree no matter how hard you test them against each other. Only a foreign implementation refuses. That is the difference between a suite that passes and a link that comes up.
The same independence makes a VIP useful well beyond this catalog. Nothing in a model here is coupled to our safety IP — if your design speaks the protocol, the VIP will hold it to the standard just as readily.
Verification IP is testbench collateral, and the boundary matters enough to state twice. A VIP carries no ASIL target, no FMEDA, no IP-XACT descriptor and no safety-mechanism interface. It cannot contribute to a safety argument, and a passing VIP run is not evidence toward an ASIL claim. It is evidence that a design conforms to a protocol — which is a different, narrower, genuinely useful thing.
That boundary is also why this catalog sits at the top level of the site rather than nested beneath the safety IP: nesting would imply a safety rating that these components deliberately do not carry. Where you need a block that does carry one, the safety soft-IP catalog is the place to look, and many of its blocks pair with a VIP here.
Entries marked shipping are built and tested collateral you can exercise on day one. Entries marked planned are scoped against the protocol’s public standard but not yet written — listed openly so you can see the roadmap and tell us where to reorder it. Customer demand is what moves a protocol up the wave.
Scoping is done for every entry in this catalog. Tell us the protocol and your timeline — customer demand reorders the wave.
Verification IP is testbench collateral and is deliberately not safety-rated: no ASIL target, no FMEDA, and no IP-XACT descriptor. Entries marked “planned” are specified against the protocol’s public standard but not yet built. Deliverables and licensing terms are shared under a mutual NDA.
circuit-design.space · +1-971-357-1400 · anovickis@circuit-design.space