SoC Testbench Structure

Pick one strategy and stay consistent.

Mixing the two within the same testbench - some sub-environments reusing whole block-level envs, others hand-picking agents - makes it unpredictable where a given piece of checking or coverage actually lives, which is exactly the kind of ambiguity a large SoC testbench can't afford. Whichever strategy a team picks, it should apply it the same way at every sub-environment boundary.

The Standard Layer Stack

Most production SoC testbenches settle into three layers, regardless of vendor or methodology flavor:

• soc_env - the top-level environment. Owns the virtual sequencer, the top-level (or chained) scoreboard, and the unified register model (RAL).
• Sub-environments - group related blocks that naturally interact, such as a CPU subsystem or a peripheral cluster. These exist mainly for hierarchy and reuse across chip variants, not for new checking logic.
• Block-level UVC environments - the reused, largely unmodified IP-level agents, now mostly passive, sitting at the bottom of the tree.

Keep the sub-environment layer thin. If it starts collecting its own checking or coverage logic instead of just instantiating and connecting child UVCs, that logic usually belongs in the scoreboard or a dedicated coverage collector instead.

One sub-environment deserves special mention: the cpu_subsystem_env. Once the DUT has a CPU, that sub-environment isn't just hosting a passive cpu_agent the way a peripheral sub-environment hosts a passive UVC. It also has to get compiled software onto the CPU and running in the first place, which is a structural concern of the testbench, not just a test-writing concern.

The Virtual Sequencer Ties the Blocks Together

A single UVC's sequencer only knows about its own driver. SoC-level scenarios - "start a DMA transfer while the CPU polls its status register" - span multiple sequencers at once, so the environment needs a coordinating point above them: the virtual sequencer. It doesn't drive any interface itself; it just holds handles to the sequencers of the active agents underneath it.

class soc_virtual_sequencer extends uvm_sequencer;
  `uvm_component_utils(soc_virtual_sequencer)

  // Handles into each active block's sequencer.
  // Populated in soc_env::connect_phase() from the child UVC handles.
  uvm_sequencer #(apb_seq_item) apb_sqr;
  uvm_sequencer #(dma_seq_item) dma_sqr;

  // Rest of the code (constructor)
endclass

A virtual sequence runs on this sequencer and forks child sequences onto the individual block sequencers it holds:

class dma_while_cpu_polls_vseq extends uvm_sequence;
  `uvm_object_utils(dma_while_cpu_polls_vseq)
  `uvm_declare_p_sequencer(soc_virtual_sequencer)

  virtual task body();
    fork
      // Kick off a DMA transfer on the DMA block's sequencer
      dma_kickoff_seq::type_id::create("dma_kickoff_seq").start(p_sequencer.dma_sqr);
      // Simultaneously poll the status register on the APB sequencer
      apb_poll_status_seq::type_id::create("apb_poll_status_seq").start(p_sequencer.apb_sqr);
    join
  endtask
endclass

`uvm_declare_p_sequencer gives the virtual sequence a correctly typed p_sequencer handle, so p_sequencer.dma_sqr and p_sequencer.apb_sqr resolve without manual casting. If you haven't used virtual sequencers before, ChipVerify's virtual sequencer article covers the block-level mechanics this builds on.

Only the agents left active need a handle on the virtual sequencer - the passive ones have nothing to receive stimulus from, so they're absent here by design, not by oversight.

Two Stimulus Engines: The Virtual Sequencer and the CPU

The virtual sequencer only accounts for half the picture. As soon as the DUT includes a CPU, the SoC testbench has two independent stimulus engines running side by side: the virtual sequencer driving whatever agents are left active in SV, and the CPU itself, fetching and executing a compiled software image that drives every interface reconfigured to passive. Structurally, the environment has to make room for both, not just the one carried over from block-level verification.

That means cpu_subsystem_env typically owns a second kind of component alongside its agents - one whose job isn't to drive a protocol, but to get the compiled test image into memory and release the CPU from reset so it starts fetching:

class cpu_subsystem_env extends uvm_env;
  `uvm_component_utils(cpu_subsystem_env)

  cpu_agent   cpu_agt;   // passive - reused IP-level UVC, observes the bus
  sw_loader   sw_ldr;    // loads the compiled C test image, releases reset

  virtual function void build_phase(uvm_phase phase);
    cpu_agt = cpu_agent::type_id::create("cpu_agt", this);
    sw_ldr  = sw_loader::type_id::create("sw_ldr", this);
  endfunction

  // Rest of the code (connect_phase, run_phase)
endclass

sw_loader is a plain uvm_component, not a UVC - it has no driver or sequencer of its own. Its job is purely to get software running; the resulting bus traffic is what the (now passive) cpu_agt observes. Chapter 2 covers how it actually gets the image in - backdoor memory loads versus a frontdoor boot ROM - and how the reset-to-fetch sequence is timed.

The two engines aren't interchangeable, and a testbench that only builds for one of them is missing half its coverage. The virtual sequencer can hit corner cases and error conditions no real driver would ever construct; the CPU running production or near-production software is the only thing that proves the chip works the way it will actually be used. Both need to be able to run in the same test, often concurrently, and both need to report into the same top-level scoreboard so a failure caught by either one fails the test.

This is a hand-off point, not a deep dive. How the two engines actually coordinate - a C test signaling completion to an SV sequence, an SV sequence injecting a fault while software is mid-transaction - is structural enough to affect cpu_subsystem_env's design, but the mechanics belong to the next article in this chapter, The Role of Software in SoC Verification.

Not Everything Runs Through This Testbench: Where Formal Fits

Even a well-structured soc_env with both stimulus engines wired up isn't where every SoC-level property gets proven. Some checks are structural rather than behavioral - they're about how the chip is wired, not what it computes - and those are usually handed to a formal tool running as a separate flow alongside simulation, not built as another component inside this environment.

The clearest example is connectivity checking: confirming that every signal that's supposed to reach a pin, a reset tree, or a multiplexed pad actually does, across every mode the chip supports. A directed simulation test can pass while a watchdog reset still fails to reach some flip-flop it was never specifically checked against - the test wasn't wrong, it just never exercised that particular fan-out path. Formal connectivity tools instead prove every path exhaustively from the netlist itself, which is a better fit for a property that's about structure, not about a specific stimulus sequence.

• Connectivity and pin muxing - every intended source-to-destination path, across every mode, proven exhaustively rather than sampled by directed tests.
• Reset and clock-domain-crossing (CDC) checks - fan-out and synchronization properties that are impractical to cover completely with directed or even randomized simulation.
• Register and address-decode access - confirming every register in the unified map decodes and responds as specified, often before the SoC testbench is even stable enough to run full tests.

Formal also runs earlier at the block level, signing off protocol compliance and corner-case properties before that block's UVC ever gets reused here - so by the time you're composing soc_env, some properties already have a formal proof behind them and don't need re-proving in simulation. Chapter 4's Connectivity Verification: Why Formal, Not Simulation covers this in depth.

The practical takeaway for testbench structure: soc_env doesn't have to (and shouldn't try to) simulate every property just because it's SoC-wide. The verification plan for a chip is the sum of this UVM testbench, the formal flows running beside it, and - later in the flow - emulation and FPGA prototyping. This article is about one piece of that plan, not all of it.

Configuration Makes One Testbench Fit Many Chips

Few teams verify a single fixed SoC. The same testbench usually has to support several configurations of the chip: a version with two DMA channels versus four, or an address map that shifts a peripheral's base address between product variants. Hard-coding these differences into the environment defeats the point of building a reusable SoC testbench.

Instead, a single configuration object - distributed through uvm_config_db before build_phase - carries fields like num_dma_channels or has_secure_region, and every environment's build_phase reads it to decide how many child components to construct and how to wire the address map. The test class selects which configuration to apply; the environment code itself never changes between chip variants.

Treat the configuration object the same way you treat the register model: one source of truth, built once per test, read everywhere else. Scattering +define macros or hard-coded parameters through the environment recreates the maintenance problem configuration objects exist to remove.

Common Mistakes