Forum Discussion
Clock constraints for divided clocks
- 2 years ago
You may checkout the forum post here:
It seems for these very low frequencies you just lie. R
Reference:Best Regards,
Richard Tan
Thank you for your reply.
The PLS7r85ms and PLS94r2ms constraints don't seem to be ignored. Timing analysis only says they are illegal.
'set_false_path' is another thing here.
Later I will try your recommendation that setting the source for each of those as the input pin to cnt2 and cnt3 instead of the output pin of the previous block.
It is the policy in this project not to use a pll block to generate low-speed clocks. The target device here is MAX 10 10M08, so it has just 2 pll blocks. I already use some pll clock outputs for fast clocks. The rest are spared for future expansion.
Regards,
- HKana172 years ago
Occasional Contributor
I tried your suggestion to set the source for each of those as the input pin to cnt2 and cnt3 instead of the output pin of the previous block. But I got the same result.
#create_generated_clock -name PLS1r57ms -source [get_pins {SLOWCLK_1|cnt1|count[0]|clk}] -divide_by 15700 [get_pins {SLOWCLK_1|cnt1|count[13]|q}]
create_generated_clock -name PLS1r57ms -source [get_pins {PLL_inst|altpll_component|auto_generated|pll1|clk[0]}] -divide_by 15700 -duty_cycle 0.478 [get_pins {SLOWCLK_1|cnt1|count[13]|q}]#create_generated_clock -name PLS7r85ms -source [get_pins {SLOWCLK_1|cnt1|count[13]|q}] -divide_by 5 -duty_cycle 0.2 [get_pins {SLOWCLK_1|cnt2|count[2]|q}]
create_generated_clock -name PLS7r85ms -source [get_pins {SLOWCLK_1|cnt2|count[0]|clk}] -divide_by 5 -duty_cycle 0.2 [get_pins {SLOWCLK_1|cnt2|count[2]|q}]#create_generated_clock -name PLS94r2ms -source [get_pins {SLOWCLK_1|cnt2|count[2]|q}] -divide_by 12 -duty_cycle 0.33 [get_pins {SLOWCLK_1|cnt3|count[3]|q}]
create_generated_clock -name PLS94r2ms -source [get_pins {SLOWCLK_1|cnt3|count[0]|clk}] -divide_by 12 -duty_cycle 0.33 [get_pins {SLOWCLK_1|cnt3|count[3]|q}]Regards,
- sstrell2 years ago
Super Contributor
Looking again, duty_cycle should be a percentage. Try 20 and 33 instead of .2 and .33.
- HKana172 years ago
Occasional Contributor
Dear sstrell,
Thank you for your reply.
I got that the duty cycle number was of percent. Thank you. Today I didn't write duty cycle numbers.
I found 2 constraints for PLS7r85ms and PLS94r2ms clocks actually ignored. So far I have seen only the report tree of Timing Analyzer. Today I found messages in the console of Timing Analyzer.
But I can't understand what it means. I attache the messages below.
Why the rise and fall edges of PLS7r85ms clock 'identical'?The period, rise edge, or fall edge of clock: PLS7r85ms was found to be outside of the range of acceptable time values. The minimum acceptable time value is -2147483.647 and the maximum acceptable time value is 2147483.647. This clock will be ignored.
The calculated rise and fall waveform edges for clock: PLS7r85ms were found to be identical (rise: -2147483.647, fall: -2147483.647). This clock will be ignored.
Ignoring clock spec: PLS94r2ms Reason: Clock derived from ignored clock: PLS7r85ms. Clock assignment is being ignored.
...
Node: SLOWCLK:SLOWCLK_1|bin_counter5:cnt2|count[2] was determined to be a clock but was found without an associated clock assignment.
Register OC_DETECT:OC4|TIMER64count:TIMER64count_1|COUNT_UP is being clocked by SLOWCLK:SLOWCLK_1|bin_counter5:cnt2|count[2]
Node: SLOWCLK:SLOWCLK_1|bin_counter12:cnt3|count[3] was determined to be a clock but was found without an associated clock assignment.
Register TIMER1Kcount:TIMER1Kcount_17|COUNT_UP is being clocked by SLOWCLK:SLOWCLK_1|bin_counter12:cnt3|count[3]Regards,