I/O buffers timing

[adam_mira]

Hi,

How can I report the setup and hold times of specific Flip Flop connected to differential input?

My design contains:

Diff input --> I/O pads -->  ibufds --> FF

1. Does the IBUFDS contain internal FF of some sort? (I am pretty sure that it doesn't but in any case:)

2. How can I calculate the setup and hold times requirements of the 1st FF (wherever it is located) using Vivado?

3. And how can I force Vivado to implement that Flip Flop to receive the best setup and hold times requirements? (I guess closest to the IBUFDS, no?)

Thank you,

Adam. 

[markg@prosensing.com · Accepted solution]

@adam_mira 

Does the IBUFDS contain internal FF of some sort? (I am pretty sure that it doesn't but in any case:)
And how can I force Vivado to implement that Flip Flop to receive the best setup and hold times requirements? (I guess closest to the IBUFDS, no?)

You are nearly correct.  There is a FF that is locked into position right next to the IBUF called the I/O-Block(IOB) FF.  When trying to capture data that is coming into the FPGA (eg. via a source synchronous interface), we often use the IOB FF for the data capture register.  You can force the capture FF in your design to be placed in the IOB in several ways (see discussion starting on page 249 of UG912 (v2020.1) for details.

How can I calculate the setup and hold times requirements of the 1st FF (wherever it is located) using Vivado?
It is a good question – but one that does not come with an easy answer (see Avrum’s discussion <here>).  The thing is, when trying to capture data coming into the FPGA, setup and hold of the capture FF are certainly important (from a timing analysis point of view).  However, the delay variability over PVT of other components (eg. IBUF) that lie in the data capture path is also very important.  So, we usually don’t ask the question about FF setup and hold.  Instead, we take a system view of the problem and use Vivado timing reports to guide our design.

For example, the schematic below shows a simple source synchronous input interface where I am capturing the data coming into port, DAT1_IN, using the register called DAT2_reg, that I have locked into the IOB.  I am also using the MMCM clock module called CLKGEN to shift the interface clock so that the clock capture edge is positioned in the middle of the data eye. 

The setup timing report for this interface is shown below.  You will note that one of the final lines (in red) shows setup of the IOB FF (DAT2_reg) – and yes, that negative value is real.  However, I had to consider the entire timing report in order to get the clock capture edge into the middle of the data eye – and not just the FF setup/hold values.

Slack (MET) :             3.553ns  (required time - arrival time)
  Source:                 DAT1_IN
                            (input port clocked by CLK1_IN  {rise@0.000ns fall@3.750ns period=7.500ns})
  Destination:            DAT2_reg/D
                            (rising edge-triggered cell FDRE clocked by clk_out1_CLKGEN  {rise@0.000ns fall@3.750ns period=7.500ns})
  Path Group:             clk_out1_CLKGEN
  Path Type:              Setup (Max at Slow Process Corner)
  Requirement:            7.500ns  (clk_out1_CLKGEN rise@7.500ns - CLK1_IN rise@0.000ns)
  Data Path Delay:        1.378ns  (logic 1.378ns (100.000%)  route 0.000ns (0.000%))
  Logic Levels:           1  (IBUF=1)
  Input Delay:            4.342ns
  Phase Shift in Clock Latency:
    Destination Clock:    2.500ns
  Clock Path Skew:        1.955ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    1.955ns = ( 9.455 - 7.500 ) 
    Source Clock Delay      (SCD):    0.000ns
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.172ns  ((TSJ^2 + TIJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Total Input Jitter      (TIJ):    0.075ns
    Discrete Jitter          (DJ):    0.114ns
    Phase Error              (PE):    0.095ns

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock CLK1_IN rise edge)    0.000     0.000 r  
                         input delay                  4.342     4.342    
    E13                                               0.000     4.342 r  DAT1_IN (IN)
                         net (fo=0)                   0.000     4.342    DAT1_IN
    E13                  IBUF (Prop_ibuf_I_O)         1.378     5.720 r  DAT1_IN_IBUF_inst/O
                         net (fo=1, routed)           0.000     5.720    DAT1_IN_IBUF
    ILOGIC_X0Y230        FDRE                                         r  DAT2_reg/D
  -------------------------------------------------------------------    -------------------

                         (clock clk_out1_CLKGEN rise edge)
                                                      7.500     7.500 r  
    C17                                               0.000     7.500 r  CLK1_IN (IN)
                         net (fo=0)                   0.000     7.500    MMCM1/inst/clk_in1
    C17                  IBUF (Prop_ibuf_I_O)         1.284     8.784 r  MMCM1/inst/clkin1_ibufg/O
                         net (fo=1, routed)           0.895     9.679    MMCM1/inst/clk_in1_CLKGEN
    MMCME2_ADV_X0Y3      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
                                                     -2.819     6.860 r  MMCM1/inst/mmcm_adv_inst/CLKOUT0
                         net (fo=1, routed)           1.278     8.138    MMCM1/inst/clk_out1_CLKGEN
    BUFGCTRL_X0Y16       BUFG (Prop_bufg_I_O)         0.072     8.210 r  MMCM1/inst/clkout1_buf/O
                         net (fo=2, routed)           1.245     9.455    CLK1
    ILOGIC_X0Y230        FDRE                                         r  DAT2_reg/C
                         clock pessimism              0.000     9.455    
                         clock uncertainty           -0.172     9.284    
    ILOGIC_X0Y230        FDRE (Setup_fdre_C_D)       -0.010     9.274    DAT2_reg
  -------------------------------------------------------------------
                         required time                          9.274    
                         arrival time                          -5.720    
  -------------------------------------------------------------------
                         slack                                  3.553   

Cheers,
Mark

[adam_mira]

markg@prosensing.com 

Thank you very much for your answer!

A follow-up question regarding forcing the capture FF in your design to be placed in the IOB:

In the referenced document UG912 the attribute IOB is displayed for "directs the Vivado tool to place a register that is connected to the specified port into the input or output logic block".

And the example: (VHDL Syntax example)

ACK : in std_logic;
attribute IOB : string;
-- Place the register connected to ACK in the input logic site
attribute IOB of ACK: signal is "TRUE";

How should I modify the example for differential ports? for example:

Ports:
ACK_p : in std_logic;
ACK_n : in std_logic;
Signal:
ACK_signal :  std_logic;
IBUFDS:
My_ibufds : IBUFDS port map( I => ACK_p , IB => ACK_n , O => ACK_signal );

attribute IOB : string;
-- Place the register connected to ACK in the input logic site
attribute IOB of ?????? : signal is "TRUE";

1. Should the attribute contain both ports:
attribute IOB of ACK_p : signal is "TRUE";
attribute IOB of ACK_n: signal is "TRUE";

2. Or just one of them:
attribute IOB of ACK_p : signal is "TRUE";

3. Or the IBUFDS output signal:
attribute IOB of ACK_signal : signal is "TRUE";

Thank you,

Adam

[markg@prosensing.com]

Adam,

The VHDL attribute method of placing a FF in the IOB can only applied to the FF (I think).  However, the following XDC constraint can be applied to the P-side of your LVDS port and it will pull-in the connected FF to the IOB.

set_property IOB TRUE [get_ports ACK_p]

In older versions of Vivado, the VHDL attribute method of setting IOB=TRUE did not work reliably.  However, since Vivado v2016, both the VHDL attribute method and the set_property XDC constraint method have worked reliably for me.

Pulling a FF into the IOB is possible if you have a direct and single connection from the IBUF to the FF.  However, if the connection between the IBUF and the FF has a combinational logic (eg. LUT) or the connection splits and goes someplace else then you cannot pull the FF into the IOB.  The following post shows ways to check if a FF has been pulled into the IOB.

https://forums.xilinx.com/t5/Design-Entry/How-to-indentify-if-IOB-Flip-Flop-was-used-after-P-amp-R-Vivado/m-p/979916#M20623

Finally, (very cool alert!!) it is possible to place a two-FF synchronizer into the IOB as Avrum showed me in the following post.

https://forums.xilinx.com/t5/Timing-Analysis/IOB-Register-and-Synchronizer/m-p/755227