12-18-2018 02:28 AM
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?
12-20-2018 06:56 AM - edited 12-20-2018 07:00 AM
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.
12-25-2018 10:59 PM - edited 12-25-2018 11:07 PM
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.
01-10-2019 02:22 PM
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.