Transaction Timing Relationships

Chapter 12.4 treated timeout as an input that simply arrived. This is where it comes from — and it is not one number.

A device must respond within a bound. A host must wait at least a bound before giving up. Those are two different numbers, and the whole of USB's transaction reliability rests on the relationship between them.

1. Bit Times, Because Nanoseconds Are Not Portable

Every timing rule in this chapter is expressed in bit times — the duration of one bit on the wire — and never in nanoseconds. The reason is arithmetic:

Low speed is 320× slower than high speed. A rule stated in nanoseconds would need four values and would be wrong the moment a fifth speed was added; stated in bit times it is one number that is correct everywhere.

Working the windows through at each speed makes the range concrete:

The right-hand column is why this chapter exists. A high-speed device has about 15 nanoseconds to decide what to say and begin saying it. That is a handful of clock cycles in the controller's own domain, and it is not a budget that tolerates a decision being made late.

2. Two Bounds, Not One

The relationship the chapter turns on, and it is easy to state as one thing when it is two:

The device's obligation is an upper bound: respond within RESP_MAX.

The host's obligation is a lower bound: wait at least WAIT_MIN before giving up.

They are different kinds of promise. The device promises not to be slow. The host promises not to be impatient. Neither one implies the other, and a system in which both are individually satisfied can still fail.

Because the numbers must also be ordered:

WAIT_MIN > RESP_MAX + the round trip

The round trip is real and not small. A response has to propagate from device to host, and the request had to propagate the other way first — cable, connectors, and any hubs in between. §3 is about it.

3. Where the Round Trip Goes

The guard band has to cover everything between the device deciding to respond and the host observing it.

Two consequences, and the second is the one that produces field failures.

The round trip scales with the topology, not with the speed. Cable propagation is a physical constant — 5 m of cable is ~25 ns whatever the bit rate. At low speed that is 0.04 bit times and invisible. At high speed it is 12 bit times, which is most of the device's entire response budget.

The guard band that was generous at full speed can be entirely consumed by the cable at high speed.

And hubs multiply it. Each hub in the path adds delay in both directions, which is why the specification bounds the number of hubs between host and device — a limit that exists for timing, not for addressing.

4. Measure From the End of the Packet

A small rule with a disproportionate consequence.

The turnaround window starts at the last bit of the packet being responded to — not its first bit, and not the start of the transaction.

Measuring from the start seems equivalent and is not, because packets are not all the same length. Chapter 12.2: a data packet can be anything from zero to 1024 bytes, which at high speed is over 8000 bit times of difference.

A window measured from the start therefore shrinks as the packet grows — generous for a handshake, adequate for a small payload, and negative for a large one.

The bug appears only with large payloads, on the fastest link, after a change that touched neither the timer nor the payload size.

§7's Y2 measures it: 176 in-time responses rejected out of 376 turnarounds, and 24 cases where the host gave up before the device's budget had even elapsed.

5. The Two Timeouts That Are Not the Same Timeout

Worth separating explicitly, because the same word covers quantities eight orders of magnitude apart.

The transaction turnaround is the one this chapter is about: 16 to 18 bit times, which at high speed is about 35 nanoseconds. It is enforced in hardware, and nothing above the controller sees it.

The software request timeout is what a driver applies to a whole control transfer:

#define USB_CTRL_GET_TIMEOUT  5000   /* ms */
#define USB_CTRL_SET_TIMEOUT  5000   /* ms */

Five seconds — roughly 1.5 × 10⁸ times the high-speed turnaround window.

They serve unrelated purposes. The turnaround decides whether this packet was answered. The software timeout decides whether this device is responding at all, across however many retries, NAKs and re-enumerations happened in between.

Confusing them is a real failure mode, and it runs in one direction: a driver that assumes hardware retries happen within its own timeout is usually right, and a hardware designer who assumes the software timeout provides any protection at all is always wrong. Five seconds is not a backstop for a 35-nanosecond window; by the time it expires, millions of transactions have failed.

6. The Turnaround Timer, as RTL

// ─────────────────────────────────────────────────────────────────────────
// usb_turnaround
//
// Classification: SIMPLIFIED SYNTHESIZABLE TEACHING RTL. It models section
// 2's two bounds, section 4's reference point, and the ordering requirement
// between them -- the last of which is checked at ELABORATION, not at run
// time.
//
// WHAT IT MODELS. The interval between the end of an inbound packet and the
// response to it, measured in BIT TIMES (section 1), with the device-side
// and host-side verdicts as separate outputs because they are separate
// promises.
//
// WHAT IT DOES NOT MODEL. The packets themselves (Module 11); the bit clock
// that produces this block's `clk` (Module 14 -- one tick per bit time is an
// abstraction, and a real controller runs faster and divides); the physical
// propagation, which arrives here as the CABLE_BT parameter rather than as
// behaviour; and the transaction sequencing that consumes `give_up`
// (Chapter 12.4, where it arrives as `timeout`).
//
// ── ON THE CLOCK ────────────────────────────────────────────────────────
// `clk` is one tick per bit time. That is a modelling choice which makes
// every number in this block match the specification's own units directly.
// A real controller clocks faster and counts differently, and the
// translation is exactly where section 1's "bit times, not nanoseconds"
// rule gets violated in practice.
// ─────────────────────────────────────────────────────────────────────────
module usb_turnaround #(
  // Section 2: the DEVICE's upper bound.
  parameter int unsigned RESP_MAX = 8,
  // Section 3: one-way propagation through cable, hubs and synchronisers,
  // in bit times. A PARAMETER rather than a constant because it is a
  // property of the topology, and the topology is not known here.
  parameter int unsigned CABLE_BT = 3,
  // Section 2: the HOST's lower bound.
  parameter int unsigned WAIT_MIN = 16,
  parameter int unsigned CNT_W    = 8
)(
  input  logic             clk,            // ONE TICK PER BIT TIME
  input  logic             rst_n,
  input  logic             bus_reset,

  input  logic             pkt_start,
  input  logic             pkt_end,        // SECTION 4: the reference
  input  logic             response_seen,

  output logic [CNT_W-1:0] elapsed,
  output logic             waiting,
  output logic             response_late,  // device side: we overran
  output logic             give_up,        // host side: stop waiting
  output logic             in_time
);

  // ── BUILD-TIME CHECK ────────────────────────────────────────────────────
  // Section 2's ordering requirement. It is NOT a run-time condition: these
  // are parameters, so the relationship is either right or wrong before a
  // single cycle elapses -- and if it is wrong, no amount of simulation
  // makes the silicon work. Checking it here moves the failure from the lab
  // to the build, which section 8 measures as 58 run-time failures becoming
  // one elaboration error at time zero.
  initial begin
    if (WAIT_MIN <= RESP_MAX + 2*CABLE_BT) begin
      $fatal(1, {"usb_turnaround: WAIT_MIN (%0d) must exceed RESP_MAX (%0d) ",
                 "plus the round trip (2*%0d). The host would give up on a ",
                 "device that answered in time."},
             WAIT_MIN, RESP_MAX, CABLE_BT);
    end
  end

  logic [CNT_W-1:0] cnt_q;
  logic             armed_q;

  assign elapsed       = cnt_q;
  assign waiting       = armed_q;

  // Section 2: two bounds, two outputs. Folding them into one would require
  // choosing which promise the block is about, and it is about both.
  assign response_late = armed_q && (cnt_q >  RESP_MAX[CNT_W-1:0]);
  assign give_up       = armed_q && (cnt_q >= WAIT_MIN[CNT_W-1:0]);
  assign in_time       = response_seen && armed_q && !response_late;

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      cnt_q <= '0; armed_q <= 1'b0;
    end else if (bus_reset) begin
      cnt_q <= '0; armed_q <= 1'b0;
    end else if (pkt_end) begin
      // SECTION 4: armed at the END of the packet. Arming at `pkt_start`
      // makes the window shrink as the packet grows -- section 7's Y2, and
      // the reason `pkt_start` is a port at all is so that a reader can see
      // it is deliberately NOT used here.
      cnt_q   <= '0;
      armed_q <= 1'b1;
    end else if (response_seen || give_up) begin
      armed_q <= 1'b0;
      cnt_q   <= '0;      // section 7's Y3: a timer that is not cleared
                          // carries the previous turnaround into the next
    end else if (armed_q) begin
      cnt_q <= cnt_q + 1'b1;
    end
  end

endmodule

What it models. The interval between an inbound packet ending and its response, against two independent bounds.

Engineering reason. Because a device being on time and a host being patient are separate promises, and the system fails when the relationship between them does — not when either one is broken.

Inputs. Packet start and end, and the response.

State retained. An 8-bit counter and an armed flag — 9 flip-flops.

Outputs. The count, the arm state, the two verdicts, and the in-time indication.

Hardware implied. A counter and two comparators against constants.

Reset behaviour. Disarmed and zeroed on both resets, because a turnaround that was in flight is over.

Assumptions. That clk is one tick per bit time — see the header, this is where a real design diverges and where §1's rule is broken in practice; that pkt_end marks the last bit and not the last byte; and that CABLE_BT is the worst-case topology, not the one on the bench.

Omissions. Packets, the bit clock, the physical propagation and the sequencing — in the header.

What DV should verify. That a response at exactly RESP_MAX is in time and one bit later is not; that the host never gives up before RESP_MAX + 2·CABLE_BT; that the window does not depend on the length of the packet that preceded it; that the timer is cleared between turnarounds; and that an illegal parameter set does not elaborate.

7. Mutation Test

Four mutations over 376 turnarounds, sweeping every response delay from 0 to WAIT_MIN + 2 against packets of 1, 8, 64 and 255 bit times, plus 300 randomised turnarounds — and separately, an illegal parameter set, which is a different kind of test entirely.

The unmutated block: 194 in time, 141 late, 41 abandoned by the host, and 0 violations of every obligation.

Y2 — arm the timer at the start of the packet

Measured: in-time responses collapse from 194 to 12. 176 rejected, and 24 cases where the host gave up before the device's budget had even elapsed.

§4's rule broken. The window is consumed by the packet itself, so it is adequate after a 1-bit packet and gone after a 255-bit one.

And the stimulus is what makes it visible. The sweep runs identical delay values against packets of 1, 8, 64 and 255 bit times — and the failure rate rises monotonically with packet length. Running the sweep at one packet length would have shown a partial failure and no pattern.

Y3 — never clear the counter

Measured: 360 turnarounds started with a non-zero counter, and every other obligation still satisfied.

The count carries over, so each turnaround begins already partway through its budget. The first transaction after a reset is correct and every subsequent one is progressively wrong, which is exactly the profile that survives a short bench.

And note what did not fire: no in-time response was rejected and no give-up was early, because the bench's own sweep resets between phases often enough to mask it. Only the direct check on the counter's state between turnarounds caught it — a check that exists because §6's contract says the timer is cleared, not because any behavioural symptom suggested it.

Y4 — the boundary off by one

assign response_late = armed_q && (cnt_q >= RESP_MAX);   // MUTANT Y4

Measured: 26 in-time responses rejected — exactly the responses arriving at precisely RESP_MAX.

A device that meets its budget exactly is declared late. In a system with any margin this costs nothing; in one where the device is tuned to its bound — which is what a maximum-throughput design does — it costs every transaction.

It is the smallest measurable defect here and the one most likely to reach production, because it is invisible unless something sits exactly on the boundary, and nothing does until somebody optimises.

Y5 — remove the build-time check

Measured with legal parameters: nothing. Every output identical to the golden design.

Which is the correct result, and §8 is about why a mutation that survives every simulation is nonetheless a defect.

8. The Assertions

// ─────────────────────────────────────────────────────────────────────────
// Classification: TEACHING ASSERTIONS about the turnaround.
// B-properties are the two BOUNDS; R the reference point; C the counter.
// The ordering requirement is NOT here -- it is an elaboration check, and
// section 7 is the argument for why that is the right place.
// ─────────────────────────────────────────────────────────────────────────

// B1 -- A RESPONSE WITHIN THE BUDGET IS IN TIME. Section 2's device-side
// bound, and the equality boundary is deliberate: at exactly RESP_MAX the
// device has MET its obligation. Section 7's Y4 is the off-by-one.
property p_in_budget_is_in_time;
  @(posedge clk) disable iff (!rst_n)
    (response_seen && waiting && (elapsed <= RESP_MAX)) |-> in_time;
endproperty
assert property (p_in_budget_is_in_time);

// B2 -- AND ONE BIT LATER IT IS NOT. The other side of the same boundary;
// without it a design that calls everything in time satisfies B1.
property p_over_budget_is_late;
  @(posedge clk) disable iff (!rst_n)
    (waiting && (elapsed > RESP_MAX)) |-> response_late;
endproperty
assert property (p_over_budget_is_late);

// B3 -- THE HOST NEVER GIVES UP BEFORE THE ROUND TRIP HAS ELAPSED. Section
// 2's ordering requirement, expressed as the run-time consequence it has.
// Note this property CANNOT fail if the elaboration check passed -- which is
// the point: it is here to catch a counter that reaches the threshold early,
// not a parameter set that is wrong.
property p_no_early_giveup;
  @(posedge clk) disable iff (!rst_n)
    give_up |-> (elapsed >= RESP_MAX + 2*CABLE_BT);
endproperty
assert property (p_no_early_giveup);

// R1 -- THE WINDOW IS INDEPENDENT OF THE PACKET'S LENGTH. Section 4, and
// section 7's Y2. Stated as: the counter is zero exactly one cycle after
// pkt_end, whatever preceded it.
property p_armed_at_packet_end;
  @(posedge clk) disable iff (!rst_n)
    (pkt_end && !bus_reset) |=> (waiting && (elapsed == 0));
endproperty
assert property (p_armed_at_packet_end);

// R2 -- AND `pkt_start` DOES NOTHING. Unusual to assert that an input has no
// effect -- and it is exactly what section 7's Y2 violates. An input present
// in the port list and deliberately unused needs a property saying so, or
// the next editor will wire it up.
property p_start_has_no_effect;
  @(posedge clk) disable iff (!rst_n)
    (pkt_start && !pkt_end && !bus_reset && !waiting) |=> !waiting;
endproperty
assert property (p_start_has_no_effect);

// C1 -- THE COUNTER IS CLEARED BETWEEN TURNAROUNDS. Section 7's Y3, and the
// ONLY thing that catches it -- because a stale counter produces no
// behavioural symptom until it happens to cross a threshold.
property p_cleared_when_idle;
  @(posedge clk) disable iff (!rst_n)
    !waiting |-> (elapsed == 0);
endproperty
assert property (p_cleared_when_idle);

// C2 -- AND IT ADVANCES ONCE PER BIT TIME WHILE WAITING.
property p_counts_while_waiting;
  @(posedge clk) disable iff (!rst_n)
    (waiting && !response_seen && !give_up && !pkt_end && !bus_reset)
      |=> (elapsed == $past(elapsed) + 1);
endproperty
assert property (p_counts_while_waiting);

R2 is the unusual one and the most valuable. It asserts that an input does nothing — which looks like a waste until you notice that pkt_start is in the port list, is obviously related, and is exactly what §7's Y2 wires up.

An input that is deliberately unused is a decision, and a decision that is not written down will be reversed by the next person who reads the port list.

B3 is the property that cannot fail, given a passing elaboration check — and it is worth keeping anyway. It catches a different defect with the same symptom: a counter that reaches the threshold early through a counting bug rather than through a parameter error. Two causes, one symptom, and only one of them is a build-time question.

9. Verification

This chapter's commit point is nobody gave up on anybody who was on time.

Stimulus. Every response delay from 0 to WAIT_MIN + 2, exhaustively — so the boundary at RESP_MAX and the one at WAIT_MIN are each hit from both sides. Repeated against packets of 1, 8, 64 and 255 bit times, because §4's defect is invisible at a single packet length. Plus 300 randomised turnarounds, and a separate illegal-parameter elaboration.

Observation. The two verdicts and the counter, per bit time — plus three obligations checked independently of the design: an in-budget response is never rejected, an over-budget one is never accepted, and the host never gives up before the round trip has elapsed. All three are stated in the protocol's terms, not the design's.

Reference model. None for the counter, deliberately — a second counter would share every assumption. The three obligations do the work, and the parameter relationship is checked by the tool rather than by a model.

Coverage — crosses:

• response delay × packet length — every delay from 0 to 18, at four packet lengths
• delay exactly at RESP_MAX, one below, one above
• delay exactly at WAIT_MIN, one below, one above
• consecutive turnarounds with no idle between them
• bus reset mid-turnaround
• parameter sets: legal, and illegal by one bit time — as separate elaborations

Negative cases with defined outcomes: an in-budget response is never rejected; an over-budget one is never accepted; the host never gives up before the round trip; the counter is never non-zero while idle; and an illegal parameter set never elaborates.

10. Debugging: the Cable That Broke the Device

A device works perfectly on the bench. In the field, on long cables through a hub, it fails — transactions time out and retry constantly, throughput collapses, but data is never corrupted. Shorter cables fix it. The customer's cable is within specification.

What does never corrupted tell you? That signal integrity is fine. The bits that arrive are the right bits. The problem is when they arrive, not what they are.

What changes with cable length? §3: propagation, at roughly 5 ns/m each way. A 5 m cable adds about 50 ns of round trip — which at full speed is under one bit time and at high speed is 24 bit times, more than the entire response budget.

So is the device too slow? Measure it. If the device responds within its budget measured from the last bit of the inbound packet, the device is compliant and the fault is in the budget the host allows — §2's ordering failure.

But the host is compliant too. Both are, individually. The pair is not, because the guard band was sized for a topology shorter than the customer's.

Whose defect is it? §3's answer: the device's, if its CABLE_BT assumption was the bench cable rather than the worst case the specification permits. A design that sized its guard band from the cable on the desk has encoded the bench into the silicon.

What is the confirming measurement? Scope both ends. Time from the last bit at the device to the first bit of its response, and separately from the last bit at the host to the moment it gives up. If the first is inside the budget and the second is shorter than the first plus the observed round trip, the ordering is violated and the numbers prove it.

And why does the hub matter separately? Because it adds delay in both directions, and §3's limit on the number of hubs exists for exactly this reason. A topology that adds a hub has changed a timing parameter, not just a connector.

The signature to keep: timeouts that scale with cable length and disappear with short cables are a guard-band problem, not a signal problem — and the device is usually at fault for having sized the band against its own bench.

11. Common Misconceptions

12. Reason It Through

A controller is being retargeted from a 60 MHz to a 120 MHz internal clock. The turnaround counter is specified in the design as “48 counts”, which was correct at 60 MHz for full speed. The team doubles it to 96 and moves on.

Is doubling right? For full speed at 120 MHz, yes — the same wall-clock interval needs twice as many faster counts.

What has been lost? The unit. The design now says 96 counts, which is a number meaningful only at 120 MHz and only at full speed. §1's rule has been broken twice over: the specification's quantity is 16 bit times, and nothing in the RTL says so any more.

What breaks next? The next change to either the internal clock or the link speed. At high speed a bit time is 40× shorter, so the same 16 bit times is a completely different count — and nothing in the design records the relationship that would let anybody derive it.

What should the parameter have been? The bit time in internal clock cycles, derived from the two rates, with the window expressed as a multiple of it:

localparam int BT_CYCLES  = CLK_HZ / LINE_RATE_HZ;
localparam int WAIT_MIN_C = 16 * BT_CYCLES;

Now which changes are safe? Both — a clock change and a speed change each update one input to an unchanged expression. And a combination that does not divide evenly becomes a build-time error rather than a rounding error, which is §7's lesson applied to a different parameter.

Is there a catch? Yes, and it is worth stating: CLK_HZ / LINE_RATE_HZ is not an integer at every combination. A 100 MHz clock against 12 Mbit/s is 8.33 cycles per bit. Which is exactly the case that must not be silently truncated — and the honest handling is a build-time check that the division is exact, or an explicit decision to round up and document the resulting margin.

And the general point: a magic number is a unit that was discarded. Every constant in a timing path should be traceable to a quantity the specification states, through an expression a reader can check — because the next person to change the clock will not have the conversation that produced 96.

13. Understanding Check

14. Summary

Every timing rule here is in bit times, because the bit rate varies by 320× across the three speeds and the kernel's own arithmetic is done the same way. At high speed the device's window is about 15 ns and the host's patience about 35 ns.

The turnaround is two bounds, not one: the device must respond within its budget, the host must wait at least its period — and WAIT_MIN must exceed RESP_MAX plus the round trip. When either bound is broken the system retries and stays correct; when the ordering is broken the host abandons devices that were never late, systematically, with every participant individually compliant.

The round trip scales with topology, not speed. Cable propagation is a physical constant, so 5 m is ~25 ns each way at every rate — 0.04 bit times at low speed and 12 at high speed. A guard band sized on a short bench cable has encoded the bench into the silicon.

And the window is measured from the packet's last bit. Measuring from the first makes it shrink as the packet grows: §7 measured 176 of 194 in-time responses rejected, with the failure rate rising monotonically with packet length — visible only because the sweep ran at four different lengths.

Two other mutations: a timer never cleared, caught only by a direct check on its idle value because it produces no behavioural symptom until it happens to cross a threshold; and a boundary off by one, which rejects a device that meets its budget exactly — the smallest defect measured and the likeliest to ship, because nothing sits on the boundary until somebody optimises.

And the fourth is the chapter's argument. Removing the build-time check on the parameter ordering changed nothing in simulation. Violating the ordering deliberately showed the same defect at three costs: an elaboration error at time zero, 58 run-time failures, or a field failure where every component measures as compliant.

A relationship between parameters is decided before simulation begins. The only honest place to check it is where it is decided.

§9 closes Module 12 with the catalogue: eleven distinct ways a passing bench has been wrong across eleven chapters — a compressed timeline, an ungeneratable malformed packet, an unobserved layer, and an unattempted illegal build being Module 12's four additions. Not one was a wrong expected value, and every one was found by breaking the design on purpose.

15. What Comes Next

Module 12 has built a transaction out of stages and bounded it in time. Everything in it assumed the bits arrive — that a packet's boundaries are found, its bits recovered, and its ones and zeros distinguished from an idle wire.

None of that is free, and it is the subject of the modules that follow: how a bit is encoded so that a receiver can recover a clock from it, how a packet's start and end are marked on a wire with no separate clock, and how a device that was just plugged in works out what speed to talk at before it can talk at all.

The clk in §6 that ticked once per bit time was an abstraction over all of it.

Browse the full path on the USB tutorials index.