`ERROR: Assert 'signal_list[id1].bit.wire != nullptr'` occurred during the `synth_efinix`

[sdjasj]

Version

Yosys 0.51+107 (git sha1 f03b449, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)

On which OS did this happen?

Linux

Reproduction Steps

Below is the Verilog code bug.v that triggers the assertion. I’ve already minimized it using C-Reduce and manual inspection (from 6493 bytes to 740 bytes) — removing any single line from the code will prevent the assertion from being triggered. (Interestingly, if I change reg [1:0] g, h, i, j; to reg g, h, i, j;, the assertion does not occur.)

module a(
    input f,
    input [1:0] b,
    output reg c
);
    reg [1:0] g, h, i, j;
    wire k, e;

    always @(*) begin
        begin
            c = h;
        end

        case (b)
            'd1: begin
                h = i;
            end
        endcase
    end

    always @(f) begin
        case (g << j >> h)
            32'd3: begin
                case (b << j)
                    'd1: begin
                        h = 0;
                        j = f ? (^k) : 0;
                    end
                    'd2: begin
                        i = j;
                    end
                endcase
            end

            default: begin
                h = e || b;
            end
        endcase
    end
endmodule

The following is the minimized min.il file using Yosys's bugpoint.

# Generated by Yosys 0.51+107 (git sha1 f03b44959, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)
autoidx 130
attribute \src "bug.v:1.1-40.10"
attribute \cells_not_processed 1
module \a
  attribute \src "bug.v:9.5-19.8"
  wire $0\c[0:0]
  attribute \src "bug.v:9.5-19.8"
  wire width 2 $0\h[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $0\i[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $0\j[1:0]
  attribute \src "bug.v:9.5-19.8"
  wire width 2 $1\h[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $1\i[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $1\j[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $2\h[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $2\i[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $2\j[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $3\h[1:0]
  attribute \src "bug.v:21.5-39.8"
  wire width 2 $4\h[1:0]
  attribute $bugpoint 1
  wire width 2 input 3 $auto$bugpoint.cc:258:simplify_something$13
  attribute $bugpoint 1
  wire $auto$bugpoint.cc:258:simplify_something$18
  attribute $bugpoint 1
  wire $auto$bugpoint.cc:258:simplify_something$57
  attribute $bugpoint 1
  wire width 32 input 4 $auto$bugpoint.cc:258:simplify_something$78
  attribute $bugpoint 1
  wire width 32 input 5 $auto$bugpoint.cc:258:simplify_something$90
  wire width 32 $delete_wire$29
  wire width 32 $delete_wire$30
  wire $delete_wire$45
  attribute \src "bug.v:36.21-36.27"
  wire width 2 $logic_or$bug.v:36$8_Y
  attribute \src "bug.v:22.15-22.26"
  wire width 32 $shr$bug.v:22$4_Y
  attribute \src "bug.v:27.29-27.41"
  wire width 32 $ternary$bug.v:27$7_Y
  attribute \src "bug.v:3.17-3.18"
  wire width 2 input 1 \b
  attribute \src "bug.v:4.16-4.17"
  wire output 2 \c
  attribute \src "bug.v:6.18-6.19"
  wire width 2 \h
  attribute \src "bug.v:6.21-6.22"
  wire width 2 \i
  attribute \src "bug.v:6.24-6.25"
  wire width 2 \j
  attribute \src "bug.v:36.21-36.27"
  cell $logic_or $logic_or$bug.v:36$8
    parameter \A_SIGNED 0
    parameter \A_WIDTH 1
    parameter \B_SIGNED 0
    parameter \B_WIDTH 2
    parameter \Y_WIDTH 2
    connect \A 1'x
    connect \B \b
    connect \Y $logic_or$bug.v:36$8_Y
  end
  attribute \src "bug.v:22.15-22.26"
  cell $shr $shr$bug.v:22$4
    parameter \A_SIGNED 0
    parameter \A_WIDTH 32
    parameter \B_SIGNED 0
    parameter \B_WIDTH 2
    parameter \Y_WIDTH 32
    connect \A $auto$bugpoint.cc:258:simplify_something$78
    connect \B $auto$bugpoint.cc:258:simplify_something$13
    connect \Y $shr$bug.v:22$4_Y
  end
  attribute \src "bug.v:27.29-27.41"
  cell $mux $ternary$bug.v:27$7
    parameter \WIDTH 32
    connect \A 32'x
    connect \B $auto$bugpoint.cc:258:simplify_something$90
    connect \S $auto$bugpoint.cc:258:simplify_something$57
    connect \Y $ternary$bug.v:27$7_Y
  end
  attribute \src "bug.v:21.5-39.8"
  process $proc$bug.v:21$2
    assign $2\h[1:0] $3\h[1:0]
    assign $0\i[1:0] $1\i[1:0]
    assign $0\j[1:0] $1\j[1:0]
    attribute \src "bug.v:22.9-38.16"
    switch $shr$bug.v:22$4_Y
      case 3
        assign $3\h[1:0] $4\h[1:0]
        assign $1\i[1:0] $2\i[1:0]
        assign $1\j[1:0] $2\j[1:0]
        attribute \src "bug.v:24.17-32.24"
        switch $delete_wire$30
          case 1
            assign $2\j[1:0] $ternary$bug.v:27$7_Y [1:0]
          case 2
            assign $2\i[1:0] \j
          case 
        end
      case 
        assign $3\h[1:0] $logic_or$bug.v:36$8_Y
    end
    sync always
      update \h $2\h[1:0]
      update \i $0\i[1:0]
      update \j $0\j[1:0]
  end
  attribute \src "bug.v:9.5-19.8"
  process $proc$bug.v:9$1
    assign $0\c[0:0] \h [0]
    assign $0\h[1:0] $1\h[1:0]
    attribute \src "bug.v:14.9-18.16"
    switch { 30'000000000000000000000000000000 \b }
      case 1
        assign $1\h[1:0] \i
      case 
        assign $1\h[1:0] \h
    end
    sync always
      update \c $0\c[0:0]
      update \h $0\h[1:0]
  end
end

The bug can be reproduced with the following commands:

yosys -p "read_verilog bug.v; synth_efinix"

or

yosys -p "read_rtlil min.il; synth_efinix"

Expected Behavior

The synthesis process should not trigger an assertion.

Actual Behavior

An assertion failure occurred, causing the synthesis to fail. The log is as follows:

2.17. Executing OPT_EXPR pass (perform const folding).
Optimizing module a.
Couldn't topologically sort cells, optimizing module a may take a longer time.
Couldn't topologically sort cells, optimizing module a may take a longer time.
<suppressed ~1 debug messages>

2.18. Executing SIMPLEMAP pass (map simple cells to gate primitives).

2.19. Executing ABC pass (technology mapping using ABC).

2.19.1. Extracting gate netlist of module `\a' to `<abc-temp-dir>/input.blif'..
ERROR: Assert `signal_list[id1].bit.wire != nullptr' failed in passes/techmap/abc.cc:536.

[KrystalDelusion]

Given the number of issues you are raising it would be nice if you could spend a bit more time identifying the underlying issue in Yosys and describing the sequence of steps that lead to the error. There is a recent example from #4590 (comment) that you can look at where I did this.

You can also try to minimize the Yosys script (rather than just using synth_*). There is some work in progress documentation on that process here https://yosyshq.readthedocs.io/projects/yosys/en/docs-preview-bugpoint/using_yosys/bugpoint.html#minimizing-scripts. I haven't (yet) updated the guide, but I think a good way to do it would be keep the bug.v for the yosys -p 'read_verilog bug.v; synth_efinix' to provide the context, and then also a reduced RTLIL file and minimized Yosys script that demonstrates just the sequence of steps relevant to the failure.

[sdjasj]

Given the number of issues you are raising it would be nice if you could spend a bit more time identifying the underlying issue in Yosys and describing the sequence of steps that lead to the error. There is a recent example from #4590 (comment) that you can look at where I did this.

You can also try to minimize the Yosys script (rather than just using synth_*). There is some work in progress documentation on that process here https://yosyshq.readthedocs.io/projects/yosys/en/docs-preview-bugpoint/using_yosys/bugpoint.html#minimizing-scripts. I haven't (yet) updated the guide, but I think a good way to do it would be keep the bug.v for the yosys -p 'read_verilog bug.v; synth_efinix' to provide the context, and then also a reduced RTLIL file and minimized Yosys script that demonstrates just the sequence of steps relevant to the failure.

Thank you for patiently providing me with suggestions. I will carefully study the materials you've shared so that I can provide more specific steps that led to the errors (including the issues I previously mentioned). It might take me some time, but I will do my best. I truly appreciate your support and understanding.

[KrystalDelusion]

It might take me some time, but I will do my best.

Thanks, fewer high quality bug reports are much nicer for us to work with than many lower quality ones, and more likely to get resolved :)

[sdjasj]

Following the guidance from KrystalDelusion, I performed further minimization using the following steps:

read_verilog bug.v
synth_efinix -run :map_luts
bugpoint -command "abc -lut 4" -grep "Assert"
select *
write_rtlil -selected min.il

I used the steps above because I observed that the last log message before the Assert was:

2.19. Executing ABC pass (technology mapping using ABC).

After manually minimizing min.il, I ultimately arrived at the following intermediate RTLIL code that still triggers the same assertion error:

# Generated by Yosys 0.51+107 (git sha1 f03b44959, clang++ 14.0.0-1ubuntu1.1 -fPIC -O3)

autoidx 691

attribute \top 1
module \a

  wire \w

  cell $_MUX_ \m
    connect \A 1'x
    connect \B \w
    connect \S 1'x
    connect \Y 1'x
  end
end

By running:

read_rtlil min.il
abc -lut 4

the same assertion failure is triggered.

Below is the code snippet from the source where the assertion happens. I'm not sure whether hitting this assertion is expected behavior in Yosys. If it is, it might be helpful to provide a more user-friendly message instead of crashing :)

for (auto &edge_it : edges) {
	int id2 = edge_it.first;
	RTLIL::Wire *w1 = signal_list[id1].bit.wire;
	RTLIL::Wire *w2 = signal_list[id2].bit.wire;
	if (w1 == nullptr)
		id1 = id2;
	else if (w2 == nullptr)
		continue;
	else if (w1->name[0] == '$' && w2->name[0] == '\\')
		id1 = id2;
	else if (w1->name[0] == '\\' && w2->name[0] == '$')
		continue;
	else if (edges[id1].size() < edges[id2].size())
		id1 = id2;
	else if (edges[id1].size() > edges[id2].size())
		continue;
	else if (w2->name.str() < w1->name.str())
		id1 = id2;
}

if (edges[id1].size() == 0) {
	edges.erase(id1);
	continue;
}

log_assert(signal_list[id1].bit.wire != nullptr);

std::stringstream sstr;
sstr << "$abcloop$" << (autoidx++);
RTLIL::Wire *wire = module->addWire(sstr.str());

(I tried to analyze what might have caused the assertion failure. A possible guess is that the constant 1'x values below are responsible:)

connect \A 1'x
connect \S 1'x
connect \Y 1'x

[KrystalDelusion]

cell $_MUX_ \m
  connect \A 1'x
  connect \B \w
  connect \S 1'x
  connect \Y 1'x
end

should get optimized away by a call to opt_expr -mux_undef.

Given the sequence of commands before the abc -lut 4 are opt_expr -mux_undef; simplemap I wonder why/how this $_MUX_ makes it through. Also calling bugpoint with the -clean option means the failure doesn't show up at all. I also noticed in the map_gates section the opt -fast comes from #1682 which I think might be relevant here, and indeed swapping out the opt_expr -mux_undef for opt -fast -mux_undef appears to resolve the issue. I wonder how many of the other synth_* errors you've found are due to the same.

[sdjasj]

I wonder how many of the other synth_* errors you've found are due to the same.

Thanks! I'll definitely take a closer look at the other synth_* errors I’ve encountered to see if they might share the same root cause.

That said, I do feel this could be considered a bug — at least from a user’s perspective. Most users probably won’t be aware of the exact sequence of commands executed inside synth_*, nor would they expect that missing a specific opt variant could lead to subtle or broken synthesis results. When this kind of issue happens, it can be quite confusing and time-consuming to debug.

If it turns out to be tricky to fix this generally, maybe it would be helpful to document a recommended workaround (e.g. using opt -fast -mux_undef) in the synth_efinix docs? Just a small suggestion from my side :)

[KrystalDelusion]

That said, I do feel this could be considered a bug — at least from a user’s perspective.

Oh it definitely is an issue in the synth_* scripts that needs to be fixed, I meant that I suspect it affects more than just synth_efinix, and it would make sense to fix as many of them as we can at the same time instead of doing each fix individually.

[sdjasj]

and it would make sense to fix as many of them as we can at the same time instead of doing each fix individually.

Oh, I see what you mean :) If I encounter the same issue, I’ll reply under this issue.

[KrystalDelusion]

Oh, this is another doubly-driven, potentially closed by #5058