Know your IP provider
Every SOC builder's checklist should include some IP-provider selection criteria.
By Pallab Chatterjee, Contributing Technical Editor -- EDN, February 27, 2008
With the shortened time to market for consumer and industrial products and the rapid introduction of new process technologies through the foundry market, there is a rash of new IP (intellectual-property) companies offering substandard and misrepresented products. The trend was inevitable in a growing marketplace. However, the presence of weak IP companies impacts the viability of the properly engineered and supported IP companies.
Additionally, countless chips and end products will fail to work, have reliability issues, and be difficult to debug as a result of these substandard IP blocks.
The selection of the IP provider and the blocks and functions involved is not just a business issue. Although business aspects are always important, for IP modules built in less-than-130-nm processes, the validation of the IP and the infrastructure supporting it are key criteria. Just how important? Currently, one of the largest causes of SOC (system-on-chip) failures from foundry shuttle runs or prototype runs is the use of unqualified IP in the design.
|
Every SOC builder’s checklist should include some IP-provider selection criteria. First, does the company have legitimate licenses for the EDA tools it is providing kits for? Many companies are outsourcing major portions of the design to Eastern Europe, India, and China, where software piracy is very visible. Pirated software tends to lack the current patches or the metadata that make it compatible with current legitimate code and could result in noncorrectable problems in design-for-manufacturing and mask-data-preparation steps.
Second, does the company have a history of commercially manufacturing the IP or parts? A number of companies are promoting silicon-proven experience when the only actual silicon they have run has been government-funded or -subsidized test chips on Defense Department or university processes. In most cases, the IP that a company sends to a fab on an MPW (multiproject wafer) under a military contract is not releasable to others because of licensing issues. In these cases, the vendor claiming silicon-tested IP is actually sending modified, process-migrated, and untested IP to its commercial customers—only “validated” by these other, different designs.
Third, does the company’s engineering team have the experience and support level you need? The larger IP providers, such as ARM, Synopsys, and Mentor, all have standard documented application and design support for their IP that includes device and RTL integration, tool integration, application verification, physical implementation and verification, and test development. The smaller IP providers are sometimes staffed only by recent university graduates and a research support team that cannot support the IP in a context of an SOC, because they have little to no real chip-building or CAD-tool-flow experience.
Fourth, does the company have the designers of its IP in-house? One of the basic assumptions is that the IP provider you are dealing with actually created the block you are licensing. In reality, some IP companies are merely brokering blocks that contractors created, IP it acquired from other companies, or blocks that are process migrations from pirated IP libraries that are floating around the industry.
This repackaging is difficult to identify at the data level and requires finding an IP company that will identify the location of its design group and offer an avenue for the end licensee to reach this group to modify or integrate the IP block in its SOC design. In this context, in-house does not necessarily mean the same location; it is the norm in the current global design community for the development site to be separate from the point of sale. However, the designers should be accessible—not moonlighting engineers in import- or export-restricted countries.
Look for additional guidelines and physical-design keys in a future article.
Contact me at pallabc@siliconmap.net.
