[slang] Automatically blackbox macros from ADDITIONAL_LIBS

[oharboe]

Description

I have to manually list macros from ADDITIONAL_LIBS in SYNTH_BLACKBOXES for slang.

Suggested Solution

Should be automatic as without slang.

Additional Context

No response

[oharboe]

Speculation: The Timing of Attribute Application vs. Elaboration

The core friction in this issue is likely a race condition between Module Definition and Elaboration/Mangling within the Slang-to-Yosys pipeline.

The Mechanism of the Workaround

The reason the manual workaround (SYNTH_BLACKBOXES) functions is that it injects the (* blackbox *) attribute (or equivalent instruction) based on the Source Identifier (the original name in the .v/.lib file). By explicitly listing the name:

1. The flow flags the module my_macro as a blackbox immediately upon recognition.
2. This flag acts as a "Stop" sign for the compiler.
3. Slang sees the blackbox attribute and aborts full elaboration for that module. It preserves the interface but discards the internals, effectively bypassing the phase where name mangling or deep hierarchy resolution would typically occur.

The Failure of "Automatic" Detection

Without the manual list, the flow defaults to treating the library module as standard source code.

1. Ingestion: Slang reads the module from ADDITIONAL_LIBS.
2. Elaboration (The "Early" Phase): Because it isn't flagged as a blackbox yet, Slang attempts to fully compile it. If the macro involves parameters, unique package scopes, or complex SystemVerilog constructs, Slang mangles the name (e.g., mapping my_macro to my_macro__param_1) to ensure uniqueness in the internal AST.
3. Late Realization: By the time the synthesis script realizes "Wait, this came from a library file," the module in the memory is already mangled or structurally altered. The original name my_macro no longer maps cleanly to the active design entities, causing the automated flow to fail.

Conclusion

The "Automatic" fix must replicate the behavior of the manual workaround: it needs to intercept modules specifically from library file paths and tag them as blackboxes before the elaboration engine triggers the name mangling process.

[povik]

The "Automatic" fix must replicate the behavior of the manual workaround: it needs to intercept modules specifically from library file paths and tag them as blackboxes before the elaboration engine triggers the name mangling process.

This reads hallucinated to me.

@oharboe do you have a simulation model or any competing definition for the macro module added to VERILOG_FILES? Macros from ADDITIONAL_LIBS should not need additional blackboxing with slang. A reproducible would help.

[oharboe]

This should reproduce the problem:

make DESIGN_CONFIG=designs/asap7/riscv32i/config.mk SYNTH_HDL_FRONTEND=slang print-VERILOG_FILES "VERILOG_FILES=designs/src/riscv32i/adder.v\ designs/src/riscv32i/alu.v\ designs/src/riscv32i/aludec.v\ designs/src/riscv32i/controller.v\ designs/src/riscv32i/datapath.v\ designs/src/riscv32i/dmem.v\ designs/src/riscv32i/flopenr.v\ designs/src/riscv32i/flopens.v\ designs/src/riscv32i/flopr.v\ designs/src/riscv32i/magcompare2b.v\ designs/src/riscv32i/magcompare2c.v\ designs/src/riscv32i/magcompare32.v\ designs/src/riscv32i/maindec.v\ designs/src/riscv32i/mux2.v\ designs/src/riscv32i/mux3.v\ designs/src/riscv32i/mux4.v\ designs/src/riscv32i/mux5.v\ designs/src/riscv32i/mux8.v\ designs/src/riscv32i/regfile.v\ designs/src/riscv32i/riscv.v\ designs/src/riscv32i/rom.v\ designs/src/riscv32i/shifter.v\ designs/src/riscv32i/signext.v\ designs/src/riscv32i/top.v\ designs/asap7/riscv32i-mock-sram/fakeram7_256x32/mock-fakeram7_256x32.v" do-yosys-canonicalize

The .lib file for the fake-ram should make sure that designs/asap7/riscv32i-mock-sram/fakeram7_256x32/mock-fakeram7_256x32.v does not appear in the .rtlil, but I find that I have to use SYNTH_BLACKBOXES as the naming mangling has already taken place in the .rtlil.

My plans for reproduction were derailed by this error though:

designs/src/riscv32i/dmem.v:33:10: error: cannot assign to a net within a procedural context
         we_mem = 4'b0000;
         ^~~~~~
designs/src/riscv32i/dmem.v:35:10: error: cannot assign to a net within a procedural context
         we_mem = 4'b1000;
         ^~~~~~
designs/src/riscv32i/dmem.v:37:10: error: cannot assign to a net within a procedural context
         we_mem = 4'b0100;
         ^~~~~~
designs/src/riscv32i/dmem.v:39:10: error: cannot assign to a net within a procedural context
         we_mem = 4'b0010;
         ^~~~~~
designs/src/riscv32i/dmem.v:41:10: error: cannot assign to a net within a procedural context
         we_mem = 4'b0001;
         ^~~~~~
designs/src/riscv32i/dmem.v:62:16: error: cannot assign to a net within a procedural context
        2'b00: mem_out = inter_dmem3;
               ^~~~~~~

[oharboe]

After a quick copilot fix(a real fix isn't important for the reproduction):

--- a/flow/designs/src/riscv32i/dmem.v
+++ b/flow/designs/src/riscv32i/dmem.v
@@ -13,10 +13,10 @@ module dmem (clk, r_w, mem_addr, mem_data, mem_out);
    input        r_w;
    input [31:0]  mem_addr;
    input [31:0]  mem_data;
-   output [31:0] mem_out;
+   output reg [31:0] mem_out;^M
    wire [1:0]   sel_mem;
    wire [3:0]   ce_mem;
-   wire [3:0]   we_mem;
+   reg [3:0]   we_mem;^M
    wire [31:0]   inter_dmem0;
    wire [31:0]   inter_dmem1;
    wire [31:0]   inter_dmem2;

The .rtlil a non-blackboxed:

module \fakeram7_256x32$riscv_top.dmem.dmem3
  attribute \src "designs/asap7/riscv32i-mock-sram/fakeram7_256x32/mock-fakeram7_256x32.v:22.29"

I was going to show that adding SYNTH_BLACKBOXES=fakeram7_256x32 made that module above a blackbox, since in this case the fakeram .lib file should provide the fake ram, but I got another irrelvant error...

ERROR: Module `fakeram7_256x32' referenced in module `dmem$riscv_top.dmem' in cell `dmem3' does not have a parameter named 'corrupt_mem_on_X_p'.

[povik]

To summarize: You seem to be explicitly adding the below file to the file list. So there are two definitions for fakeram7_256x32 and you are requesting that the one from ADDITIONAL_LIBS takes precedence. I agree that is desirable.

designs/asap7/riscv32i-mock-sram/fakeram7_256x32/mock-fakeram7_256x32.v"

[oharboe]

Yep. This would be consistent with yosys builtin verilog parser behavior.

No rush for me, but I thought it was of interest and that you'd want me to report it. So I did.

[povik]

Thanks. I'm surprised the builtin parser handles this differently

[oharboe]

https://en.wikipedia.org/wiki/Principle_of_least_astonishment

So... what is the least surprising behavior for EDA tools?

Explicitly blackboxing or not?

[povik]

As said above I think it's better if the macro takes precedence. When I say I'm surprised regarding the builtin parser it's because I had a different recollection of how the individual commands in use in our script behave.

[oharboe]

Sounds good. No opinion, I have no prior experience to ORFS.