Forum Discussion
Honored ContributorRandom single hold violations on Arria V design that doesn't push timing or util. ???
Hi - I have a design that uses about 20% of the FPGA Fabric on an ArriaVSoc. I've added my own logic to the GHRD. It doesn't push timing (my logic is 100MHz or less), or utilization (see above, even memory utilization is < 30%), but about 50% of the builds fail with a single hold violation. About 1/3 the time it's on altera_reserved_tck, and the other 2/3 it's in a random place in my portion of the design (but never in the same place twice). Messing with the seed eventually fixes it (until next time), but it takes about an hour to build, so re-building is a pain I have Placement and routing effort turned up (4.0 and max). The thing that in all cases it looks like a buffer would have fixed it. is this a bug? Is there a fix? Is there a workaround? I'm running the latest Quartus 13 on CentOS.
Thanks! /j17 Replies
Altera_ForumHave you analysed the hold timing? is it always in the same block? how many layers of logic are there between the registers where the hold violation occurs. If you are getting it 50% of the time that suggests poor logic design, even with 100MHz clock.
If it's failing in the same place, how about posting the code where the design fails on timing?- Altera_Forum
Thanks Tricky. My design contains
a) the ArriaV SoC Golden Reference Design b) some new logic I generated c) a block I designed last year that has been built many dozens of times and ships in a customers' product.(albeit on a Stratix IV) I get hold violations, consistently, very deep in block c) in a simple multi-bit shift register on a single clock domain. (so very little logic between registers) Quartus just appears to be unwilling (or unable?) to insert delay between two sequential registers. If remove a significant amount of logic from the total design (like 1/2 of b) ) the issues go away. it's just weird.... I know how to fix setup vios, and cross-clock-domain stuff, but not hold vios deep in a single clock domain - except by adding buffers. /j - Altera_Forum
Check the start and end points - do they make sense?
In a previous version of Quartus I have seen it merge registers in two different entities, creating violations in two bits of logic that should have no relation to each other. I had to specific that auto-shift register recognition was turned off for these two entites - it broke the connection and removed the timing violations. - Altera_Forum
they look reasonable, yes - but maybe I'll try turning auto-shift recognition off...
- Altera_Forum
Actually, that won't help, since there are no altshift tap in the paths....
- Altera_Forum
ACTUALLY - I think I found the common thread. these are all DSP-block to DSP-block paths. In the original design, the customer was short on DSP blocks so I forced it to build gate multipliers, I removed that constraint for this revision. Trying it now with the constraint back in place.
Can't Quartus resolve hold vios between dsp blocks? /j - Altera_Forum
Confirmed - that was the issue
- Altera_Forum
It can, but not if the DSP blocks are too far apart. It doesnt have much scope to move them. The easiest way to make life easier is put an extra register between the DSPs in the source code, it means the path wont be so long and quartus has much greater scope to move them. Alternatively, use regions to lock specific DSPs in certain areas.
- Altera_Forum
it can't add delays between DSP blocks?
- Altera_Forum
what do you mean by "delay"? The code is synthesised into logic. Registers need to be added at the code level otherwise the code behaviour would not match the hardware.
