You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was seeing some very strange behaviour as a result of Yosys being able to optimise away large parts of my design. Eventually I was able to produce a minimal reproduction case, which uncovered a nextpnr bug.
When running synth_ecp5 on the following Verilog module, Yosys will output a useless flip-flop with CE set to 1 and CEMUX set to INV. Similarly, synth_ice40 produces a flip-flop with E set to 0 and D set to 1.
This is because Yosys correctly recognises that b will never be 0, and therefore c <= 1'b1 will never be triggered.
moduletop (
input clk,
outputreg c =1'b0
);
reg a =1'b0;
always @(posedge clk)
a <=!a;
wire [2:0] b =3'd3+ { 2'b0, a };
always @(posedge clk)
if (b ==3'd0) c <=1'b1;
endmodule
However, if b is changed to any other 3-bit value between 1 and 6 inclusive, Yosys correctly optimises away the flip-flop and outputs a constant 0.
Calling synth_ecp5/ice40 with the -dff flag produces the desired result, but it's not clear to me why that should be necessary in this simple case.
Note that this behaviour is also present for bit widths larger than 3. For example, this variation also produces a flip-flop that will never trigger (while values lower than 5'd13 correctly output a constant 0):
moduletop (
input clk,
outputreg c =1'b0
);
reg [1:0] a =2'd0;
always @(posedge clk)
a <= a +1;
wire [4:0] b =5'd13+ { 3'b0, a };
always @(posedge clk)
if (b ==5'd0) c <=1'b1;
endmodule
Version
Yosys 0.49+3 (git sha1 3d35f36, x86_64-apple-darwin23.5-clang++ 18.1.8 -fPIC -O3)
On which OS did this happen?
macOS
Reproduction Steps
I was seeing some very strange behaviour as a result of Yosys being able to optimise away large parts of my design. Eventually I was able to produce a minimal reproduction case, which uncovered a nextpnr bug.
When running
synth_ecp5
on the following Verilog module, Yosys will output a useless flip-flop withCE
set to 1 andCEMUX
set toINV
. Similarly,synth_ice40
produces a flip-flop withE
set to 0 andD
set to 1.This is because Yosys correctly recognises that
b
will never be 0, and thereforec <= 1'b1
will never be triggered.However, if
b
is changed to any other 3-bit value between 1 and 6 inclusive, Yosys correctly optimises away the flip-flop and outputs a constant 0.Calling
synth_ecp5/ice40
with the-dff
flag produces the desired result, but it's not clear to me why that should be necessary in this simple case.Note that this behaviour is also present for bit widths larger than 3. For example, this variation also produces a flip-flop that will never trigger (while values lower than
5'd13
correctly output a constant 0):Expected Behavior
Actual Behavior
synth_ecp5
synth_ice40
The text was updated successfully, but these errors were encountered: