Answers Database
SIMPRIMS: What does it mean when I get setup or hold time violations in my simulation? What do I do?
Record #5255
Product Family: Software
Product Line: Model Technology
Product Part: Modelsim
Problem Title:
SIMPRIMS: What does it mean when I get setup or hold time violations in my simulation? What
do I do?
Problem Description:
Urgency: Standard
General Description:
What does it mean when I get setup or hold time violations in my
simulation? What do I do?
Solution 1:
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:
- Data path delays are too long for clocking speeds
- Clock skew is unaccounted for before simulation
- Data paths cross out-of-phase or asynchronous clocks (to
each other)
- Input data changing at the wrong time
Some questions for debugging setup or hold time issues are:
Did Trace or Timing Analyzer report the data path may run at
speeds being clocked in simulation?
Is clock skew being accounted for in this path delay? Was the
clock path analyzed by Trace or Timing Analyzer? Does
subtracting the clock path delay from the data path delay
still allow clocking speeds?
As far as simulation is concerned, one thing to note is that skew
will be modeled in the simulation, but not in TRCE (unless you use
the -skew switch for TRCE). Simulation may not equal TRCE if
skew is significant (such as using a non-BUFG clock).
trce -skew (for trce only)
or
setenv XILINX_DOSKEWCHECK yes (for trce and par)
Beware of using the environment variable with PAR. if you have
clocks on local routing, then the PAR timing score may oscillate
(because the timing score will be a function of both a clock delay
and the data delay, and ripping up paths to make the data path
faster may make the clock path slower, or vice versa). It should
only be within PAR on designs with paths that contain clocks that
use the global clock resources.
In general, please keep in mind the following 2 points when
constraining a design:
1) Period - quick way to apply to a design; it also lead in the
support of OFFSET which people can use to specify their IO timings.
It takes in consideration of the global buffer. It has lower priority
than from:to style. Again for single clock design without multicycle
it work very well.
2) FROM:TO - this is slightly more work but it works well with
complicated timing. Designs with multicycle, multiple clocks and
clocks are handle better this way. For IO how ever, you'll need to
add/subtract the delay of the global buffer. Note OFFSET before for
input and OFFSET after for output are support without a specification
of a period so you can get the best of both.
If the timing report and timing simulation still disagree significantly,
then you should look at the simulation closely, as TRCE is almost always
right when a NGDANNO vs. TRCE situation pops up.
Will slowing down the clock speeds eliminate the setup/hold
time violations?
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?
Is this path an input path to the device? Does changing the
time at which the input stimulus is applied eliminate the
setup/hold time violations?
Hopefully the answers to these questions help determine the
cause of the setup or hold time violation. Based on these
responses, possible design changes may need to be made in
order to accommodate the simulation conditions.
While Xilinx data sheets state that there are zero hold-times
on the internal registers and I/O registers with the default
delay, it is still possible to receive a hold-time violation
from the simulator. This hold-time violation is in reality a
setup violation on the register but in order to get an
accurate representation of the CLB delays, part of the setup
time must be modeled as a hold time. For more information on
this modeling please refer to (Xilinx Solution 782)
Setup and hold violations may also occur on the write cycle of
a RAM. Special care must be taken when writing to RAMs,
especially asynchronous RAMs. It is suggested to use
synchronous RAMs in your design whenever possible to simplify
the write timing for a synchronous design.
End of Record #5255 - Last Modified: 06/28/99 17:11 |
