>SVDB 907 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=907 Stu raised the issue of VPI access. As Doug pointed out, after elaboration all of these parameters will have values, or there would have been an error. However, I believe VPI can access the default value of the parameter as well as the final value. We should at least check with the SV-CC to make sure there is not a problem with a null value here. >SVDB 1134 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1134 Though I am still concerned about the potential for confusion in ordered parameter override lists... >SVDB 1294 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1294 > >SVDB 1348 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=1348 I have a problem with the text "A statement label on a for or foreach loop names the implicit block created by the for or foreach loop." This implies that a for loop always creates an implicit block. But it only creates an implicit block if it is the extended form that has variable declarations in the initializer. I would suggest that this be changed to something like "A statement label on a foreach loop, or on a for loop with variables declared as part of the for_initialization, names the implicit block created by the loop." And Stu, the answer is presumably that this would allow the name to be used to access the loop index, except that the loop indexes are automatic variables. Automatic variables cannot be accessed hierarchically. >SVDB 1464 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1464 > >SVDB 1468 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1468 > >SVDB 1588 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1588 > >SVDB 1619 ___Yes _X_No >http://www.eda.org/svdb/view.php?id=1619 I think that we need more discussion of the fact that this creates a difference between .* and a .name connection for every port in the module declaration. It should also be made clear that the constant expression for the default is evaluated in the scope of the module where it appears. Any identifiers will resolve to parameters in that scope, not in the scope of the instantiation. There are also some wordsmithing issues. Some of the sentences are overly complex and hard to follow. There are also some issues with nonstandard or informal terminology, such as "hook up". Since this was a first stab at a proposal, I don't think that this is unexpected. >SVDB 1792 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1792 > >SVDB 1940 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=1940 I am approving, because I think this is an improvement. However, there is still an issue with the wording when only a range or signedness is specified. The text says "if only a range and/or signing is specified, then the data type of the net is implicitly declared as logic". But if a range is specified, then the data type is not declared as logic. It is declared as a vector or packed array of logic. And if "signed" is specified, then the data type is declared as "signed logic", not "logic". >SVDB 2024 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2024 > >SVDB 2056 _X_Yes ___No >http://www.eda.org/svdb/view.php?id=2056 Though I think the word "also" should be removed from the sentence about the step assignment, since it no longer matches what is allowed in the initial assignment. 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 Sat Oct 13 12:08:45 2007
This archive was generated by hypermail 2.1.8 : Sat Oct 13 2007 - 12:09:03 PDT