Hi , I am trying to do the PNR for a small design and I get stuck at routing. I get this error :

[ERROR GRT-0118] Routing congestion too high. Check the congestion heatmap in the GUI.

or

Error: resizer_routing_timing.tcl, 39 GRT-0118

- How do I interpret the GUI view? It is really tight if I use

"PL_TARGET_DENSITY": 0.07 ,

and

FP_CORE_UTIL : 7

? Or what I need cover before

%run_routing

in the previous steps? All previous steps are ok, no error reported. I saw also some discussions on analog macros. I have also a SRAM which I just imported (lef, verilog, gds) , not generated from scratch . If I open the SRAM design separately in magic I do not get any DRC.

just remove following line from

config.json

and try with automatic macro placement and see

"MACRO_PLACEMENT_CFG": "dir::macro_placement.cfg",

•

MACRO_PLACEMENT_CFG": "dir::macro_placement.cfg",

- tried already, it places the macro on top-right corner and than I have 2 macro pins at the edge of the die (I considered that is not enough space to route wires to this pins •

"FP_SIZING": "absolute"

- was used also in combination with a 2000x2000 die aria and

"macro_placement.cfg"

because of the same reason stated above

add this line to config file

"PL_MACRO_HALO": "50 50,"

I suspect somehow the macro usage ... I ran now with alow congestion variable . O got trough the routing and in Magic if I opne the design and select the SRAM macro to extend it I do not see the content . I see just the pins and a layer (big blue ) named

obsli1   ( mem ).

Here you can see how the macro looks if I open the gds file.

https://github.com/MihaiHMO/VSDhdp/blob/59afb2b095851d36b5ee3115b56c88291b622091/VSDMemSoC/scripts/openlane_config.json this configuration works or not?

no, does not work

Do you “have to” flatten the RV on the wrapper? Cuz as far as I remember this is/was the worst idea possible (at least about yr ago).

What is the "wrapper" and what it do? I just learn now how to do the physical design flow in openlane for a hierarchical design . Vsdmemsoc was a "chosen" design. rvmyth core was a TLV design and converted to verilog .

When I was designing VSDMemSoC for the first time I tried to flatten the RVMYTH on the wrapper (think of it as the die area which has PDN, MACROs and etc… on it). Well it was impossible or very tough (at least in those days). So I tried to first harden the RVMYTH into a MACRO and then place it on the wrapper just like what you did with the SRAM.

So in your case the "Controller.v" is the wrapper ? I need to have a flow that make a

controller

macro? I need to modify the

vsdmemsoc,v

so containes directly the rvmyth module?

I guess your top module is VSDMemSoC? So you need to make macros out of everything else first. And put these macros into the wrapper (vsdmemsoc) just like what you did with the sram. Please note that in this method you must have NO standard cells in vsdmemsoc.v and you just instantiate other modules (macros) in it. Also please note that I am not preventing you from using the flattening method but I think it is fairly hard to implement the final design with this technique.

OK, I will try . although I think that if there would be a problem with wrapper approach I would have problems also before routing... maybe CTS or placement.

Wrapper approach?! You mean flattening the design on the wrapper? Maybe you are right. BTW there are actually 3 methods to implement your design on the wrapper: 1. Fully-flattened 2. Fully-macros 3. Hybrid (macros + standard cells) You are doing the third one right now. https://caravel-user-project.readthedocs.io/en/latest/#hardening-the-user-project-using-openlane

Ok, and I fi change now the vsdmemsoc to , should be option 1 ?

This is option 3 (stdcell + macro). Due to existence of sram option 1 is impossible in your case. You can not flatten a sram (custom layout).

So... , I think I hardened the "controller " part from vsdmemsoc . I have now a controller verilog, lib, lef, gds, . I added also vsdmemsoc layout . Same error...GRT-0118... congestion durin Running Global Routing Resizer .

in the second screenshot it shows setup violation error. where is GRT congestion error?

This is the report just for

controller

module. To show that I have a valid design from the lef, lib point of view. And I put also the placement to see that there is plenty of space for the

vsdmemsoc

design. GRT is not sown , but is there.

A Hierarchy-aware Macro placer is going to be the future

Ok, for me is not so clear what is actually hierarchy, because I see 2 modules : cntrl , it is not hardened and mem. is hardened macro. My undersatnding is if I use

"VERILOG_FILES_BLACKBOX"

the flow will ignore the implementation of this. So why just routing does not work. (till now :)) ?

https://github.com/The-OpenROAD-Project/OpenLane/issues file issue here with test case. Will let you know what is causing congestion issue