RE: [sv-bc] Treatment of parameters in interfaces.

Kaiming,

What's a code example of

"Workarounds to this problem involving the 'typedef backdoor' only partially resolve the problems the examples show. They are inconvenient and sometimes not practical. Most importantly, synthesis tools don't support it, and its hard to argue that such a construct is synthesiable."

Something like this?

interface IFC;
  parameter secret = 88;
  wire in, out;
  modport mp(input in, output out);
  typedef struct {logic [secret-1:0] dummy;} secret_T;
endinterface

module test(IFC.mp ifc, output integer backdoor);
  typedef ifc.secret_T secret_T;
  localparam secret = $bits(secret_T);
  assign backdoor = secret;
endmodule

module top;
  IFC ifc();
  integer backdoor;
  test test(ifc.mp, backdoor);
  initial begin
    $display(backdoor);
  end
endmodule

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Kaiming Ho
Sent: Thursday, July 15, 2010 8:25 AM
To: sv-bc@eda.org
Subject: [sv-bc] Treatment of parameters in interfaces.

Interfaces which appear on a module's port-list may have parameters
and access to these parameters are an important part of an RTL
design methodology which uses interfaces as opposed to individual
port in/out declarations.

Within the context of the two examples below, I'd like clarification
to the following questions:

(a) access to interface parameters is always permitted, irrespective
     if the interface is connected through a modport or not.
(b) interface parameters are constants. They can be used in
     constant expressions
(c) access to interface parameters are not considered hierarchical
     references. Therefore, they can be used to define new parameters.

The examples are:
-----------------------------------------------------------------
(1)
   // bus for carrying video samples, of parametrisable width.
interface intf_vidbus;
   parameter w = 8;
   logic valid, last_sample;
   logic [w-1:0] data;
endinterface

module dut (input clk, intf_vidbus vid_in, vid_out);
     // need to know the width of the connected interface
   localparam sample_width = vid_in.w;
     // register incoming sample
   reg [sample_width:1] samp_reg;
   always @(posedge clk) if (valid) samp_reg <= vid_in.data;
     // do some processing
   reg [2+sample_width:1] samp_new;
   always @(posedge clk) samp_new <= 2*samp_reg + vid_in.data;
endmodule

(2)
   // axi-like soc bus. request portion
interface intf_axi_req;
   logic [31:0] addr; logic addr_valid;
   logic [1:0] req_type; logic [7:0] req_size;
   logic wdata_valid;
   parameter int unsigned wdata_bytes_lg2 = 1; // 0==8b, 1==16b, 2==32b, 3==64b
   logic [8*(1<<wdata_bytes_lg2):1] wdata;
endinterface

module dut2 (input clk, reset_n, intf_axi_req req_bus);
   // assume that req_bus can only be 8, 16, 32 or 64bits wide
initial $display ("%m: req_bus width %0d", req_bus.wdata_bytes_lg2);
always @* assert(req_bus.wdata_bytes_lg2 <= 3);
   // accumulate 8, 4, 2 or 1 cycles to form 64 bits
reg [4:0] cnt;
reg [63:0] acc_reg; reg acc_reg_valid;
always @(posedge clk or negedge reset_n)
   if (~reset_n) cnt <= 0;
   else if (req_bus.wdata_valid)
     cnt <= (cnt+1 == 8>>req_bus.wdata_bytes_lg2) ? 0 : cnt+1;
always @(posedge clk)
   if (req_bus.wdata_valid)
     begin
     acc_reg <= (acc_reg << 8*(1<<req_bus.wdata_bytes_lg2)) |
                   req_bus.wdata;
     acc_reg_valid <= cnt+1 == 8>>req_bus.wdata_bytes_lg2;
     end
endmodule
//-----------------------------------------------------------------

and have been taken from real designs I've recently dealt with. They
show realistic examples of where knowledge of a parameter in a connected
interface is important.

Currently, various simulators treat the examples differently, with some
allowing both (1) and (2) while others disallow both (1) and (2).
The synthesis tools I've tried do not allow (1) but allow (2). For this
reason, I feel that it is important to achieve consensus on this so that
the tools can converge.

This issue, in particular (1), has come up before:
    http://www.eda.org/sv-bc/hm/4269.html
and various followups in
    http://www.eda.org/sv-bc/hm/4282.html
    http://www.eda.org/sv-bc/hm/4308.html
    http://www.eda.org/sv-bc/hm/6497.html
My interpretation of the discussion back then was that while it was
unclear as to what the LRM says about the legality of the construct,
the followups lean towards allowing this. I support allowing the
constructs in (1) and (2), and hope that those examples provide
additional motivation towards this goal.

Several mantis' are potentially related to the questions raised. Mantis
1508 asks what a 'hierarchical reference' is, which is a key component
of question (c). The approach described in section 23.7 regarding
'member selects' vs. 'hierarchical name', applied to interface variables
can indicate access to parameters inside interface is a member select.
Mantis 2573 relates to part of question (b).

Workarounds to this problem involving the 'typedef backdoor' only
partially resolve the problems the examples show. They are inconvenient
and sometimes not practical. Most importantly, synthesis tools don't
support it, and its hard to argue that such a construct is synthesiable.

Finally, if Mantis 2573 resolves to allow:
   reg [vid_in.w:1] samp_reg;
it opens yet another backdoor to question (c), namely:
   localparam sample_width = vid_in.w;
   localparam sample_width_workaround = $bits(samp_reg);

regards,
kaiming

-- 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.