Xilinx Virtex-class FPGAs feature several advanced hardwired, hard IP blocks, some of which we must protect for legal reasons. Traditionally, to allow customers to use these blocks effectively while preventing theft or tampering, we’ve offered customers black-box simulation models called SmartModels of these cores. However, some customers have found these models hard to use and note the models tend to run much slower than regular RTL models in third-party simulation environments. So with the introduction of Virtex-5 FPGAs, we now support a much faster, easier to use but protected form of simulation model called a SecureIP model.

These new models have significant ease of use and performance advantages over SmartModels but there are some differences users should become familiar with to use the SecureIP models very effectively.

Let’s look at the issues of Hard IP modeling and then review some run time and performance benchmark data on the new vs. the old models. We’ll also look at further performance speedups with FAST models and benchmark those models running on simulators from Mentor, Cadence and Synopsys.

Before we get into the data, here’s a bit of background. At Xilinx each piece of hardwired, hard IP falls into one of two security classifications. Cores that fit into the first classification—such as DSP clock management cores (DCMs), BlockRAMs, and FIFO models-- do not require source code protection, and as such we provide these simulation models to customers in our standard library. However, we also have a second classification for Hard IP that we must protect. These cores include our gigabit transceiver (MGT) I/O cores, PCI Express, TEMAC, and PPC440 cores. Initially, we protected our second classification of cores with SmartModels, but now we’re offering a faster and easier to use and as-safe alternative with our new SecureIP models.

Issues with Supporting Hard IP in FPGA Devices

Many designers have found that SmartModels have performance ease-of-use issues, as well as simulation compatibility and support limitations. SmartModels run more slowly than RTL code, because to run SmartModels, simulation tools must have a complex communication interface called SWIFT, which inherently limits simulation speed and thus slows down debugging much more than traditional RTL based models.

But in 2005, the IEEE added the SecureIP encryption methodology to its Verilog Language Reference Manual (LRM), which enables IP providers to deliver models to customers that offer the advantages of fast RTL simulation run times without the performance limitations of SmartModels. The beauty of SecureIP is that to the user it is essentially no different than using non-encrypted Verilog models and libraries. With SecureIP models, IP vendors provide users with the encrypted models, then users compile the models with their simulator of choice, granted the simulator supports SecureIP.

The Verilog SecureIP Encryption Methodology

The IEEE defined and published the Verilog encryption in the IEEE STD 1364-2005 version of the Verilog LRM. Since then, Xilinx has been working with our simulation tool partners to ensure their tools support the standard and to ensure the SecureIP models we develop in-house will compile in the same manner as our standard libraries that customers use with their preferred simulation tools.

But while the use model is pretty much the same, vendors distribute SecureIP libraries in a different manner and the SecureIP libraries themselves work in a different way than standard libraries. That is, Xilinx and other vendors distribute SecureIP models to customers as encrypted files, usually named with a .vp extension. A SecureIP model may have one or more encrypted files and these files can only be decrypted by using a key. To use a SecureIP model within a simulator (or other software tool), the simulator must use a key to decrypt the model. It then compiles the model and sets up an equivalent binary file to use with that simulator. For Xilinx customers using a licensed version of a simulator tool that supports SecureIP, the process is completely transparent: Customers compile the SecureIP libraries and then the simulator performs the decryption. From this point on, customers reference the SecureIP library as a standard compiled library, and the simulator uses the library reference as it does with other standard libraries. When customers run simulation using a SecureIP model, it looks like a black box in that they can view or monitor only signals that the IP provider specifies. SecureIP models provide the same equivalent signal visibility as SmartModels, but only allow users to view or monitor signals in a simulation tool as specified in the model by the IP provider.

How to Set Up and Use SecureIP Models in the Xilinx Design Flow

Xilinx distributes SecureIP models as a set of encrypted files (with .vp file extensions) that we provide in a zip file within the ISE Design Suite, release 10.1 library directory. After users install the ISE design tools, they must run the compxlib program, which will compile and set up the SecureIP library, along with the other standard simulation libraries in the ISE 10.1 release for use in a supported simulation tool. Today Mentor Graphic’s ModelSim and Questa 6.3c and later releases support the SecureIP libraries. But because the standard for SecureIP models is a Verilog standard, customers using these models in a VHDL design must have a mixed-language license of the ModelSim simulator to use them. Xilinx is currently working on SecureIP model support for NCSIM from Cadence and VCS from Synopsys, and support for both is scheduled for the next release of ISE.

Using ISE and the ModelSim environment, users run the compxlib program to compile the SecureIP encrypted models along with the standard libraries. The compxlib program sets up the compiled SecureIP library in a directory named secureip, which is under the same library directory as the other standard compiled libraries. Compxlib also creates a modelsim.ini file, which contains a reference to the SecureIP library that is similar to the UNISIM and SIMPRIM libraries. From this point, designers simply use the modelsim.ini file to reference the SecureIP libraries in exactly the same way as the other standard libraries.

Because the SecureIP libraries are just RTL source code, which simulators can compile and use like other standard libraries, designers don’t need to add any special environmental variables to use them. When the simulator tool optimizes RTL source code in a standard library, it also optimizes the SecureIP libraries and provides the same performance advantages. This allows SecureIP libraries to provide significant performance advantages over SmartModel, as mentioned above. Figures 1 and Figure 2 show what references and interfaces tools require to support SmartModels compared to SecureIP library models.

Figure 1: An overview of SmartModel Use

Figure 2: An overview of SmartIP Model Use

Benchmark Results Comparing SecureIP Models to SmartModels

Now let’s look at benchmark results that compare SecureIP models to SmartModels using ModelSim 6.3e with the ISE 10.1 release (Service Pack 1). ModelSim is the only simulator that formally supports the SecureIP models in ISE 10.1 release, so ModelSim’s results are the only ones were presenting here.

In these benchmarks, we compared simulation performance by running a set of designs that use one or more hard IP models as a SecureIP model in ModelSim. We then ran the same set of designs using the equivalent SmartModel in the same version of ModelSim. We created the benchmarks with a set of design cases that instantiate a specific hard IP model along with a set of customer designs that instantiate one or more Hard IP models from the Virtex-5 FPGA UNISIM library. The hard IP models include the GTP_DUAL, GTX_DUAL, TEMAC, and the PCI_EP.

We compiled the ISE 10.1.01 release (Service Pack 1) libraries with ModelSim 6.3e and then ran both versions of the design in ModelSim 6.3e using the default (vopt mode) with optimization switched on. We ran the benchmark designs on a 64-bit Linux machine using Red Hat Enterprise Edition 4.0 using the 32 bit executables of ModelSim, which is recommended by Mentor Graphics.

The simulation performance improvement using the SecureIP models averaged 247%, or about a 3.5X simulation speed improvement over the performance of the same design with SmartModels. The performance run time improvement using SecureIP models compared to SmartModels, which included compilation time, load time, and simulation time, averaged 166%, or about a 2.7X performance improvement.

Table 1 lists a comparison of the improvements with SecureIP models over SmartModels using the ISE 10.1 with ModelSim 6.3e.

Improved Simulation Performance Using Models in Fast Simulation Mode

Another area where we focused on improving simulation performance is with a specific class of models that users can run in FAST simulation mode. Several Virtex-5 FPGA primitives in the ISE 10.1 release have this feature. These primitives include the BlockRAMs, FIFO, and DSP48E blocks. These models are only included in the Verilog library and VHDL UNISIM library. For more details on these primitives, refer to the ISE 10.1 Libraries Guides.

http://toolbox.xilinx.com/docsan/xilinx10/books/docs/virtex5_hdl/virtex5_hdl.pdf

Users can run these models in two modes, according to what users have set in the SIM_MODE parameter. Users can set the SIM_MODE parameter to SAFE, which is the default for using the model in legacy mode, or users can set it to FAST to run the model in a configuration optimized to improve simulation run-time performance. When users simulate the model in SAFE mode, the behavior will exactly match the behavior seen in the hardware. The simulation shows users all the issues that may occur if the model encounters problems or corner-case conditions. When users run the model in FAST mode, the tool does not flag certain checks or conditions. And which conditions the tool does not check or flag depends largely on the makeup of the model (Refer to the ISE 10.1 Synthesis and Simulation Design Guide under reducing simulation runtimes on page 144 for more details).

http://toolbox.xilinx.com/docsan/xilinx10/books/docs/sim/sim.pdf

In the ISE 10.1 release, we improved the performance of the DSP48E model so that it runs faster, even in SAFE mode. The improved DSP48E model also maintains the same functionality checks that exist with the legacy model. In addition, we also boosted the models performance when users run it in FAST mode. But for our new BRAM and FIFO models, users will only see performance improvements when they run the model in FAST mode. Because some of the model features we implemented in SAFE mode provide important checks and safeguards, we advise users to become familiar with the trade offs of using the model in a configuration that optimized for performance.

Before using models in FAST mode, we recommend that designers use the simulator profiler on their design to determine which components or models in their design have the most impact on performance. If the designers determine that they can run some of the components that have the most impact on performance in FAST mode, they'll likely see some speed up in simulation performance. The amount of performance improvement designers will see using models in FAST mode will depend on the size of the design, how many models the designers are using in FAST mode, and, what other components they are using in a design. Using models with different simulation modes is supported in all Xilinx-supported simulators. The example below shows a section of Verilog source code that instantiates a Virtex-5 FPGA DPS48E model, which is in the UNISIM library (Note: you must set the SIM_MODE parameter to FAST for each instantiated instance where you want to use the model in fast mode). Happy simulating!

module DSP48E_ADDSUB ( A, B, C, CLK, ALUMODE1, ALUMODE2, SUM);

//Inputs
input [29:0] A;
input [17:0] B;
input [47:0] C;
input CLK;
input [3:0] ALUMODE1;
input [3:0] ALUMODE2;

//Outputs
output [95:0] SUM;

wire [47:0] c_reg;
wire [47:0] sum_reg;
wire carrycascout;

/////////////////////////////////////////////////////////////////////

// Instantiation of DSP48E named as utt_0 //

/////////////////////////////////////////////////////////////////////
DSP48E #(.SIM_MODE(”FAST”)) //Specify in line parameter for fast mode

utt_0 (.CARRYCASCOUT (carrycascout),

.P (sum_reg),
.A (A),
.ACIN (30'b0),
.ALUMODE (ALUMODE1),
.B (B),
.BCIN (18'b0),
.C (C),
.CARRYCASCIN (1'b0),
.CARRYIN (1'b0),
.CARRYINSEL (3'b0),
.CEA1 (1'b1),
.CEA2 (1'b1),
.CEALUMODE (1'b1),
.CEB1 (1'b1),
.CEB2 (1'b1),
.CEC (1'b1),
.CECARRYIN (1'b1),
.CECTRL (1'b1),
.CEM (1'b1),
.CEMULTCARRYIN (1'b1),
.CEP (1'b1),
.CLK (CLK),
.MULTSIGNIN (1'b0),
.OPMODE (7'b0110011),
.PCIN (48'b0),
.RSTA (1'b0),
.RSTALLCARRYIN (1'b0),
.RSTALUMODE (1'b0),
.RSTB (1'b0),
.RSTC (1'b0),
.RSTCTRL (1'b0),
.RSTM (1'b0),
.RSTP (1'b0) );

In the process of improving the models, we created a set of design cases to measure simulation run times on several Virtex-5 FPGA library components using the FAST simulation mode in Mentor’s ModelSim, Cadence’s NCSIM, and Synopsys’ VCS. Table 2 shows the results of these benchmarks. We used these design cases to specifically measure the simulation performance improvement of each model in the ISE 10.1 release that has a FAST mode and then compared the results for each model to the results for their corresponding or legacy model from the ISE 9.2i release. We didn’t derive the design cases from a typical customer design, so as previously mentioned results may vary from simulator to simulator depending on design parameters. But for the sake of testing FAST vs. legacy, we ran the design test cases on a 64 bit Linux machine with Red Hat Enterprise Edition 4.0 using the 32 bit executables of each simulator.

FAST vs. Legacy: The benchmark results

The amount of improvement of the FAST simulation model over the legacy model varied with each simulator, although the average improvement for the FAST version of the RAM models was over 2X faster for both NCSIM and VCS. The FAST DSP48E and FIFO models also showed encouraging performance improvements: up 37% or 1.4X using ModelSim, and up 25% or 1.25X using VCS. Note, these initial results represent the first revision of model improvements. We will continue to work with our simulation patners to provide additional performance improvements in future releases.

Conclusion

As it has been noted many times and in many ways, verification is a huge if not the biggest bottleneck for chip design projects. We at Xilinx realize that as we take away mainstream ASIC marketshare with multi-million gate FPGAs, designs you create with on our devices are not immune to verification requirements and there is always a need in the user community to find ways to speed up the verification process. By discontinuing SmartModels in favor or SecureIP, we’ve found significant simulation runtime and performance improvements in our tools, while ensuring that our IP is protected. And we are also finding that by making our simulation models even faster, we can further aid designers in verifying their designs.

Table 2: FAST versions of the models showed speedups on all third-party simulation environments

By Howard Walker, Sr. Technical Marketing Engineer

Howard Walker is a Senior Technical Marketing Engineer in the Design Services Division at Xilinx. He works on managing relationships with third party Simulation Tool Vendors, qualifying new feature and performance improvements and coordinating the use of simulation tools among all the divisions in Xilinx. Howard has worked at Xilinx for over 15 years in various positions and holds a bachelor’s degree in electrical and computer engineering from University of California at Santa Barbara.

June 5, 2008

[back to top]

Comments on this article? Send them to comments@fpgajournal.com