IP Breadcrumbs Method for tracking IP versions in SOC Database

Mukund Pai, Sudeep Mehta, Marijan Persun, Shambu Swamy
Intel Corporation

Abstract:

In Today’s complex systems-on-chip (SOC) designs, there is a constant need to determine and ascertain that correct IP’s are being integrated for final tape-in. In addition, there is a need to make sure that none of the IP’s used within the SOC are in violation of the vendor supplier agreement. This paranoia exists throughout the SOC development process and needs a methodology and an efficient mechanism to track IP versions and IP sources. The SOC program management office is required to verify, validate and sign-off on the IP BOM list as it matures through the SOC development process. We propose a novel method of breadcrumb insertion that is non-intrusive and easy to setup within the context of the IP-SOC development ecosystem. This method adds no overhead on the IP side nor on the SOC side. It is architected to be non-invasive but effective in dealing with today’s mix of reuse IP’s and concurrently developed IP’s. This method also addresses tracking of hierarchical IP’s that are nested within a given parent IP or IP subsystem.

Introduction:

SOC development consists of downloading several best-in-class IP’s from a common repository and integrating them in the SOC. Most IP’s deliver several drops throughout the execution phase of the SOC timeline until tape-in. These are called just-in-time (JIT) IP’s, which are developed in conjunction with the SOC development cycle. The integrator on the SOC side downloads IP’s based on current status of the RTL framework and functional validation results. Several re-drops of the IP’s are initiated due to certain validation failures or functional bugs encountered and debugged to a given IP’s collateral. Eventually, there is a stable contour developed which passes through all the rigorous directed and random validation tests. This SOC RTL integration contour is now delivered to the structural design team for hardening the IP’s and converging the design in the physical domain. In the end, before tape-in, there is a paranoia check done to make sure that the correct version of the IP is integrated into the SOC. We describe a comprehensive methodology that extracts the various IP versions currently integrated into a given SOC database contour.

Today’s IP-SOC ecosystem is a complex and diverse combination of reuse IP’s and concurrently developed IP’s. The complexity of keeping track of IP versions and IP drops within the SOC execution schedule becomes a very hard and tedious problem to resolve. When the SOC reaches tape-in status, considerable effort needs to be spent on determining that the correct IP versions are integrated into the SOC and are as intended for tape-in. To determine this, it takes several weeks and even months of human glue effort to create a detailed list of all IP’s in the SOC BOM.

An SOC BOM consisting of a mix of reuse IP’s and concurrent IP’s is usually the case when the SOC needs to be a key differentiator in the market with the latest competitive IP generations. In order to achieve this distinction and best in class functionality, some IP development goes concurrent with SOC development. These classes of key differentiator IP’s are called “just in time” (JIT) IP’s. During the SOC integration process, several revisions of the JIT IP could be delivered to the SOC. Concurrent development results in several bugs flagged during integration and verification by the SOC which the JIT-IP needs to fix in their database. This causes the IP to deliver several updated revisions to the SOC. Ultimately, if there are many JIT-IP’s constituting an SOC’s IP BOM list, then it becomes a complex issue of how to manage the revision tracking within the SOC database. This tracking has to be agile enough to detect IP versions in the front-end database or the back-end database of the SOC integration phases. The complexity increases significantly as we approach SOC tape-in.

In order to resolve this tracing and tracking of IP versions within an SOC’s database, we propose an IP fingerprinting methodology that is comprehensive but non-intrusive to the IP or SOC work flows.

We looked at existing methodologies that have used IP fingerprinting to determine IP’s used within a given SOC. These techniques are robust and have specific advantages in specific situations but we found them either too intrusive or lacking the comprehensive manner that we needed to trace and track IP’s being integrated into our SOCs. In the following sections we outline our methodology and its comprehensive capability.

FIG 1: Diagram of IP-SOC ecosystem including IP Repository. Breadcrumb insertion in IP Repository

IP Breadcrumb Methodology:

The IP Breadcrumb Methodology consists of collating critical IP Metadata in a separate file and appending it to the IP tar ball in the IP Repository as shown in Fig [1] above. The IP Repository intercepts the IP upload and inserts the breadcrumb before publishing the IP for downloads. The IP Metadata consists of several identifiers related to the IP’s lineage in the Repository database. Examples include but not limited to, the Original IP Owner, the Original IP checksum, the Repository ID, Revision ID and the time and date stamp as shown in Fig [3]. The IP checksum stands for the total checksum representing all the files in the IP tar ball. Many more useful and crucial metadata elements could be added to the IP Breadcrumb file. Since this is a file that is added to the existing tar ball, a new total checksum is derived and stored in the IP Breadcrumb file beyond the original checksum that was generated.

The SOC integrator downloads this IP tar ball using a special download script. This download script is used by all SOC integrators across all organizations. The download script tags and captures the IP metadata from the Breadcrumb file and archives it. The IP tag is referenced throughout the whole SOC Integration process. At any point in the SOC Integration Database pipe, the user can query for the IP Metadata through a special script that correlates the IP tag to the breadcrumb metadata. The flow of steps in the IP Breadcrumb generation and insertion is as shown in Fig [2]. With every SOC RTL database contour release, the user can query for a complete list of IP Revisions that have been integrated into that released database. This gives full visibility of all reuse IP versions and JIT-IP versions.

Fig [4] below shows an example of how we can check the IP versions using the IP breadcrumb methodology successfully. As illustrated, we create an IP version list downloaded from the IP Repository and compare it against the IP version list from the SOC tape-in database. Additionally, we create a tape-in IP BOM list from the IP Registry. The IP Registry is where every IP that is intended to be integrated into the SOC is captured along with the different versions meant for the different milestone drops, in case of JIT-IP’s. This comparison can be done in a few minutes what used to take weeks and months to put together. The IP breadcrumb method provides this benefit during every phase of the SOC development including tape-in.

Fig 2: Flow of steps in the IP Breadcrumb generation, insertion and IP download process

Hierarchical Breadcrumbs:

The IP breadcrumb methodology works for all IP’s including nested IP’s. We can create hierarchical breadcrumbs which include all nested IP’s within a Parent IP configuration and track the revisions across all of them as well. The Parent IP tar ball includes a breadcrumb file that instantiates all nested IP metadata along with the Parent IP metadata. This helps tremendously to keep track of which Parent IP version has particular nested IP versions included. Through this method of hierarchical tracking we are able to resolve some of the tape-in paranoia issues of version mismatches and save millions of dollars’ worth of rework post tape-in not to mention the man weeks or months of manual effort in collating all this information.

Fig 3: An example of a Breadcrumb file with IP metadata

Fig 4: Example of TI paranoia checking using IP Breadcrumbs methodology

Future Direction:

There are several enhancements being planned to provide more depth in tracing and tracking every IP collateral file in any SOC database contour using the IP breadcrumb methodology. We are investigating several methods and they are listed below.

a) Comprehensive tracking of every collateral file in every IP tar ball:

The methodology being investigated can provide the ability to know from which IP version a given collateral file originated. This tracking is helpful in a SOC database context where one might have only one type of collateral file to determine IP version and lineage. Every file would have a header section that would include the Parent IP genealogy plus the individual file checksum. The methodology could obfuscate the header information if needed as well. Every SOC Integration flow would check for the presence of the header in the collateral file. Absence of the header would cause the flow to abort giving an error message alerting the integrator.

b) In Depth tracking of every collateral file content in a given IP tar ball:

Additionally, we could create a list of the collateral files in the tar ball and their respective checksums for easy comparison and data match. This file could be added to the IP repository tar ball. At the SOC level, the infrastructure would recreate checksum for a given collateral file and that checksum could be checked against the file list lookup in the IP Repository. This method would go above and beyond just checking the header of the file for IP version association. It would check to see if the file contents are the same or have been changed since being downloaded. This is valuable in the case of 3rd Party External IP’s that are included in the SOC. The External IP Audit team can check each and every External IP file for any tampering of IP contents. This technique would help prevent costly and complicated litigations from 3rd Party IP vendors and help the internal audit team to keep databases secure and tamper proof.

c) Institute IP Metadata creation and addition at IP source:

Although this paper discusses the creation and addition of IP Metadata to the IP tar ball upload, the ideal approach would be to install the IP metadata at the source of data creation. This would be at IP create and package at the IP source. We need to have an IP packaging flow which works on the collateral files and inserts metadata in each and every file, creates a file that has all the collaterals and their checksums listed and create a top level breadcrumb file with IP metadata and tar ball checksum. This provides comprehensive coverage of the tar ball to track the IP version on the SOC side as well as have the flexibility to track individual collateral files within a given SOC database.

Conclusion:

The IP Breadcrumb Methodology is a non-invasive method of tracking IP versions within the SOC integration framework. Many different approaches exist in the industry to track and verify IP’s being used in SOCs. Some techniques are intrusive where they are blended into the Design Flows whereas some are dependent on a remote IP fingerprint storage and analytics. In this paper, we propose a non-invasive method that has all the requisite information to track specific IP versions within a given SOC database. We describe how a breadcrumb file is generated that gets archived as well as tracked thru the SOC integration phases without any overhead to the design flows. We feel that this non-invasive method is advantageous for any SOC that wants to adopt this methodology without any impact to existing IP collateral contents. The methodology also provides the framework where any SOC can implement it as part of the design flows if needed. Our results have shown that the key information can be derived behind the scenes with no overhead to the IP teams nor to the SOC teams. Our intention of building a versatile non-intrusive system of IP fingerprinting is validated through this methodology.

Acknowledgements:

We thank Intel’s Device Development Group (DDG), Information Technology Group (IT) and the Design Automation Group (DA) for their support in providing the mechanisms and tool development for making this methodology possible.

If you wish to download a copy of this white paper, click here