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
blocking & non-blocking assigns -- verilator issues error when no logical conflict exists #364
Comments
Original Redmine Comment Unfortunately this is a known limitation that's not going to be fixed soon; this case is shown in the manual under BLKANDNBLK. Verilator does all scheduling presently by variable not by individual bits (for speed) so it complains when all bits aren't handled the same way. Sorry. It's on the medium term list of things to improve. |
Original Redmine Comment Temporary workaround is to convert packed array to unpacked array. Of course, this can cause other problems with other tools. |
Original Redmine Comment Is this issue resolved as part of DETECTARRAY issue fix? Seems to compile and run correctly now. |
Original Redmine Comment Yes, fixed in git towards 3.833. |
Original Redmine Comment Apparently, I was wrong - it sill does not work in some cases, e.g.:
I got:
|
Original Redmine Comment I should add that in previous example variables are defined as simple vectors:
|
Original Redmine Comment The fixed note should have mentioned it fixes only arrays used in this context. I'll leave the bug open until the more general fix is made. |
Original Redmine Comment I wonder if some simple fix can be invented here, like splitting array into 2 arrays internally, one modeling a register, and one modeling a wire. So far all of large designs I've tried fail in Verilator with this error. Looks like its quite a common coding practice. |
Original Redmine Comment Not currently being worked on. |
Original Redmine Comment I am running into this problem very frequently with RTL that extensively uses packed structs. For instance this does different types of assignments to different elements of the struct:
See the attached tarball for an example with Makefile. I have a workaround as the tarball shows but it is painful to change all of the RTL to implement this workaround. Add me as a vote to raise the priority above Low. Thanks. |
Original Redmine Comment Good point, raised to normal. Perhaps if I provide some pointers you could attempt a patch to the warning (which should be sufficient for your case versus the larger issue)? |
Original Redmine Comment I'm not sure if you mean that the warning can be disabled for my case or the fundamental issue can be fixed for my case. Either way, I'm happy to be involved in exploring a solution (hopefully to the fundamental problem). |
Author Name: John Stevenson
Original Redmine Issue: 364 from https://www.veripool.org
In regards to the following error message:
It was issued in error. To reproduce, do the following:
There is no logical conflict:
... shiftreg[ 0 ] has a blocking assign
... shiftreg[ 1 to 9 ] have non-blocking
The text was updated successfully, but these errors were encountered: