Flexible Integration System for IPs into SoC

The number of IPs with growing complexity and heterogeneity is ever increasing (counting into hundreds) to be integrated into a single SoC. It’s not possible to have them all available at once and in a single repository for the integration engineers to assemble all of them together and integrate into the SoC. The reality is that the IPs are scattered at multiple locations with different third party vendors, in different types of repositories and with different lifecycles. Also, generally, the SoC integration team is very small with one or two top level design experts. In such a scenario, intelligent and robust automated systems are needed to integrate the IPs, from wherever they are, into the SoC without compromising the IP rights and protection.

Looking at the ENOVIA DesignSync Data Manager of Dassault Systemes, it has all what is needed for IPs integration into an SoC. However in order to expand the reach further to integrate IPs residing in different repositories such as CVS, GIT or Subversion, external to DesignSync environment, Dassault has created an innovative solution by extending the DesignSync further with Foreign Modules, and is called as DSFM.

In a typical scenario, the SoC top module can have hierarchical references to other modules within the DesignSync workspace and the external modules which can be in the native CM environment (such as SVN, ClearCase, CVS etc.) of the third party vendors. How does the DSFM system make it possible to seamlessly collate these IPs from different CM systems? That’s an innovative solution. In order to establish connection with the external CM system, the External Module uses a Modules Hierarchy Reference (href) URL which is parsed and interpreted by the client populate command to call the appropriate foreign module type function (called handler) that is responsible for further parsing and generating an appropriate external CM system command.

A top-level design vaulted within a DesignSync server can have IPs in the same server, other DesignSync server or a server external to DesignSync. The href URL used by the External Module functionality of DesignSync to establish connection with the IP in external server is different from usual href URL in the sense that it does not have host and port which provides an indication that the URL should be processed at the client side. It takes the form as – sync:///ExternalModule//, where object_data includes information to identify the target IP to be populated. For example –

sync:///ExternalModule/SVN/www.mycompany.com/81/svn/repositoryname/tags/release-1.0

The handler at the client side is a TCL (Tool Command Language) script developed by the customer and is specific to external repository type and IP reuse methodology. This code is installed into the DesignSync client tools installation or added into the Development Settings Templates when using Enterprise DesignSync Administration. The handler code must include the External Module package, establish the namespace for the functions and define the procedure for the CM system and DesignSync command that will trigger the handler.

The handler produces and executes shell level command (specific to OS) that brings the data from external CM system into the user workspace. Other DesignSync commands understand the existence of the External Module href and intelligently act accordingly, e.g. ‘add’ will not add files within external module base directories to modules; ‘ci’ recognizes and skips external module base directories; ‘rmmod’ removes external module metadata, but leaves external module base directory and data intact. The whole external module data is kept populated under the designated relative path for that module.

The overall External Module architecture must adhere to corporate IP repository standards and methodologies that can vary from customer to customer. Considerable attention must be given to registration process, legal requirements, geographical restrictions, privacy of vital IP information and so on. The system should accommodate almost all corporate IP requirements.

The system provides very high consistency, performance and control to the design integrator over the use of IPs within a complex semiconductor design. At the same time it provides good flexibility for the IP designers to stay with their choice of CM systems and design cycles to provide good quality IPs.

This is a step in the right direction by Dassault towards its Design Engineering strategy that focuses on IP integration, design collaboration and verification. The methodology provides a robust management of all IPs (including external IPs) into the SoC hierarchy that prevents any wrong or imperfect IP from entering the system, thus improving the verification time and reducing re-spins.

A nice level of detailed description about the DesignSync External Modules system can be found in a whitepaperauthored by Dassault Systemes. In the whitepaper, there are nice examples of code snippets about a few procedures such as interaction of External Module handler with an SVN server.

Comments