Tighten designs

[gudeh]

Use CORE_UTILIZATION instead of DIE and CORE explicit values. Reduce the clock period of two designs. This should make all of the changed designs to have a more dense placement and negative slacks.

[gemini-code-assist]

Code Review

This pull request updates the OpenROAD subproject and modifies physical design configurations across multiple designs (tinyRocket, ibex, aes, riscv32i, and bp_fe_top) by increasing core utilization targets and tightening clock periods. However, several critical issues were identified: replacing fixed die and core areas with dynamic utilization for designs with macros (tinyRocket and bp_fe_top) risks breaking manual macro placements; the aggressive utilization targets of 75% and 85% lead to severe timing degradation (TNS of -31.7 for ibex) and significant routing congestion (a 26% wirelength increase for riscv32i); and the 85% utilization target for aes is overly aggressive for timing closure.

[gemini-code-assist]

Using dynamic CORE_UTILIZATION instead of fixed DIE_AREA and CORE_AREA is highly risky for designs containing macros (such as the SRAMs specified in WRAP_LEFS). In physical design flows, dynamic floorplan sizing based on standard cell area changes the die boundaries whenever the netlist size fluctuates. This will break manual macro placement configurations that rely on absolute coordinates, leading to placement failures or overlaps. It is recommended to retain fixed DIE_AREA and CORE_AREA dimensions for designs with macros to ensure stability.

# These values must be multiples of placement site
export DIE_AREA    = 0 0 400.008 399.84
export CORE_AREA   = 19.992 20.16 380.016 380.16

export PLACE_DENSITY = 0.20

[gemini-code-assist]

Removing the fixed DIE_AREA and CORE_AREA in favor of dynamic CORE_UTILIZATION is problematic for bp_fe_top because it contains multiple SRAM macros (ADDITIONAL_LEFS). Dynamic floorplan sizing causes the die/core boundaries to shift whenever the synthesized netlist size changes. This invalidates manual macro placement configurations (typically defined with absolute coordinates), leading to out-of-bounds or overlapping macro placement errors. To tighten the design safely, calculate and specify a smaller, fixed DIE_AREA and CORE_AREA instead of using dynamic utilization.

export DIE_AREA    = 0 0 800 600 
export CORE_AREA   = 10 10 790 590 

export PLACE_DENSITY_LB_ADDON = 0.11

[gemini-code-assist]

The total negative slack (finish__timing__setup__tns) has degraded significantly from -2.07 to -31.7. While some negative slack is expected when tightening the design, a TNS of -31.7 at the final stage is extremely high for the Ibex core on GF180. This indicates severe, unresolvable timing violations under the new 75% utilization target. Consider lowering the utilization target (e.g., to 65% or 70%) to allow the optimizer sufficient routing and buffering space to meet timing.

[gemini-code-assist]

The detailed routing wirelength (detailedroute__route__wirelength) increased by approximately 26% (from 456338 to 575080), even though the standard cell area decreased slightly. This disproportionate increase in wirelength is a clear symptom of severe routing congestion caused by raising the core utilization from 35% to 75%. High congestion and excessive routing detours can lead to increased dynamic power, crosstalk, and potential DRC violations. Consider a more moderate utilization target (e.g., 60%) to balance density and routing efficiency.

[gemini-code-assist]

Setting CORE_UTILIZATION to 85% is extremely aggressive for a standard cell design, especially when combined with a tighter clock period of 3ns. High utilization limits the router's ability to insert buffer trees for timing closure and clock tree synthesis, and typically leads to severe routing congestion and DRC violations. A utilization target between 60% and 70% is generally the practical upper limit for routability and timing closure in most technologies.

export CORE_UTILIZATION = 70