Control Transfers

Chapter 10.1 derived three transfer types from two questions about traffic, and noted that the fourth comes from somewhere else entirely.

This is that fourth one, and its requirement is unlike the other three:

Every other transfer type requires a configured device. Configuring a device requires talking to it. Control is the service model that resolves that circularity — which is why it is the only type available before anything else works.

Its defining property is therefore not throughput and not timeliness. It is availability.

1. The Circularity

Module 6 walked the enumeration sequence and Module 8 established what each state permits. Put the two together and the problem is unavoidable.

Bulk, Interrupt and Isochronous endpoints all require a configuration to be selected. Chapter 8.5 established this precisely: function endpoints operate only in the Configured state, and which ones operate depends on which configuration was chosen.

Selecting a configuration requires a request. A request requires a transfer. A transfer requires an endpoint.

So the device needs a working endpoint before it has any working endpoints.

The resolution is the one this course has met four times. Chapter 6.3 reserved a default address; Chapter 7.5 reserved string index zero; Chapter 9.3 reserved endpoint zero. Each takes one value out of a space and defines it to exist unconditionally.

Control is the same move applied to the service model. One transfer type is defined to work before configuration, so that configuration can happen.

2. Why Not Just Use Bulk?

The question worth answering directly, because Control looks superficially like small Bulk transfers.

Both are non-periodic — Chapter 10.1 §2's grid puts them in the same row. Both are retryable. Both carry correctness-critical data. A reasonable engineer asks why the protocol needs two.

Three reasons, and each is a different kind of requirement.

Bulk can be starved; Control must not be. Chapter 10.1 §5 established that non-periodic traffic lives in what periodic reservations leave behind, and §3 shows that Control is additionally protected within that residue. A bus busy with bulk transfers must still be able to configure a device.

Control has a structure the protocol relies on. A management operation is a request with a response and a completion — the host must know whether the device accepted the command. Chapter 6.3's address commit depends entirely on that completion being well-defined, and a bulk data stream has no equivalent notion. Module 13 owns that structure in detail; what matters here is that it exists and that a plain data pipe does not provide it.

Control is bidirectional on one endpoint. Chapter 9.3 §2 established that endpoint zero's two halves are two directions of one conversation, unlike 0x81 and 0x01 which are independent endpoints. A management operation goes out and a response comes back, and they belong together — which is a property Bulk's independent unidirectional endpoints cannot express.

3. Guaranteed Availability, Concretely

The claim Control must not be starved needs to be more than an assertion.

Chapter 10.1 §5 established the periodic cap — the Linux kernel's FRAME_TIME_MAX_BITS_ALLOC holds periodic allocation to 90% of a 12,000-bit-time frame, leaving at least a tenth for non-periodic traffic.

That residue is shared between Control and Bulk, and within it Control is protected in a way Bulk is not: host implementations reserve a portion of each frame's non-periodic capacity for control traffic specifically, so that a bus saturated with bulk transfers can still carry management operations.

The exact division is a host implementation policy rather than a device-visible constant, and this module will not state a number for it — Chapter 10.1 §5's 90% is specification-anchored and enforced identically by hosts, while the control-versus-bulk split within the remainder varies.

What matters to a device engineer is the guarantee's shape:

Read the figure as a chain of guarantees. The cap guarantees the residue is non-empty. The control protection guarantees management traffic has a share of the residue. Bulk is guaranteed nothing and gets whatever survives both — which is Chapter 10.3's entire subject.

4. A Management Path Must Be Serialised

The property that has a direct hardware consequence, and the one this chapter's RTL is about.

A management operation changes the device's state. Chapter 6.3's address assignment, Chapter 6.5's configuration selection, and every other standard request either read state or modify it.

Now ask what happens if two are in flight at once. Suppose a configuration selection and an address assignment overlap. Which committed first? What state is the device in between them? If one fails, does the other's effect stand?

None of those questions has a good answer, and the protocol avoids them: a device processes one management operation at a time on its control endpoint, and the host does not begin another until the previous one completes.

That is serialisation, and it is a hardware requirement, not merely a host convention — the device must be able to reject or defer a second operation arriving while one is outstanding, because it cannot rely on the host being correct.

5. The Control-Path Gate, as RTL

Small, and every line is §4.

// ─────────────────────────────────────────────────────────────────────────
// usb_control_path_gate
//
// Classification: SIMPLIFIED SYNTHESIZABLE TEACHING RTL. It models the
// serialisation of section 4 -- one management operation outstanding at a
// time -- and the availability rule of section 1.
//
// WHAT IT MODELS. Whether a newly-arriving management operation may begin,
// given what is already outstanding and what state the device is in. It
// also reports a second operation arriving while one is in flight, which is
// a host error the device must survive rather than assume away.
//
// WHAT IT DOES NOT MODEL. The STRUCTURE of a control transfer -- its stages
// and their sequencing are Module 13's, and are deliberately absent here:
// this block sees an operation begin and an operation complete, and nothing
// in between. Nor the requests themselves (Module 13), the transactions
// that carry them (Module 12), packets (Module 11), or the scheduling that
// decides WHEN the host offers service (Chapter 10.3's arbiter is the
// nearest thing, and control is not what it arbitrates).
//
// ── ON "AVAILABILITY" ──────────────────────────────────────────────────
// Section 1's rule is that control works in every state that permits
// communication at all. In this block that is one condition: the device
// must be at least Default (Chapter 8.3), because Default is the first
// state in which the host and device share an understanding. Below it there
// is no protocol to manage.
// ─────────────────────────────────────────────────────────────────────────
module usb_control_path_gate
  import usb_state_pkg::*;
(
  input  logic clk,
  input  logic rst_n,

  // The device's protocol state (Module 8). Control is available from
  // Default upward -- section 1.
  input  usb_dev_state_e dev_state,

  input  logic bus_reset,

  // A management operation has arrived. 1-cycle pulse, already decoded and
  // qualified as addressed to the control endpoint (Chapter 9.2).
  input  logic op_start,

  // The outstanding operation has finished -- successfully or not. Module 13
  // owns what "finished" means; this block only needs the event, and needs
  // exactly one of these two to pulse per accepted operation.
  input  logic op_complete,
  input  logic op_failed,

  output logic op_accept,        // 1-cycle: this operation may proceed
  output logic op_reject_busy,   // 1-cycle: one is already outstanding
  output logic op_reject_state,  // 1-cycle: no protocol to manage yet
  output logic outstanding       // an operation is in flight
);

  // Availability, derived rather than stored (Chapter 10.1 section 6's
  // argument). Control is available from Default upward.
  logic control_available;
  assign control_available = (dev_state == DEV_DEFAULT)
                          || (dev_state == DEV_ADDRESS)
                          || (dev_state == DEV_CONFIGURED);

  // An operation that is COMPLETING this cycle is no longer outstanding for
  // the purposes of accepting a new one. This term is the whole of section
  // 4's back-to-back rule, and it has to be here rather than in the
  // sequential block below: `outstanding` is registered, so it still reads 1
  // during the cycle its completion arrives. Ordering the assignments in the
  // always_ff changes the NEXT value and does nothing for a combinational
  // decision made this cycle -- which section 7 measured the hard way.
  logic clearing_now;
  assign clearing_now = op_complete || op_failed;

  // Acceptance is combinational: a device must answer a request in the cycle
  // it arrives, not a cycle later.
  assign op_accept       = op_start &&  control_available
                                     && (!outstanding || clearing_now);
  assign op_reject_busy  = op_start &&  control_available
                                     &&   outstanding && !clearing_now;
  assign op_reject_state = op_start && !control_available;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      outstanding <= 1'b0;
    end else if (bus_reset) begin
      // A bus reset abandons any operation in flight. Chapter 8.3 section 6:
      // the host has asserted a new starting point, so an operation begun
      // before it belongs to a conversation that no longer exists. Leaving
      // this set would make the device reject the FIRST operation of the
      // new enumeration -- section 7 measures exactly that.
      outstanding <= 1'b0;
    end else begin
      // Order matters here too, but only for the registered value: a
      // completion and an acceptance in the same cycle must leave the flag
      // SET, because the new operation is now the outstanding one. The
      // back-to-back ACCEPTANCE decision is made combinationally above --
      // see the note there.
      if (clearing_now) outstanding <= 1'b0;

      if (op_accept)    outstanding <= 1'b1;
    end
  end

endmodule

What it models. §4's serialisation and §1's availability rule.

Engineering reason. A device cannot rely on the host never sending a second operation while one is outstanding, and it must give a defined answer when that happens.

Inputs. The protocol state, a bus reset, an operation start, and completion or failure.

State retained. One bit: whether an operation is outstanding.

Outputs. Acceptance, two distinct rejections, and the outstanding flag.

Hardware implied. One flip-flop and a handful of gates.

Reset behaviour. The local reset and a bus reset both clear the outstanding flag. §7 measures what omitting the bus-reset case costs.

Assumptions. That op_start is decoded and addressed to the control endpoint; that exactly one of op_complete or op_failed pulses per accepted operation; and that Module 13 owns everything between them.

Omissions. The entire structure of a control transfer, the requests, the transactions, the packets, and the host's scheduling.

What DV should verify. That a second operation is rejected while one is outstanding; that the two rejection reasons are distinguishable and never simultaneous; that a completion and a start in the same cycle accepts the new operation; that a bus reset clears the outstanding flag; that no operation is accepted below Default; and that outstanding never sets without an acceptance.

6. Control Traffic Over Time

7. Mutation Test

Four mutations, run against two plans: a full one, and one that observes only whether an operation was accepted rather than why it was refused.

  mutation                              full plan        accept-only plan
  ────────────────────────────────────────────────────────────────────────
  correct gate                          OK               OK
  C1  acceptance ignores a completion   BROKEN (2)       BROKEN (2)
  C2  bus-reset clearing omitted        BROKEN (3)       BROKEN (3)
  C3  available in every state          BROKEN (3)       BROKEN (1)
  C4  rejection reasons merged          BROKEN (2)       OK

C1 — acceptance does not account for a concurrent completion

This was not a hypothetical mutation. It was this chapter's first draft, and simulation found it.

The original wrote acceptance as op_start && control_available && !outstanding, and handled the completion first inside the always_ff — with a comment claiming that ordering implemented the back-to-back rule.

It did not. outstanding is registered, so it still reads 1 during the cycle its completion arrives. Ordering assignments inside a sequential block changes the next value and does nothing for a combinational decision made this cycle. The back-to-back case was rejected as busy, and the comment describing the intended behaviour sat directly above logic that did not implement it.

The fix is the clearing_now term in §5, which is where the rule actually has to live.

And the field symptom is the memorable part: back-to-back management operations fail, so enumeration succeeds against a slow host and fails against a fast one — or passes in a simulation with gaps between operations and fails on hardware. Every operation works individually; only the sequence breaks.

C2 — omit the bus-reset clearing

Result. Three failures. An operation outstanding when a bus reset arrives leaves the flag set permanently — only a local reset clears it. The first management operation of the next enumeration is rejected as busy, and since the host's first action after a reset is to assign an address, the device never gets one.

Chapter 8.1 §9's stale-state signature in a new place: works once, fails on the second attempt, recovered only by a power cycle.

C3 — allow control operations in every state

Result. Operations are accepted in Powered and Attached, where Chapter 8.3 established there is no shared understanding to manage.

And the consequence is worse than a refusal would be. A rejection is a defined answer the host can act on. An acceptance that goes nowhere leaves the host waiting for a completion that will never arrive — converting an immediate error into a timeout, which is slower to detect and harder to attribute.

C4 — merge the two rejection reasons

Result: it depends entirely on what the plan observes — zero errors against a plan that checks only whether an operation was accepted, and two failures once the reasons are checked.

A legitimate survivor of the natural plan, and the loss is diagnostic rather than functional. Busy means the host pipelined incorrectly; wrong state means the host addressed a device that is not ready. They send an investigation to opposite ends of the system, and §8 depends on having both.

This is Chapter 9.2 §5's distinction reached a third time: unobserved, not unobservable.

8. Debugging: the Device That Enumerates Once

A device enumerates and works. Unplugged and reconnected, it fails to enumerate — the host reports that it does not respond to the first request. Power-cycling the device fixes it.

What does works, then does not, fixed by a power cycle tell you? Chapter 8.1 §9's stale-state signature: something survived an event that should have cleared it, and only a local reset clears it.

What is specific to the first request? The first management operation after a reset is the address assignment. If it is refused, nothing else can happen — so the failure is at the very start of the management path rather than anywhere in the device's function.

What is the first observation? The control path's outstanding flag, immediately after the bus reset. If it is set, the device believes an operation is in flight and is refusing the new one.

How did it get set and not cleared? An operation was outstanding when the reset arrived, and the reset did not clear it — §7's C2.

Why does the protocol analyser not help directly? It shows the host sending a request and the device refusing it. Both sides are behaving consistently with their own state; the disagreement is about whether an operation is in flight, and only the device knows that.

And what distinguishes this from §7's C1? What preceded the failure. C2 needs a reset during an operation; C1 needs two operations in immediate succession and is sensitive to host speed rather than to resets.

The discipline this chapter adds to Chapter 8.4 §7's: when a device refuses traffic it should accept, ask what the device believes is outstanding before asking what is wrong with the traffic.

9. Verification

This chapter's commit point is a management operation was allowed to proceed, or refused for a stated reason.

Stimulus. An operation in each protocol state, including below Default; a second operation while one is outstanding; a completion and a start in the same cycle; a failure and a start in the same cycle; a bus reset with an operation outstanding and with none; and back-to-back operations at every spacing from zero cycles upward.

The stimulus requirements §7 makes non-negotiable:

• A completion and a start in the same cycle. C1 is invisible at any other spacing, and a testbench that leaves a gap between operations — which is the natural way to write one — never produces it.
• A bus reset while an operation is outstanding. C2 needs exactly this coincidence, and a plan that resets an idle device does not.

Observation. The acceptance, both rejection reasons, and the outstanding flag. C4 is invisible to an observation of acceptance alone.

Reference model. One bit and three rules: set on acceptance, clear on completion or failure, clear on bus reset — with completion evaluated before acceptance. Small enough to be exhaustive over the input space, which §10's exercise uses.

Coverage — crosses:

• protocol state × operation start — every state, including those below Default
• outstanding × start, both values
• completion × start in the same cycle, and separated by one cycle
• failure × start in the same cycle
• bus reset × outstanding, both values

Negative cases with defined outcomes: a second operation while one is outstanding must be refused as busy; an operation below Default must be refused for state; the two reasons must never assert together; and a bus reset must clear the flag whether or not anything was outstanding.

10. Reason It Through

A reviewer proposes replacing §5's single outstanding bit with a two-entry queue, so the host can pipeline management operations and reduce enumeration time.

Would it work? Mechanically, yes — the device could accept a second operation and process it after the first.

What does it cost on the device side? Each queued operation needs its own state: which request it is, what it will commit, and where its completion should be attributed. §4's callout named the problem: with more than one outstanding, a completion becomes ambiguous and has to be tagged.

What does it cost on the host side? The host must track which completions belong to which operations, and must handle the case where operation one fails and operation two — already issued — depended on it having succeeded. A configuration selection pipelined behind an address assignment that failed is a request sent to a device that is not where the host thinks it is.

How much would it save? Enumeration is perhaps a dozen management operations, once per attach. Chapter 6.7 showed the sequence is dominated by specified waiting intervals — the debounce, the reset, the recovery periods — not by the operations themselves. Pipelining removes time that is not where the time goes.

So what is the verdict? The trade is bad in both directions: substantial complexity on both sides of the bus, for a saving in a part of the sequence that is not the bottleneck, on an operation that happens once per attach.

And the transferable principle? Pipelining pays when the pipeline is busy. A management path is idle almost all the time and matters only at the moments when correctness is most important. Serialisation is the right choice precisely because the traffic is rare — which is the opposite of the intuition that rare things do not deserve simple designs.

11. Common Misconceptions

12. Understanding Check

13. Summary

Control exists because the protocol has a bootstrap problem with itself. Every other transfer type requires a configured device, and configuring one requires talking to it — so one transfer type is defined to work before configuration, the same reserve-one-value move as the default address, string index zero and endpoint zero.

Its requirement is therefore availability, not throughput or timeliness. It is the only type available in every state that permits communication, the only one an endpoint can have without a descriptor declaring it, and the only one whose failure the protocol cannot recover from by its own mechanisms.

It is not small Bulk. Size is a consequence: a descriptor read can be hundreds of bytes and a vendor command over bulk endpoints can be four. The differences are that Control is protected from starvation within the non-periodic residue, has a defined completion the protocol depends on, and is bidirectional on one endpoint where the two halves are one conversation.

The budget is nested: the periodic cap guarantees a non-periodic residue exists, control traffic is protected within it, and Bulk is guaranteed nothing and absorbs what survives both.

A management path must be serialised, and that falls out of the completion requirement — if completion is what commits a change, a second operation in flight makes completions ambiguous. In hardware that is one bit, and §7 measured the three ways to get it wrong: handling acceptance before completion refuses legal back-to-back operations, so the device works with a slow host and fails with a fast one; omitting the bus-reset clearing leaves the device permanently busy, so it enumerates once and never again; and accepting operations below Default turns a defined refusal into a host timeout.

And §10's principle: pipelining pays when the pipeline is busy. A management path is idle almost always and matters exactly when correctness matters most, which is why serialisation is right because the traffic is rare.

14. What Comes Next

Control is protected. Interrupt and Isochronous are reserved. §3's figure showed what is left for the fourth type: whatever survives both.

Chapter 10.3 is Bulk, and it is the type defined entirely by what it is not promised. It has no reservation, no service interval and no guarantee it will be visited at all — and it is nonetheless the type that moves the most data on most buses.

Understanding why those two facts are compatible is the chapter, and it turns on a distinction Chapter 10.1 has already needed twice: throughput and guarantee are different axes, and Bulk trades all of one for all of the other.

Browse the full path on the USB tutorials index.