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

Kaiming,

The answer to question a) is clearly yes. sec 25.10 [... objects that are not permissible to be listed
in a modport shall remain accessible.] A parameter cannot be listed in a modport, therefore it is always accessible.

The answer to b) depends on the answer to c). If referencing a parameter through an interface port reference is not a hierarchical reference, then the rule that says constant expressions cannot contain hierarchal references does not apply.

In my opinion, an interface port reference is not a hierarchical reference unless the actual interface connection is a hierarchical reference (something I wanted to disallow).

Dave

> -----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.