w" a full parameter of "dut",
then the interface port is providing w's
default value.vid_in.w in Kaiming's
example) is constant is not an invariant feature of the module
in which it occurs.vid_in.w might be constant at one
instantiation and variable at another.Keep in mind that the primary reason for the hierarchical reference restrictions on parameters is to have (semi-)comprehensible rules for design elaboration ... Rich, Dave wrote: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 archive was generated by hypermail 2.1.8 : Thu Jul 15 2010 - 11:52:14 PDT