The DMA bench compiles once and runs nine different scenarios: a smoke job, random jobs, a truncated packet, a scoreboard-owned drain, a deliberate hang, a virtual sequence, output backpressure, a reset in the middle of a packet, and an interrupt agent. Every one of them is a small class that extends dma_base_test, and every one is picked at run time by a single plusarg. This topic is about that layer: what the base test owns, what a derived test is allowed to change, and how the whole set grows into a regression without turning into copy-paste.

What you will be able to do

• Say what belongs in a base test and what does not, and defend the helpers reg_write, reg_read and run_job that the bench's base test provides.

• Read any derived test as a scenario: one sentence of intent, and exactly what it changes (stimulus, a factory override, or policy).

• Register type and instance overrides from a test, explain which one wins, and know when "before super.build_phase" really matters.

• Put end-of-test policy in one place instead of nine, select tests and knobs from the command line, and write a top module that the next level of integration can replace.

• Design a test library: hierarchy, naming, regression lists, and the choice between a new test, a new sequence and a new plusarg.

How one test gets from the command line to the DUT

If you have not read Environment Architecture yet, read it first: the tests here assume you know what dma_env builds and why the environment, not the test, owns topology.

The lessons, in order

Start with: Base Test Pattern.