place: add GPL_PLACE_IOS for global_placement -place_ios

[minjukim55]

Adds GPL_PLACE_IOS (default 0). When set, steps 3_1 and 3_2 copy their input through and 3_3 runs global_placement -place_ios, with the pin settings from IO_PLACER_H/V and PLACE_PINS_ARGS passed through set_place_config right before the call and reset right after.

[gemini-code-assist]

Code Review

This pull request introduces the GPL_PLACE_IOS configuration variable, enabling concurrent cell and IO pin placement in a single global placement step (global_placement -place_ios) and skipping the separate IO-less global placement and pin placement steps. It also introduces SET_PLACE_CONFIG_ARGS to pass configuration arguments to set_place_config. Feedback on the changes suggests moving the warning about ignored PLACE_PINS_ARGS outside of the $place_ios conditional block in global_place.tcl to ensure users are always warned when GPL_PLACE_IOS is enabled but PLACE_PINS_ARGS is still defined.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit 8d20f24 · Jenkins build #4 · Baseline: build · View build on dashboard

62 design(s) checked — 14 with regression(s), 0 without a comparable baseline.

❌ asap7/riscv32i base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-9426.610	-960.116	-881.820%	-1152.139	PeriodPadding 20.000%

❌ asap7/swerv_wrapper base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-3130.530	-1551.920	-101.720%	-1862.304	PeriodPadding 20.000%

❌ gf180/jpeg base — 1 failing metric(s)

Metric	target	base	delta	limit	band
cts__timing__setup__tns	-27.246	-0.0220	-123953.307%	-1.222	PeriodPadding 20.000%

❌ ihp-sg13g2/ibex base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-17.440	-0.0540	-32190.089%	-1.654	PeriodPadding 20.000%

❌ ihp-sg13g2/jpeg base — 1 failing metric(s)

Metric	target	base	delta	limit	band
detailedroute__antenna_diodes_count	129.000	109.000	18.349%	109.109	Metric 0.100%

❌ ihp-sg13g2/spi base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-0.693	-0.414	-67.441%	-0.574	PeriodPadding 20.000%

❌ nangate45/ariane133 base — 3 failing metric(s)

Metric	target	base	delta	limit	band
cts__timing__setup__tns	-448.866	-315.386	-42.323%	-378.463	PeriodPadding 20.000%
finish__timing__setup__tns	-460.744	-292.142	-57.712%	-350.570	PeriodPadding 20.000%
globalroute__timing__setup__tns	-446.739	-369.105	-21.033%	-442.926	PeriodPadding 20.000%

❌ nangate45/bp_be_top base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-1.514	0.000	—	-0.520	PeriodPadding 20.000%

❌ nangate45/ibex base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-14.938	-2.698	-453.740%	-3.237	PeriodPadding 20.000%

❌ sky130hd/aes base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-3.930	-0.492	-699.506%	-1.212	PeriodPadding 20.000%

❌ sky130hd/chameleon base — 3 failing metric(s)

Metric	target	base	delta	limit	band
cts__timing__setup__tns	-16.627	-12.678	-31.146%	-15.214	PeriodPadding 20.000%
detailedroute__antenna_diodes_count	165.000	114.000	44.737%	114.114	Metric 0.100%
finish__timing__setup__tns	-19.852	-8.719	-127.679%	-10.463	PeriodPadding 20.000%

❌ sky130hd/microwatt base — 3 failing metric(s)

Metric	target	base	delta	limit	band
cts__timing__setup__tns	-258.337	-213.433	-21.039%	-256.120	PeriodPadding 20.000%
detailedroute__antenna_diodes_count	1639.000	1457.000	12.491%	1458.457	Metric 0.100%
finish__timing__setup__tns	-228.158	-165.245	-38.073%	-198.294	PeriodPadding 20.000%

❌ sky130hd/riscv32i base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-54.264	-41.992	-29.225%	-50.391	PeriodPadding 20.000%

❌ sky130hs/aes base — 1 failing metric(s)

Metric	target	base	delta	limit	band
finish__timing__setup__tns	-1.433	-0.0291	-4828.949%	-0.589	PeriodPadding 20.000%

[minjukim55]

The QoR failures come from the OpenROAD bump, not this change

[oharboe]

I am stumped by this... This information goes in here, but where is it used on the other end?

I think it might be used by global route too?

If it is used only by global placement, why does it go into the .odb? Or is this a global variable that is not persisted?

@maliberty is working on a proposal for persisted configuration settings, and as I recall his last proposal log_cmd for a command shows everything that goes into that command, so there's a separation of storage of persisted configuration settings and consumption. Consumption is explicit and visible in logs.

[oharboe]

DRY? I think we have this if statement elsewhere in the code...

[oharboe]

use a default value for GPL_PLACE_IOS 0 in variables.yaml and $::env(GPL_PLACEIOS) => hard early loud error if something is wrong, the above can create confusion by continuing execution when the root problem is some sort of propoagation of variables

[oharboe]

to make this consistent with ORFS flow today, we don't add if statements to make code, we copy the .odb/.sdc file in the step when there's nothing to do and always execute the step, so iffy code stays in .tcl and make has a static graph. Presumably the end state of this feature is that io placement always happens in gpl and there's no ORFS option to do it as a separate step, so I'd rather avoid iffy make code.

[oharboe]

🥳 Very nice feature to be able to do pin placement as part of the regular gpl! I tried it on my designs, but waiting for it to work together with timing/routing driven gpl.

[oharboe]

I'd like to see GPL_PLACE_IOS land. I think it can land now without settling the options design still under discussion in The-OpenROAD-Project/OpenROAD#11676 and The-OpenROAD-Project/OpenROAD#11755, by keeping to what ORFS does today: explicit arguments in, nothing persisted.

Proposal

• Default flow unchanged. PLACE_PINS_ARGS, io_placement.tcl, the four design config.mk files and genMassive.py stay as they are. place_pins still takes -hor_layers, -ver_layers, -corner_avoidance, -min_distance and -min_distance_in_tracks explicitly.

• No new variable. SET_PLACE_CONFIG_ARGS isn't needed. On the GPL_PLACE_IOS path, global_place.tcl turns IO_PLACER_H/V and those three PLACE_PINS_ARGS flags into their -io_pin_* equivalents. Any other PLACE_PINS_ARGS flag warns, as FLW 25 does now.

• Scoped to the call. set_place_config runs right before global_placement -place_ios, and reset_place_config right after:

  if { $place_ios } {
    log_cmd set_place_config {*}[place_pins_args_to_place_config]
    lappend global_placement_args -place_ios
  }
  do_placement $global_placement_args
  if { $place_ios } {
    log_cmd reset_place_config
  }

Why

• Outcome-agnostic. Whether OpenROAD ends up with set_config, a ppl options struct inside PlaceOptions, or set_place_config as it is, only that one proc changes. User-facing variables and design configs don't churn now and again later.
• Congruent with today. Every command gets its options in its own log_cmd line. No stage depends on config that an earlier stage stored in the odb, so checkpoints only change when the design does.

Context, for anyone who hasn't followed the OpenROAD threads

• Proposal: a unified set_config / get_config / reset_config / report_config OpenROAD#11676 proposed a set_config store persisted in the odb, with set_place_config as an upcoming member. The replies objected to the persistence, and maliberty concluded "that isn't a win".
• RFC: options structs shared by C++, Tcl and Python (global_placement, repair_design, global_route) OpenROAD#11755 (RFC draft) prototypes explicit per-command options structs instead. In it, the pin layers and spacing still come from set_place_config, so that part is open.

[oharboe]

The second commit covers all of my inline comments: set_place_config/reset_place_config scoped to the call, pins_fixed_in_floorplan, GPL_PLACE_IOS defaulting to 0 and read through $::env, and the copy-through in place of Makefile conditionals.

The PR title and description still describe the SET_PLACE_CONFIG_ARGS version; the second commit's message describes what the PR does now.

[oharboe]

@minjukim55 I'm not a maintainer, so I can't approve PRs, but I approve of it. 💯

[oharboe]

The checkmark is grey if I comment and green if I approve, so you get a grey checkmark since I'm not a maintainer and it is still marked as "review required", so we're good...