yosys@0.65 by oharboe · Pull Request #8863 · bazelbuild/bazel-central-registry

oharboe · 2026-05-13T08:06:07Z

Adds yosys 0.65 to BCR.

Overlay changes vs 0.64 for v0.65 source layout:

VERSION = "0.65" in overlay/BUILD.bazel.
New kernel header kernel/wallace_tree.h added to kernel hdrs.
New passes/techmap/arith_tree.cc added to pass_techmap srcs.
New passes/techmap/liberty_cache.h added to pass_techmap hdrs.
Inner and outer MODULE.bazel version bumped to 0.65.

Patches:

tcl9_mp_to_ubin.patch — applies clean (verbatim from 0.64).
use_cxxopt_module.patch — applies clean (verbatim from 0.64).

source.json refreshed: v0.65 tarball integrity + new sha256s for
BUILD.bazel and overlay/MODULE.bazel.

Local verification: bazelisk run @yosys//:yosys -- -V against this
fork branch as a custom registry prints Yosys 0.65.

tools/bcr_validation.py --check yosys@0.65 passes all checks.

Stacks on top of #8862 (yosys@0.64) — metadata.json edit may need
rebase once #8861/#8862 land.

Upstream release notes:
https://github.com/YosysHQ/yosys/releases/tag/v0.65

bazel-io · 2026-05-13T08:06:34Z

Hello @UebelAndre, modules you maintain (yosys) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

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>

UebelAndre · 2026-05-26T14:54:35Z

Rebase needed 😄

Adds yosys 0.65 to BCR. Overlay changes vs 0.64 for v0.65 source layout: - `VERSION = "0.65"` in `overlay/BUILD.bazel`. - New kernel header `kernel/wallace_tree.h` added to kernel `hdrs`. - New `passes/techmap/arith_tree.cc` added to `pass_techmap` srcs. - New `passes/techmap/liberty_cache.h` added to `pass_techmap` hdrs. - Inner and outer `MODULE.bazel` version bumped to 0.65. Patches: - `tcl9_mp_to_ubin.patch` — applies clean (verbatim from 0.64). - `use_cxxopt_module.patch` — applies clean (verbatim from 0.64). source.json refreshed: v0.65 tarball integrity + new sha256s for BUILD.bazel and overlay/MODULE.bazel. `tools/bcr_validation.py --check yosys@0.65` passes all checks. Stacks on top of bazelbuild#8862 (yosys@0.64) — metadata.json edit may need rebase once bazelbuild#8861/bazelbuild#8862 land. Upstream release notes: https://github.com/YosysHQ/yosys/releases/tag/v0.65 Signed-off-by: Øyvind Harboe <oyvind@ascenium.com>

v0.65 carries v0.64's work-steal queue with the same unconditional std::unique_lock use outside YOSYS_ENABLE_THREADS. Mirror PR bazelbuild#8862's threading_includes.patch fix here so non-threaded gcc 13+ builds compile. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com>

The gcr.io/bazel-public/ubuntu2404:latest image was republished today (2026-05-26 11:20:08Z) as a single-arch amd64 manifest, causing arm64 runners to fail with `[FATAL tini (7)] exec /bin/sh failed: Exec format error` before any yosys code is fetched. Re-add via a yosys@0.65.bcr.1 once the multi-arch image is restored. Signed-off-by: Øyvind Harboe <oyvind@ascenium.com>

oharboe · 2026-05-26T15:35:20Z

@UebelAndre — dropped ubuntu2404_arm64 from the matrix in e1712cb so CI can go green.

Background: every ubuntu2404_arm64 job on this PR fails immediately with:

WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[FATAL tini (7)] exec /bin/sh failed: Exec format error

(Example: https://buildkite.com/bazel/bcr-presubmit/builds/35045#019e64d2-2a31-4bce-b5ed-868f6e9a8924)

The container can't start, so no yosys code is fetched.

Root cause is in gcr.io/bazel-public/ubuntu2404, not in this module. Querying the GCR manifest API directly:

Image	Current `:latest` manifest type
`gcr.io/bazel-public/ubuntu2004`	`oci.image.index.v1+json` (multi-arch, amd64+arm64) ✓
`gcr.io/bazel-public/ubuntu2204`	`oci.image.index.v1+json` (multi-arch, amd64+arm64) ✓
`gcr.io/bazel-public/ubuntu2404`	`manifest.v2+json` (single amd64) ✗

:latest for ubuntu2404 was repointed today (2026-05-26 11:20:08Z) from a multi-arch index to a single-arch amd64 manifest (digest sha256:1ddeef44784bb...). For ~13 months prior (2025-04 → 2026-02) it was correctly multi-arch — see the orphaned indexes still in the GCR tag list. Most likely a bazelbuild/continuous-integration Create Linux Docker Images pipeline run today produced an amd64-only image (the build.sh --load --platform=linux/amd64,linux/arm64 pattern silently degrades to host-arch-only without containerd-image-store enabled) and push.sh overwrote :latest.

Plan to restore arm64-on-24.04 coverage once gcr.io/bazel-public/ubuntu2404:latest is multi-arch again: cut yosys@0.65.bcr.1 re-adding ubuntu2404_arm64 to the matrix, or just include it in 0.66 if YosysHQ ships that release first.

UebelAndre · 2026-05-26T15:40:52Z

@meteorcloudy @Wyverald re: #8863 (comment)

Seems these images were recently broken?

@bazel-io

Adds `abc@0.65-yosyshq`, pairing with `yosys@0.65` (whose BCR module is in PR #8863). YosysHQ/yosys at tag `v0.65` pins its `abc` submodule at YosysHQ/abc tag `v0.65`, peeled SHA `5d51a5e420f5de493d07bf61109a977248c86ffb`. This module exposes that tag as a BCR-resolvable dependency. Based on `abc/0.64-yosyshq.bcr.1`. The BUILD.bazel overlay additionally lists: - `src/map/emap/{emap.c, emapCore.c}` — new mapper module in v0.65 - `src/opt/eslim/{areaEngine,delayEngine,eslimCirMan,relationSynthesiser,subcircuit}.cpp` — new sources in the existing `eslim` directory - `src/proof/cec/cecCorrIncr.c` — new source in the existing `cec` directory and adds `src/map/emap` to the `includes` list so files in that directory can resolve `#include "emap.h"`. @bazel-io skip_check unstable_url

oharboe · 2026-05-26T16:58:53Z

@UebelAndre Do we need arm ubuntu 24 for this PR?

Perhaps we can just pick it up in the yosys 0.66 release. It is only two weeks away or so?

oharboe · 2026-05-29T05:45:51Z

@UebelAndre Do you need anything more from me?

0.66 isn't that far away, the main use-case for this version is presumably testing or to get unstuck on some new problem that 0.66 introduced, so can we merge this as is without the broken arm platform?

oharboe · 2026-05-30T07:09:09Z

@UebelAndre Closing since there's no activity, let me know if I should re-open.

@maliberty FYI if you need 0.65 you can wire up this closed PR until a newer version becomes available.

UebelAndre · 2026-05-30T15:25:48Z

@UebelAndre Closing since there's no activity, let me know if I should re-open.

@maliberty FYI if you need 0.65 you can wire up this closed PR until a newer version becomes available.

Sorry, I was gone for a few days. The change seems fine but I want to know if there's a bug in the runners first before removing the coverage.

oharboe · 2026-06-01T06:13:45Z

@UebelAndre Closing since there's no activity, let me know if I should re-open.
@maliberty FYI if you need 0.65 you can wire up this closed PR until a newer version becomes available.

Sorry, I was gone for a few days. The change seems fine but I want to know if there's a bug in the runners first before removing the coverage.

Makes sense.

Please re-open this PR if you want to move forward with it.

oharboe mentioned this pull request May 18, 2026

bazel: enable Blender 3D-viewer targets on every supported-PDK design The-OpenROAD-Project/OpenROAD-flow-scripts#4235

Merged

4 tasks

oharboe added 2 commits May 26, 2026 17:05

oharboe force-pushed the yosys-0.65 branch from c434e7c to 526241d Compare May 26, 2026 15:05

oharboe closed this May 30, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

yosys@0.65#8863

yosys@0.65#8863
oharboe wants to merge 3 commits into
bazelbuild:mainfrom
oharboe:yosys-0.65

oharboe commented May 13, 2026

Uh oh!

bazel-io commented May 13, 2026

Uh oh!

UebelAndre commented May 26, 2026

Uh oh!

oharboe commented May 26, 2026

Uh oh!

UebelAndre commented May 26, 2026

Uh oh!

oharboe commented May 26, 2026

Uh oh!

oharboe commented May 29, 2026

Uh oh!

oharboe commented May 30, 2026

Uh oh!

UebelAndre commented May 30, 2026

Uh oh!

oharboe commented Jun 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

oharboe commented May 13, 2026

Uh oh!

bazel-io commented May 13, 2026

Uh oh!

UebelAndre commented May 26, 2026

Uh oh!

oharboe commented May 26, 2026

Uh oh!

UebelAndre commented May 26, 2026

Uh oh!

oharboe commented May 26, 2026

Uh oh!

oharboe commented May 29, 2026

Uh oh!

oharboe commented May 30, 2026

Uh oh!

UebelAndre commented May 30, 2026

Uh oh!

oharboe commented Jun 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants