09-07-2020 06:44 AM
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.
09-07-2020 05:01 PM - edited 09-07-2020 05:08 PM
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
09-07-2020 05:01 PM - edited 09-07-2020 05:08 PM
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
09-08-2020 01:42 AM
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
09-08-2020 04:24 AM - edited 09-08-2020 07:55 AM
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.
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