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
Raise error / warning on continous assignment to reg #1369
Comments
Original Redmine Comment I believe the code sent is legal in SystemVerilog, so no warning is appropriate. What complains and does it support SystemVerilog? |
Original Redmine Comment Xilinx ISE 14.7 syntheser complains about this:
I need to use this syntheser for Spartan 6 targets. As far as I know it does not support SystemVerilog. I also forgot to mention that I use verilator with specifying the Verilog standard that ISE supports. For linting verilator is called in the following way:
|
Original Redmine Comment Fixed in git towards 4.008. |
Original Redmine Comment In 4.008. |
Original Redmine Comment Thank you for the fix! verilator now raises error on internal_reg but does not recognize the case of out signal in the example code above. |
Original Redmine Comment In order to raise the warning for port, I've changed like the following: In 'V3ParseGrammar.cpp'
In 'V3ParseGrammar.cpp'
|
Original Redmine Comment I wouldn't have thought your patch would be needed as the unreleased git version of verilator should have fixed this about a month ago. Can you please check it? If there is a problem with those warnings please file a new issue. |
Original Redmine Comment Hi, It's been modified from 4.016. 4.016 version doesn't warn continuous assignments for the port (out) declared as
The modified version warns like the following:
I missed something ? |
Original Redmine Comment Please use the unreleased git version, it intended to fix this. |
Original Redmine Comment Oh, where can I get the unreleased git version ? |
Original Redmine Comment See https://www.veripool.org/projects/verilator/wiki/Installing |
Original Redmine Comment Is the git version different from tarball version ?I thought that they were the same. |
Original Redmine Comment Git is the change-by-change repo, which is snapshotted for the tarballs. Anyhow the version released this weekend has the change you want, so use the tarball if you want. |
Original Redmine Comment Warning about assigning to output reg does not work for me. I'm using tag 4.022 without success.
warns only about out_muxed but not about out using the initial example code in this issue. There is no warning after declaration of out_muxed has been corrected from reg to wire. |
Original Redmine Comment Sorry this has been such a mess, will make another pass. Getting this right is surprisingly difficult... |
I think that the remainder of this issue is due to Verilator seeing the varType() of "out" as a port. It appears to me that Verilator doesn't differentiate between a reg output and a wire output. Specifically this condition in V3Undriven cause the error to not be printed: !nodep->varp()->varType().isContAssignable() |
That sounds roughly right. If you could please make a pull it would be appreciated, also please check against the verilator_ext_tests as these warnings tend to have false positives until properly tuned. Thanks! |
Author Name: Peter Gerst
Original Redmine Issue: 1369 from https://www.veripool.org
Original Assignee: Wilson Snyder (@wsnyder)
Verilator does not throw error / warning on continuous assignment to a register. See the following example:
content of wire_test.v:
Calling verilator as @verilator --lint-only wire_test.v@ does not complain about the assignment on internal_reg and out registers.
git version of verilator is used (last commit on Nov 26) but the issue is also present in version 4.006:
This issue is in connection with forum message https://www.veripool.org/boards/3/topics/1559-Verilator-Verilator-fails-to-warn-error-on-procedural-assignment-to-wire that seems to be corrected: Procedural assignment to wire causes error message to be thrown using git version referenced above.
The text was updated successfully, but these errors were encountered: