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

STA report using Quartus 18.0 pro

Suhas_P_Intel
Employee
1,282 Views

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 III
391 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?

0 Kudos
Suhas_P_Intel
Employee
391 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?             

0 Kudos
Reply