A reusable testbench is written once and then bent by every test that uses it. In the DMA bench, dma_truncate_test swaps the stream driver for one that cuts packets short, dma_drain_test swaps the scoreboard for one that owns end of test, and dma_rand_test picks up a job description if someone published one. Not one of them edits the env. Two mechanisms make that possible: the factory decides which class each create call builds, and config_db decides how each instance is configured.
Swap a component, a sequence item or a sequence from a test or the command line, and predict which override wins.
Explain why an override that is clearly registered never runs, and fix it.
Write config_db sets and gets that match, and state who wins when two settings collide, during build and after.
Design config objects, keep config out of hot paths, and configure sequences per path.
Topic | Lessons | What it covers |
|---|---|---|
8 | Registration, create, override resolution (instance first, first match wins, chaining), timing and debug, parameterized and abstract classes, command-line overrides, items and sequences. | |
7 | The set/get contract, paths and wildcards, precedence at build and after, config objects, performance, auto-config, configuring sequences. |
Read the factory topic first: config_db lessons use overrides in their examples. The two rule-heavy lessons, Override resolution and config_db resolution order, are the single homes for their rules; every other lesson links to them.