SETUP & HOLD time confusion

In the Xilinx Synthesis and Simulation Design Guide there is this phrase:

"While Xilinx data sheets report that there are zero hold times on the internal registers and I/O registers with the default delay and using a global clock buffer, it is still possible to receive a $hold violation from the simulator. This $hold violation is really a $setup violation on the register. However, in order to get an accurate representation of the CLB delays, part of the setup time must be modeled as a hold time."

Can somebody put some more explanation to this phrase? I understand how the setup/hold window can be shifted back and forth by adding delay to the data path but I dont understand why the need for modeling part of the setup time as hold time, and how to properly fix hold time violations.

Thank you. /MHS

Reply to
M. Hamed
Loading thread data ...

Here is a stab at it. The min propagation delay from a flip flop to another flip flop plus the global clock uncertainty is more than the hold time of the destination FF. If the propagation delay is continuously increased, first you'll get a setup violation, if increased further... a hold violation, increased further... no violation. Once one hits the setup violation point and further, the functionality of the device comes into question.

I believe the answer is to limit the propagation delay with timing constraints.

Newman

Reply to
Newman

No, no, no. Let's not make a bad thing even worse.

I am ashamed that a Xilinx document publishes the above quoted nonsense. But let's at least look at the basics: Set-up time and hold-time are both input timing requirements. "3 ns set-up time" means, the new data must be there at least 3 ns before the clock edge, in order to be guaranted to be captured in the flip-flop. (like the airline says: you must be there one hour before departure) If data arrives later, it might actually make it, but there is no guarantee. A positive hold-time requirement (very rare and always bad!) means that the data being clocked in must actually linger on the D pin (for the specified positive hold time) beyond the clock edge. Bad requirement, since it is often very hard to live with. That's why most good parts specify "zero hold time", which means, you can take away the data right at the clock edge. In reality even a bit earlier, but that would have to be specified as a negative hold-time value, and few data sheets do. In other words, D must be stable from as early as a set-up time before the clock, to as late as a (positive) hold time after the clock, but most hold times are specified as 0. If you change D within this required timing window, the flip-flop will make the decision for you, whether it catches the early or the later data, but it usually catches a clean 0 or 1. If you change data at a very narrow "bulls-eye" point in time, then the flip-flop can indicate its displeasure by having an unpredictable output delay, the infamous metastable delay. I do not have the foggiest idea what the stupid sentence in your quote means, but it deserves to be eradicated and translated into English. Let me inquire. You obviously hit a sensitive nerve with me... Peter Alfke

On Apr 12, 6:02 pm, "Newman" wrote:

Reply to
Peter Alfke

I believe that the Op wanted to know how to alleviate the hold time violation. Many times in the post P&R simulation, the cause of a hold violation is the same as for a setup violation... excessive data path propagation delay from one flip flop to another. To get rid of it, one must reduce the combinational and routing propagation delay. If this was not clear, I failed in my explanation.

Newman

Reply to
Newman

To be blunt, no. The OP wanted to understand the barmy paragraph he read. It sounds like Peter is on a mission to get that fixed. In general a FF hold time violation is caused by excessive _clock_ path propagation to the FF in question. Fortunately, only a complete numpty would clock an FPGA FF with anything but a global clock signal. ;-) HTH, Syms.

Reply to
Symon

Just to follow up, it's important to realise that IC manufacturers do not usually give minimum propogation times for their circuits, just max times. This is because, over time, the manufacturing process might improve or whatever. The zero hold-time together with a max delay spec. and a clock distribution spec. are all you need. Anyway, I wonder why you are doing post P&R timing checks? The generally accepted method is to set timing constraints and let the P&R software take care of everything. HTH, Syms.

Reply to
Symon

I agree with what you said about timing constraints and global clocks along with synchronous design practices. I generally set up the top level testbench to simulate primary inputs to the FPGA when I do the top level behavioral simulation. Static timing is deemed sufficient for internal timing. Simulation is a necessary but insufficient for timing. After everything is ready to go, I'll do a sanity check with a full timing simulation mainly for primary input stimulus. I rarely get a timing violation, but I cannot say never. The information I gave is from an experience I had over ten years ago. I found that a hold time violation masqueraded as a too long prop delay. I just wanted to share that. Sorry if it upset you. I applaud Peter's passion for this board. He really cares about his customers.

Newman

Newman

Reply to
Newman

Hello Newman, OK, that's fine, but if you have an example where the post P&R failed the timing simulation but the P&R tool static timing said it passed, I'd be grateful if you could report it to the FPGA vendor. That would mean the design methodology followed by most folks on this newsgroup, myself included, is flawed, and something needs to be fixed.

Right, but the software's got better in the last ten years. On second thoughts, I take your point! :-)

Thanks, Syms.

p.s. I couldn't resist the Seinfeld opening! :-)

Reply to
Symon

Thank you, Newman, Peter, and Symon. As you have mentioned, I traced the problem down to a setup time problem reported as hold time violation. I still don't understand the paragraph in question, and hopfully Peter will provide the answer.

This is very likely to happen if you have functional asynchronous resets or inferred latches. But as you mentioned, only if you dont follow proper design guidelines.

/MHS

Reply to
M. Hamed

In some cases, the particulars of modeling the back annotated clock & data path delays results in certain simulation 'features' that can cause the exact location & type of the reported timing violation to migrate about within the post-PAR simulation model.

I have listed a few typical Answer Records of that sort below. (You didn't post the details of your timimg error, so I'm not suggesting that any of these are your exact problem.)

24220 9.1i Timing - Clock skew master record

24289 9.1i Timing - How does clock skew relate to Hold/Race Checks functionality?

17224 8.1i Timing Analyzer/TRACE - How does clock skew affect setup/ hold calculations? (Hold violation)

11067 SimPrim - ModelSim Simulations: Input and Output clocks of the DCM and CLKDLL models do not appear to be de-skewed (VHDL, Verilog)

18668 7.1i Timing Analyzer/TRCE - Timing tools do not properly adjust for my equivalent positive phase shift

23689 LogiCORE Blk Men Gen v2.1 - Virtex-4, timing simulation fails due to setup time violation in X_SFF

good luck, Brian

Reply to
Brian Davis

Reply to
Peter Alfke

Here is some stuff from

formatting link

Debugging Tips When you are faced with a timing violation, the following questions may give valuable clues as to what went wrong.

Was the clock path analyzed by TRACE or Timing Analyzer? Did TRACE or Timing Analyzer report that the data path can run at speeds being clocked in simulation? Is clock skew being accounted for in this path delay? Does subtracting the clock path delay from the data path delay still allow clocking speeds? Will slowing down the clock speeds eliminate the $setup/$hold time violations? Does this data path cross clock boundaries (from one clock domain to another)? Are the clocks synchronous to each other? Is there appreciable clock skew or phase difference between these clocks? If this path is an input path to the device, does changing the time at which the input stimulus is applied eliminate the $setup/$hold time violations? Based on the answers to these questions, you may need to make changes to your design or testbench to accommodate the simulation conditions.

Special Considerations for Setup and Hold Violations Zero Hold Time Considerations While Xilinx data sheets report that there are zero hold times on the internal registers and I/O registers with the default delay and using a global clock buffer, it is still possible to receive a $hold violation from the simulator. This $hold violation is really a $setup violation on the register. However, 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 Answer 782 at the Xilinx Support web site.

formatting link

The waveforms in Answer Record 782 looks bad probably because it needs to be displayed in a fixed font It was last updated on 08/06/01 and may not apply anymore.

Perhaps Peter can comment on the validity of the Answer Record 782. Hope this helps.

-Newman

Reply to
Newman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.