From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Fri Jan 22 1999 - 14:39:51 PST
BAD MSG:
Hi Adam,
-Lines: 368
Content-Type: text/plain; charset="us-ascii"
Content-Length: 14517
X-Status: $$$$
X-UID: 0000000812
Status: RO
At 01:18 PM 1/22/99 -0600, Adam Krolnik wrote:
>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.)
Thanks for the clarification. I think we still need to work out the details
of how parameters are going to affect all of this.
>
>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.
The presumption is that, if it's that critical, you'll provide a lib.map
file to be included in the user's lib.map file. Defaulting to $HOME is
something we do in NC-Verilog so I thought I'd put it in. It's not
critical. I believe there should be a mechanism for vendors to use so that
users don't have to include lib.map on every command line. They should be
able to do so, however, if they prefer.
>
>3. You probably want to add that ".." means back a directory in your
>lib.map syntax section (3.1)
Thanks. I kind of took it for granted.
>
>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?
I think it's OK. If someone has a better idea I'm open. I'm not sure "top"
is necessarily better.
>
>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.
This example assumed separate compile and simulate steps. In this
use-model, the compiler takes source files as input, but the simulator
takes a compiled cell. In this case, saying "simulate config1b" means that
the simulator will look in the work library for a config1b cell. If that
cell is a config, then it'll go get the top-level cell (from the design
statement in the config) and you're off and running. Conceivably, this
could also allow a tool to take a top-level compiled cell by itself, and go
off and bind everything according to the default (i.e. config-less) rules
using the library and view specifications in the lib.map file.
The actual invocation I believe should be left up to the vendors.
>
> 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?
Verilog-XL is a single-pass tool. It expects a source file on the command
line (like the compiler above). We're not trying to specify a use-model,
but we are trying to make the config/library functionality compatible with
both.
>
>6. Section 4.3 'default clause'
>
> You didn't describe the default clause like you did the rest.
Thanks. Again, I assumed too much.
>
>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?
The current liblist gets inherited. If you wanted, you could reset the
liblist.
config tmp;
default liblist myLib accurateTime;
path top.ifoo liblist accurateTime;
endconfig
The new liblist in effect for top.ifoo now contains just accurateTime and
this liblist is inherited for the descendants of top.ifoo. You could also do:
config tmp1;
default liblist myLib accurateTime;
path top.ifoo binding accurateTime.foo;
path top.ifoo liblist; // empty liblist inherits the library of the parent
endconfig
If you just do
config tmp1;
default liblist myLib accurateTime;
path top.ifoo binding accurateTime.foo;
endconfig
then the descendants of top.ifoo will use the liblist myLib accurateTime,
but top.ifoo itself will be bound to accurateTime.foo.
>
>8. Configuration 3B
>
> This seems redundant: (You say gateLib twice!)
>
> path tb.g1.grmod.dma.(gateLib.fsm)fsm liblist gateLib
If this is the only statement, then yes it's redundant. The liblist
specified is used for binding the specified path instance and its
descendants. If there were a binding clause elsewhere in the config that
bound the tb.g1.grmod.dma.fsm instance to a different library, then this
notation would allow you to catch that error.
>
> And, why do you drop off the final name of 'tb.g1.grmod.dma.fsm'?
That's a typo.
>
>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
This is another example of how the (cell_inst_name) notation comes in
handy. If you said
path tb.g1.grmod.dma.(fsm)fsm
then the fact that the instance tb.g1.grmod.dma.fsm actually reflects the
cell nfsm would be flagged as an error. You could actually do
path tb.g1.grmod.dma.fsm binding myLib.nfsm;
without modifying the original source, which actually gives us the ability
to bind instances to cells that have different names, which is common in
VHDL but was never before possible in Verilog. Of course, if this is too
flexible, then we can stipulate that the cell used in a binding clause must
match the module specified in the source code.
>
>
>
>9. Binding vs. Liblist
>
> Are these different?
>
> path tb.g1.grmod.dma.fsm binding gateLib.fsm
> path tb.g1.grmod.dma.fsm liblist gateLib
Yes. The binding clause specifies the binding for the particular instance,
without affecting the liblist used on its descendants. The second uses
gateLib for fsm and its descendants.
>
>10. Is there a name of the default view?
As specified in the original proposal, the default views are
module -> module
macromodule -> module
primitive -> udp
config -> config
> Say I want to do this:
>
> lib.map
> ----------
> view [default]
> directive timescale = 1ns / 10 ps;
It sounds like you're confusing mapping vs. commands. As shown in the BNF,
you have to give a view name in order to specify any view_items. If we use
view t0110 directive timescale = 1ns / 10 ps;
Then that means that any modules encountered at parse/compile time with the
specified timescale will be placed in the t0110 view. In the absence of
another view specification, all other modules will be placed in the default
(e.g. "module") view.
>
> 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.
Their config file should refer to the t0110 view for their stuff. Something
like
config xyz;
design xyzLib.top:t10n01n; // timescale = 10ns/1ns
default viewlist t10n01n;
endconfig
This will bind their top-level top and everything below it to their t0110
view, regardless of what all of your stuff is bound to. You would have to
make sure that your config referred to cells that had been compiled with
1ns/10ps. Your lib.map should contain
view t01n10p directive timescale = 1ns / 10ps;
>
>11. Example 7a - optional $display statement.
> Why not use %l and explain what %l will actually write
> out.
Good point. I was planning on using two DEBUG variables and using %l in the
other one, but I ran out of time.
>
>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?
Whatever macros are referenced in the module are checked and if they are
defined, then the appropriate view is used. If a compilation matches two
different view specifications, then it's an error:
library fooLib file "./foo.v";
view foo macro FOO;
view bar macro BAR;
compile foo.v +define FOO +define BAR
can't tell whether to use view foo or view bar, so it's an error. I put in
the part about directives having precedence over files so that you could
specify views via directive across multiple files.
library myLib file "./*.v";
view foo file "./foo*.v";
view bar file "./bar*.v";
This puts foo1.v, foo2.v etc into myLib.<cell>:foo and likewise for bar1.v,
bar2.v etc. If I want to create debug views for these, for example, then
unless I give directives precedence over files, I have to create a view
specification that not only includes the macro, but also covers all
possible files:
view debug macro DEBUG,
file "./foo*.v", file "./bar*.v";
This could get very cumbersome very quickly, particularly if I want to use
many different macros to create multiple views for many different files.
I'd like to go back to one point you made in this question
> But I don't want the
> transitive functionality - define a macro and viola, the
> view gets invoked
The view only gets invoked automatically if you aren't using a config,
because that's the only time that the view order is taken from the lib.map
file. You're welcome to compile separate versions of your files with and
without the macro defined
compile *.v
comile *.v +define+DEBUG
and then use your configurations to use the default view or the debug view
for each instance of your design. If I'm not using a config, then the view
order is taken from the lib.map and the presumption is that if you place
the debug view first, then you want specifically to use that view for every
cell that contains that macro. We added the part about the module having to
contain a reference to the macro to avoid creating two different views that
are identical for modules that do not contain the macro.
Please note that for a single-pass tool, putting +define+DEBUG on the
command line affects all modules that contain the macro. Using separate
compilation, you could choose to compile only a certain set of module with
the macro defined.
>
> 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.
>
A slightly less flexible, alternative would be not to allow mapping of
views but to require the view to be specified at compile-time. We could
then replace the view specifications in the lib.map file with a viewlist to
be searched by default.
viewlist debug module udp config;
and require the view specification to be placed on the command line (or in
the source using `view)
verilog foo*.v bar*.v +define+DEBUG +view+debug
Of course, if this is a global view assigned to every module encountered,
then you're going to have multiple views of certain cells (the ones without
`ifdef DEBUG) that are identical, which is wasteful. We would have to
specify then that, if there is a macro defined on the command line and a
view is also specified then the view name is applied only to those modules
in the specified source files that reference that macro.
I haven't thought out all of the ramifications to this approach yet, but my
gut feel is it's a bit less confusing. Do you agree?
>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.
The examples which used the run_old.f file were intended to show how a
single-pass tool could use essentially the same command line as today, and
that it would still be required to specify the source files that make up
the desired design in order to know the set of cells from which instance
bindings may be selected. In a multi-pass tool in which modules are
compiled separately, the set of cells which may be selected at binding-time
is the set of cells that have already been compiled. In this case, as
above, it is probably sufficient to give simply the compiled configuration
as an argument to the simulator. If the configuration does not contain a
design statement, then the source description of the top-level module may
also need to be provided to the simulator. This is intended to be
tool-specific and is independent of the specification.
Thanks again for your input,
-Tom
---------------
Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc.
Cycle Simulation Products 270 Billerica Rd.
Logic Design and Verification Business Unit Chelmsford, MA 01824
x6438 (978)446-6438
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.