Baud Rate, Bit Rate and Real Throughput

Chapter 3.5 closed Module 3 by observing that the configuration shorthand names three of four things and omits the rate. This module takes the rate seriously: where the number comes from, how a real clock produces it, what error that leaves, and how much of the resulting budget a link can afford to spend.

It begins with a smaller question that engineers get wrong constantly:

A link is configured for 115200 baud. How many bytes per second does it deliver?

The answer is not 14,400, and it is not obtainable from the baud figure alone. Between signalling rate and delivered payload sit three separate losses, and only one of them appears in the configuration.

1. Notation for Module 4

This module is quantitative throughout and the symbols recur across all five chapters. Defined once, here:

Sign convention, fixed for the whole module: ε is a frequency error, so positive ε means running fast. Period error carries the opposite sign, which Chapter 4.3 develops because it is a genuine source of confusion.

2. Baud and Bit Rate

The two words name different quantities that happen to coincide here.

Baud counts signalling intervals per second — how often the line may change to a new state. Bit rate counts bits per second. They are equal only when each signalling interval carries exactly one bit.

Asynchronous serial framing as this curriculum treats it is one bit per interval throughout: each interval holds one of two line states, carrying one bit. So for UART the two numbers coincide, and engineers use the words interchangeably without harm.

The equality is a property of this signalling, not of the word baud. A scheme whose symbols carry more than one bit has a bit rate that is a multiple of its baud figure, which is why the distinction exists at all. It is worth knowing and not worth a detour.

What is not equal to either is the rate at which payload moves, and that is the subject of the rest of the chapter.

3. Three Rates, Not One

Separate the quantities properly. Each is a real number an engineer might need, and they differ by factors that matter.

The signalling rate is f_baud. It is what the configuration requests and what an instrument measures on the conductor: intervals per second, regardless of what the intervals contain.

The payload bit rate is what remains after framing. A frame occupies N_frame intervals and delivers N_data payload bits (Chapter 3.5), so:

payload bit rate = f_baud x (N_data / N_frame)      bit/s

The delivered frame rate is how many frames complete per second, which is the number software actually counts:

frame rate = f_baud / N_frame                        frames/s

Worked at 115200 baud across the configurations from Chapter 3.5:

(Frames/s and payload bit/s rounded to two decimal places; efficiency is N_data / N_frame.)

So the answer to the opening question is that 8N1 at 115200 baud delivers at most 11,520 bytes per second, not 14,400 — the naive 115200 / 8 — because that division ignores framing entirely. Two of every ten intervals carry no payload.

4. The Ceiling and the Delivery

Everything in §3 is a ceiling: what the link would deliver if the transmitter never stopped. Real links rarely reach it, for a reason that is invisible in the configuration.

Chapter 3.4 established that the gap between frames is unconstrained — a transmitter may begin the next frame immediately or may wait indefinitely. Nothing in the framing produces gaps, so any gap comes from whatever is feeding the transmitter: software writing a byte at a time, a FIFO draining, a DMA engine with other work to do.

delivered rate = ceiling x (line occupancy)

where occupancy = fraction of time the line is carrying frames

Occupancy is a property of the system above the UART, not of the UART. That produces a diagnostic split worth internalising:

If measured throughput is below the ceiling, the UART is not the constraint. The frames it does send are the right length and the right rate; there are simply gaps between them, and the cause is upstream. Raising the baud rate in that situation improves nothing — it makes each frame shorter and the gaps correspondingly longer, leaving delivery unchanged.

If measured throughput equals the ceiling, the link is saturated and only a configuration or rate change helps.

Distinguishing the two takes one measurement — the inter-frame gap on a capture — and it is the difference between a five-minute fix upstream and a pointless rate increase. Module 10 builds the buffering that closes gaps; this chapter's contribution is knowing which question to ask.

5. Sizing From the Requirement

The arithmetic runs in the other direction too, and that is how it is usually needed: a system has a payload requirement and must choose a rate.

f_baud  >=  required payload bit rate x (N_frame / N_data)

Worked for a design that must sustain 10,000 bytes per second — 80,000 payload bits per second — in 8N1:

required payload  = 80,000 bit/s
N_frame / N_data  = 10 / 8 = 1.25

f_baud >= 80,000 x 1.25
       =  100,000 baud

so 115200 is the lowest common rate that meets it — with 15% headroom, before any occupancy loss. In 8E1 the same requirement needs 80,000 x 11/8 = 110,000 baud, and 115200 now has only 4.7% headroom. The configuration choice moved the requirement by 10%, which is the kind of margin that disappears silently when someone enables parity late in a project.

This is worth encoding rather than recomputing, and it is small enough to do at elaboration:

// Synthesizable SystemVerilog — elaboration-time sizing check. Infers no
// hardware; the initial block is evaluated by the tool, not by the design.
// Frame-length arithmetic follows Chapter 3.5; the generator that produces
// the rate is Module 8.
module uart_throughput_check #(
    parameter int unsigned BAUD_HZ   = 115_200,
    parameter int unsigned DATA_BITS = 8,
    parameter bit          PARITY_EN = 1'b0,
    parameter int unsigned STOP_BITS = 1,

    // What the system must sustain, in payload bytes per second.
    parameter int unsigned REQ_BYTES_PER_S = 10_000
) ();
    // N_frame = start + payload + parity + stop   (Chapter 3.5)
    localparam int unsigned N_FRAME = 1 + DATA_BITS + int'(PARITY_EN) + STOP_BITS;

    // Ceiling in payload bytes per second. Integer arithmetic throughout:
    // multiply before dividing so the result is not truncated to zero on
    // narrow configurations.
    localparam int unsigned CEIL_BYTES_PER_S =
        (BAUD_HZ * DATA_BITS) / (N_FRAME * 8);

    initial begin
        if (CEIL_BYTES_PER_S < REQ_BYTES_PER_S) begin
            $fatal(1,
              "uart_throughput_check: %0d baud in a %0d-interval frame yields %0d B/s, below the required %0d B/s",
              BAUD_HZ, N_FRAME, CEIL_BYTES_PER_S, REQ_BYTES_PER_S);
        end
    end
endmodule

Three things in that block are worth extracting, because they recur throughout the module.

Multiply before dividing. (BAUD_HZ * DATA_BITS) / (N_FRAME * 8) and BAUD_HZ / N_FRAME * DATA_BITS / 8 are not the same in integer arithmetic — the second truncates twice and loses several percent. Elaboration-time arithmetic is integer arithmetic, and the ordering is part of the correctness.

The check is a ceiling, not a promise. It confirms the configuration can carry the requirement; it says nothing about occupancy, which the design cannot know. A design that passes this check and still misses its deadline has a §4 problem, and the check's error message is worded to make that boundary clear.

N_FRAME is derived here rather than passed in, so it cannot disagree with the fields the rest of the design is built from. Chapter 3.5 made the same argument for having one function compute it.

6. What This Means for Verification

Throughput is not usually thought of as a verified property, and two parts of it should be.

The ceiling is checkable and worth checking. A testbench that streams frames back to back with no gaps and measures the frame rate should observe exactly f_baud / N_frame. A design that inserts an unintended idle interval between frames — a sequencer that returns to an idle state for one interval before accepting the next byte — reduces throughput by 1/N_frame, which is 10% at 8N1. That is invisible in any single-frame test and obvious in a saturated one.

Every supported configuration changes the expected number. The scoreboard's expected frame rate is a function of N_frame, so a test that hard-codes an 8N1 expectation reports a false failure the first time it runs 8E1. Computing the expectation from the configuration — the same arithmetic as §5 — keeps the checker correct across the matrix.

And saturation is a distinct stimulus from correctness. Most functional tests send a frame, check it, and send another; that pattern never saturates the link and never exercises the back-to-back path of Chapter 3.4. A throughput test is the natural place to generate that traffic, which makes it useful well beyond its own measurement.

7. What This Means on an FPGA

Measure occupancy before changing the rate. The §4 split is the whole diagnostic: capture the line, measure the gap between the end of one frame and the start of the next, and compare against zero. Gaps mean the bottleneck is upstream and a rate increase will not help. No gaps mean the link is saturated and a rate or configuration change is the only lever.

The requirement moves when the configuration does. §5 showed that enabling parity raises the required rate by 10% for the same payload. On a design whose rate was chosen with modest headroom, that change alone can push it below requirement — and the failure appears as missed deadlines rather than as corrupted data, which sends debugging in the wrong direction.

Compute the ceiling at elaboration. The check in §5 costs nothing in the netlist and catches an impossible configuration at build time rather than during integration.

8. Understanding Check

9. Summary

Baud counts signalling intervals per second; bit rate counts bits per second. They coincide for UART because each interval carries one bit, and that is a property of this signalling rather than of the word.

Three rates must be kept apart. The signalling rate f_baud is what the configuration requests and an instrument measures. The payload bit rate is f_baud x (N_data / N_frame). The frame rate is f_baud / N_frame, which is what software counts.

So 8N1 at 115200 delivers at most 11,520 bytes per second, not 14,400. Dividing baud by eight is the standard estimate and is always optimistic — by 20% at 8N1 and 33% at 8E2.

Everything computed from the configuration is a ceiling. Real delivery is the ceiling times line occupancy, and occupancy is set by whatever feeds the transmitter rather than by the UART. That produces the diagnostic: delivery below ceiling means the bottleneck is upstream and a rate increase will not help; delivery at ceiling means the link is saturated. One gap measurement distinguishes them.

Run in reverse, f_baud >= required payload rate x (N_frame / N_data) sizes the rate from the requirement — and shows that enabling parity raises the required rate by 10%, which is enough to break a design that had modest headroom, with a symptom that looks like a software problem.

10. What Comes Next

This chapter treated f_baud as a number the configuration supplies. Chapter 4.2 asks where those particular numbers came from — why 9,600 and 115,200 rather than round figures — and begins the arithmetic that occupies the rest of the module: how a local clock of some unrelated frequency is made to produce them, and how cleanly it divides.

Browse the full path on the UART tutorials index. For throughput reasoning where the ceiling is set by the interface rather than by framing, see Data Transfer Efficiency.