03-08-2013 02:57 AM
Hi everybody! :)
I'm quite new in using Xilinx software and I have many warnings in an ISim post-PAR simulation of my project on a Virtex-6 XC6VLX760 device like this:
"at 11116055 ps(2), Instance /tb/uut/EL2/RU/ExRB/RAM1/Mram_bank/ : Warning: /X_RAMB18E1 HOLD Low VIOLATION ON ENBWREN WITH RESPECT TO CLKBWRCLK;
Expected := 0.174 ns; Observed := 0.081 ns; At : 11116.055 ns"
I guess it is a problem with block RAMs I'm using in the design, but I haven't a very clear idea about.
Has anyone of you ever had the same issue? Have I to worry about it? How can I solve?
Thanks in advance,
03-08-2013 07:46 AM
There can be many explanations for hold violations in post P&R timing simulation. Here's some common ones:
1) Your design did not meet the timing requirements. If this is the case, the hold violations should also
show up in static timing analysis. Hold time is checked even for unconstrained paths, so this should be
an easy one to look up.
2) The paths with the hold violation are using unrelated clocks, and therefore should not be check for
setup or hold violations. If this is the case, you may need to change some settings when you generate
the timing model. For example the clock crossing paths in a FIFO need to be ignored.
3) The design is fine, but your testbench stimulus does not meet the constraints you provided
to the timing analysis tools in the UCF. A common case is using a testbench designed for
behavioral simulation, which typically has no delay from the clock edge to the data signals
(just a delta delay - which works fine in behavioral sim but has zero time delay). This can generate
hold violations on the design inputs.
There are probably others.
By the way, I almost never run post place & route simulation. I do extensive behavioral simulation
and make sure that everything passes the static timing analysis. I generate post P&R static
timing reports with the Verbose option and Unconstrained Path reporting enabled to make sure
that I haven't underconstrained the design. If all of that is clean, there is generally little useful
to glean from post P&R timing simulation*. The nice thing about FPGA's is that it's easy to do
the post P&R testing in the actual hardware. Then it's only typically when I have a tough bug
that I might resort to post P&R timing simulation. More likely I find a case that doesn't work and
change my behavioral test bench to use the same stimulus that created the problem in hardware.
* Little useful that is, unless you are not careful with clock-domain crossing - and note that
CDC problems are harder to debug in post P&R timing sim if you are hammered with
lots of setup/hold violations that are not typically the real problem with the design.
03-11-2013 02:01 AM
thank you for the reply. I will try to investigate the conditions you explained me and will let you know if I will solve. :)
Meanwhile I'd like to have your opinion about the following error that simulation displays me:
"ERROR: In process X_RAMB18E1.vhd:prcs_clk
FATAL ERROR:ISim: This application has discovered an exceptional condition from which it cannot recover. Process will terminate.
INFO: Simulator is stopped."
Can it be related to the previous warnings I said? (the component X_RAMB18E1 is the same)
Thanks again if you can help me...