Step 5: Correlating Long Congestion with Dataflow Paths - Step 5: Correlating Long Congestion with Dataflow Paths - 2025.1 English - UG938

1. Transporting data buses from one point to another in a device. This is caused by placement of cells driving or receiving data buses being far away from each other.
2. Areas of imbalanced cell type resource forcing local modules to be spread. This can force smaller contained modules to spread and end up using long routes.

This section focuses on long congestion caused by data path placement. When you have long congestion, the tool switches to shorter routes and consequently it traverses through more switchboxes. It is a slow process, hence a process to avoid when you have the following scenarios:

• Timing failures going through long congested areas
• Short congestion overlapping with long congestion

On a design with congestion, when you run report_design_analysis, it displays congested areas and gives a profile of the cells within the congested area. For short congestion, analysis is typically contained within the congested area. However, for long congestion, relevant paths not only start and end within the congested area but might also begin outside it or end outside it.

In this step, you must identify paths within an area, filter them based on direction and length and finally expand the paths to get a more holistic view of the path.

From this picture you can right click Select tiles and this selects all the tiles.

set congested_tiles [get_selected_objects]

1. It is at this point where you resume working on the tutorial design. Run the following command to set up a congested_tiles variable. This assumes that you have long congestion in the south direction within these clock regions:

   set clk_regions [get_clock_regions [list X1Y3 X2Y3 X3Y3 X4Y3]]
   set congested_region [get_tiles -of $clk_regions]
   highlight_objects -color cyan $congested_region
   

   This command assigns tiles to the congested_tiles variable and highlight all the tiles. You should see the following:
   
   
2. Next highlight the paths like you did previously using the following command:

   set start_cell [get_cells G_total_RAM_MULTS[1].ram_i/ram_name_reg_bram_0];
   ::dfv::trace_individual_paths $start_cell 20
   

   You can identify the following paths. Then within the paths, you can see the marked the paths that you are interested in.
   
   

   These paths have the following trait

   • They can travel through the congested areas.
   • They can travel southwards some distance that is at least one long line in length.
3. Next, identify the single hop dataflow paths that pass through the congested area that you highlighted previously. The -through, -from and -to switches of the get_dataflow_paths command only accepts cell objects. Hence, you need to identify the start and end cells.

   To identify the cells, firstly, you must identify the areas around the congested region that could have a start cell and an end cell. Once you have the areas, you can use Tcl to extract the cell information and generate some paths.

   Working on a clock region basis is the most convenient approach. Clock regions are defined around the congested area, determining the potential locations of the start cells and end cells of your dataflow path.

   Run the following Tcl command:

   set direction south
   set src_dest_clock_regions [::dfv::find_congested_clock_regions \
   $direction $congested_region 0]

   This command returns a list of two elements. The first element is a list of clock regions that represents where you look for the startpoint cell locations, and the second is a list of clock regions where you look for endpoint cell locations. In the above command, you have specified that the expansion is 0. This is observed at the following regions:
   
   
4. With this approach, some path‘s startpoints fall outside the Start Area and some endpoints fall outside the End Area. To capture these, you have to increase the expansion window. Run the following command, this expands the start and end areas by 1 clock region around the outside of each area:

   set src_dest_clock_regions [::dfv::find_congested_clock_regions \
   $direction $congested_region 1]

   
   
   This larger area now captures everything you are interested in.
5. Next, run the following command.

    ::dfv::get_all_paths_in_region $src_dest_clock_regions $direction 2 \
   $congested_region

   It does the following:
   1. Capture all the paths that start and end in the two areas
   2. Filter out paths that are less than one long line in south direction
   3. Filter out paths that are going in the wrong direction
   4. Filter out paths that do not pass through the congestion window
   5. Extends the start point by two hops and end point by two hops to make 5 hops in total
6. This will return a number of paths. Select the first path, it will look like the following:
   
   

   The expansion of the paths is two hops at each end. You have:

   hop1 → hop2 → congestion path → hop3 → hop4

   This allows you to see the cells that are before and after the congested path. When trying to resolve longer congestion, it is possible to take a longer divergence when you can incorporate more of the paths before and after the congested path.

7. Try repeating this analysis for the other paths and confirm that they pass through the congested region.
8. The next point is to extract the cells that would make up something that could be put in to a floorplan. Select all the five paths that were returned from the original congestion path.
   
   
   Then type the following Tcl:

   set cells_to_floorplan [filter [get_sel] {CLASS==cell}]

   At the end, you have a variable that contains all the cells that you are interested in. It is possible to follow some steps in the previous section to floorplan these cells to a new location.