By Ed Sperling
Low-Power Engineering sat down to discuss IP integration issues with Ken Brock, senior staff product marketing manager for logic libraries in Synopsys’ Solutions Group; Kalar Rajendiran, senior director of marketing at eSilicon; Mike Gianfagna, vice president of marketing at Atrenta; and Jim McCanny, CEO of Altos Design Automation. What follows are excerpts of that conversation.

LPE: Who’s going to be able to play in the IP market?
Brock: As we get to smaller geometries it becomes a rich man’s game. It’s like Larry Ellison and America’s Cup; 28nm is very much like that. Tapeouts are expensive, variability is up, and you need consistency. Being able to have the IP that’s made in a consistent fashion is essential. Standards are driving some of that. Having the Liberty TAB, CPF and UPF are important. But how much verification do we really run before it’s done? How big is your SPICE farm? And customers are saying that rather than going to a large number of IP providers, they’d rather go to one. It’s one throat to choke.
Gianfagna: We’ve been selling Spyglass for years, but half of what it’s being used for recently doesn’t have anything to do with design. It’s for discovering what’s in IP that has been bought and trying to figure out what’s wrong with it and how to fix it. It’s discovery and improvement. If you have a tool that can optimize a design it also can tell you what’s wrong with it. That’s a new application. If you can figure out ways to better assess the quality of IP, it may be a trigger for how the industry can grow. That may help the small companies play in this market, too.
McCanny: Most of our efforts are focused on standard cells. There is a myriad of things you can do and you can’t do them all, but what is the best choice? It would be bad for the industry if we killed the innovation of the little guys. A lot of these little guys can become the big guys later on.

LPE: Is the future the little guys, or is it platforms of re-usable and integrated IP?
Gianfagna: It’s both. The market resists being homogenized. The more you get standardized platforms—and you will, because the complexity is going up and the number of tapeouts is going down—the more the market will provide differentiation. One change is that the startups will be more software-oriented rather than hardware-oriented.
Rajendiran: If you have a chip and 90% is standardized, there is less chance for differentiation. That’s one of the reasons software is taking off, but you also can’t do everything in software. Verifying the software is actually more complex than if you have well-defined operating and power modes in hardware. So hardware is still important and the IP is important. But to a large extent, the off-the-shelf part needs to be addressed by the big companies. The smaller companies need to come up with whiz-bang innovation. We still need small companies, but they have a challenge with the foundries on one side and the customers on the other if all they’re doing is the same stuff as the big companies. There’s a place for everyone, but to be successful they have to play their role. Even TSMC tried to do IP because they thought they would have better control if they did it themselves. That wasn’t the case.
Gianfagna: It’s an ecosystem, so everyone has to play their role and there has to be glue between these roles. For a long time, EDA has played a role of enabler for the end product for someone else. They’ve been a silent partner. EDA can be an enabler for business. If we’re right about the need for better validation and better incoming inspection of IP, whether it’s at the transistor-polygon level or the synthesizable RTL level, then EDA can become an enabler for the IP industry and collaboration across the ecosystem. It’s EDA providing value at a different level.
Brock: That’s correct. People are now using Spyglass to look into the black boxes. They used to build the black boxes before and it was good for that. If 70% or 80% of an IP on a chip is bought, it’s a different use. As an IP provider, we’re seeing that in different areas. There are natural places for standardized interfaces. There’s a committee that defines the standards, and you’re not going to differentiate by doing USB 2.0 or 3.0. You just have to have it. That’s a very natural place to play in the IP industry. What we’re seeing now is more of the vertical integration—what we’re calling IP subsystems. If someone needs an analog front end for a digital TV, you’ll have cells and memory but you also need a processor that does audio and soft codecs. But sometimes you also a hard analog codec. That’s where a lot of innovation happens. This can be done by small companies and they can become very successful.
McCanny: TSMC tried IP and they still have it, although they’re de-emphasizing it. EDA has picked up the baton. But do you think that’s the right place for IP? Is it so complex that you need to have the collaboration with the tools supplier to build it and validate it, or are we still in a world where IP and EDA are separate?
Brock: We used to be pure-play IP (at Virage Logic, now part of Synopsys). Now, working with all the EDA vendors and supporting mixed flows, I see a better need for collaboration. We need to be able to see into modeling. For the validation part, being able to pound on the IP for more corners and stress corners is important. But it still has to work with mixed flows.

LPE: Is an integrated EDA/IP company better?
Rajendiran: The EDA companies can have unlimited access to verification tools, whereas an IP company needs to buy the tools. But that doesn’t solve the problem. You have to work smarter. When you’re verifying something, how do you know you’re verifying the functionality correctly and have the right use mode? An IP company and an EDA company combination don’t make a product company. That domain knowledge needs to happen on a larger scale.
Gianfagna: It’s a good thing IP is migrating into EDA because you do have access to the tools. An IP release is a combination of careful program management, validation, ensuring all the parts are there. That’s all good. There’s a bad part of this, too. The IP industry has been able to have higher multiples than EDA and sell at a higher value. Let’s hope that EDA doesn’t mess up the IP industry and that IP can teach the EDA industry. The EDA industry is not known for its ability to get value from its investment.
McCanny: There is also the danger that because the multiples are so much higher in IP that EDA margins will shrink further because it will be packaged with IP.
Rajendiran: Give or take a half-billion dollars, the EDA has remained at $4 billion for a long time. The semiconductor industry is about $300 billion. If the married IP plus EDA can get even 2% of that, it’s a lot more than what’s available now. IP becomes part of the chip and it ships for many years, so you can deliver the IP and get a piece of that. With EDA, for all the hard work that goes into the tools, after tapeout there’s no more interaction.

LPE: Don’t the dynamics change? In the future you won’t be able to separate out the IP, the software and the hardware. The market may be bigger.
Gianfagna: It will definitely be bigger, and EDA companies can get a lot bigger along with that if they participate in that larger market.
Brock: That will be even greater if we get involved in the application software, the EDA, the IP and the software enabling the technology to make it all happen.
Gianfagna: They all become part of the mix. More of the differentiation will be in software and that’s going to require careful design and marriage to the hardware. That’s a new model. Right now we build a chip, throw it over the wall and say, ‘Make it work.’
Brock: That’s where a lot of the processors are making that easier.
Gianfagna: They’re enabling that model.
Brock: With a smart phone you’ll have one ARM core running the baseband processors, but there might be four or five ARC processors running the surround sound and the audio and a lot of these smaller applications. These are lightweight embedded cores that are buried on an SoC that can be programmed.
Gianfagna: The other opportunity is the platform. It’s a collection of IP that works together in a certain way and which can be modified predictably. There’s a lot of EDA in that. So is there a way that EDA companies can collaborate with semiconductor companies on the back end to make all of this happen? It’s a whole different model for EDA, which is in my opinion a healthier model.

By Ed Sperling
Low-Power Engineering sat down to discuss IP integration issues with Ken Brock, senior staff product marketing manager for logic libraries in Synopsys’ Solutions Group; Kalar Rajendiran, senior director of marketing at eSilicon; Mike Gianfagna, vice president of marketing at Atrenta; and Jim McCanny, CEO of Altos Design Automation. What follows are excerpts of that conversation.

LPE: What is the big issue in IP these days?
Brock: Quality, quality and quality. There are people wanting to use it out of the box and it has to save them a significant amount of time and effort, or else they can build it themselves. It has to follow the function and specification that’s there, and it has to be robust. We don’t live in a perfect world, of course. The silicon does have variation, and it’s getting worse at every node. Getting something to work the first time and everytime is a challenge. That’s the big issue.
Rajendiran: Quality is obviously important, but the high-level issue is the disconnect between the users of IP and the builders of IP. Customers want a certain thing from a technical or a business perspective and suppliers want it a different way. The fact that market cycles are becoming shorter has aggravated that situation even more.
There has been a lot of consolidation over the past two years, which has actually helped things. But disaggregation means that everyone wants to start their own IP company, and they all try to go too broad, so quality suffers. That is really the big issue.
Gianfagna: We could have had this discussion 15 years ago. In the 1990s IP re-use was a big problem. This problem has been around a long time, but somehow in the past year or two it’s hit an inflection point and it’s now more serious.

LPE: Is that because more companies are using off-the-shelf IP?
Gianfagna: It’s more than that. A tipping point happened in the last year or two. We went from chip designs being original work with some IP integrated to a chip design being 90% IP, and hopefully you pick it right. Now the IP quality issues really start to bite you. If you pick bad bricks to build the building it falls down.
Brock: The timing you picked is right. Something changed in the past 24 months. Wafer shipments went to about a third of what they were. Everything dried up. But a lot of the people running the fabless companies and the IDMs needed to scale back. They began to really consider outsourcing the IP they had been talking about for 10 years because that wasn’t their value add.
Gianfagna: Our industry always changes in the bad times.
McCanny: Those points are valid. There’s also shrinking time to market and low power. People can live with the methodology they had for IP re-use. It wasn’t perfect but they could make it work. But with low power coming along in all the portable devices they can’t do that anymore. People need their IP models in a certain way at a certain voltage. Voltage is not linear or predictable, like timing is. Power effects are non-linear. So all of a sudden people are demanding all these different views and corners, and it’s impossible for the IP provider to ensure quality across such a wide range that customers want these days. It used to be a chip had a single voltage. Now you want to play around with voltages depending on the application. Those have made the problem more acute than what it has been in the past.

LPE: IP has to be both power-aware and proximity-aware. How do you deal with that?
Brock: That’s true. And on top of that there are many different ways of doing things. Smart phones get hung up all the time. You have to take out the battery and then start it again. It doesn’t know what power mode it’s supposed to be in. At least ‘off’ is a known state. All the other states have to be simulated and retained in the models we create.
McCanny: The compelling vision of IP was that it was a black box. You didn’t need to know all the details about it. You could plug it in and it would work. You didn’t have to have core expertise with an interface, for example. Now it may work under a certain set of environmental conditions, but it might not work if it’s next to this. Or maybe it will only work at this voltage if it isn’t switching over from another voltage. All of that brings pressure on the acquirers of IP to become experts in the IP they’re getting. So will the pendulum start swinging the other way?
Gianfagna: That raises an interesting point about whether the little guy is destined to fail. If I have a piece of IP checked out for a certain set of applications, voltage domains, frequency and configuration, the IP provider says it works here and therefore it should work everywhere. It doesn’t work everywhere, and that’s a problem. So are people going to demand from their IP supplier that it be checked and validated across a broad set of applications and certified by someone—most likely the supplier of the IP? If that happens there will be a few very large, multinational, multibillion-dollar suppliers of IP. It takes a lot of resources to stand behind something with that much validation. It’s not easy to do.
Rajendiran: Even if it’s a big company with a lot of resources, they still have to pick the first few customers and make sure all the use cases are addressed. They can’t address the broad market because of economical reasons and bandwidth. And the one they support initially won’t allow them to support everyone else because they’ll lose their competitive edge. So there’s a built-in conflicting requirement. I don’t think everyone will try to build it all themselves. There’s a ceiling on the cost, and by taking on everything yourself the only way to do that is to increase your resources. The market won’t allow that to happen. Collaboration will be the key. And it won’t just be two companies. With the soft IP you want to collaborate with the end customer. With the hard IP you want to work with someone who tapes out designs. They need to understand all the IP blocks from different vendors. The ones implementing that day in and day out are the ones who understand that best.

LPE: All of this depends on a much more tightly integrated supply chain. How realistic is that and who’s going to drive it?
Rajendiran: As we go through these cycles, one thing that has consistently gone in one direction is the focus on performance, area, and now power. There are various ways to address that. If 3D stacking takes off, people are going to leave certain blocks at 40nm because they know it works. You get the benefits of cost and you can integrate it quickly. We have gotten so much more performance out of these chips we don’t need anymore. There are several things changing to make this happen. One is consolidation. The second is the TSV (through-silicon via). And the third is that if you mess up at 28nm it’s a much bigger deal than in the past. Collaboration will happen.
McCanny: The large IP companies can only collaborate with so many of their customers. One of the perceived advantages of small companies is that they have a particular expertise in a small area, so they get 90% of the IP from other companies and add their own expertise. We’d all like to see that. We’ve seen some small startup chip companies get picked up by companies like Apple. It would be bad for the industry if we couldn’t serve that market. But there are definitely challenges because until you get to a certain size you can’t get enough collaboration. Our initial mission was to build models for IP providers. Now we’re starting to go more with IP users. They say, ‘I’ve got these models from different sources. I don’t know how to put them together, but at least I can run a tool to help me understand whether these models make sense for the process and voltage I’m using.’ That requires more cost on their side and to get more in depth with the IP to understand why certain anomalies occur and why things only work at certain voltages. It’s not easy and the problem is getting more difficult rather than simpler.

Low-Power Engineering takes a poll of the big problem with IP and how to solve it from Ken Brock, senior staff product marketing manager at Synopsys; Kalar Rajendiran, senior director of marketing at eSilicon; Mike Gianfagna, vice president of marketing at Atrenta, and Jim McCanny, CEO of Altos Design.

By Ed Sperling
Low-Power Engineering sat down to discuss timing constraints with ARM Fellow David Flynn; Robert Hoogenstryd, director of marketing for design analysis and signoff at Synopsys; Michael Carrell, product marketing for front end design at Cadence; Ron Craig, senior marketing manager at Atrenta; and Himanshu Bhatnagar, executive director of VLSI design at Mindspeed Technologies. What follows are excerpts of that conversation.

LPE: Will it be economically feasible to continue working on tools in this area for fewer and fewer customers?
Flynn: One thing we’ve been working on, which may end up in a product, is based on, if you start something and it doesn’t work you can recover. We have customers who are experts in yield and other customers who are much less expert and would love help in that area. They don’t have tools to analyze and build. Maybe we can get to the stage where you can work in a more conventional design flow and still work.

LPE: That’s a lot of the momentum behind 3D, right?
Flynn: Yes, but this would be more in the conventional flow.
Hoogenstryd: You’re talking about self-adapting circuits?
Flynn: Yes. If you’re not failing you may have overdesigned it. But you do have to adapt it.

LPE: Are we redefining failure, as well? Is it a chip that doesn’t work according to previous models or one that doesn’t work according to a different set of standards?
Flynn: This is parametric failure where you’re not quite where you hoped to be. Failure is coping with the very first errors creeping in. I think the terminology is error-resilient structures.
Bhatnagar: For everything you’re building redundancy.

LPE: But you can’t do that anymore at advanced nodes, right? You kill the power and performance with that approach.
Bhatnagar: That’s a big problem. We’re using an ARM A9 and trying to get to 1GHz. Performance is one problem. Power is another. The other thing is variability. Filler adds more complexity into your timing closure. That comes at your end stage and then you have to extract it. The volume of data becomes so large there’s no way to deal with it. If it’s a small chip it’s okay. But with 13 x 13 at 40nm, there’s no way to deal with it.

LPE: Is there an acceptable failure rate?
Bhatnagar: We budget by using uncertainty and OCV (on-chip variation) factors. The chip grows, power grows, everything grows.
Craig: Or you run multiple back-end tools until you get the answer you’re looking for.
Bhatnagar: Today there is no real solution for it. If you ask what margin you should use at a particular node, there’s no quantifiable number.

LPE: So what is good enough? That seems to be changing.
Bhatnagar: Every transistor is behaving differently. OCV has changed to AOCV—advanced on-chip variation. People have taped out using this and it seems to be working. The penalty is you have to create thousands of tables.
Hoogenstryd: That’s better than creating the library to run them.

LPE: Who gains control out of all of this?
Craig: The foundries are the only ones who understand it well enough to make it work. It’s like a vendor putting their engineers on-site at the customer location to make sure they do the right job. That’s a trend I see continuing. The vendor does 90% of the flow.
Bhatnagar: Timing wise, the foundry drives all these numbers. This is what you must have.
Craig: But that said, they can’t do it alone.
Bhatnagar: They do the test chips.
Flynn: Unless you can build IP that can adapt itself. That’s what we’re trying to do with less-expert customers.
Carrell: That’s very valuable to people. If you can get help integrating IP, that’s more valuable to a lot of customers than flexible IP.
Flynn: It is attractive, but the delivery is hard.
Bhatnagar: Ideally I want to have silicon-proven IP right up front. But I don’t want to be the first one because then I have to compete with TI. So I go with unproven IP and take the risk and my yield is terrible. So at 40nm you’ve burnt $3 million just in mask costs.
Flynn: And it gets harder and harder to get timing closure with a revised model because everything is getting so complicated.
Bhatnagar: That’s absolutely right. At 40nm version 1.0 of my chip ran pretty well. When I got back version 1.2 it ran 20% slower.
Flynn: But it might yield.

LPE: As a percentage of the overall chip design, how much is timing closure?
Hoogenstryd: It’s getting smaller as a percentage, but that’s only because everything else is growing. Timing closure has always been the leading problem for the biggest customers working on high performance. But everyone now has to wrestle with issues they didn’t have to deal with in the past. Power is part of the equation whereas it wasn’t in the past. If the power is growing, timing will decrease. But in absolute time it’s increasing.
Flynn: And all of those techniques impact timing.
Bhatnagar: I think timing closure is getting bigger. You have all these massive chips—DVFS (dynamic voltage frequency scaling), ACS, all the UPF-CPF headaches, then your CMP timing closure. When you add it up, it’s about 9 months of work. Your timing closure starts when you’re doing your architecture. Some of the IP like ARM’s is already there. You start with that. Then you move to the next level.

LPE: Are we getting to the point where we can’t push market windows any further?
Bhatnagar: Absolutely.

LPE: So it’s no longer just the cost factor of getting to the next node. Now it’s also the time it takes to get there.
Carrell: The function, the cost and the schedule have always been balanced.
Bhatnagar: Time to market is the most important thing. You may sacrifice something, which is why the number of revs goes up.
Craig: That’s what Apple does.
Carrell: They design it from the application down. The hardware guys are working hard on the silicon, but it’s almost like they’re moving differently there.
Flynn: It’s also helpful if you don’t compete on megahertz. Those headline marketing numbers are not relevant anymore.
Carrell: That’s right, which is why on the box of the iPhone the company doesn’t talk about how many megahertz the processor is inside of it.

LPE: What else affects time to market from the process side?
Flynn: Things like double patterning are having an effect.

LPE: But even at 180nm there are changes to the process involving power. Will we see timing issues there?
Craig: Handling the modes is tricky. How do you merge all your constraints together?
Bhatnagar: It’s not the timing closure. It’s the number of constraints from the various modes that goes through the roof.
Craig: Do you have a pessimistic set of timing constraints in the end? If you do, how do you come up with that? Is it too costly to try to merge everything together?
Bhatnagar: You can have different performance with different voltages.
Carrell: And do you really need to put that in a different voltage? You need to figure that out at the beginning.
Craig: We had one customer tell us that the only way we could solve their timing constraints was to work with them. They were the only ones who knew their process well enough.
Carrell: You can’t just work up a magic formula to say how 17 different modes are going to work together. It depends on the design.
Flynn: For years we’ve been talking about asynchronous, locally synchronous design. You get timing closure in complex windows. We’d love to see more work done in this area.
Bhatnagar: Timing closure starts at the micro-architecture level. How you design your clocking scheme is the most important.
Flynn: And how you provide the overrides.

By Ed Sperling
Low-Power Engineering sat down to discuss timing constraints with ARM Fellow David Flynn; Robert Hoogenstryd, director of marketing for design analysis and signoff at Synopsys; Michael Carrell, product marketing for front end design at Cadence; Ron Craig, senior marketing manager at Atrenta; and Himanshu Bhatnagar, executive director of VLSI design at Mindspeed Technologies. What follows are excerpts of that conversation.

LPE: Do models address timing constraints effectively?
Bhatnagar: No. There’s another problem in the models that we haven’t discussed—the syntax. Let’s say you’ve extracted the timing model and you have a generative clock inside. How do you model that at the chip level? It really depends on how the extraction was done. You have to have visibility into the model itself and how you’re going to define things from the top level. Most failures happen because you didn’t understand what was happening.
Hoogenstryd: There is a challenge with models. Bringing models into the top-level analysis gives you the benefit of the performance-capacity link, but typically those things run faster. Those models are only as good as the context in which you extract or define them. Rather than extracting models you’re better off using timing data from a timing run. Being able to promote that up to the chip level so you have full access to every path is important. Along with the timing data, it saves the constraints. So now you get to see with your real chip context where is your block out of scope. What timing constraint did you use in the block that you’re violating because of the chip-level context? Based on that, you can push in and look in more detail. You may have violated the scope, but that may be okay. If not, you know where to make a directed turn on your design.
Bhatnagar: So you propagate your constraints from the bottom to the top?
Hoogenstryd: They’re available at the top level, yes. You have top-level constraints, timing constraints, and you can determine where they are in violation.
Carrell: That’s in PrimeTime, right?
Hoogenstryd: Yes.
Bhatnagar: So you have full visibility even with hardened blocks?
Hoogenstryd: Yes. You try to address this problem with modeling. Even if it’s hard IP, you’re estimating what the context of that thing will be when it may be used in many different contexts. We’ve seen design teams that know the spec of the IP but they try to push it to the limit, anyway. To meet timing, they violate it.
Craig: They get out of sync at the last minute. You thought you were okay at the block level but you’re not okay at the chip level.
Hoogenstryd: Exactly.

LPE: Which side of the design process is responsible for all of this?
Carrell: We were talking earlier about different tools behaving in different ways. Independent verification is one of the things that might be important because these tools behave differently. PrimeTime is counting the money in the register and doing the books. With constraints there should be independent verification.
Hoogenstryd: The way I look at it is that PrimeTime is the arbitrator. With its usage in the market as the tool they trust for timing, it’s the arbitrator.
Carrell: But people could spend time in place-and-route and find the problem there. They can find it in static timing and synthesis. They can run and run and run with the implementation tools. But isn’t it better to find these problems with a tool designed for that?
Hoogenstryd: That’s why one of the tools we rolled out last year was Galaxy Constraint Analyzer. The front-end team would be responsible for coming up with constraints without knowledge of what synthesis or place-and-route could or could not do. We saw a lot of customers struggling. They were using their place-and-route tool as a constraints scrubber.
Bhatnagar: Out of six months of timing closure, two months you’re scrubbing the constraints.

LPE: Now that the system is no longer just the hardware, how much does software impact this?
Craig: We see it come into play with timing exceptions sometimes because people will set false paths from configuration registers and things like that. When you go through the process of trying to verify those independently, the hardware guy says, ‘I don’t know whether it’s a configuration register or not.’ He then has to find the software guy, and two weeks later you get an answer back about whether it’s too late to use that timing exception. In the meantime he’s stuck with a timing violation he’s unable to fix. The software guys then get sucked into that part of the process.
Bhatnagar: It’s the application.
Flynn: The software may be involved in driving whatever the power state specs are. You need to go back and really validate. It’s very hard to interpret what you have there. There has to be some level of abstraction, though.

LPE: What happens with 3D stacking?
Craig: You have to be pessimistic. You have to isolate one layer from the next. Otherwise it becomes too unwieldy. What happens when I tweak one? What relationship does it have on another one?
Flynn: There’s a brave new hope that memory PHYs are really tight. That’s one of the big problems. The idea that memory I/O is going to be a lot simpler has lots of attraction. There is an upside in all this, but it’s still a long way away.
Carrell: When the handoff happens from the front end to the back end, the constraints start again. How many people are even handing off a placement today? Let’s start with that. You can get physical precision in a tighter cone, which will help you with timing closure. You then can handle 3D modeling forward in a flow and keep some precision there. But we’re having trouble even getting people on board the physical handoff.
Bhatnagar: We are looking at piece parts. We are looking at timing closure by itself, SystemC by itself, and we are trying to solve these problems. All the fragmentation in the industry could be solved with language. Verilog represented functionality. System Verilog incorporated assertions. Again, that’s all about functionality. Why not assertions for timing? You should be quoting timing with functionality. That will get rid of DRC files and handoff problems.
Flynn: But timing is very technology-dependent.

LPE: Don’t you still have to create that language?
Bhatnagar: Yes, and that is the Holy Grail.
Craig: You introduce another variable into the process. It’s either RTL or testbench. If the RTL doesn’t work the testbench has a bug. If you introduce assertions you have the same problem.
Bhatnagar: But when you look at the verification space, a lot of innovation has happened. In timing closure, name one innovation over the past 10 years.
Craig: There is too much trust that the back-end tools know what you’re doing with your timing constraints. That’s the big issue. And the only way to get better is to get more experience, which means making more mistakes.
Flynn: Timing is technology-dependent, but functionality is pretty portable. Do you want to encode the functionality deep inside?
Bhatnagar: About 90% of the constraints can be part of the language itself—especially the exceptions.
Flynn: You can definitely synchronize the clocks.
Bhatnagar: I can code this clock is synchronous or asynchronous from this clock. All these problems can be solved.
Hoogenstryd: It sounds really interesting. If something were started today we might have something in five years. UPF/CPF has taken how long? But the other challenge is that the design approach is very varied. Some companies are top-down while others are bottom-up. Some look at the IP they have and build from there. That approach doesn’t work bottom-up. It may work top-down. Is the front-end guy going to do a better job with this ability?
Carrell: Writing the design at a higher level of abstraction and synthesizing out different flavors of it—this is my low-power on this process, this is my high-speed version on this process.
Hoogenstryd: If we all went back to 350nm this might be possible.
Bhatnagar: I think the industry is heavily fragmented.

LPE: What happens with design for variability? Is it made worse or better?
Craig: It makes it tougher.
Hoogenstryd: There are two camps out there. Some customers are pushing every bit of performance they can get out of their design, whether it’s timing or power. They want all the analysis tools to take into account the third-order variation effects, which puts a lot more pressure on verification. Then there’s the other camp that recognizes there’s variability and they want to design it out. A year or two ago the big discussion was stress. How do you model it? Can you do statistical analysis? One way was to design it out so that filler cells look like dummy cells. They all sort of have the same stress. Then it’s a wash. Either you have to design it out or you analyze the heck out of it.

Low-Power Engineering sat down to discuss timing constraints with ARM Fellow David Flynn; Robert Hoogenstryd, director of marketing for design analysis and signoff at Synopsys; Michael Carrell, product marketing for front end design at Cadence; Ron Craig, senior marketing manager at Atrenta; and Himanshu Bhatnagar, executive director of VLSI design at Mindspeed Technologies. What follows are excerpts of that conversation.

LPE: Let’s define timing constraints.
Carrell: Timing constraints seem pretty simple. It’s an SDC file, but it rapidly grows to become a script that includes all the other tools in the flow. There are first-party, second-party and third-party IP included in that, as well. First-party is something you’re writing. Second-party is what some guy down the hall writes. Third-party is written by someone else, and you’re never sure if it’s good or not. It includes basic timing constraints, but also the exceptions that an expert user would apply.
Craig: You can split design into two halves: What is it supposed to do and what is the performance supposed to be. The functional side is the RTL and all the standard verification techniques. On the performance side, that’s where the timing constraints come into play. What speeds are the clocks supposed to go at, I/O constraints, timing exceptions where you can ignore things? What gets tricky is designers are the ones who understand best where the timing constraints should be, but they’re not the ones who are responsible for them. You seesaw back and forth between back-end and front-end. Back-end owns it, but front-end understands it very well. It’s a tricky one to close.
Hoogenstryd: Timing constraints define the performance and help define the context. It’s an intent to define the context so a design, or a piece of a design, will work in terms of an environment. It’s not only the clock frequency, but what the inputs look like. In terms of challenges, one of the big challenges we see—especially for very large designs—is the timing constraints are split among different pieces of the design. You need to get timing conversion between blocks in the chip. Very often the timing constraints for a block are the best estimate of what the block is going to see from the chip, and often the estimate and reality are quite far apart. That leads to lots of iterations back and forth between block designers and chip integrators.
Bhatnagar: The chip is only as good as your timing constraints. If one line in your timing constraints is off, your chip could well be as good as dead. Functionally you may have workarounds, but if clock frequencies are off you’re dead. Over the years everything became timing driven. Now there are different multi-modes, so understanding and managing constraints is very problematic. In addition to that, different tools understand constraints differently. Even though there’s a standard, no tool follows it precisely.
Flynn: From an IP point of view, timing constraints don’t sound too bad. You have internal challenges building these processes up. Processes always get driven by performance. But people always push it too hard. Constraints are not handled well hierarchically. We can provide constraints here, but then some poor person has to call it all up on a global level. That’s a massive challenge. A few simple exceptions become much more complex. It’s going to get even harder when we get to 3D.

LPE: Is there a lot of finger pointing going on as front-end design meets back-end design and there is more IP being integrated?
Bhatnagar: Big time. I’ve never had problem with ARM IP. But with other IP vendors it’s unbelievable what they turn out.
Carrell: The amount of time people spend integrating IP is massive. It’s probably timing constraints, not just squeezing it into a certain amount of area.
Bhatnagar: You’re absolutely right. I personally spent the last few months taping out a 40nm chip. We had DDR PHY IP from which I had to get the DFI (DDR PHY interface) clock. I asked for latency because my interface depends on it and it should have contained that. It’s not just one IP vendor, either. They make very good functionality, but they don’t understand the whole concept of integration. Within the company there is a gap between front-end and back-end. That’s why every company I know of has Excel sheets.
Craig: I talk to the front-end teams and the back-end teams and try to understand their methodology for timing constraints. In at least 50% of the cases the back-end guys throw away what the front-end guys give them and do it from scratch. They don’t even try. Even with vendors and their customers, pretty large ASIC vendors complain their customers give them garbage in terms of constraints. I’ve seen vendors put their engineers on site with the customer to clean up their timing constraints.

LPE: Does it help if more IP comes from a single vendor instead of multiple vendors?
Craig: With some of the soft IP vendors, they really don’t understand constraints anyway. You’re never going to get something different from them.
Carrell: It’s almost like we don’t have a common understanding of whether IP is ready to be integrated or not. There used to be a standard checklist that got absorbed into a standard body.
Bhatnagar: That’s the SPIRIT consortium.

LPE: That was IP-XACT?
Bhatnagar: Yes, same thing.
Carrell: Every field in that sheet had to be filled out. But that was all voluntary compliance. It’s faded into the background because it wasn’t reliable.

LPE: So who becomes the gatekeeper of IP? Is it the vendors, the foundries, or the customers?
Carrell: If it’s on the shelf and it shows very clearly that it has been validated, then it’s more commercially viable.
Bhatnagar: It should be silicon-proven.
Carrell: Yes, but if it’s soft IP and it hasn’t been silicon-proven, that should be on the label, too. It’s like your food. If it doesn’t tell you what’s in it you put it back on the shelf and you buy something else.
Flynn: We used to do hard macros, but it was a challenge we couldn’t keep up with because of the porting needs of the technology. A lot of the complexity depends on the timing constraints in memory. What methodology are you using to handle these constraints? You want to be able to see far enough inside to make your tools work properly.
Hoogenstryd: With soft macros, the constraints provided with those serve a different purpose. They’re not necessarily constraints for defining this thing’s behavior at the chip level. For chip integration, those constraints are for mapping a particular implementation of that piece of IP. You don’t know what your latency is until you map it to a particular process and run it through a particular place and route tool and you get a block. It’s hard to say you can use those constraints you pass with the IP that it’s what you expect when you harden the IP yourself.
Flynn: You have to have that internal view, but you also need to care about the integration and how it affects your clock.
Hoogenstryd: But it’s hard to get that until you harden it.
Craig: Or you take an extremely pessimistic approach. A lot of people do that. ARM does that sometimes. That’s good from the standpoint of a provider because you have extra certainty that it’s going to work. But it can make the integration harder because everyone talking to that IP is consuming so much of that budget.

LPE: Does disaggregation of the industry make it harder?
Craig: Absolutely. At a company like IBM, they can control ownership and tell everyone exactly what they do and do not own. Otherwise, timing constraints are always someone else’s problem.
Carrell: There are much more rigid methodologies at the IDMs.

LPE: So who really is responsible?
Hoogenstryd: Everyone.
Craig: The person who ultimately has a problem is the one who’s responsible.
Bhatnagar: Ultimately it’s the back-end guy who’s driving the chips. They get the blame all the time.

LPE: How are you defining front-end and back-end?
Bhatnagar: Design and simulation and RTL verification are the front-end. Synthesis all the way down is the back-end.

LPE: Do models help? There are TLM models, power models and software models. And then there is timing.
Bhatnagar: A chip goes through many cycles. To avoid doing everything flat and then taking a hit on run time you want to do as much with models as possible. In the first round, models have to be accurate. When you go to full-flat mode you toss the models.

LPE: How about when you add in power domains and on/off?
Carrell: You replace spreadsheets by pulling things out of a catalog, instantiate it in a design and then look at a timing view and power modes. Then you figure out where your problems are and you go from there.
Flynn: It is possible to integrate models pretty well. A lot of external interfaces can be handled with the timing. When it comes to voltage, now you’ve got a problem where the supplies don’t track together. You may have two power supplies with timing closure being incredibly tight in the middle. You can look at it from a high level and estimate what you think it will be, but timing closure is even more difficult than you would expect.

By Ed Sperling
Low-Power Engineering sat down to discuss the issues in low-power design with Vic Kulkarni, general manager and senior vice president of the RTL business unit, Apache Design Solutions; Pete Hardee, solutions marketing manager at Cadence; Bernard Murphy, chief technology officer at Atrenta, and Bhavna Agrawal, manager of circuit design automation at IBM. What follows are excerpts of that conversation.

LPE: How does this industry create models? No one is thinking about thermal over time or performance over time.
Agrawal: People have modeled temperatures for a long time. When they model corners they model temperatures. One of the major impacts over time is temperature.

LPE: But typically that’s a relationship of, ‘If you do this then this will occur over time.’ What we’re talking about here isn’t a standard corner.
Hardee: A better way to describe it might be vectors. You need to take a wide variety of system modes so you get all the different power situations that can happen. Intermittent peak power may not be enough to cause thermal issues because the peaks may not be high enough. But close to peak may cause a thermal issue. As long as you have the vectors for those cases, with power analysis tools we’ll find those cases.
Kulkarni: That’s especially true when you have islands of currents. That’s where you see the huge rush currents and peak power. You also need to look ahead of it and behind it in sustained power. That way you can address electromigration and the grid design. But that is missing sometimes in the stimulus. To excite those conditions is critical for the functional vector.
Murphy: I have seen some people doing heat diffusion equations where they are trying to model how the temperature evolves in the die. Then you have an even more complex problem.
Agrawal: But that’s coming. It has to go hand in hand with power management on a chip.
Murphy: If you don’t do it you have to bound everything by an envelope that says, ‘It could go here.’ That’s not optimal.
Agrawal: We really need better power models. We don’t have them.

LPE: Who’s going to create them? Is it the tools vendors, the foundries or the chipmakers?
Agrawal: At IBM we have been struggling with this so we began creating our own power models. But we’d be more than happy to standardize these models if we could get other vendors to work on them with us. What will happen is the people who need them will create them, and eventually we will see some standard models come out of this.
Hardee: It’s the kind of model you’d expect to see in a standard cell library.
Agrawal: A standard cell library all the way up to the ESL level. You have to have models at all levels.
Kulkarni: That model would need to contain net capacitances, cell types, cell inferencing, and some of the thermal effects as you’re going up and up. Capturing those at a higher level of abstraction would be a challenge. Power is where timing was 15 years ago. Just like we created timing models and area optimization curves, that took a few years as an industry. This is now coming together where a lot of the physical effects are getting captured from a power point of view. But power is not just capacitance, either, from a model standpoint. That’s where we saw a lot of cell inferencing and clock domains and various clock trees put into a higher level of abstraction and then into RTL. Otherwise it’s only implementation and verification and we head completely off from the power goals. Many techniques we use today in the implementation world really are directed toward verifying the designer’s intent. But the designer may be off from the goal.
Murphy: There are many challenges in power, but one is modeling the modal aspect. It’s not just about the technology. It’s how you use that cell. If you take a video codec, the power consumption is a very complex function of how that codec is used. Do you wrap an envelope around it and say, ‘It’s going to be somewhere in here?’ If you do that you accept a fairly significant level of inaccuracy.

LPE: You can build in inefficiency by setting that parameter too high, right?
Murphy: Yes.
Agrawal: I don’t think you can talk about power without talking about what you’re going to use that power for. If you’re looking at that codec and you’re worried about the thermal effects, you’re just looking at the average. If you’re looking at the instantaneous power, you would look at every single thing that’s happening. You have to define it differently. Power varies widely, but we have to define why we’re using it.
Murphy: That comes back to the application. How are you going to use it?
Kulkarni: That makes standardization a problem. It raises a question that will require the cooperation of a lot of people, from the foundries to EDA vendors to end users. They need to define what the power model will need to contain, including modes of operation and fundamental technology. People are stuck at 40nm and below, which is why they’re creating these capacitance models.
Hardee: And as you go through the flow, the need for modeling and the expectation people have for modeling need to change. If we can provide models that are good enough to do relative power measurement—if you’re looking at microarchitecture decisions, is this one better than that one—that may be good enough at a high level. Certainly before signoff you want a very good absolute power measurement because you want to make sure you’re meeting the spec. At the ESL level we may be quite a long way from technology that can really get to an accurate power number. But at least if we can provide enough relative accuracy for architectural tradeoffs, that would be a good start.

LPE: Are the biggest gains to be made in power at existing nodes or at the newest nodes.
Agrawal: It’s the functionality in a power envelope. That will be the benchmark. This is the power budget I have. Tell me what you can put in a chip. Is this amount of functionality possible in this given power budget?

LPE: Then does the process node matter?
Agrawal: No, but people are used to performance improvements, which is why they may go to the next node to get a slightly improved performance at a lower voltage.
Kulkarni: The battle will be played on power per MHz, at least for the consumer market.
Agrawal: And functionality.
Kulkarni: Yes. That’s why the mobile industry is working so hard. It’s not just more functions on a mobile phone. It’s creating a user experience. Everything over 3 watts becomes uncomfortable in your hand over time. That’s why all these standards are just under 3 watts. WiMax, 802.x and others will be at 2.4 to 2.6 watts. Many customers I talk with say 20 milliwatts will increase market share. That’s very good for this industry.
Hardee: In non-mobile applications we’re hearing the reciprocal of that. People are talking performance per watt.
Kulkarni: We have one customer doing flat panel TVs. We wanted to know why they wanted to lower power in set-top boxes—or set-behind boxes, more accurately. They said that if you’re watching a movie on your TV and it’s silent and then suddenly you hear the cooling fan, it would not be a good experience.
Hardee: These thermal issues also affect reliability. That’s why these set-top boxes keep failing.

LPE: But aren’t we getting to the point where there is enough performance for most applications?
Agrawal: Yes, and the frequencies are starting to level off. Gigahertz are gone.

Low-Power Engineering sat down to discuss the issues in low-power design with Vic Kulkarni, general manager and senior vice president of the RTL business unit, Apache Design Solutions; Pete Hardee, solutions marketing manager at Cadence; Bernard Murphy, chief technology officer at Atrenta, and Bhavna Agrawal, manager of circuit design automation at IBM. What follows are excerpts of that conversation.

LPE: How important is software in lowering power?
Hardee: When you’re running software in the processor it’s how efficient data is being moved with the memory architecture and caching. People need to validate they’re using the right cache algorithm for the right application. There are a number of alternatives. We’re extending into transaction processing for that reason.
Murphy: As soon as you go up to an external memory interface your power goes way up.

LPE: How far can we reduce power, though?
Kulkarni: Functional verification has been addressed by many people around the world. A functional bug is a well-known term. We’re finding there are now power bugs. Some experts have reduced power by 100x over the last five years using every known technique. What they want to know is how they can reduce it further? That’s where we’re finding what we call ‘power bugs.’ In a multicore processor, for example, one core was running but the data was not shut off in other cores. It was creating unnecessary activity. Designers are not tuned to that because functional verifiers will not find that. We are finding more and more of these ‘power bugs’ every day when we see hot spots. The chip may be in ‘off’ mode but the address line may be running. Or the clock may be running and the data may be off. There is a lot of savings in those.
Hardee: With all these techniques to control power there’s a different kind of power bugs we’re starting to see, which are functional or structural errors with the implementation of the power intent. If I have multiple power domains I may be using power shutoff, power shutoff with retention, and multiple supply voltages that I’m adaptively or dynamically controlling. So I need a whole bunch of isolators and level shifters. A lot of verification tools are picking up errors. Those are what we call power bugs.
Kulkarni: To us those are structural bugs. What we’re finding is bugs in the relationships between signals.
Agrawal: And it’s not easy to find these bugs. If you look at fine-grain power gating it sounds very good on paper. But if you really want to do functional verification with fine-grain power gating it is very difficult.
Murphy: The whole power management architecture has become scarily complex. You have a huge amount of functionality that has to change each time you change the underlying mission-mode functionality. So you have a problem that is probably significantly more complex than ATPG (automatic test pattern generation), but you have no automation tools for it. It’s essentially being done manually.
Hardee: ATPG is its own issue. After you set up all those power domains you have to do scan insertion. We’ve seen a couple problems cropping up. One is if you didn’t consider all the power domains so half your scan chain is powered off. Or you may do a great job of isolating the power domains, and when you insert the test you have all those scan signals crossing power domains and those are incorrectly isolated. Power-aware DFT is becoming a big thing because of this.

LPE: Will we ever really be able to lower the voltage beyond 0.8 volts?
Hardee: That’s the limitation of bulk CMOS. There are other technologies like SOI and gate stack technology. If Moore’s Law is to continue, those changes will have to happen.
Agrawal: The voltage can go down below 0.8 volts. We may have to re-think architectures and topologies, but it can go down.
Kulkarni: We’re seeing islands of voltages. If you’re reading on an iPad in a certain mode as opposed to watching a video, there are different requirements. DVFS (dynamic voltage frequency scaling) and AVS (adaptive voltage scaling) might be more interesting because of this.
Murphy: DVFS is a popular term and a popular idea, but it dramatically increases the complexity of your synchronization problem. You’ve gone through a lot of work to make sure you’re not going to get handshake issues and suddenly that’s become orders of magnitude more complex.
Hardee: We’re seeing DVFS being confined to a separable block, but not generally across a design for that reason.
Kulkarni: You can envision different modes of operation across an SoC. You can have different schemes of operation.

LPE: That’s particularly true in 3D ICs, right?
Agrawal: 3D makes the power problem even worse. Today you have problems supplying power to these chips. You cannot supply enough power to these chips. So when you stack 3 or 5 or 10 chips you will be supplying power to with the same technology. Something has to change.
Hardee: And where do you put the heat sink?

LPE: Where is the solution? Is it one thing or 50 things?
Agrawal: No doubt it’s 50 things. There is no one solution. Historically we went up the power ramp with CMOS, came down with multicore—and we still haven’t quite conquered that yet.
Kulkarni: We’re seeing disparate chips in a 3D stack, not logic because of power and thermal management. But the memory and RF sections are getting stacked. It’s a flexible PCB.
Murphy: It’s bandwidth to the chip.

LPE: One of the phrases we’re hearing more about is design for variability. What does that do for power? Does it make it harder to manage?
Murphy: Variability is built into the power problem from the beginning.
Agrawal: There is a danger of optimizing your particular design for a power corner and not realizing the power sensitivity of the design to the process corners. If you optimize for one process corner and you move to another your power may go crazy. It’s very difficult to optimize power for variability.
Murphy: For a cell phone there are so many ways you can use it that there’s a huge amount of variability right there.
Agrawal: With process variability you have a non-use mode and an active mode, but the process corner could move from one to the other and the leakage power can go up dramatically. Power is always off and on averages. The danger is it might not be optimized for a particular corner.
Hardee: The number of corners is exploding, as well. At 40nm, we’re looking at about 20 corners. And with the cell libraries they’re working with, the difference in the leakage is orders of magnitude from worst case to best case. These aren’t small variations. There is a lot of variability, and that variability is showing up as leakage. Is it realistic to design for worst case? It’s not.
Agrawal: No. And as we move to 22nm, more and more people will have to do statistical timing. Worst case doesn’t leave you enough room to improve performance.

LPE: How much does process variability affect power? Seven atoms vs. eight atoms can affect performance, but will it affect power?
Hardee: Absolutely. That’s what’s giving such a wide variability in terms of leakage.
Agrawal: Leakage power varies widely with process variation.
Kulkarni: And temperature. It’s more than just power. It’s energy. If you look at energy and then power over time, it has become critical for how people design chips. They want to look at several intervals to see what happens to power. It could be completely different power as you go to different modes of operation. That’s where leakage can cause havoc. The thermal gradient can change over time and it becomes a circular computation.
Agrawal: If you run two wires in parallel, the temperature in one can increase the temperature of the neighboring wire.

LPE: How do you define energy vs. power?
Kulkarni: It’s the holistic picture. It’s not just a snapshot but power over time, so you have to figure all your components over time. You have to look at the impact of thermal and the impact of heat around it.
Murphy: There are techniques available to deal with that. There are little PDP monitors you can plant around the chip to do local compensation to adjust some of that.

Low-Power Engineering sat down to discuss a broad swath of power issues with Vic Kulkarni, general manager and senior vice president of the RTL business unit, Apache Design Solutions; Pete Hardee, solutions marketing manager at Cadence; Bernard Murphy, chief technology officer at Atrenta, and Bhavna Agrawal, manager of circuit design automation at IBM. What follows are excerpts of that conversation.

LPE: Can the power problem be solved in advanced designs or are we headed for a brick wall?
Murphy: What we’re dealing with is not a point problem. It extends all the way from application-level software design down into the implementation. It’s a stack.
Agrawal: When people were worrying about performance it was very easy to separate out instructions per cycle and cycles per second. You could optimize each of these and debug the optimized system. Power hasn’t had any such separation. People have tried look for some separation but it’s a very hard problem. That’s why the problem persists. Ten years ago people were saying power is very important, and since then some progress has been made. But we are looking for function in a power envelope all over the place, not just in a single application.
Murphy: The cell phone industry has been at the forefront of this, and one cell phone engineer told me they put a lot of functionality into the chips to do all kinds of sophisticated power-up, power-down tricks. The expectation is these knobs will be turned by the people who develop applications on top of these chips, but he said the big surprise is that no one takes advantage of those knobs because they don’t know how to. They’re lost bridging from the application to the power model of that piece of silicon.
Kulkarni: At last count there were about 22 different techniques, from system to microarchitecture to logical and physical for reducing power, analyzing power and managing power. It’s now come down to design for power. There is no single silver bullet. It comes down to dynamic power and static power, and simply managing those two equations across all levels of abstraction. But each decision you make has tradeoffs, so these 22 different techniques we’ve studied using area, timing and noise have an impact. That’s why no one has been able to solve this to date. If you look at the power grid or power delivery network, it becomes critical at all levels, not just the highest level. How you deliver that on the chip and around the chip involves tradeoffs for electromigration and electromagnetic interference. They all get impacted by microarchitectural decisions.
Hardee: A lot of these techniques have been around a long time, but what we saw at 45nm and 40nm is that leakage took over from dynamic power as being the biggest problem. We’re seeing a different emphasis on those 22 techniques that Vic talked about. The best ways to manage leakage involve shutting off as much of the system as you can. That has to be done under software control. But we’re also starting to see some physical limits as you go further down the process nodes about what you can do with leakage. The leakage is continuing to increase and the supply voltage is getting closer to the threshold voltage. There is some life left in bulk CMOS, but at 22nm people are starting to think about new approaches like SOI. The tradeoffs are not just timing vs. power. There are also cost tradeoffs for yield.

LPE: We’re hearing more about not just SOI, but fully depleted SOI. But how does all of this affect things like power delivery?
Agrawal: Suppose you have an electromigration problem in your power wire. What do you do? Do you need different materials for your wire? Can designers do something with the layout. If you move the wire, does the problem become bigger. It becomes a problem from the gate level to memory to the power level to the system-performance level. To get all these people at the same table talking the same language is not easy. People call it the kiss of death because it’s so hard, but the time has come where people have to do these things. It’s necessary.

LPE: Will this type of approach become mainstream, though?
Murphy: Everyone believes the biggest place you affect power is at the application software level. It’s going to be pretty interesting to watch Apple over the next few years. The iPhone has not been famous for its low power characteristics, but they have an advantage over the merchant market because they own the whole thing.
Hardee: Apple got people complaining about battery life after an OS revision. That meant they were back to the wrong defaults.
Kulkarni: There are many problems to solve. In the stimulus management, how do you measure power? When people generate their vectors those are not necessarily high-power-consuming vectors. With thousands of gates a clock can consume a lot of power. And memory-based designs can consumer a lot of power. The selection of right vectors will affect the power delivery metrics. Some vectors involve the package and the PCB, but when you are creating your stimulus that’s typically used for functional verification, not for power verification. The new challenge is what we have dubbed power pattern generation. That’s becoming important in most of the tough system designs like mobile phones—creating the right stimulus to drive the right power combinations. That may be multimode vs. high power-consuming vectors. If you create a functional vector set you need to select the right vector. We are finding convenient ways to live in our comfort zone, but finding the right vector is critical.
Agrawal: That’s the big difference between timing and power. Timing has been studied for a lot longer than power. People do static timing analysis—best case, worst case—and come up with one number. Power is not one number. There is different power for functional and IR and EM analysis. There is different power for di/dt (current change) and for battery life. So my power analysis has to be componentized so that given a power model I can do analysis at all these different application power corners for the same chip. That’s where patterns and switch factors come in.

LPE: But there aren’t many companies outside of IBM and Intel doing this, right?
Agrawal: That is correct. Because there is nothing available we’ve had to do it ourselves. It’s not because we love to do it.
Hardee: There are a number of people that need to work on this problem. As we’re getting the convergence of applications onto all kinds of devices, there isn’t one system mode where you can check everything. There are many different modes for just power alone. If I’m worried about leakage I’ve got to look at some modes that are shutting off a lot of the system as well as the modes where there is a lot going on. My peak mode may be in a totally different system mode to the peak mode that’s broad enough to give me a thermal problem. There are different kinds of peaks you need to look for. And with battery life, it isn’t power that you’re worried about. It’s energy. It’s the integration under the curve. You’ve got to run an awful lot of vectors for that. The other power measurement issue we’re all familiar with is accurate characterization, and the common wisdom is you need that late in the flow to be able to get a power measurement. Where people are failing is by having the wrong system activity.

LPE: With the future headed firmly toward multiple cores, will software written for specific cores or lots of cores that work as a generalized platform for whatever processing is needed?
Murphy: There’s no clear answer to that today. Almost invariably you have a housekeeping core, which is going to do stuff like boot management and configuration management. That may also be the center of where you manage your power. But if you look at any cell phone, you have DSPs performing all kinds of functions. It’s not clear yet how you divide up the software between the cores. What is clearer today is how you turn on and off all the peripherals like video and audio.
Agrawal: You design power switches and functionality that no one takes advantage of. At some point you can envision a chip with high power and single-thread performance, so you shut off everything else. But eEven though your whole chip doesn’t heat up, you may have a problem locally. So software needs to co-designed with the hardware, and today we don’t really do that.
Hardee: Using a general-purpose processor is not power-efficient. Using dedicated cores or programmable accelerators is better. And putting dedicated functions into hardware rather than running them in software may be the most efficient way.

Low-Power Engineering sat down to discuss what’s essential and what isn’t in EDA with Brani Buric, executive vice president at Virage Logic; Kalar Rajendiran, senior director of marketing at eSilicon; Mike Gianfagna, vice president of marketing at Atrenta, and Oz Levia, vice president of marketing and business development at Springsoft. What follows are excerpts of that conversation.

LPE: How do complexity and all the different levels of the flow affect signoff?
Buric: Signoff is necessary at every level. Signoff at the DRC level and the DFM level and the gate level will stay forever. However, what’s different is that if you don’t sign off at a high enough level you cannot get to the next gate.
Gianfagna: It used to be that you could leave it to the end and clean it up. You used to be able to leave OPC (optical proximity correction) to the end and fix the litho hot spots. You can’t do that anymore. There are too many hotspots. The tool will find them all but you can’t fix them all. That’s an opportunity for EDA to add more value further upstream so you don’t have to find all the problems at the back end. There are tons of examples like that with power, test, area and routing congestion where you have got to start earlier or you get crunched in the funnel at the back end.

LPE: Engineers have been postponing using power islands and clock gating as long as possible. They seem to have run out of options, even at even mainstream process nodes. Do they understand the difference of what’s needed vs. what’s not?
Levia: There are definitely companies that know what they need and which are very good at educating their suppliers. They’re very good partners for us. If you work with them, they have a very clear road map about what they’re going to do and they are very articulate in communicating what they’re going to need, when they’re going to need it and why. Sometimes they can even tell you how much they’ll need. But unfortunately there are not many companies in this category. More fall into the ‘need to be evangelized to’ category. ‘Let me tell you why you’re going to need power islands.’ Or, ‘Let me tell you why verification is different with power islands.’ So there are two distinct camps.
Rajendiran: The one thing that has changed from a market application perspective is more and more people are buying consumer parts. More people are buying a phone. If you’re a businessperson, you’re going to be using it equally for e-mail and phone. If you’re a teenager you’re going to be using it for texting. Some of them are so good they can text without even seeing a keyboard. So depending upon who it is, power consumption is going to be driven by the application. It’s not so much how much power you can put in, it’s now driven by the usage model. That’s a big change from 10 years ago when you worried about a processor that was 50% faster or one that consumed 20% less power. Those were the two slides you took to a VC to get funded. Now it’s usage. Even if you’re looking at infrastructure, it’s the green initiatives that are driving it. Intel changed five years ago when they went to multicore and power conservation. Bigger companies do a better job figuring this out and marketing it. Smaller companies are still struggling with it.
Gianfagna: Natural selection will weed out those companies.
Rajendiran: Yes, and it’s already happening.
Buric: There are a few customers—a minority—who understand what it takes. What we’re seeing as an alternative is coming from companies like TSMC with a reference flow. With the reference flow is a list of the tools needed to get you through the reference flow, which helps their business.

LPE: So they give the choice to their customers?
Buric: They’re not even choosing. They’re working with a few leading customers to learn what they need and then they have to decide whether customers can afford it or not.

LPE: Is GlobalFoundries doing that, as well?
Buric: Not yet but they will catch up. It’s a must. You cannot explain to most companies what they will need.
Gianfagna: There are a handful of customers who know what they need and drive the strategy. We all kind of work with the same customers. What’s different is the ‘have nots’ at least know what questions to ask and are looking at outsourcing more. They’re looking to understand the process better. It’s improving. The need to work differently is becoming a competitive advantage. There are some who don’t get it. You won’t see them in a year or two. That’s the opportunity for EDA. There’s a better-educated consumer base for what will bite them. You don’t think about some of this stuff at the gate level. You think about it way earlier when you have an architecture in mind, or even before. What processor will you use? What power domains? What throughput? These are high-level decisions, and it takes tools and IP. That’s the opportunity for us.