SoCs: Supporting Socketization -> Ready, set, reuse: A socketization primer

Not all approaches to intellectual-property reuse can produce order-of-magnitude productivity improvements needed for SoC design. Many companies adopt the most common approach, source reuse, but this is often inadequate.

In source reuse, the register-transfer-level source to an intellectual-property (IP) block is a starting point, but does not represent the end product. Designers must still read, understand and modify the block so it can interact with the other sy stem components. Standard coding and documentation practices help, but the true benefits of reuse are lost when designers have to understand the block at a deep enough level to modify its system interface. Even worse, any modified block needs reverification, and verification represents 60 percent or more of the overall design effort.

A superior strategy, integration-driven re-use, is one that focuses on the needs of the IP integrator: the SoC designer who is the end user of the reusable, or "socketized" IP, also called a "virtual component." A truly socketized piece of IP will have two important features. First, it will have a thorough and standard set of data files set aside in an easily accessible place for engineers-the Web is ideal. Second, the IP must be designed in such a way that it can communicate with other blocks with which it is to be integrated.

Once a company adopts an integration-driven reuse strategy and builds its portfolio of socketized IP, then these virtual components will be ready for integration with other socketized components-plug-and-play digital, analog and software IP-in specific application environments. This style of design is analogous to the plug-and-play nature of a personal computer, in which components are independently developed for a well-defined platform, and system integrators source components from a variety of vendors and easily integrate them. The key to making this possible is a well-specified system architecture.

The same notion of a common system architecture holds true for the assembly of socketized virtual components. To date, the best definition of this type of IC system architecture is the integration platform. Integration platforms are SoC design environments created for specific product applications, such as digital cameras or cell phones. These platforms include both an architectural specification and a collection of prequalified and preverified virtual components prepared specifically to operate together in the platform. By using the pla tform, SoC designers can swiftly generate new system-chips or rapid prototypes for a given application area.

Architectural spec

The architectural specification for the integration platform is fairly straightforward and customized to optimize the design for the chosen application. It consists of the bus structure; power, clocking and test architecture; I/O configuration; substrate isolation design; and required IP. In addition, the system-level constraints for performance, power and area are accounted for, along with the SoC's embedded-software architecture. The socketized virtual components selected for integration within the system architecture of the integration platform need to be made ready for integration, a process commonly referred to as "collaring," in which certain common functions are added to each block.

Most critical is that each virtual component matches the on-chip communication mechanisms that have been chosen for the device. This can be accomplished by either na rrowing the standard buses used throughout engineering to a few choices, or by adopting one consistent bus, such as the Virtual Component Interface (VCI) standard put forth by the Virtual Socket Interface Alliance (VSIA). Third-party IP suppliers such as Phoenix Technology have begun using the VCI as a standard interface for new and existing IP cores, linking cores developed with a VCI interface together into a "silicon IP bus."

Adoption of integration-centric collaring methods then allows the use of hierarchical, bus-functional verification methods, which permit the chip architect to check communication between virtual components in the system without having to functionally simulate every IP block in the entire device at once.

Unfortunately for this new reuse paradigm, specialization has led companies to organize into divisions with separate design and development organizations, each with its own design style and IP portfolio. Getting each of these diverse groups to work together in a cultu re based on design reuse takes a skillful blend of engineering and corporate management.

Cadence has been perfecting a consulting service for those facing the challenge of creating company-wide IP reuse infrastructures. Although tailored to individual customers, there is commonality enough to provide lessons.

The first step is to provide a clear set of authoring and integration guidelines based on industry standards, such as those from VSIA, to promote consistency across the company. At the same time the authoring guidelines are institutionalized, a virtual-component repository must be established within the company to capture the new models. These repositories-set up to provide access, security and consistency for the virtual-component collection-contain vast amounts of data including usage history, reference implementations, RTL files, synthesis scripts, timing models, gate-level netlists, layout databases and testbenches.

Putting it all together is the final step. Cadence has been successful in adapting corporate intranets for use as virtual IP and data repositories, creating the third and final piece of the infrastructure needed to ignite widespread reuse.