Skip to content
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

Parameter-resolved constants from interface components #1593

Open
veripoolbot opened this issue Nov 7, 2019 · 3 comments
Open

Parameter-resolved constants from interface components #1593

veripoolbot opened this issue Nov 7, 2019 · 3 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Nov 7, 2019


Author Name: Ahmed Qureshi
Original Redmine Issue: 1593 from https://www.veripool.org


When doing something like this:
localparam MY_WIDTH = $bits({my_intf.signal1, my_intf.signal2});

We get the following error:
Parameter-resolved constants must not use dotted references

I imagine this checking is to avoid cross-module referencing, but for interfaces is this something that can be supported in a future release?

Thanks!

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 7, 2019


Original Redmine Comment
Author Name: Todd Strader (@toddstrader)
Original Date: 2019-11-07T16:39:38Z


Yeah, I keep bumping into this one too. Verilator should be able to take $bits() of that signal in the same way that it can resolve parameters inside interfaces as constants. In the mean time, I'd suggest this instead:

localparam MY_WIDTH = my_intf.SIGNAL1_SIZE + my_intf.SIGNAL2_SIZE;

Presuming that those are the parameters inside the interface used to size your signals.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Nov 7, 2019


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2019-11-07T23:17:30Z


I think it's also a bug that the workaround works, any reference into a child (which an interface is) should have had a similar message. However obviously not going to fix something that is helping people out ;)

Verilator does top down module resolution, and at present the interface must be done after the parent. Imagine if the interface itself was parameterized - we must therefore do the parent first. I suspect if you try this with a parameterized interface that changes SIGNAL1_SIZE you'll find a bug (untested).

Perhaps some hack-around can be found for this, if someone wants to take a look I'd welcome it. The bigger issue is #1540 , while strictly reading IEEE parameters must be top-down, the reality that bug needs to address is they must be done in a parameter-by-parameter basis across all modules to solve cases like this.

For now added a placeholder test as t_interface_param_acc_bits.v.

Also added a case to t_interface_parameter_access.v which curiously also works ok.

@nanduraj1

This comment has been minimized.

Copy link

@nanduraj1 nanduraj1 commented Dec 26, 2019

I'm also stuck with this. verilator likes localparam MY_WIDTH = my_intf.SIGNAL1_SIZE + my_intf.SIGNAL2_SIZE; and quartus likes localparam MY_WIDTH = $bits({my_intf.signal1, my_intf.signal2});

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.