On 11/15/2010 5:30 AM, Bresticker, Shalom wrote:
Hi,
Is the following legal?
parameter P[1:0] = '{1,0};
Is P considered untyped, and then the assignment pattern is
not in an assignment-like context, and the statement is not
legal?
Or is P considered to be typed since an unpacked dimension is
explicitly declared, and then the element base type defaults to
logic?
This question came up a year or two ago; but no existing LRM wording
settles the question.
Here we have two mind-reading tricks on a collision course. I don't
know if there is a good
answer, but it always helps to confront some worst case scenarios to
help us judge.
We know what this means:
parameter P=41, Q=42, R=43;
Will a user be surprised at the meaning we'd give to this?
parameter PQ[1]='{41,42}, R=43;
If we take the suggestion (valid elsewhere?) that the unpacked
dimension implies
that the array elements have type
logic, we'd want to
insist that this does not
establish an implicit data_type to be inherited by the rest of the
parameter list -
don't "trash" the whole list. But even with that caveat, logic
seems to be
the wrong element type for this example.
Typelessness and Assignment Patterns are already complex and subtle
topics; it would be a challenge
to combine them so as to allow
partial typelessness as
suggested by this worst case.
parameter_declaration ::=
parameter
data_type_or_implicit list_of_param_assignments
data_type_or_implicit ::=
data_type
| implicit_data_type
implicit_data_type ::= [ signing ] { packed_dimension }
list_of_param_assignments ::= param_assignment {
, param_assignment }
param_assignment ::=
parameter_identifier { unpacked_dimension }
new
[
= constant_param_expression
]
18
This grammar does not provide a clean handle to the "typeless"
parameter situation.
And section 6.20.2, which discussed this, chose vague terms with no
definite relationship
to the grammar rules. It would take some compelling real-world
examples to
convince us that partial typelessness (i.e. leaving unspecified
parts of the type
open to change during override assignments, and furthermore allowing
them to be
acquired from assignment patterns) has economic viability. It
might. But the
best way to find out is usually to allow some vendor to serve such
customers and
report back on how best to do this.
Until then, I believe the best committee-move we could make is to
add a new footnote
new: An unpacked
dimension may only be used if the data_type_or_implicit specified in
the
parameter,
localparam, or
specparam
declaration is also non-empty.
Vendors are always permitted to extend over such error cases.
If such an extension survives the confusion and ridicule of the EDA
market, let's adopt it.
I don't think defaulting to logic would survive here.
Greg Jaxon
Disclaimer: The above are personal opinions unrelated to products,
plans, voting positions, or
delivery commitments of my employer.
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Mon Nov 15 10:32:44 2010