Adapter Configuration: supports_byte_enable & provides_responses

Two knobs that decide many failures

Most adapter behavior confusion comes from two fields in uvm_reg_adapter: supports_byte_enable and provides_responses. Configure them to match your bus agent reality, not wishful assumptions.

[RAL] adapter configuration impact

  supports_byte_enable:
    tells RAL whether lane masks are meaningful on this bus path

  provides_responses:
    tells RAL whether driver/sequence returns explicit response items

  Wrong settings =>
    narrow-write bugs, read-data drop, status confusion

• Set knobs in adapter constructor once; document rationale near assignment.

• Align adapter settings with driver and monitor implementation behavior.

• Validate both knobs with smoke sequences before full regressions.

supports_byte_enable deep dive

When supports_byte_enable = 1, RAL expects meaningful lane masks for partial-width accesses. If your protocol or item has no lane concept, set it to 0 and ensure map width aligns with full-word writes.

function new(string name = "apb_reg_adapter");
  super.new(name);
  supports_byte_enable = 1;
  provides_responses   = 0;
endfunction

virtual function uvm_sequence_item reg2bus(const ref uvm_reg_bus_op rw);
  apb_item tr = apb_item::type_id::create("tr");
  tr.addr  = rw.addr;
  tr.write = (rw.kind == UVM_WRITE);
  tr.wdata = rw.data;

  if (supports_byte_enable)
    tr.strb = rw.byte_en[3:0];
  else
    tr.strb = 4'hF;

  return tr;
endfunction

[BUS] narrow write example

  intent:
    write 0xAB to byte lane[1] at addr 0x1000

  expected:
    byte_en = 0b0010
    wdata   = 0x0000AB00

  if supports_byte_enable wrongly set to 0:
    full-word overwrite risk

[RAL] [BUS] byte-enable policy choices

  Protocol has strobes:
    supports_byte_enable = 1
    map rw.byte_en <-> item strobes

  Protocol has no strobes:
    supports_byte_enable = 0
    enforce full-width access rules

• Mismatch between knob and actual strobe behavior causes silent data corruption.

• For wide buses, validate lane ordering and endianness with directed tests.

• Partial updates should be checked with readback and mirror consistency.

provides_responses and read completion

Set provides_responses = 1 only when your driver/sequencer returns response items through the sequence response path. If not, leave it 0 and rely on monitor+predictor for observed data flow.

class axi_reg_adapter extends uvm_reg_adapter;
  `uvm_object_utils(axi_reg_adapter)
  function new(string name = "axi_reg_adapter");
    super.new(name);
    supports_byte_enable = 1;
    provides_responses   = 1; // driver calls item_done(rsp)
  endfunction
endclass

// Driver sketch when provides_responses=1
task axi_driver::run_phase(uvm_phase phase);
  axi_item req, rsp;
  forever begin
    seq_item_port.get_next_item(req);
    drive_request(req);
    rsp = req.clone();
    rsp.set_id_info(req);
    rsp.rdata = sampled_rdata;
    rsp.resp_ok = sampled_ok;
    seq_item_port.item_done(rsp);
  end
endtask

[UVM] response model choices

  Mode A: provides_responses = 0
    - no explicit seq rsp item
    - monitor + predictor carry readback truth

  Mode B: provides_responses = 1
    - driver emits response item
    - adapter/predictor still should align on data/status

Configuration smoke checklist

1. Write/read one full-width register and check status/data.

2. Run one narrow write and verify untouched lanes remain stable.

3. Inject one bus error and verify rw.status reports NOT_OK.

4. Confirm mirror convergence with predictor enabled.

5. Run built-in sequences to expose corner mismatches quickly.

Key takeaways

• supports_byte_enable controls correctness of narrow and lane-masked accesses.

• provides_responses must match real sequence response behavior in the driver.

• Wrong adapter knobs create deterministic but misleading failures.

• Validate configuration with targeted smoke checks before random regressions.

Common pitfalls

• Setting provides_responses=1 without actually returning response items.

• Hard-wiring full strobes while advertising byte-enable support.

• Changing adapter knobs between tests without central configuration ownership.

• Debugging scoreboard mismatches before validating adapter configuration basics.