By Pallab Chatterjee
This year’s IEDM conference will feature a non-device topic for the luncheon keynote from Masaaki Tsuruta, CTO of Sony on Interactive Gaming. The takeaway: Even in the heavy R&D and physics-centric world of devices, building for the end application has now become one of the top priorities in driving specifications.

Traditional compute systems were based on batch-mode processing, meaning they were optimized for generalized programming or scientific computing. Now the devices are split between creation and consumption machines for this media.

The mobile devices in the current generation are based on audio and video playback, audio and video capture and motion-based gaming. This is a dramatic shift in the architecture of these devices as they were originally made to be voice-based radio communicators.

The shift in content also impacts the data. The small data sets have now grown large in file size and large in block/string size. The content business is large, and as result it is making changes in specifications, hardware and use methods. In 2010, the copyright industry accounted for more than 6.4% of the U.S. GDP (according to the IIPA), or roughly $930 billion in content. Exports for this content accounted for $134 billion in foreign sales, far more than sectors such as aircraft, autos, and agriculture.

Major systems and architectural changes that have been created to this market such as higher speeds for USB, SATA, Display Port, HDMI, WiFi, Bluetooth, Zigbee, Zwave, and PCIe. At the component level, changes such as IPV6, Advance Format (AF) for disk drives, and new memory interfaces are being created. AF is a shift from the existing 512 bit blocks to 4K blocks for the storage units on rotating media. The change not only enables higher-speed access and increased densities, but it is optimized for large data sets rather than high numbers of small files. As these file blocks got longer the size of the drives got larger to accommodate the content. The typical high-end drive features a 1 Tbyte single platter and increasing density.

Similarly in processors the trend started with single CPU cores, and the graphics co-processor chip was used simply as a paint engine. As the amount of media content increased on these devices, new processor architectures, such as multicore, were implemented to allows for the many parallel compute tasks that are needed for streaming content playback. As is typical of most hardware, power optimization comes about with functional optimization. This resulted in multicore for general processing as well as specialized GPU processing for high-speed shading and physics effects in a low power format.

These hardware changes to address large streaming content (upwards of 10-Gbyte files) have moved toward new memory interfaces. The DDR3 and DDR4 formats, the Hybrid Memory Cube, hybrid persistent DRAM, high-speed SPI NOR flash, MLC and TLC flash and XDR/mobile XDR memory technologies all are targeting higher performance and capacity in a fixed power level. The goal is maximizing the performance/power ratio.

The diversity and quantity of content being made is driving these architectural advances, along with the firmware and operating system software that control them. These changes are now being brought to market on 18-to-24 month time frames vs. the 7-to-8 year cycles that were in place from the end of the 1950s through the 1990s.
Flexibility to new ideas, and most importantly, understanding and investigating the subtleties of this media content, are the keys to market penetration and an entrenched lifecycle for components. The standards generation cycle is too slow to be a driver for today’s world, and leaders in these markets need to embrace, review and get involved in both the content creation and playback spaces to effectively design next-generation IP and systems.

By Ann Steffora Mutschler
Skyrocketing software development costs, which for years have been “somebody else’s problem,” are now firmly part of the SoC development teams list of headaches. That has made virtual prototyping far more popular, particularly at 40nm and beyond, where engineers are looking at this approach as a way of managing complexity, doing architectural exploration and even performing very early functional verification using abstract models.

These models are meant to provide the design team with a view of the device and its environment at varying levels of accuracy, depending on the user requirements. The hardware model can then be executed within the virtual platform with device drivers to enable concurrent hardware/software development, rather than waiting to write the software until after the silicon came from the fab.

“We see customers going through this interesting next leap of adoption,” said Steve Brown, director of product marketing for system design and verification at Cadence. “Our perspective is that the market has experimented with commercial virtual prototyping tools for the last several years, and through that process the normal discovery of the real requirements has been going on. What I see happening is a real breakpoint where the problem the customer has is now so significant that they are rushing almost in desperation to find anything that can help them with the problem of software and multicore, and the set of challenges that come with that.”

Looking at how virtual prototyping is used today, Marc Serughetti, director of product marketing for virtual prototyping at Synopsys noted, “You have to go back to where the value is. Where does it make sense? What do you get out of those virtual prototypes? If you look at the range of customers we are talking about, the first group of customers—the semiconductor companies—this is where it starts. Especially in markets like wireless and consumer you really have a lot of pressure on the timeline, needing to make sure that the software is going to run fine on the hardware. The whole concept here is starting my software development much earlier. In semiconductor companies that means before any form of RTL is available. That’s really the starting point for all of this—doing software development earlier.”

Earlier doesn’t just mean shifting the development schedule to start sooner so you can finish on time. It also means finding ways to increase efficiency of the software development because the hardware platform complexity is growing, the software content is growing, but schedules are not shrinking.

Some users build their virtual prototypes themselves, but there might be a split within the customer community. For example, a modeling group may be involved in creating the virtual prototypes while an internal set of consumers such as the software engineers within the company actually use it.

“There are various ways of how a virtual prototype gets created,” said Shabtay Matalon, ESL market development manager at Mentor Graphics. “They can be created within a company, they can be created in a partnership between a company and an EDA vendor, but there is clearly a separation between those that are involved in the creation process and those that are on the software side that are using it, which usually are not involved in the creation process.”

Bill Frome, virtual platform manager at Texas Instruments, noted that his company has been leveraging virtual platforms for a number of generations of chips starting back to OMAP 1 days and now currently in OMAP 5.

“The focus has been on leveraging that time from pre-silicon development so we can begin verifying our software and more of our functionality before we actually get to silicon. Like a lot of companies we’ve got shorter and shorter cycle times as far as getting customers into production, so we are seeking to leverage that virtual platform to get more software running sooner to reduce cycle times. That’s really a key for us,” Frome said.

TI has been partnering with Synopsys on its virtual platform development to create the platforms. In some cases Synopsys develops the models for TI and in others TI develops the models. Then Synopsys does the final platform integration and turns it back over to TI.

“There are some other third parties that come in there as well including ARM,” said Frome. “We essentially take that final platform and then internally, we unleash our developers on that to where we can actually boot software on there, begin running some of our use cases before we get to the silicon level,” Frome continued.

Throughout the process communication is critical. Frome noted that there is definitely a communication path as far as when the architects are developing the specs. The specs are shared with the users so they can understand what that model is intended to do. Then, as a model is created, there is a feedback channel because the engineers developing the models may have questions about specific details. The final level of communication involves verification, when the models are actually being utilized.

“What we’ve seen is if we have really well written specs and there is good communication between the architects and the model developers, by the time we get to the final model, that usually goes fairly smoothly—it’s more a clarification,” said Frome. “There will be some updates that need to happen but they are fairly minor in nature at that point.”

Rules of engagement changing
None of this is done in a vacuum, however. The rules of business engagement are constantly changing. Kurt Shuler, director of marketing at Arteris, says some cell phone vendors that design their own chips are now providing requirements to their semiconductor suppliers. “They are communicating very specifically to the chip provider about the specific requirements and they are in the process of using the platform architect-type tools to say, ‘Here’s the scenario, give me a model of your [chip] and I will tell you back what changes I want you to make to your hardware to make it better for me.’ That is a totally new thing.”

Marc Serughetti, director of product marketing for virtual prototyping at Synopsys confirmed this activity. “There is definitely some of this happening. And that happens not only on the software side, but on the architecture of the SoC, too. They want to give feedback as early as possible in terms of making sure that what they have as software will run efficiently on the hardware they are getting from the semiconductor company. So we are definitely seeing this request going back and forth. One reason is to make sure the hardware and whatever software you’re getting from the semiconductor maker meets your requirements, but also to start developing that software earlier. In some markets, like consumer and wireless, it is so competitive that a two-month difference can be huge. The earlier they can start, the better.”

Some go as far as saying these business engagement changes are exactly why ESL is happening now.

“This is the key reason ESL and virtual prototyping is becoming a reality now,” asserted Mentor’s Shabtay Matalon. “In the current level of competitiveness that exists in the marketplace and the complexity and the amount of software that is embedded in each one of those devices, the software people don’t want to be treated as the afterthought in the design cycle. The only way that they will become part of it is if they get models not only before the boards are done and before the processors are fabricated, but even before the RTL is implemented. As soon as they know there is a set of processors that are in the works, they want to participate. They are putting significant pressure on the semis to give them early models of their designs even before RTL is solidified so they can influence the RTL.”

Drew Wingard peels back the covers on dark silicon, the next big thing in semiconductors and what’s needed to get there in a candid discussion with System-Level Design.

Software development is becoming the dominant cost factor in electronics design. The ability to parallelize the traditional sequential process of software development trailing hardware development is crucial to get products to market as early as possible. Virtual Prototypes are introduced as an effective development instrument for software driver, middleware and OS development. Using an example of the Synopsys DesignWare® Cores Hi-Speed USB On-The-Go (HS OTG) controller, this paper demonstrates how the specific challenges in software driver development of complex IP blocks – early availability, visibility and control – can be addressed with Virtual Prototypes.

This white paper, from Synopsys’ System-Level Solutions group, provides a quantitative summary of the gains realized in Synopsys’ USB OTG driver development project through the use of Virtual Prototypes, as well as an outlook of how to apply the lessons learned from the USB OTG driver development to other connectivity IP such as SATA, Ethernet, DDR2 and DDR3. To download this paper, click here.

By Ed Sperling
There are two schools of thought in designing complex SoCs. One says that increasing complexity requires a higher level of abstraction. The other says providing enough detail to get the design right is the only effective way to do it.

There are staunch proponents of both approaches, but what has been missing are bridges to tie the higher level of abstraction to the more laborious—and much slower—gate-level details. Tools that allow more exploration on both sides are beginning to emerge, along with a recognition that they are definitely necessary to complete designs.

These bridging exploratory or path-finding approaches rely heavily on what-if questions. What if a certain piece of IP was used next to another piece of IP, for example? Would a different IP block work better? How about if the frequency of a core was changed or a different I/O was used? And what happens if the voltage in one area is lowered or raised?

These kinds of tradeoffs are common, but increasingly each step of the way can update other pieces along the design flow. At 45nm and beyond, there are many of these kinds of tradeoffs, and the number increases dramatically at 28nm and in 2.5D and 3D structures.

“There are some path finding methodologies available today,” said Riko Radojcic, director of engineering at Qualcomm. “The part that is missing is incorporation or spatial awareness into these methods and tools, which is why it is especially important for 3D exploration. I started feeling the lack of this capability when we first looked at the tradeoffs between regular ‘complex’ design rules and ‘gridded’ design rules, and when we were looking at the tradeoffs associated with aggregating memories into a smaller set of larger instances and equipping them with redundancy versus having many small instances all over the place. In both cases we needed spatial awareness that was not easy to import up to the SoC level. “

Help is on the way
All of the major EDA vendors see opportunity in path finding at the architectural level and early in the design process. For one thing, there is already market demand for these kinds of tools among their largest customers. For another, these kinds of capabilities can be added into existing tools, so even though the development work is difficult it’s not the same as developing and marketing new products.

“The conflict on the design side is between design complexity and schedules remaining the same,” said Gal Hasson, senior director of marketing for RTL Synthesis at Synopsys. “To make matters worse, many designs are done by geographically dispersed teams. Once the RTL is complete the constraints might be way off. So you clean up the constraints, and based on this data you check whether the design is likely to meet the requirements of area and clock speed. Many times the answer is ‘no.’ This is the big challenge we’re wrestling with, and it’s causing designers to re-think the flow. You need early exploration that enables RTL and constraints to get a detailed analysis.”

The addition of software development only complicates things further.

“It used to be one architecture on a spreadsheet,” said Shabtay Matalon, Mentor’s ESL market development manager. “Now there’s an architecture team and companies are bringing in people from different disciplines into that team.”

Matalon said it’s still possible to build everything using SystemC and TLM 2.0 models, but those models require additional tradeoffs to be analyzed. Rather than starting at functionality and then moving onto timing and performance, power has to be analyzed from the outset. And then it all has to be tweaked and reanalyzed as part of the exploration process.

“As you go through the refinement process in a design you have to recalibrate your initial assumptions,” Matalon said. “The number of ‘what ifs’ and the dimensions of exploration are exploding as we move to multicore. And then you have do deal with another dimension of how you achieve performance and power.”

Where bridges are needed
One of the most important areas where this kind of bridging is necessary is in the hardware and software arena, which may be one of the hardest areas to fix. While tools are available for prototyping software, the real-time links between hardware and software design changes are sparse. From a chipmaker perspective, though, these are part of the same thing.

“We don’t see hardware and software as separate worlds,” said Bill Bench, senior director of the WLAN Media Business unit at Broadcom, which is designing wireless video chips. “You can’t do hardware without the software.”

Bench said what Broadcom also finds important for engineers is a deep understanding of cores, the electrical characteristics of a particular process node, and the availability of the right libraries. “What’s most important is that engineers are paying attention to these problems. We expect that EDA tools will mature over time,” he said

Another trouble spot is in the mixed signal world, where different engineering teams can lead to power problems and proximity effects that can impact signal integrity.

“We need to break down the silos,” said John Stabenow, group director for customer/analog design management at Cadence. “At 28nm the SoC is still distinctly divided into digital and analog. We need to bring more and more intelligence into layout at the designer’s desk and be able to abstract an analog block. The challenge is that the schematic has to wait for the layout engineer to complete the job, but there are layout-dependent effects that can impact circuit performance.”

Starting at the beginning
A common theme that runs through all of the current thinking in EDA and system-level design these days is that complex design is best addressed at the architectural level and very early in the design phase rather than later in the design.

“There is very limited opportunity to go back and change a decision,” said Ravi Varadarajan, an Atrenta fellow. “If you change a decision because the chip is not feasible, it’s a very long and painful process. The best way to avoid that is to explore more at the front end. And if it’s important in a 2D chip, it’s a necessity at 3D.”

This is easier said than done at advanced geometries, where process rules are constantly changing, process variation is higher, and even some of the structures are likely to change. At 20nm there almost certainly will be some double patterning required. At either 20nm or 16nm designs it’s also likely that designs will begin to incorporate transistor structures such as FinFETS. How those will work with new types of memory and at a variety of voltages is unknown, but it’s almost certain that all of this will require far more exploration than existing designs.

“But even in the early stages the exploration has to involve fundamental techniques that correlate to the back end,” said Varadarajan. “You still need to set up constraints and test against those constraints.”

Conclusion
Simplifying the complexities in a complex design process will probably never be complete. It will be a long-running process of development. There are simply too many variables and tradeoffs, and at advanced nodes and in stacked die those tradeoffs can have much larger effects than at older nodes. Some of those effects are physical, some are electrical, and many are business-related.

But it’s also clear that preventing problems at the front end can avoid many problems at the back end if there is a better understanding of all the factors that go into make a design work. At the very least, awareness of this problem is rising, and some of the tools that have hit the market over the past year are a reflection of that. Still, far more work needs to be done for the industry to continue progressing along the Moore’s Law road map and into 2.5D and 3D designs.

System-Level Design talks with Bob Bluth of the Naval Postgraduate School about UAV design and debug challenges–and what’s inside of these devices. (The blue and green cellophane tape seal some of the access points prior to delivery–and the directions).

By Ann Steffora Mutschler
While much has been achieved to define a system-level design flow, more is still needed. Technology goals vary depending on the perspective of tool providers in terms of what needs to be done to realize the promise of a streamlined tool flow from TLM 2.0 down to GDS II.

To many, 2011 will be an interesting year in the system-level design space as conversations with customers have shifted. “For the last two or three years, the conservation has been, ‘What does it mean to go into high-level? What languages will be used? What technologies?’” said Michal Siwinski, group director for product management in the system realization business unit at Cadence. “It was really a conversation about what system-level design would look like. Now, the conversation is shifting pretty aggressively into what it is, what it means, how to deploy it and how does it work as an integrated environment in a continuum of solutions from specification to manufacturing.”

For Cadence, that has been captured under the umbrella of the TLM to GDS flow. “We’ve made sure that everything we do, from whatever we do as an extension into high levels of abstraction both on the design and verification sides of hardware/software coordination, has to be linked into how the end implementation is done. We have to solve for the inherent discontinuity that exists in the fact that people today do something at the system level, throw it away, and then they start on the implementation side,” Siwinski said.

Similarly, companies such as Mentor Graphics have invested heavily for years in systems design both in R&D and acquisitions, and 2011 will be no different in that area. The company intends to maintain its high level of investment as customers require more design technology to beat their competition, said John Isaac, director of market development for the company’s systems design division.

Mentor also will invest in increasing the productivity of its core PCB systems design and analysis capabilities. “We understand that product design requires collaboration and effectiveness in many disciplines: IC/package/FPGA design, mechanical design and analysis, the smooth transition from design into manufacturing and the optimization of the manufacturing floor. We will invest in continuing to improve the entire product development process,” he said.

For others like network-on-chip provider Arteris, 2011 signals a focus on relationships. “We’re working on really tight integration with FPGA vendors and emulation vendors. We’ve done a lot of work with EVE and our common customers to make it really easy to take a huge ASIC SoC design and easily ‘port’ it over to a multi-FPGA emulation server (Zebu server). We’ve also worked with ENSTA (a French university) to push the envelope on network-on-chip size/complexity on FPGAs,” explained Kurt Shuler, director of marketing at Arteris.

Arteris is also working to make it easier to “plug and play” IP. The interfaces are there, but IP-XACT descriptions haven’t been detailed enough. Moreover, the customer must be involved since they all do the descriptions differently. In this regard, the company is working with Duolog and joint customers to be able to easily stitch or weave together IP for an SoC.

Further, Arteris is working on tighter integration with Synopsys’ broad system-level product line, which includes key technology from the company’s Virtio and CoWare acquisitions. Shuler noted that Synopsys is an investor in Arteris and the two have many joint customers.

For Synopsys, customer requests fall under two main categories: individual tool improvements in the five areas of system-level design (algorithm design, high-level synthesis, architecture design, virtual platforms and processor design); and flows, said Frank Schirrmeister, director of product marketing for system level solutions.

In algorithm design, Synopsys’ products have been in the market for 20+ years, noted Johannes Stahl, director of marketing for system-level solutions. “So you could say it’s a boring market, but actually it’s not boring because what customers are doing with the tools these days is super complex with hundreds of thousands of lines of C code, and models that they simulate mostly for complex wireless design. Our task list is very simple: Keep the capacity up so the simulation engine improves the speed, and improve turnaround times for simulation.”

Stahl pointed out that the most exciting piece of technology in the high-level synthesis space came with the acquisition of Synfora. “What we see from customers is that they’ve all done high-level synthesis in one way or another, but for many of these customers they’ve started at too low a level, based on the technology restrictions, so the earlier we synthesize from a very high level the more we can save in terms of verification time—which is what high-level synthesis is fundamentally about. If you start very high, you save the most. You also save the most in terms of not introducing any bugs because you don’t code at a detail level.”

Then, on the architecture side, users are asking for as many architecture analysis capabilities and models available out-of-the-box as possible. What that means in the world of architecture is that a lot of it today is interconnect-driven. As Arteris’ Shuler noted, the two companies are talking about how to connect their technologies. Synopsys also works with industry leader ARM on its NIC-301 fabric to connect things, Synopsys’ Schirrmeister said, “and we have tools to support that from the architecture analysis side. That’s a whole question of how the software splits, how the bus bandwidth, how the latencies are done. We need to make sure our tools interact with other vendors.”

On the software development/virtual prototyping side, customers are asking for an easy way to create virtual platforms and to make sure the use of the virtual platform as versatile as possible. Synopsys acknowledges that it all comes back to the models underneath, so it will work to make sure that the relevant models are available out of the box in its libraries, in application-specific areas such as automotive, consumer, wireless, he continued.

Then, in the area of flows, Synopsys is looking at how individual product components fit together, how flows interoperate with other vendors and with other tools and methodologies both before they think about system level design (pure software) and then after they’ve done system level design in hardware implementation, Schirrmeister added.

From Atrenta’s perspective, the company will be focusing on IP quality and integration readiness in 2011. “More and more IP will be delivered in synthesizable form. How do customers know what they’re getting, and how can they determine, up front, how all this IP will work together?” asked Mike Gianfagna, vice president of marketing. “Second, we’ll be working on new tools and methods to help assemble IP to create the correct architecture. Knowing you’ve got it right as early as possible will make a huge difference when it comes to implementation and embedded software development.”

Finally, with the big push toward through-silicon-vias (TSVs) and 3D packaging, a lot of activity is expected in this area, added Prasad Subramaniam, vice president of design technology at eSilicon. Other areas on eSilicon’s radar for 2011 are multicore designs and power management. “For multicore designs, how can one come up with the best architecture that will optimize power and performance? Power management continues to be a significant area all the way from architecture to implementation. How can a designer make tradeoffs in determining the appropriate power management technique?”

By Ed Sperling
Verification has always been the problem child of SoC design. It requires the most engineering resources, the largest block of time and the biggest budget in the design process. And at each new process node the problem gets bigger, in part because there is more stuff on each die—transistors, memory, interconnects, I/O, functionality—and in part because chipmakers are being called upon to generate more software, integrate more IP and do more with the same resources.

It has long been suggested that the best way to improve verification is to start the process earlier, understanding what needs to be verified as far forward as the architectural level. But that requires much more cooperation and understanding of what’s really going on in verification.

There have been different approaches to try to make this happen. Synopsys, for example, has pushed heavily into software prototyping. Mentor and Cadence have pushed into emulation and high-level synthesis (Synopsys is now in that market, as well). But so far, in part because of the sheer magnitude of the problem, the best that can be said is that the industry is treading water instead of washing downstream.

So why haven’t companies adopted new approaches to solving this problem?

“There is actually a fair amount system-level verification that is being done today,” said David Park, director of marketing for the System-To-Silicon Verification Solution at Synopsys. “The perception that system-level verification approaches are not being widely adopted is more due to a lack of prescribed flows at the system level than an actual lack of customer usage. At the functional level, there are well-defined verification flows based on methodologies like VMM and UVM, but at the system-level those methodologies are not well-defined today which results in ad hoc flows. Even customers at the leading edge have different views on what the right methodology should be.”

The results so far are largely trial and error, and the error most likely will outweigh the results. But Park believes that eventually best practices will emerge and baseline methodologies will be developed, evolving out of the many collaborations that are already ongoing between customers and tool providers.

Strategies and challenges
To say that verification isn’t getting done effectively is an overstatement, considering the vast number of advanced electronics products rolling out in the market every week. Synopsys has done as well, if not better, than any of its rivals in this incredibly complex system-level approach. But there is certainly room for improvement and opportunities for new tools across this segment.

“Systems are being designed and verified, but there seem to be two primary challenges,” said Bernard Murphy, CTO at Atrenta. “One is having a simulation sufficiently faithful to the design but sufficiently fast to run application-level software. The second is having a platform-plus-OS partitioning also sufficiently accurate and sufficiently fast to (somewhat) exhaustively test critical behaviors, for example, around mutexes and semaphores.”

There are a number of approaches for each, but none is ideal. Emulation on a commercial or custom FPGA board, for example, makes it tough to partition the design onto multiple FPGAs. While this is the most flexible approach, offering acceptable performance, it also requires a lot of effort in the area of debugging mapping problems rather than design problems, Murphy said.

A second approach is simulation on an emulation platform, which is expensive and culturally unpopular on the software management side. While software engineers will readily use an emulator, they are averse to paying for one. All of the major emulation vendors say their sales continue to come from the hardware side even though software engineers routinely schedule time to use the emulators.

A third approach is to simulate using a TLM-compliant virtual model with the ability to hot swap cycle-accurate models for the virtual models, especially if the cycle-accurate model can be derived from RTL. “You use a pure VM to get through the OS boot, but then swap in cycle-accurate models to verify behavior for individual IP,” said Murphy. “This is accurate but still very slow and painful to debug accurately across multiple IPs.”

Having a platform plus an operating system working together is a step in the right direction, but it doesn’t expose all of the problems, either. “This is heavily dependent on the architecture,” Murphy said. “Some systems have support in hardware, such as spinlocks, but will also have some low-level software support. This level of verification seems to be performed mostly with traditional simulation but needs support for assembly or higher-level instruction primitives to efficiently describe tests.”

Synopsys’ Park agrees that the next step for system-level verification is to bring all these pieces together with links to the existing RTL verification tools so that customers can assemble a verification flow that meets their specific needs. “The real breakthrough will be when a customer can seamlessly transition between a virtual platform to an RTL or hardware-accelerated representation of their design to support the different combinations of system accuracy and performance that is required to support both hardware verification and software development teams.”

One-On-One with IDT CEO Ted Tewskbury: How IDT is bridging the analog and digital engineering worlds with a mixed-signal team approach.

Can startups still survive in an increasingly complex, high up-front investment world? System-Level Design posed that question to Mentor Graphics, Synopsys, Oasys and an end user.