Step 3: Generating Dataflow Paths - 2024.1 English

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

Document ID
UG938
Release Date
2024-06-12
Version
2024.1 English

This step explains how to generate dataflow paths. These are objects that contain paths with multiple cells.

  1. In the dataflow design, click Edit > Find. When the configuration box opens, change the find type to dataflow paths using the pull down menu.

  2. Click OK. This generates the top 100 paths in the design. It starts by identifying paths of which the depths are at the value of the -max_depth value, which defaults to 10. Depth can also be referred to as hops as each cell within the dataflow path is considered a hop. It returns a dataflow paths window that looks like the following:

  3. From the Tcl Console, you can find the syntax used to generate the dataflow paths.
    show_objects -name find_1 [get_dataflow_paths -filter \
    { STARTPOINT_REF_NAME =~ "*" } ]

    This is important as in the current version of Vivado the GUI options to generate dataflow paths are limited. It does not give access to the -to/-from/-through or any of the other options. Using the Tcl Console, passing the return of the dataflow paths command to the show_objects command allows you to display paths in the GUI.

  4. Now generate a more specific command. You can use the following as your base command:
    show_objects -name find_1 [get_dataflow_paths ]
    • Add a -from cell object: G_total_RAM_MULTS[1].mult_i/mult_out_reg
    • Add a -to cell object: G_total_RAM_MULTS[6].ram_i/ram_name_reg_bram_0
      Note: This command only works with leaf cells. You should not use hierarchical cells.
      Once finished, you should have a window returned that looks like the following:

      The -from, -through and -to can each take a list of cells. You can use the get_cells command to generate a list of cells and use it as an input for this command.

  5. Select the returned path. Next, open the Device window if it is not already open. When the parent design is placed, placement of the cells in the dataflow netlist is imported and can be observed in the device view when a dataflow path is selected. In addition, you can also see the direction of the path between the source and the destination as shown in the following figure:

  6. Next, right click on the dataflow path and select Mark. This shows that the path between the source and the destination is a brief step. This design routes around before going between the two locations. This exclusively displays the beginning and ending points of the route.
  7. For this simple design, the following technique works best. Type the following at the Tcl Console and then select all the returned paths
    show_objects  [get_dataflow_paths -max_depth 1]
    This command returns all paths of length 1 in the design. As the design is small, it is effective in showing the dataflow from cell to cell through the design.

    To achieve the same thing on a more complex design, you need to source a Tcl script. In the Lab file directory source the dfv_tutorial.tcl file. This sets up the DFV namespace. You can then type 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
    
  8. There are also some other useful switches on the get_dataflow_paths command. For example you can look at paths between different macros such as RAMs – DSPs. There are two ways to do this. One way is to look at specific REF_NAMEs and the other is to use the get_cells command and filter by the types that you are interested in.
    In this design, all the RAMs cells have a REF_NAME RAMB18E5_INT. All the DSPs have a REF_NAME DSP58. The command is therefore:
    show_objects [get_dataflow_paths -start_ref_name RAMB18E5_INT \
    -end_ref_name DSP58 -max_depth 1]
  9. Select all the returned paths. It should produce a device view that looks as the following:

    This sort of picture can be symptomatic of a module that has been reused a lot. Sometimes all cases might not be thought out and there is a stretching of the path. If you can identify a common module, you can design for the worst case scenario.

  10. The second way to do this is more powerful but requires a bit more coding. Here, using the get_cells command can achieve the same:
    set source_rams [get_cells -hier -filter {PRIMITIVE_GROUP==BLOCKRAM}]
    set dest_dsps [get_cells -hier -filter {PRIMITIVE_GROUP==ARITHMETIC}]
    show_objects [get_dataflow_paths -from $source_rams -to $dest_dsps \
    -max_depth 1]
    
    This produces the same result.