[sv-bc] RE: [sv-ec] Question on Mantis item 505

The right-hand side must be unsized, real or integral according to
the paragraph after the first example in 22.2.  I think that's
not restrictive enough and that 'integral' should be replaced
with 'simple bit-vector type'.

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org]On Behalf Of
Steven Sharp
Sent: Friday, April 22, 2005 3:53 PM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: [sv-ec] Question on Mantis item 505


I was assigned the job of addressing the incorrect text in this item.  I am
not sure whether my changes are what would be desired.

The original text in the LRM said that if a parameter was declared without
a data type, it would default to type logic of arbitrary size, for Verilog
compatibility.  This is incorrect, since in Verilog it defaults to the
data type of the value assigned (whether that ends up being the default
value on the declaration, or the value supplied in a parameter override).

Since Verilog allows only a limited set of types, this will be either a
signed or unsigned logic vector, or a real (it is also possible to supply
only the signedness and get the size from the value, but I didn't want to
go into that here).  However, when I change the text to say that it gets
its type from the value assigned in SystemVerilog, that allows it to
inherit the larger variety of SystemVerilog types.

Is that what we want, or did we want to restrict it to inheriting the
limited set of types that it could have inherited in Verilog?  That is
all that would be required for Verilog compatibility.  Note that a
parameter could end up inheriting a type that is not actually declared
or otherwise visible in the scope of the parameter.  With the proposal
to allow $typeof()/type() anywhere a type could be used, this would
be a backdoor way of sneaking a type into a module without explicitly
declaring a type parameter.

I seem to recall someone raising a concern about defparam being used
to override a type parameter.  The response was that this was not a
problem because with defparams were not being extended to allow overriding
type parameters.  However, with this backdoor mechanism, a defparam could
be used to override an untyped value parameter with a typed value, allowing
the defparam to effectively pass in a type.  The type could be extracted
with type().  So if there was any problem with allowing defparam to
override a type parameter, the same problem would presumably occur here.

Steven Sharp
sharp@cadence.com