USB Backward Compatibility

One question has been deferred at every step of this module and referenced repeatedly: when a host, a device, a cable and a port each have their own capability, what actually happens?

This chapter answers it, and in doing so takes apart the phrase the module has been careful never to use loosely. “Backward compatible” is not a property a specification has. It is a claim that means different things at different layers, that is delivered by at least two genuinely different mechanisms, and that describes an outcome no single participant controls.

The chapter's practical payoff is a model you can compute with, and the assertion that catches the most damaging bug in this area.

1. Which Layer?

Start by refusing the unqualified statement. This is backward compatible is incomplete in the same way this is fast is incomplete: it omits the dimension.

Two rows deserve emphasis.

The device-model row is why any of this works. Chapter 4.1 §3 identified it as the load-bearing commitment and Chapter 4.5 showed it was never rebuilt. Compatibility at every other layer is a choice each generation made; compatibility at this one is the invariant that made the choices worth making.

The power row is not a generation property. A port's data capability and its power capability are separate facts that happen to arrive on the same connector. Module 19 owns power; the only claim here is that inferring one from the other is unsound, and it is a common enough error to be worth stating in a compatibility chapter specifically.

2. Two Mechanisms, Not One

Chapter 4.3 §2 introduced this distinction; here it earns its own section because the two mechanisms fail differently.

Fallback — generation two's approach. One medium, several arrangements, the two ends negotiate down to one both support. Compatibility is achieved by agreement at connection time.

Coexistence — generation three's approach. Separate media, all present, each carrying its own architecture. Compatibility is achieved by the old path never going away.

The failure signatures differ, which is the operationally useful part. A fallback failure tends to be loud: the connection does not settle, or settles somewhere unexpected. A coexistence failure tends to be quiet: everything works, at the older capability, with nothing reported — because a connection on the older path is a perfectly correct connection.

USB4 uses both, which is worth noticing. Its USB 2.0 pair is coexistence; the capability tiers within its own link involve negotiation. Modern USB is not one compatibility mechanism but a stack of them.

3. Effective Capability Is an Intersection

Here is the model the rest of the chapter computes with.

No single participant determines what a connection does. The host has a capability, the device has a capability, and the interconnect — the cable, the connector, and every hub in the path — has one too. What the connection actually runs is bounded by all of them together:

          host capability
                ∩
        device capability
                ∩
     interconnect capability
                ∩
      architecture's own rules
                ↓
       effective capability

Three consequences follow, and all three are practical.

A label describes one participant, never the system. “This is a 10 Gbit/s device” states one term of an intersection. It is true and it does not predict the outcome.

The weakest participant governs. A capable host and a capable device on an inadequate cable operate at what the cable supports — which is Chapter 4.3 §8's scenario, and why a cable swap is such an informative experiment.

And hubs are participants, not wires. A hub in the path contributes its own capability to the intersection. A newer device behind an older hub is bounded by the hub, which is why Chapter 2.7 §5's advice to vary topology is a capability experiment as well as a physical one.

4. The Model in Hardware

The intersection is small enough to write, and writing it makes one bug impossible to miss.

// ─────────────────────────────────────────────────────────────────────────
// capability_intersect
//
// Classification: CONCEPTUAL ARCHITECTURE ABSTRACTION. Synthesizable, but
// it is NOT a USB negotiation engine and implements no USB mechanism.
//
// WHAT IT MODELS. Section 3's intersection, plus the rule that matters most
// in practice: a participant must never SELECT a capability it does not
// itself support. The bitmap positions are opaque tiers -- they carry no USB
// semantics and are deliberately not named after generations.
//
// WHAT IT IS NOT. There is no negotiation protocol, no chirp, no link
// training, no timing, and no notion of how any participant's capability was
// discovered. Real USB establishes capability through mechanisms owned by
// Chapter 3.7 and Modules 5 and 20; this block assumes the answers have
// already arrived and only computes what follows from them.
//
// A generation is not an enumeration value and support is not a parameter --
// see Chapter 4.5. The tiers here are ordered capability bits, nothing more.
// ─────────────────────────────────────────────────────────────────────────
module capability_intersect #(
  // Number of ordered capability tiers. Bit 0 is the most basic tier and
  // must be supported by every participant for a connection to exist at all.
  parameter int N_TIERS = 4
) (
  input  logic               clk,
  input  logic               rst_n,

  // One bit per tier, set where that participant supports that tier.
  input  logic [N_TIERS-1:0] host_caps,
  input  logic [N_TIERS-1:0] device_caps,
  input  logic [N_TIERS-1:0] link_caps,     // cable, connector, hubs in path

  output logic [N_TIERS-1:0] common_caps,   // what all three support
  output logic [N_TIERS-1:0] selected,      // one-hot: the chosen tier
  output logic               no_common      // no tier is supported by all
);

  logic [N_TIERS-1:0] common_c;
  assign common_c = host_caps & device_caps & link_caps;

  // Highest common tier, as a one-hot select. Priority from the top down:
  // the best capability everyone can actually deliver.
  logic [N_TIERS-1:0] sel_c;
  always_comb begin
    sel_c = '0;
    for (int i = N_TIERS - 1; i >= 0; i--) begin
      if (common_c[i] && (sel_c == '0)) sel_c[i] = 1'b1;
    end
  end

  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      common_caps <= '0;
      selected    <= '0;
      no_common   <= 1'b0;
    end else begin
      common_caps <= common_c;
      selected    <= sel_c;
      // NOT an error to be silently tolerated. If no tier is common, there
      // is no valid connection, and reporting that is the only honest
      // outcome -- selecting something anyway is the bug section 6 traces.
      no_common   <= (common_c == '0);
    end
  end

endmodule

What it models. The intersection, the selection of the best commonly supported tier, and the explicit no common capability outcome.

Why the structure exists. common_c is an AND across all three participants because §3's bound is conjunctive — every participant constrains independently. The selection scans downward so the outcome is the best tier everyone can deliver rather than the best any one of them claims. no_common is a distinct output rather than a silently-zero selected, because there is no valid connection here is information, and a design that quietly selects something anyway is the §6 failure.

Hardware implied. Two AND arrays, a priority encoder, three registers.

State retained. Only the registered outputs — the intersection itself is combinational, because it is a function of its inputs and has no history.

Assumptions. That all three capability vectors are valid, stable and already synchronised into this domain, and that tiers are ordered with bit 0 most basic. How any participant's capability was discovered is outside the model.

What DV should verify. That selected is always a subset of every input vector; that it is one-hot or zero; that no_common and a non-zero selected are mutually exclusive; and that the tier chosen is genuinely the highest common one rather than merely a common one.

What it deliberately omits. All of USB. No negotiation, no timing, no discovery, no link training — and the tiers are unnamed on purpose, because naming them after generations would suggest a generation is an enumeration value, which Chapter 4.5 argued against at length.

5. The Assertions

// ─────────────────────────────────────────────────────────────────────────
// Assertions for capability_intersect.
//
// Classification: ARCHITECTURAL TEACHING ASSERTIONS about capability
// reasoning. They prove nothing about USB compliance.
// ─────────────────────────────────────────────────────────────────────────

// C1 -- THE CENTRAL ONE. A selected tier must be supported by EVERY
// participant. The bug it catches is a component advertising or selecting a
// capability its datapath cannot execute -- which produces a connection that
// is established and then does not work, and whose symptom appears far from
// the advertisement that caused it.
property p_selected_is_universally_supported;
  @(posedge clk) disable iff (!rst_n)
    (selected != '0) |->
      ((selected & $past(host_caps))   != '0) &&
      ((selected & $past(device_caps)) != '0) &&
      ((selected & $past(link_caps))   != '0);
endproperty
assert property (p_selected_is_universally_supported);

// C2 -- exactly one tier, or none. A multi-hot selection means two tiers
// are simultaneously active, which downstream logic will resolve by some
// accident of priority rather than by design.
property p_selection_is_onehot0;
  @(posedge clk) disable iff (!rst_n)
    $onehot0(selected);
endproperty
assert property (p_selection_is_onehot0);

// C3 -- "no common capability" and "a tier was selected" are mutually
// exclusive. Reporting both is a contradiction that lets software believe a
// connection exists while hardware believes it does not.
property p_no_common_excludes_selection;
  @(posedge clk) disable iff (!rst_n)
    no_common |-> (selected == '0);
endproperty
assert property (p_no_common_excludes_selection);

C1 is the assertion this chapter exists to produce. Stating it as the selection must be present in all three input vectors makes it independent of how the selection was computed, so it holds against any implementation and fails against every variety of the over-claiming bug.

C2 and C3 guard the degenerate outcomes, which are easy to get wrong precisely because they are the paths nobody exercises deliberately: a selection with no valid answer, and a contradiction between two outputs that are supposed to describe the same situation.

6. The Bug This Catches

A device advertises support for a capability tier its datapath cannot actually sustain. The host, device and cable all report the tier as available, so it is selected. The connection establishes successfully — and then misbehaves under load.

Why is this the worst class of compatibility bug? Because everything reports success. There is no failure to negotiate, no fallback, no error at connection time. The system did exactly what it was told, using information that was wrong.

Why does the symptom appear far from the cause? Because the advertisement happens at connection time and the consequence appears during operation, possibly much later and only under conditions that stress the claimed capability. The evidence linking them is not co-located in time or in layer.

What makes it so persistent? It often passes testing. A device that over-claims by one tier works acceptably under light load — the datapath keeps up when it is not being pushed — and fails under exactly the conditions a functional test is least likely to sustain.

And why is C1 the right protection? Because it constrains the relationship between what was selected and what each participant claimed, so it fires wherever a selection exceeds a claim. It cannot catch a participant whose claim was itself untrue — no logic can, since the claim is the input — but it catches every case where the selection exceeds the claims available, which is where the mechanism can be wrong rather than the data.

The residual risk is worth naming honestly. If a device's advertised capability is simply a lie, this model faithfully computes a wrong answer from wrong inputs. Capability reasoning is only as sound as the capability information, and the guard against that is not an assertion but compliance testing and interoperability work — which is Chapter 1.6 §10's argument about why standardisation makes such testing economically possible.

7. Verification

The compatibility dimension is a matrix, and the method is more valuable than any particular filled-in table.

Build the matrix from participants, not from labels. Host capability × device capability × interconnect capability, with the expected result being the highest common tier rather than anything either endpoint claims alone.

The rows that matter most are the asymmetric ones. New device on old host and old device on new host are different paths through the logic, not mirror images, and it is easy to test one and assume the other.

Include the degenerate rows. No common tier at all — which must be reported, not silently resolved. And a participant claiming a tier the others do not, which must not be selected.

Cross it with the dimensions the earlier chapters contributed:

• capability matrix × topology, since a hub is a participant in the intersection
• capability matrix × attach order, including re-attachment at a different capability, which is Chapter 4.5 §7's churn
• capability matrix × reset, since state scoped to the previous selection must not survive
• capability matrix × concurrent tenant, for a link carrying other protocols

And the coverage that finds real bugs is the cross, not the margins. Closing coverage on host capabilities and separately on device capabilities says nothing about the combinations — which is where every interesting compatibility failure lives.

8. Debugging a Capability Shortfall

A generation-aware debugging chain, which replaces the reflex to blame the PHY:

What does the host support?            -- a fact about the port, not the machine
        ↓
What does the device support?          -- claimed, and possibly untrue
        ↓
What does the interconnect support?    -- cable, connector, and every hub
        ↓
What was actually selected?            -- the intersection's output
        ↓
What does the controller believe?      -- registers and status
        ↓
What does software report?             -- a driver's interpretation of the above
        ↓
Where is the first disagreement?

The value is in the last line. Each level is separately observable, and a shortfall is localised by finding where two adjacent observations stop agreeing — not by inspecting any one of them alone.

And the observability caution from Chapter 3.8 §4 applies with full force. A software message naming a generation reports a driver's interpretation of controller status; it is not direct evidence that the physical layer operated in that mode. Equally, observing a physical mode does not establish that software configured the device correctly. The two ends of that chain are separate claims and require separate evidence.

9. Common Misconceptions

10. Reason It Through

A USB4-capable laptop, a USB 3.x hub, a USB 2.0 mouse and a cable of unknown provenance. The mouse works perfectly. Is this a compatibility success?

Compute the intersection for the mouse. The mouse supports one basic tier. The host supports it, the hub forwards it, and any conforming cable carries it. The intersection is that tier, it is selected, and the mouse operates exactly as designed. Yes — and by the narrowest possible margin, because the outcome is determined entirely by the mouse's single term.

Why is this the module's whole argument in one configuration? Because the mouse is being served by an architecture three generations newer than itself, through a hub one generation newer, over a link that can carry protocols the mouse has never heard of — and none of that is visible to it. It presents the same self-description, receives the same address, and is configured by the same framework Chapter 4.1 established.

What did that cost? Everything this module catalogued. The USB 2.0 pair present in every connection; the hub's translator; two protocol engines in the host; a tunnelling layer that must carry USB faithfully enough that the mouse cannot tell. Compatibility is not inherited — it is bought, generation after generation, and it is still being paid for.

Now change one thing: attach a 10 Gbit/s drive instead. The intersection becomes interesting. The host is capable; the drive is capable; the hub is a participant and bounds the result; the cable is unknown and bounds it too. The drive will operate at the highest tier common to all four, which may be well below what either endpoint could do — and nothing will report an error, because a connection at that tier is a correct connection.

What is the general lesson? A working connection proves the intersection was non-empty, nothing more. It says nothing about whether the result was the best available, and the distinction between working and performing as expected is exactly the distinction this chapter's model exists to make computable.

11. Understanding Check

12. Summary

“Backward compatible” is incomplete until it names a layer and a direction. Mechanical, electrical, protocol, device-model, software, performance and power compatibility are distinct claims with distinct answers — and power is not a generation property at all. The device-model row is why any of it works: never rebuilt across four generations, it is the invariant that made every other compatibility choice worth making.

Compatibility is delivered by at least two mechanisms. Fallback negotiates to a shared arrangement on one medium and fails loudly. Coexistence keeps the old path physically present and fails quietly, by running the older path with nothing reported. Modern USB uses both.

Effective capability is an intersection — host ∩ device ∩ interconnect ∩ the architecture's rules — so the weakest participant governs, a hub is a participant rather than a wire, and a label on any one participant states one term and predicts nothing.

The hardware model computes exactly that, selects the highest common tier, and reports no common capability as a distinct outcome rather than silently choosing something. Its central assertion — a selected tier must be present in every participant's claim — catches over-claiming in all its forms, and cannot catch a claim that is simply untrue, which is what compliance and interoperability testing exist for.

And the closing discipline: a working connection proves the intersection was non-empty, nothing more. Not that the result was the best available, not that the claims were honest, not that software configured what it thinks it did.

13. What Comes Next

Module 4 is complete. Four generations, the pattern connecting them — accretion at the bottom, nothing ever removed, the device model untouched — the rate and coding story underneath, and a model for reasoning about what any particular combination will actually do.

What this module has consistently treated as a single dimension is the speed modes themselves. Rates appeared as evidence of generational change; the codes that made them reachable were examined; and effective capability was computed over abstract tiers. But what a speed mode actually is — how Low, Full, High and the newer modes differ in how a device uses them, what each is suited to, and what choosing one commits a design to — has been deferred at every step.

Module 5 takes them as its subject. You now have exactly the right preparation for it: you know why there are several, you know what made each reachable, and you know that which one a connection runs is an intersection rather than a label.

Browse the full path on the USB tutorials index.