By Ed Sperling
Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: What standards do we need that we don’t have?
Ruby: My vote would be for a power-consumption level. That’s absolutely critical. Gates have their own built-in standard cell libraries and power models. You abstract to RTL, and we have found a way of using the same standard-cell library. But once you go above RTL there is nothing in terms of power consumption models.
Pangrle: With UPF, SAIF (Switching Activity Interchange Format) had been included. The standard is really set up for power intent. But when you look at the back, there’s this ‘SAIF’ information, as well. There has been a little bit of talk on that committee about what we should be doing with this. If you’re going to have any type of standard to specify the energy coming out of a given part, that’s going to be tied to some activity. You have to have some way of specifying that, as well. There is a potential for tying that together in the future, whether it’s there or somewhere else.
Rajendiran: By definition, a standard means multiple parties need to talk. Models have come out of that with standards like UPF. You can specify the power intent, but that’s a very high level. Where it gets implemented, when you’re splitting microwatts and nanowatts, it’s necessary but not sufficient. You need a standard, but you need good tools and someone who can combine the high-level intent with all the nitty gritty low-level details of the variants and power and know how these things will be put together and verified. I don’t think we’ll ever have a situation where you push a button and determine whether function is correct and timing is correct and power is correct. If we do, that means we have stagnated. We will always have something pushing us.

LPE: But we’re still at the point where we don’t even know how to write testbenches for power, right?
Balachandran: Yes. When a customer starts with their first low-power design, they’re struggling to figure out what to do to exercise all the low-power functionality in the design. If the customer is more experienced, they already have a way to do that. They’re learning how to do a low-power design from a test perspective. Creating that first test plan and testbench for a low-power design is not a trivial task. It’s a huge methodology change. They’ve got to invest resources in terms of learning what it takes to do it and allocating resources to do it. That challenge is still not solved.
Ruby: If you look at it from a hardware perspective you’re absolutely right. But if we can somehow leverage the applications running on this hardware and transform them to testbenches, that would be another element of this solution.
Rizzatti: But is it the embedded software doing that? The application is the embedded software. You don’t have to invent anything.
Pangrle: It’s been a challenging transition for the hardware guys to deal with all the complexity brought about by power. If you look at the software, it’s almost always been purely about functionality. Either the software works or it doesn’t. Now you’re asking the software guys to look at the way they write their code because it can have a big impact on the performance of a device.
Rajendiran: A developer writes a piece of code and even provides a way to test it. The developer knows the guts of the software, so he comes up with a test plan. We used to call that white-box testing. Then we also used to pick up the most junior guy and tell him to do a black-box test. The reason we did that is the developer knows a certain path to exercise. If you give it to some random guy he’ll exercise it in ways the developer never thought about. It’s probably impossible for the developer to write a test plan for power, though. You probably need a combination of test plans. The better companies have people writing power verification plans and the developer writes the functionality part.
Balachandran: I’ve seen the same thing. The designer and the verification engineer are still working independently. The design engineer is not the verification expert and isn’t the architect of the low-power system. The verification engineer comes from a software background and has expertise in writing a test environment without much of the low-power hardware knowledge. The low-power architect has very little idea about how to write the software and how to write the testbenches to test his design. It’s almost as if you need a third person who knows enough about both of them to be an intermediary in order to close the gap. That’s the challenge companies are facing. You either have a verification expert, who is not a low-power expert, or you have a low-power design expert who doesn’t have enough knowledge of the verification concepts. Large companies are investing a lot in methodology. They have low-power methodology teams in place, and they’re tasked with coming up with the proper flow to get this working. Some companies are expending as many as one or two years to come up with the right methodology for their environment before they put a flow in place for their design teams.
Ruby: What if you can say, ‘Look, I’m designing this chip for a cell phone and I can verify it runs this operating system and 500 applications?’ If I forget about testbenches and power and I can just run the applications on my hardware, to me that would be golden. So can you run an application to analyze your power grid? That’s a big question.
Balachandran: That’s a great idea, but the apps don’t come out before the product is launched in many cases. How do you test for that before you get the product out in silicon and ship it? That’s where the challenge is.
Ruby: You test it the same way as our customers do. You test it with what you’ve got at the time.
Balachandran: That requires a very big effort on the part of the software developers for an application and the system providers working ahead well in advance. Only a couple companies in the world have that kind of clout.
Ruby: Look at the consolidation in the semiconductor industry. That’s exactly where we’re going.
Balachandran: But even those companies that are the system builders are sourcing their ICs from different companies. This has to go down the chain where the IC companies have those requirements and specs for apps in mind from the beginning, because if you talk to the typical IC maker they don’t care about apps as much.
Ruby: They should.
Balachandran: Maybe they should, but it’s a big change in the entire ecosystem. It’s possible, but not easy to accomplish.

LPE: What happens with stacked die? Does that change the verification process because there are new issues with power in stacks?
Pangrle: That’s more on the physical side. On the functional side it’s just a bigger system. On the physical side, the interaction of heat dissipation comes into play. If you’ve got a single die you can stick a heat sink on top or do some active cooling. If you start stacking something in the middle it doesn’t have a direct path out to that heat spreader anymore.
Rajendiran: When you think about flip chip, it took 30 years before it came into common use. The reason is that we have vectors pulling us in different directions. On one hand the mobile and consumer space are pushing us into the cheapest and lowest power. That’s a completely different direction than some of the biggest companies are taking. The biggest benefit people are looking to gain with stacked die isn’t low power. It’s that the cost is too high to move to 28nm or 22nm. Already verified chips at 180nm are perfectly fine because that portion doesn’t need to run that fast. If you combine 180 and 130 and 65, and maybe do the logic that ties them together in 90nm, time to market is the key.

LPE: But when you verify that, three good chips don’t necessarily make one good stacked die, right?
Rajendiran: No, and verification will continue to be a challenge. We need standards and models, and the verification will only be as good as the model. The overall full-chip model has to make some assumptions about timing and power, and that has to come from the IP supplier and manufacturers.

Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: How does IP affect verification from a power perspective?
Pangrle: In the old days you’d see processor cores quoting watts per megahertz. When you’re operating at a standard clock frequency and voltage the whole time there is no other state that’s at least a reasonable approximation. Now you look at the levels of complexity going on above that with multicore designs that may be operating at different voltage levels or different clock frequencies. Watts per megahertz goes right out the window. There is a challenge in how you get that kind of information. If I’m a designer working in an SoC I’m trying to figure out what is my lowest energy core to put in there and what voltage and what frequency you want to run. How do you make these tradeoffs if you don’t have any data to work with? And then, once you have this, how do you hook it all together. You need to give that to the customer who’s going to use all this IP. That can be a third-party IP from outside or IP that’s developed in-house that you want to re-use from project to project. How do you keep that information so the next designer who picks that up knows how to use it? That’s complicated further by the fact that a lot of control for these SoCs is moving out of hardware and into software. From a verification standpoint you need some environment where you can bring in the software and get an idea. Often what’s going to determine the power is the software running on top of it. With phones we see instances with software where you download an update and your battery life gets a lot better—or it gets worse.

LPE: We’re used to verifying pieces of this, but now we’re dealing with interactions, as well. Don’t we have to raise up the level of verification?
Pangrle: You do. There’s almost a renewed interest in the high-speed emulation. Clock frequencies, especially for x86 processors that are used for most simulation, have stalled out since about 2004. We’re getting access to more cores, and if you’re doing regression tests that’s good. But if you’ve got software that you need to run and you can’t break that up, then the reality is that single-threaded performance hasn’t increased much. We’re seeing a lot of interest in higher-speed simulation and verification to help address that problem.
Rizzatti: Raising the level of abstraction won’t do any good in computing power consumption and verifying power domains because you don’t have the accuracy. Here we are really talking about cycle accuracy. Emulation is the alternative. It’s cycle accurate but you have performance that is orders of magnitude faster than a simulator. You can simulate the interaction of the software with the hardware and verify power domains turning on and off. There is lots of interest here.
Rajendiran: With chips becoming more complex and larger, if you have 100 power islands, at any time you may have one or two operating and the rest you want to put into a lower power state. So how do you know those things have been turned down to a low power state? That becomes a verification challenge. The more domains and islands you have, the bigger the challenge to make sure your intent is implemented at the chip level.
Ruby: Power verification has many different aspects. There is power intent verification. There is power consumption verification. There’s probably also something to be said about power integrity verification. Test power is orders of magnitude higher than functional power because all of the low-power techniques and clock gating are not working in the test mode. Everything is open and running at the same time. You have to verify physical power integrity, as well. Verification in the past used to be RTL or something above that. For power it needs to be done at multiple levels, from the system level to RTL. And what do you feel comfortable with? If you do RTL emulation you can understand the hardware behavior of your design. The question is how does software drive that hardware. Can you establish that kind of behavior in accelerators, or do you need to bring the hardware up a level and truly make it work with the software? Based on the RTL description we can estimate power consumption. The further you move up in levels of abstraction the more you lose. At the gate level you get good accuracy. As you move up to the RTL you start losing accuracy. As you move up to system level you may lose so much accuracy that the analogy becomes useless. There is a tradeoff here between the types of verification you do at the higher level, including power consumption, and the turnaround time that’s required.

LPE: Aren’t we changing verification, though? We’re taking it both up in abstraction and down to the most basic level.
Pangrle: It isn’t an either/or issue. It’s an ‘and.’ You need to be checking this at multiple levels. You can’t ignore one level and hope everything will work out okay. You have to make sure you’re accounting for all the different scenarios a complex SoC may run under. One thing that gets challenging is that if you’re looking at running software on a virtual prototype or some type of accelerated environment, you can’t run that many cycles when you’re looking at what’s happening on the power grid. Only certain pieces are of interest to you. When it’s doing what it’s supposed to be doing most of the time, that’s probably not where it’s going to fail.
Balachandran: Software verification is important. A lot of it is also done with methodology. The verification methodology is changing compared to non-low-power verification. They also have a link to SystemC simulation in their environments. And we are seeing customers with a renewed vigor to do gate-level simulations. Some customers now have a methodology of not taping out their chip without doing more extensive gate-level simulations for the power. The low power has caused a renewed focus in that area.
Rajendiran: When you are splitting microwatts and nanowatts, you have to go to that level. RTL was great 20 years ago because you were doing simple blocks with 20,000 gates. There are so many libraries at the same process node and for the same flavor that it really becomes very critical which library you pick. That can have a huge swing factor for a mobile device. If you have a chip verified in this process at this foundry but it’s not at a price point you like, you can’t just move it. Gate-level is becoming a lot more important at that perspective.
Rizzatti: A simulator running at the gate level will take forever. We’re talking many years.
Ruby: We need to do this with multiple levels. But one of the key elements of the solution involves technology-dependent models that can take you through the levels of abstraction. There may be multiple models for multiple levels, but you may want to say you’ve done this design and you know what the power profile is and you can measure all the way down to gate or transistor level. You can then abstract the model for that block, push it up several levels of abstraction, and still maintain as much accuracy as is practically possible. You can do this because it’s not being done from scratch. If you don’t a netlist and you don’t have a post-synthesis result, you can still estimate power consumption based on RTL and create an RTL power model. Technology-dependent modeling, not milliwatts per megahertz, will be the key to this puzzle.

Low-Power Engineering sat down to discuss the problems of identifying and verifying power issues with Barry Pangrle, solutions architect for low-power design at Mentor Graphics; Krishna Balachandran, director of low-power verification marketing at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Will Ruby, senior director of technical sales and support at Apache Design; and Lauro Rizzatti, general manager of EVE-USA. What follows are excerpts of that conversation.

LPE: What’s the big challenge with verifying power in an SoC?
Ruby: Power has a couple of different components. One is how the low-power techniques impact functionality. If you talk about things like power gating, power supply shutoff, multiple supply voltages and so on, this is where you need to understand certain rules of turning on and off power supplies. You need to be able to create retention cells, to be able to retain state, and to retain functionality. That’s one major aspect. The other side is that you have to look at the power consumption itself. How do you verify that you are on target, if you have a target, and that you are not exceeding a specification? And how do you ensure the design has efficiency built in.
Rajendiran: This is all about is trying to verify what your intentions were that you stated in the beginning and making sure that has been implemented—and when the chip comes out, making sure it is functioning that way. In the old days we simply meant functional and timing verification. Now, just on the functional side, it has become so complex that just getting it out the door is a challenge. It’s the same with software. No one thinks about verifying it all. That’s the practical problem. The person who is verifying the power states doesn’t have the time to put in the right hooks. We have the Unified Power Format to help, but we still don’t have standardization as to how you verify the states. Tools rely a lot of naming conventions, but even though there are fewer companies there is still not compatibility in reading all of those things. Tools are always playing catch-up, too. The ideal solution will be a combination of great tools and planning. In addition, you can have the best tools, but if you put them in the wrong hands you don’t get results.
Pangrle: There’s a functional part and a physical part of verification. A lot of what is going on in the industry right now, especially with the power formats and the convergence around UPF and the 1801 IEEE working group, has been to keep the power intent separate from what has been the standard part of functional verification. It’s allowing people to use their standard flow, take it to RTL, and still be able to design RTL blocks that can be used in different design scenarios with different power management. You don’t have to hard-code isolation, level-shifting, retention registers into those blocks. You can still design your block your same way, and if in one design you’re going to power down that block that’s okay because the intent information is in a separate format and you can bring that in. From that standpoint, there has been good collaboration between EDA companies and their customers. From the standpoint of putting it all together and being able to support the tools, one of the things we’re seeing is that as EDA companies work with designers there are times where something is a little different and different vendors have created support. That’s where it gets tougher to move designs from one company’s set of tools to another. It also brings up some new questions. From the physical side, if you’re powering up and down blocks it has a real impact on your power grid and whether it’s going to function. Just because logically it looks as if it should work, that doesn’t mean when you get your chip back from the foundry you’re not going to run into other issues. And in terms of the complexity of testing, you can do the standard ATPG, but when you go through the dynamics of running different voltages and frequencies and bringing things up and taking them down, to what extent are you actually going to test that?
Balachandran: Verification is complex enough without low power, stretching the resources from both a verification productivity standpoint as well as IP cost. When you add low power into the mix, it makes things much worse. The complexity of low-power designs has been going up slowly but steadily. Some companies that are on the cutting edge, particularly in the mobile market, started adopting low-power designs about five or six years ago. They were the frontrunners of the whole low-power wave. They put the initial pressure on low-power verification, because now you have to start thinking about verification differently. You have to start thinking about voltages, multiple supplies, and whether things going to work in all those conditions. Clock gating is the most basic technique, and almost every company you talk with has been doing clock gating. Now that has expanded into more sophisticated techniques to curb the power, and with that comes the burden to verify properly. All it takes is one unverified state or transition or sequence for the design to completely lock up and not function at all.’

LPE: How bad is this problem?
Balachandran: It’s becoming more widespread. There are government regulations and green initiatives. Everything is going green. There are demands on specifications, and even on power for devices connected to the wall. That requires chipmakers to make their designs much more power-efficient. Customers typically start with four or five power domains. Some of that verification can be done with static techniques or with some rudimentary simulation. But it’s becoming more complex, and this complexity is increasing for the mainstream market, not just the mobile market. The number of power domains is exploding. We’ve seen designs with 50 power domains, which is potentially 250 power states. It’s pretty much impossible to verify all of them. So you need to come up with a really good test plan. When people are confronted with low-power designs the first time, they have no clue about how to write a testbench for low power. Often they need a lot of methodology help, in addition to having the right tools in place, to figure out what they’re going to do, how they’re going to go about doing it, and how they know when they’re done. Then, what is the measure of confidence they have at the end to figure out if they’re really done?
Rizzatti: From the perspective of emulation, this technology has been used for functional verification. Ten years ago, power management was essentially a gated clock. You turned off and on some part of the chip and saved energy there. Around 2001-2002, designs with 10 or 20 of these were called derived clocks. Today we have customers with 100,000 derived clocks. There’s an explosion. But that’s only one problem. Over the past five years, and especially in the past one or two, there are all these new techniques for turning on and off voltages. We had one customer with well more than 100 power domains. The whole industry is changing. Power management is a nightmare, and it makes SoC verification orders of magnitude more difficult.

LPE: With a disaggregated supply chain and more IP re-use, does it make it more difficult to verify the design? Not all of the IP is fully characterized for power.
Balachandran: UPF, or IEEE 1801, and CPF have ways to model the power intent of IP. The issue isn’t so much the ability to specify the power intent of IP. Talking to all the major customers, everybody is either integrating internal IP or using third-party IP. Some of the IP blocks have their own power management, too. It has to be communicated to the integrator of that SoC as to what are the legal ways to integrate the IP into the SoC. That information has to be passed along. The power format is not the right way to pass that information. So the industry has to work out a way—together—to solve this problem. The IP companies, the EDA companies and the whole ecosystem has to work on this to facilitate communicating the right behavior that IP can be integrated from a power perspective, and to tell the IP integrator when they are doing something wrong. If IP is coming from a third party and you have no idea what is going on with that IP in terms of its inner functionality or how the power is implemented and what ways you can put it together on the block, then you can shoot yourself in the foot pretty quickly. This is a problem that needs to be solved. One potential solution is to create assertions for an IP block. The IP developer doesn’t know how IP is going to be used, but they do know what is legal or not. They can create assertions for that and ship it with the IP. Then, when the integrator puts it into the SoC and runs the verification, they are able to figure out if they’ve done it properly or not. If it’s not, then they can have a dialog with the IP company. It’s a way of communicating the data sheet of the IP to the next-level integrator. This is one way of solving the problem. It requires close collaboration between IP partners and EDA and design services companies.
Rajendiran: More times than not, people don’t do that. There are many ways that tools can help, too. If some expert designed the IP block, he can provide some input and then a tool can insert assertions back into the RTL. Ideally you want to keep it separate as a companion file. That’s one approach. But the problem is more complex than that when it comes to low-power verification. IP is one issue. There is physical IP where you can’t do much because it’s already hard coded. There’s also soft IP. Each of the classes has its own challenges. With the soft IP, a lot of activity only happens at the gate level. Depending on how the RTL gets synthesized and mapped, you can have a perfectly functioning solution when you use a particular library in a particular foundry, and the same thing may not work somewhere else. You need deep knowledge about this stuff. You need collaboration of tools, the integrator and the IP developer to make sure you at least get the product out to market on time.
Ruby: There is another dimension of IP—the power intent side, which is the functional verification aspect. That’s absolutely essential to ensure the functionality. Time and time again, what I’ve come across is the need for some way to describe the power consumption behavior of IP, as well. It could be technology dependent or technology independent. It could be models that describe assumptions as a function of clock frequency or data rates. From my customer perspective, this is also becoming essential in the power verification area because they’re not just worried about functional intent. They’re also worried about hitting their power specs. They need models for the IP coming in. If they plug IP into their design and they run their clock frequency at a certain rate, what power consumption can they expect? That’s another very important element to this verification challenge.

Low-Power Engineering talks about how to verify the power portion of semiconductor designs with Krishna Balachandran of Synopsys; Barry Pangrle of Mentor Graphics; Kalar Rajendiran of eSilicon; Will Ruby of Apache Design, and Lauro Rizzatti of Eve-USA.

By Ed Sperling
Low-Power Engineering sat down to discuss billion-gate design challenges with Charles Janac, CEO of Arteris; Jack Browne, senior vice president of sales and marketing at Sonics; Kalar Rajendiran, senior director of marketing at eSilicon; Mark Throndson, director of product marketing at MIPS; and Mark Baker, senior director of business development at Magma. What follows are excerpts of that discussion.

LPE: If you don’t look at this as 1 billion gates, but instead look at it from the standpoint of subsystems, is it easier to justify from a business standpoint?
Browne: Yes because you know these customers because you’re tier one, two or three in this segment and you know what to put together. You may be nowhere in another segment. So here you do something original. Here you try something new.
Rajendiran: There is a difference between a derivative and a variant. You can start out with one chip, do a re-spin and get a derivative. A variant is where you start out with a big system and then that hardware is given to all the divisions in the company. Each product line comes up with what to do to create a variant, mostly in software.
Janac: Is a variant a software re-spin?
Rajendiran: That’s what we’re seeing. It’s like a superset.
Browne: We’ve seen that in a lot of companies, too. You don’t know what you need for a particular market so you create a superset.
Rajendiran: Not only don’t you know what you need, but the markets are changing. You don’t have time to figure it out. Are you really going to do a billion-gate design from scratch? Probably not. When you do a new chip the traditional defect density model tells you that your yield is low. So can you easily take what you have and do it in four chips? This isn’t the traditional way of doing integration. If I can make them into four chips and tie them together with 2.5D, then you get better yield.
Browne: Or can company ‘A’ race to market with multiple chips. If not, then the slow and steady guy may win. How far do you jump out ahead before it’s off a cliff?

LPE: On a multicore/many-core implementation, are these core sizes becoming more heterogeneous?
Throndson: There’s definitely a lot more interest in that area. One of the more popular configurations in the application processor space for these Internet-connected applications is in mobile or the digital home. It may have floating point or no floating point, which can affect a significant chunk of the core size. That works on other features, too.
Browne: It’s hardware vs. software.
Throndson: Yes. Software needs to be a little bit more aware of where those dedicated resources exist, but that’s a manageable problem. It definitely helps to save power and area, though.

LPE: EDA traditionally has been one size fits all. Are the tools moving in those directions.
Baker: System-level change based on applications is very interesting. Right now we’re in a vertical space and there are functional verification, custom design and digital implementation areas. All of us are trying to find ways to automate the process by abstracting it up a level to get to an answer more quickly. The EDA industry needs to make tradeoffs on area, power and cost so we can add productivity to the design teams. Everyone is working on that now.

LPE: It used to be a tradeoff between power and performance. Is performance no longer an issue?
Janac: It depends on the market. If you’re in DTV and you’re operating on a 25% or 30% gross margin, the die size becomes very important because it’s so cost-sensitive. If you’re in a high-margin base station, area is less important. It’s all performance. It depends on the market. But in the billion-gate chip, the big concern will be risk. People get fired for being late and for quality problems.
Browne: But risk is different things for different people. Samsung’s president said his company will be using TSVs in 2013. There are ‘Haves’ and ‘Have Nots.’ If you need to get there first you’re going to have a different risk profile than if you’re a follower. And it’s a whole continuum.
Janac: But whoever is in charge of the Samsung TSV chip is going to get fired if he doesn’t get there by 2013. He’s got to be very cognizant of the implementation risk he’s going to take to do the project.
Browne: And someone else will get fired if the factory isn’t full.
Janac: But the guys who create the design don’t get fired if the factory isn’t full. They get fired for not delivering on time, on scope and with quality.

LPE: Will we be able to get these chips out the door on time with a billion gates?
Browne: We have to improve on quality at the same rate as we improve on dealing with complexity. It’s a marathon race, not a sprint.
Rajendiran: Some companies can afford to take a huge risk. Hopefully other companies will be smarter about how they approach this. It is important to differentiate by market. But there are more ways to get there than just by following Moore’s Law. We don’t have billions of dollars to write off.

LPE: Isn’t some of this about getting more granular in the design?
Janac: The key in a billion-gate design is how you manage the partitioning and the IP re-use. You need to understand the risk of not redoing the IP, as well as the risk of redoing it.
Browne: It’s all about how it works in the system. The guy with more understanding that will have the ability to reuse more cleverly.
Baker: Certain companies will rise and succeed because they’ve built the knowledge base internally.

LPE: What happens on the manufacturing side? How do you manage yield issues?
Rajendiran: At any process node it’s the same. One thing the better foundries do is apply their learning to get to a better level of yield. The more chips you do, the more expertise you have, the better you get. We’ve done it and learned it with in-house expertise. You have the building blocks, the tools and the expertise. That’s what sets one company apart from another. Anyone can buy the tools, but can the produce it?

By Ed Sperling
Low-Power Engineering sat down to discuss billion-gate design challenges with Charles Janac, CEO of Arteris; Jack Browne, senior vice president of sales and marketing at Sonics; Kalar Rajendiran, senior director of marketing at eSilicon; Mark Throndson, director of product marketing at MIPS; and Mark Baker, senior director of business development at Magma. What follows are excerpts of that discussion.

LPE: Will anyone be able to afford to create these complex chips in the future?
Janac: Sure, but it will be extremely expensive.
Browne: Apple is doing it. They’ve come at it with a systems approach. The user will have a great experience because they’re going to add a whole bunch of devices. But we’ve got to find ways to attach to the software at a higher level. We’re doing a full system design. We’re not hooking up a couple of widgets anymore.
Baker: Apple has moved up the stack. From an EDA standpoint we see all these challenges. We’re actively seeing designs at 28nm, planning for 20nm. We’ve yet to see designs at 14nm. But the complexity of validating one of these devices, whether it’s a single die or a multiple-die approach and in the future 3D, is increasing by orders of magnitude.
Browne: With 100 times the number of elements you can’t just extend the methodologies we use today. You have to define the interactions so you can abstract this. You can’t manage this many power domains when the use models are different for all the users. There may be 200 things you’re turning on and off to reduce leakage and increase battery life. To date, most people haven’t done that. In the rush to get to production people want to know if it runs Android or Angry Birds, not whether you’ve done all the power management stuff up front. We’re back to the speed of execution in getting it almost right and being early.
Rajendiran: That’s correct. Verizon, after years of rumors, finally launched the iPhone. But as they got near to release they said it cannot do multitasking. Who was asleep at the wheel? Then the next day they had a software fix to enable that. Why didn’t they think about it ahead of time? With all these complications we should really partition who does what.
Browne: Yes, it’s a system problem.
Rajendiran: But it’s something people could have easily thought out ahead of time. We need to define the components that need to be addressed and give it to the people who can address it. If you take a processor and optimize it for a set of libraries vs. another set of libraries, for the same performance level, one might take a third of the power of the other one. But who should tell you that? Should it be the company that makes the processor or the company that builds the SoC?

LPE: But increasingly you’re not building the chip. You’re integrating parts.
Throndson: You can see people racing ahead of each other, depending on the pieces you’re considering. Part of it is just a matter of getting to market early with a solution. But in terms of parallel hardware, it’s still way out in front of parallel software. Even with power part of the answer is going back to better utilize the hardware that’s already there, whether it’s the processor itself or at the larger system level. It’s very difficult to optimize and deliver every component that goes into these systems today.

LPE: From the network-on-chip perspective, will these chips be running at the same node and power or will there be an array of nodes, power and legacy technologies.
Janac: You’re going to be dealing with multiple processes and legacy applications. It doesn’t make sense to put analog IP on a 16nm design. You will have to use multiple die using a system-in-package approach where the digital part of the system is running at the latest nodes optimized for low power and cost and the analog stuff is running on trailing-edge processes where the IP is available.
Browne: We’re building a system using building blocks, and good enough wins if it’s early enough. The more you re-use, theoretically, the quicker you can get there. But the real challenge is how you better enable mix and match in the software area.

LPE: And that ‘good enough’ is also tested well enough?
Browne: Good enough has programmability. The fabric allows reprogramming. We think it’s important to be able to do things in parallel. If you can get enough of them done simultaneously, even if they’re running slower, then you don’t need buffers to manage those serial events and you have less logic and less wires and slower transistors in the linear area of design. That also means there is less leakage.

LPE: Will the tools be able to deal with this kind of structure?
Baker: Re-use has been around for about 15 years. So what’s preventing the re-use? A lot of that scaling and functionality is available today. It’s not a new challenge. The challenge we face is that re-use isn’t happening. We’re redesigning these components with each iteration.
Janac: Once you get past RTL the tools are horizontal. The chain of synthesis, place and route, verification and DFM are applicable to that entire system. Above RTL it’s like the silos of IP. Those tools are not addressing that. The MIPS and ARM processors each have their own tools. Arteris’ NoC has its own tools. You wind up with horizontal silos where the IPs are tied to the tools. Only when they reach RTL do they hit the Magma, Mentor, Synospys and Cadence tools. There is no horizontal toolset that can handle all of these IPs at the architectural level.
Rajendiran: There’s no reason to keep up with Moore’s Law for things that have already been certified and verified. In the old days we were following it. When Moore came up with that law he wasn’t talking about cost. He was talking about transistors. At that time you could do a chip for $50,000. That’s not the case anymore. People are slowly coming to the realization that if you have a chip working, why bother re-doing all of it? You can put software on it, you can even re-do it on the latest process, and use an interposer to make it work. So 90% of the chip is already validated. You add new software and you get the chip out sooner.
Browne: You also cover more markets, which adds more complexity to the definition. The requirements are different for a smart phone and a tablet computer.

LPE: But some of the functionality may be the same between a smart phone and a set-top box, right?
Browne: Yes, and that’s why the big companies have more data points. They know which subsystems can be re-used. When you’re doing audio on these devices everything works. When you add more cores or video, it’s different. The guys with a bunch of technology in-house just need to add more things out of what they already have.

LPE: How many of these billion-gate designs will be on 2D structures vs. 2.5D or 3D?
Rajendiran: With 3D, the problem is more on the manufacturing side. When you drill a hole there are problems. It’s just a matter of time before full 3D works.
Browne: The fabless community is huge. There are $3 billion fabless companies that have very expensive product portfolios. There are also startups that build similar point devices to try to go after those markets. The difference is the big guys get to run more experiments. The little guy only has one.
Janac: The answer depends on what you’re trying to do. If you’re building a unified chip that fulfills a unique function, throwing it on 16nm process makes sense. If you’re mixing functions that are mixed signal, analog, RF or legacy it makes sense to put it on more die. But fundamentally the mixed-die approach is more expensive than trying to put it all on a single die in 2D, assuming you can use one process and the IP is all packaged correctly.

LPE: How many derivative chips do you need to get these days to make it economically feasible?
Browne: At 28nm the cost is about $80 million. How are you going to get that back?
Janac: People who make wireless chips are spinning them off into automotive and home gateways, so you wind up with seven to 10 derivatives for a successful platform.
Browne: In some cases a subsystem is re-used, in others it’s the same chip.

By Ed Sperling
Low-Power Engineering sat down to discuss billion-gate design challenges with Charles Janac, CEO of Arteris; Jack Browne, senior vice president of sales and marketing at Sonics; Kalar Rajendiran, senior director of marketing at eSilicon; Mark Throndson, director of product marketing at MIPS; and Mark Baker, senior director of business development at Magma. What follows are excerpts of that discussion.

LPE: What are the big issues we need to contend with in billion-gate designs?
Rajendiran: Billion-gate designs are no longer a fantasy. We can do that at 28nm with a 20 x 20 mm chip. But just to put this in perspective, when we first sent a man to the moon they had three computers. The power and the memory those three had together was less than we have in a phone today. So the question you have to ask is are your really putting that to good use? And from a business perspective, will it work when it comes out and who can help across the business value chain?
Baker: We’re approaching billion-gate designs in the GPU or microprocessor area. In the SoC area, we’re approaching about 100 million gates. In the next generation, we’ll see SoCs with quad cores. Beyond that, there will need to be some very significant changes in what kinds of applications we can apply those to and how we’re going to deal with the power aspects. These will most likely be in the mobile market and we’re going to have to deal with system-level issues like verification, battery life, and power. From an EDA perspective we’re on track for capacity and for some of the turnaround time, but power will need some of the focus.
Throndson: Process migration hasn’t continued to scale forward. We hit a performance wall years ago. Power hasn’t scaled, either, as we reached some of the smaller geometries. Area is the one piece that is scaling better, which enables these large numbers of gates. The keys here are systems integration and multicore processing horsepower.
Browne: When you look at design costs for billion-gate designs you have to look at the markets that are going to drive them. The mobile market has enough volume to handle the cost of these types of designs. It also has a lot of parallelism and concurrency because there is a lot of functionality, and there are a lot of different use scenarios. Traditional EDA is scaling so it can take advantage of this—traditional designs partitioned at a chip boundary in a way that fits well with the system architecture. That’s probably where 80% of us will see business opportunities. The other 20% is where you take a design and partition it across two chips. Their bigger challenge is on the tool and the architecture side and the ability of semiconductor and system companies to manage that level of complexity. When you scale to four or eight cores, there’s a huge amount of parallelism and on-chip memory. The issue we see is how you get that right, and today the solution is a lot of subsystem design. LTE radios are a good example. We’re going to replace GSM radios with LTE radios. They’re going to be 15mm of area and have a half-dozen DSP cores, but it’s going to be a standalone system that allows you to do verification, have a known good block, and which is characterized with the others. But you can’t do this as a billion gates at the top level.
Janac: What I have in my house isn’t a personal computer. My phone is a personal computer, and it will have everything I need in terms of data, family photos, passwords and payment systems. It’s more like a supercomputer and it’s going to be the driver for the billion-gate design. You’ll need storage and the computing power to make this a true PC. There are four criteria for this. The first is processing power. We’re going to have to go to many cores, so you’ll need cache coherency to utilize those cores from a programming perspective. Another key is integration. How do you bring these cities of silicon together, which is where the communication system for the SoC becomes critical? You also need partitioning. As you build more and more functions, those functions have different dynamics. The modem has to go through SoC evaluation, so it’s on an 18-to-24 month cycle, whereas the efficient digital SoC people are going to be on an annual cycle. You have to decide whether you’re going to put it on one die or multiple dies, whether you can stack the functions, and whether you can mix processes in the same dies. The partitioning and the support for the partitioning are going to have to be there. The last part involves the cost of the hardware and software. The hardware cost has been increasing slowly but the software has been increasing rapidly. So how can you use the hardware and the parameters in the hardware to lower the cost of embedded software, if not the operating system?

LPE: Will an increase in granularity in designs, in terms of various core sizes, wider I/O and multiple cores and processors, affect how we build these devices?
Janac: We’re going to have tremendous power, but we’re not going to be able to afford to keep it all on. When you’re doing graphics the GPU will be on and the rest of it needs to be shut off. For audio it will be the same. You need to be able to manage turning on and off of this functionality. And in terms of 3D silicon, some of the high-power parts of the chip such as RF and some of the modems probably need to be on a different die and connected through wide I/O and TSVs (through-silicon vias). These things will need very intelligent and capable power architectures. While you have more transistors you’re still dealing with the same power budgets.

LPE: Won’t it be even tighter budgets? In 3D stacks, the dies are actually thinner?
Browne: The terminals are better in those packages, though. Even though the dies are thinner there is a lot better coefficient with the bonding. But it’s still a problem.
Throndson: But the power source is not scaling with the demands.
Browne: We’re seeing designs today with a dozen to 100 power domains. Those are at 40nm. We have customers starting 14nm designs now. You’re going to have to move to abstractions. There are 1,000 voltage domains. Somebody will have to have a product that generates the HAL (hardware abstraction layer) of software. We generate RTL. Generating RTL and C code are not that different. That’s where you’re going to see a lot of growth in the supply chain.
Rajendiran: If you look at 130nm, we used to have one type of transistor. Now we have multiple types of transistors and different process flavors, which add a level of complexity. You now have a whole bunch of different libraries, depending on which type of transistor you use. That’s an opportunity and a challenge. How are you going to pick and choose your implementation? Then you throw in a billion transistors, and you’re talking about putting it into a single SoC. It’s going to cost a lot of money and you don’t even know if you’re taking the right path to optimize power, performance and the market. And most of it is driven by consumer markets where each person will use a device differently. What you put on the chip affects battery, performance and even leakage. There are great opportunities, but it’s also more complex. It comes down to who can you partner with for the software, for planning the product, and for implementing the chip in hardware. And it really needs to be tied together so you hit the product introduction times.

Low-Power Engineering examines hurdles ranging from power to cost in billion-gate IC designs with Arteris; Jack Browne, senior vice president of sales and marketing at Sonics; Kalar Rajendiran, senior director of marketing at eSilicon; Mark Throndson, director of product marketing at MIPS; and Mark Baker, senior director of business development at Magma.

Low-Power Engineering sat down with Marco Brambilla, ASIC design manager at STMicroelectronics; Charlie Janac, president and CEO of Arteris; Mike Gianfagna, vice president of marketing at Atrenta, and Javier DeLaCruz, director of semiconductor packaging at eSilicon. What follows are excerpts of that discussion.

LPE: Is concurrent design strategic—meaning is it done at the architectural level—or is it tactical across all phases of the design?
Gianfagna: You need both. That’s the bad news.
Brambilla: The tactical portion of it is possible today, but I have no idea how to do it strategically. Nobody is writing machine code anymore. It’s not efficient. If someone wrote Windows in machine code it would be a 1 megabyte executable instead of a 1 terabyte executable.
Janac: It would never get done. At Cadence for years we were trying to catch Calma, which was the leader in layout. They had 4 megabytes of RAM and they were running on a 16-bit minicomputer. And they were more efficient until the Sun 260 generation, which had 256 megabytes of memory, but Calma could never get off the Eclipse. You’re trading off use and configurability vs. time to market. If your cost is too high and you’re too inefficient you will not be competitive. On the other hand if you’re too efficient and make the last optimization of hardware you’ll never get done and you’ll lose the market.

LPE: Going forward, if time to market and standardized IP are essential, do we have the expertise to do concurrent design?
Brambilla: With different IPs, you have the problem of porting. You may have a piece of IP that works beautifully on a 65nm process. TSMC’s process will not be that different from ST’s, but you still have to port it to make it work. That’s a problem, because you have to face all the implementation steps. Today we don’t have the tactical portion done well enough. People need to know about certain coding styles or electromigration issues. That’s the tactical portion. The strategic portion is what you can do so people don’t have to be concerned about it. If we need to distribute a bus, we have to almost do the buffers by hand. There will always be certain areas where you need the expertise of people who have done it. But I’d rather have someone who understands what areas need to be addressed rather than have to deal with every portion of the design.
Janac: When you want to synthesize the network of a bus you don’t want to do it by hand.
Brambilla: Or if I know that is a peculiarity, I can deal with that, as well.
Janac: But if you look at the strategy of Synospys, they’re on the right track. They are packaging the IP, and someday they’ll package it with their tools so they wind up with a system where you can do that kind of analysis at the architectural level. But it’s going to take a combination of tools and IP. When you’re at SystemC level, how good is that analysis going to be? It won’t be very good unless it’s dealing with the USB 3.0 model or the network-on-chip model or the actual ARM model. You’d better have those models and they better come directly from the IP.
Brambilla: If I go to a vendor and they have the 32 L and the 32 G, which one do I choose? I have to make a decision at that level because if I choose the wrong node I might not be able to mix them. There will be vendors that will offer an L and G process and others that will offer an LG. I can kill myself with leakage or performance.
Gianfagna: We’re describing an interesting change. Picture a funnel, which is wide at the top and narrow at the bottom. In the bottom half, concurrent design is so hard in terms of balancing the physical effects, the variability and the integration effects that there are a small number of companies capable of dealing with that and build a chip that yields and works. But how does that small group of companies serve what’s above them in the funnel? The answer is some number of architectures that work, and then add in enough programmability and variability. The bottom of the funnel is a small number of companies that understand how to go from gate architecture to silicon. What’s above the funnel today—a large number of fabless semiconductor companies—they go away. What those people do then is to figure out how to add their own customization, whether it’s in the form of FPGA programming files or interesting ways to build a 3D stack and software. These increasingly will be software companies. The hardware will be an assumed thing.
Janac: The problem is that the top of the funnel is feeding junk into the bottom of the funnel. How do you get that knowledge from those experts into the front end of the cycle so you don’t get junk?
DeLaCruz: Yes, by the time they get it it’s too difficult to change anything. There are tradeoffs we make on IP selection. Sometimes high-end IP has a pre-set bump assignment on it, such as SerDes. That will dictate what stack you can use. Maybe going to a different performance can change the economics. There’s no way an EDA company can figure out what those tradeoffs are going to be. Or if you make other tradeoffs like increasing the amount of capacitance on a chip so you don’t have to put that capacitance in the package or on the PCB. There’s no one tool that considers all those different things. Or if I make this one tradeoff my power will go down, but I may be going to a process that has more leakage. These are the kinds of tradeoffs you need to make very early on. Do you go system on chip, network on chip or system in package? There are different tradeoffs. It’s a combination of expertise and resources.
Brambilla: I totally agree. To solve that you don’t need the packaging expert. You need someone with a vision of the final device. When we start we need to know this thing has to go on a PCB. If I use a package that’s too small it may save you $1 on the package and cost you $20 more on the board.
Gianfagna: The system-level engineers and architects are the guys at the top of the funnel. I would argue those people can’t worry about all the issues we’re talking about. They’ve picked a package and a set of silicon and a set of programmability, and now they’re trying to figure out how to use that effectively. That might be programming an FPGA layer in a stack. It might be choosing a different memory because there are a few that are pre-qualified. And then there’s a lot of application software that needs to be run on this. Those are the decisions that are made at the top of the funnel. The minute you start factoring in the technology node, you can’t get there.
Brambilla: There are limits to that.
Janac: People are starting to figure out the software and functionality use cases, and then they’re starting to figure out the hardware that supports those use cases.

Low-Power Engineering sat down with Marco Brambilla, ASIC design manager at STMicroelectronics; Charlie Janac, president and CEO of Arteris; Mike Gianfagna, vice president of marketing at Atrenta, and Javier DeLaCruz, director of semiconductor packaging at eSilicon. What follows are excerpts of that discussion.

LPE: Is there cross-training going on to allow for concurrent design?
Brambilla: Yes, but the first step is that you need the teams to know what’s available. That includes training the managers and having good internal discussions and distribution of knowledge. At the initial phases you need the packaging guys in. You need the test guys in because if you put in an embedded DRAM and it takes three minutes to test, that’s not an option. We have the packaging, test, the back end and all the functions.
Janac: Do you have people in ST that are responsible for the overall methodology?
Brambilla: Yes. It’s a little more bottom-up, though. We know what kind of ASIC we do. Every division in ST has a more functional approach because we do it all. So we have central R&D that goes with a reference flow and tools. And inside the divisions we have dedicated people who think about what is the best flow to implement what we do. But design teams no longer have time to think about why they should invent the next clock distribution? I want someone to tell me that with this kind of complexity you go mesh.
DeLaCruz: Are you doing the same number of tapeouts now as in the past?
Brambilla: No.
DeLaCruz: So here’s the problem. No one is doing nearly as many tapeouts now because what used to be $100,000 for a mask set is now $3 million.
Brambilla: That’s not the big issue. The big guys with 60% or 70% market share don’t care about the cost of a mask set. The problem is productivity. You need 4x productivity at each new node. I had an ASIC at 65nm with 25 sub-chips, and every piece of this thing was different. So we will need 100 sub-chips for the next version at 22nm. It’s not the $1 million or $3 million for the mask sets. It’s the $40 million or $50 million to develop the ASIC.
DeLaCruz: But there’s also the issue of having all these high-end specialists around. If you’re going from 25 chips a year to 4 chips a year, then you have all these people who are going to be intensively involved in the chip for five or six weeks. You can’t have that. It’s going to drive the need for cross training and concurrent design. You can’t align things vertically anymore. You need broad levels of expertise.
Brambilla: I hear what you’re saying, but the big issue we’re seeing is productivity. We don’t have people idle because they’re doing fewer chips. To do those four chips today I need the same amount of people, plus some more, that I needed to do 16 chips at 65nm.

LPE: Where are the biggest problems in concurrent design? Is the software and hardware, verification or something else?
Janac: It’s basically about wires and gates. The gates scale but the wires don’t, so you need a better way of managing the wires and assembling the SoC. You can’t afford to re-do all of them in the next generation, so one of the big issues of IP re-use is how you support the protocols those subsystems communicate in, how you get them integrated easier into the next generation of the chip. It all comes down to architectural improvements to get to the next generation.
Brambilla: The next time you do a chip you need more bandwidth. Your Verilog is probably useless—or at least it’s not efficient. It was efficient when you designed it in that node. If you change the frequency there’s a problem.
Gianfagna: You’d need to change the microarchitecture, which is hard to do with Verilog.
Brambilla: Yes, so you’re redesigning it. To me there is a big issue every time you change from software to hardware, which is co-development. When you go from RTL to the physical world it’s more co-development. When you go from silicon to the package that’s more co-development. It used to be more than just separate islands. They were like separate continents. But the infrastructure today doesn’t help you as much as you need to increase productivity. I would need to move people just to describe the algorithms and have some tool generate the RTL, but that tool should generate the RTL knowing there are physical constructs. The RTL should be able to predict power and congestion issues. Today we have problems of power integrity because at 32/28nm and 22nm the density of the gates cannot be supported by the power grid.
DeLaCruz: What if you use two pieces of silicon instead of one? How do you deal with your structure then?
Brambilla: You can only handle that at the top level. This is something that requires training. It may make sense to do 5mm square on both ASICs and create more efficient communication between them. It costs more, but it may shave three or four months off the development time.
Gianfagna: What you’re describing is the need for better methodology with a globalized company and more localized infrastructure to use those resources. ST is a big enough company to have the resources to make that work. But what about the guys who don’t have that luxury? There are a lot of fairly large fabless companies that don’t have infrastructure to allow that to happen. How are they going to get to this new level of integration and new way of working? That’s a big challenge.
Brambilla: I know of five companies today that do ASIC services through the fab.
DeLaCruz: But ASIC services can be another island, unless they’re totally integrated with their supply chain.
Brambilla: It’s a huge problem.
DeLaCruz: Historically, there were design services for chip layout and packaging services. You can’t isolate those. It’s easier to get people to overlap in the same company. It’s really difficult to get people to overlap in different companies.
Brambilla: That’s why ST decided not to go fabless. At 20nm, if you don’t control the process how are you going to tune your back-end flow? How much does it cost to run silicon at a third-party fab to verify if your mesh clock tree or H-tree work?
Janac: But don’t the big guys have process teams? Guys like Qualcomm are basically running their own process.
Gianfagna: Yes, and if you look at their org chart you’d swear they own a fab.
Janac: But what you’re saying is that’s not the case with medium-sized companies, right?
Gianfagna: Yes, there are a lot of those companies.

LPE: In 3D stacking you may have a platform developed by a large IDM bolted onto something else. Does that work with the existing players and infrastructure, or do we need to re-think the design process?
Janac: If the bridges are well defined, you can make that work. You can envision an analog die in 90nm and another die in 22nm going to a memory. As long as the way it comes together is well defined, it should work. I don’t see another choice. Otherwise these mid-size companies go to FPGAs, or they become IP providers, or they die.

LPE: What you’re talking about is concurrent design across an ecosystem, not just within a single company, with a focus on everything from interoperability to power.
Janac: That’s right.

LPE: But it’s never been effectively done.
Janac: Companies like ARM can organize an ecosystem across multiple generations of products and multiple companies. We need to see more of that. If someone defines a 3D silicon methodology it can work. There aren’t other choices. A small guy cannot afford to make a 22nm chip. They may be able to go to a company like eSilicon, but there won’t be enough capital around the small and medium-sized guys to go to the latest nodes.
Brambilla: If you’re a startup, you need to prove your technology. If you’re lucky you can prove it at 90nm and then you hope you can be bought. If you’re trying to prove it at 20nm then your best bet is to be part of another company’s mask set. If you’re very small, you might have to wait until there are enough contributors to that mask set. It is true that you also need the ecosystem outside, and you will need some way of describing that—almost a super version of IP-XACT. But inside the ASIC we need to start solving the need of automating the tradeoff analysis. I want people to stop writing Verilog and algorithms, and then use a tool chain that allows them to converge toward silicon in a way that avoids all the issues you deal with today.
Gianfagna: You’re describing a top-down design methodology that comprehends hardware-software co-design, partitioning and physical implementation issues, and which balances it from the algorithm all the way through. That’s a great vision. But an alternative vision is that it’s too hard to do that. What if you come up with a hardware-based design flow that targets a large market with the ability for customization in software, and then you build a chip to address that? Now the co-design problem becomes, ‘Which architecture is most compatible with my software?’ I can just use that chip and customize the software. We’ve been predicting this for a long time, namely that all the differentiation becomes software.
Brambilla: We do have some progress in that direction. I see it as an intelligent way of attacking certain markets. I don’t see it in the switching market or cell phones.
Marvell designs a chip set, throws functions into a chip set, and they give it to Nokia or whoever they like.
Janac: Their volume is just barely enough to stay in that business.
Gianfagna: MediaTek has a similar strategy and they’re selling into the Chinese market.
Janac: But their stuff is highly optimized.
Gianfagna: That’s true. But the cell-phone market and the smart-phone application are very similar. We have 3G, 4G and a way to deliver the video. We have Wi-Fi. That all gets standardized. So the way that ‘Vendor A’ differentiates itself from ‘Vendor B’ is the software interface and maybe some clever stuff with touch screens. It’s more mechanical.
Brambilla: In that space I agree with you.
Janac: I don’t. One of the things that’s happening is we are in a computing architecture switch, from PC server to the cloud. What people have gotten wrong is those edge devices will need to become extremely sophisticated. The cloud will not always be available and you will need that sophistication to take advantage of the information that’s in the cloud. So those devices are going to go through a huge amount of innovation and become way more powerful than today. It may take several years but it will happen.
DeLaCruz: If you’re very highly standardized, you can probably program software to make some tradeoffs for you. When you’re dealing with a wider range of chips with analog content and some interface into memory you’re dealing with very different problems. I don’t think I would trust an EDA tool vendor to think of all these different options. They’ll implement certain things, but they’re going to be behind the curve by at least a year.
Janac: With the physical layout the tools were driven by design rules. But at the architectural level you really need IP. Without IP the tools do not have any reality. We’re going to see a combination of tools and IP at the architectural level. Without IP, ESL is a $50 million market. On the other hand, if you have the tools and the IP you can generate a lot of value. ARM cores will come with tools. Our interconnect will come with tools. The memory controllers will have tools. You’re going to see a unification of IP and EDA at the architectural level.
DeLaCruz: At that point in time the only options you’re presenting yourself with are the ones the IP vendors are giving you. It’s limited. But stepping back and taking a higher-level view, there may be a different way of looking at this problem.
Janac: The economics are forcing each company to build its own IP that’s core to its value. Otherwise it’s too hard to be too competitive across all IP and 60 subsystems. You have to pick from a menu of IP to build those parts of the chip that economics don’t allow you build yourself.