RE: [sv-bc] Typing of parameter assignments

Speaking as a user, the last time I checked tool implementations of
this, which was a while ago, I found the worst case to be where you
declared a parameter with a non-zero right index, as in

parameter [6:2] pp = 5'5;

where in some cases the result was that the tool treated the parameter
as being [4:0] instead of [6:2]. As a result, I had to tell my users to
avoid typing their parameter declarations, for fear of it being
mistreated by the tool.
I hope the situation today is better.

Shalom


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Michael (Mac) McNamara
> Sent: Tuesday, February 07, 2006 8:01 AM
> To: Brad Pierce; sv-bc@eda.org
> Subject: RE: [sv-bc] Typing of parameter assignments
> 
> My memory is fuzzy, but I vaguely recall that Verilog-XL
> version 1.6 (or
> older) allowed parameter width declarations, but ignored them.
> We (at
> Chronologic) might have learned this from our customers, or
> recaled this
> from use of the tool at Ardent Computer; it is of no matter.
> 
> This notion then made it into 1364-1995, perhaps not the text,
> but into
> the common wisdom?  Or maybe into the text?  I don't recall.
> 
> In any case it seems that Mentor and Chronologic got this
> notion,
> implemented it, and later the spec did not include this text
> (or this
> text was deleted).  I believe (again, fuzzy memory) that we
> later fixed
> VCS to honor these declarations (or maybe not, I can't check
> these
> days...  :-)
> 
> 
> Michael McNamara
> mcnamara@cadence.com
> 408-914-6808 work
> 408-348-7025 cell
> 
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Brad
> Pierce
> Sent: Monday, February 06, 2006 9:25 PM
> To: sv-bc@eda.org
> Subject: 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