From The Outside In Making Third-Party IP Work in Semiconductor Design

More than 30 years after it first emerged as a technology, third-party intellectual property remains a significant source of delay and failure in semiconductor design. What's worse, as the cost of manufacturing rises, the impact of failing IP is growing.

IP procurement is fraught with pitfalls. Seduced by low up-front licensing charges or glossy features sets, inexperienced project teams often buy poor-quality or inappropriate IP, framing their project around the IP rather than selecting the right product for the application.

Time-consuming and costly IP verification is an accepted way of compensating for a faulty procurement process. While integrating IP is never foolproof, however, there are steps vendors and consumers can take to improve both product quality and the procurement process.

Although it is accepted industry practice for IP consumers to verify purchased IP on receipt, this approach is largely self-defeating, adding delays that the IP was meant to eliminate by speeding time-to-market. In many cases, a consumer will verify using test vectors supplied by the IP vendor, which simply consolidates any errors or presumptions already present.

This consumer verification process masks an uncomfortable truth — IP consumers have so little faith in their vendors that they willingly repeat work for which they have already paid. Individually, each consumer is taking sensible measures to protect the investment made, but collectively our industry is wasting millions of dollars attempting to raise the bridge by draining the river.

The real issue is how to improve product quality at the vendor level.

Designing IP is no easy task. Each function has to be "right first time" across a vast range of process technologies, line widths, CAD flows and integration environments. If software is involved, a core also has to consider real-time issues like interrupt response times, direct-memory accesses and bus data capacity. It's a wonder third-party IP ever works at all. Yet, many vendors fail to take steps that could make things much easier.

In developing IP, a set of coding guidelines for both software and hardware is essential. Whether an inverse signal is called "fred_" or "notfred" doesn't matter, but debugging code where the signal naming twists and turns between modules is a nightmare.

Inconsistency is one of the major causes of structural and procedural errors (see figure). Adopting rules such as a standard loading on all input and outputs, always having an "else" or default clause in loops or resynchronizing all signals on entry to a module, helps to ensure interoperability between blocks.

Configuration, not versions

Though most vendors version control the modules of their product, some still fail to use configuration control for their releases. With most IP changing more rapidly than the end product, the ability to exactly reproduce any given released version is essential. This is particularly true where modules are common to more than one product, or where patches are applied to some configurations.

Directory structures

IP directory structures are often designed to be convenient to the developer, rather than the verification engineer. However, the directory structure needs to sustain multiple views of the same function on multiple technologies, and encompass future revisions without wholesale changes. This can be done by separating technology-dependent and technology-independent views. Soft links and long paths should be avoided because they can cause issues with data compression. Even deliverable naming needs to be carefully considered. Call your deliverable "Main" or "Input," and you're guaranteed to clash when your IP merges with the rest of the product.

Self-checking testbenches are a powerful aid for consumers who buy IP because they lack a particular expertise. But they are also a frequent source of irresolvable error. They should always default to a fail unless they explicitly pass — some have been known to pass with no netlist compiled in — and they should be checked to ensure that any underlying assumptions are valid. A classic example here is the bus monitor that checks for conditions like frame overrun, but not that the data received is the same data sent out.

Probably the most difficult errors to debug are those caused by poor data hygiene. Design environments often have common set-up scripts, inherited variables and assumed data structures that may well be missing from a customer's integration environment. Data releases should always be built on a machine with no inherited setups, and then unpacked and verified on a further clean machine exactly as a customer might use it.

See related chart Inconsistency is one of the major causes of structural and procedural errors when developing IP. As such, a set of coding guidelines for both software and hardware is essential. Source: Zarlink Semiconductor

IP failure is not just limited to technology. Commercial or legal issues such as failure to consider the definition of derivative and fee-bearing products can easily mar even a successful IP integration ("That's not a free bug fix, it's a redesign and a new license fee.") Poorly defined deliverables can result in last-minute delays and costs when members of the layout team find they don't have all the views required; an inconsistent royalty model across a project can lead to complex and fluctuating charges that baffle finance and engineering alike. In each case, it is easy for the consumer to blame the supplier and "poor IP" for delays that sit entirely outside of the integration process.

It is also a mistake to assume that all answers to IP quality lie only with the supplier. Customers often make assumptions about IP based on their usual working practices, forgetting that the supplier may have different defaults — and then blame the supplier for the consequences. For example, are your default process layers the same as your supplier's?

IP procurement is a specialist subject best handled by a dedicated team of engineering, legal and purchasing staff that can build a body of experience and an appreciation of one another's needs. Your purchasing function can learn that the cost of supporting poor IP is often higher than the license fee, and that "lowest price wins" is not necessarily the best strategy. Your engineering team can learn that legal review of the contract agreement is one area where accuracy can be more important than schedule. License agreements may seem like dry legal issues, but their impact can be enormous. Your legal team should also understand the engineering deliverables involved.

Too often, one major asset for the development team is overlooked: the IP supplier itself. Once the tendering process is over, bring your supplier in "from the cold" as a partner in the design process. Giving your supplier detailed insight into your design can avoid the misunderstandings and assumptions that lead to errors, and save critical time if bug resolution is required. Also involve your supplier in your post-development reviews and audits. They can provide valuable feedback to both design team and supplier, improving both your product — and your supplier's — next time around.

Steve Deeley (steve.deeley@zarlink.com) is director of intellectual property with Zarlink Semiconductor Inc. (Ottawa).