From: Adam Krolnik (adamk@cyrix.com)
Date: Wed Jul 15 1998 - 21:33:40 PDT
Good morning,
<p>Before I put my 2 cents in on this topic, I would like to say that I feel
this topic is too large to begin now. The remaining work on the erratta
and enhancements currently on this list is large enough that it may become
an either or situation. This configuration enhancement would require it's
own chapter as well as modifications to existing ones. Not only is a
syntax needed, but the exact features, abilities and restrictions defined.
This would be a long task given the amount of time it takes to pass erratta
and simple enhancements.
Now my comments on this topic.
I see the goals from the original mail as these:
1. Separate filename/path from module name - This is a worthy goal.
2. Group cells into libraries named for later reference.
3. Allow same cell name in a library with another method of distinction
(specifically for alternate abstractions/implementations.)
4. Method for specification of modules for specific instances in terms
of the libraries/abstraction/location.
5. Hierarchical organization of libraries.
<p>On the specification of libraries, I would not be in favor of adding this ability
at the command line. This should be file based so one can reference the library
either as a usage or in building a superset library.
Library names should not be restricted to one name. Consider someone creating
two libraries for different reasons that have some common components. Library
names if defined within the source should not be restricted from being added
to another library.
There are really two forms of libraries: an unconnected collection of cells and
a connected collection of cells. The second one would be like an ASIC that is
composed of a specific set of cells and are connected to each other. One would
be building a library only containing the pieces necessary to compose the ASIC.
It would be nice if instead of having to exactly list all the pieces necessary
for building it, libraries could be specified and then have the builder determine
the necessary pieces and throw away the rest.
Of course each library should have it's separate rules for specifying what
cells are included. These rules should not be global as the current -y, -v,
+incdir and +libext ordering.
The need for multiple cells with the same name (but with a differentiator
- the 'view') is intriguing. It makes sense if you accept the argument
of putting several versions of IP into one library. I think the idea
is interesting but will need a good implementation to be accepted.
If one intends to place the view inside the source, then the view
should be executable by the source. I.E. their example required a
+define to indicate which view was required. This is silly, the
view should be available from the preprocessor if that is the ability
they want.
Specification of a "config" a cell to instance mapping should have the
general/specific properties they suggest (or search order if you will.)
It also must include the ability to specify +define and +arg switches.
You will miss out greatly if you can't specify those as part of a
configuration. You also must be able to reference a previously
defined "config" either for a set of instances, or for inclusion
within the current config. This is required for hierarchical creation
of a config. When specifying a specific mapping for an instance, it seems
to me that the needed information is library and view. Requiring
library:cell:view (as the first mail suggested) is redundant (use of cell)
since it is defined within the source (and it's bad to require the same
information in two places.)
<p>Configs need to be used as:
Library creation
sub design unit packaging
top level simulation definitions
<p>Has anyone gotten here? GOOD, I'm done! Maybe this is the start of that chapter.
<p> Adam Krolnik
Verification Engineer
Cyrix - NSM.
Richardson TX. 75085
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:57 PDT
and
sponsored by Boyd Technology, Inc.