>>SVDB 1339 _X_Yes ___No >>http://www.eda.org/svdb/view.php?id=1339 >> >>SVDB 1345 _X_Yes ___No >>http://www.eda.org/svdb/view.php?id=1345 I do think that 12.4.2 should say "after finding a true condition" instead of "after finding a matching condition". Can we make this a friendly amendment? Case-statements look for matches, while if-statements look for true (though that could be regarded as "matching" non-zero). The rest of this section refers to true conditions. I assume that this was just a copying error from the case section. I am also not sure that 12.4.2 should be saying "evaluate and compare" instead of just "evaluate". This may have come in from the case section also. Yes, there is an implicit compare to zero, but that is just the definition of whether the condition is true or not, so I don't think it needs specific mention. It seems more likely to confuse than help. However, I acknowledge that it is not wrong. It is still possible that this text could be misinterpreted as meaning that it executes the first true/matching statement *of the subset that it evaluated before finding a violation*. However, it is hard to make it completely clear while leaving the flexibility Gord requested. Overall, I think that the proposed text is quite good, and a definite improvement. >>SVDB 1583 _X_Yes ___No >>http://www.eda.org/svdb/view.php?id=1583 >> >>SVDB 1809 ___Yes _X_No >>http://www.eda.org/svdb/view.php?id=1809 Should wait until Dec 10 for Francoise's revised version. >>SVDB 2222 _X_Yes ___No >>http://www.eda.org/svdb/view.php?id=2222 >> >>SVDB 2225 ___Yes _X_No >>http://www.eda.org/svdb/view.php?id=2225 There are a number of other problems in this section that should be fixed, but I will confine my comments to the text being changed. In the first text change, the name of a parent module declaration is allowed instead of its instance name. The same would presumably apply to a program or interface name. However, this was not mentioned in this part of the text before, so maybe it is a separate issue. In the second text change, the revised text would read "If not found and the current scope is not the module scope, look for the name in the enclosing scope, repeating as necessary until the name is found, or the compilation unit scope is reached." Notice the "and the current scope is not the module scope". That would imply that we don't look in the compilation unit scope if the current scope is the module scope. If it is assumed to apply to each repetition, it would prevent us from ever looking in the compilation unit scope. This was basically a combination of a bottom-testing loop with an if-statement, to make it act like a while loop. That has a problem if you change the condition on one without the other. The simplest fix is to strike the "and the current scope is not the module scope". We don't need to prevent a look upward starting from the module scope any more, since we will always be going up at least once before we reach the compilation unit scope. In the final text added to the end of item b), it should not say "design unit scope is reached". It should say "module scope is reached". I think we have agreed that upward hierarchical searches do not look in the compilation unit scope of parent instances, only in the compilation unit scope of the reference. If this was just an error, and it should say "module scope is reached", then that should fix it. If you really think that it should be looking in the compilation unit scope of parent instances, then we have a bigger issue. >SVDB 1571 ___Yes ___No _X_Abstain >http://www.eda.org/svdb/view.php?id=1571 The new proposal addresses the specific concerns that I had with the text. I still have more general concerns about adding this functionality at this stage of the process, when there are still open issues with the existing macro functionality. However, since nobody else appears to share that concern, I will not vote against the proposal. There is no point in wasting meeting time on a live vote if nobody else votes against this in the email vote. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Dec 4 15:19:26 2007
This archive was generated by hypermail 2.1.8 : Tue Dec 04 2007 - 15:19:51 PST