Re: enhancement/466: Separate Compilation

From: Alec Stanculescu (alec@fintronic.com)
Date: Wed Sep 10 2003 - 12:00:00 PDT

  • Next message: Stefen Boyd: "enhancement/455: Fwd: pdf file attachment for BTF en#455"

    Precedence: bulk

    The following reply was made to PR enhancement/466; it has been noted by GNATS.

    From: Alec Stanculescu <alec@fintronic.com>
    To: lawrence@cadence.com
    Cc: etf-bugs@boyd.com, ennis@jedatechnologies.com, fm@cadence.com,
       mac@verisity.com, sharp@cadence.com
    Subject: Re: enhancement/466: Separate Compilation
    Date: Wed, 10 Sep 2003 10:56:56 -0700

     Jay,
     
     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.
     
     Best regards,
     
     Alec
            
    > Alec,
    >
    > 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
    >
    >
    > ===================================
    > Jay Lawrence
    > Senior Architect
    > Functional Verification
    > Cadence Design Systems, Inc.
    > (978) 262-6294
    > lawrence@cadence.com
    > ===================================
    >
    > > -----Original Message-----
    > > From: alec@fintronic.com [mailto:alec@fintronic.com]
    > > Sent: Tuesday, September 09, 2003 7:20 PM
    > > To: etf-bugs@boyd.com
    > > 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 and
    sponsored by Boyd Technology, Inc.