From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Tue Jan 12 1999 - 13:37:45 PST
At 01:09 PM 1/12/99 -0600, Adam Krolnik wrote:
<p>BAD MSG:
>
>Hello Tom,
>
>Thanks for the time to make the proposal and convert the examples.
>Here are my questions/comments.
X-Lines: 328
Content-Type: text/plain; charset="us-ascii"
Content-Length: 12523
X-Status: $$$$
X-UID: 0000000794
Status: RO
Thanks for taking the time to review it. I'll include my answers to your
questions below.
>
>0. This proposal is huge in the amount of functionality that it presents!
>Add to it attributes - I am beginning to get worried about this amount of
>functionality added at the last minute without some good thinking about
>it. We argued/thought more about the mundane erratta/enhancements than
>this one.
You make a good point, I guess. I would point out that Cadence has been
using the attribute syntax for years. We decided to propose it because it
does fit well with the config proposal in allowing you to specify in your
source code what representation is to be used for a given instance. We do
consider them to be two separate proposals, however. On Friday, I'd like to
go over the config proposal first, and then if we have time, go over
attributes.
>
>1. lib.map syntax
>
>Hate the `view, `library, `this `that `this again!
We actually chose this notation so that we wouldn't be adding any new
keywords. I also realized that, by separating things with commas and
terminating with a semicolon allowed us to avoid library-endlibrary or
view-endview pairs. It's essentially a syntactic choice between
library foo;
dir "/proj/dir1/", "/proj2/dir2";
file "./vlog/*.v";
endlibrary
and
(`)library foo
dir "/proj/dir1/", dir "/proj2/dir2",
file "./vlog/*.v";
Making them look like compiler directives allows you to parse tokens in a
different "namespace" than for regular source, so dir, file, etc. don't
need to be keywords. I'm not sure if you can specify these things as
keywords only when they appear in a library-endlibrary or view-endview.
>
> A. I would rather see the `view (which can be coded into Verilog source
> code files) functionality reduced. This seems like a big extension
> of `uselib which people don't seem to happy to have.
Actually, the proposal specifically states that the lib.map file will be
parsed before any source files on the command line, and that it is an error
if `library or `view are encountered after a module or udp declaration.
Therefore, `view cannot appear in arbitrary places in the source code. This
restriction will be required whether we use `view or just view.
>
> I would support this functionality in a lib.map (or equivalent)
> file. But I don't like keeping the ` marks to start the commands.
ee above.
> It is obtuse to me to have +define and compiler options as part of a view.
I'll try to explain below.
>
> B. What does it mean to have a +define with this view?
> Does the compiler have to analyze the source files repeatedly
> for each view encountered?
It means that that view was created by invoking the compiler with +define+foo.
mod1.v:
module mod1(a);
output a;
reg a;
`ifdef foo
initial a = 1;
`else
initial a = 0;
`endif
endmodule
lib.map:
`view set arg +define+foo, file "mod1.v"; // or `view set macro foo, file
"mod1.v";
`view clr file "mod1.v";
If I compile mod1.v +define+foo, it goes into view "set". If I just compile
mod1.v, it goes into view "clr".
This brings up a good point. If I have
`view set arg +define+foo;
then any file encountered with foo defined will be put into view set, but
there is no way to specify "any file encoutered with foo not set". If I
just say
`view clr;
that forces everything thereafter to be view clr. This means there would be
a difference between
`view set arg +define+foo;
`view clr; // overrides the `view set
and
`view clr; // sets everything to clr
`view set arg +define+foo; // except if +define+foo
Is that OK?
>
> C. What does it mean to have a compiler option with a view?
> Does the compiler have to optimize the source files differently
> for each view encountered?
Yes, but remember if you encounter multiple instances of a given
lib.cell:view, you're still only compiling it once. After that, you're
referencing the one you already compiled. I suppose if you wanted to
recompile you could, but that would give suboptimal performance.
>
> I can understand the usefulness of having this - the debugging
> example. But I think it's too much to be able to put this
> all in the source code as a super compiler directive. If its
> still kept in how about merging macro and arg into one -
> you can say +define+MACRO which is a command line argument.
Again, it's not really going in the source code. This stuff can only appear
in the lib.map file. The only drawback to merging macro with arg is that
macros can be set from within the source code with `define. If you keep
track of all macros defined when each module declaration is declared, then
this is fairly straighforward.
>
>
>
>2. You show examples of an equivalent -y <> -v <> operation in these
> files. How does one do the equivalent of +libext for directories?
The equivalent of +libext would be to use wildcards
-y /proj/vlog +libext:.v = file "/proj/vlog/*.v"
I'm not sure there's a need to have both dir and file. They're both in
there to help the parser know what it's looking for.
>
>
>3. Example Senario 1e (asic1_install_035) How does core view
> get incorporated into rtl?
The default liblist for the rtl-based config causes it to look for cells in
proj2lib and vendor1_035_lib. When it locates a cell in vendor1_035_lib,
the vendor's lib.map file (which defined the library in the first place)
specifies that you should only be looking at views core and gates in this
library. That's what the library viewlist construct does. It gives vendors
a way of specifying the set of valid views for the libraryies which they
deliver. If we didn't do this, then every config that used that library
would have to have
lib vendor1_035_lib viewlist core gates;
in it, and that's cumbersome.
>
> You show an example of including additional elements into the
> library definition file. I don't understand the viewlist
> functionality. There is a viewlist in the config that
> only lists rtl. Why should the core view be searched?
The viewlist rtl is a default statement. This means that, for any element
that is not covered by a more specific statement, look for the rtl view
only. As mentioned above, the viewlist in the vendor1_035_lib declaration
is a more specific statement, so that takes precedence over the default
viewlist for all cells in that library.
>
>4. What happens if a vendor library defines a view that is
> in conflict with a view from another library? Is there
> the ability to rename the view?
Now you're getting into an area which had me briefly concerned answering
your +define+MACRO question above. The real question is: what should be the
scope of a view declaration? Should it be "hierarchical" and inherit across
included files, or should it be local to the file in which it is declared?
Seems to me like you want it to inherit, so you can have one global lib.map
file that everyone can include from their own and then add to
include "/proj/global/lib.map"
`view ...
`library ...
The proposal states that the
`view;
tatement will reset things so that cells get the default view. Vendors
could then put a `view; at the beginning of their lib.map files to reset
things. This might force users to include vendor lib.map files only at the
end of their own, or to have the global lib.map file include all of the
vendor lib.map files, insert a `view; and then set the company-wide global
views for everyone.
/proj/global/lib.map:
include "/vendors/v1/lib.map";
include "/vendors/v2/lib.map";
`view;
`view...
`library...
./lib.map:
include "/proj/global/lib.map"
`view myview...
>
>5. What is the difference between inst and path clauses?
> One of them must refer to a instance and the tree of
> instances below it.
The inst clause specifies any instance of the specified cell. The path
clause specifies a specific hierarchical path to a specific instance. In
both of these cases, the optional (lib.cell:view)<inst_name> may be used as
an additional error checking mechanism to make sure that the instance you
specified is actually bound to the lib.cell:view that you thought it was.
>
>6. What would you do to read in the lib.map file if it
> resides somewhere other than ./ ?
> E.g. All examples run verilog from the tb/ directory.
> What if you were trying to say
> verilog tb/tb.v cfg/adders1b.cfg
You would have a ./lib.map file that included the others. We could add
that, if the lib.map file doesn't exist in ./ that the simulator should
look in $home.
>
>7. How about an example where hierarchical config files
> are used? E.g.
>
> You have a directory <path_to_old_asic> that contains
> a config file defining that ASIC (and maybe a lib.map
> file that defines the libraries used.)
The file /root/projects/proj3/tb/board1.cfg has hierarchical configs in it.
If each of these were in a different file, board1.cfg and fpga.cfg, then
you could say
verilog board1.cfg fpga.cfg
>
> You are creating a new board that instantiates that.
> You simply want to refer to that configuration file
> since it has all the information necessary.
This is actually what the design statement is for in a config. It specifies
the lib.cell:view of the module that is that top-level of that config.
Knowing the lib.cell:view of the top-level module and the rules for
configuring everything below it is sufficient to instantiate a hierarchy by
simply referring to the config from the parent.
>
>8. Is there a way to specify a lib_cell_view_name for inclusion
> in a simulation that is not instantiated? E.g. I have some
> design verification modules that are listed in a library.
> Is there a way to have some of these compiled into the
> simulation or must they be explicitly called out I.e.
> <my_path_to_module>/<my_module>.v
The proposal states that there can be only a single design statement in a
config, specifying a lib.cell:view for the top-level module. I suppose we
could extend this to allow multiple lib.cell:view specifications in the
design statement. This shall only be allowed for a top-level config. A
config that is incorporated using the binding statement for an instance
cannot have multiple elements in the design statement, because the design
statement specifies the lib.cell:view to be used for the instantiated
instance, and it makes no sense to have unbound elements there.
>
>
>9. Can a lib.map file define the default liblist search order?
> Your examples show the configuration file defining the search
> order. But what if you defined library stuff in lib.map and
> wanted to keep all library stuff there - element selection,
> order of libraries searched, etc.
In the absence of a config, the searching order is spelled out in section
2.2 of the proposal. It basically takes the set of libraries and their
order from the set of libraries defined in lib.map. If the config doesn't
have a default liblist statement, it will also take the info from lib.map
>
>10. If you are allowing all lib.map functionality to be specified
> as compiler directives in the source - why not also allow
> that functionality to be specified in the configuration files?
> E.g.
>
>//---------------------------------------------------
>// This file: /root/projects/proj1/tb/adders1a.cfg
>//---------------------------------------------------
>`view gates file ".../*.vg;
>`view rtl file ".../*.v;
>
>`library lib1
> file "/root/projects/proj1/gates/adder.vg", // gates view
> file "../vlog/*.v"; // rtl view
>
>config adders1a;
> default liblist lib1,
> viewlist rtl;
> path tb.top.i2 viewlist gates;
>endconfig
As long as the view and library declarations ALL appear before ANY module,
udp or config declaration, then you could do this.
>
>
>11. Section 4.2 Attributes should be typeless.
noted - thanks.
>
>12. Section 4.4 sounds like 'references' delayed until binding time.
Yes. One of the reasons we're doing this is that we're finding it much more
useful to have separate parse/compile and elaboration steps. The
elaboration/binding step really needs to be source-file-order independent.
Thanks again for your comments. I hope this cleared some things up.
-Tom
<p>---------------
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.