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.

By Ed Sperling
Synopsys continued its buying spree, acquiring verification IP developer ExpertIO. Synopsys will absorb the entire ExpertIO team, including CEO Craig Stoops, into its verification group. Terms of the deal were not disclosed. What’s particularly interesting is that ExpertIO’s partners include all of the Big Three EDA vendors.

Synopsys also is collaborating with Sigrity to accelerate signal integrity analysis, and it won a deal with Yamaha, which is standardizing on its Processor Designer tool for custom DSPs.

Mentor Graphics won a deal with Altera, which will use its Voloce emulator to verify its next-generation FPGAs.  Mentor also won a deal with Fujitsu Semiconductor, which is expanding its use of Mentor’s Calibre platform for physical verification and DFM. e

Open-Silicon rolled out a 28nm version of its Interlaken IP core for chip-to-chip packet transfers for networking products.

Arteris reported more than 100% growth in NoC technology licensees in 2011. The number is now 39, up from 18 at the beginning of last year.

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
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: What’s changing in design?
McNamara: Software is a component that can’t be ignored anymore. It can’t be done later in the design cycle. The hardware-software co-design is a real problem—and a real opportunity. When you look at battery life, often it’s the software that has to be fixed. It isn’t the hardware. The software is now smarter and does more.
Subramaniam: As you go into smaller geometries you have more choices in terms of technology and complexity. There are more variables in the technology, different libraries that are available, more choices in terms of transistor Vt and channel length. If you look at the combination of what’s available to do a design, finding the optimal point in your design optimization is key. How do you optimize for power, performance and area all at the same time. Many people only see a small portion of the design space that’s available to them, but while it may be good enough for them it may not be the optimal solution.
Varadarajan: What’s changed is the increasing commonality between SoCs today. You see an ARM core, a GPU from ARM or Imagination, and DDRs. The challenge is how to improve the turnaround time for closure. These designs undergo a lot of derivatives over their lifespan, which are incremental changes. The real challenge is how you can close on a new derivative in 10% to 15% of the time it took to do the original design. What can you capture to achieve closure at the front end so every single design is not a complex back-end-to-front-end netlist handoff process? There are some customers going down that path already, putting in methodologies and mechanisms to ease that process.
Rey: There are a lot of tendencies and trends that require the tools to be faster and have new functionality, and the designers need to be aware of that to get an edge over their competition. In addition to that, there is also a need for portability. People don’t want to be tied to a single semiconductor manufacturer. They want more than one source. Designers need to be aware of that and be able to port their design to different places, and the tools need to be able to play in more than one place at the same level.
Zorian: There are two things going on. One is that complexity is going up, and the other is that shrinkage continues. On the complexity side IP usage is going up. It’s now 70% to 90% of a chip. But if you look at vertical markets, IP is not enough. These need to be grouped together into subsystems to improve re-use and reduce design time. On the shrinkage side, maintaining the health of the chip is a problem. The more we shrink, the more important our yields, quality, reliability and testability. We need to ensure those capabilities are available early on in our IP and our subsystems. You have placeholders, so as you move down you can shrink while maintaining the health of the chip.

SLD: How do we deal with all of this complexity? Is it a matter of raising the abstraction or do we need to deal with the problem differently?
Varadarajan: Abstraction is the key message. If you look at all the advancement over 20 years, physical synthesis still closes timing at the cell level. It places and routes standard cells and finally signs off on timing at the standard-cell level. That’s what designers trust, and it has to go down to that level today. Being able to have enough confidence at a higher level of abstraction and having global design closure with confidence is essential. Being able to predictably create subsystems and validate timing closure at that level, before you descend into the detailed implementation is essential.
Subramaniam: Abstraction alone is not enough. What you need in addition to that is an actual implementation of that abstraction. One of the reasons IP re-use has been successful, particularly in the analog and mixed-signal area, is that you have the abstraction and the actual implementation. You know that when you implement something it’s going to work. We need to extend that to the subsystem level. Today we have it at the individual IP block level. We don’t have it at the level of the subsystem. We need to create hardened or quasi-hardened models, so you can have an abstract view of that subsystem and also know how it will behave. You know its performance characteristics, its power characteristics and all the other critical characteristics. In 3D ICs, you might have pre-implemented version of subsystems that you can simply drop in. That makes derivatives simple. You have a common subsystem with a standard interface. It allows the designer to focus on one portion of a design, no matter what the technology node.
Zorian: I agree that having abstraction isn’t sufficient. You also need the ability to explore the different options and optimize between them. You need automation capabilities to explore those options and see what the best choices are. It may be 2D or it may be 3D. But with designs today you have so many ways of optimizing them. To explore that is very important.
Rey: On the implementation side, historically there were not robust methods to keep the abstraction level all the way down to the implementation. That is changing. You come up with IP, you know where you can stretch the limits of implementation, and you need to get those details down to the implementation. The foundries are jumping into that. It’s becoming mainstream. Think about keeping several different power domains. You need to make sure information moves all the way from the system level to GDS II to ensure you are not crossing from one power domain to another without the proper protection. That’s happening now.
McNamara: At each design level we need some way of modeling the design. Then we need a way of verifying the design is behaving the way we think it should behave, whether it’s functional or electrical. There’s a transformation stage, which we call synthesis, where you take that abstraction level and push it down to the next level, whether that’s RTL to gates to polygons. And then you have an analysis or extraction phase that takes information from that level and projects it up to a higher level of abstraction. We’ve all built tools that do pieces of that. But if we want to raise it to a higher level of abstraction we need to have a modeling language and a way of transforming it to the lower levels and abstracting information up. There is a system above every design node that just considers us as a component. That plays all the way from the transistor to the macro cell and up. As we look at increasing complexity, we have to tame this. We need a way of bounding these things and putting rules around them so the higher levels can abstract away that detail but also take advantage of the power. If you have too firm a rule that doesn’t let you take advantage of what the power can do, then you’re leaving performance, area or power on the table. It helps to think of this in four boxes. Do we have a modeling language? Do we have a way of verifying it’s correct. Do we have a way of projecting it to the lower level? And do we have a way of abstracting things up to a higher level?
Subramaniam: The modeling language should be able to address all the key attributes of the design. You need to be able to define a set of metrics for every design, and then you need to be able to look at all the different alternatives that are available for that design and translate each of those implementations into the metrics. Now, when you’re in the exploration phase, you can take a particular design and if you use this combination of transistors or this process from this foundry, what does it look like? That’s really critical as part of the exploration phase. Both tools and language are required for this exploration phase.

SLD: Is there a language that does this?
Zorian: We are going up in abstraction. TLM is a high-level description. That same IP has multiple levels of description. But what is being shared for exploration purposes is a transaction-level model. Once you decide to use it, you go down to the detailed models. But there’s a good exchange of information at that level.

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.”

Hardware-aware virtual prototyping is the best way to optimize system performance, power consumption, and cost and enable concurrent HW/SW development. Using a multi-core design, this paper demonstrates how Vista hardware-aware virtual prototyping fulfills the key needs of system and software teams.

To download this white paper, click here.