By Ed Sperling
The push to “smaller, faster and cheaper” hasn’t changed since ICs were first introduced, but the context for those requirements is beginning to shift—with enormous consequences.

What was once done on multiple chips continue to migrate to a single chip or package because of cost, but in some cases the decisions about goes where go well beyond an individual device to include a network of systems. Power and heat have forced some of those decisions. Others are being driven by shorter market windows that affect business decisions about exactly when to move to smaller, faster and cheaper, and whether to keep a design in two dimensions or move to three. In some cases, it even has evolved into a tradeoff about sharing resources to make up for additional costs elsewhere in a design.

“Form factor is everything in a lot of these cases, and you’re being forced to make tradeoffs involving a lot of different pieces,” said Mike Gianfagna, vice president of marketing at Atrenta. “But that requires you to know exactly what you’re doing. A lot of times you don’t. What happens when you reduce the number of layers? Do you know the impact on the system? You may not. But competitive pressure is also forcing you to rethink everything.”

Rethinking designs
Some of these changes are as fundamental as where the processing gets done. While the concept of cloud computing has been around since the days of time sharing on mainframe computers in the 1960s, the ability to offload processing and storage on the fly—and to load balance across compute farms around the globe—adds a modern twist to it all.

The result is a handheld device with the performance capabilities of a compute farm—but with the design focused far less on local processing and storage and more on communication and battery life.

This is evident with a number of upcoming communications schemes and protocols in the handheld market. LTE Advanced, for example, which is expected to find its way into smart phones and base stations over the next four years, focuses on reducing power while increasing performance. One of the best ways to do that is by shifting what processing is done where.

“One of the key decisions is how much processing and intelligence is in the cell phone versus the cloud,” said Graham Wilson, a product marketing manager at Tensilica. “You also have to understand deeply what cores are being used for. There is no room for fat. We’re also going to see a big shift in infrastructure from homogeneous to heterogeneous.”

That means rather than a giant cell tower on the highest hill or building, smaller boxes will be mounted on houses and strung together in a mesh network. “Every house will have its own femto cell or pico cell box so they’re less reliant on the macro cell and they work off each other,” Wilson said.

That changes what resources can be committed within a design to processing, to communication, to storage, and where it can be done best—whether it’s a central processing unit or lots of smaller processors for individual uses. It also boosts the ability to cut some costs in different places than just by shrinking the process geometries in a design.

The Low-Latency Interface working group of the MIPI alliance, for example, is currently working on a new standard that allows DRAM memory to be shared between two chips. NoC technology vendors, in particular, have seen this push because it requires a highly efficient network-on-chip infrastructure.

“The big advantage is that it allows you to get rid of an entire memory chip,” said Kurt Shuler, vice president of marketing at Arteris. “The modem and the application processor are sharing the same memory. You also reduce the number of pins, which is important because it allows you to use those pins for other things.”

He notes there is a very slight performance hit. But the ability to eliminate an entire memory chip can save a couple dollars in a design. Multiply that times millions of units and the savings are huge—far greater than just shrinking the features on a die.

Rethinking packaging
Stacking die offers another alternative to improving performance and time to market, but the tradeoff will be in cost unless additional components can be eliminated. Adding an interposer layer or TSVs will be expensive—at least initially—even though 2.5D and full 3D stacking hold the promise of dramatically improving performance through shorter distances, bigger pipes for data, and lower power because signals will not have to be driven as far.

While this packaging approach is still under development, foundries report that chips are rolling out using this approach. “This is already happening,” said Luigi Capodieci, R&D Fellow at GlobalFoundries. “It’s mostly a decision of which design processes to use in the chip, and that decision will have to be made by the chip designers.”

Stacked die also allow IP developed at older nodes—particularly analog—to be attached through Wide I/O to other chips developed at more advanced processes. That, at least in theory, substantially reduces the time it takes to design a chip because much of it can be based on what has been previously developed.

“Re-use leads to a reduction in time to market,” said Shrikrishna Gokhale, COO and managing director of Open-Silicon’s India unit. “This opens up the lifecycle of different IP and puts the emphasis on packaging and re-use.”

It also puts greater emphasis on software-hardware co-design, he said, and requires more emphasis on defining partitioning earlier in the architecture phase. In addition, it requires a rethinking of what gets done where. Some portions of the design that used to be in separate locations now have to be co-located in the same place because of the constant need to update models and data for both hardware and software teams.

“The logic front-end design needs to be done at the same location as the software,” he said. “That’s less important at the back end, which is the physical implementation.”

Other tradeoffs are less obvious, though, particularly to design engineers. One involves weight.

“Half the weight of a tablet is the battery,” said Drew Wingard, CTO of Sonics. “You can’t afford to add a bigger battery so you have to do an increasing amount of computation with lower power. That means you look at more efficient ways of doing that computing. One is using the GPU as a general-purpose CPU, which allows you to get a lot of performance at low energy.”

He noted that utilizing the GPU requires it to be easily accessible to software developers. And it requires much better management of clock domains, voltages and on-off functionality within an acceptable power budget. And to be really energy-efficient, users need to be able to easily input their own usage models.

Rethinking manufacturing
Some of the changes that are under way are forcing a major shift in manufacturing, too. Staying on the Moore’s Law road map has always been a given for high-volume digital designs, but with double patterning required at 14nm and the delay in extreme ultraviolet lithography, alternatives are being considered that could have ramifications throughout IC design.

“Double patterning is the biggest issue we’re dealing with right now,” said Jean-Marie Brunet, director of product marketing for model-based DFM and place and route integration at Mentor Graphics. “We’re even looking at triple patterning, but there is no way to have density balance between the layers when you do that.”

Lars Liebman, an IBM distinguished engineer, said his company has been working on commercializing self-assembly for finFETs because even multi-patterning isn’t sufficient beyond 14nm. That has implications throughout the design chain. For one thing, it can increase the density on existing process nodes. For another, many of the tools for automating design, particularly on the DFM side, will need to be rewritten.

Conclusion
Area, power and performance have always been the standard metrics for tradeoff in any IC design. What’s changing significantly is why those tradeoffs are being made and where the benefits will show up. Changes targeted at an individual chip in the past, or even a block or subsystem, may now be aimed at a much broader level.

The good news is that infrastructure changes—everything from manufacturing approaches to communications networks—evolve much more slowly and deliberately than those made in the individual device or chip. The bad news is that sometimes that moves so slowly that it can affect what’s done elsewhere in this much broader system. But some change is underway at every level, and managing that change—and the tradeoffs it will demand—will be much more challenging in the future.

By Ann Steffora Mutschler
With the cost of designing and producing even moderately advanced SoCs skyrocketing, semiconductor companies and systems houses must find ways to defray the cost across a larger number of end uses than ever. As such many companies have adopted a platform-based derivative design approach, with that the platform serving as the first SoC design of a new family.

That strategy is expected to become far more widespread as mainstream process nodes push beyond 40nm, outsourcing of entire subsystems becomes more popular, and stacking of die gains traction.

“There used to be this idea that you would define this platform and all the chips would be derivatives of that platform,” said Drew Wingard, CTO at Sonics. “Now it’s more of, ‘No, we can’t afford to think about trying to build the platform itself. Instead, we are going to build the first chip, but we are going to use a platform-based design approach, which basically says we’re going to set ourselves up so that we can make derivatives.’ The way to sell this to more people is to personalize it for different customers or for different markets or for different regions of the world by making these derivatives. I think that’s a very common need that’s expressed to us by our customers, and it’s all of course about defraying the cost.”

But what exactly is a platform? A commonly cited definition was provided by Alberto Sangiovanni-Vincentelli, a professor of electrical engineering at the University of California at Berkeley, who is best known for co-founding both Synopsys and Cadence. He defined a platform as a set of choices that you’ve made, and because you’ve made those choices you can then abstract upwards from them to a higher level of design abstraction. And because you’ve fixed those aspects, you can refine downward.

“So the question then in a platform design is, ‘What things do you fix, what decisions do make and what decisions do you make flexible,’” said Wingard. “What things can you make different in each of the different derivatives? That’s what gets interesting about this whole theory of platform-based design.”

Of course, companies like Intel have been derivative powerhouses from the very beginning, noted Naveed Sherwani, president and CEO of Open-Silicon. “That’s actually what their strength is. They would have one or two teams chase new designs, then they would have 5, 10, or 15 teams do derivatives. The challenge is not actually to do derivative engineering. The challenge is how to do derivative engineering in the most cost-effective fashion.”

What is considered cost-effective today, however, is a different formula from what applied five years ago.

“Derivatives are being used to chase smaller and smaller markets because markets are fragmenting,” Sherwani said. “We have the long tail effect. We don’t have that $3 billion market to chase. Those are few and far between. Now we have to go chase that $200 million or $400 million market. Previously you could be more inefficient in your derivative design and you could afford to be late, but now you have to be very efficient because you are chasing a smaller market.”

A second consideration is to determine if a derivative will be outsourced. That requires effort in every aspect of chip development. “You have to have a full vertical team, and that’s not quite the case when we’re doing ASICs. Somebody is giving us fully functional RTL and our job is to do physical design, tape it out and get a working part. That is a completely different phenomenon when you go to derivative design,” Sherwani continued.

Closely connected with this decision is the rapid rise in various forms of die stacking—system in package or 2.5D with a silicon interposer—which has given semiconductor and systems developers a greater degree of freedom to choose the right option for their situation.

In this realm, Jack Harding, president and CEO of eSilicon explained the company is seeing large semiconductor and systems companies who say, “I’ve got this large inventory of successful parts. I’ve got for example, 180nm die sitting on the shelf and I’ve got this other 65nm die I got from the guy down the street and I got this RF radio I got from Skyworks and I’m going to put that all together and make some sort of product as opposed to actually making a brand new chip. The thought process is much like making a derivative. You’re making an architecture, you’re considering the software implications, you want to use as much of each, but you’re approaching it from two radically different perspectives.”

One involves making a chip that is a superset of something a company has already created. A second involves piecing it together with components the company can acquire. “Or we can try to piece it together with stuff that you have or you think you can get,” Harding said. “Let’s make a chip that is packaged or a device is good enough and get that to your customers in six months instead of three years and the NRE is $100,000 instead of $6 million. If it really takes off, then we’ll go and make the ASIC and we’ll make that single, advanced node part. If you think about the need to have a derivative, there are really two vectors to go down. One is the die-level, advanced-packaging approach. The second is to simply modify the RTL and re-tape out a version of the chip which is kind of ‘close enough.’”

A third option, of course, is to never make a chip and simply go to an FPGA.

Outsourcing grows, but not because of cost
No matter which approach is used, outsourced teams play larger roles than in the past. “A lot of global companies have that mantra of you build one design in one location and then you ship it somewhere else for derivatives,” said Michal Siwinski, group director of product marketing in the system and software realization group at Cadence. “I’m seeing at least in the leading companies something a little bit different. The geo teams are not just being treated as a cost reduction. Rather, due to the sheer complexity of what it takes to build these massive SoC platforms, you basically have these globalized teams that might take a lead on a specific derivative.”

In general, the big savings that made headlines a decade agp by outsourcing to lower-cost labor areas are no longer an option.

“Due to the complexity of re-integration, I’m not seeing that so much now,” Siwinski said. “A whole product line with its derivatives might be led by one geography versus the other, but in general the complexity of doing that derivative and the time and cost are at this point so prohibitive on their own. If you consider that a new design is $150 million, and the derivative might be $100 million, that’s still not cheap. So it’s not about notions of having lower cost to the derivatives. Rather it’s utilizing a global workforce where a lot of that expertise needs to be built in all the geographies.”

Architectural decisions drive derivatives
With all of this complexity, there is a lot more up-front work required to define what the platform is and what new market segments it can serve, in addition to the main business unit’s market. “There’s more coordination within the corporation and more cooks in the kitchen up front,” said Kurt Shuler, vice president of marketing at Arteris. “That takes a long time and there’s a lot of coordination of the different groups, because what happens is when that platform goes from one business unit to another business unit, the IP that that second business unit uses may be totally different than what the guys who created the platform for.”

Jon McDonald, a technical marketer at Mentor Graphics noted, “When you think about outsourcing, it all comes back to understanding what needs to be done. The traditional approach when people just started RTL design was that it was easy when a group is all in one location. If you have a design group and they’re all together, they have meetings daily or weekly. Everybody is talking and you communicate a lot of things informally. When you go to outsource something you’ve got to have a contract. And it’s not just a business contract. There’s got to be a development contract. If that development contract is not very specific and very rigorous, there are opportunities for miscommunication, there are opportunities for something to be delivered that doesn’t satisfy the need.”

To combat this, in many situations the delivery contract is an executable transaction level model, which is completely unambiguous and allows each party to say, “This is what I need: this is the performance I need. You need to deliver a subsystem or part or whatever it is that does exactly what this does with this performance and this architecture,” he continued. “By putting a little bit more into the upfront specification/the upfront architecture, if you have an executable model for the upfront architecture and a prime [mil/aero contractor] hands that to a subcontractor, it makes the process so much easier because they know what it needs to do.”

By Ann Steffora Mutschler
From a planning perspective, creating derivative chips seems a straightforward task, but the process is much more complex than simply replacing or adding a peripheral—it starts with identifying the right team of engineers to perform that process.

“One of the needs in the market is somebody to have vertical expertise to do derivative design and yet be cost-effective,” observed Naveed Sherwani, co-founder, president and CEO of Open-Silicon. “Then, depending upon the vertical markets, you need to have many, many such derivative teams. A derivative team that can do router designs and switch fabric kinds of designs is not the one that can do a home gateway and is not the one that can do a WiFi chip and not the one which can do something else. You can pick your number—you can call it 15 or 30 verticals—and while there is some commonality between them, the front end of this may not be as common,”

As such, derivative teams must be very good at looking at somebody else’s design and making changes to that design. Specifically, the derivative team must be able to quickly pick up the architecture of the chip and understand the changes requested.

“Sometimes people say it is a derivative, but really it’s a brand new chip,” he pointed out. “Other times it is a true derivative—one that does not touch or alter the architecture of the chip in any significant way, does not change the data flow of the chip in any significant way, and which also doesn’t require you to re-time the whole circuit. As long as it is removing some IP, changing the number of ports, adding some functionality, that doesn’t change the architecture and the dataflow of the chip. Those are true derivatives.”

Another challenge that derivative teams face concerns how much data knowledge can be captured from the original team and how much of the original team is available to consult with the derivative team. In some cases the original team is very accessible, which makes it much easier. In other cases it is not.

“If the design team doing the derivative wasn’t involved in the original design, they do not necessarily understand the details of the formula that made that chip work (the so-called recipe),” said Mike Gianfagna, vice president of marketing at Atrenta. “That includes things like difficult-to-route areas, timing constraints, false paths, and placement restrictions for performance-sensitive digital blocks or analog modules. So you need a solid methodology for the original design that contemplates the outsourcing of the derivative. If you approach it that way, you can capture all the implementation recipe details as meta-data for the design which can then be part of the handoff. Capturing this meta data starts at the architectural level. This approach helps a lot.”

Further, truly understanding market needs and demands is critical. Drew Wingard, CTO of Sonics, said he has observed lots of people struggling to understanding that some of the interesting markets for SoCs—mobile phones, TVs, set-top boxes, tablets, automotive infotainment and telematics—change really fast. “So the idea that you’ve got the right smarts in your platform so that you can cover a couple of years’ worth of derivatives without changing any of your base assumptions has gotten increasingly difficult.”

Also, he noted that it is not uncommon to see a proposed derivative program get canceled in the first couple months. Once it gets to a certain critical mass, it seems more likely that it will continue through to the end. “We do see a lot of derivative-oriented design starts pop up and get started, and either the targeted end customer goes away or the speed with which the team is able to roll onto this derivative from that other program, which would have been the platform design or one of their other derivatives—happens a little too late. Suddenly that market window looks like it’s not as wide open as it was before.”

There may even be a loss of competitive capability when doing derivatives. Atrenta’s Gianfagna noted that doing a design from scratch will always yield the best fit for a given set of product requirements. Using the derivative approach will necessarily involve compromises, but as software becomes a larger and larger part of the system’s value, this downside decreases, he concluded.

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.

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 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 Ann Steffora Mutschler
Model-driven design is coming into its own, in part because the old way of using models at advanced nodes doesn’t always produce usable chips and in part because of the need for making tradeoffs at the earliest stages of the design process.

The concept of developing models for IC design is hardly a new one, and it is being done today on a number of levels ranging from transactions in TLM 2.0 to power and software. Historically, though, it has been done at a very high, purely functional level, often for algorithmic verification. These models have enabled engineers to verify if a data stream or data object could be manipulated, and once the function was verified the model was disregarded. From there, little executable performance information was recovered.

More recently, engineering teams have begun to recognize those models can used and flowed down into the rest of the design process to help make architectural tradeoffs. A lot of engineering teams are running into problems in that their designs do what they are supposed to do, but they are not successful because they miss the performance, observed Jon McDonald, technical marketing engineer for the design and creation business unit at Mentor Graphics. “Those performance issues could be timing and power-related; often it’s both and it’s a tradeoff between the two.”

More and more, he said, engineering teams want to take the architectural models that they’re getting at the very high level to define what the system is, how they’re going to do manipulations and break that down to the level of an architectural refinement where they decide what should be implemented in software, what should be implemented in hardware, how fast it needs to be and how many processing engines are needed. These are questions around implementation choices that need to be made before implementation because once teams start writing RTL it’s much more difficult to make a change.

Tom De Schutter, senior product marketing manager at Synopsys, noted that years ago everybody was hoping those models would also be synthesizable and that they would be a starting point for the IP components. So rather than just creating a model for a specific use case and then ‘throwing it out,’ there would be an implementation path. “That just doesn’t seem to be a reality. There are high-level synthesis tools, but it’s a very specific type of model, not what you need for these type of use cases.”

One item coming more to the forefront, he explained, is that although the model is not synthesizable into a piece of IP it actually can provide a lot of value as a reference to create the IP and to create the testbench before the IP is available. More and more IP vendors are now doing a model-first approach. They create a SystemC model, they verify the functionality of the model, create the testbench around it, potentially also create software stacks, and so on based on the model. Doing that provides more debug ability. They can then re-use that model to develop and verify the actual IP model.

While there is no automated path, the goal is still to reduce the effort for IP development significantly by doing a model first. Varying results are seen based on whether engineering teams consistently develop the models or whether they just try one model.

“It’s really something that by just doing one model you can’t really prove or disprove that methodology works. ST is probably the best example of a company that’s really adopted this methodology and has a lot of documentation out there. Some IP vendors have done this, as well, and they’ve seen good results. But it’s really something that you completely adopt and go for it, or if you kind of step into it and assume that it won’t work then you can easily prove that it doesn’t. It’s like with all statistics, depending on the mindset and how you ask questions there’s always a way to prove or disprove certain assumptions,” De Schutter added.

Interestingly, what often today is called model-based design refers to these things that have UML models or MathWorks models, which are independent of hardware and software implementation, said Frank Schirrmeister, group director for product marketing of the system development suite at Cadence. “What you have there is the trend continuing and getting stronger that on the pure software side linking into to the software development piece you have these things like UML and MDA (model-driven architecture) and so forth, which you find in the OMG (Object Modeling Group) where UML sits. That’s progressing and there are certain application domains, which seem to be more sensitive to it.

The linkage to the hardware side is finding more interest, he said, with smaller companies linking UML type models to SystemC, which leads naturally into the hardware world. “That’s happening and it’s progressing, but it’s in the very early stage of adoption. It’s definitely pre-chasm and not something that you will find broad adoption next year,” he said.

Integrating IP into models
When it comes to integrating IP into models, a robust model based on standards is needed. “We’re seeing a lot of customers who invested significantly in SystemC and TLM 2.0 as the standard level of abstraction at which you can create a fairly abstract model of a piece of IP for your system. You can still define timing and power characteristics around that piece of IP, so you can do what-if analysis. If you take in a third-party piece of IP—and quite a few third parties are starting to offer SystemC models and TLM models of their IP—you can take that IP, plug it into your system, start exercising that IP in various ways, and see how it interacts with the rest of your system,” Mentor’s McDonald said.

By having those robust standards and having models that are developed and interoperable between the companies supplying the IP and their customers consuming the IP, there is now the opportunity to really make detailed tradeoffs before committing to the implementation. It is likely too that System C will need to be extended over time to address some of the outstanding technical barriers.

From the user perspective, Mike Berry, senior director of engineering at Open-Silicon, explained that in terms of integrating IP into models, “We would look for either vendor-provided models of the IP to put into a bigger environment or go off and build those models ourselves if they are not available. Many designs today obviously use a lot of off-the-shelf IP in conjunction with some amount of custom designed logic—the customer’s secret sauce so to speak. Where IP can play a role in the modeling approach is that you can build up a model of a chip or a system using the models of the individual IP blocks and then use those off-the-shelf again to develop a standardized or non-custom part of the total model environment. You can adjust focus on developing custom models for the pieces that aren’t available off the shelf so, much like with hardware design, they can help expedite things and reduce the load on the design team. The same can be said for the modeling environment. You don’t have to develop all those models yourself you can take advantage of existing models for standard IP.”

By Ed Sperling
The tradeoffs between performance, power and area are being fine-tuned to a degree never seen before in the IC business, driven partly by complexity, partly by better tools, and partly by the need to gain a competitive edge in specific applications.

Just being able to make these kinds of tradeoffs is a technological feat that marries everything from high-level modeling and synthesis to prototypes of hardware and software and better characterization of IP. But being able to use the data from these tools more effectively is changing what can be done in design.

“This is going to be a way of life going forward,” said Jack Harding, president and CEO of eSilicon. “If you look at the number of variations between process nodes, types of IP and voltage, no human can sort through all the permutations anymore and come up with an optimal design, and certainly not around PPA.”

This is particularly true at 28nm, where power, performance and area are not linear extensions from previous nodes. And in stacked die, where multiple generations of technology at different voltages are packaged together, those tradeoffs may be greater still.

“The fact is that we may not know the best combinations anymore because there are too many things to consider,” said Harding. “I’m convinced this is a permanent change, too. I liken it to place and route in the early 1990s, where it was used to help smart guys design chips. By the late 1990s that had to be automated in all chips because the gate count was too high. We’re now approaching tool-assisted SoC architectures.”

Cause and effect
At least part of what’s behind this shift is market demand for more customized solutions. The move to subsystems and off-the-shelf IP means that companies have to find a way to differentiate their chips, something that will become even more apparent as the industry begins shifting to 2.5D and 3D stacks over the next couple years. Even the software might not be enough to differentiate the product in some markets, such as Android phones.

“The stakes are higher and the tools are better,” said Wally Rhines, chairman and CEO of Mentor Graphics. “Now a microwatt matters. It can be the difference in a win or a loss.”

The same is true of area and performance. But the new wrinkle is those variables almost need to be tweaked for each customer. Naveed Sherwani, president and CEO of Open-Silicon, said that for some of the large search engine, cloud computing and social media companies, the emphasis is on performance at any cost. This is contrary to the direction of most data centers, where power has become the major focus due the cost of running and cooling racks upon racks of servers.

“The reason PPA is changing is because now we can change it,” Sherwani said. “There are a lot more tools that can play with more things that affect power, performance, area and cost. We’re heading toward a very platform-style approach to design, so the changes from one customer to another may be only about 20%. With 3D stacking and memory, the next few years should be very interesting.”

Why now?
As with all significant changes in the IC business, there is no single factor that is responsible. The push to advanced nodes has added more complexity to designs, starting with more transistors (with 3D transistor designs at 14nm), more leakage, more features that require more complex power management, more IP re-use, a larger software component that needs to be written more quickly and with energy efficiency in mind. On top of that there are better tools for making these kinds of tradeoffs, and all of the big EDA companies are working on better analysis of the data that can be added into major flows.

Still, getting sufficiently good data to make these kinds of tradeoffs isn’t easy—even with better tools.

“PPA perplexes everyone,” said Bernard Murphy, chief technology officer at Atrenta. “The time to do PPA tradeoffs is early on, but the challenge is that there are a lot of unknowns at that time. There is recognition that if you can’t solve the big problem you can break it into smaller pieces, and these days not all of the design is unknown.”

He noted that Atrenta has been examining the effect of bus fabrics on the whole PPA equation. He said the direct influence on power is less, but they do contribute heavily to idle mode power, something that will become particularly apparent once wide I/O becomes mainstream.

“One of the reasons the NoC (network-on-chip) exists in the first place, and why ARM is looking at pseudo-NoCs is to control congestion,” he said. “The bus fabrics are only getting more complicated, and there is very little expertise in detailed performance analysis.”

Education is critical across the board in PPA. Teams of software engineers working with hardware engineers on designs alongside groups that are focused on manufacturability have expanded the scope of many design engineers. To some extent, everyone will have to think like a systems engineer in the future, even if they have their own area of expertise. But the very fact that they are talking to other team members is eliminating some of the silo behavior that various teams have lived with for the past couple of decades.

The future
While PPA has always been a way to spin cost, increasingly it also is seen as a way to improve time to market. Stacked die, and re-use of IP, subsystems and even entire platforms and die, will alter this equation even more—and add far more options for trading off power, performance and area.’

Those tradeoffs already are being done on a localized basis, with one IP block versus another or one processor core or multiple cores versus one or more other cores. In the future, it could include entire chips, as well, which may be customized quickly for individual markets or customers.

These changes also are likely to bring shifts within the supply chain. How the pieces will be reassembled is unknown at this point, but most experts agree that more change is inevitable.

By Ed Sperling
It was a good week for emulation. Mentor Graphics joined forces with MoreThanIP to create emulation solutions for multi-gigabit Ethernet SoCs.  Mentor also won a deal from ZTE for its Veloce emulator, and it added emulation solutions for USB 3.0 products.

Cadence and Samsung have developed a 32nm HD digital camera SoC for Ambarella, which has been creating digital still cameras with high-definition video capabilities. Translation: lots and lots of pixels. Cadence also teamed up with Xilinx for system design, software development and testing of Xilinx’s Zynq platform. And Cadence announced its quarterly numbers, showing net income of $28.1 million for the quarter ended Oct. 1 ($37.3 million non-GAAP) vs. $126.8 million in the same period in 2010 ($11.2 million non-GAAP). Revenue for the quarter was $292 million vs. $238 million in 2010.

eSilicon inked a deal to use Synopsys’ Custom IC design solution for 28nm SoCs. And Synopsys’ DesignWare Audio IP achieved first-pass silicon for 65nm and 55nm process technologies from multiple foundries.

Open-Silicon launched an ARM Center of Excellence to provide complete SoC development solutions for low-power chip development for the networking, telecommunications storage and computing markets. This is becoming a very cozy relationship. Open-Silicon already has a multi-year licensing agreement in place with ARM.

Atrenta introduced early PPA analysis for ARM’s AMBA designer using its SpyGlass and GenSys products.  Atrenta also joined Cadence’s System Realization Alliance, which is no surprise considering it was one of the first to adopt Cadence’s EDA360 terminology.

Arteris won a deal from VIA Telecom for its high-speed inter-chip communications IP between mobile phone baseband chips and application processors.

Tensilica won a deal from EnVerv, which licensed Tensilica’s ConnX DSP cores for its smart grid power line communications SoCs.

By Ann Steffora Mutschler
By and large most designs today are derivatives, meaning they don’t start from a blank slate. And while that gives engineering teams a starting point, it also can make adding new IP blocks or changes to the design problematic, with the potential for increased routing and timing issues along with considerable pain to back-end engineers and delays in chip schedules.

Derivatives can be split into a number of categories, depending on the market or the evolution of technology at any point in time.

“Let’s say in a chip there is a certain amount of embedded memory and they want to remove it,” said Kalar Rajendiran, senior director of marketing at eSilicon. “Maybe the memory block they had was not efficiently implemented and it was taking too much space, so they only put in 1 megabyte. They release a product and then they may say they want to do a derivative product to increase memory capacity to run more programs. That’s a simple change conceptually–add more memory to it–and you would call that a derivative design because it is slightly different from the previous one.”

Other types of derivatives can involve changing the interface or functionality, regional adjustments to support different temperature conditions, or variants in terms of geography that would support differences in TV broadcast compliance, for example.

Neil Hand, group director of marketing for Cadence’s SoC realization group, observed that the definition of a derivative design has fundamentally shifted over the last couple of years. In the past, an engineering team could sit down, design a chip and develop five derivatives of it for each different market by swapping out the IP blocks and tweaking the system for each of those markets.

“That definition of derivative is dead because you can’t afford to do it,” Hand said. “If you look at how people approach it today, they use more of a platform. They put all of the IP they need for all the different applications on the design and then they’ll package it appropriately, depending on the target market, or will turn things on and off in software or hardware in order to make it fit that application. A good example of that is if you look at what Apple does with the A4 and the A5. It’s one design that targets multiple devices, whereas in the past that would have been multiple different chips.”

The stakes get higher along with Moore’s Law, too.

“With 40 and 28nm nodes, these are getting to be quite expensive from an SoC development perspective,” said Navraj Nandra, senior director of marketing for DesignWare Analog and MSIP at Synopsys. “What we are seeing at 28nm especially with our customers is they are developing an SoC but you can almost consider it an application platform and it is designed for a couple of market segments. The two big ones are smart phones and tablets.”

The methodology from an SoC perspective and the IP requirements to address those applications are similar but not exactly the same. “In order to ship the products out quickly to market and because the typical development cost of a 28nm SoC is at least $100 million now, if you want to get one of these chips out to market you’re going to have to invest at least $100 million—and that’s just on the SoC side. You’ve got way more costs on developing the software on top of that. So the expenditure is significant,” he continued.

Power consumption is often addressed in derivative designs. When the initial excitement about a product has gone away, customers want more battery life. Derivatives can focus on reducing power consumption, which in turn can have an effect on how you put your SoC design methodology together and how you develop the IP, Nandra said.

A recent customer visit illustrated this perfectly. “I was in Korea a couple of weeks ago and met with a company that develops TVs. I met the design team, and this particular design team develops the chipsets for the high-end TVs. Their SoC had all the latest IP requirements. The technology was designed with a very fast data path to do a lot of number crunching. This team now is looking at getting into the low-cost digital TV market, so they want to build a derivative chip that needs to have similar functionality to the high-end chip but that needs to be cheaper,” he added.

Managing complexity
As design platforms get bigger, and engineering teams must dealing with more IP blocks, the story really becomes about how to manage these huge IP platforms talking to each other, said Cadence’s Hand. “In the old days it was one monolithic design—easy to manage, no real problems, and it was a relatively small die. Then you got to the first realm of where we are today where you had tens of IP blocks and you could use relatively simple interconnects and the dies were relatively small. Now you look at the modern designs and every thing about them has become big.”

As a result, a holistic view must be taken of what it means to throw these connections together. “You can’t do necessarily what’s easiest for the system guys to the exclusion of the IP and the silicon. You can’t just do what makes the silicon guys happy because that may mess up your system performance. And you have to have that holistic view of cross all the realizations: silicon, SoC and system,” Hand added.

One of the most important considerations of starting with a baseline product with the intention to expand it in the future is time to market. Getting the chip out there, winning sockets and getting it into the customer’s hands so they can start working with it is critical.

“In some cases you can imagine going into a program development and at the beginning having very good intentions about designing in features, designing in configurability, parameterization, things like that to enable those future expansions to happen,” said Mike Berry, senior director of engineering at Open-Silicon. “But sometimes you can end up making tradeoffs as you go through the design flow. You may be losing some of that or not making it quite as robust as was originally envisioned by the product marketing guys or the architects of the program. Then, when you go to do that next version there could be some things you have to deal with, some warts that may, if they had been implemented in a slightly different way, have made the expansion a little bit easier. So you might have to go back and do some rework, either within the RTL or within the test environment to effectively roll in those new features.”

Sometimes however, the biggest challenges that come up with derivatives are not related to the technology but rather, the market.

“The bigger problem they run into is a market problem,” said Bernard Murphy, CTO of Atrenta. “So you build the super chip in anticipation that you’ll be able to do the low-cost version and the low-power version and the future phone version and then you find the super chip wasn’t that much of a home run so the derivatives become irrelevant. But that is not a design problem. I had somebody at one company tell me that happens 9 times out of 10. But how many home runs do you really see?”

Planning ahead
When an engineering team knows they will be doing derivatives, it makes sense to plan ahead to make it simpler to make the changes down the road….but do they?

“Yes and no,” said Kurt Shuler, VP of marketing at Arteris. “When they draw that block diagram and they create their internal roadmap slides and they have a block diagram of a chip and the derivatives, they have it tied together with a bunch of lines on the chart. You think that anything is going to be fine. But depending on the interconnect technology you use, each time you create one of those derivative chips can almost be like creating a whole new chip, and the reason is because of the back-end problems. To the SoC architect who is creating drawings of stuff, then the chip designers and the chip engineers are creating RTL, that then gets synthesized down into gates and eventually gets placed on the chip.”

Things don’t usually work out that smoothly, however.

“There is a disconnect between the architect’s drawing of a nice, clean, pretty picture of the chip, and nice, clean, pretty RTL and then when you go and try to design it in a chip, it looks like hell–you have all kinds of timing problems and what have you and you have to futz with it forever,” Shuler continued. “That is the biggest issue. A lot of companies say they are doing ‘the platform approach’ and are creating all these derivatives based off of this thing but are not seeing the benefits they expect. When you talk to the back-end people you find out the derivatives can take as long as the original chip did. That should be a red flag. If you don’t look at the platform holistically you’re going to be disappointed.”