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

Hi Kaiming,

Thanks for your questions. My answers are:

(1) Yes

(2) I prefer a top-down parameterization, so I would parameterize
multiply_by_2:

module multiply_by_2 #(parameter w=8) (
      intf_video_bus #(.w(w)) bus_in,
      intf_video_bus#(.w(w+1)) bus_out
    );

(3) The syntax does not allow specialized generic interface ports,
intentionally.

(4) The reason an interface port cannot be left unconnected is that
components referenced within it must exist. I do not see why specialization
would make a difference.

Regards,

Peter.

-----Original Message-----
From: Kaiming Ho [mailto:kaiming.ho@iis.fraunhofer.de]
Sent: 17 January 2011 10:10
To: Peter Flake
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Proposal for Interface Specialization in Port
Declarations

Hello Peter:
   I feel a bit uncomfortable with the use of examples to define our intent.
I agree with you that the one in the LRM is not good. You've modified it to
show one particular use model. Is it your intention to allow the following:

(1)
    interface intf_ahb_bus#(parameter bus_bytes_lg2=0);
      logic HCLK; logic [31:0] HADDR;
      logic [ (1<<bus_bytes_lg2)*8-1:0 ] HWDATA;
           ...
    endinterface

    module cpu_with_32b_system_bus (
       intf_ahb_bus#(2) sys_bus,
           ...
    );

    Here, the module has an interface port which is specialized with
    bus_bytes_lg2=2, independent of any other parameters.
      I see this as the simplest use model where an RTL designer can
    enforce what is connected to the module's ports.

(2)
    interface video_bus#(parameter w=8);
       logic valid; logic [w:1] data;
    endinterface

    module multiply_by_2 (
      intf_video_bus bus_in,
      intf_video_bus#(.w(bus_in.w+1)) bus_out
    );

    Here, the two interfaces that need to be connected have a certain
    relationship. One does not care about the parametrisation of the
    incoming 'bus_in', but 'bus_out' must have one more bit than 'bus_in'.
      The language currently has no way to describe this intent.

(3) Is it your intention to allow specialized generic interfaces ports?
    I cannot think of how this would be useful, and can see how this would
    complicate tool implementations. Explicitly disallowing it would be OK.

Finally, I would like to bring up the statement in 23.3.3.4:
   "An interface port cannot be left unconnected"
Can we consider removing this rule for interface ports which have been fully
specialized?

regards,
kaiming

On 13.01.2011 18:27, Peter Flake wrote:
> 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.

--
Kaiming Ho
Fraunhofer-Institut für Integrierte Schaltungen IIS Am Wolfsmantel 33
91058 Erlangen
Telefon  +49 (0) 9131 / 776-4716
Fax      +49 (0) 9131 / 776-4499
E-Mail   kaiming.ho@iis.fraunhofer.de
Internet www.iis.fraunhofer.de
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.