Re: [sv-ec] RE: class datatypes with parameter oomr override legal ?

My opinion (biased to be sure) is that hierarchical
referencing of parameters in parameter overrides is
generally a pretty bad idea for SV.  In particular, I think
that in previous discussions, Steven and I had agreed
that general references are certainly not reasonable
since that would open up the same kind of holes as were
closed by disallowing "upwards" defparams across generate
constructs (i.e. pulling a value up via such an override
reference is effectively the same as a defparam upwards).

Ideally, within the LRM I'd prefer to just outlaw the
use of hierarchical references to parameters as parameter
associations completely and leave it to vendors to quietly
continue to support the legacy expectation for such references
in pre-1364-2001 constructs.  Certainly when one
begins to consider all of the various permutations
of such references in the context of all of the new
SV constructs, I do not think that it is reasonable
(or really all that useful in general) to allow such
generality and the difficulty that it would entail for
overall elaboration flow and consistency.

In a sense this dovetails with the state of defparams
in C.4 "Constructs identified for deprecation".  Defparams
are certainly not a legal form of override for parameterized
classes (or for type parameters in any context);  I'd
view the very restricted legacy use of hierarchical
parameter references in overrides as a necessary legacy
support burden but certainly wouldn't want to set any
expectation for that to be extended to other contexts.

Gord.

Brad Pierce wrote:
> According to
> 
>    http://www.eda-stds.org/svdb/view.php?id=1224#2216
> 
> --- begin quoted text
>> What is the motivation for requiring constant expressions in defparams
>> and parameter declarations, but not in the parameter value assignments
>> in module instantiations. That is, in A.4.1, why don't
>> ordered_parameter_assignment and named_parameter_assignment require
>> constant_expression?
> 
> These certainly have to be constant expressions. I'm not sure whether
> they have to conform to the same restrictions as defparams, though.
> For example, XL appears to allow hierarchical names in module instantations
> but not in defparams.
> 
> Steven Sharp
> sharp@cadence.com
> 
> --- end quoted text ---
> 
> -- Brad
> 
> 
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Francoise Martinolle
> Sent: Wednesday, January 21, 2009 2:20 PM
> To: sv-ec@eda.org
> Subject: [sv-ec] class datatypes with parameter oomr override legal ?
> 
> Are class datatype considered constant expressions?
> I looked up the BNF for class datatype and I found :
> class_type ::=
> ps_class_identifier [ parameter_value_assignment ]
> { :: class_identifier [ parameter_value_assignment ] }
> list_of_parameter_assignments ::=
> ordered_parameter_assignment { , ordered_parameter_assignment }
> | named_parameter_assignment { , named_parameter_assignment }
> ordered_parameter_assignment ::= param_expression
> named_parameter_assignment ::= . parameter_identifier ( [ param_expression ] )
> 
> And the param_expression can lead to a hierarchical identifier.
> Here is a test to illustrate my question:
> module oomr;
>    parameter LW = 8;
> endmodule
> module top;
> 
>    class container #(int WIDTH=2);
>    endclass
> 
>    container #(.WIDTH(oomr.LW)) vc = new;
> 
>    initial $display (vc.WIDTH);
> endmodule // top
> 
> --
> 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.