Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Paths
  • Concept Map
  • How to Read the Diagrams
  • Part 0: What Is a Protocol?10
  • Part 1: Timing and Clocking11
  • Part 2: Encoding and Framing12
  • Part 3: Handshakes13
  • Part 4: Flow Control17
  • Part 5: Transactions19
  • Part 6: Concurrency and Performance17
  • Part 7: Ordering13
  • Part 8: Sharing and Arbitration12
  • Part 9: Deadlock and Liveness13
  • Part 10: Reliability and Recovery20
  • Part 11: Bring-Up and Link Management10
  • Part 12: Power8
  • Part 13: Shared State and Coherence9
  • Part 14: Security and Isolation7
  • Part 15: Specifying and Verifying11
  • Part 16: Protocols Dissected17
    • How to Dissect a Protocol
    • UART
    • SPI
    • I2C
    • APB
    • AHB
    • AXI4
    • AXI-Stream
    • PCI Express
    • DDR
    • CHI
    • Ethernet
    • USB
    • UCIe
    • CXL
    • Protocols Compared: Protocols Dissected
    • Drills: Protocols Dissected
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 16: Protocols Dissected
  1. Topics
  2. First Principles of Hardware Protocols
  3. Part 16: Protocols Dissected
  4. USB

Part 16 · Protocols Dissected · Working (W)

USB

USB dissected through the twenty questions (USB 2.0 mainly): a host that schedules every transaction, devices that speak only when polled, NAK as flow control, a one-bit sequence number, four transfer types with different guarantees, hot-plug and enumeration. A protocol designed so that devices can be cheap.

On this page

    Note

    Level: Working (W) · Answers: How do real protocols answer the fifteen questions?

    Before this: Ethernet, Enumeration and Discovery

    A keyboard, a webcam, a flash drive and a microphone share one USB port through a hub. None of them ever starts a conversation. The host asks each one, in a schedule it controls: "any keystrokes?", "next video packet", "next block". A busy device says "not yet" and is asked again later. Putting all the scheduling in the host is what lets a USB mouse cost less than its cable.

    How does USB answer each question when the host decides everything?

    Constraints first: what USB had to work with

    Constraint

    USB

    C1 Distance and medium

    Cables of a few metres, connectors, hubs

    C2 Bandwidth and latency

    1.5 to 480 Mb/s for USB 2.0 (fact S25); bounded latency for periodic devices

    C3 Wires

    One differential data pair (USB 2.0) plus power

    C4 Topology

    A tiered star: one host, hubs, many devices

    C5 Who builds each side

    Any vendor; devices must be cheap; USB-IF certification (fact P37)

    The device never initiates: it answers tokens. NAK is flow control; the DATA0/DATA1 toggle lets the device and host detect a retried duplicate.

    USB's answers to the fifteen questions

    Each answer links to the lesson that explains the idea behind it.

    #

    Question

    Answer

    1

    When is the data valid?

    No separate clock: receivers recover timing from transitions, guaranteed by bit stuffing (fact S2) (1.4)

    2

    Where does a message start and end?

    Packets start with SYNC and a packet ID and end with end-of-packet; NRZI with bit stuffing (facts S2, S25) (2.3)

    3

    Is the receiver ready?

    Devices answer the host's tokens with ACK, NAK (not ready) or STALL (fact S25) (3.6)

    4

    How much may I send before I hear back?

    NAK is flow control: a device that cannot take or give data says so and the host retries later (fact S25) (4.2)

    5

    What exactly is being asked?

    Four transfer types: control, bulk, interrupt and isochronous, each with different guarantees (fact S25) (5.1)

    6

    How many requests can be in flight?

    On a USB 2.0 bus the host runs one transaction at a time, scheduled into frames and microframes (fact S25) (6.3)

    7

    In what order do results become visible?

    In order per endpoint (7.1)

    8

    Who gets the wire?

    The host schedules everything and reserves bandwidth for periodic transfers, at most 80% of a high-speed microframe (fact S25) (8.7)

    9

    Why can it hang?

    Devices never initiate, so they cannot deadlock each other; a device that NAKs for ever stalls only its own transfers, and host software times out (9.9)

    10

    What if bits go wrong?

    CRC5 on tokens, CRC16 on data; retry for all but isochronous; DATA0/DATA1 toggling, a one-bit sequence number, discards duplicates (fact S25) (10.10)

    11

    How do the two sides agree at start-up?

    The host detects attach, resets the port, and enumerates the device at address 0 (fact T24) (11.6)

    12

    How do we save power without losing data?

    Suspend with remote wake-up; USB 3.x adds U1, U2 and U3 link states (fact S19) (12.6)

    13

    What if there are several copies of one value?

    Not applicable

    14

    Who is allowed to ask?

    Not addressed by the protocol: the host trusts what a device reports about itself

    15

    How do we know it is correct?

    USB-IF certification (fact P37) (15.8)

    The choices that define USB

    • Host-centric: all scheduling, bandwidth allocation and intelligence in the host; devices only respond.

    • Transfer types as guarantees: isochronous trades reliability for timing, bulk trades timing for reliability.

    • A one-bit sequence number: with one transaction outstanding per endpoint, DATA0/DATA1 is enough to catch duplicates.

    • Plug and play: hot-plug, enumeration and descriptors are part of the protocol from the start.

    What breaks

    A device (illustrative) did not toggle its data PID correctly after a host retry. When an ACK was corrupted, the host resent the token, the device sent the same data again with the same PID, and the host, expecting the other PID, accepted it as new: one block was duplicated in a file. Correct DATA0/DATA1 toggling, which exists exactly for this case, fixed it.

    Why this matters

    Senior lens. USB shows the trade of putting all intelligence on one side, the opposite of DDR's direction: here the host is complex and devices are cheap. Its transfer types are a compact lesson in guarantees: isochronous accepts loss for bounded timing, bulk accepts delay for reliability. When reviewing a USB device, check data toggling across retries, NAK behaviour and suspend and wake.

    Interview

    Asked: "How does USB 2.0 avoid duplicated data when an ACK is lost?"

    Weak answer: It uses a CRC.

    Strong answer: With data toggling, a one-bit sequence number. Data packets alternate between DATA0 and DATA1 per endpoint. If the host's ACK is corrupted, the device doesn't toggle and resends with the same PID when polled again; the host sees a PID it already accepted, discards the duplicate and ACKs again. One bit suffices because each endpoint has only one transaction outstanding at a time. Isochronous transfers skip all this: no handshake, no retry, because timing matters more than every packet.

    Follow-ups: (1) Why is one bit enough? (2) Why does isochronous have no retry?

    Check yourself Why can a USB 2.0 device not deadlock another device?

    Devices never initiate; the host schedules every transaction, so no device waits on another.

    Check yourself A webcam uses isochronous transfers. What happens to a packet with a bad CRC?

    It is lost: isochronous has no handshake or retry; the application tolerates the loss.

    Key takeaways

    • USB is host-centric: devices speak only when polled; NAK is flow control.

    • Four transfer types give different guarantees; DATA0/DATA1 is a one-bit sequence number.

    • Hot-plug, enumeration and suspend with remote wake are built in.

    Keep going

    Next: Lesson 16.14, UCIe. Die-to-die links inside one package: short reach, flits, CRC and retry.

    Related topics

    • Part 16 overview: Protocols Dissected

    Previous

    219 / 234

    Next: UCIe

    Up next

    Up nextUCIe

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • How to Dissect a Protocol
    • UART
    • SPI