hold time violation

[Altera_Forum]

when i synthesis & fit my design, hold time violation is reported at my output port in fast model timing analysis. 

the fpga was connected with some slow device, which requires a relative large hold time, as 10ns. it is always compiled with negative slack, about -3~-7ns. i think i can add some delay on the output of data, but i did not find the way to route manually    btw: i am using cyclone ii which can only set the max 6ns delay by "Delay from Output Register to Output Pin" by assignment editor. and it is useless also.

[Altera_Forum]

It sounds like the constraints are setup, which is good. A few things to check: 

1) Assignments -> Settings -> Fitter. Optimize Hold Timing should be on for at least I/O(All Paths will work too) and make sure multi-corner optimization is checked. I don't think this latter is on by default in many versions. 2) Double check the setup slack at the slow corner. To add ~10ns in the Fast is probably adding 20-25ns in the slow corner, depending on speed grade. If that's tight on setup timing, the fitter is just trying to split the difference. 3) Make sure there is no Fast Output Register = On assignment. (You would have manually done this, so unlikely). This would force it into the I/O, and as you said, the delay chain can't be large enough to meet timing. 4) A location assignment for the register far away from the I/O should do the trick, although you shouldn't have to do this. Highlight the register in the TimeQuest report, Locate -> Assignment Editor so the register name shows up in the To column, Location as the assignment, and do something like LAB_X1_Y1, for example, to put it in the bottom left corner. 5) A 10ns hold requirement is quite large. Usually when I've seen stuff like that, it's met by sending data out on the falling edge, which adds a half-cycle delay that is PVT invariant. Just an idea.

[Altera_Forum]

is there any way to insert some LCELL as delay chains?

[Altera_Forum]

You can manually instantiate them. lcell is the name, and I believe in and out are the ports. (I think in VHDL a_in and a_out are the ports, since in and out are keywords). Naturally without hand-placing them, you can get a lot of variance. If you have timing constraints that require a positive hold, check that Assignments -> Settings -> Fitter has Optimize Hold Timing set to All Paths and Optimize Multi-Corner is checked. This tells the router to add delays to try and meet hold requirements. As a test, I took a FF->FF in Cyclone 3 and added a 20ns hold requirement. The router was able to meet this by routing around the chip almost twice. (Note that it failed at first because I had a 30ns setup requirement. Adding 20ns in the fast corner is ~40ns in the slow corner, so I had given it impossible constraints. By making the setup relationship 50ns or so(I don't remember), the hold could be met.)

[Altera_Forum]

i believe fitter would work in many situation. 

i checked the setup time for my design, it remains about ~20ns as slack in slow model, which means that fitter have sufficient time slack for hold time. but in realistic it is not. it is odd。

[Altera_Forum]

I am a bit worried about a device with +10ns tH. are you sure? or is it -10ns with tSU close to it but +ve.

[Altera_Forum]

--- Quote Start ---  I am a bit worried about a device with +10ns tH. are you sure? or is it -10ns with tSU close to it but +ve.  --- Quote End ---    it is a phy chip compliant with 10/100BASE-T. the hold time comes from the datasheet.

[Altera_Forum]

How much is the device tSU? 

 For tH of + 10 ns, and if you are sending clock and data together from fpga then you need to delay the clock relative to data. Alternatively, send the clock inverted, inversion may solve the tH problem since it implies half period clock delay.

[Altera_Forum]

10ns also. 

 ok, i will try that.

[Altera_Forum]

having tSU = 10 ns and tH = 10 ns gives a sampling window of 20 ns during which data should not change. The transition window is what is left of: 

clk period - 20ns. I hope you have enough margin left.

[Altera_Forum]

the period is 40ns. 

according to sta result, it would have 23ns slack for setup check, which, in my opinion, minus 10ns still have 13ns margin.

[Altera_Forum]

with 40 ns period, you have a sampling window of 20 ns since your tSU/tH window is 20 ns. Thus if your slack for tSU is 23, you are left with -3 ns slack for tH, a clear failure. 

 |------------------|_______________ |-------------clk(40 ns)  xxxxxx-----------------------xxxxxxxxxxxxxxxxxxxx--------tSU/tH  --x----------------------------------------x-----------data transition

[Altera_Forum]

but i can't adjust the slack for tSU, it was calculated automatically. 

i think the slack for tSU is too large.

[Altera_Forum]

If your output data and clock go together from FPGA then you need to set output delays as follows: 

 max delay = +tSU = +10 ns min delay = - tH = -10 ns  ignoring board effect

[Altera_Forum]

i find a para of text in Quartus handbook 10.1 in P13-6 

"When you turn on Optimize Hold Timing ...... the Fitter works to meet the following criteria: ■ Hold times (tH) from device input pins to registers ■ Minimum delays from I/O pins to I/O registers or from I/O registers to I/O pins ■ Minimum clock-to-out time (tCO) from registers to output pins" the second criteria only shows that fitter would minimum the delay between register and pins. but in the case above, it would not a right method. is it a bug or my misunderstanding?

[Altera_Forum]

--- Quote Start ---  If your output data and clock go together from FPGA then you need to set output delays as follows:  max delay = +tSU = +10 ns min delay = - tH = -10 ns  ignoring board effect  --- Quote End ---    unfortunately, the clock is not generated by fpga, it was determined outside. i have to set max delay larger than 10ns and min delay smaller than -10ns. dose quartus set half period as default sample window? can i change that value?  the typical tSU of external chip is 24ns and tH is 12ns, i think it would be easy to satisfy those requirement. because there is only one output register before output pin(see attachment:register2output) and the setup slack is still very large.(setup.jpg)

[Altera_Forum]

i find a strange tips, the upper report(fast corner model) shows register to pin data delay is just 8.355ns,but in slow corner model the data delay is 25.523ns. 

the same data path get such a tremendous different result. i think it is the problem. can i correct this by setting?

[Altera_Forum]

That variance seems a little large, but is probably correct. My rule of thumb is that the slow corner is always twice the fast corner.  

What device and version of Quartus? (Old versions, and I'm talking years ago, weren't as good meeting timing constraints like this). Do you have the Optimize Multi-Corner option checked? I would try that first, as it would explain why it can't meet the fast corner. Note that your constraints are pretty difficult. You have a 0ns hold relationship, with a -11ns min delay externally. That means the FPGA needs to get its data out in greater than 11ns at the Fast Corner. So if it were at something like 15ns, then doubling that for the slow corner would be 30ns. But you have a 40ns setup relationship and 11ns of that are chewed up externally, so the FPGA has 29ns to work with, i.e. the 30ns output delay would fail.  In general, if you need a long output delay, the quick trick is to drive it out on the falling edge. That adds a half-cycle delay that is PVT invariant, i.e. it's fixed. This should buy you a lot. A plug here, but you might want to look at the I/O section of the first chapter Getting Started in the TimeQuest guide I put on the alterawiki. Might help.

[Altera_Forum]

the environment is: 

device:cycloneiii quartus 9.0 sp2 optimize multi-corner option was checked.  i tried many times find that the slow corner is as above 2.8 times as the fast corner. actually tH=12ns tSU=15ns are acceptable as the specification. in double rate condition, it would work. but can not be in rate 2.8.

[Altera_Forum]

It probably wouldn't work with 2x difference. You're asking for the output delay to be greater than 12ns and less than 25ns. Technically it's possibly, but that's really, really difficult to dial into. Phase-shifts or clocking on the falling edge tend to be much better ways to solve something like this.  

(I'm guessing you're in the slowest speed device. That makes the spread a lot larger, as you basically get everything out of the fab. If the fab starts producing faster parts, it can still be marked as the slowest, which is another reason the spread is so large. A faster speed grade will reduce this variance, but I think there are probably other ways around this.)

[Altera_Forum]

ok, i got the problem.