hold time violation

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

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

i think the slack for tSU is too large.

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

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?

--- 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)

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?

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.

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.

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.)