Tighten designs - #4482
Conversation
…k period for two designs which did not reach a negative slack Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
## make update_ok for ibex (gf180)... designs/gf180/ibex/rules-base.json updates: | Metric | Old | New | Type | | ------ | --- | --- | ---- | | placeopt__design__instance__area | 725567 | 724846 | Tighten | | placeopt__design__instance__count__stdcell | 15783 | 15301 | Tighten | | cts__design__instance__count__setup_buffer | 1372 | 1330 | Tighten | | cts__design__instance__count__hold_buffer | 1372 | 1330 | Tighten | | globalroute__timing__setup__tns | -2.0 | -8.23 | Failing | | finish__timing__setup__tns | -2.07 | -31.7 | Failing | ## make update_ok for riscv32i (ihp-sg13g2)... designs/ihp-sg13g2/riscv32i/rules-base.json updates: | Metric | Old | New | Type | | ------ | --- | --- | ---- | | synth__design__instance__area__stdcell | 140000.0 | 139000.0 | Tighten | | placeopt__design__instance__area | 157813 | 156855 | Tighten | | placeopt__design__instance__count__stdcell | 10692 | 10640 | Tighten | | cts__design__instance__count__setup_buffer | 930 | 925 | Tighten | | cts__design__instance__count__hold_buffer | 930 | 925 | Tighten | | detailedroute__route__wirelength | 456338 | 575080 | Failing | | finish__design__instance__area | 168206 | 167407 | Tighten | Large percentage changes in failing metrics (>50%): - ibex (gf180) finish__timing__setup__tns 1431.40% (-2.07 → -31.7) - ibex (gf180) globalroute__timing__setup__tns 311.50% (-2.0 → -8.23) Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.
| export CORE_UTILIZATION = 50 | ||
| export PLACE_DENSITY_LB_ADDON = 0.10 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I'm pretty sure we have other designs with macros that uses CORE_UTILIZATION. You can double check it, but I think this is just gemini hallucinating.
There was a problem hiding this comment.
Your changes are fine. If a certain design were to use manual macro placement we could treat it as an exception. It's just Gemini being overly defensive.
| export CORE_UTILIZATION = 50 | ||
| export PLACE_DENSITY_LB_ADDON = 0.11 |
There was a problem hiding this comment.
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
| }, | ||
| "finish__timing__setup__tns": { | ||
| "value": -2.07, | ||
| "value": -31.7, |
There was a problem hiding this comment.
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.
| }, | ||
| "detailedroute__route__wirelength": { | ||
| "value": 456338, | ||
| "value": 575080, |
There was a problem hiding this comment.
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.
| export SDC_FILE = $(DESIGN_HOME)/$(PLATFORM)/$(DESIGN_NICKNAME)/constraint.sdc | ||
|
|
||
| export CORE_UTILIZATION = 20 | ||
| export CORE_UTILIZATION = 85 |
There was a problem hiding this comment.
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
🔍 QoR checkMetrics reflect the PR merge build — i.e. what will land on the target branch. Advisory — results are log-only and do not affect build status. The authoritative QoR gate remains the local rules-file check. Commit 62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.
|
| set clk_name core_clock | ||
| set clk_port_name clock | ||
| set clk_period 800 | ||
| set clk_period 700 |
There was a problem hiding this comment.
Does it change QoR at all? I don't see new metrics for this design.
Same for ihp/aes and nangate45/bp_fe.
|
for the private design: For public designs: I am surprised to see improvements, I suspect after merging with master results improved. I can further tighten them. |
|
nangate45/bp_fe has a PPL error for certain input utilization values: gf12/tinyRocket has the error mentioned in #4500. |
5 participants
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.