A receiver has locked to the line and is producing a perfect stream of bits. It still cannot do anything with them. Is this bit the first bit of a byte or the third? Is this byte part of the packet that just started, or the beginning of the next one? Bits without boundaries are like a book with every space and full stop removed.
How does a receiver find where each message starts and ends?
The obvious answer is to count: agree on a message size, and every N bits starts a new message. That works until one bit is lost or gained, from a glitch, a clock slip or a dropped symbol, and then every boundary after it is wrong, forever. Counting alone gives the receiver no way to notice that it has lost its place, let alone recover. A framing method must let the receiver find boundaries in the stream, and find them again after an error.
Every protocol uses one of five methods, or a combination:
Method | How the boundary is marked | Recovers after an error by | Cost |
|---|---|---|---|
Idle + start bit | The line rests at a known level between messages; a change marks the start | Waiting for the next idle period | Idle time between messages |
Delimiter | A unique pattern that cannot appear inside data marks the start (and sometimes the end) | Searching for the next delimiter | Data must be prevented from forming the pattern (stuffing or special symbols) |
Length field | A header says how long the message is; the next one starts right after | Only with help from another method: a lost length misframes everything after it | A header field |
Sync header | Every fixed-size block starts with a short pattern that is checked continually | Slipping until the pattern is found in many blocks in a row (lesson 2.8) | A few bits per block |
Explicit last flag | A side signal marks the last word of a message | Nothing to recover: on chip, words are never lost | One wire |
Flip one bit in the framing information of a long stream and follow what the receiver does:
Method | One corrupted boundary causes |
|---|---|
Idle + start | One bad message; the next idle period resynchronises |
Delimiter | One or two bad messages; the next delimiter resynchronises |
Length field alone | Every later message is misframed: the receiver reads data as headers, and keeps going wrong |
Sync header | One bad block; if errors continue, the receiver drops lock and hunts again |
Last flag (on chip) | Two messages merge or one splits; there is no recovery mechanism, because on chip this should not happen |
This is why length fields almost never stand alone on an unreliable link. Protocols pair them with a method that can resynchronise (a delimiter, a sync header or a start-of-packet symbol) and protect the length with a CRC so a bad one is detected before it is used (lesson 2.3).
If... | Prefer | Because |
|---|---|---|
Messages are short and occasional, the line can idle | Idle + start bit | Simplest; every message resynchronises |
Variable-length messages on an unreliable serial link | Delimiter (plus stuffing or special symbols) | Self-resynchronising |
A continuous high-speed stream | Sync headers on fixed blocks, plus delimiters or lengths inside | Continuous checking; fast loss detection |
Variable-length packets on a reliable or protected path | Length field | No scanning: the receiver knows where the next packet starts |
On-chip streams | Last flag | Words are never lost on chip; one wire is cheapest |
Protocol | Framing |
|---|---|
UART | Idle high; each character starts with a low start bit and ends with a high stop bit. |
Ethernet | A 7-octet preamble of alternating 1s and 0s, then a start frame delimiter (10101011) marks the start of each frame; frames are separated by an inter-frame gap of 96 bit times. |
10 Gb/s Ethernet (64b/66b) | A 2-bit sync header (01 or 10) on every 66-bit block, checked continually; control blocks inside mark frame starts and ends. |
AXI-Stream | An explicit last flag: TLAST marks the last transfer of a packet. |
DCLink (this course) | A length field in the header (lesson 2.3), on a link that will gain a CRC (lesson 10.11). |
A design carries packets with a length field over a serial link with no other framing (illustrative). It works for weeks. Then a single bit error hits a length field: the receiver reads the next 14 words of data as packets, finds a "header" with a length of 9 in the middle of a payload, and stays misaligned. Thousands of packets are lost before a timeout resets the link.
Symptom: a long burst of nonsense after a single error, ending only with a reset.
Root cause: length framing cannot resynchronise by itself.
Fix: add a resynchronising method (a start-of-packet symbol or a sync header), and check the header with a CRC before trusting its length.
Because the receiver would see a false boundary in the middle of a message. Protocols prevent it with stuffing (lesson 2.4) or by making the delimiter a symbol that data cannot encode (lesson 2.9).
At most that character and perhaps the next: the line returns to idle after the stop bit, and the next start bit resynchronises the receiver.
So a corrupted length is detected and the packet is discarded before the receiver uses the bad length to find the next boundary.
Receivers find message boundaries by idle and start bits, delimiters, length fields, sync headers or an explicit last flag.
What matters on an unreliable link is how framing recovers after an error; length fields alone cannot.
On chip, a last flag is enough because nothing is lost; serial links combine a resynchronising method with lengths and CRCs.