Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Suhas_P_Intel
Employee
948 Views

STA report using Quartus 18.0 pro

The clock period and the frequency in the attached spreadsheet for the constraints specified do not match constraints and each other. The desired frequencies are specified by using clock edges of uClock in the constraint file.

xtr_clk   25 to 10 MHz is 2.5:1 ratio so picking 1, 6, 11 edges of uClock

msg_clk 25 to 5 MHz is 5:1 ratio so picking 6, 16, 26 edges of uClock also looks correct.  6 because msg_clk is shifted by 25%

 

Suhas

0 Kudos
2 Replies
sstrell
Honored Contributor II
57 Views

Hmm. For xtr_clk, based on the edges, the clock rises at 0 ns, falls at 100 ns, and rises again at 200, making for a period of 200 (correct) and a frequency of 5 MHz (incorrect). For msg_clk, the clock rises at 100 ns (which is a falling edge in uclock but I don't know if that makes a difference), falls at 300 ns, and rises again at 500 ns, making for a period of 500 (incorrect) and a frequency of 2 MHz (also incorrect).

 

I'm not sure what's going on here, but I rarely, if ever, see the -edges option used. Is there a reason you're using time relationships instead of frequency?

Suhas_P_Intel
Employee
57 Views

​Thanks for confirming the reporting bug.

Using edges allows me to scale clocks without having to specify a period for each generated clock. I was hoping that the Quartus tool would do all the calculations. I only change the clock period of the source clock when I'm instantiating the PLL by passing correct parameters:

                                .c_cnt_hi_div0(hi),

                                .c_cnt_lo_div0(lo),

                                .output_clock_frequency0(outClockPeriod),                

Is this reporting bug likely to be fixed in the next release?             

Reply