An engineer opens a 1,200-page protocol specification on their first day on a new project. Read front to back, it is a wall of signal tables, state machines and exceptions. Read with a list of questions in hand (when is data valid? who may send? what happens to an error?), it becomes a set of answers, each one a choice the designers made for a reason. The rest of this part reads fourteen real protocols that way.
How do you read an unfamiliar protocol quickly and understand why it is the way it is?
The obvious approach is to read the specification in order and memorise the details. Specifications are organised for implementers, by layer and signal, not by the questions you have. Details memorised without their reasons do not transfer: the next protocol has different signal names and you start again. What transfers is the set of questions every protocol must answer, and the trade-offs between the possible answers.
Every protocol is a set of answers to the same questions, shaped by its constraints. Start with the constraints, because they explain most of the answers:
# | Constraint question | Why it matters |
|---|---|---|
C1 | What distance and medium? (on-chip wires, a board, a cable, a package) | Sets clocking, encoding and error rates |
C2 | What bandwidth and latency targets? | Sets width, pipelining, concurrency and buffering |
C3 | How many wires or pins? | Serial or parallel; shared or dedicated signals |
C4 | What topology, and how many agents? | Point-to-point, bus, switched; arbitration and addressing |
C5 | Who builds each side, and must they interoperate? | Negotiation, compliance, how strict the rules must be |
Then the fifteen questions of this course, one per part:
# | Question | Explained in |
|---|---|---|
1 | When is the data valid? | |
2 | Where does a message start and end? | |
3 | Is the receiver ready? | |
4 | How much may I send before I hear back? | |
5 | What exactly is being asked? | |
6 | How many requests can be in flight? | |
7 | In what order do results become visible? | |
8 | Who gets the wire? | |
9 | Why can it hang? | |
10 | What if bits go wrong? | |
11 | How do the two sides agree at start-up? | |
12 | How do we save power without losing data? | |
13 | What if there are several copies of one value? | |
14 | Who is allowed to ask? | |
15 | How do we know it is correct? |
"Not addressed" is an answer. AXI has no retransmission; UART has no flow control in its frame. Knowing what a protocol leaves to the system is as useful as knowing what it does.
Look for the alternative. Every mechanism rejects another: credits instead of ready, invalidate instead of update. Naming it shows you understand the trade.
Explain from the constraints. If an answer does not follow from C1 to C5, either the protocol made a mistake or you missed a constraint, often history and compatibility.
Question | DCLink's answer |
|---|---|
C1 to C5 | On-chip or package; moderate bandwidth; few wires; point-to-point hops; one team builds both sides |
Handshake (3) | Valid/ready on each hop (step 2) |
Flow control (4) | Credits per hop (step 3) |
Concurrency (6) | Four tags, out-of-order completion (step 5) |
Deadlock (9) | Separate request and completion credit pools (step 8) |
Reliability (10) | CRC-8, sequence numbers, go-back-N replay (step 9) |
Bring-up (11) | Capability exchange, minimum of both sides (step 10) |
Verification (15) | Checker, monitor, per-tag scoreboard (step 12) |
Each line names a mechanism and points at the lesson that justifies it. The pages that follow do the same for real protocols, all fifteen questions each.
If you want | Read |
|---|---|
Foundations | UART, SPI, I2C and APB: simple protocols where every answer is visible |
On-chip buses | AHB, AXI4, AXI-Stream, then CHI |
High-speed links | PCI Express, Ethernet, USB, then UCIe and CXL |
Memory | DDR |
A team (illustrative) integrating a new interface read its specification for signal names and timing only, and assumed errors would be retried as on their previous protocol. This one reported errors and left recovery to the requester; their requester ignored error responses, and corrupted data reached software. Asking question 10 ("what if bits go wrong?") on day one would have found it.
It tells you what the system around the protocol must provide, such as retries or flow control, which is where integration bugs hide.
Short distance (C1): on a chip or a small board, a shared clock is practical.
Read any protocol with twenty questions: five constraints, then its answer to each of the fifteen.
For each answer, name the mechanism, the alternative it rejected, and the constraint behind the choice.
"Not addressed" is an answer: it shows what the system must supply.