UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor rarvind
Visitor
348 Views
Registered: ‎06-23-2018

Mismatch of Logic cell delays from Data sheet vs Implemented design

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

 

AB
NamePath 1
Slack3.928ns
Sourced   (input port clocked by clk  {rise@1.000ns fall@6.000ns period=10.000ns})
Destinationr1_reg/D   (rising edge-triggered cell FDRE clocked by clk  {rise@1.000ns fall@6.000ns period=10.000ns})
Path Groupclk
Path TypeSetup (Max at Fast Process Corner)
Requirement10.000ns (clk rise@11.000ns - clk rise@1.000ns)
Data Path Delay1.045ns (logic 0.433ns (41.477%)  route 0.611ns (58.523%))
Logic Levels1  (IBUF=1)
Input Delay6.500ns
Clock Path Skew1.513ns
Clock Uncertainty0.035ns

 

DATA PATH:

Delay TypeIncr (ns)Path (ns)LocationNetlist Resource(s)
(clock clk rise edge)(r) 1.0001.000  
input delay6.5007.500  
 (r) 0.0007.500Site: J15d
net (fo=0)0.0007.500 d
IBUF (Prop_ibuf_I_O)(r) 0.4337.933Site: J15d_IBUF_inst/O
net (fo=1, routed)0.6118.545 d_IBUF
FDRE  Site: SLICE_X0Y114r1_reg/D
Arrival Time 8.545  

 

DESTINATION CLOCK PATH:

Delay TypeIncr (ns)Path (ns)LocationNetlist Resource(s)
(clock clk rise edge)(r) 11.00011.000  
 (r) 0.00011.000Site: E3clk
net (fo=0)0.00011.000 clk
IBUF (Prop_ibuf_I_O)(r) 0.25011.250Site: E3clk_IBUF_inst/O
net (fo=1, routed)0.64411.894 clk_IBUF
BUFG (Prop_bufg_I_O)(r) 0.02611.920Site: BUFGCTRL_X0Y16clk_IBUF_BUFG_inst/O
net (fo=2, routed)0.59412.513 clk_IBUF_BUFG
FDRE  Site: SLICE_X0Y114r1_reg/C
clock pessimism0.00012.513  
clock uncertainty-0.03512.478  
FDRE (Setup_fdre_C_D)-0.00512.473Site: SLICE_X0Y114r1_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 TypeIncr (ns)Path (ns)LocationNetlist Resource(s)
(clock clk rise edge)(r) 11.00011.000  
 (r) 0.00011.000Site: E3clk
net (fo=0)0.00011.000 clk
IBUF (Prop_ibuf_I_O)(r) 1.41112.411Site: E3clk_IBUF_inst/O
net (fo=1, routed)1.92014.331 clk_IBUF
BUFG (Prop_bufg_I_O)(r) 0.09114.422Site: BUFGCTRL_X0Y16clk_IBUF_BUFG_inst/O
net (fo=2, routed)1.58416.006 clk_IBUF_BUFG
FDRE  Site: SLICE_X0Y114r2_reg/C
clock pessimism0.30016.306  
clock uncertainty-0.03516.271  
FDRE (Setup_fdre_C_D)0.02916.300Site: SLICE_X0Y114r2_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?

0 Kudos
3 Replies
Highlighted
Participant evant_nq
Participant
289 Views
Registered: ‎07-18-2018

Re: Mismatch of Logic cell delays from Data sheet vs Implemented design

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.

Tags (1)
Visitor rarvind
Visitor
241 Views
Registered: ‎06-23-2018

Re: Mismatch of Logic cell delays from Data sheet vs Implemented design

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.

0 Kudos
Participant evant_nq
Participant
138 Views
Registered: ‎07-18-2018

Re: Mismatch of Logic cell delays from Data sheet vs Implemented design

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.

0 Kudos