The `synth_efinix` synthesis process keeps `Adding EN signal` and does not terminate.

[sdjasj]

Version

Yosys 0.50+49 (git sha1 05c81b3, clang++ 14.0.0-1ubuntu1.1 -Og -fPIC -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -fsanitize=address,undefined)

On which OS did this happen?

Linux

Reproduction Steps

The following is the Verilog code file bug.v that triggers the bug. I have already minimized it as much as possible using C-Reduce and manual editing (although the code may still look a bit long, I’ve tried my best, from 8745 bytes to 488 bytes :) ). I tried using bugpoint to minimize it, but I don’t know how to write a script that treats the non-terminating synthesis process as a bug.

module a (
    input b,
    input h,
    input i,
    output reg o
);
    wire c, j, k, e, g;

    reg l, n, d, f;

    always @(posedge b or negedge c) begin
        if (c) begin
            o = j > l;
            l = (l | j) ? k ? h : i ? 0 : n : 0;      
        end
    end

    always @(h) begin
        d = k;
    end

    always @(e or g or f) begin
        if (e) begin
            l = 0;
        end else begin
            d = g;
            l = f;
        end
    end

endmodule

Running the following script will trigger the bug.

yosys -p "read_verilog bug.v; synth_efinix"

I discovered this bug while testing Yosys using a fuzzing tool I am developing.

Expected Behavior

The synthesis process is expected to terminate within a finite amount of time, rather than repeatedly outputting Adding EN signal.

Actual Behavior

The following log was produced:

2.10.2. Executing OPT_MERGE pass (detect identical cells).
Finding identical cells in module `\a'.
Removed a total of 0 cells.

2.10.3. Executing OPT_DFF pass (perform DFF optimizations).
Removing never-active async load on $auto$ff.cc:266:slice$38 ($aldff) from module a.
Adding EN signal on $auto$ff.cc:266:slice$38 ($aldff) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$77 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$80 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$85 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$90 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$95 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$100 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$105 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$110 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).
Adding EN signal on $auto$ff.cc:266:slice$115 ($dffe) from module a (D = $auto$wreduce.cc:513:run$41 [0], Q = 1'x).

and it keeps repeating without termination.

[povik]

Thanks, I can reproduce also with read_verilog bug.v; synth -run coarse; opt -undriven;

[widlarizer]

Thanks for your report. Your reproducer doesn't pass check after proc (or even before), and the issues check detects directly lead to triggering an edge case, namely, it detects a mux feedback path from Q to D because both Q and D are driven by 1'x as a consequence of this driver-driver conflict:

Warning: multiple conflicting drivers for a.$procmux$12_Y:
    port Q[0] of cell $procdff$37 ($aldff)
    port Y[0] of cell $procmux$12 ($mux)

I am fairly confident this edge case isn't triggerable by valid designs. We should still handle it by throwing an error instead

[widlarizer]

While it's a general improvement, I consider #5058 to be an alternative solution to this issue as opposed to #5040. I don't really think there's something to be changed in opt_dff when it does odd things as it receives a flop with a Q output additionally driven by a constant