SuperSpeed (SS)

Every mode so far has been an alternative to the others. Low and Full Speed differ by qualified decisions; High Speed is a second electrical world on the same pair. In all three cases exactly one mode is active on the conductors at a time, and moving between them means leaving one behind.

SuperSpeed is not an alternative. It runs on the additional pairs Chapter 4.3 described, which the earlier modes do not use at all — so it does not displace them and they do not constrain it.

That single structural fact changes what active mode means, and this chapter is about the consequences.

1. A Mode With Its Own Conductors

The defining property is structural rather than electrical.

SuperSpeed operates on separate differential pairs, distinct from the D+/D- pair the earlier modes share. Its signalling scheme, termination and line behaviour are its own, and Chapter 4.6 §2 established that it also carries its own line code where the earlier modes carry none.

Two consequences follow that have no precedent in this module so far.

It does not contend for the earlier modes' conductors. There is no handshake by which SuperSpeed displaces High Speed, because there is nothing to displace — the pairs are different. Chapter 4.3 §2 called this coexistence rather than fallback, and here is where the distinction becomes operational.

Two modes can therefore be active on one connection at the same time. A device may present capability on the SuperSpeed path while remaining reachable on the older pair, and both paths can be doing something. That is not possible for any pair of modes examined earlier.

2. What the Envelope Buys, and What It Demands

Read SuperSpeed as an envelope, in the Chapter 5.1 sense.

It buys a nominal 5 Gbit/s signalling rate on dedicated pairs, with a data-flow model that Chapter 2.6 noted differs from the classic one — traffic is routed toward an addressed device rather than forwarded to enabled ports, and a device may asynchronously signal readiness rather than being polled while idle.

It demands considerably more. Dedicated conductors through connectors, cables and boards. A PHY with clock recovery and line coding the earlier modes never required. A controlled, terminated channel, because Chapter 3.8 established that a small swing is affordable only when the channel is good. And a link that is brought up through a process of its own — which Module 20 owns and this chapter deliberately does not describe.

The envelope framing makes the asymmetry visible. Low Speed's bundle was cheap devices and restricted capability. SuperSpeed's is high capability and demanding physical requirements. Both are coherent; they sit at opposite ends of a cost axis, and a device chooses the bundle that matches what it is.

3. Per-Path Mode State

Chapter 5.3 §4 argued for centralising the active mode. Figure 1 refines that: centralise per path, not per connection.

A controller supporting both therefore holds two independent mode states — one for the classic path, which is Low, Full or High Speed or none, and one for the SuperSpeed path, which is SuperSpeed or none. Each has its own validity, its own establishment, and its own invalidation.

Three properties matter.

They are independent. One path being inactive says nothing about the other. A device operating on the classic path with no SuperSpeed established is ordinary, and so is the reverse.

They fail independently. Chapter 3.8 §7 noted that a device can fail on the newer path and work on the older one, because the two depend on different physical qualities. Per-path state is what lets a controller represent that rather than collapsing it into a single confused answer.

And a single “current mode” register would be wrong. Not merely imprecise — wrong, because it cannot represent a legitimate state of the system. Any design that reduces both paths to one value has lost information it needs.

4. Requested Versus Active, Now Per Path

Chapter 5.3 §2's distinction compounds here.

Software requests capability; each path independently establishes or does not; and the observed result is two answers, either of which may differ from the request. A test that asked for SuperSpeed and got classic operation is the Chapter 4.3 §8 scenario — a capable device on a capable host running the older path because the interconnect did not provide the newer one, with nothing reported because that is a correct connection.

So a verification environment cannot ask what mode is active? It must ask it of a path, and it must ask it twice. An environment holding a single mode variable has already made the §3 modelling error, and will report confidently on a system it cannot represent.

5. A Mode Observer, as a Verification Model

The RTL in Chapter 5.3 was controller logic. This one is not — it is a verification model, and the distinction is part of the lesson.

// ─────────────────────────────────────────────────────────────────────────
// usb_mode_observer
//
// Classification: VERIFICATION MODEL. This is testbench logic, not a DUT
// and not synthesizable intent. It exists to be instantiated beside a
// design and to answer, from observation alone, what is actually active.
//
// WHAT IT MODELS. Section 3's per-path mode state as a checker: it records
// what was REQUESTED, observes what each path ESTABLISHED, and reports
// disagreement. Its whole purpose is to make "we asked for SuperSpeed" and
// "SuperSpeed is running" separately visible, because an environment that
// conflates them cannot detect a fallback.
//
// WHAT IT DOES NOT MODEL. Any establishment mechanism -- it observes
// outcomes only; link bring-up, which Module 20 owns; any USB protocol;
// and any timing. The classic-path mode encoding is borrowed from Chapter
// 5.3's package purely so the two chapters agree.
// ─────────────────────────────────────────────────────────────────────────
module usb_mode_observer
  import usb_mode_pkg::*;
(
  input  logic      clk,
  input  logic      rst_n,

  // What the test asked for. An intention -- never used to qualify checks.
  input  logic      req_superspeed,

  // Observed from the DUT's own reporting, per path. Levels, per Chapter
  // 5.3's contract: asserted while that path has a mode established.
  input  usb_mode_e classic_mode,
  input  logic      classic_valid,
  input  logic      ss_active,

  // ── Observations the environment should act on ─────────────────────────
  output logic      any_path_active,
  output logic      both_paths_active,   // legitimate, and worth covering
  output logic      fell_back,           // SS requested, classic got it instead
  output logic      nothing_established   // requested something, got nothing
);

  assign any_path_active   = classic_valid || ss_active;
  assign both_paths_active = classic_valid && ss_active;

  // THE OBSERVATION THAT MATTERS. Requested SuperSpeed, did not get it, and
  // a classic path came up instead. This is a legitimate system outcome --
  // not an error -- which is exactly why it must be OBSERVED rather than
  // assumed away: a test that assumed its request was granted is now
  // checking SuperSpeed expectations against classic operation.
  assign fell_back = req_superspeed && !ss_active && classic_valid;

  assign nothing_established = req_superspeed && !any_path_active;

  // A tiny amount of state, purely so the environment can report at the end
  // of a run rather than only sampling instantaneously.
  logic seen_fallback_q, seen_both_q;
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      seen_fallback_q <= 1'b0;
      seen_both_q     <= 1'b0;
    end else begin
      if (fell_back)         seen_fallback_q <= 1'b1;
      if (both_paths_active) seen_both_q     <= 1'b1;
    end
  end

endmodule

Models. Per-path observation, and the requested-versus-established comparison that a single-mode environment structurally cannot make.

Hardware implied. None — it is a verification model. Naming that explicitly matters, because the same code written as DUT logic would be a design that decides things, and this one only reports.

Assumptions. That the DUT exposes per-path mode and validity to the environment, and that validity is a level per Chapter 5.3's contract.

Does not model. Establishment, link bring-up, protocol or timing — it observes outcomes only.

How it is used. fell_back is not an error flag. It is a coverage and diagnosis signal: a run in which it asserted was checking a different mode than the test intended, and an environment that does not surface it will report a pass on expectations that were never exercised.

6. The Assertions

// ─────────────────────────────────────────────────────────────────────────
// Environment-side properties for usb_mode_observer.
//
// Classification: TEACHING ASSERTIONS about the ENVIRONMENT's model, not
// about the DUT's protocol behaviour. They check that the observer's view
// is self-consistent, which is what makes its reports trustworthy.
// ─────────────────────────────────────────────────────────────────────────

// O1 -- fallback and success are mutually exclusive. If both could assert,
// the environment's own view is incoherent and every conclusion drawn from
// it is suspect.
property p_fallback_excludes_ss;
  @(posedge clk) disable iff (!rst_n)
    fell_back |-> !ss_active;
endproperty
assert property (p_fallback_excludes_ss);

// O2 -- "nothing established" must mean no path is active. A checker that
// could report nothing established while a path was running would hide the
// very condition it exists to surface.
property p_nothing_means_nothing;
  @(posedge clk) disable iff (!rst_n)
    nothing_established |-> !any_path_active;
endproperty
assert property (p_nothing_means_nothing);

// O3 -- THE ONE WORTH HAVING. Both paths active concurrently must be
// treated as legitimate and never as an error. Written as a coverage-facing
// property: if an environment is tempted to assert this away, that is the
// section 3 modelling error appearing as a checker.
property p_both_active_is_legal;
  @(posedge clk) disable iff (!rst_n)
    both_paths_active |-> (classic_valid && ss_active);
endproperty
assert property (p_both_active_is_legal);

O3 looks tautological and is doing real work, because its purpose is to state, in executable form, that concurrent per-path activity is a legal system state. An environment whose author believed only one mode could be active would have written the opposite property — and would then have flagged correct behaviour as a failure. The most valuable thing an assertion sometimes does is record what is permitted.

7. Verification and Debug

Stimulus must include partial capability, because that is where the per-path model earns itself: a device presenting only classic capability; a path where SuperSpeed is requested and unavailable; and both paths available and active.

Observation is per path, always. The environment records two answers and compares each against what was requested.

The crosses that matter:

• requested × classic established × SuperSpeed established, including every disagreeing combination
• both paths active concurrently — the case §3 says a single-variable environment cannot even represent
• SuperSpeed failing while classic succeeds, per Chapter 3.8 §7
• detach on one path while the other remains active

For debug, the question must name a path. What mode is this in? is ambiguous here. The productive form is which paths are active, and for each, what was established versus requested? — and a fallback is then visible as a specific, named disagreement rather than as a vague underperformance.

And the instrument caution compounds. A protocol analyser configured for one path sees that path. Chapter 3.8 §4's rule that no instrument sees another's abstraction now has a second axis: an instrument may also be looking at the wrong path, and its silence is not evidence about the other one.

8. Common Misconceptions

9. Reason It Through

A test requests SuperSpeed, attaches a SuperSpeed-capable device, and passes. Investigation of an unrelated issue reveals that the connection was running the classic path throughout.

How did it pass? Because the test checked behaviour that both paths implement — device enumeration, a control transfer, a data exchange — and those succeeded on the classic path exactly as they would have on SuperSpeed. The device model is unchanged across paths, which is a strength of the architecture and precisely what allowed the test to be satisfied by the wrong thing.

What did the test actually establish? That the device works. Not that SuperSpeed works, and not that SuperSpeed was reachable — neither of which it observed.

Why is this worse than a failing test? Because it produced a confident pass on an untested configuration. A failure would have prompted investigation; a pass closed the item. And the coverage report will show the SuperSpeed test as executed.

What would have caught it? §5's observer. fell_back asserts the moment SuperSpeed is requested, does not come up, and the classic path does — and an environment surfacing that would have reported the run as not having exercised what it claimed.

What is the general principle? A test must verify that it ran under the conditions it assumed. Where a system can legitimately satisfy a request with something other than what was asked for — which is the whole of graceful degradation — passing says nothing about which thing was tested unless the environment observed it.

10. Understanding Check

11. Summary

SuperSpeed runs on separate differential pairs with its own signalling, termination and line code, at a nominal 5 Gbit/s. Because it does not use the classic modes' conductors it does not displace them — it coexists, and two modes can be active on one connection simultaneously.

That makes mode a property of a path rather than of a connection. A controller holds two independent mode states, each with its own establishment, validity and invalidation; they fail independently, because the paths depend on different physical qualities; and a single current-mode register is wrong rather than imprecise, since it cannot represent a legal system state.

Chapter 5.3's requested-versus-active distinction compounds: there are now two observed answers, either of which may differ from the request, and an environment holding one mode variable cannot represent what it is testing.

The verification model makes that visible. Falling back is a legitimate outcome, not an error — so it must be observed, and a run in which it occurred was checking different expectations than the test intended. The assertion worth writing is the one recording that concurrent per-path activity is legal, because an engineer assuming otherwise would have asserted the opposite and flagged correct behaviour.

And the discipline it produces: a test must verify that it ran under the conditions it assumed. Wherever a system may legitimately satisfy a request with something else, a pass says nothing about which thing was tested.

12. What Comes Next

SuperSpeed established the pattern of a mode owning its own path. What it did not address is what happens above it, and the tiers above are where the most confusing terminology in USB lives.

Chapter 5.5 takes SuperSpeed+ and the tiers beyond it — the rate steps, the use of multiple lanes, and what scaling within one architectural family costs. It is also where this module's verification thread reaches its conclusion, because each additional tier multiplies the configuration space that Chapter 4.5 warned never retires — and where the module hands over to enumeration, since a link that is up and running in a known mode still has not told the host what is actually attached to it.

Browse the full path on the USB tutorials index.