You are asked to design the packet format for a new link between two chips. It must carry reads, writes and their responses. Someone suggests just sending the address and data. Within ten minutes of discussion the list of things the receiver needs to know has grown to: what kind of packet this is, how long it is, who it is for, which earlier request it answers, whether it arrived intact, and whether it is the next one in sequence.

What goes in a packet besides the payload, and where does each piece belong?

The obvious answer, and why it breaks

The obvious packet is pure data: address and value, nothing more. It breaks the moment the receiver needs to do anything but store it. It cannot tell a read from a write, cannot find the end of a variable-length payload, cannot match a response to its request, and cannot tell whether the bits arrived intact. Each missing piece forces either a separate wire (fine on chip, expensive off chip) or a field in the packet. Packet design is deciding which pieces the receiver needs, and where they go.

The idea: header, payload, trailer

Two more choices shape every format:

• Fixed or variable length. Fixed-size packets (or cells) make buffers and timing simple but waste space when messages are small. Variable-length packets fit the data but need a length field or a delimiter, and buffers sized for the largest packet.

• Alignment and padding. Hardware reads fields fastest when they sit at fixed positions and on natural boundaries (a 32-bit field on a 32-bit boundary). Formats therefore pad fields and payloads to multiples of the bus width, trading a few wasted bits for much simpler logic.

Build it: DCLink step 1

DCLink, the small protocol you build through this course, starts here. Each packet is one 32-bit header flit (the unit sent per transfer) and 0 to 15 payload flits. The header's top four bits are the packet type (write, read, completion) and the next four are the number of payload flits. The receiver finds every packet boundary by reading the previous packet's length, the length-field framing of lesson 2.2. The model packs three packets into one stream, parses them back, then flips one bit in the first length field.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

"""DCLink step 1: framing packets by a length field.

A packet is one 32-bit header flit followed by 0 to 15 payload flits. The header
carries the packet type in bits 31:28 and the number of payload flits in bits 27:24.
The receiver finds every packet boundary by reading the length of the one before.
"""
TYPES = {0: "WR", 1: "RD", 2: "CPL"}


def pack(ptype, payload):
    assert 0 <= len(payload) <= 15
    return [(ptype << 28) | (len(payload) << 24)] + list(payload)


def unpack(flits):
    packets, i = [], 0
    while i < len(flits):
        hdr = flits[i]
        ptype, n = hdr >> 28, (hdr >> 24) & 0xF
        packets.append((TYPES.get(ptype, f"?{ptype}"), flits[i + 1 : i + 1 + n]))
        i += 1 + n                                  # the next header starts right after
    return packets


stream = pack(0, [0xAAAA0001, 0xAAAA0002]) + pack(1, []) + pack(2, [0xBBBB0001])
print("stream:", " ".join(f"{f:08x}" for f in stream))
good = unpack(stream)
for t, p in good:
    print(f"  {t:3} with {len(p)} payload flits: {[f'{x:08x}' for x in p]}")
assert good == [("WR", [0xAAAA0001, 0xAAAA0002]), ("RD", []), ("CPL", [0xBBBB0001])]

bad = list(stream)
bad[0] ^= 1 << 24                                   # one bit flip in the first length field
print("same stream with one bit flipped in the first length field:")
for t, p in unpack(bad):
    print(f"  {t:3} with {len(p)} payload flits")
print("PASS: length framing recovers every packet; one bad length field misframes the rest")

It prints:

stream: 02000000 aaaa0001 aaaa0002 10000000 21000000 bbbb0001
  WR  with 2 payload flits: ['aaaa0001', 'aaaa0002']
  RD  with 0 payload flits: []
  CPL with 1 payload flits: ['bbbb0001']
same stream with one bit flipped in the first length field:
  WR  with 3 payload flits
  CPL with 1 payload flits
PASS: length framing recovers every packet; one bad length field misframes the rest

The good stream parses perfectly: 02000000 is a write (type 0) with 2 payload flits, 10000000 a read with none, 21000000 a completion with one. Now look at the corrupted run. One flipped bit turned the write's length from 2 into 3, so the receiver swallowed the read's header as payload, and the read disappeared without any error being reported. That is lesson 2.2's warning in miniature, and the reason DCLink will gain a CRC and sequence numbers in Part 10.

The design space

How real protocols chose

What breaks

A packet format puts its CRC in the header, computed over the payload, to keep all control fields together (illustrative). The sender must now compute the CRC before sending the first word, so it has to buffer the entire payload first. Latency rises by a full packet time, and the transmit buffer must hold the largest packet. The fix moved the CRC to a trailer, so the packet could stream out while the CRC was computed alongside. Field placement is not cosmetic: it decides buffering and latency.

Key takeaways

• A packet is a header (what the receiver needs first), a payload, and a trailer (what can only be computed last, such as a CRC).

• Fixed versus variable length and alignment versus packing trade simplicity against efficiency.

• Length framing without a check silently misframes after one bad bit: DCLink will need a CRC.

Related topics

• Part 2 overview: Encoding and Framing

• Lesson 0.7: Layering and the End-to-End Argument