USB Reset

Chapter 6.1 left the host with a port, something stably attached, and a known operating mode. What it does not have is any guarantee about the state that device is in.

It may have just been plugged in. It may have sat through a previous host's abandoned enumeration. It may be part-way through answering a request nobody is listening for. The host cannot ask, because asking requires the device to be in a state where it answers — which is exactly what is in question.

Reset breaks that circularity, and this chapter is about what it establishes.

1. An Assertion, Not a Question

The host's problem is epistemic. It needs the device to be in a known state and has no way to find out what state it is in.

Reset is the host asserting a state rather than discovering one. It does not ask the device to report; it drives a condition the device is obliged to recognise, and the device's obligation is to arrive at a defined state regardless of what it was doing before.

That framing explains reset's two essential properties.

It must be unmistakable. A device might be in any condition, including confused, so the signal that resets it cannot depend on the device interpreting anything subtle. Chapter 3.7 showed why an extended SE0 is the right choice: it is recognisable with nothing more than line-state machinery, requires no agreement about encoding, and cannot be confused with data because it is outside the signalling alphabet.

It must be unconditional. A device may not decline. There is no negotiation, no acknowledgement, and no way for a device to indicate it would rather not — because a device that could refuse could also be broken in a way that makes it refuse.

2. What Reset Establishes

After a successful reset the device is in its Default state, and that name is precise: it is the state in which the device's protocol-visible properties are at their defined starting values.

Three of those matter for enumeration.

The device responds at the default address. It has no assigned address — Chapter 6.3 is entirely about why that is necessary and how it is resolved.

Its control path is available. The device is reachable, which is what makes the first request possible. That path is endpoint zero, and Module 9 owns endpoints; what matters here is that it exists before configuration, because otherwise there would be no way to configure anything.

It is not configured. Whatever configuration may previously have been selected is gone, and the device offers no functional interfaces until Chapter 6.5 selects one.

Module 8 owns the complete state model, including states this chapter does not need. What enumeration requires is the progression Default → Address → Configured, and reset is what guarantees the first of those.

Read the two curved edges as the chapter's point. Reset reaches Default from everywhere, and it is the only edge in the diagram that does.

3. What Must Be Discarded — and What Must Not

Now the part with direct RTL consequences, and where Chapter 4.5 §4's state-lifetime rule applies with full force.

Protocol-visible state must be discarded. The assigned address returns to the default. Any selected configuration is gone. Per-endpoint protocol condition returns to its defined starting value. These are the things the host and device must agree about, and the whole purpose of reset is to force that agreement by resetting both sides' view to a known one.

Implementation state need not be, and often should not be. A buffer's contents, a clock's lock status, the device's own internal initialisation, firmware's data structures — none of that is protocol-visible, and discarding it is at best wasteful and at worst harmful. A device that reinitialised its entire subsystem on every bus reset would be slow to re-enumerate and might lose work it did not need to.

The boundary between those two categories is a design decision with consequences, and it is exactly Chapter 2.2 §6's distinction arriving at its most concrete. Getting it wrong in either direction produces a real bug: discard too little and the host and device disagree about the device's identity; discard too much and the device is needlessly slow or loses state it owned.

4. Bus Reset Is Not RTL Reset

Chapter 3.7 §6 raised this and it deserves restating here, because this is the chapter where the temptation is strongest.

A hardware reset is an electrical control input from the surrounding system. It returns logic to a known state and is not a protocol concept.

A bus reset is a protocol event — a condition on the wires that the device detects, and which obliges it to place its protocol-visible state at defined values.

The tempting and wrong implementation is to wire the detected bus reset into the controller's hardware reset. It is wrong for three compounding reasons.

It resets the detector. The logic that observed the reset is itself reset, so the observation is destroyed in the act of being made — Chapter 3.7's argument.

It clears too much. §3 established that implementation state should generally survive. A hardware reset does not distinguish; it clears everything.

And it discards the distinction software depends on. Firmware may legitimately need to know that a bus reset occurred — to abandon in-flight work, to re-arm, to log it. A device whose logic was simply reset cannot report anything, because the reporting machinery was reset too.

The correct structure is that a bus reset is detected, reported, and acted upon by logic that is itself outside the scope of what it clears. That is the same rule Chapter 2.4 §3 established for event paths, and it is why §5's RTL keeps the two resets on separate ports.

5. Reset-Driven State Clearing, as RTL

// ─────────────────────────────────────────────────────────────────────────
// usb_reset_scope
//
// Classification: SIMPLIFIED SYNTHESIZABLE TEACHING RTL. It models the
// SCOPE of a bus reset -- which state it clears and which it must not --
// and no USB mechanism beyond that.
//
// WHAT IT MODELS. Section 3's division: protocol-visible state returns to
// defined values on a bus reset, while implementation state survives. It
// also models section 4's separation, keeping the local hardware reset and
// the protocol bus reset as DIFFERENT inputs with different scopes.
//
// WHAT IT DOES NOT MODEL. Bus-reset detection (Chapter 3.7 owns it -- the
// input here is an already-decoded, already-synchronised indication), the
// complete device-state machine (Module 8), addressing (Chapter 6.3),
// configuration (Chapter 6.5), endpoints, control transfers or packets.
// ─────────────────────────────────────────────────────────────────────────
package usb_enum_pkg;
  typedef enum logic [1:0] {
    DEV_POWERED    = 2'b00,   // attached, no reset seen yet
    DEV_DEFAULT    = 2'b01,   // reset complete -- responds at address 0
    DEV_ADDRESS    = 2'b10,   // has an assigned address (Chapter 6.3)
    DEV_CONFIGURED = 2'b11    // a configuration is selected (Chapter 6.5)
  } usb_dev_state_e;

  localparam logic [6:0] USB_DEFAULT_ADDR = 7'd0;
endpackage

module usb_reset_scope
  import usb_enum_pkg::*;
(
  input  logic       clk,
  // LOCAL hardware reset -- an electrical condition from this chip's system.
  // NOT the protocol event. See section 4.
  input  logic       rst_n,

  // PROTOCOL bus reset: an already-decoded, already-synchronised indication
  // that the bus reset condition was observed. A LEVEL while asserted.
  input  logic       bus_reset,

  // Enumeration progress events (owned by Chapters 6.3 and 6.5).
  input  logic       addr_committed,
  input  logic [6:0] addr_value,
  input  logic       config_selected,
  input  logic [7:0] config_value,

  // Protocol-visible state -- CLEARED by bus reset.
  output usb_dev_state_e dev_state,
  output logic [6:0]     active_addr,
  output logic [7:0]     active_config,

  // Reported to firmware, and deliberately NOT cleared by bus_reset itself,
  // so firmware can learn that a reset happened. Cleared by firmware.
  output logic           bus_reset_event,
  input  logic           bus_reset_event_clear
);

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      // Local hardware reset: everything, including the report.
      dev_state       <= DEV_POWERED;
      active_addr     <= USB_DEFAULT_ADDR;
      active_config   <= 8'd0;
      bus_reset_event <= 1'b0;
    end else begin
      // ── Protocol-visible state: cleared by the PROTOCOL event ──────────
      if (bus_reset) begin
        dev_state     <= DEV_DEFAULT;
        active_addr   <= USB_DEFAULT_ADDR;
        active_config <= 8'd0;
      end else begin
        if (addr_committed) begin
          active_addr <= addr_value;
          dev_state   <= DEV_ADDRESS;
        end
        if (config_selected) begin
          active_config <= config_value;
          // A configuration value of zero returns the device to Address --
          // selecting "no configuration" is a legal action, not a failure.
          // Written as if/else rather than a ternary: a conditional between
          // two enum literals is not directly assignable to an enum without
          // an explicit cast, and the cast obscures the intent.
          if (config_value == 8'd0) dev_state <= DEV_ADDRESS;
          else                      dev_state <= DEV_CONFIGURED;
        end
      end

      // ── The report: set by the reset, cleared only by firmware ─────────
      // Set beats clear, for Chapter 2.4's reason: a reset arriving in the
      // same cycle firmware acknowledges the previous one must survive.
      if (bus_reset)                   bus_reset_event <= 1'b1;
      else if (bus_reset_event_clear)  bus_reset_event <= 1'b0;
    end
  end

endmodule

What it models. The scope of a bus reset: which state it clears, which it leaves, and the report that lets firmware know it happened.

Why this hardware exists. Because the host and device must agree about the device's protocol identity, and reset is how that agreement is forced. The register set above is the agreement.

Inputs. A local hardware reset; a decoded, synchronised bus-reset indication; and the two enumeration events that advance state.

State retained. Protocol state, active address, active configuration, and the firmware-facing reset report.

Outputs. The protocol-visible state, plus an event firmware polls or is interrupted by.

Reset behaviour. The two resets have different scopes, which is the block's whole point. rst_n clears everything including the report. bus_reset clears protocol-visible state and sets the report — it does not clear it, because a report destroyed by the event it reports is useless.

Hardware implied. A small state register, an address register, a configuration register, and one sticky event flag.

Assumptions. That bus_reset is decoded and synchronised upstream; that addr_committed and config_selected are single-cycle qualified events from the chapters that own them; and that implementation state lives elsewhere and is deliberately not in this block's scope.

Deliberately omits. Reset detection, the full state machine, addressing and configuration mechanics, endpoints, control transfers and packets.

What DV should verify. That a bus reset from every state reaches Default; that address and configuration are cleared by it; that the event is set by reset and cleared only by firmware; that a reset coinciding with a firmware clear still leaves the event set; and that the local reset clears the event while a bus reset does not.

6. The Assertions

// ─────────────────────────────────────────────────────────────────────────
// Assertions for usb_reset_scope.
//
// Classification: TEACHING ASSERTIONS about reset SCOPE in this model. They
// verify the block's contract, not USB compliance.
// ─────────────────────────────────────────────────────────────────────────

// R1 -- THE CENTRAL ONE. A bus reset returns the device to Default from any
// state. Catches a controller that clears its state machine conditionally,
// or that treats reset as a request rather than an obligation.
property p_reset_reaches_default;
  @(posedge clk) disable iff (!rst_n)
    bus_reset |=> (dev_state == DEV_DEFAULT);
endproperty
assert property (p_reset_reaches_default);

// R2 -- the address goes with it. Catches the classic bug of section 7: a
// state machine that resets while the address register does not, leaving
// the device internally Default while still answering to a stale address.
property p_reset_clears_address;
  @(posedge clk) disable iff (!rst_n)
    bus_reset |=> (active_addr == USB_DEFAULT_ADDR);
endproperty
assert property (p_reset_clears_address);

// R3 -- so does the configuration. A device that believes it is still
// configured after a reset will offer interfaces the host has forgotten.
property p_reset_clears_config;
  @(posedge clk) disable iff (!rst_n)
    bus_reset |=> (active_config == 8'd0);
endproperty
assert property (p_reset_clears_config);

// R4 -- THE ONE TEAMS FORGET. The reset must not destroy its own report.
// A bus reset sets the event, and only firmware clears it -- so a reset
// coinciding with a firmware acknowledgement still leaves it set.
property p_reset_event_survives_clear;
  @(posedge clk) disable iff (!rst_n)
    bus_reset |=> bus_reset_event;
endproperty
assert property (p_reset_event_survives_clear);

// R5 -- state cannot advance while reset is asserted. Catches an
// enumeration event being honoured during a reset, which would let the
// device leave Default without the host having done anything.
property p_no_advance_during_reset;
  @(posedge clk) disable iff (!rst_n)
    bus_reset |=> (dev_state != DEV_ADDRESS && dev_state != DEV_CONFIGURED);
endproperty
assert property (p_no_advance_during_reset);

R2 is the one that earns its place. The failure it catches — a state machine that resets while an address register does not — produces a device that is internally in Default and externally still answering to an address the host has discarded. Both sides behave consistently with their own view, and they disagree. §7 traces it.

R4 protects the §4 argument in executable form: the report must outlive the event that created it.

7. The Bug: Reset Clears the FSM but Not the Address

A device enumerates successfully. The host resets the port again — during error recovery, or because software re-enumerated. From then on the device is unreachable, and the host's attempts at the default address get no answer.

What happened? The device's state machine returned to Default, so it believes it has no address. Its address register was not cleared, so its bus-facing comparison still matches the previously assigned address. The device therefore ignores traffic sent to the default address — which is all the host is sending, because as far as the host is concerned this is a freshly reset device with no address.

Why is it so confusing? Because both sides are behaving consistently with their own state, and neither reports an error. The host addresses a device that does not answer; the device sees no traffic addressed to it and correctly stays silent. Nothing is malformed, nothing times out at the protocol layer in an informative way, and no error bit is set anywhere.

Why does it pass testing? Because the first enumeration works perfectly. A test that attaches a device and enumerates once never exercises reset-after-address, which is the only path where the bug exists.

What is the debugging signature? Works the first time, fails on re-enumeration. That pattern — first attempt succeeds, subsequent attempts fail — is close to diagnostic for state that survived a reset it should not have.

What catches it? R2 in simulation, and the churn stimulus of §8 in an environment.

8. Verification

This chapter's commit point is device in Default, and it is the second in the module's chain after Chapter 6.1's attachment believed.

Stimulus must include reset from every state. Reset from Powered, from Default, from Address, and from Configured are four different paths through the logic, and only the first is exercised by a simple attach-and-enumerate test.

The high-value pattern is churn, exactly as Chapter 4.5 §7 argued: enumerate, reset, enumerate again; reset mid-sequence; reset immediately after an address is committed. That is where §7's bug lives and where an environment that reaches a working configuration and stays there finds nothing.

Representative coverage — crosses, not margins:

• bus reset × each protocol state, including reset during a state transition
• bus reset coinciding with firmware's event acknowledgement — R4's case
• local hardware reset × bus reset, asserted separately and together
• reset followed by re-enumeration, verifying the device answers at the default address again

Negative cases with defined outcomes: an enumeration event arriving while reset is asserted, which must not advance state (R5); and firmware clearing the event before reading it, which must not lose a subsequent reset.

And the reference model is small, which is why this is a good place to start one: expected protocol state, expected active address, expected configuration. Chapter 6.6 grows it into the full enumeration model.

9. Common Misconceptions

10. Reason It Through

A device enumerates and works. After a host-initiated re-enumeration it becomes unreachable. Power-cycling the device fixes it. A bus trace shows the host addressing the default address and receiving no response.

What does power-cycling fixing it tell you? That the problem is state inside the device that survived a bus reset but not a power cycle. That single observation narrows the field enormously: a hardware reset clears it, a protocol reset does not, so it is state the protocol reset failed to include in its scope.

What does the trace tell you? That the host is behaving correctly for a freshly reset device — it is using the default address, which is exactly right — and that the device is not answering.

What state, if stale, would produce exactly this? The active address. If it still holds the previously assigned value, the device's address comparison rejects traffic sent to the default address, and it stays silent. Both sides are internally consistent, which is why nothing reports an error.

How would you confirm it without reproducing intermittently? Read the device controller's address register immediately after a bus reset. It should read the default address; if it holds the old value, the diagnosis is complete and no further reproduction is needed.

What is the general principle? When a power cycle fixes what a protocol reset does not, the fault is a scope error rather than a logic error — some state was omitted from what the protocol reset is defined to clear. That is a specific, checkable class of bug, and its signature is exactly works the first time, fails on retry.

11. Understanding Check

12. Summary

Reset breaks a circularity: the host cannot discover a device's state, because discovery requires a state. Reset asserts one instead — it is the only point in USB where the host tells rather than asks, and the device may not decline.

It must be unmistakable, which is why an extended SE0 is right: recognisable with only line-state machinery, needing no agreement about encoding, and outside the signalling alphabet so it cannot be confused with data.

It establishes the Default state: no assigned address, control path available, not configured. That is what makes the first request possible and what every later step assumes.

Scope is the design decision. Protocol-visible state — address, configuration, protocol condition — must be cleared, because that is the agreement being forced. Implementation state should generally survive, and clearing it is wasteful or destructive.

A bus reset is not a hardware reset. Wiring one into the other destroys the detector, over-clears, and removes firmware's ability to learn a reset happened. The correct structure detects, reports and acts — with the report outliving the event that created it.

And the classic bug: state machine cleared, address register not, producing a device internally in Default and externally answering a stale address, with both sides consistent and neither reporting an error. Its signature is works the first time, fails on re-enumeration, and when a power cycle fixes what a protocol reset does not, the fault is a scope error.

13. What Comes Next

The device is in Default. It is reachable, it is not configured, and it has no address — which is where the next problem lives.

A bus is shared. Every device below a hub sees traffic, and each decides whether it is the intended recipient by comparing an address. But a device that has just been reset has no address to compare against, and the host cannot assign one without first being able to talk to the device. That is the same circularity reset solved, appearing again at a different layer.

Chapter 6.3 shows how it is resolved — and the answer turns out to contain the most interesting timing boundary in enumeration, because receiving an address and beginning to answer to it are not the same event. That gap is where a great deal of device-controller RTL goes wrong.

Browse the full path on the USB tutorials index.