Repository navigation
Use percent of minimum clock period #4583
Description
Description
Worst negative slack (WNS) is a poor number to compare runs by. It mystifies more often than it explains:
-
Percent of a small number.
make metadatarules compare WNS by percent, so a few picoseconds read as a large change. From Remove REMOVE_ABC_BUFFERS support #4580 (comment):Metric target base delta limit band cts__timing__setup__ws-0.624158 -0.518657 20.34 % -0.618657 PeriodPadding 5.0 % -
WNS measures the SDC, not the tool. WNS covers every path group, including in2reg, reg2out and in2out paths whose constraints are often approximate, such as
set_output_delay [expr $clk_period * 0.2]. In OpenROAD'srepair_setup_parallel_eval_default_sequencetest (gcd, asap7, 220 ps; the setup-repair stack test: Add LEGACY repair setup path regressions OpenROAD#11794 … doc: Update the rsz setup repair architecture OpenROAD#11805), the worst endpoint for the whole run is the outputresp_msg[13]. Its required time comes from that arbitrary 44 ps, so the repair's effect on the design never shows in WNS. -
TNS has the same small-number problem. The clock period is chosen so WNS ends up slightly negative, so TNS sums only the few endpoints that fail: two in the gcd test by the end. It swings from case to case. If the failing paths are ones a change can't fix, its effect on everything else stays hidden.
-
On a large design, WNS ranks changes the wrong way. On XiangShan's tile (asap7, about 2.7 M instances, at global route; ideas, repair-headroom: WNS mystifies; a one-flop loop sets XSTile's floor at 2,151 ps bazel-orfs#1356), against a 2,000 ps target:
Change Worst path Endpoints ≥ 2,000 ps Excess over 2,000 ps control 2,504 ps 5,259 733 ns placement cohesion 2,524 ps 4,336 548 ns cohesion + a logic cut 2,419 ps 5,741 763 ns By the worst path, the second change looks worse and the third looks best. By the endpoints that fail, it's the other way round. The SDC there also asks 473 ps, so nearly every endpoint violates and TNS against it says nothing.
Suggested Solution
-
Compare by the minimum reg2reg clock period: the clock period minus the reg2reg worst slack, in percent of that period, not of WNS. It's the same idea as
timing__fmax, which @maliberty pointed out is already reported, but restricted to register-to-register paths: those are the paths the flow can close, while the other groups' constraints are often guesses.Measuring reg2reg only also takes the SDC's accuracy out of the question.
- ORFS's
.sdcfiles often constrain IO with rough budgets, such as 0.2 × the period. With a reg2reg metric those budgets stop mattering for the comparison, which makes the SDCs easier to maintain. Measuring reg2reg alone is fine for tracking the tools. set_input_delayandset_output_delaystill deserve targeted tests of their own, especially where a flow repairs hold heavily on purpose.- An accidental
set_input_delayhold buffer infestation probably deserves an error message in OpenROAD, with an explicit override for designs that mean it. That's where an input delay's min value leaves the input paths with hold violations nobody intended, and hold repair fills the design with delay buffers.
- ORFS's
-
For A/B comparisons, look at more than one path: the reg2reg endpoints within a band around the period, before and after; how many improved and by how much, and how many got worse. The profiler in rsz: Add the setup repair profiler OpenROAD#11796 already records WNS/TNS trajectories and failing endpoint counts, and looks like a natural place for that per-endpoint view.
-
Optionally, a floor to read the period against: the one-flop-loop floor, the worst path from a register back to itself. No clock skew or retiming can beat it, so when the period sits at the floor, only that loop's wire, cells or logic can help. On XiangShan's tile it's 2,151 ps, above the 2,000 ps target, which no tuning of the flow could have revealed by WNS alone (bazel-orfs#1356).
Additional Context
The reg2reg-only point matters for designs whose IO constraints are budgets, not real requirements. In theory there could be designs with no reg2reg paths, and those would need a fallback.
Activity
maliberty commentedon Sep 30, 2026
fmax is already available and is equivalent to clock period
oharboe commentedon Sep 30, 2026
minimum clock period = 1/fmax = clock period - WNS, provided WNS is not capped to 0
oharboe commentedon Oct 15, 2026
@maliberty Ooops.... my formula is wrong because fmax is reg2reg, whereas WNS includes in2reg, reg2out and in2out.
My concern about using anything but reg2reg is that the .sdc files are oftentimes very approximate w.r.t. non-reg2reg constraints, such as 0.2 * clock period
there could be designs without reg2reg paths in theory in ORFS designs.
Right?
oharboe commentedon Oct 18, 2026
A concrete case for reg2reg: in OpenROAD's
repair_setup_parallel_eval_default_sequencetest (gcd, asap7, 220 ps, from the setup repair stack The-OpenROAD-Project/OpenROAD#11794 … The-OpenROAD-Project/OpenROAD#11805), the worst endpoint throughout the run is the outputresp_msg[13]. Its required time comes fromset_output_delay [expr $clk_period * 0.2], an arbitrary 44 ps. So that WNS tells us more about the quality of the.sdcthan about OpenROAD as a tool. A reg2reg minimum period isn't affected by that choice.oharboe commentedon Oct 18, 2026
On TNS, the same small-number problem applies. The clock period is chosen so that WNS ends up slightly negative, so only a few endpoints fail, and TNS adds up just those few: in the gcd test above, two endpoints by the end. Large swings from case to case are to be expected, and if the failing endpoints happen to be paths a change can't fix, its effect on everything else stays hidden.
We can get more mileage out of each test case by examining more paths: the reg2reg slack of every endpoint within a band around WNS, before and after, passing endpoints included. From that, how many improved and by how much, and how many got worse. That should show both what's working and what's holding us back.
Admittedly that's a bit naive as stated. Endpoints with plenty of slack should get slower if that buys area or power, so "got worse" probably only means something inside the band.
The profiler added in The-OpenROAD-Project/OpenROAD#11796 already records WNS/TNS trajectories and failing endpoint counts, so it looks like a natural place for a per-endpoint view.
oharboe commentedon Oct 21, 2026
@migueldalberto @maliberty I rewrote the issue body to be more coherent after collecting various information in discussions.
oharboe commentedon Oct 22, 2026
ORFS's designs aren't unit tests. A design's WNS, or minimum clock period, is meant to show how well OpenROAD does on this kind of design, which is its register-to-register logic. A sweep of 51 ORFS designs at global route (The-OpenROAD-Project/bazel-orfs#1386) looked at what WNS measures today:
.sdc, mostlyclk_io_pct 0.2Behind each WNS: every reg2reg endpoint of every design on one graph. Each line is one design, showing the share of its endpoints at or beyond each period, over its own clock. A line ends at the design's worst endpoint. The bold lines are the medians, and the strip below shows where WNS puts each design:
Two one-line
.sdcchanges were tested, each with a control that reproduces the original run byte for byte:Designs by what sets their WNS
asap7/riscv32i-mock-sram:riscv_top,asap7/jpeg_lvt,asap7/chi_async_bridge,asap7/aes-block:aes_cipher_top,sky130hd/riscv32i*,asap7/aes,asap7/ethmac_lvt,nangate45/tinyRocket*,sky130hs/ibex,ihp-sg13g2/spi,sky130hd/ibex,nangate45/bp_fe_top,asap7/tinyRocket-regfile*,asap7/tinyRocket*,asap7/jpeg,gf180/ibex,ihp-sg13g2/aesihp-sg13g2/ibex,nangate45/ibex,asap7/aes_lvt,asap7/aes-mbff,asap7/ibex,asap7/ibex-regfile,sky130hs/riscv32i*,asap7/uart,ihp-sg13g2/gcd,sky130hs/gcdihp-sg13g2/i2c-gpio-expander:I2cDeviceCtrl,gf180/uart-blocks:uart_rx,nangate45/bp_be_top,asap7/riscv32i,gf180/uart-blocks:uart,asap7/riscv32i-mock-sram:fakeram7_256x32,gf180/riscv32i,ihp-sg13g2/i2c-gpio-expander:I2cGpioExpanderTop,asap7/gcd,asap7/gcd-ccs,nangate45/swerv*,nangate45/picorv32,nangate45/dynamic_nodeasap7/ethmac,nangate45/tpu,asap7/picorv32,asap7/picorv32-regfile,nangate45/gcd,ihp-sg13g2/riscv32i,asap7/mock-alu,sky130hd/gcd,asap7/tpuasap7/aes-block:aes_rcon* has registers the timer never sees (check_setup).
Scope: synthesised with slang (bazel-orfs's default) rather than yosys's frontend, and read at global route. 11 flows failed before timing and 19 large designs were left out; both are listed in the study.