Failing to run globalroute for MegaBoom on Nangate45.

[sakundu]

Description

For one of our projects, we used OpenROAD and ran P&R for MegaBoom on Nangate45. We found that even after reducing the floorplan utilization to 20%, OpenROAD fails to run global routing. We have updated the fastroute.tcl file to allow more routing resources than the default. It would be good if you could suggest some solutions or enhance your global route engine to fix the problem.

We have uploaded the CTS, DEF, Verilog, and SDC files that were the input to the global route stage. We use the default Nangate 45 lef and lib available in the ORFS GitHub.

Please let us know if you have any suggestions to fix the problem, and if you need any more information to debug it further.

Thanks,
Sayak

Suggested Solution

No response

Additional Context

No response

[stefanottili]

Using the macro.mod.lef to get the TAP cell to load def and then display the RUDY routeablilty heat map ..

OpenROAD-flow-scripts/flow/platforms/nangate45/lef/NangateOpenCellLibrary.tech.lef
OpenROAD-flow-scripts/flow/platforms/nangate45/lef/NangateOpenCellLibrary.macro.mod.lef

This doesn't look like a GRT problem at all, this looks like GIGO, a bad netlist being unplaceable.
Querying the instances in the dark middle of the chip shows "regfile" as instance names.

Just synthesizing the abstract description of the "regfile" will not get you a placeable netlist.

Maybe physical synthesis tools got better over the last couple of years, but a regular structure like a regfile will at the very least need careful attention to the structure of the muxes and very likely some data path placement.
You'll have to isolate the muxes in separate RTL hierarchy and script the placement of the sequential elements.

[gadfort]

I've seen this behavior a few times before when I synthesized a register file. I noticed that during global placement the register file would get to densities much greater than requested (90+%, even when the density requirement is set to 40%). The commercial tools struggle with this too, but the placement density they achieve is usually around 70%.

I would suggest taking a look at the global placement step maybe try turning off routabilty driven placement since that appears to be when the density climbs up.

[oharboe]

@sakundu Have you considered looking at https://github.com/The-OpenROAD-Project/megaboom ?

The register files and SRAMs will probably have to be crafted in some way that is outside the scope of OpenROAD and then provided to OpenROAD as macros.

What I do w.r.t. register files and SRAMs is that I "mock" them, which you can read more about in https://github.com/The-OpenROAD-Project/megaboom.

Basically, I create a macro that is an area and timing representation of the register file (to be provided by some non-OpenROAD means later), which allows me to run the rest of the design through OpenROAD to look for issues.

Since nangate45 isn't a production process anyway, perhaps you don't need anything more than mock register files and srams?

[QuantamHD]

https://github.com/bespoke-silicon-group/bsg_fakeram

Is a good place to start if you're trying to generate rams

[maliberty]

https://github.com/jjcherry56/bsg_fakeram might be better

[oharboe]

https://github.com/bespoke-silicon-group/bsg_fakeram

Is a good place to start if you're trying to generate rams

This wont work for Megaboom to create e.g. the registerfiles and many other SRAMs because there is a mismatch between the module interface and what these tools produce.

As a start, I recommend mocking these modules as described in the megaboom repository.

Mocking is much more general and can also handle cases such as mocking multipliers, barrel shifters, reorderbuffers or really anything.

[QuantamHD]

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.

Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

[oharboe]

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.

Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

Indeed... mocking is a stop gap useful in early iterations of setting up a flow. You can explore what the problems the design runs into with an close zero latency SRAM and maybe tinker a bit with the verilog.to.mock something closer to realistic. Area can also be mocked(smaller and bigger). However, mocking will not give you any insights into what constitutes realistic latency and area...

Though for Megaboom on nangate45 as a starting proposition, I dont think physical realism is being studied, would be my guess...

[oharboe]

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.

Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

If you do want to target a real PDK, then the starting point is not the currently generated Verilog, but Chipyard. Chipyard can be fed the available SRAMs and then it will generate the bridging logic to connect Megaboom to avaialable SRAMs. This is called Barstools. I am not familiar with it...