From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Fri Feb 05 1999 - 08:40:39 PST
BAD MSG:
Please let me know what you think.
ontent-Length: 25829
X-Lines: 574
X-Status: $$$$
X-UID: 0000000848
Status: RO
Thanks,
-Tom
Attachment Converted: "E:\INCOMING\draft2.html"
---------------
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-6438From ???@??? Mon Mar 01 12:24:24 1999
Return-Path: <yatin@multi2.netcomi.com>
Received: from hub1.san-jose.webnexus.net (hub1-20.san-jose.webnexus.net [209.140.224.20])
by gw.boyd.com (8.8.7/8.8.5) with ESMTP id MAA19262
for <stefen@boyd.com>; Mon, 1 Mar 1999 12:15:40 -0800
Received: from multi2.netcomi.com (IDENT:yatin@multi2.netcomi.com [204.58.155.202])
by hub1.san-jose.webnexus.net (8.9.1a/8.8.5/WN-1.3) with ESMTP id LAA07523
for <stefen@boyd.com>; Mon, 1 Mar 1999 11:24:14 -0800 (PST)
Received: (from yatin@localhost) by multi2.netcomi.com (8.8.5/8.7.4) id NAA29300; Mon, 1 Mar 1999 13:19:17 -0600
Received: (from yatin@localhost) by multi2.netcomi.com (8.8.5/8.7.4) id NAA29291; Mon, 1 Mar 1999 13:19:15 -0600
Received: from earth.sunburst-design.com (root@sunburst-s2-0-31.pdx13.or.nw.verio.net [206.58.6.210]) by multi2.netcomi.com (8.8.5/8.7.4) with ESMTP id NAA29250 for <1364core@ovi.org>; Mon, 1 Mar 1999 13:18:56 -0600
Received: from Saturn (saturn.sunburst-design.com [192.168.0.7])
by earth.sunburst-design.com (8.8.7/8.8.7) with SMTP id LAA12812
for <1364core@ovi.org>; Mon, 1 Mar 1999 11:20:51 -0800
Message-Id: <3.0.32.19990301110904.00734e94@mail.sunburst-design.com>
X-Sender: cliffc@mail.sunburst-design.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 01 Mar 1999 11:09:14 -0800
Old-To: 1364core@ovi.org (IEEE-1364 Core Group Reflector)
From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
Subject: Configuration Conference Call & Notes - Please Join!!
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Loop: 1364core@ovi.org
Old-To: 1364list1@ovi.org, 1364list2@ovi.org
X-Loop: 1364list2@ovi.org
To: Daryl.Stewart@cl.cam.ac.uk, S1364@eda.ics.es.osaka-u.ac.jp,
adamk@cyrix.com, alec@fintronic.com, andersn@nortel.ca,
anderson@acuson.com, bob@simucad.com, carl.ruggiero@infocus.com,
chas@cadence.com, cliffc@europa.com, dinesh@synopsys.com,
dkf@apteq.com, drew@silicon-sorcery.com, eli@interhdl.com,
elkind@cadence.com, elliot@wellspring.com, flake@elda.demon.co.uk,
furui@n022.saskg.semicon.sony.co.jp, gmoretti@veribest.com,
john@simucad.com, jskud@cypress.com, kurt@wsfdb.com,
lynnh1@ix.netcom.com, mac@surefirev.com, mannan@dsmtech.com,
marek@cadence.com, mno1@ricochet.net, naveen@lsil.com,
pieper@synopsys.com, prabhu@lsil.com, roberts@cadence.com,
skp@cadence.com, stefen@boyd.com, stuart@sutherland.com,
tfitz@cadence.com, vhberman@worldnet.att.net, vivek@veri-log.com,
wadswort@poci.amis.com
Status: RO
What goals do we want to accomplish with configurations?
In order to revitalize the effort to add configuration enhancements to the
1999 Verilog LRM, WE NEED PARTICIPATION FROM THE ENTIRE VSG. This week, we
are asking VSG members to ponder their configuration needs and propose
goals that should be addressed by a configuration proposal.
We anticipate holding a conference call next Monday evening, 6:00 PM EST /
3:00 PM PST to prioritize our configuration goals, and make proposals to
meet those goals. We must arrive at a reasonable consensus soon or else
configurations will be deleted from the 1999 Verilog LRM. Anders Nordstrom
will send out the conference call announcement under a separate e-mail.
Please look over the following configuration wish list and add your
configuration requirements. Please participate in next week's conference
call. If you cannot participate by phone, please e-mail your opinions
concerning which of the following goals you feel are important.
Regards - Cliff Cummings
**********
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 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.
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?
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.
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
>> >
>> >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.
This brings up another question. Where are the compiled libraries going to
reside?
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!
If automatic update is included, I propose the command line switch
"-nolibupdate" be standardized (a little more specific than "+noupdate").
>> >
>> >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"
>> 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"
<p>>> >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.
NOTE: I again like "instance" over "path"
>> >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.
>> >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!
>
>> >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!
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.
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.
I believe conditional compilation or $test$plusargs are sufficient to cover
this capability.
NOTE: I still don't need views.
>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)
>> 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).
>> 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.
>> 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.
>> ---------------
>> Tom Fitzpatrick
Updated by Cliff Cummings
<p>//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design, Inc. Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:25 PDT
and
sponsored by Boyd Technology, Inc.