-
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
nMigen should avoid emitting very large wires that cause issues in Yosys #341
Comments
Here's the generated RTLIL, but unfortunately I don't know how to parse it any better than YoSys does:
|
The cause of this error is some truly enormous wires here:
This happens because the result of a left shift is sized appropriately to hold the result no matter what the shift amount is, i.e. it has the size of I'm inclined to say this isn't a bug with nMigen, since that's the intended semantics, even if unexpected. It tickles a bug in handling very large slices in Yosys, which is unfortunate, but not necessarily trivial to fix. What I think we should do here is to make the RTLIL backend error out instead of creating very large wires, say anything over 1 million bit. (Or perhaps warn rather than error out.) |
Ah, that makes sense - thanks. The same issue occurs with this left-shift code, though:
Shouldn't max(rhs) = 32 in that case? Or should a different syntax be used to shorten the |
nMigen never uses constants to determine result sizes. This would lead to very surprising results in certain corner cases, such as if you had a piece of generic code that sometimes takes a constant and sometimes a variable, or just different constants.
Try |
Oh, interesting. |
Let's keep this open, since it is a usability bug. |
Then would something like this work for the RTLIL backend warning? Maybe if it had its own Warning class like the DriverConflict and UnusedElaboratable ones? (And with fewer typos) |
No, not really. I think it should be a hard error until it's fixed upstream in Yosys (btw, could you report it there please?) and it should probably be in |
I personally would add a note for shifts in this instance that looks like "if this was unintentional, consider using slice notation to shorten the width of the right hand side expression". |
I agree that we could also do that for shifts where the result ends up larger than the LHS. The question is, how do we suppress that warning? What would be the syntax for that? |
Does nMigen have a way to zero/sign-extend a Value to a given width that's more elegant than |
It looks like you can suppress individual types of warnings when the code is simulated or built like this:
There's also On the bright side, it should be easier to raise an Exception than find a clean way to handle warnings. |
To a given specific width? You could do something like
Indeed. I think that silencing the warning if the RHS is indexed, something like
Yes, but that's far too verbose for a relatively high false positive rate warning like this. Such warnings should be possible to suppress with natural-looking constructs like the one I suggested above. |
Okay, I reported this to Yosys here - hopefully I didn't misunderstand the nature of the issue: How about this, for raising an error with oversized wires? Unfortunately, that doesn't seem to indicate where the error occurs in the 'pre-generation' code or the RTLIL that would otherwise be generated, so it might not be too helpful if someone sees it after making a large change. |
Did you link a wrong commit? |
yes, sorry. |
Please leave it to me, this is one of those changes that are faster to implement than to properly discuss and review. |
@WRansohoff Thank you for the report and the discussion. As you can see in the commit, I had to look up the limits we are bound with in the Verilog standard and the Yosys source code. Although I could have guided you through that during review, it would be equivalent to writing the code myself, just with more steps. |
Thank you for the fix! And I understand, I probably won't know enough to make meaningful contributions to HDL tools for a long time (if ever). |
The following code seems to cause a YoSys parser error when it is built:
This is the error I get:
Replacing the left shift with a right shift results in the module building without problems (besides the 'no clocks' warnings). I think I'm using a pretty recent version of YoSys:
0.9+1706 (git sha1 ed4fa19b)
The text was updated successfully, but these errors were encountered: