The block bench's dma_env is 30 lines: three agents, a scoreboard and three connections. The subsystem bench verifies two DMAs in a chain, and its environment contains that same dma_env twice, unedited, plus one end-to-end checker. Getting there took a handful of decisions that are easy to get wrong: what the env decides and what the test decides, how options reach the env, which agents go passive one level up, how a vendor's VIP fits in without leaking into every test, and who holds the sequencer handles. This topic makes those decisions on the bench.
Design an environment and its config object: what the env builds and wires, what belongs in env config vs agent config vs the test, and why the env creates defaults only when its get fails.
Reuse a block env inside a subsystem env unchanged: passive agents on internal buses, the same virtual-interface names one level deeper, block scoreboards kept and an end-to-end checker added.
Integrate third-party VIP behind an adapter subscriber, a config map and a report catcher, and keep its version and compile under control.
Decide whether an env needs a virtual sequencer, where it lives at block, subsystem and SoC level, and what passive agents do to virtual sequences.
Lesson | What it answers |
|---|---|
What | |
The two-DMA bench: one env reused twice, the subsystem top, 10/10/10 matches, and what changes again at SoC level. | |
Adapter subscriber, config mapping, report catchers, version pinning, and what to ask the vendor. | |
Env-owned virtual sequencer vs handles, hierarchical virtual sequencers, and passive agents. |
Read this topic before Tests: Base Classes, Selection and Startup: tests make more sense once you know what the environment promises them. Start with: The Environment and Its Config Object.