Help with $setuphold

[FP]

I am running a simulation after synthesis and I am getting the
following error.

** Error: C:/Modeltech_xe_starter/library/lib18.v(9835):
$hold( posedge CK &&& (flag == 1):54 ns, posedge E:54 ns, 500 ps );

lib18.v is a library with various net delays. I dont have anything
setup for setup and hold in my verilog testbench. I am getting the
same error, no matter what frequency I run the master clock at. How do
I get rid of this error?
Currenty the master clock is running at 200MHz(4 ns period)

Your help would be appreciated

 

[KJ]

On Jun 2, 9:08 am, FP <FPGA.unkn...@gmail.com> wrote:

I am running a simulation after synthesis and I am getting the
following error.

** Error: C:/Modeltech_xe_starter/library/lib18.v(9835):
$hold( posedge CK &&& (flag == 1):54 ns, posedge E:54 ns, 500 ps );

lib18.v is a library with various net delays. I dont have anything
setup for setup and hold in my verilog testbench. I am getting the
same error, no matter what frequency I run the master clock at. How do
I get rid of this error?
Currenty the master clock is running at 200MHz(4 ns period)

The reported error appears to be a hold time violation which means
that the signal is not remaining stable for the required amount of
time after the rising edge of the clock. To fix.
1. Identify exactly which signal it is
2. Determine if this is a design error or a modelling error and then
apply the appropriate fix.
3. Re-run the simulation.

As a first guess, it is likely that your testbench signals get
generated on the rising edge of your clock input and then go into your
design. But if the design has some non-zero hold time requirement
then the testbench inputs will be changing before the required time
and generate the error that you're seeing. This type of problem is
frequently a modelling error, your model of the environment in which
your design is operating is flawed in that it does represent the real
world (no real part would generate an input 0ns after the rising edge
of a clock). One way to fix this type of error would be to generate
the inputs on the falling edge of the clock.

It's also possible that the input signal truly is asynchronous to your
system clock. In this situation, hold time (and setup time)
violations are inevitable, your design has to handle the async inputs
properly with internal synchronizers but there is no way to get rid of
the simulation detecting the violation since it really is occurring.
One possible work around though would be to artificially add
synchronization to the testbench.

Kevin Jennings