Mark Hartoog wrote: > > > 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. > This is really an implementation issue. The configuration has to either borrow (super impose) the scope of the confing's "design" or it will have it's own scope. From the perspective of the coder it will look the same. This has to already be in place today for configurations to override instancing. > 2) I don't think the current proposal makes clear that the overrides > must > be constant expressions. > I will tighten the wording up on this. > 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. > The proposal in for literals and system function only. Not for packages or $unit. > 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. > Shalom has addressed this. -- ========================================================== Don Mills mills@lcdm-eng.com www.lcdm-eng.com ========================================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 17 08:46:45 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 08:46:54 PST