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