IP Re-Engineering and Design Methodology

B Akash Apasangi, Venugopal Nallamalli from MindTree Ltd  

Introduction:

Today SoCs are becoming increasingly complex with hundreds of IPs being reused, integrated and further translated into millions of transistors in the design process. Each IP used in these SoCs evolves from one stage to another stage during the design cycle. The IP after a certain stage will undergo changes for the new requirements or to fit the design environment changes or due to known bugs (including silicon bugs) discovered during the validation.  In the current trend an IP can be used in multiple SoCs and hence there is a need for the IP to be configurable, robust and support multiple projects (requirements) with minimal effort from the IP user to modify the IP. To cater to these changing requirements a new methodology to re-engineer IPs has been developed to enhance, sustain and maintain IPs.

Challenges in IP Re-Engineering:

Today integration teams and designers are faced with varied challenges when it comes to reusing an IP core. Some of the challenges with IP’s are mentioned below:

• IPs undergoing continuous development – feature enhancements, performance improvements etc
• An IP is used in multiple projects and across various geographies – IP maintenance and support
• IPs used across multiple technology nodes
• Lack of IP quality and IP bugs leading to more design re-spins
• No proper documentation leading to longer integration time and productivity loss
• IP Packaging – providing the ability for the integrator to plug the device with minimal integration effort while modifying the IP according to the user’s requirements

Solution – IP RED Methodology:

IP Re-Engineering and Design (IP-RED) is an initiative (methodology) to re-engineer IPs which provides efficient and cost-effective solutions. This methodology offers benefits in the form of robust IP design, qualification, customization, clean-up, maintenance and re-use.

IP RED is broadly classified into two types; Design IP (known as DIP) re-engineering and Verification IP (known as VIP) re-engineering. A conceptual block diagram of IP RED is shown below in Figure 1. The IP RED methodology is built upon a back-bone structure consisting of tools, platforms, process and methodology. The verticals are the application areas (like Design, Verification, FPGA Flow, ASIC Flow, and Validation) while the phases (Auditing, Execution and Packaging) span through each of these verticals providing a standard approach. Following sections will delve into finer details of IP RED like - phases, scenarios and also look into a case study to illustrate the usage and effectiveness of the methodology.

Figure 1 : IP RED Concept

The IP RED methodology is divided into three phases, namely – Auditing, Execution and Packaging.

Auditing:

The phases of IP RED correspond to the systematic approach for the given scenario in which an IP is initially audited for the current status of the IP, available documentation, implementation details, integration requirements and tools (reports and logs) available – tool flow etc,. The auditing phase is crucial in providing inputs on scope, schedule, current status, feasibility and effort for re-engineering the IP. Considering these parameters an auditing report is prepared and reviewed leading to a detailed work breakdown structure (WBS); which is also the starting point for execution.

Execution:

The execution phase is the actual implementation stage. This phase overcomes the design challenges that are posed by the re-engineering process; like - technology dependency, tool dependency, and special hardware dependencies. This phase uses the auditing report specifying the exact nature of changes and what changes to do and the available infrastructure in converting the existing IP in to an enhanced IP. Execution is performed with a specific set of guidelines provided to re-engineer the IP.

Packaging:

The packaging and quality check phase follow execution phase where the deliverables are packaged according to the requirement and are quality checked before they are delivered to the customer. The quality check process is split across phases and it is mandatory to ensure that the IP meets the required quality needs. The packaging phase is as important as auditing and execution, in which it takes into account the environment where the IP will be integrated or to suit the environmental needs of the customer using this IP. The IP package provides a facility to configure the IP with minimal manual intervention and also to test the IP with a stand alone verification environment. A typical IP Package may consist of Docs, RTL, Verification, Scripts, Synthesis and Formal Verification directories. The scripts can be provided to configure the IP, run test cases, and perform trial synthesis. The synthesis directory includes files with info related to multi-cycle path, false path etc. Thus ensuring the package supports every aspect of re-engineering cycle.

IP RED Scenarios:

 It becomes difficult without a methodical approach to ensure proper implementation of the IP re-engineering requirements. This is addressed by identifying the possible scenarios and providing a detailed re-engineering flow for each of such scenarios with proper estimation of schedule and effort without compromising on the quality goals. IP Re-engineering and design scenarios are classification of possible ways in which an IP can be re-engineered or application where IP RED can be applied. Table 1 highlights IP RED scenario examples with respect to design IP (DIP) and verification IP (VIP).

IP Re-Engineering Scenarios
DIP	VIP
Feature enhancement /removal	Specman based re-engineering
Power, Performance, Area Optimization	SV/Vera based re-engineering
Technology Migration	SoC Verification
Process /Guideline Compliance	Migration (ex: ’e’ to SV)
IP integration into SoC	Gate Level Verification
IP Bench marking / certification	Compliance check and coverage improvement

Table 1 : IP RED Scenario Examples

DIP scenarios are classified into five broad groups based on the set of re-engineering activities carried out. The basic categories are as mentioned below:

1.    IP RTL Development and Enhancement: In this category an IP is re-engineered considering the RTL related changes. For example:

• Bus protocol changes
• Abstraction level translation
• Clock and reset changes
• IP enhancement using design reuse
• IP scalability and debug enhancements

2.    IP Technology Implementation: This category of IP re-engineering involves the migration of IP from one technology to another. This covers both ASIC and FPGA categories and technology related changes. For example:

• Technology node migration
• FPGA to ASIC migration
• ASIC to FPGA migration
• FPGA to FPGA migration

3.    IP Optimization: This category of IP re-engineering scenarios includes the optimization for Power, Performance and Area. For example:

• Architectural changes for Power
• Architectural changes for Performance
• Architectural changes for Area

4.    IP Validation: This category of IP re-engineering scenario includes the validation across multiple platforms like ASIC validation, FPGA validation and IP bench marking and certification. For example:

• ASIC / FPGA Validation
• IP benchmarking / certification

5.    IP Maintenance: This category of IP re-engineering scenario includes the activities for IP maintenance like clean-up for process or guidelines or for synthesis. For example:

• IP cleanup for synthesis and implementation
• Cleaning up of IP for process / guidelines compliance
• IP documentation and maintenance

Some of the VIP scenarios are categorized as mentioned below:

1.    Specman based re-engineering: This re-engineering category addresses the VIPs developed using Specman. For example:

• eRM compliance
• Feature enhancements
• Environment upgrade / migration

2.    System Verilog (SV) / Vera based re-engineering: This category addresses the VIPs developed using SV or Vera. For example:

• Methodology compliance
• Environment upgrade / migration
• Coverage improvement

3.    SOC Verification re-engineering: This re-engineering category addresses the SoC based re-engineering activities like updating the test bench or test environment or coverage based updates or performance verification at system level.

4.    Migration & Verification: This VIP re-engineering category addresses the various verification environment migration related activities and also involves methodology compliance checks. For example:

• Migration from Specman ‘e’ to System Verilog (SV)
• Migration from legacy environment to ‘e’ / SV
• Methodology compliance (VMM / OVM / AVM / ERM)

For each scenario, IP RED flow will provide detailed step by step approach that will help in smooth execution of the activities for getting the re-engineered IP in the estimated time with quality deliverables leveraging the experience and anticipating the issues foreseen in the design flow. The methodology makes it simpler by having pre - defined checklists and templates for different phases of IP RED for each scenario with the finer details of tasks to be performed. The methodology also takes care of the impact of changes on the IP at each phase of re-engineering.

Case study 1:

Let us consider the case study of AXI Verification IP (VIP) used for verifying the AXI interconnect. Following sections provide an overview of the AXI VIP enhancement flow and also detail the overall verification environment.

AXI VIP Enhancement:

A flow diagram showing the guidelines for the case study considered is as shown in Figure 3. The flow diagram shows a common flow used for enhancement of VIPs for both Specman ‘e’ and System Verilog (SV). The AXI VIP has the following features: it can act as an AXI master / slave; it will drive all the transactions to and from the DUT. The AXI VIP includes protocol checkers, bus functional modules (BFM), monitors, sequence drivers and configuration used to configure the AXI and also the static information required for operation like endian type, bus width etc. The enhancements required were related to performing interleaving operation, priority logic, out of order address and data transactions, time out feature when the master locks the bus for a particular transaction and bug fixes related to ready and valid signals.

The VIP is enhanced for these requirements using the IP RED methodology. Starting with auditing phase where the VIP data base along with supporting documents are analyzed for the missing features and requirements are clearly defined to understand the scope of work and a SoW is created with each activity clearly defined guided by the estimation checklist. The audit report is reviewed and signed off to by customer to proceed for next phase. The latest database of the IP is taken and the execution is performed as per the feature enhancement scenario flow as depicted in Figure 3. The guidelines for enhancement of the VIP are considered taking into account the coding guidelines including the targeted methodology like OVM/VMM in case of System Verilog or eRM wherever applicable or custom methodology to avoid the simulator dependency. The VIP was successfully enhanced, verified and was packaged according to the standard format including scripts for modifying the VIP and test cases for stand alone verification of the VIP. The VIP was successfully used to verify the DUT using the verification environment as explained in the next section.

 

Figure 2 : AXI Verification environment

Environment Overview:

The AXI verification environment is as shown in the Figure 2. It consists of AXI VIP used as both slave and master, the DUT is an AXI interconnect fabric which is an AXI compliant controller intended to control and enhance the performance of AXI system bus transactions. This controller can be configured based on the requirements of the system. It incorporates multiple address multiple data architecture and is designed to achieve high system performance and is developed as part of DIP development methodology. The test cases represent different scenarios in which a DUT can be used, they are also written to cover the corner cases and to ensure the coverage goals are met. The environment will use built in protocol checkers within the VIP in addition to these interconnect checkers need to be coded to verify all the features. The checkers will mimic the design so that any deviation in the RTL implementation with respect to the design document will be caught in the course of verification. The checker code will be coded in a way that if the matrix of masters and slave is varied we can use the same set of checkers to check the DUT. The scoreboard is used to keep track of the input transactions and output transactions and to check if they match for a particular master salve path and will also check for data integrity and make sure all the transactions are complete before the test case ends.

Case study 2:

This case study highlights another VIP enhancement where a PCIe1.1 Specman ‘e’ Verification Component (eVC) is enhanced to PCIe2.0 eVC. The VIP enhancement for PCIe 2.0 consists of mainly changes in the protocol at transaction layer (TL), data link layer (DLL), physical layer (PL) and changes in configurations.  The VIP was successfully enhanced using the IP RED methodology using the flow diagram presented in Figure 3 to ensure the enhanced eVC is adhering to the latest PCIe2.0 standard specifications.

 

Figure 3 : Specman ‘e’ / SV VIP feature enhancement flow

Check List:

The following section shows the snapshot of the VIP re-engineering check list for auditing of IPs. The first section shows the general considerations for VIP and the later one specifically related to Specman ‘e’ based and SV based re-engineering.

 

Figure 4 : Snap shot of the check list showing sections of VIP auditing check list

 Conclusion:

The IP RED methodology provides a robust solution for re-engineering IPs with its structured approach in each phase of IP re-engineering, be it development, enhancement or implementation applicable to both DIP & VIP and supported by well defined check-lists and templates thus ensuring quality deliverables. The methodology leverages on several man years of experience in re-engineering IPs to provide a near accurate estimates with respect to schedule and effort for re-engineering an IP. Two case studies are presented based on VIP re-engineering, showing how a VIP can be enhanced for the given set of requirements indicating the need for such a methodology.