Subject: Re: $root proposal
From: Adam Krolnik (krolnik@lsil.com)
Date: Wed Apr 03 2002 - 10:08:17 PST
Hi Stefen;
1. The statement "All uninstantiated modules become implicitly
instantiated within the top level, ..."
Is this 'top level' referring to the $root top level? I am confused
because the first statement says, "In SystemVerilog there is a top level
called $root,..."
I'm thinking, "can there be another top level called thetop?"
Maybe the first statement should say,
In SystemVerilog the top level is named $root. Verilog has
an unnamed top level.
2. How about an example of referencing a net in $root from
another module, or at least a description that this is
possible.
3. The statement in the comparison for $root says:
- may not contain any initial or always procedures
- may contain procedural statements ...
Why the restriction - I can have the statements, but not the word,
'initial'?
4. Section 15.3 library mapping
I would like to see an example of the library mapping information stored
in $root. I don't think this would work... Maybe we have different ideas
on how the lib.map file works?
5. Instead of allowing a random collection of functions,
tasks, typedefs, etc. to be placed into $root, why not
instead have these things as part of an interface?
If you have to import tasks/functions/nets/variables/parameters
they I would rather see someone importing an interface to
access these rather than a scattered set. It seems cleaner
and easier to maintain this way.
This then frees up the keyword 'import' to be used when a
good object model can be imparted to Verilog or SystemVerilog.
Either this, or drop the importation and require instead
that the elements (that would require an import) be referenced
from $root.<element>.
Thanks.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Wed Apr 03 2002 - 10:09:55 PST