RE: [sv-bc] Typing of parameter assignments

Note also that the BNF has 'defparam_assignment'.

Shalom


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of francoise martinolle
> Sent: Wednesday, February 08, 2006 12:09 AM
> To: 'Steven Sharp'; gordonv@model.com
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Typing of parameter assignments
> 
>  I agree with Steven, a defparam is an assignment of the RHS
> value to the
> parameter.
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Steven
> Sharp
> Sent: Tuesday, February 07, 2006 2:14 PM
> To: sharp; gordonv@model.com
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Typing of parameter assignments
> 
> 
> >From: Gordon Vreugdenhil <gordonv@model.com>
> 
> >The reason this came up was with some testing done by someone
> else who
> >tested exactly the above in a couple of other implementations
> and got
> >the "self determined" answer.
> 
> There are a couple of reasons implementations might get this
> result:
> 
> 1. They may not have implemented Verilog-2001 typed parameters,
> but accept
> and (mostly) ignore the range, for Verilog-XL compatibility.
> 
> 2. They may have implemented typed parameters, but failed to
> change the
> evaluation of their values to be context-determined.  This
> seems likely to
> be a very common bug in implementations.  As I mentioned, I
> think that
> NC-Verilog did this originally, before we caught it and fixed
> it.  It could
> go uncaught for a long time, since it requires a parameter
> declared with a
> width, and an expression that overflows at its self-determined
> width but not
> at the parameter width.
> 
> 
> >Ok (mostly).  Since module instance overrides are also in the
> list of
> >"assignment like contexts", the same should be true for those,
> correct?
> 
> I would expect so.  As far as I can see, any situation where an
> expression
> is being evaluated to determine the value of an integral object
> should use
> the width of that object in the context.  I can't think of any
> exceptions
> off the top of my head, though I may be missing something.
> 
> 
> >Now, since a "defparam" is not a normal assignment and is not
> listed as
> >an assignment like context, does this also imply that a
> defparam does
> >NOT behave in the same manner?
> 
> I would expect a defparam to use the LHS as context also.
> 
> I don't think you should read too much into the fact that
> defparam is not
> listed as an assignment-like context in 1800.  Some people on
> the committees
> are trying to pretend that defparams have gone away, by stating
> that they
> are deprecated and refusing to mention them anywhere else in
> the LRM.
> Others of us don't have that luxury, and have to continue to
> support them,
> no matter how much we may dislike them.
> 
> >There is
> >no clear LRM statement about whether the RHS of a defparam is
> context
> >sensitive or not.  Or are you implying in your last comment
> that a
> >defparam is an assignment, just not an "assignment like
> context" for
> >the purposes of non-integral parameters?
> 
> I would say that it is an assignment, but that 1800 is silent
> about whether
> it is an "assignment like context", just as it is silent about
> defparams
> everywhere else.  I think you would be free to reject an
> assignment pattern
> expression as a RHS of a defparam, because of this.
> 
> Steven Sharp
> sharp@cadence.com