Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎02-09-2021

Can't reference MMCM generated clocks

I have a very simple design that I'm using to test some constraints. Hierarchy is as follows: top/u_MMCM/inst/mmcm_adv_inst.

MMCM gets as input a 20MHz clk and produces 2 clks: 10MHz and 5MHz. These two clocks are then fed into a bufgmux so that the design can switch between the two. Following this, I would then create a physically exclusive constraint between the two. But I can't, because I cannot reference the two clocks, 10M and 5M. After synthesis their names are clk5M_clk_wiz_0 and  clk10M_clk_wiz_0. When using those default names the tool (vivado 2020.2) says it cannot find them. Then I tried to rename them with

create_generated_clock -name clk10M [get_pins -hierarchical u_MMCM/inst/mmcm_adv_inst/CLKOUT0]

but the tool says it cannot find pin u_MMCM/inst/mmcm_ad_ins/CLKOUT1, which is clearly wrong because when opening the synthesized design I can find them using that path.

What's happening?

It's for a zynq7000. I'm doing everything in the GUI.

Tags (3)
0 Kudos
2 Replies
Registered: ‎02-09-2021

It seems that the solution was to use the constraints only for implementation.

FYI this is what my constraint looks like

create_clock -period 50 -name boardClk20M [get_ports boardClk20M]
set mmcm "u_MMCM/inst/mmcm_adv_inst"
create_generated_clock -name clk10M -source [get_pins $mmcm/CLKIN1] [get_pins $mmcm/CLKOUT0]
create_generated_clock -name clk5M -source [get_pins $mmcm/CLKIN1] [get_pins $mmcm/CLKOUT1]
create_generated_clock -name clk10mux -divide_by 1 -add -master_clock clk10M -source [get_pins BUFGMUX_CTRL_inst/I0] [get_pins BUFGMUX_CTRL_inst/O]
create_generated_clock -name clk5mux -divide_by 1 -add -master_clock clk5M -source [get_pins BUFGMUX_CTRL_inst/I1] [get_pins BUFGMUX_CTRL_inst/O]
set_clock_groups -physically_exclusive -group clk10mux -group clk5mux
0 Kudos
Registered: ‎01-23-2009

The problem with your original command is the use of a hierarchical path along with the -hierarchical flag - these two cannot be used together. 

[get_pins -hierarchical u_MMCM/inst/mmcm_adv_inst/CLKOUT0]

If you use the -hierarchical flag then the object name is assumed to be a "simple" name - containing no hierarchy. However, you also have the hierarchy to the pin you want - the two don't work together.

So either use

[get_pins u_MMCM/inst/mmcm_adv_inst/CLKOUT0] 

which is what you effectively did in your second example. 

Or use

[get_pins -hierarchical mmcm_adv_inst/CLKOUT0]

which is not recommended because it has the potential to be matched by another MMCM anywhere in the design, or use

[get_pins -hierarchical -filter {NAME ~= *u_MMCM/inst/mmcm_adv_inst/CLKIN1}]

which will find the pin regardless of where the partial hierarchical path (u_MMCM/inst) exists in your design.

If you know the position in the hierarchy, the first one (which is what you used in your second example) is the one you should use.

As for the second part, depending on how the clocking module is included in your design (whether it is synthesized "Out of context" or "Global", which is an option in the IP generation). If it is "Out of context", the MMCM will not exist at the time of synthesis (which is why you can't find it) - the clocking wizard instance will be a "black box", which will be filled in after synthesis. But even in this mode, the output clocks of the clocking wizard module exist at the time of synthesis - the black box will have the "Out of context (ooc)" clocks applied to its pins.

So, your solution is to do what you have done (use your constraints for implementation only), but that has the effect of leaving the synthesis improperly constrained (which may or may not have an effect on your final results. The other solution is to use whichever clocks exist on the pins of the clocking wizard (not inside it) - it will either have the ooc clocks or the real clocks at all stages of the process (synthesis and implementation) regardless of how the wizard was synthesized.

To do this you need to find the names of the output ports of the clocking wizard, which are probably [get_pins u_MMCM/clk_out1] and [get_pins u_MMCM/clk_out2] (unless you renamed them when you generated the clocking wizard module). Again, these pins will exist and have clocks on them regardless of the step you are at (synthesis/implementation) and regardless of whether the clocking wizard module is synthesized OOC or Global.