cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Voyager
Voyager
805 Views
Registered: ‎10-12-2016

source , destination clock path delays are not same even though both having same path in hold analysi?

Jump to solution

Hi Frieds,

Am using VCU118 and vivado 2019.2.

in the timing report tool showing source clock paths delays are different from the destination clock even though both clk are having same path.

Please find the timing report.

Any help or suggestions are highly appreciated.

-Sam

 

-Sampath
0 Kudos
1 Solution

Accepted Solutions
Highlighted
586 Views
Registered: ‎01-22-2015

@ssampath 

Pls consider only path type hold, in that check for the source and destination clock delay only.    PAD --> BUFG--> MMCM--> (BUFG1,BUFG2)

In the hold report, the source clock is clk_50M and the destination clock is clk_100M.  Both clocks are created by MMCM_X0Y12.  Therefore, both clocks share the same base clock, clk_in_300_p, coming from pin, G31. 

In the hold report, the path for both clocks starts at pin, G31.  Therefore, both clocks have the common path consisting of “G31 -> IBUFDS -> BUFGCE -> MMCM” (let’s call this PATH0).  Once inside the MMCM, paths for the two clocks become separate (ie. are no longer common).  However, you are correct to think that the delay through PATH0 should be the same for each clock.

In the hold report, I find that the delay thru PATH0 for clk_50M is 2.789ns – and for clk_100M is 3.149ns.  Near the top of the report, you will see:

  Clock Path Skew:        1.248ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    5.274ns
    Source Clock Delay      (SCD):    4.333ns
    Clock Pessimism Removal (CPR):    -0.307ns

The purpose of CPR is to remove the delay differences over common paths for the two clocks.  So, (3.149 – 0.307 = 2.842), which is close to 2.789.  So, in the end analysis, both clocks have roughly the same delay over PATH0.  In the end analysis we have only rough equality (and not exact equality) - perhaps because there are other common paths in the design that we cannot see.

See discussion near Fig 178 in UG906(v2020.1) for details of CPR.

Cheers,
Mark

View solution in original post

0 Kudos
8 Replies
Highlighted
777 Views
Registered: ‎01-22-2015

@ssampath 

The two timing reports show different delay through identical clock paths because one report is for,

Path Type:              Hold (Min at Slow Process Corner)

and the other path is for,

 Path Type:              Setup (Max at Slow Process Corner)


Process, Temperature, and Voltage (PVT) variations can cause propagation delays to change for both clock and data.  Therefore, timing paths are analyzed in different ways to ensure that your design passes timing analysis over large PVT variations.  This analyzing of paths in different ways causes the two reports (ie. two Path Types) to give a different delay value for the same physical path.

Cheers,
Mark

 

0 Kudos
Highlighted
Guide
Guide
770 Views
Registered: ‎01-23-2009

What you are seeing is called "On Chip Variation". Take a look at this post that describes the different timing corners and the effect of clock pessimism.

Avrum

Highlighted
Voyager
Voyager
731 Views
Registered: ‎10-12-2016

Thank you markg@prosensing.com ,

 

Please check only either setup or hold.

if you take setup timing report , source clock path delay and destination clock path delay are different even before MMCM.

 

PAD --> BUFG--> MMCM--> (BUFG1,BUFG2)

source clock from pad to BUFG1 and destination clock pad to BUFG2.

am expecting PAD to MMCM delay is same for both. But in report its different.

 

-Sam

-Sampath
0 Kudos
Highlighted
Explorer
Explorer
716 Views
Registered: ‎04-07-2014

Hi @ssampath ,

your timing report shows two timing analysis for the same path: one setup (met) and one hold (violated).

Xilinx characterizes its FPGAs for timing variation depending on process corner, temperature and so on. So for each signal path delay, there is a minimum and a maximum propagation time defined.

For the timing analysis the tool always uses the worst case timing scenario. In case of setup, a larger propagation delay is more problematic, so this value is taken. In case of a hold analysis, a smaller propagation delay is more problematic, so this is taken. Therefore, you observe two propagation delays.

Normally setup is violated and hold is met, when timing is having problems. In your case it is the other way around. I assume, that there is something wrong with your MMCM design. Perhaps the clocks are not phase aligned? Perhaps your MMCM parameters are not correct?

The clock names indicate intended 100MHz and 50MHz clock frequencies, but the timing report says 6.666ns and 13.333ns period times, indicating 133MHz and 66MHz clocks.

Please check your MMCM settings. When BUFGs are driven by the same MMCM, the clocks are normally phase aligned.

I hope that helps.

Regards,

Sebastian

Highlighted
Voyager
Voyager
708 Views
Registered: ‎10-12-2016

HI @sgeorgi_sen ,

Pls ignore the clk namse . Initially we planned with 100M later MMCM factors we chnaged as per requirement but not clock names.

my intention not to analyse 2 paths (setup and hold ). Pls consider only path type hold, in that check for the source and destination clock delay only.

-Sampath
0 Kudos
Highlighted
Explorer
Explorer
621 Views
Registered: ‎04-07-2014
Hi,

You need to analyze setup and hold for your design to work properly.

Regards Sebastian
0 Kudos
Highlighted
587 Views
Registered: ‎01-22-2015

@ssampath 

Pls consider only path type hold, in that check for the source and destination clock delay only.    PAD --> BUFG--> MMCM--> (BUFG1,BUFG2)

In the hold report, the source clock is clk_50M and the destination clock is clk_100M.  Both clocks are created by MMCM_X0Y12.  Therefore, both clocks share the same base clock, clk_in_300_p, coming from pin, G31. 

In the hold report, the path for both clocks starts at pin, G31.  Therefore, both clocks have the common path consisting of “G31 -> IBUFDS -> BUFGCE -> MMCM” (let’s call this PATH0).  Once inside the MMCM, paths for the two clocks become separate (ie. are no longer common).  However, you are correct to think that the delay through PATH0 should be the same for each clock.

In the hold report, I find that the delay thru PATH0 for clk_50M is 2.789ns – and for clk_100M is 3.149ns.  Near the top of the report, you will see:

  Clock Path Skew:        1.248ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    5.274ns
    Source Clock Delay      (SCD):    4.333ns
    Clock Pessimism Removal (CPR):    -0.307ns

The purpose of CPR is to remove the delay differences over common paths for the two clocks.  So, (3.149 – 0.307 = 2.842), which is close to 2.789.  So, in the end analysis, both clocks have roughly the same delay over PATH0.  In the end analysis we have only rough equality (and not exact equality) - perhaps because there are other common paths in the design that we cannot see.

See discussion near Fig 178 in UG906(v2020.1) for details of CPR.

Cheers,
Mark

View solution in original post

0 Kudos
Highlighted
Explorer
Explorer
504 Views
Registered: ‎04-07-2014

Hi @ssampath ,

can you create a minimal example showing your problem? For instance a vhdl and xdc file? Then xilinx support could try to reproduce your problem. It seems, that you only want to clock cross a signal between two clocks with fixed relations generated from the same MMCM. This should be possible of course without the needed for CDC structures.

Unfortunatelly I dont have the ultrascale toolchain installed.

Regards,

Sebastian

0 Kudos