cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Extract Modules From a Routed Design to Evaluate Timing Closure Readiness

Xilinx Employee
Xilinx Employee
5 0 121

As designs continue to increase in complexity and size, achieving repeatable and reliable timing closure can be a difficult task. 

The long run times required to fully place and route large designs can be difficult to navigate. However, when the fully assembled design is analyzed for timing, designers can frequently identify several key modules where the majority of the timing violations occur. 

In such cases, it can be helpful to perform a feasibility analysis to see if the troublesome module can close timing by itself in an out-of-context implementation. The purpose of this analysis is to assist the designer by reducing the complexity of the full place/route task so that they can iterate faster and identify potential solutions more quickly.

In this article, we will look at the generic case of extracting a hierarchical block (target module) out of a routed design for the purpose of out-of-context implementation.  (A similar approach could be taken by marking modules as out-of-context for synthesis.)

1.  Identify module(s) with significant timing violations from a fully routed design

One way to visualize which modules might be problematic in timing closure is to open a routed design checkpoint and generate a list of the top 500-1000 failing timing endpoints.

report_timing -of [get_timing_paths -max_paths 1000 -slack_lesser_than 0] -file route_paths.rpt -rpx route_paths.rpx -name route_paths

 

Visualization of these paths is best done using the hierarchy window in Vivado which can be easily summoned by hitting the F6 function key. 

Because timing paths are objects in Vivado, they can be selected in the Timing window and the corresponding cells/nets are highlighted in the hierarchy view.  The modules that light up the most are where the largest number of timing violations exist. 

These modules are good candidates for analysis using this method.

2020-08-27 16_43_11-xcoapps60_1 (xcoapps60_1 (jbieker)) - VNC Viewer.jpg

 

2.  Extract the target module

The target module can be extracted from the routed design checkpoint using the Tcl command write_checkpoint.  The checkpoint will contain placement and routing information as well as any timing assertions and exceptions (multicycle paths, false paths) that are scoped to modules under the hierarchy of the target module. 

After being unplaced and unrouted, the target_module.dcp is the checkpoint that will be placed/routed out-of-context.

write_checkpoint -quiet -force -cell [get_cells $target_module] target_module.dcp

Extract target module from routed checkpointExtract target module from routed checkpoint

 

3.  Create a simple floorplan

In order to prevent the placer from spreading the target module across the full span of the die, it is helpful to create a pblock that mirrors the placement of the module done for the full design. 

Below is an example of what a floorplan.tcl file might look like.

# Remove existing pblocks
if {[llength [get_pblocks]]} {
  delete_pblocks [get_pblocks *]
}

# Create pblock that mirrors the placement of the target module in the full design
create_pblock target_top
resize_pblock target_top -add CLOCKREGION_X0Y3:CLOCKREGION_X2Y4
add_cells_to_pblock target_top -top

 

Floorplan target moduleFloorplan target module

4.  Create a simple set of timing constraints

This step creates a set of clock constraints based on the top level clocks connected to the module.  The timing exceptions that are scoped to modules contained within the target module are retained in the target checkpoint.  For the sake of simplicity, it can be useful to force all of the clocks to be asynchronous.  A script is provided below to do the following:

  • create the clocks
  • create the timing exceptions between the clocks
  • create the HD.CLK_SRC property to allow the tool to better account for clock skew
  • adds 250 ps of setup uncertainty on each clock to make the analysis more realistic

To create the constraints, select the module in the Vivado GUI and run the script which will create a file called constraints.tcl that can be used to drive the out-of-context implementation of the module.

set CONSTRAINT_FILE [open constraints.tcl w]
set index 0

foreach pin [get_pins -filter {DIRECTION == IN} -of [get_selected_objects]] {
  if {[llength [set clock [get_clocks -quiet -of $pin]]] != 0} {
    set clk_name [get_property REF_PIN_NAME $pin]
    puts $CONSTRAINT_FILE "create_clock -quiet -name $clk_name -period [get_property PERIOD $clock] \[get_ports $clk_name\]"
    puts $CONSTRAINT_FILE "set_clock_groups -quiet -async -group \[get_clocks $clk_name\ -include_generated_clocks]"
    puts $CONSTRAINT_FILE "set_property -quiet HD.CLK_SRC BUFGCTRL_X0Y${index} \[get_ports $clk_name\]"
    incr index
  }
}

puts $CONSTRAINT_FILE "set_clock_uncertainty -quiet 0.250 -setup \[get_clocks\]"
close $CONSTRAINT_FILE

The resulting constraints.tcl file will look like the following:

create_clock -quiet -name clk_out1 -period 20.001 [get_ports clk_out1]
set_clock_groups -quiet -async -group [get_clocks clk_out1 -include_generated_clocks]
set_property -quiet HD.CLK_SRC BUFGCTRL_X0Y0 [get_ports clk_out1]
create_clock -quiet -name clk_out4 -period 3.334 [get_ports clk_out4]
set_clock_groups -quiet -async -group [get_clocks clk_out4 -include_generated_clocks]
set_property -quiet HD.CLK_SRC BUFGCTRL_X0Y1 [get_ports clk_out4]
create_clock -quiet -name clk_p -period 1.389 [get_ports clk_p]
set_clock_groups -quiet -async -group [get_clocks clk_p -include_generated_clocks]
set_property -quiet HD.CLK_SRC BUFGCTRL_X0Y2 [get_ports clk_p]
create_clock -quiet -name dphy_clk_200M -period 5.000 [get_ports clk_200M]
set_clock_groups -quiet -async -group [get_clocks clk_200M -include_generated_clocks]
set_property -quiet HD.CLK_SRC BUFGCTRL_X0Y3 [get_ports clk_200M]
set_clock_uncertainty -quiet 0.250 -setup [get_clocks]

The clock interaction report shows that the intra-clock paths are safely timed while the inter-clock timing paths are ignored.  This is precisely the goal of this analysis technique because the vast majority of timing paths in the target module are intra-clock paths.

Clock Interaction ReportClock Interaction Report

5.  Implement the target module out-of-context

Build the out-of-context target module with the following script:

open_checkpoint target_module.dcp
source constraints.tcl
source floorplan.tcl
route_design -unroute
place_design -unplace place_design write_checkpoint -force place.dcp report_utilization -file util.rpt report_timing_summary -file placed_tim.rpt report_design_analysis -timing -logic_level_distribution -of_timing_paths [get_timing_paths -max_paths 10000 -slack_lesser_than 0] -file place_vios.rpt report_timing -of [get_timing_paths -max_paths 1000 -slack_lesser_than 0] -file place_paths.rpt -rpx place_paths.rpx route_design write_checkpoint -force route.dcp report_timing_summary -file route_tim.rpt report_design_analysis -timing -logic_level_distribution -of_timing_paths [get_timing_paths -max_paths 10000 -slack_lesser_than 0] -file route_vios.rpt report_timing -of [get_timing_paths -max_paths 1000 -slack_lesser_than 0] -file route_paths.rpt -rpx route_paths.rpx report_qor_suggestions -file route_rqs.rpt write_qor_suggestions -force -tcl_output_dir route_wqs route_wqs.rpt

Implemented Target ModuleImplemented Target Module

6.  Analyze and Adjust

After the implementation run is complete, timing can be analyzed, timing constraints adjusted, floorplanning employed and the process can be repeated quickly to determine whether or not it is feasible for the module to close timing independently before implementing it in context with the rest of the design.

Using this technique, designers can identify and resolve timing bottlenecks more quickly which can reduce the duration of the timing closure task for the full design.