Course map
- 1 lesson
Starts with How to Use This Course
- 1 lesson
Starts with Reading Paths
- 1 lesson
Starts with Concept Map
- 1 lesson
Starts with How to Read the Diagrams
- 10 lessons
Starts with A Protocol Is a Contract
- 11 lessons
Starts with Common-Clock Interfaces
- 12 lessons
Starts with Line Codes
- 13 lessons
Starts with Valid-Only Streams
- 17 lessons
Starts with Why Flow Control
- 19 lessons
Starts with Reads and Writes Are Not Symmetric
- 17 lessons
Starts with Latency, Throughput and Bandwidth
- 13 lessons
Starts with Why Ordering Matters
- 12 lessons
Starts with Shared Media and Topologies
- 13 lessons
Starts with Deadlock, Livelock and Starvation
- 20 lessons
Starts with Error Models
- 10 lessons
Starts with Reset Semantics
- 8 lessons
Starts with Idle Detection
- 9 lessons
Starts with Why Coherence
- 7 lessons
Starts with Access Attributes
- 11 lessons
Starts with Writing an Interface Contract
- 17 lessons
Starts with How to Dissect a Protocol
- 5 lessons
Starts with Read Any Spec
- 6 lessons
Starts with The Reasoning Framework
About this course
Most protocol courses teach one specification: signal names, encodings, timing tables. This course teaches what every specification is answering. From a UART to CXL, every protocol has to decide when data is valid, where a message starts, whether the receiver is ready, how much may be in flight, in what order results appear, who gets the wire, why it might hang, and what happens when bits go wrong. The answers change from protocol to protocol. The questions do not.
Learn the questions, the possible answers and the trade-off behind each, and you can read a new specification in a day, explain why AXI, PCIe or I2C made the choices they did, and design and defend a protocol of your own.
What you will be able to do
Read an unfamiliar protocol specification in a day and know what to look for.
Explain the reason behind the main design choices of AXI, PCIe, I2C, DDR, CHI, Ethernet, USB and UCIe.
Size buffers, credits, tags and replay windows from bandwidth and latency.
Debug a hang, a lost transfer or a throughput collapse from a waveform by reasoning about the protocol.
Answer senior and principal interview questions that have no single-protocol answer, and design a small protocol from requirements.
Four levels on every page
Badge | Level | Who | What a page gives you |
|---|---|---|---|
F | Foundation | 0–3 years | The problem, the mechanism, a clear picture, one worked example |
W | Working | 3–6 years | Rules, corner cases, runnable code, failure modes, how to verify |
S | Senior | 6–10 years | Sizing maths, trade-off tables, cross-protocol comparison, debug method |
P | Principal | 10+ years | Design-space reasoning, what a reviewer must ask, how the choice ages |
Each lesson carries its lowest level badge, and every lesson ends its teaching with a Senior or Principal lens, so experienced readers get something from the foundation pages too. See reading paths for routes by role.
The parts
Part | Title | The question | Lessons | Status |
|---|---|---|---|---|
0 | What is a protocol, really? | 8 | 8 ready | |
1 | When is the data valid? | 9 | 9 ready | |
2 | Where does a message start and end? | 10 | 10 ready | |
3 | Is the receiver ready? | 11 | 11 ready | |
4 | How much may I send before I hear back? | 15 | 15 ready | |
5 | What exactly is being asked? | 17 | 17 ready | |
6 | How many requests can be in flight? | 15 | 15 ready | |
7 | In what order do results become visible? | 11 | 11 ready | |
8 | Who gets the wire? | 10 | 10 ready | |
9 | Why can it hang? | 11 | 11 ready | |
10 | What if bits go wrong? | 18 | 18 ready | |
11 | How do the two sides agree at start-up? | 8 | 8 ready | |
12 | How do we save power without losing data? | 6 | 6 ready | |
13 | What if there are several copies of one value? | 7 | 7 ready | |
14 | Who is allowed to ask? | 6 | 6 ready | |
15 | How do we know it is correct? | 10 | 10 ready | |
16 | How do real protocols answer the fifteen questions? | 15 | 15 ready | |
17 | Can you apply all of it? | 5 | 5 ready | |
18 | Can you explain it under pressure? | 6 | 6 ready |
How the course is built
One picture that keeps coming back. A sender, a channel and a receiver with a return path. Each part adds its idea to that same figure: a ready signal, a credit counter, a replay buffer.
DCLink, a protocol you build. Twelve steps across the course turn a bare wire into a small protocol with handshakes, credits, transactions, tags, ordering, arbitration, deadlock freedom, replay, start-up and low power.
Real simulations. Every waveform comes from a simulation of the code on the page, and every number in a plot comes from a model on the page.
Real protocols as evidence. Each lesson shows how two to four real protocols answered its question, and why their constraints led there.