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

That is the same as the 'if(A=B)' mistake. The effect of that mistake
will crop up somewhere other than the typo's location and is very
difficult to debug.

 

A very common mistake is to have a local variable declaration assignment
(VDA) in a static function and expect the variable to be initialized
each time you entered the function. The static keyword requirement is a
reminder that you most likely wanted the variable or even the function
to be automatic in the first place.

 

Oh, and I forgot one other reason to add a rule - to prevent most
backwards incompatibilities, 

 

Verilog only allowed VDAs at the module level and it didn't have the
static keyword. So you can't require the static keyword in all static
VDAs and still have backwards compatibility. So the rule has to be
slightly more complicated. The static keyword is only required on static
VDAs where there is an allowed choice between static and automatic
lifetimes of that variable.

 

Dave

 

 

________________________________

From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] 
Sent: Friday, November 03, 2006 1:18 AM
To: Rich, Dave; sv-bc@eda-stds.org
Subject: RE: [sv-bc] Is dynamic variable written in continuous
assignment

 

Thanks.

 

Using those rules, why require the user to add the keyword 'static' on a
variable declaration assignment in a procedural block, for example?

 

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