Mismatch of Logic cell delays from Data sheet vs Implemented design

[rarvind]

Why there is mismatch of delays/setup/hold times in data sheets (ds181 AC DC Switching Characteristics) when compared after placement and route in timing reports?

For example: I've a simple register to register design to do the timing analysis.

Here is the following code:

module delay(
    input clk,d,
    output reg q
    );   
    reg r1;
    wire w;
    always@(posedge clk)
        r1 <= d;    
    assign w = !r1;
    always@(posedge clk)
        q <= w;     
endmodule

Data (d) from input is fed to D input of register 1 (r1_reg/D) From Q output(r1_reg/Q) is fed to inverter (using LUT1) where it's (inverter's) output is given to D of register 2 (r2_reg/D).

Path 1 delay_timing_summary

A	B
Name	Path 1
Slack	3.928ns
Source	d   (input port clocked by clk  {rise@1.000ns fall@6.000ns period=10.000ns})
Destination	r1_reg/D   (rising edge-triggered cell FDRE clocked by clk  {rise@1.000ns fall@6.000ns period=10.000ns})
Path Group	clk
Path Type	Setup (Max at Fast Process Corner)
Requirement	10.000ns (clk rise@11.000ns - clk rise@1.000ns)
Data Path Delay	1.045ns (logic 0.433ns (41.477%)  route 0.611ns (58.523%))
Logic Levels	1  (IBUF=1)
Input Delay	6.500ns
Clock Path Skew	1.513ns
Clock Uncertainty	0.035ns

DATA PATH:

Delay Type	Incr (ns)	Path (ns)	Location	Netlist Resource(s)
(clock clk rise edge)	(r) 1.000	1.000
input delay	6.500	7.500
	(r) 0.000	7.500	Site: J15	d
net (fo=0)	0.000	7.500		d
IBUF (Prop_ibuf_I_O)	(r) 0.433	7.933	Site: J15	d_IBUF_inst/O
net (fo=1, routed)	0.611	8.545		d_IBUF
FDRE			Site: SLICE_X0Y114	r1_reg/D
Arrival Time		8.545

DESTINATION CLOCK PATH:

Delay Type	Incr (ns)	Path (ns)	Location	Netlist Resource(s)
(clock clk rise edge)	(r) 11.000	11.000
	(r) 0.000	11.000	Site: E3	clk
net (fo=0)	0.000	11.000		clk
IBUF (Prop_ibuf_I_O)	(r) 0.250	11.250	Site: E3	clk_IBUF_inst/O
net (fo=1, routed)	0.644	11.894		clk_IBUF
BUFG (Prop_bufg_I_O)	(r) 0.026	11.920	Site: BUFGCTRL_X0Y16	clk_IBUF_BUFG_inst/O
net (fo=2, routed)	0.594	12.513		clk_IBUF_BUFG
FDRE			Site: SLICE_X0Y114	r1_reg/C
clock pessimism	0.000	12.513
clock uncertainty	-0.035	12.478
FDRE (Setup_fdre_C_D)	-0.005	12.473	Site: SLICE_X0Y114	r1_reg
Required Time		12.473

For example when going through properties in data sheet I can't see any where mentioned the Setup time (Setup_fdre_C_D) of flip flops in CLB to be 0.005.

Actually the min setup/hold time i've found for my device XC7A100TCSG324-1 to be

tDICK (AX - DX input to CLK on A-D flip flops) is 0.09/0.26 ns.

Similarly propagation delays of IBUF(prop_IBUF_I_O) of one path is 0.250ns which is different from other.

My path 2 is reg to reg- **Here I'm only showing destination clock path

Delay Type	Incr (ns)	Path (ns)	Location	Netlist Resource(s)
(clock clk rise edge)	(r) 11.000	11.000
	(r) 0.000	11.000	Site: E3	clk
net (fo=0)	0.000	11.000		clk
IBUF (Prop_ibuf_I_O)	(r) 1.411	12.411	Site: E3	clk_IBUF_inst/O
net (fo=1, routed)	1.920	14.331		clk_IBUF
BUFG (Prop_bufg_I_O)	(r) 0.091	14.422	Site: BUFGCTRL_X0Y16	clk_IBUF_BUFG_inst/O
net (fo=2, routed)	1.584	16.006		clk_IBUF_BUFG
FDRE			Site: SLICE_X0Y114	r2_reg/C
clock pessimism	0.300	16.306
clock uncertainty	-0.035	16.271
FDRE (Setup_fdre_C_D)	0.029	16.300	Site: SLICE_X0Y114	r2_reg
Required Time		16.300

How is that setup times of flip flops are different and are less than the minimum values what are specified in the data sheet.

Here in this path IBUF(Prop_IBUF_I_O) propagation delay is 1.411ns. How is this possible if clock to the both flip flops are routed through the same path?

[evant_nq]

Hi rarvind,

    Are you comparing the values in the Datasheet (ds181) to the timing report?

The values in the datasheet are not the same values that will be necessarily be in the timing report. The timing report has values that are based on characterization data to guarantee that setup and hold will be valid on any device meeting the speed grade specified, across PVT (Process, Voltage, Temp).

So a Datasheet value might be what can be measured in lab as the Max or Min, but to know setup and hold will be met on a specific static placement on any particular FPGA can produce different numbers.
    
    If the question is why there are differences between the difference on the Prop_ibuf_I_O on the Data path and the Clock path, the destination clock path for setup is at a different process corner and different paths. The data is Early, and the Clock is late.
    
    If you look at all corners for one of the delays: (This is based on a quick version of your example I put together) we can see what the value can be.
    

    CLK MAX FAST Prop_ibuf_I_O: (r) 0.196
    CLK MIN FAST Prop_ibuf_I_O: (r) 0.833
    CLK MAX SLOW Prop_ibuf_I_O: (r) 0.385
    CLK MIN SLOW Prop_ibuf_I_O: (r) 0.967

    We can actually find what the values the tool is using for these calculations using the following command:
    
report_property  [get_timing_arcs -of_objects [get_cells clk_IBUF_inst]]

Property             Type    Read-only  Value
CLASS                string  true       timing_arc
DELAY_FAST_MAX_FALL  double  true       0.385
DELAY_FAST_MAX_RISE  double  true       0.385
DELAY_FAST_MIN_FALL  double  true       0.196
DELAY_FAST_MIN_RISE  double  true       0.196
DELAY_MAX_FALL       double  true       0.967
DELAY_MAX_RISE       double  true       0.967
DELAY_MIN_FALL       double  true       0.196
DELAY_MIN_RISE       double  true       0.196
DELAY_SLOW_MAX_FALL  double  true       0.967
DELAY_SLOW_MAX_RISE  double  true       0.967
DELAY_SLOW_MIN_FALL  double  true       0.833
DELAY_SLOW_MIN_RISE  double  true       0.833
FROM_PIN             pin     true       clk_IBUF_inst/I
IS_DISABLED          bool    true       0
IS_USER_DISABLED     bool    true       0
LIB_CELL             string  true       xt_artix7/IBUF
NAME                 string  true       {clk_IBUF_inst/I --> clk_IBUF_inst/O [combinational] }
SENSE                string  true       positive_unate
TO_PIN               pin     true       clk_IBUF_inst/O
TYPE                 enum    true       combinational

And as you can see, we can see where the numbers come from. And this is specific for the exact arc as we can look at the other buffer and see it's numbers for setup and hold for that IBUF.

report_property  [get_timing_arcs -of_objects [get_cells d_IBUF_inst]]

Property             Type    Read-only  Value
CLASS                string  true       timing_arc
DELAY_FAST_MAX_FALL  double  true       0.380
DELAY_FAST_MAX_RISE  double  true       0.380
DELAY_FAST_MIN_FALL  double  true       0.191
DELAY_FAST_MIN_RISE  double  true       0.191
DELAY_MAX_FALL       double  true       0.963
DELAY_MAX_RISE       double  true       0.963
DELAY_MIN_FALL       double  true       0.191
DELAY_MIN_RISE       double  true       0.191
DELAY_SLOW_MAX_FALL  double  true       0.963
DELAY_SLOW_MAX_RISE  double  true       0.963
DELAY_SLOW_MIN_FALL  double  true       0.829
DELAY_SLOW_MIN_RISE  double  true       0.829
FROM_PIN             pin     true       d_IBUF_inst/I
IS_DISABLED          bool    true       0
IS_USER_DISABLED     bool    true       0
LIB_CELL             string  true       xt_artix7/IBUF
NAME                 string  true       {d_IBUF_inst/I --> d_IBUF_inst/O [combinational] }
SENSE                string  true       positive_unate
TO_PIN               pin     true       d_IBUF_inst/O
TYPE                 enum    true       combinational

Just to confirm, theis is the module and constraints I used. They might be slightly different, but you can use the same commands above to find your delays in your version.

module top(
    input clk,
    input d,
    output reg q
    );
reg r1;
wire w;
always@(posedge clk)
    r1 <= d;    
assign w = !r1;
always@(posedge clk)
    q <= w;   
endmodule

set_property PACKAGE_PIN E3 [get_ports clk]
set_property PACKAGE_PIN J15 [get_ports d]

create_clock -period 10.000 -name clk -waveform {1.000 6.000} [get_ports clk]
set_input_delay -clock [get_clocks clk] -max 6.500 [get_ports d]

If I misunderstood the question let me know, but I think that should at least give some more insight into how to find the numbers, and why you should relay on the speedfiles numbers not the DS numbers.

[rarvind]

How to find the timing_arcs of the BEL like LUTs and FF?
report_property -all [lindex [get_timing_arcs -of_objects [get_cells r1_reg]] 0]
Tried this but it's reporting nothing.

report_property -all [lindex [get_speed_models -of_objects [get_bels SLICE_X0Y114/A5FF]] 0]

*note: X0Y114 is where I constrained my design (p_block) and A5FF is where the r1_reg got placed.

Tried this but the corner values are not matching with the timing reports.

[evant_nq]

Tried this but the corner values are not matching with the timing reports.

Can you share what your corner values are? I would be curious to see what it reports compared to what the timing results for the path would be.