High congestion - asap7 . Many OA and AO combinational cells in the congestion areas.

[Mudbhatkal]

I'm seeing high congestion at global place for a design using asap7 libraries on Openroad. I tried using cell padding with 8 cell sites on the left and right. It helped reduce the congestion a bit, but not enough. I have set a max fanout and tightened the max capacitance in addition to the previous changes, and congestion is still there. I also changed the flow to congestion-driven instead of timing-driven and used the routability check overflow option but still see the congestion although it has decreased slightly. Any suggestions? 

[maliberty]

Can you provide a test case or at least some images of the problem?

[Mudbhatkal]

The RTL was generated through OpenASIP
By testcase do you mean odb file ? If not, how do I generate one ?

The image shows estimated congestion and is captured after detailed placement.

[rovinski]

What does the placement density map look like for comparison?

[Mudbhatkal]

It looks ok.

[maliberty]

A test case is needed to go further

[maliberty]

make global_place_issue should package the test case. Do not post if you are using any confidential data.

[Mudbhatkal]

Here is the testcase : https://tuni-my.sharepoint.com/:u:/g/personal/pooja_mudbhatkal_tuni_fi/EVDGc1VOxIZNhEfmDVLf1JcB56kh2ipprLFusncKTGhAWA?e=NnEMJh
Please let me know if you have access issues

[gudeh]

Hi @Mudbhatkal, aren't you using a config.mk file for your design?

[Mudbhatkal]

Yes, I am

[Mudbhatkal]

config.zip

[maliberty]

This design does have an very unusual distribution of cell types. I think you will need to enlarge the block and lower the placement density to compensate for it.

@gudeh this could be an interesting case to test your routability improvements on.

[gudeh]

You can set the derating with this TCL command: set_global_routing_layer_adjustment.

I use it like this: set_global_routing_layer_adjustment $env(MIN_ROUTING_LAYER)-$env(MAX_ROUTING_LAYER) 0.
At: flow/scripts/global_route.tcl and flow/scripts/global_place.tcl after the existing setting by the script, so it gets overridden.

[Mudbhatkal]

@gudeh , the congestion has decreased a bit . The run errors in cts final with : [ERROR GRT-0044] set_global_routing_layer_adjustment requires layer and adj arguments.
Error: global_route.tcl, 17 GRT-0044
Command exited with non-zero status 1
Elapsed time: 0:02.65[h:]min:sec. CPU time: user 2.47 sys 0.17 (99%). Peak memory: 325700KB.
make[1]: *** [Makefile:749: do-5_1_grt] Error 1
make: *** [Makefile:749: results/asap7/tta0/base/5_1_grt.odb] Error 2

[gudeh]

From the error message it seems you missed the layer and derating value parameters, try to use it like this: set_global_routing_layer_adjustment $env(MIN_ROUTING_LAYER)-$env(MAX_ROUTING_LAYER) 0

[Mudbhatkal]

Hmm I had made the changes . It was 0.5 in the files and I changed it to 0. Now re running by adding the line after the 0.5 setting.

[gudeh]

The standard derating values will vary depending on the design, the PDK, and the metal layers.

[maliberty]

Btw, what sort of block is this?

[Mudbhatkal]

It's a VLIW ASIP processor core

[gudeh]

Hi @Mudbhatkal, I noticed from the log files in the make issue you uploaded that you used yosys version 0.33. Have you tried other Yosys versions? ORFS is currently using 0.38 from a recent update. If you have a local installation of ORFS you can use the 'build_openroad.sh' script. I usually use the following: ./build_openroad.sh --local.

Maybe this would provide a different set of logic gates and a different routing scenario. For some reason I was not able to run Yosys on my end with your files.

[Mudbhatkal]

I ran the build command. Still seeing congestion issues

[gudeh]

You can check on the yosys log file for the yosys version, search for the keyword: yosys 0.

[Mudbhatkal]

Ahh it hasnt got updated even after running the build command. Will check. Thanks

[gudeh]

You might be missing a make clean_all, before re-running the design.

[phsauter]

To add a bit to this, Yosys-0.34 and earlier had a pretty significant issue in the way it elaborated and synthesized part-selects like array[i*33+:33], especially if the step-size was not a power-of-2.
This was addressed by improving peepopt in Yosys-0.35 (shiftmul pattern) and in Yosys-0.36 (shiftadd pattern).

So for example our scoreboard (in the issue stage of a CPU for simple out-of-order execution) has a lot of registers and a lot of MUXing involving them, which I assume is also the case for your VLIW core. Before this fix it was about 5-7 times larger than we expected it to be. Using Yosys-0.36 or newer it is still a bit bigger than what we would expect but we are talking 20-70%, not multiple times larger.

[maliberty]

Have you tried lowering PLACE_DENSITY as I suggested earlier?

[gudeh]

Lowering the placement density seemed to help indeed. You can add the following to your config.mk design file:

export PLACE_DENSITY = 0.40

The cell padding also has some influence on the placement density and the routing congestion. You can also try to modify the values in the design config.mk like the following:

export CELL_PAD_IN_SITES_GLOBAL_PLACEMENT = 4
export CELL_PAD_IN_SITES_DETAIL_PLACEMENT = 4

[Mudbhatkal]

Before posting this issue, I tried with 4 (global) and 8(detail) and anything beyond that didnt work. I had also tried with place density as 0.2 . Iwill try it now with derate set to 0.

[stefanottili]

vliw cores I’ve seen in the past had wide and deep muxes around the registers. If these are not isolated in a separate rtl hierarchy, synthesis tools tend to ignore mux levels and generate ao/oa spagetti netlists that no R&R tool can untangle.
Physical synthesis tools are supposed to be able to give you a better netlist, but since yosys isn’t one of them, you’ll have to rewrite the rtl of the muxes to get a P&R friendly netlist.
Put each mux level in a separate rtl hierarchy and make sure that synthesis doesn’t flatten them. Separate enables per level of muxing. You should be able to identify mux structures in your netlist.
P&R tools are usually bad at visualizing cone connectivity, but OR has timing critically color coded cone viewing as part of the timing debug. Use it after placement to look at your muxes.

[Mudbhatkal]

big_tta_fixed.zip
This RTL has some fixes but I still see congestion issues. Also tried with synth_hierarchial set to 1. Attaching it here in case someone finds it useful.

[gudeh]

Hi @Mudbhatkal, I am sorry I was not able to have a look at the flow with your new RTL yet. Have you seen @phsauter 's comment on yosys version? It seems you were not able to update it previously. May I suggest you to try and cd to the yosys folder and manually update it, you can try to git checkout master and git pull? You can also try to use the --clean option from the build_openroad.sh script. When I am facing too much trouble updating the tools I usually download the whole ORFS from scratch and build again.

[phsauter]

I don't know how you would do this in ORFS/OpenLane but our solution for some modules showing high congestion (180% and more) was to use -routability_driven in global_placement and then tune the parameters here until we got good results.

Specifically I had to increase -routability_check_overflow (which I think basically determines how early OR will use routability-driven, closer to 1 being earlier).
And then we also changed -routability_max_inflation_ratio and routability_max_inflation_iter so it didn't inflate the problematic areas too much.
In my experience this gives better results than increasing cell padding values.

So you might want to play around with them as well. This probably doesn't help you very much since we have different designs but currently I have:

-routability_check_overflow 0.4
-routability_inflation_ratio_coef 1.5
-routability_max_inflation_ratio 1.5
-routability_max_inflation_iter 4