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
Question: AUTOINSTPARAM use with dependent parameters #1663
Comments
Original Redmine Comment I'd suggest don't use ANSI style arguments, instead use 1995 style, and 2001's localparam:
|
Original Redmine Comment Oooh. Thanks! I hadn't though of looking backward. |
Original Redmine Comment Foiled! |
Original Redmine Comment I think you used "parameter" instead of "localparam". |
Original Redmine Comment I only used parameter for the @BYTES_PER_WORD@. I noticed I hadn't given a number to that parameter on the upper module.
|
Original Redmine Comment I misunderstood what you said was wrong in the last exchange, at present verilog-mode doesn't parse the value of the "inner" localparam, so won't do what you want. |
Original Redmine Comment I was thinking that's a lot of language awareness for verilog-mode... |
Author Name: Berk Akinci
Original Redmine Message: 3215 from https://www.veripool.org
Hi,
I often find myself with parameterized modules with dependent parameters. They can't be localized because they affect ports (and I'm still using Verilog 2001).
In the below example, I'd like ideally to have user module to only have @BYTES_PER_WORD@ exposed and all else calculated. (I do have a bit of dilemma on how complicated an expression I would tolerate in the brackets.)
I saw that you recently added a regex to AUTOINSTPARAM, but then the undeclared parameters are used in the module instance ports.
Do you have a suggested use in this case w/ numerous dependent parameters?
I'm probably asking for a little too much automation, but I ask in case you have already solved this in a way I haven't discovered.
Thanks,
Berk
Here's a simplified example:
The text was updated successfully, but these errors were encountered: