Stop Bits, Frame Boundaries and Back-to-Back Frames

The frame now has an entry (Chapter 3.1), a payload (Chapter 3.2) and optionally a check (Chapter 3.3). It needs an end.

This is the field UART material most often describes wrongly, and the wrong descriptions are specific enough to name. The stop interval is said to resynchronise the clocks, or to give the receiver time to catch up, or to be dead time between characters. None of those is what it does, and each produces a different wrong expectation about how a link behaves.

What it actually is: a required mark condition of at least a configured duration, at a position the receiver knows, which the receiver checks. That is a smaller claim than the folklore and it does more work — because it is the check that turns a stream of intervals into a frame with a verifiable shape, and it is the requirement that makes the next frame detectable.

1. What the Stop Interval Requires

At the end of the payload — and after the parity interval if the configuration includes one — the framing requires the line to be at mark for at least a configured duration.

That is the whole requirement, and three features of it matter.

It is a level requirement, not an activity. The transmitter is not doing anything during the stop interval that it was not doing while idle; it is holding the same level. What makes the interval part of the frame is that the framing requires it there, at a position both endpoints can compute from the origin.

It has a defined position. The receiver knows exactly where it is — start, plus payload width, plus parity if present — because all of those are configuration it already has (Chapter 2.3 built the grid that locates it). The position is what makes the requirement checkable.

It has a minimum duration, not a maximum. The configuration says how long the line must be at mark before anything else may happen. It does not say the line must return to activity afterwards — idle is the same level, of unbounded length (Chapter 3.1). So the stop interval and the idle that may follow it are the same line state, distinguished only by whether the framing requires it.

2. Three Things It Is Not

Each of these is a common formulation, and each is wrong in a way that leads somewhere.

“It gives the receiver time to catch up.” There is nothing to catch up on. The receiver processes one interval per bit period throughout the frame and the stop interval is one more of those — it is not slack, and a receiver that needed recovery time would need it uniformly, not once per frame. What is true is that a receiver must move the assembled value somewhere before the next frame's payload overwrites it, and whether one interval suffices depends on what is above it — buffering, which is Module 10. That is a property of the receiver's surroundings, not of the stop interval.

“It is dead time between characters.” It is a checked position, and the check is the most useful diagnostic the framing provides. It is also not between frames — it is inside the frame it terminates, counted in N_frame and paid for in line time like every other field.

3. The Framing Error

If the receiver finds space at the stop position when the framing requires mark, it reports a framing error.

The name is precise and the precision matters: it reports that the frame did not end in the expected state. It does not report why, and the receiver has no way to determine why, because every cause produces the same observation.

A framing error is an observation, not a diagnosis. An engineer who treats the flag as "the baud rate is wrong" will be right often enough to keep believing it and will lose an afternoon the first time the real cause is a configuration mismatch.

Two things narrow it quickly. Whether the payload also looks wrong separates timing and configuration faults — which corrupt the payload too — from corruption confined to the stop interval. And whether it happens on every frame or intermittently separates systematic causes, which are configuration, from physical ones, which are not. That is the same diagnostic split Chapter 3.3 §8 drew for parity errors, and the two flags together are more informative than either alone.

4. The Frame Boundary and Back-to-Back Frames

Once the stop requirement is satisfied, the frame is over. The line is at mark, and the transmitter may do one of two things: continue holding mark, which is idle, or begin another frame.

There is no required gap. The next frame may begin in the interval immediately following the stop interval. The line goes mark — for the stop duration — and then straight to space for the next frame's start.

This is the arrangement that makes the §2 correction visible. In Figure 2 the next frame's origin arrives one interval after the stop check — the minimum possible. In a link with a long idle gap it arrives much later. The receiver's timing behaviour is identical in both cases, because what supplies the origin is the transition, and a transition is not improved by having been preceded by more mark.

If the stop interval genuinely resynchronised anything, those two cases would differ: more mark would mean more resynchronising. They do not differ, and that is a testable prediction rather than an argument.

5. Stop Duration Is a Configuration Choice

How long the mark condition must last is configurable, and the available choices are a capability of a particular implementation rather than something the framing fixes.

Commonly offered options are one stop interval and two; some implementations also offer one and a half, which is the historical arrangement associated with certain narrow payload widths. Which of these a given UART supports, and in which payload configurations, belongs to its documentation.

What matters architecturally is what a longer stop requirement costs and buys.

It costs line time. Two stop intervals rather than one adds one to N_frame — the difference between 10 and 11 intervals in a common configuration, which Chapter 3.5 computes as a throughput change.

It buys margin before the next entry and a longer window over which the mark condition must hold — which makes the check slightly less likely to pass by accident on a marginal link. It does not buy timing correction, for the reasons in §2.

The two endpoints need compatible expectations, and not identical ones. A transmitter sending two stop intervals to a receiver expecting one satisfies the receiver's requirement — the receiver checks its position, finds mark, and is content; the extra mark interval simply looks like idle. The reverse fails: a receiver expecting two stop intervals, given one, may find the next frame's start transition where it expects the second stop interval and report a framing error. The asymmetry is worth knowing, because it means a configuration mismatch in one direction is invisible and in the other is loud — and the invisible direction is the one that hides a real disagreement until something else changes.

6. What This Looks Like in RTL

Both sides are small, and both are gated by the frame sequencer that Modules 6 and 7 build.

// Conceptual SystemVerilog — the transmitter's stop output.
// Shown as the sequencer's output selection for the stop state; the state
// encoding, the interval counting and the transitions are Module 7's.
import uart_line_pkg::*;   // UART_MARK / UART_SPACE, from Chapter 3.1

// During the stop state the line is held at mark for the configured
// number of intervals. Note this is the SAME value the idle output
// drives — the stop interval is a framing requirement, not a distinct
// electrical condition.
TX_STOP: tx_bit = UART_MARK;

// Conceptual SystemVerilog — the receiver's stop check.
// sample_stop_i is asserted by the sampling mechanism (Module 5) at the
// stop position located by the phase counter of Chapter 2.3. How the flag
// is latched, presented and cleared is Module 9's.
always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        framing_error <= 1'b0;
    end else if (frame_start_i) begin
        framing_error <= 1'b0;              // new frame, new verdict
    end else if (sample_stop_i) begin
        framing_error <= (rx_sampled_i != UART_MARK);
    end
end

Four points are worth extracting.

The transmitter drives the same value for stop and idle. That is not a shortcut — it is the protocol. The stop interval is defined as a required mark condition, and mark is what idle is. A design that treated them as different electrical states would be inventing a distinction the framing does not have.

The check is a comparison at one position, not a search. The receiver does not look for mark somewhere near the end; it samples the position its grid says is the stop interval and compares. Everything that makes that position correct — the origin, the payload width, the parity setting — has already happened.

Clearing on frame_start_i gives the flag a defined scope. Each frame gets its own verdict, so a framing error reports on the frame that just ended rather than persisting from an earlier one. Whether the reported flag is sticky across frames is a separate decision at the status interface, and Module 9 makes it — the distinction between a per-frame condition and a latched status bit is exactly the kind of thing that gets conflated.

Reset clears it. A receiver coming out of reset has not observed a frame and cannot have a verdict about one.

7. What This Means for Verification

The stop check is a single comparison with a wide set of ways to fail, which makes it unusually productive to test.

The positive case must be checked, not assumed. A frame that ends correctly must produce no framing error. It sounds trivial and it catches a real defect class: a receiver whose stop position is off by one reports errors on perfectly good traffic, and only a test that asserts the absence of the flag notices.

Violate the stop position deliberately. Drive space at the stop interval with the payload otherwise intact. The error must be reported, and — worth asserting separately — the payload should still be delivered, because a framing error says the frame ended wrongly, not that its contents are unavailable. Whether a given design delivers it is a design decision; a testbench should establish which one was made.

Back-to-back frames are the important stimulus in this chapter. A frame beginning in the interval immediately after the stop is legal and is where a receiver that does not return cleanly to watching will fail. The test should include a run of them, not a pair, since a receiver that recovers slowly may survive one and fall behind over several.

Contrast back-to-back against long idle and assert the receiver behaves identically. That is §4's testable prediction, and a design whose behaviour differs has a timing dependence on the gap that the model says should not exist.

Mismatch the stop configuration in both directions, because §5 showed they are not symmetric. Transmitter sending two where the receiver expects one should pass; the reverse should fail — and confirming the passing direction actually passes is what proves the receiver is checking a position rather than requiring an exact frame length.

Combine with the parity axis. The stop position depends on whether a parity interval is present, so a parity misconfiguration displaces the stop check. Testing the two independently misses the interaction; the symptom of a parity-presence mismatch is frequently a framing error rather than a parity one, which is a genuinely confusing diagnostic that a testbench should reproduce deliberately.

8. What This Means on an FPGA

A framing error flag is worth bringing out physically during bring-up. Paired with the parity flag from Chapter 3.3, it separates the failure classes of §3 faster than reading status registers — and it works before the register interface itself is trusted.

A line stuck at space produces framing errors continuously, because the stop position can never be satisfied. Combined with Chapter 3.1 §4 — where the same condition also produces continuous false frame entry — a disconnected or shorted receive input has a completely characteristic signature: unbroken frames, all with framing errors, none of which were sent. Recognising that pattern saves the hour that gets spent suspecting the receiver.

Back-to-back frames are what a DMA-fed or FIFO-fed transmitter naturally produces, so a design tested only with software-paced traffic — which inserts gaps without meaning to — may meet its first back-to-back run in the field. The stimulus is easy to generate deliberately and easy to omit by accident.

9. Understanding Check

10. Summary

A frame ends with a required mark condition of at least a configured duration, at a position the receiver computes from the origin and checks. Electrically it is the same level as idle; what makes it part of the frame is that the framing requires it there and something verifies it.

It is not a resynchronisation — nothing measures or adjusts a frequency, and at the moment it is sampled the accumulated timing error is at its maximum for that frame (Chapter 2.5). It is not recovery time — the receiver handles it like any other interval, and any catching-up belongs to the buffering above. It is not dead time — it is the most useful diagnostic position the framing provides, and it is counted and paid for inside the frame.

Finding space where mark is required produces a framing error, which reports what was observed and never why. Six distinct causes produce the identical observation, and the receiver cannot distinguish them; whether the payload is also wrong, and whether the error is universal or intermittent, narrow it far faster than the flag alone.

No gap is required between frames. The next start transition may occur in the interval immediately after the stop, and the receiver's timing behaviour is identical whether the gap is zero or hours — which is the testable prediction that disproves the resynchronisation account.

Stop duration is configuration, and the options are an implementation capability. A longer requirement costs an interval of line time and buys a little margin, not correction. The mismatch is asymmetric: sending more stop than the receiver expects passes silently, while sending less fails loudly — and the silent direction hides a genuine disagreement until something else changes.

11. What Comes Next

Every field of the frame is now defined: entry, payload, optional check, and required ending. Each came with a choice — how many payload bits, whether parity is present and in which mode, how long the mark condition must last — and those choices are not independent of one another.

Chapter 3.5 assembles them. It reads the shorthand that names a configuration, computes what each one costs in intervals and in line time, and establishes exactly what the two endpoints must agree on before a single frame can cross. It is the chapter where the module's five fields become one contract.

Browse the full path on the UART tutorials index. For the framing error treated as a timing outcome rather than a framing one — why it appears at the end of a frame first — see Chapter 2.5.