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."
Mixed-signal IP presents its own set of challenges. Many fabless-semiconductor vendors are moving toward fast serial interconnects, such as from PCI to PCI Express, to take advantage of the latest standards. But getting the same throughput on a single serial line, which was possible on multiple parallel lines, requires use of a serializer/deserializer (SERDES) technology.
"SERDES technology means you're now embedding a mixed-signal piece into the IP," says Navraj Nandra, director of product marketing for mixed-signal IP at Synopsys. "This is typically circuitry that does clock and signal recovery with the data. We can develop nice mixed-signal IP to do this function, but generally it goes into a large digital chip. At this point, most SoC integrators are not knowledgeable of, or sensitive to, the analog issues. As a mixed-signal IP provider, we need to be cognizant of that and to provide deliverables, models, and views to make it easier for the integrator."
Mixed-signal IP of this nature often is provided as a hard macro in GDSII format, but that's not sufficient, says Nandra. "You need to provide timing files, Liberty files, and .lef models for floorplanning," says Nandra. "You need to show solid documentation to help the customer place mixed-signal IP in the right location on the chip, or else they'll pick up noise from digital gates that can impact the analog performance."
This creates special test issues for the IP provider. "To shoulder all of that as the mixed-signal IP unit inside Synopsys, we've had to go to compliance testing," says Nandra. "But that's not enough, either." Not knowing how a piece of mixed-signal IP will be used or in what context it will be integrated, it's incumbent on the IP provider to test it in worst-case conditions.
Synopsys builds such IP onto test chips with multiple noise structures that recreate a harsh, noisy environment. Those noise generators are then switched on and off, which drives nasty substrate currents into the analog portions of the IP and disturbs the power supply and the noise-sensitive nodes. Then the mixed-signal IP is recharacterized under these extreme conditions.
"In the case of, say, a PCI Express PHY, we look at things like jitter and bit-error rates to see if we still meet the performance we had in a quiet environment," says Nandra.