From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Mon Mar 01 1999 - 13:45:41 PST
BAD MSG:
Hi All,
-Lines: 695
Content-Type: text/plain; charset="us-ascii"
Content-Length: 30952
X-Status: $$$$
X-UID: 0000000849
Status: RO
Just wanted to try and get my comments in before the call this evening.
-Tom
At 11:09 AM 3/1/99 -0800, Clifford E. Cummings wrote:
>**********
>Tom Fitzpatrick and Cliff Cummings have added notes to the goals, below.
>**********
>
>Based on Tom Fitzpatrick's configuration proposals, we seem to be
>converging on a configuration proposal that includes two new types of
>files: library files and configuration files.
>
>The major differences between library files and configuration files seems
>to be:
>Library Files: are used to do physical mapping of files and groups of files
>to a symbolic library name
>Configuration Files: are used to specify which libraries will be used for
>individual instances, instances with instantiated sub-instances (where
>sub-instances "inherit" the same library as the parent-instance), or entire
>designs. No physical mapping is done in a configuration file which means
>that a library file is required before a configuration file can be used.
>Due to the simple syntax of of the library file, I am no longer opposed to
>this requirement.
>
>For library files, Tom has proposed the keyword "path" to specify the
>hierarchical path name of an instance and the libraries that are used for
>that instance. Example:
> path top.a1.foo liblist lib1 lib2; // looks in lib1 first, then lib2
>I still prefer to use the keyword "instance." I believe "instance" is more
>intuitive than "path." Example
> instance top.a1.foo liblist lib1 lib2; // looks in lib1 first, then lib2
There are two reasons we want to use "path" instead of "instance" here. If
these reasons don't convince you (and a majority of the committee), then
I'll concede.
The first reason is that the 1364 Spec refers to names like "top.a1.foo" as
"hierarchical path names".
The second is that we wanted to reserve the "inst" clause to specify
configuration information for specific subinstances of a given cell.
Actually, this is one of the concepts that folks seem to object to, but I'd
like to leave the keyword open for future enhancement.
Here's another suggestion: How about "scope" instead of "path". Since we've
already agreed that configuration information is based on module hierarchy
(ie. it's not possible to specify configuration information for a named
block, for example), then I think "scope" is a good compromise.
>
>>> There is some redundancy in this list but I did not want to filter ideas.
>>>
>>> >What goals do we want to accomplish with configurations?
>>> >
>>> >There is some redundancy in this list but I did not want to filter ideas.
>>> >
>>> >1) Simple library usage.
>>> >User provides only part of a design and a collection of files containing
>>> >modules that may be needed in the simulation. This works ok with
>>> >-y,-v,+libext.
>>>
>>> Old: -y lib1 +libext+.v -v lib2.v
>>> New: (lib.map) library lib1 "./lib1/*.v";
>>> library lib2 "./lib2.v";
>
>In my opinion, the library file (library map file) satisfies how physical
>files are mapped to libraries in a manner that is superior to separate -v,
>-y and +libext switches. The wildcard capability is a very nice enhancement.
Glad to hear it.
>
>What seems to be missing from this proposal is an easy way to use the
>defined libraries without having to create a separate configuration file.
>We should not require all Verilog 1999 designs to have a configuration
>file. So how are we going to allow library usage without requiring a
>configuration file?
Actually, the proposal explicitly states that the lib.map file by itself
will be used, in the absence of a configuration, to determine the default
bindings of a design. See section 13.5.1.
>
>Old: verilog topFPGA.v -y FPGAdir +libext+.v
>New: verilog topFPGA.cfg
>Requires: a library, a library file and a configuration file.
>FPGAlib.lib: I have no objection to requiring the library file since it is
>as simple to assemble as a "-f" command file and is almost as easy as
>adding "-y FPGAdir +libext+.v" to the command line.
>library FPGAlib "<FPGA_install_path>/FPGAdir/*.v"
>topFPGA.cfg: I now have to create this separate file just to use the
>FPGAlib. I object to this additional overhead.
Actually, if you're going to be using FPGAlib, you would simply "include"
it in your default lib.map file.
>
>I believe Tom has hinted at standardizing a command line switch to address
>this? Since +command switches are not syntax checked, if we add a comand
>switch, I propose it should be a syntax-checked "-command" style. Something
>like "-uselib" or I believe some EDA tools use "-L" for "library"?
>
>Old: verilog topFPGA.v -y FPGAdir +libext+.v
>New (style #1): verilog topFPGA.v -uselib FPGAlib FPGAlib.lib
>New (style #2): verilog topFPGA.v -L FPGAlib FPGAlib.lib
>The new command calls the top-level file, specifies usage of the "FPGAlib"
>library, and lists the library file to be compiled.
>If the library has already been compiled once, the command line would
>simply be:
>New (style #1): verilog topFPGA.v -uselib FPGAlib
>New (style #2): verilog topFPGA.v -L FPGAlib
Hmmm... It sounds like you want a command-line method for specifying the
default library search order that may change between invocations and that
overrides the lib.map ordering. Is that correct?
If it is, then I would prefer the -L switch to -uselib. Then, if you
specify multiple -L libraries, the searching will always start with the
first one on the command line. I do NOT want to allow re-introduction of
liborder and librescan.
I also don't like changing the command line depending on whether the
library has been compiled. There was some discussion as to whether the
lib.map file should be read implicitly or not. Perhaps this requirement is
to have a command-line switch to allow the tool also to read in another
library map file without requiring editing lib.map to "include" the file
explicitly. Is that correct?
If so, then I would suggest that we stay with the default name lib.map and
add the command line switch -libmap <filename> to include the new one. Or
perhaps we could just shorten this to "-map <filename>".
Thinking about this a little more, there are three things you want to be
able to do:
1) just use the default file, so you don't have to type anything. This
would be lib.map
2) Include another file in addition to lib.map
3) Use a different file instead of lib.map.
How about "-imap" (include map) for (2) and "-umap" (use map) for (3)?
>
>>> >
>>> >2) Add a configuration capability to directly replace the -v, -y and
>>> >+libext switches (Cliff)
>>>
>>> Old: -y lib1 +libext+.v -v lib2.v // order-dependent search
>>> New: (config) default liblist lib1 lib2;
>
>Same comments as above.
>>> >
>>> >3) Define named libraries that can be referenced. (Adam)
>>> >Make the library mechanism automatically update out-of-date libraries,
>>> >similar to Makefiles. For compiled-code simulators, the compiled library
>>> >modification date would be compared to the source file modification dates
>>> >that are called for the library. If updating is required, compile the
>>> >appropriate files; otherwise use the existing compiled library (Cliff)
>>> >The connotations of -y, -v contain too many problems (Adam)
>>>
>>> This is handled by the source-to-library mapping in the lib.map file. I
>>> disagree that we should standardize on a tool behavior of automatically
>>> updating libraries. While this may be desirable in most cases, we should
>>> not preclude the ability of the user to not do this. I expect that this
>>> will be a tool-specific issue, with the tool automatically updating by
>>> default, but implementing a +noupdate switch or something like that.
>
>In the absence of automatic library update, we would require users to have
>a separate command to compile libraries?
>
>I found this to be very annoying in VHDL. If a library was out of date,
>VHDL would report the out-of-date library problem and not compile the design.
If you find this annoying, then I think this is an excellent chance for
individual vendors to add value and get a competitive advantage. I didn't
say that vendors couldn't do it, I simply said that I don't think we should
enforce a particular behavior via the Standard.
>
>This brings up another question. Where are the compiled libraries going to
>reside?
Since every tool has to compile the design itself, the location of the
compiled libraries is vendor-specific. This is actually another advantage
to logical library names. How vendors manage library data could (and does)
significantly affect the performance of the tool. This is another place for
competition and optimization.
>In VHDL, when the design would not compile due to an out-of-date library,
>we either had to find a sys-admin and instruct them on how to re-compile
>the libraries (since they were under some sort of root control), or we had
>to copy the libraries to a local directory so that we could re-compile
>ourselves and get some work done while we waited for the sys-admins to
>figure out and update the central root-controlled libraries.
>A real hassle!
Another place for competition. For standard libraries and such, the CAD mgr
is likely to place them under some sort of control. You can either use the
CAD mgr's lib.map information to get his controlled data, or you can use
your own which points to his sources but puts the results in your library
under your control. Alternatively, the tool could implement some temporary
storage mechanism whereby if the source library is out of date, you can
temporarily put your data in a local place, and when the library is updated
it could point you back there. I don't believe that we need to standardize
on such a tool-specific behavior.
>
>If automatic update is included, I propose the command line switch
>"-nolibupdate" be standardized (a little more specific than "+noupdate").
Agreed.
>
>>> >
>>> >4) Inheritance
>>> >A design and its sub-instances should have the ability to inherit the
same
>>> >libraries that were used for specific instances.
>
>The one caution associated with inheritance is that the top-level design
>module (the module that instantiates the gate-level instances) is generally
>not in the vendor library (it just instantiates everything from a vendor
>library). This has been one of the problems with the current "`uselib hack"
>(as Stephen puts it!). With `uselib, a designer generally had to write out
>the gate-level netlist from a synthesis tool, then manually add a `uselib
>directive to the gatelevel netlist to call the gate-level library. Some
>FPGA tools write the gate-level netlist with the `uselib directive imbedded
>in the netlist, which causes problems when the design is sent to a vendor
>or to a remote design team where the libraries are located in a different
>place.
>
>Typical usage(?):
>(file: mylib.lib)
>library tb "tb.v"
>library mygates "../gates/*.v"
>library FPGAlib "<FPGA_install_dir>/*.v"
>
>config myFPGA;
> design tb.tb
> default liblist mygates FPGAlib
>endconfig
>
>NOTE: there is nothing about this request that requires "views"
We'll discuss views below in (11).
>
>>> This is built into the syntax of configs. A liblist specified for a
>>> particular instance using the cell, inst and path selection clauses is
>>> automatically inherited down the hierarchy until a new liblist is
>>> specified. This is also handled by the hierarchical use of configs using
>>> the binding clause.
>>>
>>> path top.a1.foo liblist lib1 lib2;
>>> allows all subinstances of foo to get the liblist lib1 lib2.
>>>
>>> path top.a1.foo binding foo_cfg;
>>> uses the preconfigured foo_cfg to represent top.a1.foo and all of its
>>> subinstances.
>>> >
>>> >5) Ability to easily specify the library search order (Adam)
>>> >Should have the ability to change the search order for different
>sub-blocks
>>> >of a design.
>>>
>>> Again, this is built into the syntax of configs.
>>> path top.a1.foo liblist lib1 lib2; // looks in lib1 first, then lib2
>>> path top.a1.bar liblist lib2 lib1; // looks in lib2 first, then lib1
>>> path top.a1.bar.b1 liblist lib3 lib4; // lib3 first, then lib4
>
>This is a welcome enhancement. No more need for "liborder" and "+librescan"
Glad you agree. See (1) above.
>
>
>>> >6) Document the default library resolution priority
>>> >Specify what the default search order is and what constitutes a search
>>> >order syntax error.
>>>
>>> Libraries are always searched in the order specified. Searching for each
>>> new module always starts at the beginning of the list. This eliminates the
>>> worry about +liborder +librescan, etc.
>
>This is a welcome enhancement. No more need for "liborder" and "+librescan"
>
>>
>>> >7) Module name collisions.
>>> >User needs two versions of the same module. We need a better solution
>than
>>> >the `uselib hack.
>>>
>>> Lets try to avoid the term "version", as that tends to imply revision
>>> control. We prefer the term "representation" or "abstraction". Suppose we
>>> have two representations - gate and RTL. This is where views come in
handy:
>>>
>>> path top.a1.foo viewlist gate;
>>> path top.a2.foo viewlist rtl;
>
>Or instance top.a1.foo gateslib
> instance top.a2.foo rtllib
>
>NOTE: views are not required here if the user is willing to compile two
>libraries as opposed to compiling two representations into the same
>library. With two libraries, I don't have to worry about which "view" is
>the default view.
See the view discussion in (11) below.
>
>NOTE: I again like "instance" over "path"
See "scope" discussion above.
>
>>> >Ability to run a system simulation with multiple ASIC libraries that have
>>> >same-named modules (Mac)
>>>
>>> path top.a1 liblist vendorlib1;
>>> path top.a2 liblist vendorlib2;
>>>
>>> >Ability to fill model requirements from one library and still pick up
>>> >missing models from another library (Mac) (falls under search order
>above?)
>>>
>>> path top.a1 liblist vendorlib1 otherlib;
>>> path top.a2 liblist vendorlib2 otherlib;
>>>
>>> All subinstances of top.a1 will first be looked for in vendorlib1. Any
>>> modules not found there will be searched for in otherlib. If not found in
>>> otherlib, it's an error. Similarly for top.a2 and vendorlib2.
>>> >
>For the above two examples, substitute "instance" for "path" and I agree
>with Tom.
Cool!
>
>>> >8) Top level modules.
>>> >User specifies names of top-level modules and the compiler searches for
>>> >them in the specified libraries. [Currently only top-level filename
>>> >specification is possible.] (Adam Krolnik)
>>>
>>> This is what the design statement does.
>>> config foo;
>>> design worklib.top:rtl;
>>> <rest of config>
>>> endconfig
>>>
>>> By specifying just the file containing the config foo, we automatically
get
>>> the rtl view of top as our top-level module, configured as specified.
>>> Alternatively, if the tool precompiles things, then you would really only
>>> need to pass the compiled configuration to the simulator as
>>> worklib.foo:config.
>>>
>>> Using this capability, along with hierarchical configs, makes it real easy
>>> to go from simulation to synthesis. If I use one configuration for my
>>> testbench, which hierarchically uses a separate config for my DUT,
>>>
>>> config test1;
>>> design worklib.test1:rtl;
>>> default liblist lib1 lib2;
>>> cell DUT binding worklib.dut:config;
>>> endconfig
>>>
>>> Then when it's time to synthesize, I can simply pass the
worklib.dut:config
>>> to the synthesis tool and I'm guaranteed to synthesize what I simulated!
>>> (Of course, you do have to make sure that there are no defparams in test1
>>> that affect parameters in the dut, but that's a workable issue).
>>>
>>> NOTE: While it is possible to specify multiple top-level modules in a
>>> design statement, it shall be an error if a config with multiple top-level
>>> modules is used hierarchically, since a config may be bound only to an
>>> instance of a module. You can't bind the mulitple top-levels in the
>>> sub-config to the single instance in the top config.
>>> >
>>> >9) Easy way to incorporate released designs and updated designs. (James
>>> >Markovitch)
>>>
>>> If I change my design, and specify a new config for it, like
>>> worklib.dut_released:config, then I simply modify my test config as
>follows:
>>>
>>> config test1_with_released_dut;
>>> design worklib.test1:rtl;
>>> default liblist lib1 lib2;
>>> cell DUT binding worklib.dut_released:config;
>>> endconfig
>
>I did not follow the arguments here. Lost me on this one!
In the first example, I am using the config test1 to specify both a
testbench, also named test1, and a DUT. The config states that I use the
rtl view of test1 as the top-level of my design. For any subinstances of
test1 (excluding DUT), I search lib1 and lib2 to find the cells. I have
already created a separate config for the DUT cell, worklib.dut:config,
which I want to use to bind the DUT cell in test1. This config line could
also be done using the new "scope" clause as
scope test1.DUT binding worklib.dut:config;
Now, since I'm not going to be sending my testbench through synthesis, the
only thing I want to give to the synthesis tool is the DUT and what's below
it. Therefore, if the synthesis tool just reads the DUT configuration that
I instantiated in my testbench config, then I'm guaranteed to synthesize
what I just simulated.
In the second example, the only difference is that I'm using a different
hierarchical config to represent the DUT. The bindings of stuff elsewhere
in my testbench doesn't change, so all I have to do is change the binding
clause to specify the new config to use for DUT.
I believe this is a powerful capability and that eventually designers will
be using configs to pass data between tools, instead of having to rely on a
panoply of -f files as they do now.
>>
>>> >10) Prefer to have revision control separate from the Verilog
language. Do
>>> >not burden Verilog with revision control (James Markovitch)
>>>
>>> I couldn't agree more.
>
>I also agree!
>>
>>> >11) Different levels of debugging capability is desirable (James
>Markovitch)
>>>
>>> This is especially where views make a difference. This actually falls most
>>> naturally into the separate-compile use-model, where I can compile my
>>> module several times with different options:
>>>
>>> compile foo.v
>>> compile foo.v +debug
>>> compile foo.v +delay_mode_zero
>>> etc.
>>>
>>> Then, with these in different views from my lib.map file
>>>
>>> library lib1 "foo.v";
>>> view rtl "foo.v";
>>> view debug "*.v" arg +debug;
>>> view nodly "*.v" arg +delay_mode_zero
>>>
>>> I can choose the different views for specific instances of module foo:
>>>
>>> default liblist lib1
>>> path top.a1.foo viewlist rtl;
>>> path top.a2.foo viewlist debug;
>>> path top.a3.foo viewlist nodly;
>>>
>>> This method can also work for the "single-pass" use model as well, but it
>>> requires the parser/compiler to be a bit more intelligent. It does require
>>> the set of source files, including the configuration file, to be provided
>>> on the command line (and this is in no way incompatible with -y/-v for
>>> specifying groups of modules which may or may not be compiled, but it does
>>> enforce the more rigorous search rules).
>>>
>>> 1) When the parser/compiler encounters instance top.a1.foo, it uses the
>>> liblist and viewlist to determine that it needs the lib1.foo:rtl cell.
>>> 2) Using the lib.map file, it resolves that lib1.foo:rtl comes from file
>>> foo.v (with default options), and invokes the compiler as: "compile foo.v"
>>> 3) When it encounters instance top.a2.foo, it uses the liblist and
viewlist
>>> to determine that it needs lib1.foo:debug.
>>> 4) Using the lib.map file, it resolves that lib1.foo:debug comes from file
>>> foo.v, compiled with the +debug command-line argument set, so it invokes:
>>> "compile foo.v +debug"
>>> 5) The same is done for the top.a3.foo instance.
>>>
>>> This is how the library mapping supports both use models. In the
precompile
>>> use model, it's up to the user to compile the source with the right
command
>>> line options to produce the views he needs, and then the simulator only
>>> needs the top-level compiled module to know how to get everything else out
>>> of the library. In the single-pass use-model, the user provides all of the
>>> files, and the tool must determine from the library and view
specifications
>>> what the compile-time environment must be to produce the required view(s).
>>> Adam writes:
>>> >Tom writes:
>>> >>11) Different levels of debugging capability is desirable (James
>Markovitch)
>>> >>
>>> >>This is especially where views make a difference. This actually falls
>most
>>> >>naturally into the separate-compile use-model, where I can compile my
>>> >>module several times with different options:
>>> >
>>> >This can be very bad.
>>> >
>>> >Tom's proposal states that +args and +define+ command line options
>>> >will alter the set of modules selected for a simulation from libraries.
>>> >E.g.
>>> >
>>> >Consider a module that uses a `define inside it for debugging - but YOU
>>> >don't know that. You may be using this module or, you may be simulating
>>> >a gate version (or some other module from another library.)
>>> >
>>> >You decide to use the same preprocessor name for your own stuff. Now you
>>> >decide to simulate with it defined. Guess what, you just included that
>>> >module using the same `define.
>>> >
>>> >What can result?
>>> >
>>> >1. No compilation - rtl model doesn't plug into gates
>>> >2. Incorrect simulation - other module doesn't work in current
>environment!
>>> >
>>> >This is action at a distance. You didn't explicitly state you wanted
>modules
>>> >to be changed - but you did by setting a preprocessor name!
Adam and I spoke about this issue, and while it is possible, it is also
easy to avoid. The only time this will come up is if you are using default
library searching. If this problem may arise, then it is possible to just
use a config to specify explicit bindings to avoid the problem.
This is also a place where views may be considered an advantage. If I
enforce a coding style such that each view of a given cell in a library has
the same port list, then I can use this mechanism to switch between views
in the same library and make sure I don't run into this problem.
If I don't have views, and I have to compile each of these representations
into a different library, it becomes much harder to manage the library
search order to make sure that this problem doesn't exist.
>
>James has requested different levels of debug capability. Tom makes a good
>argument in favor of views to enable this capability. Adam makes a good
>argument against this capability due to dangerous design practices.
See my previous comment.
>
>Cliff's opinion: when I want to include different levels of debug
>capability, I typically use conditional compilation in my master file and
>recompile the design. I would consider it to be a dangerous practice to
>keep two different views of the same model just so I could select debug
>options. Whenever I run a simulation with debug options enabled, I want to
>know that I am running on my current design. If I run a separate debug
>view, I run the risk of not recompiling my debug-view of the design after
>changes. I consider this to be a dangerous practice.
Yes, but there's no reason the tool can't tell you that. If I have `ifdef
DEBUG in my code, and I've compiled it twice, once with +define+DEBUG and
once without, then if I change my source, why can't the tool tell me that
my source is out of date with the compiled version, regardless of which
compiled version I'm using? The answer is that it can. In fact, I think it
should, which means that we should probably standardize on this at least
requiring a warning message to this effect.
>
>I believe conditional compilation or $test$plusargs are sufficient to cover
>this capability.
I don't believe it is. Many compilers have separate "gofast" switches that
affect performance at the expense of debugability (and other capabilities).
It makes no sense to have to put each of these compiled objects in
different libraries when they represent the exact same component. Using
$test$plusargs won't work because these are compile-time optimizations.
Using $test$plusargs at runtime means that you have to compile the slowest,
non-optimized version, just so the information is available if the user
might want to get to it.
Even if you use conditional compilation, then views are going to benefit
you. Suppose I've got two different debug switches, DEBUG1 and DEBUG2.
That's potentially four different abstractions of the SAME component. As
I'm swapping between these, I don't want to have to keep recompiling. I
want to be able to compile each one once and be able to go back to it
efficiently.
Without views, my only choice is to put each of them in a different
library. This makes managing the library search order much more difficult.
The nice thing about views is that it gives you a way of separating the
searching. First, you search for the right library, then within that
library you search for the right view.
Let's look at another example. Suppose I've got an RTL view with a `ifdef
DEBUG and a gate view with a `ifdef DEBUG. Without views I'd have to
compile these into four different libraries. If I choose to compile them
into RTL, gate and debug libraries, then I'm going to overwrite one of them
in the debug library.
Also, if not all of my rtl components have the same `ifdef DEBUG in them,
then my DEBUG_RTL library will have fewer components in it than my RTL
library. I think it's a lot easier to use libraries as collections of
cells, and use views to distinguish between different
representations/compilations of those cells.
If you want to keep RTL and gates in different libraries, you're welcome to
do that if you think it's easier to manage, but we're still going to want a
way of distinguishing at a finer level of granularity.
>
>NOTE: I still don't need views.
You don't WANT views. You only need them if you want to be more efficient
in managing your data, and in achieving optimal simulation performance.
[Forgive me if that sounds sarcastic. It isn't meant to be.]
>
>>12) Consolidate libraries into one place (James Markovitch)
>>>
>>> All libraries are listed in the lib.map file. Using the include statement
>>> in a lib.map file allows you to use vendor-supplied or company-wide
lib.map
>>> files that are associated with a particular library.
>>>
>>> include "/vendors/vendor1/lib.map";
>>>
>>> All relative paths in the vendor's lib.map file are relative to
>>> "/vendors/vendor1/" (which is what I meant in the draft 2 proposal, but
>>> apparently it wasn't clear enough), so the vendor library is easily
>>> transportable.
>>>
>>> >
>>> >13) Not excited about adding features to support anticipated future
>>> >capabilities (Mac)
>>> >Only put in what is really required today (Anders)
>>>
>>> What do you think of the simulation-to-synthesis flow described in point
>>> (8) above? This is exactly the type of flow that we envision for passing
>>> this data around to other tools as well.
>>>
>>> >Don't put in anything that would inhibit Cadence future enhancement
>>> >features (Anders)
>>>
>>> Thanks!
>
>I agree with Mac. I believe I can do 100% of what I want to accomplish
>without views, and I believe most users will easily do the same. I agree
>with Stu that we should implement a powerful minimal enhancement.
>
>As I have stated earlier, I fully expect Cadence to implement their full
>configuration proposal, and I believe they should.
>>
>>> >14) Include clear usage examples with whatever is standardized (Alex)
>>>
>>> I think we're making progress on this one, but we still have some ways
>to go.
>
>Yeah, needs work!
>
>>> 15) Standardize `uselib as a basic form of configurations. It's already
>the
>>> de facto standard, and should be documented. The description of `uselib
>>> can explain the limitations of using compiler directives for configuration
>>> management, and can refer to whatever section contains the new
>>> configuration statements. (Stu)
>
>I totally disagree. `uselib should die a miserable death as soon as
>everyone discovers the new and powerful simple configuration syntax.
>See my notes about `uselib under (4)
I also totally disagree with Stu on this one.
>
>>> 16) Reserve the configuration keywords from the Cadence proposal, so that
>>> they are illegal as virtual names. This will allow future expansion of
the
>>> configuration file. (Stu)
>Stu has suggested reserving the Cadence keywords in case we decide to adopt
>more of the Cadence proposal in Verilog 2002. This might be a good idea. We
>might also want to document the keywords, noting potential future
>enhancement, and state that each of these key words are legal and should be
>ignored by any tool that does not use them(?) (so Cadence configurations
>can at least be parsed by compliant simulators).
I like that idea, especially given that we're probably going to wind up
with a subset of my original proposal.
>
>>> 17) Add library capabilities to the configuration file
>>> - The basic config file should specify a default virtual library name.
>(Stu)
>>> - The basic config file should specify zero, one or more additional
>virtual library names. (Stu)
>>> - The basic config file should specify physical paths for each virtual
>library name. For example: (Stu)
>>> - The basic config file should specify virtual names for one or more
>instance scopes of a design. (Stu)
>>> - The basic config file should specify actual hierarchical paths for
>each virtual instance scope. (Stu)
>
>I now agree with the Cadence proposal, that we separate the library
>physical mapping into a separate file and use te configuration file to call
>the libraries. I believe most of what Stu is requesting is included in the
>separate files.
I agree with Cliff on this one. We ABSOLUTELY want to keep these two
different pieces of information separate.
>
>>> 18) Add VHDL parsing to the Verilog configuration capability.
>>> Also, configuration is the only decent part of VHDL. So to make life
>simpler for
>>> everyone, I would just add parsing VHDL configurations on top of the
>`view' (aka
>>> architecture) stuff you are adding. (Kev)
>
>I disagree with Kev about the usefulness of VHDL configurations. Most VHDL
>users that I personally know, either rely on a tool to generate a VHDL
>configuration file, or they have to look up the syntax every time they
>build one. I am trying to avoid the same complex configuration syntax that
>exist in VHDL.
>
>I also do not want to burden Verilog configurations with aving o parse VHDL
>configurations. Let's see what the EDA vendors come up with on this idea
>and see if users embrace one of the EDA implementations.
Thanks Cliff. I believe that using VHDL configuration is a bad idea.
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:26 PDT
and
sponsored by Boyd Technology, Inc.