A quote for an AXI4 VIP arrives in your inbox: a licence per simulator seat, renewed yearly. In the meeting, a confident engineer says the team could write one in a month; the AXI-Stream agent on the DMA took a week. The manager turns to you: buy or build? Then, after you answer, the harder one: and whichever we pick, how do we know it works?
Buy-versus-build is usually argued as licence cost against salary, and that framing misses most of the cost. What you are paying for is trust: a verification component you can believe when it reports nothing wrong. A home-built agent is cheap to start and expensive to trust, because every protocol rule it checks, every corner it generates and every coverage point it collects has to be written and then proved. A bought VIP is expensive to start and also needs trust, but much of the proof (compliance suites, other customers' bug reports) comes with it.
Buying a used car is a good picture. Building your own car is possible and teaches a lot, but nobody does it to get to work. Buying one is faster, and you still get it inspected before you pay, because a car that looks fine can hide a cracked chassis. VIP qualification is the inspection, and it is needed whether you bought the VIP or built it.
Factor | Favours buying | Favours building |
|---|---|---|
Protocol complexity | AXI4 with outstanding transactions, IDs, reordering, exclusive access; PCIe, USB, DDR, Ethernet | APB, AXI-Stream, a simple interrupt, an in-house bus |
Compliance evidence | The vendor ships a compliance suite and a protocol checker mapped to the spec's rules | No standard exists, so nobody can sell you compliance |
Schedule | Needed in weeks, and the protocol is the means, not the product | Time to build and prove it, or it is the product you are verifying |
Reuse | Many projects, many protocols: a vendor portfolio pays back | One bespoke protocol used across your own projects: build it once, package it as VIP |
Licence and seats | Few concurrent runs | Thousands of nightly runs on many seats can make licences the larger cost |
Control and visibility | You can live with encrypted source and vendor support | You must debug, extend or port it freely (another simulator, emulation) |
Lock-in | The vendor supports your simulators and UVM version | The VIP only runs on one vendor's simulator, and you use two |
For the DMA, the answer is easy to defend: the course built APB and AXI-Stream agents in days, because both protocols fit on a page and the bench needed only a subset. For an AXI4 master on a real DMA, with outstanding transactions per ID and in-order responses per ID (the case out-of-order scoreboards exist for), building a checker that catches every protocol violation is months of work that a vendor has already done and a compliance suite already measures.
Qualification is a short project with a written result. Run it before the purchase is final where you can (most vendors offer an evaluation licence), and again on every major version.
Check | How | Pass when |
|---|---|---|
Compliance suite | Run the vendor's suite on your simulator, with your UVM version and compile flags | It passes there, not only on the vendor's reference setup |
Checker sensitivity | Inject protocol errors: drop a handshake, change data while valid is high and ready is low, reuse an ID illegally | Each injected error produces a counted |
Default enables | Read the config defaults for checkers, coverage and recording | Protocol checking is on by default, or your wrapper turns it on |
Coverage model | Map its covergroups against the protocol spec and your plan | Your plan's protocol rows map to its coverage, or you know what to add |
Performance | Run your longest test with the number of instances the chip needs | Run time and memory stay within your regression budget |
Debug visibility | Fail a test on purpose and debug it with the VIP's messages and transaction recording | You can find the cause without vendor support |
Integration | Wrap it with your adapter, config map and message policy | Your scoreboards and tests never name a vendor type |
Support | File one real ticket during evaluation | A useful answer arrives in days, not weeks |
The checker-sensitivity row matters most and is skipped most often. A checker that is never seen to fail is a checker you are trusting on faith. Here is the shape of a qualification test: inject a violation and require that the VIP reports it. The vendor names are invented, as in Integrating Third-Party VIP:
// snippet: qualification test shape (vendor names invented)
class vip_expect_catcher extends uvm_report_catcher;
`uvm_object_utils(vip_expect_catcher)
string id_pattern = "VND_AXI_*";
int unsigned seen;
function new(string name = "vip_expect_catcher");
super.new(name);
endfunction
function action_e catch();
if (get_severity() == UVM_ERROR && uvm_is_match(id_pattern, get_id())) begin
seen++;
set_severity(UVM_INFO); // expected in this test only
set_message({"[EXPECTED] ", get_message()});
end
return THROW;
endfunction
endclass
// In the qualification test: attach the catcher to the VIP agent only, inject
// one violation with an error sequence, then in report_phase:
// if (catcher.seen == 0)
// `uvm_error("QUAL", "injected protocol error was not reported by the VIP")The catcher demotes only the expected errors, only on the VIP, only in this test, and the test fails if the VIP stayed silent. Checking Expected Faults covers the pattern in depth.
A bought VIP is not free to integrate. Budget for a transaction adapter so your scoreboards never see vendor types, a config map so tests never set vendor fields, a message policy for its warnings, compile isolation and a pinned version. Integrating Third-Party VIP builds all four on the DMA bench. Those layers are also your lock-in insurance: if the vendor is replaced, the adapter and the config map are the whole change.
The course never bought a VIP, but it did qualify its own checking, and the runs show why qualification is about seeing a checker fail. First, a planted DUT bug, the mutation build:
+UVM_TESTNAME=dma_smoke_test with EXTRA_ARGS=+define+DMA_BUG_WORD6
UVM_ERROR dma_tb.sv(396) @ 375000: uvm_test_top.env.sb [SB_MISMATCH] expected 52c7d685, got ad38297a
UVM_INFO dma_tb.sv(411) @ 655000: uvm_test_top.env.sb [SB] 7 words matched, 1 mismatchedThen the trap: a library comparator fed by a deliberately wrong predictor.
+UVM_TESTNAME=dma_cmp_trap_test
UVM_INFO dma_tb.sv(411) @ 655000: uvm_test_top.env.sb [SB] 8 words matched, 0 mismatched
UVM_INFO dma_tb.sv(1637) @ 655000: uvm_test_top.env [CMP] class comparator: 8 matches, 0 mismatchesThe scoreboard passed qualification: one corrupted word, one mismatch, on the right word.
The class comparator failed it: 8 wrong predictions reported as 8 matches, because axis_item has no do_compare, so compare() had nothing to compare. Without a test that fed it wrong data on purpose, that comparator would have been trusted. The same is true of any VIP checker you have never seen fire.
A team bought a well-known protocol VIP, integrated it in a week and ran it for six months. Their regression was clean. During a chip-level bring-up, a lab engineer found a protocol violation on that interface that the VIP should have flagged on day one. The VIP's protocol checker was controlled by a configuration bit that defaulted to off in the release they had, documented on page 140 of the user guide. Nobody had injected an error during integration, so nobody had seen the checker stay silent.
The fix took one line. The lesson took longer: the qualification checklist's sensitivity row, and a regression test that injects one violation per release and fails if the VIP does not report it. That test is cheap, and it is the only evidence that the checker you are paying for is running.
No. Compliance on another simulator says the VIP is correct there; your compile flags, UVM version and simulator semantics may differ (race behaviour, constraint solver, unsupported constructs). Run the suite in your own flow, and treat any failure as a qualification issue for the vendor to resolve before you depend on the VIP.
Whether its checks can fail at all. Inject a violation (data changing while TVALID is high and TREADY is low, TVALID dropping before the handshake) and confirm each produces a counted error. A year of silence is equally consistent with a correct design and a checker that never runs, as the class-comparator trap showed on this bench.
Next: VIP is one tool in the strategy. Choosing the Verification Strategy per Block picks the right tool for each block.