From: Adam Krolnik (adamk@cyrix.com)
Date: Fri Oct 23 1998 - 01:54:16 PDT
My comments from the large amount of text you sent.
------------------------------------------
Library definition components:
1. name (module name, view?)
2. elements
3. locations
Methods of creation:
A. `library naming specifies following elements
Questions/comments:
This must terminate with the end of a file?!
So you specify the name of the library in a file,
What do you say to load file/directories into a library?
B. Separate library file defining library(ies?), elements.
Question/comments:
Need another file to define files/directories as part
of library? Don't see usefulness of a file with library
name and element names as only way to go.
While I see the usefulness of separating the library file or
directory names from the library definition, I see usefulness
in defining a library from all the modules defined in a file
or directory. Maybe it would be best to allow filenames
within a definition and in another place so one has the flexibility
to do what is most useful at the time. Later, then can modify the
library definition to remove filenames if required.
------------------------------------------------------------
What is this doing? Why not say "view behav, gate, rtl" if one piece is part
of all three views? Why switch a view based on what `define is set?
Similar methods can be used to specify the view. The `view directive could
be used with `ifdef to set the view for a module based on the macros defined:
`ifdef BEHAV
`view behav
`else
`ifdef GATES
`view gate
`else
`view rtl
`endif
`endif
module DFF();
endmodule
------------------------------------------------------------
Naming of pieces
module -> cell
instance name -> inst
hierarchical name -> path
Confusing... and error prone. What about someone using instance name in two places.
Must use full hierarchical path? or root of tree? You asked this about Cliff's
proposal. I see use of both, but I don't understand the difference between inst
and path. Maybe only module or hierarchical path (which may be a subset of the
actual compilation path if used in a configuration defining a specific piece.)
------------------------------------------------------------
>config adders1
> instance top.i2
> uselibfile /proj/gates/adder.v
> endinstance
Hate this! Like idea of saying 'get module for <instance> from library(:view)'
>// Note that these library directives can be included
>// in the source file with the config or can be
>// in a separate file which gets `included
>`library vlib file="/proj/vlog/adder.v"
>`library glib file="/proj/gates/adder.v"
Hate this! Same problem set as 'uselib! A library definition or
mapping will specify too much information to be reasonably defined
by command line switches.
>// LIBRARY_MAP = (
>// /proj/vlog/ => vlib,
>// /proj/gates/ => glib,
>// * => work) // work is the default by default
Hate this! Let's call this the first idea and remind ourselves 'The first idea
is the worst and needs a better one.'
>Need notion of directory and file I think...
What is the + => or * => stuff? What is "work"?
I could see a configuration file/library definition file that could be used
to define configurations or libraries (with or without filenames.)
Some configurations will be simple and could best be described with
one file and a library (with filenames.)
Some configurations will be more complex and would benefit from
having hierarchical configuration files (one defines system, another
defines IP reused block with specified libraries, another defines
new code without libraries, another defines mapping of filenames
to libraries.)
Some configurations will be distributed to other sites on other platforms
and requre separate definitions of libraries and locations as well as
IP definitions.
<p> Adam Krolnik
Verification Engineer
Cyrix - NSC.
Richardson TX. 75085
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:00 PDT
and
sponsored by Boyd Technology, Inc.