RE: [sv-bc] Is dynamic variable written in continuous assignment

I can accept that.

But then I don't understand why, when I brought up the confusion about
the results of the array sum() method, that sum() of an array of bits
returns a 1-bit result instead of the integer sum that the users
expected and wanted, as reported by Chris Spear, the responses were of
the form, "It's the users' fault. They need to read the LRM more
carefully and pay attention to the exact wording and put together
information written in different places and figure out the logical
implications of all that."

Shalom

> -----Original Message-----
> From: Gordon Vreugdenhil [mailto:gordonv@model.com]
> Sent: Friday, November 03, 2006 5:36 PM
> To: Bresticker, Shalom
> Cc: Rich, Dave; sv-bc@eda-stds.org
> Subject: Re: [sv-bc] Is dynamic variable written in continuous
> assignment
> 
> 
> 
> Bresticker, Shalom wrote:
> 
> > Thanks.
> >
> >
> >
> > Using those rules, why require the user to add the keyword 'static'
on
> a
> > variable declaration assignment in a procedural block, for example?
> >
> 
> Since users do get confused about:
> 
>    always @(some_reg) begin
>       integer x = some_reg;
>       $display("x is %d", x);  // why didn't x change???
>    end
> 
> This is based on real "bugs" that we've seen reported and
> is why I am strongly in favor of requiring "static" in such
> a context; users often assume that initialization occurs
> on every entry for ANY block local declaration.  This is
> very much like the  "if (a = b)" kind of error -- valid
> code but such a common error that we should have a protective
> rule in the LRM.
> 
> Gord.
> 
> 
> 
> >
> > Shalom
> >
> >
> >
> >
----------------------------------------------------------------------
> --
> >
> > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > Sent: Friday, November 03, 2006 11:11 AM
> > To: Bresticker, Shalom; sv-bc@eda-stds.org
> > Subject: RE: [sv-bc] Is dynamic variable written in continuous
> assignment
> >
> >
> >
> > The phrase "-class properties and dynamically sized variables-" is
> > parenthetical and should be removed.
> >
> >
> >
> > My philosophy is that simpler is better, re-use is better. The fewer
> > rules there are, the easier it is for users and implementers to
> > understand the language. If we have existing rules for writes to out
> of
> > bounds array elements, why do we need special rules for out of
bounds
> > NBA writes?
> >
> >
> >
> > When do we need additional rules?
> >
> >
> >
> > 1.                       If the semantics are too ambiguous or
> difficult
> > to define without them. Until I write the proposal and it passes, we
> > won't know for sure, but I'm confident that's not the case here.
> >
> > 2.                       If the implementation is too difficult
> without
> > them. I am told by implementers at least two companies that this is
> not
> > the case here either.
> >
> > 3.                       When it's difficult for the user to
determine
> > where or what they've done that makes no sense. That's why we DO
have
> an
> > extra rule requiring parenthesis around an assignment inside of an
> > expression to prevent "if(A=B)" when they really meant "if(A==B)".
On
> > the contrary, "always B=1;" is still a legal statement, but that's
> easy
> > to catch. It's not always possible to make sense out of rules that
are
> > designed to keep you from writing code that makes no sense.
> > Out-of-bounds array indexing and null class handle de-references are
> > easy for tools to catch, and they have to do that anyways.
> >
> >
> >
> > I would only go through the trouble of removing an existing
> restriction
> > if the above can be satisfied AND I see a benefit to the user. I'll
> get
> > to that when I submit the proposal.
> >
> >
> >
> > Dave
> >
> >
> >
> >
> >
> >>  -----Original Message-----
> >
> >>  From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> >
> >>  Sent: Friday, November 03, 2006 12:12 AM
> >
> >>  To: Rich, Dave; sv-bc@eda-stds.org
> >
> >>  Subject: RE: [sv-bc] Is dynamic variable written in continuous
> assignment
> >
> >>
> >
> >>  Dave,
> >
> >>
> >
> >>  > Those cases are both legal. The array as an aggregate is a
static
> >
> >>  > variable. The LRM is currently restricting references to members
> of
> >
> >>  the
> >
> >>  > array in non-procedural contexts.
> >
> >>
> >
> >>  [SB] That should be clarified if the restriction remains. I was
also
> >
> >>  fooled.
> >
> >>
> >
> >>  > By the way, I have on my to-do list writing a proposal to remove
> that
> >
> >>  > restriction on dynamic variable members (just leaving the
> restriction
> >
> >>  on
> >
> >>  > automatics in place). It really should be up to the user to
avoid
> >
> >>  > out-of-bounds array indexing or null class handle de-references.
> >
> >>
> >
> >>  [SB] Could you explain your philosophy as to when to leave the
> >
> >>  responsibility to the user to get things right and when to protect
> him
> >
> >>  from himself?
> >
> >>
> >
> >>  Thanks,
> >
> >>  Shalom
> >
> 
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil                                503-685-0808
> Model Technology (Mentor Graphics)                gordonv@model.com