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!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎12-26-2015

Slack violations in kintex7 using vivado 14.4


I am getting following timing violation :



Slack (VIOLATED) :        -1.734ns  (required time - arrival time)

  Source:                 location1/DFF/q_reg/C

                            (rising edge-triggered cell FDCE clocked by clk_out3_dcm_fc  {rise@5.000ns fall@10.000ns period=10.000ns})

  Destination:            location1/DUT/q_reg/CLR

                            (recovery check against rising-edge clock clk_out1_dcm_fc  {rise@0.000ns fall@5.000ns period=10.000ns})

  Path Group:             **async_default**

  Path Type:              Recovery (Max at Slow Process Corner)

  Requirement:            5.000ns  (clk_out1_dcm_fc rise@10.000ns - clk_out3_dcm_fc rise@5.000ns)

  Data Path Delay:        6.086ns  (logic 0.316ns (5.192%)  route 5.770ns (94.808%))

  Logic Levels:           1  (BUFG=1)

  Clock Path Skew:        -0.274ns (DCD - SCD + CPR)

    Destination Clock Delay (DCD):    -1.150ns = ( 8.850 - 10.000 )

    Source Clock Delay      (SCD):    -1.705ns = ( 3.295 - 5.000 )

    Clock Pessimism Removal (CPR):    -0.830ns

  Clock Uncertainty:      0.187ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE

    Total System Jitter     (TSJ):    0.071ns

    Discrete Jitter          (DJ):    0.115ns

    Phase Error              (PE):    0.120ns


    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)

  -------------------------------------------------------------------    -------------------

                         (clock clk_out3_dcm_fc rise edge)

                                                      5.000     5.000 r 

    AD12                                              0.000     5.000 r  clk_p

                         net (fo=0)                   0.000     5.000    clocks/inst/clk_in1_p

    AD12                 IBUFDS (Prop_ibufds_I_O)     0.906     5.906 r  clocks/inst/clkin1_ibufgds/O

                         net (fo=1, routed)           1.081     6.987    clocks/inst/clk_in1_dcm_fc

    MMCME2_ADV_X1Y1      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT2)

                                                     -7.786    -0.799 r  clocks/inst/mmcm_adv_inst/CLKOUT2

                         net (fo=1, routed)           2.130     1.331    clocks/inst/clk_out3_dcm_fc

    BUFGCTRL_X0Y5        BUFG (Prop_bufg_I_O)         0.093     1.424 r  clocks/inst/clkout3_buf/O

                         net (fo=8, routed)           1.871     3.295    location1/DFF/q_delayed

    SLICE_X4Y1                                                        r  location1/DFF/q_reg/C

  -------------------------------------------------------------------    -------------------

    SLICE_X4Y1           FDCE (Prop_fdce_C_Q)         0.223     3.518 f  location1/DFF/q_reg/Q

                         net (fo=1, routed)           3.766     7.284    n_0_location1

    BUFGCTRL_X0Y0        BUFG (Prop_bufg_I_O)         0.093     7.377 f  temp_inferred_i_5/O

                         net (fo=52, routed)          2.004     9.381    location1/DUT/q_delayed

    SLICE_X2Y1           FDCE                                         f  location1/DUT/q_reg/CLR

  -------------------------------------------------------------------    -------------------


                         (clock clk_out1_dcm_fc rise edge)

                                                     10.000    10.000 r 

    AD12                                              0.000    10.000 r  clk_p

                         net (fo=0)                   0.000    10.000    clocks/inst/clk_in1_p

    AD12                 IBUFDS (Prop_ibufds_I_O)     0.803    10.803 r  clocks/inst/clkin1_ibufgds/O

                         net (fo=1, routed)           0.986    11.789    clocks/inst/clk_in1_dcm_fc

    MMCME2_ADV_X1Y1      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)

                                                     -6.759     5.030 r  clocks/inst/mmcm_adv_inst/CLKOUT0

                         net (fo=1, routed)           2.005     7.035    clocks/inst/clk_out1_dcm_fc

    BUFGCTRL_X0Y4        BUFG (Prop_bufg_I_O)         0.083     7.118 r  clocks/inst/clkout1_buf/O

                         net (fo=47, routed)          1.732     8.850    location1/DUT/fc_dut

    SLICE_X2Y1                                                        r  location1/DUT/q_reg/C

                         clock pessimism             -0.830     8.021   

                         clock uncertainty           -0.187     7.833   

    SLICE_X2Y1           FDCE (Recov_fdce_C_CLR)     -0.187     7.646    location1/DUT/q_reg


                         required time                          7.646   

                         arrival time                          -9.381   


                         slack                                 -1.734   


I have attached the timing report. Please find it and give some solution.


Thanks & Regards


0 Kudos
1 Reply
Registered: ‎01-23-2009

Re: Slack violations in kintex7 using vivado 14.4

The path you are showing here is not your biggest problem - there is another path with a slack of -5.355, which is the same type of path.


Both paths are to the asyncronous clear input of a flip-flop. Even though these are asynchronous clear inputs they must be deasserted synchronously - that is what the reset recovery timing check is for. 


The root of the problem is that you appear to be resetting multiple clock domains all with the same reset. The reset if generated by a flip-flop on clk_out3, which is a "normal" 10ns clock (rise=0, fall=5). The path you are showing is to the CLR input of a flip-flop on an 10ns clock that is 180 degrees out of phase (resulting in a requirement of 5ns), and the worse path is to the CLR input of a flip-flop running on a phase shifted 12.5ns clock, which has a rising edge at 1.406 (resulting in a 1.406ns requirement).


Neither of these can be met.


In addition, there is is likely a large number of flip-flops being reset/cleared, and hence the tools have inserted a BUFG on this huge fanout net.


The solution is to fix your reset structure.


First, you need a separate reset for each clock domain. To generate it, normally you would use a reset bridge for each clock domain.




This generates a reset that is asserted asynchronously with the rst_in, but deasserted synchronously with respect to dst_clk. You will need one of these for each clock domain. This is a clock crossing circuit, so should have the ASYNC_REG property set on both flip-flops (although this doesn't matter in ISE, but should be used in Vivado). You will also need an exception (a set_false_path in Vivado or TIG in ISE) on the rst_in signal.


Since these clocks are all from the same MMCM, these clocks are technically synchronous, you could probably get away with simply registering the "reset" flop on each domain, but there is no harm in using the full reset bridge - as long as you don't care that there is some uncertaintly as to which clock edge will take each domain out of reset.


You should also question your entire reset strategy. In Xilinx devices, synchronous resets are preferred over asynchronous resets, and no resets are preferred over that. Getting by without resets can reduce the routing of your design significantly, but has to be done very carefully to ensure that your design comes up properly (any flip-flop that can change state on the first clocks after "start up" needs an expicit and synchronized reset).



Tags (2)
0 Kudos