Re: Quartus II and fixing hold timing

A hold violation is very rare on any FPGA if the design is synchronous and the dedicated clock distribution is used.

-- Mike Treseler

the

Hi Ken,

The Optimize Hold Time algorithm in Quartus 3.0 is smart enough to know where to add delay to fix Th without violating Tsu, if possible. So the behaviour you're seeing where fixing the hold violations causes setup violations is not generally expected.

That said, there are cases where we cannot fix Th without causing problems on Tsu.

1. Your circuit is such that the connections to which we have to add delay to fix a Th violation are also on another, Tsu-critical connection. If we add delay to resolve Th, we will violate Tsu. The only solution here is to re-work your circuit.

1. A sub-case of #1 above: the only part of a timing path to which we could add delay to meet a Th constraint at a register, without violating some Tsu constraint, is on the last LUT->reg connection on the Th path. If Quartus register packs this LUT and register together into one logic cell, a dedicated routing connection is used to make the connection from the LUT to the register, so we can't slow it down by adding more routing. The workaround to this is to set a constraint to force the LUT & register to be kept in separate logic cells. In our in-house PCI core, we have to turn off register packing on two banks of registers to allow the router the flexibility to fix the hold time problem. The constraint we set (in the file) is:

AUTO_PACKED_REGISTERS_STRATIX = OFF on low_ad_or_fb[] and high_ad_or_fb[]

If your PCI core uses similar names / has a similar structure this may give you an idea of what to register unpack. Looking at whether or not the registers at which you're having Tsu / Th problems were packed with LUTs in the Quartus floorplan editor will also let you see what's going on.

1. The same as #2, but the register and LUT were packed together by your synthesis tool. Depending on your synthesis tool, you may be able to tell it not to do this (but it'll be tool specific).

1. I've never tested the optimize hold time algorithm in cases where someone has inserted logic cells to slow down the clock (this isn't a common technique). It is possible Quartus is mis-estimating the delay at the point where the algorithm kicks in, and hence Quartus thinks it's OK on Tsu and Th, but is not. If you send me your circuit, I can see if this is the case, and if necessary upgrade Quartus to model this better.

2. You can buy Altera's PCI core. It works with Cyclone, and there are 32-bit and 64-bit versions. You can try it out (instantiate, simulate, place and route, timing analyze -- basically see that it works) for free, but have to buy it to generate programming files. See the Interfaces & Peripherals category on
   formatting link

The best way for me to give you more guidance on what went wrong and how you can fix it is for you to send a Quartus archive of your design to me. All such designs are treated as confidential -- we will use it in house only as a test case to improve our software.

Regards, Vaughn

Altera