FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 07-10-2005, 02:54 PM
Paul Solomon
Guest
 
Posts: n/a
Default 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 With Quote
  #2 (permalink)  
Old 07-10-2005, 05:01 PM
Mike Treseler
Guest
 
Posts: n/a
Default Re: Quartus Timing Issues

Paul Solomon wrote:

> 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.


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

-- Mike Treseler
Reply With Quote
  #3 (permalink)  
Old 07-11-2005, 02:27 AM
Paul Solomon
Guest
 
Posts: n/a
Default Re: Quartus Timing Issues

"Mike Treseler" <[email protected]> wrote in message
news:[email protected]
> Paul Solomon wrote:
>
>> 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.

>
> Consider running everything at 80MHz and use
> clock enable inputs where needed for lower
> effective rates.
>
> -- 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 With Quote
  #4 (permalink)  
Old 07-13-2005, 06:08 AM
Vaughn Betz
Guest
 
Posts: n/a
Default Re: Quartus Timing Issues

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]




"Paul Solomon" <[email protected]> wrote in message
news:[email protected]
> "Mike Treseler" <[email protected]> wrote in message
> news:[email protected]
>> Paul Solomon wrote:
>>
>>> 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.

>>
>> Consider running everything at 80MHz and use
>> clock enable inputs where needed for lower
>> effective rates.
>>
>> -- 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 With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Timing Issues in Quartus design pjjones FPGA 1 11-11-2004 04:11 AM
Acek 1K - Quartus II - timing issues Kumaran FPGA 6 11-25-2003 03:24 PM
Re: Quartus II and fixing hold timing rickman FPGA 0 08-08-2003 05:16 AM


All times are GMT +1. The time now is 12:27 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved