Protocol Agents

Agents · Module 14 · Page 14.5

The Engineering Problem

The reuse discipline (Module 14.4) reaches its highest leverage on a standardized protocol. Most interfaces a chip exposes aren't bespoke — they're industry-standard protocols: AXI, AHB, APB (the AMBA family), plus PCIe, USB, I2C, SPI, Ethernet. A protocol agent is an agent built for one of these — and it's the most valuable kind of agent, because a standardized protocol means the same agent is correct for every DUT that uses it (and millions of chips use AXI). But building one raises a specific question: how does the protocol determine the agent? The protocol is a specification — a precise contract of signals, transactions, handshakes, and rules — and the agent must encode that spec faithfully. Its transaction must model the protocol's fields; its driver must speak the protocol's signaling; its monitor must reconstruct and check the protocol's rules; its sequences must generate the protocol's traffic. And the protocol has roles — master and slave — so the agent is built per role. The problem this chapter solves is how a standardized protocol shapes a protocol agent, and why that agent is the highest-value, most-reused VIP.

A protocol agent is an agent built for a specific standardized protocol — it encodes the protocol specification as a reusable verification component. The protocol shapes every part of it: the transaction models the protocol's logical operation (AXI: address, data, burst type/length/size, ID, response); the driver drives the protocol's signaling and framing (AXI's channels, per-channel valid/ready handshakes, burst sequencing); the monitor reconstructs the protocol's transactions and checks its rules (handshake, ordering, response matching); and the sequences generate the protocol's typical traffic. It is built per role — a master agent (drives requests, the initiator) or a slave agent (responds, the completer) — and you use the one matching the role the testbench plays (the complement of the DUT's role). Its protocol checking is its crown jewel: the agent is the protocol's compliance suite in executable form. Because the protocol is standard and ubiquitous, a protocol agent is the highest-leverage reuse there is — built once, reused across the entire industry's worth of that interface, which is why protocol VIP is a commercial product. This chapter is the protocol agent: how the spec shapes each component, master/slave roles, the agent as executable spec, and the wrong-role bug that hangs a DUT.

How does a standardized protocol shape a protocol agent — its transaction, driver, monitor, and sequences — what are the master/slave roles you build per role, and why is a protocol agent the highest-leverage, most widely-reused VIP?

Motivation — why protocol agents are the highest-value VIP

A protocol agent is worth the investment to build well because a standardized protocol multiplies the reuse. The reasons:

• A standard protocol is ubiquitous. AXI is on almost every SoC, many times over. An agent that correctly implements AXI is correct for every AXI interface — so its reuse spans the entire industry's worth of AXI ports. No bespoke agent reaches that scale.
• The protocol is a precise spec — so the agent has a clear, fixed target. Unlike a bespoke interface, a standard protocol has a published, exact specification. The agent's correctness is well-defined: fidelity to the spec. This makes a protocol agent buildable to a known standard — and certifiable.
• The agent encodes the compliance suite. The protocol's rules (handshake, ordering, response) become the agent's monitor checks — so the agent is the protocol's compliance test in executable form. A good protocol agent certifies a DUT is protocol-compliant, which is exactly what integration demands.
• Build-vs-buy is a real decision. Because protocol agents are so valuable and so reusable, VIP vendors sell them — a commercial AXI VIP is a major product. Teams buy proven protocol VIP rather than re-implement a subtle spec, because getting the protocol exactly right is hard and high-stakes.
• The protocol determines the agent's whole structure. You don't invent a protocol agent's transaction or timing — the spec dictates them. This makes the build disciplined (follow the spec) but demanding (the spec is large and subtle — AXI has five channels, burst types, ordering models).

The motivation, in one line: a standardized protocol is ubiquitous and has a precise spec, so a protocol agent that faithfully encodes it is correct for every DUT using the protocol and certifies compliance — making it the highest-leverage, highest-value reuse in verification, worth building (or buying) exactly right.

Mental Model

Hold the protocol agent as a certified expert in one protocol — the specification made executable:

A protocol agent is a certified expert in one protocol — the specification brought to life. It knows the protocol's vocabulary (the transaction), speaks it correctly (the driver), understands and judges it (the monitor and checks), and carries a repertoire of typical conversations (the sequences). Because the protocol is standard, this one expert is useful everywhere the protocol is spoken. Picture hiring a certified specialist in a widely-spoken language — say a certified AXI translator. Their expertise has four faculties, all derived from the language's specification. They know the vocabulary — the words and grammar (the transaction: address, data, burst, ID, response). They speak it fluently and correctly — producing well-formed utterances in real time (the driver: driving the channels with correct handshakes and framing). They understand and judge it — hearing what's said and catching any grammatical error (the monitor reconstructing transactions and checking the protocol's rules). And they carry a repertoire — typical conversations they can hold on demand (the sequences: standard reads, writes, bursts, ordering scenarios). Because the language is standardized — the same everywhere it's spoken — this one certified expert is useful at every place that uses it: every AXI interface, on every chip, in every project. You don't retrain them per setting — they're certified to the spec, and the spec is universal. And they come in roles: a speaker who initiates the conversation (a master agent, driving requests) and a listener-responder who answers (a slave agent, responding) — you bring the expert whose role complements the party you're testing. The value of the expert is exactly their fidelity to the specification — a fully certified expert catches every error and handles every scenario; a half-trained one misses things.

So the protocol agent is a certified expert in one protocol — the spec made executable: it knows the vocabulary (transaction), speaks it (driver), understands and judges it (monitor + checks), and holds typical conversations (sequences), all derived from the protocol's specification. Because the protocol is standard and universal, the one expert deploys everywhere it's spoken — and its value is its fidelity to the spec. Build (or hire) one certified expert; deploy across every interface that speaks the protocol.

Visual Explanation — the protocol shapes every component

The defining picture is derivation: the protocol specification determines the agent's transaction, driver, monitor, and sequences — every component is shaped by the spec.

The figure shows that every component of a protocol agent is derived from the specification. The protocol specification (the exact contract — for AXI, the published AMBA spec) defines the protocol's fields, signaling, rules, and operations, and from it flow the agent's four components. The transaction models the protocol's fields — for AXI: address, data, burst type/length/size, ID, response — the logical content of an operation. The driver implements the protocol's signaling and framing — AXI's channels, the per-channel valid/ready handshakes, burst sequencing — speaking the protocol on the pins. The monitor + checks reconstruct the protocol's transactions from the pins and check its rules — handshake legality, ordering, response matching (Module 13.3). The sequences generate the protocol's typical traffic — standard reads, writes, bursts, ordering scenarios. The crucial reading is that nothing in a protocol agent is invented — every component is derived from the spec (the warning-colored specification shapes every brand-colored component). This is why a protocol agent is correct for every DUT that obeys the same spec: the agent and the DUT are both implementing the same contract, so the agent fits any compliant DUT automatically. It's also why building one is disciplined but demanding: you don't choose the transaction fields or the driver's timing — the spec dictates them — so the build is a faithful encoding of a precise, often large document (AXI's five channels and burst model are substantial). The diagram is the protocol agent's origin: a specification, rendered into a transaction, driver, monitor, and sequences — the spec made executable, and correct by construction for every implementation of that spec.

RTL / Simulation Perspective — the protocol in the transaction and driver

In code, the protocol's fields appear in the transaction and its signaling in the driver. The code shows an AXI-style transaction and the driver framing it onto the protocol's channels.

// === TRANSACTION: the protocol's fields, exactly as the spec defines them (AXI write) ===
class axi_txn extends uvm_sequence_item;
  rand bit [31:0] addr;                    // AWADDR
  rand bit [7:0]  data[];                  // WDATA  (a burst: one beat per element)
  rand bit [7:0]  len;                     // AWLEN  (burst length - 1)
  rand bit [2:0]  size;                    // AWSIZE (bytes per beat)
  rand axi_burst_e burst;                  // AWBURST (FIXED / INCR / WRAP)
  rand bit [3:0]  id;                      // AWID   (transaction ID for ordering)
  axi_resp_e      resp;                    // BRESP  (OKAY / SLVERR / DECERR) — from the slave
  // the fields ARE the protocol's logical operation — dictated by the spec, not invented
endclass
 
// === DRIVER (master role): speak the protocol — address channel, then data burst ===
task axi_master_driver::drive(axi_txn t);
  // --- AW (address-write) channel handshake ---
  vif.awaddr <= t.addr;  vif.awlen <= t.len;  vif.awburst <= t.burst;  vif.awid <= t.id;
  vif.awvalid <= 1;  @(posedge vif.clk iff vif.awready);  vif.awvalid <= 0;   // valid/ready handshake
  // --- W (write-data) channel: drive each burst beat ---
  foreach (t.data[i]) begin
    vif.wdata <= t.data[i];  vif.wlast <= (i == t.len);                       // WLAST on final beat
    vif.wvalid <= 1;  @(posedge vif.clk iff vif.wready);  vif.wvalid <= 0;     // per-beat handshake
  end
  // --- B (write-response) channel: receive the slave's response ---
  @(posedge vif.clk iff vif.bvalid);  t.resp = axi_resp_e'(vif.bresp);  vif.bready <= 1;
endtask
// The MONITOR independently reconstructs this from the channels and CHECKS the spec's rules (13.3).

The code shows the protocol embodied in the transaction and driver. The transaction (axi_txn) has exactly the protocol's fields — addr (AWADDR), data[] (WDATA, a burst of beats), len/size/burst (AWLEN/AWSIZE/AWBURST — the burst descriptor), id (AWID — for ordering), and resp (BRESP — the slave's response). These fields are the protocol's logical operation — dictated by the spec, not invented (you don't get to choose AXI's fields; the spec defines them). The driver (master role) speaks the protocol: it drives the address-write channel (awaddr, etc., with the awvalid/awready handshake), then the write-data channel beat by beat (each wdata with wvalid/wready, asserting wlast on the final beat), then receives the write-response channel (bvalid/bready, capturing bresp). This is the protocol's signaling and framing — the channels, the per-channel handshakes, the burst sequencing — executed. The shape to carry: a protocol agent's transaction is the spec's fields and its driver is the spec's signaling — both are faithful encodings of the specification, not free design choices. The monitor (not shown) independently reconstructs this from the same channels and checks the spec's rules (Module 13.3). The protocol agent is the spec, in code: the fields, the channels, the handshakes, the burst model — all exactly as the protocol defines them, which is precisely what makes the agent fit any compliant AXI DUT.

Verification Perspective — master and slave roles

A protocol has roles — master (initiates) and slave (responds) — and a protocol agent is built per role. You use the agent whose role is the complement of the DUT's, so the agent plays the other side of the protocol.

The figure shows the role complementarity central to protocol agents. A protocol has two roles: a master initiates transactions (drives requests), and a slave responds (returns data and responses). A protocol agent is built per role — there's a master agent and a slave agent — and you use the one whose role is the complement of the DUT's. To verify a slave DUT (a design that responds), you use a master agent to drive requests into it — the agent initiates, the DUT responds. To verify a master DUT (a design that initiates), you use a slave agent to respond to it — the DUT initiates, the agent responds. The verification insight is that the agent plays the other side of the protocol from the DUT, so together they form a complete, legal protocol conversation: one initiates, the other responds, exactly as the protocol requires a pair of participants. This is why the role matters: a protocol is a two-party contract, and the testbench must supply the party the DUT isn't. Pick the wrong role — a master agent against a master DUT — and you have two initiators and no responder: the DUT's requests get no response, and it hangs (the DebugLab). Pick the right (complementary) role and the conversation completes. A mature protocol VIP ships both a master and a slave agent (and often a monitor-only passive agent for internal interfaces, Module 14.3), so a consumer can play either side — driving a DUT that responds, or responding to a DUT that drives. The figure is the role discipline: a protocol agent is role-specific, and correct use means matching the testbench's role to the complement of the DUT's — so the agent and DUT together hold a complete protocol conversation.

Runtime / Execution Flow — building a protocol agent from the spec

Building a protocol agent is a disciplined encoding of the specification: model the fields, implement the signaling, encode the rules and traffic, package as a VIP. The flow shows the build.

The flow is the protocol agent's build as a translation of the spec. Model the fields (step 1): the spec's logical operation becomes the transaction's fields — address, data, burst descriptor, ID, response (Module 9's transaction modeling, now spec-driven). Implement the signaling (step 2): the spec's channels, handshakes, and framing become the driver (built per role — master or slave) and the monitor's reconstruction (Module 13.2). Encode the rules (step 3): the spec's handshake, ordering, and response rules become the monitor's protocol checks — this is the compliance suite (Module 13.3), the agent's crown jewel. Build traffic + package (step 4): the spec's typical operations become the sequence library, and the whole travels as a VIP (Module 14.4). The runtime insight is that every step is a faithful translation of part of the spec into the agent — the agent is the specification, re-expressed as a transaction, driver, monitor, checks, and sequences. This makes the agent's correctness a single, well-defined property: fidelity to the specification at every step. A field the transaction omits, a handshake the driver gets wrong, a rule the checks don't encode, a scenario the sequences can't generate — each is a gap between the agent and the spec, and each is a defect in the protocol agent (an incompletely encoded spec — missing compliance coverage). This is why a protocol agent's value is its spec fidelity: a fully faithful agent handles every scenario and catches every violation (a complete compliance suite); a partial one leaves protocol corners untested and violations uncaught. The flow is the discipline that produces a high-value protocol agent: encode the spec completely and faithfully — every field, every channel, every rule, every typical operation — because the agent is the spec, and its worth is how completely and correctly it embodies it.

Waveform Perspective — the protocol's signaling on the pins

A protocol agent's defining behavior is the protocol's actual signaling — for AXI, the channel handshakes and burst framing. The waveform shows an AXI-style write: the address handshake, then a data burst with wlast, then the response.

The waveform shows the protocol agent speaking the AXI specification's signaling. On the address-write (AW) channel, awvalid asserts and the slave returns awready — the handshake that accepts the address. On the write-data (W) channel, the master drives a two-beat burst: wvalid with each beat (wdata = D0 then D1), wready accepting each, and wlast asserted on the final beat (marking the burst's end). On the write-response (B) channel, the slave returns bvalid with the response (bresp = OKAY). The crucial reading is that this exact signaling — per-channel valid/ready handshaking, burst framing with wlast, the separate channels for address, data, and response — is the AXI specification. The protocol agent's driver produces it (a master agent driving these channels) and its monitor checks it (verifying each handshake is legal, the burst is well-formed, the response matches) — exactly as the spec defines. The picture to carry is that a protocol agent's waveform is the protocol itself on the pins: recognizable, standard signaling that anyone who knows AXI can read — the channels, the handshakes, the burst, the response. This is why the agent is reusable: it produces and checks the standard signaling that every AXI DUT also speaks. Reading a protocol agent's waveform — are the channel handshakes legal? is the burst framed correctly with wlast? does the response come back? — is reading the protocol, and a correct protocol agent makes the spec's signaling appear faithfully on the interface, every time.

DebugLab — the DUT that hung because of a wrong-role agent

✗ MASTER agent on a MASTER DUT's interface → two initiators, no responder → hang:
  // DUT (master) asserts awvalid, waits for awready + bvalid
  // agent is ALSO a master → it also wants to initiate; it does NOT drive awready or respond
  // → nothing returns awready / bvalid → DUT stalls forever → test timeout
 
✓ SLAVE agent on a MASTER DUT's interface → the agent responds → conversation completes:
  // agent is a SLAVE → it drives awready, accepts the write, returns bvalid/bresp
  // DUT (master) gets its handshake and response → transaction completes → no hang

Common Mistakes

• Using the wrong-role agent. Match the testbench's role to the complement of the DUT's — a slave agent for a master DUT, a master agent for a slave DUT; the same role on both sides hangs.
• Incompletely encoding the spec. A protocol agent's value is its fidelity to the spec; a missing field, handshake, rule, or burst type leaves scenarios untested and violations uncaught.
• Inventing the transaction or timing. A protocol agent's fields and signaling are dictated by the spec, not chosen; deviating from the spec breaks compatibility with compliant DUTs.
• Skipping the protocol checks. The monitor's protocol checks are the agent's compliance suite; an agent without them drives and reconstructs but certifies nothing.
• Re-implementing a standard protocol from scratch. Getting a subtle spec exactly right is hard; a proven VIP (built or bought) is usually the right choice for a standard protocol.
• Hardcoding protocol parameters. Width, ID size, and burst limits should be config knobs so the one agent serves every variant of the protocol (Module 14.4).

Senior Design Review Notes

Interview Insights

Exercises

1. Derive the components. For a protocol you know, name what its spec dictates for the agent's transaction, driver, monitor checks, and sequences.
2. Choose the role. A DUT is an AXI memory controller (it responds to reads/writes). State which agent role you use and why.
3. Diagnose the hang. A master DUT asserts a request and waits forever. Name the likely role mismatch and the fix.
4. Audit fidelity. List three gaps between a protocol agent and its spec that would reduce the agent's value, and what each leaves untested.

Summary

• A protocol agent is an agent built for a specific standardized protocol (AXI, APB, …) — it encodes the protocol specification as a reusable verification component, correct by construction for every DUT that obeys the same spec.
• The protocol shapes every component: the transaction models its fields, the driver drives its signaling and framing, the monitor reconstructs its transactions and checks its rules, and the sequences generate its typical traffic — nothing is invented; all is derived from the spec.
• It is built per role — a master agent (initiates) and a slave agent (responds) — and you use the agent whose role is the complement of the DUT's, so the agent and DUT together form a complete protocol conversation.
• Its protocol checking is the crown jewel — the agent is the protocol's compliance suite in executable form — and its value is its fidelity to the spec: an incompletely encoded spec leaves scenarios untested and violations uncaught.
• The durable rule of thumb: build (or buy) a protocol agent as a faithful, complete encoding of the protocol spec — its fields, signaling, rules, and traffic — and use the role that complements the DUT's (a slave agent for a master DUT, a master agent for a slave DUT); a standard protocol's ubiquity makes this the highest-leverage reuse there is, so its value is exactly how completely and correctly it embodies the specification.

Next — Agent Configuration: the module closes with the knobs that make one agent serve every use — how an agent's config object carries is_active, the virtual interface, and protocol parameters, how the environment sets it per instance, and the configuration patterns that turn a single agent class into a flexible, reusable component.