A UVM bench that simulates one block with an event-driven simulator is where most DV careers start. Real projects keep pushing past it. A car company asks for proof that a broken flip-flop cannot hurt anyone. The SoC team wants to boot Linux before tape-out, and the simulator would take weeks to do it. The architects hand you a SystemC model and a C++ algorithm, and the analog team hands you an ADC. This topic covers those four exits from the plain UVM bench, and what changes in your work at each one.
Explain ISO 26262 in a DV engineer's terms, run a fault campaign, read its result and turn each missed fault into a testbench fix.
Say when a design moves to emulation or an FPGA prototype, what a split HVL/HDL testbench is, and what UVM code has to change for it.
Connect SystemC TLM models, C/C++ reference models, C tests on an embedded CPU and Python (cocotb) to a UVM flow, and choose between them per block.
Verify a mixed-signal boundary with real-number models: thresholds, settling and monotonicity, with tolerance-based checks.
Lesson | The question it answers |
|---|---|
Your bench passes every test. How many broken-hardware faults would it notice, and what do the safety metrics measure? | |
The simulator runs at a few hundred cycles a second on the full SoC. What moves to a box, and what must change in the bench? | |
How do SystemC, C/C++, embedded C tests and Python fit with UVM, and who picks which? | |
How does a digital DV engineer check an ADC, a DAC or a PLL without a SPICE simulator in every run? |