Forum Discussion

Suhas_P_Intel's avatar
Suhas_P_Intel
Icon for New Contributor rankNew Contributor
7 years ago

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

​

2 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    7 years ago

    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's avatar
    Suhas_P_Intel
    Icon for New Contributor rankNew Contributor
    7 years ago

    ​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?