SSOCs have changed ASIC development teams to ASIC integrator teams. An ASIC integrator team's prime responsibility is the verification of the SSOC to test for functionality and manufacturability, and to interface with the fabless supplier in order to take the SSOC ASIC to production. Traditional ASIC development teams — working at the gate level — now mostly develop IP or validate IP from a supplier. This means that new ASIC/IP development teams need to have a flexible design environment, and must be able to add IP from different vendors and test it even before the IP is purchased.

To ensure the decisions on IP selection and integrations are technically sound, ASIC/IP teams commonly designate an engineer dedicated to IP analysis and procurement issues. This engineer is someone with deep knowledge of ASIC design processes, who knows the issues from verification to siliconization. One responsibility of this person is to grade the IP, to get a good idea of its quality and reliability. For contract development and final negotiation, someone from procurement is essential to make sure that all terms and conditions are as expected.

The design cycles for SSOCs are the same as those of traditional SoC designs. However, ASIC part volumes have increased significantly as functions from multiple ASICs are integrated into SSOCs commonly targeted for multiple products. This makes first-time success, time-to-market, yield issues and design-for-yield and design-for-manufacturing extremely important goals. Thus, especially with the advent of 90-nanometer technology, utilizing siliconized IP becomes very important.

But all siliconized IP is not equal. Active monitoring of the IP providers throughout the IP's design cycle is a necessity. Since a design engagement usually starts at the verification stage, well before the IP is siliconized and tested, loopbacks are essential to make sure that siliconized IP functionality is the same as intended functionality. There is always the possibility that someone modified the functionality just slightly, thinking it wouldn't cause problems — an assumption that results in major functionality issues later on.

It is also important to fully validate IP, even if it has been siliconized and used in other applications. Earlier applications may not have exercised all the functions in the IP. It could happen that a new application may invoke an instruction or command that was not tested properly or was never used before.

Typically, there are five sources for obtaining IP: partner company, fabless-driven IP, vendor IP, internal IP design or outsourced IP design. SSOC designers may be using any combination of these on a particular design.

Generally, the easiest model to use, and the one with least overhead, is the partner company model. It involves a highly trusted relationship where exact road maps are passed between the companies. The partner then designs or obtains IP from its sources based on the customer road map. The partner company is responsible for making the IP work and delivering it to the SSOC design group.

This model works well if the SSOC design company and the partner supplier's design focuses match. However, one limitation is in cases when the partner company may not have the desired IP in its portfolio and, in fact, the IP may not be in the road map of its other customers. This generally creates resistance from the partner and demands for additional funds.