Development Tools for SoCs

Software-Driven SoC Development

If we can reduce the dependency of software developers on getting real silicon in order to do their development and verification, we can shrink the overall time-to-market equation for SoCs significantly.


  • Page 1 of 1
    Bookmark and Share

Article Media

It is well known in the semiconductor industry that software development costs for a new SoC outpace the hardware development costs, and at an ever increasing rate. This dramatic encroachment of software costs deeper into the semiconductor industry and the desire to reduce or at least control them drives an important inflection point for the capability of development tools and techniques used to build complex SoCs. The current SoC development methodology is often not sufficiently powerful to create functioning software-intensive SoCs for the smartphone, tablet and other markets, and at the same time meet aggressive time-to-market and cost objectives.

The most significant problem is that software is often developed too late in the process-in some extreme cases starting post-silicon-even though software has a large impact on overall performance and functionality of the SoC. Figure 1 (bottom row) illustrates this SoC development flow. In the traditional SoC flow, the software development effort is serialized after the hardware development, relying on availability of the silicon to begin verification and application software efforts. This approach has the obvious problem of lengthening time-to-market (TTM) for the SoC under development, and is hopefully more the exception rather than the rule today.

Figure 1
A comparison of SoC software development flows.

Over the past ten years or so, much effort has been exerted to bring the software development activities into the pre-silicon domain, via technologies such as software virtual platforms, FPGA prototyping environments and hardware emulation capabilities. This software-enhanced SoC flow (middle row) is more or less the current practice for many semiconductor companies today.

However, even though efforts were made to move the software development earlier in the process, the amount of software that needed to be executed before silicon has skyrocketed, in many cases perhaps negating the forward progress already made. The reason is easy to see. The availability of powerful OSs, such as Apple’s iOS as well as open source software, such as Linux and Android, enabled the development of consumer devices such as smartphones and tablets on a scale previously unimaginable. But wait, there’s more, as in Moore’s Law. With more and more transistors available, silicon designers are adding increasingly powerful multicore processors and hardware subsystems, such as graphics, video processing and wireless networking, which in turn need support in the software stack to fully utilize this new hardware capability. So it’s a perfect storm of powerful and widely used system software that must be adapted to and optimized for increasingly powerful SoC hardware, in less and less time to meet shrinking market windows.

The problem, however, is that all the operating systems require massive amounts of software. Hundreds of megabytes of executable images need to run in order to develop, test and optimize the SoC hardware-dependent software being developed by the SoC software team. Being able to execute thousands of instructions at 10 kHz in some form of simulation and/or emulation doesn’t scale well when billions of instructions must be executed to boot Android and run and debug system software and apps on the SoC under development. While emulation provides a stop-gap with execution speeds in the MHz domain, booting full Linux, Android or iOS can still take hours. FPGA-based prototyping extends execution into the 10s of MHz domain, but in contrast offers less debug insight into the hardware compared to simulation and emulation, and is available significantly later in the project when hardware descriptions have become mature enough.

This requirement to execute large-scale software stacks puts extreme pressure on the SoC development flow technologies such as software virtual platforms, FPGA prototyping environments and hardware emulation to increase their capability to execute software while at the same time maintaining their fidelity with and visibility of the hardware under development. Constraints or limits on the ability of SoC software developers to execute and debug large amounts of software before silicon availability adversely affects their productivity and will increase costs and delay time-to-market.

Ideally, we’d like to get to the Software-Driven SoC flow shown on the top of Figure 1, where there is essentially continuous development of hardware and software utilizing the best available representation of the hardware at any point in the flow, with “meaningful” software execution speed, i.e., capable of running Android, Windows RT and other large-scale operating systems.

Figure 1
A comparison of SoC software development flows.

The software-driven SoC flow defines a new development methodology and uses new development tools and technology with which extensive system software is not only able to be brought up and verified early, but development teams are also enabled to use software early in the development cycle to verify hardware via software (software-driven verification). They can also measure and debug hardware/software interactions and develop, test and optimize the software deliverable to the SoC customer (e.g., Android ported and optimized to the SoC under development). That means the emphasis is on software execution being supported during all phases of SoC hardware development.

Software Productivity and Its Limits

Increasing software productivity has proven to be a challenging task, so when we aim to improve the SoC software developer’s productivity, we must know what we’re up against, and deliver meaningful improvements.

The classic paper by Frederick Brooks, “No Silver Bullet - Essence and Accident in Software Engineering,” divides the difficulties in software development into two components: accidental and essential. Accidental difficulty is centered around transforming the conceptual representation of software into the reality of running (correctly) on a particular piece of hardware. The single largest gain in software productivity has been made by the introduction of high-level languages, which automated this transformation process. What is left is the essential difficulty, and Brook’s thesis is that no one tool or tools will ever make the kind of productivity improvements gained from the introduction of high-level languages in attacking essential difficulties.

However, Brooks was not altogether pessimistic. He recommends closely examining make vs. buy trade-offs as a powerful weapon in increasing productivity. Having developers not writing software where they don’t have to is a great way to make them dramatically more productive. Another more “mechanical” approach to reduce accidental difficulties is to dramatically reduce the “turnaround” time from finding a defect, repairing it and testing the fix. The obvious implication for SoC software development, pre-silicon, is having a software execution environment that is fast enough to have a turnaround time that is interactive or runs in minutes rather than hours or days.

So when we are looking to increase the productivity of SoC software developers, we are strongly in the camp of finding approaches that have large and easily measureable benefits. At the top of our list is a development flow that fixes the accidental difficulty of slow software execution by adding technology that allows “meaningful” software execution on the best available hardware representation as early as possible during the development cycle.

Software Development Is Strongly Hardware Dependent

After numerous discussions with software developers within semiconductor companies, we have seen a clear picture emerge. For the software developers, ironically, it is all about the hardware. All the software effort, from writing the lowest level driver to building the coolest multimedia Android app, is driven by and limited by the underlying SoC hardware and its availability to developers on the SoC software team. Keep in mind, however, that these software developers are targeting large-scale operating system environments, such as Android, Linux and Windows RT. These systems represent millions of lines of code and megabytes of executable images, so it is critically important that the SoC development environment be able to handle the performance requirements to execute such large and powerful operating systems, while at the same time presenting the most accurate representation of the underlying hardware.

Figure 2 illustrates a typical complex design with both the hardware and software components. The SoC hardware is composed of a mix of blocks, some unique to the SoC, some based on reuse of previous generation SoCs, some purchased IP and so on. Each SoC maker must decide where to put their effort. In some cases they perceive their value to be substantial across the whole SoC, whereas other makers might decide to concentrate on a particularly important hardware subsystem and use standard off-the-shelf blocks for the rest. Most of these hardware blocks will interface to the application processor in some way. This in turn means that the application processor software will need driver support and maybe more, including OS kernel and middleware changes to effectively work with each hardware block of the SoC. Note also that some of the blocks themselves are processors (a DSP in the case of the current example), which of course run a sophisticated software stack as well. Figure 3 (right side) shows a more detailed view of the multiple software stacks typically developed for a modern SoC.

Figure 2
Complex SoC hardware blocks and software stacks.

Figure 3
SoC software stacks and software-driven SoC flow.

A potentially worrisome situation shown in Figure 3 is that a significant amount of the delivered value is from the software running on the SoC, and it has to be developed from scratch (the block labeled Proprietary OS). So now we’re in a bit of a bind. We’re now in the “no silver bullet” domain of limits to increasing software development productivity. The good news is the software required for an SoC is often externally supplied, such as Android from Google. Thus the SoC maker’s software effort is dominated by porting and optimizing the software to exploit the unique capabilities of the SoC, rather than developing Android itself. So whatever rising software costs the SoC maker is seeing, they are not driven by the costs of developing Android, but rather by the cost of adapting Android to their own SoC. Short of taking transistors away from the hardware designers, it’s hard to see how to dramatically reduce the costs. However, we can dramatically reduce the time-to-market by enabling significant software development earlier in the flow.

Figure 3
SoC software stacks and software-driven SoC flow.

In addition, as shown in Figure 3, SoC developers are not just developing software that ships with the SoC. It’s clear that a significant amount of test and verification software is developed for the SoC and used along with other more traditional hardware verification techniques. It is not uncommon for Linux to be ported to a new SoC for use as a “test” OS since it provides a very rich set of tools and execution features that greatly simplify running verification software on a new SoC. There is no expectation that this Linux would ever be shipped to a customer; its use is purely internal. This is software-driven verification and it is an important use-case and subject to the same accuracy (if not more) and performance requirements as the SoC customer-deliverable software stack.

Figure 3
SoC software stacks and software-driven SoC flow.

Note that Linux, Android, Windows RT and other commercial operating systems are developed outside of the semiconductor industry. In these cases the software effort on the part of the SoC maker is largely on porting and optimizing the software to run well on the SoC under development. However, this effort is not limited to the lowest levels of the stack, e.g., device drivers, as many may think. Although hardware dependencies are often thought of as being taken care of by device drivers, in many cases, changes to the core OS or even middleware layers are often developed to exploit SoC hardware capabilities.

So whether it is software that ships with the SoC, or software that is only used internally for testing and verification purposes, there is no way to shortcut the fact that the OS has to boot, load middleware and support applications running in order to develop and test the OS, its underlying hardware-dependent software and the hardware itself.

Software-Driven Development Supports Hardware Development

From a software perspective, it is interesting to observe that the earlier you move in the SoC hardware development process, the more it resembles software development and is therefore subject to more of the usual problems and solutions in the software world. We can see that the more the SoC hardware effort resembles developing software, the more the productivity gains start to be limited just as they have been in pure software.

As is true with software, the best way to make a hardware developer more efficient is to not develop hardware in the first place. SoC designers understand the importance of IP reuse, whether internally developed and/or externally acquired. So it is no surprise that SoC hardware developers have increasingly turned to reusing internal IP or purchasing IP to help decrease the amount of new “software,” e.g. hardware for the SoC that is developed from scratch, and the use of high-level synthesis tools and other means to raise the level of abstraction. Figure 2 shows the numerous IP blocks that compose a modern SoC.

Figure 2
Complex SoC hardware blocks and software stacks.

Another lesson from the software domain is to raise the abstraction level used to implement the new SoC blocks. If for a hardware developer, register transfer level (RTL) can be considered the same level of abstraction as assembly language for software developers, moving to high level synthesis such as SystemC and tools such as Cadence’s C to Silicon provide that next higher layer of abstraction.

Using processor-based software-intensive blocks is another approach. In this case, most of the hardware “implementation” of a block’s function remains in software, written in C or C++ and running on a specialized processor constructed and optimized to execute the block’s function at near RTL speeds. The Tensilica Xtensa core from Cadence and Synopsys’ ARC are good examples of this approach.

With the Brooks model in mind, we can also see why in the “classic” EDA world, the tools continue to increase the productivity of developers by keeping up with each change in process technology. In effect, the back-end development process (place and route, timing closure, etc.) for semiconductors is dominated by artificial difficulties, that is the physical changes in the semiconductor process as a result of moving to the next node of technology. As Brooks tells us, artificial difficulties are amenable to tooling to get dramatic productivity gains, and the EDA business continuously exploits that fact by developing those tools year after year.

So where the SoC development is dominated by physics, e.g., place and route, timing closure and other artificial difficulties, engineering efforts will continue to see productivity gains. And where hardware development is dominated by essential difficulties, IP reuse and purchased IP provide significant productivity gains.

In the end, as more and more hardware remains in software, if even only early in the development process, or always remains in software with the processor-based block approach, execution of software even on the pure hardware side becomes increasingly important during the development process. The process further strengthens the value proposition of a software-driven SoC flow, faster time-to-market and reduced costs.

The Overall Flow for Software-Driven SoC Development

The right side of Figure 3 shows a view of the software-driven flow and its relationship to the software deliverables for a typical SoC in a mobile device. Virtual platforms, emulation and FPGA prototyping (and the silicon itself) all provide software execution environments suitable for various stages of the SoC development flow.

Figure 3
SoC software stacks and software-driven SoC flow.

A critical underpinning of the software-driven SoC flow is the observation that a huge percentage of the millions of instructions that will be executed booting Android exercise a very small subset of the SoC hardware-mainly the processor and memory. The software-driven SoC flow exploits this situation by moving these elements to faster (although less accurate) attached simulation environments. For example, an ARM Fast Model is moved out of emulation along with its memory. This “hybrid” approach is carefully engineered to interact perfectly with the rest of the SoC RTL being run in emulation or in an FPGA prototyping system. No two SoC designs are alike, so there is always tuning of the configuration. And in some cases over time, different hardware subsystems may be moved out of RTL emulation and into a faster execution environment where emulation accuracy is less important than software execution speed.

Ideally, the same tooling (debuggers, etc.) works across the different environments, allowing software developers and their hardware partners to select the most suitable spot in the flow to address the development task at hand.


Cadence Design Systems

San Jose, CA.

(408) 943-1234.