Quartus Timing Issues

Hi Guys,

I am a relatively inexperienced user of Quartus (I did a thesis on it and now I am mucking around trying to get a FM demod working), and I have run into some issues on timing as my design grows large.

I am using a straix part and it is clocked at 80MHz, and I have a number of FIR filters in the design. There are currently 2 FIR filters that need to run at 80MSPS and then a seriec of filters that these feed into after decimation, so these other filters run a lower clock rates.

When I compile etc, the timing analysis gives a stack of critical warnings about the signals between the filters not having enough hold time etc. however it is basing th necessary hold times on the 80MHz clock (I think). I wantd to know how to:

1) Tell the timing analysier that these components are running at different clock speeds, and 2) Tell the fitter that 2 filters need to be fit to run at 80MHz and the others dont matter so much, so that I dont end up with the 80MSPS filters being spread out and not meeting the timing requirements whilst the slow ones do.

I hope someone has some clues and that I made sense.

Regards,

Paul

Reply to
Paul Solomon
Loading thread data ...

Consider running everything at 80MHz and use clock enable inputs where needed for lower effective rates.

-- Mike Treseler

Reply to
Mike Treseler

Hi Mike,

This seems to have solved my problems, I dont claim to understand how but it does seem to work.

Can you explain why this fixes the problem? As I thought forcing all the filters to be clocked at 80MHz would add additional constraints that would lessen the chance of a correct fit.

Regards,

Paul

Reply to
Paul Solomon

It's hard to be definitive without seeing your actual timing constraints, but it sounds like your original constraints set an 80 MHz timing constraint on the clock for the two higher speed FIR filters, and left the rest of the clocks unconstrained. It also sounds like those other clocks were reduced in speed through logic on the 80 MHz clock, which would result in a slower, but highly skewed, clock relative to the 80 MHz clock.

With no timing constraint on the slower clocks, Quartus will trace through the logic generating those clocks, see that it is fed by an 80 MHz clock, figure out the skew, and assume you want synchronous transfers from the 80 MHz clock to the slow clocks, if any data paths exist between these domains. The clock skew between the 80 MHz and slower clocks would be causing your hold violations. Quartus can automatically repair them by adding data delay if you ask it to, but that option is off by default to encourage designers to check their timing constraints and clock generation scheme first, just like this case.

By running everything at 80 MHz, you get rid of this clock skew, and make a cleaner design with much simpler hold time conditions.

Hope this helps,

Vaughn Altera [v b e t z (at) altera.com]

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.