cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pf_arc
Observer
Observer
290 Views
Registered: ‎06-21-2018

Vivado 2017.4 report_timing irregular behaviour regarding process corners (Update: Possibly Quad SPI/Timing constraint related)

I'm having problems with erratic behaviour of the report_timing command, I believe that there might be a problem with my config_timing_corners setting.

When I open a routed design checkpoint, the report_timing command does not report any issues:

 

open_checkpoint: Time (s): cpu = 00:01:20 ; elapsed = 00:01:08 . Memory (MB): peak = 2514.000 ; gain = 1722.449
report_timing -delay_type min_max -path_type end -no_header -warn_on_violation
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -2, Delay Type: min_max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -max_paths 1 -nworst 1 -delay_type min_max -sort_by slack.
Endpoint                       Path Delay(ns)  Requirement(ns)  Clock Skew(ns)  Slack(ns)     
----------------------------------------------------------------------------------------------
endpoint_name
                               0.656           0.000            0.302           0.013         



report_timing: Time (s): cpu = 00:00:36 ; elapsed = 00:00:19 . Memory (MB): peak = 2764.570 ; gain = 140.418

 

However, if I reconfigure setting the config_timing_corners setting, a violation appears:

 

open_checkpoint: Time (s): cpu = 00:01:19 ; elapsed = 00:01:07 . Memory (MB): peak = 2523.688 ; gain = 1716.188
config_timing_corners -corner Slow -delay_type min_max
config_timing_corners -corner Fast -delay_type min_max
report_timing -delay_type min_max -path_type end -no_header -warn_on_violation
INFO: [Timing 38-91] UpdateTimingParams: Speed grade: -2, Delay Type: min_max.
INFO: [Timing 38-191] Multithreading enabled for timing update using a maximum of 2 CPUs
INFO: [Timing 38-78] ReportTimingParams: -max_paths 1 -nworst 1 -delay_type min_max -sort_by slack.
CRITICAL WARNING: [Timing 38-282] The design failed to meet the timing requirements. Please see the timing report for details on the timing violations.
Endpoint                       Path Delay(ns)  Requirement(ns)  Clock Skew(ns)  Slack(ns)     
----------------------------------------------------------------------------------------------
different_endpoint_name
                               0.420           13.300           -7.877          -3.516        



report_timing: Time (s): cpu = 00:00:38 ; elapsed = 00:00:19 . Memory (MB): peak = 2867.105 ; gain = 95.297

 

According to the config_timing_corners -help command, the min_max setting for both Slow and Fast is Vivado's default.

The design has been generated using non-project mode with a tcl script which to my knowledge does not reconfigure the config_timing_corners setting, but then how can I explain the mentioned behaviour? Can I check the current config_timing_corner setting somehow in the tcl script?

Edit: We execute this "report_timing -delay_type min_max -path_type end -no_header -warn_on_violation" routinely as part of our implementation script in order to generate a critical warning if timing fails. I have now modified the script to execute "config_timing_corners -corner Slow -delay_type min_max" and "config_timing_corners -corner Fast -delay_type min_max" immediately before the report. When the implementation had finished, there was no critical warning, and the timing was met, however opening the design checkpoint and configuring Slow to min and Fast to max revealed the timing issue again. I am at a complete loss what is happening.

Edit 2: The plot thickens. It seems to me that the problem is in the nature of the failing path: the input flip flop of a Xilinx AXI Quad SPI (PG153) instance. If I increase the maximum number of worst paths per endpoint, I see that two paths fail but two paths between the same source/destination meet the timing:

pf_arc_0-1625229725167.png

Is it possible that report_timing command simply does not realize that some of the paths fail? Why the path in question fails is also not clear to me, it is simply between the pad and the input flip flop:

pf_arc_1-1625230030602.png

I assume the problems happen because of the multicycle constraint, which is taken from the IP's xdc file and I don't quite understand what it does:

 

#------------------------------------------------------------------------------
# for Axi Quad SPI

# Startup block clock delay value
set cclk_delay 6.7
# - - - - - - - - - - - - - - - - - - - - - - - - -
# Following are the SPI device parameters
# Max Tco
set tco_max 8
# Min Tco
set tco_min 0
# Setup time requirement
set tsu 2
# Hold time requirement
set th 3

# Following are the board/trace delay numbers
# Assumption is that all Data lines are matched
set tdata_trace_delay_max 0.25
set tdata_trace_delay_min 0.25
set tclk_trace_delay_max 0.2
set tclk_trace_delay_min 0.2
# - - - - - - - - - - - - - - - - - - - - - - - - -

# Following command creates a divide by 2 clock
# It also takes into account the delay added by STARTUP block to route the CCLK
# This constraint is not needed when STARTUP block is disabled 
create_generated_clock  -name clk_sck -source [get_pins -hierarchical *axi_quad_spi_0/ext_spi_clk] [get_pins -hierarchical *USRCCLKO] -edges {3 5 7} -edge_shift [list $cclk_delay $cclk_delay $cclk_delay]

# Data is captured into FPGA on the second rising edge of ext_spi_clk after the SCK falling edge 
# Data is driven by the FPGA on every alternate rising_edge of ext_spi_clk
set_input_delay -clock clk_sck -max [expr $tco_max + $tdata_trace_delay_max + $tclk_trace_delay_max] [get_ports SPI_D*] -clock_fall;
set_input_delay -clock clk_sck -max [expr $tco_max + $tdata_trace_delay_max + $tclk_trace_delay_max] [get_ports F_CS] -clock_fall;
set_input_delay -clock clk_sck -min [expr $tco_min + $tdata_trace_delay_min + $tclk_trace_delay_min] [get_ports SPI_D*] -clock_fall;
set_input_delay -clock clk_sck -min [expr $tco_min + $tdata_trace_delay_min + $tclk_trace_delay_min] [get_ports F_CS] -clock_fall;
set_multicycle_path 2 -setup -from clk_sck -to [get_clocks -of_objects [get_pins -hierarchical */ext_spi_clk]] 
set_multicycle_path 1 -hold -end -from clk_sck -to [get_clocks -of_objects [get_pins -hierarchical */ext_spi_clk]] 

# Data is captured into SPI on the following rising edge of SCK
# Data is driven by the IP on alternate rising_edge of the ext_spi_clk
set_output_delay -clock clk_sck -max [expr $tsu + $tdata_trace_delay_max - $tclk_trace_delay_min] [get_ports SPI_D*];
set_output_delay -clock clk_sck -max [expr $tsu + $tdata_trace_delay_max - $tclk_trace_delay_min] [get_ports F_CS];
set_output_delay -clock clk_sck -min [expr $tdata_trace_delay_min -$th - $tclk_trace_delay_max] [get_ports SPI_D*];
set_output_delay -clock clk_sck -min [expr $tdata_trace_delay_min -$th - $tclk_trace_delay_max] [get_ports F_CS];
set_multicycle_path 2 -setup -start -from [get_clocks -of_objects [get_pins -hierarchical */ext_spi_clk]] -to clk_sck 
set_multicycle_path 1 -hold -from [get_clocks -of_objects [get_pins -hierarchical */ext_spi_clk]] -to clk_sck

 

 

 

0 Kudos
0 Replies