| Industry Insight|
Continuous Hardware-Software Development
Statistics suggest that the traditional sequential ‘hardware then software' design approach is woefully inadequate. With growing hardware complexity, including the rise of multicore devices, software development isn't set to get any easier. Shay Benchorin, Director of Business Development at Synopsys System Level Solutions Group explains why taking a continuous approach to hardware-software development delivers benefits to software and hardware quality, reduces cost and improves productivity.
A research analyst's study that considered over 45,000 embedded software design starts reported that 54 percent were completed behind schedule, incurring an average delay of 3.9 months (source: EMF).
The same study asked engineers whether the end result met their pre-design expectations. Alarmingly, over 30 percent of respondents felt that the final system was not even within 50 percent of pre-design expectations in terms of performance or systems functionality. Since the majority of embedded designs are late to market, and a high proportion do not meet the functional or performance specifications, it seems reasonable to ask whether the current ‘hardware then software' development process can be improved.
Embedded software development plays an increasingly important part in SoC projects with a growing trend towards including microprocessor IP within the chip. Synopsys' own data collected from successive user group surveys suggests that up to 40 percent of chip design starts now incorporate at least one microprocessor, and there is a growing trend to incorporate multiple cores within the SoC. While multicore creates a powerful platform processor, it also creates an even more challenging target for the software team.
There are parallels between hardware and software development in terms of the cost profile (see Figure 1). Software development costs are incurred during the initial development phases and then incurred again in terms of end user software once the product ships. Like back-end chip manufacturing costs, end-user costs are affected by the decisions that are taken during the earlier development phases. Without a change in approach to hardware-software development, the software cost component is likely to increase as chip complexity grows.
Figure 1. Cost Profile for Hardware and Software
Traditional Sequential Approach
With a traditional sequential development process, hardware must be made available before the software engineers can start developing code. Hardware prototyping using programmable logic can avoid the need to wait for silicon samples to be made available. However, implementing a physical prototype can in itself be a complex and time-consuming project, and this approach requires that the RTL is ready before it can be mapped to an FPGA which ,may take many months Furthermore, one of the key development issues cited by software engineers is that physical prototypes do not always enable adequate control and visibility of the system to make the code development straightforward.
The sequential flow continues with software debug and testing followed by integration of the software into the hardware. The process of integrating software on the hardware will likely reveal issues with the hardware itself. Discovering hardware problems at this stage in the development process may lead to a complete silicon re-spin.
Instead of taking a sequential approach to system development, hardware-software integration should begin at an early stage and continue throughout the design and debug process. The challenge is how can this be achieved, given that the chip implementation is often in the critical path?
System Development Flow
By definition, the system development encompasses both hardware and software. Ideally the architecture should be analyzed and explored using the applications for which it is intended. Decisions made at the architectural stage concerning partitioning of functions between hardware and software often have the greatest impact in determining the overall design quality, performance and final product cost. A robust system development flow brings hardware and software elements together at a much earlier stage in the process, at the time when the system architecture is first defined. By defining the architecture to a sufficient level of detail, an unambiguous executable specification can be developed to guide the rest of the implementation process. The executable specification is a high-level system representation that can be used to develop and integrate the software. In turn, the software can be used to refine the hardware architecture. This iterative process enables actual software to be run on proposed hardware to finalize the system architecture.
Figure 2. Continuous Hardware-Software Development
When it comes to implementation, the software development process must have access to the hardware. At the same time, the hardware development process can benefit significantly by having early access to software, specifically to assist the validation process.
Bringing the hardware and software together for system integration inevitably reveals problems that will, until that time, not have been anticipated. Therefore the earlier that system integration can be performed in the overall process, the more reliably issues can be anticipated and resolved.
A process that enables hardware and software to be continuously and simultaneously refined will also enable a greater amount of validated applications to be made available at product release.
A Virtual Approach
While the system development flow described above represents an ideal scenario, enabling such a flow using a virtual approach is not straightforward. In practice a number of issues must be addressed; early attempts by the industry to resolve these have been unsuccessful for a variety of reasons.
Achieving usable simulation speed within a virtual environment has always been challenging. A virtual system is essentially a software representation of a hardware design, running a software operating system and application. The achievable simulation speed is a function of the level of model abstraction, which also determines the accuracy of the development environment. The availability of processor models at the appropriate level of abstraction and accuracy is vital if a virtual approach is to be a practical option for design teams.
Any solution based on a virtual approach must provide support for standard languages for hardware and software development, and also ensure full binary compatibility with production software. This will ensure that no changes are required when moving from the virtual environment to the actual physical system. This is key to enabling a production-quality software development process.
The Synopsys Virtual Platform
Synopsys Virtual Platforms are fully functional software models that can represent complete systems, encompassing the processor, SoC including chip peripherals, board, I/O and even the user interface. The virtual platform executes unmodified production code, including drivers, the OS and applications. With this capability, a virtual platform can streamline and accelerate software development for complete systems – not just the chip. Synopsys Virtual Platforms are capable of addressing many of the inadequacies of the traditional sequential development flow for embedded systems.
Synopsys Virtual Platforms use transaction-level modeling, which represents hardware at a higher level of abstraction to enable faster simulation and earlier availability. This approach models transactions flowing within the system instead of dealing with individual bus cycles, individual pins and wires.
With physical prototyping, having limited visibility into the complete system is a significant issue for software developers. One of the key benefits of taking a virtual approach to system development compared with a use of a hardware-based prototyping environment is that the developer will enjoy superior debug capabilities. A virtual platform grants the developer unrivalled visibility and fine-grained control within the system.
Synopsys' Virtual Platforms allow developers to build and run entire system-level models at speeds of up to 50 simulated MIPS. This enables an OS to boot, and hundreds of millions of instructions to be executed in seconds. For hardware developers, Synopsys Virtual Platforms support the SoC design flow with mixed-mode simulation and a seamless path down to RTL design and verification, including integration of simulation acceleration technologies and even actual hardware in the loop if this is a requirement.
For software engineers, Synopsys Virtual Platforms allow the familiar legacy software development and debug environment to be retained and used in conjunction with the platform. For example, using a software development environment such as Texas Instruments' Code Composer Studio enables full multicore debug to be carried out across the TI DSP core. Similar features are enabled with ARM's RealView, the GNU toolchain and debug environments from other vendors.
Beyond enabling advanced debug, Synopsys Virtual Platforms provide a number of advanced features offering other benefits to system architects, including advanced power modeling and sophisticated support for development of multicore systems.
Managing power is an increasingly important issue for both battery-powered and tethered applications, and early insight into power consumption at an architectural and system level can enable significant savings to be made. Manual analysis can provide initial estimates for power budgeting purposes, but with sophisticated power management technologies such as frequency and voltage scaling, multiple power domains and clock gating, accurate dynamic power analysis is too difficult and time-consuming to perform manually.
Synopsys Virtual Platforms enable power modeling at a system level, which provides a relative measure of power consumption on an application-by-application basis. This enables the system architect to make tradeoffs to minimize power, for example, looking at execution frequency against application runtime.
Systems with advanced power saving capabilities require power management control, which is often facilitated by a discrete ASIC. Typically, power management control uses a software management layer or power-aware OS to manage a hardware controller to take care of frequency scaling, controlling separate power domains and other power saving features. The power-aware OS can be ported to and optimized on the virtual platform so that the software developer can validate the power management strategy based on real applications before the hardware is available.
Power estimation is enabled by incorporating special components which contain power analysis equations within the functional blocks. For example, a power model of the ARM1136 processor core contains four different parameters, each of which corresponds to a different power mode of the device. These correspond to the active, dormant, inactive and shutdown states. Each state is characterized in terms of milliamps per MHz, and this number is scaled according to the applied voltage and frequency from the power controller. Immediate visual feedback allows the system architect to quickly and easily optimize the system for minimal power for actual applications running on the system.
Complex systems contain multiple embedded cores, and this trend is extending to the chip domain where advanced SoCs now incorporate multiple control processors and programmable DSPs. Integrating multiple cores provides a very powerful hardware platform which can deliver higher performance for less power than a single, high-performance processor.
However, multicore designs are challenging from a software development perspective. Tools and techniques for multicore software debug are generally lagging behind the ability to design and implement the multicore systems in hardware. One challenge is to control debug synchronization between cores. If one processor is stopped through the JTAG debug interface, other cores may continue to run, generating interrupts and events which are then impossible to trace.
Because Synopsys Virtual Platforms run everything off the same simulation timeline, multicore debugging is much easier than in other environments. All of the cores can be stopped at the same time, allowing detailed synchronous multicore debugging. This feature enables fine-grained control and debug of all cores, allowing breakpoints to be set so that the engineer can single-step through and examine the state of any core.
Synopsys System-Level Solutions
It is clear that a number of requirements must be met to properly enable continuous hardware-software development. As well as a technology platform to bring the hardware and software environments together, the availability of a broad range of models at an appropriate level of abstraction is critical to the success of the approach.
Synopsys' growing DesignWare IP library complements the virtual platforms approach to provide an environment that now enables continuous modeling, power estimation and budgeting at a system level, as well as advanced multicore debug. Synopsys Virtual Platforms allow engineers to get on with developing the increasingly complex software layers some nine to twelve months ahead of silicon availability. Hardware developers also benefit from this approach as earlier software integration enables more robust functional verification with real application scenarios.
©2010 Synopsys, Inc. Synopsys and the Synopsys logo are registered trademarks of Synopsys, Inc. All other company and product names mentioned herein may be trademarks or registered trademarks of their respective owners and should be treated as such.