Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20623 Discussions

Random single hold violations on Arria V design that doesn't push timing or util. ???

Altera_Forum
Honored Contributor II
2,051 Views

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! 

/j
0 Kudos
17 Replies
Altera_Forum
Honored Contributor II
475 Views

Have 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?
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

they look reasonable, yes - but maybe I'll try turning auto-shift recognition off...

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

Actually, that won't help, since there are no altshift tap in the paths....

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

Confirmed - that was the issue

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

it can't add delays between DSP blocks?

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

I mean delay buffers, the conventional way to fix hold violations.

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

delay buffers, ie registers. You need to change the source code.

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

would prefer not to - delay buffers != registers - it adds analog (timing) delays to fix hold vios all over the chip. The solution here was to let it implement a few of the multipliers in LUTs 

 

best 

/j
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

there are no analogue buffers in FPGAs.

0 Kudos
Altera_Forum
Honored Contributor II
475 Views

Hold violations are cause by routes between registers being too long. To fix them, you make the distance between the reg's shorter. If this becomes too hard, because there are too many luts between the reg's, or the regs are inside the multiplers that cannot move, the easiest way to fix it is to add another stage in the pipeline between the multipliers to allow the fitter to shorten the distance between registers. 

 

LUT based multipliers will have poorer timing performance that the hard ones.
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

 

--- Quote Start ---  

there are no analogue buffers in FPGAs. 

--- Quote End ---  

 

 

so how does Quartus fix timing violations caused by clock skew? (sorry, I'm an ASIC guy where adding delay buffers is how you fix hold vios).  

 

 

--- Quote Start ---  

LUT based multipliers will have poorer timing performance that the hard ones.. 

--- Quote End ---  

 

 

you think? :-) 

 

/j
0 Kudos
Altera_Forum
Honored Contributor II
475 Views

 

--- Quote Start ---  

so how does Quartus fix timing violations caused by clock skew? (sorry, I'm an ASIC guy where adding delay buffers is how you fix hold vios).  

--- Quote End ---  

 

 

Basically, it will try and move the registers around, and maybe try a different routing.  

There are no buffers in FPGAs. Unlike Asics - generates clocks in FPGAs are a bad idea. they can have massive skew on them as the routing is not up to scratch. Clock enables are the much prefered/recommended method 

In the olden days, designers used to use LUTs to delay signals to account for skew or delay. AHDL even has an LCELL function that would insert an extra LUT for you at the HDL level. But as chips clocked faster, this trick became less reliable as the effects of temperature , placement and routing had a much greater effect on the delay than the LUTs themselves, so you have no reliable way to delay a signal enough. 

 

So, in FPGA land, the only way to fix hold violations is to make the route shorter. Easiest way to make the gap shorter is to reduce the logic between registers. Or when it comes to DSPs or RAMs, add extra pipelining. It's quite common when you get to the limits of the chip fmax, you can only have 1 or 2 luts between registers, and even then as the chip gets full, extra pipeline states are required to account for the routing delay and congestion around the chip.
0 Kudos
Reply