Update yosys submodule by github-actions[bot] · Pull Request #45 · oharboe/OpenROAD-flow-scripts

github-actions · 2026-05-15T11:01:39Z

Automated changes by create-pull-request GitHub action

Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>

…t-staging/secure-fix-variables fix make issue missing variables

…h-diagnostic Netlist hash diagnostic

Restore the sweep recipe (per-platform --keep_going, big designs solo, small designs batched) and the triage decision tree for failing _tests. The yosys-environment false-positive check now points at @bazel-orfs//:make-yosys-netlist (and the reverse @bazel-orfs//:yosys-check), which moved upstream in 432edcd63; the full workflow lives in @bazel-orfs//:TESTING.md "Debugging OpenROAD determinism (bazel vs make)". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Yosys 0.63 has a WRAPCELL/RTLIL-identifier memory corruption that produces garbage characters in module names like `'\\<random>_KOGGE_STONE'` during synthesis of designs that exercise the $alu architectural-options path (cva6, ibex, riscv32i*, swerv_wrapper, sky130hd/{ibex,microwatt} all hit this in the asap7+sky130hd sweep). Upstream yosys fixed it; 0.65 produces clean names like `ALU_64_0_64_0_64_KOGGE_STONE`. bazelbuild/bazel-central-registry#8863 adds 0.65 to BCR. Until that lands we point at oharboe's fork branch via an additional --registry in .bazelrc, then force the root resolution to 0.65 via single_version_override (bazel-orfs's MODULE.bazel pins to 0.63). Verified: //flow/designs/asap7/cva6:cva6_synth now builds clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Upstream main now has commit c000cb3 "orfs_design/orfs_flow: add user_sources= for design-private path hooks" — the same change we were carrying as 0001-orfs_design-add-user_sources.patch. Drop the patch file and remove the patches= reference in MODULE.bazel. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Run `make DESIGN_CONFIG=designs/asap7/uart/config.mk metadata update_rules` to baseline `rules-base.json` against the make-built yosys netlist. The diff captures three groups of changes: * `synth__canonical_netlist__hash` and `synth__netlist__hash` are new warning-level rules introduced by a5839b8. This commit materializes them for the first time on a real design (make-yosys SHA-1 over `1_1_yosys_canonicalize.rtlil` and `1_2_yosys.v`). * `finish__timing__setup__ws` and `finish__timing__setup__tns` get tightened by `--tighten`: make-flow's slack is meaningfully better than the previous baseline; this records the new headroom. The point of the snapshot is to give a `bazelisk test` re-run a make-yosys reference against which the bazel-yosys netlist hash mismatches, so `checkMetadata.py` surfaces the warning-level `[WARN] synth__netlist__hash differs ...` diagnostic that the next README change documents. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

The previous bucket-#2 text walked the reader through the symptom ("bazel-built yosys and make-built yosys produce different `1_2_yosys.v`") before pointing at the diagnostic. Now that `rules-base.json` carries warning-level `synth__canonical_netlist__hash` and `synth__netlist__hash` entries (a5839b8), the diagnostic IS the symptom: `checkMetadata.py` emits [WARN] synth__canonical_netlist__hash differs test: <bazel> == <make> [WARN] synth__netlist__hash differs test: <bazel> == <make> right above the failing QoR row. Lead with that and keep `@bazel-orfs//:make-yosys-netlist` (+ the reverse-direction `@bazel-orfs//:yosys-check`) as the per-stage `.odb` SHA-matrix proof when the warning alone isn't enough. Drop the `SYNTH_NETLIST_FILES` and `BLOCKS=` parenthetical — that level of detail belongs in `@bazel-orfs//:TESTING.md`, which the link already points at. Dress-rehearsed on `//flow/designs/asap7/uart:uart_test`: after bumping `rules-base.json` from the classic make flow (ca657c9) the bazel `_test` fires both `[WARN] …__hash differs` lines exactly as described, alongside the pre-existing `detailedroute__route__wirelength` failure. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

`synth__canonical_netlist__hash` (1_1_yosys_canonicalize.rtlil, post-front-end) and `synth__netlist__hash` (1_2_yosys.v, post-ABC) already exist as warning-level entries in `rules-base.json`. On asap7/uart both already DIFFER between bazel-pinned yosys and make-pulled `tools/install` yosys (`cff062a8…` vs `6e8e16e4…`, and `ab8b0b69…` vs `95652d90…` respectively), so the post-ABC hash on its own can't tell us whether the drift is yosys-internal non-determinism (read_verilog / hierarchy / opt_clean / techmap / dfflibmap) or an ABC version mismatch. Add a third fingerprint immediately before the main `abc` call in synth.tcl: [WARN] synth__canonical_netlist__hash differs ... # front-end snapshot [WARN] synth__preabc_netlist__hash differs ... # mid-level synth [WARN] synth__netlist__hash differs ... # post-ABC The pre-ABC snapshot is computed by `write_rtlil` to a temp path, `exec sha1sum`, file delete, then `puts` of the hash to the yosys log. The full RTLIL is never shipped as a bazel artifact — only the 40-char SHA in `1_2_yosys.log`, which is already collected by the synth action. `extractTagFromFile` in `genMetrics.py` regex- greps the line; the corresponding `level: warning` rule entry lives alongside the other two in `genRuleFile.py`. `flow/designs/asap7/uart/rules-base.json` is regenerated via `make … metadata update_rules` so the third field is populated from make-yosys. Re-running `bazelisk test //flow/designs/asap7/uart: uart_test` then surfaces three warnings: `71b3e9b0…` vs `4ab7b670…` for the new pre-ABC bucket, confirming drift is already present mid-yosys (i.e., not only ABC). Two supporting plumbing changes ride along: * `MODULE.bazel` gains `patches =` on the bazel-orfs `git_override`, pointing at the new `patches/bazel-orfs/` directory. The first vendored patch teaches `orfs_generate_metadata` to pull synth's outputs in via `data =` — without it the post-ABC `synth__netlist__hash` lands as `N/A` because `1_2_yosys.v` isn't otherwise in the metadata action's sandbox. Vendoring here keeps small bazel-orfs fixes in this PR while we iterate; when the patch lands upstream, drop the entry and bump `BAZEL_ORFS_COMMIT`. * `flow/README.md` "Triaging a failing `_test`" bucket #2 is rewritten to document the three-way bisection. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

…ersion compare The previous three-way `synth__*_netlist__hash` diagnostic on asap7/uart fired all three warnings, but the canonical-RTLIL header diff turned out to be dominated by a yosys version skew: `tools/install/yosys` reported `Yosys 0.63`, the bazel-pinned yosys reported `Yosys 0.65` (BCR PR registry override), and the `tools/yosys` submodule was at the v0.64 release commit — three versions across three places. Without surfacing the versions in `rules-base.json`, the version skew is invisible to `checkMetadata.py` and easy to misread as non-determinism. Two changes: * Add `synth__yosys__version` and `synth__abc__version` literal warning-level rule entries. - yosys version: `extractTagFromFile` on `1_2_yosys.log` line 1 (the yosys banner), regex `^Yosys (\S+)`. - abc version: `synth_preamble.tcl` runs `yosys-abc -c "version; quit"` via `exec` using the `YOSYS_EXE` env var that `flow/scripts/variables.mk` exports, extracts the "UC Berkeley, ABC <ver>" line and `puts` it to the same log; `genMetrics.py` extracts via `extractTagFromFile`. Now `[WARN] synth__yosys__version differs test: 0.65 == 0.63` appears directly above the netlist-hash warnings whenever the underlying binaries diverge. * Bump `tools/yosys` submodule from `8449dd470` (v0.64 release) to `b85cad634` (v0.65 release, fetched from github.com/YosysHQ/yosys.git since The-OpenROAD-Project fork hasn't synced 0.65 yet). `flow/designs/asap7/uart/rules-base.json` is regenerated from `make … metadata update_rules` against the fresh `tools/install/yosys` 0.65 build, so the baseline hashes belong to make-yosys-0.65 rather than the previous 0.63 build. Several timing thresholds tighten by ~30% (`cts__timing__setup__tns` -1190 → -826, `finish__timing__setup__ws` -46.9 → -35.8 etc.) — that's yosys 0.65's better QoR over 0.63, not a regression. Same-version verification: `tools/install/yosys/bin/yosys -V` and `bazel-out/.../external/yosys+/yosys -V` both report `Yosys 0.65`; `synth__yosys__version` and `synth__abc__version` both pass on bazel `_test`. But the three netlist hashes *still* differ — `cff062a8…` vs `51e1c96c…` on canonical, etc. A line-level diff on the canonicalize RTLIL (`autoidx 5145` is identical on both sides) shows a systematic `+3` offset on the `$<N>y` wire-counter names, indicating the bazel build performs ~3 extra wire-create operations earlier in the front-end that the make build does not. This is real bazel-vs-make build- environment non-determinism in yosys 0.65, distinct from the version skew that caused the earlier confusion. Next investigation should narrow which canonicalize step (`read_design_sources` / `hierarchy -check` / `opt_clean -purge`) contributes the +3 wires. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

The earlier three-way hash (`canonical`, `preabc`, `netlist`) showed all three differing between bazel-yosys and make-yosys even at matching versions (Yosys 0.65, ABC 1.01), but couldn't pinpoint which yosys pass introduces the drift. This commit adds three more hash points to bisect: post_read_sources : after `read_design_sources` (verilog/slang frontend only) post_hierarchy : after `hierarchy -check -top` (elaboration order) canonical_netlist : after `opt_clean -purge` (existing) post_synth_main : after `synth -run fine: -noabc` (main synth pipeline) preabc_netlist : immediately before `abc` (existing) netlist : post-ABC `1_2_yosys.v` (existing) Mechanism: `synth_preamble.tcl` defines a `write_state_hash` tcl proc that `setattr -unset src */mod` (so paths in src attributes don't make the hash bazel-vs-make path-dependent), `write_rtlil` to a temp, sha1sum, deletes the temp, and `puts` a `<metric>: <sha>` line to the yosys log. `genMetrics.py` greps the lines via `extractTagFromFile`. No new bazel artifacts ship; the existing `1_1_yosys_canonicalize.log` / `1_2_yosys.log` carry the SHAs. The `setattr -unset src` strip is now unconditional (the `SYNTH_REPEATABLE_BUILD`-gated block in `synth_canonicalize.tcl` becomes redundant since `write_state_hash` strips on first call; left in place as harmless idempotent backup). Src attributes are debug metadata that no downstream pass relies on for decisions. Verification on asap7/uart with same-version yosys/ABC on both sides: [INFO] synth__yosys__version pass test: 0.65 == 0.65 [INFO] synth__abc__version pass test: 1.01 == 1.01 [WARN] synth__post_read_sources__hash differs test: 39c975e8... == fc8ed9cc... [WARN] synth__post_hierarchy__hash differs test: 39c975e8... == fc8ed9cc... [WARN] synth__canonical_netlist__hash differs test: c1269aa7... == 579a132d... [WARN] synth__post_synth_main__hash differs test: 0cb19660... == 022a854d... [WARN] synth__preabc_netlist__hash differs test: 49c7bd07... == 6a40bd28... [WARN] synth__netlist__hash differs test: 5ed342e4... == c3163e94... Two findings fall out: 1. Non-determinism is born at `post_read_sources`. `hierarchy -check` is a no-op for uart (slang has already elaborated the top); `post_hierarchy` matches `post_read_sources` exactly on both sides. Every subsequent pass (opt_clean, synth pipeline, techmap+dfflibmap, ABC) faithfully propagates the entering divergence but does not introduce new divergence between bazel and make. 2. The slang frontend call is therefore the proximate site of the drift. Mechanism is consistent with yosys' pointer-keyed `IdString`/`dict` iteration: different memory layouts in the bazel-built and make-built yosys binaries assign different counter values to anonymous wires (visible as systematic `+3` offsets in `$<N>y` wire names in the canonical RTLIL diff). Next investigation: which yosys API call in `read_slang`'s implementation allocates IdStrings/dicts/pools in pointer order? That's the patch site. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Flip `blender = True` once, globally, in flow/designs/design.bzl's design() wrapper. Every design routes through this single funnel, so this is the only ORFS-side line that changes. Two small bazel-orfs patches make the global flip safe: 0002-blender.bzl-export-blender_supports_pdk-predicate.patch Exposes `blender_supports_pdk(pdk)`. Lets callers ask "does this PDK have a BlenderGDS stackup?" without provoking the loud fail() in _pdk_to_blendergds (which we keep — it's a useful guard for anyone calling orfs_blender() directly with a bogus PDK). 0003-orfs_design.bzl-forward-blender-silently-skip-unsupp.patch Adds a `blender = False` parameter to orfs_design() and forwards it to orfs_flow(). When True but the design's PDK is unsupported (asap7, nangate45, …) the request silently downgrades to False, so no `_blender*` targets are declared and @blender / @blendergds are never referenced by analysis. Confirmed behaviour after these patches: * `bazelisk query //flow/designs/sky130hd/gcd:all` shows the 5 `gcd_final_blender*` targets (sky130hd is supported). * `bazelisk query //flow/designs/asap7/gcd:all` shows none of them (asap7 has no BlenderGDS stackup — silent skip). * `bazelisk query 'tests(//flow/designs/sky130hd/gcd:all)'` returns only `gcd_test` — `tags = ["manual"]` keeps the blender targets out of `bazelisk test //...` wildcards. `bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html` runs the full physical-design flow to completion and then fails at the orfs_gds klayout-merge step (klayout looks up klayout_tech.lef under the non-sandbox execroot rather than the active processwrapper sandbox). That failure is in bazel-orfs's orfs_gds rule and surfaces because orfs_blender exercises orfs_gds with the host PATH klayout for the first time on this design; it is independent of these patches and will be triaged separately. bazel-orfs patches are vendored under patches/bazel-orfs/ via the existing git_override(patches=…) mechanism. Upstreaming is deferred until the orfs_gds klayout-merge issue is sorted out, to minimise bazel-orfs churn. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

os.path.realpath() follows symlinks. Inside a Bazel sandbox, the bazel-out/ tree is symlinked from the sandbox back to the bare execroot; realpath resolves through that symlink and yields the bare-execroot path, not the sandbox path. That alone doesn't matter for os.path.relpath(a, b) when both operands are realpath'd from the same sandbox — the relative result is unchanged. But the resulting <lef-files> path in the generated klayout.lyt is later resolved by klayout against the LYT file's location. Klayout opens the LYT (also through a symlink), resolves through to the bare execroot, and then looks for the sibling klayout_tech.lef at the bare-execroot path — where the in-flight file does not exist during action execution (only the sandbox copy does), so def2stream fails with errno=2. Fix: don't realpath. os.path.relpath produces the correct relative path from sandbox-relative inputs directly. Map files keep their absolute form via abspath for the unchanged-under-non-sandbox case. Surfaced for the first time on bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html — the orfs_blender macro is the first bazel-side consumer of orfs_gds (klayout def2stream), so the latent path bug had no prior trigger. Mirrors bazel-orfs's patches/0037-fix-generate_klayout_tech-drop-realpath.patch into ORFS directly so bazel-orfs no longer needs to carry it. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

@orfs

flow/BUILD has \`load(\"@bazel-orfs//:openroad.bzl\", \"orfs_pdk\")\`, which requires @bazel-orfs to be a visible bazel_dep of @orfs even when @orfs is consumed as a non-root module (e.g. by tools/OpenROAD). With dev_dependency = True the bazel_dep is a no-op at non-root consumption and the load() fails. The companion git_override(bazel-orfs, …) is implicitly root-only by Bazel semantics — non-root modules' override directives are silently ignored — so dropping dev_dependency = True does not leak our local pin into downstream consumers; their own bazel-orfs pin still wins. Other dev_dependency = True bazel_deps (openroad, qt-bazel, yosys-slang, bazel-orfs-verilog, toolchains_llvm) are unaffected — none of @orfs's own BUILD files load() from them; the existing load() callers (tools/OpenROAD/src/gui/BUILD, etc.) live in downstream packages that bring their own bazel_deps. Mirrors bazel-orfs's patches/0036-fix-bazel-orfs-bazel_dep-non-dev-for-load-visibility.patch into ORFS directly so bazel-orfs no longer needs to carry it. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

The previous switch to relpath (commit 01652ca) cleaned up the content but did not actually fix def2stream's errno=2 under a Bazel sandbox. Investigation via strace shows klayout's Layout.read(def, layout_options) opens the input DEF (a sandbox symlink to the bare execroot, staged from orfs_final), realpath's it to the bare-execroot results dir, and then resolves <lef-files> relative paths against THAT dir. Sibling intermediates like objects/klayout_tech.lef only exist in the per-action sandbox, not at the bare execroot, so the lookup lands at .../execroot/_main/bazel-out/.../klayout_tech.lef and fails with errno=2. Declaring klayout_tech.lef as a Bazel output of orfs_gds doesn't help -- Bazel only materialises declared outputs at the bare execroot at action completion, not while the action is still running and klayout is reading them. Plain abspath (NOT realpath -- realpath would chase Bazel input-file symlinks back out to the bare execroot for any input already at the bare execroot) writes the in-sandbox absolute LEF path into the LYT. KLayout opens that absolute path directly with no relative-path resolution involved, so the sibling lookup never escapes the sandbox. Cost: the LYT's content now embeds the per-invocation sandbox number, so the orfs_gds action cannot be cross-action cached. That's an acceptable trade-off for correctness while we wait for a klayout-level fix or a Bazel feature that lets us write a stable bare-execroot path from inside the action. Confirmed end-to-end: bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html produces 6_final.gds and the blender_html sh_binary, with both the sandbox sandbox-id N going forward and after fresh action re-runs (verified by deleting outputs and rebuilding). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Picks up: 68b3d4e orfs_synth_rule: propagate synth args via OrfsInfo.arguments aeec6aa make-yosys-netlist: clear VERILOG_FILES on the re-synth bazel run 993a12c make.tpl: guard export YOSYS_EXE when YOSYS_PATH unsubstituted (5b65b4e on bazel-orfs is a rewrite of our previous pin c000cb3 with the same subject; no diff against the previous pinned tree for the files our vendored patches touch.) All three vendored bazel-orfs patches (0001..0003) apply cleanly against the new pin. None of the picked-up commits change orfs_gds or klayout-related code paths -- the def2stream errno=2 fix lives in ORFS (previous commit, generate_klayout_tech: write absolute LEF paths). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Vendors a new bazel-orfs patch (0004) that propagates the design's per-stage source files through the orfs_final -> orfs_gds chain. Without this, orfs_gds (which orfs_blender invokes standalone with src=orfs_final and no data=) gets 6_gds.args.mk's ADDITIONAL_LEFS correctly populated via OrfsInfo.arguments, but the actual LEF files are missing from the sandbox. klayout's def2stream then fails with errno=2 on the very first read, e.g. on microwatt: RuntimeError: Unable to open file: .../sandbox/.../execroot/_main/flow/designs/sky130hd/microwatt/lef/Microwatt_FP_DFFRFile.lef The patch adds ctx.attr.src[OrfsDepInfo].files to source_inputs()'s transitive list. OrfsDepInfo.files is the per-stage tuple of (config + ctx.files.src + ctx.files.data + extra_configs) without the stage's logs/reports, so propagating it carries the design's ADDITIONAL_LEFS / ADDITIONAL_GDS source files forward but avoids read-only-log collisions in the next stage's sandbox. (Tried DefaultInfo.default_runfiles.files first — it includes the previous stage's logs and the next stage's write to logs/.../6_1_merge.log fails with Permission denied.) Verified end-to-end: - bazelisk build //flow/designs/sky130hd/gcd:gcd_final_blender_html still succeeds (no macros — regression check). - bazelisk build //flow/designs/sky130hd/microwatt:microwatt_final_blender_html now gets past orfs_gds and produces 6_final.gds (562 MB, including the four IP macros: Microwatt_FP_DFFRFile, RAM32_1RW1R, RAM512, multiply_add_64x64). Subsequent BlenderGDS html-export step fails for microwatt — separate issue, Blender appears to choke on the merged-GDS size — but that is downstream of the klayout/def2stream lookup this patch addresses. Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Earlier commit a1552a8 switched generate_klayout_tech.py to write absolute LEF paths into the LYT (bypasses klayout's relative-resolution escape to the bare-execroot under a Bazel sandbox). The unit test test_basic_generation still asserted the old relpath form and failed in CI: AssertionError: '../tech.lef' not found in '...<lef-files>/tmp/tmpwlgkq96a/tech.lef</lef-files>...' Update the assertion to expect os.path.abspath(lef_path). Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Iterating on microwatt_final_blender_html on PR The-OpenROAD-Project#4231. Three prior attempts on this same vendored patch surfaced (and fixed) successive gltf-export failures via the new phase logging: iter 1 ("appears to choke") -> phase logs pinpointed int32 overflow in gltf2 exporter's corner_normals.foreach_get for a single 9.3M- polygon mesh. Fixed by passing `export_normals=False`. iter 2 -> phase logs pinpointed the GLB 4 GB single-file ceiling on the binary container header (gltf2_io_export.save_gltf: struct.pack("I", length)). Fixed in iter 3 with a hardcoded sky130-specific drop set (licon, li1, mcon, met1, all vias) gated by `total_polys > 30_000_000`. iter 3 -> build succeeded, GLB 2.17 GB / HTML 2.89 GB. Build green but overshoots the ~2 GB per-tab memory cap mainstream browsers enforce, so the html target builds but won't load. This iteration generalises the iter-3 drop into a dynamic heuristic: rank meshes by polygon-count × bytes-per-poly (calibrated from iter 3 data: 39.7M polys -> 2.17 GB GLB -> ~55 b/poly, rounded up to 60), drop biggest first until the estimated GLB binary is ≤ 150 MB. That's ~10% of the 2 GB browser-tab cap with base64-inflation margin -- bling- and-fun loadable. Heuristic is layer-name agnostic, so non-sky130 PDKs work the same way; gcd-class designs (<1M polygons) already fit under the budget so the loop is a no-op for them. Phase log records the drop list + estimated post-trim GLB (`budget-trimmed` line) so the next iteration can recalibrate _GLB_BYTES_PER_POLY if the empirical ratio drifts on another design. A successful microwatt_final_blender_html bazelisk run on top of this patch validates the budget-cap path. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

…bump PR-4231-head/14 Jenkins QoR check flagged 14 designs whose post-CTS, post-globalroute, post-finish timing or routing metrics drifted by more than the rules-base.json thresholds. Every failing metric corresponds to a change in the synth/place/route path driven by: * tools/OpenROAD: 08f67ee5ec -> b0a6f2956a (engine code refresh on this PR's submodule pointer) * tools/yosys: b85cad6347 -> 8449dd4700 (the yosys 0.65 bump the PR's title commit makes -- new synthesis result -> different post-synth structure -> downstream timing/routing follows). The drifts are all in the direction expected from a tool refresh: more buffers, looser slack, more routing wirelength, more antenna diodes. None of them block last-stage completion -- per the Jenkins summary every design "Flow reached last stage" and only the rules check fails. Update each failing metric's threshold in rules-base.json to the actual PR-4231-head/14 value (sourced from .../PR-4231-head/14/artifact/reports/<plat>/<design>/base/metadata.json), rounded to the existing precision and slackened by one tick in the worse direction so noise margin matches the prior calibration. Only the failing metrics are touched; every other rule keeps its existing threshold so tight metrics stay tight. Designs touched (and the metric kinds that moved): asap7/aes-block cts setup ws+tns asap7/ethmac_lvt cts/gr/finish setup ws+tns asap7/riscv32i cts setup tns asap7/swerv_wrapper finish hold tns nangate45/ariane133 cts/gr/finish setup tns nangate45/bp_fe_top finish setup tns nangate45/swerv_wrapper cts setup tns, finish setup ws sky130hd/chameleon cts/gr/finish setup ws, dr antenna_diodes sky130hd/gcd cts buf+setup tns, gr setup ws+tns, dr wirelength, finish setup ws+tns sky130hd/ibex gr setup tns sky130hd/microwatt gr+dr antenna_diodes_count sky130hd/riscv32i cts/gr/finish setup tns, dr wirelength sky130hs/jpeg gr antenna_diodes_count sky130hs/riscv32i gr/finish setup tns, finish setup ws The Jenkins run is deterministic on these metrics (per the qor-baseline-workflow note: master-vs-master values agree to 6 decimals), so taking the PR run's value as the new baseline does not just paper over noise -- it reflects the real new operating point of the bumped toolchain. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Run `bazelisk run @bazel-orfs//:bump` to advance the pin from the oharboe/yosys-netlist-wrapper-fixes side branch (68b3d4e) to current upstream main (ef90d6c). All five vendored patches (0001..0005) re-apply cleanly against the new tree -- none of them landed upstream in this window: 0001 flow.bzl: pull synth into generate_metadata data deps 0002 blender.bzl: export blender_supports_pdk predicate 0003 orfs_design.bzl: forward blender, silently skip unsupported 0004 environment.bzl: pull src OrfsDepInfo.files into source_inputs 0005 render_gds.py: phase logging + dynamic drop-to-GLB-budget `bazelisk query //flow/designs/sky130hd/microwatt:microwatt_final_blender_html` succeeds after the bump, so MODULE.bazel resolution still produces the expected target with all patches in place. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Two formatter-only fixes the GitHub Actions Lint workflows flagged on PR The-OpenROAD-Project#4231 ("lint" Python/black and "Tclint" Tcl/tclfmt jobs): flow/util/genMetrics.py Two `for metric in (...)` tuples were wrapped across two lines; black 26.5 folds them onto a single line. No semantic change. flow/scripts/synth_preamble.tcl tclfmt 0.7.0 re-indents the `if { [catch { ... } _err] } { ... }` block onto a multi-line `if {` form with 4-space body indentation; the original used a 2-space body inside `[catch { ... }]`. No semantic change. Both files come from earlier commits on this branch: 3e57288 flow: drill down — non-determinism enters in read_design_sources (introduced the genMetrics.py loops and the synth_preamble.tcl catch block) Re-running the formatters locally produces no further diffs: black --check flow/util/genMetrics.py -> 1 unchanged tclfmt --check flow/scripts/synth_preamble.tcl -> clean tclint flow/scripts/synth_preamble.tcl -> clean Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Iter 5 of microwatt_final_blender_html crashed at gdsii-imported with `NameError: name 'bpy' is not defined` -- the after-Blender heuristic in iter 4 was a module-level function but bpy is only imported inside main() (Blender requires that under --background). Quick fix would be `import bpy` inside the helper, but the deeper problem the user flagged is that an after-import drop is the wrong place for the trim anyway: Blender spends ~5-7 min and ~16 GB RSS extruding all 17 layers and we then throw most of them away seconds later. Redesign: trim the addon's bundled layerstack YAML before invoking `bpy.ops.import_scene.gdsii`. The addon iterates `for layer_name, data in layerstack.items()` and calls `create_extruded_layer` per entry, so dropping entries from the YAML cuts the per-layer extrusion cost to zero for the dropped layers -- never paid, not refunded. The new flow is: addon-registered layerstack-trimmed (write trimmed.yaml; addon picks it up via gdsii_use_custom_config + gdsii_config_path) gdsii-imported (now only kept-layer meshes are built) gltf-export html-write Bling-and-fun preset (sky130-only for now): substrate `nwell` plus the topmost two metal layers + the via stack between them (`met3`, `via4`, `met4`, `met5`). Drops licon, li1, mcon, met1, via, via2, via3, met2, diff, poly wholesale. Effect on microwatt sky130hd: ~26M input polygons -> ~200K Blender per-layer extrusion ~5-7 min + 16 GB RSS -> seconds, < 1 GB GLB binary ~10 GB raw -> < 80 MB base64-embedded HTML ~13 GB nominal -> < 110 MB Comfortably inside any browser tab's working memory. PDKs without a preset fall through to the addon's default unfiltered stack -- gcd-class designs already fit so this is a no-op for them; larger non-sky130 designs would surface as the next iteration of phase logs and we add a preset for them then. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

…pstream All five vendored bazel-orfs patches (0001..0005) landed upstream in this bump window, in the same order with matching subjects: 1f4f12e flow.bzl: pull synth into generate_metadata data deps b3b19b0 blender.bzl: export blender_supports_pdk predicate 4b3ae0 orfs_design.bzl: forward blender, silently skip unsupported PDKs f4e25a3 environment.bzl: pull src OrfsDepInfo.files into source_inputs 3a5ddd7 render_gds: trim layerstack before Blender import for fast-turnaround viewer Drop them all -- `git apply --check --reverse` confirms 0001..0004 match upstream exactly, and 0005's upstream version is the same patch modulo a small context drift that doesn't matter once the patch isn't re-applied locally. patches/bazel-orfs/ goes away entirely. `bazelisk query //flow/designs/sky130hd/microwatt:microwatt_final_blender_html` succeeds after the change, so MODULE.bazel resolution still produces the expected target with no vendored patches. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Bumping bazel-orfs to 3a5ddd7 picked up the upstream copy of our layerstack-trim feature, but the upstream commit landed without the PDK_CONFIGS monkey-patch fix that I added locally after upstream sent the PR -- so the merged version still goes through the addon's gdsii_use_custom_config=True path, which is broken: File ".../blendergds/__init__.py", line 613, in import_gdsii colorfile = addon_dir / pdk_info.get('color_path', ...) / ... UnboundLocalError: cannot access local variable 'pdk_info' The addon's import_gdsii skips initialising pdk_info / addon_dir in the custom-config branch but uses them a few lines later for the color_path lookup. Vendor a one-hunk patch on render_gds.py that monkey-patches addon.PDK_CONFIGS[pdk]['config_path'] instead, so the addon's else branch fires normally. Path's absolute-RHS semantic makes `addon_dir / Path(abs_path)` evaluate to the absolute path, so the trim YAML still resolves correctly. Once a fix lands upstream (in bazel-orfs or in the BlenderGDS addon's __init__.py), this can be dropped and bazel-orfs bumped again -- the patches/ directory comes back if we need a vendored fix in the meantime. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com> Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

fix make issue missing variables

2669d02

Signed-off-by: Augusto Berndt <augusto.berndt@precisioninno.com>

github-actions Bot force-pushed the update-yosys branch from 649ad00 to 7fd3e25 Compare May 15, 2026 13:25

Merge pull request The-OpenROAD-Project#4230 from The-OpenROAD-Projec…

69ae727

…t-staging/secure-fix-variables fix make issue missing variables

github-actions Bot force-pushed the update-yosys branch 5 times, most recently from deb77ba to 970c76a Compare May 16, 2026 13:13

Merge pull request The-OpenROAD-Project#4232 from oharboe/netlist-has…

2f6e9c9

…h-diagnostic Netlist hash diagnostic

github-actions Bot force-pushed the update-yosys branch 9 times, most recently from ef0a4c2 to 224da8f Compare May 17, 2026 18:37

oharboe and others added 12 commits May 17, 2026 20:42

oharboe added 6 commits May 17, 2026 20:43

github-actions Bot force-pushed the update-yosys branch from 224da8f to 176748f Compare May 17, 2026 18:59

github-actions Bot force-pushed the update-yosys branch 2 times, most recently from 67f7911 to 8da94f7 Compare May 17, 2026 20:17

github-actions Bot force-pushed the update-yosys branch from 8da94f7 to 756eadb Compare May 17, 2026 20:37

github-actions Bot force-pushed the update-yosys branch from 756eadb to b654bdb Compare May 17, 2026 21:38

oharboe and others added 2 commits May 18, 2026 00:07

[BOT] Update yosys submodule

5f54eba

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

github-actions Bot force-pushed the update-yosys branch from b654bdb to 5f54eba Compare May 17, 2026 22:09

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update yosys submodule#45

Update yosys submodule#45
github-actions[bot] wants to merge 26 commits into
netlist-hash-diagnosticfrom
update-yosys

github-actions Bot commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

github-actions Bot commented May 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants