In short: An interrupt is a sideband signal from a design block that says “something needs attention now”. In a UVM testbench you model interrupt handling by watching the interrupt lines and, when one fires, starting an interrupt service routine (ISR) sequence that uses grab() to take exclusive control of the sequencer. The ISR clears…
In short: A virtual interface is a handle that lets your class-based UVM code reach a real, static interface connected to the DUT. You pass it in with uvm_config_db#(virtual my_if)::set from the top module, then each component reads it with get in build_phase. This keeps the run-time class world and the static module world connected…
In short: A clock monitor is a reusable SystemVerilog/UVM component that watches a clock signal and automatically checks its frequency, duty cycle, and on-the-fly switching, and flags glitches or timeouts. Because it is built as a uvm_monitor inside a uvm_agent, you can plug it into any UVM environment and verify complex clock systems without writing…
In short: UVM RAL (Register Abstraction Layer) is a labelled remote control for the registers inside your chip. Your test reads and writes registers by name, like regmodel.uart.baud_div.write(…), and RAL turns each call into the correct bus activity. It also keeps a mirror copy of every register so your checks always know the expected value….
In short: The SoC verification flow is the end-to-end process of proving a whole chip works once all its blocks are stitched together. It moves through five stages: pull out the features to test, write a verification plan, build the environment and run tests, close functional and code coverage, then sign off. The focus at…
In short: This is the final part of building a UVM environment for the pipe design. Here we add the test, pass the real interface down to every component through the configuration database, add a coverage collector, build the top module that ties the design to the testbench, and finally run the first simulation. By…
In short: This is part three of building a UVM environment for the pipe design. Here we add the monitor that watches the pins, wrap the driver, sequencer, and monitor into an agent, and build a scoreboard that checks the results against a small reference model. We then group everything into an environment. After this…
In short: This is part two of building a full UVM environment for the pipe design. Here we finish the driver so it actually wiggles the pins, add the sequencer, and write several sequences: a single packet, many packets, and a directed case. We also explain the handshake between a sequence and the driver, so…
In short: This is part one of a four part series where we build a full UVM environment, step by step, to verify a small design. In this part we study the design under test (a two channel pipe), write its SystemVerilog interface, and create the transaction (the data packet) that will carry stimulus and…
In short: A UVM testbench is a stack of reusable classes. The sequence item is one packet of stimulus, the sequence decides what packets to send, the sequencer schedules them, the driver turns them into pin wiggles, the monitor reads pins back into packets, the agent groups the sequencer plus driver plus monitor for one…