The DMA bench's stream agent drives data into the DMA at block level, watches the DMA's output passively, and, in the two-DMA subsystem bench, watches a bus that no testbench component drives at all. Same class, three jobs, zero edits. That is what VIP (verification IP) means: an agent packaged so that other benches, other teams and other projects can use it without opening the source. This topic is about the decisions that make that true.
Say exactly what a VIP must guarantee before an integrator can switch it to passive at subsystem or chip level.
Place two passive monitors on one bus on purpose, and know what that costs and what it buys.
Decide which variation points are parameters and which are configuration knobs, and live with the factory's limits on parameterized classes.
Name what each common protocol agent (APB, AXI, AXI-Stream) must get right, and where protocol rules should be checked.
Ship a VIP release that consumers can upgrade on purpose: versions, deprecation shims, a library-version check and a qualification gate.
Lesson | What it covers |
|---|---|
What a VIP owes its integrator for passive reuse: no drives from the interface, a self-sufficient monitor, input-only binding at chip level. | |
The subsystem bench's middle bus, watched by dma0.out_agt and dma1.in_agt; why both stay, and how not to double count. | |
Parameters versus knobs, max-width builds, parameterized classes and the factory, and a validated config object. | |
What APB, AXI and AXI-Stream agents must each get right, item granularity, and protocol checks in the interface. | |
Semantic versions, deprecation shims, UVM-library checks, encrypted delivery and the release gate. |