Top Module Hub: Startup Contracts from HDL to UVM

Overview

The top module is the HDL bridge between static design infrastructure and dynamic UVM verification classes. A robust startup contract prevents null interfaces, wrong test selection, and reset-race failures.

Keep startup architecture explicit: publish handles before run_test, lock deterministic reset policy, and prove first-traffic plus first-check liveness.

Sub-lessons in this topic

1. hdltop-structure - robust top.sv layering and ownership boundaries.

2. interface-config-db - publishing/retrieving virtual interfaces correctly.

3. run-test-factory - startup test selection and override governance.

4. clock-reset-generation - deterministic multi-domain startup timing.

5. dpi-uvm-config - external startup knobs through DPI with safeguards.

6. startup-sequence-walkthrough - timeline-based startup debug methodology.

[UVM][ENV] startup architecture

top.sv
  -> instantiate interfaces + DUT
  -> generate deterministic clock/reset
  -> publish startup handles via config_db
  -> call run_test once

base_test/env
  -> consume startup state in build/connect
  -> launch scenario with objections/timeout
  -> validate first monitor/checker liveness

[UVM][ENV] startup release gate

- interfaces/config published before build consumers
- requested test resolved by factory
- reset policy stable and documented
- first monitor publish and first compare observed
- timeout/objection controls active

Key takeaways

• Startup quality directly controls regression trustworthiness.

• Top-module logic should stay thin but highly observable.

• Ordering and path-scope discipline are non-negotiable startup contracts.

Common pitfalls

• Calling run_test before critical startup state is published.

• Encoding scenario policy in top.sv instead of UVM tests.

• No startup probes, forcing slow and noisy debug loops.

Applied Patterns

Use this startup checklist whenever top-level startup logic changes.

[UVM][ENV] startup checklist

structure:
  top owns static integration concerns only

publication:
  all required handles/knobs set before run_test

control:
  +UVM_TESTNAME resolves to known registered class

timing:
  reset/clock policy documented and validated

liveness:
  first monitor + checker activity proven

function void report_phase(uvm_phase phase);
  `uvm_info("STARTUP_HEALTH",
    $sformatf("test=%s mon=%0d cmp=%0d",
      get_type_name(), env.mon.publish_cnt, env.sb.compare_cnt),
    UVM_LOW)
endfunction

• Keep startup gates objective and counter-based.

• Use one deterministic smoke path for startup validation.

• Treat startup changes as infrastructure-level modifications.