By Ed Sperling
Mentor’s Dennis Brophy looks back on the life of the man who first pulled him into the standards world, Don Loughry. It’s a good story and a great eulogy to one of the stars of the standards effort.

Cadence’s Richard Goering examines an all-too-common phenomenon in testing a chip—exploding it. Testing a chip with everything on is a lot different than testing it with the normal functional power. Make sure you check out the photo.

Synopsys’ Navraj Nandra looks at non-volatile memory and why it’s important for smartphones with near-field communications. When you swipe your phone, speed and battery life are critical.

How many TVs can U.S. households hold? Apparently not as many as TV makers would like. IHS iSuppli’s Lisa Hatamiya predicts flat panel shipments will fall for the first time ever this year.

Mentor’s Michael Ford compares the taming of young music students to orchestrating of the chip manufacturing process. Just imagine if Toscanini had been in charge of a 28nm fab.

Cadence’s Adam Sherer digs into verification of power-aware designs and why they should be running low power in every regression test.

In case you’ve wondered where you can augment your verification skills for AMS, Synopsys’ Helene Thibieroz details who’s teaching this summer at UC Santa Cruz. Bring your surfboard.

Mentor’s Mike Jensen rolls out Part 5 of his analog modeling epic, this one focusing on implementation of equations using VHDL-AMS.

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

–Mentor’s Jon McDonald sheds light on cycle-accurate models and why they’re not always necessary or even good.

–Synopsys’ Achim Nohl shares some insights about virtualization and ARM’s big.LITTLE processor.

–Cadence’s Frank Schirrmeister steps back and assesses how many of ESL’s core pieces have moved beyond the early adopter phase.

–Sonics’ Frank Ferro asserts that speed is still the crucial requirement for all SoCs. Damn the torpedoes, full speed ahead.

–Arteris’ Kurt Shuler looks ahead to the coming shakeout in the design industry and who’s going to be affected.

–Atrenta’s Mike Gianfagna compares SoC development to an old video game with much higher stakes.

–eSilicon’s Javier DeLaCruz looks at which companies will be the drivers of TSV packaging.

–Methodics’ Simon Butler expounds on the continuous build approach and why it’s necessary to take SoC design out of the Dark Ages.

By Ed Sperling
The monolithic ASIC, which has been the bread-and-butter of chipmakers for decades, is giving way to systems on a chip among mainstream chipmakers and at mainstream process nodes.

This shift has been overhyped, overpromised and slow to materialize. While SoCs have been common for years in mobile electronics and for high-performance platforms such as gaming consoles, they have always been more expensive to design and manufacture. But at 40nm and beyond—and increasingly even at 65nm and 90nm—physics, an increasing amount of software and the inclusion of more third-party IP are forcing changes in best practices for designing chips. And as the industry heads into 2.5D stacking over the next couple years, subsystems that can be part of systems in package will add even great emphasis, as well as some new wrinkles, to the shift.

“It’s happening now and it will continue to happen,” said Tom Lantsch, executive vice president of corporate development at ARM. “We’re seeing application processors that are heterogeneous multicore on the same chip with graphics engines and video engines and they’re now running Symbian instructions. A lot of this shift is based on power. There’s a realization that you can do things other ways more efficiently.”

So what exactly is the difference between an SoC and an ASIC? The common definition is that an SoC includes one or more processors plus software and peripherals, making it a complete system rather than a ASIC, which is suited for a very specific task.

“The ASIC customer used to be the system house,” said Hans Bouwmeester, director of IP at Open-Silicon. “But now the system houses and fabless semiconductor companies are focusing on horizon tasks. It’s not divided by front end and back end anymore. It’s horizontal and vertical, which is re-use or availability of IP and competence. If you look at ARM’s chips, they’re applicable across multiple domains and customers are willing to outsource that development to them.”

This shift hasn’t been lost on Open-Silicon or eSilicon, both of which are shifting from an ASIC to an SoC approach. And both say the SoC world will explode once the once the industry begins adopting 2.5D stacking over the next couple years—a move that also may include more emphasis on FPGA platforms as part of the 2.5D stack.

Partition issues
At least part of what an SoC brings to the design table is flexibility. There is an ability to try different things, and at each new process node more room to experiment. But silicon is never free, even if it is available. Shrinking feature sizes creates its own set of problems at each new process node.

The typical method of deal with these problems is a “divide and conquer” approach. If there are 500 blocks, those blocks can be aggregated according to function, shared resources, or some other scheme. But in an SoC, finding the right line on which to base that partitioning is more difficult. Even worse, it can change, depending upon which market a chip will serve.

“If you do a flat design you always get the best quality,” said Sudhaker Jilla, product marketing director at Mentor Graphics. “But as the chip grows the runtime becomes unbearable. It can go from hours to more than a week. The alternative is to use a hierarchical approach, but then you have a problem of performance. You want the turnaround time of a hierarchical flow, but the quality of a flat one.”

The reality is both are needed for SoCs, but that also means a significant learning curve for the design teams. They need to learn new tools, figure out how to partition their designs—whether it’s by blocks, geography, or IP.

“The key is that companies need to figure out how to divide and conquer,” said Jilla. “Will it be dual-core or quad-core? Or will it be multiple different cores?”

More tools, more IP
For EDA and IP vendors, this is only good news. Selling to the biggest chipmakers has always been lucrative, but continuing to sell to those same customers while also adding incremental business is a big win. FPGA tools have been sufficient, for example, to do basic layout and verification, but put that same FPGA into an SoC or a stacked die configuration, add software and third-party IP, and then try to integrate it all together and the complexity easily outpaces what the typical FPGA tool can do.

“The biggest trend is that people are spending 35% to 40% of their effort writing software,” said John Koeter, vice president of marketing for Synopsys’ solutions group. “When you get down to 28nm or 20nm, companies are spending more than 50% of the time to market developing software. If you look at an SoC today, it’s usually two to four host CPUs, two to four GPUs, and it’s increasingly heterogeneous.”

He said that opens up huge opportunities for linking software to hardware, and virtualizing the hardware and software. It also opens up opportunities for IP, tools to help integrate that IP, exploratory tools that can show the tradeoffs at the architectural stage, and a suite of verification tools and verification IP.

“Just from a verification standpoint you’ve got to tackle this at several levels,” said Pete Heller, senior product line manager at Cadence. “You’ve got to look at it from the subsystem and block level for functional reasons. And you’ve got to look at the full SoC and pump real data through the system so you can get as much real-life validation as you can. Then there’s a third level, which is to put it into the hands of 100,000 people and let them be the guinea pigs after you’ve already worked out all the bugs you can.”

What is a subsystem?
That leads to the next phase of this whole development scheme—fully integrated and tested subsystems, which are expected to begin hitting the market over the next year in preparation of more SoCs and 2.5D stacked die.

“If you look back 10 years when Gartner was tracking design starts, in 2000 there were about 20,000 chip designs a year,” said Drew Wingard, CTO at Sonics. “Now we’re seeing more SoCs because you have processors sprinkled around the chip that may or may not even show up in the bill of materials and that you may or may not have access to.”

Increasingly, those pieces will be combined into fully integrated systems that include IP, possibly processors, and perhaps even shared resources such as memory with standardized interfaces. That approach will become particularly useful when chips can be stacked, either in 2.5D or 3D, and it will completely render the number of design starts meaningless. There will be more design starts, but the final outcome may be subsystems rather than chips—or chips that are part of a stack rather than the fully integrated stack itself.

“A general-purpose processor may not be the most efficient way to accomplish a task,” said Wingard. “This has led to a huge discussion around subsystems. Not everyone believes each function needs a processor. But how independent is a subsystem going to be? You can quickly get into a situation where you have enough performance most of the time, but there may be specific and critical sequences where you don’t have enough.”

There has been a lot of talk about subsystems across the industry lately, and companies are positioning themselves to take advantage of this shift. But the challenges of making this all work are huge.

“This is similar to the challenge embedded companies have faced for a long time,” said Simon Butler, CEO of Methodics. “It’s one thing if you’re dealing with a homogeneous environment where the tools talk together. But when you have to bring all these different pieces together and make sure all the parts are aligned, it’s going to be very difficult.”

Past, present and future
Still, the road to SoCs has been set and it’s gaining momentum. That became very obvious at the Consumer Electronics Show over the past couple of years.

“What’s changed is the user experience is now a combination of hardware and software,” said Mike Gianfagna, vice president of marketing at Atrenta. “We’re seeing the consumerization of electronics. The idea isn’t new. Joe Costello was talking about this a decade ago. But it’s finally happening. The semiconductor content is enabling the user experience.”

That will only increase as future designs allow more choices of IP, software, processors and ultimately subsystems on a chip—and more intelligent tradeoffs to make it all work faster and cheaper while using less energy.

By Ann Steffora Mutschler
Engineering teams across the globe continue to pound the process geometry treadmill to stay on the curve of Dr. Moore to achieve better speed or lower power or smaller die—and it all adds up to increased complexity in the design and packaging. However, with advanced forms of die stacking such as package-on-package, silicon-in-package, 2.5D silicon interposer technology and other techniques, engineering teams now have more degrees of freedom around how chips are constructed.

A significant consideration in moving from one process generation to the next is that there are many IP functions that must migrate. “Sometimes it’s too expensive to port it from one generation to the other and you may not need it as far as the speed or as far as the power,” noted Shafy Eltoukhy, vice president of manufacturing operations for Open-Silicon.

This is where advanced die stacking comes into play. The engineering team may consider going to 28nm for one particular aspect of the function—for example, to get a better speed in the ARM processor—while there are a lot of other interfaces for a particular die that may not have to be in that advanced process node. A USB 2.0 or 3.0 does not have to be in 28nm to achieve the requirements—it could be in 90nm or 40nm, he said.

“The whole notion of re-using IP is common, though something not as commonly discussed is the reusability of die. What we’ve been seeing a fair amount of is companies saying, ‘I’m going to use advanced packaging techniques that are available today and I’m going to take this older generation die that I’ve got sitting on the shelf. And I’m going to make a much smaller new chip to complete it or extend it or interface to it. And I’m going to put that all into a multi-chip module, or advanced packaging structure, and circle back and use a lot of the IP that is in actual hardware form and make that available.’ It’s not mainstream, but reusing IP 15 years ago wasn’t mainstream either,” said Jack Harding, president and CEO of eSilicon.

Engineering teams tend to have a certain function they really want to squeeze and go to the next generation, but there are a lot of other functions in the design that don’t have to be in the latest generation, Eltoukhy observed. In advanced SoCs, customers are paying first and foremost for the IP development. “You are paying more dollar-wise per silicon area for a function that does not have to be in 28nm.”

What process node makes sense
Naturally this leads to a discussion about not bringing every single function into the next generation, especially because some analog and RF functions do not scale very well. So why not stay in the previous generation and partition the design in order to leverage older technology where available and not re-invent it?

“What I have to do instead is some kind of interface between this technology and the new technology. I put only the function that I want in the technology that can handle it and leave the other somewhere else,” he noted.

The question then becomes how to connect these together. “You certainly can connect them on the package level, which people used to call MCM (multi-chip module). You can actually get multiple die and bolt them in the substrate of the package and connect them. But the package technology has been way, way behind compared to the silicon technology, and you may end up with much higher power and slow interfaces and so on,” Eltoukhy explained. This has led to the development of silicon interposer technology in order to replace the substrate interconnect or the package interconnect, which is commonly known as 2.5D stacking.

Essentially, silicon interposer technology connects one die to another instead of connecting to a package, thereby reducing power and improving speed. Xilinx already has made its version of 2.5D-stacked technology available with certain product families.

Another use of 2.5D would be in a processor design that needs to talk to a DRAM, he continued. “Most people have a DDR interface and you go through the board to interface with the memory. But this approach is slow and large. Instead of buying a DRAM package from a DRAM vendor, we ask the vendor to sell us a known good die, which can be attached with processors on an interposer so you don’t have to go outside the chip. The DRAM can talk to the processor right away and the form factor will be much, much smaller. So there are multiple applications for that interposer—mixing the process nodes so that you can reduce the cost and so on, and improving the yield or bringing up some known good die from the DRAM to your die.”

“The application processors, which are really only delivered with package-on-package memory, end up with a very easy knob in that system—they can pile on different amounts of DRAM. To them it’s almost the same design and it is the same software. A couple of bits different in the software and suddenly they’ve got a new derivative part,” said Drew Wingard, CTO of Sonics.

“In many cases the die itself has more package attachment or wire bonding sites than the package may have pins, so you may take the same die and put it into a different package with different amounts of I/O resources available, and then sell those chips—even though they are the same fundamental chip design—at different price points. That’s been going on for a long, long time but with some of the more advanced packaging technologies, there are new degrees of freedom there,” he added.

While sounding tantalizing, all of these options are still under development. Complicating widespread deployment are two factions in the industry at odds as to the right path forward. On one side are the semiconductor foundries, which would like to enable customers to use a transposer because, at the end of the day, they want to sell more dies to put on the interposer, Eltoukhy explained. “They say, ‘We can give you the interposer but you buy the dies from us and we can glue it together for you.’”

In another camp are packaging providers such as Amkor and ASE that fear losing business to the foundries and would also like to offer the interposer to their customers so they won’t go and do the interposer with their foundry. “These two camps are fighting now because it requires some investment from a capex point of view,” he added.

Managing complexity, saving dollars
In addition to dealing with complexity, advanced die stacking techniques can save big dollars, eSilicon’s Harding asserted. “You could measure it just in terms of NRE dollars, you could measure it in engineer years of work, you could measure it in terms of time to revenue. By any metric, going down the advanced-package, multi-die solution is better by two orders of magnitude than just actually making a new chip, and I would argue it’s probably better by one order of magnitude by just doing RTL modification, which still has high NRE and a lot of technical risk, albeit you have a product that is closer to being the final product. These decisions are classic risk-reward.”

By Ed Sperling
Synopsys is working with Applied Materials on TCAD models for 14nm and 11nm logic and memory chips. The collaboration covers front-end-of-line to back-end-of-line reliability. The two companies previously collaborated on of projects, including TSV development for stacked die. Synopsys also has been working with Global Unichip to enable 30 tapeouts ranging from 130nm to 40nm.

eSilicon added Korea to its TSMC value chain aggregator program. Given the fact that Korea’s electronics market is booming—witness Sony’s downplaying of its digital TV future and Samsung’s growth in a variety of sectors—being able to pull together the right components and IP for OEMs there and to create designs is a significant opportunity.

Methodics integrated its VersIC platform with Synopsys’ Galaxy platform, allowing engineering teams to manage design data and IP within Synopsys’ design flow. This is particularly useful in complex designs, which increasingly rely on third-party and re-use of internally developed IP, and where libraries are now measured in terabytes.

By Ed Sperling
Ever since verification IP was introduced it was seen as something that should be given away with purchased IP. The result was limited investment by IP vendors, frustration on the part of IP customers, and a market opportunity that nearly fizzled before it even began.

But as the amount of commercially developed IP content continues to grow in ICs, the potential interactions increase with neighboring IP blocks and tools, and time to market pressures continue to mount, the market for verification IP also is growing. The proof is in the amount of investment now being poured into this technology by the large IP vendors—most notably Synopsys, Cadence, Mentor Graphics and ARM.

“VIP is the hottest growth segment in verification,” said Michael Sanie, director of verification product marketing at Synopsys. “But after 10 years of patch over patch we’re starting to see multiple problems. One is performance. Three million lines of code is average for an SoC. The second is debug. You use VIP for that, but it’s still hard to find the bugs. And the third is that it takes up to four weeks to set up and integrate within a verification environment.”

The reality is that verification IP will never actually reduce the time spent in verification, which can run as high as 75% of the total NRE for an SoC. But done right, it can improve time to market and make chip companies more confident about stopping verification, which is always a judgment call.

Make, buy, or make do
Most of the commercially available has at least some verification IP bundled with it. That VIP is there to prove the IP works. But there’s a whole other level of VIP under development now that’s sold separately.

“If you get VIP with the IP, it’s very targeted or constrained,” said Jason Polychronopoulos, product manager for verification IP at Mentor Graphics. “To do the job properly, verification IP should reduce the verification effort. There are a few things you need to do that. One is that it needs to fit into the verification flow, which increasingly involves UVM. The second is that it needs to be complete. This is not just a question of driving a stimulus. It needs to do complete protocol checking and coverage. The third is that it needs to be part of an overall verification plan, which is executable and linked to results.”

The last part is where all three of the big EDA players see opportunity. Complexity in design is bad enough. But trying to add it into an existing automation flow is particularly difficult. And while many design flows are still a mix of proprietary and commercial tools, verification is weighted heavily toward the commercial side. As more third-party IP gets incorporated into designs, being able to verify it in the context of what interacts with that IP, as well as the context of how to test it all from a block, subsystem and even system level will become more critical. And while most companies were well aware of what was inside their own IP, most commercial IP is viewed as a black box. Taking the time to understand all of its intricate behavior is a luxury most design teams don’t have.

So while some chip developers may opt for the free VIP, the more commercial IP that is used the less sufficient those tools will become—even at mainstream process nodes. But that doesn’t mean there won’t be a lot of grumbling from the customer base.

“The whole problem is getting harder and harder,” said Simon Butler, CEO of Methodics. “At some point the consumers of IP will have to ante up. But there also will be a lot of pushback. They assume that if they buy IP it should just work, and companies are always on the verge of thinking, ‘Why not just develop the VIP ourselves?’ But there are so many problems and so many versions of IP they never do. Still, you’re going to hear questions about the value.”

He noted that ARM cores come with a verification suite to make sure no bugs are introduced and that timing remains intact. But when other things are jammed around that core problems can creep in. “In theory, this should all be plug and play. But the reality is you can’t come up with every corner case.”

Abstracting up and down
Another twist in current VIP usage is that it has to work with transaction-level models created with the TLM 2.0 standard, and it still has to link back down to problems that surface at the register transfer or gate levels.

“The VIP that’s out there today is based on Vera or e or C,” said Synopsys’ Sanie. “Over time it will need to be configured to work with VMM, OVM and UVM.”

This is no simple task, though. Sanie said the VIP for USB 3.0, for example, now is about 500,000 lines of code. There is an estimated 30 million lines of code in RTL and testbenches on an SoC. In comparison, Windows is only about 50 million lines of code.

But that’s also code that a company doesn’t have to generate itself. Just digesting the amount of information in standard interfaces such as PCI Express 3.0 involves thousands of pages of information. A smart phone may have 20 of those types of interfaces.

“Nobody can do more than one or two,” said Tom Hackett, senior product marketing manager at Cadence. “You must import expertise into the project. When you’re the IP creator the view is that you want to get the IP out the door and you limit what’s good enough for verification. On the verification side it’s different. You want to exhaustively test the IP. You want to verify the IP block you’re implementing works. But you also want to put it in the context of the rest of the chip. And then you need to integrate it with hardware and software and across the whole development flow. VIP has to play a role across the spectrum.”

He noted that if you’re generating the VIP yourself, you’re only learning from your own company’s past projects. VIP that is commercially developed incorporates knowledge from multiple customers.

Competitive advantage within
Not everyone wants to sell this kind of technology. eSilicon, for one, believes there is a competitive advantage in knowing what works best where and in being able to verify it internally for customers.

“We’ve invested quite heavily in these kinds of utilities and in capabilities to evaluate different IP,” said Jack Harding, eSilicon’s president and CEO. “This is comparable to how place and route tools progressed in the 1990s. At first, they were there to augment the smart engineer. Once it was automated, the engineers could oversee the process. IP is heading down a similar path for power, performance and area. We need to produce analytics that are the equivalent of place and route and run permutations of voltage versus temperature versus performance. The human brain can no longer process this many variations—and make sure it still works.”

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 Ed Sperling
Japan’s SoC market, which has been a big market for advanced EDA tools, may be headed for a major consolidation. Renesas, Fujitsu and Panasonic are in talks to combine portions of their business in conjunction with the Japanese government’s Innovation Network Corp., according to numerous news reports. One particularly interesting addition to these changes in Japan: GlobalFoundries may buy Elpida Memory’s Hiroshima fab. Whether all of these changes create a larger and much stronger market for tools and services, or whether it actually shrinks, is a big question mark.

Cadence is collaborating with Samsung for 32, 28 and 20nm DFM flows. Key to the deal are pattern classification and search, CMP prediction, and both litho and yield analysis.

Synopsys won a deal with CSR for its Galaxy implementation platform. CSR makes everything from low-energy Bluetooth chips to GPS ICs.

eSilicon expanded its SerDes licensing deal with Avago. Under the terms of the deal, eSilicon will be able to include Avago’s SerDes cores—from 28nm to 90nm—in chips for the communications and storage markets. http://www.esilicon.com/press-releases/195-esilicon-expands-serdes-ip-licensing-agreement-with-avago-technologies-

Methodics rolled out a new release of its IP version-control product, aka Subversion, boosting performance and improving the distributed use model. As IP use and re-use grows, keeping track of IP in complex designs is turning out

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: When it comes to derivative designs, there has been some emphasis on creating superchips up front where everything is included and you turn on and off certain parts, right?
Subramaniam: That’s one approach. Another is re-usable IP in a 3D form. You may have a processor, an RF subsystem, and then you have something else that is flexible and that changes. There are various ways of implementing this.
Varadarajan: How companies differentiate themselves is software. That’s what the end user sees. They don’t care if it’s a Mali graphics core or an Imagination Technologies core. On one hand it’s software, but for the software to get to the new user it’s a question of how quickly the company can adapt the new architectures and build these systems more predictably. That goes back to time to market. Clearly, in the area of derivative designs, the first version of the system is not the final version. It goes through multiple iterations and revisions. It’s a question of how can a company adapt the architectures and get new SoCs out in much shorter time frames. That’s a methodology issue. How can you build tools on them? How can you set up a predictable process where each rev does not take the same amount of time? You need to be able to re-use what you’ve already learned and get these designs out predictably.

SLD: Time to market is a big differentiator too, isn’t it?
Varadarajan: Absolutely.
McNamara: That’s a key one. But how do you get to the end consumer? A watch that can tell you your heart rate is worth a lot more than one that just tells you the time. But how much more? The silicon isn’t that much different. But if you have standard software like Android, that will only do what it does. You may have new capabilities but no one can use them. Your differentiation has to show in the standard software. For you to get your bit included in the standard software you have to have enough volume that the software makers care about you. They also have their time-to-market pressures.
Zorian: And that time to market can be divided into pieces. It’s not only the chip design that impacts it. After first silicon comes back, you have to ramp up very fast. We don’t pay attention to that second period. Between first silicon and ramp up time there is a window. To optimize that you have to build into your chip the necessary infrastructure to shrink that part later on. If you build all the necessary debug and diagnostic capabilities early on, that’s a very good investment to shrinking that second interval.
McNamara: And that gets much more important as SoCs get bigger and bigger. You can’t tell just running it where the problem is. You have to embed debugging.
Zorian: That’s why I see time to market as two components. One is from the design is finished to first silicon, and then from first silicon to yield. We spend lots of time developing tools for the first part, but not as much on the second part, which takes lots of optimization.

SLD: One thing that seems to be missing is getting standards to work together better, and tools to work together better from one vendor to another. What’s going on in terms of integrating all of this stuff?
Zorian: It’s always a tradeoff. While you like to have multiple vendors’ tools, having it all from one company has its advantages. Probably point tools are better for certain things. But if you want to get to market faster, a single vendor solution is better.
McNamara: It’s a lot like power-performance-area. It’s an optimization issue. A single-vendor flow is going to lock you in. If they raise the prices, you’re stuck with it. If they don’t have a tool that does good clock-tree insertion you’re stuck with that. However, if you’re buying a point tool from everyone then you have to be the integration team that deals with version 7 of this tool, which just came out and doesn’t work with version 13 of that tool. Plus, people don’t want one solution. They think two is better. If there’s one way of doing something they look for an alternative-even if the one that works is fine. You always look for another way to do something. When we, as an industry, try to supply something that works together, the industry says they want a choice.
Subramaniam: I don’t see this is as big a problem as it’s made out to be. There are disparate flows and there are discrepancies between those different formats, but they generally work together quite well. There may be a few glitches here and there. It’s always nice to have everything unified. But having a choice also makes a big difference. The people who make that choice are willing to sacrifice between the two environments.
Rey: The differences tend to spike from time to time, when there is a level of discontent in the user community where they don’t accept a particular version anymore. There is a trend toward having something integrated, which has advantages both for the user and for the provider. But those advantages become disadvantages at some point, too. When you look at the foundries providing interposers, they do that because they want to be a single provider for everything. The advantage for the user is that you have a single place to go and complain if something doesn’t work. On the other side, the disadvantage is that you have much less power when you want to negotiate for the interposer for different chips. It’s the same for tools in a vertically integrated flow. The good thing is that we all are constantly under competitive pressure to have the best performance, the best capacity, and then integrating it all goes even further.

SLD: What standards do we need in the future? What’s missing?
Varadarajan: Standards are essential. UPF and CPF is one mess that’s out there today. Almost 80% or 90% is common information, but it’s expressed differently. That’s something designers have to deal with. But as we migrate into 3D (stacking), there are lots of standards around 3D. We have had a bunch of meetings. We are looking at more objectives that need to be traded off at a very early stage in terms of thermal effects, stress effects, and what is the representation of the stacked die when you go beyond the simple memory on top of logic. You really don’t want multiple standards for interfacing to multiple tools. What is the XML standard? Is there one unique standard everyone can agree with? I’m hopeful something everyone can agree on will happen.
Zorian: Whenever we have interfaces between things we definitely need the standards. There are some cases where we have been very successful with standards, and 3D is the next challenge. In the test world, people realized a while ago that you need a standard to talk to every chip for testing and debugging. That’s why we have JTAG. It’s been around for 20 years, and since then almost every chip uses JTAG. It’s an exchange point between your chip and the board. Ten years later the same committee generated something for IP. IP needs a handshake for test and debug and diagnosis. Today almost every chip has JTAG/1500 ports on every IP. It’s well adopted because it’s an interface point between the IP provider and the IP user. Today that same committee is creating a new standard for 3D, called 1838, and that is meant to test between the dies. When you have stacks you need to test on both sides. They need to talk to each other. It’s a community effort. But if you need a standard it can be done, and it can be done successfully.
McNamara: And if you look at the Verilog VHDL wars, that is now resolved with System Verilog. It was a long struggle and there was a lot of contribution of great intellectual content. It ended up that no one won. There was a unified standard that put bits of Verilog into VHDL, or VHDL in Verilog. It was messy. There were a lot of engineers who got the chance to rewrite tools that worked just fine. With anything that’s interesting, there are going to be multiple ways to do it and people are going to look for the alternative.
Rey: There used to be a term from the manufacturing community. They were looking at how you make the masks and manufacture each transistor, but they didn’t know if the transistor was going to be used for a high-performance application or something that was going to be turned on only once in a while. The term was design intent. We were manufacturing and we have no idea what design intent was. There are trends to bridge that gap. Interestingly enough, there isn’t much yet on helping optical proximity correction or mask manufacturing. But understanding power domains, and then going back to connect two transistors that are supposed to be connected to the right power supply—those types of things are starting to grow in importance and we see things being extended in that direction.
McNamara: Whether it’s a single-vendor flow or multiple vendors’ point tools, all of these tools are inserting transistors. If you start with a high-level model, it may be based on a heartbeat, but there’s some fundamental math being done. Later tools start inserting the test points. And then later tools are putting in parity on buses for redundancy. The original algorithm was a heartbeat. At the next level it’s a sea of gates or polygons. Why are they all here? Nobody knows. But the task was handed to us to implement these polygons. If you had information from high, you might be able to get rid of redundant gates. You may need only 8 bits to carry data. Why are there 9 bits? Why is there a generator or a receiver? You may want some redundancy but not all of it. There’s a need for a front-to-back understanding of why this transistor is here. That’s the overarching standard that will take a long time to create, but it’s an optimization opportunity.

SLD: With 2.5D stacking, the promise is faster time to market. Will that simplify things or add more complexity?
Zorian: It’s a tradeoff. It may simplify things because you might not have to go to the next node.
McNamara: Or you can buy memory from a company that’s at 28nm and the rest of it you keep at 40nm.
Zorian: Yes, and in that case it is simplified. But there are some additional constraints you have to pay for—the ability to model, simulate and put your software on a multi-die entity. Modeling it and being able to do virtual prototyping is a challenge.
Subramaniam: It simplifies the problem in that it can use heterogeneous technology to achieve your goal, but the design of the system itself is going to get much more complicated. And on top of that, the testing of the system will be much more complicated. It doesn’t come without sacrifice.

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.

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.