cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
1,004 Views
Registered: ‎08-15-2014

Where is here a inter-clock timing path of iserdes3

Jump to solution

hi,

I am using ISERDESE3 in my design. the CLK is connected to output of MMCM, and CLK_DIV was from  a BUFGCE_DIV by CLK.

But I found there is one hold timing path violation that I couldn't understand:

1) from xxx/i_iserdes/INTERNAL_DIVCLK  to xxx/iserdes_data_raw_d[5] (As shown in the attached picture).

2) I saw there is a data path from iserdes3's Q[5] to iserdes_data_raw_d[5]. but since CLKDIV and C of FDRE(iserdes_data_raw_d[5]) had been connected to the same clock.

3) XX/i_iserdes/INTERAL_DIVCLK should be a reserved port of iserdes3, it should not be used.

4) So why it is reporting a inter-clock path timing violation here? 

I couldn't understand this, anyone could help me?

 

 

timing_iserdes3.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
915 Views
Registered: ‎01-23-2009

These are not (really) the same clock. The two clocks share the same path up to the MMCM, but then use different clock buffers; one uses clkout2_buf and the other uses clkout1_div_buf. Because one of these goes through a BUFGCE_DIV, the it is given a new name; it is an automatically generated clock. The name of this derived clock doesn't necessarily tell you where it comes from - so the fact that it has "INTERNAL_DIVCLK" in it is probably not telling you much - if you look at the clock path, you can see that it is generated "normally" - the MMCM and the BUFGCE_DIV.

Now, given that the two clocks are the same frequency, the BUFGCE_DIV is obviously in "divide by 1" mode. So, one questions why it is here - why do you have two different clock buffers for what is essentially the same clock? Maybe you can remove one? That being said, there is nothing "wrong" with this - in Vivado, all clocks are related by default - so even if these are two different clocks, they will have (almost) the same attributes, and hence synchronous clocking between the two is legal.

If there is a reasons for having the second clock buffer (maybe power gating, or maybe the IP you are using does it on its own), then you need to be careful in UltraScale/UltraScale+. In previous technologies, all global clock networks were identical, and hence the output of one BUFG was always balanced with another BUFG (assuming they had a common generation point - i.e. the same MMCM/PLL). But this is not true in US/US+; the global clock networks are built dynamically depending on the elements they need to reach. As a result, you can get significant skew between them. In order to avoid this, you need to tell the tool that you plan to cross between them synchronously. This is done with a new property called the CLOCK_DELAY_GROUP. When you put the same CLOCK_DELAY_GROUP value on multiple global clock nets, you tell the tool that they need to remain balanced. This will force the tool to ensure that they share the same CLOCK_ROOT, which balances the skew. Without this property, the tool has no such restriction, and hence these two clocks do not share the same CLOCK_ROOT - one is in X3Y8 and the other in X3Y7. Take a look at this post on the CLOCK_DELAY_GROUP.

To fix this, you need to place the clock nets in the same group

set_property CLOCK_DELAY_GROUP clk_core_grp [get_nets u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/pinmux_rx_bus[11].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[17].i_dnlvds_pinmux_rx_iserdes/clk_iserdes]
set_property CLOCK_DELAY_GROUP clk_core_grp [get_nets u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/pinmux_rx_bus[11].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[17].i_dnlvds_pinmux_rx_iserdes/certus_signal_burst_ram_wclk]

This should help reduce the clock skew - although it is already really small. However, there is an SLR crossing here, and this is contributing much more significantly to the hold time problem.

The next question is "why didn't the tool fix this". The tool should have been able to fix this by adding net delay on the route between the ISERDES and the fabric flip-flop. But it doesn't appear to have done so.

So, the next question - is this a post-synthesis report or a post place and route report. Hold time fixing is only done during routing, so it is normal to see small hold time violations after synthesis - they will be fixed during routing. If this is a post-synthesis report, then the failure is probably meaningless - it will likely be fixed during implementation.

Avrum

View solution in original post

0 Kudos
6 Replies
Highlighted
Moderator
Moderator
957 Views
Registered: ‎01-16-2013

Hi,

Can you please share the timing report for this specific path?

Both for setup & hold analysis.

Thanks,
Yash

 

0 Kudos
Highlighted
Explorer
Explorer
951 Views
Registered: ‎08-15-2014


Min Delay Paths
--------------------------------------------------------------------------------------
Slack (VIOLATED) : -0.133ns (arrival time - required time)
Source: u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.i_iserdes_monitor/INTERNAL_DIVCLK
(rising edge-triggered cell ISERDESE3 clocked by clk_out2_NV_HSTDM_ga10x_clk_INTERNAL_DIVCLK {rise@0.000ns fall@18.520ns period=37.040ns})
Destination: u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.iserdes_data_monitor_raw_d[5]/D
(rising edge-triggered cell FDRE clocked by core_clk {rise@0.000ns fall@18.520ns period=37.040ns})
Path Group: core_clk
Path Type: Hold (Min at Slow Process Corner)
Requirement: 0.000ns (core_clk rise@0.000ns - clk_out2_NV_HSTDM_ga10x_clk_INTERNAL_DIVCLK rise@0.000ns)
Data Path Delay: 0.757ns (logic 0.360ns (47.556%) route 0.397ns (52.444%))
Logic Levels: 0
Clock Path Skew: 0.041ns (DCD - SCD - CPR)
Destination Clock Delay (DCD): 5.515ns
Source Clock Delay (SCD): 5.719ns
Clock Pessimism Removal (CPR): -0.244ns
Inter-SLR Compensation: 0.760ns ((SCD + DPD - CCD) * PF)
Source Clock Delay (SCD): 5.719ns
Data Path Delay (DPD): 0.757ns
Common Clock Delay (CCD): 1.410ns
Prorating Factor (PF): 0.150
Clock Net Delay (Source): 3.320ns (routing 1.185ns, distribution 2.135ns)
Clock Net Delay (Destination): 3.834ns (routing 1.203ns, distribution 2.631ns)

Location Delay type Incr(ns) Path(ns) Netlist Resource(s)
------------------------------------------------------------------- -------------------
(clock clk_out2_NV_HSTDM_ga10x_clk_INTERNAL_DIVCLK rise edge)
0.000 0.000 r
Y47 0.000 0.000 r hstdm_pll_in_p (IN)
net (fo=0) 0.000 0.000 u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/I
HPIOBDIFFINBUF_X0Y155
DIFFINBUF (Prop_DIFFINBUF_HPIOBDIFFINBUF_DIFF_IN_P_O)
0.293 0.293 r u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/DIFFINBUF_INST/O
net (fo=1, routed) 0.045 0.338 u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/OUT
Y47 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O)
0.000 0.338 r u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/IBUFCTRL_INST/O
net (fo=1, routed) 0.683 1.021 u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/hstdm_pll_in
MMCME3_ADV_X0Y6 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1)
0.320 1.341 r u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/mmcme3_adv_inst/CLKOUT1
net (fo=2, routed) 0.305 1.646 u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/clk_out2_NV_HSTDM_ga10x_clk
BUFGCE_X0Y146 BUFGCE (Prop_BUFCE_BUFGCE_I_O)
0.060 1.706 r u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/clkout2_buf/O
X3Y8 (CLOCK_ROOT) net (fo=22069, routed) 3.320 5.026 u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/veridae_pullup_u_NV_hstdm_sourcesyn_receive_u_NV_HSTDM_ga10x_clk_inst_clk_out2
SLR Crossing[1->0]
BITSLICE_RX_TX_X1Y178
ISERDESE3 (Prop_ISERDES_BITSLICE_COMPONENT_RX_TX_CLK_INTERNAL_DIVCLK)
0.693 5.719 r u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.i_iserdes_monitor/INTERNAL_DIVCLK
------------------------------------------------------------------- -------------------
BITSLICE_RX_TX_X1Y178
ISERDESE3 (Prop_ISERDES_BITSLICE_COMPONENT_RX_TX_INTERNAL_DIVCLK_Q[5])
0.360 6.079 r u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.i_iserdes_monitor/Q[5]
net (fo=3, routed) 0.397 6.476 u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/iserdes_data_monitor_raw[5]
SLICE_X298Y207 FDRE r u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.iserdes_data_monitor_raw_d[5]/D
------------------------------------------------------------------- -------------------

(clock core_clk rise edge)
0.000 0.000 r
Y47 0.000 0.000 r hstdm_pll_in_p (IN)
net (fo=0) 0.000 0.000 u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/I
HPIOBDIFFINBUF_X0Y155
DIFFINBUF (Prop_DIFFINBUF_HPIOBDIFFINBUF_DIFF_IN_P_O)
0.493 0.493 r u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/DIFFINBUF_INST/O
net (fo=1, routed) 0.078 0.571 u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/OUT
Y47 IBUFCTRL (Prop_IBUFCTRL_HPIOB_I_O)
0.000 0.571 r u_NV_hstdm_sourcesyn_receive/u_ibufg_hstdmclk/IBUFCTRL_INST/O
net (fo=1, routed) 0.757 1.328 u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/hstdm_pll_in
MMCME3_ADV_X0Y6 MMCME3_ADV (Prop_MMCME3_ADV_CLKIN1_CLKOUT1)
-0.240 1.088 r u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/mmcme3_adv_inst/CLKOUT1
net (fo=2, routed) 0.357 1.445 u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/clk_out2_NV_HSTDM_ga10x_clk
BUFGCE_DIV_X0Y24 BUFGCE_DIV (Prop_BUFGCE_DIV_I_O)
0.236 1.681 r u_NV_hstdm_sourcesyn_receive/u_NV_HSTDM_ga10x_clk/inst/clkout1_div_buf/O
X3Y7 (CLOCK_ROOT) net (fo=69687, routed) 3.834 5.515 u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/veridae_pullup_u_NV_hstdm_sourcesyn_receive_u_NV_HSTDM_ga10x_clk_inst_clk_out1
SLR Crossing[1->0]
SLICE_X298Y207 FDRE r u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.iserdes_data_monitor_raw_d[5]/C
clock pessimism 0.244 5.760
inter-SLR compensation 0.760 6.520
SLICE_X298Y207 FDRE (Hold_GFF2_SLICEM_C_D)
0.089 6.609 u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/\\pinmux_rx_bus[10].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[1].i_dnlvds_pinmux_rx_iserdes/gen_monitor.iserdes_data_monitor_raw_d[5]
-------------------------------------------------------------------
required time -6.609
arrival time 6.476
-------------------------------------------------------------------
slack -0.133

0 Kudos
Highlighted
Explorer
Explorer
948 Views
Registered: ‎08-15-2014

thanks for your reply.

paste the whole timing report here.

0 Kudos
Highlighted
Moderator
Moderator
932 Views
Registered: ‎01-16-2013

Hi,

Thanks for sharing the required files.

In the ISERDES3 there is internal connection between CLKDIV (input) and INTERNAL_DIVCLK (output pin). So both the clocks are same.

INTERNAL_DIVCLK pin is reserved i.e. you cannot connect that in fabric (So n/c is correct usage). But all the output data is synchronous to INTERNAL_DIVCLK (so from understanding point of view this is equivalent to output data is synchronous to CLKDIV).

In your reporting the source element is clocked by INTERNAL_DIVCLK i.e. nothing other than CLKDIV. Destination is clocked by core_clk. The path is expected and this is genuine timing analysis. 

I hope the above information will be helpful.

Thanks,
Yash

 

 

0 Kudos
Highlighted
Explorer
Explorer
930 Views
Registered: ‎08-15-2014

Thanks yashp,

The current problem is that. the CLKDIV of iserdese3 is from output of the MMCM. and CLKDIV is connected to INTERNAL_DIVCLK (output pin), I am using CLKDIV to sample the output of ISERDESE3. though they're the same clock, but now it is reporting an inter-path between INTERNAL_DIVCLK and CLKDIV. in other words, seems tool doesn't take them as the same clock.

How to handle this? 

 

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

These are not (really) the same clock. The two clocks share the same path up to the MMCM, but then use different clock buffers; one uses clkout2_buf and the other uses clkout1_div_buf. Because one of these goes through a BUFGCE_DIV, the it is given a new name; it is an automatically generated clock. The name of this derived clock doesn't necessarily tell you where it comes from - so the fact that it has "INTERNAL_DIVCLK" in it is probably not telling you much - if you look at the clock path, you can see that it is generated "normally" - the MMCM and the BUFGCE_DIV.

Now, given that the two clocks are the same frequency, the BUFGCE_DIV is obviously in "divide by 1" mode. So, one questions why it is here - why do you have two different clock buffers for what is essentially the same clock? Maybe you can remove one? That being said, there is nothing "wrong" with this - in Vivado, all clocks are related by default - so even if these are two different clocks, they will have (almost) the same attributes, and hence synchronous clocking between the two is legal.

If there is a reasons for having the second clock buffer (maybe power gating, or maybe the IP you are using does it on its own), then you need to be careful in UltraScale/UltraScale+. In previous technologies, all global clock networks were identical, and hence the output of one BUFG was always balanced with another BUFG (assuming they had a common generation point - i.e. the same MMCM/PLL). But this is not true in US/US+; the global clock networks are built dynamically depending on the elements they need to reach. As a result, you can get significant skew between them. In order to avoid this, you need to tell the tool that you plan to cross between them synchronously. This is done with a new property called the CLOCK_DELAY_GROUP. When you put the same CLOCK_DELAY_GROUP value on multiple global clock nets, you tell the tool that they need to remain balanced. This will force the tool to ensure that they share the same CLOCK_ROOT, which balances the skew. Without this property, the tool has no such restriction, and hence these two clocks do not share the same CLOCK_ROOT - one is in X3Y8 and the other in X3Y7. Take a look at this post on the CLOCK_DELAY_GROUP.

To fix this, you need to place the clock nets in the same group

set_property CLOCK_DELAY_GROUP clk_core_grp [get_nets u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/pinmux_rx_bus[11].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[17].i_dnlvds_pinmux_rx_iserdes/clk_iserdes]
set_property CLOCK_DELAY_GROUP clk_core_grp [get_nets u_NV_hstdm_sourcesyn_receive/u_NV_hstdm_bank_receive/pinmux_rx_bus[11].i_NV_dnlvds_pinmux_rx/pinmux_rx_iserdes_bus[17].i_dnlvds_pinmux_rx_iserdes/certus_signal_burst_ram_wclk]

This should help reduce the clock skew - although it is already really small. However, there is an SLR crossing here, and this is contributing much more significantly to the hold time problem.

The next question is "why didn't the tool fix this". The tool should have been able to fix this by adding net delay on the route between the ISERDES and the fabric flip-flop. But it doesn't appear to have done so.

So, the next question - is this a post-synthesis report or a post place and route report. Hold time fixing is only done during routing, so it is normal to see small hold time violations after synthesis - they will be fixed during routing. If this is a post-synthesis report, then the failure is probably meaningless - it will likely be fixed during implementation.

Avrum

View solution in original post

0 Kudos