In short: Good functional coverage guidelines keep your coverage honest and useful. The essentials: base coverage on the test plan and the spec, keep a traceability link from each scenario to a cover point, add controls to enable or disable coverage, turn coverage on after the early bug storm settles, collect coverage only from passing…
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…
In short: The UVM factory is a lookup table that decides which class to build when you ask for an object. You register a class once, always build with create() instead of new(), and then you can replace any class with a subclass from the test without editing the code that builds it. That is…
In short: Callbacks and the factory both help you reuse UVM code, but they solve different problems. A callback adds a small piece of behaviour at a fixed point inside a component you keep as-is, which is ideal for error injection or a locked third-party VIP. A factory override swaps a whole component or object…
In short: A UVM callback lets you change what a component (like a driver or monitor) does at chosen points, without touching that component’s source code. You define an empty hook method inside the component, register it, then plug in your own class later to inject errors, add checks, or collect coverage. It is the…
