UVM Callbacks: Runtime Hooks for Advanced Control

Overview

Callbacks let you inject behavior without editing the main component . Instead of forking a driver or monitor each time a project needs custom logic, UVM lets you register callback objects and execute user-defined hooks at targeted points in the flow.

Think of callbacks as controlled extension points. The base component keeps ownership of protocol timing and core correctness, while tests or environments selectively attach callback logic for traffic shaping, protocol perturbation, fault injection, coverage nudges, and observability.

Lessons in this topic

1. Callback Type and Hooks - uvm_callback, uvm_register_cb, and virtual hook methods.

2. uvm_do_callbacks Flow - macro execution sequence, callback ordering, and multi-callback execution.

3. Registration Per Instance - add/delete callbacks, get_first/get_next iteration, and ordering behavior.

4. Error Injection Patterns - field corruption, delay injection, and protocol perturbation templates.

5. Callback vs Virtual vs Config - practical decision table for choosing extension mechanisms.

6. VIP Callback API Design - guidance for VIP authors exposing stable, composable callback hooks.

Big-picture map

[TEST] scenario intent
   │
   │ attaches callback objects
   ▼
[UVM] agent/env build
   │
   ├── [ADV] callback registration
   │       drv.cb_pool <= my_delay_cb, my_corrupt_cb
   │
   ▼
[DRV] main protocol loop
   │
   ├── pre_tx hook  ──► callbacks run in order
   ├── drive item   ──► base timing/protocol stays authoritative
   └── post_tx hook ──► callbacks observe/update metrics
   ▼
[UVM] scoreboard/coverage sees impacted traffic

[UVM][ADV] callback positioning philosophy

  Base component responsibilities:
    - protocol legality
    - pin timing
    - transaction ownership
    - error handling baseline

  Callback responsibilities:
    - optional behavior tweaks
    - scenario-specific perturbations
    - test-specific instrumentation
    - reusable policy objects

  Goal: extension without inheritance explosion

Key takeaways

• Callbacks are runtime extension points, not replacements for protocol ownership.

• Keep base driver/monitor stable; project-specific behavior lives in callback classes.

• Registration controls scope: global component class vs specific instance.

• A disciplined callback API prevents copy-paste VIP forks.

Common pitfalls

• Putting core protocol logic inside callbacks - makes behavior fragile and order-dependent.

• Using callbacks for one-time static settings - use config_db instead.

• Ignoring callback order - stacked callbacks can produce non-obvious interactions.

• No documented hook contract - users cannot safely build callback classes.