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

Shalom,

Now you're no longer talking about a rule to keep someone from doing
something bad, but changing the semantics so that bad code becomes good
(The difference between what's good or bad is another topic and
something your parents should have taught you :). 

I'm all for that, but the place to have done that was with the general
expression rules for Verilog, and it's too late to change that. What had
been suggested was to create an additional set of rules that said the
expression rules were different in that case. 

Like I said, fewer rules are better, and reduce the number of places you
have to look to figure out what's going on.

Dave


> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Saturday, November 04, 2006 11:22 PM
> To: Vreugdenhil, Gordon
> Cc: Rich, Dave; sv-bc@eda-stds.org
> Subject: 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