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

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.

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