fix(infra): upgrade yosys 0.15 → OSS CAD Suite 2026-05-06 (closes #36) [RECOVERY of lost PR #37]#38
Merged
marcos-mendez merged 5 commits intomainfrom May 6, 2026
Conversation
added 5 commits
May 6, 2026 12:38
The cicd/Dockerfile pinned yosys-0.15.tar.gz from 2021-09-15, six years stale. Upstream yosys is at v0.64 (2026-04-09) on a monthly release cadence, and the 2023-08-31 unification commit moved synth_ecp5 into a thin wrapper around `synth_lattice -family ecp5`. None of that landed in 0.15. Surfaced by Stays #33 (yosys ECP5 day-1 recon, 2026-05-06): "The MAST CI Dockerfile pins yosys 0.15 — needs upgrading to v0.64 or OSS CAD Suite latest. Trivial Stream 3 PR." Choice: Option B (OSS CAD Suite). Three options were on the table: A. Pin yosys ≥ v0.64 source-built. Smaller scope but doesn't pin compatible nextpnr-ecp5 + prjtrellis HEADs, so the image still drifts version-by-version against the rest of the open ECP5 flow. B. OSS CAD Suite tarball (CHOSEN). Single date-pinned download (2026-05-06) ships yosys v0.64 + nextpnr-ecp5 + prjtrellis + verilator + iverilog + cocotb-ext as a tested-together bundle. This is what every production open-FPGA ECP5 reference uses (OrangeCrab, Trellis Board, ULX3S, Versa-ECP5, ECPIX-5, LiteX). The Dockerfile shrinks: one wget + one tar replaces a from-source `make -j` build. C. Drop the Dockerfile entirely. Rejected: it is still referenced by `.circleci/config.yml` (8 jobs) and by `cicd/build-docker.sh`, so removing it without removing those would break legacy CircleCI consumers. The active CI is `.github/workflows/ci.yml` (GHA), but the Docker image surface is non-zero. Smoke test (proves the path works on real CI): A new GHA job `yosys-ecp5-smoke` runs: yosys -p "read_verilog -sv src/int/mul_pipeline_32bit.sv; synth_lattice -family ecp5 -top mul_pipeline_32bit; write_json /tmp/smoke/mul_pipeline_32bit.json" against `src/int/mul_pipeline_32bit.sv` (a self-contained 124-line module that does not pull in the AXI4 fabric). The job uploads the produced JSON as an artefact and prints the yosys version into the GitHub step summary. If this passes, the yosys + lattice techlib half of the rev-A open ECP5 flow is live. `src/global_mem_controller.sv` was the alternative target named in the issue, but it instantiates `axi4_mem_model` from `verif/`, which would turn the smoke into a multi-file integration test. The 32-bit multiplier exercises arith_map_ccu2c.v (carry chain) and the LUT4 path — a representative -85F primitive coverage check — without that fan-out. OSS CAD Suite URL pattern verified against the GitHub release API: tag = 2026-05-06 (created 2026-05-04) asset name = oss-cad-suite-linux-x64-20260506.tgz Refs: - Issue #36 - Stays PR #33 (Agent 4 yosys ECP5 day-1 recon) - yosys v0.64 release notes (2026-04-09) - OSS CAD Suite releases (YosysHQ/oss-cad-suite-build) Authored by Agent 1 (RTL Architect). Signed-off-by: Agent 1 (RTL Architect) <popsolutions.co@gmail.com>
mul_pipeline_32bit.sv:65 uses the `assert_known macro defined in src/assert.sv. yosys's preprocessor pulls macros only from files explicitly passed to read_verilog (no automatic include path), so the smoke command needs both files. Order matters: assert.sv first so the macro is in scope when the module body parses. Confirmed against the prior CI failure on the v0.64+187 OSS CAD Suite build: src/int/mul_pipeline_32bit.sv:65: ERROR: Unimplemented compiler directive or undefined macro `assert_known. That same yosys version DID install cleanly and report `Yosys 0.64+187 (git sha1 49b4f6d81, clang++ 18.1.8 -fPIC -O3)`, so the OSS CAD Suite upgrade itself is verified — only the smoke command was missing the macro file. Signed-off-by: Agent 1 (RTL Architect) <popsolutions.co@gmail.com>
Second smoke iteration revealed the next layer: src/int/mul_pipeline_32bit.sv:65: ERROR: Unimplemented compiler directive or undefined macro `__FILE__`. src/assert.sv's `assert_known` macro expands to `__FILE__` and `__LINE__`, which yosys's preprocessor does not support (verilog-2005 behaviour; cf. yosys#1075). iverilog and verilator do support them, so the asserts work in real verification runs — but for a synth-only smoke we just no-op the macros via `-Dassert_known(VAL)=` and `-Dassert(VAL)=`. The module body never reaches `__FILE__` / `__LINE__`. This lets the smoke prove the synth path, which is its only job: yosys reads SV → synth_lattice -family ecp5 → write_json. Signed-off-by: Agent 1 (RTL Architect) <popsolutions.co@gmail.com>
Third smoke iteration: src/int/mul_pipeline_32bit.sv:65: ERROR: Unimplemented compiler directive or undefined macro `assert_known. yosys's `-D` flag for read_verilog accepts only value macros (`-Dname=val`), not function-like macros (`-Dname(args)=val`). So the previous attempt at `-Dassert_known(VAL)=` was silently dropped. Switched to writing a tiny smoke_top.sv wrapper that: 1. `define`s assert_known and assert as no-ops before include, 2. `include`s the real module file. This is the verilog-preprocessor-canonical way of overriding macros. The wrapper lives in /tmp/smoke (build artefact), not in src/, so the RTL itself is untouched — the task brief explicitly forbids modifying RTL or test files, and we don't. Signed-off-by: Agent 1 (RTL Architect) <popsolutions.co@gmail.com>
Fourth smoke iteration: mul_pipeline_32bit.sv:81: ERROR: Can't resolve task name `\mul_pipeline_cycle_32bit_2bpc'. mul_pipeline_32bit.sv calls a task defined in another file, so it is not actually self-contained. Switched the smoke target to src/generated/dadda_32bit32.sv: 1420 lines of pure combinational logic, no module instances, no task/function calls into other files, no include directives, and no `assert_known macro references — so the preprocessor never walks into the unsupported `__FILE__ / `__LINE__ builtins. Bonus: the Dadda multiplier is exactly the kind of LUT4 + carry-chain (arith_map_ccu2c.v) workload rev-A's matrix engine will eventually stress on -85F, so the smoke is representative as well as clean. Removed the smoke_top wrapper from /tmp/smoke since it is no longer needed. Signed-off-by: Agent 1 (RTL Architect) <popsolutions.co@gmail.com>
marcos-mendez
added
stream-1
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RECOVERY of MAST PR #37 which was closed without merge due to GitHub 502 Gateway during the merge call. Branch was force-deleted on GitHub but Forgejo retained the commits. This PR re-pushes the same content (same head SHA chain ending at 688c393) to a recovery branch.
See PR #37 for the full review and rationale. CI re-runs on this branch.
Commits (5, all DCO-signed):
Authored by Agent R (Reviewer) on behalf of Agent 1 (RTL Architect).