input path setup requirement failed between virtual clock and actual system clock

[karthikeasan]

Hi,

I have a requirement to register the input in_0 with respect to 125MHz(clk_sys) mmcm generated clock.

In order constrain above requirement, I have created virtual clock which is same as generated clock(125 MHz) to apply in input delay constrain as shown below

create_clock -name clk_sys_virt -period 8

# System MMCM
create_generated_clock -name clk_sys     [get_pins ../mmcm_inst/CLKOUT0]

set_clock_groups -name async_clocks -asynchronous -group {clk_sys} \

-group {clk_xx}

set_input_delay -clock [get_clocks clk_sys_virt] -max 3.0 [get_ports {in_0}]
set_input_delay -clock [get_clocks clk_sys_virt] -min 0.0 [get_ports {in_0}]

While running the above timing constrain, the place and route tool reported that the above path is failed for the setup requirement.

report:

slack : negative

from in_0 to reg/d

source clock : clk_sys_virt

destination clock : clk_sys

I am wondering why the tool reporting between virtual clock and generated clock ? is it expected ?

Thanks in advance

KS

[thakurr]

Hi @karthikeasan

What is the frequency at the clock input pad of the FPGA? Since MMCM is in the clock path making the input path as CDC, now to adjust the tool requirement you may need multicycle constraint or virtual clock or both based on MMCM phase shift.

>>I am wondering why the tool reporting between virtual clock and generated clock ? is it expected ?

Please check the below link:

https://www.xilinx.com/support/answers/59893.html

The primary clock has to be clock coming at the input clock pad and the destination clock has to be the virtual clock or generated clock at MMCM.

Hope this helps.

Regards

Rohit

----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

[hemangd]

Hi @karthikeasan,

FYI: 

For Clock Modifying Blocks (CMB) such as MMCMx, PLLx,IBUFDS_GTE2, BUFR and PHASER_x primitives, you do not need to manually create the generated clocks.

Vivado automatically creates these clocks, provided the associated master clock has already been defined.

You only need to create the primary clock that is feeding into the CMB.

Have a look at this case 1 of this AR https://www.xilinx.com/support/answers/62488.html

Regards,

hemangd

[karthikeasan]

Hi @hemangd,

Thanks for your information.
The primary clock (ref clk) for the mmcm is another generated clock comes from the PS section of device.
The constrain for primary clock is already provided in respective PS section xdc file.

This is something sounds like derive_pll_clocks command used in altera.

I am going to remove the generated clock constrain for mmcm output.

Thanks
KS

[karthikeasan]

Hi @thakurr,

Thanks for your response.

The frequency of the ref clk( input to mmcm) is 50mhz clock which is generated by the another mmcm.

This is not a register to register transfer to constrain cdc/ multicycle path .

The input in_0 comes directly from input pad.. that’s why I want to apply input delay constraint.

The inpu (in_0) has no relationship with ref clk ( primary clock in this case).

The primary clock has to be clock coming at the input clock pad and the destination clock has to be the virtual clock or generated clock at MMCM“

I am not convinced with your above statement.

When I said virtual clock is my reference clock in input delay constrain, I would expect virtual clock as my source and destination clock.

Thanks
Karthi.s

[avrumw]

I am going to remove the generated clock constrain for mmcm output.

create_generated_clock -name clk_sys     [get_pins ../mmcm_inst/CLKOUT0]

The create_generated_clock here is not a "real" create_generated_clock. Since it is missing both the -source and the "relationship" (-divide_by, -multiply_by, ...) it is merely renaming the automatically generated clock on the output of the MMCM. So there is no reason to remove it.

I am wondering why the tool reporting between virtual clock and generated clock ? is it expected ?

Because you asked it to. Your set_input_delay created a timing relationship between the virtual clock and the input pin, and the input pin propagates to the generated clock. This creates a path from the virtual clock to the generated clock.

Your set_clock_groups only sets clk_xx and clk_sys as being asynchronous - it has no effect on the clk_sys/clk_sys_virt relationship.

But the bigger question here is "what are you trying to accomplish". If the clk_sys is ultimately coming from the PS, how is the USB clocked, and how are the USB chip's data signals related to a "real" clock. For synchronous communication the USB signals have to be related to a clock shared between the FPGA and the USB device, and the USB inputs have to be constrained with respect to that clock. Anything else doesn't make sense...

Avrum

[karthikeasan]

Hi @avrumw,

I was misunderstood about virtual clock relationship with input delay constraint.

Yes, you're right,  "This creates a path from the virtual clock to the generated clock".

As you said, the generated clock constraint is just to rename the automatically generated clock which I don't need anymore.

Your set_clock_groups only sets clk_xx and clk_sys as being asynchronous - it has no effect on the clk_sys/clk_sys_virt relationship.

Yes, there is no point in mentioning virtual clock (clk_sys_virt) as asynchronous clock to clk_sys.

Thanks

KS