Parameter-resolved constants from interface components

[veripoolbot]

---

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]

---

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]

---

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]

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});

[nndurj]

@wsnyder I'd like to work on a workaround. Can you suggest where I should look at?

[wsnyder]

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

[nndurj]

• $display( $bits(intf.data) ) works
• logic [$bits(intf.data)-1:0] data works
• localparam WIDTH = $bits(intf.data) gives Parameter-resolved constants error
• Attached test program PFA t.sv.txt