Layered Architecture

Reusable UVM Architecture · Module 26 · Page 26.2

The Engineering Problem

The previous chapter established the mindset — a testbench must be architected for reuse and scale, not grown ad-hoc. But mindset needs structure: what architecture delivers reusability and scalability? The answer, the one UVM is built around, is layering — separating the testbench into layers, each operating at a different level of abstraction, each connecting to its neighbors through a standard interface. Without layering, a testbench is a tangle: the code that wiggles pins, the code that decides what stimulus to send, the code that checks results, and the code that configures the run are all mixed together — so a change to any of them ripples through all of them, and none can be reused without dragging the others along. The trap is mixing abstraction levels: a driver that also decides what to drive (scenario logic) and also checks the response (functional logic) works — but it's now welded to specific tests, unreusable, and unchangeable in isolation. Layering forbids this: each layer holds one concern at one abstraction level, so each can be changed and reused independently — which is precisely what makes the testbench reusable (lower layers reused across tests) and scalable (lower layers reused across integration levels). The problem this chapter solves is the layered architecture: the five canonical layers (signal, command, functional, scenario, test), what belongs in each, how they connect, and why the separation is the mechanism of reuse and scale.

Layered architecture separates the testbench into layers by level of abstraction, each connected to its neighbors through a standard interface, so each layer can be changed and reused independently. The five canonical layers, from the DUT upward: the signal layer (the physical pins — the interface and clocking, the only layer tied to the DUT's wires); the command layer (the driver and monitor — they translate between transactions and signals, the boundary where abstraction changes); the functional layer (the agent, scoreboard, coverage, predictor — they operate on transactions, checking and measuring); the scenario layer (the sequences and sequencer — they decide what transactions to generate, orchestrating meaningful scenarios); and the test layer (the test and configuration — they select scenarios and configure the environment for a particular run). Stimulus flows down (test → scenario → command → signal → DUT); response flows up (DUT → signal → monitor → functional). The cardinal discipline: each layer holds one concern at one abstraction level, connected by a standard interface (the transaction at the command↔functional boundary, the sequence item at the scenario↔command boundary) — so the lower layers (the agent: driver, monitor, functional checks) are reused unchanged across tests and integration levels, while only the scenario and test layers vary. Collapse the layers — put scenario or checking logic in the driver — and you lose both reuse and independent change. This chapter is the layered architecture: the layers, their concerns, their interfaces, and why the separation is the reuse.

What are the layers of a UVM testbench (signal, command, functional, scenario, test), what belongs in each, how do they connect through standard interfaces, and why is separating concerns by abstraction level exactly what delivers reusability and scalability?

Motivation — why layering is the mechanism of reuse

Layering isn't organizational tidiness — it's the mechanism by which reusability and scalability are achieved. The reasons each layer must be separate:

• Each layer changes for a different reason. The signal layer changes when the DUT pins change; the command layer when the protocol changes; the scenario layer when the stimulus strategy changes; the test layer every test. Separate layers mean a change for one reason touches one layer — not the whole testbench.
• Lower layers are reused across tests. Every test of a block uses the same agent (driver, monitor, coverage) — only the scenario and test layers differ. If the agent is separate, it's written once and reused by every test; if it's tangled with test logic, every test re-touches it.
• Lower layers are reused across integration levels. The block's agent is exactly what the subsystem and SoC need to drive and check that block's interface (the scalability of 26.1). A clean command/functional layer composes up; a tangled one can't.
• Standard interfaces let layers compose. Because layers connect through transactions (a standard abstraction), a sequence written for one driver works with any driver of that transaction type, and a scoreboard checks transactions regardless of how they were driven. The standard interface is what makes the pieces interchangeable.
• Mixing abstraction levels destroys all of it. A driver with scenario logic and inline checking can't be reused (it carries test-specific behavior), can't be changed in isolation (a check change edits the driver), and can't compose up (it drags its test concerns into the SoC). One layering violation forfeits the reuse layering exists to provide.

The motivation, in one line: layering is how reusability and scalability happen — because each layer changes for its own reason and connects through a standard interface, the lower layers (the agent and its checks) are built once and reused across every test and every integration level, while only the scenario and test layers vary — and mixing abstraction levels (a driver that decides what to drive or checks the result) couples the layers and forfeits the very reuse layering exists to deliver.

Mental Model

Hold layered architecture as the addressing layers of a postal system — each layer its own abstraction, handed off through a standard label, independently swappable, the transport reused by every sender:

When you mail a package, you write a street address and hand it over. You are working at the highest level of abstraction: this should reach this person at this place. You do not think about trucks or flight routes. The local post office takes your package and works one level down: it reads the address, decides the destination region, and hands the package to regional transport with a routing label. Regional transport works lower still: it doesn't care about the street, only the region, and it moves the package to the right national hub. National transport cares only about which hub, and loads it onto a truck or plane — the physical layer, the actual movement through space. At the destination it all runs in reverse, climbing back up: the package arrives at the national hub, goes to regional, to the local office, and finally to a carrier who knows the actual street and walks it to the door. Each layer operates at its own abstraction — street, region, nation, physical route — and hands off to the next through a standard interface: the labeled package. And because the layers are separate and the interface is standard, each layer is independently swappable. The post office installs new sorting machines, the airline changes, the trucks are replaced — and none of it changes how you write an address. Most importantly, the same transport infrastructure carries every package from every sender. You do not build a private delivery network for your one letter; you express intent at the top, and the shared lower layers, built once, translate it down to physical movement and back up to delivery. That is why mail scales to billions of packages: layered abstraction, standard handoffs, and shared lower layers reused by all. When you mail a package, you write a street address and hand it over — working at the highest abstraction (this should reach this person), not thinking about trucks or flight routes. The local post office works one level down: reads the address, decides the region, hands off to regional transport with a routing label. Regional works lower: it cares only about the region, moving the package to the right national hub. National cares only about which hub, loading it onto a truck or plane — the physical layer, the actual movement. At the destination it runs in reverse, climbing back up: national → regional → local → a carrier who knows the street and walks it to the door. Each layer operates at its own abstraction (street, region, nation, physical route) and hands off through a standard interface: the labeled package. And because the layers are separate and the interface standard, each is independently swappable — new sorting machines, a different airline, replaced trucks — none changes how you write an address. Most importantly, the same transport infrastructure carries every package from every sender: you don't build a private delivery network for one letter; you express intent at the top, and the shared lower layers, built once, translate it down to physical movement and back up to delivery.

So layered architecture is the postal system's layers: the test layer is the sender's intent (what to send, to whom — the run's purpose), the scenario layer composes the shipment (which packages, in what order — the sequences), the functional layer verifies delivery (the right thing reached the right place — the scoreboard/coverage), the command layer is the local post office (translating between the address and physical handling — transactions ↔ signals), and the signal layer is the trucks and planes (the physical movement — the pins). Each operates at its own abstraction, hands off through a standard interface (the transaction is the labeled package), and is independently swappable. And the lower layers are shared infrastructure reused by every sender — the agent is built once and reused by every test and every integration level, just as the postal network is built once and reused by every package. Mix the layers — put routing logic in the truck or the sender's intent in the sorting machine — and you lose the independence and shared reuse that make the system scale. Build the testbench as layered abstraction with standard handoffs and shared lower layers — express intent at the top, translate down to pins and back up, and reuse the lower layers across every test and level.

Visual Explanation — the five layers

The defining picture is the stack itself: signal, command, functional, scenario, test — five layers, each at its own abstraction.

The figure shows the five layers, top (most abstract) to bottom (physical). Test layer (the brand-colored top — test + configuration): selects scenarios and configures the environment for a particular run — varies every test. Scenario layer (sequences + sequencer): decide what transactions to generate, orchestrating meaningful scenarios. Functional layer (the success-colored — agent, scoreboard, coverage): operate on transactions to check results and measure coverage. Command layer (the warning-colored — driver + monitor): translate between transactions and signals — the boundary where abstraction changes. Signal layer (interface + clocking): the physical pins — the only layer tied to the DUT's wires. The crucial reading is the abstraction gradient: the top (test) works in intent ("run a stress scenario with these settings"), the bottom (signal) works in pin wiggles (valid, ready, addr, data), and each layer down is one level more concrete. The warning-colored command layer is highlighted as the boundary where abstraction changes — above it, everything is transactions (a write of this data to this address); below it, everything is signals (the handshake that carries that write). The driver translates down (transaction → signals), the monitor translates up (signals → transaction) — and because of this boundary, the layers above the command layer never touch a pin, and the signal layer never knows what a transaction means. That separation is what makes them reusable: a sequence (scenario layer) works with any driver that accepts its transaction; a scoreboard (functional layer) checks transactions regardless of how they were driven; the signal layer is the only thing that changes when the DUT's pins change. Each layer holds one concern at one abstraction level and connects through a standard interface — and that's precisely what lets each be changed and reused independently. The diagram is the architecture: test → scenario → functional → command → signal, a gradient of abstraction with the command layer as the translation boundary. Separate the testbench into five layers by abstraction level — each one concern, connected by standard interfaces — so each can change and be reused independently.

RTL / Simulation Perspective — one concern per layer

In code, layering means each component holds exactly one layer's concern. The example shows the layers cleanly separated versus a driver that violates the boundary.

// SIGNAL layer: the interface — physical pins + clocking (the only layer tied to the DUT)
interface bus_if(input bit clk); logic valid, ready; logic [31:0] addr, data; endinterface
 
// ✓ COMMAND layer: the driver ONLY translates a transaction into signal activity — nothing else
class bus_driver extends uvm_driver #(bus_txn);
  virtual bus_if vif;
  task run_phase(uvm_phase phase);
    forever begin
      seq_item_port.get_next_item(req);     // receive a transaction from the scenario layer
      vif.addr <= req.addr; vif.data <= req.data; vif.valid <= 1;  // translate → signals
      @(posedge vif.clk iff vif.ready);     // the protocol handshake — command-layer concern
      vif.valid <= 0;
      seq_item_port.item_done();
    end
  endtask  // NO decision about WHAT to drive (scenario), NO checking (functional) — one concern
endclass
 
// ✓ SCENARIO layer: the sequence decides WHAT transactions — nothing about signals
class write_burst_seq extends uvm_sequence #(bus_txn);
  task body(); repeat (16) begin req = bus_txn::type_id::create("req");
    start_item(req); assert(req.randomize()); finish_item(req); end  // intent, not pins
  endtask
endclass
 
// ✓ FUNCTIONAL layer: the scoreboard checks TRANSACTIONS — independent of how they were driven
class bus_scoreboard extends uvm_scoreboard; /* compares observed vs expected transactions */ endclass
 
// ✗ VIOLATION: a driver that takes on scenario + functional concerns → coupled, unreusable (DebugLab)
class smart_driver extends uvm_driver #(bus_txn);
  task run_phase(uvm_phase phase);
    if (test_name == "stress") req.data = gen_stress();   // ← SCENARIO logic in the command layer
    drive(req);
    if (vif.resp != expected) `uvm_error("DRV","mismatch");  // ← FUNCTIONAL checking in the driver
  endtask  // now the driver is welded to specific tests + checks — reusable nowhere
endclass

The code shows one concern per layer. The signal layer (bus_if): physical pins + clocking, the only DUT-tied layer. The command-layer driver (bus_driver): it only translates — get_next_item receives a transaction, the driver drives the signals and runs the protocol handshake (@(posedge clk iff ready) — a command-layer concern), then item_done. It makes no decision about what to drive (that's the scenario layer) and does no checking (that's the functional layer): one concern. The scenario-layer sequence (write_burst_seq): it decides what transactions (16 randomized writes) — intent, never touching a pin. The functional-layer scoreboard: it checks transactions, independent of how they were driven. The violation (smart_driver): a driver that takes on scenario logic (if test_name == "stress" — deciding what to drive) and functional checking (if vif.resp != expected — checking the response) — now it's welded to specific tests and checks, reusable nowhere (the DebugLab). The shape to carry: each layer's component holds exactly its own concern — the driver translates (command), the sequence decides (scenario), the scoreboard checks (functional) — and the boundaries are standard (the bus_txn transaction flows from sequence to driver via get_next_item/item_done; the scoreboard consumes transactions). The violation is mixing concerns (a driver doing scenario and functional work), which couples the command layer to tests and destroys its reusability. Keep each layer's component to one concern — the driver only translates, the sequence only decides, the scoreboard only checks — so each is reusable independently.

Verification Perspective — why the separation is the reuse

The defining payoff of layering is that the lower layers are reused while only the upper layers vary. Seeing which layers are fixed and which vary clarifies why the separation is the reuse.

The figure shows why the separation is the reuse. The lower layers — signal, command, functional (the interface, the driver and monitor, the scoreboard and coverage, bundled as the agent and environment) — are written once and reused unchanged across every test and every integration level (the success-colored fixed stack). The upper layers — scenario and test (the sequences and the test configuration) — vary per run (the warning-colored what varies). The verification insight is the ratio: in a mature testbench, the vast majority of the code is in the lower layers (the agent, the env, the checks — the infrastructure), and a new test reuses all of it, supplying only a new sequence and configuration (a small fraction). So the effort of building the infrastructure is paid once and amortized across hundreds of tests — that's the reuse layering delivers. This is only possible because of the standard interface at the scenario↔command boundary: the sequence hands the driver a transaction (bus_txn), and any sequence producing that transaction type works with the existing driver — so a new test's new sequence plugs into the unchanged lower stack. Collapse the layers — put test-specific logic in the driver or checking in the monitor — and this is impossible: the lower layers now contain per-test behavior, so every test must re-touch them, and nothing is reused. The test→scenario→agent flow (selects → transactions → fixed stack) shows the upper layers steering the reused lower stack, while the vary/reuse split on the right names what changes (scenario + test) versus what's reused (the whole lower stack). The crucial point is that reuse is not a feature added to the architecture — it is the architecture: the layering, with its standard interfaces, is what makes the lower layers reusable, and without it (collapsed layers), reuse cannot exist. The diagram is the reuse mechanism: lower layers fixed and reused, upper layers vary, connected by a standard transaction interface — the separation is the reuse. Build the lower layers once and reuse them across every test by varying only the scenario and test layers — the standard interface between them is what makes it possible.

Runtime / Execution Flow — stimulus down, response up

At run time, the layers cooperate: stimulus flows down the stack (intent → pins), and response flows up (pins → check). The flow shows the round trip through the layers.

The flow shows the round trip through the layers. Down (step 1): the test selects a scenario and configures; the scenario generates a transaction expressing intent. Down (step 2): the command-layer driver translates the transaction into signal activity, driving the DUT. Up (step 3): the DUT responds on the signals; the command-layer monitor reconstructs a transaction. Up (step 4): the functional layer checks the observed transaction against expected and records coverage. The runtime insight is the symmetry: stimulus descends from intent (a transaction meaning a write) to pins (the handshake that carries it), and response ascends from pins (the DUT's signal activity) back to a checked transaction (the meaning of what the DUT did). The command layer is the hinge — it translates down (driver: transaction → signals) on the stimulus path and translates up (monitor: signals → transaction) on the response path. Above the command layer, everything is transactions (the scenario thinks in writes and reads, the functional layer checks writes and reads); below it, everything is signals. This is why the upper layers are reusable across protocols up to the transaction: a scoreboard that checks transactions doesn't care whether the signal-level protocol is AXI or APB — only the command and signal layers know the protocol. And it's why the lower layers are reusable across tests: the driver and monitor translate any transaction the same way, regardless of which test generated it. The down (brand/default) → up (default/success) progression traces a single transaction's life: born as intent (scenario), translated to pins (driver), carried to the DUT, observed back as pins (monitor), checked as a transaction (functional). The crucial point is that each layer only ever talks to its neighbors through the standard interface (transaction up/down, signals at the bottom) — no layer reaches past its neighbor — which is exactly the discipline that keeps them independent and reusable. The flow is the layers cooperating: intent down to pins, pins up to a check, with the command layer translating at the boundary. Stimulus flows down from intent to pins and response flows up from pins to a check — each layer translating only between its abstraction and its neighbor's through the standard interface.

Waveform Perspective — the command layer translating one transaction

The command layer's translation is visible: one transaction (high abstraction) becomes a sequence of signal events (the handshake). The waveform shows the boundary where abstraction changes.

The waveform shows the command layer as the abstraction boundary. The scenario layer hands the driver a single write transaction (txn_issued — one event at the transaction level). The command-layer driver translates it into signal activity: it asserts valid with the address and data (addr=A4, data=D7), waits for the DUT to assert ready (the handshake), then completes. One transaction above the command layer becomes many signal events below it (six cycles of valid/ready/addr/data activity). On the response path, the monitor reconstructs a transaction from these same signals. The crucial reading is the change in abstraction across the boundary: above the command layer, the write is a single, indivisible thing (txn_issued — one event, one transaction object carrying addr A4, data D7); below it, the same write is a temporal protocol (assert valid, hold addr/data stable, wait for ready, deassert). The driver's job — the entire command-layer concern — is this translation: turning the atomic transaction into the protocol. The layers above never see valid/ready/addr/data — they work only in transactions — which is exactly why they're reusable independent of the signal-level protocol: a sequence that issues a write and a scoreboard that checks a write are identical whether the signal-level protocol is this handshake, AXI, or APB, because only the driver and monitor (command layer) know the protocol. The picture to carry is that the command layer is where one abstraction becomes another — transaction ↔ signals — and that boundary is what insulates the upper layers from the protocol, making them reusable. Reading the waveform this way — one transaction above, a multi-cycle handshake below, the driver translating between them — is seeing the abstraction boundary that the whole layered architecture is organized around. One transaction becomes a multi-cycle signal sequence at the command layer — that boundary is what keeps the upper layers protocol-independent and reusable.

DebugLab — the driver that knew too much

✗ LAYERING VIOLATION — the driver holds three layers' concerns:
  class smart_driver extends uvm_driver #(bus_txn);
    task run_phase(uvm_phase phase);
      if (test_name == "stress") req.data = gen_stress();   // SCENARIO concern (what to drive)
      drive_signals(req);                                    // command concern (the only legit one)
      if (vif.resp != expected) `uvm_error("DRV","mismatch");// FUNCTIONAL concern (checking)
    endtask
  endclass
  // → a new test must EDIT the driver (add an if-branch); reuse drags test logic + checks along;
  //   a check change edits the driver; the check is invisible in the functional layer → unreusable
 
✓ CLEAN LAYERING — each concern in its own layer:
  class bus_driver extends uvm_driver #(bus_txn);            // COMMAND: translate only
    task run_phase(uvm_phase phase);
      forever begin seq_item_port.get_next_item(req); drive_signals(req); seq_item_port.item_done(); end
    endtask
  endclass
  class stress_seq extends uvm_sequence #(bus_txn); /* SCENARIO: decides what to drive */ endclass
  class bus_scoreboard extends uvm_scoreboard;      /* FUNCTIONAL: checks the response */ endclass
  // → a new test = a NEW SEQUENCE (driver untouched); reuse the driver as-is; checks live in the scoreboard

Common Mistakes

• Putting scenario logic in the driver. Deciding what to drive is a scenario-layer concern; a driver keyed off test names can't be reused. Stimulus strategy lives in sequences.
• Checking inside the driver or monitor. Inline response checking is a functional-layer concern; it belongs in the scoreboard, centralized and visible.
• Reaching across abstraction levels. A sequence that wiggles pins, or a component that bypasses its neighbor, breaks the standard interface; each layer talks only to its neighbors.
• Mixing configuration into components. Hardcoded settings in the lower layers prevent reuse; configuration is the test layer's concern, passed down through config.
• Letting the boundary blur. The command layer is the one place abstraction changes; keep transactions above it and signals below it, never mixed.
• Treating layering as overhead. The separation isn't ceremony — it's the mechanism of reuse; collapse it and the lower layers can't be reused across tests or integration levels.

Senior Design Review Notes

Interview Insights

Exercises

1. Place the concern. Given a piece of logic — generating a stress pattern, asserting valid, comparing a response, selecting a test — name which layer it belongs in and why.
2. Find the violation. Given a driver that branches on a test name and checks a response inline, identify the two layering violations and refactor each into its proper layer.
3. Trace the round trip. Follow a single write transaction down from the scenario layer to the pins and back up to the scoreboard, naming the translation at the command layer in each direction.
4. Argue the reuse. Explain why separating the layers is what lets the same agent serve every test and compose from block to SoC, and what breaks if the layers are collapsed.

Summary

• Layered architecture separates the testbench into five layers by abstraction level — signal (pins), command (driver/monitor: translate transactions ↔ signals), functional (agent/scoreboard/coverage: check and measure), scenario (sequences: decide what transactions), test (test/config: select and configure) — each connected to its neighbors through a standard interface.
• Stimulus flows down (test → scenario → command → signal → DUT) and response flows up (DUT → signal → monitor → functional); the command layer is the boundary where abstraction changes (one transaction ↔ a multi-cycle signal sequence).
• The separation is the reuse: the lower layers (the agent and its checks) are written once and reused unchanged across every test and every integration level, while only the scenario and test layers vary — possible only because layers connect through standard interfaces (the transaction).
• The cardinal discipline: each layer holds one concern at one abstraction level — a layering violation (a driver with scenario logic or inline checking) couples the layers so nothing can be changed or reused independently, forfeiting the reuse layering exists to deliver.
• The durable rule of thumb: separate the testbench into signal, command, functional, scenario, and test layers, each holding exactly one concern at one abstraction level and connecting only through standard interfaces — the driver only translates, the sequence only decides, the scoreboard only checks, the test only configures — so the lower layers are reused unchanged across every test and integration level while only the scenario and test layers vary; mix abstraction levels and the architecture couples, forfeiting the reusability and scalability that layering exists to provide.

Next — Reuse Methodology: the layered architecture makes reuse possible; the next chapter makes it systematic. How to turn reusable components into a deliberate methodology — verification IP, configurable agents, base classes and factory overrides, packaging and versioning — so reuse isn't an accident of clean layering but a disciplined practice that scales components across blocks, projects, and teams.