Timing, Critical Paths, and Pipelining

1. Engineering intuition — the clock waits for the slowest path

Every clock cycle, data launched from one register must travel through logic and settle at the next register before the capturing edge. The clock period therefore has to be long enough for the slowest of all these register-to-register journeys — the critical path. One slow path (a wide adder, a deep mux tree, a long comparison chain) holds the entire clock back, no matter how fast everything else is. So designing for speed is about finding that slowest path and shortening it. The most powerful way is to cut the journey in half with a register in the middle: each half now fits in a shorter period, so the clock can run faster — that is pipelining.

2. Formal explanation — the timing equation and slack

-- A PATH: launch FF → combinational logic → capture FF.
-- The clock period must cover the WHOLE path:
--     Tclk ≥ Tcq + Tlogic + Tsetup        (+ routing delay, − clock skew)
--       Tcq    = clock-to-Q of the launch FF
--       Tlogic = combinational delay between the FFs
--       Tsetup = setup time of the capture FF
--
-- CRITICAL PATH = the path with the LARGEST (Tcq + Tlogic + Tsetup) → sets Fmax = 1 / Tclk_min.
-- SLACK = required_time − arrival_time.   slack ≥ 0 → meets timing.   slack < 0 → FAILS.
--
-- To MEET timing (increase Fmax), reduce the longest Tlogic:
--   • PIPELINE: insert register(s) to split long logic into shorter stages.
--   • reduce LOGIC DEPTH (simpler expressions, balanced trees), retiming, parallelism.

The period must satisfy Tclk ≥ Tcq + Tlogic + Tsetup; the critical path is the largest such sum and fixes Fmax. Slack (required − arrival) must be ≥ 0. You raise Fmax by cutting the longest Tlogic — chiefly by pipelining (inserting registers to shorten each stage) or reducing logic depth.

3. Production usage — pipelining a long combinational path

-- BEFORE: one long combinational path (multiply THEN add) between registers → big Tlogic → low Fmax.
-- result <= (a * b) + c;     -- all in one cycle: mult delay + add delay on one path
 
-- AFTER: PIPELINE — split into stages with a register between them.
process (clk) begin
  if rising_edge(clk) then
    mult_r <= a * b;          -- STAGE 1: just the multiply (shorter path)
    c_r    <= c;              -- align c with the pipeline (delay to match)
    result <= mult_r + c_r;   -- STAGE 2: just the add (shorter path)
  end if;
end process;
-- Each stage's Tlogic is smaller → higher Fmax. Cost: result is 1 cycle LATER (latency),
-- but a new result still comes EVERY cycle once the pipe is full (throughput unchanged).

What hardware does this become? Two shorter register-to-register stages instead of one long one: the multiply in stage 1, the add in stage 2, with a pipeline register between. Each stage's delay is roughly half the original, so the clock can run faster (higher Fmax). The trade is latency — result now appears one cycle later — but throughput is unchanged: once the pipeline is full, you still get one result per clock. This latency-for-frequency trade is the central RTL timing technique; you also help the tool by registering big operations (so DSP/BRAM internal registers are used, 16.5) and keeping logic depth shallow.

4. Structural interpretation — one long path split into stages

5. Simulation interpretation — pipelined latency and throughput

6. Debugging example — timing fails on the critical path

Expected: the design meets the target clock frequency. Observed: the timing report shows negative slack on a register-to-register path — the design will not run at the required frequency (or is unreliable at it). Root cause: a long combinational path between registers — a wide multiply-then-add, a deep mux/ comparison chain — has Tlogic large enough that Tcq + Tlogic + Tsetup > Tclk, so that critical path caps Fmax below target. Fix: shorten the longest path — pipeline it by inserting registers to split the logic into stages (accepting added latency), reduce logic depth (balanced trees, simpler expressions), register big arithmetic so DSP/BRAM pipeline registers are used, or retime. Engineering takeaway: negative slack means the critical path is too long for the clock — break it with pipeline registers (trading latency for frequency) or reduce its logic depth; the slowest path alone sets Fmax, so fix that path.

-- BUG: long single-cycle path → critical path too long → negative slack.
-- result <= (a * b) + c;     -- multiply + add in one cycle
-- FIX: pipeline into two shorter stages (registers between) → higher Fmax (+1 cycle latency).
mult_r <= a * b;  c_r <= c;   result <= mult_r + c_r;   -- in a clocked process

7. Common mistakes & what to watch for

• One long combinational path. A multiply-then-add or deep chain caps Fmax; pipeline it into shorter stages.
• Ignoring slack. Negative slack = timing failure; read the timing report and fix the critical path specifically.
• Forgetting to align data when pipelining. Delay parallel signals (like c) to match the added stage, or results desynchronize.
• Confusing latency and throughput. Pipelining adds latency but keeps one-result-per-cycle throughput; don't assume it slows the data rate.
• Not registering big arithmetic. Register multiplies/wide ops so DSP/BRAM internal registers help timing (16.5).

8. Engineering insight & continuity

Timing is set by the critical path: Tclk ≥ Tcq + Tlogic + Tsetup, the slowest register-to-register path fixing Fmax, with negative slack meaning failure. The primary RTL remedy is pipelining — insert registers to split long logic into shorter stages, trading latency for higher frequency while keeping throughput — alongside reducing logic depth. Pipelining adds registers, which costs area; the flip side is reusing hardware to save area, the next lesson's topic: Resource Sharing and Optimization — how synthesis (and your coding) shares expensive units like multipliers across operations to trade area against speed.