- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
i have a slow speed system as follows - 20M refclk -> clk divider giving refclk/2, refclk/4 -> clk_mux (to select clock going into rest of the syste) -> clk_gate -> ciock going into rest of the system the clock divider, clk_mux, clk_gate are coded in verilog (they are not IPs in any way) the above design leads to gates on the clock path, but i still have to implement the design as is and since its a slow speed design, i might be able to get away with the skew. so i had some questions regarding the best way of constraining the above design - 1) is it OK to constraint the clk divider outputs using the following syntax - create_generated_clock -source [get_ports {refclk}] -divide_by 4 -multiply_by 1 [get_pins {clk_divider|DTC_CTSROOT_1|Q|q}] create_generated_clock -source [get_ports {refclk}] -divide_by 2 -multiply_by 1 [get_pins {clk_divider|DTC_CTSROOT_2|Q|q}] or should i use get_keepers in the constraint somewhere? is the above constraint wrong in anyway? Timequest does not throw an error by i've read that get_keepers should be used for this. is that correct? 2) is it OK to constraint the clk mux outputs using the following syntax (constraining the clk_mux output to the fastest/worst case frequency) - create_generated_clock -source [get_ports {refclk}] -divide_by 2 -multiply_by 1 [get_pins {clk_mux_2to1|Z|combout}] 2a) when i use the above constraint, i get a warning in QuartusII saying - No paths exist between clock target "clk_mux_2to1|Z|combout" of clock "clk_mux_2to1|Z|combout" and its clock source. Assuming zero source clock latency.” why is this? 2b) my 2:1 clock mux is simply coded in verilog as - Z = sel? A0, A1 where Z is the output and A0, A1 are the clock inputs, sel is the select line for the mux is the above method of constraint correct or do i need to use get_keepers in the constraint somewhere? 3) i know get_keepers returns a set of non-combinational nodes in the design. so is the get_keepers only applicable to clocked/registered logic? or should it be used to constraint combinatorial logic too? 4) since i have a clock gate in my design as well, is my understanding correct that i will need to constraint the clock gate output as well (to the worst case frequency output from the clk_gate)? if so, can i simply use the constraint below or do i need to use get_keepers in here somewhere? create_generated_clock -source [get_ports {refclk}] -divide_by 2 -multiply_by 1 [get_pins {clk_gate|out_clkt}] please let me know ... thanks in advance ... :) z.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1) Looks good, but shouldn't there by a -name? Also, it seems like by 1 of DTC_CTSROOT would be the 10MHz clock and have a divide by 2, while bit 2 would be a divide by 1. I don't know what logic you have to divide down, but am just assuming it's a counter.
2) This is wrong. There can't be a register between the -source and the target. You want your lines in 1) and then add: create_generated_clock -name clk5M -source [get_pins {clk_divider|DTC_CTSROOT_1|Q|q}] [get_pins {clk_mux_2to1|Z|combout}] create_generated_clock -name clk10M -source [get_pins {clk_divider|DTC_CTSROOT_2|Q|q}] [get_pins {clk_mux_2to1|Z|combout}] -add set_clock_groups -exclusive -group {clk5M} -group {clk10M} The last one cuts timing between these clocks, ensuring no paths are analyzed where clk5M drives the launch register and clk10M drives the latch, or vice-versa. get_keepers only does enpoints of a timing path, i.e. FFs, IO ports, RAMs, DSPs. Your use of get_pins works just as well and is necessary for the combinatorial mux output. There are multiple get_* commands that overlap in one way or another and when it makes sense, either one will work. get_pins is the one used by ASIC tools, but users often find it annoying(which is why it has things like -compatibility_mode, to make it work more like a simple wildcard to the name. The -hierarchical matching is confusing to most. Just to be safe, put a keep on your mux: (* keep *) wire Z; Quartus synthesis should preserve this anyway, but I've gotten in the habit of doing that.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please clarify use of the last point 4).
What kind of constraint is suitable for that last clock gate and how to write that.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which one are you asking about?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am asking about the point 4) mentioned by Zubin. How should the create_generated_clock statement look like when I can not mention master clock as the refclk, but to mention it the output of the clk_mux
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Zubin's generated clock for 4) looks correct except it's missing the -name. Note that -source is always a physical point in the design. You only need -master_clock if multiple clocks go through that point. For example, let's say you had two clocks coming in:
create_clock -period 10.0 -name clk_A [get_ports {ref_clk_A}] create_clock -period 12.0 -name clk_B [get_ports {ref_clk_B}] And now let's say you build a 2:1 mux to gate them. To that mux output you would add: create_generated_clock -source [get_ports {ref_clk_A}] -name gate_clk_A [get_pins {clk_mux|combout}] create_generated_clock -source [get_ports {ref_clk_B}] -name gate_clk_B -add [get_pins {clk_mux|combout}] Now let's say the output of this fed another gated clock(please try to avoid this, just an example), then you would add something like: create_generated_clock -source [get_pins {clk_mux|combout}] -master_clock gate_clk_A -name gate_two_A [get_pins {clk_mux_two|combout}] (If it's a mux, you might have multiple constraints to this output, using the -add option)- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks! That answers my question.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page