flow: refactor io_placement to avoid propagating intermediate ODB

[oharboe]

This change modifies io_placement to write a script with pin locations rather than passing an intermediate ODB containing dummy placement to global placement.

This avoids global placement seeing an .odb file modified by pin placement. As a result, global_placement no longer has to clean up the mess in the kitchen after IO placement (by manually deleting components before proceeding).

Cost taxonomy

Category	What happened	Actionable Fix	Wall-clock	Main Tokens	Subagent Tokens
thinking	Refactored Makefile, io_placement.tcl, and global_place.tcl dependency chain to pass coordinate script instead of .odb.	N/A	30m	180k	0
flaky tools	RePlAce diverged during global placement on origin/master (task-357).	Ran tests on branch to verify we hadn't caused regression.	25m	35k	0
bloat	Read full logs from failed global placement runs.	Extracted tail lines and confirmed failure source instead of reading full logs.	5m	25k	0
Total			60m	240k	0

Scope: this PR.

[gemini-code-assist]

Code Review

This pull request refactors the placement flow by integrating the initial global placement with skipped IOs directly into the IO placement step, simplifying the Makefile targets and step numbering. Feedback on these changes highlights an issue in io_placement.tcl where the POST_IO_PLACEMENT hook is executed unconditionally; if the IO placement is skipped, no design is loaded, which will cause any custom post-placement scripts that query the database to fail. It is recommended to move this hook inside the else block where the design is actually loaded.

[maliberty]

What "mess in the kitchen"? The makes it hard to work on IO placement as you can only see the results after gpl runs which is substantially slower. We also have ongoing development that will moot this be integrating IO placement into gpl.

[oharboe]

What "mess in the kitchen"? The makes it hard to work on IO placement as you can only see the results after gpl runs which is substantially slower. We also have ongoing development that will moot this be integrating IO placement into gpl.

placing io pins moves all the stdcells as a side-effect => intentional?

Then global placement have to move all the stdcells back to the center (clean up the kitchen before making the next dish)...

Am I misunderstanding something?

[oharboe]

We also have ongoing development that will moot this be integrating IO placement into gpl.

😌

[maliberty]

Because of the mutual dependence between IO and cell placement we iterate (cells skipping io, then io, then cells again with ios). So we are resetting the locations for the next iteration. I wouldn't call it a mess so much as visibility into the process. The process will be more internal to gpl in the future.

[oharboe]

Thank you for the explanation. I understand it to be debug output, but since this is all internal in gpl in the future, this PR is moot: a matter of taste/debugging/visibility into the process and doing anything here now is just churn for no reason while we wait for gpl upgrade.

😌