Re: [sv-bc] Typing of parameter assignments

Gordon Vreugdenhil wrote:
>    parameter [7:0] p = 4'b1111 + 4'b0001;
> yields 0 as the result rather than what one would get with
> a "reg" declaration.

Could you elaborate on what makes you expect this result?
As you say it doesn't fit the "context-determined expression width"
rules at all.  I can't find any 1364 LRM support for this.

> This treats the rhs as a self-determined
> expression which normalizes the values/types that you would
> get in this case versus a defparam or module instance overrride.
> 
> Observations:
>   1) if I have:
>          parameter [7:0] p = '1;
>      I am assuming that we should get 1'b1 rather than 8'b11111111
>      as we would get in a register context.
>   2) in P1800, a typed parameter is considered to be an
>      assignment like context.  This implies that the type is
>      taken into account when evaluating the RHS.
> 
> So, we have semi-contradictory assumptions -- for non-assignment
> patterns, there is an (implied) assumption that the RHS does
> not consider the LHS type; for an assignment pattern it must.
> 
> I would prefer to normalize this and require that the RHS is
> always a self-determined expression meaning that in the context
> of a parameter, an explicit type annotation would be required
> for an RHS that represents a composite literal.  If we'd prefer
> to keep the "two mode" nature of this, we should be explicit
> as to the type/no-type rules for parameters and the default
> expression values.
> 
> Gord.

Two modes?

While it is nice to see an island of self-determined sanity in
a stormy sea of context sensitivity, the location of this island
right in the middle of the channel seems more of a hazard than
a harbor.

As you say, it would make "parameter" statements be an exception
which (silently) changes the outcome of constant evaluation.  Context
determined width is bad enough, without subverting the user's
understanding by also depending on the statement type for more context!

Is there really a backward compatibility issue here?

Greg