Essentially, three kinds of IP exist in an SoC design: IP that you buy from a third party; custom logic that needs to be generated out of functional necessity; and the "special sauce" IP that differentiates your SoC from whatever else is on the market. The latter element is the only design aspect with which you have leverage to provide value. Whatever time you spend on the other two elements is time lost to designing in value and differentiation.
So it's imperative that the third-party IP be of the highest possible quality and sourced from a trustworthy vendor. Most third-party IP is standards-based, such as USB, PCI, or serial-ATA interfaces. Generally, standards-based IP is becoming more complex, so SoC design teams stand to gain little in trying to become experts in IP of this nature.
But what does it take to create a good quality IP block? Certainly, it must be functionally correct from the start and thoroughly validated against the standard it implements. It should offer portability to support multiple applications. There should be a verification methodology in place to catch corner cases. And, there should be an established methodology for testing it in a system environment using verification IP for full-chip validation.
The early days of merchant IP saw some rather dicey deals on the table. "What we believe is that the IP industry suffered early on," says Guri Stark, vice president of marketing in Synopsys' Solutions Group. "A lot of people, the garage guys, were developing IP but didn't deploy everything needed to ensure quality. People got burned and had to buy again elsewhere. There was a period of time when people actually didn't buy IP because of that."
"A big bugbear for IP customers is when they have to do more work than they anticipated after the IP arrives," says Keith Clark, ARM's vice president of technical marketing. "So when they receive IP, is it fully validated? Then they'll save an enormous amount of effort, which is why they buy IP in the first place. To buy from a well-known supplier of quality IP is important to them. You have to have some confidence in what you're receiving. If it's a memory controller for SDRAM, it has to be just that. They want to be able to plug it in, configure it, and it works. They don't want to have to dig down into someone else's RTL to make it work properly."
For IP such as that marketed by ARM, which largely comprises highly complex processor cores, it's equally important that there be an established path to implementation. "You want some assurance that as the flow develops, they can implement a high-performance or low-power core," says Clark. "So a reference methodology must be in place. People want proof of an implementation flow for these complex pieces of IP."
Fortunately, the IP industry has matured since the days of the "garage guys." But many IP buyers won't soon forget those halcyon days. As a result, they often spend as much, if not more, time on validating their IP vendors than they do the specific cores they're looking to purchase or license.
What should you expect from a vendor of quality IP? Basically, you should look for the elements that will facilitate integration. You'll want to make sure you receive the RTL source code for the IP block, because when the SoC ends up with bugs, that source code will help you nail down those bugs. You'll need all of the tools you can get for debugging, including proper verification IP to create a system-level test environment.
You'll also want a user interface that can guide you through configuration of the IP. "For example, IP can be configured, or comes in different configurations, depending on whether it's hard or soft IP," says Kevin Walsh, director of product marketing in Synopsys's DesignWare group. In Walsh's example, the end-user application will dictate whether you need two or four physical layers (PHYs), or whether your memory size needs to be configured in a particular way.
There's also the assembly and test side to consider. Typically, IP is going to be integrated into an SoC. It needs to be assembled correctly into a system from a pin-level perspective, and then tested in context. Therefore, you need the bus-functional models to get a feel as to whether it will operate correctly.
Physical-interface issues are yet another consideration. "On the application side, you have to deal with the fact that you might be linking to a particular bus," says Walsh. "The bus might have its own characteristics. Pieces of IP will hang off the bus, and you must be cognizant of how they interface on that side. On the electrical or PHY (layer 1) side, you have the same issue in terms of how it links to the digital part of the system and then how it links to the I/O structure."
Reprints
