Hold errors

--- Quote Start ---

Hi,

I have a two banks of registers, with bankA driving bankB. Both run from the same 6.4ns clock (from a PLL). I'm getting a hold error because it appears that the delay between the registers is extremely small(no logic in between, only routing). There is some clock skew between the clock arriving at bankA and the clock arriving at bankB. Once you add up the clock skew and hold time requirement for bankB, it's much larger than the data delay. This only happens to a few registers. Each bank is 80 registers.

I do have the 'all paths' turned on. Is there some other way that I can solve this issue. It's a single clock net driving both register banks so I'm not sure what else I can do.

How can I set a minimum delay or is that not a good idea?

Regards

MT

--- Quote End ---

Hi,

how large is your clock skew ? Is a global line used for the clock ? You can check that in the compilation report section "Fitter" -> "Global and other Fast signals". If the clock is not global defined it as global.

--- Quote Start ---

I'm getting a hold error...

I do have the 'all paths' turned on.

--- Quote End ---

If the hold violations are only with the fast timing model, then did you also turn on "Optimize fast-corner timing"?

Even if you already are using global routing as pletz suggested, it is not unusual to get hold violations between registers in two different kinds of resource blocks (LAB, RAM block, DSP block, I/O cell). The routing hop between the global metal and the register inside the block has different delays for these different blocks, causing some clock skew. I haven't had any trouble fixing these hold violations with the Fitter's hold optimization. I don't remember seeing hold violations between registers in the same kind of resource block when using global routing for the clock, but it is possible to have some small clock skew even in that case.

It's unusual for Quartus not to get this right.

I usually find that the reason for hold errors is that the clock path delay is much larger than I thought - typically because someone created a gated clock.

Find the hold error in the timing analyzer and then right click on it and go "list paths"

In the box at the foot of the screen, open all the little boxes with + in them until you can see the path of the clock for your second register bank. Check it isn't going somewhere you didn't expect, like not on a global wire, or through an LAB.

--- Quote Start ---

... it is not unusual to get hold violations between registers in two different kinds of resource blocks (LAB, RAM block, DSP block, I/O cell).

--- Quote End ---

--- Quote Start ---

It's unusual for Quartus not to get this right.

--- Quote End ---

I should have been more clear. I meant that this kind of hold violation is not unusual when the Fitter is not optimizing hold for all paths. I don't recall ever seeing this kind of hold violation when I did enable this hold optimization including fast-corner optimization.

--- Quote Start ---

I usually find that the reason for hold errors is that the clock path delay is much larger than I thought - typically because someone created a gated clock...

--- Quote End ---

What drdr6 suggested for gated clocks is good advice for the Classic Timing Analyzer. For either timing analyzer, look for unusually large clock skew. In TimeQuest you can look through details of the clock paths for the source and destination registers if you use "-detail full_path" for report_timing; that is similar to looking through the Classic Timing Analyzer List Paths submessages as drdr6 suggested. For Report Timing in the TimeQuest GUI, you can see the clock skew on the "Statistics" tab.

If you do have a gated clock, then see http://www.alteraforum.com/forum/showthread.php?t=2388.

--- Quote Start ---

... go "list paths"

In the box at the foot of the screen, open all the little boxes with + in them...

--- Quote End ---

To open all the List Paths submessages at once, press <Ctrl> while clicking the "+".