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
Macro name == module name interferes with module location via -y #300
Comments
Original Redmine Comment Should have suspected that one would bite back. Fixed in git for 3.305+. SystemC users will need the latest SystemC git change. |
Original Redmine Comment Thanks for the quick update, but I think the fix will have the same problem. (Disclaimer: I only examined the modified code using git diff. I had trouble building the code I got from git.) It looks like the non-backticked module name ("MYMOD") passed to remove_defines() will still get passed to defvalue_nowarn which returns the defined value "" which gets returned to the caller. I think something like this (untried) will work:
I see similar remove_defines subroutines in Getopt and Preproc - do they need a similar fix? |
Original Redmine Comment You're right, I added a test, saw it fail, then added the fix. |
Original Redmine Comment In 3.305. |
Author Name: John Dickol
Original Redmine Issue: 300 from https://www.veripool.org
Original Date: 2010-11-03
Original Assignee: Wilson Snyder (@wsnyder)
Some Verilog RTL we received from a vendor (i.e. we can't easily change it) uses an ifdef to control the instantiation of a module. The macro name in the ifdef is the same as the module name. Something like this simplified example:
MYMOD.v exists in a subdirectory (subdir/MYMOD.v). Vhier cannot locate it when I use -y to point to the subdir:
Listing the MYMOD file explicitly on the command line works:
The culprit appears to be this bit of code in Netlist.pm:
In top.v, the module name MYMOD does not have a leading ` so it shouldn't be treated as a macro. But it is expanded to the macro's value (the empty string) which prevents MYMOD.v from being found.
The text was updated successfully, but these errors were encountered: