8

I am a bit confused as to if it is legal, from a standards stand point, to read a parameter from an interface.

Like so

interface foo_if #(parameter BAR=5)();
...
logic [BAR-1:0] data;
modport slave(input data, ...);
endinterface

module foobar(foo_if.slave s);
...
logic [s.BAR-1:0] bar;
logic [$bits(s.data)-1:0] m_data;
...
endmodule

I have a problem where a major synthesis tool vendor can not even handle this. And they explicitly tell you in the help message that it is not allowed to use $bits() with a interface member.

However a simulation tool from another vendor handles this perfectly as does another synthesis tool I have.

However in SystemVerilog for Design by S. Sutherland et al. it is stated:

Because the design hierarchy may not be yet fully resolved during elaboration, it is illegal to assign a parameter, specparam, or localparam constants a value that is derived from elsewhere in the design hierarchy

However if I am not allowed to use parameters from interfaces, it really cripples the usefulness of interfaces.

The SystemVerilog 1800-2012 Standard on the other hand states:

25.10 Access to interface objects

Access to objects declared in an interface shall be available by hierarchical name reference, regardless of whether the interface is also accessed through a port connection or through a virtual interface, and regardless of the existence of any declared modports in that interface. A modport may be used to restrict access to objects declared in an interface that are referenced through a port connection or virtual interface by explicitly listing the accessible objects in the modport. However, objects that are not permissible to be listed in a modport shall remain accessible.

AxelOmega
  • 974
  • 10
  • 18
  • [Xilinx Vivado](http://forums.xilinx.com/t5/Synthesis/accessing-systemverilog-interface-parameters/m-p/405317) doesn't support parameters access and neither does Altera Quartus. They do support the `$bits(interface.port)` workaround... However interfaces are still crippled as modports aren't very well supported on FPGA tools. – Chiggs May 04 '15 at 13:33

1 Answers1

3

The issue here is not about access, but what is allowed in places that require constant expressions. The LRM is not very clear that interface port references are not considered hierarchical references. But the tool is not complaining about s.BAR, it is complaining about s.data, which is a variable, not a parameter. Normally, you can't use variables in constant expressions, but the LRM 20.6.2 says

The $bits function can be used as an elaboration time constant when used on fixed-size data types; hence, it can be used in the declaration of other data types, variables, or nets.

So $bits(s.data) should have been treated like a parameter expression.

BTW, you should be using the latest freely available IEEE 1800-2012 LRM.

dave_59
  • 39,096
  • 3
  • 24
  • 63
  • Actually neither s.BAR or the $bits() worked. So even if the $bits() is not working. You are claiming that s.BAR should have worked if I understand your answer correctly. – AxelOmega May 01 '15 at 17:02
  • The LRM mentions interface port references explicitly when it talks about importing a type (typedef) from an interface instance. For the same reason, parameters through interface ports should also be allowed. Most tools already support that, but it is not explicit in the LRM. – dave_59 May 01 '15 at 20:08
  • @dave_59 sadly very few (none?) of the FPGA tools support access to interface parameters. ASIC folks have all the fun ;) – Chiggs May 04 '15 at 13:35
  • LRM should be more clear on this. But if interface ports should behave like ordinary ports and there should be a way to access port sizes either through interface port parameter access (**s.BAR** - which is illegal hierarchical access now), or through the interface port signal width (**$bits(s.data)**). – Amal Jul 10 '15 at 17:42
  • Related question: https://verificationacademy.com/forums/systemverilog/access-parameterized-interface-ports-size-within-module – Amal Jul 22 '15 at 18:32