Verification Architecture Hub: Block to SoC Reuse

Overview

Senior verification architecture is about boundaries and reuse — the same agent VIP serves block, subsystem, and chip levels; what changes is role, config, and surrounding checkers.

Design decisions should cite reuse, config strategy, and passive-agent patterns — not ad hoc per-level rewrites.

Sub-lessons in this topic

1. block-level-baseline — active agents, full scoreboard, directed + random mix.

2. subsystem-integration — composing block VIPs with integration checkers.

3. soc-multi-domain — power, clock, and multi-interface chip composition.

4. reuse-config-strategy — cfg objects, is_active, and hierarchy-scoped knobs.

5. passive-agent-soc-pattern — flip active→passive when RTL drives pins.

6. architecture-tradeoff-matrix — document decisions with explicit trade-offs.

[ARCH][SENIOR][UVM] verification reuse ladder

block TB
  active agents + full SB + block coverage
      |
      v
subsystem TB
  mix active/passive + integration SB + scenario vseqs
      |
      v
SoC TB
  mostly passive monitors + chip SB + SW-like stimulus

// architecture principle: one agent class, many roles
class bus_agent extends uvm_agent;
  bus_cfg cfg;
  bus_monitor mon;
  bus_driver drv;
  bus_sequencer sqr;

  function void build_phase(uvm_phase phase);
    super.build_phase(phase);
    mon = bus_monitor::type_id::create("mon", this);
    if (cfg.is_active == UVM_ACTIVE) begin
      sqr = bus_sequencer::type_id::create("sqr", this);
      drv = bus_driver::type_id::create("drv", this);
    end
  endfunction
endclass

Key takeaways

• Reuse the same VIP across hierarchy levels — do not fork per level.

• Architecture is config-driven: is_active, interfaces, and checker wiring.

• Passive agents at chip level prevent double-driving and preserve checking.

• Document trade-offs explicitly — senior reviews demand rationale.

Common pitfalls

• Rebuilding agents per hierarchy level instead of reusing one VIP.

• Driving pins with two masters because a block agent stayed active at SoC.

• Leaking VIP internals so integrators couple to implementation.

• No documented config contract between VIP author and integrator.

The reuse ladder in practice

Each level adds integration scope but should subtract duplicated agent logic.

[ARCH][SENIOR][UVM] level comparison

LEVEL        AGENTS              CHECKING                 STIMULUS
block        active (drive)      block scoreboard         directed + random
subsystem    mix active/passive  block + integration SB   scenario vseqs
SoC/chip     mostly passive      chip SB + SW checks      SW-like vseqs

Architecture review questions

• Can this agent serve block and chip without code changes?

• Is is_active the only difference between block and SoC usage?

• What is the VIP's published API (cfg, seq lib, analysis port)?

• Who owns integration scoreboard vs block scoreboard?

[ARCH] senior review gate

reuse:
  same agent source at all levels

config:
  cfg object is the only configuration path

boundaries:
  VIP internals hidden from integrator

documentation:
  tradeoff matrix attached to arch doc

Common pitfalls

• Chip TB that reimplements block protocol checks from scratch.

• Subsystem env with no clear owner for cross-block integration checks.

• Config scattered across plusargs, defines, and direct field pokes.