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…
In short: Thinking like a verification engineer means you start from the specification and keep asking what can go wrong and why, long before you write a single line of code. Language and methodology are just tools. The real skill is turning a spec into a long list of scenarios, corner cases, and checks that…
In short: These UVM interview questions cover the topics interviewers ask most: TLM ports and analysis ports, sequences and sequence items, the driver-sequencer handshake API, the factory and overrides, uvm_config_db, phasing, objections, RAL, and callbacks. Each answer includes real UVM code you can adapt. Work through them out loud and you will be ready to…
In short: A uvm_report_catcher lets you inspect every report message before it is acted on, and change it. The most common use is an error demoter: you catch a known, harmless UVM_ERROR and lower it to a UVM_WARNING or UVM_INFO so it does not fail an otherwise passing test. You write a class that extends…
In short: UVM phasing is a fixed schedule that every component follows so the whole testbench starts, runs, and shuts down in the same order. Build phases run top down to create components, connect and end-of-elaboration wire them up, the run phase (plus its twelve sub-phases) drives real simulation time, and the cleanup phases run…
In short: UVM phasing is triggered by run_test(), the single call in your top module. run_test() builds the test component, then a phase controller walks every component through the phases in order, calling build_phase, connect_phase, run_phase, and the rest. You do not call the phases yourself; you only override the ones you need, and UVM…
In short: UVM reporting is how your testbench prints messages, and it comes with four severities: uvm_info, uvm_warning, uvm_error, and uvm_fatal. Each message carries an ID and, for info, a verbosity level so you can filter noise. The `uvm_info style macros wrap these calls and add file and line info automatically. You control what prints…
In short: A UVM run phase ends when no component holds an objection. Each component that has work raises an objection at the start and drops it when done; while any objection is up, the phase keeps running. So to end a test cleanly you raise an objection before your stimulus and drop it after….
In short: In UVM you build objects and components with the factory call type_id::create() instead of the plain constructor new(). Both end up calling new(), but create() first asks the factory which class to build, so a single override line in a test can swap one class for another without editing the code that builds…