RE: [sv-bc] Proposal for Interface Specialization in Port Declarations

Hi,

The proposal seems ok, except that it needs to relate to Dave Rich's comment in 2502:

"If we allow this, the issue of "default specialization" will come up.

The current syntax assumes the parametrization of the interface comes from the instance that is connected to the port. You would have to distinguish between

(iface itf)

and

(iface #() itf)

where the latter means the port must be connected to an iface instance with parameters matching the defaults."

A minor editorial point. The proposed text says, "The module header can ...". It holds for interface and program headers as well.

Regards,
Shalom

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Peter Flake
Sent: Thursday, January 13, 2011 7:27 PM
To: sv-bc@eda.org
Subject: [sv-bc] Proposal for Interface Specialization in Port Declarations

I propose the following language changes to deal with the issues raised in Mantis 905 and 2502. The type checking here is minimal to avoid assigning unnecessary parameters in the port declaration.

I have not seen anything that needs to be changed elsewhere.

I welcome comments on this proposal. I am not particularly happy with the example, but I have tried to minimize the changes.

Syntax changes:

interface_port_declaration ::=
interface_identifier [ parameter_value_assignment ] list_of_interface_identifiers
| interface_identifier [ parameter_value_assignment ] . modport_identifier list_of_interface_identifiers

interface_port_header ::=
interface_identifier [ parameter_value_assignment ] [ . modport_identifier ]
| interface [ . modport_identifier ]

Other LRM change:

25.8 Parameterized interfaces
Interface definitions can take advantage of parameters and parameter redefinition, in the same manner as module definitions. Such a parameterized interface can be connected to modules which have generic interfaces or interfaces with the same name without parameters in the module header.

The module header can declare an interface with one or more parameter values, in which case those values must match the actual values in the interface to which it is connected.

The following example shows how to use parameters in interface definitions with two styles of module header:

interface simple_bus #(AWIDTH = 8, DWIDTH = 8)
(input logic clk); // Define the interface
logic req, gnt;
logic [AWIDTH-1:0] addr;
logic [DWIDTH-1:0] data;
logic [1:0] mode;
logic start, rdy;

modport slave( input req, addr, mode, start, clk,
output gnt, rdy,
ref data,
import task slaveRead, task slaveWrite);
// import into module that uses the modport

modport master(input gnt, rdy, clk,
output req, addr, mode, start,
ref data,
import task masterRead(input logic [AWIDTH-1:0] raddr),
task masterWrite(input logic [AWIDTH-1:0] waddr));
// import requires the full task prototype

task masterRead(input logic [AWIDTH-1:0] raddr); // masterRead method
...
endtask

task slaveRead; // slaveRead method
...
endtask

task masterWrite(input logic [AWIDTH-1:0] waddr);
...
endtask

task slaveWrite;
...
endtask

endinterface: simple_bus

module memMod(interface a); // Uses just the interface keyword
logic avail;

always @(posedge a.clk) // the clk signal from the interface
a.gnt <= a.req & avail; //the gnt and req signals in the interface

always @(a.start)
if (a.mode[0] == 1'b0)
a.slaveRead;
else
a.slaveWrite;
endmodule

module cpuMod #(parameter W = 8)(simple_bus#(.AWIDTH(W)).master b);
enum {read, write} instr;
logic [W-1:0] raddr;

always @(posedge b.clk)
if (instr == read)
b.masterRead(raddr); // call the Interface method
// ...
else
b.masterWrite(raddr);
endmodule

module top;
logic clk = 0;

simple_bus sb_intf(clk); // Instantiate default interface
simple_bus #(.DWIDTH(16)) wide_intf(clk); // Interface with 16-bit data

initial repeat(10) #10 clk++;

memMod mem(sb_intf.slave); // only has access to the slaveRead task
cpuMod cpu(sb_intf.master); // only has access to the masterRead task

memMod memW(wide_intf.slave); // 16-bit wide memory
cpuMod cpuW(wide_intf.master); // 16-bit wide cpu
endmodule

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.