FPGA Guide
Topic hub

Timing closure and constraints

How static timing analysis works, what XDC and SDC constraints tell the tools, how to cross clock domains safely, and the reset and pipelining habits that make designs close.

Updated 13 Nov 2026 · static timing analysis, setup and hold, XDC, SDC, clock domain crossing, metastability, false path, multicycle path

Overview

A design that simulates correctly can still fail on the board if a signal arrives at a flip-flop too late or too early. Static timing analysis (STA) checks every register-to-register path against the clock without simulating anything, and the constraints you write are what tell it which clocks exist and which paths matter. This hub is for engineers who have met their first red timing report and for anyone who has copied a constraints file without understanding it.

Timing closure is the loop of reading that report, deciding whether the failure is real, and fixing either the constraint or the logic. Most of the loop is judgement rather than tooling, and it is the skill that separates people who can finish a design from people who can start one.

Key ideas

Setup, hold and what STA computes

Each flip-flop needs its data input stable for a setup time before the clock edge and a hold time after it. For a path from register A to register B, STA adds the clock-to-output delay of A, the logic and routing delay between them, and compares the sum against the clock period minus B’s setup time, adjusted for the clock skew between A and B. Slack is what is left over. Negative setup slack means the clock is too fast for the logic. Negative hold slack means data changed too soon after the edge, which usually only happens across clock domains or with large skew, and the router fixes most of it by adding delay. The tool reports the worst negative slack (WNS) and the total across all failing paths (TNS). A tiny WNS on one path and a huge TNS on thousands are different problems.

Setup and hold windows around a rising clock edge. Data must settle before the setup window opens and stay stable until the hold window closes.clkd (ok)stable earlystable earlyd (setup fail)latelateqcapturedcapturedsample edgesab
Setup and hold windows around a rising clock edge. Data must settle before the setup window opens and stay stable until the hold window closes.

Constraints: XDC and SDC

Both AMD’s XDC and the SDC used by Altera, Lattice, Microchip and the open-source tools descend from the Synopsys design constraints language, written as Tcl. The minimum is a create_clock on every input clock and generated clocks on anything derived in logic. Beyond that, input and output delays describe the board, set_clock_groups declares which clocks are unrelated so that paths between them are not analysed, set_false_path removes paths that STA should ignore because they never matter, and set_multicycle_path tells the tool a path has more than one cycle. Each exception is a promise. A false path on a real path hides a real failure, and the tool will not warn you.

Clock domain crossing

A signal moving from one clock domain to another can arrive at the receiving flip-flop during its setup window, leaving the output in a metastable state for an unbounded time. The standard remedy for a single bit is two flip-flops in series in the receiving domain, which gives the first one a full clock period to settle. The mean time between failures grows exponentially with that settling time and is quoted by vendors in years. For multi-bit values the two-flop trick does not work, because the bits may settle on different cycles. Use a Gray-coded counter for pointers, a handshake with a request and acknowledge for occasional words, or an asynchronous FIFO for streams. Constrain the crossing with set_clock_groups or set_max_delay with the datapath-only option so STA neither fails it nor ignores the real path delay. Vendor tools can report CDC structures they recognise, and a clean CDC report is worth having before every release.

Reset strategy, pipelining and retiming

Asynchronous reset assertion is fine, but asynchronous release is a CDC problem in itself, because every flip-flop may leave reset on a different edge. Synchronise the release with a two-flop reset synchroniser per domain, and prefer synchronous resets on FPGA logic where the vendor’s flip-flops support them cheaply. For paths that are too long, pipelining means adding a register in the middle and accepting one more cycle of latency. Retiming lets the synthesiser move registers across logic for you, which works well on arithmetic and badly when the register has a reset or an initial value. Floorplanning and placement constraints come last, after the logic itself has been made shallow.

Where to start

Intermediate lessons on reading timing reports, a complete XDC for a board, and an asynchronous FIFO with formal proof are coming.

Tools and vendors

Vendor Constraint format Timing analyser CDC reporting Hub
AMD XDC Vivado report_timing_summary report_cdc, report_clock_interaction /vendors/amd/
Altera SDC Quartus Prime Timing Analyzer Clock domain crossing report in Timing Analyzer /vendors/altera/
Microchip SDC SmartTime in Libero SoC Limited, relies on analyser reports /vendors/microchip/
Lattice SDC (Radiant), LPF with SDC (Diamond) Radiant Timing Analyzer Limited /vendors/lattice/
Open source SDC subset in nextpnr nextpnr built-in None /vendors/opensource/

Common mistakes

  • Running with no constraints and treating a clean report as proof that timing was met.
  • Copying a false path from a forum answer onto a path that carries real data.
  • Synchronising a multi-bit bus with one two-flop synchroniser per bit.
  • Releasing an asynchronous reset without a synchroniser, then seeing a state machine start in two states at once.
  • Gating a clock with an AND gate instead of using a clock enable.
  • Adding placement constraints before the logic depth has been reduced.
  • Treating an uncertain hold failure as harmless because “the router fixes those”. It fixes most, not all.

Going deeper