Advanced verification & UVM

UVM driver

A UVM driver is the component that takes an abstract request — 'write the value 0x55 to address 0x10' — and wiggles the actual pins of the design to make that request happen, cycle by cycle, exactly as the protocol demands. It is the hands of the testbench. The sequencer hands it transactions like a chef calling out orders; the driver is the line cook that turns each order into real motion: assert valid, wait for ready, hold data stable, deassert. It speaks the design's native pin-level language so the rest of the testbench never has to.

The driver and sequencer communicate through a tidy handshake (get_next_item / item_done) so the sequencer is blocked until the driver has actually finished pushing each transaction onto the wires. This separation — high-level intent in the sequence, low-level timing in the driver — is what lets you reuse the same stimulus across different protocol speeds: change only the driver's timing, and every existing test still runs.

A common beginner bug is forgetting to call item_done() — the sequencer then hangs forever waiting for the driver, and the simulation stalls with no error message.

Also called
driveruvm_driver驅動器