From: Alec Stanculescu (email@example.com)
Date: Wed Sep 10 2003 - 12:00:00 PDT
The following reply was made to PR enhancement/466; it has been noted by GNATS.
From: Alec Stanculescu <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
Subject: Re: enhancement/466: Separate Compilation
Date: Wed, 10 Sep 2003 10:56:56 -0700
One of the issues addressed by the standardization of Separate Compilation is
how to deliver separately compiled IP in a way that does not reduce
the performance of the simulation, and that works in the same way for all
standard complying Verilog simulators. Another issue is how to save compilation
time (more than what is provided by incremental compilation) for
Verilog descriptions that will not change much (or not at all), again
in a way that is the same for all standard complying Verilog
simulators. As you mentioned, it is important to have a separate
compilation mechanism that does not create a configuration nightmare
for the user.
Yes, only an NC simulator will be able to use a module that is
compiled separately using an NC simulator, but the performance of the
simulation should be very similar to the case where all the code is
compiled at once. This mimics the separate compilation in C were for
many years only the C compiler that compiled the separately compiled
code could use it. In the future we may standardize even the interface
necessary to have a separately compiled Verilog used by a different
Verilog compiler than the one that produced it.
What we need to standardize at this time is the generation and the
usage of the separately compiled IP and most importantly, the
restrictions imposed on the code involving separately compiled IP
should be the same. Having standardized these three issues, it would
be very easy for a user to write a script that would handle simulation
of IPs produced by various simulators that they own.
The IEEE 1499 standard (OMI) you are referring to is not meant as a
replacement for separate compilation within Verilog. It's purpose is
much more general. It is meant to interface modules governed by
different simulation paradigms (e.g. C/C++, different simulation
kernels, etc.). If someone would try to use OMI as a replacement for
separate compilation in Verilog one would soon find out that OMI
degrades the performance of the simulation and also uses much more
memory than would be used by compiling the code all at once.
This solution is vendor neutral in that it provides users that already
own Verilog simulators from more than one Vendor with the capability
of importing IP that is separately compiled in their simulation flow
with no additional effort related to the number of simulators supported.
Without the proposed standardization users would not use separate
compilation because the simulation flow for each simulator would be
totally different, and hence a nightmare.
An important point to consider is that the proposed Separate Compilation
standardization is not overlapping with with any other portion of the
language, it does not introduce new keywords, new data types, etc. It is a very
straightforward standardization, that is already implemented, and
that will bring a clear benefit. The only part were one could work
some more is to relax the restrictions.
I hope that this explanation gives you a new view point on this
matter. Please do not hesitate to ask any further questions.
> I read through this proposal this morning and just can't seem to make
> sense of what is being proposed.
> In order to standardize on separate compilation as an IP delivery
> mechnism, I believe the important thing is vendor neutrality. It must be
> possible to use a model packaged with any given tool in any other tool.
> Without this the IP providers have a configuration management nightmare.
> The IEEE 1499 Open Model Interface (OMI) standard already defines how to
> deliver separately compiled models. If 1364 wants to standardize on how
> to do this I believe it would best be done by referencing the 1499
> standard, not reinventing the wheel.
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> > -----Original Message-----
> > From: firstname.lastname@example.org [mailto:email@example.com]
> > Sent: Tuesday, September 09, 2003 7:20 PM
> > To: firstname.lastname@example.org
> > Subject: enhancement/466: Separate Compilation
> > Precedence: bulk
> > >Number: 466
> > >Category: enhancement
> > >Originator: Fintronic USA, Inc.
> > >Environment:
> > >Description:
> > Separate compilation
> > ====================
> > 1. Introduction
> > Super-FinSim provides the facility of separately compiling parts of
> > the Verilog hierarchy. This pre-compiled hierarchy can then be mixed
> > with other Verilog sources to build a new design. This facility is
> > extremely helpful for users who want to ship their IP to their
> > customers but do not want them to access the Verilog source. Not only
> > will the access to the source be denied using the regular
> > `protect/`endprotect mechanism but the IP provider will only have to
> > ship binary files which would make it virtually impossible to
> > re-create the original Verilog code. Another useful application of
> > separately compiled code is for users who add legacy code to their
> > designs which has been tested and will not need to be modified.
> > 2. Compiling a Verilog Design Hierarchy into object code for
> > later reuse
> > --------------------------------------------------------------
> > ----------
> > 2.1 +sepgen option
> > A Verilog description can be separately compiled for later reuse by
> > invoking the compiler, called finvc, with the special option +sepgen,
> > followed by an invocation of finbuild, as follows:
> > # finvc +sepgen+<mymodel> <other options>
> > # finbuild
> > <mymodel> is a name given by the user to this design. One of the uses
> > of <mymodel> is to make any symbols in the separately compiled design
> > not clash with similar symbols in the final design (which instantiates
> > the separately compiled design). After running these two steps, the
> > temporary directory (fintemp by default) will contain the compiled `C'
> > files, the interpretation data files, the elaboration data files as
> > well as all other files needed for simulating this hierarchy. In
> > addition it will contain a Verilog interface file called
> > interface.v. This file contains the shell for the exported modules in
> > the separately compiled design. Any of these modules can be
> > instantiated in the final design.
> > 2.3 Other options.
> > finvc also assumes that everything in the separately compiled design
> > except the interface for the top level module is protected. This
> > assumption can be relaxed with the option (+fin_sep_unprotect).
> > 3. Using a separately compiled hierarchy
> > ----------------------------------------
> > 3.1 +sepuse option
> > In order to use a separately compiled Verilog design hierarchy as part
> > of a new Verilog design hierarchy one must invoke finvc with the
> > special option +sepuse, followed by finbuild and the invocation of the
> > executable simulator, as follows:
> > # finvc +sepuse+<directory name> <other options>
> > # finbuild
> > # TOP.sim
> > The directory name is the directory where all the files were generated
> > in the compilation step. More than one such +sepuse options can be
> > specified. In this case finvc treats the file interface.v in the
> > separately compiled directory as a library file, so that any module
> > that is used in the final design and cannot be found is searched in
> > this file.
> > 4. Restrictions
> > ---------------
> > 4.1 Restrictions on the separately compiled code
> > A module in the separately compiled design can be instantiated
> > outside of the separately compiled design only if:
> > a) there are no external references anywhere in the the separately
> > compiled design (things like a.b.c).
> > b) none of its parameters or the parameters of the modules
> > instantiated in the hierarchy below it are overwritten with more
> > than one value
> > 4.2. Restrictions on the code instantiating a separately compiled
> > module
> > A design can instantiate modules from the separately compiled
> > design if:
> > a) it does not overwrite the parameters of the separately
> > compiled module
> > b) it doesn't make external references into the
> > separately compiled design
> > c) its time precision is not finer than the time precision of
> > the separately compiled design.
This archive was generated by hypermail 2.1.4
: Wed Sep 10 2003 - 12:06:32 PDT
sponsored by Boyd Technology, Inc.