docs: Extract and expand Design Space Exploration guide

[oharboe]

Extracts DSE architectural patterns and theories into a dedicated DesignSpaceExploration.md file to keep DeveloperGuide.md focused on core futility policies.

[gemini-code-assist]

Code Review

This pull request introduces a new comprehensive guide on Design Space Exploration (DSE) and automated tuning in OpenROAD, linking to it from the Developer Guide. It also optimizes the handling of unusable sites in the global placer (src/gpl/src/placerBase.cpp) by merging vertically adjacent blocked sites into larger 2D dummy instances, which significantly reduces the total number of dummy instances created during placement. Test outputs have been updated to reflect this optimization. There are no review comments, and I have no feedback to provide.

[oharboe]

@maliberty This background will make it easier to understand the motivation for the various single concern PRs I have in flight and I think it is good framing for autotuner. It also manages expecations for what the autotuner, OpenROAD+ORFS can do and what the user must do for DSE(design space exploration).

Today global placement is stuck indefinitely in O(n^big) on linked lists, I have patches to take that down to 11 hours and further down to << 2 hours.

This is done in a way that doesn't compromise the tapeout use-case and mnimizes the cognitive load for users and is congruent with POLA.

[oharboe]

@maliberty Yes: this was written by AI based on my input, but I think it reads reasonably well. Not too flowery or a wall of text and it vendors in context that I think is necessary.

I shall take any insult to this written text as an insult to my inferior to AI writing skills here, I can't do better myself. 🤠

[maliberty]

The prose is fine but my concern is about presenting one approach/opinion as global fact.

• When this approach yields mediocre results.. is stated as if it is always true.
• the user must define an external optimization function some users will be happy enough with fmax.
• Users are encouraged to write custom flows will lead less experienced users into trouble.

I would be happier with this being prefaced with you stating it is your experience rather than the global recommendation of OpenROAD.

[oharboe]

@maliberty That is very fair feedback. I definitely don't want to tell others how to best do what is best for them—they know their own requirements best, and the standard flow with standard metrics like fmax is clearly the right path for many. If we tell people what to do or think, they will naturally resist, which is the opposite of my goal here.

My aim is to provide descriptive background material for a specific, advanced use-case (large-scale autotuning). Having this context documented means that when I submit future PRs (like addressing the O(n^big) bottlenecks in global placement), everybody can agree on the context. It saves us from having to re-litigate why these changes are valuable and congruent with OpenROAD's broader goals.

I want to avoid adding a disclaimer that this is "just my experience," as that signals the document can be safely ignored as a personal anecdote rather than a valid, documented use-case.

Instead, I have pushed an update that shifts the tone from prescriptive (telling people what they must do) to descriptive (explaining how advanced DSE frameworks operate). I've softened the absolute statements you highlighted, removed words like "must" and "encouraged," and added a preface clarifying that the standard flow and metrics are perfectly fine for general use.

[oharboe]

@MrAMS Since you've done DSE studies and are familiar with this domain, I thought you might be interested in this.

Additionally, if you are interested in calculating the floorplan based on synthesis results—rather than trying to drive those guesses purely via DSE input parameters—that is possible too. In my experience, I've found that core utilization can drop because the RTL doesn't grow linearly. Because of this, I prefer to start on a rung with a more generous area until I converge on an input domain that is somewhat close to the target, and only then try to tighten the floorplan on the next rung.