RE: [sv-bc] Fwd: RE: 6.20.2 Value parameters - partially defined type - unpacked array

The first bullet in 6.20.2 lists only two possible cases: the expression being real and the expression being integral. I believe the intent was that these were the only two cases in which these rules applied. This was explicit in the 1800-2005 LRM, but that text seems to have been lost when the two LRMs were merged. In that LRM, 6.3.2 said

"In an assignment to, or override of, a parameter without an explicit type declaration, the type of the right-hand expression shall be real or integral."

My interpretation is that this declaration does not satisfy the requirements to be a parameter without an explicit type declaration. Therefore, it has an explicit type declaration. Just as "var v[2]" would be an unpacked array of 2 logic elements, "parameter p[2]" would be an unpacked array of 2 logic elements. Then you would apply the assignment rules. I believe that these no longer require equivalent element types, so this would be legal and would truncate each of the shortints to 1 bit during assignment.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Mlynek
Sent: Wednesday, August 31, 2011 4:04 AM
To: sv-bc@eda.org
Subject: [sv-bc] Fwd: RE: 6.20.2 Value parameters - partially defined type - unpacked array

In chapter 6.20.2 LRM defines how should be the type parameter if its type is not fully defined.
This description misses the unpacked array type parameters.
Lets assume situation where there is only unpacked dimension defined - like below how it shuld behave. IMHO LRM should add description for such cases and similar cases ie only singes and unpacked dim defined, only packed range and unpacked dimension defined etc...
typedef shortint T[2];
module name;
  parameter p[2]=T'{1,2}; //LRM do not describe how this case should work while BNF allows such code.
  initial $display("%p", p);
  initial $display("%b", p[0], p[1]);
endmodule

module top;
  parameter int tp[2]= '{1,-1};
  name #(tp)uut2();
endmodule
DANiel

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.