Re: [sv-bc] Typing of parameter assignments

>From: Gordon Vreugdenhil <gordonv@model.com>

>For example,  the following:
>    parameter [7:0] p = 4'b1111 + 4'b0001;
>yields 0 as the result rather than what one would get with
>a "reg" declaration.  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.

Can you support this from the LRM text? 

NC-Verilog gets the same answer as with a reg (though I think we may
have originally gotten the result you describe, until we realized it
was wrong and fixed it).

If the LHS has a width, then that should be used in the evaluation
of the RHS.  It is an assignment, and unless you can find LRM text
to say otherwise, it should follow the rules for assignments.

If the LHS does not have a declared width, you can describe it as
evaluating the RHS as a self-determined expression.  But you can
also say that it is using the LHS width in the evaluation of the RHS.
It is just that in that situation, the LHS is defined to get the
width from the width of the RHS.  So evaluating the RHS at the width
of the LHS is the same as evaluating it at the width of the RHS,
which is the same as evaluating it as self-determined.

>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.

Again, I disagree.  This should give 8'b11111111, just as you would
expect.

>   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.

And as far as I know, 1364-2001 is the same.

>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 don't agree with your implied assumption, and therefore don't
think we have a contradiction.

>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.

I think it is already normalized the other way, and does not have
a two-mode nature.

Steven Sharp
sharp@cadence.com