By Ann Steffora Mutschler
Whether it is a smartphone, tablet, video game with home networking feature or any other digital device, each contains multiple subsystems with a mixture of IP blocks from either in-house development or licensed from third parties. Managing the subsystems, let alone the individual IP blocks and the interplay between all of them, is not getting any easier. In fact, with the move to smaller geometries, sensitivity to all things power and characterization for stacking techniques, complexity continues to explode.

For chipmakers, the most important thing to keep in mind with IP management is to have a product roadmap and IP that’s derived from that roadmap.

“You define the features that you want in your product in the future and then you derive the IPs,” said Alex Haggenmiller, director of central R&D at Lantiq, an SoC developer for next generation networks and the digital home. “Maybe this is scheduled for about three years and then we know which IPs are needed. This is the same for internal and external.”

Currently at the 65nm HP node, Lantiq plans to make the move to 40nm sometime next year. Haggenmiller assumes the engineering teams will be able to re-use much of the 65nm digital RTL IP. “In our 65nm products it depends also on the throughput requirements and the complexity. We use USB 2.0, but for the next generation of our architecture we will use USB 3.0 and of course then you have a different RTL. But for those products that have the same standard—USB 2.0—maybe we will use the same IP due to a consistency of software.”

When it comes to power, it depends. “If it is on RTL and is related only to implementation, then you can do it anyway. If you need to modify the architecture of an IP, then I think it’s pretty hard to modify the architecture of an IP because you lose the quality of the IP and risk functional correctness. This we try to avoid. Then it is better to choose another IP provider than to modify an IP because one additional advantage of re-using IPs where a vendor has several customers is the quality. If you are not an early adopter of an IP maybe you get a better quality than if you do it on your own,” he added.

Mike Gianfagna, vice president of marketing at Atrenta observed that the IP consumption vector is moving more toward soft or synthesizable IP. “Hard IP is still important but the complexity is demanding that a lot of IP is delivered in soft or synthesizable form because you need to retarget for different process technologies more easily, you need to change architectures slightly, you need to integrate more easily. And clearly all that is easier at the soft level than the hard level.”

He explained that this has created a very interesting problem because the completeness, robustness and integration risks associated with soft IP are a lot more insidious and a lot less obvious than they are with hard IP.

“With hard IP, you can run design rule checks, you can run DFM checks, you can put it on a cyber shuttle, you can see if it wiggles. You kind of know what you are getting. With soft IP you have the privilege of licensing this stuff and then going through the synthesis, place-and-route loop and saying, ‘Oh boy, this was weak from a power consumption point of view,’ or ‘This is pain in the neck to test,’ or ‘I can’t route this block because it has these ridiculously wide MUXs,’ or ‘the interconnect in this IP is a disaster’ and you find this out the hard way. We hear a lot of horror stories about that. At advanced nodes, the problems become worse because power consumption and routing congestion can bite you even more so its even more important to see those problems coming earlier,” Gianfagna said.

Integration, power consumption and routing congestion are some of the roadblocks that SoC development teams are running into today just to get their subsystems out the door.

Simon Butler, CEO of Methodics, noted that many SoC developers are running into the issue of releasing with confidence these hierarchical subsystems where there are so many components on them now. With so many interdependencies between the components and subsystems, when it comes to actually making a release of one of the IP components on the subsystem blocks, the regressions may have passed internally, “and the team involved for that particular deliverable may know exactly what is required of them. But what they don’t know is how the dependencies around them—the expectations on the other blocks around them in the subsystem—have changed. So they find that they spend a lot of time going back and forth beyond just making their block work according to spec, but making it work in the context of all this other stuff. It’s quite a chaotic environment.”

Some customers have described the situation as ‘paralysis,’ Butler said, and that they just can’t release. “It’s just really hard to make releases because there’s no convergence between everyone else’s requirements and yours. They’re tweaking things. You’re tweaking things. You think you’re tweaking things to get in line with them and vice versa, but there’s really never been a consistency-checking and context-checking environment that gives you that confidence that what you are releasing is going to work up the food chain.”

Part of the problem is that there are the engineers doing software, which is part of the IP within a block, while others are doing test. These are different skill sets, and there is no clear connection between any of them. “There’s no placeholder for everything,” Butler said. “Everything is kind of being shoe-horned in. What they are looking for is a way that basically gets them off the hook for having to watch all these moving parts and manually decide when an IP is ready. What they want is a system that lets them go off and focus on their individual deliverables, and as these things become ready, as they pass regressions and make releases, the system decides whether that subsystem is ready for promotion or not.”

With all of the chaos, this is taking a toll on the business. It becomes harder and harder to get designs out the door. Corners are cut, designs are done conservatively, and margin is added wherever possible.

Power issues
The power problem rears its head in a few ways in complex devices. “One is just the simple fact that because you’ve got so many more things happening in parallel, you need to be much more careful about the aggregate power of each block so you try and optimize each block by itself,” Atrenta’s Gianfagna said. Another thing that gives design engineers trouble is that because everything is controlled by software, they need to start thinking about how to define the power domains and what the metaphors are for ‘on’ and ‘off’ for the different blocks. Blocks need to be shut off in a coherent way and then brought back up when needed. A third issue that causes problems is the fact that with every new technology node, leakage gets worse.

“You can define your power domains but you really need a really good hardware-software interface to figure out if you’ve got it right,” Gianfagna said. “We hear from a lot of customers that they’ve developed a scenario and they really need a model that is fast enough to run some scenarios but accurate enough to reflect what’s really happening. I’ve decided I can shut down the browser when a call comes in but what does that really do? How does that really work? What’s the real power profile of that if I run real data, a real scenario through that? Customers want to do that. That’s a somewhat under-served market today. There are not a lot of good tools, there are not a lot of good flows, yet that interface of the software emulation with the hardware design world it is an absolute opportunity for growth in EDA.”

The marriage of the hardware architecture and the software emulation world for architectural analysis still requires work to get it right, but it could well be a big opportunity for better management of IP in complex systems.

By Ann Steffora Mutschler
The confounding ‘make versus buy’ decision is understandably muddled by design complexity. Millions of gates, thousands of blocks, dozens of cores, plus software, packaging, and worries about physical effects don’t make this decision any easier.

In some cases the process can be simplified by mandating that anything that doesn’t add differentiation really is an IP block, and as such, it should not be built in-house. The exceptions, of course, are large fabless semiconductor companies that have an internal IP group, and which can amortize the development costs across a large number of chips.

Alex Haggenmiller, director of central R&D at Lantiq, a developer of SoCs focused on next-generation networks and the digital home, said his company has a simple rule: “The one rule is everything that is standard and where you do not have to expect major changes, this we will license. USB, PCI, DDR—this is not worthwhile to do in-house because we don’t have many analog designers.”

Also, if the company does not have expertise for a particular IP it needs, and that available from a third party, it will be licensed, he said. “But if we see that we can differentiate on one or the other IP, and we have the know-how, then we will do it in-house. For example, a T PHY, a 10/000 or 1,000 Gbit Ethernet PHY, where you need to embed this and from a power perspective be very attractive, then we will do this in-house. The prerequisite of course is always that we have the know-how, because if you have to build up the know-how and then do an in-house development you lose too much time.”

For standard IP, Lantiq’s goal is to go 100% with external providers.

Depending on the user category, however, the reason behind the “make” decision can vary, said Kalar Rajendiran, senior director of marketing at eSilicon.

For a foundry, foundation IP such as basic standard cells, standard I/O, and memory-bit cells are core to their business. Second-tier foundries may decide to hire companies to build more than foundation IP for them because the third-party IP companies are busy developing IP based on top-tier foundries’ processes.

When it comes to semiconductor companies developing (n+1)-process-based products, because foundries are very tight-lipped about openly sharing technical information on their very leading edge processes, third-party IP companies are unable to develop IP for these processes early on. So these semiconductor companies work directly with the foundries to develop the required IP. Sometimes they hire third-party companies as contractors to develop IP for them. Because they are always staying at the very leading edge, they maintain an in-house IP development team, if not for developing the entire IP set, at least to manage and interface with the third-party IP company that is on contract.

Then, for companies developing products based on exotic-processes, Rajendiran noted that because there is not a large market for this kind of IP, it is difficult to convince a third-party IP company to develop this IP. So these companies will end up developing IP on their own or by hiring a contractor to develop it for them.

For all other users, buying from the broad third-party IP supplier base is what will make sense, he said. If some customization is required, the customer is better off negotiating an IP customization contract with an IP company or a value-chain producer. The difference is that with a value-chain producer, the customer shares the common goal of taking the IP into volume production as part of their ASIC or ASSP whereas with an IP company, which just agrees to customize the IP, the contractual responsibility typically ends when the IP is customized and the design database is delivered to the customer.

Particular market segments can make a difference too. In the mixed-signal arena, there is a significant move to outsource a lot of IP thanks to modern SoCs, which contain a high level of complexity in the interfaces, said Neil Hand, group marketing director for Cadence’s SoC Realization Group. “This means there are complex interfaces involving high-speed SerDes, analog front ends, and all kinds of mixed-signal IPs that are particularly sensitive to the design they are going in and require special skills. So then you ask, ‘Do I build out my own expertise to build this or just go buy the IP? When it doesn’t work, do I have the expertise to fix it?’ If I’ve got third-party IP, its the vendor’s responsibility to resolve the problem.”

Sonics’ Jack Browne agreed. “The make versus buy question around a microprocessor—MIPS, ARM, Tensilica or ARC—is really about the software and ecosystem and what you are trying to accomplish with it. The real make versus buy is what it costs to build your own ecosystem for a processor. Everybody needs software tool, compilers, debuggers and you can get a lot of that open source.”

With approximately 20% of designs today in the 100 million-gate range and above, interesting challenges are emerging for IP, EDA and software, observed Navraj Nandra, senior director of marketing for analog and mixed-signal IP at Synopsys. “From the IP side of it, customers are expecting ready-to-go blocks that are fully verified in the latest technologies. And for many customers, they’ve already gone through this make-versus-buy transition because they’ve realized in their design team in order to put together a 28nm, 100 million-gate chip it’s going to take a big design team comprised of design engineers, verification engineers and software engineers.”

Overdesign contributes to decision-making
It is safe to say that many – if not most – SoCs are overdesigned today. But what is the impact on the cost equation? Cadence’s Hand questions what the cost of overdesign is versus the cost impact of underdesign? “Right now, if you tried to design to the limit you have two impacts. First, if you get it wrong, you’ll miss the market and you’re no good anymore. Second, you may be limiting yourself in terms of how widely you can apply something.”

In that way, Hand says overdesign is necessarily a bad decision. “Overdesign may be the most cost-effective way of getting somewhere. Let’s say you need to get to a point as quickly as possible. If you’re not really worried much about power or squeezing every last drop out of the system, you can drop a much bigger processor in there, do a sloppy job on software, get to market sooner and maybe increase the cost of your device by a few pennies. I’m not saying people should do that, of course.”

Preferring to call ‘overdesign’ by a more user-friendly term, ‘redundancy,’ Synopsys’ Nandra explained that pressures leading to redundancy are the ability to make sure the design will work in different cases, along with the ever-daunting time to market.

“These chips are going into product lifecycles of a year at most, then the next generation comes out. Basically, they’ve got to work right off the bat. If you’ve got to go through another re-spin and fab cycle, you’re going to lose your market window. That’s where overdesign or redundancy comes in. What you’re trying to do is cover your bases. If the memory compiler doesn’t quite yield in this new technology, we’ll put lots of redundant bit cells in there to make sure that at least we’ll get this block to work in production. What you’ve done is halved your risk, but you may have increased the area. The overdesign happens to solve some of these challenges of yield, but you don’t always get an optimum design in terms of area or power consumption.”

Here is where the chip planning, IP management and architectural analysis tools promise to give greater visibility into what is being built, improve predictability, and give the cost perspective up front.

For now, the make versus buy decision is no easier than it has been in the past due to complexity. But pulling in data from early in the tradeoff stage can help not only with architectural decisions but shining light on the cost equation, as well.

By Ed Sperling
System-Level Design sat down to discuss hardware and software priorities with Neil Hand, group director for marketing for Cadence’s SoC realization; Johannes Stahl, director of product marketing for system-level solutions at Synopsys; Prasad Subramaniam, vice president of design technology at eSilicon; and Bernard Murphy, CTO at Atrenta. What follows are excerpts of that conversation

SLD: Who makes the money as the value shifts inside of SoCs and devices?
Subramaniam: The system makers still make the money. They are offering value with the software and the whole system.
Stahl: It’s the companies that have unique control points.
Murphy: The guy making the hardware is not necessarily making the money, whereas Google is.
Hand: It depends how you define the system. With Android it may be the ecosystem. But in other industries the system maker may be the ecosystem, like in automotive or medical. People always thought the system maker is whoever makes the hardware, but it’s changing to whatever the ecosystem has enabled.
Subramaniam: The system maker is not just delivering the hardware. It’s delivering the entire solution.
Hand: But one of the changes is that the system maker may not deliver the hardware at all. They may be delivering hardware from other people.
Subramaniam: Yes, that’s possible now.
Hand: Is HTC delivering the hardware, or are they just an enabler for Verizon’s ecosystem?
Subramaniam: And if you look at Apple, they design the products, but those products are made by someone else. But Apple does provide the hardware, the software and all the content. They’re not creating the content, but they’re making it available to you. They’ve created the entire system for their end application.
Hand: It’s the same with Sony. They pioneered that idea after Betamax when they started buying the studios and the content providers. Apple has out-executed them.
Murphy: No one has been able to reproduce the Apple model.

SLD: In the chip world, who makes the money?
Hand: Whoever can deliver differentiation. If you deliver differentiation, people will pay for it. If it becomes a ‘me too,’ no one wins.
Subramaniam: It’s differentiation plus value. Conventional wisdom is that as you go up the value chain there’s more opportunity to create value and you will create more profits.
Hand: We believe there’s a limit of what you can achieve through pure automation of designs, though, which is where IP fits in. For other people it will be the software. Different companies will take different tacks to deliver that value to the end user.
Stahl: It will be companies with a structural advantage, such as TSMC or ARM. They have the scale and deployment in the industry.

SLD: The other side of this is where EDA companies make their investments.
Stahl: That’s why we invest in IP. Virtual prototyping will pay off over time, too. The structural advantage of having enough is very important.
Hand: We’ve invested in IP and the system development suites. We believe the investment is in the SoC and the system, in addition to our traditional business.
Murphy: IP won’t be just hardware. It will also include software.

SLD: So where will the biggest breaking points be in the future?
Subramaniam: Technology is still evolutionary. I don’t expect any revolutionary tools to come out. Maybe with 3D ICs there will be something new required, but even 3D ICs are evolutionary. Most problems there can be addressed using existing tools with some additions. Maybe at some point when Moore’s Law is gone and we’ve come up with a new kind of transistor then we’ll have a new industry for EDA and design. Until then, things will be more or less similar.
Stahl: We’re seeing semiconductor makers growing their software development at a phenomenal pace. The way many companies are attacking the problem is more bodies on the problem, but the more intelligent companies are asking whether you can afford to do software the same way over and over. Do you need to be more methodical and what are the connection points between normal software engineering and the platform? How much can you systematically verify and test? There’s a lot of realization among managers, who now also have to run software teams, that they can apply the lessons of EDA to this business. There’s the biggest potential, but it will be an evolutionary change. We won’t be able to brainwash the software engineers to use a different language.
Subramaniam: The one thing that can happen in software is that with silicon so cheap you can have lots of little processors doing specialized tasks. One of the challenges of software is how to take advantage of all of these little machines in silicon and get the best productivity out of the tools. There is an opportunity for multicore software development where you start with a high-level language and break it down into millions of little problems. This is not an easy problem. People have been trying to do this for 25 to 30 years.
Stahl: People need to be much more conscious of how to validate this heterogeneous system to make sure it really runs, but at the end of the day you have to do more brute force simulation. We cannot afford to wait to start developing software until silicon is there.
Hand: If you look at base stations, they broke those designs into lots of small DSPs, each doing one part of the design chain. That has a parallel today. As the software becomes more and more complicated, it changes from IP to a subsystem that is validated and trusted. It’s tested, good and encapsulated. People don’t violate the rules that are in there. That’s where you get much closer collaboration between hardware and software.
Stahl: Some companies like Ericsson have a discipline of developing large-scale hardware and software. That has to be transferred to the semiconductor large software stacks. It’s a discipline.
Murphy: It’s a little bit of, ‘To a hammer everything looks like a nail.’ If there was a better understanding of the system problem they would realize that turning all the design knobs isn’t as easy as it looks.
Hand: Years ago it used to be easier to fix something in hardware than in software. A semiconductor company doesn’t necessarily look at those tradeoffs today.
Murphy: They know what they can fix. The universe of possible fixes is bounded.

SLD: Using software for specific processors or functions seems to be a radical shift.
Subramaniam: The advantage of having hundreds of processors on a chip may be a little bit wasteful, but it actually saves you power. Rather than one 1GHz processor running at 50% activity you can have hundreds of 100 MHz processors running at 2% activity and burning very little power.
Stahl: I don’t see any of these homogeneous processors in the consumer space. It’s one processor at a time optimized and running all the software. Incremental design tactics won’t allow for that kind of radical shift.
Hand: I don’t think it’s radical. It can happen at an evolutionary scale. Today you have multiple processors handling the baseband and the touchscreen. They do have isolated functions with their own function.
Stahl: But it’s still very heterogeneous.
Murphy: And with the high-end smart phone processors, you design in everything and you either take stuff out or you disable it.
Hand: It’s a tough call even where you have hundreds of distributed processors. How flexible will it be if you can’t break down an application into a bunch of little pieces?
Murphy: Another problem that comes up is in verifying subsystems. You can build a subsystem and test it, but you’re targeting a market window that is short. I haven’t seen many examples of subsystems that are significantly re-used from generation to generation. You’re back to verifying these huge systems.

By Ed Sperling
System-Level Design sat down with Kathy Werner, IP strategy and business manager inside of Freescale’s Design Technology Organization, to discuss tagging of soft IP. What follows are excerpts of that conversation.

SLD: How new is the concept of IP tagging?
Werner: IP tagging has been around for a long time. VSI Alliance was one of the first standards organizations that looked at IP tagging. It started out as the Virtual Socket Interface Alliance. They had a number of initiatives they were addressing. One was the on-chip bus specification. They also did the quality IP specification, they started the encryption standard, looked at IP transfer, defined the list for standard deliverables. The goal was to facilitate IP re-use between design groups, between companies and between vendors and customers. Tagging was one of those efforts, and it really was intended to provide some security around IP. There were two aspects to this. One was a soft IP spec and the other was a hard IP spec.

SLD: How far did it get?
Werner: The hard IP spec is in wide use. TSMC was an early adopter. It really is a text string put on the text layer of a GDS. Any back-end tool that can read the GDS can read the back-end field and determine where this IP came from.

SLD: While IP may adhere to standards, a lot of it isn’t characterized effectively. Will this help?
Werner: Not initially. The tagging tries to define the ownership and the origin. There are additional fields for the size and there are user-defined fields where you can put the process. It’s not going to be complete, but for the hard IP this information travels with it. There isn’t anything about interference or cross-coupling.

SLD: How about for the soft tagging?
Werner: The intent was to track the IP that went through the design flow. You have RTL here. It went through synthesis on this date, for example, using this company’s tool. That really depended on all the EDA tools that touched the tag. If one tool didn’t do that you lost all your tags, so needless to say soft tagging never got going. That left a huge gap. Whenever a vendor delivers IP you lose all control of it. It can be copied and used someplace else and you don’t know. Being able to tie it to the source, to where it’s used, and to the royalties constitute a first step.

SLD: So no matter where IP comes from or where it gets used—whether it’s in the United States or China or Taiwan or some other country—at least we know where it’s from, right?
Werner: Yes, right up front.

SLD: But what’s missing is still other information, such as how it reacts to physical effects. Will that be provided in the future?
Werner: That gets into the hard-tagging spec, and should we revisit issues that are more relevant now than they were five to eight years ago? Probably, but it’s not being considered right now.

SLD: Who would drive that effort?
Werner: When the VSI Alliance folded, it donated its tagging specs to Accellera. They are in the public domain and they’re freely available to anyone who wants to use them. But with any standard effort, it will be the pull of the users.

SLD: How about IP-XACT? Is that comprehending the tagging?
Werner: We’re proposing that now. Nothing has been finalized.

SLD: What is the next big challenge in tagging?
Werner: From my viewpoint, the big issue is figuring out the tagging for soft IP. That’s what we’re trying to drive forward. It’s becoming a bigger issue and a lot of people have a lot of different views on this. For example, the FPGA companies are moving more and more into IP. Historically, they have given away IP to sell silicon. But the IP is getting so complex and expensive that it’s no longer a sustainable model. Now they need to know who’s using their IP so they can collect royalties.

SLD: Who’s backing this move?
Werner: Any vendor with an IP royalty model should be all over this.

SLD: How do the tags work?
Werner: Here’s one implementation: If you end up with text on GDS, it supports and enables honest users. It can be deleted, so you’re assuming people want to do the right thing. But if the tag is in the GDS, you can still get the information about ownership.

SLD: Is that robust enough?
Werner: That’s something we’ve been discussing. Should the tag be a watermark or should it be encrypted? We’re still looking for industry input on that.

SLD: Doesn’t it also protect the company that uses the IP from liability issues?
Werner: Yes, absolutely. And having some way of identifying the version of IP helps with bugs. You know which products are going to be affected. If you tape out version 1.0 and you have a derivative design that uses a later version of IP, you know which version is going to be affected.

SLD: Where are we now with this effort?
Werner: Accellera has been working on this for several months. An IP provider is going to have a different view than a semiconductor company like Freescale, which is going to have a different view than an FPGA vendor. We’re trying to get all these inputs to really scope out what needs to be done.

SLD: Why is Freescale involved?
Werner: We have been using the hard-tagging specs internally. We tag our libraries. But like any company we’re using more and more third-party IP. We want to make sure we’re legally compliant and have a data-driven approach to tracking that IP. Now there are spreadsheets and bills of materials, but anything with that much human intervention is prone to errors.

By Ed Sperling
With the amount of IP in SoC designs now hitting an estimated 70% to 90%, companies are scrambling to figure out a way to more consistently integrate that IP and to test that it will work as expected.

This is easier said than done, however, for a number of reasons:

1. There are numerous types of IP, ranging from I/O to logic and memory.
2. Not all IP is of equal quality.
3. Not all IP is used the way it was intended, or even consistently from one chip to the next.
4. Re-use within companies of their own IP frequently doesn’t conform to any standards.

So far, standards efforts in this area have been relatively modest. The SPIRIT consortium introduced IP-XACT to document IP and provide tools to access meta data, but that’s a far cry from a consistent methodology for integrating IP.

“In the old days all you had to do was characterize the IP,” said Jean-Marie Brunet, director of product marketing for model-based DFM and place-and-route integration at Mentor Graphics. “Now you try to create context with lithography and stress. You need to instantiate the IP in corner cases and the surrounding context. It’s random at this point, which means there is not a lot of predictability.”

That becomes even more critical at future nodes. At 20nm, for example, double patterning makes IP even harder to characterize and re-use. And fill at 28nm and 20nm can have an effect on density, which in turn affects min/max values. That also has an effect on IP.

“These are problems for the IP creator and the SoC integrator,” said Brunet. “You almost need a ring around every IP, but that blows the area. And double patterning is not done the same way from the IDM to the foundry, so you need a situational solution for each version.”

There also has to be a better way of defining what is good IP. A piece of IP that functions perfectly in one design may not function the same way in all designs because of issues ranging from noise—a problem that has been particularly acute for RF and some analog IP—to electromagnetic interference, physical stress and exactly how the IP is used.

“The big issues we’ve found is that different IP is being delivered in different states of readiness and quality with a different understanding of what it means to actually be IP,” said Neil Hand, group director for product marketing in Cadence’s new business group. “Today when you deliver IP you do some amount of generalized skeleton code, floor planning and I/O placement. But there is a lack of consistency in this.”

He noted that at 70% to 90% IP content in SoCs, any amount of overhead in making IP come together and work properly is unacceptable. “What’s needed is to unify the delivery of IP. After that, everything falls into place.”

Verifying quality
Behind that delivery is a need to have more consistent quality, which means the IP can be used under a variety of circumstances and still work as planned.

“Integration is an issue, but the bigger problem from a customer standpoint is to figure out which IP is good and which IP is not good,” said Gideon Intrater, vice president of marketing and applications at MIPS. “The risk is huge. What you’re looking for is IP that is isolated enough from the rest of the system. With sensitive analog or RF you still want to be able to drop it into the chip and have enough rules in place for using that IP. But you also have to consider that the more aggressive the process technology, the more IP you put in a chip and the more power and power rails, which are noise—all of that is going to impact how the IP behaves.”

IP certainly needs to be tested once it’s in a design, but it also needs to be tested and properly characterized well before that. Large IP vendors typically build reference designs using worst-case scenarios to test the limits of their products. With Synopsys’ DDR3 and DDR4, for example, the company has built the memory into what Navraj Nandra, Synopsys’ senior director of marketing for DesignWare analog and MSIP IP, calls “cheap and nasty packages.”

“What we don’t know is how the customer will implement IP inside an SoC,” Nandra said. “But there is a lot you can do to mitigate potential issues if you know what they are.”

The largest merchant IP vendors—ARM, Synopsys and MIPS—all use this method of testing all possible configurations and developing data sheets for problems that can erupt along the way. Jack Browne, senior vice president of sales and marketing at Sonics and a former executive at MIPS, said that once an IP company has more than 20 customers and has developed more than 5 to 10 products, it has figured out the quality issues. “As customers do their second and third transaction with an IP company, they’ve got the quality issues worked out on their side, too.”

Internally developed IP and most custom-built analog IP rarely have that kind of information available, however. And as companies attempt to move their existing IP to the next process node, or when they attempt to use the old methods of putting in IP blocks as it becomes available, problems can erupt that no one ever considered.

“The interconnect ends up being the sticky point in chips,” said Kurt Shuler, director of marketing at Arteris. “If you use Wide I/O to memory on a mobile phone you get better bandwidth, but the question that has to be answered is where you put everything. You need to floor plan all the IP blocks earlier. And often the people doing the interconnect and the people doing the IP don’t understand the IP inputs as well as they need to.”

Future directions
The question now is just how much IP will be sold pre-integrated as subsystems or even as complete die for use in 3D stacking.

“The methodologies for putting subsystems together and SoCs together are not all that different,” said Ajoy Bose, chairman and CEO of Atrenta. “There is some methodology in place today, even if it involves homegrown solutions and scripts. What’s more of a challenge is trying to fit your own ideas into an existing situation.”

That’s been the problem with commercial IP from the start. It’s possible to write IP specifically for an SoC design that is smaller in area, uses lower power and has no proximity issues because it is developed for a specific design. But getting the design out the door on time using internally developed IP is impossible.

“Right now you create IP, sign off on that IP, you import the IP, validate it in an SoC and hand it off to implementation,” said Bose. “This is similar to what the enterprise software industry was doing with analysis, human resources and inventory. Then enterprise applications were created to connect all the software together into a single integrated package. We’re seeing the same trend in IP with the subsystem becoming more popular. It helps that the semiconductor companies are aligning themselves vertically, too. With each vertical they know the pieces that are used.”

In many cases this job will fall to value-chain producers such as eSilicon, Open-Silicon and Global Unichip, which are among the largest commercial IP integrators and testers. Kalar Rajendiran, eSilicon’s senior director of marketing, said his company has developed a four-step methodology for selecting, managing, integrating and testing IP. What’s important in this process is an understanding of how that IP performs in chips over time and for multiple customers.

“The really heavy lifting is in selecting the IP,” he said. “Choosing IP suppliers is very important. Once we qualify the IP we document it in a database with version control. We also audit the supplier’s methodology—what they use to develop and verify that IP—and we do a site visit to the IP supplier to meet with them. We’ve been doing this for 10 years. We have proof points about why not to go with certain supplier. In some cases it’s because they cause problem for other industry players.”

At this point those kinds of capabilities are a competitive advantage and problems on the integration and testing of IP loom large for many companies. That may change as the IP industry continues to consolidate and tools become available, but at that point the problem also may be less about integration than on customization of IP for specific needs.

System-Level Design sat down to talk about what makes a company successful in the IP market with John Koeter, vice president of marketing for IP and systems at Synopsys; Art Swift, vice president of marketing and business development at MIPS Technologies; Vishal Kapoor, vice president of product management for SoC realization at Cadence; and Charlie Cheng, CEO of Kilopass. What follows are excerpts of that discussion.

SLD: What happens to IP when we move into 3D stacking?
Koeter: The answer depends on whether it changes the chip architecture. What we’re seeing now is it isn’t changing the architecture. What most people are doing is taking an active processor and stacking DRAM on top of it. That’s not changing the fundamental way they’ve chosen to partition their chip. So that hasn’t changed our business yet. But being the leader in interfaces, clearly we’re looking at that all the time. There’s a camp in the mobile area that’s pushing wide I/O for DRAM, which is enabled by 3D packaging.
Kapoor: When you get into the implementation you have to worry about that. I agree that concept has been around for awhile. When you start thinking about the differences in geometries, any time you change geometries you have to take physical effects into consideration.
Cheng: I disagree. We license to three out of the top five DRAM companies. DRAM is a prime candidate for stacking. Somewhere in the stack there’s a dedicated chip that does repair. When there’s a repair it keeps adding to the defect map. From wider bus to the way a stack is managed, there will be a lot of changes in the architecture and requirements. Where there is a problem there will be a solution. The question is whether it will be differentiated enough so that you can go to a customer and get paid for that.
Koeter: There’s potential that isn’t being actualized right now. If there was a fundamental change in the architecture that would be a problem. If there was a fundamental difference in the partitioning with the digital function being at 28nm or 22nm and there is a 130nm chip with analog that would be a challenge, too, but we’re not seeing that right now.
Cheng: It’s not going to happen in 2012 because there are some problems that haven’t been solved yet. When consumers see some great results from stacking is when you’ll see a shift.
Swift: If our customers are putting 200 cores, sometimes homogeneous and sometimes heterogeneous, on a chip, that gets magnified with a 3D approach. That will have to impact the business of EDA tools.
Kapoor: That’s true, but the question wasn’t around EDA tooling. From an EDA perspective that will certainly be the case.

SLD: Are the processors cores going to be split up across chips, or will they all be in one place?
Swift: In a heterogeneous environment there could be lots of different processors doing different things. You might have a cluster of processors doing the data processing, but you can still have lots of ancillary processors. They won’t be necessarily be clustered together. Analog functions will be clustered, as well.
Koeter: The processor, the interconnects and the DRAM interfaces are usually—but not always—the determining factors in the performance of the chip. Will the processor and the interconnects move off chip? I don’t see that happening. Could the DRAM interface change to a very wide interface? I can absolutely see that happening through the apps processor and memory.

SLD: That’s a through-silicon via approach?
Koeter: Yes.

SLD: There is a wide variety of IP in use, and some of it is still developed internally by chipmakers. Where is it toughest for IP vendors to break into the homegrown IP market?
Cheng: There are two areas that are hard to outsource. One is tied to the process technology itself. The recipe is hard to get, so it’s hard to complement. It’s also not very profitable for outside companies because you have to customize for every process technology. The second area is IP that has a lot of proprietary applications, such as a proprietary audio transceiver that is different from Bluetooth, using radio waves and CD-quality. You couldn’t license that widely because the greater industry requires compatibility. To the one or two companies that really need it, they’re better off doing it themselves.
Kapoor: And that isn’t IP anymore. By the classical definition it’s still intellectual property but it wouldn’t translate into a merchant IP model.
Cheng: That’s correct. The second one is where the highest monetary value is. The MIPS S-1 registration document is a great example. It got $5 for every game console sold and $2 for every cartridge sold for the Nintendo graphics engine. Each one of us would kill to license IP where the customers pay us that amount of money.
Koeter: There’s a different level of maturity in outsourcing depending on the function. Microprocessors are the most widely outsourced. Interfaces are the next most common. And in our business we’re seeing 17 of the top 20 semiconductor companies in the world outsourcing interfaces to us. Memory is increasingly outsourced, as well. But when you look at analog IP, RF and security—those things are not being outsourced. They’re much earlier in the outsourcing phase.
Kapoor: If you go back to processors, interfaces, and memory and storage being the three big broad areas of oursourcing, outside of that it’s highly specialized. If I want a PLL I’m going to have to go to a services house. They may have some repeatable processes internally, but it’s custom-built for me. There are also things that will differentiate my chip. That’s my secret sauce. But the model will go to more and more outsourcing and standards-based stuff because the value is in the software.

By Ed Sperling
A growing reliance on third-party IP is beginning to expand well beyond just IP blocks and into full subsystems, opening significant growth opportunities for companies competing in this market as well as enormous business and technical challenges.

The IP market is ripe for this kind of convergence. Complexity at advanced process nodes coupled with time-to-market demands has elevated third-party IP from an emergency fix inside most designs to a necessity. By some reports IP now accounts for up to 90% of an SoC design. What’s changing is that IP increasingly is being integrated with other IP, software and even hard IP, so it can be plugged into an SoC with far fewer integration problems associated with single IP blocks.

“What’s driving this are the tablet and smart phone markets,” said Prasad Subramaniam, vice president of design technology at eSilicon. “Those are the highest growth markets, and companies like ARM and MIPS are creating blocks around their cores to harden and pre-verify. We’re even seeing this happening with entire reference designs, which include those subsystems. In the past this was just a reference design. But there are a lot of OEMs—especially Asian companies—that don’t have the resources to do these designs from scratch, so they’re picking up the design and fixing whatever is necessary to get to market quickly.”

James Mac Hale, vice president of Asia operations at Sonics, had a similar view: “We’ve seen SoCs move from integrating cores to subsystems. The number of cores is going up, and so is the complexity and desire for re-use. The challenge is that once you combine all these subsystems, how do you design the overall system behavior. Each reacts differently on its own.”

Getting a handle on the changes in this market is no simple task, in part because this trend is just beginning to take shape and in part because of the breadth of what’s happening. Even defining IP can lead to arguments about what is and is not considered commercial intellectual property. Adding more pieces into the mix only confuses the definition.

Synopsys, for one, defines IP subsystems based upon function. That definition includes the integration of one or more pieces of IP with the software stack running on top of it, all of which is configured for a specific application. That could be an audio-based subsystem with an ARC processor, the necessary codecs, interconnects for such things as a headset or speakers, or it could be a USB subsystem with the controller, PHY, a software stack on the USB, integration services and verification IP, according to John Koeter, vice president of marketing for IP and systems at Synopsys.

“The majority of IP is still going through traditional sales channels,” said Koeter. By our best estimates, about 5% of the IP market today is made up of IP subsystems. Over the next three years we expect that to double or triple.”

Exactly what those subsystems evolve into, however, is anyone’s guess. “One way to look at this is that right now you have semiconductor IP like USBs or memory, and at the other end you have platform-based deisgn, which is architectural re-use but not IP,” said Mike Gianfagna, vice president of marketing at Atrenta. “The subsystem is what’s in between. What’s interesting about all of this is that a few years ago what we now consider a subsystem was a full chip.”

Business challenges and changes
As the market for subsystems grows it also will create significant fallout across the industry, which is why chipmakers, IP developers and tools companies all are scrambling to position themselves for this shift. Rather than just another form of outsourcing of pre-developed IP, the convergence of multiple IP blocks, development tools, software and even services threatens to shake up the power structure in this segment of the industry.

It’s not certain at this point who will lead the subsystems effort, and whether the leaders will emerge from existing IP vendors, software developers, tools companies, or some combination of all three that has yet to come together.

Neil Hand, group director for marketing inside of Cadence’s SoC realization group, believes that while foundries are well equipped to deliver IP the EDA companies are better equipped to deliver a subsystem. “This is the functional space, which is where EDA companies live,” Hand said. “They can combine IP with high-level synthesis and high-level modeling. It’s a natural direction for EDA companies to be working with IP.”

eSilicon’s Subramaniam believes it also could be the chip companies that ultimately sell the combined subsystems. “I see the chip companies becoming more like IP companies, particularly as 3D stacking evolves,” he said. “You might see memory companies initially, but it also could be analog companies or an RF company selling the subsystems.”

At least part of what will drive these changes is the push toward Wide I/O and the recognition that multicore and many-core strategies need to be re-evaluated. The initial idea behind multicore was that either software would be written in parallel or that virtualization would work when parallelization wasn’t possible. Despite the devotion of enormous resources to parallelization of software, the best that companies have been muster for many applications is to thread certain functions onto two or four cores. In a 16-core processor, that still leaves 12 cores idle.

Virtualization hasn’t worked out as planned, either, despite its success in the server world. The solution in enterprise IT departments has been to virtualize servers to improve utilization of the servers, which typically had been running at 5% to 15% of capacity, by most industry estimates. While that improved efficiency in large server farms with thousands of server racks, because it reduced cooling costs and the cost of powering the servers, the strategy is actually inefficient at the processor level because all the cores must be homogeneous and too many need to be in the “on” state to take advantage of this approach. Moreover, one of the limitations of multicore and many-core systems is the shared memory.

With wide I/O, more dedicated memory and heterogeneous cores sized for specific applications, performance can be ratcheted up significantly while simultaneously reducing power. That basically turns a core into a subsystem, and one that may or may not be independently designed by a third party and tweaked slightly for re-use.

“The tricky part is what happens near the interface,” Gianfagna said. “Timing, power and the performance of a subsystem, or even a block, are now affected by its neighbors. That means you have to re-check it in the context of full chip integration. We will need tools at the subsystem and the system level to do that. In my opinion, that’s a huge opportunity for EDA. It’s also a modeling and methodology challenge.”

Signal traffic also is affected. Sonics’ Mac Hale said connectivity is one of the top issues that needs to be addressed as IP is combined into subsystems. “We need much more flexible interfaces to deal with this,” he said. “System-level IP is becoming much more important these days, and that includes subsystems. We need to understand how different subsystems interact.”

Impact of 3D stacking
3D stacking and Wide I/O are expected to bolster sales of pre-integrated IP even more. While solving the issue of traffic bottlenecks, they also significantly raise the complexity of the interactions.

“It’s not really off-the-shelf subsystems,” said Cadence’s Hand. “They have to be tweaked by traffic patterns. Long-term there may be a whole memory subsystem, but right now it’s getting together pieces that work. That could include a Qualcomm baseband subsystem, which is incredibly complex. It also could be a compute subsystem that includes a processor and graphics chip. But while there is a demand for off-the-shelf IP that works together, customers are still wary
of taking everything off the shelf.”

In one respect this is a significant market shift. From an EDA tools perspective, however, it amounts to a tweak—at least for the moment.

Michael Buehler-Garcia, director of Calibre design solutions marketing at Mentor Graphics, said that whether it’s blocks or subsystems or even moving devices onto printed circuit boards, the basic idea hasn’t changed. As a result he believes many of tools at the back end of the design should work fine—at least until stacking of chips begins over the next couple years.

“At that point you’re going to be doing the kind of make vs. buy decisions that you’re doing now with third-party IP, but it could be a proven die instead of IP,” Buehler-Garcia said. “From an EDA perspective, until you are doing tradeoff analysis and tuning with the TSV (through-silicon via), the tools we have now will work with extra scripts.”

Conclusions
The push toward subsystems will continue unfolding over the next few years, driven by ever-increasingly complexity and an understanding of where companies truly add value and where they’re adding a function that is required by a particular market segment. That makes subsystems a design shortcut, and one that is particularly useful when the marketing department adds another requirement late in the design cycle.

“An IP subsystem becomes the bridge between the system-level design and the implementation,” said Synopsys’ Koeter. “You get a virtualized model of the IP subsystem, accelerated chip-level verification and you start seeing software integration of the stack.

It also becomes a business opportunity in its own right for companies that can build these flexible subsystems, and for those that can sell them in a coherent way.

“The market opportunity is for a catalog of proven silicon so you pick out what you want,” said Mentor’s Buehler-Garcia. “That is a quick way to get to market.”

By Ann Steffora Mutschler
As SoC and system complexity rises continually and software drives much more in a system, specific vertical application areas will require tailored IP and tool flows to allow designers to meet time-to-market demands.

Today, many systems are designed around a platform, which contains most of the STAR IP—processors, GPUs, memory controllers, interconnects, memory subsystem, etc.—on the platform either fixed or with a defined migration path for these IP, said Nitin Chawla, chief scientist for Mentor’s Catapult C team.

“Where we look at a place for active differentiation is adding or redefining the application engines, such as wireless modems, video processing pipelines, encoding/decoding/transcoding engines. These are things that would keep your platform scalable for most of the software content but also add additional functionality to differentiate your product,” he said.

The big challenge for the digital consumer market, which is where many of these SoCs either directly or indirectly play, is to maintain or improve design productivity given the shorter time to market window. Another challenge is getting good quality results because most of these blocks have limited reconfigurability, so they need to be extremely low in terms of their cost to area and power, he said.

“Given the fact that you can do a lot of design exploration and choose an architecture that is best suited for that specific technology node and performance requirements—this is a design need. The idea is to be able to support this design need without disrupting the conventional implementation that is RTL to GDSII,” Chawla added.

However, continuing on the path of taking the horizontal, more baseline flows and just adding some capabilities to make them more applicable toward specific applications or verticals—basically the way EDA has done things in the past—is not scaling any longer, said Michal Siwinski, senior director of solution and product marketing at Cadence.

“With software taking a more important role in differentiation of the end offering, at the end of day having silicon that is 1% smaller or slightly faster in most applications on the market is no longer the primary criteria. Clearly, for some specialized applications that’s still the key factor but what is becoming differentiating is shifting. The more that shifts, the more the trend is to a top-down, vertical approach being necessary to the way the tools and solutions are being developed and deployed.”

“If you really take a clean slate and think about what is needed to enable a mobile market, or to enable what is needed in networking, or storage for example, from a top down perspective the requirements are so fundamentally different than starting from a clean slate – a lot of the underlying technologies that you would then build to support that would be drastically different,” Siwinski explained.

Vertical-specific IP ahead?
When it comes to narrowly-focused applications, Vishal Kapoor, VP of marketing for SoC realization at Cadence, does not believe it makes sense from a business perspective to have 100% vertical-specific IP. Cadence is making a bet that with convergence, there is a very significant demand on the memory interfaces.

“If you look at our DDR controller, we’ve got DDR controllers going in from consumer devices all the way to supercomputers,” said Kapoor. “The reason we are able to do that is if you take IP and make it very vertical-specific, you’re narrowing the market; but if you make it very configurable so that you can deliver specific configurations to your customers, that makes sense.”

Based on his experience on the graphics and wireless side of things, Arteris director of marketing Kurt Shuler explained that the tools needed to create the test load or the software that runs on it are different in those areas. Also, how success or failure is measured is different, as are the metrics.

“If you’re doing a big graphics chip that’s running in a PC it’s very different than something that’s going to be running in a cell phone. So the infrastructure behind that is different. The tools and the players are different. If you are doing something on the wireless side, they can get really complicated because if you back up all the way, they have to get these things certified that work under different cellular networks,” he said.

Further, the IP must be configurable to every SoC so that when the designers are putting the SoC together, it allows for architectural exploration since every customer asks for power, performance, gate count, noted Frank Ferro, director of marketing at Sonics.

Of course, application-specific IP exists today, mainly in the form of subsystems, noted Prasad Subramaniam, vice president of design technology at eSilicon. Chip designers are beginning to take the building block approach to the next level in creating subsystems that are targeted to specific applications by combining different pieces of IP together in the most common way that they would be used. Then they leave the rest to the imagination of the end customer to customize their own proprietary know-how so that it is easier for them to build their end application, he explained.

By Ed Sperling
Growth returned to almost all sectors of EDA in Q3 of 2010, from ESL to semiconductor IP. Moreover, that growth occurred in all geographies except Japan, with Asia showing the strongest upswing.

In raw numbers, EDA revenue for Q3 was $1.3 billion, which is 11.9% higher than in Q3 of 2009. The numbers also increased sequentially by 6.9% over Q2, so the comparison isn’t just to a down year.

“Typically after a recession EDA lags,” said Wally Rhines, chairman of the EDA Consortium, and chairman and CEO of Mentor Graphics. “That makes this pickup especially encouraging.”

The big winners in the technology categories were IP layout, which grew 11.8% globally (28.5% in Asia/Pacific); Emulation, up 18.5%; design for test, up 75%; and IP, up 25%. ESL grew 4% and power analysis grew 30%, reflecting the complexity of designing semiconductors at advanced nodes.

The number of engineers working in EDA also increased by 1.9% to 26,474 in Q3.

Things were a bit slower in the system-design world. PCB and multi-chip module revenue were down 5.4% compared to Q3 of 2009. The four-quarter moving verage for this sector was down 1.8%.

By region, the Americas were still the strongest buyers of EDA tools. Sales were $577 million, up 12.9% over the same period in 2009. Asia/Pacific bought $274 million in tools, up 34.6%. Rhines noted that most of the tools sales in that region, which includes India, China, Taiwan and Korea, came from large multinational semiconductor companies, whose design teams typically are spread out around the globe.

Source: EDAC

By Ann Steffora Mutschler
System-level design is impacting the supply chain at many levels. Software suppliers, IP providers, semiconductor companies, system integrators and OEMs are challenged to work ever more closely together and find a new balance of power for who controls what in the content of an SoC.

“We see more and more the design chain driving how our tools work together,” Frank Schirrmeister, director of product marketing for system level solutions at Synopsys said. “The semiconductor house works with us on how to integrate the IP they use to make the chip development, and the representation of the chip to be used as a prototype, more efficient. They work with us to interact with their customers — the integrators and system houses – to take prototypes like virtual prototypes and send that to the system house to do software development and hardware/software integration on it, long before the chip is available.”

In the other direction coming down from the design chain, the system houses use tools from the system level to articulate requirements to their suppliers, namely the semiconductor companies and integrators, in a way that is much more crisp and precise and not open to interpretation. “Instead of pushing down a paper spec and having 10 meetings to identify what the spec means and talk about it they provide an executable prototype as a virtual prototype to their suppliers and tell them, ‘This is what I want, can you deliver on it?’ Then you have something much more precise to interact on within the design chain,” Schirrmeister said.

What this reflects is the notion of how the power structure within the design changes, which is becoming very application-specific. In wireless, a lot of vendors are pushing virtual platforms because they need to make sure Android, Windows Mobile 7, and the Apple iPhone OS all work on it when the chip comes back. In automotive, it’s much more about precision of the specification so it sometimes more the other way around, where the system house articulates downstream.

“That’s an interesting thing to watch as we basically go from IP to subsystems, from subsystems to more complex subsystems in semiconductor houses, and then to the system houses gaining more importance in specifying things,” he said.

Similarly, Mark Throndson, product marketing director for technologies at MIPS, also has seen a lot of change and an increasing demand for system-level solutions. “There is a software aspect, as well, which ties together everything. That’s a heavy amount of the investment MIPS has made, from our Android activities to work with Adobe, and a variety of major open source initiatives.”

The system implementations for new products, such as TVs that connect to the Internet, require a whole new suite of capabilities and services to enable that experience effectively, which is a more complicated development effort. “Our customers and our customer’s customers look to us to provide more of the solution than just licensing an IP core,” Throndson said.

“More of the solution” may include software that doesn’t necessarily just depend on the microprocessor IP. It may have some dependencies on what graphics support there is, the type of audio and video processing capabilities, security, specific interfaces and the like. He noted that MIPS leverages its relationships with complementary IP third parties to create platforms with software that can support the different pieces of IP.

Seeing is believing
From the perspective of network-on-chip supplier Arteris, the shift to system-level design is causing changes in the design chain represented by semiconductor companies finally starting to ask for models, noted Kurt Shuler, Arteris’ director of marketing. “Since I joined Arteris in August I have seen five prospects ask for SystemC TLM models of the interconnect, either at the cycle accurate or approximately timed levels of abstraction.”

The NoC IP configuration can be used to interface these models with the SoC system models.

Mentor Graphics also sees a lot more interaction happening between the designers and the rest of the supply chain. John Isaac, director of market development for Mentor’s Systems Design Division, said it is being driven by “increasing pressure on the OEMs to get the most competitive product to market faster. For example, starting at the very beginning of the design process the designer is communicating the parts that have been chosen for the product to procurement and manufacturing. This will enable them to identify any of those chosen parts that may affect their ability to get the product to target volume production on time, or components that may require special manufacturing and thus increase product cost and time,” he said.

“We see additional communication between the various disciplines in the product development process again during the entire design process rather than at the end. An example is between electrical and mechanical domains. The mechanical designers have a view of the entire product, including the enclosure, and they are in the best position to analyze if the power being generated by the ICs on the PCB will be dissipated properly or if junction temperatures will be too high and affect product reliability,” Isaac said.

Supply chain changes driven by rise of ODM model
With the very strong emergence of ODMs, the role of the OEM has pretty much disappeared said Giddy Intrater, vice president of product marketing at MIPS. “Rather than the OEM building the system, the ODM actually expects to get the complete system done by the semiconductor company so the new system companies are the semiconductor companies rather than what used to be the big OEMs of the world.”

He noted that OEMs such as Apple still do complete system design, but the bulk of consumer electronic products are built by ODMs that actually expect to get complete solutions from their chip vendors. “Now these chip vendors are turning back and actually wanting to reduce the amount of work that they need to do and go back to their IP suppliers and expect the IP suppliers to do as much of the system-level design for them,” Intrater said.

As a result of these shifts in the market, he said, MIPS’ customers supply the complete system to their customers, which means MIPS is responsible to supply the complete subsystems. “We typically supply the CPU subsystem, which includes the CPU and major pieces of software that go with it. In the past we would just offer a compiler and an operating system and our customers would write their code on top of it. Now we have to come with complete software systems that run on top of our solutions and Android or other software systems that we’re working on,” he continued.

Michal Siwinski, Cadence’s group director for product management and system realization, agrees a major shift is taking place with OEMs today. “The idea of a traditional OEM and the demarcation line between an OEM and a semiconductor company are shifting, and will continue to shift. I would argue that over time what semis have traditionally done is going to change pretty drastically, and a smaller number of semis in the classical sense will remain. Some will basically evolve much more toward being system providers and we see that already with a few companies that identify themselves as semis—they are basically behaving like OEMs already.”

What exactly will they become?

“I don’t think that most of the semis or the system houses today know where they will actually end up,” Siwinski said. “I think a lot of them are trying new things because the time pressures and the cost pressures are just prohibitive. Some are exiting businesses, some are taking bold, new steps—and all of them are looking for different, more productive, more efficient ways to get things done.”

What the shift to system-level design means
The industry has been talking about system-level design taking off for quite a number of years, noted Mike Gianfagna, vice president of marketing at Atrenta. “It’s finally happening, but not the way a lot of people envisioned it. Sure, high-level synthesis is becoming more of a mainstream tool, but that’s a small part of the story. The real story is about platform-based design, IP reuse and software differentiation. Advanced chip design is now all about finding the right collection of pre-existing blocks, stitching them together in the most efficient way, and adding differentiating software to the design in a predictable manner. It used to be about who came up with the best original circuit design. These days, too much original design is likely to spell long time to market and a loss of market share.”

These trends are creating new markets and new supply chain configurations. IP providers have to prove their product is robust, complete and integration ready. “EDA can help with that, creating a new market. Tools to help assemble the design are also a new area for EDA, and this one has a potentially very interesting twist. The semi suppliers are focusing more and more on providing complete platforms, software stack and all, as opposed to just a bare chip. Putting that platform together requires a lot of EDA assistance. Could EDA become a business enabler for the semi companies, and not just a cost of doing business? Maybe, and that would be a new model for the supply chain,” Gianfagna said. “If we take a look at what’s going on with 3D stacked die design, the supply chain will take on a new look, as well. Who is going to assemble a stack of silicon from multiple vendors? Someone has to take the yield and inventory risk. Who will that be? It could be a new breed of company.”