Twenty years ago the electronics industry became interested in the
notion of formalizing re-use through third-party IP. It has turned out
to be harder than anyone imagined.
In 1996, the Virtual Socket Interface Alliance (
VSIA)
was formed to standardize the development, distribution and licensing
of IP. Soon afterward, companies with a couple of people in a garage put
up their IP developer shingle to enter the gold rush. Quality suffered,
and the industry quickly developed a bad reputation. Additional effort
was soon placed on defining the set of expected deliverables that should
go along with an IP block. That set of deliverables continues to be a
moving target. Even today, the industry is poised for the next set of
requirements that potentially will define a new set of directions and
capabilities for the industry.
Few of the original IP developers remain. Most were consolidated into
a handful of large suppliers. One that is still in business is Digital
Core Design (DCD), based in Poland.
“We have been part of the IP market since 1999, so we remember the times when the
IP
market was created,” says Tomeq Cwienk, PR manager for DCD. “For us,
the design process was never about developing an IP block, selling it
and forgetting about it. Every single core we build was tailored to the
project needs.”
Since that initial effort, the IP industry has undergone a
fundamental change. “Twenty years ago when an IP block was purchased,
such as a USB block, the integrator understood the protocol themselves
and they just wanted IP for it,” notes Kevin Yee, product marketing
director for
Cadence. “Today when they buy IP they don’t know much about the protocol.”
This is a key change for IP, which increasingly looks like a black
box. But for this scheme to work, the vendor has to selectively expose
aspects of the IP so it can be properly used and integrated. “
SoC
design these days is less about design and more about integration,”
continues Yee. “Twenty years ago a PCI block was a good percentage of
that die, but today it is a very small part of the design. The number of
IP blocks used in a design is increasing exponentially. It used to be 1
or 2 blocks. Now it is possibly 50 or 60 blocks.”
With this change comes an associated migration of knowledge and a
change in the development schedules. IP frequently is developed in
parallel with the SoC rather than ahead of time. “There are two key
challenges that we constantly face,” says Prasad Subramaniam, vice
president of research and development and design technology for
eSilicon.
“There is schedule pressure because the IP is a prerequisite for the
chip to happen, and you have to make sure that they are of good quality.
You’re often building IP that is compliant to certain standards and
oftentimes these standards are evolving, or they are not so
straightforward to interpret because you’re reading a 500-page document
and you want to make sure you pick up all the nuances that are described
in the standard.”
Another major change is related to the size and complexity of the IP
blocks. “Just as the scope of the chips has changed, IP has moved up the
food chain as well,” says Yee. “Where we used to have a simple IP
protocol, it is now much more complex, more software around it.
Integrators need to understand different things about it.”
That means that the IP has to be developed differently. “You have to
build in a lot of flexibility into your IP,” adds Yee. “Otherwise you
are building a custom IP every time and that model doesn’t work. A lot
of companies that used to develop their own IPs have switched to
third-party IP. A lot of customers use multiple nodes and multiple
processes and that means that maintenance becomes more difficult.”
The deliverables expected for an IP block can vary a lot depending
upon several aspects of that block. The first distinction is whether the
block is a hard or soft core, and the second is if it whether it is
considered to be library IP, standard interface IP or star IP. (A more
detailed description for each of these can be found in the Knowledge
Centers (
Intellectual Property,
Hard IP,
Soft IP,
Digital IP).
IP developers have been integrating greater amounts of functionality
into a single block. Examples include complete audio or video
subsystems. That could help relieve SoC integrators from having to worry
about certain aspects of the design. “Today, there is a big requirement
for security and we see this from all angles – automotive,
Internet of Things etc.,” says Andrew Faulkner, senior director of product marketing for
Sidense. “Because of this we are adding more features that allow our
One Time Programmable
(OTP) memory to hook seamlessly into security systems and to co-operate
with various different security strategies. In addition, we are adding
capabilities such as saving secure keys and locking those keys while
minimizing or preventing side-channel attacks. It has gone from
providing a memory to adding system-level features.”
New deliverables
In order to make some of the IP blocks more black box, alternative ways
must be found to provide the information that is needed for SoC
integration, such as information about quality and the ways in which the
block can be used. “One big advancement has been in coverage,” says
Gabriel Chidolue, verification technologist for
Mentor Graphics.
“Integrators would like to see how the IP provider has verified what
they are delivering and that it meets the specification. Another
requirement is for ease of configuration and concepts such as
IP-XACT
have come a long way in helping IP consumers leverage IP in many
different contexts. It defines how you connect IP blocks together and
how to hook it up to a verification environment.”
There are multiple viewpoints as to what needs to be exposed.
“Another view that comes out of that is a machine understandable view of
all of the registers that are inside of the block,” adds
Drew Wingard, chief technology officer at
Sonics.
“There is technology that takes that and creates the databook version
of the chip. Just the register description of some chips can be more
than 3,000 pages long, so automating that can be a big deal.”
The newest enabler for exposing information about the power
capabilities of a block and its external needs comes with the latest
release of
IEEE 1801-2015, often called
UPF.
“With UPF 3.0 it becomes possible to add a power model deliverable,”
continues Wingard. “Now with any tool that understands UPF 3.0, you get
an unambiguous description of it that could be used to calculate how
much power could be consumed in different modes of operation.”
Navraj Nandra, senior director of marketing for IP in
Synopsys
adds more detailed aspects of it. “UPF is used to model retention,
isolation, power switching and power gating. UPF is the plan of record
for all our IP.”
It all comes down to providing the right information to enable the
SoC integrator to do their job more efficiently. “When you take a
concept such as power, they realize they understand the flow from a
functional point of view if everything is powered from the same supply,”
explains Chidolue. “However, if I start breaking things up into
multiple power domains, the system integrator need a little bit more
guidance about the internal functional behavior.”
There are many issues that need to be resolved. “The point here is
that the vendors must take responsibility for ensuring their IP works in
external environments, and this is hard to do,” asserts Dave Kelf, vice
president of marketing for
OneSpin Solutions.
“It is not enough to deliver an integration documentation that
describes the necessary integration steps. The vendor must provide a
complete environment that can be configured to operate in the foreign
territory of their customer’s design.”
Characterization
Several industries place additional demands on IP providers. “Recently,
IP consumers have become more concerned about IP reliability and ease of
integration into the ASIC,” says Vamshi Krishna, senior IP field
application engineer at
Open-Silicon.
“Because to this, there is a demand for additional deliverables such as
silicon characterization reports, certifications, evaluation boards
along with the standard deliverables.”
Characterization places additional pressures on the food chain. “Our
silicon has to be qualified in advance of the SoC doing their
integration,” says Sidense’s Faulkner. “That is not always possible
because it takes a similar amount of time to qualify the IP as it does
an IC. There are 1,000 or 2,000 hours of reliability testing. It has to
go to the fab. It has to be packaged and then tested. This can be quite
lengthy. We are finding that we have to work very closely with the
foundries. We have to create PDKs and
SPICE
models, and that means a high degree of risk because if we are
developing our solution at the same time as them, then this is a
conundrum that we have to find a way through.”
Depending upon the type of IP, characterization can become an even
bigger problem. “Generally, for hard IP we would like to have models at
various operating conditions, slow process, fast process, typical
process; low temperature, high temperature,” says Subramaniam. “For
certain types of IP, such as digital, the corners can be limited to
worst case condition, but for analog IP we would like to have many
corners.”
Growing software content
When you look at charts of development effort, it is not uncommon to see
software being defined as requiring more time and effort than hardware
for complex SoCs these days. But the increase in software content for IP
has been more limited. “Software refers to device drivers and possible
some application layers,” says Krishna. “The investment for this
software IP block is low and, in general, do not exceed the investment
on hardware.”
There are also not quite the same quality constraints for this
software. “You need to deliver drivers with your IP, so that there is a
reference,” says Larry Lapides, vice president of sales for
Imperas.
“But how can you keep up with having Linux, FreeRTOS, VxWorks, ThreadX
and so on. You can’t do them all, but you do need to have one or two
reference implementations.”
Part of the reason for the slow software growth is the nature of the
IP targets. “The software component right now is probably small, and
it’s unclear to me whether it will grow,” says Subramaniam. “This is
because if you’re trying to target a hardware IP block you probably want
to put more and more into the hardware to get the most out of it, and
therefore the software component of it should be small.”
Wingard agrees for most cases. “We don’t see the software content
exceeding hardware any time soon for most IP blocks. But in media, it
might be true today. Audio subsystems have to deal with a large number
of compression and decompression standards and things like echo
cancelation. These tend to be written in software. People who have done
well in this area probably have spent more on software than hardware. In
graphics, it is probably about there. In video, decoders and encoders
are sufficiently challenging hardware designs, so it is probably on the
edge there. The other place may be security. Hardware security could
include RSA, DES and all of the other crypto function. So they may be
close to having more software than hardware.”
But while the IP may not need large quantities of software, there is a
growing need to run software on a model of the complete SoC, and that
may mean additional models being requested. “While software may be a
significant component of the IP,” says Lapides, “what is more important
is having the
high-level models for integration verification and you also need the fast untimed models for software development.”
Additional models can be added to that list. “Some IP can impact the
performance of the design and thus the desire to deliver a performance
model of the IP,” says Wingard. “This may help the customer to make sure
that the collection of blocks has enough performance, when combined
together, with all of the other things that are all working together, to
share resources to such things as memory. Sometimes that performance
model is fairly simple and at other times it might looks like the
description of traffic associated with this block along with the time
domain view of it.”
One thing is blazingly clear. The IP market is a work in progress and
the demands placed on the industry are increasing all of the time. It
is no longer possible to develop a hardware block and expect it to be
adopted by the industry. The role of IP is to help and decrease the
workload on the SoC integrator and that requires a very large amount of
collateral be provided along with the functionality.
http://semiengineering.com/ip-requirements-changing/
