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

Originally, there was opposition to even adding a warning in the LRM or
suggesting a workaround.

Shalom

> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> Sent: Sunday, November 05, 2006 3:21 PM
> To: Bresticker, Shalom; Vreugdenhil, Gordon
> Cc: sv-bc@eda-stds.org
> Subject: 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