By Ed Sperling
System-Level Design sat down to discuss electronic-system-level design with Stephen Bailey, director of emerging technologies for the design verification technology group at Mentor Graphics; Michael McNamara, vice president and general manager of Cadence’s System-Level Division; Ghislain Kaiser, CEO of DOCEA Power, and Shawn McCloud, vice president of marketing at Calypto. What follows are excerpts of that conversation.

SLD: As power becomes more of a consideration, both with more third-party IP and what is considered mainstream design moving down to 40nm and beyond, will the companies using ESL change?
Kaiser: It’s not a just question of power consumption. It’s power consumption and power techniques and implementation in software and hardware. The ideal flow will have at the system level some tools and methodology to analyze and estimate power very quickly, and then to have implementation down to the silicon. Unfortunately that’s not possible today. Nevertheless, there is interest to explore power and implement power using a refinement methodology for meeting the power budget in a design flow and making decisions earlier. One part is to implement power reduction techniques and to keep consistency between the system-level definition and implementation. That’s the first phase of UPF/CPF. We need to move this standard to a higher level. For the software part, we need to make sure that is well captured at the system level and implemented in the software development phase. The main system level goal for power is to define the critical use cases for power and the most efficient implementation. We have to look at the ‘V’ cycle process flow. The system level is in front of the validation of the system. What is missing today is, when customers get back their silicon how is it possible to validate the power consumption? They run the software, measure the power consumption, and get maybe 500 milliwatts. Is it correct? Do they have some bugs? They’re working blind. The information should come from the system-level design.
McCloud: There’s a reason why the power of the actual subsystem on the chip is very critical. It’s not just a question of battery life. It’s also thermal integrity and power and supply integrity. As we pass 45nm it’s very difficult to scale your supply voltage to reduce power. If you don’t do anything, you’ll see a chip that has four times the number of transistors and four times the amount of power in the same die space. That would be impossible.
McNamara: That was the death of a processor at one large company. There was too much power density.
McCloud: It becomes critical from a thermal perspective. Your chip is going to burn up or you’re going to have supply dropouts and the chip will ultimately fail.
McNamara: It’s a matter of getting the power there and the heat out. Even if the chip survives, you don’t want to burn the hand of the person holding the phone.

SLD: So with growth of third-party IP, does it change system-level design?
Bailey: The way I see the market going, there already are 2.5D devices where there are hardened 2.5D platforms. Xilinx, Altera and Microsemi have products in this area. When you look at the economics involved, this opens the door for a lot more companies to get involved in electronic-system-level design than before because they don’t have to hire and spend millions of dollars just to get the chip out, let alone any of the software. Even if it costs them $25,000 to $50,000 for leading-edge chips at the latest process nodes, that’s nothing compared to the millions of dollars it would have cost them to engineer that up front. They can focus on a small amount of differentiating logic or just software. It’s a much lower cost for NRE, so a lot more companies can afford to be startups and try to do something innovative. They can take these chips into consumer markets and new market-specific applications.
McNamara: The Zynq platform from Xilinx is one of them. We’re working with a company that will use those in scanners for inventory. You only need a thousand of these. But now you can build a fully customized device with volume 1,000 for no NRE. You’re basically buying an FPGA SoC. Now you can do system-level design with that and determine what goes into software, what goes into the FPGA, and what goes into the peripherals.
Bailey: You might have some custom peripherals on there and maybe an accelerator block.
McCloud: We see a similar trend between early production in FPGAs and volume production in ASICs in Japan. They’re making very high-end TVs in low volume. The consumer market is all about time-to-market, which may be a six-month development cycle. ASICs can take a long time, so they’re doing early production with FPGAs. HLS makes this possible. It’s the same C/C++/ESL model being used to go to the FPGA for early production and then re-targeted for an ASIC.

SLD: What standards are necessary in the short-term to make all this work?
McNamara: With transaction-level modeling, we need version 3.0. One of the big missing pieces is the separation of communication from computation. If there’s a standard way of representing a communication port that I can model, that would be useful. The virtual platform can be just a pass-through, with no need to model it. When it’s being synthesized to logic, you’re using the OCP bus or AXI or Amba 3. There are different choices for the communication. That should be something you just swap in or out for doing the calculations. You want HLS that can work with a communication model and a computation model as an ensemble, that has all the details you need of the protocol. That’s important for the next level. When you go from the transaction level to RTL, you have to get to signals and wires. You don’t need to model the signals at the transaction level. It’s just a block of data. That’s one standard that’s need. The other thing that’s needed is a way to extract power from the lowest level and represent it at the system level. There are two aspects to that. One is, what is the cost of an ‘and’ operation on an A9? What is the cost of a divide operation? You can do some software profiling to get the cost of power in the processor cores. Then there’s the other bunch of logic that is an MPEG-3 or MPEG-4 decoder. How do you represent the power in a way you can trade off designs in a way that is more than ‘A’ is better than ‘B’? We have to improve on 30% accuracy. We also have to pull in software. We’ve talked about software as a user of power. What about software shutoff of a radio? And there’s some other software that’s not aware it’s shutoff and is dependent on data from this radio. There’s a correctness modeling that needs to be there.
Kaiser: The power needs standardization at the system level to capture the power behavior and the power interface with the software and the hardware. You need to keep consistency from the system level to implementation, taking into account exploration and software and hardware implementation. Those are the three topics that need to be considered in hardware standardization.
McCloud: TLM 2.0 is certainly in the right direction, but it does need further standardization around power policies and performance policies. We need a better way to standardize moving power up to the ESL level. UPF and CPF have to move up to the ESL level, as well. There needs to be some progress in that direction. And we need to do a better job of connecting these point tools in a flow, even if that means going across companies. We have great point tools. How do we bring those together to create an overall ESL solution?
Bailey: I chaired the UPF committee through the first couple of revisions. UPF definitely could be used at the TLM level. In addition, there will be continued innovation and new bus fabrics on SoCs. GALs (generic array logic devices) will grow in use, and that will create new on-chip bus structures. There will be new interfaces external to the chip, as well. You’ll see more standardization pushing up into the software levels of these protocols so there is less to change in software stacks because the underlying hardware protocol will change. The other thing in standardization is that with the move up in abstraction, verification will move up in abstraction beyond that. You can’t have verification at the same level of abstraction as HLS or TLM. It has to move up further. You’ll see some standardization in verification, as well, beyond UVM and OVM. People need to know what to test, to make sure they’ve tested what they want to test, as well as being sure their results are correct. That’s what verification should be about, not writing testbench plumbing code.
McNamara: There could be a stage of having a testbench language for TLM, and there are efforts in UVM to address that, but the real leap forward is testing the hardware/software system. If I’m supplying IP, today that IP has a driver. Sometimes it’s fairly large. If you look at memory IP, there’s a lot of software that comes with it. How do you not just verify the hardware, but also the software to make sure there are not any deadlocks in these device drivers? And then you need to eliminate deadlocks between these devices and IP you’re buying from other people.
McCloud: One of the biggest challenges we hear about is unpredictability of systems. You’ve got RTL, software and you upload it on emulation That’s very late in the design process. You need to pull that forward and verify the software and hardware and all the pieces working together.
Kaiser: Anticipating issues is key to the system level. But being able to keep the flow consistent, and being able to provide information from the system level to implementation teams for power consumption to have guidelines and specifications earlier is a problem if your specification is frozen at the RTL level. Your planning is impacted. If you can freeze your specification earlier you can get the specification closure earlier. That’s a key benefit.

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 Pallab Chatterjee
The idea that SoC and system design are a mix of hardware and software, in the form of both application software and firmware, has been in place for more than 60 years. But the emphasis is beginning to shift.

The traditional approach has been to create the highest-performance circuit design, with some control options for flexibility, and then use this adaptable “platform” product in the end application. This allowed for cost savings by re-use of the hardware for multiple designs, and the ability to quick-start programs with custom designs before the finalized specification was in place, as it could be adjusted in software.

This trend continued in to the SoC arena, where standardized designs were created and SoC platforms were developed. The ability to create a logic design with literally billions of gates and functions required a great deal of software to manage. The designs are so large that they cannot be up at one time, and the internal data paths of the design exceed the bandwidth of external bus and memory systems so all the logic processing cannot be done at once. As a result, there is a lot of software control needed to use the correct portion of these SoC platforms at the correct time.

This partitioning between hardware and software has brought with it a number of things. First, it brought the ability for in-the-field updates and feature changes. As the available hardware is known, changing the software/firmware allows for enabling and disabling features. It has been the major driver of the $100M chip. The cost of a large digital custom chip used to be less than $1M and take six to nine months to develop. Current SoCs are now on a 2.5- to 3-year development cycle with control software/firmware development accounting for upwards of $65 million of the $100 million in design costs.

The interaction between hardware and software systems started to shift with rise of mobile devices. Mobile has an unending need for power management coupled with high performance. The trend has been to continue to utilize the platform SoCs and ASICs in a system, but to embed context and application-based power management into the design. This allows for the same qualified platforms and end application code to be used that are in cord-powered products. By selectivity turning on and off functions (portions of the chip) based on what mode the product is in—such as getting a user input, displaying a static graphic and reading an external device—the overall power of the product can be reduced, and the operating time of the device can be extended.

This scheme has worked well. However, over the next year end-application software will take the driving role in hardware architecture. The Linley Processor conference was filled with application-optimized hardware for network and packet processing, multicore and distributed processors for data processing, and communications and security acceleration processors. Companies such as Broadcom even recently introduced high-speed carrier Ethernet products that are simultaneously power- and performance-optimized under firmware control, for both voice (PTN) and data (IP-RAN) network applications. The move to multi-core and distributed CPU/GPU processing has now and forever moved application software to being at the forefront of the design flow and being the optimization criteria for the hardware design.

This concept was exemplified at Oracle World, when several new “engineered systems” were released for the cloud server and core data center applications. These database- and Java-processing optimized servers, supporting the Oracle Elastic Cloud along with the Exadata and Exalogic hardware accelerators, were engineered from the application software down through the rack design, the board designs, the bus backplane selection, to the memory access architecture and processor design to provide the highest possible performance on high user count cloud access processing. These optimized products are the start, and future products like the announced but not yet released Oracle Exalytic query and expression processor are signs that application software is now driving mobile and cloud hardware design.

By Ed Sperling
System-Level Design sat down to discuss hardware and software priorities with Neil Hand, group director for marketing for Cadence’s SoC realization; Johannes Stahl, director of product marketing for system-level solutions at Synopsys; Prasad Subramaniam, vice president of design technology at eSilicon; and Bernard Murphy, CTO at Atrenta. What follows are excerpts of that conversation

SLD: Who makes the money as the value shifts inside of SoCs and devices?
Subramaniam: The system makers still make the money. They are offering value with the software and the whole system.
Stahl: It’s the companies that have unique control points.
Murphy: The guy making the hardware is not necessarily making the money, whereas Google is.
Hand: It depends how you define the system. With Android it may be the ecosystem. But in other industries the system maker may be the ecosystem, like in automotive or medical. People always thought the system maker is whoever makes the hardware, but it’s changing to whatever the ecosystem has enabled.
Subramaniam: The system maker is not just delivering the hardware. It’s delivering the entire solution.
Hand: But one of the changes is that the system maker may not deliver the hardware at all. They may be delivering hardware from other people.
Subramaniam: Yes, that’s possible now.
Hand: Is HTC delivering the hardware, or are they just an enabler for Verizon’s ecosystem?
Subramaniam: And if you look at Apple, they design the products, but those products are made by someone else. But Apple does provide the hardware, the software and all the content. They’re not creating the content, but they’re making it available to you. They’ve created the entire system for their end application.
Hand: It’s the same with Sony. They pioneered that idea after Betamax when they started buying the studios and the content providers. Apple has out-executed them.
Murphy: No one has been able to reproduce the Apple model.

SLD: In the chip world, who makes the money?
Hand: Whoever can deliver differentiation. If you deliver differentiation, people will pay for it. If it becomes a ‘me too,’ no one wins.
Subramaniam: It’s differentiation plus value. Conventional wisdom is that as you go up the value chain there’s more opportunity to create value and you will create more profits.
Hand: We believe there’s a limit of what you can achieve through pure automation of designs, though, which is where IP fits in. For other people it will be the software. Different companies will take different tacks to deliver that value to the end user.
Stahl: It will be companies with a structural advantage, such as TSMC or ARM. They have the scale and deployment in the industry.

SLD: The other side of this is where EDA companies make their investments.
Stahl: That’s why we invest in IP. Virtual prototyping will pay off over time, too. The structural advantage of having enough is very important.
Hand: We’ve invested in IP and the system development suites. We believe the investment is in the SoC and the system, in addition to our traditional business.
Murphy: IP won’t be just hardware. It will also include software.

SLD: So where will the biggest breaking points be in the future?
Subramaniam: Technology is still evolutionary. I don’t expect any revolutionary tools to come out. Maybe with 3D ICs there will be something new required, but even 3D ICs are evolutionary. Most problems there can be addressed using existing tools with some additions. Maybe at some point when Moore’s Law is gone and we’ve come up with a new kind of transistor then we’ll have a new industry for EDA and design. Until then, things will be more or less similar.
Stahl: We’re seeing semiconductor makers growing their software development at a phenomenal pace. The way many companies are attacking the problem is more bodies on the problem, but the more intelligent companies are asking whether you can afford to do software the same way over and over. Do you need to be more methodical and what are the connection points between normal software engineering and the platform? How much can you systematically verify and test? There’s a lot of realization among managers, who now also have to run software teams, that they can apply the lessons of EDA to this business. There’s the biggest potential, but it will be an evolutionary change. We won’t be able to brainwash the software engineers to use a different language.
Subramaniam: The one thing that can happen in software is that with silicon so cheap you can have lots of little processors doing specialized tasks. One of the challenges of software is how to take advantage of all of these little machines in silicon and get the best productivity out of the tools. There is an opportunity for multicore software development where you start with a high-level language and break it down into millions of little problems. This is not an easy problem. People have been trying to do this for 25 to 30 years.
Stahl: People need to be much more conscious of how to validate this heterogeneous system to make sure it really runs, but at the end of the day you have to do more brute force simulation. We cannot afford to wait to start developing software until silicon is there.
Hand: If you look at base stations, they broke those designs into lots of small DSPs, each doing one part of the design chain. That has a parallel today. As the software becomes more and more complicated, it changes from IP to a subsystem that is validated and trusted. It’s tested, good and encapsulated. People don’t violate the rules that are in there. That’s where you get much closer collaboration between hardware and software.
Stahl: Some companies like Ericsson have a discipline of developing large-scale hardware and software. That has to be transferred to the semiconductor large software stacks. It’s a discipline.
Murphy: It’s a little bit of, ‘To a hammer everything looks like a nail.’ If there was a better understanding of the system problem they would realize that turning all the design knobs isn’t as easy as it looks.
Hand: Years ago it used to be easier to fix something in hardware than in software. A semiconductor company doesn’t necessarily look at those tradeoffs today.
Murphy: They know what they can fix. The universe of possible fixes is bounded.

SLD: Using software for specific processors or functions seems to be a radical shift.
Subramaniam: The advantage of having hundreds of processors on a chip may be a little bit wasteful, but it actually saves you power. Rather than one 1GHz processor running at 50% activity you can have hundreds of 100 MHz processors running at 2% activity and burning very little power.
Stahl: I don’t see any of these homogeneous processors in the consumer space. It’s one processor at a time optimized and running all the software. Incremental design tactics won’t allow for that kind of radical shift.
Hand: I don’t think it’s radical. It can happen at an evolutionary scale. Today you have multiple processors handling the baseband and the touchscreen. They do have isolated functions with their own function.
Stahl: But it’s still very heterogeneous.
Murphy: And with the high-end smart phone processors, you design in everything and you either take stuff out or you disable it.
Hand: It’s a tough call even where you have hundreds of distributed processors. How flexible will it be if you can’t break down an application into a bunch of little pieces?
Murphy: Another problem that comes up is in verifying subsystems. You can build a subsystem and test it, but you’re targeting a market window that is short. I haven’t seen many examples of subsystems that are significantly re-used from generation to generation. You’re back to verifying these huge systems.

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 FREE 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
The semiconductor industry is used to looking at changes every couple of years, based upon the progression of Moore’s Law. But look out further, over the next five years when the most advanced process node is somewhere between 14nm and 16nm, and the job of designing and manufacturing an SoC will look very different.

At the center of this change are three very significant trends:

1. Cost increases. It will cost way too much to develop custom SoCs using current methodologies, tools and strategies at 20nm and 14nm, both from an NRE and from a time-to-market perspective.
2. Software plus hardware. Software is becoming a huge part of the chip design, but while hardware design is getting more complex it’s still improving at a far faster rate than software development.
3. Time to vertical markets. Differentiation will be based on the ability to quickly cobble together chips that meet the needs of different markets—either for vertical markets or specific customers—at a reasonable price point.

Derivatives market
One of the biggest shifts will be in the integration of in-house and external IP blocks, subsystems, and ultimately full die into chips—and in being able to create far more derivatives out of those various pieces more quickly.

Freescale, for one, already has embarked on a plan to figure out where it can add the most value in its chip development, which is primarily multiprocessing cores and advanced interconnects. In the future it will buy much of the standardized I/O and memory technology that it built in the past to focus its efforts on core hardware components, software development and integration. Derivatives are a key part of that strategy, and it is emerging as one of the recurring themes across all SoC development at future nodes.

“The cost of all development will go up, so you have to get more efficient by developing simple derivatives,” said Lisa Su, Freescale’s senior vice president and general manager of networking and multimedia. “Silicon design has to become more modular. A lot of the differentiation will be in the software stack.”

She said the challenge is to find translators—people who understand how to bridge the gap between hardware and software. “To build really good hardware you have to understand how the software programming model works. Software drives the hardware.”

Freescale is hardly alone in recognizing this shift into derivatives. But derivatives for a large fabless company such as Freescale have a different meaning than derivatives for a midsized company, which will rely much more heavily on outside service providers such as Open-Silicon, eSilicon and Global Unichip to build these kinds of chips.

“What we’re talking about is not breaking new ground or creating major IP,” said Naveed Sherwani, president and CEO of Open-Silicon. “To really address the cost issue there will need to be derivatives outside of companies, and a lot more more companies doing derivatives. There will be a consolidation in design services, which will be fully integrated in derivative design. Derivatives keep the complexity contained.”

A complex SoC might cost $50 million to $70 million to design at advanced nodes, but 10 or more derivative chips might only cost $5 million to $7 million each. That makes them much more affordable and allows companies to put their dollars where they can best be used for differentiation.

Abstracting up
From a tools standpoint, there needs to be a giant step to another level of abstraction. There simply is too much detail and data to process in a complex SoC that today contains up to 100 million gates, and which in a couple process nodes could contain billions of gates.

“The existing way of doing things will break down,” said Ravi Varadarajan, fellow at Atrenta. “Design closure is still being done at the place and route level with power estimation. That needs to be raised by a level of abstraction. With a higher level of abstraction you can do more with less effort. This has been a long time coming. We need to elevate this process from the gate level and RTL so we can put together a system. I was speaking with one customer that put together a complex SoC. It took them 1-1/2 to 2 years to close the chip. They were going back and forth over whose problem it was.”

He added that will become particularly important in 2.5D stacking, where integration will have to occur at the subsystem level. But whether a high-speed bus or a low-speed bus is used to connect those subsystems, all of that should be transparent to the designer. Similarly, exploration at the SoC level should allow changes in memories that are used to connect to multicore processors that are reflected in other parts of the chip architecture.

There is almost universal agreement about the need to raise the level of abstraction. The question is when, by whom, and whether that abstraction level will include enough details to be useful—particularly when making architectural tradeoffs about such things as different memory configurations, power measurements that are useful, and how that will work with an increasing amount of third-party IP. Block re-use is expected to increase to more than 70% of an SoC design in 2015.

“One of the main technology challenges is block design and re-use,” said Frank Schirrmeister, director of product marketing for system-level solutions at Synopsys. “The main issue there is integration. From the technology side we need to figure out connectivity. We can take care of the registers at all locations, and then you’ve got companies like Arteris, Sonics and ARM that are addressing how you put it all together. But you’ve got lots of blocks and assembly of blocks.”

Those blocks increasingly are being assembled into full subsystems, too, which are beginning to show up on the market complete with software drivers.

Software first, software last, software everywhere
Software is a complicating factor, though, rather than a simple solution. While there has been lots of discussion around the challenge of getting hardware engineers to talk with software engineers, there has been far less discussion about just what each piece of software code should do in designs.

One of the reasons is that there is no simple answer. It all depends—on the market, the device, and what is the motivation of the companies developing the chips. Are they looking to maximize performance, minimize power, or simply build lots of derivative chips that can function using the same basic hardware.

“There are different ecosystems forming,” said Jack Browne, senior vice president of sales and marketing at Sonics. “Before you might partner with Wind River and Monte Vista. Now you partner with the application developers.”

What this means for chip designers is that it’s no longer a closed world. In the past most chips were written to specs that focused on performance, process technology, power budgets or some other well-defined set of rules that were largely hardware-specific. In the future those boundaries will be far less well defined and they will need to be modified quickly based upon individual markets. Software is one way of doing that, providing the hardware can take advantage of the software.

There has been a fair amount of discussion already about devices being software-first or hardware-first, with some engineers and companies taking a middle position saying there needs to be a better bridge. In the future the decision of how software is written may include everything from popular applications, use models, vertical and regional markets—as well as all the old rules.

“In the mobile world, where you have Google TV and Android running on high-performance platforms like MIPS and ARM, that’s where application-specificity comes in,” said Synopsys’ Schirrmeister. “In the automotive world there’s AUTOSAR (automotive open system architecture), which separates the software from the hardware so you can control the whole stack from the hardware to the software. The challenge is which version you’re on. Then you’ve got the semiconductor manufacturers and IP providers doing things like Linaro on the Linux side to make sure the right platforms are supported. “

Business effects
While the technology and process changes are significant, they are at least better understood than how that technology will intersect with business. Chips will still be built. More components and services will be outsourced. The price will be more affordable to some, less affordable to others. And software will have to be written more quickly and verified more easily than it is today.

Where things get fuzzy, though, involves who is best positioned to take advantage of these changes and who will reap the lion’s share of the rewards for getting the formula right.

Sonics’ Browne says the market has split into small chipmakers that want to push the leading edge of performance and/or low power, those that are looking for a unique volume play in the consumer electronics/smart phone market, and those looking to break into new markets such as portable medical devices once the price point drops low enough.

“The question is how quickly you can do derivatives, or whether you can compete with the old superchip approach,” noted Browne.

Freescale’s Su has a similar take on the market. She said the goal is to start with a platform that can bridge many end markets, then customize it for specific uses. “We’ve been working on ARM-based products that can be used in auto infotainment as well as industrial and medical markets. You start with a general processor as a test chip and then branch off from there.”

But who wins from those designs, and who ultimately loses is unknown at this point, and while design and development will be built on years of evolutionary changes, the business ramifications of those changes are far less obvious.

By Ann Steffora Mutschler
As product design evolves to contain more and more software, that software—including the applications that run on the device—is now starting to drive design and process requirements. This change is causing ripples throughout the semiconductor industry, driving evolutionary thinking about where to go next.

OEMs have taken notice of a new dynamic and want to capture the same kind of continuous revenue stream that Apple has pioneered with its devices: the iPhone, iPod and iPad.

“Looking at Apple from a business model perspective, the dollar is moving uphill, the value is moving uphill towards the application, however to enable that Apple is using the hardware and the operating system as a locking mechanism to extract revenue and customs from it,” said Frank Schirrmeister, director of product marketing for system-level solutions at Synopsys. “There is a channel to Apple’s hardware device. They own the channel. They define the channel and they extract the 20% or 30% fee that application developers have to give to Apple.”

Ironically, Apple is leveraging the hardware and lower-level software, including the OS, to achieve that level of ownership.

“From a design perspective, it is actually that gateway—the operating system—which is tied to the hardware which enables that. So it’s not necessarily the application defining the hardware, it’s the hardware enabling the application. From a design perspective, what the hardware developer has to do today if they define a platform as Apple is defining the iPhone as a platform. They have to define it wide enough so that it can serve a variety or number of applications but it’s not essentially yet at a point where the application is defining the hardware,” Schirrmeister said.

To many, application-driven design today means there is a well-defined platform and the design engineer has done their homework to understand what type of applications the platform needs to support.

“It is conceivable that at [some] point, the platform [will be] so broadly defined like a multiprocessor platform that you can then automate this notion of configuring the hardware to meet an application. What that means is the approach which is concurrent compilation: you take an application and split it up, and you automate how it is implemented on a given hardware piece. But that is really a software-related design flow where the application is driving the implementation,” Schirrmeister continued.

EDA’s changing role
With these dynamics in play, EDA vendors are striving to chart a way forward.

“EDA companies help you get from RTL to silicon, but all of their customers are saying, “That isn’t the problem. The problem is I’ve got algorithms in software that are driving my platforms. How are you helping me with that?” said Simon Davidmann, president and CEO of Imperas, and founding director of OVP. “The customers are saying those are correct [virtual platforms and system-level design techniques] but actually it is a bigger problem – software is driving it. I absolutely believe that it is the software that is driving things, and it’s not driving it from a naïve point of view—you have to know what type of platform you are running on and the type of performance it can give you. For example, if you are building a device, someone might say it’s got to have Android. That defines the complexity of the platform you’ve got to build, it defines the performance of the processor you’ve got to use—and it probably points you in the direction of one processor or another.”

Ideally you want tools that allow you to do the tradeoffs with virtual platforms a key piece of the technology needed, but don’t panic, Davidmann advises. All of the pieces to this puzzle are not going to come together overnight. “With all of this, there has to be a learning process that we all have to go through: the tool providers, the methodology providers and the customers that will adopt it. It’s not something that’s going to happen overnight – it’s going to take several years but the great thing is that people are beginning to understand it is the software. The world is moving to understand this but I don’t think anybody has all of the answers as to how to solve it.”

While the specific tool flow of the future is not clear as of yet, Cadence clearly articulated the issues earlier this year when it announced its EDA360 vision. At the heart of this is looking at how design has to change with general purpose SoCs and processors often not fitting the bill any longer.

“The biggest thing is always volume,” said Steve Leibson, marketing director and EDA360 evangelist at Cadence. “The high volume applications fight for every penny to reduce the unit cost of the SoC. The only way to do that is to optimize the SoC for the particular application so you’ve got to start with the applications.”

One of the most interesting changes propelling this vision is the rise of the Android operating system, which Leibson highlighted has “skyrocketing into prominence and is causing the coalescence the embedded industry around far fewer number of operating systems. That’s one of the enablers for this applications-driven orientation.”

“We’re still a long way in connecting the hardware and software worlds. And that’s why Cadence came out with its EDA360 vision, which identifies this gap. The thing that is new about EDA360 is that it puts down on paper what people have been talking about for 10 years in one form or another, but really circling the wagons to say that the world has changed, is changing and will continue to change,” he said.

While the industry used to operate under a simple mercantile model, Apple pioneered a different sort of model. The other system vendors have seen that and want a similar continuous revenue model for themselves.

“To us, that is the whole thing driving it. With the interconnectedness of everything, you can now get this continuous revenue model for things you could never get it from before,” Leibson noted, pointing to TVs and cars as application platforms. “That means if you want to design the most efficient silicon to enable these apps, you really have to keep in mind what the apps are in the first place. You’ve got the change the cost/revenue model for these chips somehow to improve their profitability so that it’s more attractive for people to design more chips.”

By Ann Steffora Mutschler
Building a system now includes software, but defining the software stack is a mounting challenge for engineers. What used to be almost exclusively drivers now includes RTOSes and OSes, executable files, middleware, firmware, IP, embedded software and applications.

With millions of different embedded products, all with different sets of software, it comes down to product requirements in terms of what the product has to do. And that plays a lot into what kind of software stack you need, said Cadence architect Jason Andrews.

“How much does the user see? How much do they need to be exposed to? On one hand, you have products where the user sees nothing. The software is completely automatic and invisible. The other extreme is a product where the users can add their own applications. Then you have to build something that is quite a bit more flexible. It comes down to the requirements of the products,” he explained. “Also, for most software engineers, they think about the hardware they have. A lot of times they are given hardware and they say, ‘Go find the software stack and get all the software to do certain requirements on a given hardware.’ So the hardware isn’t always flexible. There may be only a certain amount of memory or a certain kind of processor they have to work with.”

Up the stack
Technically speaking, the software stack depends on the IP at every layer. “The OS layer needs to implement the driver that interfaces with the IP at the lowest level (registers),” said Achim Nohl, technical marketing manager for Synopsys’ solutions group. “The OS driver provides rudimentary services to the upper layer that can now control the IP (e.g., In case of a GPS driver: open GPS device, write control data to the GPS device, read control data from the GPS). The OS is shielding the hardware details such as registers of the GPS.”

The next layer is the middleware, which is largely a set of libraries. In the case of Android, it has a huge middleware component consisting of libraries that provide easy-to-use interfaces to the application layer to control all aspects of a phone. The middleware provides more comprehensive services to the application layer to control the IP. For example, in the GPS example above it will allow to get the coordinates, get the direction, among other things.

“This stacking makes a lot of sense as now the application gets more independent of the OS. The middleware is shielding the details of the OS. This way, the same application can run on OMAP or Qualcomm Snapdragon. Even though both platforms run different configurations of the OS, the middleware allows the application not to worry about it. The middleware takes care that the functions such as get coordinates are translated into the driver commands for OMAP or Snapdragon. Thus the middleware is typically platform-specific at the driver level. It talks to the drivers, not to the hardware directly,” Nohl said.

Next is the application layer. Applications (executables) can be native or interpreted. “Native” means they are compiled for a specific platform. This is very efficient, but it makes the application executable platform-specific. In order to create the executable OS, libraries and middleware libraries need to be considered. Thus, the application executable gets OS- and middleware-specific and can run only on those platforms using the same processor, such as an ARM A9 only, an ARM A8 only, or a MIPS processor only.

Finally, applications in the Android Market Place are Java-based and can run on any phone that runs the Android software stack. Obviously, it is a challenge to make sure all those layers in the software stack work well together and are tested well enough. There can be dozens of variants of hardware platforms.

Selecting and defining the stack
In terms of the selection of the software stack, it depends on what kind of software you need to run.

“In a deeply embedded device, you want to run a software stack with a very small memory profile and very little overhead so that power is saved and not much memory needs to be spent.” Nohl said. “In the case of a DSP-type subsystem you may run an RTOS, as you have real-time constraints to fulfill such as processing signals from a sensor every 100ms. In the case of security applications, you might run a so-called hypervisor underneath the software stack. This is a kind of virtualization that somehow watched what the OS tries to do with the hardware and can interfere in case of a strange thing going on. In the case of a consumer application, you will choose an OS such as Android. Other vendors have their own locked OS such as RIM or Apple. In the case of automotive, special software stacks such as AUTOSar have been specifically designed for automotive applications.”

After defining the software stack, ideally, it should be analyzed. ARM has a software tool, Streamline, which is meant for performance analysis but can also perform stack analysis, according to Javier Orensanz, product manager for debug tools in the system design division of ARM. Streamline can be configured to generate a static analysis report on the stack usage for the different parts of the software and from this report, you can get a pretty good idea of what kind of stack you need, he said.

“In reality, you should always compliment your analysis of the stack with some dynamic analysis to see how the stack is used as the software runs. In this area there are several things that can be done. The quick, easy and dirty way that most people do it is to fill the memory with a pattern, run the code, then check the memory to see how low the stack went. This analysis is pretty good because as long as you cover the typical usage of the software it gives a dynamic way of how low the stack is going to go. So it is very useful. But this doesn’t tell you which functions make use of the stack or just how low the stack goes. This is why some alternative information is good to complement it, so if you see an unexpectedly high use of the stack you need more information to make informed decisions on how to improve your software,” Orensanz explained.

Key considerations
At a higher level, there are a variety of issues that can be considered ‘key,’ but what is most important depends on the perspective.

“I think if you ask software people, ‘what’s your biggest challenge,’ there are probably two things: All engineers will say the requirements keep changing, which is always a struggle. Besides that, I think the number one thing everyone is facing now is the gigantic complexity crisis because what happens is that the software stack has gotten so big that you’re assembling a lot of code that you didn’t write,” said Andrews. “The stack is like layers of abstraction and they get all the pieces and it sounds good, but it’s just like any kind of re-use story. It sounds good when you get to re-use things, but as soon as something breaks then you have to peel back all those abstraction layers and figure out what’s broken underneath. Pretty much universally everybody I’ve been talking to on the software stack and the system verification say, ‘We get all the pieces, we put it all together, it mostly works, and then all of a sudden the user interface starts bogging down and it’s slow. Now what?’ So they have to go way down in the bottom of the stack somewhere and find some driver, which came from somebody else and is misbehaving, and it takes a really long time because of the complexity. This is the biggest challenge—software stack complexity. A lot of mobile devices contain 10 million-plus lines of code and you wrote almost none of it.”

One way to manage this complexity is with simulation-based techniques in virtual platforms that aim to help engineers understand how the system is running, more quickly find where the problems are, analyze what parts of software are taking time, why the battery is draining so quickly – basically to get more information out. Historically this was done on FPGA boards or prototype boards and the visibility was very poor.

“Quality is very complicated to achieve,” said Victor Reyes, technical marketing manager in Synopsys’ solutions group. “We are dealing now with huge software stacks with very complex software running on very complex hardware platforms with multicore systems, and basically the integration issues between software and hardware are so complicated it’s not easy to understand all the issues that the integration produces.”

Synopsys is trying to create solutions to help engineers improve quality by improving software debug by giving global visibility on the complete system, including the hardware platform, the software executed on top, as well as the environment around the device.

Too many cooks
Another issue gumming up the works is that there are more stakeholders contributing to an embedded software stack

“This has changed quite a bit from the past,” Nohl said. “Previously, it was the mobile phone manufacturers that were providing the firmware and applications. Today it is many-fold. The semiconductor companies need to establish an operating system running on their specific application processor. Then there are the application spec providers like Google with Android, and those application software stacks need to be ported now by the mobile phone vendors to the specific mobile phone, running on the operating system provided by the semis. And at the end, you have a whole community of software developers that are creating apps for this specific application—all running on an embedded device. All the functions are highly distributed and things are intertwined.”

Outside of the consumer realm, Reyes said that automotive applications demand safety and robustness as the amount of software in the car is growing exponentially.

The impact of SMP
In addition to quality, complexity, time-to-market, performance, power and the usual suspects creating problems, the true realization of symmetric multiprocessing is having a huge impact in the industry.

“Multicore and multithreaded software support is becoming a crucial element as we go forward,” said Mark Throndson, MIPS’ director of product marketing. “It takes a lot more sophistication in terms of the software development and such, but it’s basically being driven by performance demands to achieve the Web-connected experience, driving down into everyday products, not just the PC. For better or worse, the software needs to be able to take advantage of that, and frankly it’s been easier historically to expand the hardware in this area and software is challenged to catch up effectively. It’s a combination of SMP-based operating systems as well as fundamentally developing code that’s more threaded in nature to take advantage of it.”

Learning how to make simultaneous multithreading and simultaneous multiprocessing work well together, then designing software threads so that when running on a multicore they make optimal use of the resources, for example, and balancing load equally between processors – all of these skills should be next on the software engineer’s to-do list.

This online cross-discipline graduate course will teach hardware engineers the basics of software design and software developers the basics of hardware design. In this way, each discipline will be able to understand the design of the complete system, following the practices established by high- level systems engineering. Factors that affect the selection of hardware and software solutions in design will be examined, as well as the use of trade studies to optimize the efficiency of integration issues. Techniques for partitioning of system-level functions and requirements to hardware/software components will be provided, as will practical guidance, through case studies, process templates and design check-lists. Prerequisite: Basic understanding of hardware or software development. For more details, see Syllabus and a presentation given by the instructor at Embedded Systems Conference.

June 21 to August 29, 2010  
For more information, visit the PSU website

By Ed Sperling & John Blyler
A year ago it was all about developing hardware at the leading edge of Moore’s Law. Now the focus is on developing software.

In a span of months the EDA industry has pointed its headlights in an entirely new direction. And while work will continue at 28nm, 22nm and beyond for smaller features along the classic Moore’s Law road map, all three of the major EDA vendors are plotting distinctly different courses that focus heavily on software.

Here’s a look at some of the new and developing approaches:

While none of the Big 3 will abandon their existing markets and flows, all see limited growth—as well as interest from investors—in just the classic EDA market. And they see an increasing role for software in SoC design.

Cadence’s plan
Of the three, the most radical shift is at Cadence, which has been largely in retrenchment mode over the past two years. Cadence is calling its new direction “EDA360,” and what’s different—at least in the initial announcement—is the starting point for thinking about the problems that EDA needs to solve. Rather than rely on tools to create the best SoCs, and then build software stacks to run on the hardware, the company is looking at the application software and middleware first, while the hardware becomes more of a generic application platform. According to the plan, the software should be able to reconfigure the hardware as necessary.

John Bruggeman, chief marketing officer at Cadence, said this is the strategy being used with great success by both Apple and Google. Rather than the platform dictating how the applications run, the applications are dictating the platform. But making that strategy work on a mass scale requires a different way of looking at the complexity in design, he said.

“This is an integration problem,” said Bruggeman. “At 65nm and 40nm, for every $1 spent on IP it requires $3 to integrate it into the SoC. The challenge is getting the $3 integration cost down. The problem of integration is all about profitability.”

The terminology that keeps popping up in Cadence’s 28-page blueprint is “realization.” There is system realization, SoC realization and silicon realization.

According to the document: “With an application-driven system realization approach, developers can start by envisioning the application. They can then design at the system level as far as possible, work down to the software, and finally build or buy the hardware. The application-driven approach will help close the profitability gap by addressing cost, time to market and quality.”

Mentor’s plan
Mentor already is looking well beyond just the chip. Its Nucleus RTOS and Linux tools strategy are playing a big role in the company’s move into a variety of communications devices. Case in point: The deal with Freescale that was announced this week to provide specific features in the Linux to support the silicon is a first for an EDA company.

“For evaluation purposes, the user gets a version of Linux that will be optimized by Mentor Graphics and Freescale,” said Shay Benchorin, director of marketing for Mentor’s embedded software division. “When the company doing the evaluation is ready to go commercial, we build on that. In the past, if you changed software or development tools you had to change the product. This is a new approach for users. You can evaluate the silicon and make sure it’s optimum for your use, then ramp to production in the shortest amount of time. The first set of tools will be for performance evaluation. The second set will be for debug, improving performance and optimizing power.”

Mentor also sees this strategy working well with its Nucleus RTOS, particularly with a multicore chip where one core can be running Android and the second can be running Nucleus. Add in virtualization software and each core can do many tasks that are separate, or which are integrated but run concurrently across multiple cores.

Mentor’s acquisition of Valor last month also moves the company well into printed circuit board-level design, as well. Valor has its own Design for Manufacturing (DFM) tools in addition to manufacturing execution and control software (see “EDA Extends Board Design into Manufacturing”). This essentially allows Mentor to control both the design and manufacture of a complete PCB. Add to that mix Mentor’s acquisition in 2009 of Flowmetrics, which helps model thermal challenges faced when designing the packaging in which chip dies reside.

At an even higher, pre-hardware or software partitioned architectural level, Mentor also has tools for system modeling that interface with mainstream requirements packages like Doors.

Synopsys’ plan
Synopsys is well along in its strategy of concurrent design to speed up time to market. Whether the software ultimately drives the hardware or vice versa doesn’t really matter with Synopsys’ approach. What does matter is that they both get designed concurrently.

As Aart de Geus, chairman and CEO of Synopsys, said in a recent interview: “As a percentage of our business, classic EDA is shrinking, but this is not a case of ‘classic EDA doesn’t grow.’” For example, in the past, EDA companies added front-end RTL synthesis and design tools with timing and power closure to improve the productivity of chip designers. Next, efficiencies were found in the back-end of the process by adding physical design with extraction and Design for Manufacturing (DFM) and Yield (DFY) tools. Today, EDA vendors are improving the value of system-level design with architectural tools.

Synopsys’ recent acquisitions in the virtual protoyping market are good examples of this trend. In recent months Synopsys added CoWare and VaST to its collection of existing virtual prototyping tools, having acquired Virtio several years ago. Virtual prototype tools are necessary to create the executable models needed by programmers and software engineering who create software applications for electronics, especially in the short time to market markets like mobile phones.

The bigger picture
Some industry executives say the automated chip design and manufacturing industry is being absorbed back into the semiconductor supply chain. Such advocates point the fact that two of the three major EDA tool vendor CEO’s either lead semiconductor industry organizations – like GSA – or hold seats on the board of directors for major semiconductor (not EDA) companies.

In all respects, EDA companies are moving up the electronic development chain to embrace a full system-level or total platform market. This is a move beyond just tools to create and manufacture today’s high complex chips – still the mandatory hardware “system” for any electronics. These systems-on-chip (SoC) designs have become more prevalent thanks to engineering innovation and the consumer push for higher performance, lower power and less expensive products. Indeed, the SoC hardware has become the given, the commodity in the electronic product equation. What, then, is the differentiator?

To answer that question, one must consider three major trends. One is the application of the problem-solving approaches, techniques and algorithms developed in the EDA market to industries that have a growing electronic component, such as medical, industrial and automotive. (see “Is EDA Still EDA?”)

Another important trend is the movement up the electronic product chain to include the design and manufacture of – not only the SoC – but also the chip package design and pin layout to even the printed circuit board on which all the electronic components reside. Mentor is not alone in extending it reach toward the board level market. Cadence has tools for the design (not manufacture) of PCBs, too. The recent Cadence acquisition of Taray enables the design of multiple FPGAs on a single board design. Synopsys’ acquisition of Synplicity-Hardee and then Prodesign give it a strong tool suite in the design of FPGA for rapid prototyping and hardware modeling.

Perhaps the most telling trend is toward the incorporation of software operating systems and applications as the future differentiator in both chip and even board level products. Few can doubt that the EDA market is definitely shifting direction toward a system-level, software rich platform. Who will win or lose as these platforms continue to emerge in new electronic markets is the real question. But for now, at least, there’s plenty of change to watch—and ultimately to judge over time.