Powered State

Chapter 8.1 left the device physically present and inert. It has a connector mated and nothing else — no power, no identity, no permissions.

This chapter is where that changes, and it contains something that appears nowhere else in USB:

Powered is the only state in which the device acts on its own initiative. Everything before it happens to the device; everything after it is the host acting on the device. This is the one moment the device chooses.

What it chooses is when to be noticed — and that choice has consequences the device controller owns alone.

1. What Powered Means

A device is Powered when operating power is available to it but the host has not yet acted on it. Power is present; nothing has been reset, addressed or configured.

What is legal? Internal activity. The device can bring up its own logic, run its own initialisation, and present its pull-up. It cannot participate in the protocol, because no protocol has begun.

What is guaranteed? That power is available. Not that the device is ready, not that the host knows about it, and not that any speed has been established.

How is it entered? By power becoming available to an attached device — which is not the same as being plugged in, for Chapter 8.1 §5's reasons.

How is it left? Upward by a bus reset, which produces Default. Downward by losing power, or by the device being removed.

And that upward exit is the point of §4, because it is not optional and it is not something the device can do for itself.

2. Where Does the Power Come From?

Two answers, and they lead to genuinely different hardware.

A bus-powered device draws its operating power from the bus. Plug it in and it powers up. Unplug it and it stops. Its Attached and Powered states are almost simultaneous — the same physical act causes both.

A self-powered device has its own supply. It may be fully powered while the bus is not, and it may be running long before anyone plugs it in.

For a bus-powered device the two states nearly collapse together. For a self-powered one they are genuinely independent, and that independence creates a hardware requirement with real consequences — §3.

3. A Self-Powered Device Must Watch Bus Power

The chapter's hardware requirement, and it is one that catches real products.

Consider a self-powered device plugged into a host that is switched off. The device has its own power and is fully operational. The host is not. What should the device do with its pull-up?

If it presents the pull-up anyway, it drives current onto a bus conductor that nothing is driving from the other end. The device is back-powering the bus — feeding current into a host that is supposed to be off, through a connection designed to carry power the other way.

The consequences are real. It can hold a host's USB subsystem in a partially-powered state, prevent a host from entering or staying in a low-power condition, and violate electrical requirements the port was designed around.

So a self-powered device must monitor bus power and must not present its pull-up while bus power is absent. That is a hardware obligation, not a firmware nicety: the pull-up has to be switchable, and something has to drive that switch from a bus-power detector.

4. Powered Cannot Become Default On Its Own

A structural point that explains the shape of the whole state machine.

The device is powered, initialised and presenting its pull-up. Why is it not simply in Default?

Because Default is a statement about a shared understanding, and the device cannot establish one alone. Chapter 6.2 showed that reset is an assertion the host makes: it forces the device to a known condition regardless of what the device thought. A device that declared itself Default unilaterally would be asserting a shared state one party has not agreed to.

And the host genuinely needs the transition to be its own action, because reset is also when speed is established (Chapter 3.7) and when the host commits to enumerating this device rather than some other one on a busy bus.

So the edge out of Powered is the host's, and the device's only role is to have made itself noticeable in time.

This produces a shape worth noticing now, because it recurs for every state above:

device makes itself noticeable   ← the device's initiative ends here
            ↓
host decides to act              ← everything after this is the host's
            ↓
host resets                      → Default
            ↓
host assigns an address          → Address
            ↓
host selects a configuration     → Configured

Every upward transition above Powered is caused by the host. The device's entire agency is spent in one act, and Chapter 2.6's host-centric model is what that agency asymmetry looks like from inside the state machine.

5. When to Present the Pull-Up

The device's one decision, examined properly.

Presenting the pull-up means I am here and I am ready. It is a claim, and like every claim in Module 7, the hardware has to be able to keep it.

Too early is a real failure. Chapter 6.1 §8 noted it: a device that announces itself while still initialising gets a reset and a sequence of requests it cannot answer. The host is not being unreasonable — it saw a device declare readiness and took it at its word.

Too late is also a failure, though a gentler one: the host may have finished looking, and the device waits until something prompts another look.

So the rule is: present the pull-up when the device can actually respond, and not before. What "can respond" means is implementation-specific — clocks stable, the control endpoint's logic out of reset, descriptor storage readable — and that is the part a controller designer owns.

6. The RTL: Deciding to Be Noticed

Small, and every line is a decision from §3 or §5.

// ─────────────────────────────────────────────────────────────────────────
// usb_pullup_control
//
// Classification: SIMPLIFIED SYNTHESIZABLE TEACHING RTL. It models the
// decision of WHEN to present the pull-up, and nothing else.
//
// WHAT IT MODELS. Section 5's readiness rule -- announce only when the
// device can actually respond -- and section 3's bus-power rule: a
// self-powered device must not present its pull-up while bus power is
// absent, because doing so back-powers the bus.
//
// WHAT IT DOES NOT MODEL. The pull-up's electrical behaviour (Chapter 3.5
// owns the resistor, its value and the line's settling), speed selection
// (Chapter 3.7), the protocol state machine (Chapter 8.3), or anything
// above it. This block decides one bit.
//
// SYNTHESIS NOTE. `vbus_present` crosses from an analogue detector and MUST
// be synchronised before it arrives here; this block assumes that has been
// done. The debounce on it is for supply settling, not for metastability,
// and the two are different problems with different solutions.
// ─────────────────────────────────────────────────────────────────────────
module usb_pullup_control #(
  // Cycles bus power must be continuously present before it is believed.
  // Scaled down for simulation; the real value comes from the supply's
  // settling behaviour, not from the protocol.
  // NOTE: there is deliberately no SELF_POWERED parameter -- see the note
  // following this section for why that distinction is a comment rather
  // than a configuration option.
  parameter int unsigned VBUS_STABLE_CYCLES = 8
)(
  input  logic clk,
  input  logic rst_n,

  // Bus power present, already synchronised to this domain.
  input  logic vbus_present,

  // The device's own readiness: clocks stable, control-endpoint logic out
  // of reset, descriptor storage readable. Owned by whatever initialises
  // the controller; this block only consumes it.
  input  logic device_ready,

  output logic pullup_enable,
  output logic vbus_stable       // exported for status/debug visibility
);

  logic [31:0] vbus_cnt;
  logic        vbus_q;

  // ── Qualify bus power ───────────────────────────────────────────────────
  // Chapter 6.1's continuous-stability discipline, applied to a supply
  // rather than a connector: any transition restarts the count, so a
  // supply that is still settling cannot accumulate its way to "stable".
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      vbus_cnt    <= '0;
      vbus_q      <= 1'b0;
      vbus_stable <= 1'b0;
    end else begin
      vbus_q <= vbus_present;

      if (vbus_present != vbus_q) begin
        vbus_cnt    <= '0;
        vbus_stable <= 1'b0;
      end else if (vbus_cnt < VBUS_STABLE_CYCLES) begin
        vbus_cnt <= vbus_cnt + 1;
        if (vbus_cnt == VBUS_STABLE_CYCLES - 1) vbus_stable <= vbus_present;
      end
    end
  end

  // ── The decision ────────────────────────────────────────────────────────
  // Registered rather than combinational, deliberately: this drives an
  // analogue switch, and a glitch on it is a glitch on the bus. A
  // combinational term over a counter and two inputs can glitch; a
  // flip-flop output cannot.
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      // The safe direction. A device coming out of reset has not yet
      // established that it is ready OR that bus power is present, and the
      // failure modes of announcing too early are worse than those of
      // announcing slightly late (section 5).
      pullup_enable <= 1'b0;
    end else begin
      // BOTH conditions, and the AND is the whole block:
      //   device_ready  -- section 5: do not claim readiness you lack
      //   vbus_stable   -- section 3: do not back-power an unpowered bus
      //
      // Note there is no SELF_POWERED term here. The requirement differs by
      // device type in MOTIVATION but not in BEHAVIOUR: a self-powered
      // device must check bus power to avoid back-powering, and a
      // bus-powered device has no bus power to run on, so the same check is
      // merely vacuous for it rather than wrong. The distinction belongs in
      // this comment, not in logic -- see the note below section 6.
      pullup_enable <= device_ready && vbus_stable;
    end
  end

endmodule

What it models. The readiness rule and the bus-power rule, as one registered bit.

Why this hardware exists. Because presenting the pull-up is the device's only unilateral act, and both ways of getting it wrong — too early, or while the bus is unpowered — produce failures that are invisible on a working bench.

Inputs. Clock and local reset; a synchronised bus-power indication; and a device-readiness indication from whatever initialises the controller.

State retained. A stability counter, the previous bus-power sample, the qualified stable flag, and the output.

Outputs. The pull-up enable, and the qualified bus-power flag exported for status and debug.

Reset behaviour. The pull-up is disabled. That direction is deliberate: a device leaving reset has established neither readiness nor bus power, and announcing too early is the more expensive error.

Hardware implied. A counter, a comparator and two flip-flops, driving an analogue switch.

Assumptions. That vbus_present is already synchronised — the header separates that from debouncing, because they are different problems; that device_ready genuinely means the control endpoint can answer; and that the parameter is set correctly for the product.

Deliberately omits. The pull-up's electrical behaviour, speed selection, the protocol state machine, and everything above it.

What DV should verify. That the pull-up never asserts without stable bus power; that it never asserts without device readiness; that a bus-power glitch shorter than the stability window never produces an assertion; that losing bus power removes the pull-up; and that the output is glitch-free because it is registered.

7. The Assertions

Three properties, and the third is the one §8 measured doing unexpected work.

// ─────────────────────────────────────────────────────────────────────────
// Classification: TEACHING ASSERTIONS about the pull-up decision.
// P1 and P2 are SAFETY properties -- something must never happen. P3 pins
// the block's INTERFACE TIMING, which turns out to be what distinguishes a
// registered implementation from a combinational one (section 8).
// ─────────────────────────────────────────────────────────────────────────

// P1 -- SAFETY. The pull-up is never presented without stable bus power.
// This is section 3's back-powering rule, and it is the property that
// protects a bus the device is not supposed to be driving.
property p_no_pullup_without_vbus;
  @(posedge clk) disable iff (!rst_n)
    pullup_enable |-> $past(vbus_stable);
endproperty
assert property (p_no_pullup_without_vbus);

// P2 -- SAFETY. Nor without the device being able to respond (section 5).
property p_no_pullup_without_ready;
  @(posedge clk) disable iff (!rst_n)
    pullup_enable |-> $past(device_ready);
endproperty
assert property (p_no_pullup_without_ready);

// P3 -- INTERFACE TIMING. The output is registered, so it reflects its
// preconditions from the PREVIOUS cycle -- never the current one.
//
// Note carefully why both P1 and P2 use $past as well: a registered output
// CANNOT track its inputs in the same cycle, so a property written against
// the current cycle would fail on the correct design at every assertion
// edge. Getting this wrong is the most common way to write an assertion
// that appears to find a bug in working hardware.
property p_output_is_registered;
  @(posedge clk) disable iff (!rst_n)
    pullup_enable == $past(device_ready && vbus_stable);
endproperty
assert property (p_output_is_registered);

// P4 -- PROGRESS. Safety properties above are all satisfied by a design
// that never asserts the pull-up at all. This is what forbids that: with
// both preconditions held stable, the pull-up must follow.
property p_pullup_eventually_asserts;
  @(posedge clk) disable iff (!rst_n)
    (device_ready && vbus_stable) |=> pullup_enable;
endproperty
assert property (p_pullup_eventually_asserts);

P1 and P2 are safety; P4 is progress, and the distinction is the one Chapter 7.3 §9 had to discover by measurement. P1 and P2 forbid an assertion that lacks a precondition — and are both satisfied completely by a block whose output is tied low. P4 is what requires the pull-up to actually happen.

P3 looks like a restatement of P1 and P2 together, and is not. It is an equality rather than an implication, so it constrains the output in both directions and in a specific cycle. §8 measures what that catches.

And the $past in all four is load-bearing. A registered output physically cannot reflect its inputs in the same cycle. A property written as pullup_enable |-> vbus_stable would fail on the correct design every time bus power was withdrawn, because the output takes a cycle to follow — which is how engineers end up "finding bugs" in working hardware and then weakening real properties to silence them.

8. Mutation Test

Three mutations of §6. All were run; results are measured.

W1 — ignore bus power entirely

pullup_enable <= device_ready;   // MUTANT W1

Result, measured against two benches:

                              host ON throughout      bus power varied
  correct design              OK (0 errors)           OK (0 errors)
  W1 (bus power ignored)      OK (0 errors)           BROKEN (5 errors)

Against a bench where bus power is present for the whole run — a host that is on, which is every developer's bench — the mutant is indistinguishable from the correct design. Vary bus power and it fails five checks, P1 among them.

This is the §3 bug exactly, and its measurement makes that section's point: the defect requires a powered device on an unpowered bus, which is not a state any ordinary test creates.

This is the §3 bug exactly, and its measurement makes the point that section argued: the defect requires a powered device on an unpowered bus, which is not a state any ordinary test creates.

W2 — qualify bus power without restarting on a transition

if (vbus_present && (vbus_cnt < VBUS_STABLE_CYCLES)) begin   // MUTANT W2

Result, measured — the same shape as W1: zero errors with the host on throughout, and three failures once bus power is varied. Cumulative rather than continuous, so several short bus-power pulses, each far below the stability window, accumulate to the threshold and the device announces itself on a supply that never settled.

Worth noting because it is the same defect in a different domain. In Chapter 6.1 §7 it was a bouncing connector; here it is a settling supply. The shape of the mistake — count while present instead of count while unchanged — is identical, and so is the fix.

W3 — drive the pull-up combinationally

assign pullup_enable = device_ready && vbus_stable;   // MUTANT W3

This mutation was expected to survive, and it did not. The expectation was that a combinational output is functionally identical at every point a simulation samples, so only a gate-level view could distinguish it. That reasoning was wrong, and the measurement says why:

                              host ON throughout
  correct design              OK (0 errors, 0 violations)
  W3 (combinational output)   BROKEN (1 error, 2 violations)

It fails even with bus power present for the entire run, and every functional check passes — the only thing that fires is P3, the property pinning the interface timing.

Why P3 catches it. A registered output asserts one cycle after its preconditions become true. A combinational one asserts in the same cycle. P3 is an equality against $past(...), so it distinguishes those two timings exactly, and no functional check can — because functionally the two designs reach the same steady state.

9. Verification

This chapter's commit point is the device has announced itself — the last thing the device does on its own initiative.

Stimulus. Bus power applied and removed, with the device ready and not ready, in every order; bus-power pulses shorter than, equal to, and longer than the stability window; readiness asserting before, during and after bus power stabilises; and — the case §7's W1 needs — a ready device on an unpowered bus, held there.

The stimulus requirement §7 makes non-negotiable: generate a powered, ready device with no bus power. Without it W1 is invisible, and W1 is the defect that ships.

Observation. The pull-up enable together with both of its preconditions. Checking that the pull-up eventually asserts is not enough; what matters is that it never asserts when either precondition is missing.

Coverage — crosses:

• bus power present × absent, crossed with device ready × not ready — all four cells, and the ready without bus power cell is the one that matters
• bus-power pulse width: shorter than, equal to, and longer than the stability window
• readiness asserting before × during × after bus power stabilises
• bus power removed while the pull-up is asserted

Negative cases with defined outcomes: a ready device with no bus power must not present the pull-up; a bus-power glitch must not produce a transient assertion; and removing bus power must remove the pull-up.

And the limit, narrowed by §8's W3: the glitch on a combinational output is not visible in RTL simulation, and belongs to gate-level simulation, static timing and review. The timing difference, however, is fully visible — P3 catches it — so registering this output is a property the testbench can and should enforce.

10. Common Misconceptions

11. Reason It Through

A self-powered instrument works perfectly. A customer reports that their laptop will not enter sleep while the instrument is connected — even though the instrument is idle and its own software is closed.

What does the laptop will not sleep have to do with a USB device? Sleep requires the host's USB subsystem to reach a low-power condition, which requires its ports to be quiescent. Something is keeping a port active.

What is special about this device? It is self-powered, so it is fully operational whether or not the host is. A bus-powered device would have lost power along with the port.

What is it most likely doing? Presenting its pull-up while bus power is absent or reduced — §3's back-powering. From the host's point of view a device is present and asserting itself, so the port cannot be considered idle.

Why did nobody catch it? Because every test had the host on. The failure requires a powered device on an unpowered bus, and that is not a configuration a functional test produces — §7's W1 measured a mutant with exactly this defect passing a full testbench.

How would you confirm it? Measure the pull-up while removing bus power with the device still powered. It should release. If it does not, the gating in §6 is missing or its bus-power detector is not connected.

And why does the symptom point away from the device? Because the device works. The complaint is about the laptop, then the hub, then power management — three places that are all behaving correctly. The device is the last suspect precisely because it is functioning, which is the signature of a fault in what a device does when nobody is talking to it.

12. Understanding Check

13. Summary

Powered means operating power is available and the host has not yet acted. Internal activity is legal; protocol participation is not, because no protocol has begun.

It is separate from Attached because connection and power are independent — routinely so for a self-powered device, occasionally so for a bus-powered one. States are distinguished by whether they can differ, not by whether they usually do.

That independence creates a hardware obligation: a self-powered device must not present its pull-up while bus power is absent, or it back-powers the bus — keeping a host's USB subsystem partially powered and blocking low-power states. The pull-up must be switchable and gated.

Powered is the only state in which the device acts on its own initiative, and the act is presenting the pull-up: a claim of readiness the host immediately tests by resetting and interrogating. Too early produces a device that cannot answer; too late produces a device nobody is looking at. Every transition above Powered is caused by the host, which is Chapter 2.6's host-centric model seen from inside the state machine.

The RTL is one registered bit gated on two conditions, and §7 measured all three ways of getting it wrong. Ignoring bus power passes a full testbench unless the stimulus includes a ready device on an unpowered bus. Counting cumulative rather than continuous stability is Chapter 6.1's debounce defect in a new domain. And driving the output combinationally survives, legitimately — the hazard is a glitch, and RTL simulation cannot see glitches, which makes it a reminder to know what your method cannot reach.

14. What Comes Next

The device is powered, ready, and has announced itself. The host has seen it and will now act.

Chapter 8.3 is that action, and it is the chapter where this module's state machine is finally built. Default is the state a reset produces, and it has a property no other state has: it is reachable from everywhere. That single edge is what makes a USB device recoverable from any condition, and it is why Chapter 6.6 could say that enumeration needs exactly one error-recovery path.

It is also where the module's RTL begins in earnest — and where the difference between clearing a state register and clearing a state starts to matter.

Browse the full path on the USB tutorials index.