From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Wed Apr 28 1999 - 07:51:06 PDT
BAD MSG:
Hi Adam,
-Lines: 108
Content-Type: text/plain; charset="us-ascii"
Content-Length: 4483
X-Status: $$$$
X-UID: 0000000872
Status: RO
Thanks for your comments. Their disposition is included below:
>I have these comments on the configuration proposal:
>
>
>1. (2.1) Should the listing of files contained in a library be standardized?!
Absolutely not. This is an implementation-specific decision and is a key
area of differentiation (performance/ease-of-use) among vendors. As long as
the mapping works correctly, it doesn't matter exactly what the libraries
contain or where they reside.
>2. (2.1) The character '.' specifies the 'same directory as the "lib.map"
file is
>in'.
Thanks. I've added the clarification.
>3. (2.1) Do all relative file references have to start with "./"?
No. I've added the clarification that all paths that do not begin with "/"
are relative to the directory containg the lib.map file.
>
>4. (2.1.1) What happens with multiple cells in a library with the same
cell name?
The LAST cell encountered is written to the library. I've added this
explicitly to the proposal. This is to support a "separate-compile"
use-model where it is assumed that encountering a cell after it has already
been compiled is intended to be a recompilation. Otherwise, there's no way
to distinguish between the "I want to recompile this cell" case and the
"Oops, here's another cell with the same name but ignore this one" case.
This is a prime example of why views would be useful. If you've got
multiple modules with the same name, you can map them to different views of
the same cell in the same library and distinguish between them.
>5. (2.2) Reference to 'views'.
Nice catch.
>6. (3.1) Recommend replacing 'selection_clause' and 'expansion_clause' with
> all legal combinations. Its too confusing to read and understand
> each one separately.
I don't know how to write the BNF for combining them. I'd be happy to fix
it if you (or someone else) shows me how.
>7. (3.4.1) Liblist_clause doesn't allow multiple library specifications.
I thought that the BNF notation "{library_identifier}" meant "one or more
library_indentifier". If not, what should the correct BNF be?
>8. (3.4.2) I thought the alternate for 'bind' was 'use', not 'binding'.
"Bind" is the verb. The clause was always called "binding." If the BTF
prefers "use" I guess we can add it. Since I've already acquiesed on
"inst", I was hoping to keep one of my original names in tact. 8-)
>
>Omissions:
>
>1. What about include paths: for a configuration? for a library?
Not sure what you mean by "include path". Configurations themselves reside
in libraries and deal with library components (including other configs).
Since configs occur in "standard" verilog, there's no reason you can't use
`include inside of a config declaration to include another file in the
declaration. The include command is already specified for lib.map files.
>2. What `timescale will a module inherit when compiled into a library
> with no definition of file order?
If multiple files are specified to the compiler at a time, then `timescale
and other directives would inherit across file boundaries as they do now.
If each file is compiled separately, then each file would need to set the
directives it needs explicitly (or include a file that contains them).
>3. What happens with conflicting `defparam statements when compiled into
> a library with no definition of file order?
Defparams are only used at elaboration time, not compile time. The
conflicting defparam statements will be resolved as they are now when the
library cells are connected at elaboration time.
>4. What about +define+SYMBOL values for a configuration?
Configurations can only refer to already-compiled cells in the library,
they cannot provide command-line arguments to the compiler. If you need to
refer explicitly to "this cell compiled with these options", then that's
what views would have given you. You could have said
compile foo.v +define+SYMBOL // map to view SYMBOL
compile foo.v // map to view NORMAL
and then refererred to either lib.foo:SYMBOL or lib.foo:NORMAL as required,
without having to go back and recompile lib.foo
<p>Thanks for you help. I'll be sending out the updated proposal later today.
-Tom
---------------
Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc.
RTL Verification Flow/Product Engineering 270 Billerica Rd.
Design and Verification R&D Chelmsford, MA 01824
x6438 (978)446-6438
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:26 PDT
and
sponsored by Boyd Technology, Inc.