1. Home
  2. Field-Programmable Gate Arrays
  3. Re: Quartus II and fixing hold timing

Re: Quartus II and fixing hold timing

> I'm using Quartus II version 3.0 and am having trouble meeting setup > and hold timing. This is a large PCI design in the > Cyclone 12C device. The routing I'm getting is really bad so my > setup time violations are pretty bad. I can fix the setup times by > inserting 2 LCELL buffers on the PCI clock and placing the buffers > in such a way to get a lot of clock insertion (around 8 ns). If I synthesize

the

design without hold time fixing enabled then I can get Tsu and Tco > to pass (just barely). I have the PCI logic back annotated (placement > not routing). If I then synthesize while enabling hold time fixing > Quartus fixes most of the hold time violations but breaks the setup > timing even though the PCI logic is back annotated. I think Quartus > must be pretty dumb as far as fixing hold timing. If the worst > case setup time is around 15 ns (8 ns clock insertion + 7 ns PCI setup > time requirement) then those worst case paths should have no problem > with hold times. If quartus just placed delays on the short paths > it could fix hold timing. But I suspect that it's placing the delays > around the pin and affecting both long and short paths. > > Has anyone else seen this? Does anyone have any idea of how to fix hold > timing while not breaking the setup paths?

I think the best way to fix the setup and hold time problem is to fix the routing. The best way to fix the routing is to fix the placement to permit the routing to be good.

Even if you fix the timing by adjusting the relative clock delay, I don't think buffers are the way to do it. The delay from a buffer can vary over a wide range. So you may add a lot of delay max and very little min. The min delay will help with the hold time, but the large max delay will detract a lot more from the setup! Perhaps a DLL is what you need?

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX
Reply to
rickman
Loading thread data ...

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

-- Mike Treseler

Reply to
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

Reply to
Vaughn Betz

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.