riscv32i: declare dmem's procedurally assigned signals as regs

[oharboe]

What

flow/designs/src/riscv32i/dmem.v assigns we_mem and mem_out inside always @* blocks while declaring we_mem a wire and leaving mem_out an implicit net. A net cannot be the target of a procedural assignment (IEEE 1364-2005 6.1.2, IEEE 1800-2023 6.5). yosys's Verilog frontend accepts it; slang rejects it nine times:

dmem.v:33:10: error: cannot assign to a net within a procedural context

so riscv32i cannot be read with SYNTH_HDL_FRONTEND=slang.

Fix

The declarations: reg [3:0] we_mem and output reg [31:0] mem_out, which is what both frontends build. Always blocks and drivers unchanged. The file keeps its CRLF line endings.

Test

New flow/test/test_riscv32i_slang.py reads the riscv32i sources with read_slang (a black-box module standing in for the fakeram7_256x32 macro the flow takes from liberty) and asserts slang accepts them.

• Fails before this change, passes after (yosys 0.68 with the slang plugin).
• Skips where no yosys with read_slang is available (YOSYS_EXE or yosys on PATH, SLANG_PLUGIN_PATH for the plugin), which includes the Python-only util test job.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the Verilog module in dmem.v to declare mem_out and we_mem as reg instead of wire, ensuring compliance with stricter Verilog compilers like slang which require signals assigned in always blocks to be variables. It also introduces a new test suite test_riscv32i_slang.py to verify this compatibility. The feedback recommends wrapping the source file paths in double quotes to properly handle paths containing spaces and adding a timeout to the subprocess execution to prevent potential hangs during CI runs.

[openroad-ci]

🔍 QoR check

Metrics reflect the PR merge build — i.e. what will land on the target branch.

Commit 044d7cf · Jenkins build #3 · Baseline: build · View build on dashboard

62 design(s) checked — 0 with regression(s), 0 without a comparable baseline.