Build a UVM testbench: driver, monitor, scoreboard and coverage-driven closure

You are interviewing for a hardware design verification role, and the interviewer wants to see whether you have really built and used a verification environment. Explain how you would verify an RTL block with SystemVerilog and UVM. For concreteness, assume the block receives transactions (an ID and a data word) on an input interface with a valid/ready handshake, processes them, and returns one result per input on an output interface with the same handshake. You may use a block you know instead, as long as you state its interfaces. ### Clarifying Questions - Do results leave the block in the same order as the inputs, or can they be reordered, for example by ID? - Is there a reference model (for example in C or C++), or must the testbench compute expected results itself? - Does the block have configuration registers that must be programmed before traffic starts? - Is this a block-level environment, and should it be reusable at the subsystem or chip level? ### Part 1 — Testbench architecture Sketch the UVM testbench: its components, what each one does, how they are connected, and how the class-based testbench reaches the DUT's signals. Trace how one transaction travels from a test to the DUT's pins. ```hint Follow one transaction Start from a test that wants to send one transaction, and list every component it passes through until it toggles a pin. Then do the same in reverse from the output pins. ``` ```hint Static versus dynamic The DUT and its interfaces are modules; the UVM components are classes created at run time. Consider what bridges the two worlds, and how it reaches the components that need it. ``` #### What This Part Should Cover - The UVM component hierarchy and the job of each component, including active versus passive agents - How components connect to each other (TLM ports) and to the signals (interfaces and the configuration database) - Phases, the factory, and how tests vary stimulus without editing the environment - Protocol-level checks on the interfaces ### Part 2 — Monitor and scoreboard What does a monitor do, and why is it separate from the driver? How does your scoreboard decide whether the DUT behaved correctly, including when results can leave in a different order from the inputs, and how does it detect results that never come out? ```hint Where expected values come from A scoreboard compares two streams. Decide where each stream comes from, and what has to happen to the input stream before it can be compared with the output. ``` ```hint The end of the test A wrong value is easy to catch. Think about which kind of bug produces no mismatch at all, and at what point in the test you would catch it. ``` #### What This Part Should Cover - Monitor responsibilities, and why checking is based on observed pins rather than on what the driver intended - How expected results are produced (reference model or predictor) and compared, in order and out of order - End-of-test checks and drain handling, so that missing or extra results are caught - Error reporting that makes a failure easy to debug ### Part 3 — Coverage and verification methodology How do you know verification is done? Compare code coverage with functional coverage, show how you would write functional coverage for this block, and explain how coverage steers constrained-random stimulus, directed tests and sign-off. ```hint Two different questions One kind of coverage tells you which lines of RTL ran; the other tells you which features and scenarios from the specification were exercised. Think about what each one can miss. ``` #### What This Part Should Cover - What code coverage measures, and what it cannot tell you - Functional coverage derived from a verification plan: coverpoints, bins, crosses and assertion coverage - The coverage-driven loop of constrained-random regressions, hole analysis and directed tests - Sign-off criteria beyond a single coverage number ### What a Strong Answer Covers - A self-checking, reusable environment with a clean separation of stimulus, driving, observing and checking - Correct UVM mechanics described from hands-on use rather than as vocabulary - A scoreboard that catches wrong, extra and missing results - Coverage-driven closure using both code and functional coverage - Practical debugging: reproducible seeds, clear messages, assertions close to the source of a bug ### Follow-up Questions - How would you reuse this block-level environment when the block is integrated into a larger subsystem? - Functional coverage is at 100% but code coverage shows a branch that was never taken. What do you do? - A scoreboard mismatch appears with only one random seed out of thousands. How do you debug it? - When would you check a behavior with a SystemVerilog assertion instead of in the scoreboard?