“USB 3.x Is Just Faster USB 2.0”

    THE CONNECTOR FITS
    A USB 2 plug goes into a USB 3 receptacle and works. Nothing about
    the physical experience suggests two different things.

    THE SOFTWARE DID NOT CHANGE
    The same driver, the same libusb calls, the same descriptors, the
    same endpoint numbers, the same standard requests, the same
    transfer types with the same names. An application ported from USB
    2 to USB 3 often changes NOTHING.

    THE MODEL SURVIVES
    Endpoints are still (number, direction). Enumeration still goes
    Default, Address, Configured. The host still schedules. Bulk is
    still bulk. EVERYTHING this curriculum has taught for thirty
    modules remains true.

    THE MARKETING IS ENTIRELY NUMERIC
    "SuperSpeed", "5 Gbps", "10 Gbps", "20 Gbps". Every public
    description of USB 3 is a bandwidth figure. Nobody advertises a
    change of transaction model, because nobody buys one.

    THE NAMING ACTIVELY HELPS THE BELIEF
    USB 3.0 became USB 3.1 Gen 1 became USB 3.2 Gen 1x1, and the same
    5 Gbps link has had three names. A reader concludes, reasonably,
    that the versions differ only in speed grade.

    IF USB 3 WERE FASTER USB 2, THEN:

    1  a cable that carries USB 2 correctly would carry USB 3
       correctly, just with more of it

    2  a hub would be a hub -- one device, one internal architecture,
       repeating faster

    3  a USB 2 device in a USB 3 port would get some of the benefit,
       or at worst none, but would be on the same bus as its
       neighbours

    4  USB 3 failures would look like USB 2 failures, faster:
       corrupted packets, retries, timeouts

    5  polling a device would work the same way, so an idle USB 3
       device would cost roughly what an idle USB 2 device costs

    6  a device that enumerates at USB 2 speed in a USB 3 port has a
       SPEED problem

    COUNT THE WIRES

      USB 2 uses        D+ and D-                     one half-duplex
                                                      differential pair
      USB 3 adds        SSTX+ SSTX- SSRX+ SSRX-       TWO pairs, one per
                                                      direction, full
                                                      duplex
    And the USB 2 pair is STILL THERE and still used.

    A USB 3 connection is therefore not a faster bus. It is TWO BUSES
    operating simultaneously in one cable:
      o  different differential pairs
      o  different signalling and encoding
      o  different link state machines
      o  different transaction models
      o  and a device may be using either, or in some cases both

    Inspect the descriptors of a USB 3 hub as the host sees it:

      it presents as TWO hub devices
        o  a USB 2 hub, on the D+/D- bus
        o  a SuperSpeed hub, on the SS pairs

      with separate downstream port state, separate routing, and
      separate topology. 31.1's tier limit applies to each of them.

    USB 2, an idle interrupt endpoint
      the host issues an IN token every interval, forever.
      The device answers NAK. (31.2 -- this is the whole of 31.2.)
      The bus is never quiet, and the device is never asleep.

    USB 3, an idle endpoint
      the host issues a request ONCE. The device does not answer "not
      yet" repeatedly -- it responds when it is ready, asynchronously.
      The link enters a low-power state between activity and leaves it
      when there is something to carry.

    OBSERVED, constantly, in the field
      a USB 3 device in a USB 3 port, working, at USB 2 speed

    WHAT HAPPENED: SuperSpeed connection was not established, so the
    device fell back to the bus that was available. It then enumerated
    normally, presented its descriptors, opened its pipes and worked.

    CAUSES, none of which are a "speed problem"
      the cable lacks or breaks the SuperSpeed pairs
      an intermediate hub is USB 2 only
      the port is wired for USB 2 on that particular header
      SuperSpeed link training did not complete
      the device's own SS pairs are not connected on the board

    AND THERE IS NO ERROR. Fallback is CORRECT BEHAVIOUR -- it is
    exactly what makes the connector's compatibility promise work.

    WHAT CARRIED OVER (and the belief is right about all of it)
      o  endpoints as (number, direction)
      o  descriptors, configurations, alternate settings
      o  enumeration: Default, Address, Configured
      o  the four transfer types, by name and by purpose
      o  the host's authority to schedule and authorise
      o  the driver and application interface

    WHAT DID NOT
      o  ONE BUS became TWO, physically separate, simultaneously
        operable, sharing a connector
      o  half duplex on one pair became full duplex on two
      o  host-polls-and-device-NAKs became request-and-asynchronous-
        response, which is what makes link power management possible
      o  one hub became two hubs in one package, with separate
        topologies
      o  a fallback path exists that is SILENT and CORRECT

    THE SENTENCE TO REPLACE THE BELIEF WITH
      "USB 3 preserved the programming model and replaced the
       mechanism. So my software ports, and my assumptions about the
       WIRE, the POWER, the TOPOLOGY and the FAILURE MODES do not."

    WHAT WOULD HAVE TO BE MODELLED TO REFUTE THIS BELIEF IN HARDWARE

      two PHYs with different encodings, because the belief's error is
        that there is one
      two link state machines, including SuperSpeed link training and
        its power states
      the fallback DECISION -- which is where the misconception
        actually lives
      two transaction models running simultaneously

    WHAT SUCH A MODEL WOULD ACTUALLY TEACH

      Nothing about the misconception. It would teach the reader to
      read my simplification of two PHYs. The belief is not that some
      block computes the wrong function; it is that TWO THINGS ARE ONE
      THING -- an error of counting, not of logic.

    AND THE DISHONEST VERSION IS WORSE

      A "dual-bus arbiter" written for this chapter would be RTL
      manufactured for symmetry: it would look rigorous, add a passing
      simulation and a mutation table to the page, and misrepresent
      the architecture, because a real USB 3 device does not arbitrate
      between the two buses -- they operate independently.

    WHAT THE MODULE'S FOUR SPECIMENS DID, AND WHY THAT WAS DIFFERENT

      31.2  resp_valid = token_valid           who may start a
                                               transaction -- a
                                               structural fact
      31.3  idx = {tok_is_in, tok_ep}          what identifies an
                                               endpoint -- an encoding
      31.4  bulk sees only what remains        an allocation ORDER
      31.5  fn_ep_en = attached && CONFIGURED  a gate

    Each of those four beliefs is a claim about a FUNCTION that some
    block computes, so each becomes a line of RTL and each becomes a
    one-line mutation that is the belief verbatim. This belief is not
    of that kind, and pretending otherwise would be the worse error.

    SYMPTOM      "our USB 3 device is slow"

    WRONG MODEL  one bus, running below its rated speed
    WRONG QUESTION   why is our throughput low?
    WASTED ON        buffer sizes, packet sizes, queue depths, driver
                     tuning, DMA, the firmware's transfer loop -- all
                     of which are irrelevant if the device is on the
                     other bus

    CORRECT MODEL  two buses; one of them may not have established
    THE FIRST QUESTION, and it takes one command:
                 WHICH BUS IS THIS DEVICE ON?
                 (the host reports the negotiated speed -- lsusb -t on
                  Linux, the USB tree in Device Manager on Windows,
                  System Information on macOS)

    and the two answers are two unrelated investigations:

      operating at USB 2 speed   -> SuperSpeed never established.
                                    Cable, hub, port wiring, board
                                    routing of the SS pairs, link
                                    training. NOT a throughput problem
                                    and nothing in the device's data
                                    path is implicated.

      operating at SuperSpeed    -> now it is a throughput question,
                                    and 31.4 applies: what else is on
                                    this controller, and how much
                                    periodic bandwidth is committed?

    SYMPTOM      "it works on my desk and not in the enclosure"

    WRONG MODEL  a cable either works or it does not
    THE OBSERVATION  compare the NEGOTIATED SPEED in both places, not
                     the throughput
    TYPICAL CAUSE    the enclosure's front-panel header, its internal
                     cable, or an internal hub is USB 2 only

    A cable that "works" is not a cable that carries both buses. There
    are four more wires, and they fail independently and silently.

    1  COUNT
       List every conductor in a USB 3 cable and say which bus each one
       belongs to.

    2  THE HUB
       Draw a USB 3 hub with one USB 2 device and one USB 3 device
       attached, showing which internal hub each connects through.

    3  POLLING
       Explain why USB 2 could not have link power management even at
       USB 3 data rates.

    4  FALLBACK
       A device negotiates USB 2 speed in a USB 3 port. List five
       causes, and say which of them are in the device.

    5  COMPATIBILITY
       USB 3 could have emulated USB 2 over the new PHY instead of
       keeping the old pair. Argue both sides, and name the
       misconception each choice would have produced.

    6  CARRY-OVER
       For each of 31.1 through 31.5, state whether its correction is
       still true on USB 3 and why.

    7  NO RTL
       Section 6 argues that this belief is not the kind that becomes a
       line of RTL. Construct the strongest counter-argument, then say
       what a reader would actually learn from the block you proposed.

    8  DEBUG
       Write the two-command diagnostic you would give a support team
       for "our USB 3 device is slow", and say what each command rules
       out.

    9  DESIGN REVIEW
       Write the 30.4-style review question that would catch a board
       whose SuperSpeed pairs are routed without regard to length
       matching.

   10  THE WHOLE MODULE
       Pick the belief from this module that you have personally held,
       and write the prediction you made because of it.

    THE CORRECTION
    o  USB 3 preserved the PROGRAMMING MODEL and replaced the
       MECHANISM. Both halves matter.
    o  there are TWO BUSES in the cable, physically separate, operable
       at the same time, sharing a connector and an address space
    o  half duplex on one pair became full duplex on two
    o  host-polls-and-device-NAKs became request-and-asynchronous-
       response, and THAT is what makes link power management possible
    o  a USB 3 hub is two hubs, with separate topologies
    o  fallback to USB 2 is CORRECT, SILENT and ERRORLESS -- which is
       what makes the connector's promise work and what makes the
       misconception expensive

    WHY NO RTL
    o  this belief is a MISCOUNT, not a wrong function. The other four
       beliefs in this module are each a claim about something a block
       computes, so each became one line and one mutation. This one
       would have become a "dual-bus arbiter" that misrepresents an
       architecture in which the two buses do not arbitrate at all.
    o  RTL manufactured for symmetry looks like rigour and teaches the
       reader your simplification instead of the subject

    THE DEBUG CONSEQUENCE
    o  "our USB 3 device is slow" -> which bus is it on? One command.
       Two answers, two unrelated investigations, and only one of them
       is about throughput.
    o  a cable that "works" is not a cable that carries both buses

    THE SIX, AND WHAT EACH ONE COSTS

    31.1  point-to-point only        looks for a bus conflict that
                                     cannot exist
    31.2  devices initiate           asks "why isn't the device
                                     sending" -- a question with no
                                     answer
    31.3  endpoints are ports        debugs a buffer that no name
                                     reaches
    31.4  bulk is always fastest     quotes an idle-bus number as a
                                     specification
    31.5  enumeration is optional    debugs a perfect data path that
                                     was never reached
    31.6  USB 3 is faster USB 2      tunes throughput on a device that
                                     is on the other bus

    NOT ONE OF THEM PRODUCES A WRONG BIT. Every one of them produces a
    CONFIDENT WRONG QUESTION, which is far more expensive, because a
    wrong answer gets corrected and a wrong question gets pursued.

    Each belief was encoded as a one-line mutation and scored:

      P-M1  1,098      D-M1     48      S-M1    218      E-M1  1,246
      P-M2      3      D-M2     58      S-M2     78      E-M2     22

    The four "whole belief" mutations score high because a
    misconception is not a corner case -- it is wrong nearly
    everywhere. Removing the dedicated intent phase took 1,098 to 236
    and 1,246 to 437, not to zero.

    So: NOBODY SHIPS THESE BELIEFS. Build one and nothing works.

    They survive in the heads of people DEBUGGING correct hardware,
    where there is no testbench, no assertion and no mutation score --
    only a prediction, and no habit of noticing when it was wrong.

    THE FOUR VERIFICATION PRINCIPLES THIS MODULE MEASURED

    1  A DUT and a reference model written by the same person from the
       same sentence are ONE artefact. 31.4's missing clamp was found
       by an intent check while the design and its model agreed.

    2  An INTENT CHECK states the claim in the architecture's own terms
       and consults no model -- which is the only kind of check that
       can express "these two must DIFFER" (31.3) or "this must stay
       silent for 200 cycles" (31.2, 31.5).

    3  Exhaustive is exhaustive over THE AXES IT HAS. 31.3's fifth axis
       and 31.4's "below / at / above" axis each exist because a
       specific misconception was named first.

    4  A property that a CORRECT design violates is the most precise
       statement of a misconception available -- 31.4 §8 writes one
       down and never enables it.

    WHERE TO GO FROM HERE

    o  Module 30 is the review procedure. Run it on something real --
       your own design, or an open-source USB core -- and record what
       the checklist found that reading did not.
    o  Module 27 is the interview set. The answers in this module's
       section 12s and 8s are written the way an answer should sound.
    o  Modules 21-26 are the RTL and verification build. If you have
       read without building, that is the gap.
    o  And the habit worth keeping is the smallest thing in the track:
       when a system does not do what you expect, ask what your model
       PREDICTED before asking what the system did wrong. Six times in
       this module, the prediction was the defect.