Step 5: Correlating Long Congestion with Dataflow Daths

Long congestion is the congestion of only the longer routes in the device which are fewer in number to the shorter routes. It is typically caused by two reasons:

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.
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.

Note:

The following is to illustrate how to get the congested tiles in a normal design. The tutorial design does not exhibit congestion.

When you run report design analysis, you are presented with a picture of the following

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

From here you can assign to a variable and switch to the dataflow design.

set congested_tiles [get_selected_objects]

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:
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.

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:
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.
Next, run the following command. It does the following:
```
 ::dfv::get_all_paths_in_region $src_dest_clock_regions $direction 2 \
$congested_region
```
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
```
::dfv::get_all_paths_in_region $src_dest_clock_regions $direction 2 \
$congested_region
```
  In addition to filtering out paths that you are not interested in, it takes a given path and expand it by two hops from the start and destination to provide you with a datapath that allows you to take a more holistic approach to floorplanning.
Select all the paths that are returned. It should look like the following:
The expansion of the paths is two hops at each end. You have:
hop1 → hop2 → congestion path → hop3 → hop4
This is a challenge to correlate. So for the first path, examine the start point cell. Run the individual path on this cell by running the following command:
```
set start_cell [get_cells G_total_RAM_MULTS[2].mult_i/mult_out_reg]
::dfv::trace_individual_paths $start_cell 5
```
Select the paths that are returned. It shows that this passes through the congested region:

Step 5: Correlating Long Congestion with Dataflow Daths - 2024.1 English

Vivado Design Suite Tutorial: Design Analysis and Closure Techniques (UG938)