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. Every VIP here is written clean-room from the public standard, so it disagrees with the design when the design is wrong. Run against our own can_fd, the CAN checker surfaced a real bit-stuffing gap — since fixed and 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. Run against our own CAN FD controller, the checker surfaced a genuine bit-stuffing gap that the block’s own testbench had passed cleanly for months. It was fixed and then formally closed. That is the entire argument for independence, and it is why these VIPs exist as a separate product line rather than as an internal test asset.
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