- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am wondering about clock constraints for divided-generated clocks.
I made a slow-clock generation block which has counters for divide.
It has 3 counters. cnt1 divides 10 MHz clock counting 15700 to make PLS1r57ms clock. cnt2 divides PLS1r57ms clock counting 5 to make PLS7r85ms clock. And cnt3 divides PLS7r85ms clock counting 12 to make PLS94r2ms clock.
Then I wrote the clock constraints like below.
create_clock -period 20.833 [get_ports {FPGA_CLK1}]
create_clock -period 68.817 [get_ports {FPGA_CLK2}]
derive_pll_clocks
derive_clock_uncertainty
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_nets {SLOWCLK_1|cnt1|count[13]}] -divide_by 5 -duty_cycle 0.2 [get_nets {SLOWCLK_1|cnt2|count[2]}]
create_generated_clock -name PLS94r2ms -source [get_nets {SLOWCLK_1|cnt2|count[2]}] -divide_by 12 -duty_cycle 0.33 [get_nets {SLOWCLK_1|cnt3|count[3]}]
The compiler said constraints for PLS7r85ms and PLS94r2ms were illegal. It also said they were base clocks. Why are they Base clocks?
I think PLS7r85ms and PLS94r2ms clocks are "generated clocks". What is wrong with this?
Thanks in advance.
My environment
Quartus Prime Lite Edition: 18.1.0 Build 625 09/12/2018 SJ Lite Edition
Windows7 professional sp1
Target device: MAX 10
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may checkout the forum post here:
It seems for these very low frequencies you just lie. R
Reference:
Best Regards,
Richard Tan
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
First, why don't you just use the PLL to generate all these clocks? Are you using the other clock outputs or have no PLL available for doing this?
Also, don't use get_nets. You should be using get_pins to target physical points in the netlist. Did you use the Name Finder to make sure you have the correct target names? I'm guessing the names shown in this report showing as unconstrained should be the names you should be using in your constraints, but you must use the Name Finder to verify.
In the report, those two clock inputs are showing as unconstrained base clocks because your clock constraints are incorrect. The unconstrained paths report indicates that it thinks these are base clocks that need clock constraints.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your reply.
Then I pointed the source and the target with pin in my sdc file. But I got the same result as before.
create_clock -period 20.833 [get_ports {FPGA_CLK1}]
create_clock -period 68.817 [get_ports {FPGA_CLK2}]
derive_pll_clocks
derive_clock_uncertainty
#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_nets {SLOWCLK_1|cnt1|count[13]}] -divide_by 5 -duty_cycle 0.2 [get_nets {SLOWCLK_1|cnt2|count[2]}]
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_nets {SLOWCLK_1|cnt2|count[2]}] -divide_by 12 -duty_cycle 0.33 [get_nets {SLOWCLK_1|cnt3|count[3]}]
I always use the name finder to point sources and targets. Without it it is quite tough to know correct pin or net names.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why are you using BOTH derive_pll_clocks and create_generated_clocks ?
Either let Quartus do it (first option) or you do it manually (second option).
For example, I have a design with a couple of clocks generated based on a 50MHz clock input to the PLL.
The PLL generates one clock CPUCLK at 80MHz, and a second clock based on logic divide of the PLL output RTCCLK at 25KHz.
# Master 50MHz clock input
create_clock -period 20.0 -name CLOCK_50 [get_ports {CLOCK_50}]
# Created clocks based on PLLs (CPUCLK = 80MHz)
create_generated_clock -source {pll|altpll_component|pll|inclk[0]} -divide_by 5 -multiply_by 8 -duty_cycle 50 -name CPUCLK {pll|altpll_component|pll|clk[0]}
# Created clocks based on logic (RTCCLK = 25KHz)
create_generated_clock -source {pll|altpll_component|pll|clk[0]} -divide_by 5000 -duty_cycle 50 -name RTCCLK {dk8ea_clock:rtc|rtcclk}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
derive_pll_clocks only works for the PLL. They have to create generated clocks for those additional ones based on the PLL output.
As I mentioned in my first reply, OP should just put all the clocks in the PLL if they can, but I know MAX 10 is limited with PLLs so maybe that's not an option.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you generate reports in the timing analyzer to understand why the last 2 SDC constraints are getting rejected? Try the ignored constraints report.
Try setting the source for each of those as the input pin to cnt2 and cnt3 instead of the output pin of the previous block.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looking again, duty_cycle should be a percentage. Try 20 and 33 instead of .2 and .33.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may checkout the forum post here:
It seems for these very low frequencies you just lie. R
Reference:
Best Regards,
Richard Tan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Richard,
Thank you for the information.
I check the materials first.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for letting me know the case that was 13 years ago. I didn't imagine the cause was too low clock frequency to be analyzed.
This time I took the telling a lie to Timing Analyzer method. I reduced the division rate of PLS1r57ms clock to 15. Warnings or errors on SLOWCLKs went away. Thank you again.
create_generated_clock -name PLS1r57ms -source [get_pins {PLL_inst|altpll_component|auto_generated|pll1|clk[0]}] -divide_by 15 [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 [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 [get_pins {SLOWCLK_1|cnt3|count[3]|q}]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for acknowledging the solution provided. I'm pleased to know that your question has been addressed.
Now, I will transition this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out.
Thank you and have a great day!
Best Regards,
Richard Tan
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page