Re: [sv-bc] Question on Mantis item 505

Steven,

    Thanks for the shrewd analysis!  One consequence I'd note of
saying that the type is directly inherited is that it isn't Verilog
backward compatible.  If the parameter is assigned from another
parameter which is declared with certain upper and lower bounds, the
receiving parameter (in verilog) does not typically inherit those
bounds.

    I think dynamic flow of type information is a new concept, which
has not yet proven to be feasible throughout the tool chain.  By
adding type parameters in their limited form, the LRM confined the
new idea to a distinct communication channel with few pre-existing rules.
My only criticism (correct me if I'm wrong), is that the LRM has not
codified the ABI for that type communication.  In my experience as
a minority C++ compiler vendor, the lack of a name-mangling standard
impeded portability and code reuse.  In EDA it could impede large
project, multi-team integration.

Greg Jaxon


Steven Sharp wrote:
> 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
> 
> 
>