Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
17263 Discussions

Timing constrain between pll clock and clock divisor

Altera_Forum
Contributeur émérite II
1 465 Visites

Hi,  

i have a PLL that generate three clock frequencies: 10MHz, 20MHz and 48MHz. The 20MHz clock is used to generate a 555KHz clock dividing the 20Mhz by 36. 

I setted up the Timing analyzer with all clock informations: create clock, derived clock, derive pll clock, clock uncertainty. After the Timing Analysis i have a Setup Violation between registers path with 555KHz as launch clock and 48MHz as latch clock. I know that 10MHz, 20MHz and 555KHz stay all in integer ratio between them but not 48MHz. So, which SDC command i need to insert to manage this situation? 

 

Thanks 

 

Nick
0 Compliments
5 Réponses
Altera_Forum
Contributeur émérite II
692 Visites

derive_pll_clocks 

 

Then launch TimeQuest and run "Report Clocks". This will give the exact clock names for each one, and copy them to add a constraint like so: 

set_clock_groups -asynchronous  

-group {48mhz_clk}  

-group {10mhz_clk  

20mhz_clk  

555khz_clk} 

 

Naturally, your design needs to be able to handle any paths between 48MHz and the other domains as being asynchronous.
0 Compliments
Altera_Forum
Contributeur émérite II
692 Visites

Thnak very much Rysc.

0 Compliments
Altera_Forum
Contributeur émérite II
692 Visites

Another question: 

What about the PLL input clock? 

I must insert also the PLL input clock in the second group? (PLL input clock is 20MHz from an external oscillator)
0 Compliments
Altera_Forum
Contributeur émérite II
692 Visites

Anyone can help me? 

 

Thanks
0 Compliments
Altera_Forum
Contributeur émérite II
692 Visites

First, do you have paths between the 20MHz input clock and any of those outputs? If not, then it makes no difference if you put it in a group or not. All your doing is cutting non-existent paths. By default TQ will analyze all paths between the input clock and any of those PLL output clocks. If there are clocks that have funky relaitonships, such as 48MHz <=> 20MHz, you'll probably end up with a tiny setup relationship, the path will fail, and you then need to decide whether to modify the path so it doesn't exist or cut it some how(either with a set_false_path, or putting the clocks in different groups of a set_clock_groups assignment). 

So: 

a) In most designs, the reference clock only feeds the PLL and no logic directly, so there are not paths between it's logic(since it doesn't drive logic) and other domains. So it makes no difference. 

b) Some users don't like to put it in there so in case someone uses it to drive logic that erroneously feeds another domain, it hopefully fails timing and they can fix it. Some users like to put it in there so it more clearly shows what clock(s) it is related to and not related to. If it's not explicitly cutting paths, it's user preference. 

c) If you do have paths, especially asynchronous paths to other other domains that you want TQ to ignore, then you do want to put it in there(or cut those paths with set_false_path).
0 Compliments
Répondre