| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 466
|
| Category | enhancement
|
| Synopsis | Separate Compilation
|
| State | open
|
| Class | enhancement
|
| Arrival-Date | Sep 09 2003
|
| Originator | Fintronic USA, Inc.
|
| Release | 2005
|
| 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. |
| Fix |
The restrictions specified in Fintronic USA's donation could be relaxed during the standardization process. |
| Audit-Trail |
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. > 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. > > > |
| Unformatted |
|
Hosted by Boyd Technology