By Ed Sperling
Mentor Graphics rolled out the next generation of its Veloce2 emulation platform, adding virtualization capabilities. The key here is that it allows software engineers to use the platform to verify their software from their PCs, rather than having to go into a lab to work on their code. This is a new wrinkle in emulation, which is now being used as much for software verification as for hardware. Appealing to software engineers is a whole different world.

Cadence roared back to life in Q1, with revenue increasing to $316 million compared to $266 million in Q1 of 2011. Net income was $31 million compared with $6 million in the same period last year. On a non-GAAP basis, net income was $47 million compared with $23 million in 2010. The company expects revenue of between $315 million and $325 million this quarter.

Synopsys extended visibility in HAPS debug FPGA prototypes, adding about 100 times more storage capacity for signal traces while slashing memory utilization for complex designs.

Open-Silicon expanded its solutions portfolio to include architectural analysis and modeling, pre-silicon prototyping, embedded software, co-silicon system design and test and post-silicon validation. It also expanded its ARM Center of Excellence and boosted staffing at its design center in Pune, India.

Tensilica added support for China’s Dynamic Resolution Adaptation standard to its audio encoder/decoder library for its HiFi Audio DSPs. That should open up a huge market.

Soitec said it is ready to provide fully depleted silicon-on-insulator wafers for both 2D and 3D customers. The company claims significant cost savings over bulk CMOS at advanced nodes—a major shift from previous nodes.

By Ed Sperling
As designs pass beyond 1 billion gates, some companies already are beginning to look at the next big change—the trillion-gate design.

Those designs will be fewer in number, highly targeted at segments such as mobile, and most likely platform-based so they can be used as subsystems in other SoCs or stacked SoCs. But even beyond the business equation, which is almost inconceivable at the moment, there are technology challenges that are well beyond the grasp of even the smartest teams of engineers.

Sameer Halepete, vice president of LSI engineering at Nvidia, said he expects the GPU to cross the trillion-gate mark in 2020.

“There are two worries,” he said during a keynote speech at the Mentor Graphics User2User conference. “First, is there a market for this? And second, if there is a market, can you build it?”

The driver, he said, will be the quest for ever-more-realistic graphics in games and faster performance, which will only be achieved by adding more processors to a die.

From a technology standpoint, the process node will be somewhere around 8nm. Designs at this level will require voltage and frequency scaling, power gating, rail gating, mid-level clock gating, and fine-grain clock gating. It also will require improved variation modeling for process, voltage and temperature.

Some of the biggest challenges will come in the area of test and reducing defect density more quickly. Test currently accounts for as much as 5% of the overall design costs, Halepete noted.

“We also will need to change verification because it takes more random tests to get the last bug,” Halepete said. “Formal verification will help. It changes the way you think about verification, though. It requires a lot more up-front work, but once you decide what the stimulus is and set up a testbench you can prove it quickly.”

A second problem big issue will be timing closure. He said there will need to be more front-end visibility into the design faster to achieve timing closure. There also will have to be an increase in designer productivity, because design teams have swelled by 30 times in recent years. That rate of increase cannot continue, and chipmakers are looking to EDA vendors to provide that improvement through more automation.

EDA vendors already are witnessing this pressure for much greater automation to reduce the time to market. All of the emulation vendors—Mentor, Cadence and EVE—have seen strong growth in the past two years, partly because of an increase in the number of transistors and partly because of the need to speed up software automation.

“A lot of customers have been doing evaluations for one chip and now they’re buying for a six-chip configuration,” said Jim Kenney, director of marketing for Mentor Graphics’ Emulation Division. “Some of these customers are doing billion-gate designs. But they’re already asking when we’ll be ready for 2 billion gates. And when we get to 2 billion, they’ll be asking for 4 billion.”

Apparently some companies will be asking for a lot more in the near future.

By Ann Steffora Mutschler
Yield. Just the word can make many engineers cringe and hide in their cubicles—especially with manufacturing problems and excessive power during test increasing causing failures. But the combination of physical data with diagnostics engines may be the light at the end of the tunnel, allowing for easier pinpointing of defects.

There are many reasons why a chip fails on the tester, and most fall under two areas. One area includes manufacturing problems, explained Bassilios Petrakis, director of product marketing for front-end products at Cadence. “You can think of a case where the wires are not manufactured ideally, so sometimes they might touch because of a short. Or sometimes the wires are thinner than they should be, which causes more resistive type behavior in the wire or they get disconnected. There are tons of defects that are either known, or new ones that come up with new processes.”

Another class of problems is due to excessive power when the chip is tested. “What tends to happen is people design a chip for tolerances when it’s being used in the normal function—in a cell phone or whatever it is—but you also have to consider what happens when you test the chip. We’ve seen failures on the tester. Customers tell us that. And after some work, most people tend to think they are manufacturing defects. A lot of them actually occur because there’s way too much switching activity on the chip that wouldn’t happen in functional mode,” he said, which can cause a chip to fail the test, or even damage the chip itself.

These issues traditionally have been addressed by the diagnostics tools associated with ATPG, but thinking in this area has expanded. Robert Ruiz, senior product line manager for test automation at Synopsys noted that diagnostics has been around for as long as ATPG because they are correlated technologies, but efforts have been underway to improve the accuracy of layout-aware/physical diagnostics tools by pulling in physical information to cut down the search base. “Older diagnostic technology looks at a wire as one node. Everything is connected to it and it can’t pinpoint out. Using physical diagnostics understands that this is not one, single continuous wire but it fans out—there are branches on it. When I think of branches, I think about a defect on that tree. You narrow that tree down among several trees, but if you have more physical information about the tree you know if a defect is along one branch.”

Physical diagnostics use is on the rise due to the accuracy it promises. Connected to this is the need for the infrastructure to support it, which prompted Synopsys to add the ability to read in LEF DEF so it can become layout-aware and run diagnostics, he said.

Alongside traditional diagnosis is volume diagnostics, which brings in another dimension of data into the diagnostic tools. “What’s driving this is the fundamental trend of moving away from individual test engineers diagnosing a fairly small number of failing parts to a much more systematic process,” explained Cy Hay, product marketing manager for ATPG and diagnostics at Synopsys. “It’s not really changing the traditional application. It’s an expansion beyond using diagnostics in an almost offline manner, where there is a test engineer sitting in a lab on a tester with a few failing parts that maybe came back as returned merchandise, to a much more systematic application of diagnostics to improve yield. Especially with the types of yield limiters that customers see today, combined with the pressure to not only bring up a new process node but new designs manufactured in very high volumes, very quickly—there’s clearly a lot of pressure there. The traditional techniques that the fabs have used to improve yield don’t always apply or don’t work as efficiently on some of the more advanced process nodes, especially the aggressive and large designs that are being thrown at a new process node.”

New technology, new challenges
With all of this great new technology, there are challenges too. Geir Eide, DFT product marketing manager at Mentor Graphics, pointed out that part of the challenge now is getting people to talk together. “People who don’t even know the other guys exist—basically connecting product engineers, failure analysis engineers, test engineers, physical design and library designers—you’re basically giving these guys some technical capabilities that allow them to communicate.”

The problem is that they’re not used to talking to each other even though there is much to be gained by opening up this kind of conversation.

“You’re dealing with the fact that something that is beneficial for the product engineers, that will make his job easier, for him to be able to use these capabilities he needs the DFT engineers and the test engineers to enable that,” Eide said. For instance, for diagnosis to work, the data collected on the tester is needed, which means that the test engineer needs to facilitate that. While that doesn’t necessarily makes his job harder, it’s just something that he needs to do to help someone else’s job easier. This means there is a lot more interplay across different organizations and sometimes even across companies where test is outsourced, failure analysis might also be outsourced.

“Part of the beauty of these types of tools is we make it possible for multiple organizations to do the analysis so you don’t need to sit in the fab to do the analysis. You don’t need all the fab data to do this. From that point of view, the challenging piece here is that you have to share data across organizations that normally wasn’t shared, and you have to store the data and make it accessible. On the other hand, you can use software to do a lot of work that previously required you to take a lot of physical devices and slice and dice them and kind of do a lot of expensive, time-consuming analysis,” Eide added.

“The test guys don’t usually give a rip about the physical design—it’s just there. What we are trying to do is being able to make it so that they don’t have to know all the rules and things that they are looking for,” stressed Jeff Wilson, Calibre product marketing manager at Mentor Graphics.

During Mentor’s recent User2User conference, Global Foundries discussed combining diagnosis results that originate from test results and using real silicon data to help validate and identify the yield-limiting design features which ties into DFM tools.

There are a lot of ways things can go wrong. Whether it is a lithography problem, a fill problem, or other issue, being able to determine the root cause of that that problem and being able to fix it is the area that probably is going to bring the biggest benefit to the designers because the test guy shouldn’t have to know all the stuff about the physical design to make things work, he concluded.

By Ann Steffora Mutschler
As semiconductor manufacturing technology continues its march toward 20nm, SoCs are plagued with advanced interconnect delays, cross capacitance, and process variability, as well as area and power constraints—and the significance of these factors is increasing with each passing node.

“With lower nodes we are getting advantage on area, more and more logic is getting included onto the dies, which means many interfaces are also integrated on the same die. All the interfaces may have their own unique requirements of clocking and when they interface with each other there are many constraints that come into picture which result into complex clocking schemes for the ASICs,” explained Shrikrishna Mehetre, engineering manager at Open-Silicon.

In advanced SoCs additional modes of operation dictate that extra tradeoffs in timing closure must be made to make sure the device works in all of the different modes and with the minimal amount of power, said Andy Inness, place and route specialist at Mentor Graphics. “Fixing power in one mode may break an operation in another mode. You need to make sure you take both into account, so when you optimize one you don’t break a different one.” The physical effects of advanced nodes can have varied impacts because as the voltage is varied, the physical effects are different in different voltages.

Advanced timing closure requires the P&R tool to account for all operating modes, and all process corners. This significantly reduces the number of timing violations and helps for faster timing convergence. Source: Mentor Graphics

In recent designs, Open-Silicon has seen that additional complexity as it has integrated numerous such interfaces and ended up with as many as 400 clock domains, many of which are generated clocks and dependent on each other. While so many interdependent clocks interact with each other on a 18mm x 18mm die, the insertions delays and skews for all these clocks and their impact on the overall timing optimizations is huge.

In addition to the clocking requirement for the design functionality, complexity also comes from the DFT logic addition and the test requirement for such huge logic and memories in the designs because the clocking requirements for DFT logic add to the complexity of the design. In this scenario, the timing optimization is not just restricted to achieving better data path delays. It also requires consideration of physical effects such as interconnect delays, cross cap, the clocking skews and variability.

High frequencies = extreme variability
Companies like Open-Silicon are working with clocks ranging from hundreds of MHz to a few GHz at 40nm and 28nm technology nodes. At such high frequencies achieving the required skews and insertion delays for such a big clock network over large dies is very challenging. The variability across different functional/DFT modes and different process corners is very high. When combined with clock distribution over a huge die and the variability at smaller nodes, timing optimization needs to consider these large overheads, Mehetre said. Power optimizations using clock gating has become the norm, but achieving timing closure for clock-gating latches is an additional complexity the needs to be addressed.

In addition, timing optimization is not a standalone task anymore. It needs to consider all the parameters such as clock period available, physical effects (interconnect delays, cross talk, variability), and clock skews across different corners and modes. Adding in excessive margins at different stages (such as data-path optimization before CTS, clock skew opt after CTS, variability optimization after CTS is completed, SI optimization after routing is done) is becoming inefficient at smaller nodes. EDA tools needs to model these effects right from the initial optimizations rather than relying on margins at different stages. For instance, instead of applying a single OCV number for the entire design, Mehetre said it’s better to use AOCV (local OCV), and all the IP vendors need to support AOCV models at smaller nodes. So instead of trying to achieve a global skew number, effort should be put in to utilize the useful skew and planning for the useful skew should be done from initial optimizations.

The impact of shrinking process nodes
While there was an era when interconnect delays were marginal with respect to cell delays, the situation seems to be reversing beginning at 28nm. Enhanced physical synthesis considering the clocking and modeling of the interconnect/cross-talk delays, variability is needed to replace added margins for these designs. Also, logical optimizations that consider variability and different corners needs to be part of the initial optimizations, Mehetre asserted.

As such, there needs to be change in the way clocks are used for such huge designs. Rather than looking at how to optimize timing and clocks for the effects, the approach should be how to minimize the impact of these effects during the architecture and RTL design phase itself. This is especially true if the clocks are to be shared or if they are interdependent, and during the logic design the goal should be to reduce interdependency.

Paul Cunningham, senior group director of R&D at Cadence agreed that smaller geometries are having an impact and that, by far, the biggest impact is on the wires rather than scaling of the transistors. “The transistors are getting smaller faster than the wires. We went from being all about the transistors to more about the overall wire capacitances and then at the very advanced nodes—28nm and below—we’re seeing it’s more and more about the resistances in the wires.”

All of these issues require engineering teams to rethink the algorithms, which has led to a clock concurrent optimization process, he said. “The underlying model in timing terms is, rather than thinking about a path in the design—I call them chains—where a chain would be a sequence of functions that span multiple register boundaries. Eventually these functions form some kind of a feedback loop and it’s that loop that really dictates the speed. In a traditional flow, if I’ve got a four-pipeline stage loop, my speed is driven by whichever of those four pipeline stages is the longest. In a clock concurrent world, I’m going to take the average of those four pipeline stages and that’s what drives the speed of my chip.”

Embracing that approach has required major changes to the tools themselves. “It’s a complete genetic rewrite in terms of the algorithm,” Cunningham asserted. “To the end user, it just looks like a new kind of next-generation step in the flow. So I’ve just rewritten step ‘n.’ What comes into step n, what goes out of step n is still the same but the actual result is now much better for power, performance and area. You are really optimizing the clock parts and the logic parts at the same time.”

Overall, boundaries are blurring throughout the entire optimization flow and the trend in the industry is towards the different optimization steps becoming more and more intimately linked so it’s a very, very smooth transition and possibly its a more fine-grained transition as you go from step n to step n+1 to step n+2. Twenty years ago they were really very distinct, isolated steps almost as if you were running different tools, he observed.

“It’s really the sum of all the steps—making the combination greater than the sum of its parts—that’s where the industry is focused these days,” Cunningham concluded.

By Ed Sperling
Among tools vendors it’s been standard practice to listen closely to customers but not deliver everything they ask for—or at least not always on the customers’ timetable.

This strategy has worked well enough for both sides in the past, but at 20nm and in stacked die configurations, the level of tension between these two worlds is increasing, and the gaps in the tool chain are becoming more noticeable. Part of the problem is that skyrocketing complexity is forcing more automation, but integration issues, physical effects, process variation and the realities of physics make it more difficult and time-consuming to develop tools to make that complexity more manageable. R&D budgets for EDA companies already are hovering around 30% or more, compared with average R&D investments of about 10% to 20% in other areas of chip development and manufacturing, and betting on the wrong area can have a significant impact on EDA company’s earnings.

The other part of the problem is that chipmakers’ own internal tools are running out of steam at advanced nodes because of the need to bridge both hardware and software design environments and because old methods of doing things are way too slow and very often ineffective. This is clearly reflected in the fortunes of EDA tools vendors, which have been rising steadily for the past couple of years, with the strongest growth in areas such as ESL, including hardware-software co-design and software prototyping, and emulation.

Add in stacking of die, in both 2.5D and 3D configurations, and the number of issues that have to be dealt with by both chipmakers and tools vendors increases by orders of magnitude. On top of that there are double patterning issues at 20nm, finFETs at 14, and potentially 450mm wafers that will require significantly higher yields to be cost-effective, but which may be harder to test in wafer-on-wafer or die-on-wafer configurations.

Where chipmakers see challenges
Riko Radocjic, director of design for silicon initiatives at Qualcomm, breaks the design process down into three areas—design authoring, which is the actual chip design; pathfinding, which includes exploration for how to best build a chip; and tech tuning, which is physical space exploration. Most of the EDA tools have been effective in the design-authoring phase, with some point tools now finding their way into the pathfinding area. But the real challenges are in the tech-tuning area.

Mechanical stress becomes a serious issue in 3D stacks, ranging from the effects of TSVs to die alignment. “You cannot solve the problems with a tool. They have to be solved in a flow,” he said. “It’s a debug nightmare. You need a separate domain that takes external stresses and produces a set of rules. You also need hotspot checking to make sure you have caught all of the interactions.”

Also missing, he said, are EDA tools that understand the materials inside a stacked die, and a standard PDK for all mechanical and thermal properties.

“Thermal is the next frontier,” he said during a presentation at the Electronic Design Process Symposium this month. “You need to manage for hotspots and overall system power. On a global level you have skin temperature and overall system power. On a local level you have to manage hot spots, junction temperatures and power density. And there is also the compounding factor that all advanced systems use some form of thermal management. We need a system-chip co-design methodology and tools to deal with this. We cannot solve thermal issues only at the component level. It must be system and component, and we will need tools for pathfinding thermal issues. We don’t even know where to put our thermal sensors. We need thermally aware floor planning.”

Summing it up, he said it amounts to 3D-aware co-design tools for package, system and thermal, and a flow to integrate everything.

A stacked die of the future; memory on top left, with logic/memory in middle on top and I/O and analog RF blocks on top right. All feed into interposer stack in the middle. Source: Qualcomm.

Altera, which has just developed its first 2.5D stacked FPGA prototype, is encountering similar thermal and mechanical issues. While the company continues to offer scaled down tools for FPGA development, it needs the most advanced tooling for creating those FPGAs in the first place. Topping his list are robust standards for cells, IP and stacked ICs, as well as tools to help quickly identify some of the problems that Altera encountered while developing its prototype stacked die.

Signal integrity issues encountered and addressed by Altera in stacked die using interposers.

“We’re looking for more of a divide and conquer strategy,” said Arif Rahman, product architect at Altera. “Die stacking will be an enabler for a complete solution in the future, but it will not just be an FPGA. It will be an FPGA plus other accompanying functions.”

Where EDA tools vendors see challenges
For the tools vendors, the list of problems that need to be solved is exploding. So many things need to be fixed and solved that it’s imperative just to focus on both what will have the most impact and what will provide the greatest long-term returns.

At least part of that effort involves existing tools, which have to be run faster and do more things than in the past. This is particularly true in areas such as emulation, which in the past were used almost exclusively for hardware. They are now becoming the tool of choice for software verification because the complexity of the software makes it far too slow to run using simulation. What takes hours or days in simulation can be measured in seconds in emulation. And given the fact that verification is still the lion’s share of the NRE, anything that can be done to solve this problem is considered a big win.

Mentor Graphics’ announcement this week of enhancements to its emulation tools is a case in point. Recognizing that software engineers are using the emulation tools as much as the hardware engineers, the company has added a virtualization layer that allows a workstation to be a front end—matching the way software engineers work—rather than doing work in a lab the way hardware engineers typically work.

“This allows one workstation per user,” said Jim Kenney, director of marketing for Mentor’s Emulation Division. “We’ve also been working to improve performance and capacity so you have more robust software execution and debug.”

Mentor isn’t alone in this quest. Cadence has been updating its own emulation, and all the EDA vendors have been racing to improve the reach and integration of their tools. Bassilios Petrakis, product marketing director at Cadence, noted that building smaller die that yield better is still a challenge that needs to be solved—particularly before stacking becomes mainstream.

“When you look at multiple die with TSVs, the cons are that the ecosystem is still emerging, there is no volume production yet and there are thermal issues,” Petrakis said.

Samta Bansal, senior product marketing for SoC Realization at Cadence, predicts that stacking memory on logic using an interposer will become mainstream beginning in 2013 to 2014, with TSVs becoming mainstream by 2015. She said work in EDA typically needs to begin three to four years before these efforts, noting that it began in earnest at Cadence in 2009. Synopsys rolled out its 2.5D tool flow last month and is working on a full 3D flow, and Mentor has been working on a variety of areas ranging from test to modeling of stacked die over the past several years.

But EDA vendors also need to pick new areas for the future, and this is where even the best educated guesses become difficult.

“EDA traditionally has been an industry where big companies acquire small companies doing interesting things,” said Wally Rhines, chairman and CEO of Mentor, noting that markets that have shown strong growth include DFM, formal verification, ESL and power analysis. He said the next wave of electrical design challenges include low-power design at higher levels of abstraction, optimizing embedded software for power, in-circuit emulation, design for test, physical verification, stacked die verification, and system design that extends beyond the PCB.

That concern is echoed by Drew Wingard, chief technology officer at Sonics: “From an EDA perspective, the next layer up in the power hierarchy is how we convince ourselves that the hardware and software are working together correctly. This is a different protocol check than we normally do. You have dependencies, because you can’t turn off one until another turns off. The mix of hardware and software makes it difficult to prove what’s correct. Right now there is not even enough time to test the power management until the second spin.”

He noted that just trying to get software to turn on the power management features in a chip is a challenge. “The thermal/power reduction to be gained by turning on features already in a chip can be significant.”

One issue that almost certainly needs attention is derivative designs. Getting them out the door is painful, expensive, and time-consuming.

“A lot of engineering that’s being done is derivative engineering,” said Naveed Sherwani, president and CEO of Open-Silicon. “This is not something that EDA vendors focus on, but it’s something that’s definitely needed. What’s out there is a kluge of methodologies and flows. EDA so far has not woken up to this opportunity. They certainly listen to their customers, but they’re still not close enough. You have to do the work to understand it, and the revisions and changes that are needed are painful. A derivative is almost like a new project. There can be 1 million degrees of improvement here.”

Conclusions
All of this requires tools—notably more and new capabilities built into existing tools—as well as new tools that can integrate all of these pieces. But what gets addressed first is a difficult balance.

While chipmakers at the leading edge are used to developing some of their own tools, methodologies and dealing with poor yields, their existing development is running out of steam. That means moving forward at advanced nodes and in stacked configurations will require developing entirely new versions of tools, methodologies—an enormous expense by anyone’s calculations.

Qualcomm's proposed tech-tuning flow.

EDA vendors, meanwhile, have their work cut out for them just updating their existing tools, and they are cautious about massive investments in new areas that may not return dividends within an appropriate time frame—or within an immature supply chain when it comes to stacking of die.

“To get ROI back on tools of this complexity you need more than 20 customers,” said Mike Gianfagna, vice president of marketing at Atrenta. “That means you’re going to be negative on that investment for three or four years. So you really have to pick your battles, and small companies probably can’t do this at all.”

Gianfagna noted that for chipmakers the challenge is too many options. “You need a way to prune the solutions space fast. You have to figure out which architectures to choose quickly and which roads to pursue further. The real gap is not in the tech tuning. It’s coming up with the right architecture that supports meaningful decision-making.”

The question now is when the gaps that each side sees will merge, and when it will become profitable enough to take an investment risk.

By Ed Sperling
System-Level Design sat down to discuss hardware-software co-design with Frank Schirrmeister, group marketing director for Cadence’s System and Software Realization Group; Shabtay Matalon, ESL market development manager at Mentor Graphics; Kurt Shuler, vice president of marketing at Arteris; Narendra Konda, director of hardware engineering at Nvdia; and Jack Greenbaum, director of engineering for advanced products at Green Hills Software. What follows are excerpts of that conversation.

SLD: We’ve been hearing about co-design for a long time. What are the problems that haven’t been resolved?
Matalon: The industry started moving to co-design 15 to 20 years ago with technologies such as emulation, but the big change is that emulation alone is too late. The RTL needs to be quite solid at this stage. Co-design today means above RTL. Co-design is not even enough because you’ve already defined your architecture. There is one level ahead of it where you need to really validate that your assumptions are being met. There is a major role for ESL in co-design and we’re seeing the industry is taking off. This is the fastest-growing segment because you need to start co-design before the RTL is implemented and validate the assumptions regarding funcationality, performance, power and area before key implementation decisions are made.
Shuler: There is still a tendency to come up with some requirements and hack away at RTL. A lot of companies are getting smarter about that now. They’re starting at higher levels of abstraction and working their way toward more detail. But it still doesn’t happen all the time. When a company is purchasing IP from different vendors, there is still a question about where they get their models. That’s a common issue that slows the adoption of the new way of adoption. There also are disparate cockpits that people use. There are commercial tools you can use for SystemC and TLM simulation that are really good and really help with ease of use. But some of the biggest companies don’t use commercial tools. What slows us down as an IP provider is that we have to make sure our interfaces and IP-XACT information works with internally developed SystemC cockpits. Those things are not specified. There are one or two or three people within those companies that know how it works.
Konda: From a need point of view, the design sizes have been exploding and chip sizes are doubling in size. On top of that, especially at the SoC level, we see a number of processors, 20 to 25 different interfaces—USB, Internet controllers, SATA—so co-design has become an absolute necessity. The second piece of the puzzle is software. If we follow the traditional model of the design and then you start developing the software it’s way too late. We are designing our own design environment—RTL models, C models, and simulating all of this at an SoC level. What we are doing is homegrown, but we also are looking at commercial tools to see if they would make our life easier. What we would like to see is mixing and matching various models. Some parts of the design might be an FPGA, some might be an emulator, some might be C models and others could be RTL models. It’s a complex problem and I don’t see a clean solution at the moment. The end goal is to realize an SoC as early as possible.
Greenbaum: There are two sides to this. One is that we’re frequently asked to fix it in software when the chip is already is in production. We’ve seen mistakes that make it all the way through to several revs of silicon. We also look at this as a tool provider, where there is a continual cultural divide between hardware engineers and software engineers. From the point of view of silicon that’s already in production, the biggest problem is memory bandwidth. We have a board in our lab right now and doing something as pedestrian as video capture while the CPU and GPU are busy causes time-outs on the PCI bus. You can’t stream video to memory while you have the processor and GPU busy. This was a function of the system architecture that the SoC was supposed to handle. The arbiter doesn’t arbitrate properly. There are no knobs or gauges on it. And the problem wasn’t discovered until very late. There’s nothing that can be done in software. This is the most common error I see. Memory bandwidth problems aren’t something organizations can tackle today.
Schirrmeister: There are problems on the tool side, as well, right?
Greenbaum: You would hope that to do hardware-software co-design you could get system architects, software architects and processor architects in the same room and solve the problems up front. Unfortunately they don’t speak the same language. The implementation folks, especially here in the United States, speak Verilog. The software engineers speak C. The system architects know how to draw boxes and lines. When I first learned about SystemC I thought everyone could speak the same language. It’s not happening quickly enough. Language is just the easiest place to see this cultural divide, and it will always prevent us from shortening our cycles.
Schirrmeister: The whole notion of becoming independent of hardware and software increasingly will be adopted. The engineers who know boxes and lines may expect that UML (Unified Modeling Language) and SysML (Systems Modeling Language) can be used, once they know functionally what the system will do, to attach requirements or whatever they need on top of it. SystemC models are great, but how do you get above that? There will need to be more automation. When I did my first design I drew gates and connected them by hand. Then we began connecting bigger blocks and the assembly was automated. Automated scripts will become more common in the future. And as we are spreading out toward hardware-software independence, the underlying automation that will bring them together will have to be created because it’s too complex for human beings.

SLD: What’s the starting point? Is it hardware, software, or both?
Matalon: The world has changed. It used to be primarily hardware-centric. Now there are two challenges. One is hardware-software co-design. The other is that there is no hardware at all. The majority of hardware designs are based on standard processors or embedded processors that can do everything. Hardware is not required unless the product is really addressing a niche in the market where power and performance are important. Not every design cares about those factors. If I want to control a refrigerator, all the computation and control can be done in software. Co-design is not for everything. There are a lot of designs that are getting out the door where the challenge is writing the software. When you get into co-design, it implies you have a problem that cannot only be solved in software. You may need higher performance. You may need a network on chip to implement a design. You need a specific architecture or arbitration or an accelerator to implement graphics, and you need RTL for that because a standard processor won’t do the job. Then you head toward multiple processors, multiple cores combined with hardware—that’s the sweet spot for co-design. There’s no doubt that models have been the drag on this. When the design needs to meet performance and power, and there is a software part where there are certain tasks that will be done with processors and others with network devices, you need to get to the problem of partitioning between hardware and software. You have to do it right so that you account for both hardware and software.

SLD: You’re talking about complete optimization?
Matalon: Yes. And here’s where we need to focus.
Schirrmeister: The challenge lies in not knowing what you don’t know. When I’m writing the software, I may not know the memory that talks back to the fridge doesn’t know that the grocery store where I’m going to buy my milk has run out. I may not have foreseen that scenario. To me the things always start at the functional requirements of the user, whether it’s a graphics design, memory bandwidth. People don’t get the requirements right in the first place before marketing changes them. And then how to transfer those requirements into co-design is a challenge we haven’t solved. That’s where the models come in. If you just do this at the LT level you may not see the memory problem. If you go down to the cycle-accurate level, you may not be able to run enough cases to figure out the configurations.
Matalon: From a practical perspective, you may not need co-design for all designs. In an SoC, where you need to access memory and peripherals and sensors, the ratio is probably 100:1. But the pain level and the complexity aren’t such that everyone needs it.
Shuler: It’s more up-front work.

System bring-up and hardware/software verification are two of the most challenging and lengthy tasks in systems design, and they often threaten to delay market entry for today’s electronic devices. The complexity of the hardware/software interface has exceeded the ability of engineers to conceive and test the interactions, and to reverify when changes are introduced. This paper describes a unique functional verification automation solution that shortens the time to functionally verify software drivers along with system hardware, and helps improve the quality of the eventual system.

To view this white paper, click here.

By Ed Sperling
Mentor’s Colin Walls shows off his robot demo in a video from Design West, aka ESC, and wonders why the video isn’t going viral. Maybe a different outfit would help—for the robot, that is.

Synopsys’ Karen Bartleson and Yvette Huygen interview Peter Ateshian of the Naval Postgraduate School about technology being developed below 22nm. If you want a fascinating glimpse into the future, here it is, but the audio segment runs 30 minutes so plan ahead.

Cadence’s Richard Goering takes a look at how Specman and e changed IC verification in an interview of Andy Eliopoulos. Just to put it in perspective, it’s been seven years since Cadence acquired Verisity.

But why all the noise about e these days? DeepChip’s John Cooley reports on the language wars simmering between e and System Verilog. Apparently the fire is still going on this one.

IHS iSuppli’s Hailin Zhao predicts China’s wireless infrastructure investment, particularly for LTE, will peak in two years and begin declining slowly after that. But that also means LTE-enabled devices should really pick up after that.

Synopsys’ Eric Huang looks at what makes Intel’s new processor so fast. Hint: It has something to do with integration of USB 3.0.

Cadence’s Reuven Naveh digs into why constraints are ignored in the e language and whether it’s a tool bug.

Mentor’s Bernard Sutton examines what he calls the black art of PCBA test and quality. The key is a mix of process and test skills, which don’t ordinarily go together. But we’re much more forgiving these days about heresy and black arts.

Verification engineers should check out the blog posted on the Synopsys Verification Martial Arts site by Cavium’s’ Brian Hunter about customizing UVM messages without getting a sunburn. If you’re working on verification, you probably don’t see the sun very often. That explains why UVM is endorsed by the American Dermatology Association.

System-Level Design talks about where the problems are with hardware-software co-design and how much progress we’ve made with Narendra Konda of Nvidia, Frank Schirrmeister of Cadence, Shabtay Matalon of Mentor Graphics, Kurt Shuler of Arteris and Jack Greenbaum of Green HIlls Software.

By Ed Sperling
Mentor’s Colin Walls has hit upon one of the most important points in embedded software—the value in open source is in the ability to integrate it. And therein lies a potential hidden cost—not to mention all the Mountain Dew needed to pump up software programmers. Just try submitting that expense report to a hardware company, though.

Speaking of software, Cadence’s Jason Andrews looks at modeling large memories in SystemC. This language is finally catching on, but the uptake is still painfully slow.

Synopsys’ Helene Thibieroz talks with AMD engineers about using Verilog-AMS with UVM. This stuff is getting very complicated.

Semico’s Joanne Itow charts wafer demand over the past quarter century. If you thought the semiconductor business was cyclical, check out the jagged red line in the middle chart. Yikes!

IHS iSuppli’s Henning Wicht looks at another side of this market—polysilicon pricing. Apparently there is a glut of this stuff at the moment, which should make for lower prices over the next year.

What do Yocto, Poky and Angstrom have in common—aside from the fact that they sound like reindeer commands? Mentor’s Christopher Hallinan sheds some light on an alternative universe. And yes, it’s true. Software engineers really do speak a different language.

Cadence’s Richard Goering questions whether system modeling is the next abstraction layer for EDA. This one is probably best answered in a rear-view mirror, but it’s an interesting question.

Synopsys’ Eric Huang is rounding up viewers for his USB video. He claims it’s the best seven minutes you can spend. You can have it out with him if you don’t agree.

Mentor’s Nazita Saye does what all good engineers do when they go car shopping. They read all the reports about what can go wrong, figure out what causes the problem—in this case it’s electromigration on a PCB for the water pump—and then proceed to make an educated decision about what warnings to ignore.