Showing results for 
Show  only  | Search instead for 
Did you mean: 

Timing Constraints: Part 2 (of 5)

6 7 15.1K

Following along the forum traffic, it has come to my attention that timing constraints are often a mystery to new users.  In order to help those who have never had to constrain their timing, I continue with part 2 (of 5) on timing constraints.



Setup and Hold


In a practical synchronous digital system, the data must arrive before the clock edge that samples it.  The minimum amount of time in which the data must arrive before the clock edge is called the setup time.

As well as arriving before the clock edge, the data must persist for some finite amount of time at the clock edge.  This is called hold time.  Hold time may be negative, zero, or positive.  When it is negative, the data goes away before the clock edge. When it is zero, the data persists until the clock edge.  When it is positive, the data persists for some time after the clock edge.

By design, in the FPGA fabric, for all speed grades, all hold times are either negative or zero.  This simplifies the placement and routing, as the data only needs to arrive before the clock edge, and is allowed to change immediately following a clock edge.

The value that the data exceeds the minimum setup time is known as slack.  Slack should always be positive.  If a report shows a negative slack, then the setup timing will be inadequate (data will arrive too late).

The clock path itself has delay, or skew.  Thus, to analyze the timing, the tools will calculate the arrival time of the data and the clock at the flip-flop of interest.



If you recall from last time, the period constraint defines the clock period for the synchronous elements of interest (the flip-flops).  The timing analyzer verifies that all paths between synchronous elements meet the setup and hold timing for your design.  A violation of a period constraint will appear in the timing report, and have a negative slack value. It will either be identified as violating a setup requirement or a hold requirement.

If a setup requirement has been violated, then the data needs to arrive at the flip-flop sooner.  To do so may require a faster path.  If the place and route software cannot find a faster path, you do have the option of placing the path manually in the FPGA_Editor tool, but this is a tool of last resort. It is better to try to re-architect the circuit to meet the requirement.  One way to do this is to place a flip-flop earlier in the path.  This is known as pipe-lining, and will add latency to the signal, but it will also allow the value to be captured properly.

If a hold requirement has been violated (the data went away before the clock edge arrived), then this is often an indication that you have a design problem (bad architecture).  Values should only change on the clock edge, and not before.  If an external value is changing before the clock edge, one needs to delay the clock edge (using a DCM or PLL) so that the data is now registered properly by the new delayed clock.

An alternative is to use the Idelay element in the IOB to move the data to where the clock is valid.


Data Valid Window

The time from before the clock edge (setup) plus the time after the edge (hold) is known as the data valid window, or the time the data must be stable to be properly registered.  If the data is not valid for at least this amount of time, then the results are indeterminate, or unknown.



Just because the data was not valid for as long as required does not mean that the output of the flip-flop is metastable--metastable is different from indeterminate!  An output could be 0 or 1, seemingly at random, if the timing is not met.  Metastability means the edge was “almost” capable of capturing the state and the flip-flop output is in some intermediate state (not 1, not 0) for some time after the clock edge.  Metastability cannot be prevented, as it is a fact of the physics of the circuits, if the clock edge and the data are almost perfectly “missed.”

In a properly designed synchronous system there are no problems with metastability.  Metastability is a problem when something is asynchronous, like pressing a key on a keyboard, or when two synchronous clocks are asynchronous to each other.  When something is asynchronous, it needs to be synchronized.

For how to deal with metastability, please consult:

Next time:  Tprop, or offsets.

Austin Lesea


Constraints Guide:  Constraint Syntax for UCF, PCF, HDL

Timing Constraints User Guide:  Conceptual information on how to constrain a design

Timing Analyzer Help:  General information on how to use timing analyzer

Message Edited by austin.lesea on 02-16-2010 10:10 AM

Part 1 & 2 are very helpful to build the concepts. 

Timing Constraints: Part 3 of (5) onwards are available? pls let me know




If enough people ask for the entire series, I will ask to get it converted to pdf and posted.

My schedule right now is once every two weeks or so to post the next part.


Thank you, I am glad these articles are helpful,



Nice link about metastability.


But how can one assure the FFs in a synchronizer are close to each other? And when used for crossing clock domains, you still get errors for not meeting timing requirements. Wouldn't it be possible for Xilinx to create an IP core for a good synchronizer that solves all this?




Hello, austin:


"Hold time may be negative, zero, or positive.  When it is negative, the data goes away before the clock edge."

"By design, in the FPGA fabric, for all speed grades, all hold times are either negative or zero."

"If a hold requirement has been violated (the data went away before the clock edge arrived)"


I conclude FPGA violates hold requirement by design from the three quotations. So what goes wrong with my deduce?




Proper use of timing constraints will locate the DFF in the same slice (constraint the path from DFF1 to DFF2, or a LOC constraint)....


Regardless, metastability can not be eliminated, only reduced to some acceptable level, so there is no such thing as a "solution."  Only you can decide if you have a low enough probability to meet your requirements.






OK, let me think this through (again).  Positive hold time means you REQUIRE the data to persist after the clock edge.  This can be very bad (difficult) to place and route).  So, by design, the FPGA fabric has no positive hold time requirements (or, at least, so few that it  makes placing and routing possible, and reliable).


OK, so let us say our hold time is 0.  And, we have a setup time of 500ps (just an example).  The data MUST be present 500 ps before the clock edge, and persist right up to the  clock edge. ' Violation' of this hold requirement would be that the data goes away at any time before the clock edge.






       i new to the timing constarits. I have worked on small example of d_ff is


library IEEE;


entity dff is
Port ( clk,rst : in STD_LOGIC;
d_in : in STD_LOGIC_VECTOR (7 downto 0);
d_out : out STD_LOGIC_VECTOR (7 downto 0));
end dff;

architecture Behavioral of dff is

d_out <= (others =>'0');
elsif(clk'event and clk='1')then
d_out <= d_in;
end if;
end process;

end Behavioral;


i have given the constarit as a



NET "clk" TNM_NET = clk;
TIMESPEC TS_clk = PERIOD "clk" 5 ns HIGH 50%;
INST "d_out<0>" TNM = d_out_da;
INST "d_out<1>" TNM = d_out_da;
INST "d_out<2>" TNM = d_out_da;
INST "d_out<3>" TNM = d_out_da;
INST "d_out<4>" TNM = d_out_da;
INST "d_out<5>" TNM = d_out_da;
INST "d_out<6>" TNM = d_out_da;
INST "d_out<7>" TNM = d_out_da;
TIMEGRP "d_out_da" OFFSET = OUT 7.6 ns AFTER "clk";


in this case offset out , if have give vaule less than 7.6 ns then it is showing that setup violation