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
SystemVerilog cast on input ports causes signal to be ignored #1526
Comments
Original Redmine Comment Thanks for the good test case. Believe I've fixed it, see git and verilog-mode-2019-09-26-ef55eb6-vpo, please give it a try on your larger design. |
Original Redmine Comment Thanks! That solved the issue on hand (on my full code), but it caused a new bug :-(
Using the previous (Sep 5) version, x is correctly detected and not inferred as output. Using the new Sep 26 version, x is not detected correctly and inferred as output (as quoted above). Even for the Sep 5 version, I had to put an extra parenthesis in the template to get it to work, otherwise 'x' would turn into an output as well. |
Original Redmine Comment In your example as I understand it, "x" is an output, and is not used as an input (always's are ignored) and so should correctly be in the autooutput list. It looks like you were relying on a bug in the older version. If you don't want x in the output list you might want to use verilog-auto-ignore-concat. |
Original Redmine Comment Are you implying that referencing a signal within your module is not enough to keep it internal? Does it has to be an explicit input of another module? I went over the available documentation, and it seems this is not clearly described. |
Original Redmine Comment
Correct. Autooutput was originally for modules which just had submodules and it's too late to change the convention. [[Verilog-mode-Help#verilog-auto-output]] "Make output statements for any output signal from an /AUTOINST/ that isn't an input to another AUTOINST. |
Coming back to this issue after someone in my company stumbled on it. Given the following synthetic example:
Using an old version that predates the ef55eb6 commit (the one fixing this issue), the example about would yield:
We were using
|
((x)) was a bug and not intended to be used. |
I've tried verilog-auto-ignore-concat, but for my case it only makes things worse - I began thinking about adding a mode to track non-instance usage (so that RHS usage would cancel outputs and LHS use would cancel inputs), but the more I think about this, the more complex it is:
Maybe we can add a new mode where concatenation is considered only if there are no commas, so that |
Maybe {{..}}? If you'd like to make a pull for that please feel free. |
hi. and thank you for the support in advance. i am Tomer and i work with Udi (the one that started this thread) we are now upgrading from a very old version of this tool, and the only thing that gives us trouble is the way to manually exclude ports that one side is in an auto_template and the other not (an always block or other non-auto generated way) until now we used: from the thread above i understand that this was an old bug that was fixed. what i did not understand is:
using ({x}) with verilog-auto-ignore-concat does not work well for us, since the usage of {} in verilog is for concatenation, and we use it even in auto_template quite a lot. again, thanks for the support and quick answers. |
Looking further, setting verilog-auto-ignore-concat will also cause (( to be ignored. I don't understand the comment about wanting {} to work however, as the older versions that ignored (('s would I thought also have been ignoring ({, That is verilog-auto-ignore-concat should make it similar to the older version. |
we cannot use ignore-concat since we need the auto_template to NOT ignore concatenations. i still did not understand how i can declare a port to be ignored by the auto_input/output? without using {} |
hi wsnyder. can you please help us with our problem? |
What about if we add a new |
that would be great. when can we expect a feature like this? |
and thank you for the reply |
Would you be able to try a patch to add it? Otherwise I'll try to get to it next weekish. |
a patch is also good to make sure it works for us |
Sorry, I meant would you be willing to try to make a patch yourself? Otherwise I'll try to get to it next weekish. |
i dont think i know how... |
when you say weekish, you mean next week or the one following? |
hi. did you get the chance to look into adding this feature? thanks |
Sorry haven't gotten to it yet, still near the top of the queue, but the queue grows ;). |
i have been thinking that adding /AUTO_NOEXPAND/ within the auto_template might be a bit problematic since the auto_template is a comment it self. having said that, any way you see fit, which you can implement should be fine with me. thanks |
hi again. we would like to upgrade to the new version next week. thanks |
Please give the new AUTONOHOOKUP a try
|
we are now checking the version. thanks for your time and effort. |
we have tested this version. thank you for the effort. if you can release an official revision with this update. |
Author Name: Udi Finkelstein
Original Redmine Issue: 1526 from https://www.veripool.org
Original Assignee: Wilson Snyder (@wsnyder)
In the following minimal code example, "x" is promoted to output although it's used as both input and output.
Commenting line 22 and uncommenting line 21 solves this issue, showing that the SV casting is the issue.
I'm well aware of the fact that in this example "x" is even generated without dimensions, but at the moment this bothers me less because I declare the wire by myself. The real code where I ran into this uses partial indexing of a multidimensional reg, and I understand from past issues that this isn't supported anyhow.
All I want is just to stop it from being generated by AUTOOUTPUT. I know there are workarounds for disabling ports (dead `ifdefs etc.) but I don't want to add this unnecessarily to the code when it's Verilog-mode's fault.
Also, if I change line 21 to ".x(x[][])," the port is declared as
Instead of using the assigned parameter value (4).
The text was updated successfully, but these errors were encountered: