Forum Discussion
New ContributorSTA 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
2 Replies
sstrellSuper Contributor
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_IntelThanks 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?
