How to get heatmap data?

[gudeh]

Hi guys, congratulations on all the great job done with the OpenROAD project!! I want to use it to develop my ideas during my Ph.D.

I am trying to build a dataset for graph neural network training. My idea is to perform physical design predictions with a mapped circuit before P&R. I am trying to extract features from Verilog with Yosys, send them to the DGL python library and perform training with DGL. These steps are already operational, but I am missing an essential aspect of the prediction: the label!

To solve the mentioned issue I would like to have the data shown by the heatmaps in the GUI, such as placement density and routing congestion. I would like them not as images but the actual numeric values. The positions of the cells and wires would also be essential.

• Can anyone point me to which path I should go to get this data? I understand all of it is already processed by the code to show the images in the GUI. I just need to find it.
• Would there be any TCL command which could help me with that?
• Or my best shot is to try and use the odb database and edit some code?

I noticed there are some heatmap codes in ./src/gui/src, but there are so many attributes and methods. Also, I am not used to the odb database yet. Any help is welcome.

[gudeh]

By the way I couldn't find the path ./build/src/swig/tcl/opendbtcl and ./build/src/swig/tcl/opendb_wrapper.cpp as mentioned in the documentation.

[maliberty]

The bit of documentation is out of date as we now include the tcl functionality in openroad itself and no longer build standalone executables for odb. (@vvbandeira)

@arlpetergadfort My first thought was to look at each engine but maybe it would be easier to provide a dump_heatmap command in the GUI since it has already abstracted the interface to each engine. Does that seem reasonable to you?

[gadfort]

@maliberty That seems reasonable, as long as the GUI is active, dump_heatmap can dump the raw data to a file, should be easy. CSV or JSON?

[maliberty]

@arlpetergadfort do you actually need it to be active to query the data sources? It is ok if it is required but I'm curious why. I have no strong feeling on the format but would opt for CSV as you can also load it into a spreadsheet easily

[gadfort]

@maliberty The heatmaps would need a little reworking to further separate them from the GUI, but i agree there really is no need for the GUI in this instance, but that will have to changed another time.
#1612

[gadfort]

Command is gui::dump_heatmap name filepath

[maliberty]

#1612 is merged so you should be good to go.

[gudeh]

Hi! Thanks a lot for such a quick response. Definitely I wasn't expecting for such a convenient solution.
With the new dump_heatmap command I can get the heatmap of the bounding boxes in CSV format, this is awesome! I have two questions:

1. How are the bound boxes sizes defined? Will they always have the same sizes independent of the technology? I suppose they might depend on the die and core area.
2. How can I tell which logic gate is in each bounding box? My best shot is to inspect the DEF file versus the dump_heatmap myself, the integer values only seem to be on different scale. Or is there any other easier way to define where each logic gate is? maybe with ODB, or an openroad command?

[maliberty]

1. The heatmap source itself will determine the box size. For global routing I know it is 15 pitches of M3 by default though I'm not sure for the others without digging a bit. @arlpetergadfort do you happen to know the others?

2. You can use the odb tcl commands to get at that type of data. As a hint:

set block [ord::get_db_block]
foreach inst [$block getInsts] { 
  set box [$inst getBBox] 
  puts "[$inst getName] [$box xMin] [$box yMin] [$box xMax] [$box yMax]" 
}

[gadfort]

The bounding box size is in um, for the global routing it is fixed, but the others can be changed using gui::set_heatmap command and modifying the GridX and GridY options. They will default to 10um by 10um if not set.

Also, I would amend @maliberty odb tcl a little by doing:

set block [ord::get_db_block]
foreach inst [$block getInsts] { 
  set box [$inst getBBox] 
  puts "[$inst getName] [ord::dbu_to_microns [$box xMin]] [ord::dbu_to_microns [$box yMin]] [ord::dbu_to_microns [$box xMax]] [ord::dbu_to_microns [$box yMax]]" 
}

That way you will get the bounding box in microns which matches the units for the heatmap CSV.

[gudeh]

Hi @arlpetergadfort and @maliberty, thanks a lot for your help you guys are amazing! I have almost everything I need for labeling the logic gates!! I have the heatmap for the block with gui::dump_heatmap and the gates locations with your provided TCL snippet.

I have made a new .tcl where I modified the make gui_final TCL in /flow/scripts/gui.tcl where I added your provided TCL snippet (lines 49 to 58). And I edited the /flow/Makefile to provide a new command make my_gui. I beleive I didn't edit the Makefile as supposed (I am getting some "overriding recipe for target..." warnings). But either way I am able to get the data I need. Feel free to point me out the proper way to edit the code with new TCL commands.

There is something I didn't understand, the values don't seem to relate from the two CSV's I am getting. What exactly is the TCL snippet providing? Shouldn't it be the position of the bounding box each cell belongs to? Or is it simply the cell's position? It would be better for me if I had the position of the bbox each cell belongs to, this way I can label each cell to the heat provided by the bbox it is inside. If there isn't a quick modification to TCL snippet available I can do it myself in Python

[maliberty]

You are repeating the previous rule and probably want something like:

my_gui: my_gui_6_final.def
$(foreach file,$(RESULTS_DEF),my_gui_$(file)): my_gui_%:

You are getting the bbox of each instance. You'll have to map that back to the grid you are working with (an instance may be across a boundary as well).

[gudeh]

Hey guys, I have some issues with the heatmap features. I noticed that running the GCD project from a fresh OpenROAD-flow with this exact sequence of commands:

git clone --recursive https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts.git
cd OpenROAD-flow-scripts/
sudo ./build_openroad.sh --local
cd flow
make
make gui_final

Renders no output on the circuit's image when clicking on the checkbox for Placement Density. The Power Density checkbox works fine. Furthermore, clicking on Routing Congestion and IR Drop gives the error message bellow and shows no heatmap in the image.

[WARNING GUI-0066] Heat map "Routing Congestion" has not been populated with data.
[WARNING GUI-0066] Heat map "IR Drop" has not been populated with data.

If I run the AES project I can see the Placement and Power heatmaps. Although I have the same errors with Routing and IR Drop.

The Routing and IR Drop also gives errors when trying to call gui::dump_heatmap: [ERROR GUI-0072] "Routing Congestion" is not populated with data.
I also noticed that the CSVs provided by the gui::dump_heatmap command gives bouding boxes with different sizes for Placement and Power, is this expected?

[gudeh]

Routing congestion only exists at the end of grt or if you reload the guides with read_guides. There is no place to store it in DEF. I assume ir_drop is similar with analyze_power_grid being required.
@arlpetergadfort any thoughts on the bbox differences?

The only reason the bbox would be different is if they are specified differently. You may want to check their settings in the gui to ensure both are the same size.

I was wrong about bboxes having different sizes. What actually happens is that Placement seems to ignore (most of) the ones with heat value 0, while Power shows all the ones with heat value 0. This reflects CSVs with different number of lines. Not a problem!

[gudeh]

Hello there! It seems OpenROAD changed its way of reloading a design run. As far as I could understand, it was changed from DEF to ODB files. I noticed the heatmap values changed again. Now if I use read_guides before dumping the heatmaps I get different values than with a simple make gui_final. When I read the guides I get lower heat values, I wonder what would be the proper way to do this. It seems that ODB now has more information than previously with DEF and there is no more need for read_guides before calling gui::dump_heatmap, am I correct?

[maliberty]

In detailed routing we run with -save_guide_updates which will update the guides. You could see some difference in results as a result. I guess it depends on what your goal is. If you want the pure grt result then you can make gui_5_1_grt.odb (which should match loading the guides).

[QuantamHD]

@maliberty I feel like we should add a warning to read_guides to let people know it's not the ideal way of doing things.

[maliberty]

@QuantamHD I await your PR

[maliberty]

I don't see any issue with placement density. This is gcd/ng45:

[gudeh]

Oh! That was my mistake, the minimun value here was set to 50%, with 0% the heatmap shows up. Thanks a lot for the clarification!!!

[maliberty]

@arlpetergadfort I'm seeing:

>>> read_guides results/nangate45/gcd/base/route.guide
[WARNING GUI-0066] Heat map "Routing Congestion" has not been populated with data.

This used to work - do you know what has changed?

[maliberty]

The read_guides issue was fixed a while back but I don't see that mentioned here.

[gudeh]

What was happening with read_guides was that it was required for populating the heatmap for Routing, and it is working properly. What I tried to say is that running global_route also populates the heatmap for Routing, although this two commands provide heatmaps with different density values, not a problem. Although, neither of them are mentioned in the documentation on the GUI.

IRDrop working fine after analyze_power_grid -net VDD also!

Thanks a lot guys!!

[gudeh]

This is the result I got with read_guides ./results/nangate45/gcd/base/route.guide:

And this is with global_route:

[maliberty]

@eder-matheus are you aware of this difference / do you need a test case?

[eder-matheus]

@maliberty @gudeh A testcase would be good, but I think I know why do you see this difference. In our flow, we define the routing layers available during the global routing (e.g., set_routing_layers -signal met1-met5 -clock met3-met5) and we also apply the adjustments on the routing layers (e.g., set_global_routing_layer_adjustment * 0.5). The guide doesn't store this information, so you have to set the same layer range and adjustments before reading the guides to get the same congestion map from the global_route command.

[gudeh]

Hi again! I am progressing with my dataset generation. Looking real promising. I am only having issues trying to close the gui. Even if I use gui::hide it goes to the openroad> command option in terminal. How can I exit it the gui AND the openroad afterwards via a TCL file? This is what I have tried. As seen in the last lines.

By the way if you uncoment the part where I try to use the Routing and IRdrop heatmaps the gui::hide doesn't work.

[gadfort]

You don't need gui::hide unless you want to get to the command line. You can just exit directly from the gui.

[gudeh]

If I don't exit the GUI my flow execution gets stuck. I perform some processes after running the gui::dump_heatmap and repeat for multiple designs. I would like to be able to exit the GUI from the TCL file. This way I can run multiple designs without having to manually exit the GUI.

[maliberty]

@arlpetergadfort if I have a script consisting of just 'exit' and I run openroad -gui <script> it doesn't exit. If I type it into the gui tcl prompt it does exit. Do you know why the script version doesn't work?

[gadfort]

@maliberty I think thats a bug, it should work. I'll need to take a look at it. My best guess is that the exit is captured by Qt, which is is supposed to do, but then the GUI is still requested to open, which basically negates the exit.

[gadfort]

Should be fix here: #1645

[gudeh]

[maliberty]

Show DBU switches between DBU and microns, not display versus no display.

[gudeh]

Hi everyone! I am coming back to this project. I was focusing on other tasks the last months.

I wanted to share with you an example of what my code is able to generate by editing Yosys and OpenROAD: https://drive.google.com/drive/folders/1xTz4iTuGx0bDD-ZWAOV-MDQWKI0a8XA8?usp=sharing .

This pair of CSV files can be used as input for DGL Python library and create a GNN.

There is an issue though, I created a Python script to check for collisions among the heatmaps and logic gate locations, and it is really slow. I made it by comparing the location of all the gates against each of the 4 heat types. I would like to ask any suggestions on how to improve this. Is this able to be solved on the OpenROAD db?

[maliberty]

The link to your script is broken. The heatmaps are a grid so it should be easy to compute the index into the map.

Matt

[gudeh]

Hello again! I found a bug on my code to retrieve learning data using OpenROAD. The logic gate names don't match!

My machine learning model features come from the verilog generated during the flow. Optionally I can use the 1_1_yosys.v ( post tech map ) or the 6_final.v ( post route ). Afterwards I get the labels using some TCL commands discussed previously in this post. For example:

set dut gatesPosition_
set fileName ${designPath}/${dut}${::env(DESIGN_NAME)}.csv
set outFile [open $fileName w]
puts $outFile "Name,xMin,yMin,xMax,yMax"
set block [ord::get_db_block]
foreach inst [$block getInsts] {
set box [$inst getBBox]
puts $outFile "[$inst getName], [ord::dbu_to_microns [$box xMin]], [ord::dbu_to_microns [$box yMin]], [ord::dbu_to_microns [$box xMax]], [ord::dbu_to_microns [$box yMax]]"
}
close $outFile

At last, I have to build up my dataset by matching the logic gates names from the verilog, the logic gate names(from the TCL snippet pasted here and the heatmap dumps (positions). But there is a problem:

I noticed that sometimes the flow changes the names of the gates between the verilog and the names retrieved from the TCL command ( [$inst getName]) causing unexpected behavior when I build the dataset. For example, the design bp_be_top with nangate45, there is a gate called \be_calculator/_09864_ in the 6_final.v, and the name I get with the TCL command is be_calculator/_09864_ without the \.

My question is: Is there anyway to be sure that OR flow won't change the names of the gates? If not when and how does the tool changes the names of the gates, does it simply remove the starting \ or are there any other possible modifications?

[maliberty]

Names are a bane for EDA tools. Most likely dropping the leading slash will work unless you have very complex names.

[gudeh]

Hi guys, I have another doubt regarding the heatmaps provided by OR. I would like to make sure the behavior is as intended. This is the routing congestion heatmap when executing the Rocket Tile design with standard values (config.mk) given by the repository:

After executing the flow, OR inserts a lot of Filler Cells. It seems that the standard core size for Rocket Tile is extremely large, is there a reason for that?

I ran the flow with the same design, although dividing the max X and max Y core area values in half and leaving the die area as is:

export DIE_AREA = 0 0 924.92 799.4
#export CORE_AREA = 10.07 9.8 914.85 789.6
export CORE_AREA = 10.07 9.8 457.425 394.8

And this is the routing congestion heatmap after execution. There is still a considerably high congestion between core and die:

To confirm, this is the placement density after the same run:

This seems strange to me. I wouldn't expect so much routing congestion between die and core area. Furthermore, I couldn't even see metal wires on the green congested area. Is this as supposed to?

[maliberty]

ng45 tinyRocket

[maliberty]

Its only run on that one pdk. It appears to go back to Tutu The-OpenROAD-Project/OpenROAD-flow-scripts@3ed9ff4

[maliberty]

even further back The-OpenROAD-Project/OpenROAD-flow-scripts@6f005dc

[maliberty]

actually we do run it on some private pdks but you would expect them to be smaller not larger

[rovinski]

Ok then who knows 🤷‍♂️. Should be fine to reduce the area. Will probably help runtime.

[gudeh]

Hello again. I wonder if there is a way to get the heatmaps considering only certain metal layers, is that possible?

[maliberty]

All of the underlined items support configuration through a double click to bring up the dialog. You can then choose the layer, eg

[gudeh]

Alright. What about the gui::dump_heatmap, is it possible to get only some layers with it? I would like to select multiple layers simultaneously, is that possible?

[maliberty]

@gadfort is there a tcl command for changing these options?

[gadfort]

gui::set_heatmap gives you access to those settings including the layer