FPGA Constraint Extensions

Timing constraints — clocks, generated clocks, I/O delays, exceptions, OCV and MCMM setup

FPGA Constraint Extensions

An FPGA is a chip you configure after it is built. Instead of fixing logic in silicon, you load a design into a sea of pre-made blocks and programmable wires. The timing of that design still has to be checked, and the same SDC ideas apply. But FPGAs add their own concerns, and an FPGA timing-constraint format extends the basic SDC commands to handle them. This chapter explains what carries over from ASIC constraining, what is added, and where the differences bite.

The Same SDC Foundation

The core SDC commands you already know work the same way on an FPGA. You still define clocks, describe when signals arrive and leave at the pins, and tell the tool which paths to ignore or relax.

• create_clock defines a clock with a period and waveform.
• create_generated_clock derives a divided or multiplied clock from a source.
• set_input_delay and set_output_delay describe timing at the pins relative to a clock.
• set_false_path removes a path from analysis.
• set_multicycle_path gives a path more than one clock period.
• set_clock_groups declares clocks unrelated so cross-clock paths are not checked.

# standard SDC — portable across compliant tools
# A 125 MHz clock has a period of 8.00 ns
create_clock -name sys_clk -period 8.00 [get_ports sys_clk]
set_input_delay -clock sys_clk -max 2.40 [get_ports data_in]
set_output_delay -clock sys_clk -max 1.90 [get_ports data_out]
set_false_path -from [get_ports async_rst]

If you can constrain an ASIC, you already know most of FPGA constraining. The clock period of 8.00 ns for a 125 MHz clock, the input delay of 2.40 ns, the false path on an asynchronous reset: these read exactly the same on either target. The foundation is shared because the timing math, setup and hold checks against clock edges, is the same physics.

FPGAs have built-in resources you do not design yourself. Constraints must point at those resources. This is where an FPGA timing-constraint format extends plain SDC with extra commands and properties. Pin placement. An ASIC port maps to a pad you design. An FPGA pin maps to a fixed physical package pin that already exists. You must tell the tool which package pin a port uses and what electrical standard it follows. These are physical-assignment constraints layered on top of timing constraints. Dedicated clock resources. FPGAs have special clock-capable input pins and dedicated clock-routing networks. A clock entering on a normal pin cannot reach the dedicated network and will have poor, unpredictable skew. Constraints and good design steer clocks onto clock-capable pins so they use the dedicated routing. On-chip clock generators. FPGAs contain blocks that take an input clock and produce new clocks at different frequencies and phases. These are configured, not built from gates. The tool usually creates generated clocks for their outputs automatically, but you still constrain the input clock that feeds them.

capable pins

Clock Regions and Dedicated Routing

A clock region is a physical area of the FPGA fabric served by a limited number of dedicated clock lines. The chip is divided into these regions, and each region can only carry so many distinct clocks at once. This is a hard resource limit with no ASIC equivalent, where you would simply route more clock wires. Dedicated routing is the special low-skew wiring reserved for clocks and a few other global signals. Because it is purpose-built, a clock on dedicated routing reaches all its flip-flops with small, predictable skew. A clock forced onto general-purpose routing, by contrast, has large and variable skew that wrecks timing. The practical effect on constraints:

• A clock should enter on a clock-capable pin so it can reach dedicated routing. A constraint or assignment pins it there.
• The number of clocks in one region is capped. If a design needs more clocks than a region supports, the tool fails placement, and you may need to restructure clocking.
• High-fanout control signals like a global reset can also use dedicated networks, freeing general routing for data.

A worked example. A design uses four clocks. The target FPGA's clock regions each support a limited set of dedicated lines. The team places the four clock sources on clock-capable input pins and

confirms each clock's loads fall within regions that can reach those clocks. One clock that drives logic spread across the whole device must use a network that spans regions; the team constrains it onto a global clock resource. The data-path constraints, periods and I/O delays, are ordinary SDC; the clockresource steering is the FPGA-specific layer.

I/O Timing on an FPGA

I/O timing on an FPGA still uses set_input_delay and set_output_delay , exactly as on an ASIC. The numbers describe the same thing: how long after a clock edge an input is valid, and how much time downstream logic needs after an output changes. The difference is what the delays must account for. An FPGA input may pass through dedicated input registers and fixed input buffers before reaching fabric. The package and board add delay. So the input delay you set should reflect the external board timing, and the tool adds the internal FPGA delays it already knows.

# standard SDC — portable across compliant tools
# Source-synchronous-style input: data arrives 2.10 ns after the clock edge,
# earliest valid 0.60 ns after the edge
create_clock -name rx_clk -period 6.00 [get_ports rx_clk]
set_input_delay -clock rx_clk -max 2.10 [get_ports rx_data*]
set_input_delay -clock rx_clk -min 0.60 [get_ports rx_data*]

A worked example. A 166.7 MHz interface has a period of 6.00 ns. External logic guarantees data is valid no later than 2.10 ns after the clock edge and stays stable until 0.60 ns after the next edge. You set max input delay 2.10 and min input delay 0.60. The FPGA tool combines these with its known internal input-path delays to check setup and hold at the capturing register. The constraint commands are pure portable SDC; only the awareness of fixed internal delays is FPGA flavor.

How FPGA Constraining Differs from ASIC

The commands overlap heavily, but the mindset differs in a few important ways.

The biggest practical difference is finiteness. An FPGA has a fixed number of registers, clock lines, and routing tracks. Over-constraining, asking for tighter timing than you need, makes the tool work harder and consume more of those finite resources. On an ASIC over-constraining costs area and power; on an FPGA it can cause the design to simply not fit. A second difference is that much of the clock infrastructure is pre-built. You do not synthesize a clock tree; you choose dedicated networks. This means clock skew is usually low and predictable, so some of the careful skew management an ASIC needs is replaced by correctly steering clocks onto the right resources. A third difference is that asynchronous clock relationships are extremely common on FPGAs, which often bridge many external interfaces. Declaring unrelated clocks with set_clock_groups is routine.

# standard SDC — portable across compliant tools
# Three clocks that never interact: tell the tool not to check paths between them
set_clock_groups -asynchronous \
-group {sys_clk} \
-group {rx_clk} \
-group {tx_clk}

Declaring sys_clk , rx_clk , and tx_clk asynchronous means the tool will not try to time paths that cross from one to another. Those crossings are handled by synchronizers in the logic, not by static timing. This keeps the report focused on paths that the clock relationships make meaningful.

Interview Q&A

create_clock , create_generated_clock , set_input_delay , set_output_delay ,
set_false_path , set_multicycle_path , and set_clock_groups . The timing math, setup and hold

against clock edges, is identical, so a 125 MHz clock is still an 8.00 ns period and an input delay still describes arrival relative to that clock on either target.

resources: which package pin a port uses and its I/O standard, steering clocks onto clock-capable pins and dedicated routing, and constraining the input clocks of built-in clock-generator blocks. These exist because the FPGA's resources are pre-built rather than designed by you.

served by a limited number of dedicated clock lines. Each region can carry only so many distinct clocks. It matters because exceeding that limit makes placement fail, a hard resource cap with no ASIC equivalent where you would just route more clock wires.

skew wiring, so a clock on it reaches all its flip-flops with small, predictable skew. A clock forced onto general-purpose routing has large, variable skew that breaks timing. Constraints and assignments steer clocks onto clock-capable pins so they reach the dedicated network.

finite supply of registers, clock lines, and routing tracks. Asking for tighter timing than needed makes the tool consume more of those finite resources, which on an ASIC merely costs area and power but on an FPGA can make the design fail to fit entirely.

many external interfaces with unrelated clocks, such as a system clock, a receive clock, and a transmit clock. Declaring them asynchronous stops the tool from timing paths that cross between them, since those crossings are handled by synchronizers in the logic rather than by static timing analysis.

Key Takeaways

• The SDC core is shared: clocks, I/O delays, and path exceptions work the same on FPGA and ASIC.
• FPGA formats add physical assignments: package pins, I/O standards, and steering clocks to dedicated resources.
• Clock regions are a hard, finite limit on how many clocks an area of fabric can carry.
• Dedicated routing gives low, predictable skew, so steering clocks correctly replaces much ASIC skew management.
• Over-constraining can stop an FPGA from fitting, so constrain to real requirements and declare unrelated clocks asynchronous.