Re: [sv-bc] Typing of parameter assignments

This is ETF issue

   http://www.boyd.com/1364_btf/report/full_pr/487.html

and backlog Mantis item

   http://eda.org/svdb/bug_view_page.php?bug_id=1065

IEEE Std 1800-2005.8.13 clearly states that the following are
assignment-like contexts

     - For a parameter with an explicit type declaration:
           - A parameter value assignment in a module, interface,
program, or class
            - A parameter value override in the instantiation of a
module, interface, or program
            - A parameter value override in the instantiation of a class
or in the left-hand side of a class scope operator

and according to Shalom in http://www.eda.org/sv-bc/hm/3333.html

      "In the 1364 ETF, we discussed parameter initializations, and I
believe the consensus was that they are evaluated in the same way as
assignments. I.e., 'the bit size of the right-hand side expression of an
assignment depends on itself and the size of the left-hand side.'
(P1364-2005, sub-clause 5.4.1)."

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Monday, February 06, 2006 8:45 PM
To: Steven Sharp
Cc: sv-bc@eda.org
Subject: Re: [sv-bc] Typing of parameter assignments



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

Nope.   I couldn't really support the reverse either since
parameters aren't really discussed explicitly in terms of
the RHS values.  The case of untyped parameters is but
parameters aren't really covered; perhaps a sentence should
be added to the effect that for typed parameters, parameter defaults
and module instance parameter overrides are context determined in
the same manner as an assignment to a reg.

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.

I was surprised by this result which is why I brought this up.

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


Ok (mostly).  Since module instance overrides are also in the
list of "assignment like contexts", the same should be true
for those, correct?

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?  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 think it is already normalized the other way, and does not have
> a two-mode nature.


Sounds good to me.

Gord.


> Steven Sharp
> sharp@cadence.com
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com