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: