SVDB 1397 _ X __Yes ___No http://www.eda.org/svdb/view.php?id=1397 SVDB 1809 ___Yes _ X __No http://www.eda.org/svdb/view.php?id=1809 I think this issue needs more discussion in order to reach consensus. The V1 proposal from Gord has the unfortunate feature that task and function names triggered imports, but then the names do not bind to the import they triggered. That seems wrong to me. The V2 proposal from Francoise is really going back to what I originally proposed, which is delaying import decision under some circumstances from parsing to name resolution. Some people were strongly opposed to this. I am not sure how the V2 proposal could be implemented other than by the technique I outlined a long time ago. The V2 proposal as written would apparently require that tools keep track of the lexical context of every task/function name reference and all the import statements in order to make name binding decisions. I suppose it may be ok to describe it this way in the LRM, although this may not be the way tools would implement it. SVDB 2037 ___Yes _X__No http://www.eda.org/svdb/view.php?id=2037 I still have a number of problems with this proposal. 1) The proposal allows local parameters to be created in configurations without clarifying if a configuration is now a scope or if these parameters are somehow being added to the scope the instance is in. 2) I don't think the current proposal makes clear that the overrides must be constant expressions. 3) The proposal say that overrides may include "reference to an identifier in the target instance context." I find this confusing. What is the target instance context exactly? Can it include references to $unit identifiers? Can it include references to already imported package identifiers in the context scope or enclosing scopes (like $unit)? I assume it cannot not trigger a wild card import. 3) It is not clear if you can make <packageName>::<identifier> references in local parameter or override expressions. If you can, can you do this if the package is referenced no place else in the design? Does this then make the package part of the design (this can have side effect of executing code invoked from the initial value expressions of variables in the package). 4) I do not like allowing hierarchical identifiers in configuration overrides. SVDB 2106 _X__Yes ___No http://www.eda-stds.org/sv-bc/hm/7701.html http://www.eda.org/svdb/view.php?id=2106 SVDB 1602 _X__Yes ___No http://www.eda.org/svdb/view.php?id=1602 SVDB 2097 _X__Yes ___No http://www.eda.org/svdb/view.php?id=2097 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Dec 15 18:22:46 2007
This archive was generated by hypermail 2.1.8 : Sat Dec 15 2007 - 18:23:17 PST