-
Notifications
You must be signed in to change notification settings - Fork 175
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
Time-0 race condition for simulation #594
Comments
This is a well known issue. There is a workaround for it that's supposed to be firing here, but doesn't. I'll look into it. |
Wait, no, this is a different, much less well known issue. I've actually never seen this before, but it makes sense:
Why not? I believe that most, possibly all, synthesizers ignore it, to solve exactly this kind of issue. Alternatively, we could guard its use with |
Oh, I didn't know that synthesizers would ignore it -- I thought they'd yell and scream about non-synthesizable statements. In that case it's fine to put it in there! You mean something like this?
|
BTW, I found that in the generated Verilog, this will not pass the test:
But this does:
As does this:
Are the last two equivalent? |
Another interesting data point. If I compile simbug.py to rtlil, then use yosys to convert that to verilog via:
Then the test passes. Presumably because there are no |
Hi, There are two possible workarounds that, while none of them is a clean solution, may help someone until this is solved:
|
Minimal test case. simbug.zip
Summary:
The Verilog that nMigen outputs can contain time-0 race conditions which cause problems for simulation.
Details:
I'm running through the Zero to Asic course using nMigen. The digital design part assumes you're writing Verilog, runs the code through Icarus Verilog, and then simulates/tests using cocotb. Everything is fine, except I managed to stumble into a Verilog simulation subtlety. Best explained by the Icarus Verilog FAQ:
The Verilog generated by nMigen is something like this:
This results in the time-0 race described above. While not synthesizable, manually altering the Verilog resolves the problem:
You'd think that you could use a reset signal to reset registers to known states, but that doesn't fix the problem.
I emphasize that this is a simulation issue, not a synthesis issue. I'm honestly not sure what the solution here is. I don't really want to see
initial #0
in Verilog for synthesis.The text was updated successfully, but these errors were encountered: