cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
5,592 Views
Registered: ‎03-18-2016

different timing analysis results for the same path

Jump to solution

Hi,

I was checking out the timing of an IDDR register data-input from an implemented design

unsing the TCL report_timing command:

 

report_timing -rise_to  [get_pins -hier ADC_R0_15[0].ADCR/D], yielding (pruned for better readability):

 

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                   (clock FPGA_RCKp rise edge)
                                                      0.000     0.000 r  
                   input delay                  4.000     4.000    
   Y17                                             0.000     4.000 r  OC[0] (IN)
                    net (fo=0)                   0.000     4.000    OC[0]
    Y17  IBUF (Prop_ibuf_I_O)         0.467     4.467 r  OC_IBUF[0]_inst/O
                 net (fo=1, routed)          0.000     4.467    SigProc_Inst/OC_IBUF[0]
    ILOGIC_X0Y99         IDDR                                   r  SigProc_Inst/ADC_R0_15[0].ADCR/D
  -------------------------------------------------------------------    -------------------
                (clock CLK fall edge)        3.572     3.572 f  
    V13                                               0.000     3.572 f  FPGA_RCKp (IN)
                         net (fo=0)                 0.000     3.572    SigProc_Inst/FPGA_RCKp
    V13 IBUFDS (Prop_ibufds_I_O)      0.396     3.968 f  SigProc_Inst/RCK_Buf/O
                         net (fo=2, routed)    0.843     4.811    SigProc_Inst/I
           BUFG (Prop_bufg_I_O)         0.027     4.838 f  SigProc_Inst/CLK_Buf/O
              net (fo=10168, routed)       0.715     5.553    SigProc_Inst/CLK
    ILOGIC_X0Y99    IDDR                                         f  SigProc_Inst/ADC_R0_15[0].ADCR/C
                  clock pessimism              0.000     5.553    
                  clock uncertainty           -0.035     5.518    
           IDDR (Setup_iddr_C_D)       -0.001     5.517    SigProc_Inst/ADC_R0_15[0].ADCR
 

So far so good!

Out of curiosity I was asking for the timing to the CLOCK-input of that particular IDDR register :

 

report_timing -rise_to  [get_pins -hier ADC_R0_15[0].ADCR/C]

And got:

 

   Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                (clock CLK fall edge)        3.572     3.572 f  
    V13                                               0.000     3.572 f  FPGA_RCKp (IN)
                       net (fo=0)                   0.000     3.572    SigProc_Inst/FPGA_RCKp
   V13 IBUFDS (Prop_ibufds_I_O)     0.900     4.472 f  SigProc_Inst/RCK_Buf/O
                   net (fo=2, routed)           2.100     6.572    SigProc_Inst/I
  -------------------------------------------------------------------    -------------------
           BUFG (Prop_bufg_I_O)         0.082     6.654 f  SigProc_Inst/CLK_Buf/O
              net (fo=10168, routed)       1.733     8.387    SigProc_Inst/CLK
    ILOGIC_X0Y99         IDDR                                         f  SigProc_Inst/ADC_R0_15[0].ADCR/C
  -------------------------------------------------------------------    -------------------

 

Notice the difference in SigProc_inst/CLK delay time ?

The first calculation yields 5.53ns delay, the second one 8.387ns ??!!

 

Questions:

* There are two different results for the same components / nets - how's that possible

* Why is the analysis calculating the timing for the falling edge of the IDDR clock despite of the -rise_to command ?

* How can I get the timing of the IDDR clock (SigProc_Inst/ADC_R0_15[0].ADCR/C) rising edge ?

 

Thank's for helping!

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
10,369 Views
Registered: ‎01-23-2009

Re: different timing analysis results for the same path

Jump to solution

The second path is somewhat questionable - you have asked it to report the timing path that ends at the clock input of a flip-flop. But the clock input of a flip-flop is not the endpoint of a static timing path. So I am not entirely certain what it is reporting for the second command...

 

But what you are seeing is the difference in timing corners - Vivado does multi-corner timing analysis; both setup and hold checks are done at both "Fast process corner" and at "Slow process corner". Presumably, one of these paths is at one corner, and the other is at the other (which accounts for different timing through the same components and nets). You need to look at the Path Type in the header of the timing report to see which one you are getting.

 

Furthermore, since these two paths may not be the same type of check (Max vs. Min or Setup vs. Hold), then this too will affect the delays attributed to a particular component; each cell has characterization data for 4 process corners, SLOW_MIN, SLOW_MAX, FAST_MIN and FAST_MAX. Depending on the type of analysis, and where the component is in the analysis (source clock delay, datapath delay or destination clock delay), the different timing value will (correctly) be used.

 

Performing timing analysis like this ensures that if the static timing analysis passes (assuming your constraints are correct), then the device will work under all legal combinations of Process, Voltage and Temperature.

 

Avrum

View solution in original post

4 Replies
Highlighted
Guide
Guide
10,370 Views
Registered: ‎01-23-2009

Re: different timing analysis results for the same path

Jump to solution

The second path is somewhat questionable - you have asked it to report the timing path that ends at the clock input of a flip-flop. But the clock input of a flip-flop is not the endpoint of a static timing path. So I am not entirely certain what it is reporting for the second command...

 

But what you are seeing is the difference in timing corners - Vivado does multi-corner timing analysis; both setup and hold checks are done at both "Fast process corner" and at "Slow process corner". Presumably, one of these paths is at one corner, and the other is at the other (which accounts for different timing through the same components and nets). You need to look at the Path Type in the header of the timing report to see which one you are getting.

 

Furthermore, since these two paths may not be the same type of check (Max vs. Min or Setup vs. Hold), then this too will affect the delays attributed to a particular component; each cell has characterization data for 4 process corners, SLOW_MIN, SLOW_MAX, FAST_MIN and FAST_MAX. Depending on the type of analysis, and where the component is in the analysis (source clock delay, datapath delay or destination clock delay), the different timing value will (correctly) be used.

 

Performing timing analysis like this ensures that if the static timing analysis passes (assuming your constraints are correct), then the device will work under all legal combinations of Process, Voltage and Temperature.

 

Avrum

View solution in original post

Highlighted
Guide
Guide
5,571 Views
Registered: ‎01-23-2009

Re: different timing analysis results for the same path

Jump to solution

By the way, if none of this makes sense to you, you might want to consider learning more about the static timing engine in Vivado and how it works. The timing engine is based on the concepts of SDC (Synopsys Timing Constraints), which really define more than just the format of constraint commands, but really all the concepts behind "What is a static timing path", "What is a setup or hold check on that static timing path", "How are delays calculated on static timing paths", "How do the different timing corners work, and how are they used" (and a whole bunch of others).

 

While all the information on this exists in the user guides, Xilinx offers a very good course on the concepts of static timing analysis: "Vivado Design Suite Advanced XDC and Static Timing Analysis for ISE"

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
5,554 Views
Registered: ‎03-18-2016

Re: different timing analysis results for the same path

Jump to solution
Hi Avrum,
actually the biggest surprise was that the delay to the clock- input was even longer than to the data- input of the IDDR. I would have assumed otherwise since the clock- delay doesn't contain the propagation delay of the IDDR flip-flop.

However, I'll ignore the second path - the first one (almost) complies to what the full (worst case) timing report states...

Thank's a lot for helping me out - again!
0 Kudos
Guide
Guide
5,548 Views
Registered: ‎01-23-2009

Re: different timing analysis results for the same path

Jump to solution

actually the biggest surprise was that the delay to the clock- input was even longer than to the data- input of the IDDR.

 

This should not surprise you at all...

 

The connection to the data input of the IDDR is very simple - it comes directly from the input buffer of the Input/Output Block (IOB) to the IDDR (which is in the same IOB as the IBUF). This is a short, dedicated, and one-to-one connection.

 

The clock path, is far more complex (and highly dependent on what clocking method is used). Based on your the timing report, you are using an uncompensated global clock buffer as the clock insertion mechanism. So, this means

  - the clock comes in on the input buffer of a clock capable pin (at least I hope it does). This is a different IOB from the one that brings the data in

  - the clock takes a dedicated route from the IOB (which is on the edge of the die) to the BUFG (which is located in the center of the die)

  - the output of the BUFG is distributed (literally) to everywhere on the die; the output of this BUFG can potentially be used to clock every CLB flip-flop, every block RAM, every DSP cell, and (yes) every IDDR, ODDR, ISERDES, OSERDES in any IOB anywhere on the FPGA die (which, again, are back out on the edges of the FPGA).

 

So clearly the clock path is going to be significantly longer than the datapath. It is, in fact, precisely for this reason that FPGAs have MMCM/PLL/DCM for "deskewing" the input clock. Using an MMCM/PLL/DCM with BUFG feedback, you can "cancel out" (at least the majority) of this clock insertion to make the insertion delay of the clock match more closely the insertion delay of the data input.

 

Avrum

Tags (1)
0 Kudos