Full Speed (FS)

Chapter 5.1 introduced the envelope model and used Low Speed to show that a mode constrains architecture rather than merely timing. What it could not do is show the model's real value, because a single envelope examined alone still reads like a list of properties.

The model becomes useful when you can compare two envelopes and say exactly which commitments differ. That is this chapter, and the answer is smaller than most people expect: Full Speed and Low Speed share a great deal, and the differences are few, specific, and mutually supporting in the way §1 of the previous chapter described.

1. The Baseline, Not the Faster Option

Full Speed is worth understanding as the reference envelope. It is the mode the original architecture was designed around — Chapter 4.1 identified it as the capability that ordinary peripherals were expected to use — and Low Speed exists as a deliberate reduction from it for devices that did not need the whole thing.

That ordering matters for how you read the comparison. Low Speed is not Full Speed's predecessor and Full Speed is not an upgrade. They were defined together, as two points in one design, and the restrictions of Chapter 5.1 §3 are the difference rather than a deficiency.

Its nominal signalling rate is 12 Mbit/s — the unit caution from Chapter 4.6 §4 applying as always.

2. What the Two Modes Share

This list is longer than the difference list, which is the chapter's first point.

The same conductors and the same signalling framework. Both operate on the D+/D- pair using the line states Chapter 3.1 defined — J, K, SE0 and the illegal SE1 — with the same receiver structure observing them both differentially and single-endedly.

The same announcement mechanism. Both are announced by a pull-up's position, as Chapter 3.5 established: D+ for Full Speed, D- for Low Speed. One mechanism, one bit of information, two answers.

The same electrical arrangement in kind. Neither uses terminations; both rely on the pull-up/pull-down contest; both use the larger swing that Chapter 3.8 contrasted with the high-speed arrangement.

The same device model. Descriptors, addressing, configuration, classes — all of Chapter 4.1 §3's untouched framework. A Full-Speed device and a Low-Speed device are described to software identically.

The same host-owned transaction model, the same topology rules, the same hub arrangement.

Everything, in short, except the handful of items in §3.

3. What Actually Differs

Read the table as two groups.

The first four rows are electrical and follow from each other. A lower rate permits slower edges, slower edges permit cheaper cabling, and the pull-up position plus the polarity convention are the mechanism by which the two are told apart — the whole of Chapters 3.3 to 3.5.

The last three rows are architectural, and they are the interesting ones. Full Speed permits all four transfer types, where Low Speed permits two. It permits larger packets. It reaches further.

That middle row is the substantive difference between the modes, and it is why Chapter 5.1 §4 spent a section on the coherence of the restriction. Full Speed's envelope admits devices that stream and devices that move bulk data — printers, storage of modest size, audio — which is an entirely different population from keyboards and mice. The rate difference is eightfold; the capability difference is categorical.

4. The Polarity Row Deserves a Second Look

One row in §3 has a consequence disproportionate to its size, and Chapter 3.4 built a whole chapter on it: the J/K polarity convention inverts between the two modes.

That is worth revisiting here only for its mode consequence rather than its mechanism, which Module 3 owns. The consequence is this: two modes that share a signalling framework can still require mode-specific interpretation of it. A receiver decoding line states must be told which mode it is operating in, because the same physical condition carries different names in the two.

This is the first and simplest instance of the pattern that governs the rest of this module. Mode is not a parameter that scales something; it is information that downstream logic must consume. Chapter 5.3 makes that architectural, and it starts here, in the smallest possible form: one bit of mode selecting between two interpretations of one wire condition.

5. Implementation: What Changes and What Does Not

For a device, the choice between the two envelopes is a product decision with a narrow technical footprint. The analogue requirements differ, the clocking differs, the pull-up goes on the other conductor — and the device model, descriptors and class behaviour are identical. A device changes mode by changing very little, which is exactly what you would expect of two points in one design.

For a host controller, supporting both is cheaper than supporting one of these and a genuinely different arrangement, because the two share the electrical framework. What the controller must carry is the difference: mode-appropriate timing, the polarity convention of §4, and knowledge of which transfer types and packet sizes the mode permits.

And that is the shape of the cost. Supporting Low Speed alongside Full Speed is not a second implementation; it is a set of mode-qualified decisions inside one implementation — which is affordable, and which is also precisely the structure that Chapter 4.5 §4's state-isolation problem lives in. The next chapter's mode is not like this at all, and the contrast is the point.

6. Verification

Most of Chapter 5.1 §6's guidance carries directly, so this section names only what is different about verifying the two together.

The valuable stimulus is the pair, not either alone. Because the modes share so much, a single-mode environment exercises nearly all the shared logic and none of the mode-qualified decisions. The cases that matter are the ones where the two differ: polarity interpretation, permitted transfer types, packet-size limits.

The polarity cross is mandatory and easy to omit. Chapter 3.4 §6 showed that a decoder hard-coding the Full-Speed convention passes a complete Full-Speed regression and reports J and K exactly backwards at Low Speed. The stimulus that catches it is the same test run at both modes, which requires the environment to treat mode as a crossed dimension rather than a fixed configuration.

And the transfer-type cross is the architectural one. A Full-Speed device using all four types and a Low-Speed device restricted to two must both be exercised, including the refusal cases — because an implementation that permits a forbidden type will do so silently.

Representative coverage — the crosses, not the margins:

• mode × line-state interpretation, both polarities
• mode × transfer type, including forbidden combinations refused
• mode × packet size at and beyond each envelope's limit
• both modes active behind one hub simultaneously

7. Common Misconceptions

8. Reason It Through

A controller passes its entire Full-Speed regression. A Low-Speed device is attached and communication fails immediately, with no errors reported at the physical layer and legal line states throughout.

What does the absence of errors tell you? That nothing illegal is occurring on the wire — so the fault is not electrical and not a matter of malformed signalling. Legal states with wrong meaning is a specific signature.

Which of §3's rows could produce it? The polarity row. If the decoder applies the Full-Speed convention at Low Speed, every J is read as K and every K as J. Both are entirely legal states, so nothing flags it, and the result is a consistent, plausible, wrong interpretation of everything.

Why did the Full-Speed regression not catch it? Because at Full Speed the hard-coded convention is correct. The defect is not a corner of the tested space — it is outside it, which is why Chapter 3.4 §6 argued that mode must be crossed rather than fixed.

How do you confirm it in one observation? Compare the conductors against the reported line state while the port is idle. A Low-Speed port idles with D- higher and should report J; a report of K with those conductors settles it.

What is the general lesson? A fault that produces only legal outputs is invisible to legality checking, and the modes that share the most framework are the ones most able to hide such a fault — because sharing is exactly what makes a single-mode test appear to cover both.

9. Understanding Check

10. Summary

Full Speed is the reference envelope the architecture was designed around, at a nominal 12 Mbit/s, and Low Speed is a deliberate reduction from it rather than an earlier version of it.

The two share almost everything: conductors, line-state framework, announcement by pull-up position, electrical arrangement in kind, device model, transaction model and topology.

They differ in seven commitments, of which four are electrical and follow from one another, and three are architectural. The substantive one is transfer types — Full Speed permits all four, Low Speed two — which is a categorical difference admitting an entirely different population of devices. The eightfold rate gap is the least significant row.

The polarity row carries an outsized consequence: the J/K convention inverts, so a receiver must be told its mode before it can decode. Generalised, mode is information downstream logic must consume, not a parameter that scales something — the smallest instance of what Chapter 5.3 makes architectural.

Supporting both is one implementation with mode-qualified decisions, which is cheap precisely because the modes share so much — and which is not the general case, as the next chapter shows.

And for verification, that sharing is a trap: a single-mode regression exercises the common logic and none of the differences, so mode must be a crossed dimension rather than a fixed configuration.

11. What Comes Next

Everything so far has been two variations on one design. Both modes use the same conductors the same way, are announced by the same mechanism, and differ in commitments a single implementation absorbs as qualified decisions.

Chapter 5.3 breaks that. High Speed does not share the electrical arrangement — it terminates the line, uses a much smaller swing, and removes the pull-up that the previous two modes depend on for their very announcement. Supporting it alongside them is not a set of qualified decisions; it is a second electrical world with a transition between them.

That chapter is also where this module's central distinction gets built in hardware: the difference between the mode a system supports, the mode it requested, and the mode that is actually active — three things that testbenches and drivers conflate constantly, and that a controller must keep rigorously apart.

Browse the full path on the USB tutorials index.