Interface array forwarding and modports

system-verilog

QUESTION

Are interface parameters for a module automatically deducted from the interface instance that is connected to the module instance?

Background

I am designing a System that provides a communication infrastructure with multiple channels. Each channel can be tied to a different module by the user. To separate the user logic from the system I created a module wrapping the infrastructure. This is the setup in (pseudo) code

interface channel_if #(parameter int CHANNELBITS = 8);
     logic dummy;

     modport arbiter(input dummy);
endinterface

module arbiter(
    channel_if.arbiter channel[CHANNELS] //MODPORT defined
);
endmodule

module infrastructure(
    channel_if #(CHANNELBITS=16) channel[CHANNELS] //PARAMETERS defined
);

arbiter channelArbiter(channel);

endmodule

The problem I have is the following: I can either specify the parameters for the interface array OR the modport. I found no way (Vivado 2015.1) to define both, parameters AND modport.

In top the following code would be found:

…
channel_if #(CHANNELBITS=16) channelHarness[CHANNELS];
channel_if channelHarness[CHANNELS]; //either this or previous

infrastructure(.channel(channelHarness.arbiter));
…

While it is no problem to assign InterfaceArray.modport to the infrastructure module, I can not assign InterfaceArray.modport inside infrastructure (We already stripped the interface array down to modports at the infrastructure module boundary).

Questions

Since I can not define the interfaceparameters for arbiter (only possible if I do not define the modport, which yields inout orts for the interfac,e which I do not want), can I use Interfaces with non defaultparameters?

Are interface parameters for a module automatically deducted from the interface instance that is connected to the modelinstance?

Best Answer

Parameter values are deduced from the interface instance that is connected to the model instance. See the example in section 25.8 Parameterized interfaces of the 1800-2012 LRM.

The interface/modport construct in the SystemVerilog language is one of the most poorly documented sections of the LRM and has many open issues. I would avoid using them unless absolutely necessary.

Related Solutions

Electronic – Instantiating multidimensional array in system verilog

First off, it is a common practice that parameters are upper case. When reading code this helps identify constants from variables. For arrays, refer to IEEE Std 1800-2012 § 7.4 Packed and unpacked arrays.

Packed means all the bits can be accessed at once or sliced
Unpacked means each index must be individually selected.

The following have the same dimensions:

logic [N-1:0] arr_up [M-1:0]; is M unpacked arrays, each with N packed bits
logic arr_uu [M-1:0] [N-1:0]; is M unpacked arrays, each with N unpacked single bits arrays
logic [M-1:0] [N-1:0] arr_pp; is M-by-N packed array, a slice of N-bits can be read out of the M index

Unpacked arrays can be initialized with a single digit: logic [N-1:0] arr_up [M]; is equivalent to logic [N-1:0] arr_up [0:M-1];. Do note that the [M] is [0:M-1] not [M-1:0].

The differences is in the access. All can access a single bit, but only packed bits can access a slice.

arr_up[M-2] = {{N{1'b0}}}; // legal
arr_uu[M-2] = {{N{1'b0}}}; // illegal, assigning packed to unpacked
arr_pp[M-2] = {{N{1'b0}}}; //legal`

arr_up[M-1:M-4] = {{3*N{1'b1}}}; // illegal, unpacked cannot use sliced array
arr_uu[M-1:M-4] = {{3*N{1'b1}}}; // illegal, unpacked cannot use sliced array
arr_pp[M-1:M-4] = {{3*N{1'b1}}}; // legal

arr_up[M-2][N-5] = 1'b0; // legal
arr_uu[M-2][N-5] = 1'b0; // legal
arr_pp[M-2][N-5] = 1'b0; // legal

arr_up[M-2][N-5:4] = {{N-9{1'b1}}}; // legal
arr_uu[M-2][N-5:4] = {{N-9{1'b1}}}; // illegal, unpacked cannot use sliced array
arr_pp[M-2][N-5:4] = {{N-9{1'b1}}}; // legal

If the simulator is only accessing a single bit or index, unpacked arrays will give better performance. This is because packed arrays are accessed as a whole even if only one bit is being used. There is a balance between the simulators lookup overhead and number of lookup operations. Generally 2-D arrays are unpacked arrays of packed arrays. Adding dimensions is normal on the unpacked side. bytes, integers, words, and data buses are packed.

With typedef enum logic [N-1:0][1:0]{S0,S1,S2,S3} statetype;, be aware this is creating the definition of the state type. It is create a 2*N-bit array but only allows 4 values.

For an array of 4-state state machines, I would recommend:

typedef enum logic [1:0]{S0,S1,S2,S3} state_et;
state_et state[N], nextstate[N];

System Verilog Adapter Interface

Is it legal to have modports that do not include all wires of an interface?

Yes, refer to IEEE Std 1800-2012 § 25.5.4 Modport expressions:

A modport expression allows elements of arrays and structures, concatenations of elements, and assignment pattern expressions of elements declared in an interface to be included in a modport list. This modport expression is explicitly named with a port identifier, visible only through the modport connection.

Like explicitly named ports in a module port declaration, port identifiers exist in their own name space for each modport list. When a modport item is just a simple port identifier, that identifier is used as both a reference to an interface item and a port identifier. Once a port identifier has been defined, there shall not be another port definition with this same name.

For example:
interface I;
  logic [7:0] r;
  const int x=1;
  bit R;
  modport A (output .P(r[3:0]), input .Q(x), R);
  modport B (output .P(r[7:4]), input .Q(2), R);
endinterface
module M ( interface i);
  initial i.P = i.Q;
endmodule
module top;
  I i1 ();
  M u1 (i1.A);
  M u2 (i1.B);
  initial #1 $display("%b", i1.r); // displays 00100001
endmodule

Not all simulators/synthesizer support modeport expressions, so you will have to experiment. Modeport expressions are not new, they are also described in IEEE Std 1800-2005. Maybe the Accellera SystemVerilog 3.1a as well (I'd need to dig up the old LRM to verify).

Can one have assignments in an interface?

Yes. Synthesis support may be limited for some tools; you'll need to experiment. For simulations, assign statements in an interface can be used to control data for tri-state buses.

interface I;
  bit drive_en;
  tri [15:0] io;
  logic [15:0] io_drv;
  assign io = drive_en ? io_drv : 'z;
endinterface

Interfaces can also contain their own tasks and functions. If you are using the interface for design, then generally you want to limit keep the interface simple: mostly signals and modports. This is not a rule, just a recommended guideline.

Or could I do some magic to cause a write to a member in a union to result in updates of other members of the union that do not share bits?

More power to you if you got the magic to pull it off. Probably not worth the effort.