What Is Verification IP?

A Verification IP (VIP) is a reusable model of one side of a protocol, used to exercise and check a design that implements the other side. If you are building an AXI slave, the VIP is the master that talks to it: it drives legal traffic, watches what comes back, and says so when the design breaks the specification.

It is verification collateral, not silicon. A VIP is never synthesised into your chip — it exists only inside the simulation.

What a VIP does

• Drives stimulus — generates legal protocol traffic, including the awkward corners a hand-written test tends to skip.
• Checks the protocol — asserts the rules of the specification continuously, so a violation is reported where it happens rather than as a mysterious failure later.
• Monitors passively — observes the bus without driving it, so it can be attached to a link that two other components are already using.
• Models the far end — for memory and link protocols, answers as a real device would, so the design under test sees realistic responses and backpressure.

VIP or BFM?

The terms get used interchangeably and they are not the same thing.

A BFM (Bus Functional Model) drives and samples signals: it turns a call like WRITE_BURST(addr, len) into legal wiggles on the bus. That is the stimulus half.

A VIP is the BFM plus the judgement: the protocol checker that knows the rules, the monitor that watches without interfering, and the far-end model that responds. A BFM can drive an illegal transaction quite happily. A VIP tells you that it did.

What is in ours

141 protocol VIPs across 16 groups, of which 70 ship with real, tested collateral today and the rest are scoped. The shipping set is 218 SystemVerilog files covering 59 protocols:

The UVM agents are APB5 / APB4 / APB3 / APB2, OBI (Open Bus Interface), TileLink (TL-UL). Everything else is a task-based SystemVerilog BFM, callable from a plain Verilog testbench with no methodology library required — which is deliberate: most of the designs these are used against are small enough that a UVM environment costs more than it returns.

What is NOT in them

Two limits, stated here rather than discovered after you download something.

No functional coverage models. The VIP deliverable contains 0 covergroups. Coverage closure is your verification plan’s job, not something these ship an opinion about. (This repository does contain 76 files with covergroups across 48 UVM environments — but those verify our own safety IP and are not part of any VIP product.)

Not safety-rated. No ASIL, no FMEDA, no IP-XACT, no safety manual. That distinction matters and it is not hedging: the safety soft-IP in this catalog carries measured diagnostic coverage and a gated ISO 26262 verdict. The VIPs are verification tools used while integrating it. Only one of those two things is a safety claim.

Clean-room, and why that matters

These are written from the public protocol specifications, not derived from this catalog’s own RTL. That is the point of using one: a VIP built out of the design it is meant to check inherits the design’s misreadings of the spec, agrees with them, and passes. An independent second source disagrees instead.

Choosing one

• Check the revision, not the protocol name. “CAN” and “CAN FD” are different problems; so are PCIe Gen3 and Gen6.
• Decide whether you need a checker or just traffic. If you only need to bring a link up, a BFM is enough and is faster to wire in.
• Match the methodology you already have. Dropping a UVM agent into a directed Verilog testbench means adopting UVM; a task-based BFM does not.
• Ask what it is built from. A VIP derived from an implementation is not an independent check of that implementation.

Browse all 141 verification IPs →