JOVANA
Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

Why Timing Matters: From a Clock Edge to Static Timing Analysis

A modern chip can be logically perfect and still fail — not because the math is wrong, but because a signal arrived a few trillionths of a second too late. Every synchronous design is a relay race against a [[clock-signal|clock]], and if any runner misses the handoff, the chip produces garbage. This guide opens the timing track by showing why settling **before the next clock edge** is the whole game, and why engineers check it with an exhaustive, vectorless method called [[static-timing-analysis|static timing analysis]] instead of just simulating.

The chip that computes the right answer too late

Picture a runner sprinting toward a teammate to pass a baton. The runner is fast, the path is clear, the handoff is rehearsed — but the receiving runner has already started moving at a fixed whistle. If the baton arrives a fraction of a second after that whistle, it doesn't matter how perfect the runner was: the handoff fails, and the whole team is disqualified. A digital chip lives exactly this drama, billions of times a second, on every single signal it carries.

Here is the surprise that catches every beginner. We usually think a circuit is correct if its logic is correct: feed it the right inputs and the gates compute the right output. That is necessary, but it is not enough. A real gate built from real transistors takes *time* to switch — a tiny but nonzero delay while charge sloshes through wires and channels. Chain dozens of gates together and the delay adds up. The output is correct, but it shows up late. In a clocked system, late is just another word for wrong.

The clock: a metronome that keeps a billion gates in step

Why impose a deadline at all? Because without one, chaos reigns. If thousands of signals were free to update whenever they finished computing, faster paths would race ahead of slower ones and the chip could read a half-cooked answer. The fix is one of the most powerful ideas in all of engineering: a shared clock signal — a square wave that ticks up and down at a fixed rate — acts as a metronome the whole chip marches to. Almost nothing happens 'whenever it's ready'; instead, the chip only commits to new values on the clock's rising edge.

The components that obey the clock are the flip-flops (and registers built from them). A flip-flop is a one-bit memory cell with a simple, strict rule: it ignores its data input the entire time, then on the clock's rising edge it snapshots whatever value is sitting there and holds it steady until the next edge. Everything *between* flip-flops is plain combinational logic — gates with no memory — and it is free to churn, settle, and produce a result during the gap between two ticks. Flip-flops plus clocked discipline is the heart of sequential logic.

clock:  __|‾‾|__|‾‾|__|‾‾|__       a square wave, period = T
          ^      ^      ^
        edge   edge   edge          flip-flops only update HERE

          |<--- T --->|             one clock period = one 'turn'

If the clock runs at 1 GHz:  T = 1 / 1e9 = 1 nanosecond.
Everything between two edges has just 1 ns to finish. Forever.
The clock period T is the deadline. At 1 GHz it is one nanosecond — the entire budget for data to launch from one flip-flop, race through the logic, and arrive stable at the next.

The launch-and-capture race: one timing path

Zoom into a single hop and you see the unit of everything that follows: a launch flip-flop, a cloud of logic, and a capture flip-flop. On a clock edge, the launch flip-flop fires its stored bit out onto a wire. That bit then propagates through a chain of gates — each one a standard cell, a pre-characterised logic building block with a known delay — and through the metal wires connecting them, which add delay too. One clock period later, the next edge arrives at the capture flip-flop, and it must find that the data has *already settled*. This launch → logic → capture journey is a timing path.

      same clock edge launches and (one period later) captures
               |                                   |
   clk --------+--------------------+--------------+----
               |                    |              |
          +----v----+   logic   +---v---+      arrives, must
   D ---->|  LAUNCH | --[ ]--[ ]--[ ]-->| CAPTURE|  be stable
          |   FF    |  combinational    |   FF   |
          +---------+   (no memory)     +--------+

   t_clk-to-q   +   t_logic + t_wire    must be < T
   (launch FF        (everything in           (one clock
    delay)            between)                 period)
One timing path: data launches from a flip-flop, propagates through combinational logic and wires, and must be stable when the capture flip-flop samples it one period later.

There are really two deadlines hiding here, and the track will spend whole rungs on each. The data must not arrive too late (or the capture flip-flop samples a value still mid-change) — a failure called a setup violation. But it must also not arrive too early and change again right after the edge before the flip-flop has finished latching — a hold violation. For now, hold the simple picture: the signal has to be stable in a window around the capturing edge. Land outside that window and the bit you store is undefined.

Why you can't just simulate your way to confidence

The instinctive way to check timing is the way you'd debug software: run the chip. Apply a stimulus — a test vector — watch the waveforms, and confirm every signal settled in time. This is dynamic simulation, and for a tiny circuit it's perfect. The problem is coverage. A timing bug only shows up if your vector happens to *exercise the exact path* that's too slow, with the exact data that toggles it. Miss that one stimulus and the slow path sleeps quietly through your entire test, then wakes up in a customer's phone.

And the number of paths is astronomical. A real design has millions to billions of distinct launch-to-capture paths. To be sure by simulation you would need a vector set that excites the worst case of every one of them — combinatorially impossible. Simulation answers 'is this *particular* run on time?' What we actually need is 'is *every* path on time, under all data?' Those are completely different questions.

Static timing analysis: checking every path at once, with no vectors

The breakthrough is to stop running the chip and instead *analyse its structure*. Static timing analysis (STA) turns the whole design into a timing graph: every flip-flop, standard cell and wire becomes a node or edge labelled with its delay, drawn from libraries that the foundry measured for those parts. STA then walks this graph and computes, for the worst case, how late a signal can possibly arrive at every endpoint — *without ever applying a single input vector*. That word static is the whole point: it reasons about the structure, not about any one execution.

  1. Build the graph. Break the design at every flip-flop into a collection of timing paths, each running from a launch point to a capture point through combinational logic and wires.
  2. Add up delays. For each path, sum the worst-case delay of every cell and wire to find when the signal latest arrives — its arrival time.
  3. Compute the deadline. From the clock period and the capture flip-flop's requirements, work out the latest moment the data is *allowed* to arrive — its required time.
  4. Compare — that's slack. Required minus arrival is the margin, called slack. Positive slack means the path makes its deadline; negative slack flags a violation that must be fixed before tapeout.

Because STA only ever *adds and compares delays along the graph*, it scales to the whole chip in hours, not the geological time vector simulation would need. Crucially it is vectorless and exhaustive — it implicitly considers the worst case of every path simultaneously, so no slow path can hide for lack of the right stimulus. The targets it checks against — clock period, setup and hold requirements, input and output delays — are written down as timing constraints, the contract that tells STA what 'on time' even means.