Bit Time, the Bit Grid and Frame Duration

Chapter 2.1 established a bargain with four terms and showed that three quantities are locked together inside it: how badly the two rates disagree, how many intervals a receiver predicts from one alignment, and how much positional error is tolerable. That argument was entirely structural. None of those three is yet a number.

This chapter supplies the units. It converts a configured baud figure into the time quantities engineers actually reason with, builds the grid of intervals a frame occupies, and computes how long a receiver's prediction has to survive. It then turns to the awkward fact that makes the rest of the module necessary: the interval you need almost never divides evenly into the clock you have.

1. Notation

This module builds a reasoning language that later chapters reuse. Five symbols carry it, and every one has a unit.

Two symbols arrive in later chapters and are named here so the language stays consistent: ε_TX and ε_RX are each endpoint's fractional frequency error — dimensionless, introduced in Chapter 2.4.

2. The Bit Period

The conversion is the simplest relation in the module and the one everything else rests on. One interval per symbol, f_baud symbols per second, so:

T_bit = 1 / f_baud

Worked at a common configuration:

f_baud = 115200 baud

T_bit  = 1 / 115200
       = 8.680555... x 10^-6 s
       ≈ 8.68056 µs

Across the range engineers actually meet:

What the number means physically. T_bit is how long the transmitter holds one signalling state on the conductor before moving to the next. It is also, and more importantly, the unit in which every receiver decision is denominated. A receiver does not have "a small timing error"; it has an error that is some fraction of T_bit. Ten nanoseconds of displacement is nothing at 9,600 baud — about 0.01% of an interval — and is 1% of an interval at 1 Mbaud. The same physical error is harmless or serious depending entirely on T_bit, which is why the module expresses everything from here as a fraction of a bit rather than in absolute time.

3. The Bit Grid

Once the transmitter begins a frame at some instant, the intervals that follow are fixed relative to it. Take that instant as t = 0. Then interval k — counting from zero — occupies:

interval k spans   [ k x T_bit ,  (k+1) x T_bit )

its boundaries sit at      k x T_bit
its centre sits at   (k + 0.5) x T_bit

This set of positions is the bit grid. It is worth being precise about its status, because it is the object every later chapter manipulates.

The grid is a construction, not a signal. Nothing on the conductor marks a boundary. The transmitter changes its output level only when consecutive intervals happen to carry different values; two identical values in succession produce no transition at all, and the boundary between them is invisible. The grid exists in each endpoint's reasoning, not on the wire.

Both endpoints build their own copy. The transmitter's grid is produced by its own timebase and is, by definition, the correct one. The receiver's is a prediction built from the agreed rate and one observed event — which is exactly the arrangement Chapter 2.1 described, now expressed as geometry. When later chapters say error accumulates, they mean these two grids drift apart.

The invisible boundary marked in the figure is not a curiosity. It is the reason a receiver cannot recover timing by watching for transitions during a frame: there may not be any. The alignment event at the start is the only transition guaranteed to exist, which is why the scheme depends on it so completely — and why Chapter 2.3 is about that single event.

4. Frame Duration

A frame occupies a whole number of intervals. Call it N_frame. Then:

T_frame = N_frame x T_bit

N_frame is a configuration-dependent quantity, not a constant. It is the total count of signalling intervals the frame occupies — the alignment interval, the payload intervals, any additional interval the configuration includes, and the closing mark interval. Which of those are present, and how many, is set by configuration and is Module 3's subject.

Taking the most commonly encountered arrangement purely as a worked example — one alignment interval, eight payload intervals, one closing interval, so N_frame = 10:

f_baud  = 115200 baud
T_bit   ≈ 8.68056 µs
N_frame = 10                  (example configuration, not a universal)

T_frame ≈ 10 x 8.68056 µs
        ≈ 86.8056 µs

and at the slower end of the range:

f_baud  = 9600 baud
T_bit   ≈ 104.16667 µs
N_frame = 10                  (same example configuration)

T_frame ≈ 10 x 104.16667 µs
        ≈ 1041.6667 µs  ≈ 1.0417 ms

5. The Gap Between Frames

T_frame is the span of one transmission. It says nothing about what follows, and the answer is: anything.

The conductor returns to its idle level at the end of a frame and may stay there for any duration — zero, microseconds, hours. A transmitter may begin the next frame in the very next interval, producing back-to-back frames with no gap at all, or may send nothing for the rest of the day. Chapter 1.3 established idle as a valid steady state of unbounded length, and nothing in the timing model constrains it.

Two consequences matter here.

Line occupancy is not determined by T_frame. The time to move a given number of frames depends on the gaps between them as well as on their duration, and the gaps are set by whatever is producing data — software, a state machine, a FIFO draining. A calculation that multiplies frame count by T_frame computes a lower bound on elapsed time, not the elapsed time.

Framing consumes line time even at full occupancy. In the N_frame = 10 example, eight of the ten intervals carry payload:

payload efficiency = 8 / 10 = 0.80 = 80%

So even with no gaps at all, a fifth of the conductor's time goes to framing rather than data. That is a fact about this configuration rather than about UART, and Chapter 4.1 develops throughput properly. The point here is narrower: T_frame is a frame-duration quantity, and turning it into a data-rate quantity requires two further things — the payload fraction, and the gaps.

6. The Problem This Chapter Ends On

Everything so far has treated T_bit as a real number. A receiver cannot. Chapter 2.1 §5 established that its only timebase is its own clock, so every interval it constructs is some whole number of F_clk cycles.

That raises an arithmetic question with an unpleasant answer. How many system-clock cycles is one bit interval?

cycles per bit = F_clk / f_baud

F_clk  = 100 MHz = 100,000,000 Hz
f_baud = 115200 baud

cycles per bit = 100,000,000 / 115,200
               ≈ 868.0556

It is not an integer, and it is not close to being one in a way that helps. A counter can count 868 cycles or 869 cycles. It cannot count 868.0556.

This is not a peculiarity of that pairing. Across the configurations engineers actually build:

Not one divides evenly. That is the normal case rather than bad luck: system clocks are chosen for the logic they serve and serial rates come from a different tradition entirely, so the two have no reason to share factors.

This chapter stops at the problem statement. Choosing the count, quantifying the error it leaves, and deciding whether to correct it are Chapter 4.3 and Chapter 4.4; building the hardware that produces the intervals is Module 8. What matters now is the structural fact: a third error source has appeared. Alongside the transmitter's oscillator and the receiver's oscillator, the receiver's own construction of T_bit is inexact — and all three land in the same budget, which is Chapter 2.5's subject.

7. What This Means in RTL

The arithmetic above becomes a parameter and a counter, and both have decisions in them that this chapter can frame even though Module 8 builds them.

// Synthesizable SystemVerilog — parameterisation only, no timing logic.
// The generator that USES this count is Module 8; the choice of value and
// the error it leaves are Chapter 4.3. What is shown here is how the
// arithmetic of §6 reaches hardware, and how wide it has to be.
module uart_timing_params #(
    // Elaboration-time arithmetic, evaluated by the tool, not by hardware.
    parameter int unsigned CLK_HZ   = 100_000_000,
    parameter int unsigned BAUD     = 115_200,

    // 100e6 / 115200 = 868.0556 -> 868. The fractional part is DISCARDED
    // here, and discarding it is a decision with a measurable cost that
    // Chapter 4.3 quantifies. Chapter 4.4 covers not discarding it.
    parameter int unsigned CYC_PER_BIT = CLK_HZ / BAUD,

    // Width is derived, never hand-written: a counter that must reach
    // CYC_PER_BIT - 1 needs $clog2(CYC_PER_BIT) bits. For 868 that is 10.
    parameter int unsigned CYC_W = $clog2(CYC_PER_BIT)
) (
    input  logic clk,
    input  logic rst_n
);
    logic [CYC_W-1:0] cycle_count;   // 10 bits here, not a guessed 16
endmodule

Three things in that fragment are worth extracting, because they recur throughout the RTL modules.

The division happens at elaboration, not in hardware. CLK_HZ / BAUD is integer arithmetic the synthesis tool performs once while building the design. No divider appears in the netlist — a point worth making because "divide the clock by the baud rate" sounds like it implies division hardware, and it does not.

The truncation is a design decision, not a rounding detail. 100_000_000 / 115_200 evaluates to 868 in integer arithmetic; the 0.0556 is discarded silently. That discarded fraction is a real frequency error in the constructed interval, and it is spent from the same budget as the crystal tolerances. Chapter 4.3 measures it. The reason to surface it here is that it is easy to write this line without noticing a decision was made.

The counter width is derived from the parameter. $clog2(CYC_PER_BIT) gives 10 bits for 868. Hand-writing a width invites two failures: too narrow and the counter wraps early, silently producing the wrong interval; too wide and the design carries flip-flops and comparator logic it never uses. Deriving it means a design re-parameterised for a different clock or rate stays correct without a second edit.

8. What This Means for Verification

Quantities that are parameters are quantities a testbench must vary, and this chapter has produced three.

f_baud and F_clk are an axis, not a setting. The pairing determines the fractional part in §6, and that fraction varies non-monotonically across pairings — 0.0278 for one combination, 0.6667 for another. A testbench that only ever runs one pairing has tested one point in that space. The interesting selections are the ones with an inconvenient fraction, because they carry the largest construction error.

N_frame is an axis. Frame length multiplies whatever per-interval error exists, so the longest supported configuration is the worst case and the shortest is the most forgiving. Testing only the common ten-interval arrangement leaves the design's actual boundary untested — and Chapter 2.4 shows the relationship is linear in N_frame, which makes the worst case easy to identify and therefore inexcusable to omit.

The inter-frame gap is an axis. Because it is unconstrained, both extremes are legal traffic: back-to-back frames with no idle at all, and a single frame after a long silence. Both are ordinary, and they exercise different behaviour in a receiver — one tests whether it is ready for a new alignment event immediately, the other whether prolonged idle leaves it in a state that can still detect one.

None of that is a coverage model yet. It is the observation that three testbench axes fall out of one chapter of arithmetic, which is the habit Modules 14 and 15 formalise.

9. What This Means on an FPGA

The §6 table is the practical content of this chapter for an FPGA engineer: the fabric clock is chosen for the design, the serial rate is chosen by whatever is at the other end, and the ratio between them is whatever it happens to be.

Two consequences are immediate. The ratio is large, which is comfortable — 868 cycles per interval means the clock resolves the interval finely, and the construction error is a small fraction of a bit. A design attempting a very high serial rate from a modest fabric clock has far fewer cycles per interval and a correspondingly coarser construction, which is where this arithmetic stops being a formality.

And the count is not a constant of the design. Moving the same RTL to a board with a different fabric clock changes CYC_PER_BIT and therefore the residual error. Deriving the parameter from CLK_HZ and BAUD, as §7 does, is what makes that port a re-elaboration rather than a re-verification.

10. Understanding Check

11. Summary

A baud figure is not a time. The conversion T_bit = 1 / f_baud supplies the unit everything else in this module is denominated in — about 8.68056 µs at 115200 baud, about 104.16667 µs at 9,600. Errors are expressed as fractions of T_bit because the same absolute displacement is trivial at one rate and fatal at another.

From an origin, the bit grid places boundaries at k x T_bit and centres at (k + 0.5) x T_bit. It is a construction rather than a signal: nothing on the conductor marks a boundary, and consecutive intervals carrying the same value produce no transition at all. Both endpoints build their own copy, and the receiver's is a prediction — which is why later chapters describe error as two grids drifting apart.

A frame spans T_frame = N_frame x T_bit, where N_frame is a configuration parameter and not the constant ten. Carrying it as a symbol keeps visible the trade that longer frames spend more margin. The gap after a frame is unconstrained — zero to unbounded — so frame duration alone never determines how long a sequence of frames takes, and framing consumes line time even at full occupancy.

The chapter ends on the arithmetic that makes the rest of the module necessary. F_clk / f_baud is the number of local clock cycles in one interval, and it is essentially never a whole number — about 868.0556 at 100 MHz and 115200 baud, about 10416.6667 at 100 MHz and 9,600. A counter cannot count a fraction, so the constructed interval differs from T_bit, and that residual is a third error source alongside the two oscillators. All three are spent from one budget.

12. What Comes Next

The grid of §3 is anchored at an origin this chapter simply assumed. Chapter 2.3 supplies it: how a receiver converts the one guaranteed transition at the start of a frame into a timing origin, why the reconstruction is redone for every frame instead of being held across the stream, and what the word synchronisation does and does not mean here. Chapter 2.4 then puts numbers on the divergence between the transmitter's grid and the receiver's, and Chapter 2.5 spends the result against the margin surrounding each centre.

Browse the full path on the UART tutorials index. For a clocked interface where the equivalent arithmetic is exact by construction rather than approximated — and what that buys — see CAS Latency.