What does it mean when I get setup or hold time violations in my simulation? What should I do?
Setup and Hold Times
The simulator will issue a setup or hold time violation any time data changes at a register input (data or clock enable) within the setup or hold time window for the particular register. There are a few typical causes of a setup or hold time violation:
- The path to this register was not constrained.
- The testbench is providing stimulus without taking the device setup and hold times into account.
- The path to this register is constrained, but is not meeting the specified constraint.
- The path was constrained and reported to be meeting timing, but clock skew was not taken into account.
- The data path to this register is asynchronous (see (Xilinx Answer 15969)).
For more information about Timing Constraints, please visit the Timing and Constraints Tech Tips page at:
Questions to ask when Debugging a Setup or Hold Violation:
Is the design properly constrained?
At a minimum, every design should have PERIOD, OFFSET IN, and OFFSET OUT constraints.
Are all of the paths going to this register covered by the timing constraints you have added to the design?
The setup or hold error message provides the instance name of the register on which the violation occurs. Locate this register in your design and ensure that all paths coming to this register are properly constrained.
Does the clock speed in the simulation match with the clock speed used when specifying the timing constraints?
Is this path an input path to the device? If so, does the external setup between the clock and the data match what was specified in the OFFSET IN constraint?
Is clock skew being analyzed?
In the 6.1i software, clock skew is analyzed automatically. Prior to 6.1i, TRCE must be run with the -skew option to analyze clock skew. The skew is modeled in the simulation.
Does this data path cross clock boundaries (from one clock frequency to another)? Are the clocks synchronous to each other? Is there appreciable clock skew between these clocks?
If this is an asynchronous path on which setup violations cannot be avoided, please see (Xilinx Answer 15969).
Hopefully the answers to these questions help determine the cause of the setup or hold time violation. Based on the responses, you may need to make design changes in order to accommodate the simulation conditions.
If you were not able to find the source of the problem by answering the above questions, you will need to trace backward in the simulation to find the exact cause of the problem.
1. Browse your design hierarchy and add the signals connected register on which the setup violation occurs.
2. Find the signal which caused the setup violation and trace back to its driver.
3. Continue tracing back through the components until you locate the pad or synchronous element that caused the signal to violate the setup time. (If a component has more than one input, trace back the active driver--i.e., the input that changed last.)
4. Now that you have the source of the problem, you can analyze the timing between the specific source and the destination. This should identify the problem.