UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer jhouee
Observer
179 Views
Registered: ‎11-27-2015

Understand timing report starting delay

Jump to solution

hello,

There is still something I don't understand the vivado timing report, this is the starting delay before the calculation of the full path.

What are those starting values in red ? delay of a buffer before to get those clock ?:

(clock clk_7680k rise edge)
                                                    125.000   125.000 r 

and

                       (clock ceva_clk rise edge)
                                                    130.000   130.000 r 

 

here my report:

Max Delay Paths
--------------------------------------------------------------------------------------
Slack (MET) :             0.350ns  (required time - arrival time)
  Source:                 ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_RX/iDC_OFFSET_REMOVE/dc_est_trunck_i_Z[11]/C
                            (rising edge-triggered cell FDCE clocked by clk_7680k  {rise@0.000ns fall@62.500ns period=125.000ns})
  Destination:            ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/bus_sync0_Z[11]/D
                            (rising edge-triggered cell FDCE clocked by ceva_clk  {rise@0.000ns fall@5.000ns period=10.000ns})
  Path Group:             ceva_clk
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            5.000ns  (ceva_clk rise@130.000ns - clk_7680k rise@125.000ns)
  Data Path Delay:        5.802ns  (logic 0.096ns (1.655%)  route 5.706ns (98.345%))
  Logic Levels:           0 
  Clock Path Skew:        1.814ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    2.394ns = ( 132.394 - 130.000 )
    Source Clock Delay      (SCD):    0.580ns = ( 125.580 - 125.000 )
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.689ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.422ns
    Phase Error              (PE):    0.475ns
  Clock Net Delay (Source):      0.580ns (routing 0.007ns, distribution 0.573ns)
  Clock Net Delay (Destination): 2.143ns (routing 0.962ns, distribution 1.181ns)
  Clock Domain Crossing:  Inter clock paths are considered valid unless explicitly excluded by timing constraints such as set_clock_groups or set_false_path.

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_7680k rise edge)
                                                    125.000   125.000 r 
    SLICE_X52Y343        FDCE                         0.000   125.000 r  ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_CLK_GEN/clk_7680k_1_Z/Q
    X1Y5 (CLOCK_ROOT)    net (fo=1436, routed)        0.580   125.580    ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_RX/iDC_OFFSET_REMOVE/clk_7680k
    SLICE_X52Y353        FDCE                                         r  ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_RX/iDC_OFFSET_REMOVE/dc_est_trunck_i_Z[11]/C
  -------------------------------------------------------------------    -------------------
    SLICE_X52Y353        FDCE (Prop_DFF_SLICEM_C_Q)
                                                      0.096   125.676 r  ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_RX/iDC_OFFSET_REMOVE/dc_est_trunck_i_Z[11]/Q
                         net (fo=1, routed)           5.706   131.382    ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/dc_est_i[11]
    SLICE_X52Y353        FDCE                                         r  ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/bus_sync0_Z[11]/D
  -------------------------------------------------------------------    -------------------

                         (clock ceva_clk rise edge)
                                                    130.000   130.000 r 
    MMCM_X0Y2            MMCME4_ADV                   0.000   130.000 r  ceva_clk_inst/mmcme4_adv_inst/CLKOUT0
                         net (fo=1, routed)           0.227   130.227    ceva_clk_inst/clk_out1_clk_wiz_0
    BUFGCE_X0Y62         BUFGCE (Prop_BUFCE_BUFGCE_I_O)
                                                      0.024   130.251 r  ceva_clk_inst/clkout1_buf/O
    X1Y3 (CLOCK_ROOT)    net (fo=46382, routed)       2.143   132.394    ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/ceva_clk
    SLICE_X52Y353        FDCE                                         r  ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/bus_sync0_Z[11]/C
                         clock pessimism              0.000   132.394   
                         clock uncertainty           -0.689   131.705   
    SLICE_X52Y353        FDCE (Setup_EFF_SLICEM_C_D)
                                                      0.027   131.732    ceva_dgf_top/dfe_fifo_top/u_dfe_top/iDFE_SFR_IF/iBUS_SYNC0/bus_sync0_Z[11]
  -------------------------------------------------------------------
                         required time                        131.732   
                         arrival time                        -131.382   
  -------------------------------------------------------------------
                         slack                                  0.350   

 

0 Kudos
1 Solution

Accepted Solutions
Mentor watari
Mentor
126 Views
Registered: ‎06-16-2013

Re: Understand timing report starting delay

Jump to solution

Hi @jhouee 

 

The reason is "using different clocks between launched FF and captured FF".

STA tool calculates least common multiple or near it to correctly analyze setup timing violation which is worst case, if using different clocks between launched FF and captured FF".

 

So, in this case, STA tool considers worst case for setup timing violation, launched time is 125[ns] (2 cycle of 16[MHz]) and captured time is 130[ns] (13 cycle of 100[MHz]).

 

Best regards,

View solution in original post

3 Replies
Xilinx Employee
Xilinx Employee
143 Views
Registered: ‎05-22-2018

Re: Understand timing report starting delay

Jump to solution

Hi @jhouee ,

I guess your understanding is correct, it is the starting delay added. Generally it is zero if their is only a clock constraint provided. Check page no.241 of below link:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug906-vivado-design-analysis.pdf

Thanks,

Raj

0 Kudos
Guide avrumw
Guide
128 Views
Registered: ‎01-23-2009

Re: Understand timing report starting delay

Jump to solution

You will notice that your startpoint (Source) and endpoint (Destination) are not on the same clock - the source is on clk_7680k, apparently ruinning at 8MHz, and the destination is on ceva_clk, which is at 100MHz.

When you have a path that goes between two clocks, the tools look at all combinations of edges on the source and destination clock and find the two that are the closest. So, for example, the first rising edge of clk_7680k would be at 0ns - a path launched at this edge would be captured at the next edge of ceva_clk which is at 10ns, resulting in a 10ns requirement for this path.

However, the second rising edge of clk_7680k is at 125ns (1x125ns). The edge of ceva_clk that would capture that path is at 14th edge, which is at time 130ns (the first is at 0ns, the 2nd is at 10ns, and so on), resulting in a 5ns requirement - since this is the smaller requirement, it is used (and it is easy to see that no other edges would result in anything smaller). So that's what the 125ns and 130ns are - the selection of which rising edges are used for the timing of this path.

That being said, there are a number of things about this report that show problems with your clocking structure and constraints

  • Your source clock does not start at a primary port of the FPGA
    • This means that you have a create_clock command on an internal pin of the FPGA
      • This is highly discouraged and prevents proper skew analysis of related clocks
  • Your source clock is generated by a flip-flop
    • Locally generated clocks are highly discouraged in an FPGA
    • Even if the clock is generated by a flip-flop, it should be constrained with a create_generated_clock, not a create_clock
  • Your desgination clock starts at an output of an MMCM
    • Again, this is a create_clock on the output of the MMCM
      • This is highly discouraged - the output of the MMCM should be automatically derived from the input (the tools will do this for you)
      • Again, this prevents proper skew analysis of related clocks
  • From this report we have no way to tell if the two clocks are actually related to each other in any way - the create_clock commands on internal pins prevent us from seeing the clock path upstream from these two points
    • If they are not from a common root (and hence these are unrelated clocks) this is an illegal clock domain crossing path (and will never work)
    • Even if they are from a common root, the two clock paths are grossly different, and, if you let the tools perfom the correct timing analysis (by constraining only the clock inputs, and having proper create_generated_clocks for the generated clocks), the tools will almost certainly tell you that this path fails due to huge clock skew
  • Also, it is a bit of a worry that your clock name of clk_7680k indicates that this clock should be running at 7.680MHz, rather than 8MHz. Since this path is a clock domain crossing path between these two domains, this makes a huge difference; at 8MHz, the requirement is 5ns as you see in your report. At 7.680MHz, the requirement is likely around 0.2ns or less (which is impossible to meet)

Before you can worry about this actual timing report, you have to fix all of the above things to make the report meaningful. Almost certainly, this path is going to be impossible to meet.

Avrum

0 Kudos
Mentor watari
Mentor
127 Views
Registered: ‎06-16-2013

Re: Understand timing report starting delay

Jump to solution

Hi @jhouee 

 

The reason is "using different clocks between launched FF and captured FF".

STA tool calculates least common multiple or near it to correctly analyze setup timing violation which is worst case, if using different clocks between launched FF and captured FF".

 

So, in this case, STA tool considers worst case for setup timing violation, launched time is 125[ns] (2 cycle of 16[MHz]) and captured time is 130[ns] (13 cycle of 100[MHz]).

 

Best regards,

View solution in original post