By Ed Sperling
Cadence’s Pete Hardee digs into substrate biasing and whether there’s a real payoff at advanced process nodes. Answer: Yes, particularly for controlling current leakage in planar devices, but it’s likely to be overshadowed by FinFETs at 20nm and beyond.

Mentor’s Colin Walls examines the distinction between using SystemC for hardware models and test models. This is sort of like building the crash dummy or testing its limits.

Cadence’s Richard Goering reports on a development in formal analysis called “case-splitting” that can close up coverage holes in verification. This is an interesting twist.

Calypto’s Shawn McCloud, writing in DeepChip, unveils a survey of 744 engineers on what they do to reduce power in designs. Clock gating and power gating are at the top of the list. The 6% who “don’t know” may be unemployed soon.

Mentor’s Mike Jensen delivers the second part of his how-to on analog modeling, which may be coming to an engineering team near you—even if they swear they’ll never use this stuff.

Semico’s Morry Marshall looks at the pros and cons of an all-electric vehicle and who the likely buyer would be. But is it really pollution-free?

By Ed Sperling
Mentor Graphics boosted the functionality of its PCB tools, adding 3D field solvers and thermal/power co-simulation analysis. This is particularly important for high-speed interconnects such as SerDes, which requires 3D modeling for signal integrity analysis.

Cadence roared back to life in Q4 with revenue of $308 million compared to $249 million in the same period in 2010, and net income of $11 million (or $46 million non-GAAP) compared to a loss of $37 million in 2010 (or $18 million non-GAAP). The company anticipates revenue will be in the range of $305 million to $315 million this quarter, with annual revenue in the range of $1.24 billion to $1.28 billion.

Sonics and Tensilica are working together to integrate Tensilica’s DSP processor interface with Sonics’ OCP-IP interface. The goal is to boost on-chip performance while making it easier to integrate IP. These kinds of deals are helpful in getting SoCs to market more quickly. Sonics also issued its formal response to rival Arteris’ countersuit.

By Ed Sperling
System-Level Design sat down to discuss the changing design landscape with Juan Rey, senior director of engineering for Calibre in Mentor Graphics’ Design to Silicon Division; Michael McNamara, vice president and general manager of Cadence’s System-Level Division; Yervant Zorian, chief architect at Synopsys; Prasad Subramaniam, vice president of design technology at eSilicon; and Ravi Varadarajan, an Atrenta fellow. What follows are excerpts of that conversation.

SLD: As we go up in abstraction, will transaction-level modeling be enough? It doesn’t address software or the physical effects, does it?
Zorian: That’s correct. It’s a higher-level model. But it’s good for initial exploration.
Subramaniam: You need to be able to explore all the different multidimensional aspects of the problem—power, performance and area. Being able to look at one aspect is good, but it’s not sufficient. That’s the missing link here.
McNamara: That’s where you get to things like parasitic extraction. You need to lift up the power information from the RTL and the gate-level simulation and project that up to the TLM so you can run simulations there and boot software on it and get a sense of your power. As you switch to a different manufacturer, that also has an effect on the leakage power. You’d like to be able to project that information up, too. That’s crossing nodes with abandon. You’re going from a choice of one transistor to another and projecting that onto system-level power. But for us to tame the complexity we have to have a system that lets us do that. I may not care how fast it works. I may just need more than a day of life on a battery. I may need it to last the flight from here to India.
Varadarajan: The abstraction only works when there is correlation. It enables you to do design exploration. If you make all these choices and you can’t trust and implement those choices when you go to the back end then it’s not useful. The correlation is key as you go down in implementation. In a typical SoC you have IPs and complex bus fabrics switching up these IPs. What designers do is transform the SoC from a hierarchy where they collect IPs and push them to the bus fabrics into larger subsystems that get implemented by design teams. That is a difficult task. One of our customers complained there was a timing signal that went from the lower left corner of the chip to the top and all the way back down. That’s something that should have been addressed up front. When you go down into the implementation of a very complex IP that is coming from a third party, the implementation is going to be a function of how you break down the data flow, how you organize the memory and the floor plan of the entire IP. Being able to capture that and make high-value decisions, like whether you can push it from 400MHz to 500MHz, is going to be a function of how the floor plan is going to look. You need a predictable way of handling that. Once you have taken care of the global topology, all the physical synthesis tools are commodities. If you organize the data flow, they can all converge to the same timing targets. You need to demystify IP and break it down at the abstract level, and have enough confidence you can achieve your targets, whether that’s timing or condition or power, and then be able to implement that predictably when you go into the back end.

SLD: To get a design out faster you’re decoupling IP from the rest of the design. But to do exploration you need to really understand all the tradeoffs of performance, power and area from a system level. How do we bridge those disparate ideas?
McNamara: There’s a tools aspect to it of being able to extract information so it can be shared. The end customer needs to be trade off ‘A’ versus ‘B.’ You can assemble one company’s IP with another company’s IP, but you’re going to be just like someone else. So how do you differentiate?
Subramaniam: This is where system-level tools come into play. Today you can figure out performance and what speed you need to run your system at. But they don’t have the ability to absorb information that is available at the lower level. What we need to do is to input the implementation-related information up into the system-level tools. When the system-level designer is exploring the system bandwidth requirements and how to architect the system and organize the software and hardware partition, they should be cognizant of the implementation-level details at that level. That is a missing link today, and it’s a gap that needs to be addressed.
Rey: There is the issue of certification. You need to understand interactions when IP is placed in a certain area. Look at 3D integration, where you have things in different die that have to work together. Even though the general consensus is this is really a cost equation, as soon as you want to stretch the limits a little bit and go to higher frequency the approach breaks down. More research into implementation and testing will be required to make sure it works. When you go to very high frequencies we’re starting to see some effects that were not important before.
Subramaniam: If you look at memory, there are different kinds of memory interfaces. You can have a wide I/O interface in a 3D stack that is running at a much lower speed but giving you the same bandwidth as a much higher-speed interface that is SerDes-based and has fewer pin-count. In a 3D environment, both are applicable. In fact, the wide I/O is more amenable to a 3D environment. One of the things system-level tools should enable is for you to determine which makes more sense for this design. Should you use a SerDes-based high-speed serial interface to access memory or a wide I/O low-speed interface? This is where the power-performance-bandwidth-area tradeoff comes into play.
McNamara: It’s also the implementation. If it’s displaying video you need a lot of data, but it’s also 24 frames per second so you know exactly what bandwidth is needed for the next frame. Wide I/O could make more sense in that case. If you have a low-latency message and you need to get it quickly and it’s small, both would work. You could send the same message over either channel. But you need to see which one is better for the application. We’ve talked about power-performance-area, but there are many other cost metrics—things like routability. One design may be 10% smaller but the routing guys will kill you. You also have reliability. As geometries get smaller and smaller, maybe there’s another way of implementing something that’s more reliable, particularly if this is going into the back office of a bank. If you care about one of these other dimensions, is there a way to extract that information and project it through the system?
Subramaniam: You need to define the metrics and have those metrics defined for each one of these subsystems. That’s required for exploration.
Zorian: Exactly. But architecture-level exploration is there already—the prototyping capabilities where you can explore different architecture options, whether it’s 3D or 2D or wide I/O or not wide I/O. You can play with those. We do have virtual prototyping capabilities that allow you to play the game early on—pre-silicon.

SLD: That’s assuming your IP is very well characterized, though. From the big companies like Cadence, Synopsys, Mentor and ARM, that’s going to happen. From other sources, maybe not.
Zorian: When we started IP it was just for re-use. It was a design piece. Today that isn’t the case. There is differentiation between IP providers. I believe in IP completeness. You need to put out a complete package for IP. From a design point of view and from a manufacturing point of view you have to prove it in silicon, you have to have the silicon reports with it, and you have to maintain it internally with built-in self-test and built-in self-repair and debug diagnostics. That makes your IP complete, and it’s a differentiator in the future between one IP provider and another.
Subramaniam: This is where a standard like IP-XACT may come into play. If you have a host of third-party IP providers out there, how can the small IP players enable their IP in the ecosystem? The answer is by using a common standard to characterize the IP and fit their IP into the tools environment. That will enable designers to access that IP in their environment.
McNamara: And you mentioned the subsystem. It’s no longer that I want this PCI Express. I need a compute subsystem that gives me the floating point, the graphics, and so on. There’s IP that’s software for that. Often IP suppliers of these subsystems are giving you demo drivers. They almost work. You’re assembling this device to get to market by Christmas. You figure all you have to do is slap this thing together, put on Android and you’re there. Then you realize the driver doesn’t actually work. Then you integrate it all with the rest of the system and you find out you have to fix the driver again, because while it worked great after you fixed it on a point-to-point link, it doesn’t work as well on a shared bus. There’s also a software component there that has to be tested and proven. When you get to platform-based design, there will be common subsystems and the Linux kernels will already know about these. They’ll already have the device drivers. So then there may be hot IP from another company that gives you 10% more performance with 15% less area, but the Linux kernel doesn’t know about it. That’s now another challenge to the small IP providers. They need Unix developers working for them to deliver all of this and they may not be able to afford them. But how we’ve made these devices better every year is by taming complexity.

SLD: We also have to start dealing with yield issues, right? Multiple known good die could end up in a package or stack as all bad die.
Zorian: It’s not only the dies. It’s also the interconnects. Those TSVs are of a different nature. The defects that can hurt them are different. Our ability to test them at the end is not sufficient because by then you’ve destroyed your whole device. At the stack level you have to test and prove and retest.

SLD: It’s also the interposer, right?
Zorian: Same approach.

SLD: From a designer standpoint, assuming we have subsystems that can plug and play and IP that can be mixed and matched, how do companies differentiate themselves.
McNamara: That’s where having a complete flow is essential. One company did a great memory controller that could handle any device with 15 common memories, and you could use this IP on your device and build something that didn’t require custom memory. What this meant was there was wasted silicon. There were bits available to talk to memories that this device would never talk to. When we have this great system where we have the transformation tools down and the analysis tools up and this way to select IP and put it together, there’s another phase of this optimization that goes across the whole thing. It isn’t just gate-level optimization to clean up a couple bits. You’re looking across the whole stack and realizing the customer is going to run iOS on it and it will never run Android, so maybe there’s something you can get rid of reliably on this design, but keep the IP for another design and delete something else. That’s a differentiator. You need a way to optimize a design.
Rey: There is always the possibility of stretching the technology into limits that are defined in a conservative way by the manufacturer. Yield is one aspect. Another aspect is related to performance. You can see the companies that have an intimate understanding of the technology processes. They can go beyond the recommended rules and the established rules that the foundries have imposed, and it can give them an advantage.

SLD: Can that be done in a disaggregated market, or can it only be done by the large IDMs?
Rey: It can be done in a disaggregated market, and it has been proven by some of the companies we work with. What you need is a certain level of volume so the manufacturers will pay attention to you. Otherwise it’s going to be a lot harder.
Subramaniam: I agree. If you look at the performance of different technology nodes, there’s a significant overlap in performance between neighboring technologies—40nm and 28nm, and 40nm and 65nm. Somebody who makes a smart choice can differentiate their product by implementing it in a cheaper technology versus someone else who uses brute force in a more expensive technology. That’s one way of differentiation. But in spite of there being a lot of re-use, there’s always going to be some aspect of the problem which is unique to the individual—algorithms, software techniques—and those will be designed independently. They will be complementary to the re-usable IP and that will always be there. But when you talk about wasted silicon, that is a by-product of re-use. Not everyone can afford to do a custom design for every design. There will be some customization, but that will be dedicated to a small portion of the overall system.

By Ed Sperling
Cadence’s Frank Schirrmeister compares the state of system-level design to predictions made 10 years ago. A key finding: IP re-use solved one of the big system-level problems identified at the end of the last century.

Synopsys’ Karen Bartleson is hosting a trivia game throughout 2012. Prizes are $40 Amazon gift cards. Given Amazon’s just-announced earnings, this may qualify as a corporate charity write-off for Synopsys.

Mentor’s Robin Bornoff looks at the reasons why thermal interface materials go bad and what to look out for to prevent bottlenecks or, worse, complete meltdowns.

DeepChip’s John Cooley is soliciting comments for the FTC on the proposed Synopsys acquisition of Magma in light of previous concerns that were raised when Synopsys bought Avanti in 2002. But are those claims still relevant? Mike Demler offers up a completely different viewpoint, also in DeepChip. He says that Magma shareholders should be thrilled by the offer.

Cadence’s Richard Goering focuses on a white paper that shows verification performance is more than just raw simulation speed. There are some notable pointers to how to speed up the simulation process.

Tom De Schutter, writing in Synopsys’ TLMCentral, is running a competition for sensor device modeling. The deadline for submissions is in 16 days. Start coding.

Mentor’s Colin Walls addresses an engineer’s concerns about real-time signal processing with Android and other OSes.

And in case you missed the most recent System-Level Design newsletter, here are some standout blogs:

–Mentor’s Jon McDonald looks into how differences of opinion can affect design.

–Synopsys’ Achim Nohl addresses the question of what makes one model better than another.

–Cadence’s Frank Schirrmeister expounds on the importance of software in hardware designs.

–Sonics’ Frank Ferro pulls back the covers on the reasons why SoC design is suddenly much more interesting to a lot more people.

–Arteris’ Kurt Schuler adds meat to the argument that the time to invest in semiconductors is during a downturn.

–eSilicon’s Doug Ridge draws a parallel between the odd mix known as turducken and SoC design.

–Methodics’ Simon Butler digs into why IP distribution is such a big problem.

–And Atrenta’s Tiffany Sparks looks at some electronic designs that literally can change lives.

System-Level Design talks about what’s changing and what’s needed with Juan Rey of Mentor Graphics: Yervant Zorian of Synopsys; Michael McNamara of Cadence; Prasad Subramaniam of eSilicon; and Ravi Varadarajan of Atrenta.

By Ed Sperling
Estimates of how much time it takes to verify a complex SoC are still hovering around 70% of the total non-recurring engineering costs, but with more unknowns and more things to verify it’s becoming harder to keep that number from growing.

Verification has always been described as an unbounded problem. You can always verify more, and just knowing when to call it quits is something of an art. Moreover, with software now thrown into the mix, engineering teams have to decide what’s good enough for tapeout and what can be fixed once the chip is already in the market.

Making that decision is becoming tougher, though. The amount that has to be verified is less clear, in part because of the growing amount of outside IP that is now included in designs. Of the 70% or 90% of IP that is used or re-used in a complex SoC, less than 50% is now commercially purchased with the remainder internally developed, often for previous projects. The amount of commercially generated IP is expected to rise over the next few years, though, basically creating a series of black boxes that companies didn’t create internally.

While much of this commercial IP will be sold as pre-verified, what works in one design may not work exactly the same way in another. That’s particularly true with different process technologies. A general-purpose process built for speed may cause IP to behave completely differently than one optimized for low power. And in stacked die, two known good die may no longer work when they are packaged together.

“The new world is a broader supply chain for chips,” said Mike Gianfagna, vice president of marketing at Atrenta. “There is a need for better visibility in the supply chain, including everything from early predictions to yield to the track record of the supplier. There are multiple points of failure. For data management, planning, thermal and mechanical analysis you need fundamental enabling technologies. At the same time there is a re-invention of the industry into smaller, more niche markets.”

Knowing what to verify
Just knowing how much to verify is a challenge. Taher Madrawala, vice president of engineering at Open-Silicon, said this is not a simple decision because file sizes for verification are becoming enormous. That means what gets left out of the verification process may be as strategic as what gets included, because all of this can affect time to market. Verification budgets remain tight, both from a manpower and equipment standpoint.

“On top of that you don’t always have access to all of the functionality,” Madrawala said. “That’s especially true in 3D stacks or system-in-package. You don’t always have access to increased functionality because some things are encapsulated inside the package.”

He noted that from an NRE perspective, the percentage spent on verification has remained constant from 90nm down to 45nm. That has been helped by more standards, including modeling of IP in C or C++, an increased use of emulation, and the ability to run tests on multiprocessing computers. But with compressed schedules and greater complexity, those numbers can change.

There also are differences of opinion about what works, what will continue to work, and what needs to be changed in the future, both from a physical and a functional standpoint. Tools vendors insist that most of the capabilities are already there to do verification, even though they will need to be speeded up through better modeling at a higher level of abstraction with a greater reliance on multiprocessing servers. They also say that verification teams need to learn to use the tools that are out there better.

Chipmakers generally acknowledge the need for better training on the tools, but they say the growth in complexity will create the need for additional testbenches. In particular, there will need to be new tools for partitioning designs and verifying the results once stacked die become more mainstream.

“As complexity grows, integration will be the issue,” said Prasad Subramaniam, vice president of design technology at eSilicon. “You will need specialists for each part of the design. People’s specialties will get narrower. And then you will need people to manage more specialties. The generalists, who will be the architects and higher-level engineers, will define the problem. Once they have made the decision about what to do, then the specialists will take over. But there will also be a lot of feedback. This will be an iterative process. There will be meetings where you need to reconcile differences and make adjustments. There will be a lot of collaboration, and verification will start from the get-go.”

Verification strategies
There are two main approaches to verification. One is to verify the pieces. Another is to verify the system. Both are necessary, but the order in which they need to be done as part of a verification flow can vary greatly for even derivative chips.

Samta Bansal, 3D IC lead and silicon realization digital project manager at Cadence, said that in stacked die an incremental approach will be needed to do verification. “If you analyze it all together it overcomplicates the process,” Bansal said. “For one thing, not all of the pieces will be available at the same time. A more feasible approach will be to verify each chip in a stack as part of a verification flow, then focus on the microbumps, TSVs, LVS and DRC for alignment and ultimately create a single file.”

That’s not so simple, of course. In stacked die there are physical verification issues that can complicate the functional verification, notably stress and power. And there is now software that needs to be considered in the mix, with the trend toward an increasing portion of the stack.

“Functional and physical verification are both important but independent tasks,” said George Zafiropoulos, vice president of solutions marketing at Synopsys. “In both cases, verification is moving up in system complexity. We’ve gone from blocks to lots of blocks to lots of processes and I/O, and there is more stuff coming. Complex interface IP at the periphery of the chip has gone up by an order of magnitude. The design team can’t verify everything, though.”

Zafiropoulos said design teams used to think there was not enough time to do verification at the block level. He said that putting 100 blocks together increases the challenge exponentially.

“A lot of this is bottom up,” he said. “You build sub-circuits up to the chip and then in multiple chips. You can’t afford to have errors inside these blocks. But you also need to change the scope of what has to be done. In the past, one engineer could comprehend everything on a chip. Now we’ve gone from the guy who knows everything about a chip to teams that are in different companies and maybe different countries.”

The result, he said, will be a gradual change in three areas. First, more and more engineers will do verification, rather than just specific verification teams. Second, all engineers will become more software savvy. And third, new kinds of tools will be introduced, including formal approaches.

By Ann Steffora Mutschler
From its perspective as a leader implementing system level design methodology, STMicroelectronics is uniquely positioned to discuss issues and challenges related to the use of models in a variety of use cases. System-Level Design had the opportunity recently to discuss challenges in the modeling space with Jean-Marc Chateau, director of ST’s SPT (System Platforms and Tools) group; Alain Clouard, manager of the System Platforms Group (SPG) part of SPT; Laurent Maillet-Contoz, team manager of system modeling technology and infrastructure, part of SPG; and Antoine Perrin, team manager for verification, validation and software platforms, part of SPG. What follows are excerpts from that discussion.

SLD: What is ST’s overall model approach?
Chateau: We have several types of things we need—not only one type of model to do system-level design with a full methodology and a full environment. There are transaction-level models that we need and that we purchase and develop internally, as well. Together we also need verification components, VIP we purchase, which are also models in a way, and we need also to have the IP-XACT view together with the models and the IP in order to assemble a full platform. In this platform we also need transactors between RTL and TLM, and therefore we have to purchase those transactors as well.
Clouard: We use models that are typically TLM models as reference models to generate expected data when verifying hardware—VHDL or Verilog RTL. We use these models as well as a virtual platform to develop either systems that can be run from the RTL verification or a virtual platform to develop the prediction software that could be shipped to the customer.

SLD: What are the issues today with transactors?
Perrin: Today for verification of the software or even for the architecture we need transactors and we need performance with this product. Today I run the RTL on the emulator or on the simulator. We need both types. We need a transactor that can run in pure simulation mode or coordination mode. Depending on the kind of protocol that we use, we develop this transactor internally or we can have it from a third party if they have it.
Chateau: Typically each emulator vendor is proposing a separate transactor—sometimes fully, sometimes partially. The problem I see today is I have to partition the same type of transactor from each vendor because it is proprietary to their emulator, while what Alain is developing with his team is generic and can be used on all, but we cannot do all transactors as well. Of course we would prefer to have to partition only one transactor per protocol for any type of machine, but today that is not the case. To be more precise, Mentor, Cadence and EVE have their own transactors that cannot be used with the other machines.

SLD: In terms of obtaining TLM models from outside vendors, are they providing what you need?
Clouard: For processor models, it’s not a secret that ST is using quite a lot of ARM processors and we have now for several years a good offering in processor models for the virtual platforms from ARM. We integrate their models into our virtual platforms. This is for fast simulation but we have very low need for performance estimation and no need for estimating the time the application will take on the chip. This is the most usage we have inside the company that is with models that are functionally representative. Performance estimates are another type of usage. We have concerns about having processor models that provide performance estimates—comple SoC performance estimates well ahead in the project that are not provided by ARM. This is not provided by other suppliers except Carbon, which is providing cycle-accurate processor models that we can embed in our TLM virtual platform. Carbon now has an offering to switch from flat transaction-level models to cycle-accurate models, which is a good step. But we still are looking for a supplier with an ARM-certified processor model that is fast and cycle-accurate or time-accurate enough and affordable. What we need for wide deployment is the combination of software platforms, the combination of some timing accuracy—not necessarily cycle accurate—but some timing accuracy. We also need fast speed for executing large portions of software, not only small benchmark code, and it has to be affordable for deployments by the software teams and system architects.

SLD: What kind of power information is available with models today?
Maillet-Contoz: There is at the moment no real representation of power information at the transactional level because TLM models include very loose timing information. You cannot associate cycle accurate power information into your very loose timing models. There are some ongoing R&D activities to cover that and to find a way to associate TLM functional models and other kinds of models that would deal with non-functional properties and particular power information, but that’s R&D activity now.

SLD: What about IP models?
Clouard: We develop our own library of our own IP. For the IP we purchase, the biggest IP vendor is Synopsys, which now has a large offering of TLM models that we have started to use, as well. But it’s not the case for many other vendors. ARM has TLM models for processors, but not for graphics. And Imagination, which is very popular in the mobile/smartphone/tablet world, also has no TLM models. In that case, we need to find a way to have a full platform either using emulation or Carbonizes the RTL. There is really a lack of TLM models.

SLD: Why are there no TLM models for graphics processors?
Clouard: Some suppliers are moving into the direction of having a C/C++ reference model first in their design team, which makes it possible for them in the future to provide System C/TLM wrapping of those reference models. So I think that will come. In the past, GPUs have been designed in a custom flow at each IP supplier.
Chateau: In general it will come when the IP is complex enough that they need to design it with a top-down flow starting with a model in TLM as a reference like we do for SoCs today with IP from ST. It is very important for us to have the TLM model and IP before the RTL because if it is a new IP that is not developed, and we are waiting for it from the vendor, the architect will need the TLM before the RTL. We need to synchronize both teams: the IP vendor team and the user in the system house team—synchronize on the same flow in order to get what we need, when we need it.

SLD: What are other issues with processor models or IP models that the vendors need to address?
Clouard: For sure, the interoperability of TLM models is not complete enough today.

By Ed Sperling
Fabs and foundries frequently have been the savior of flawed designs, fixing problems such as power and performance, identifying design issues and often developing solutions to those problems.

Over the next couple of process nodes, and in stacked die that will span multiple processes, there will be far fewer saves coming from the back end. Double and triple patterning, stress effects, new materials and the laws of physics are forcing a change in direction. In fact, for the first time design teams will have to make up for a slew of changes and challenges on the manufacturing and packaging side, employing new methodologies, new tools and deeper levels of expertise.

In a keynote speech at the SEMI Industry Strategy Symposium last week, Applied Materials chairman and CEO Mike Splinter sounded the alarm over the changes ahead. “Change is accelerating,” said Splinter. “Compared with the last 15 years, the next five years will have more changes and more inflection points. And it’s not just about complexity. It’s happening at the foundational level of how an IC is made.”

He’s not alone in that assessment. Bernie Meyerson, an IBM fellow, said CMOS is now in “the end game.” While CMOS certainly isn’t going away, there are physical limits for what can be done to extend it. That has spawned extensive research into alternative materials such as silicon on insulator and graphene, new elements for insulation, as well as new structures such as FinFETs and carbon nanotube FETs.

So what does this mean for design at advanced nodes? Lots more work on design for manufacturability, more complexity in achieving the same kinds of boosts in performance and energy efficiency that were taken for granted at older nodes, and much more up-front checking of just about everything.

“From 40nm to 28nm to 20nm, the number of checks for physical verification will grow by leaps and bounds,” said Michael White, director of product marketing for Calibre. “There are almost 1,000 more DRC checks from 40nm to 28nm between early production and volume production. We are also capturing additional context-dependent yield detractors. For example, historically we have had spacing checks. Now we have spacing checks and we need to check all of the other geometries in the neighborhood, including lithography and fill issues. Those are extra constraints.”

Lithography used to be something design teams never had to consider. But the delay in EUV will require double patterning at 22/20nm and potentially even triple patterning of at least some portions of the chip at 14nm. This becomes particularly challenging for design teams, because one of the approaches under serious consideration is something called spacer-assisted double patterning. In simple terms, a polygon design may look nothing like what’s on the mask using SAPD. This is akin to driving a car in reverse using the rearview mirror where nothing that appears in the mirror resembles the road.

Stacking effects
One solution to these issues is stacking of die, whether in 2.5D or 3D configurations. The so-called “More Than Moore” approach bundles technologies together at nodes that make sense for a particular function, rather than trying to fit everything into the most advanced process. So while the logic or memory may be created at 22nm or 14nm, for example, analog may be developed at 130nm.

This all makes sense in theory, but it also adds a new dimension of complexity that ripples back and forth between the design and the manufacturing worlds. It also exposes the entire supply chain into the design process, because problems detected anywhere along the chain can affect multiple other areas—and it’s possible that no single segment can solve them alone.

“Over the next three to five years chips will go vertical,” said Naveed Sherwani, CEO of Open-Silicon. “The question is how we are going to put together 3D ICs and what will go into them. There is a lot that needs to be done in this area.”

Sherwani contends that tools and methodologies should make it easier and quicker to do derivative designs. That’s the goal, and at least part of the solution involves companies learning to use the tools they have more effectively, and to apply some discipline to their methodologies. It’s easy to get blinded by the number of permutations and choices from the growing complexity.

“As process geometries continue to get smaller and the amount of IP used increases, the complexity of the design process becomes a major issue, which puts pressure on the entire development team from a coordination and communication standpoint,” said Simon Butler, CEO of Methodics “Also, with software elements and power constants, which are really just other types of IP, added to the already very complex mix of things, design teams need better ways to manage the entire SoC development process and synchronize all the moving parts. Internal design organizations already struggle with managing remote design teams. Now, with a disaggregated design chain consisting of separate companies, the need for real-time collaboration and managed data exchange is critical.”

That sentiment is echoed across the industry. Frank Schirrmeister, senior director for the Cadence System Development Suite, said that in principal tools allow engineers to model almost everything they need. “This isn’t a tool problem. It’s a discipline problem. But the other side of this is that in 1993 logic synthesis was pretty simple. Twelve years later, the whole process is not longer understandable by any engineer.”

Margin call
One of the most effective ways to deal with unknowns in the past is guard-banding—the process of building extra safeguards into ICs. That worked until about 65nm, but at advanced nodes it can cause performance degradations or drain batteries more quickly, or both.

“The guard band for synthesis is a smaller percentage at 28nm and it’s even smaller at 20nm,” said Jack Browne, senior vice president of sales and marketing at Sonics. “So you’ve got to be able to interoperate with the right guys. We’re all trying to manage a horrible amount of complexity and simplify it. The problem is there is too much that’s new and not enough experience points so that people can make the safe choices. There are significant unknowns on everyone’s road map.”

One potential solution—and one that’s being considered by a number of large chip and IP companies—is to harden everything into pre-qualified, pre-verified subsystems. While this limits the number of permutations, it does take some of the risk out of using those blocks. But too many hardened subsystems also can limit the ability of companies to differentiate their designs. And while that works well at a company like Apple, it does not work so well at a chip company trying to sell technology to Apple’s competitors.

“With subsystems you’ve closed the black box and given up the chance to turn some of the dials,” Browne said. “We’re seeing this with the TI OMAP team, which has accumulated a significant number of libraries and with Broadcom. And Toshiba has created video and RF subsystems.”

Caution ahead
All of these issues have raised questions about what needs to be fixed in the design flow, what needs to be extended, and how this will unfold over time. The reality is that changes may be slow because there is serious uncertainty about exactly what problems will erupt, where and when.

“There’s always a risk of getting too far ahead with the tools,” said Steve Smith, senior director of platform marketing at Synopsys. “We will add capabilities to current tools to make them 3D aware, but the goal is to enable engineers to do what they do best. We’re already dealing with multicorner, multimode design, and 3D will be another dimension. We might have coupling effects and we certainly will have a challenge with temperature. But most of the processes are familiar, and changing things in a working flow is always risky.”

By Ed Sperling
Mentor’s Travis Mikjaniec takes a scientific look at a question that has long plagued homeowners: Is pipe insulation effective? In a word, yes. But if you’re reading this while holding a hairdryer to your pipes, it’s clearly not as effective as you would hope.

Synopsys’ Mandar Munishwar writes about how to close the gap between verification coverage numbers obtained through simulation and the optimal coverage goal. It’s a time-consuming job, but someone has to do it.

Cadence’s Qi Wang looks at who needs to worry about low power in design. Hint: Everyone.

Semico’s Michell Prunty takes a step back from the CES hubbub to ponder what’s really going on—a battle of digital ecosystems. This is an interesting look at the market from a completely different angle.

Mentor’s Colin Walls digs into why the embedded software market is becoming so interesting. Think Intel Inside, or at least deep inside Intel.

Are smart phones really running at 4G speeds? According to Synopsys’ Hezi Saar, no—at least not the current models. But things are about to get faster quickly.

Cadence’s Richard Goering interviews Cadence’s Frank Schirrmeister on system-level design. Granted this is a closed loop, but there’s a lot of good information circulating here.

Mentor’s Robin Bornoff looks at 3D thermal packaging and how to model these complex devices from a power/heat standpoint.

Synopsys’ Karen Bartleson interviews a Russian educator on engineering education in Russia. You can hear this one for yourself.

Cadence’s Vincent Reynolds reports on the “Club Formal” event in the U.K. last month, including pictures. Given the increasing challenges of verification these days, this kind of education is absolutely vital.

Synopsys’ Eric Huang has found the fastest advertised USB 3.0 flash drive on the market. Check out the stats.

By Ed Sperling
NXP has incorporated Tensilica’s ConnX baseband engine DSP core into its software-defined radio platform for satellite and terrestrial digital radio. The chip is being used in everything from digital radio and mobile HDTV to traffic system electronics.

Cadence published what it claims is a definitive book on advanced verification. Given the time it takes to do verification, this certainly can’t hurt.

Picochip churned out a femtocell for the consumer electronics market using Synopsys’ Galaxy flow, which speeded up migration to the 40nm process node.

TSMC reported a 4.5% year-over-year decrease in Q4 revenue, with a net margin of 30.2%. While that’s an interesting bellwether for the semiconductor industry, what’s really interesting in the earnings report are some of the other numbers. In 2012, the company expects capital expenditures to be about $6 billion. In addition, 28nm process technology accounted for just 2% of total wafer revenue; 40nm was 27% and 65nm was 30%.