Does Openroad make a trial routing when placing a design ?

[TEEkohl]

I have layouted a design with appr. 32000 gates and can achieve a placement density of only 29% after CTS, else the router will fail due to congestions. I made the layout twice, once with Openroad and once with another P&R tool and compared the total routing length:

Other P&R Openroad
-----------------------------------------------
Metal1 0um 0um
Metal2 363,237um 1,414,352um ( 690,150um)
Metal3 392,971um 2,614,102um ( 746,645um)
Metal4 554,437um 544,897um (1,053,430um)
Metal5 260,327um 1,181,199um ( 494,697um)

Via1 92,376 107,652
Via2 84,940 148,623
Via3 21,446 37,950
Via4 7,662 20,292

Even if I take into account that the core area required by Openroad is 1.9x as large in width and height (= 3.61x the area, keeping the same aspect ratio), which will make all routes longer, the total routing length should not exceed the values set in parenthesis. But with the exception of Metal4 they are clearly beyond. This leads me to the assumption that the placement result is poor.
Are there any means to improve the placement ?

[maliberty]

There is very little information here to go on. The global placer with -routability_driven will consider routing congestion. Are you using ORFS? Is this a PDK you brought up yourself or a public one?

[TEEkohl]

I am using the Openroad flow scripts. Both environment variables GPL_ROUTABILITY_DRIVEN and GPL_TIMING_DRIVEN are set (by default), thus the option -routability_driven is enabled. The PDK is the IHP OpenPDK.

[maliberty]

Can you share the design?

[oharboe]

@TEEkohl OpenROAD has come an enormously long way since I started using it. Recently(in the last year or so), I find that routability problems point to a real problem in the RTL (Verilog). Occasionally there are some edge cases that OpenROAD is struggling with that merits further investigation, and even a bug sometimes, but in that case, a reproducible test case with the exact circumstances is needed to comment.

Most often someone with years and years of backend experience looks at whatever testcase I have and after two minutes say: your problem is X. :-) Mostly the solution is in fixing the RTL.

[TEEkohl]

I still have to clarify what we can share. Meanwhile I have two more questions, which might help to debug my problem.

1. If I am using a 3rd-party-tool for synthesis and put the result into
   .../results/ihp-sg13g2/OpenPDK/$(DESIGN_NAME)/$(FLOW_VARIANT)/1_synth.v resp. 1_synth.sdc
   and start the layout with 'make floorplan', Openroad-flow-scripts retriggers the Yosys synthesis, not accepting my netlist. Only if a use 'make do-floorplan', which presumably skips some dependency checks, it continues with the floorplan. What is causing this behavior ?
2. What is the purpose of 1_synth.rtlil file which is also generated by Yosys ?

[oharboe]

tir. 26. aug. 2025, 08:59 skrev TEEkohl ***@***.***>:

I still have to clarify what we can share. Meanwhile I have two more questions, which might help to debug my problem. 1. If I am using a 3rd-party-tool for synthesis and put the result into .../results/ihp-sg13g2/OpenPDK/$(DESIGN_NAME)/$(FLOW_VARIANT)/1_synth.v resp. 1_synth.sdc and start the layout with 'make floorplan', Openroad-flow-scripts retriggers the Yosys synthesis, not accepting my netlist. Only if a use 'make do-floorplan', which presumably skips some dependency checks, it continues with the floorplan. What is causing this behavior ?

The cause are the time and date of detailed dependencies and make. Using do-floorplan is the correct solution, this uses the ORFS scripts and stages and you can replace outputs like you do. You could consider bazel-orfs to create a flow too, where using alternative synthesis tools is supported.

1. What is the purpose of 1_synth.rtlil file which is also generated by Yosys ?

This is a yosys specific internal language independent representation of the rtl. Also, any unused RTL/modules is stripped from this file, the input is canoncalized (a single representation of multiple equivalent). This is particularly useful for bazel that uses content hashes, not file dates for dependencies. For ORFS and make, it creates a clear separation of parsing input languages(verilog, systemverilog) and synthesis.

…

— Reply to this email directly, view it on GitHub <#8094 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVLJZS7VAVZ3WOHBWR6TSD3PQHV5AVCNFSM6AAAAACER4OK2WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRRHA2TSNI> . You are receiving this because you commented.Message ID: <The-OpenROAD-Project/OpenROAD/repo-discussions/8094/comments/14218595@ github.com>

-- *CONFIDENTIALITY NOTICE* -- This email is intended only for the person(s) named in the message header. Unless otherwise indicated, it contains information that is confidential, privileged and/or exempt from disclosure without written approval by Ascenium Inc.

[TEEkohl]

Attached you'll find a simpler, smaller design, but which shows the same tendency, that the required chip area is about 1.7x as large compared with a 3rd party tool (Factor 1.3x in height and width, keeping the same aspect ratio). Again I compared the total routing length.

3rd party tool Openroad Factor
--------------------------------------------
Metal1 1um 0um
Metal2 50,370um 228,683um 4.54
Metal3 95,914um 168,147um 1.75
Metal4 61,121um 165,504um 2.71
Metal5 81,504um 16,617um 0.20

The tarball extracts into the same directory structure as the Openroad-flow-scripts flow directory and SHOULD run out of the box with the make command.
What might make problems in the source code for Openroad are some large multiplexer structures as can be seen in spi_readback.v and Testcase_spi.v.
In the synthesized netlist you will also see 256 latches sg13g2_dllrq_1, which shouldn't be there (they are constantly enabled), but Yosys put them in there.
Verilog is not my preferred HDL.
Testcase.tar.gz

[oharboe]

https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/docs/user/FlowVariables.md#SYNTH_NETLIST_FILES

[TEEkohl]

That works, perfect!
But I discovered two bugs in the Testcase scripts I uploaded.

File designs/ihp-sg13g2/OpenPDK/Testcase_spi/config.mk:
export IO_PLACER_H = Metal3
export IO_PLACER_V = Metal2

File designs/ihp-sg13g2/OpenPDK/Testcase_spi/pdn.tcl:
set horiPower "TopMetal2"
set vertPower "TopMetal1"

After the last update of the IHP OpenPDK the preferred routing directions were inverted.