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

If hierarchical references to interfaces are not legal as
connection actuals, then the basic situation that Kaiming and
Brad describe is less troublesome whether you consider the
dotted name as "hierarchical" or not.

Keep in mind that the primary reason for the hierarchical
reference restrictions on parameters is to have (semi-)comprehensible
rules for design elaboration in the presence of complex generates.

For example, if I completely open the doors, what would I do with
something like the following:
    module top;
       if (my_gen.p == 1) begin:my_gen
          parameter p = 0;
       end
       else begin:my_gen
          parameter p = 1;
       end
    endmodule

This is a structural contradiction rather than just a
non-converging value computation. The existing LRM rules
are designed to avoid structural contradictions since they
are much more troublesome and there are so few reasonable
situations.

The defparam rules are designed to avoid such issues by
disallowing any such possible structural loop since no
"upwards" backedge in the dependency graph can exist.

I would be fine with allowing parameter references into
interfaces as Kaiming suggests *as long as* the interface
instance is "above" the reference in the topology (i.e.
the interface actual isn't in a generate block that might
be defined away). Alternatively if you view this as saying
that the interface has (effectively) a defparam to the
reference point then as long as the normal defparam rules
hold, I'm ok with allowing this.

It might be worthwhile to change the entire tone of how
we describe this so that we describe the structural intent
rather than assignment/reference restrictions that enforce
the intent.

We haven't done that previously since describing the
structural intent in a way that is meaningful to a reader
and that all implementations would treat in the same manner
is not an easy thing to do.

Gord.

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

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.