RE: enhancement/466: Separate Compilation

From: Jay Lawrence (lawrence@cadence.com)
Date: Wed Sep 10 2003 - 06:40:01 PDT

  • Next message: Brad Pierce: "Re: errata/217: PROPOSAL - Note that task/func params can only be overridden by defparams"

    Precedence: bulk

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

    From: "Jay Lawrence" <lawrence@cadence.com>
    To: <alec@fintronic.com>, <etf-bugs@boyd.com>
    Cc:
    Subject: RE: enhancement/466: Separate Compilation
    Date: Wed, 10 Sep 2003 09:25:28 -0400

     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 - 06:43:07 PDT and
    sponsored by Boyd Technology, Inc.