ch6-Modport

2019-11-02

SystemVerilog Modport

​ Modport lists with directions are defined in an interface to impose certain restrictions on interface access within a module. The keyword modport indicates that the directions are declared as if inside the module.

Syntax

1
2
3
4
5
modport  [identifier]  (
  input  [port_list],
  output [port_list]
);

Shown below is the definition of an interface myInterface which has a few signals and two modport declarations. The modport dut0 essentially states that the signals ack and sel are inputs and gnt and irq0 are outputs to whatever module uses this particular modport.

Similarly, another modport called dut1 is declared which states that gnt and irq0 are inputs and the other two are outputs for any module that uses modport dut1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
interface   myInterface;
  logic   ack;
  logic   gnt;
  logic   sel;
  logic   irq0;
 
  // ack and sel are inputs to the dut0, while gnt and irq0 are outputs
  modport  dut0 (
    input   ack, sel,
    output   gnt, irq0
  );
 
  // ack and sel are outputs from dut1, while gnt and irq0 are inputs
  modport  dut1 (
    input   gnt, irq0,
    output   ack, sel
  );
endinterface

Example of named port bundle

In this style, the design will take the required correct modport definition from the interface object as mentioned in its port list. The testbench only needs to provide the whole interface object to the design.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
module dut0  ( myinterface.dut0  _if);
  ...
endmodule
 
module dut1  ( myInterface.dut1 _if);
  ...
endmodule
 
module tb;
  myInterface   _if;
  dut0    d0   ( .* );
  dut1   d1   ( .* );
endmodule

Example of connecting port bundle

In this style, the design simply accepts whatever directional information is given to it. Hence testbench is responsible to provide the correct modport values to the design.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
module dut0  ( myinterface  _if);
  ...
endmodule
 
module dut1  ( myInterface _if);
  ...
endmodule
 
module tb;
  myInterface   _if;
  dut0    d0   ( ._if (_if.dut0));
  dut1   d1   ( ._if (_if.dut1));
endmodule

What is the need for a modport ?

​ Nets declared within a simple interface is inout by default and hence any module connected to the same net, can either drive values or take values from it. In simple words, there are no restrictions on direction of value propagation. You could end up with an X on the net because both the testbench and the design are driving two different values to the same interface net. Special care should be taken by the testbench writer to ensure that such a situation does not happen. This can be inherently avoided by the use of modports.

Example of connecting to generic interface

A module can also have a generic interface as the portlist. The generic handle can accept any modport passed to it from the hierarchy above.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
module dut0  ( interface  _if);
  ...
endmodule
 
module dut1  ( interface _if);
  ...
endmodule
 
module tb;
  myInterface   _if;
  dut0    d0   ( ._if (_if.dut0));
  dut1   d1   ( ._if (_if.dut1));
endmodule

Design Example

​ Lets consider two modules master and slave connected by a very simple bus structure. Assume that the bus is capable of sending an address and data which the slave is expected to capture and update the information in its internal registers. So the master always has to initiate the transfer and the slave is capable of indicating to the master whether it is ready to accept the data by its sready signal.

Interface

Shown below is an interface definition that is shared between the master and slavemodules.

1
2
3
4
5
6
7
8
9
10
11
12
13
interface ms_if (input clk);][][]
  logic sready;      // Indicates if slave is ready to accept data
  logic rstn;        // Active low reset
  logic [1:0] addr;  // Address 
  logic [7:0] data;  // Data
 
  modport slave ( input addr, data, rstn, clk,
                 output sready);
 
  modport master ( output addr, data,
                  input  clk, sready, rstn);
endinterface

Design

​ Assume that the master simply iterates the address from 0 to 3 and sends data equal to the address multiplied by 4. The master should only send when the slave is ready to accept and is indicated by the sready signal.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// This module accepts an interface with modport "master"
// Master sends transactions in a pipelined format
// CLK    1   2   3   4   5   6
// ADDR   A0  A1  A2  A3  A0  A1
// DATA       D0  D1  D2  D3  D4
module master ( ms_if.master mif);
  always @ (posedge mif.clk) begin
 
    // If reset is applied, set addr and data to default values
    if (! mif.rstn) begin
      mif.addr <= 0;
      mif.data <= 0;
 
    // Else increment addr, and assign data accordingly if slave is ready
    end else begin
    // Send new addr and data only if slave is ready
      if (mif.sready) begin
        mif.addr <= mif.addr + 1;
        mif.data <= (mif.addr * 4);
 
     // Else maintain current addr and data
      end else begin
        mif.addr <= mif.addr;
        mif.data <= mif.data;
      end
    end
  end
endmodule

Assume that the slave accepts data for every addr and assigns them to internal registers. When the address wraps from 3 to 0, the slave requires 1 additional clock to become ready.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
module slave (ms_if.slave sif);
  reg [7:0] reg_a;
  reg [7:0]  reg_b;
  reg     reg_c;
  reg [3:0] reg_d;
 
  reg    dly;
  reg [3:0] addr_dly;
 
 
  always @ (posedge sif.clk) begin
    if (! sif.rstn) begin
      addr_dly <= 0;
    end else begin
      addr_dly <= sif.addr;
    end
  end
 
  always @ (posedge sif.clk) begin
    if (! sif.rstn) begin
        reg_a <= 0;
      reg_b <= 0;
      reg_c <= 0;
      reg_d <= 0;
    end else begin
      case (addr_dly)
        0 : reg_a <= sif.data;
        1 : reg_b <= sif.data;
        2 : reg_c <= sif.data;
        3 : reg_d <= sif.data;
      endcase
    end
  end
 
  assign sif.sready = ~(sif.addr[1] & sif.addr[0]) | ~dly;
 
  always @ (posedge sif.clk) begin
    if (! sif.rstn) 
      dly <= 1;
    else 
      dly <= sif.sready;
  end
 
endmodule

The two design modules are tied together at a top level.

1
2
3
4
5
6
7
8
module d_top (ms_if tif);
  // Pass the "master" modport to master
    master   m0 (tif.master);
 
    // Pass the "slave" modport to slave
    slave   s0 (tif.slave);
endmodule

Testbench

The testbench will pass the interface handle to the design, which will then assign master and slave modports to its sub-modules.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
module tb;
  reg clk;
  always #10 clk = ~clk;
 
  ms_if   if0 (clk);
  d_top   d0  (if0);  
 
  // Let the stimulus run for 20 clocks and stop
  initial begin
    clk <= 0;
    if0.rstn <= 0;
    repeat (5) @ (posedge clk);
    if0.rstn <= 1;
 
    repeat (20) @ (posedge clk);
    $finish;
  end
endmodule

Simulation Output

Remember that the master initiates bus transactions and the slave captures data and stores it in its internal registers reg_* for the corresponding address.

modport-design-example-waveClick to try this example in a simulator! img

Verification System Verilog
SV ChipVerif_Web

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！