Low-Power Engineering sat down to discuss the advantages of dealing with power at a high level with Mike Meyer, a Cadence fellow; Grant Martin, chief scientist at Tensilica; Vic Kulkarni, senior vice president and general manager at Apache Design; Shawn McCloud, vice president of marketing at Calypto; and Brett Cline, vice president of marketing at sales at Forte Design Systems. What follows are excerpts of that conversation.

LPE: What’s missing from our tools arsenal? If you have enough experience you get a feel for what works, but how does the average engineer get there?
Martin: You need to build some tools that can actually do high-level system bookkeeping. That’s really what it’s all about. When you have a power estimation or energy estimation, it produces traces of activity that can feed into an overall system model. Various IP models could all be calibrated to send out that information. People could run scenarios and estimates that way. It still seems to be missing. I recall talking to people about this two or three years ago.
Kulkarni: The industry seems to be doing a lot of optimization techniques in ESL, but not a lot of analysis techniques. We have been doing that for several years at the RT level. A lot of us can do RTL power optimization. But from an analysis standpoint there are very few who can do it. It takes so long to be accurate about how to stimulate RTL without having a synthesis engine underneath. ESL synthesis experts still don’t have the analytic engine for ESL. That’s a missing piece along with ESL power models.
McCloud: We have very good point tools out there today. We have good HLS tools doing very complex, high quality hardware accelerators. We have some pretty good power optimization, power analysis, power optimization and integrity tools. What’s missing is a way of productizing the integration of all those tools. It’s standardizing UPF and CPF and getting that propagated through the tools. And then what’s missing on the TLM side is better standardizing around annotating the power and getting the right fidelity to the TLM models. That’s one of the primary purposes of the TLM model—to be able to run real software on it and get accurate estimates. What we need to do is put these good tools together.
Meyer: And we need to recognize that it’s not just an issue of hardware vs. software. There’s also the issue of multiple cores. People have the choice to have some stuff run in a high-speed core and other stuff run on a lower-speed core. Those types of decisions don’t come easily. There’s a fair amount of effort you need to put together a prototype so you get an idea of what the power is if you have two cores vs. one core and an accelerator. There’s a lot of modeling that has to be done to come up with an answer there, even with very early estimates.
Cline: In the case of people with 30 years’ experience who have to trade off between one core, two cores or four cores and the custom logic that goes around it—there are very few of them. You won’t sell a lot of tools into that market. Most of the people with 30 years of experience are grinding RTL everyday or writing software. For EDA vendors, you get paid for optimization with an extra zero vs. what you get paid for analysis. It’s the way the world works. If you have a tool that squeezes out an extra 10% at the end of the process, you get paid for that—especially if you’re putting out a fire where you don’t meet timing or something else that’s critical. What’s the time value of a week over the course of a project? At the beginning of a design a week isn’t worth anything. At the end of the project the value of a week is huge. If you sell a product into the last week of a project and it squeezes out another 5% or 10%, you’re a hero.
Martin: On the other hand, the decisions you made in those first few weeks may cost you downstream. There are a lot of design teams out there where it seems there is very little accumulated experience and they’re confronted with these problems and very rapidly trying to do design. Stepping back from the tools and the analysis, you have to ask, ‘What is the overall design methodology?’ Do you have that experience taught to design teams to make choices about how many cores, what kinds of cores, what kind of hardware blocks, and do they all fit together? That architectural expertise has been gained by years of experience.
Kulkarni: It’s almost as if power is where timing was 15 years ago in terms of the knowledge base.

LPE: Except that the people who know timing now need to know power, as well, right?
Kulkarni: Yes. It’s not just mobile or cloud computing. Everything is focused on power, from disk drives to memory. Customers that have 65 watts per chip want to move to 60 watts. They want to move from 5 milliwatts to a few milliwatts. The knowledge of power is limited, though, in terms of power management, power optimization, as well as certain decisions that have an impact downstream. How do we, as an industry, get power analysis and power decisions to be pervasive? Even from my own company we have not given a complete recipe for how to do RTL to GDSII design. It’s in many people’s heads. The end customer also changes their mind on the fly, but at least in 80% of the design, if we can all produce a recipe book then we all benefit. UPF and CPF have started that work already. But when you go to a customer, typically they have some used IP and some new IP. UPF/CPF may apply to the brand new IP but not the old IP, so mix and match flows are another challenge. How do you make sure the previous design worked and certain parts of circuits work in the new design?

LPE: What you’re talking about is flexibility in modeling, right?
Kulkarni: That’s correct.

LPE: HLS has been around for more than a decade and it still isn’t mainstream. Will power force a change in perception?
Cline: It’s certainly going to be a factor. But what drives it is the ability to get your job done in the right amount of time.
Meyer: Yes, it’s time to market.
Cline: It’s also time to results. You have to hit some sort of metric for your results. I was just in Japan and the concern there is how they’re going to get $5 per chip. To do that they need twice the number of features and speed. So pick your favorite HDTV company. If it’s not Visio, then Visio is undercutting them by 50%. How do they get their chips to where they’re competitive?
McCloud: I wouldn’t underplay the potential significance of power becoming a critical factor for people adopting HLS. We’re just now scratching the surface in terms of what we can do in HLS. Memories are consuming 60% of the power in a typical HDTV. There’s a whole slew of memory optimization we can do around the way we slice the memory, around memory-enabled gating, light-sleep mode, deep-sleep mode. Those are things that are perfectly suited for an HLS tool, which has a detailed understanding of the state in the design of the data path. The tools already have sequential and combination clock gating. But as we start to go past 45nm, it’s not just the battery life. It’s also thermal and power integrity issues that become critical. That’s when HLS will really become close to a requirement.
Martin: Any technology that lets you explore the design space for different alternatives, whether it’s HLS or configurable processors, if you’re keen on performance you can examine more alternatives more quickly. If it’s power and it really does let you explore that space, that’s also key. If it’s just within a few percentage points of what you do in RTL by hand, that’s not going to drive that market. It has to offer a wide margin.
Cline: It’s also what’s called ‘change and check.’ You can change something very quickly and check what the results are. We see a lot of engineers that need to change a number of things and then check them, and then change and check more. You can’t do that in RTL. It gives them a whole other set of options.
McCloud: One of the things we really need to do is shrink-wrap the methodology. Then the smaller companies can pick it up and run with it. Right now it takes a big company to put that investment behind it.
Cline: I agree, except that the very small companies use it because they can’t get the funding to go build a $50 million chip. The middle of the curve are the guys who can’t move just yet.
Kulkarni: The ideal solution for designers would be HLS for optimization of power, timing and area, and then quickly checking against the RTL power analysis. The reason is that at the RTL level you can capture physical effects. That becomes a linchpin from the physical world to the ESL world. But you also have to have good power models.

LPE: Don’t you also need more standardization?
Meyer: You certainly need to be sure that you’re not double counting. A lot of times you’re modeling more than just the software, and you’re trying to estimate the power there and you’re starting to include what’s in the memory and the cache. And then you start looking at the cost somewhere else, and you’re adding the cost in again. You have to have a way to say, when you aggregate it, how do you make sure it’s not double-counted.

Low-Power Engineering sat down to discuss the advantages of dealing with power at a high level with Mike Meyer, a Cadence fellow; Grant Martin, chief scientist at Tensilica; Vic Kulkarni, senior vice president and general manager at Apache Design; Shawn McCloud, vice president of marketing at Calypto; and Brett Cline, vice president of marketing at sales at Forte Design Systems. What follows are excerpts of that conversation.

LPE: Does the approach to using tools have to change for low-power?
McCloud: Way too often, when people get to the block level, they start saying, ‘I’m going to use my functional tests.’ That’s completely wrong. That’s one of the big advantages of doing things at the higher level. You’ve got things that are closer to the real application running. That’s an incredible difference.

LPE: But how do you integrate that concept with different use models? Two different users may use the device for completely different purposes and in different ways.
Cline: You can go through the user profiles pretty easily. If Apple claims its new phone will have eight hours of talk time, that probably doesn’t include me not talking on the phone at all. I’m just going to surf and get e-mails and do other things. They understand one profile, and then there’s probably a mixed profile for the average user. You can conceptualize that at the system level when you’re doing your design, figuring out if the phone is running for eight hours straight here’s what’s probably going to happen on your next project. But you need to get down to something measurable, which right now is the RTL level, and even that is questionable in some situations. But it’s a tough problem.
McCloud: Today, the cell phone is one of the more common applications that high-level synthesis has to do with the image single-processing blocks. A large number of these ISPs—everything from the sensor to the image correction that’s occurring to the final JPEG decoding—are done with high-level synthesis. The reason is that having a dedicated hardware accelerator is going to produce the lowest power needed for doing image signal processing. It’s a very specific function. You take a picture, you do image correction and processing, you compress it, store it and you’re done. You shut the hardware down.

LPE: High-level synthesis isn’t normally associated with power estimation. Is this a new use?
Cline: It’s been there to some extent. Power estimation comes in a number of different forms. Let’s say you’re laying down a clock cycle and designing it in high-level synthesis, and the tool is doing the work to fill it up. It knows that a multiplier is going in. It can do quick analysis on a multiplier with a reasonable stimulus to figure out whether this multiplier has a better power profile than another one, as long as they both meet your performance goals. You can trade off the area with them, too. One of the things we can do is go through this process of scheduling the clock cycles, filling it up with all the different functional units that are going to go in there, and determine at a later stage in the synthesis process which are the lowest-power multipliers. Can you swap those in and still meet all your timing budgets? If you blow timing then you’re tool is useless. You have to meet timing, and afterward you minimize area and power and let the user make tradeoffs where they want to. It’s been there for a long time with various levels of maturity. What you’re going to see is that will continue to mature, but you have limited benefits at that level. You can make 5% and 10% improvements at that level. You can’t make 50% improvements.
McCloud: It’s evolving. Power has been in HLS for awhile. It’s being used to design applications for lower power. The first stages of this centered around simple exploration. You take a JPEG and your requirement is to compress that picture in 500 milliseconds. You can do that with a 25MHz clock, a 50MHz clock or a 100MHz clock. Each one of those has very different power tradeoffs. That kind of capability has existed in HLS for years.

LPE: But you’re coming at it from the standpoint of clock speed compared with power first.
Martin: That’s only true if you have a fixed-instruction-set processor. When you design your own instruction set you’re in a whole new ballgame, which is one reason we’ve been supporting high-level analysis and estimation in the design flow for a number of years. The power talk is interesting because of the confusion people have between power and energy. In mobile devices, assuming you have driven toward a peak-power level that is sufficient for low-cost packaging you’re targeting in your device, it’s all about energy. Energy is the issue here, and there are many ways to fit into a particular energy budget, but so often people express themselves using metrics such as milliwatts per megahertz. What does that mean in terms of the overall energy? It depends on what a milliwatt does. If you target one type of instruction set where you can do more in one cycle than in another, that reflects in the total energy consumption.
McCloud: For me it all boils down to battery life. That’s what matters. There’s a second component that is centered around power and integrity. The reason it’s so important is that when you reach 45nm we’re starting to reach a technology inflection point where you cannot scale the supply voltage any more to help reduce the power. At about 45nm or lower, the power density is goes non-linear. This is going to create huge problems around thermal and supply integrity. You’re going to start getting a Vdd dropout, you’ll have hot spots in your chip, and the chip will burn up. It’s not just about battery life. It’s how we’re going to be able to take advantage of these technologies in the future and be able to produce these chips in a way that power density doesn’t go through the ceiling.
Kulkarni: Specifically what we’re looking at is how do we get the high-level power support budgets versus the power consumption, which is insatiable demand of all functionality and multiple modes of operation. How do we make sure that the power grid we’ve designed will work? We’ve been watching that stimulus carefully. But what happens to that stimulus out of millions of clock cycles. There are things in the context of dynamic voltage, voltage route, and the package, and the PCB, and the system. You have a band of inaccuracy first, and then you look at the energy models and what happens over time. How do you capture those when you are switching between a lot of domains and there is a lot of switching activity? How do you model that accurately? And how do you model the physical effects at a higher level of abstraction so that your inaccuracy band gets narrower and narrower. We especially see that below 28nm, where there are huge transients causing voltage droop. Either your grid will collapse if you overdesign, or if you underdesign you will have electromigration problems with power energy and heat all coming together.

LPE: What you’re talking about here is a hierarchical flow with two-way communication, right?
Kulkarni: Yes. And the reason we have not done too much power synthesis at the ESL level in the past is that when you make a transaction-level model, how do you go inside that? Power creates a different level of challenge. The industry really needs to address how to create these high-level models that will tune into what happens down at the chip level. And then you have to connect the front end to the back end and get to the details of power in both directions.

LPE: How do we fix software to make systems more efficient?
Meyer: You’re presupposing that you have software at the time of the design. That’s one of the biggest challenges. That’s where virtual platforms become an important part, running real software on the system. That’s one of the real challenges at the system level—to have something you can run in software early enough to influence the hardware decisions that you’re making.

LPE: Do we need an understanding of the software and how it’s going to function at a very high level, though?
Meyer: For some cases, if you could characterize how much the software is using each of the blocks and be able to understand system performance without detailed modeling, that would help you understand your power budget and do a better estimate. But we really haven’t spent much time working at that level yet.
Martin: We spend a lot of our time working at that level. Letting our customers build configured and tailored processors is extremely important. Sometimes you can do an interesting job by taking referenced or standards-based software, and if you have a very good compiler for an application-specific processor it may be able to do things like automatically vectorize and infer the use of some fairly sophisticated instructions. That has a limit, though. To really figure out what an optimal algorithm implementation would do on a particular instruction set you may have to get into more manual optimization. But some of the early work can be done with an envelope if you have a good targeting compiler.
Cline: A lot of our customers have that exact issue. With cell phones they may look at their next platform and say, ‘This time it’s going to have real-time video on it. Can my ARM processor run this real-time video algorithm at the same time it’s doing a network connection to beam everything up while it’s also downloading e-mail?’ And they may not be ready to buy the next ARM processor. So if they put this into custom gates, what is the cost in terms of area and power and what is the speed? They do that initial analysis using high-level synthesis and figure out what the tradeoff is. A lot of times they can buy a bigger processor and take on more royalty cost or power issues. So in some cases they have the software already, or at least they know what it’s going to look like. In other cases when you build a bigger system you may not have that.
Kulkarni: One of our customers who was designing a digital TV asked us whether they can profile the software for power. It’s an interesting question. With digital TV your eyes are pretty much looking at an oval field picture, so can you do power reduction on the black pixels on the edges? That’s pixel-by-pixel power reduction. That’s a great challenge for all of us. It’s not just mobile applications. It’s also digital TV, streaming video, heads-up displays for military applications, and so on.
Cline: Those guys don’t care about battery life, which makes it very interesting.
Kulkarni: But they still want to reduce the power.
McCloud: It’s all about the packaging cost.

Low-Power Engineering sat down to discuss the advantages of dealing with power at a high level with Mike Meyer, a Cadence fellow; Grant Martin, chief scientist at Tensilica; Vic Kulkarni, senior vice president and general manager at Apache Design; Shawn McCloud, vice president of marketing at Calypto; and Brett Cline, vice president of marketing at sales at Forte Design Systems. What follows are excerpts of that conversation.

LPE: Do we need to redefine what constitutes a system when we’re talking about power?
Meyer: It definitely is part of a bigger picture. The problem is that there is very little support up at those levels. You’re managing budgets and it’s a crude mechanism you need there. As we go forward things like virtual platforms and power—or maybe more on the energy level where you’re looking at where power is spent between hardware and software—and making decisions on how things should be implemented makes a lot of sense.
Martin: We’ve supported power modeling in our application-specific processor design flow for a number of years. The kind of power modeling you get can be quite accurate for the instruction set. It’s reasonable to allow you to make energy tradeoffs with the instructions you have. You can then run that set of instructions and predict what the energy consumption is going to be, and then you can do experiments around that. We feel like we’ve been a plug without a socket for years, at least for determining the right instruction set.
Kulkarni: In terms of how we see the world, it’s more than absolute accuracy and prediction. It’s really relative accuracy and relative analysis of what-if scenarios. That’s where the whole world is going in terms of macro architecture analysis. But the Holy Grail is ESL synthesis with RTL power analysis. That’s the ideal flow—you capture some of the physical effects in the RTL world but do a lot of what-if tradeoffs, hardware-software co-simulation, DVFS, looking at various power scenarios, and then validate that through a real hardware description language because that’s where all the realization will occur. But you can do all the relative accuracy of power up at the ESL level. That’s the picture we see from our end customers.

LPE: So it’s big-picture power estimation?
Kulkarni: Power estimation is still questionable at the moment. But getting traces to drive the RTL power analysis is a much better approach, which we have used in a mobile application. We took a 2.5 million-gate design and applied SystemC-level simulation, then did ESL with a partner, and then looking at the IP and DSP models there were multiple cores. We took the transaction-level trace and combined it with RTL analysis to essentially emulate what would happen on a six-second call on a cell phone. We could analyze that in four hours using this flow vs. three months using pure RTL analysis and RTL power estimations. So a combination of ESL synthesis plus RTL analysis that captures a realistic stimulus and the physical effects can reduce that band of accuracy from RTL to gate to final signoff.
Cline: Today that’s a typical flow. There isn’t any real SystemC analysis—or good ones, anyway. But as far as optimization and estimation go, these are two separate worlds. The first one is that somebody has to get the power right on a macro level. You need some way to model those larger blocks and get your power budgets right at the block level, which may have only 10 blocks in your design. From there you need to go to power estimation. You go through synthesis, go to RTL estimation, and then loop the information back into your system level. There has to be some sort of modeling at the higher level, with more parameters than just the performance numbers. There has to be some other quick estimation of area using a synthesis engine and quick estimation of power using a combination of synthesis and techniques through application-specific processors or RTL.

LPE: How accurate do the initial high-level power analysis or estimation have to be?
Martin: Our experiments with our processor estimation have been that for the RISC core you can be plus or minus 3%. For other things it can be more like plus or minus 20%. The key is to make macro tradeoffs. It’s not whether this is 5% better than that one. It’s whether this takes you in a different space than that one, and for that 20% or 15% is an adequate coarse-grained analysis. People always want to verify at RTL and maybe down to place and route that the decisions they made at the high level are being validated at the implementation level.
Kulkarni: What we find is a band of inaccuracy, as opposed to absolute numbers. About 30% is adequate as you go through RTL, RTL synthesis, P&R, layout, and final grid signoff. If you keep that band and narrow it down consistently, you get a true power budgeting solution at the system level. That includes hardware-software tradeoffs, and RTL to synthesis all the way to grid design and package. That way the ESL designer working on the next-generation smart phone is not completely off the mark in terms of final cost, power and SI budgets.
McCloud: From a high-level synthesis perspective, accuracy needs to be quite high. At the end of the day you’re doing hardware architectural exploration between different frequencies and technology. If you are off 20% or 30% when you’re trying to make your design selection it’s significant. It does come down to the accuracy of the up-front power estimation tool when you get closer to the hardware you’re trying to create. If you’re talking about something before that in the TLM platform space, at that level when you’re making decisions about whether to move something into software or keep it in hardware, accuracies in the range of 30% or 40% are sufficient. But if you’re creating a hardware accelerator, you need to be within 10% or 20%.
Meyer: If you’re consistently overestimating by 20% and you know that’s happening, that’s much more acceptable. But if you’re plus 20% in one area and minus 20% over here, then your confidence disappears very quickly.
Martin: You have to be monotonic. If the estimator says A will be greater than B, then by the time you get detailed analysis A had better be something greater than B—even if the actual numbers aren’t the same.
McCloud: And that’s the problem. If the estimations in high-level synthesis are off by 20% or 30%, you run a high degree of risk that your relative comparison between one solution and another solution is not the same relativity when you go down to RTL synthesis at the gate level. If you think solution A is 5 milliwatts and another solution is 7 milliwatts, when you go to actually implement that and run it through power estimation tools at the gate level, you might find that comparison is correct. That’s why I believe you need a relative level of accuracy.

LPE: Is it harder to get an accurate assessment as we start adding in multiple power islands, voltage rails, and stacked die packages?
McCloud: It might get a little bit easier. Of course you need to be able to architect your high-level synthesis tool to be able to take into consideration that you’ve got islands, but in some respects you’re localizing the power estimation to a particular region of your design. When you’re talking about power gating of an entire hierarchical block, that’s actually a benefit when you localize it to a specific area.
Cline: The problem that high-level synthesis tools will have in the future, if there’s not a closer correlation to the back end, is having a disconnect at 20nm or 1nm.
Meyer: And having some way of passing down what you think is a good implementation for this piece of it. There has to be something to express, ‘I expect this to be a high Vt and this to be a low Vt.’

LPE: Does it make it harder to pick which processors and which IP and which interconnects you’re going to use because you are running at such a high level?
McCloud: The further you get away from the silicon the greater the impact you can have on power. At the gate level a power expert can save the design 10% to 15%. If you get up to the TLM decisions with software and hardware, you can achieve huge power savings. Maybe you only 30% accuracy, but the decisions you make can have a bigger impact.
Martin: That’s where configurable processors can open up a whole new area. You can get a 10-to-1 improvement in performance in terms of the instructions for deep dataplane applications. You can get a 3-to-1 improvement in energy consumption.
Kulkarni: You are doing so many tradeoffs at ESL that you are purposely making assumptions based on how long it will take. If you add more accuracy to ESL what that means is you are really adding synthesis. That will explode the runtime. The designs are getting so complex that for the next tablet there will be 1 billion gates. That’s an unheard of number for mobile applications. To do a what-if analysis for that kind of application it’s critical that it gets done quickly. In GPS vs. the iPod, for example, it’s critical to determine what kind of stimulus can be provided for ESL. That’s the missing link for root power analysis. It’s better to optimize timing and area, but it gets more difficult to optimize for power. The more analysis you do, the more synthesis you put under the hood, which will expand the run time.
McCloud: I don’t think you can do any reasonable level of power estimation without some realistic switching activity represented. Otherwise your estimates will be way off.
Martin: That just emphasizes the use scenarios. We run into design teams sometimes that don’t seem to fully understand the system constraints they’re operating under. They can’t identify whether they want to operate at a 200MHz operating point and a 40LP process, vs. a 500MHz operating point. But if you target close to the edge of a process the results you get in terms of energy consumption and peak power consumption can be way off. People really understand the usage scenarios and the constraints that system architectures put on operating points and operating constraints. Sometimes that’s missing.

Low-Power Engineering sat down to discuss reliability with Ken O’Neill, director of high reliability product marketing at Actel; Brani Buric, executive vice president at Virage Logic; Bob Smith, vice president of marketing at Magma, and John Sanguinetti, chief technology officer at Forte Design Systems. What follows are excerpts of that conversation.

LPE: Is a more complex supply chain causing reliability issues?
Sanguinetti: That does happen as a result of disaggregation. There’s third-party IP and the associated issues of putting it all together. The most common problem is when you buy a piece of third-party IP and you want it to do something just a little bit different. You make a change—or a third party makes a change and it isn’t fully tested. That’s the way bugs get introduced.
Buric: This touches the gray area between quality and reliability. That’s why people have standards. TSMC is developing TSMC 9000, which is just one measure of an ISO standard. When you build a complex device that’s how you make sure all sub-components conform to quality standards. That’s part of the equation. If you can’t establish quality standards you cannot manage a design these days.
O’Neill: Quality standards would mean things like toggle coverage and code coverage for validation and test programs?
Buric: Yes. Whatever you may need.

LPE: How disaggregated is the supply chain?
O’Neill: It’s becoming more disaggregated. Years ago when I started with Actel we designed the entire chip. We designed the I/Os, the logic, the routing and the programmable interconnect. Today, because of the complexity of our current and future generations of FPGAs, we’re sourcing pieces of IP from outside of our own company. There’s a supply chain issue there. We have to choose our suppliers wisely, as well as the products we purchase from them, and ensure that we’re consistent with our own verification and validation techniques. Going forward, we will do more and more sourcing of our IP as our products become more complicated.

LPE: As the foundries impose restrictive design rules at future process nodes, how will that affect reliability?
Buric: Restrictive design rules have always been there. They have not always been so obvious, though. They help reliability. If you don’t use them, then you have a fundamental failure in yield. Reliability is a marginal case of yield. They are establishing rules to minimize freedom of implementation on silicon, which will result in higher reliability. As the process matures, some of those rules may be waived. They can learn enough to see it is not impacting anything.
Sanguinetti: Over time, our coding requirements have gotten more strict. They don’t have the effect of design rules, though.

LPE: But isn’t this complexity hitting every part of the flow?
Sanguinetti: Yes, it is, and we’ve had to modify our product over time to put out RTL that is more regular and follows different rules. That has been a maturation process. But it’s on the order of 10s or 100s of rules, not thousands.
O’Neill: We see some movement in the end-user community and among their customers to impose coding standards, as well. If you’re doing a design for an industrial process at a petrochemical plant or something that’s safety critical you may be working to a certain specification imposed by intended operator of the plant. They will impose coding standards. Similarly, for commercial aircraft we’re seeing the certifying authorities imposing standards on the contractors, who in turn are purchasing FPGAs or ASICS to implement critical digital logic.
Buric: The European Community has been doing that with their contracts for the past 20 years. Companies have had to follow their codec style or they would not get the contract.
Smith: The challenge for the restrictive design rules is that if the foundries are too restrictive, people will not move to the next node. It will be too restrictive, too expensive, and far less attractive. We have a lot of customers designing at 40nm, but a lot of design is still being done at 180nm. There are reasons to go to 40nm—density and power—but there’s not free lunch. It costs more to do designs for all the reasons we’re talking about: verification, reliability and everything else.

LPE: Are the economics of reliability changing? Does it become more expensive to guarantee reliability at future process nodes?
O’Neill: Absolutely.
Smith: The number of rules and the number of cases you need to check for goes up, so it’s more expensive.
Buric: Reliability is becoming a liability. You have to design with that in mind and it costs you money. I have seen people doing it for alpha particles where it’s two-bit detection, one-bit correction. I’m now seeing algorithms with 8-bit detection. People need it or they wouldn’t do it. It costs silicon and it costs in the design.

LPE: Is reliability now part of the cost equation in developing a chip?
Buric: Yes.
Smith: For the fabs, definitely. They’re staking their reputation on being able to deliver a product that meets certain standards. Being able to test that and then being able to somehow abstract that and do a bunch of rules so folks like us can take those rules and make sure everyone follows them is a tough job.
O’Neill: From an FPGA standpoint, we’re not designing for a single application. We’re designing for a whole range of applications. We go from consumer electronics applications, which have a lifespan of two years, to military and aerospace systems that have to survive 20 years. We don’t have the luxury of just designing an FPGA that just survives two years. We have to design for the maximum lifetime. That really causes us to look very carefully at the tradeoffs between density, reliability, power and performance.
Sanguinetti: What would you do differently if you could design products just for the consumer electronics market?
O’Neill: Let the parts run hotter so the power density would be higher. There’s a tradeoff there, too, because you need low power to conserve battery.
Buric: You could save on the package, too.

LPE: Is reliability considered essential all the time?
Buric: It is company-specific. It’s hard to see a trend. In the consumer market, cost is critical. In that market, failure is measured against cost of replacement.
Sanguinetti: If you have a TV set that drops frames every 30 seconds or you get a blocky picture, you get a bad reputation and no one buys your products.
Smith: It depends on the application. In military and aerospace, it’s vital to be reliable. On the other extreme, if you go into the Hallmark store and pick up a card with a synthesizer attached to a battery, it has to last through the shelf life, but design for reliability is minimal.

Low-Power Engineering sat down to discuss reliability with Ken O’Neill, director of high-reliability product marketing at Actel; Brani Buric, executive vice president at Virage Logic; Bob Smith, vice president of marketing at Magma, and John Sanguinetti, chief technology officer at Forte Design Systems. What follows are excerpts of that conversation.

LPE: As we push to the next process nodes, do all of the tricks of power islands and multiple voltages become more common in designs?
Buric: No, because people will look at the cost of implementation. We have customers looking at simulating and figuring out what are the power savings of switching something off and turning it back on. That costs power. They are doing fairly complicated analyses and staying away from these techniques if they don’t have to use them.

LPE: If you implement all of these techniques, though, is a device more reliable or less reliable?
Buric: In my opinion, it becomes more difficult to make it reliable. But it’s all comes back to your capabilities. If you know how to do it and you’ve done it before, it’s more difficult but you can still do it.
Smith: I don’t think it’s de facto less reliable. But it makes it a heck of lot more difficult to maintain reliability. That requires a lot of work. The other side of this is that low power used to be just battery-powered devices. Now it’s part of the overall Green movement. Everybody is searching for ways to cut power. About 1.5% of all the power generated goes into servers, server farms, and the cooling associated with it. We have a lot of wireless customers. Power is a huge deal. Reliability is a huge deal, too. If you have a phone that dies all the time, the manufacturer is going to go out of business. But we’re starting to see more of a focus on low power for things people plug into the grid, and the government is starting to mandate that. Reducing power without giving up the reliability is very hard.
Sanguinetti: That’s true even in this industry. Quite a number of companies have verification server farms. You run your regression tests with 10,000 processors. That has a power bill of about $1 million a year. That’s a lot of electricity.
Buric: We have 1,000-plus processors just to do fairly straightforward tests. One of the things that is responsible for what’s going on here at the lower technology nodes is that IP memory and logic design and EDA tools help solve reliability problems that may be caused by calculation errors from migration that overload certain parts of the design. It’s much more critical on the current nodes than before. You have to properly characterize IP and use synthesis, high-level synthesis and place-and-route tools to avoid any potential reliability problems in operating conditions.
O’Neill: We’re all coming at this from a variety of different directions, but in our world we see an intersection between low power and reliability. This is from a system-level for high-reliability and outer-space systems. The motivation for achieving low power in the consumer space is battery life and the greater good of the planet. In military and aerospace, battery life can be important in handheld radio systems, but there’s much more interest in reliability. Power becomes a reliability issue for a different reason. There are a lot of very high-performance systems where they can’t have forced cooling. The cooling fan itself is a factor in reliability. Fans can fail and they can increase the risk of foreign debris, which can cause short circuits and add other reliability risks.

LPE: So it’s imperative to lower the power in the parts?
O’Neill: Yes, because as you increase the performance of these systems, more power is being generated. That means more heat, and heat equals reliability risk. There are very few failure mechanisms that decelerate with temperature. Most of them accelerate with temperature, and some of them accelerate exponentially. So minimizing the heat dissipation inside enclosures that have very complex systems running inside them becomes a primary issue. People often come to us seeking low-power FPGAs because there’s some other power-hogging device inside the enclosure generating a lot of heat. They need to minimize that. They can’t afford another heat-generating device.

LPE: Do devices that use lower power last longer?
O’Neill: Given the same process node, if you run at lower power you’re probably going to have better reliability because your junction temperature is lower. That’s going to result in prolonged life.
Buric: If you look at what people are doing with end of life now, they’re saying lower temperature will extend the life. It’s very clear that if you go to overheated conditions where a lot of parts become unpredictably fast then you have a very high chance of a device completely malfunctioning.

LPE: Where does this get designed in?
Sanguinetti: We don’t have any visibility into this.
Smith: Neither do we. It’s something our customers have to deal with. Our job is to get them from concept to manufacturing. Their job is to figure out the application and the expected lifespan. In some applications, a year is fine. If it’s going into the engine controller of an automobile, a year is not fine. That would be more like 15 or 20 years at a minimum.
Buric: End of life is primarily a process function, and for that reason it is analyzed and characterized at the device level. A lot of people simulate end of life, and those models are typically provided by the process side. These are similar to any other SPICE model.
O’Neill: When we design a chip, we design with a package that comes from the foundry. That package will include things like the design rules, which are decided by tradeoffs between reliability, power, functionality and sheer utilization. You want to cram as much logic into as small a space as possible, but you’d better not exceed the electromigration rules or whatever other rules are in there for reliability.

LPE: In the synthesis world, what’s the biggest reliability issue?
Sanguinetti: Logic errors. It’s getting the design right. The issues that our customers have, aside from the spec being wrong, is interfaces between blocks or sections of the design that are done with high-level synthesis and those sections that are done with legacy RTL or manually. That’s where the opportunity for errors is the greatest. When you’re within the confines of high-level synthesis, the opportunity for error gets reduced and the verification problem is reduced. But at those interfaces there’s a lot of potential for miscommunication.

LPE: As the industry becomes more disaggregated, does it become more difficult to pinpoint the source of reliability problems?
Buric: No. Problems are well defined and everyone has to take responsibility. If you go back to our discussion about radiation and alpha particles, you design to eliminate that problem. That design can be in the memory space or error correction. You know what the problem is and you solve the problem. If the problem is end of life and the technology provider gives you all the guidelines, then you design with those in mind. If you own the design, you own the problem. It’s in designers’ hands and it’s a well-defined boundary.
Smith: It’s a gray area. In the ideal world, we get a set of rules from the foundry. There are thousands of them, and if you do this and this then they’ll stand behind the process in the design. For a big part of the population, that’s the way it works. But the people with the deeper pockets will go back to the foundry and say, ‘Let’s talk about where these margins really are because we need to do something special for this product line.’ They’ll get the data, analyze it, and they may design outside of those guidelines. The rules are the rules except when you break them to get an advantage, and then you’d better have the time and the money to go analyze everything to make sure you don’t end up with a product that fails or doesn’t yield.
Buric: You actually don’t break rules. You define a new set of rules that are mutually agreed upon. If you set those rules unilaterally, you’re shooting yourself in the foot. Memory cells have violated every rule, but they’re so predictable in manufacturing that they can violate the rules. All of those are mutually agreed upon, though.

By Ed Sperling

Low-Power Engineering sat down to discuss reliability with Ken O’Neill, director of high reliability product marketing at Actel; Brani Buric, executive vice president at Virage Logic; Bob Smith, vice president of marketing at Magma, and John Sanguinetti, chief technology officer at Forte Design Systems. What follows are excerpts of that conversation.

LPE: Do chips become less reliable as we start adding power islands, multiple voltages into the mix with smaller line widths and multiple cores?
O’Neill: As we go down the process curve, one of the effects we have observed is that radiation effects are no longer the domain of designers just working on aerospace systems. We’ve seen radiation effects start to become dominant from a reliability standpoint in commercial ground-level systems. These are background neutrons in the atmosphere. That can cause memory cells to have single-bit upsets, and the consequences can be severe. For most applications, you don’t care about a single bit. In consumer electronics, it may be a pixel changing color. But if you have system-critical data in a server or a router it could mean enterprise-class equipment having field failures.
Buric: All of those effects started showing up at 90nm when people started doing a serious analysis of the radiation space. It’s not getting better. It’s getting worse each node. There are two aspects of dealing with this. One is how the system is designed. The other is how system designers can further ensure that nothing has happened.

LPE: Does it show up on the design side?
Sanguinetti: We don’t see it directly, but our customers are putting tighter requirements on the style of RTL that we produce. Most of it includes locally produced rules. Those rules have been developed to ensure a smooth transition through the back-end flow. Now they’re starting to add rules it will produce better results. That’s about our only exposure to the physical side. The other piece of reliability is whether you’ve got the logic right, and that’s just verification.
Smith: On the implementation side, reliability is more around design rules. Presumably some of these effects are covered by those rules. What’s most important in our world are the low-power effects—multiple voltage domains, turning blocks on and off, dynamic voltage frequency scaling. The question is how you model that design so it will be reliable under a bunch of different operating conditions. It’s now multi-load, multi-corner and multicore. We’ve seen designs that have up to 100 different models. That affects reliability.

LPE: From the standpoint of all the multiple everything, does it become less reliable as you keep dropping the voltage?
Buric: You’re talking about a badly implemented design. We have customers today that, because of technology scaling, have thousands of memory instances on the same design. This is a nightmare by itself. There is also a lot of process variation. You need to make sure that the same device in place ‘A’ has the same performance on place ‘B.’ You have to consider all of that. If you do it wrong, you don’t get proper yield. But you also might have a chip that escapes detection in the test but which has problems in the field. We have customers making hearing aids. They are trying to drop the voltage as low as you can get, and they are really hitting the limit at low voltages for both how to maintain content in memory and how to operate. Then the design misbehaves because they are pushing the lower corners of performance. On advanced nodes you also have a phenomenon of low voltage combined with other low voltages behaves much worse than a typical array. That creates additional reliability problems.

LPE: Finding all the corners and verifying all the various pieces is getting harder. What’s the impact on reliability with that?
Smith: The amount of time that’s being spent on verification, particularly on small geometry and very complex chips, is rising. Implementation and place and route is still a huge job. But the verification is taking more time. Most of the verification flows are 15 years old. Variability on chip is a huge effect. At 180nm we didn’t have to worry about that very much. At 40nm and 28nm, it’s a big concern. Verification takes a lot more time and more compute power. It now takes a CPU farm. The industry is ripe for big change there. In terms of reliability, it depends on whether you’re going to do a marginal design or a really good design. To do a good design you have to do a lot of verification and you have a lot of operating conditions. And if you’re doing a low-power design and using all these techniques, there are likely to be a lot of operating environments. Then you have to consider all the corners in the process. When you multiply those out you have hundreds of different scenarios.
Sanguinetti: These issues are less important for some products than others. But the line between what we think of as consumer products and other products is blurry. Is an industrial printer a consumer product? If something goes wrong there, you may get degraded quality. But what if it’s a prototype of a device that prints 3D models. A failure there, or an intermittent failure, can result in something a good deal worse. Is a hearing aid a consumer device?
Smith: Or a pacemaker?
Sanguinetti: Reliability also is a bigger issue if you have to reboot something. Do you really want to reboot your television or your hearing aid.
Buric: But when you talk about power islands and multiple voltages, those techniques are much less used than you might expect. It’s extremely difficult to use them in a reliable fashion. We see people staying away from using them, especially in consumer devices. It’s extremely expensive. If there was an easy way to verify them, that would eliminate some of the problems we face now. But right now, there’s much more noise than reality.

LPE: Is it the same in the verification world?
O’Neill: There are two aspects to that. There’s the verification we as a company do. And then there’s the verification our customers do on their designs when they’re getting ready to program the design into a part. From the customer perspective, the changes we’ve seen are scaling linearly with the fact that they are doing bigger and faster designs. But it’s not an exponential increase in the amount of verification and validation of those designs. A lot of the deep submicron effects are somewhat shielded from the customers by the fact that there’s a level of silicon design and we just give them a tool to place logic into this part. The onus is on us to design our FPGA with as much competence as possible to mitigate the deep submicron effects. From the point of view of the design teams at Actel, they are spending more time using more complex tools to do verification and validation of their designs. In addition to implementing programmable gates and routing structures we’re adding hard IP into our parts. That includes multiply/accumulate blocks, increasingly sophisticated I/Os, different flavors of SRAM cells and various forms of non-volatile memory. All of those things represent different types of what is effectively ASIC design, and it’s now being done by the Actel design team. We, on the other hand, have experienced an exponential increase in validation and verification.

Low-Power Engineering poses two questions about reliability  to Brani Buric, executive vice president at Virage Logic: Ken O’Neill, director of high reliability product marketing at Actel;  John Sanguinetti, chief technology officer at Forte Design Systems, and Bob Smith, vice president of marketing at Magma.

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.

By Ed Sperling

LPD: How much does software affect the overall system architecture?
Buric: It can affect it quite a bit. If you look at Linux, that is a growing standard worldwide. There are more than 10 suppliers, so their target market is fairly limited and there is no common spec. So they overdesign to make specs for different target markets. Those are areas where if you do everything from a system-level design, you can save a lot because you can optimize where to share implementations.
Ng: One of the problems we see is the legacy mindset. Because the time-to-market pressures are so great, most companies don’t have the time to go back and re-do their design infrastructure. If your design teams are designing the next technology, they’re more than likely leveraging their previous designs. But because that wasn’t captured at the system level, it’s hard to go back and get an optimal implementation. You’re fighting to get this chip out the door and generate revenue. It’s not a matter anymore of trying to find the optimal implementation. And because of resource constraints, nobody has the luxury of having one team doing the implementation of the next design and having another team off to the side doing the more strategic infrastructure and maybe generating models for some of the existing IP that’s already been proven.
Sanguinetti: No one wants to take something that works and write a higher-level model of it.
Kroll: We do see that happening more often, though. People do see the value of the models and being able to integrate that into the whole system. More people are investing in high-quality models, verifying them upfront and making sure they represent the hardware. You can annotate technical information from downstream back to the model so that you really can do the verification or validation of the chip complete at the beginning. Then you have the process and also the possibility to say, ‘I have an RTL model of this. Does it still match the specification?’ Or if the software running on an FPGA doesn’t work you can go back to the model and match the software to the model and find the bug.
Ng: If the industry shifts to where designs get outsourced to the fabless ASIC guys—and from a business need that has to be there—then it might accelerate all of this. But it’s very tough for a newer company that doesn’t have a lot of legacy stuff.
Sanguinetti: That’s absolutely right. It’s the legacy stuff that gets left behind. For new code and new implementations, there’s a tremendous amount of value in ESL with faster time to market and better quality RTL. What we hear from our Japanese customers, after two generations of using this, the top thing they get out of it is IP re-usability. This was a revelation to them and to us. The real value of ESL is IP re-usability.
Buric: This trend will happen. About 20% to 25% of fabless startups today have, as part of their business plan, where they create a working component for something and then to sell it to someone who has a more complex chip. That is one trend. Another trend is the big companies are selling components like Bluetooth into even more complex designs for big bucks. You need a consistent way to transfer that knowledge. This trend of building bottom-up models will be there.

LPD: Does this trend toward a higher abstraction layer open the door for more startups, or does it close the door to them?
Kroll: I think it will open the door for more startups. If you can develop a component and it can be integrated in a chip. People can develop a technology or an FPGA prototype and sell it to a bigger company.
Ng: We have a couple customers. One we’ve supported on a 65nm process. They went out of the chip business and they’ve sold their designs. Now they handoff their design, which gets integrated into their customers’ larger design. In effect, we’ve lost a customer. Instead of selling the chip, they’re selling the design. I’ve seen a few instances of that.
LPD: There are a lot of companies that have their own homegrown tools. Does complexity make those tools less valuable over time?
Buric: If you think about the way the industry has grown up, there are two directions. Established companies figure out ways solve a number of problems specific to them. Equally important, a large number of startups have experience with individual problems and develop tools to solve those. There is a lot of internal knowledge captured in the early phases of design, and I believe there will be a lot of startups based upon that knowledge.
Sanguinetti: I agree with that. The fundamental dynamic of EDA involves people who had a problem, they leave the company and form a startup because they think they have an idea of how to solve it. They develop a solution to the problem and then get acquired by the consolidators. I think that will continue. The only fly in the ointment is it’s becoming harder to solve a problem in an EDA context, and that’s becoming increasingly necessary. As the consolidators have gotten bigger and have more influence they put roadblocks in the way of little companies. System Verilog is a killer for someone who wants to support RTL’s input. They have to import System Verilog test bench code as input. They have to spend man-years on it, whereas 15 years ago doing it in Verilog wasn’t too hard. Things have gotten harder for the little guys.

LPD: They’ve gotten harder for the big guys, too.
Kroll: One of the thing that needs solving is where do the models come from, who can use them, and how to improve success with them as a vehicle to solve problems. Currently, the big guys have the manpower to build those models. Maybe everyone needs to pitch in and have the models available. TLM 2.0 is one of the bigger opportunities out there. Right now there are IP vendors developing models, the semiconductor companies are also developing models and then the ESL companies are developing models.
Buric: Once we have enough models out there it will be chaos, and then there will be standards.
Ng: There are a lot of proprietary systems out there and it’s easy to develop models for those within that context. If at some point those systems run out of gas, you can have a wider solution and more standardization and collaboration.
Buric: Another problem is that certain groups create obstacles. They don’t want to adopt a common model. This will continue for awhile. If I create something in silicon and it fails, that’s my problem. For that reason, there will be constructive paranoia. Failure costs a lot. On advanced process chips, you can’t fail.

By Ed Sperling

Low-Power Design sat down with Walter Ng, senior director of platform alliances at Chartered Semiconductor; Brani Buric, executive vice president of sales and marketing at Virage Logic; John Sanguinetti, CTO at Forte Design Systems and Andrea Kroll vice president of marketing and business development at JEDA Technologies. What follows are excerpts of that discussion.

LPD: What will the differentiator be in the future?

Sanguinetti: We have to take as input designs that are relatively high level. Our customers tell us the higher the better. We spend most of our time in raising the level of abstraction. But we also have to be cognizant of what happens downstream. We don’t want to put out RTL that is junk. And it can’t just be acceptable to the tools. We want to put out RTL, for example, that can make dramatic improvements to power optimization. That’s true with any of the logic synthesis tools. But we don’t have very good visibility downstream, so we’re very reactive.

Ng: On our end, everything is about cost. Cost touches time to market and all the specs. We’re seeing much more widespread adopting of ESL tools. If you’re looking at power and selection of architectures, that can be most influenced at the system level. At the gate level, optimizing on power techniques, the wrong selection of an architecture can more than skew what kind of power you’re going to get. With more integration happening because of silicon’s capabilities, the more complex functions and the more important ESL should be. Getting from the algorithm level through system description, RTL and the physical implementation is a huge cost. The verification of each one of those representations is a huge cost. The more structured that approach can be, the better. Most of the leading edge of design is consumer applications, and these are extremely cost and power sensitive applications.

LPD: Why hasn’t ESL taken off until now?

Buric: It did. But there’s a difference between what has been used and what is commercially available. ESL has been adopted in one form or another over the last 15 years, at least. Most of those are internally developed tools targeted at a particular application. If you want to move from there to the commercial market, you have to make those tools very generic. That makes the problem more difficult to solve. But complexity of designs is going through the roof, so you have to start using these kinds of tools everywhere. If you’re not first-time right, you can lose your business or even your company, but you certainly will lose your market opportunity. It is now a must-have to make sure everything downstream matches your intent.

Kroll: One of the problems in ESL is the models are not of sufficient quality to estimate what’s going on in the technology later on. What is the power consumption, what is the area and what is the cost factor for the models. That’s the problem in the commercial market. You can’t make the tools broad enough and still use them for a specific task in an individual company for a specific application.

LPD: Does the number of models increase for each node?

Sanguinetti: That’s the way abstraction goes. We recognized we need a higher level of abstraction in ESL for the past 15 years, but it’s taken a long time to get to any kind of agreement about what it looks like. There are a number of approaches to it, which are largely overlapping. That’s what happened with SystemC. It took a long time before it became a standard. TLM is the same. There were a lot of ways of abstracting out interfaces. That’s why there are a lot of different models.

Kroll: They just specified TLM 2.0 last year.

Ng: As more folks come to adopt ESL and more is flushed out, this is part of a natural maturation of the process.

Buric: As this happens, you’re also going to see the rise of a second generation of ASIC vendors—eSilicon, Open-Silicon, Global Unichip. And due to design complexity, there will be an ESL signoff between design intent and design implementation if you don’t have a clear signoff.

LPD: Can ESL handle all the power islands that are cropping up in designs?

Kroll: I don’t think so. There are people already doing power analysis with SystemC and TLM 2.0. They are switching off components and making sure the dynamic power is captured properly. There needs to be more standardization on how to do it.

Sanguinetti: ESL can do anything. You can write lower-level code in your higher-level environment. It’s a bogus complain about ESL that you can’t do this or that. Maybe it’s as much effort to do it if you weren’t using ESL, but that doesn’t mean it can’t be done. In some cases, ESL hasn’t made your life easier—yet. But that’s where continuing work will be done.

LPD: Such as?

Sanguinetti: Power islands. Right now you put a module in one domain, another module in another domain, synthesize them and hook them up with an interface. Writing that abstract interface is work.

Buric: It becomes structural ESL. You have to partition the problem.

Sanguinetti: You want to be able to write code at a higher level, and what you take advantage of is the language’s expressability and the tools’ capability.

LPD: As we get to the next several nodes we’re facing restrictive design rules. Does that limit the demand for ESL?

Ng: Now that the flow is a connected flow, through RTL to physical, more and more people will be adopting it. They don’t have a choice. The challenge is creating a really good representation of the physical design at such an abstracted level. Even developing a synthesizer to put out good RTL good, dealing with the different interpreters and synthesis tools, is a challenge when it comes to power. Connecting that physical implementation is to the highly abstracted algorithmic world is difficult.

LPD: How do changes at the smaller geometries affect RTL?

Ng: From an RTL standpoint, not much. But it does affect the implementation of gates. We’re getting to the point where we will have to question what physical structures are allowed. We’re not saying they’re bad or good. But it will be a fairly limited set. From that to gate-level implementations that leverage those changes. I don’t know how you can comprehend that in a model. It’s more constraints on the physical implementation.