The driver handshake is four calls. Behind them sits a good deal of machinery: a lifecycle that start() walks through, an arbitration queue in the sequencer, a response queue in every sequence, and a set of ways to stop all of it. Senior interviews live here, because this is where real benches break: the high-priority sequence that waits anyway, the response queue that silently overflows, the reset that leaves the driver holding a stale item.
List what seq.start(sqr, parent, priority, call_pre_post) does, in order, and say when pre_body and post_body are skipped.
Explain how the sequencer picks the next sequence in each arbitration mode, and write a custom arbitration function.
Return responses from in-order and pipelined drivers without overflowing the response queue, and match them by transaction ID.
Stop sequences around a reset without fatals or zombies, and choose who owns the objection.
Read a uvm_do macro and write the explicit code it stands for.
Lesson | What you learn |
|---|---|
The steps of | |
The arbitration queue, grants, priorities, the six arbitration modes, | |
The response queue and its depth of 8, | |
| |
| |
What each macro expands to, the IEEE 1800.2 forms, and why many teams ban them. |
Several of these lessons show logs from a small lab bench, seq_lab_tb.sv: one agent with a sequencer and a few driver variants, run with Verilator and the same IEEE 1800.2 UVM library as the DMA bench. The DMA bench itself has one driver per interface, and these mechanisms need several.