Field Side Effects

Chapter 1 · Section 1.7 · Register Specification & CSR Thinking

1. Why Should I Learn This?

Side effects are the difference between modelling a register and modelling a design. A field's access policy tells you what happens to that field on a read or write; a side effect tells you what happens to everything else. Miss one and you get the most disorienting kind of RAL failure: the register you accessed checks out perfectly, but a different register — one your access silently changed — now mismatches, or worse, quietly holds a wrong value that no test is watching. And on the DUT side, a side effect you did not know about is a landmine: a debug tool that reads a FIFO register pops real data; a sequence that writes a whole register trips a start bit it did not mean to.

Learning to see side effects — and to classify which ones RAL handles for free versus which you must model — lets you keep the whole mirror honest, not just the addressed field, and to reason about the cross-register and external consequences that make register verification a system problem rather than a per-cell one. It is the idea that connects a register map to the behaviour behind it.

2. Industry Story — the debug dump that ate the packets

A network block exposes an RX_DATA register: reading it returns the next word from the receive FIFO and pops the FIFO, and a separate RX_LEVEL register reports how many words remain. This is correct, ordinary hardware. The verification engineer models RX_DATA and RX_LEVEL accurately.

Then, for observability, someone adds a periodic 'register health dump' that reads every register and logs it — including a plain read of RX_DATA. Now every dump pops a word off the receive FIFO and throws it in a log, so the design under test loses one received word per dump, RX_LEVEL decrements out from under the test that was tracking it, and packet-integrity checks fail intermittently in a way that moves with the dump timing. The RTL is flawless; the bug is that a read of RX_DATA is not an observation, it is a destructive operation with cross-register consequences, and a tool that treated it as a harmless peek corrupted both the data stream and the model's picture of RX_LEVEL. The post-mortem rule the team adopts: an access with a side effect changes state beyond the field it names — enumerate those effects, model them, and never let a 'harmless' read or a 'full-word' write trigger one by accident.

3. Concept — a taxonomy of side effects

Side effects form a ladder, from the ones RAL handles for you to the ones you must model:

• Intra-field. The access changes only the addressed field, by its policy: W1C clears the bit you write, RC clears the field you read. RAL already handles these — they are the access policy from 1.5, and the mirror predicts them from the policy alone.
• Cross-field (within the register). The access changes other fields of the same register: writing a lock bit makes the register's config fields read-only; writing a mode field forces a companion field to a default. RAL does not infer these from policy — you model them (callbacks, or a field-access predictor).
• Cross-register. The access changes a different register: a write to CTRL.clear_all clears every bit of INT_STATUS; a read of RX_DATA pops the FIFO and so decrements RX_LEVEL and may set RX_EMPTY. These are the dangerous ones for the mirror, because the affected register's mirror drifts unless the model predicts the effect.
• External (beyond the register file). The access changes the outside world: writing CTRL.start launches a job; a W1C clear of the last pending interrupt de-asserts the IRQ line to the CPU. These are not mirror state, but they are real behaviour a test must verify.

The rule for RAL is: it knows the intra-field effects from the policy; every effect that reaches another field, another register, or the outside world must be modelled — through a predictor watching the bus (Chapter 6) or callbacks on the register (Chapter 9) — or the mirror of the affected register goes stale. Here is one cross-register side effect as a flow:

4. Mental Model — an access is a transaction with consequences

5. Working Example — modelling a cross-register side effect

RAL's cleanest way to keep an affected register honest is a predictor that watches the bus and updates every register from observed activity (Chapter 6) — a passive predictor sees the FIFO read and, given a model of the effect, updates RX_LEVEL. Where the effect is not observable from the bus alone, a callback on the triggering register fires and predicts the affected one. The shape of a callback that models a cross-register effect:

// A callback on RX_DATA that models the pop's effect on RX_LEVEL.
// (Callbacks are Chapter 9; shown here so the mechanism is concrete.)
class rx_data_cb extends uvm_reg_cbs;
  rx_level_reg level_h;   // handle to the affected register's model

  virtual task post_read(uvm_reg_item rw);
    // A read popped the FIFO, so the modelled level is one lower. Predict it
    // on the AFFECTED register so its mirror tracks the side effect.
    if (level_h.count.get() > 0)
      void'(level_h.count.predict(level_h.count.get() - 1));
  endtask
endclass

// Register the callback so every RX_DATA read updates RX_LEVEL's mirror.
rx_data_cb cb = new();
cb.level_h = reg_model.rx_level;
uvm_reg_field_cb::add(reg_model.rx_data.data, cb);

// Now a read of RX_DATA keeps BOTH mirrors honest:
reg_model.rx_data.read(s, got);        // pops the FIFO; callback predicts RX_LEVEL--
if (reg_model.rx_level.count.get() != expected_level)
  `uvm_error("SFX", "RX_LEVEL mirror did not track the FIFO pop")

The key move is predict() on the affected register — the side effect is modelled by updating the mirror of the register the access changed, not the one it addressed. Without it, RX_LEVEL reads correctly only until the first RX_DATA read, then drifts by one per pop.

6. Debugging Session — the stray read that drained a FIFO

// RX_DATA read pops the FIFO (cross-register effect on RX_LEVEL / RX_EMPTY).
// A register-health dump reads EVERY register with a plain frontdoor read:
foreach (all_regs[i]) all_regs[i].read(s, tmp);   // includes RX_DATA -> POPS the FIFO
// Consequences:
//   (a) the DUT loses a received word to the log every dump,
//   (b) RX_LEVEL in the DUT decrements, but the model never predicted it,
//   (c) the test tracking RX_LEVEL now sees a value it cannot explain.

7. Common Mistakes

• Treating every read as an observation. A read of a FIFO/RC register is an operation with consequences; a plain read from debug or passive code triggers them.
• Writing whole registers instead of read-modify-write. A full-word write can trip a start or clear bit you did not mean to set, causing an unrelated side effect.
• Modelling only the addressed register. A cross-register side effect drifts the affected register's mirror; you must predict() it there.
• Forgetting external effects in the test plan. A start write launching a job or a clear de-asserting an IRQ is real behaviour that needs its own check, not just a mirror update.
• Assuming the access policy captures side effects. Policy covers intra-field only; cross-field, cross-register, and external effects are separate and must be modelled.

8. Industry Best Practices

• Enumerate side effects per register in the plan. For each register, list what an access changes elsewhere — the list drives both callbacks and checks.
• Use a predictor to absorb observable side effects. A passive predictor watching the bus keeps affected registers honest for the effects that are visible in traffic (Chapter 6).
• Use callbacks for effects that are not bus-observable. A pre/post callback on the triggering register predicts the affected one (Chapter 9).
• Never frontdoor-read a side-effecting register for observability. Backdoor peek for debug dumps and passive checks; reserve the frontdoor read for the one intended consumer.
• Verify external effects explicitly. A start that launches work or a clear that drops an IRQ needs a functional check, not just a mirror update.

9. Interview / Review Questions

10. Key Takeaways

• A register access can reach beyond the field it names: intra-field (policy), cross-field, cross-register, and external side effects.
• RAL handles intra-field effects from the access policy; everything beyond that you must model — with a predictor watching the bus or callbacks on the triggering register.
• A cross-register side effect drifts the affected register's mirror even when both registers are modelled perfectly in isolation — you must predict() the effect on the register it reaches.
• Some reads are destructive (FIFO pop, RC clear); never frontdoor-read a side-effecting register for observability — use backdoor peek.
• External effects (a start launching work, a clear dropping an IRQ) are real behaviour that needs its own functional check, not just a mirror update.