Skip to content

XDC and timing constraints

Constraints are part of the design specification. They tell implementation which package pins to use and tell static timing analysis what timing the external world requires.

Start from the official master XDC

Use the Digilent Basys 3 master XDC:

  1. Save a copy inside the project.
  2. Uncomment only the clock and peripherals used.
  3. Rename each port inside get_ports to exactly match the top entity.
  4. Keep unused constraints commented.
  5. Record the board revision.

Example clock:

set_property PACKAGE_PIN W5 [get_ports clk_i]
set_property IOSTANDARD LVCMOS33 [get_ports clk_i]
create_clock -add -name sys_clk -period 10.000 -waveform {0 5.000} [get_ports clk_i]

The 10 ns period expresses 100 MHz.

Port constraints

Typical physical properties:

set_property PACKAGE_PIN V17 [get_ports switch_i]
set_property IOSTANDARD LVCMOS33 [get_ports switch_i]

set_property PACKAGE_PIN U16 [get_ports led_o]
set_property IOSTANDARD LVCMOS33 [get_ports led_o]

Other properties such as drive strength, slew, pull-up, or pull-down should be applied only when the interface and board require them.

Timing constraint order

A useful mental order is:

  1. Define primary clocks.
  2. Define generated clocks.
  3. Define external input and output delays for synchronous interfaces.
  4. Declare clock relationships or asynchronous groups where justified.
  5. Add specific path exceptions only after understanding the path.

Input and output delays

For a synchronous external device, constraints must model time outside the FPGA:

set_input_delay  -clock ext_clk -max 3.0 [get_ports data_i[*]]
set_input_delay  -clock ext_clk -min 0.5 [get_ports data_i[*]]
set_output_delay -clock ext_clk -max 2.5 [get_ports data_o[*]]
set_output_delay -clock ext_clk -min -0.2 [get_ports data_o[*]]

These numbers are examples only. Derive them from the external component data sheet, PCB delay, and clock relationship.

Buttons and switches are asynchronous user inputs, so an I/O delay relative to the system clock is not a truthful model. Synchronize them and constrain/analyze the CDC structure instead.

False paths are not performance fixes

A false-path exception tells timing analysis that a path does not need to meet normal timing. It does not make the electrical path safer.

Only declare a false path when the functional architecture makes the timed relationship irrelevant—for example, within a correctly designed asynchronous CDC exception strategy.

Danger

Never add set_false_path simply to make red timing numbers disappear. You are removing analysis, not correcting hardware.

Multicycle paths

A multicycle path is valid only when the receiving logic intentionally has multiple clock cycles to capture data and the enable/protocol guarantees that behavior.

When specifying a setup multicycle, consider the corresponding hold relationship. Copying a one-line exception without deriving both can create an unsafe analysis.

Constraint queries

Test object selection in the Tcl console:

get_ports *
get_clocks *
get_cells -hierarchical *sync*
report_clocks
report_clock_interaction

If a query returns nothing, the constraint may silently affect no objects or produce a critical warning. Read the constraint messages.

Timing concepts

For a register-to-register path:

launch clock → source clock-to-Q → combinational/routing delay → setup at destination
  • Setup check: data must arrive early enough before the capture edge.
  • Hold check: data must remain stable long enough after the capture edge.
  • Slack: required time minus arrival time.
  • WNS: worst negative slack.
  • TNS: sum of negative setup slack over failing endpoints.

A safe baseline for a completed implementation is no failing setup or hold paths across all properly constrained path groups.

Essential reports

After implementation:

report_timing_summary
report_timing -max_paths 10 -sort_by group
report_utilization
report_drc
report_clock_interaction
report_cdc

Check the unconstrained-path sections of the timing summary. A design with “timing met” but missing clock or I/O constraints can be falsely reassuring.

XDC review checklist

  • Board revision and master XDC source are recorded.
  • Every used top-level port has the correct pin and I/O standard.
  • The 100 MHz input clock is constrained to 10 ns.
  • Generated clocks are defined when real generated clocks exist.
  • Synchronous external interfaces have input/output delays.
  • Every timing exception has a written architectural reason.
  • No important constraint query matches zero objects.
  • Timing summary reports no unintended unconstrained paths.