From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Wed Jan 13 1999 - 12:22:07 PST
BAD MSG:
Hi Adam,
-Lines: 228
Content-Type: text/plain; charset="us-ascii"
Content-Length: 8610
X-Status: $$$$
X-UID: 0000000797
Status: RO
At 09:08 AM 1/13/99 -0600, Adam Krolnik wrote:
>
>You mention that much of the `library and `view functionality
>is intended for the lib.map file - so why do you speak about
>"adding new keywords", "parse tokens in a different namespace", etc.
>
>This separate file lib.map has a separate language from Verilog and
>the preprocessor. There is no conflict with keywords, etc.
>I think you are looking at implementation too much. It could be a
>separate parser/lexer and therefore have no connection to the
>rest of the language.
>
>I propose removal of the ` from the language of the lib.map file.
That's fine. I actually like the idea of separating the namespaces. To be
honest with you, I wasn't crazy about the backtick either. This, however,
enforces the restriction of having all lib.map information before any
"verilog" - i.e. module, udp or config declaration.
>
>I also am beginning to dislike the implicit reading of the file
>lib.map. Is it too much to require specifying the library mapping
>files as part of the command line or in a command file (-f file)?
Yes, I think it is, because you are going to require the lib.map
information every time you run the tool. This is information that will be
set up once and referred to several times. Requiring lib.map to be
specified on the command line is going to tick people off, particularly
since the lib.map information is required before any verilog source is
encountered.
By the way, I think this is a good time to explain our philosophy here.
This will also address some of your concerns later in this note.
The lib.map file contains mapping information, NOT command information. It
is intended to accomodate both "single-verb" incovations, like Verilog-XL,
and "multi-verb" (separate compile and simulate steps) incovations, like
NC-Verilog. The lib/view mapping information in lib.map is intended to be
applied when a module is parsed/compiled. The compiler goes through the set
of files given on its command line and when it encounters a module
declaration, it looks at the state of its world
what file am I parsing?
what directory am I in?
what macros are defined? what are their values?
what command line arguments were selected?
It then takes this information and compares it to the view and library
statements specified in lib.map. When it encounters a library statement
that matches the current "state", then it places the compiled module into
that library, otherwise it goes into the default work library. If a view
statement matches the current "state", then the compiled module goes into
the matching view, otherwise it goes into the default view. It doesn't
matter if the compile happens separately, or if it happens when the module
is encountered at bind-time.
That's why this information is separated from the verilog source and why
the information is required before any regular verilog is encountered.
By the way, since we've removed `view and `library from lib.map, we could
now add them back in as regular compiler directives:
`view <name>
`library <name>
These could be used to override any lib.map information and force the
compilation of the following module into the specified library/view. This
is your standard double-edged sword that could cut you badly with things
like cross-file inheritance. We can discuss this more on Friday.
>
>You also speak of the fact that the `view and `library can't occur after
>a module is defined. Don't you mean within a module? E.g.
>
>`view rtl
>
>module ff;
>...
>endmodule
>
>`view gate
>
>module aoi2;
>...
>endmodule
>
No, see above.
>I wrote:
>>
>> 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?
>
>You responded, "the view was created by invoking the compiler with
+define+foo"
>
>But If you speak about 'compiling a library' then you have to analyze the
source
>differently (read re-parse it due to possible define changes) for each view
>defined. So if there are 4 views, you would have to run the source through
>the compiler 4 times and concatenate the results into a library. E.g.
>view1 is +define+foo1; view2 is +define+foo2; view3 is +define+foo3;
>Source code is different depending on which 'foo' is defined (1, 2, 3).
This is confusion about mapping info vs. command info. If I happen to
compile a library only once, then whichever macro is defined matches a
particular view statement, and all cells in the library are put into that
view. If I try to refer to a different view in my config, then I've either
got to go off and compile that cell with the proper view defined (and it's
OK for the tool to figure out the necessary command line to make this
happen and do it automatically), or I've got an error.
>
>You write,
>
>: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".
>
>But this doesn't make sense! I intepret this to say "For view 'set',
>define 'foo'. It doesn't say take all modules with 'foo' defined into
>view 'set'. Why would you expect the latter?
I would expect the latter because that's the way I've defined it 8-). Your
interpretation assumes a command where mine assumes a map. I hope this is
clear now.
>
>>4. What happens if a vendor library defines a view that is
>
>So what you are saying is that if I have three libraries two
>with a view 'gates' and one with a view 'gates' and 'gtime', I could
>specify a particular view for each library in a particular order?! E.g.
>
>viewlist lib1.gates, lib2.gates, lib3.gtime;
>
>Instead of the general
>
>viewlist gates;
>
>Maybe it's a combination of the liblist and viewlist statements.
This is what the viewlist clause in a library statement accomplishes. If I
have
library lib3
file "<whatever>",
viewlist gates gtime;
Then that specifies that, by default, whenever I take something from
library lib3, I'll get the gates view if it exists, or the gtime view
otherwise. These are the only two views that exist for cells in lib3. If
you want to be able to change this on the fly, then you omit the viewlist
clause from the library statement and use a viewlist clause in a lib
statement within your config:
config myconfig;
lib lib3 viewlist gtime gates;
endconfig
This states that, for myconfig, when I encounter a cell in lib3 I'll take
the gtime view if it exists, or the gates view otherwise. If I say
config myconfig1;
default viewlist gates;
endconfig
then I'm always using the gates view, regardless of what library I'm
dealing with.
>
>: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.
>
>This has always confused me. It seems there are three things to reference
>specify something for a specific module/udp/macromodule; specify something
>for a specific instance of a module; specify something for the hierarchy
>starting with a specific instance.
>
>The names 'path', 'inst' and 'cell' would seem to somehow map to these ideas,
>but it doesn't sound like they do.
cell mylib.foo <statement>;
means that the <statement> is applied to every instance of foo that is
resolved to mylib.foo.
inst u1 <statement>;
means that the <statement> is applied to every instance named u1
path top.foo.u1 <statement>;
means that <statement> is applied to the specific instance top.foo.u1
>
>I.e. How would I have all instances of module my_add use a specific
>lib_cell_view?
cell my_add binding mylib.my_add:my_view;
By the way, does anyone prefer "use" to "binding"?
>How would I have a specific instance use a specific lib_cell_view?
path top.foo.u1 binding mylib.foo:my_view;
>How would I have an entire hierarchy from a specific instance use a
>specific lib/view? E.g. (timing accurate vs. rtl)
path top.foo.u1 viewlist timing;
>
>
>By the time we're done with this commentary, Friday will be just
>to vote on it...
I hope so.
Thanks,
-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.