[DO NOT REVIEW] yosys 0.65 + bazel-orfs bump + sweep/yosys-idempotency README — investigation record

[oharboe]

Summary

Record of a sweep-and-triage session across asap7 + sky130hd to validate the
@bazel-orfs//:make-yosys-netlist workflow and surface upstream-fixable
bugs. Stops short of a clean classification because of a hierarchical-PDN
gap in bazel-orfs for BLOCKS= designs (see "Open" below) — we hold further
QoR/idempotency work until ABC catches up to yosys 0.65 upstream.

Commits

1. flow/README.md: document host-aware sweep + yosys-idempotency triage
   — restores the sweep recipe and the failing-_test triage decision tree
   that previously lived on an abandoned branch. References
   @bazel-orfs//:yosys-check / @bazel-orfs//:make-yosys-netlist and
   defers to @bazel-orfs//:TESTING.md for the full classification matrix.

2. bazel: bump yosys to 0.65 via BCR PR registry override — points
   .bazelrc at oharboe's fork branch for
   bazelbuild/bazel-central-registry#8863
   (adds yosys 0.65 to BCR) and forces yosys resolution to 0.65 via
   single_version_override so it overrides bazel-orfs's 0.63 pin.
   Fixes the WRAPCELL/RTLIL-identifier memory corruption on 0.63 that
   produced garbage like '\<random>_KOGGE_STONE' in cva6/ibex/riscv32i
   synthesis on the asap7 platform.

3. bazel: bump bazel-orfs to c000cb3 (user_sources= is upstream) —
   user_sources= is now in bazel-orfs main; drop the local patch.

Verified during the session

• yosys 0.65 fixes the WRAPCELL garbage: cva6_synth builds clean
  (ALU_64_0_64_0_64_KOGGE_STONE, etc. — no control characters).
• aes-block builds end-to-end via the classic make flow.

Open

• aes-block still fails [ERROR PDN-0233] Failed to generate full power grid
  via bazel-orfs even with abstract_stage=\"final\" for sub-blocks (tested
  and reverted in this session). Root: bazel's sub-block abstract has
  OBS LAYER M5 ; RECT 0 0 9.144 9.144 ; covering the full macro, while
  make's leaves M5 channels open. Compounded by sub-block size delta
  (9.144 vs 9.235 µm) driven by yosys-version cell-count differences.
  This is a real bazel-orfs bug for hierarchical (BLOCKS=) designs;
  diagnosis on hand, fix pending.
• Three independent bazel-orfs wrapper fixes for make-yosys-netlist
  phase-3 re-synth are queued at
  The-OpenROAD-Project/bazel-orfs#734.
  Phase-3 still doesn't complete end-to-end (SDC source files aren't in
  orfs_final's runfiles) — needs a follow-up to bundle synth source
  inputs into downstream runfiles.
• WNS drift between yosys 0.63 and 0.65 with ABC not bumped in lockstep
  is the reason this PR doesn't try to classify the 7 QoR-failing designs
  via make-yosys-netlist — wait for ABC sync upstream before re-running.

Resuming

Once ABC catches up upstream and the BLOCKS PDN gap is fixed:

• Bump bazel-orfs pin past the wrapper fixes (TORP/bazel-orfs#734) +
  the BLOCKS fix.
• Re-run the sweep (flow/README.md recipe) and the classification
  (make-yosys-netlist per failing _test).

Test plan

• bazelisk test //flow/designs/asap7/cva6:cva6_synth builds clean
  with yosys 0.65 (was the canonical WRAPCELL-garbage repro on 0.63).
• cd flow && make finish DESIGN_CONFIG=designs/asap7/aes-block/config.mk
  produces full 6_final.{def,gds,odb,sdc,spef,v} chain — confirms the
  bazel-orfs PDN failure is build-infrastructure, not design.
• Full sweep classification — held pending ABC bump.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the bazel-orfs dependency to a newer commit, removes a local patch that has likely been upstreamed, and forces the yosys version to 0.65 to address memory corruption issues. Additionally, it expands the flow/README.md with detailed instructions for running full test sweeps and triaging test failures. A review comment identifies a security and stability concern regarding the use of a personal GitHub fork as a Bazel registry in .bazelrc, suggesting the use of git_override or archive_override as a more robust alternative.

[gemini-code-assist]

Using a raw GitHub URL from a personal fork as a Bazel registry is insecure and fragile. It bypasses the official BCR's trust model and makes the build dependent on the availability and state of a specific branch in a third-party repository. For testing a pending BCR update, a more robust and secure approach is to use git_override or archive_override (with an integrity hash) for the yosys module in MODULE.bazel. This keeps the override localized to the project and avoids the need for global registry modifications.