Routing Congestion Heatmap Not Populated with Data

[ellen-wood]

We are making a mixed signal project for an upcoming ChipIgnite.

We hand-drew a large analog GDS file, comprising multiple cells of different devices. We then imported a macro of GDS generated from a separate, purely digital Openlane hardening. We called this final top level GDS 'final_mixed_signal_top' and instantiated it within Caravel_user_project.

We then ran make user_project_wrapper to run Openlane and harden our design. It fails at Step 10 (Global Routing) and requests we analyse the Heatmap in the GUI. However, when we open the .ODB file from the /runs directory in the GUI, (File > Open DB) we get an Error message saying that the Routine Congestion Heatmap is not populated with Data.

[maliberty]

Please attach the test case.

[ellen-wood]

issue_reproducible.tar.gz

Is this correct?

[maliberty]

That allows me to reproduce your routing congestion issue. I'm not sure how it relates to the title of this issue though. The input db will be from before grt is run.

[maliberty]

Your LEF abstract is too detailed. You should bring the pins out to the edges and create a simple OBS to cover the block.

[RTimothyEdwards]

@ellen-wood : If you used magic to create the LEF, then use lef write -hide to make sure that the interior of the macro is just a stack of obstruction blocks. If the project is placed in the user project wrapper cell, then all the pins will be on the boundary. Please use the most recent version of magic where I implemented a workaround for the excessively long processing time of lef write on large designs (magic version 8.3.403 or newer). With that version, you should specify power nets with the command lef nocheck vccd1 vssd1 vccd2 vssd2 vdda1 vdda2 vssa1 vssa2 vccd vssd so that lef write doesn't try to trace all the power nets to find the poly and diffusion antenna areas. Run lef nocheck before running lef write -hide.

[RTimothyEdwards]

If the macro does not completely fill the wrapper, then as Matt said, make sure that all the pins are on the perimeter of the macro layout, so that they don't end up completely surrounded by obstruction and therefore become unroutable.

[ellen-wood]

@maliberty I tried to upload the .ODB file, but it says that file type is unsupported here. I hadn't realised the file was generated before grt was fun. I can share the repo tomorrow, if that would help? I would share today however I am troubleshooting some issues with Git. (Still relatively new to all of this)

@RTimothyEdwards yes it was generated in Magic, I will try your suggestions and run it again. Does OBS mean obstruction block?

[ellen-wood]

In your tutorial video on the OpenRoad GUI Matt, you already have some designs loaded in, in order to demonstrate the functions of the GUI, and the Routing Congestion heatmap is populated with Data. Can I ask what files you have loaded in order to view this? When I opened the GUI (using openroad -gui command) I then clicked File > Open DB. It was looking for .ODB files, so I imported the .ODB generated in my latest Openlane /runs directory. Which is what yielded the following message:

[maliberty]

The database has to be saved after grt is run to have congestion information (or you have to be in the GUI when you run grt). I think it is more of an OL question about how to get it to save the information.

Note also that grt has a -congestion_report_file option to dump out congestion markers. OL should add that option. @kareefardi @donn

[ellen-wood]

Hi @maliberty , that makes sense, thank you for explaining. Just to clarify grt means global routing timing optimisation? I have been assuming so but just want to double check.

As you have suggested, it seems there is greater analytic possibility by running openlane step-by-step, interactively, or running grt in the GUI as you suggest. However, as per the caravel_user_project instructions, we run the command make user_project_wrapper on our design to harden in the context of caravel. This runs a makefile which starts OL flow automatically. So it seems its not possible to use the GUI or interactive mode on the Caravel builds?

https://caravel-user-project.readthedocs.io/en/latest/index.html#hardening-the-user-project-using-openlane

[maliberty]

yes grt = global routing

I'll leave it to the OL (OpenLane) team to comment on how to enable more debugging in the flow.

[ellen-wood]

Vijayan helped with the solution to this. Putting it here in case its useful for anyone else.

As the .ODB file doesn't get populated with heatmap data unless routing completes, you can't load this into the GUI to inspect the results after the flow fails. Instead you have to inspect the results separately with Openroad:

Go to link: https://github.com/Precision-Innovations/OpenROAD/releases

Download openroad for your operating system: openroad_2.0_amd64-ubuntu20.04.deb in my case

Go to download location and run command sudo apt install ./openroad_2.0_amd64-ubuntu20.04.deb

Go to issue_reproducible directory for the run which failed to build due to congestion

Then run the following commands one by one

openroad
source run.tcl
gui::show

Now the heatmap is populated

[kareefardi]

The routing congestion error is fixed in OpenROAD and it will propagate to OpenLane soon. As for the heatmap and -congestion_report_file these are also addressed in newer versions of OpenLane