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."