A Complete Layered Testbench

Transaction, generator, driver, monitor, scoreboard and environment working together through mailboxes and a virtual interface.

Everything in this course comes together in a layered testbench, the architecture that UVM standardizes. Each class has one job, the classes talk only through mailboxes, and only the driver and monitor touch the design's pins (through a virtual interface). The same structure scales from this adder to verification of whole chips.

The testbench

Txn: the data item, with a constraint that makes 0 and 255 appear much more often than pure chance would.

Generator: randomizes n transactions and puts them into a mailbox.

Driver: takes each transaction, drives the pins through the virtual interface at the falling edge, and tells the scoreboard what it sent.

Monitor: watches out_valid on every clock and sends each result to the scoreboard.

Scoreboard: the reference model (a + b) and the comparison, in order.

Env: creates the components, connects them with mailboxes, runs them in parallel and prints the verdict.

Why this structure

Checking results inside the driver Drive in the driver, observe in the monitor, compare in the scoreboard

A driver that checks its own stimulus cannot be reused passively, and mixes timing of driving and sampling. Keeping the roles separate is what makes layered testbenches reusable.

Why does the monitor sample #1 after the clock edge (or use a clocking block)?

To read values after the design's non-blocking updates for that edge have settled, avoiding a race between the design updating outputs and the monitor reading them.

Which components touch the DUT's pins?

Only the driver (to apply stimulus) and the monitor (to observe). Everything else works with transactions.