Parameter-resolved constants from interface components #1593
Comments
|
Original Redmine Comment 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: Presuming that those are the parameters inside the interface used to size your signals. |
|
Original Redmine Comment 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' 8000 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. |
|
I'm also stuck with this. verilator likes |
|
@wsnyder I'd like to work on a workaround. Can you suggest where I should look at? |
|
Well the big problem is as mentioned above, but see no reason why $bits can't be subject to the same rules as the current parameter references within an interface. Some combination of V3Width/V3Param is involved in this, it might only be a matter of suppressing the error if underneath a $bits (an attribute requesting DIM_BITS). |
|
|
the suggested workaround doesn't work for interface arrays: |
|
@tinebp that's not too surprising that arrays don't work either. By the date of this bug you can see we'd appreciate someone putting time in to make pull to fix this. |
|
I got the same error with |
|
It seems like something has broken the workaround that @veripoolbot suggested. Even if that was not supposed to work, this is a regression in functionality.
|
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!
The text was updated successfully, but these errors were encountered: