uvm_driver Hub: Execution Contracts and Debug Discipline

Overview

This hub defines a practical contract for uvm_driver : predictable ownership transfer, explicit completion semantics, and instrumentation that makes deadlocks diagnosable in minutes instead of hours.

The same patterns apply to simple bus drivers and complex VIP: keep pull/completion boundaries visible, classify failures deterministically, and make progress observable.

Sub-lessons in this topic

1. run-phase-loop - run_phase Loop.

2. virtual-interface-setup - Virtual Interface Setup.

3. protocol-drive-task - Protocol Drive Task.

4. reset-clock-discipline - Reset and Clock Discipline.

5. driver-error-handling - Driver Error Handling.

6. driver-debug-patterns - Driver Debug Patterns.

Architecture map

[DRV][TLM][UVM] handshake control spine

[UVM] sequence intent
   -> [TLM] sequencer arbitration
   -> [DRV] get_next_item
   -> [DRV] protocol execution
   -> [TLM] item_done / response
   -> [UVM] sequence progress

invariants:
  one grant -> one completion
  bounded wait -> explicit status
  identity-preserving responses

[DRV][TLM][UVM] timeline anchors

- request granted
- transfer active
- completion emitted
- response consumed

these anchors should appear in logs and counters

Key takeaways

• Model handshake semantics as a protocol, not boilerplate.

• Exactly-once completion is the top-level invariant.

• Bounded waits and explicit statuses prevent silent hangs.

• Minimal structured telemetry accelerates root-cause isolation.

Common pitfalls

• Treating get_next_item/item_done as incidental implementation details.

• Mixing response styles without clear sequence-side contract.

• Ignoring reset/timeout branches in completion logic.

• Debugging by waveform first without progress counters.