The “Dark Art” of FPGA Timing Constraints: A Practical Guide to SDC & XDC

If you’ve spent more than a week in FPGA design, you know the feeling. You hit “Generate Bitstream,” go grab a coffee, and come back to see the dreaded red text: Timing Constraints Not Met.

But ignoring these errors or blindly applying “Synthesis Strategies” isn’t a solution. In high-reliability fields like avionics or automotive, a timing violation isn’t just a warning—it’s a potential metastability event waiting to happen in the field.

The XDC (Xilinx Design Constraints) or SDC (Synopsys Design Constraints) file is the contract you sign with the Static Timing Analysis (STA) engine. Today, we’ll move beyond the basics and dive into the technical mechanics of the four most critical command sets.

1. create_clock: Defining the Time Reference

The STA engine is purely mathematical. Without a reference period, it cannot calculate Setup (`Data Arrival < Data Required`) or Hold (`Data Arrival > Data Required`) slack.

However, defining a clock isn’t just about the frequency. A designer must also consider Jitter and Duty Cycle distortion. Furthermore, if you are interfacing with external synchronous devices (ADCs, SDRAMs), you must define Virtual Clocks.

Why Virtual Clocks?
The I/O delay constraints need a reference clock. If the external device’s clock doesn’t physically enter the FPGA (e.g., it shares a board-level oscillator), you cannot use `get_ports`. You need a virtual container to represent that external time domain.

clocks.xdc

# 1. Standard Clock (100MHz) on a physical pin create_clock -period 10.000 -name sys_clk [get_ports clk_in] # 2. Virtual Clock (For external device I/O analysis) # Note: No [get_ports] argument is used here. create_clock -period 10.000 -name virt_adc_clk # 3. Adding Input Jitter (Crucial for high-speed margins) set_input_jitter [get_clocks sys_clk] 0.100

2. set_input_delay & set_output_delay: System Level Budgeting

These are the most misunderstood commands in the history of FPGA design. Let’s be technically precise: These commands do NOT add delay lines inside the FPGA.

Instead, they subtract time from the global period budget. You are describing the physics of the PCB trace and the external IC’s datasheet parameters to the Vivado/Quartus analyzer.

A. Input Delay: The Data Arrival Equation

When an external chip sends data to the FPGA, the data is valid only after a certain delay relative to the clock edge. The STA engine needs to know: “How late is the data arriving at the FPGA pin?”

T_co (Clock-to-Output): Time for the external sensor to output data after the clock edge (e.g., 3ns).
T_trace (PCB Flight Time): Propagation delay on the copper trace (e.g., 1ns).

The Math: The data arrives at the FPGA pin at 4ns. If the clock period is 10ns, the internal logic has only (10ns – 4ns) = 6ns to latch the data.

input_constraints.xdc

# Input Delay = Max T_co + Max T_trace set_input_delay -clock [get_clocks sys_clk] -max 4.0 [get_ports rx_data]

B. Output Delay: The Setup Time Requirement

For outputs, the logic is inverted. You are driving a downstream chip (e.g., a DAC) which has a Setup Time (T_su) requirement. The data must be stable at the destination pin before the capturing clock edge.

T_trace: Flight time to the DAC (0.5ns).
T_su: DAC Setup requirement (1.0ns).

The Math: You must output the data 1.5ns before the next clock edge.

output_constraints.xdc

# Output Delay = T_trace + T_setup_of_external_device set_output_delay -clock [get_clocks sys_clk] -max 1.5 [get_ports tx_data]

3. set_false_path: Waiving Timing Checks

In a multi-clock system, paths crossing from `clk_A` (100MHz) to `clk_B` (148.5MHz) are asynchronous. The phase relationship is indeterminate. The STA tool will try to analyze this and fail miserably, reporting massive timing violations.

By applying `set_false_path`, you are telling the tool: “Do not optimize or analyze this path. I have handled it manually.”

Warning: This command does not fix the metastability problem; it hides it. You must ensure there is a double-flop synchronizer or an Async FIFO on this path in your RTL code.

cdc.xdc

# Ignore paths between asynchronous domains set_false_path -from [get_clocks clk_core] -to [get_clocks clk_ddr] set_false_path -from [get_clocks clk_ddr] -to [get_clocks clk_core]

4. set_multicycle_path: The “Hold Time” Trap

This is where the real designers prove their worth. Sometimes, combinational logic (like a complex DSP multiply-accumulate) is too deep to finish in one clock cycle (10ns). If your architecture permits capturing data every 2 or 3 cycles, you can relax the constraint.

The Problem: When you tell the tool `set_multicycle_path -setup 3`, it moves the Setup Check to the 3rd edge (30ns). However, by default, it also moves the Hold Check to the 2nd edge (20ns).

This is dangerous. You want to check for Hold violations (min delay) at the original launch edge (0ns) to prevent race conditions. Therefore, you must manually shift the Hold check back.

multicycle.xdc

# 1. Relax Setup: Allow 3 cycles (30ns) for propagation set_multicycle_path -setup 3 -from [get_pins dsp_A] -to [get_pins dsp_P] # 2. Fix Hold: Shift the hold check back by (N-1) cycles # If Setup is 3, Hold should be shifted back by 2. set_multicycle_path -hold 2 -from [get_pins dsp_A] -to [get_pins dsp_P]

Final Thoughts

Timing closure is an iterative process of physics and mathematics. The XDC file is your mechanism to model the physical reality of the board layout and the logical requirements of the silicon.

Next time you see a WNS (Worst Negative Slack) violation, do not just attempt to pipeline the logic. Verify your constraints. Are your I/O delays modeling reality? Are your false paths truly asynchronous? A clean constraint file is the foundation of a robust FPGA design.

Happy coding.
fpgawizard.com

Articles