I. Overview
The ability to create differentiated products for SoC, IC, and FPGA designs within narrow market windows depends heavily on effective semiconductor IP reuse.
This white paper covers ten best practices for maximizing the efficient reuse of internal and external IP from a data and design flow integration perspective. It discusses core development practices which lay the groundwork for quality IP development, along with efficient mechanisms for managing a company’s dynamically changing IP across divergent design teams and derivative designs.
II. Set up IP Development to Maximize Later IP Reuse
Partition new design work into functional modules.
The project manager or chip lead creates an initial partitioning structure, and then assigns the design modules/IP development to individual designers or teams. This practice establishes the various design modules as IP blocks, even when their current reuse potential is not yet known.
The ideal practice is to define the design modules in anticipation of the optimal reuse of each block. The lead must strike a balance between creating small modules, which have high flexibility as they will not be further split during reuse and ensuring that each IP block contains a critical mass of functionality, so it can be reused on its own rather than always needing to be combined with other modules.
By encouraging only selected team leaders and architects to define the individual blocks and their components, development organizations can avoid complex instance trees, creating too many imcompatible IPs and broken design rules.
Organize each IP block as a collection of data types.
Each IP design element is generally comprised of mixed data types, including HDL, SPI, LIB, LEF/DEF, SPF, and GDS.
Setting up the IP block organization by consistent and relevant data types gives developers an infrastructure in which to place their data files and sub-directories rather than using ad-hoc trees which may be difficult to package or release.
Data type partitioning also allows engineers to easily extract or apply access controls to specific data types, such as “Verilog and LIB only”.
Curate all new IP – internal & external – to a centralized IP management system.
Create an initial metadata schema to enable the available IP to be categorized and searchable throughout its development and release process.
Curate all IP to this centralized IP management system, regardless of which design management system it was created in or is currently stored. As you add new IP, expand your metadata schema as appropriate.
Binding 3rd party IP into the same central IP catalog allows easier tracking and verification of any changes associated with updates from external vendors.
Link the IP to a bug/issue tracking system from the start.
Integrate the IP with an issue or bug tracking system. Doing this step from the beginning ensures that all identified issues, feature requirements and bug fixes associated with each IP block are automatically recorded in both the issue tracking system and the IP management system.
This close linkage allows project management, design and verification teams to view and trace the issue history for every IP they work with across all versions and designs. The IP changes associated with the bug fixes and feature enhancement completion should be viewable in the IP and the issue history viewed in the issue tracking system.
Further, chip and IP designers should automatically be notified of any new bugs identified as well as the bug status. Bug fixes or design improvements can then be automatically or selectively propagated to the other design branches or derivatives.
This practice allows the chip integration lead to determine if the IP blocks are ready for release and publish for reuse. In determining IP readiness, it is helpful to have automated processes that prevent publishing if there are open issues, yet also allow a means to document waived issues for a specific release of the IP. This methodology allows the mix and match of different versions of the same IP in different blocks, without having to respin all blocks to use the newest version.
Use an assembly methodology to capture IP dependencies in a design.
Use structured techniques to define assembly relationships between various IP and hierarchical IP sub-modules. Configuring these assembly relationships in advance allows for accurate, real-time tracking and reporting of the where, what and who of each IP version as it is used across the enterprise.
Defining assembly relationships in advance ensures that every item in the assembled IP configuration is tracked in the design system from the point of creation or import.
A defined assembly approach is in contrast to manually creating after-the-fact linkages or a ‘bill of materials’ (BOM). Since the BOM and associated records are typically not created until the end of the project, early visibility into project dependencies are lost.
Finally, using a defined configuration approach enables the ability to deliver issue or bug roll up reports in real time for the assembled design without having to copy the open issue report into each chip project. The heavy lifting can be achieved automatically using an assembly map rather than scripting and maintaining a complex methodology or reverse tracking through a static BOM.
III. Use Branching Instead of Copying
While creating new IP derivatives, use virtual referencing techniques instead of copying the IP
When creating a new version of an existing IP to meet new requirements, clone the IP to create virtual copies through pointers, so that each IP version can be separately and independently tracked. This practice replaces creating physical copies of different IP versions in multiple repositories, leading to unrecognized and orphan copies whose usage and heritage is unknown.
Maintaining the relationships between the original IP and its derivative versions allows for the efficient management and propagation of IP updates in both directions – parent to child and child to parent – depending on the policy.
Advanced branching with history tracking allows top level assembly teams to work with stable or released versions of each IP module while the design teams continue to work on the IP and chip development. By avoiding data duplication, branching also minimizes storage space in the repository.
Use private staging branches to manage IP block derivatives within the same design
Encourage designers and teams to use staging branches for development on their individual IP modules, and then merge their changes once their tasks are completed.
When using different versions of the same IP module multiple times in the same design, it is best to create re-named branches for each IP version to ensure accurate tracking, and to avoid name space collisions. The renamed branches still carry the original history since they are virtual projections rather than physical clones.
IV. Developing Quality IP for Reuse
Establish the practice of continuous integration for digital IP
It is a best practice to merge new or changed IP code into the IP repository with sufficient frequency that developers collaborating on the design or IP can correct errors before they propagate to other user workspaces. The designer’s changes should be verified and then submitted as a single commit operation using a repository that supports atomic change list creation, and it should be easy for all team members to view the latest deliverables and changes with confidence.
Continuous integration enables ongoing team member communication, reduces the number of conflicts, and accelerates resolution. In contrast, delayed or only periodically-scheduled check-ins can make it more difficult to resolve development conflicts.
Set up and utilize a requirements-driven flow during IP development
It is important to have a consistent set of requirements for IP to be promoted to new milestones.
Encapsulate all relevant property data associated with each IP element into the IP repository, such as design data, bug status, assertions, constraints, timing goal status, margins, power consumption, electrical data, regression results, and documentation.
As the IP development and verification process progresses, members of the design team involved with the IP can mark or flag its lifecycle status, based on rules or metrics associated with an IP property list. Quality or verification metrics can also be imported or linked from third party tools. In combination, these steps allow managers to measure progress against specific milestones such that certain property groups go from “incomplete” to “in progress” to “pass”.
Optimize security access for IP blocks
It is important to put security measures in place to control user action and for file access control for the IP block to protect the IP data and restrict who can use certain blocks. The security granularity can range from chip level to IP block level down to the individual file.
In setting up the security structure, the organization’s security needs must be balanced with the development restrictions and overhead associated with maintaining complex security policies. One practical approach is to set general policies using a fairly high granularity, then modify and tighten the measures for specific situations.
Conclusion
By establishing and deploying best practices for IP creation, reuse, and management, organizations can improve leverage of their company’s development assets across the globe.
Today’s designs have complex interdependencies to navigate, across the original IP, its versions, and even the individual hierarchical sub-modules for larger IP blocks. For example, it is critical to enable issue or bug status visibility and tracing between the original IP and all its versions.
The design practices discussed above can form the preliminary basis for a company’s IP reuse and design quality strategy; they can be further adapted and extended to match the needs of individual organizations. Dramatically reducing the engineering time spent integrating internal and third-party IP into the design flow and minimizing the time to achieve confident verification of the IP in the context of the entire SoC, IC, and FPGA design, will enable broad compliance by worldwide design and verification teams.
About IC Manage IP Central
IC Manage IP Central semiconductor IP management system pulls together all of a company’s IP into a searchable IP catalog for every design team to access, scaling to 100M+ IP objects. Engineers search for the optimal IP for their design using a Google-like user interface and powerful IP catalog filters, then view an automatically generated datasheet. IP Central supports all commercial design management systems and Git compatible systems.
Alex Tumanov, PhD, Director, IC Manage
Alex is director of applications engineering at IC Manage, where he has supported IC Manage’s customers in structuring and implementing their IP and design management systems. Prior to IC Manage, Alex worked as management consultant at McKinsey and Company. Alex was also a researcher at Rice University and Stanford University, where he developed an object-oriented data acquisition software system to detect, simulate, and analyze billions of interactions, built a particle detector processor using programmable logic Xilinx chips, and developed modules to analyze billions of interactions. Alex received his M.S. and Ph.D. degrees from Princeton University.