IP Requirements Changing

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/