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, > ShalomReceived on Fri Nov 3 02:01:48 2006
This archive was generated by hypermail 2.1.8 : Fri Nov 03 2006 - 02:02:00 PST