High Quality IP creation through Efficient Packaging and Multiple Configuration Testing

Prabuddha Mitra, Synopsys (I) Pvt. Ltd
Bangalore, India

Abstract

An efficient method of Packaging Silicon IP and then testing /synthesizing it for multiple configurations has been described. It has been shown how with the help of a packaging/regression environment called the Regression Control Environment(RCE), the “Packaging Engineering” activity can be automated. The process of linting, verifying, synthesizing an IP core for multiple configurations in an efficient, automated way along with many other IP development related activities have also been described. The proposed methodology has resulted in better quality of IP cores. It has also reduced the time spent on packaging as well as verification/synthesis activities during IP development process leading to an overall increase in productivity.

1. Introduction

IP Design for re-use and its efficient packaging is an important aspect of IP development process and hence considerable attention is being paid to it. Many packaging tools have been created and methodologies have been suggested in this regard. However, the problem is that there is no established pre–defined standard which clearly defines the IP core development /verification guidelines. In the absence of such a guideline, most companies provide an IP core as a package consisting of the following items

• Source Code(mostly written as RTL code for soft IPs)
• Synthesis Scripts
• Testbench/Behavioral code
• Backend Tools support
• Embedded Licenses
• User Guide/Documentation/DataBooks etc.

The challenge of designing high quality IPs for reuse, verifying and synthesizing them as well as their efficient packaging becomes much more tough & tricky with IP vendors laying more and more stress on Time To Market.

In this paper we have dealt with the issue of high quality IP creation by designing it for reuse and then packaging it and finally testing/synthesizing it for multiple configurations. The methodology/flow followed for packaging is a fully automated one . A packaging/regression testing environment called the Regression Control Environment (RCE) has been created which delivers the following tasks in an automated way through the use of mostly Perl and Unix Shell/Tcl scripts –

1. Creation of a compressed package called a “coreKit” consisting of all the customer deliverable items – Synthesizable RTL source code, Synthesis Scripts, Verification testbenches, Embedded licenses etc.
2. Testing the coreKit for various possible configurations
3. Checking for synthesizability and “Formality” (Formal verification between RTL source and generated netlist) in multiple configurations
4. Version control mechanism and embedding of licensing information for release control
5. Generation of multiple IP products from the same internal database via the RCE.

The aim of this paper is to enable IP vendors to provide high quality IP cores, with excellent verification for reasonably all configurations with an extremely small “Product development Lifecycle”. The RCE tasks mentioned above will be described in detail, so that the intricate niceties at each stage come out. We have taken the example of packaging of the IEEE – 1394 Synopsys IP core via the RCE and the packaging tool coreBuilder. coreBuilder is a Synopsys packaging tool and has its own lexical language for making a core reusable. For clarity and completeness, we have briefly touched upon the coreBuilder tool (which is a part of the set of packaging tools called coreTools).

2. The Regression Control Environment (RCE)

The Regression Control Environment, as discussed, is an environment created to automate the packaging process as well as other quality related activities like simulation of multiple configurations, linting checks (Leda, DC-Lint, …), coverage analysis, synthesis regressions etc. Here we deal with each of the topics separately in the following subsections.

2.1 Creation of the coreKit

The RCE has a Makefile that has a set of commands that carry out the various functionalities of the RCE. The default command of the Makefile - “make” invokes the tool coreBuilder and creates a coreKit package. Before the creation of coreKit a number of activities are involved which are described in the following subsections.

2.1.1 Creation of Configurable RTL source code

In this step, the RTL source code (Verilog or VHDL) is written according to coreBuilder syntax. The coreBuilder has its own lexical extensions to Verilog/VHDL languages which makes RTL source code configurable on the basis of a set of predefined parameters. The parameter values are specified by the user as input to the coreConsultant tool and the source code is unpacked from the coreKit on this basis. The parameters’ values can be specified both via the coreConsultant GUI as well as in the batch mode if the same set of values is required to be repeated a number of times.

A Design configuration parameter is created using coreBuilder specific “reuse-pragmas” in the following fashion:

// reuse-pragma attr Description Request Receive FIFO Depth
// reuse-pragma attr MinValue 8
// reuse-pragma attr MaxValue 65536
// reuse-pragma attr Label Req Rx FIFO Depth (Power of 2 only)
// reuse-pragma attr CheckExpr {[CheckPower \ @ReqRxFIFODepth ]>0}
// reuse-pragma attr CheckExprMessage "FIFO depth must be \
a power of 2 only."
// reuse-pragma attr GroupName Asynchronous Receive
// reuse-pragma attr Sequence 10

`define ReqRxFIFODepth 64

Here the parameter name is ReqRxFIFODepth. The description of the attributes is given in the following Table

Attribute	Description of the attribute
Description	Description of the parameter
Label	Name of the parameter as visible in the coreConsultant GUI
MinValue	Specifying the lower limit on the value this parameter can take
MaxValue	Specifying on the parameter’s max value
CheckExpr	This attribute returns a true value if the Tcl expression following it evaluates to a true value.
CheckExprMessage	Displays the message that pops up if the CheckExpr fails to return a true value.
GroupName	Gives the name of the group in which the parameter is kept.
Sequence	Provides the sequence number of the parameter in the given group.

Hence, after the coreKit is created and then installed in a coreConsultant, the GUI (Graphical User Interface) looks as in Fig 1.

Here the 1st parameter in the GUI is our example parameter and as can be seen has a default value of 64. This value can be changed by the customer according to his requirements.

Once a parameter is created, it can be used to configure the source code.

For example, suppose we have a parameter AvRxEnable with the following attributes –

// reuse-pragma attr Description Isochronous Transmission Enable
// reuse-pragma attr Label ISO Transmit Enable
// reuse-pragma attr DefaultValue 1
// reuse-pragma attr GroupName Isochronous Transmit
// reuse-pragma attr Sequence 10

`define AvRxEnable

Here, we can include /exclude sections of the source code depending on whether the parameter is enabled. This is exemplified below:

// reuse-pragma startSub rxav [IncludeIf @AvRxEnable \
%subText]
wire Clk;
wire Rst;
wire [0:19] LLC_CycTimer;

// reuse-pragma endSub rxav

Hence, the part of code in between the startSub – endSub section is excluded if the user decides to disable the parameter AvRxEnable in his configuration. This feature is advantageous to the traditional use of `ifdef, where the section of unused code remains in the customer workspace.

Fig 1 . coreConsultant GUI of an Installed coreKit

2.1.2 Creation of Configurable Verification TestBench

As can be easily guessed, to verify multiple source code configurations, we need to accordingly configure the Verification TestBench. The TestBench may be configured according to the source code parameters. In addition to the source code parameters, the TestBench may also have Verification specific parameters. These parameters typically appear to the customer as which test case to run, specification of Verification Software Installation path etc.

More over, the customer may also desire that unnecessary test cases are not dumped into his workspace. For example, in our IEEE 1394 core we had a feature enabling AV transmission/reception. Accordingly, we had a set of AV test cases that were packaged into the coreKit. Now, if a particular customer wanted to configure his core which did not have the AV feature, he would normally not want that the AV related test cases be unpacked into his workspace. Hence, we had to package the Test Bench into the coreKit in such a fashion so that the TestBench directories/files could be selectively installed by the customer.

Thus, we wrote a script which was understood by the coreBuilder/coreConsultant tools, that enabled us to package TestBench directories into the coreKit in an automated fashion and also they were unpacked (via the coreConsultant) into the customer workspace and installed selectively. This is exemplified below.

add_files_to_filegroup AV_TESTS –files\
./verif_cust/TestCases/av_tests/app_command.v \
./verif_cust/TestCases/av_tests/user_command.v" –install\
sim/TestCases/av_tests

set_filegroup_attribute AV_TESTS DeliverableType TRE
set_filegroup_attribute AV_TESTS Configurable 1
set_filegroup_attribute AV_TESTS ConfigActivity \
SpecifyConfiguration
set_filegroup_attribute AV_TESTS Install {=eval_param\
@AvTxEnable||@AvRxEnable}
set_filegroup_attribute AV_TESTS InstallWhen installation

In the above example, the files “app_command.v” and “user_command.v” were added to the coreKit

as part of the AV_TESTS filegroup. This was done while creation of the coreKit through the invocation of the coreBuilder tool from the RCE Makefile. Subsequently, when the coreKit was unpacked via the coreConsultant tool, if a user chose not to enable the parameters AvTxEnable and AvRxEnable(both), then these files were not dumped into the user configured workspace.

2.1.3 Synthesis

The important activity of synthesizing the IP core for multiple configurations and also providing the same facility to the customer can be done in a unique and efficient way.The key point is that coreBuilder users provide tool independent information about how they "intend" for the design to be implemented and then the tool looks at (1) the tool version, (2) the specific configuration of the core, (3) the specific cells available in the target library, and (4) the intent packaged with the coreKit, to generate an optimal synthesis script. Customers can add their own script fragments (the auxiliary scripts) if customization is really needed.

2.1.4 Packaging of Documents into the coreKit

The RCE also supports the automated packaging of all kinds of documents like Databooks, Release Notes and Installation notes into the coreKit. It also enables, that these documents appear as Help Menu items once the coreConsultant GUI is invoked by the customer.

Documentation filegroups are packaged as shown below:

add_files_to_filegroup Documentation_Files/Document \
-install ./docs

These files are added into the Help Menu of coreConsultant via another script as shown below:

set ::HelpMenuData {
{./docs/1394_dbook_3.2.pdf {DW_1394 DataBook}}
{./docs/1394_release_3.2.pdf {DW_1394 Release Notes}}
{./docs/1394_install_3.2.pdf {DW_1394 Installation Notes}}
}

Hence, just specifying the list of items to appear in the Help Menu is enough for the RCE to do the rest and put them as part of Help of coreConsultant.

2.2 Simulating Multiple configurations

Once the IP core is made configurable, it is required to be verified for all the realistically possible configurations before providing it to the customer. The RCE provides support to unpack the core into multiple configurations and then simulating them in an automated fashion.

This is done through regression control files .These are Perl Control files, which first define a specific configuration, then call RCE internal subroutine called ‘test’ by providing it with the specific arguments as shown in Fig 2. alongside.

Please note: The name of actual IEEE 1394 parameters have been changed

use strict "vars";

# declare valid general options and set them to default values

$options{"config"} = undef
$options{DesignView} ="RTL";
$options{SimTiming} = undef;
$options{SimChoice} = "VCS";
$options{RunStyle} = "local";
$options{RunOptions} = "";
$options{SimVer} = undef;
my $emailaddress = `whoami`;
chomp $emailaddress;
$options{EmailAddress} = "$emailaddress";
$options{DumpEnabled} = undef;
$options{DumpDepth} = undef;
$options{GrdSimParallel} = 1;
$options{TechFile} = undef;
$options{TechLib} = undef;
$options{Coverage} = undef;
$options{VeraHome} = undef;
$options{seed_num} = undef;
$options{ExtraRuntestOptions} = undef;

#----------------------------------------------------------------------------
# declare valid design-specific simulation options and set them
# default values
#----------------------------------------------------------------------------

$options{ClockDefault} = undef;
$options{ClockPeriod} = undef;
$options{TimeoutDefault} = undef;
$options{TimeoutCycles} = undef;
$options{ClockRatio} = undef;

# Optionally restore a previous random seed to rerun same tests
seed(0x12345678);

my $runoptions = "RunOptions= -V -o ./grd.log -P bnormal -l \
os_version=5.8 -m e -M $emailaddress \
/remote/drg01/dwre/bin/cc_wrapper ";

# ----------------------------------
# Configurations
# ----------------------------------

my $config0 = "NUM_HOST_CHANNELS=3 \
NUM_TRANS_CHANNELS=1 NUM_LOGIC_ENDPTS=3 \
NUM_PHY_ENDPTS=6 NUM_CONFIGS=6\
DESCRIPTOR_CACHE_MODE=2 TX_DFIFO_DEPTH=640 \
_MAX_ALTS_IN_INTF_1_CFG_1=10 \
ALTS_IN_INTF_2_CFG_1=10" ;

# ----------------------------------
# Run specific targetted tests first
# ----------------------------------

test( "config=Sim_config0_randomseed","DesignView=RTL",\
"SimChoice=VCS",$config0, "RunStyle=grd",\
"$runoptions","GrdSimParallel=1","SimVer=7.0.1", \
"Coverage=1", "DumpEnabled=1", "ExtraRuntestOptions= --\
rmdump 1 --RANDOM_SEED 1");

test(config=Sim_config0","DesignView=RTL","SimChoice=\
VCS",$config0,\
"RunStyle=grd","$runoptions","GrdSimParallel=1",\
"SimVer=7.0.1", "Coverage=1", "DumpEnabled=1", \
"ExtraRuntestOptions= --rmdump 1");

Fig 2. A simulation control file for IEEE 1394

As can be seen in the above simulation control file, first a configuration (config0) is defined by specifying the parameter values. Then ,the perl subroutine “test” is called which is fed with the following parameters respectively – the name of the configuration workspace into which the coreKit is going to be packed; the View that is going to be simulated ,i.e RTL,GTECH or GateLevel Netlist; the simulator that is going to be used; the predefined set of configuration parameter values that are going to be taken; whether the simulation is going to run on local machine or on a compute environment like a grid; the version of the simulator that is going to be used and whether one needs to enable simulation display dump for GUI postprocessing (BehvDump).

Hence, we can execute the tasks of the Verification activity in an automated fashion through the RCE. This increases the quality of the IP as well as decreases the Time To Results (TTR) substantially.

2.3 Synthesizing multiple configurations

Similar to simulation, to ensure the quality of the IP, we need to synthesize it for various configurations. This can be done in an automated fashion via RCE synthesis control files which are very similar in structure to RCE simulation control files.

Even here, we start by defining the configurations we need to synthesize by providing values to the parameters. Then in the perl control files we call a RCE inbuilt subroutine called “synth” as shown below.

synth( "V-2003.12-SP1", "lsi", "dc,formality", "eval [exec cat\
regress/tsmc_13u.tcl]", $config2, \
"config=Synth_config2_tsmc13u_V-2003.12-SP1 ");

Here the arguments passed to the “synth” subroutine are respectively --- Implementation Tool version no., target libraries, whether we want to synthesize or do a formal verification run, execution of custom scripts, the configuration parameter values, the configuration workspace name into which this coreKit is going to be unpacked .

As can be seen, all the information needed to run synthesis is provided in just one function call. These arguments can be changed to call the synth subroutine a number of times to run synthesis multiple times. Hence, this feature can also be seen as a way to increase quality/productivity as well as TTR.

The RCE Makefile target for running the simulation/synthesis regression is “regress”. Hence to run regressions, the core developer needs just to type ---

make regress confirm=yes control=<contol filename>;

2.4 Linting Quality checks on the IP

Once the synthesis and simulation regressions are completed, a normal quality analysis report requires Leda, DC Lint or other linting check reports. RCE has perl files to generate these reports automatically.

Hence, the core developer just needs to type the RCE Makefile target “qaag” (Quality-At-A-Glance) to generate the reports for the following quality checks :

Leda, DC Lint and Coverage. The individual RCE commands for these activities are respectively –

make qaag_leda; make qaag_dclint and make qaag_coverage.

2.5 Version control mechanism

To go through the “release” process in an automated way, the RCE provides the Makefile target “release”.

Hence, the release team just needs to type: make release and the Server (say CVS or Perforce) gets tagged accordingly .Other release related activities can also be executed in a similar automated fashion.

3 Creation of multiple coreKits(products) from the same database

The RCE enables us to create multiple coreKits/products with different contents from the same internal development database. The different products are encrypted with different License keys, the embedding of which are also achieved automatically via the RCE.The entire process is charted out with the help of the following example.

For our IEEE 1394 core, we had had two products namely

1. The IP core that supported the DTCP DTCP feature
2. The IP core that was provided without the DTCP Encryption-Decryption feature

These two products had separate licenses for unpacking (customer use) and were normally to be provided to the customer exclusive of one another. As part of the development process, it was also not desirable to maintain two different databases for the coreKits since any common change needed to be reflected in both the databases.

Hence, we generated a script that created the two coreKits from the same database of source files following the algorithm described below:

1. The declarations of DTCP related parameters (Section 2.1.1) were changed to accommodate the license related enabling/disabling.

For example, the parameter DTCPTxEnable was defined as follows:

In the above example we can see that only if the parameter AvTxEnable is true and the user has the authorized License, the Parameter value can be changed. If the User does not have the authorized license, then the parameter value is forced to “Zero” and also it cannot be modified via the coreConsultant by the user. This parameter (DTCPTxEnable) when disabled, removes the Transmit chain corresponding to the DTCP feature.

2. The script took as input whether we want a coreKit with the DTCP feature (coreKit 1) or without it (coreKit 2).

3. If the option for coreKit 1 was chosen, then the License corresponding to Product No. 1(LICENSENAME1 in the above example) was embedded into the coreKit and the package was created.

4. If the option for coreKit 2 was chosen, then the script completely removed the files that had the DTCP copyrighted encryption-decryption algorithms. Next, it embedded the license corresponding to Product No. 2.

Hence, in the consequent step, when the coreKit was generated, it was ensured that nothing related to the DTCP algorithm went inside the coreKit. The sections of code related to DTCP in other files would be automatically removed from coreKit 2’s customer workspace as he won’t be having the authorized license to unpack coreKit 1. (As we were maintaining separate sets of licences for the 2 Products or coreKits). Hence, in this fashion with the help of RCE and our custom script we were able to generate 2 separate coreKits (Products) and test them a multiple number of times in a highly automated fashion. This ensured accurate quality checks for both of our products simultaneously and in the end increased our productivity.

4. Conclusion

In this paper, an efficient scheme of packaging IP using Synopsys coreTools was mentioned .Apart from that, the paper also suggested highly efficient automated ways of testing multiple configurations and also synthesizing them. The paper dealt with various other aspects of quality improvements like Leda checks and Version Control Mechanisms. Hence, in a nutshell the paper provides a genuine guideline (with the successful example of IEEE 1394 core) to IP vendors about creating high quality IP cores through their efficient packaging/testing so as to improve overall productivity and TTR.This method of packaging and testing has been successfully employed for a number of Synopsys IP cores like Ethernet,SD-MMC,1394 ,HSOTG etc.

References

[1] Synopsys coreBuilder User’s Guide

[2] Synopsys coreConsultant User’s Guide

[3] Michael Keating, Pierre Bricaud, Reuse methodology manual: for system-on-a-chip designs, Kluwer Academic Publishers - Norwell, MA, USA

[4] Synopsys DESIGNWARE® 1394 AVLINK™ Databook