cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,157 Views
Registered: ‎04-20-2018

Automatically generated clock not found by get_clocks

Jump to solution

I have a clock generated by an MMCM (from a Clocking Wizard 5.4 rev 3 IP block)

 

I can see this clock in the list running report_clocks:

 

Generated Clock     : clk_out1_clko_phase_shifter
Master Source       : u_slave1/u_phaseshifter/inst/mmcm_adv_inst/CLKIN1
Master Clock        : mgt_refclk
Multiply By         : 1
Generated Sources   : {u_slave1/u_phaseshifter/inst/mmcm_adv_inst/CLKOUT0}

but if I use the generated clock name in the xdc, for example to set an output delay constraint, like

 

set_output_delay -clock [get_clocks clk_out1_clko_phase_shifter] -clock_fall -min -add_delay -1.000 [get_ports IO_B12_L10N_Y26]

 

I get:

 

WARNING: [Vivado 12-627] No clocks matched 'clk_out1_clko_phase_shifter'. 

I tried also to use explicitly create_generated_clock but then the tool give a WARNING about not finding the source pin.

 

Do you have any idea about where the problem is?

 

Best regards,

 Francesco

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
1,433 Views
Registered: ‎01-23-2009

Re: Automatically generated clock not found by get_clocks

Jump to solution

So first, take a look at this post on how the XDC is read twice, once before IP netlists are inserted, and once after. This is probably the cause of the critical warning you are getting.

 

However, that being said, why are you specifying a set_output_delay with respect to a generated clock? Normally a set_output_delay is specified with respect to some system level clock that is used by the destination device as part of its capture mechanism; the output of the MMCM is not directly visible to the downstream device, and is generally not useful as the source of a clock for a set_output_delay (although there are cases where it is needed).

 

Take a closer look at your system requirements and see if there is a better clock to use as the -clock for your set_output_delay. If you are not sure, then tell us more about your system and maybe we can help.

 

All this being said, I am not saying this is incorrect - it may be right. Furthermore, as the post mentions, this critical warning is basically false - the correct constraint does get applied before place and route (where it is important...)

 

Avrum

View solution in original post

0 Kudos
3 Replies
Highlighted
Guide
Guide
1,434 Views
Registered: ‎01-23-2009

Re: Automatically generated clock not found by get_clocks

Jump to solution

So first, take a look at this post on how the XDC is read twice, once before IP netlists are inserted, and once after. This is probably the cause of the critical warning you are getting.

 

However, that being said, why are you specifying a set_output_delay with respect to a generated clock? Normally a set_output_delay is specified with respect to some system level clock that is used by the destination device as part of its capture mechanism; the output of the MMCM is not directly visible to the downstream device, and is generally not useful as the source of a clock for a set_output_delay (although there are cases where it is needed).

 

Take a closer look at your system requirements and see if there is a better clock to use as the -clock for your set_output_delay. If you are not sure, then tell us more about your system and maybe we can help.

 

All this being said, I am not saying this is incorrect - it may be right. Furthermore, as the post mentions, this critical warning is basically false - the correct constraint does get applied before place and route (where it is important...)

 

Avrum

View solution in original post

0 Kudos
Highlighted
Mentor
Mentor
1,140 Views
Registered: ‎02-24-2014

Re: Automatically generated clock not found by get_clocks

Jump to solution

try this:

 

create_generated_clocks -name "clk_out1_clko_phase_shifter" [get_pins u_slave1/u_phaseshifter/inst/mmcm_adv_inst/CLKOUT0]

 

But having said this,  Avrum is completely correct that you should carefully examine your requirements for this output delay constraint.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Highlighted
Visitor
Visitor
1,095 Views
Registered: ‎04-20-2018

Re: Automatically generated clock not found by get_clocks

Jump to solution

@avrumwwrote:

So first, take a look at this post on how the XDC is read twice, once before IP netlists are inserted, and once after. This is probably the cause of the critical warning you are getting.


 

Thank you, I understand.

 


@avrumwwrote:

However, that being said, why are you specifying a set_output_delay with respect to a generated clock? Normally a set_output_delay is specified with respect to some system level clock that is used by the destination device as part of its capture mechanism; the output of the MMCM is not directly visible to the downstream device, and is generally not useful as the source of a clock for a set_output_delay (although there are cases where it is needed).

 

Take a closer look at your system requirements and see if there is a better clock to use as the -clock for your set_output_delay. If you are not sure, then tell us more about your system and maybe we can help.


My problem is the following: I have built a board to test an ASIC that we designed and the FPGA task is to send data to the ASIC. We do have a system clock but due to some design errors we can't fully control the delay of the system clock to the ASIC with respect to the FPGA at system level. The ASIC itself has some extra complexity and the input timing requirements depends on the operation mode so we need to be able to adjust the delays of all the data going to the ASIC. So in order to find the correct timing dynamically during the test I take the system clock in the FPGA, pass it through an MMCM to have the ability to fine tune the phase and use it to time the output signals. This is the origin of those set_output_delay

 

[edit: in the meanwhile I changed my set_output_delay constraints using a virtual clock and setting an appropriate multicycle path to take into account the global internal delay. I think this solution is better.]

 

I realize that it's probably a baroque method, so I'm open to suggestions!

 

Thanks,

 Francesco

0 Kudos