Open norandomtechie opened 4 years ago
Minimised test case: using 1479.tar.gz, run yosys -p "fsm" 1479.il
.
Unrelated to the bug, but I suggest you use synth_ice40
's -abc9
option to improve performance.
Another testcase, with a different pass:
module \top
wire input 1 \A
wire output 2 \Y
cell $_AND_ \sub
connect \A \A
connect \B 1'0
connect \Y \Y
end
end
Blows up on extract_fa
Nevermind, it's an unrelated bug...
I did try the abc9 option you specified, as "synth_ice40 -abc9 -top top", but it made no difference. It also had an error with another design, so I will have to hold off on using that option.
We think we may have fixed it by synchronizing outkey in the scankey module above to the given clock. Currently, outkey is assigned combinationally, but if we change the module to do the following:
module scankey (clk, reset, inkeys, strobe, outkey);
input clk, reset;
input [19:0] inkeys;
output strobe;
output reg [4:0] outkey;
wire [4:0] next_outkey;
reg [2:0] delay;
always @(posedge clk, posedge reset)
if (reset) begin
delay <= 0;
outkey <= 0;
end
else begin
delay <= delay << 1 | |inkeys;
outkey <= next_outkey;
end
assign strobe = delay[2];
assign next_outkey = inkeys [19] ? 5'd19 :
inkeys [18] ? 5'd18 :
inkeys [17] ? 5'd17 :
inkeys [16] ? 5'd16 :
inkeys [15] ? 5'd15 :
inkeys [14] ? 5'd14 :
inkeys [13] ? 5'd13 :
inkeys [12] ? 5'd12 :
inkeys [11] ? 5'd11 :
inkeys [10] ? 5'd10 :
inkeys [ 9] ? 5'd9 :
inkeys [ 8] ? 5'd8 :
inkeys [ 7] ? 5'd7 :
inkeys [ 6] ? 5'd6 :
inkeys [ 5] ? 5'd5 :
inkeys [ 4] ? 5'd4 :
inkeys [ 3] ? 5'd3 :
inkeys [ 2] ? 5'd2 :
inkeys [ 1] ? 5'd1 : 5'd0;
endmodule
Then it works just fine. However, I still think this is a bug, because the design theoretically should still work, regardless of having it synchronized to the clock domain or not.
This is undoubtedly a bug; compiler crashes are always bugs.
Your ABC9 error is weird; it generally produces better synthesis results than the default, which is why I recommended it. However without further information it's not really possible to diagnose it further.
On Tue, 12 Nov 2019, 13:59 Niraj Menon, notifications@github.com wrote:
I did try the abc9 option you specified, as "synth_ice40 -abc9 -top top", but it made no difference. It also had an error with another design, so I will have to hold off on using that option.
We think we may have fixed it by synchronizing outkey in the scankey module above to the given clock. Currently, outkey is assigned combinationally, but if we change the module to do the following:
module scankey (clk, reset, inkeys, strobe, outkey); input clk, reset; input [19:0] inkeys; output strobe; output reg [4:0] outkey;
wire [4:0] next_outkey;
reg [2:0] delay; always @(posedge clk, posedge reset) if (reset) begin delay <= 0; outkey <= 0; end else begin delay <= delay << 1 | |inkeys; outkey <= next_outkey; end
assign strobe = delay[2]; assign next_outkey = inkeys [19] ? 5'd19 : inkeys [18] ? 5'd18 : inkeys [17] ? 5'd17 : inkeys [16] ? 5'd16 : inkeys [15] ? 5'd15 : inkeys [14] ? 5'd14 : inkeys [13] ? 5'd13 : inkeys [12] ? 5'd12 : inkeys [11] ? 5'd11 : inkeys [10] ? 5'd10 : inkeys [ 9] ? 5'd9 : inkeys [ 8] ? 5'd8 : inkeys [ 7] ? 5'd7 : inkeys [ 6] ? 5'd6 : inkeys [ 5] ? 5'd5 : inkeys [ 4] ? 5'd4 : inkeys [ 3] ? 5'd3 : inkeys [ 2] ? 5'd2 : inkeys [ 1] ? 5'd1 : 5'd0; endmodule
Then it works just fine. However, I still think this is a bug, because the design theoretically should still work, regardless of having it synchronized to the clock domain or not.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/YosysHQ/yosys/issues/1479?email_source=notifications&email_token=AALPDW3BLWIVLVB5TJTK2WTQTKZD3A5CNFSM4JKLIZR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOED2KQLQ#issuecomment-552904750, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPDWZ3PYFJ253BRWFZ7DLQTKZD3ANCNFSM4JKLIZRQ .
Stumble on the same assert. Was able to minimize my code by hand to the following:
module test(input a, b, output c);
assign c = a ? 1 : 0;
assign c = b ? 1 : 0;
endmodule
Errors when I try to use eval -table
:
$ yosys -p 'read_verilog test.v; eval -table a -table b'
Yosys 0.38 (git sha1 543faed9c, gcc 13.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -ffile-prefix-map=/build/yosys/src=/usr/src/debug/yosys -fPIC -Os)
-- Running command `read_verilog test.v; eval -table a -table b' --
1. Executing Verilog-2005 frontend: test.v
Parsing Verilog input from `test.v' to AST representation.
Generating RTLIL representation for module `\test'.
Successfully finished Verilog frontend.
2. Executing EVAL pass (evaluate the circuit given an input).
ERROR: Assert `current_val[i].wire != NULL || current_val[i] == value.bits[i]' failed in ./kernel/consteval.h:79.
But if I try:
module test(input a, b, output c);
assign c = a ? 1 : 0;
assign c = b;
endmodule
It works:
$ yosys -p 'read_verilog test.v; eval -table a -table b'
Yosys 0.38 (git sha1 543faed9c, gcc 13.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -ffile-prefix-map=/build/yosys/src=/usr/src/debug/yosys -fPIC -Os)
-- Running command `read_verilog test.v; eval -table a -table b' --
1. Executing Verilog-2005 frontend: test.v
Parsing Verilog input from `test.v' to AST representation.
Generating RTLIL representation for module `\test'.
Successfully finished Verilog frontend.
2. Executing EVAL pass (evaluate the circuit given an input).
\b \a | \c
--- --- | ---
1'0 1'0 | 1'0
1'0 1'1 | 1'0
1'1 1'0 | 1'1
1'1 1'1 | 1'1
End of script. Logfile hash: ace15c8f0e, CPU: user 0.02s system 0.00s, MEM: 20.82 MB peak
Yosys 0.38 (git sha1 543faed9c, gcc 13.2.1 -march=x86-64 -mtune=generic -O2 -fno-plt -fexceptions -fstack-clash-protection -fcf-protection -ffile-prefix-map=/build/yosys/src=/usr/src/debug/yosys -fPIC -Os)
Time spent: 51% 1x eval (0 sec), 48% 2x read_verilog (0 sec)
Steps to reproduce the issue
The following code causes Yosys to fail an assertion error:
The Yosys version used was Yosys 0.9+932 (git sha1 3c6a566d, gcc 6.3.0-18+deb9u1 -fPIC -Os).
The command used was yosys -p "read_verilog test.v; synth_ice40 -top top; write_verilog struct_test.v"
We use the generated struct_test.v file to be able to perform gate level simulation of the code using CVC.
Expected behavior
We expected the compiler to load the file test.v, synthesize it with the ice40 scripts, then write it back out as a synthesized Verilog file called struct_test.v.
Actual behavior
The following output is produced: