cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
2,558 Views
Registered: ‎01-22-2015

delay vs phase-shift in timing analysis

Jump to solution

The schematic below shows circuits for source-synchronous input to a Kintex-7 FPGA.

Src_Sync_Input1.jpg

Data, SCP_DATA_A[0], entering the FPGA is center-aligned so things should be simple.  I just need to get the forwarded clock, SCP_DATA_CLK, into the FPGA clock-tree and then route the clock to a register that captures the data.  Using BUFR would be convenient, but SCP_DATA_CLK is not on a clock-capable pin and cannot reach a BUFR.  So, I used set_property CLOCK_DEDICATED_ROUTE FALSE and routed SCP_DATA_CLK to a PLL in case some added delay/phase-shift is needed to keep the data center-aligned.  Constraints for the interface are:

 

set_input_delay -clock SCP_DATA_CLK -max 9.3 [get_ports {SCP_DATA_A[0]}]

set_input_delay -clock SCP_DATA_CLK -min 7.3 [get_ports {SCP_DATA_A[0]}]

…and use of IP (Clocking Wizard) for the PLL has automatically generated the following constraint.

create_clock -period 16.667 [get_ports clk_in1]

 

With the PLL configured for 0deg phase-shift of the forwarded lock, timing analysis reports plenty of margin for the interface: setup slack= +4.7ns,  hold slack= +7.5ns.

 

I should have left well-enough alone – but – I wanted to get perfectly center-aligned data (ie. make setup and hold slack equal). I calculated that a delay of 1.4ns would balance the slacks (4.7+1.4=6.1,  7.5-1.4=6.1).  Since, the clock period is 16.667ns, I reasoned that 1.4ns equates to (360*1.4/16.667) ~ 30deg phase shift. 

 

Reconfiguring the PLL to give -30deg phase shift resulted in setup slack= +3.3ns, hold slack= +8.9ns.  Oops – wrong way – no worries.  I’ll just reconfigure the PLL to give +30deg phase shift and all should be perfect.

 

Reconfiguring the PLL to give +30deg phase shift resulted in setup slack= -10.6ns,  hold slack= +22.8ns. For me, this result was unexpected!

 

Here is the setup timing report when the PLL is configured to give 0deg phase shift.  It all makes sense to me.

--------------------------------------------------------------------------------------
| Tool Version : Vivado v.2017.3.1 (win64) Build 2035080 Fri Oct 20 14:20:01 MDT 2017
| Date         : Sat Jun  9 07:09:28 2018
| Host         : Rosetta running 64-bit Service Pack 1  (build 7601)
| Command      : report_timing -to [get_cells {a62d/bA62_ADAT_reg[0]}] -setup
| Design       : BRADBURY
| Device       : 7k160t-fbg484
| Speed File   : -3  PRODUCTION 1.12 2017-02-17
--------------------------------------------------------------------------------------
Timing Report
Slack (MET) :             4.657ns  (required time - arrival time)
  Source:                 SCP_DATA_A[0]
                            (input port clocked by SCP_DATA_CLK  {rise@0.000ns fall@8.333ns period=16.667ns})
  Destination:            a62d/bA62_ADAT_reg[0]/D
                            (rising edge-triggered cell FDRE clocked by clk_out1_ADC_PLL  {rise@0.000ns fall@8.333ns period=16.667ns})
  Path Group:             clk_out1_ADC_PLL
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            16.667ns  (clk_out1_ADC_PLL rise@16.667ns - SCP_DATA_CLK rise@0.000ns)
  Data Path Delay:        1.424ns  (logic 1.424ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           1  (IBUF=1)
  Input Delay:            9.300ns
  Clock Path Skew:        -1.023ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    -1.023ns = ( 15.644 - 16.667 ) 
    Source Clock Delay      (SCD):    0.000ns
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.252ns  ((TSJ^2 + TIJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.166ns
    Discrete Jitter          (DJ):    0.190ns
    Phase Error              (PE):    0.121ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock SCP_DATA_CLK rise edge)
                                                      0.000     0.000 r  
                         input delay                  9.300     9.300    
    C12                                               0.000     9.300 r  SCP_DATA_A[0] (IN)
                         net (fo=0)                   0.000     9.300    SCP_DATA_A[0]
    C12                  IBUF (Prop_ibuf_I_O)         1.424    10.724 r  SCP_DATA_A_IBUF[0]_inst/O
                         net (fo=1, routed)           0.000    10.724    a62d/SCP_DATA_A[11][0]
    ILOGIC_X0Y196        FDRE                                         r  a62d/bA62_ADAT_reg[0]/D
  -------------------------------------------------------------------    -------------------

                         (clock clk_out1_ADC_PLL rise edge)
                                                     16.667    16.667 r  
    B20                                               0.000    16.667 r  SCP_DATA_CLK (IN)
                         net (fo=0)                   0.000    16.667    a62d/clkf/inst/clk_in1
    B20                  IBUF (Prop_ibuf_I_O)         1.295    17.962 r  a62d/clkf/inst/clkin1_ibufg/O
                         net (fo=1, routed)           0.955    18.917    a62d/clkf/inst/clk_in1_ADC_PLL
    PLLE2_ADV_X0Y3       PLLE2_ADV (Prop_plle2_adv_CLKIN1_CLKOUT0)
                                                     -5.792    13.125 r  a62d/clkf/inst/plle2_adv_inst/CLKOUT0
                         net (fo=1, routed)           1.277    14.402    a62d/clkf/inst/clk_out1_ADC_PLL
    BUFGCTRL_X0Y16       BUFG (Prop_bufg_I_O)         0.072    14.474 r  a62d/clkf/inst/clkout1_buf/O
                         net (fo=133, routed)         1.170    15.644    a62d/CLK60
    ILOGIC_X0Y196        FDRE                                         r  a62d/bA62_ADAT_reg[0]/C
                         clock pessimism              0.000    15.644    
                         clock uncertainty           -0.252    15.392    
    ILOGIC_X0Y196        FDRE (Setup_fdre_C_D)       -0.010    15.382    a62d/bA62_ADAT_reg[0]
  -------------------------------------------------------------------
                         required time                         15.382    
                         arrival time                         -10.724    
  -------------------------------------------------------------------
                         slack                                  4.657    

 

When the PLL is configured to give +30deg phase shift, only the required-time calculation changes during setup timing analysis  – as shown below. This timing report does not make sense to me.  I would have expected the +30deg phase shift to affect the PLL delay of -5.792 (changing it to -5.792+1.389= -4.403) and for the launch-time of the clock capture-edge to remain at 16.667 (instead of being changed to 1.389).  

                         (clock clk_out1_ADC_PLL rise edge)
                                                      1.389     1.389 r  
    B20                                               0.000     1.389 r  SCP_DATA_CLK (IN)
                         net (fo=0)                   0.000     1.389    a62d/clkf/inst/clk_in1
    B20                  IBUF (Prop_ibuf_I_O)         1.295     2.684 r  a62d/clkf/inst/clkin1_ibufg/O
                         net (fo=1, routed)           0.955     3.639    a62d/clkf/inst/clk_in1_ADC_PLL
    PLLE2_ADV_X0Y3       PLLE2_ADV (Prop_plle2_adv_CLKIN1_CLKOUT0)
                                                     -5.792    -2.153 r  a62d/clkf/inst/plle2_adv_inst/CLKOUT0
                         net (fo=1, routed)           1.277    -0.876    a62d/clkf/inst/clk_out1_ADC_PLL
    BUFGCTRL_X0Y16       BUFG (Prop_bufg_I_O)         0.072    -0.804 r  a62d/clkf/inst/clkout1_buf/O
                         net (fo=133, routed)         1.170     0.366    a62d/CLK60
    ILOGIC_X0Y196        FDRE                                         r  a62d/bA62_ADAT_reg[0]/C
                         clock pessimism              0.000     0.366    
                         clock uncertainty           -0.246     0.120    
    ILOGIC_X0Y196        FDRE (Setup_fdre_C_D)       -0.010     0.110    a62d/bA62_ADAT_reg[0]
  -------------------------------------------------------------------
                         required time                          0.110    
                         arrival time                         -10.724    
  -------------------------------------------------------------------
                         slack                                -10.614  

 

Please explain how timing analysis is interpreting and using the PLL phase shift of +30deg for the forwarded clock.

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
2,856 Views
Registered: ‎01-23-2009

Mark,

 

As you suspect the difference is due to the fact that Vivado treats phase shifts (WAVEFORM delay) differently then propagation (LATENCY delay) delays.

 

By adding a phase shift, the "new" clock generated by the MMCM has edges that occur after the input clock (as opposed to a 0 shift, which has edges at the same time as the input clock). Since the setup capture edge is the first destination clock edge (strictly) after the launch edge, this changes as you change from 0 to anything positive. At 0 degree phase shift, since the two clocks are aligned, the "next" edge of the destination clock is one full clock period later. At ANY (i.e. 0.1ns) positive phase shift, the destination clock edges are now later than the source clock edges, so the "next" destination clock edge is not a full clock period later (like it was at 0 degrees) but the magnitude of your delay (i.e. 0.1ns) later.

 

The "old" way of fixing this was to use the set_multicycle_path 0 for the input constraints. But...

 

This is the perfect opportunity to use the

 

set_property PHASESHIFT_MODE LATENCY [get_cells a62d/clkf/inst/plle2_adv_inst]

 

This will change how the tools treat the MMCM phase shift. Now won't need to change the constraints regardless of the phase shift (0, +ve, or -ve).

 

Avrum

View solution in original post

2 Replies
avrumw
Guide
Guide
2,857 Views
Registered: ‎01-23-2009

Mark,

 

As you suspect the difference is due to the fact that Vivado treats phase shifts (WAVEFORM delay) differently then propagation (LATENCY delay) delays.

 

By adding a phase shift, the "new" clock generated by the MMCM has edges that occur after the input clock (as opposed to a 0 shift, which has edges at the same time as the input clock). Since the setup capture edge is the first destination clock edge (strictly) after the launch edge, this changes as you change from 0 to anything positive. At 0 degree phase shift, since the two clocks are aligned, the "next" edge of the destination clock is one full clock period later. At ANY (i.e. 0.1ns) positive phase shift, the destination clock edges are now later than the source clock edges, so the "next" destination clock edge is not a full clock period later (like it was at 0 degrees) but the magnitude of your delay (i.e. 0.1ns) later.

 

The "old" way of fixing this was to use the set_multicycle_path 0 for the input constraints. But...

 

This is the perfect opportunity to use the

 

set_property PHASESHIFT_MODE LATENCY [get_cells a62d/clkf/inst/plle2_adv_inst]

 

This will change how the tools treat the MMCM phase shift. Now won't need to change the constraints regardless of the phase shift (0, +ve, or -ve).

 

Avrum

View solution in original post

2,524 Views
Registered: ‎01-22-2015

Avrum,

 

Many thanks for very clear explanation and perfect solution!

 

Mark

0 Kudos