EC-21.4 Timing: Constraints, Static Analysis and Closure

What this is and why it exists

A design that simulates perfectly and fails on the bench has usually failed timing.

The tool would have said so, if anybody had told it what the requirements were. That is the trap in this topic: an unconstrained design passes timing analysis trivially, and works never.

Static timing analysis checks every path in the design against the clock, without simulating anything. It is exhaustive and it is fast. Those two properties are why it finds in minutes what a year of simulation would not.

The vocabulary

• Setup time — how long data must be stable before a clock edge.
• Hold time — how long it must remain stable after the edge.
• Slack — how much time a path has to spare; negative slack is a violation.
• Critical path — the path with the least slack.
• Constraint — a statement telling the tool what the timing requirements are.
• Clock skew — the difference in arrival time of one clock at two registers.
• False path — a path the tool should ignore because it never matters.
• Multi-cycle path — one allowed more than one clock period to settle.
• Pipelining — inserting registers to shorten the logic between them.

The mental model

Everything starts at one flip-flop. Setup asks whether the data arrived early enough before the clock edge. Hold asks whether it stayed put long enough after it. Every timing failure in a synchronous design is one of those two, on one specific path.

The analyser walks every path from one register to the next and compares the arrival time against the requirement. It does this for all paths, not for the ones a test happened to exercise. That exhaustiveness is the whole value.

But it only checks against what the constraints say. The clock period, the delays at the inputs and outputs, and the paths that should be ignored all have to be written down. Most timing surprises are missing constraints rather than slow logic, which is worth remembering before optimising anything.

A timing report breaks a failing path into stages. You can see whether the time went into logic levels, into wire delay, or into the clock arriving unevenly at the two ends. Each of those three has a different remedy, and treating them alike wastes days.

Setup failures are cured by shortening the logic between registers. Add a pipeline stage, restructure the expression, or let the tool retime. Adding a stage changes the latency of the design, which is a specification change and has to be agreed rather than assumed.

Hold failures are different in kind and more alarming. Slowing the clock down does not fix one, because hold has nothing to do with the clock period. It is usually a clock distribution problem, and the fix is to insert delay in the data path.

What you should now be able to explain or do

• State the setup and hold requirements in terms of one flip-flop.
• Explain why static analysis finds what simulation misses.
• Write the constraints a tool needs: clock, input and output delay, exceptions.
• Read a timing report and say where the time went on a failing path.
• Fix a setup violation, and say what the fix costs elsewhere.
• Explain why slowing the clock does not fix a hold violation.

Check yourself