From: Adam Krolnik (adamk@cyrix.com)
Date: Fri Jan 22 1999 - 11:18:53 PST
Hello Tom,
Thanks for the exposition of examples. Many comments - many to
enhance comprehension of the functionality.
Thanks.
1. The order of the -v/-y files affecting what gets simulated
is not a shocking concept. A better indicator of confusion
would be these:
a. I put an extra module in my file, but it doesn't find
that module (ordered wrong in a library directory file.)
b. I specified a parameter override on an instantiation,
now it picks up a different module from some other library
(presence of parameter overrides cause library searching to
locate modules with parameters.)
2. I am no longer fond of defaulting to ./lib.map. I really don't
like automatic searching of $HOME for files.
This shoots your argument for better packaging of designs -
A user inadvertently specifies something in his home
library mapping file.
3. You probably want to add that ".." means back a directory in your
lib.map syntax section (3.1)
4. Section 4.1 last paragraph - "The design statement ... is used to
specify the top-level module representation (s) to be used for
the design."
Is 'design' a good word? Does it make sense in the context that
you can define multiple top level modules?
5. Section 4.2, 'simulate work.config1b'
Does one have to specify 'work' or could it be implicitly understood
if not specified. I believe that a very common method would be to
have the config file in that library.
We would still need to have some method of specifying which
configuration to actually simulate/build. Saying
'verilog-xl config1b'
Is ambiguous - is that a file or a name of a configuration? Which
does the user intend?
6. Section 4.3 'default clause'
You didn't describe the default clause like you did the rest.
7. Consider 2 modules (in 2 libraries or 2 views) that have the
same structure (same instances within (both modules and instance
names.)
If you use the selection clauses to specify an alternate
library/view, how does this affect the hierarchy below the
specified path/cell/inst? E.g. I want cell foo/inst ifoo/path top.ifoo
to come from the accurateTime library. Are the instances within
foo/ifoo going use whatever library search list is in effect or
do they come from the accurateTime library because the parent
came from there?
8. Configuration 3B
This seems redundant: (You say gateLib twice!)
path tb.g1.grmod.dma.(gateLib.fsm) liblist gateLib
And, why do you drop off the final name of 'tb.g1.grmod.dma.fsm'?
9. Binding expansion clause
Why do you require the cell name but the library and view are
optional? This seems error prone as you now specified information
both in the verilog source and the config file that may need changing
if the verilog source code changes.
E.g.
config ...
path tb.g1.grmod.dma.fsm gateLib.fsm
endconfig
module dma;
...
nfsm fsm(); // Oops designer working on new fsm and tried it out!
endmodule
9. Binding vs. Liblist
Are these different?
path tb.g1.grmod.dma.fsm binding gateLib.fsm
path tb.g1.grmod.dma.fsm liblist gateLib
10. Is there a name of the default view?
Say I want to do this:
lib.map
----------
view [default]
directive timescale = 1ns / 10 ps;
I think I really want this functionality in
a config - so I can nest them. I.e. A package
of code I got from XYZGRGl uses a timescale
of 10ns /1ns. My design uses 1ns / 10ps.
I hope they specified this in their config
file so their code doesn't break mine.
11. Example 7a - optional $display statement.
Why not use %l and explain what %l will actually write
out.
12. Precedence of view statements.
"The macro, directive, and arg clauses ... take precedence"
I see this functionality as extraneous and confusing. E.g.
I made a module change, now it doesn't compile! Oh, the
'define I made conflicts with yours and now I get put
in your view and don't get compiled - what?!
If you want to have macro's defined when views are invoked
thats fine (I'll vote for that.) But I don't want the
transitive functionality - define a macro and viola, the
view gets invoked - What if there are multiple macros
defined - do they all get defined then?
It is reasonable to expect that if someone put a macro
in a view they should specify using that view to get
the macros defined.
To place views, libraries and (with the view statement precedence)
macros/directives/arguments in independently definable structures
makes this very flexible - but very confusing and easy to get
it wrong. I don't think one needs total flexibility - something
we have seen with several enhancement requests voted down.
13. (Lastly) Invocation of examples
All you examples use the old run_old.f file. Could you give
some examples where you show that it is not needed. It
seemed that there were several examples where the configuration
files should have taken its place.
Adam Krolnik
Verification Engineer
Cyrix - NSC.
Richardson TX. 75085
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.