Is asap7 really signing off setup at the *best-case* corner? (CORNER ?= BC)

I think I must be misreading the asap7 corner setup, because as far as I can tell the default flow evaluates setup timing at the fast / best-case corner — which would be backwards. I'd appreciate a sanity check before I conclude I've found a real problem.

What I see

flow/platforms/asap7/config.mk (upstream/master @ 7bf5a814e4) defaults the single timing corner to BC:

export CORNER ?= BC                                   # line 197
export LIB_FILES += $($(CORNER)_$(LIB_MODEL)_LIB_FILES)

and BC is the fast corner (0.77 V, 25 C, *_FF_* libs):

BC_VOLTAGE = 0.77 ;  BC_TEMPERATURE = 25C
BC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_FF_nldm_*.lib.gz    # FF  = fast / best case
WC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_SS_nldm_*.lib.gz    # SS  = slow / worst case
TC_NLDM_LIB_FILES_T = .../asap7sc7p5t_*_TT_nldm_*.lib.gz    # TT  = typical

Since the flow is single-corner (LIB_FILES comes from the one selected CORNER), all STA — setup included — appears to run at FF by default. Setup is normally closed against the slow corner, so this looks wrong. gf180 has the same CORNER ?= BC; nangate45/sky130hd are single-typical-corner and look unaffected.

Minimal reproduction — `gcd` (smallest design, no corner override)

designs/asap7/gcd/config.mk sets no CORNER, so it inherits the platform default. Running it stock vs. forcing worst-case:

make DESIGN_CONFIG=./designs/asap7/gcd/config.mk            # default (BC)
make DESIGN_CONFIG=./designs/asap7/gcd/config.mk CORNER=WC  # worst-case

run	libraries actually loaded	worst setup slack
default (`BC`)	`asap7sc7p5t__FF_nldm_` (fast)	−35 ps
`CORNER=WC`	`asap7sc7p5t__SS_nldm_` (slow)	−347 ps

(Slack values are worst slack reported at the same timing-driven global-placement stage,
identical clock and SDC; grep _FF_nldm/_SS_nldm in each run's log confirms which corner's
libraries were read.) The default run reads the fast libraries and reports ~−35 ps; the
same design at the worst-case corner is ~−347 ps — a ~10× difference, and the sign of the
engineering conclusion ("barely violating" vs "badly violating") flips with it.

So the stock gcd — and every asap7 design that doesn't override CORNER — is being timed at
the best-case corner, which under-reports setup violations by an order of magnitude here.

Questions

Am I misreading this — is there a separate setup/hold corner mechanism I'm missing that makes setup actually use SS despite CORNER ?= BC?
If not: is BC an intentional asap7/gf180 choice (e.g. tied to how these predictive PDKs were characterized), or an oversight? If intentional, could it be documented, since "asap7 setup is reported at best-case" strongly affects how the numbers should be read?

Happy to send a PR (flip the default to WC/TC, or add docs) once I know which it is.

Interesting question, I asked Claude to do some digging.

1. Is there a separate setup/hold corner? No. With CORNER ?= BC, every asap7 stage, setup included, is timed with the FF libraries. gf180 has the same default.

2. Intentional or an oversight? Nothing records why. asap7 started on a single TT library (4eeefb6, Jan 2021). CORNER ?= BC arrived in a platform update with no stated rationale (67b9571, Mar 2021). That was six months before ORFS could load more than one corner (CORNERS, f9463be, Sep 2021), so one corner was all the flow could do at the time. gf180 copied the pattern at bring-up (5c761de). A 2023 attempt to tie CORNERS to asap7's CORNER naming (#837) was reverted the next day (#839).

Flipping the ORFS default is a lot of work, and users have no reason to keep it.

CORNER ?= BC is also the default for the regression suite, and every asap7 clock period and rules.json has been calibrated against FF since 2021. A different corner changes the results of every asap7 design at once. That amounts to fuzzing the inputs, and designs that sit near an edge will turn up problems that have nothing to do with the corner.

#4681 shows what that looks like. Switching asap7/aes-block to slang made the parent's netlist slightly smaller, while the macros stayed the same. CORE_UTILIZATION 47 then gave a slightly smaller core (11,857 vs 11,875 µm²), the macros (9,792 µm² with halos) crossed the ~82% of the core where macro placement fails with MPL-0003, and the build stopped. read_verilog fails at the same core, and the nearest failing and passing cores differ by one site column. A corner flip would do this to every asap7 design at once: each failure investigated, each fixed or re-floorplanned, and each rules.json re-baselined.

A user's own design isn't bound by any of that, and there is no reason to prefer FF. Set CORNER=WC for setup, or CORNERS (below) for setup and hold together.

Single corner is the default, not a limit. LibreLane (the OpenLane 2 successor) does multi-corner analysis through STA_CORNERS and DEFAULT_CORNER, picks corners per step with RSZ_CORNERS, CTS_CORNERS and PNR_CORNERS, and extracts SPEF per corner. ORFS has the mechanism too: with CORNERS set, read_liberty.tcl loads every corner into one OpenROAD session, so repair and the reports see all of them. ihp-sg13g2's i2c-gpio-expander uses it (CORNERS = slow fast).

On asap7 it needs these changes:

Corner names: asap7 names its lists <CORNER>_<LIB_MODEL>_LIB_FILES, while read_liberty.tcl looks up <CORNER>_LIB_FILES. CORNERS="WC BC" finds nothing.
ADDITIONAL_LIBS: macro and multi-bit flop libraries are folded into LIB_FILES, which multi-corner mode ignores, so macros lose their timing. They need reading into every corner, as AUTO_MEMORIES already does.
Synthesis: it maps with LIB_FILES and stays single-corner. Set CORNER=WC for synthesis.
Parasitics: setRC.tcl sets one RC corner for all liberty corners. Separate RC corners would need set_layer_rc -corner.
Corners per stage: LibreLane's per-step corner lists would need CORNERS read per stage. In bazel-orfs, stage_arguments can already set it per stage.

#4771 (consistent <COMMAND>_ARGS) doesn't need to change for this. LibreLane's per-step corners (RSZ_CORNERS, CTS_CORNERS, PNR_CORNERS) choose which liberty and RC data a step loads. repair_timing and clock_tree_synthesis then work on whatever is loaded and take no corner option. That makes corners variables that name files, which #4771 leaves to variables of their own, so a build can declare them as a stage's inputs. Corner-specific repair is item 5: CORNERS with a different value per stage.

A test in bazel-orfs could carry 1 and 2 as a patch on ORFS and build asap7 gcd three ways: CORNER=BC (today's default), CORNER=WC, and CORNERS="WC BC" with CORNER=WC for synthesis. Pass/fail checks would be:

the multi-corner run reads both the SS and FF libraries;
report_checks -corner reports setup at WC and hold at BC;
every macro has timing arcs in every corner.

With setup and hold WNS for each arm, that test would show what flipping the default, or running both corners, costs.

It looks like an arbitrary choice in the mist of time when we only had single corner analysis. As a tool to drive OR development it hardly matters which corner we use. We could now setup a two corner analysis. I don't recall the history of CORNERS and what broke but we could try again.

I agree it doesn't matter much as test cases, but academics are using this for evaluation of research ideas, so it should probably be fixed to prevent incorrect claims.

Transitioning to multi corner is definitely a good suggestion and is probably needed for both of the above cases. It probably coincides with needed work in the resizer etc.

What about continuity of the regression tests? These will likely break if it goes to multi corner as well.

What about continuity of the regression tests? These will likely break if it goes to multi corner as well.

There's been some thinking about how to measure QoR. It all started with the observation that percent of WNS is very misleading because WNS is by design small and then it snowballed into #4583

Multicorner would make QoR evaluation across designs even more interesting.

We can update our limits but it has the possibility to create more confusion for academics trying to compare results across such a switch.

Perfect is the enemy of good. If they do that, then it is just ineptitude and we can't prevent that. Most academics aren't comparing an old version of OR/ORFS with a new version, but a version that they have modified with the baseline before they modified it.

Since ORFS is a regression testing suite, surely there are better designs/benchmarks to use for academic study.

I wouldn't use unit-tests to measure the performance of a CPU, I'd use CoreMark, SPEC, etc.

Isn't there something like that for EDA tools?

Unfortunately, many papers are using these benchmarks.

8. Unfortunately, many papers are using these benchmarks.

Hmm.... so all the more reasons to include something that resembles benchmarks in ORFS designs then. I've got CoralNPU + XiangShan in the pipeline. I think I saw some EDA competition designs, but I can't find them now. Do you happen to know some good ones?

I've already got CoralNPU in HighTide. XiangShan would be a good addition.

EDA competitions are tending to use the ORFS designs too....

10. I've already got CoralNPU in HighTide.

😌

You may be interested in this new setup, it has wired up new features in OpenROAD, particularly generate_ram to do register files + verilog surgery. It needs a few more PRs merged before I can flip it to ready to review.

#4653

XiangShan would be a good addition.

You can follow the work in bazel-orfs, I haven't thrown it the towel yet.

Most academics aren't comparing an old version of OR/ORFS with a new version, but a version that they have modified with the baseline before they modified it.

Don't they compare against a previously published result?

Sometimes. I've seen some comparing with baseline ORFS.

In any case, it seems like multi corner tests should be a thing...

I am interested in this conversation, what is the conclusion?

Perhaps a separate issue but

export BC_TEMPERATURE          = 25C
export TC_TEMPERATURE          = 0C

These two values should be swapped

Navigation Menu

Repository navigation

Is asap7 really signing off setup at the best-case corner? (`CORNER ?= BC`) #4764

What I see

Minimal reproduction — `gcd` (smallest design, no corner override)

Questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Is asap7 really signing off setup at the *best-case* corner? (CORNER ?= BC) #4764

Description

What I see

Minimal reproduction — gcd (smallest design, no corner override)

Questions

Activity

oharboe commented on Nov 1, 2026

maliberty commented on Nov 4, 2026

mguthaus commented on Nov 4, 2026

oharboe commented on Nov 4, 2026

maliberty commented on Nov 4, 2026

mguthaus commented on Nov 4, 2026

oharboe commented on Nov 4, 2026

mguthaus commented on Nov 4, 2026

oharboe commented on Nov 4, 2026

mguthaus commented on Nov 4, 2026

mguthaus commented on Nov 4, 2026

oharboe commented on Nov 4, 2026

maliberty commented on Nov 5, 2026

mguthaus commented on Nov 5, 2026

raphaelrowley commented on Nov 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Is asap7 really signing off setup at the best-case corner? (`CORNER ?= BC`) #4764

Minimal reproduction — `gcd` (smallest design, no corner override)