<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Low-Power Engineering Community &#187; Synopsys</title>
	<atom:link href="http://chipdesignmag.com/lpd/blog/tag/synopsys/feed/" rel="self" type="application/rss+xml" />
	<link>http://chipdesignmag.com/lpd</link>
	<description>Making Semiconductor Architectures More Efficient</description>
	<lastBuildDate>Fri, 25 May 2012 03:42:44 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
		<item>
		<title>Traversing The Abstraction Landscape</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/05/10/traversing-the-abstraction-landscape/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/05/10/traversing-the-abstraction-landscape/#comments</comments>
		<pubDate>Thu, 10 May 2012 07:01:43 +0000</pubDate>
		<dc:creator>Ann Mutschler</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[abstraction]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Low-Power Design]]></category>
		<category><![CDATA[Mentor Graphics]]></category>
		<category><![CDATA[power modeling]]></category>
		<category><![CDATA[SPICE]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=4060</guid>
		<description><![CDATA[Tools and techniques mitigate the pain of moving between levels of abstraction; balancing between them for accuracy and abstraction.]]></description>
			<content:encoded><![CDATA[<p>By Ann Steffora Mutschler</p>
<p>Back in the early days of semiconductor design engineers could count the number of transistors on their chip with their own two eyes. They designed and worked at the same level of design abstraction when doing the timing analysis. Tools were SPICE-like, maybe abstracted with slightly simpler timing models than the SPICE-level transistor models.</p>
<p>Thanks to Moore’s Law, the number of transistors that can fit on a chip has grown to the billions, which obviously can’t be counted with the naked eye. But they also no longer scale with SPICE. Abstraction has been the way out by providing a higher-level view on the design.</p>
<p>“Clearly, even when I’m at gate level, I know I’m not getting the same accuracy that I would be getting at SPICE level, but if my models are good enough and it is close enough, I’m willing to take that slight hit to be able to do bigger designs,” noted Barry Pangrle, a solutions architect for low-power design at Mentor Graphics. “That’s the progression that we’ve gone from—transistors to gates. Then people were doing schematic capture and everything was gate-level models. Then we went to RTL and we started moving to RTL models. Now we are moving on into system and bigger components and functional blocks. At each level, we’re giving up some measure of accuracy—it’s just not going to be as detailed. It’s not going to be as fine-grained and the hope is though that we have enough information that we can make the decisions at that level of abstraction.”</p>
<p>The abstraction levels in use today were developed over a long period of time. They are well-defined because a huge amount of work was done in terms of both modeling, to make sure we can move between levels, and to ensure there is the appropriate level of detail to accomplish what needs to happen in that level.</p>
<p>“Today, we’ve tuned it and created enough modeling around it so we can get the information that we need out,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “But I would say that the model isn’t general enough if we thought of some new use of these connections and voltages and expected it to give us the data that we wanted. Whereas if you did that all in SPICE, it likely would [provide the right data] because that’s one indication of the maturity of the model—whether you can use it for things that weren’t anticipated originally when you built the model.”</p>
<p>At the RTL level engineers synthesize down to a gate-level netlist so that they can bring in their gate level models, Pangrle said, with the hope that based on the information they get from those models, they can create something that’s going to be representative of what they need at the RTL level. “Now we’re looking at going one level beyond that and saying, ‘Okay, at the next level of abstraction what kind of information can we capture here?’ The tricky part is making sure that you still have the level of accuracy that you need to be able to make the types of design decisions that you’re going to rely on that information.”</p>
<p>But these levels of abstraction are not all fun and games. For engineering teams doing low-power designs, there are many challenges moving between these different design abstraction views, the biggest one between the RTL to gate because these two abstraction levels have too many big differences, explained Qi Wang, technical marketing group director for low power and mixed signal at Cadence. “On top of that, there is a lot of handshake of tools between those two levels.”</p>
<p>For example, he said an important aspect of low-power design is to gather activities. RTL simulation is run to collect activity, so all of the signal activity is annotated along with all the signal names. The engineer hopes to re-use that activity at the gate level, but the problem is the name seen at the RTL may not be the name seen at the gate level because the synthesis tool renames the files.</p>
<p><strong>Power formats</strong></p>
<p>In addition to this renaming, a lot of optimization can happen between the RTL and the gate level, which means that some signal may simply optimize out. Another possibility is that the logic may not optimize out but the representation can be changed, Wang said. “On the activity side, this is a flow challenge. The activity file you get for the RTL you hope you can re-use for the gate level, but many times you will find it is very difficult.”</p>
<p>Another kind of difficulty involved is with the power format, no matter what standard is, Wang noted. “The whole idea is that you describe your power intent in another file&#8230; If you write a power format file for RTL, which means it will be used for the RTL so all the names you refer to would be the RTL names. Now when you get to the gate level you hope you can use the same RTL level power intent because I want to keep my golden power intent through the design and verification flow.” But this will have the same problem as in the activity file.</p>
<p>To address this formal verification techniques can be used to indicate which RTL register names map to the corresponding flip flop on the netlist with a name-mapping file.</p>
<p>Then on the power intent side, he suggested the easiest way to deal with the renaming issue to have the synthesis tool write out a new power intent file, which automatically will reflect the name changes and the hierarchy ungrouping. When it comes to enabling the flow, however, the power intent written out by the synthesis must be equivalent to the original power intent, which is where power-aware equivalence checking tools are utilized to prove that the new power intent and the old power intent are equivalent.</p>
<p><strong>Twenty years of hard labor</strong></p>
<p>Traditionally, traversing levels of abstraction has been relatively straightforward—it’s just a lot of work. “If you look at the library modeling process that has evolved to go from kind of transistor level to gate level, things are very well defined today,” Chin said. “Libraries are super solid and vendors know how to characterize things even as the technology changes. That’s an example of a level of abstraction that’s pretty mature because over the last three, four or five generations of technology, we haven’t had to make major changes. There have been many, many little extensions and timing models and functionality and things like that but basically since we haven’t changed the fundamental design flow, the models and libraries have stayed pretty much the same, which is great.”</p>
<p>There have been similar advances in synthesis. “If you look at this between RTL and gate level, synthesis has changed a lot over that time, as well, but in general if you couple synthesis with verification tools and formal verification tools, things have actually grown nicely so that we still have very dependable flows that most people are still pretty happy with. You can push the button and trust what comes out at the other end. And as you recall, it took us 20 years to develop that level of trust,” he concluded.</p>
<p>Once the engineering community moves en masse to the system level, that 20 years could easily be duplicated.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/05/10/traversing-the-abstraction-landscape/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Cost vs. Value</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/05/10/cost-vs-value/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/05/10/cost-vs-value/#comments</comments>
		<pubDate>Thu, 10 May 2012 07:01:21 +0000</pubDate>
		<dc:creator>Ann Mutschler</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[analog/mixed signal]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[low-power engineering]]></category>
		<category><![CDATA[low-power verification]]></category>
		<category><![CDATA[Synopsys]]></category>
		<category><![CDATA[Texas Instruments]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=4053</guid>
		<description><![CDATA[With low-power requirements complicating mixed-signal design, engineering teams are following the money in an attempt to streamline the architectural process.]]></description>
			<content:encoded><![CDATA[<p>By Ann Steffora Mutschler<br />
The increasing amount of mixed-signal content being included in SoCs for automotive, networking and all manner of mobile devices is reinvigorating the mixed-signal industry. While this is great news for companies playing in anything related to mixed-signal technology, it also means increasing complexity for the engineering teams pulling all the pieces together.</p>
<p>“People have been designing mixed-signal for a long time and the composition of mixed-signal is changing drastically,” explained Mladen Nizic, engineering director at Cadence Design Systems. “Traditionally, mixed-signal was viewed as big digital with some analog in there, but now we see that mixed-signal has really expanded in complexity. So we have designs today that are about equal mixed with respect to analog and digital content. With designs that in the past were predominantly digital, engineers didn’t need to worry about analog impacts and effects. Now they have to, at least to some extent. Digital designers doing verification need to have some representation for these analog parts or mixed-signal parts or they might not completely verify their designs.”</p>
<p>Given that consumers are the driving force behind semiconductor demand today, there are very high performance and cost demands. In fact, cost is now viewed as a primary design variable, according to Navraj Nandra, senior director of marketing for DesignWare analog and mixed signal IP at Synopsys.</p>
<p>Packaging—a significant portion of system cost—plays a deterministic role in the architecture of SoCs because the choice of package dictates a number of technological aspects of the system.</p>
<p>“Our customers are selling package-tested parts, so packaging becomes an important part of the cost equation. Customers would like to use the cheapest possible package that they can get away with, and the design challenge is that the cheapest package has the worst performance in terms of parasitics. You’ve got really bad parasitic inductance, parasitic capacitance, lead frames are very badly put together, and there’s a lot of leakage through the substrates. These things are typically in some kind of cheap BGA or wirebond implementation,” he explained.</p>
<p>To illustrate, Nandra shared a recent situation with a customer that wanted very high performance capabilities on the die but were going to put it into a really cheap package because it was going into a low-end smartphone they wanted to sell under $200. “The discussion was around how to get a very-high-speed memory to connect to the chip being developed without compromising signal integrity. In that particular package configuration that they had, there would be a limitation on speed. At a certain speed they’re going to get skew and reflections on the line, which is going to impact performance of the chip. Then the customer asked if they could save cost by compromising on the board—maybe use a two-layer board instead of a four-layer board. That’s certainly possible but, again, you have to downgrade or degrade the performance because the two-layer board doesn’t have that many degrees of freedom in terms of performance. So cost is absolutely a critical part of the equation when you’re coming into designing not only IP but also when you’re looking at it from an SoC perspective.”</p>
<p>He believes a lot of engineers don’t quite understand these tradeoffs. While it is certainly possible to get the performance with a very expensive technology at 28nm with all the process options, all the different masks that allow all the different voltages, a nice package and an expensive board or connector, the reality is that many SoCs must be designed and manufactured in the cheapest possible environment.</p>
<p>“This could be the biggest mixed-signal challenge, because every six months or so engineering teams look at ways of getting the cost down on their product. But they want the performance, too, so the ingenuity from the engineering side really needs to apply to that: ‘How can I get the most out of very little in terms of the package, the board material and such,’” Nandra continued.</p>
<p>Complicating mixed-signal designs is the persistent drive for lower power, said Pat Hunter, product marketing engineer responsible for developing strategies for point-of-load power solutions at Texas Instruments. “Integration and power consumption [are trends,] but the biggest trend I really see is battery life because we all know—we’re consumers—the biggest complaint we all have about our cell phones is the battery life. In TI we do a lot in the area of charging the battery, but the more important part of it is accurately gauging the capacity of the battery.”</p>
<p>Low-power challenges in mixed-signal come from a couple of aspects, noted Cadence’s Nizic. “One is that we brought more digital into analog. Before we didn’t worry much how much of that digital was consuming because it was really small parts. If I have instead of a few hundred or a couple thousand standard cells now I have a hundred thousand or a few hundred thousands with my analog, that’s becoming a significant part of my overall power budget. Second, I want to use this digital to better optimize power of my analog &#8212; shut it down when it’s needed &#8212; it’s all interacting &#8212; now I have to apply low-power techniques on my digital part but at the same time, that complicates my interfaces with analog. That’s another dimension when I try to verify power modes and functionally entire design.”</p>
<p>Like Nandra, TI’s Hunter has seen customer demand for cost reduction, as well as the accompanying struggle to make the right architectural tradeoffs.</p>
<p>Speaking to designing devices for longer battery life, Hunter said, “If you look at them like they are fuel gauges, the biggest architectural tradeoff is you are adding cost to your system because the microcontroller will have an analog/digital converter on board and they can do their own gauging. But it’s very inaccurate because the batteries have internal impedance, and if you don’t keep up with internal impedance you’ll think that there’s less energy in the battery than there really is. I’ve got customers that were doing laser wrinkle removers and so they had their own A-to-D gauging the battery. They were doing a cost reduction. But the biggest complaint from their end customers (the consumer) was that they could never trust the battery reading. Here’s the case where they were going to do a cost reduction but they are adding my part because they needed that extra accuracy. The challenge is trying to justify the extra cost. The way you do that is with consumers. If you’ve got two smartphones side by side—they pretty much all do the same thing nowadays—but if you’ve heard this one’s got twice the battery life you as a consumer will buy that. Nobody cares that my solution is in there. They just care what my solution does for the product.”</p>
<p>When it comes down to it, <a href="http://blogs.synopsys.com/theeyeshaveit/2010/01/04/cost-is-the-new-ip-design-variable-for-ddr3-interfaces/" target="_blank">cost defines everything</a>. “It’s choice of process technology, choice of the IP that you’re going to use, speeds that you’re targeting, packaging, risks you’re willing to take. In the end, if you were to devote significant resources your quality would be great, but you have to make that tradeoff now between ‘my cell phone probably is going to be on the market for six to nine months before someone is going to expect an update or a new cell phone, so do I need to now run through all the qualification standards that require five years of operation?’” Nandra said.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/05/10/cost-vs-value/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Getting Ready For Stacked Die</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/04/05/getting-ready-for-stacked-die/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/04/05/getting-ready-for-stacked-die/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 07:01:56 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[2.5D stacked die]]></category>
		<category><![CDATA[3D stacked die]]></category>
		<category><![CDATA[Altera]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Docea Power]]></category>
		<category><![CDATA[Mentor Graphics]]></category>
		<category><![CDATA[Synopsys]]></category>
		<category><![CDATA[Xilinx]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3951</guid>
		<description><![CDATA[EDA vendors are now taking 2.5D and 3D approaches very seriously; lots of pieces are in place but others are still missing.]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
The move toward stacking of die has always been a series of disconnected pieces and vague promises for the future, but in the past few months the scenario has changed radically—and so has the commentary.</p>
<p>All three of the Big Three EDA vendors now have at least some of the pieces in place for 2.5D stacking and are working on a full 3D flow. Two of the biggest FPGA vendors, Altera and Xilinx, have rolled out 2.5D prototypes. The big foundries have developed processes and interposer technology. And IP vendors are beginning to talk about how IP will have to be characterized to work effectively in stacked-die configurations.</p>
<p><strong>Unanimous vote of confidence</strong><br />
Possibly the most dramatic change has been at Synopsys, which has been vague about stacked die for the past couple of years as it tried to sort out where the issues were and where the opportunities will be.</p>
<p>“For some time, the situation has been very foggy,” said Marco Casale-Rossi, product marketing manager for implementation platforms at Synopsys. “We decided to let things settle to understand the main directions, and believe that over the last 18 months we have understood where mainstream will be—2.5D with an interposer. It will be a number of die, side by side, communicating through an interposer and with the outside world through a TSV.”</p>
<p>Synopsys has decided to focus in three areas: a complete solution for implementation and verification; an evolutionary 2.5D to 3D flow that builds on what already exists; and an R&amp;D commitment with customers and research groups to solve whatever problems may come up in the future.</p>
<p>“Extraction will be very important,” Casale-Rossi said. “We need to take into account a number of new elements such as microbumps, TSVs and interposers. And historically, EDA tools have been designed to deal with one process technology at a time. Now we’ve got bricks manufactured using different process technologies and the rules are different depending on the die.”</p>
<p><strong>EDA’s next big thing</strong><br />
Synopsys isn’t alone in trying to predict where the pain points and the opportunities will be. Both Cadence and Mentor Graphics threw their support behind stacked die over the past couple of years, and Cadence has been working on system-in-package since the beginning of the millennium. So far it appears that the opportunity is large enough and broad enough that there isn’t much overlap.</p>
<p>Cadence has built its 2.5D suite from its SiP tools, which were introduced in in 2007 at a time when the market was still focused on planar ASIC solutions. At that point, the company was divided over whether stacked die would really be an opportunity going forward. There is far less doubt these days that it was the right choice.</p>
<p>“The big question as we got into 3D was whether we build separate tools or use the same tools,” said Samta Bansal, senior product marketing for SoC Realization at Cadence. “We did need new layout tools because of the new electrical features—TSVs and microbumps. The analysis tools also have to be able to comprehend the new constraints, which are thermal and mechanical. And we needed new models and tools with respect to microbumps, and had to make sure the current tools understand the new dimensions.”</p>
<p>She said TSVs are similar to vias, but still different enough to require changes in the tools. And floor-planning requires understanding of placement in a stack to optimize behavior. But she noted that what customers discovered they really needed were tools for packaging.</p>
<p>“Customers that are developing 2.5D are looking at this one of two ways,” she said. “One is a package-driven flow, where the interposer is an extension of the package substrate. The other is an IC-driven flow, where as you go along you have more TSVs and more IC-centric routers. But for both of them, 3D stacking is a combination of digital, custom (analog/mixed signal) and the package.”</p>
<div id="attachment_3953" class="wp-caption alignnone" style="width: 686px"><a href="http://chipdesignmag.com/lpd/files/2012/04/Screen-Shot-2012-04-04-at-8.52.56-AM.png"><img class="size-full wp-image-3953" src="http://chipdesignmag.com/lpd/files/2012/04/Screen-Shot-2012-04-04-at-8.52.56-AM.png" alt="" width="676" height="321" /></a><p class="wp-caption-text">A 2.5D stack. Source: STMicroelectronics and Cadence</p></div>
<p>Mentor Graphics likewise has been extremely active in 2.5D, with a long-range view of 3D stacking, focusing in particular on both test and manufacturability.</p>
<p>“Several factors need to be addressed,” said Steve Pateras, product marketing director for Mentor Graphics’ silicon test products. “One is known good die. How good is the testing before you put chips in a package? Most times you test chips after they’re already in the package, but with 2.5D and 3D the yield goes down as you increase the number of die.”</p>
<p>A second issue involves I/O testing—or more accurately, the lack of testing—which takes on new meaning in a stacked die. In stacked die, it’s imperative to test the I/O before the die are packaged because many times it will not be testable after they’re already in the package.</p>
<p>Pateras said one of the approaches being talked about is wafer on wafer stacking to reduce costs, but that makes it particularly hard to test. He said the better approach is die-to-wafer stacking, using a base wafer with everything else stacked on top for greater control and better yield. But that also creates another problem.</p>
<p>“When you stack heterogeneous die in a stack, there is no standard for communication between the die,” he noted. “We’ve solved one problem, which is memory stacked on logic. But we need to develop a 3D test standard and standards for embedded self test.”</p>
<p>On the manufacturing side, Mentor has modified its DFM tools for 2.5D and 3D verification. And most experts believe existing ESL models can be relatively easily tweaked.</p>
<p><strong>What’s still needed</strong><br />
It’s easy to forget that 2.5D and 3D are evolutionary steps with possibly game-changing impacts. While some EDA tools have always been offered well in advance of the mainstream, they are typically behind the chip design teams working at the leading edge of Moore’s Law. At 20nm and beyond, the cost of making chips has become so enormous that leading-edge companies are building upward. And as they do so, they are finding some pieces are missing that will need to be filled in.</p>
<p>“The first thing that’s missing involves the temperature issue,” said Ghislain Kaiser, CEO of Docea Power. “When you stack die together you’re putting more power into a package, whether it’s 2.5D or 3D. You have to manage that. Many times there is no dissipation problem, but you need to have tools to make sure. You need to be able to analyze the dynamic power profile, and right now it’s impossible to make a link between the software and dissipation when you run actual software on the chip. The best you can do is a simple profile.”</p>
<p>One of the great benefits of stacked die, in addition to not having to move analog designs to the next process node, is increased flexibility and options for designers. Teams can stack different memories in different places and they can move functionality from one die to another to improve performance or lower power or both.</p>
<p>“With that freedom you need to do more exploration,” said Kaiser. “But you may have too many degrees of freedom. You need to be able to optimize different chips along price, performance and power. And you need more accuracy. The gate-level tools are not 100% accurate.”</p>
<p>That’s easier said than done, however. There are no standards in the IP world that would allow an accurate comparison between one piece of IP and another. Frequently they are not even measured the same way by different vendors. Moreover, they can vary significantly with different usage scenarios.</p>
<p>That’s typically where standards fit in. Cadence’s Bansal said the foundation to enable 2.5D and 3D is clear, but there needs to be a seamless and consistent way to integrate digital, AMS and the package. “If the routing is not optimized, for example, you may end up with several layers of interposer. That will make the chip much more expensive.”</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/04/05/getting-ready-for-stacked-die/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Power, Applications Drive New Thinking On System Planning</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/04/05/power-applications-drive-new-thinking-on-system-planning/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/04/05/power-applications-drive-new-thinking-on-system-planning/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 07:01:31 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[Apache Design]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3975</guid>
		<description><![CDATA[Application-driven power-aware flows begin taking root, but they require a sharp change in the starting point and execution of designs.]]></description>
			<content:encoded><![CDATA[<p>By Ann Steffora Mutschler<br />
Throwing out the term ‘application-driven power-aware design methodology’ may sound like gobbledygook to some, but this concept is keeping many technologists awake at night—especially considering video games that heat iPads to 100+ degrees centigrade (near melting). The problem is very real, and potentially painful in more ways than one. </p>
<p>The iPad example, along with others such as streaming video and heavy graphics in Facebook applications, which exercise the complete logic, SoC and memory access, along with high speed DDRs for displays and the display itself, show just how power hungry consumer applications are—and how much new thinking is needed to address the problems.</p>
<p>“If you have a GPU that is driven by high activity games, so-called power guys who are really driving the game industry, it can define the maximum power consumption limit. Instead of using the same GPU, which is doing multiple applications of low-activity movies or low-activity plain dialogue movies versus action movies versus streaming 1080P—one can think about creating GPUs that are specifically designed for those applications and optimized with respect to dynamic and leakage power,” suggested Vic Kulkarni, general manager and senior vice president of the RTL business group at Apache Design.</p>
<p>The alternative is creating different application processors and GPUs on multiple SoCs, including 3D stacks. “That’s another thing people are looking at very aggressively—how do we get logic on logic or logic on memory to manage power and heat,” he said. “Application-specific processing units may be better for power optimization as opposed to general purpose CPUs for different applications.”</p>
<p>Application-driven is really where things are headed, agreed Cary Chin, director of technical marketing for low-power solutions at Synopsys. “If you want to do the best possible optimization, one of the problems is that when you are doing the lower-level design, you don’t really know exactly what you are designing for. That’s been a dilemma for a long time. You have to make some decisions about what your target application is, and for the most part over the years we’ve gotten away with this idea of general purpose computing. You can write software to customize things, and then build the hardware however you need. The problem is when the big issue is power—as it has been for the last few years and apparently will continue to be for quite a long time—the optimizations that you need to do make a big difference at the hardware level, and for each particular application the requirements are different.”</p>
<p>But the amount of complexity that is being added into the mix is still on the rise.</p>
<p>“If you think about the amount of stuff that needs to happen—this idea of application-driven in terms of power efficiency is great, but the problem, like in most complicated problems, is that you can’t really do it top-down,” Chin said. “It would sure be nice if we could say, ‘Lets just make the applications aware,’ and everything works underneath that.”</p>
<p>At the heart of these designs are the highly skilled system architects, which to Chin seem analogous to good cooks. “A good cook very rarely has a recipe that they’re cooking from. They don’t say, ‘Here are all the requirements of what I need; I’m going to go get all this stuff.’ A really good cook looks at all the good stuff that’s available and creates things based on what’s available, and I think that’s what system architects do. An architect’s real job is to understand the technology, both on the hardware and the software side and maybe the application side, as well, in terms of how applications are created and distributed. The stuff that’s going on in the architect’s mind is that they start to create and formulate what kind of things can be made with the pieces that are coming together.”</p>
<p>Architects are thinking about customizing logic for particular very specific needs these days, he noted. “I think that’s what we’re going to start seeing because there are so many gates and so much silicon available. The idea we’ve designed around for the last 30 years or so, which is that we’re generating general-purpose silicon that basically does optimization based on re-use of the silicon for many functions, is exactly the opposite direction of the optimum for low power. To get the lowest power design you need to custom design a specific function that you need without having any other transitions in your device. If you could create custom logic for everything you would have an ultra low power device.”</p>
<p>Summing up the need for application-driven power-aware flows, William Ruby, senior director of RTL power product engineering at Apache Design explained, “If you look at software and hardware—these are the two basic parts of a system. Traditionally software has not been power-aware at all, and software is now being used to control the hardware. Software itself does not consume power, but it has a huge impact on how much the hardware is burning. What needs to happen is that you need to start thinking about realistic application scenarios.”</p>
<p>There is a huge amount of infrastructure in place to design for functionality, find functional bugs and identify corner cases. “But a lot of that infrastructure is simply not suited for any type of power analysis or power driven design work: you need something fundamentally different,” Ruby said. “If you look at how the application-driven flows will evolve, you start with the application and then you say, ‘How can I simulate, emulate or somehow replicate the effect of running that application on this hardware.’” </p>
<p>Regarding emulation, Qi Wang, technical marketing group director for low power and mixed signal at Cadence, explained that traditionally engineering teams have done power estimation by running some functional tests to get activities to drive power estimation. But those activities are for functional testing and have no way to represent the actual application. “This is the biggest disconnect right now and people now realize that, but there’s no technology to bridge the gap because this huge abstraction gap between system abstraction and silicon abstraction,” he said.</p>
<p>However, hardware can be mapped to the emulation box today and then system software and applications can be tested. Traditionally emulation boxes were used to verify system functionality used by software or application, but emulation is now being extended to do power estimation, as well. </p>
<p>“If you think about it, it’s a very natural extension because you run those applications anyway to verify the functionality,” Wang explained. “Why not at the same time take down the traces to record all the activities and send it to the power estimation tool to do the power estimation? That kind of bridges the gap between the software application and the actual hardware. And it’s not just for power estimation. We know that a lot of people doing advanced low power designs do power management and power gating.”</p>
<p>Overall, application-driven power-aware tools will need to both address the performance angle as well as model and abstract the design to higher levels able to run a system type of a power simulation, Ruby asserted. “These models need to be as accurate as possible. You need to start building a model chain all the way from silicon up to the power spec.” </p>
<p>It comes down to modeling and processing huge amounts of data, he concluded.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/04/05/power-applications-drive-new-thinking-on-system-planning/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Reliability Concerns Grow</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/04/05/reliability-concerns-grow/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/04/05/reliability-concerns-grow/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 07:01:28 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[Apache Design]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Nvidia]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3968</guid>
		<description><![CDATA[New process nodes and packaging options are raising unexpected issues for chips; longevity is a looming issue.]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
Knowing when to signoff on an IC design has always been as much art as science, matching engineering experience with managed risk. As ICs become more complex, however, even the most advanced chip companies are getting things wrong.</p>
<p>Some of this can be fixed through software and some of it can be tweaked with programmable firmware. But some of it may have to be fixed in the next cycle of chips. </p>
<p>“We’re seeing three different scenarios unfolding as we push to lower power and higher performance,” said Arvind Shanmugavel, director of application engineering at Apache Design. One is operational, the second is time-based, and the third is event-based.”</p>
<p>The operational problems enter the picture when areas of the chip are switched on and off. The transitional current can be high enough to cause serious issues. The time-based concerns involve electromigration. Electrons over time damage metal interfaces, which must be minimized by controlling the amount of current flowing to interconnects and creating an accurate model of the temperature distribution across a die. The event-based issues stem from voltage and frequency scaling. Sufficient feedback about temperature is required to prevent wires from burning out.</p>
<p>“The event-based liability is ESD, which occurs regularly in high-performance ICs. But it generally is not discussed in EDA,” Shanmugavel said. “You need to know if there is a hit, how is the IC hit and whether you can reliably discharge an ample amount of current. We’ve had a 2 kilovolt standard for decades, but devices are getting smaller and they’re discharging the same amount of current. Designers need to do true simulation and characterization to avoid wire burnout. The wires are thinner, too, so even the same amount of current can cause problems.”</p>
<p><strong>The laws of physics</strong><br />
Shrinkage brings other problems, as well. Metal spacing rules traditionally were driven by lithography, but physics has taken over.</p>
<p>“If the metal spacing is too small, the electrical field may become too intense,” said Ting-Sheng Ku, director of engineering at Nvdia. “The spacing rules increasingly are dominated by the electrical properties of the dielectric, not the lithography. At 28nm the industry saw some of that. At 20nm the spacing can become a real problem if the industry does not address it.”</p>
<p>Nvidia typically runs at the front edge of Moore’s Law, so the types of effects it is witnessing are brand new to the design industry. Ku said many of these had been predicted, so there is little surprise even though solving these new problems remains extremely difficult. But one area that is emerging is in the area of longevity of parts.</p>
<p>“Transistors get weaker as time goes on,” he noted. “You get impurities trapped in the system and they do physical damage. This is all physics-related, but as features get smaller this gets worse.”</p>
<p>He said more modeling is required for these kinds of effects over time to avoid future problems.</p>
<p>New types of errors in stacks<br />
As if things weren’t hard enough, there are new types of errors being introduced into chips that didn’t exist in the past, particularly in stacked die.</p>
<p>“Just having extra processing steps can generate errors,” said Marc Greenberg, director of marketing for SoC Realization at Cadence. “There also are mechanical issues when you put die together, and you have additional annealing steps from TSVs.” </p>
<p>This is particularly troublesome for memory because DRAMs are somewhat delicate, he said.</p>
<p>And in extreme environments, single-event upsets caused by radioactive particles have always been a risk. But they become an even greater risk as features shrink and more gets packed together, either in planar or stacked configurations. At advanced nodes, margins can affect performance and power. But cutting margin means that if anything goes wrong, there isn’t a failover mechanism.</p>
<p><strong>Verification and other challenges</strong><br />
Even without unexpected outside interference, just having confidence that issues have been fully addressed is a big issue. Verification coverage in a complex SoC is almost impossible to address in a reasonable market window.</p>
<p>“Verification is going non-linear in complexity,” said Aart de Geus, chairman and CEO of Synopsys. “Hardware and software interactions will continue to become more complex because the functionality is the hardware plus the software. In addition to that, we have to keep physics in check.”</p>
<p>The good news is at least tools makers are aware of the problems.</p>
<p>“We are getting this under control,” said Apache’s Shanmugavel. “But reliability has always been the stepchild of simulation. It has not been treated as a functional problem. That will have to change. We will need to use models to create probabilities and rely more on event-driven simulation—and then we will have to string it all together to see if we’re getting a voltage drop over time or a high peak current.”</p>
<p>And if none of these problems is insurmountable or unexpected at 20nm, there surely will be others that arise as companies begin testing chips at 14nm.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/04/05/reliability-concerns-grow/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>2.5D Leverages Existing Tools On The Way To 3D</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/04/05/2-5d-leverages-existing-tools-on-the-way-to-3d/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/04/05/2-5d-leverages-existing-tools-on-the-way-to-3d/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 07:01:14 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[2.5D stacking]]></category>
		<category><![CDATA[3D Stacking]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Mentor]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3957</guid>
		<description><![CDATA[Packaging teams have been dealing with some of the same issues in 2.5D stacking that were in MCMs, but 3D stacked die present some entirely new problems.]]></description>
			<content:encoded><![CDATA[<p>By Ann Steffora Mutschler<br />
As design and manufacturing issues with true 3D design continue to be worked out, interim 2.5D technologies are moving ahead as engineering teams leverage this packaging-driven approach to manage heat, cost, area and yield.</p>
<p>Technologies such as Wide I/O memory support 2.5D, and when combined with logic they allow engineering teams to realize a performance increase, particularly for applications such as GPUs and gaming where there aren’t significant area constraints but there are performance and power demands.</p>
<p>“That’s where people are using Wide I/O memory and logic side by side in a 2.5D silicon interposer configuration,” observed Samta Bansal, senior product marketing manager for Silicon Realization at Cadence. Also, there is less of a heat management burden for 2.5D—another reason that engineering teams are looking at 2.5D now.</p>
<p>On the power side of 2.5D designs there are some extra issues that have to be considered during the design process, pointed out Steve Smith, senior director of 3D IC strategy and marketing at Synopsys. “For example, the die that you place on the interposer are bare die. They are not packaged. This is one of the issues that you have to think about. How do you drive the signal connections between each die which are relatively long? You could have relatively long wires feeding between a pair of die—maybe like in the case of Xilinx they talk about actually building special I/O drivers that are matched according to the power needed to drive the signal across a certain length of wire. They figured out based on the length of wire how big the drive strength should be and then modeled that and created a special I/O cell.”</p>
<p>Another power issue with 2.5D is how to get power reliably into the die from the interposer, he said. “The way it works with a silicon interposer is the power comes from outside of the package all the way back to the battery, basically up through the package I/O, up through the interposer through silicon vias (the metal connections from the front to the back of the interposer die) and then gets transferred up into the die themselves so the actual TSVs, the placement of them, the number of them have to be figured out to reliably get enough power up to the die. Then you also have to think in terms of the signals that cross between the die and make sure you have enough power to drive those as well.”</p>
<p>Thermally speaking, there are heat issues with 2.5D-stacked designs, but these are being modeled with traditional thermal tools that engineering teams are already using. </p>
<p>“At the moment, we’ve got an interposer and essentially flip chips sitting on top of them, so a lot of the modeling is happening at a macro level using traditional tools and current systems. I think it will start to change when we convert those simple flip chips—simple being a relative term—to being a true, active die that has through silicon vias in it, and then where it’s stacking multiple things up higher in there. I think that’s when we’ll see the next fracture of the methodologies,” noted Matthew Hogan, Calibre marketing engineer in the Design-to-Silicon division at Mentor Graphics.</p>
<p><strong>Some challenges not technology-related</strong><br />
In addition to the thermal and power issues, there are also challenges related to how to best allocate the new tasks inherent in 2.5D design.</p>
<p>“Traditionally in the IC realm a lot of organizations are set up with a system architect that designs the chip and the chip gets broken up into little blocks. The teams then go away for 3 to 18 months, then come back and do final chip assembly,” Hogan said. “All of those jobs and tasks are very well identified and we have the tradition of who does what, where and when. Eventually we go into the package side of things. One of the things that we’re seeing is from a 2.5D and 3D IC perspective, we now have this concept that gets overlaid where we’ve got a system netlist, so it’s a system design where we’ve got our flip chips on top with our interposer.</p>
<p>But who actually owns the netlist isn’t always clear.</p>
<p>“If you take a traditional IC design flow then maybe you’d say the packaging guys did the assembly and the package and that sort of stuff—maybe it’s over there. If you have a look at the front of this whole system, you’ve got a system architect working in ESL and he doesn’t necessarily deal with the 128-bit data bus that’s got level shifting on it. He deals with, ‘I need a communication channel between this chip and that chip that does 3.5Mbps because this is the data stream that I want.’ Somewhere within the definition of the high-level architectural view of what the system needs to look like and the physical implementation there really needs to be ownership of this system netlist, which is a pin-accurate description of how these different devices and designs are going to be connected together. That’s what you use when you go and do your verification of the complete 3D assembly,” he said.</p>
<p>The result is that ‘traditional’ IC design and verification groups need to expand and look for either different resources or tweak what they consider their roles and responsibilities so they can handle this new system netlist. That way, when they verify the 2.5D or 3D stack they understand who owns what, where it comes from and how it was created.</p>
<p>“They’re doing these sorts of netlists already when they do their LVS verification and there’s a golden LVS netlist,” Hogan said. “But that guy’s dealing with one chip and a whole bunch of IP internally when you get out to the system of 2.5 and 3D stacks. It’s that system view that you need to create yet again—another golden system netlist.”</p>
<p><strong>Are new tools required for 2.5D?</strong><br />
With any new technology, there is always a concern in the minds of engineers about whether they will have to add new tools to take advantage of what the new technology offers. With 2.5D, engineers can rest easy, for the most part.</p>
<p>Generally design teams are able to use a lot of the traditional techniques and tools that they’re currently using to really understand what’s happening from a power and thermal perspective in 2.5D. </p>
<p>Synopsys’ Smith pointed to the oft-quoted Xilinx stacking example and noted, “They’re claiming they started working on their interposer design eight years ago. At that time, there were no special tools for doing this, although strictly speaking you could regard 2.5D as kind of like a multi-chip module, which has been around for decades. It’s a packaging concept where you put different die on a package substrate like a mini circuit board. So that’s been there.”</p>
<p>Replacing package substrates with a silicon interposer results in the same kinds of issues, he noted. “You’ve got the close proximity of the die, they’re all going to be packaged together in the same package, so I think the thermal issues, for example, are very similar in that sense. I think the reason why companies are saying they’re managing is because this is very familiar to them. The people that work in the IC design companies usually have a separate packaging group/team from the design team, so the packaging team would be the ones that have the expertise in dealing with thermal issues with multiple die in a package. The advantage of an interposers is, because we’re not stacking active dies on top of one another there are no issues with die interfering directly with each other. If you did a true 3D IC, you’d be stacking active die on top of one another. Then you have a massive thermal issue.”</p>
<p>In 2.5D, the interposer has no transistors on it. It’s just wiring. And the tools that are used for thermal analysis of packages are equally applicable to 2.5D. While it is a rough analysis (because that’s all that’s needed for now), in 3D IC design the analysis is more complex because the areas in the silicon die with the higher temperatures must be identified as this impacts performance.</p>
<p>All of the big EDA vendors began addressing 3D design issues a few years ago and are well on their way. When the industry changed focus to 2.5D as an interim step driven by the foundries and packaging companies, the most complex issues were already identified. </p>
<p>From Synopsys’ perspective, the most dramatic impact to the 2D design flow to accommodate 2.5D has been the routing for the interposer, so the company added a more regular silicon routing system. At Cadence, Bansal noted that the company has been building up its 2.5D/3D flow most notably with STMicroelectronics; in addition to its inclusion in foundry reference flows. Mentor, as well, has extended a number of its tools to accommodate 2.5D/3D IC design and has established key relationships with foundries such as inclusion in reference flows.</p>
<p>At the end of the day, engineering teams can leverage the benefits of 2.5D now using existing tools as they prepare their organization and methodologies for the full step to 3D when the time comes.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/04/05/2-5d-leverages-existing-tools-on-the-way-to-3d/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Betting On Subsystems</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/04/05/betting-on-subsystems/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/04/05/betting-on-subsystems/#comments</comments>
		<pubDate>Thu, 05 Apr 2012 07:01:06 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[subsystems]]></category>
		<category><![CDATA[Synopsys]]></category>
		<category><![CDATA[Tensilica]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3963</guid>
		<description><![CDATA[Bundling and pre-verifying IP blocks makes sense on paper, but how far will this trend continue?]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
One of the consistent trends among successful companies, particularly in well-established industries, is that over time labor becomes specialized. No one can do everything well, and the more complex the systems the more pieces have to be outsourced.</p>
<p>This creates immediate benefits for companies putting together the overall systems. They can focus on designs and doing what they do best. And it creates new problems, because standards have to be created and updated so the pieces fit together exactly as planned. This is particularly difficult in complex SoCs, so rather than breaking pieces down to their most basic component level, they are partially re-aggregated into subsystems.</p>
<p>The automotive industry went through a similar transition. In the early 1900s, when cars were still basic and the industry was new, all the components came from the same companies. By the 1950s, there were suppliers of most of the components inside of cars, but gradually those aggregated into radios, seats, cooling systems, and more recently there are suppliers for wiring harnesses and the electronics that are replacing mechanical components.</p>
<p><strong>From IP to subsystems</strong><br />
Subsystems are the likely follow-on to IP blocks inside of SoCs for several reasons. First, it gives vendors a way to capitalize on their success in the IP market—and to distance themselves from those companies that failed. Early adopters of third-party IP learned quickly that just because one IP block is priced lower than another doesn’t mean it will end up costing less in the long run.</p>
<p>It costs a lot, in terms of money and manpower, to fully characterize IP for complex SoCs. Even standard IP must fit into non-standard chip configurations with sensitivity to noise, heat and power. </p>
<p>Synopsys’ audio subsystem introduction last month is a case in point. Its decision to bundle its audio chip into a subsystem combined both internal IP and tools with the ARC processor and other IP it acquired from Virage Logic. “The goal was to create a drop-in audio solution that is fully configurable,” said Henk Hamoen, product marketing manager at Synopsys. “We took Virage’s audio codecs, Synopsys’ A-to-D capability, and we added system-level tools virtual prototyping and an assembler.”</p>
<p>That leads to reason two, faster integration. Synopsys’ top rival in this market is Tensilica, which has been developing its own audio subsystems and racking up a long list of codecs to fit into any possible scenario. </p>
<p>“If you were to build the entire thing out of state machines, you would need to lay down 5 million lines of code,” said Steve Roddy, vice president of marketing and business development at Tensilica. “Most successful subsystems have hardware and software and they’re programmable.”</p>
<p>The third reason involves competition. Integrated subsystems raise the barrier of entry for IP vendors to compete in this market. Small IP vendors have a tougher time competing with competitively priced, pre-integrated and verified subsystems—particularly if they can be customized. But there also are logical limits about what gets bundled.</p>
<p>“It may seem natural to an IP provider to put audio and video subsystems together, but no one is asking for it,” said Roddy. “There is a naturally occurring separation. The people who buy DSPs aren’t analog guys so they don’t always understand that side as well the IP vendors do.”</p>
<p><strong>Preparing for stacked die</strong><br />
Subsystems are seen as a great way to speed time to market in complex SoCs, but they’re even more critical in stacked die. Memory subsystems, for example, will likely be entirely separate chips that are included inside the same package. </p>
<p>“The industry in general is looking at more and more integration,” said Vishal Kapoor, vice president of product management at Cadence. “We’ve moved from gate to IP to separate pieces of IP, and in general we’re looking at subsystems—although there is some debate about how to define a subsystem. Connectivity between products appears to benefit from pre-configuration or organizing things together.”</p>
<p>In 2.5D, at least, this is relatively straightforward. Subsystems created in one process may not need to be moved to the most advanced process, particularly when it comes to analog.</p>
<p>“If you have audio DACs (digital-to-analog converters), for example, and they work fine, there’s no need to build new ones” said Tensilica’s Roddy. “If you look at the typical catalog of a mixed signal company, they may have 2,000 to 3,000 parts. A lot of it is older technology, but you can take some of that and for $50,000 turn it into a custom part. You couldn’t do that if you integrated it on a die. This allows you to tweak the analog customer by customer, and to mix and match Legos.”</p>
<p>He said Tensilica has a couple dozen customers in the United States, Europe and Japan working on 2.5D chips, mixing and matching multiple analog parts. That’s can be particularly good news for subsystem vendors. “If you bundle multiple IPs together when it makes natural sense, then you get a multiplier effect for these chips.”</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/04/05/betting-on-subsystems/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Experts At The Table: IP</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/03/23/experts-at-the-table-ip-3/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/03/23/experts-at-the-table-ip-3/#comments</comments>
		<pubDate>Fri, 23 Mar 2012 07:01:12 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Round Tables]]></category>
		<category><![CDATA[Technology Features]]></category>
		<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[ARM]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[IP]]></category>
		<category><![CDATA[Methodics]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3927</guid>
		<description><![CDATA[Last of three parts: Managing risk with a disaggregated supply chain; why and where the IP stack is growing; the changing economics of stacked die; thermal, power and economic context.]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
<em>Low-Power Engineering sat down to talk about IP with John Goodenough, vice president of design technology and automation at ARM; Simon Butler, CEO of Methodics; Navraj Nandra, senior director of marketing for DesignWare analog and mixed signal IP at Synopsys, and Neil Hand, product marketing group director at Cadence. What follows are excerpts of that discussion. </em></p>
<p><strong>LPE</strong>: The supply chain needs to function almost like an extended IDM model, right?<br />
<strong> Goodenough</strong>: Yes, but it’s not a new concept. All of this was done in the automotive industry 25 years ago. The semiconductor industry is transitioning there. People are trying to manage the risk of taking a product out, and they are dependent on a lot of moving parts. Their goal is to understand and manage the risks.<br />
<strong> Butler</strong>: But it needs to come in a consistent way. You don’t want to be on a plane every week. You need to have an abstraction that gives you the visibility you need without having to have a VPN license.<br />
<strong> Hand</strong>: You need to set up a hosted design chain for the customer. Everyone is working within that common collaborative environment so that when something goes wrong it can be quickly addressed. As there are new revisions, they automatically drop into that environment and the customer sees them. That’s a trend that’s happening now.<br />
<strong> Butler</strong>: That might be true if you’re both working on parts of the SoC. But if you’re a systems house and you’re assembling, then it’s a different tool set.<br />
<strong> Hand</strong>: That’s correct. But the trends in the microcosm of IP are beginning to move into that realm, as well. Once you get into a system context, the EDA/VIP world doesn’t really fit into a system environment with their supply chain. That’s a challenge we have to resolve.</p>
<p><strong>LPE</strong>: How does that affect growth of IP?<br />
<strong> Hand</strong>: It affects everything up and down in the stack. It goes down to integrating into the SoC with RF, RF-like technologies such as optical, data converters, analog—all of that is starting to come as IP instead of standalone chips. The software and firmware stacks are more of an IP area. And once that gets solved, the next thing is how you build that into the system level models and supply chain models that are required for that. But we’re at such a low level on the IP side that there’s a lot of integration that has to happen.<br />
<strong> Goodenough</strong>: I just came from Linaro. When we look at the new IP, it’s the software IP and analog IP. It’s the next logical thing to do. It’s the up-and-coming thing where people are looking to reduce cost. It’s no longer a real differentiator, so you just outsource it. But then you have to look at managing those software communities. It’s open-source software communities and making sure the platform and the instruction set and the memory maps of the platform architecture are being consistently reflected up to the software community and the operating system guy, so that when you plug those things together they work.<br />
<strong> Hand</strong>: And in some cases that IP may become standalone and part of a 3D stack, in which case you have to manage that whole supply chain. How do you get that integrated onto the stack? In some cases, because of cost, risk or performance, you may not want to integrate some of this IP natively into the SoC.</p>
<p><strong>LPE</strong>: Analog is a classic example of that, right? In 2.5D, you may want a whole separate chip at an older process node.<br />
<strong> Nandra</strong>: Yes. We do build stuff that integrates into more nodes, but we also have customers that would like to put their analog into a 65nm power management IC, including the rest of the interfaces, and then the rest of the SoC at 20nm or 14nm. At 65nm, the power management is leading-edge technology. There are still some design challenges, although they’re not so difficult if you’ve worked at that node before. The point about stacking and packaging is quite interesting. From a signal integrity perspective, a lot of these things become easier. You don’t have long wires or cables anymore. You just have some communication going through the software and a via. The challenge becomes thermal dissipation between the substrates. You have a substrate at 65nm and one that’s at a smaller node with very different thermal characteristics. Someone has to figure out how to widen the memory lines so they don’t fuse together.<br />
<strong> Goodenough</strong>: It’s a new context. They’re just wires, but they’re wires done in a different way.<br />
<strong> Hand</strong>: The other challenge is a business one. Who owns the risk? If you have Wide I/O and a Wide I/O memory chip, the memory chipmaker says this is a known good die but it couldn’t be tested out on the landing pads. So it gets thinned out, stacked on seven other dies and then you finally do a test of the whole stack. It doesn’t work. Who owns the problem? You’ve got eight memory chips and an SoC, and it’s packaged and pinned out. Who owns the cost?<br />
<strong> Nandra</strong>: From a practical packaging perspective, all of these technologies in 3D IC and wide I/O are really expensive. We’ve had similar discussions on Wide I/O. It’s a throwback technology with significant performance, but you have to invest heavily in your package. When it comes down to high-volume parts, people aren’t going to pay the money for this.<br />
<strong> Hand</strong>: It depends. It’s the overall cost of the system that’s important. If you can get the overall power down and performance up, companies will invest. We’ve got customers investing in this now because it’s a way of differentiating. If you’ve got smartphone SoC vendors and they can differentiate with better power and performance and win the socket, they’ll do what they have to.<br />
<strong> Nandra</strong>: With Wide I/O, that roadmap has been pushed out as people try to make LPDDR meet that requirement. Today, JEDEC is looking at LPDDR 4. That will push out Wide I/O further. From a technical perspective I totally get why big companies are looking at this technology. They’re also looking at fully depleted SOI, for example. But it’s not going to make it into a tablet or smartphone.<br />
<strong> Goodenough</strong>: It’s a question of when the cost is right.<br />
<strong> Hand</strong>: For many customers, LPDDR 3 will solve their immediate problems. But if you look at the trend, this is already happening. To get terabit per second performance out of memory you have to go to stacks. It’s not a question of whether the cost equation will work for this. It’s just a matter of whether it’s next year or the year after that.</p>
<p><strong>LPE</strong>: We’re looking at a complete bifurcation of the market—those who do massive volume versus those who work in lower volumes.<br />
<strong> Goodenough</strong>: It’s not so much volume as how much you can recover from your investment in how you make your silicon. Whether that’s a micro on a board, a processor in an FPGA, a custom chip, all that matters is how much profit you’re recovering. If you can only recover a wafer-thin margin you’re not going to be investing in new technologies.<br />
<strong> Hand</strong>: Then you need volumes of 50 million units a year to get your money back.</p>
<p><strong>LPE</strong>: But this does play into subsystems, because you can integrate all the pieces and achieve much greater volume, right?<br />
<strong> Goodenough</strong>: It’s no different than boards. You’re seeing that happening in SoCs and FPGAs. Whether it’s going onto a board, a hard block in an FPGA, a soft fabric in an FPGA or a custom ASIC, they’re all basically different compile points that end up as a piece of silicon with a different price and a different energy envelope. And if you go to China with a standard part, you can probably turn a board around in two or three days. That’s a big difference from spending 2.5 years doing a custom IC.<br />
<strong> Hand</strong>: You’ll have much of what was on the board in an SoC itself. Whether that’s integrated into an SoC or a stack or just integrated parts, it depends.<br />
<strong> Goodenough</strong>: But if I’m a customer I don’t really care about that. I only care about how much power does it use, how much does it cost and what’s the form factor.<br />
<strong>Hand</strong>: There have been many chips in the telecom world that make no sense to manufacture if you measure them by consumer SoC metrics, such as how many units have shipped. But the value you get out of each of those means they can make the economics work. Going back to context, there’s an economic context that people building a system are operating in. If you’re providing IP, you have to provide the right deliverables in the economic as well as the technical context. That’s what will drive subsystems more than anything else, too—the economic context.</p>
<p><strong>LPE</strong>: And time to market is part of that economic equation?<br />
<strong> Hand</strong>: Yes. If most of your chip is good enough to get the job done and you can do it in a few months of integrating extra pieces, while assuming everything you didn’t touch works perfectly, that’s a compelling argument.<br />
<strong> Nandra</strong>: We see that with smartphones and tablets. In China, customers are starting to get into the tier-two markets. They’re all about derivatives. The idea is that you do reduce the cost of the IP.<br />
<strong> Goodenough</strong>: You have to maintain IP, though. The IP may be fixed but the context is evolving. You have to evolve your IP as that context changes from four-layer boards to two-layer boards, or 32nm to 14nm. IP has a long lifetime and you have to anticipate where it’s going to land.<br />
<strong> Butler</strong>: What’s particularly interesting is the IP view of defect tracking. A defect in IP never really goes away. There’s always somebody using it somewhere, and you need to know. It’s different from software where the lifetime is project-based. What we need is something that tracks bugs in IPs that goes into a system context so you get all your dependencies.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/03/23/experts-at-the-table-ip-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Experts At The Table: IP</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/03/16/experts-at-the-table-ip-2/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/03/16/experts-at-the-table-ip-2/#comments</comments>
		<pubDate>Fri, 16 Mar 2012 15:49:57 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Round Tables]]></category>
		<category><![CDATA[Technology Features]]></category>
		<category><![CDATA[ARM]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[IP]]></category>
		<category><![CDATA[Methodics]]></category>
		<category><![CDATA[Synopsys]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3915</guid>
		<description><![CDATA[Second of three parts: Changing dynamics of working with customers; risk vs. modification; context; blocks vs. subsystems; consolidation and the role of small IP developers; defining IP quality.]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
<em> Low-Power Engineering sat down to talk about IP with John Goodenough, vice president of design technology and automation at ARM; Simon Butler, CEO of Methodics; Navraj Nandra, senior director of marketing for DesignWare analog and mixed signal IP at Synopsys, and Neil Hand, product marketing group director at Cadence. What follows are excerpts of that discussion. </em></p>
<p><strong>LPE</strong>: Are we seeing a blurring of the lines between design teams because of the shift to more third-party IP?<br />
<strong> Hand</strong>: Customers want off-the-shelf IP. But it’s a very big distinction between becoming part of their design team and working with them all the way through, versus working on an outsourced basis. Customers want predictable, proven IP.<br />
<strong> Butler</strong>: It may take a month to deliver the library, and then there are all kinds of bugs. So you don’t ship the library anymore. You work in a common environment.<br />
<strong> Hand</strong>: Most customers don’t have to deal with that level. But the changes you make to hard IP should be zero.<br />
<strong> Nandra</strong>: In terms of the feature sets and configurations, when it comes to physical IP it’s a well defined set. The work is done by the IP vendor. They’re proving it on silicon. And then what we ship is a black box.</p>
<p><strong>LPE</strong>: Isn’t all IP a black box?<br />
<strong> Nandra</strong>: The softer it gets, the more configurations customers expect.<br />
<strong> Hand</strong>: With soft IP such as a memory compiler, you essentially have a compiler for that memory compiler. It’s still delivered as code to a customer. They have to do the implementation, so it’s more of a gray box.</p>
<p><strong>LPE</strong>: But the trend is still away from touching that, right?<br />
<strong> Hand</strong>: You still need to go through the physical implementation. You need to take their design context and optimize it or you won’t be able to hit the power, performance and area targets.<br />
<strong> Goodenough</strong>: You need to supply the IP with the recipe to get people to the context. We provide soft IP and we provide the recipe to go through an implementation flow.<br />
<strong> Nandra</strong>: The customer touches the IP, but the goal is to configure it.<br />
<strong> Goodenough</strong>: They’re touching it in a carefully constrained way.<br />
<strong> Hand</strong>: Some of these IP blocks have a huge number of configurations, so no two deliverables will be exactly the same.<br />
<strong> Butler</strong>: And you don’t want to create part numbers for these things. It’s better to ship the IP with the tool that helps configure the IP.</p>
<p><strong>LPE</strong>: One of the evolving trends in design these days is more rationalized use of resources—only what’s needed. A second trend is to do more exploration, comparing different IP and different implementations. Are those trends in sync?<br />
<strong> Hand</strong>: It depends on the risk associated with configurability. On soft IP they want configurability because there’s a lower perceived risk. There will be some parts where if you touch the core there’s too much risk. There’s always a tradeoff between configurability and risk.<br />
<strong> Goodenough</strong>: If you look at an ARM core, we’ll let people modify that cache sizes and take a gross functional block and turn a SIMD accelerator on and off. If you go and play with a new bus topology for an SoC, you have to go validate it, but there’s a lower perceived risk around that. One trend we do see, which our customers are pushing, is to provide larger subsystems. It’s not just the core, but a core and a memory subsystem that’s ready to go out with software that is known to run on it, including the BIG.little switches. They can adopt the correct risk profile that they want.</p>
<p><strong>LPE</strong>: That’s basically managing context internally, right?<br />
<strong> Goodenough</strong>: Yes. The amount of effort are putting into validation, whether it’s logical validation of systems or signoff, or going through the implementation floorplans, they’re equating time to market with something that is known good.<br />
<strong> Hand</strong>: Unless there’s a material impact. Your customers want to focus on their differentiation. If you can give them something that’s proven and working and not going to impact their differentiation, they’ll take it as it is. If they can turn a knob and lower power, then they want that knob to turn. If you look at SoCs today, about 80% of them are the same. What’s different is how they’re configured, how they’re balanced and how they’re mapped to their customer application. That’s the secret sauce they bring to the table.</p>
<p><strong>LPE</strong>: What happens to the IP industry if we’re pushing into larger and larger subsystems that are more contextually aware?<br />
<strong> Hand</strong>: There will be increasing consolidation. The cost associated with building IP is going up. You can’t bring a small piece of IP to market that people that people will bank on for a 28nm or 20nm chip. That will be a natural process of maturing of the industry.<br />
<strong> Goodenough</strong>: I agree. It’s a scale problem—the number of people you’re trying to supply while staying on the edge of physics and software. Only a company of scale can do that?<br />
<strong> Butler</strong>: But the cost of entry for startups is down.<br />
<strong> Goodenough</strong>: Yes, and you can still do an IP model as a one-off for one company because your context is constrained. You can still see a lot of innovation where there is a constrained problem. The question is how you scale from one to many. That’s a challenge for the classic IP industry.<br />
<strong> Hand</strong>: It’s similar to what happened in core EDA. Everyone said EDA startups were dead because it wasn’t scalable. EDA startups continue to happen, but once it gets to a point of scale if it’s rival technology then one of the larger EDA companies acquires them. It will be similar for IP. Once it becomes viable and needs scale, either they become a major player with a large investment—something that’s unlikely—or they will be bought up by another company.<br />
<strong> Nandra</strong>: We se a lot of companies that want to go to a complete chip, and through that process realize they have a lot of valuable IP. They get on the radar of other companies that need that sort of function. Most companies don’t start out as IP companies. They start out doing design services or with aspirations of becoming a chip company, and through that process they build a lot of interesting functions that are valuable to other people.<br />
<strong> Goodenough</strong>: You see a lot of technical innovation in function.<br />
<strong> Hand</strong>: If you look at interface IP, that’s one area where there has been a lot of consolidation. Five years ago there were a lot more companies doing standards-based IP. That’s shrinking rapidly. But there are other areas where there isn’t the level of standardization, such as analog front ends. There is a lot of innovation there.<br />
<strong> Butler</strong>: OpenAccess was a good way of bring EDA vendors onto a single platform. That drove innovation because it meant startups could be on the same database as Cadence and Synopsys and it was easier to plug their tools in. Will there be something similar in the IP world?<br />
<strong> Goodenough</strong>: That was the original idea behind IP-XACT, which is a meta-data standard. There are some very successful things being done off the back of that, such as the ability to define register maps and take a lot of pain out of integration. IP-XACT is necessary but not sufficient by itself. You need other standards to glue the Legos together. But you also need to put your glue into a modeling environment. Which one do you use? Which synthesis flow do you use? There is diversity, which is legitimately driven because people are trying to optimize design points and cost structures.<br />
<strong> Hand</strong>: And a big piece of that is defining a quality standard. What is an acceptable quality for IP and how do you measure that? If customers can’t quantify something it’s seen as a risk. As you going forward, the lack of a well-defined quality standard for smaller companies makes it hard to prove to their customers that it’s worth buying.<br />
<strong> Butler</strong>: Quality is an intangible thing. It’s not clear you’ll ever define it.<br />
<strong> Goodenough</strong>: And there is no standard integration environment. Putting a standard definition of quality is nearly impossible.<br />
<strong> Hand</strong>: But even if you solve all those modeling and integration problems, there’s still a question—if you’re a smaller player—how do you prove the quality of what you’ve got.<br />
<strong> Goodenough</strong>: It’s a business-to-business transaction.<br />
<strong> Hand</strong>: But then you have a small company dealing with a large company, which is putting its whole future up for grabs based on a piece of unproven IP. How do you prove it? As a small company, that’s a big problem.<br />
<strong> Goodenough</strong>: That’s back to the trust issue. You trust the guy doing the IP because you’ve worked together for 20 years and they’ve done this before. ARM is a trusted company. We’ll stand behind it, no matter what it takes.<br />
<strong> Hand</strong>: But it’s easier for ARM, Synopsys or Cadence to build that trust than three or four guys doing consulting and working in a shed.<br />
<strong> Nandra</strong>: Most of the customers willing to take on a bigger risk are driven by cost. The actual cost is always more because something inevitably goes wrong.</p>
<p><strong>LPE</strong>: A lot of this started with very standardized pieces. Those are no longer so standard. Are there new markets shaping up for IP?<br />
<strong> Nandra</strong>: The biggest growth is in smartphones and tablets. These customers are driving the smaller technology nodes, and there’s lots of innovation at the fabs to get devices to work at these small feature sizes. There’s a combination happening between baseband chips and application processors. Customers are looking at combining the two. That makes a huge SoC, and we all have to work in technology that isn’t very friendly.<br />
<strong> Butler</strong>: We see the blurring of boundaries. When a company is looking to interface with a vendor on the bleeding edge, there are so many revisions and so much churn as they nail down what the IP needs to be that they need to have a different way of interacting with a customer. Just downloading something from the Web site doesn’t work anymore. You need visibility into the customer’s environment and visibility into regressions in the test environment. One vendor has set up a portal to give their customers visibility into the IP that’s being generated. That way the customers can figure out if the vendor is on track to have something within the promised four weeks or six weeks. It’s having a way to bring the two teams together and build trust, without having to be on site or have VPN access, and be able to abstract out the quality and the progress is happening.<br />
<strong> Goodenough</strong>: This is trust and concurrent engineering.</p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/03/16/experts-at-the-table-ip-2/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Experts vs. Expertise</title>
		<link>http://chipdesignmag.com/lpd/blog/2012/03/08/experts-vs-expertise/</link>
		<comments>http://chipdesignmag.com/lpd/blog/2012/03/08/experts-vs-expertise/#comments</comments>
		<pubDate>Thu, 08 Mar 2012 16:00:48 +0000</pubDate>
		<dc:creator>ed</dc:creator>
				<category><![CDATA[Top Stories]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[Cadence]]></category>
		<category><![CDATA[Synopsys]]></category>
		<category><![CDATA[Tensilica]]></category>

		<guid isPermaLink="false">http://chipdesignmag.com/lpd/?p=3892</guid>
		<description><![CDATA[Analysis: A shortage of automation tools is forcing everyone to have at least some working knowledge about power techniques, but will that ever change?]]></description>
			<content:encoded><![CDATA[<p>By Ed Sperling<br />
The trend in IC design—particularly for large, complex SoCs—is specialization among engineers. There are specialists for layout, for verification, for DFM, for test, and for software, among other things. And there are experts who have a smattering of many of the pieces and can oversee the integration and testing.</p>
<p>Power is different. Because power affects every part of a design, and it has to be dealt with at every step along the way—from initial architecture to final signoff—there is no single expert or even group of experts who can handle that task. In short, everyone needs at least some expertise in this area, while some may need lots of expertise.</p>
<p>“What’s different about power is that it is still a relatively new focus for most people,” said Cary Chin, director of technical marketing for low-power solutions at Synopsys. “It’s also not compartmentalized. And it permeates what every engineer does. It’s not clear it will stay that way. In the past, things that were not compartmentalized eventually were compartmentalized and automated. But over the next three to five years, it certainly looks as if it will stay that way.”</p>
<p>Part of the reason for this has to do with a lack of automation. At this point, there isn’t even a clear-cut way to automate power. While everyone is well aware of battery life, there is no single fix. There are a variety of models being developed that can at least allow architects and design engineers to take accurate readings and make tradeoffs. And those kinds of models do help on the verification side. But truly automating power will require many more steps. </p>
<p>Compounding that is a lack of understanding about how to deal with power. There are gaps in expertise everywhere, and thorny tradeoffs that no one wants to touch. </p>
<p>“Even though power is getting more visibility, there is still a lack of expertise,” said Qi Wang, technical marketing group director for low power and mixed signal at Cadence. “Many customers want to add low-power techniques into their designs but they’re not aware of the obstacles. If you save power you may sacrifice area and timing. It may impact the design schedule. And verification gets harder.”</p>
<p>He noted that globalization is helping somewhat, because big companies do have a fair amount of expertise in this area.</p>
<p>“The rate of growth of expertise in this area is phenomenal in places like China,” he said. “Three or four years ago, people didn’t know what I was talking about. That’s all changed. With companies like Huawei, and other big companies moving their designs there, the rate of producing experts in this area is improving.”</p>
<p><strong>Different vantage points</strong><br />
Who’s proficient at proficient at power and who isn’t frequently is a function of where they’re coming from within the design space. Some people have to deal with power because their designs demand it. Others don’t—at least not yet.</p>
<p>“The level of sophistication on power is quite varied, and the perspective of system makers is often quite different from the view of component makers,” said Chris Rowen, chief technology officer at Tensilica. “Some teams play it strictly by the book—just look at the specs of all the components, add up all the power, divide by battery capacity, and struggle with the answer. They may always not appreciate either the central role of scenario analysis and software-driven power management in making mobile devices battery life and thermal issues tractable. At the same time, some also have gotten a deep appreciation of some subtle issues around power. For example, the leakage current of 45nm and 28nm digital circuits is actually not bad under typical conditions—room temperature and average processing—and only a small fraction of the active power at normal clock frequencies.”</p>
<p>But only small changes in temperature or other random variances produce non-linear effects that can greatly exacerbate leakage. Rowen said some engineers have been burned by these surprises and are starting to invest much more to avoid them.</p>
<p><strong>Field tests</strong><br />
It also helps that consumers are becoming much more savvy about power. They can set preferences on their phones to minimize power consumption, and increasingly understand that bad reception can sap battery power as a device attempts to communicate to find a better signal. They also can spot a problem and communicate about it over the Internet.</p>
<p>That’s exactly what happened with Apple’s iOS 5 operating system. The newest release includes changes to improve battery life. What makes this particularly interesting for the SoC design world is that Apple is a true integrated device manufacturer. It designs the chip, the software that runs on it, the interfaces for the applications that run on top of all of that, as well as the overall platform. In fact if anyone can get it right, it should be Apple. Still, the complexity of a device like an iPhone or an iPad has surpassed even the most advanced technology companies, however. </p>
<p>“It’s really hard to tell where the problem is,” said Chin. “But these days beta testing is happening at the user level. The problems are so complex that companies need population data to determine the problem. Luckily, connected devices continually gather that information. Apple can gather information from 250 million users in the first week of release. If you were to do system-level simulations, how much can you really simulate in six months? We’re seeing public beta testing for that.”</p>
<p>In this case, users actually became part of the expertise needed to test the power on the iPhone—and an extension of the power verification team at Apple.</p>
<p><strong>Short-term and long-term</strong><br />
While this is an interesting development in power verification, most ICs sold into a socket don’t have this luxury. They have to work well, and they have to be competitive from a power, performance and area/cost perspective. They also have to be delivered on time with increasing complexity, meaning everyone in the design chain will need to know something about power, and some engineers will have to know a lot about power. </p>
<p>While some of that expertise may be automated in the future, experts will still be required to solve thorny issues involving power and related issues such as heat for many years to come.</p>
<p>“Low power expertise won’t necessarily secure you a job, but in whatever you do, low power expertise will help you do your job better,” said Wang. </p>
]]></content:encoded>
			<wfw:commentRss>http://chipdesignmag.com/lpd/blog/2012/03/08/experts-vs-expertise/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

