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'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). |
|
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: