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