By Ed Sperling
Standards groups are beginning to look at power and other physical effects much more seriously in the wake of the dueling power formats—UPF and CPF—that have caused angst across the design industry.

To put it in perspective, when CPF and UPF were first introduced power was something of an afterthought in design. At 65nm it ceased to be something that could be dealt with later in the design process, and at 28nm it has become an essential part of the architecture. But as battery life, mobility, and energy costs even for plugged-in devices become overriding concerns, power now needs to be considered at full system level, which could mean everything from a rack of servers to an automobile.

Much of this is being driven from the chip level, and in the software that manages chips and interactions between chips. There are at least a half dozen new standards efforts under way or on the drawing board. Most heavily leverage the expertise of chipmaker and where they have encountered or expect to encounter pain in designs, most notably in stacked die or in planar SoCs below 20nm, or from tools vendors that have gained expertise in a specific area.

Si2 currently has one standard in legal review for system-level power modeling. The standard is called “atomic” power modeling, based on the assumption that the model cannot be broken down into smaller pieces, although it can be used at various levels of abstraction.

Also in the works is a standard for co-design, which is one of the most difficult challenges facing design today. While hardware engineers are well versed in how to build an energy-efficient chip, that engineering effort can be wasted if the software running on an SoC isn’t energy-efficient, as well.

“The first step is to get there with the architectural ESL level,” said Steve Schulz, president and CEO of Si2. “Then, we will look at how the software runs and develop a bridge. You will never get the software community to adopt the hardware approach to design. That community is 20 to 30 times larger than hardware engineers and they have their own tool flows. We have to think about a minimally intrusive solution. We’ve called it a bridge to the software world, and if it’s not intrusive then the software teams will use it. Most of them will never understand concurrency and how to get to a GDS II stream, but there are characteristics that are reasonable proxies of the details. You don’t simulate all the code, but you do generate enough discrete choices so everyone can get on the right track for power.”

A first step in that direction is finding data objects that can be passed back and forth between the software and hardware teams. From there a power model will need to be created across both. The power-flow group within Si2 has been reactivated to develop a source for the power model. “The focus this year will be hardware,” said Schulz. “In 2013 we will turn our attention to understand the data objects stored.”

That puts the likely adoption timeframe a of a co-design framework for power in the 2015 time frame—roughly at the 14nm process node and at a time when 2.5D stacking is expected to be mainstream and 3D stacking will become more commonplace.

Stacking effects
“There are two new requirements for design,” said Andrew Yang, president of Apache Design. “The first is a 3D IC flow. The second is an RTL-to-gate power methodology.”

Included in the 3D requirements is the need for multi-die thermal and stress analysis. Yang said the key is the amount of current a design can sustain without failure over time, and it gets worse at advanced nodes and sometimes in stacked configurations because wire handling capability is decreasing, power density is increasing, and electromigration is increasing.

3D IC thermal stress analysis. Memory die is impacted by power distribution of logic die. Source: Apache Design.

“This can be a safety issue,” he said. “You need to make sure the metal topology is handled correctly. Electromigration is affected by heat. The hotter it gets, the less current a metal wire can sustain. The electromigration rules are increasing, which is why GlobalFoundries, Intel and TSMC are all coming up with complex electromigration rules.”

Front to back, back to front
Being able to get a chip out the door at all is a challenge, which is why there are more standards being dictated from the foundries these days. In addition to process variation, continually shrinking geometries is making it harder to obtain adequate yields as quickly as in the past. That has led to more rules for place and route, test, IP, and layered across all of those is power.

“We’re seeing it in the available sizes, speeds, memory and logic cell sizes,” said Chris Rowen, CTO at Tensilica. “That’s what we target—area, power and process compatibilities. Whether that’s stacked or conventional die is affected only subtly. But with die stacking you will see significantly higher bandwidth and less latency, which will have an effect on modeling of the system. It’s not a qualitative change, but it is a quantitative change. It won’t change how one DSP communicates with another, but it will change how DSPs communicate with memory.”

How much of that will be standards promoted by standards bodies versus de facto standards from the largest foundries remains is unknown. Also missing are good open standards for on-chip debug and trace, said Rowen.

ESL standards
One of the most glaring holes in all of this is at the ESL level, where standards for power models are non-existent. While this isn’t a big problem in a single vertically integrated company, it’s a huge problem in a disaggregated supply chain where various companies work on designs—something that will become even more pronounced in stacked die where subsystems at different process geometries need to be integrated with other subsystems.

“What’s missing is something that allows companies to exchange power models, especially for IP-based designs” said Ghislain Kaiser, CEO of Docea Power. “In an ideal flow you would be able to take the IP from the IP suppliers and put together a power model and assess the power impact on the underlying hardware. But you also need to have interoperability between suppliers and customers that goes beyond the semiconductor level. It has to be optimized at each level—the SoC, the chip set, the PCB and above. So there won’t be only one number.”

The accuracy of those power models also will shift throughout the design. At the beginning a model may be only 40% accurate, but at the end it may need to be accurate to plus or minus 5%, Kaiser said.

Other pieces are missing, as well. Kiran Vittal, senior director of product marketing at Atrenta. “Right now, when a designer uses memory they don’t realize the code they are writing is not optimized for power. When you read memory you get a redundant read. The controller code isn’t optimized for memory. And all of that has to be networked, because you may have as many as 2,000 memories in a design. If you do it right you can save about 20% of the memories and the power needed to run them.”

To show just how bad this can get, a large systems house was designing a chip was required to give an early indication of its power budget to the OEM. The OEM used that estimate for calculating its own power budget and came up with a spreadsheet that represented the total design. The problem was that the spreadsheet ultimately was off by 100% in its power estimate, which in turn caused problems with the final device and greatly increased the amount of time it took to successfully bring a product to market.

“A lot of the ESL tools today know performance and area, but they don’t have a clue about power,” said Vittal. “This is fertile ground for innovation.”

By Ed Sperling
Concern over getting the heat out of stacked die is well defined, even if the current raft of existing and proposed solutions ranges from ineffective to exotic and expensive. What is less well understood is how to plan for and manage power inside of stacked die.

While power and heat frequently go hand in hand—where there is heat there is almost always power dissipation—they can be very different from a design standpoint. Each can be affected by the other, and each needs to be modeled as part of a holistic design, but system power budgets may be too high to be acceptable and still low enough not to cause thermal issues. Nevertheless, the number of power issues that can result from stacking die can be far greater simply because there are more possible permutations, and so far there is little information about how to solve this.

The reasons for the dearth of knowledge in this area stem partly from the fact that some of these devices are just now being built—the best knowledge about design always comes from experience and history—and partly because power can vary greatly from one system to the next, from one user to another, and sometimes from one chip to another even within the same design. In a stacked die, all of these come into play in the same package, often with unexpected results. That makes it difficult to model power accurately enough up front, and equally difficult to deal with as the design progresses.

“We’re seeing some complex power management schemes emerging,” said Mike Gianfagna, vice president of marketing at Atrenta. “The problem is that if you have an error, you automatically generate incorrect power management circuitry. The opportunity is to enhance much more complex verification schemes to deal with this.”

He noted that many large chipmakers have their own homegrown version of power modeling, but it will take time—and standards—before there is a systematic way of dealing with it.

What needs to be addressed where
There are several distinct points where power needs to be addressed in a design. The first is at the architectural level, where modeling will be inaccurate. But it can be accurate enough to get an idea of which IP, including processor cores, to choose, which memory, various interconnect schemes, and I/O preferences. Each of those has a different effect on power, and together they have a cumulative effect.

“As you go down in the design flow you refine the power models and the software,” said Ghislain Kaiser, CEO of Docea Power. “But your accuracy depends heavily on the IP. For some IP, if you have an error of more than 20%, it will impact decisions later on. For IP that is small and not power-hungry, an error of that size may not cause any problems. But you do have to think about the global impact of the power, especially in a stacked die.”

While this is complicated enough in a planar SoC, it becomes even more complex in a stacked die because not all of the pieces are necessarily built at the same time. In addition, IP blocks and even entire subsystems can interact in unforeseen ways, sometimes decreasing power consumption as with Wide I/O, and at other times generating more power than anticipated because of unexpected proximity and other physical effects such as increased temperature.

“There are lots of things going on,” said Andrew Yang, president of Apache Design. “The voltage is fluctuating, so you’ve got on-chip voltage regulators to stabilize the power supply and back biasing to further reduce leakage power. At 20nm, reliability is becoming a key driver. Electromigration and electrostatic discharge are now mandatory for robust volume manufacturing. And we’re not just dealing with IR drop. In a platform solution, IR drop is one small item. You have to consider a full-chip power model.”

No simple answers
In addition to understanding power throughout the flow, Apache has been a strong advocate of understanding power over time, a necessary perspective that further complicates the design process with a fourth dimension. Power can be affected by a number of factors over time—even small increments of time from one die to the next.

“Die-to-die interactions are a form of variability,” said Riko Radojcic, director of design for silicon initiatives at Qualcomm. “You need a timer that understands thermal gradients and the impact of thermal gradients on time. There is a gap there right now.”

How to solve this problem is a big unknown, particularly when it comes to power. Power models and power numbers are dynamic rather than fixed, needing adjustments and tweaking throughout the life of the design and even beyond.

The general consensus is that none of this will ever be automated beyond a certain point, and no single tool will handle all of the power issues—even in 2D designs. In 2.5D and 3D, the number of options and possible interactions increases non-linearly. As the industry progresses into the next dimension, one of the biggest challenges will just be grasping all of the possibilities—and all of the subsequent effects that go along with those options.

By Ed Sperling
Low-Power Engineering sat down to discuss the increasing challenges of designing for mobile devices with Qi Wang, technical marketing group director at Cadence; Cary Chin, director of technical marketing for low-power solutions at Synopsys; Bernard Murphy, CTO of Atrenta; and Dave Reed, senior director of marketing at SpringSoft. What follows are excerpts of that conversation.

LPE: How real is wide I/O?
Wang: If you have unlimited resources and no restriction on packaging costs, even on the chip you can have wide I/O. You always want I/O as wide as possible. With 2.5D and 3D that will be the driving force. All the IDMs will keep developing the fancy stuff like FinFETs. Traditionally you go through the gate using source and drain, and the reason you have so much leakage is that your gate is so far from silicon that you control the other side. If you turn it around and put controls on the top and bottom of the silicon, the leakage is almost zero.
Reed: Other things that mobile drives is super-integration. Almost every chip we see has analog on the same chip as digital. That’s a noisy environment. You have to raise the voltages. But now you’re on a more advanced process than in the past, and some functions are moving into digital that used to be in analog. It’s done for power and availability. That’s a new architectural tradeoff that people have to make. Do they move it to digital or leave it in analog? Plus, people need automation there.
Murphy: Is the same thing happening with RF?
Reed: RF is coming onto the chip as well, but there are not the same tradeoffs as there are with other analog portions.
Murphy: I remember discussions about mono-chips where the whole smart phone including RF is on the same SoC.
Reed: I remember those discusssions, too. We had to give up gallium arsenide for a long time for RF.
Wang: One side of mobile is cost and low power. The other side is the signal. Anything that communicates with the outside world is analog. So every SoC is a mixed-signal chip by definition. We saw the same trend of moving things to digital. One reason is power. The other is when they define IP, they want to make it more configurable. They want to program those analog features. But analog is hard to migrate to the next node. If you move to digital it’s easier to migrate. So if you combine mixed signal and low power, that’s one of the big shifts in the market.

LPE: Do the tools exist for that?
Reed: I haven’t seen many. Are there any at the architectural level?
Wang: No. Right now we do it with a service team. It’s all manual.
Murphy: We’re seeing a lot more errors coming up around the mixed signal integration, too. And they’re subtle errors. When you put mixed signal together with power management you have things like level shifters and you find things aren’t quite characterized where you expected them to be or in the range you characterized them in. Something switches and the other side doesn’t switch. That’s a big challenge.
Chin: That whole verification area is tough. You can view the low power verification world today as a move in the direction of mixed-signal verification.
Wang: It originated from our old technology. We repositioned ourselves. Our previous methodology to speed up the design flow was analog and digital. The analog dealt with analog and the digital dealt with digital. Analog is a black box. You don’t even ask what is inside. The other side is the same. But that has to be changed. As ICs become more complicated, you can’t treat them as a black box anymore. It all has to be modeled and verified. The other side of this is that to move from analog to digital you have to do co-design. We are nowhere close to mature on that, but analog and digital engineers are working together because low power has to be considered as a whole.

LPE: But most of the engineers working in these fields live in silos. What’s going to change that?
Wang: On one side, the EDA vendors have to educate them in this methodology. There are a handful of very advanced companies in the world, but they don’t share their knowledge. To move the whole industry forward the EDA companies need to step forward. But we are starting to see more solutions architects to drive low power and mixed signal. I just came back from Taiwan and was promoting mixed signal models. The customer said they didn’t think that was a problem at the early stage. They would test a chip, find out what works, and go back and design another one. The customer acknowledged they will need to change in three to five years, but things will slowly happen.
Murphy: It’s not just Taiwanese companies. U.S. wireless companies accept they will have to do multiple spins because they cannot fix the mixed signal problems on the very first silicon. They’re going to put in enough redundancy to test it, and then they’ll fix it in the next one.
Chin: That’s really the testament to the need for tools in this space. When the customers are saying it’s going to fail, something is needed.

LPE: Let’s go back to the tradeoffs between Wide I/O and smaller I/Os. Do companies really understand this?
Chin: It’s the same problem we’ve been seeing on chip for a long time. It’s also related to this idea of dynamic power. What we’ve done for 20 years is optimize logic for performance, which means we care about the critical path. The way we optimize the critical path through synthesis is by trading off slack on other paths. You get a wave of transitions running through the chip. It’s an interesting tradeoff, because from the standpoint of power there’s nothing worse you can do. When you think about it from the standpoint of energy efficiency for computing a function, you have logic computing that function with a minimum of transitions and that’s it. Through this process of optimization we’ve folded everything onto itself. It’s re-use and resource sharing at a high level, but if we’re not reclaiming energy then design methodologies will have to change completely. Some smart EDA person will invent a new tool that allows you to push forward with this old idea of not folding your logic or sharing pieces so you can achieve the lowest possible power. That’s exactly where these tradeoffs happen. 3D IC is one example for the packaging level. Within the chip, within the synthesis domain, the system-level domain, the whole idea of architectural assembly of IP and blocks, this plays itself out many ways. It’s an important concept with regard to dynamic power. It’s fundamental. It’s the multiplexor problem.
Reed: If you look at the way the CPU guys have gone, they’re already down that path. They’ve stopped frequency scaling. You have separate cores. You can shut these things down or run them slower. They’re using the silicon to buy better power.
Chin: But you have more stuff sitting there that’s inactive.
Wang: If you look back 30 years, the most expensive thing was silicon area. At that time you had to do resource sharing. You went from parallel to serial. Now we are taking mixed signal to parallel.
Chin: And massively parallel is just one function computed optimally for everything that comes out of a chip. Maybe you expand that to 3D IC where each one of those has it’s own I/O. It’s interesting to think about how the methodologies and flows will have to change as we move in that direction.
Murphy: Architecturally, people are doing that on SoCs. Instead of one big DSP or CPU, they’re moving more and more of this stuff apart. There are multiple CPUs. The bus structure is split into many levels of hierarchy so you can shut big chunks of it down.

LPE: How low can we drop the voltage? Is it just 0.7 volts or 0.8 volts?
Wang: It can go much lower than that.
Murphy: I’ve heard 0.1 volts.
Wang: It also depends on the size we go to. You can get down to 0.3 or 0.2 volts without any problems. If you keep the aspect ratio of the depth and the height of a FinFET then you can guarantee the performance, but you do have other physical effects. Nothing is free. But the voltage can go much lower than what the textbooks say.
Reed: The rate of voltage scaling has been slowing. Leakage was the consideration that has been slowing the rate of scaling, though.
Wang: Absolutely, because if you look at a traditional 2D device it’s harder to control the channel so the leakage is a problem. But we can continue dropping it for a long time to come.

By Ed Sperling
Low-Power Engineering sat down to discuss the increasing challenges of designing for mobile devices with Qi Wang, technical marketing group director at Cadence; Cary Chin, director of technical marketing for low-power solutions at Synopsys; Bernard Murphy, CTO of Atrenta; and Dave Reed, senior director of marketing at SpringSoft. What follows are excerpts of that conversation.

LPE: What effect does the wireless spectrum have on design?
Murphy: Spectrum availability is getting squeezed. That’s why things like MIMO (multiple input multiple output communications) are becoming interesting. But to support MIMO you need multiple radios or complex radios, and radios suck power. You have to deal with that problem to take advantage of whatever spectrum is left.
Chin: I’ve been doing a lot of experiments with power lately, and it turns out that the screen is not always the biggest power hog in the system. In general it is, but if you’re in an area with poor communications signals the radio draws a lot more power than the screen. This is why some people with the first iPhones were surprised that they were getting 1.5 hours of battery life. With multiple radios in a device today, it’s a big deal. My phone gets much hotter when I’m streaming something while driving around in my car with the screen off than if I’m at home in a WiFi environment. We’ve been working on cutting a number of cords in mobile. The power cord is the most recent. But the one we cut previous to that was Ethernet. It turns out that was a big deal. There are new standards. Bluetooth was notorious for being a power hog. The new Bluetooth standard improves that. But power is really a global issue. When I worked in synthesis, we thought a lot about divide and conquer. But the ramification of power is global. A picowatt in one quarter of the chip affects the whole chip. That’s one thing we need to think differently about. It’s not just physically adjacent blocks or logically connected blocks.

LPE: But some of these effects are also outside the chip, like multiple towers handling a signal instead of just one. How you deal with that in the design? There are lots of disconnected pieces that aren’t even part of the SoC ecosystem.
Murphy: There is a lot of architectural power modeling. They’ll look at the SIM card and the battery and what’s around. Then you have to start thinking about where your transmission sources are, and as you move around between these things how much power are you using as you move around.
Chin: More and more we need to talk about this holistic approach for low-power design. You really need to think about everything in a global sense. It’s a difficult problem, and the solutions are moving toward more standardization and more IP. If we can take communications standards and have reasonably re-usable chunks, that will simplify things. But then having all of those things work together and making sure the low-power methodologies are consistent is not simple. We’re not going to run out of things to do.
Murphy: A lot of design teams thought they could handle power in the same way they handle test. The problem now is there is a much stronger coupling between power management and the design, so you can’t finish the design and then do the power management. They’re too interrelated. But you still need a high level of expertise to do the power management.
Chin: Power goes even above the chip-design process. It might even be something you need to think about before you think about the rest of your chip. And chip designers are pretty uncomfortable with that.
Wang: Most of our leading customers in the mobile market have come to the conclusion that they cannot address this from the same point of view. They have to combine software engineers, hardware engineers and system engineers all the way to the signoff. They need to work holistically doing modeling, estimation, create a spec, and at every stage check for the spec. We’re seeing more and more real customers adopting that approach. What’s ironic here is that EDA companies often get blamed for being behind, but in this case the EDA companies are ahead. They want to know why their power came up at 11 (volts) when then put down 5 (volts).
Reed: EDA is always a little bit behind the leading edge and ahead of everyone else. The people who have had to deal with power seriously for awhile have been doing just that. We’ve learned from them. But before test could be thought of separately it was part of everything else. It was great when you didn’t have to include test. It was liberating because you went from a small handful of people designing 7,000-transistor chips to tens of thousands of people designing millions of transistors. I have no doubt power will come to that stage.
Chin: I’m not so sure of that. I used to work in test and we created a methodology to make that separate. But in the case of power, it’s so closely intertwined that I can see the opposite happening. It may be power that’s most important, and whatever performance comes out is what we get. Design for power may become the biggest design parameter and everything else may fall beneath that.
Reed: Power debug has become a new thing you have to worry about, whether you’re using UPF or CPF.
Wang: Power has become an inseparable part from concept to silicon. Power is a requirement. It is not a technology or technique. If people want more functionality, it all boils down to energy needed to do the computation. In some ways, people have invented the problem. One CEO came to Cadence to talk about moving from desktops to mobile. He is trying to find a new market for his processors, so he is looking at medical and gaming. But what’s interesting is they’re not building games. They’re building simulators for physical effects. We need to worry about demand for bandwidth and power. And performance does not just mean speed. Bandwidth is part of the performance. Response time of downloading and communicating can be a bottleneck.
Murphy: And it still has to be within the cost envelope. Power has probably gone slightly beyond performance in importance, but it hasn’t gone beyond cost. Consumers are forever going to be cheap. If I could buy something last year for $200, it should be $50 next year.
Chin: But the iPhone is a $600 device that costs $200, so we’ve figured out different ways of paying for that to amortize the cost over time.
Wang: Cost is a constant, but that doesn’t solve the problem. The success of Apple is not just the device. They create a value chain so they don’t just try to extract the value from the hardware device. There’s too much competition for that. Another angle we need to consider is that it’s not just about consumer mobile devices. A much larger market for mobile applies to medical. In a hospital you will have thousands of sensors in one room. If you multiply that by the number of sensors you will have in your body, it’s a very large number. People want entertainment and they want to live longer. You don’t need a different methodology to low power and low cost. The application-driven business model will be the underlying baseline.

SLD: What changes if power becomes the starting point?
Murphy: FinFETs will have an effect. Intel thinks they’ve solved the leakage problem.
Wang: That creates a new problem, though, gate sizing. Previously you could increase the channel width to make the cell bigger. Now you have to make it higher.
Chin: As power becomes the most important factor for design, the design methodology and tools will change. You can envision that over the tools we use will be very different. Over the past 30 years we’ve defined a methodology that gives us the highest-performance devices for the lowest cost and the smallest area. But we’re optimizing for performance. If that changes, there’s a lot of room for new methodologies, new tools and new ways of designing. If you look at simulation tools, we’ve been doing logic simulation for at least 30 years. It won’t be long before someone introduces a simulator that simulates power as well as logic. Today we have lots of approximations that help to solve the problems we have today, but we go back to device-level simulation to figure out what’s really going on with power. With UPF and CPF, that’s a temporary thing. In five years design intent and power intent will be the same thing. I believe these things are going to change radically.
Murphy: But everything we worry about in mobile power is predicated on the fact that you are removed for a long period of time from charging sources. If energy scavenging becomes really effective the problem goes away.
Reed: In terms of things affecting designers, there are a number of them. One thing people have had to care a lot about lately is leakage. It’s been an ongoing challenge—whether it’s subthreshold leakage, so we turn these off harder, or the dynamic power. For 3D (stacking) we can reduce the power several ways if we shorten the connection. You also can widen the I/O and add more memory and memory channels.

By Ed Sperling
Low-Power Engineering sat down to discuss the increasing challenges of designing for mobile devices with Qi Wang, technical marketing group director at Cadence; Cary Chin, director of technical marketing for low-power solutions at Synopsys; Bernard Murphy, CTO of Atrenta; and Dave Reed, senior director of marketing at SpringSoft. What follows are excerpts of that conversation.

LPE: As we move toward the next process nodes and stacked die, we have lots of issues ranging from physical effects to software and hardware convergence. Are we making progress solving these issues?
Wang: The reality is that engineers are smart enough to find solutions and workarounds. The mobile market has changed everything—hardware, software, design methodologies, low power and mixed signal.
Murphy: There are a lot of challenges, but a couple of the obvious vectors for any mobile device are whether you can fit into a power, performance and cost profile, and whether you can finish verifying it before it becomes irrelevant. That will decide a lot of what you’re going to use to build it and what methodologies you’re going to use. With things like Android, some of the software choices are more obvious than they used to be.
Reed: We don’t run out of challenges to solve because we don’t run out of things we like. Who thought they needed to be able to watch a TV show on their cell phone? I just got back from Asia, and over there if you don’t have something to stare at on the train then it’s a long ride. We can and have solved any problems that have come up, and we will continue to do that.
Chin: That’s exactly what engineers do. We solve problems. One of the things we learned in the last five years or so, though, is that some of these problems that make chips fly off the shelves aren’t solved by purely technology. The iPod is a good example. It wasn’t the first MP3 player available in the market. The iPhone wasn’t the first smart phone, and the iPad wasn’t the first tablet. But those devices were flying off the shelves even though they didn’t contain the latest technology. As engineers we have to expand our vision beyond just technology as we move into this space of mobile devices and consumerism and what people are looking for, as opposed to who has the fastest processor or more storage. That’s a fundamental change in the market.
Reed: I agree that performance is not the driver anymore. It’s super integration. Consumers want a smaller footprint and they want better power. One thing I’m unhappy with on my mobile device is how fast the battery runs out.
Chin: We haven’t crossed the threshold of acceptability with power yet. I have chargers everywhere because it’s too painful to think about having my phone die. We’re not high enough on the power scale to say we have enough yet. Playing music back today is largely solved with the amount of storage and processing. It no longer taxes performance or storage. Video is where we’re running into problems today.
Reed: Data communications are a problem.
Murphy: If you look at the whole Apple lineup, it’s not leading-edge implementations of anything. It’s a new way of looking at the user experience. But I see that as a disruptive jump, and I don’t see every other player in the market doing disruptive jumps. All of the Android platforms are essentially clones of the iPhone or iPad.

LPE: This is like business drafting?
Murphy: Yes, exactly. You get some business jumps out of the iterative company like Apple, but the majority of the market is not doing that.
Wang: I agree that other phones are clones, particularly on the hardware. But I do see differentiation in the software. With hardware platforms it’s going to go the way of foundries. There are not too many of them in the world. Eventually they will all have the same DNA. But the software will differentiate the features, the look and feel and the power consumption. Where Apple did a good job is packing new technologies inside a user interface. If you look at the Macbook Air, there’s a video of someone in Japan using it to chop fruit because it’s so sharp. But I’m also amazed by the graphics and the battery life. I still believe performance is driving the business. Unfortunately, those fancy technologies are crucial to the semiconductor industry but we don’t get recognition. People don’t care about a 3D IC. They care about being able to watch a video. It should be more application-driven as opposed to 20nm. That’s not the driving force anymore. It’s the application, the software and the platform—and all of it put together to create a unique value.

LPE: We say performance isn’t important, but no one wants to wait for downloads. It’s no longer just a device. It’s how it interfaces with everything else, right?
Chin: But even that is in the context of the human interface. The speed at which I can push the button is on the order of seconds before you get upset about it. That’s different than the billionths or trillionths of a second we’re working on down at the engineering level. As you get new applications coupled with different things phones can do, you have to think about how those relate to power usage and efficiency. That has to be above a certain threshold, and today pushing 3D IC as a manufacturing technology to allow lower power is a good goal. There are other ways of doing that, too.
Murphy: If you look at 3D movies on a cell phone, then stacking die is the solution. If you have to do that much processing, that puts a lot of emphasis on memory. You can solve that with a big external DRAM, but battery life will suffer. If you stack a DRAM on top of an interposer, you can get good performance and battery life.
Reed: When you reach a threshold then continuous improvements lose value. With interactive tools, you need enough performance where people perceive it’s instant. Once you reach that point then you don’t have to do better than that. With bandwidth we certainly haven’t reached the threshold. Processing power, maybe. On my home computer I used to look for an upgrade every couple of years. I don’t look for that anymore.
Murphy: But on your handheld device that’s different.
Reed: I prioritize battery life over processor speed.
Chin: And that’s the interesting part. In the generation we’ve grown up with in technology, there hasn’t been a competitor to performance. Faster was always considered better.

LPE: How about cost?
Chin: In the consumer space, $1,000 for a PC was always good enough, and $2,500 for a high-end one was acceptable. That’s why a one-inch IC was the maximum you could build for 30 years. Those things didn’t change for a long time, despite these technological advances. But power is the one thing that is changing. You’d rather have it last an extra hour than run faster because you rarely run a spreadsheet on your phone.
Murphy: You don’t want it to run slower, though, for everything you’ve already got.
Chin: Above that line it can run slower because what I’ve gained is more time for the stuff that’s critical. That will change when we hit the next killer app. If everyone needs on-the-fly video encoding and recognition, that will change things.
Murphy: That’s cloud-based video.
Chin: Yes, and it’s coming. But we’re at the point where we need to define the next killer app. We did a really good job over the years, between Intel and Microsoft, of creating new versions of processors and apps that required each other. Today the stuff I really care about is not plugged into the wall, so power is a big issue. That doesn’t mean we’re done looking at technology. The piece that goes hand in hand with mobile is the cloud infrastructure on the other side of the communications pipe.
Reed: Low power does not equate to low technology, though. If you see the extremes people have to go to in order to manage power down at the silicon level, it’s extreme.

LPE: So how do we get the power down? Will it be 2.5D and 3D stacking? Will it be better software?
Murphy: All of the above and more.
Wang: There is no silver bullet. At the system level you have to go beyond the IC. In a mobile device the screen sucks up the most power. That needs to be tackled first. So if you can’t solve that, you add solar to the screen so it powers itself. In software, people are starting to recognize that’s an issue and they’re worrying about it. They’re developing tools and methodologies to solve that. Then if you go down a level the challenge is the packaging problem, which is why we’re talking about 3D ICs and wide I/O. You have to work all the angles. You have to squeeze out every bit of it.

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

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

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

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

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

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

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

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

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

The idea of developing software and hardware simultaneously isn’t new, but it has taken on renewed urgency in IC design because of growing complexity, including power and proximity issues. Low-Power Engineering captures the perspective of executives at four companies working in this market: Marco Brambilla of STMicroelectronics; Charlie Janac of Arteris; Mike Gianfagna of Atrenta, and Javier DeLaCruz of eSilicon.

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

LPE: What is concurrent design and how has the definition changed?
DeLaCruz: This is a legacy we created for ourselves because physical design teams can operate separately from CAD tool developers and packaging and everyone throws what they’ve finished over the wall. Concurrent design is a way of undoing the damage we’ve driven into our culture. We can do this by creating CAD tools that allow concurrent work on the same thing. Cadence, Synopsys and Mentor are all trying to create tools for this. Another way of doing this is by getting your people to talk together more effectively. That’s difficult because people have been told they should work in different departments, not talk to each other because things get messy that way and take too much time.
Gianfagna: There are two things that caused the problem. One is that we used to do things sequentially. You did placement, you did routing, and then you’d tweak the placement and timing would be closed and everyone would be happy. You can’t do that anymore. Now when you change placement you break timing. When you fix timing you mess up clock synchronization. When you fix clock synchronization you mess up power. And they’re all related. One breaks the other. So there’s a need to simultaneously optimize. Beyond that is an even bigger problem. The supply chain is now spread out. You’re dealing with a separate packaging company, a separate substrate company, and five or six IP developers.
Brambilla: There’s another level of complexity. My team does turnkey designs and ASICs. When it’s turnkey it’s easy. When it’s an ASIC you also have a huge separation between the customer doing the RTL and us doing the rest. There’s a big discontinuity. When people want to go to the next node, sometimes they’re approaching it with a software mentality and don’t realize that a forward loop becomes a million gates. Once upon a time we did software-hardware co-design. Now you have separate entities who say that’s your job and this is my job, and we have to cross-educate them.
Janac: You’re taking a serial design and that serial design has gotten longer, and now you’re trying to make it parallel. The parallelization of that process cuts the time. The answer is that you have to consciously create islands where this parallelization works and then have very well defined communication between those islands. Let’s take this problem of the RTL designer and physical layout separation. If the physical layout guys can get the constraints up front into the RTL, then the physical layout people will not get junk from the RTL designer. There needs to be a well-defined set of interfaces between those islands.

LPE: But this is all getting more complicated, right, and not just within a single block or subsystem? You have proximity effects because of density, you have electrostatic discharge issue, power issues, heat issues, software that may or may not work across the whole thing, and version-control issues on IP.
Janac: Within these islands you have to take into account an increasing number of constraints.
Gianfagna: We’re hearing it with timing constraints. The front-end guy needs to worry about timing constraints more. What we hear is that’s a back-end problem. It’s hard-wired into everyone’s brain that it’s a back-end issue, but that’s wrong. Is there a human issue here? As an industry we don’t have a great track record of changing quickly.
Janac: Atrenta had an advertising slogan that I liked, which is that timing closure begins above RTL. The earlier you solve some of these problems the cheaper it is to solve them.
Gianfagna: Intuitively that makes sense. When it comes down to the real world that isn’t always the case. People don’t always approach it that way.
Janac: But then their chips don’t come out. It’s hard to tell an RTL designer they have to worry about congestion. But if you give them a capability to eliminate that congestion, such as cutting wires in half, then they’ll use it. But if you tell someone they should speak French it’s not going to happen unless you teach them to speak French.
Brambilla: There are several issues here. I wish we could still work in islands. The islands are getting blurred, or they require more people from different functions to work in them.
Janac: You need to build bridges between the islands.
Brambilla: But you also need to populate those islands. They’re no longer homogeneous. We have started on 28nm devices. These are 17 x 17 or 18 x 18 mm. You’re talking in excess of 100 million gates for non-repeating logic. The graphics guys are doing 100 million gates but it’s copies of the same thing. There is still a problem of validation, but from a design point of view it requires a different amount of resources. When we’re doing a communication ASIC of 100 million gates, that’s all random logic. You have people putting 4x more gates in the same area with greater productivity. They don’t have time to worry about congestion. And they’re moving up, up, up in terms of higher-level coding languages. If I want to port to double the frequency I might have to change my bus width rather than just doubling the clock.
Gianfagna: That’s a microarchitecture change.
Brambilla: But you can’t do that in Verilog. At that point you’re talking to a software person or an algorithm person, not to a designer. Try to explain to that person what the structures are that can cause congestion. Sometimes I have trouble explaining memories to a designer. They don’t get it. There are Verilog designers who don’t understand what their Verilog becomes in gates. How do we ask them to be more proactive?
DeLaCruz: We’re victims of the way we used to be organized. I keep hearing this term ‘islands.’ I think it’s a big crutch. We’re just putting Band-Aids on this. These islands need to be moved. Within eSilicon, rather than the physical design team creating something that can cause problems with packaging, and packaging causing problems with PCB design, we moved the line. We overlap physical design significantly. The packaging team does floor planning, pad ring layout, and all the SSO operations on the die. By the time it’s gotten to packaging we know it’s done properly. All of our packaging personnel are mixed in with our physical design team. That’s blurring the line. The islands aren’t being kept separate. As we go to through-silicon vias, is that interconnect a packaging issue or a design issue? You can’t have the delineation anymore.
Janac: Why not give them the tools that isolate them from the complexity?
DeLaCruz: Let’s say you have a chip design that can be a certain die size, in round numbers 4 x 4. The physical design team wants to add more signals. If you go to 28nm, you’ve got all these signals and your die has to grow. They don’t know about all these things like silicon interposers, which would translate that 4 x 4mm die into an 8 x 8mm die.
Janac: You can have an interconnect that contains all the wires. Do you put all those wires on one die or on another die? You’re giving them the tools to deal with that.
DeLaCruz: You have to cross-train because 3D silicon is not a physical design issue. It’s a packaging issue. There’s a methodology in physical design. There’s an issue in packaging. It’s a little bit of each, and you can’t have different people doing each.
Janac: It’s a combination of training and methodology. You have to train your designers and tell them that a 3D toolkit is part of the methodology they have. And then you have to give them the tools to successfully implement their technology.
Gianfagna: You can come up with the tools. We in EDA can come up with the vision. But it doesn’t mean anything unless there’s a mandate from the top down that this is the way things are going to work.

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: Is a fully integrated IP platform an effective way of dealing with power?
McCanny: There are a lot of issues that we’re still trying to get our arms around. A lot of the tools we’re using were not designed with power in mind. We’ve adapted them. We’re using different constructs to handle power constructs. As an industry we haven’t designed from the bottom up for how power is managed and modeled. Platforms may help, but that won’t be a complete solution. There are still a lot of complex issues to be worked out, such as predictably modeling power. We also need pre-set rules for IP for what you can and cannot do with it. We need to know, for example, ‘This is how IP will behave when you power it up and power it down, and when you go from this voltage to another voltage.’ Right now we’re tweaking as we go along. You don’t know what the IR drop will be or how it will affect the IP block. You have no control over how the power supply is connected to that piece.
Rajendiran: We start somewhere in the middle. There are high-level system-design tools, and meanwhile there has been an explosion of nuances on the physical side. System-level design can be perfect, but then somebody has to map it to a physical and implementable device. If I had a set of functions I want to implement, I could choose hard IP from Supplier A and Supplier B. Each will have a different implication for power. Even where you put it will have different implications. One may cause a different IR drop than the other one. System design has not taken off because you need to know all the possibilities. There are gaps in between.
Gianfagna: Gaps are the enemy. You need everything to be implementation-aware all the way through the process. If you look at the high-level ESL companies that don’t exist anymore it’s because of those gaps.
Brock: A well-defined piece of IP differentiates on power, performance and area. But it also has to be usable. In the case of memory, you have to have a mesh across the whole thing so when you tack on the power you don’t get an IR drop all the way on the other side. If it’s from a reputable vendor you may not have to look inside because you know what it will do whereas if it’s coming from someone else you might have to poke around inside. The only way you know if something can be dropped in from outside the box is by making a lot of mistakes and coming up with something that has been tested over the years and that you know you can trust. So Vendor A may be thinking about all of these little details.
McCanny: There is a lot of IP that’s a black box. To some extent you want a black box, but when something doesn’t work out there’s very little information to determine what the problem is. Knowing which things have been checked out and which things have not is essential to know. You get the numbers but no information about where this data came from. The IP vendor doesn’t want all their secrets stolen, but if the customer uses it in the wrong way there’s no information about why his model doesn’t match transistor-level simulations or his silicon, which is even worse.

LPE: As we move into 3D stacking that becomes even more critical, right? You have proximity effects in multiple directions. How big will this problem be and will it affect 3D’s adoption?
Gianfagna: 3D will change the market. Now you’re not just selling hard or soft IP. Now you can start to think about selling pre-characterized slices in the stack. That could be a memory supplier or an FPGA supplier. It will expand the market. But there’s a new set of analyses. The early analysis of the stack before you place IP becomes much more difficult. You’ve got placement problems and thermal and mechanical issues that didn’t exist before. Making silicon paper-thin and then punching holes through it and seeing if it still works isn’t simple. Beyond that, there’s a whole separate issue on sourcing and building the stack. Who’s going to be the general contractor? Who’s going to take the yield risk and the inventory management risk of the heterogeneous stack of silicon, put it together and ship it to an end customer. The end customer won’t take that risk in every case.

LPE: How much of the content changes in a 3D stacked die and does it come from more or fewer vendors?
Rajendiran: The first place it will really be adopted is in the memory space. The industry is waiting for some standardization of the interface from companies like Micron. Once that happens it’s really going to take off. Meanwhile, whether it is TSV-based or SiP-based, the inventory management issues are the same. We have a customer looking at the SiP package, bringing their die and their partner’s die and we’re putting them together.
Brock: We’re still putting everything together, the foundation IP with memories and high-speed interfaces. We have an analog component, processor component, cells and MDM, so the natural outbreak is to come up with IP subsystems. If a company needs an analog front end for a high-definition TV, we have all this stuff that can go into that. That’s going to be the natural outgrowth of collaboration. At Virage we had a processor, memory and logic, which is what you need to build a core. You can characterize that, add some software stacks and you can start growing them. But you also have to be very cautious about how you build those. You have to be sure there’s a market.
McCanny: When you put all these blocks together you get one big block.
Brock: Or a collection of blocks that can be, ‘Slot A, tab B.’
Gianfagna: The derivatives are a good argument for an IP company being part of an EDA company. You have to have the ability to do customization. A large EDA company can do that. A small IP company cannot. You need infrastructure to do that right.
Brock: There are places for small IP companies. Most of them started as design services companies.
Rajendiran: And most of them still are design services companies. If you look at the IP industry the biggest one is ARM, the next biggest is Synopsys, and after that it’s MIPS. After that, I can’t think of who’s fourth. On the one hand, everyone is a design services company. When this began the only master they served was an OEM company. When it became a completely open market one design served 100,000 companies, so you had 100,000 masters. The IP industry takes the easy way out by remaining small.
Brock: But there are a lot of unique collaborations going on.

LPE: Don’t all the fabless companies become IP companies?
Gianfagna: Is it IP aggregator or creator?
Rajendiran: They do create their own IP that becomes part of the chip.
McCanny: Over time, will the small guys wither away? Will end companies still use the IP from these companies if the IP isn’t completely validated?
Gianfagna: If we can come up with a language for how to do that, then we will use their IP. Validating a piece of IP generally is easier than building it from scratch. If nothing else, you’re on the back of the 10 guys who came before you. The problem is there is no way to validate the quality, the deliverables, the use model, the scope of use and the integration risks.
Brock: Very often it’s a bunch of guys in a garage with a great idea. But it’s how you build it and the methodology. The kind of people like things done and if it’s not done in a certain way they get upset. You need a bunch of those people.
Gianfagna: Strong, rigid methodology pays off in IP.
Brock: It’s this discipline that has to go in step by step. The gotcha is when you skip a step. You may not find out about that for a couple of generations. You need tools to go in and understand what’s really there.
Rajendiran: A lot of people leave companies and that step you skipped a couple generations ago no one remembers. If you can build tools that can probe the IP who’s going to let that happen?
Gianfagna: There are a couple of 900-pound gorillas that could make it work. The end customers also can demand it. The IP providers won’t wake up tomorrow and say they’re open to criticism and change. It’s not just the syntax of the IP, though. It’s power, the clock and other things that do affect the implementation. What they’re trying to do is to dig deep enough to tell their customers what’s good and what isn’t.