A processor reads a register in a peripheral. While the read is in flight, a watchdog resets the peripheral. The peripheral comes back clean, with no memory of the read. The processor is still waiting for its answer, and nothing in the system will ever send it. A reset is supposed to make things safe; on one side of an interface it made the other side hang.

What must an interface guarantee during and after reset, and what happens to transactions caught by one?

The obvious answer, and why it breaks

The obvious view is that reset returns a block to a known state, so it is always safe. For the block itself, it is. But an interface has two sides, and a reset usually reaches only one. Whatever the reset side "forgets" (outstanding requests, credits it owed, data half-sent), the other side still remembers and is still waiting for. Reset semantics are about the boundary, not the block.

The idea: rules for both sides

Build it: a read caught by a reset

The requester issues a read in cycle 1. The target would answer four cycles later, but it is reset in cycle 3 and forgets the read. The requester has a 6-cycle completion timeout.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

// A read caught by a reset. The requester issues a read in cycle 1; the target
// would answer 4 cycles later, but the target is reset in cycle 3 and forgets the
// read. The requester has a completion timeout of 6 cycles: when no response has
// arrived it completes the read with an error, so it does not wait for ever. The
// checker confirms no stale response ever arrives after the reset, and that the
// timeout turned the lost read into an error.
module tb;
  logic clk = 0;
  always #5 clk = ~clk;
  initial begin $dumpfile("wave.vcd"); $dumpvars(0, tb); end

  int cyc = 0;
  always @(posedge clk) cyc <= cyc + 1;

  wire  req   = (cyc == 1);                       // the requester's read
  wire  rst_t = (cyc == 3);                       // target reset pulse
  // Target: remembers a pending read and answers 4 cycles after it arrived
  logic       pending = 0;
  logic [2:0] age = 0;
  logic       rsp = 0;
  always @(posedge clk) begin
    rsp <= 0;
    if (rst_t) begin pending <= 0; age <= 0; end  // reset: the read is forgotten
    else if (req) begin pending <= 1; age <= 0; end
    else if (pending) begin
      age <= age + 1;
      if (age == 3) begin rsp <= 1; pending <= 0; end
    end
  end
  // Requester: waits for the response, with a 6-cycle completion timeout
  logic       waiting = 0, timeout_err = 0;
  logic [3:0] wait_cnt = 0;
  always @(posedge clk) begin
    timeout_err <= 0;
    if (req) begin waiting <= 1; wait_cnt <= 0; end
    else if (waiting) begin
      if (rsp) waiting <= 0;
      else if (wait_cnt == 5) begin waiting <= 0; timeout_err <= 1; end
      else wait_cnt <= wait_cnt + 1;
    end
  end

  int responses = 0, errors_seen = 0;
  always @(posedge clk) begin
    if (rsp) responses++;
    if (timeout_err) errors_seen++;
  end
  initial begin
    #160;
    if (responses == 0 && errors_seen == 1) $display("PASS: the reset dropped the read; the requester's timeout completed it with an error instead of hanging");
    else $display("FAIL: responses %0d timeout errors %0d", responses, errors_seen);
    $finish;
  end
endmodule

The target's reset branch clears pending: the read simply ceases to exist on that side. Only the requester's timer turns that into something software can see.

Watch it run

How to read it, slot by slot:

• Slot 0: the read goes out (req); from slot 1 the target holds it (pending) and the requester is waiting (waiting).

• Slot 2: the target is reset (rst_t). In slot 3 pending is 0: the read is gone.

• Slots 3 to 6: nothing happens. rsp never rises. Without a timeout, waiting would stay high for ever.

• Slot 7: the timeout fires (timeout_err); the requester completes the read with an error and stops waiting.

Ways to handle a one-sided reset

How real protocols chose

What breaks

The opening system (illustrative) reset a peripheral from a watchdog without telling the interconnect. The processor's read hung, the core stopped, and a second watchdog reset the whole chip. Adding a reset-aware wrapper that answered any request to the peripheral with an error while it was resetting kept the processor alive; the driver saw the error and re-initialised the peripheral.

Key takeaways

• Reset clears one side's state; the other side still remembers outstanding requests, credits and tags.

• During reset, drive interfaces inactive; start traffic only when both sides are out of reset and initialised.

• Handle one-sided resets with timeouts, reset-aware wrappers, quiescing, or joint resets.

Related topics

• Part 11 overview: Bring-Up and Link Management