cleanup on floorplan_to_place

[eder-matheus]

No description provided.

[eder-matheus]

@maliberty I'm not sure if this is the best solution to prevent having the non-stage variables being deleted on the single-run. I'm open to suggestions here.

[maliberty]

I think this simple and works well enough. The other option would be to capture all envars at the start and restore them between stages in floorplan_to_place.tcl

[maliberty]

This is starting to resemble the old single flow (0e02037)

[maliberty]

I think this simple and works well enough. The other option would be to capture all envars at the start and restore them between stages in floorplan_to_place.tcl

[oharboe]

Excellent initiative and starting point. I am sure we can refine this, but already DRY.

@MrAMS FYI Useful to make Optuna scripts to extract metrics rather than running flows

[MrAMS]

Useful to make Optuna scripts to extract metrics rather than running flows

@oharboe
It looks like this PR enables extracting metrics from existing EDA result to avoid redundant runs, but we still need to execute the EDA flow to generate the data first, right? I'm not entirely sure I understand your point. Please let me know if I'm misunderstanding anything.

[oharboe]

The core hypothesis is that we can achieve accurate PLACE_DENSITY and CORE_UTILIZATION metrics without running the flow to completion or relying on high-precision timing/routing-driven placement. In fact, disabling these advanced features may yield a cleaner estimate for initial density checks, allowing us to "fail fast" on doomed runs.

To optimize this Design Space Exploration (DSE), I propose the following:

1. Streamline the Check: Run a simplified placement flow—skipping timing/routing-driven optimization and interim .odb writes—to serve as an early gatekeeper.
2. Reduce Dimensionality: Structure the DSE hierarchically:
   • Stage 1: Filter RTL parameters based on synthesis metrics (e.g., compute/energy). Here the RTL is parameterized(e.g. Chisel generation or SystemVerilog top level parameters)
   • Stage 2: Filter for viable PLACE_DENSITY and CORE_UTILIZATION using the simplified flow.
   • Stage 3: Full optimization of remaining parameters.
3. Maintain Flexibility: Since optimization goals are highly project-specific, we should avoid hard-coding objective functions. Instead, we should empower the user to define their own functions via tools like Optuna.

Note: The ability to skip writing interim .odb files would be a natural extension of this PR.

[MrAMS]

This is a fantastic proposal! I couldn't agree more with the overall approach.

One concern I have is regarding Optuna. While it natively supports pruning for single-objective optimization, it currently does not support pruning for multi-objective optimization. Since my goal is to explore the Pareto Frontier, losing the ability to prune unpromising trials early is a significant limitation we need to consider.

Maybe we can use Ray Tune or SMAC3 instead of Optuna. Or pruning in multi-objective optimization is not possible in fact. Ray Tune and SMAC3 made some tricks which turn multi-objective optimization into single-objective optimization.

I have another concern regarding the resource overhead when combining Ray Tune (or other supports parallel trials) with Bazel.

Since we need to isolate the output_base for each worker to prevent locking issues, this implies spawning multiple Bazel server instances (JVMs) simultaneously. I'm worried this might lead to excessive memory consumption and potential OOM (Out of Memory) issues, as each idle Bazel server already carries a significant footprint. Althogh we can use "multi-slot Bazel concurrency" workaround as I mentioned in The-OpenROAD-Project/bazel-orfs/pull/473, but it is not elegant.

We could certainly opt to disable parallel trials, but as I mentioned in my previous email, I’ve noticed that OpenROAD's CPU utilization is surprisingly low, even on my laptop. It doesn't seem to leverage multi-core architectures effectively.

If we forgo parallel trials (task-level parallelism), we would need to figure out how to maximize OpenROAD's internal multi-threading capabilities. I suspect this will be extremely difficult, as my understanding is that many underlying EDA algorithms are inherently serial.

That said, I'm not an expert on OpenROAD's internals, so I am very open to corrections or suggestions if anyone knows a way to unlock better multi-core performance within the tool itself.

[oharboe]

We can trivially have N (static number easily on the order of maximum cores) orfs_flow() in a single bazel build that we each configure with a different parameter, will follow up out of band.