DCRouter's APB register interface was verified with an APB task written by the same course that wrote DCRouter. Both read the APB rules the same way. If the writer had misread one rule, say whether pslverr may be sampled outside the access phase, the RTL and the testbench would share the misreading, and every test would pass. A model of the standard written by someone else, against the standard itself, does not share your mistakes.
What is verification IP for, and when is it worth having?
The obvious approach is to write your own interface model: you know the protocol, and it is only a few hundred lines. For a simple internal interface, that is fine. For a standard interface (a bus protocol, PCIe, USB, a memory interface), your model encodes your reading of a long specification, the same reading your designers had, and your design must interoperate with other people's implementations that read it differently. Independence is the point.
VIP provides | VIP does not provide |
|---|---|
Drivers that can produce every legal (and chosen illegal) behaviour of the protocol | A check of your design's function behind the interface |
Protocol checkers: every rule of the standard as assertions | Your scoreboard and reference model |
Coverage of the protocol's features | Coverage of your design's features |
Monitors producing transactions for your scoreboard | Knowledge of your system's configuration and use |
Compliance test suites, for some standards | Proof of interoperability with every real partner |
Situation | Choice | Why |
|---|---|---|
Complex industry standard (PCIe, USB, Ethernet, DDR) | Buy (or use a mature internal VIP) | Thousands of pages of rules; compliance matters; independence is essential |
Simple standard bus (APB, simple AXI uses) | Reuse a proven internal VIP, or buy | Small, but shared misreadings are still costly |
Internal, project-specific interface (DCRouter's packets) | Build | No standard exists; write it from the interface specification (lesson 2.2), ideally by someone other than the designer |
Configure it to your use: optional features on or off as your design implements them.
Turn on every protocol check: VIP checkers often catch more than VIP drivers.
Merge its coverage with yours: protocol coverage plus design coverage.
Keep the design's own checks: VIP checks the interface; your scoreboard checks the function.
Practice | Purpose |
|---|---|
Commercial or internal VIP for every standard interface | Independent protocol models across projects |
VIP checkers active at block, subsystem and chip level | Protocol violations caught wherever they occur |
Compliance suites before tape-out for interoperability standards | Evidence beyond your own tests |
A team (illustrative) built its own model of a high-speed serial standard and passed thousands of tests. The model and the design shared an interpretation of an optional ordering rule, which a partner's chip read differently. Interoperability failed at the first plug-in test. A third-party VIP, or a compliance suite, had the other reading built in.
It is an internal interface with no standard; the model is written from DCRouter's own interface specification, ideally by someone other than its designer.
No: VIP checks the interface rules; whether the right data comes out depends on the design's own scoreboard and reference model.
VIP is an independent model of a standard interface: drivers, checkers, coverage, monitors.
Independence matters: your own model shares your designers' reading of the standard.
Buy or reuse VIP for standards, build for internal interfaces, and keep your own functional checks.