-
Notifications
You must be signed in to change notification settings - Fork 174
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulation of Verilog output doesn't match nMigen simulation #418
Comments
Adding |
We should already be handling that case (grep for |
Is there a ticket in Yosys for the bug you mention? |
It is not technically a Yosys bug; Yosys outputs "structural netlists" so it doesn't care about what iverilog does. The bug lies in the way nMigen combines with Yosys. I'll need to think about a good way to fix this. |
This is actually a surprisingly subtle issue. I'll raise it at the next Yosys meeting. |
@jeanthom I've discussed this in a Yosys meeting today. The conclusion was to adjust the reg x;
always @* begin
x <= 1;
end we get something like: reg init;
initial init = 0;
reg x;
always @* begin
if (init) begin end
x <= 1;
end |
Thank you for taking the time to discuss this issue with the Yosys team. That solution seems good, may I ask you why an |
It was; |
I would resolve the wire/regs dependencies, but this might be something to avoid on really large designs. BTW does the |
Yeah, so requiring manual changes makes that approach unviable, of course. The goal of a code generator is to make my life simpler, not the other way around.
Hard to say without benchmarking. I know it wouldn't affect Verilator. |
The issue was solved upstream. |
This is actually not entirely fixed yet--nMigen should detect whether Yosys has the fix, and omit |
|
Now that I'm looking at this again, I'm confused. How is the behavior of your snippet not a simualtor bug? The continuous assignment Further, the |
@jeanthom If I run the following Verilog with Icarus Verilog: /* Generated by Yosys 0.9+2406 (git sha1 9d658a19, gcc 10.1.1 -fPIC -Os) */
(* \nmigen.hierarchy = "top" *)
(* top = 1 *)
(* generator = "nMigen" *)
module top(b, a);
(* src = "test.py:6" *)
output a;
reg a;
(* src = "test.py:7" *)
input b;
(* src = "test.py:12" *)
wire fsm_state;
always @* begin
a = 1'h0;
(* src = "test.py:12" *)
casez (fsm_state)
/* \nmigen.decoding = "aaaaaaaa/0" */
/* src = "test.py:13" */
1'h0:
a = 1'h1;
endcase
end
assign fsm_state = 1'h0;
initial begin
$dumpfile("t.vcd");
$dumpvars;
#100;
$finish;
end
endmodule I get this VCD file:
That definitely sets |
I'm also confused because I spent the whole day trying to reproduce the issue with older versions of Yosys to no avail... Probably the minified test code was wrong? The issue I faced in gram#18 was that the generated Verilog code looked like this: reg fsm_state;
always @* begin
a = 1'h0;
casez (fsm_state)
1'h0:
a = 1'h1;
endcase
end
|
Thanks. I can work with this. |
Hi! I was working on a design that used comb statements inside a FSM and noticed that nMigen outputs "always @*" verilog blocks. This causes issues in verilog simulators because the
always
block is only evaluated when a signal of its sensibility list changes.Here's some minimal code that showcases this bug:
Its verilog output:
When the Verilog code is simulated with either Icarus Verilog or Modelsim,
a
is invalid (because its value hasn't been set). When simulated using nMigen built-in simulator,a
is1
.The text was updated successfully, but these errors were encountered: