How virtual prototypes speed SoC hardware design

Graham Hellestrand
(05/07/2004 5:00 PM EDT)

  1. Introduction

The world of the hardware design engineer has changed dramatically in recent years. Designers no longer sit and code RTL in isolation to meet a paper specification, and then wait for a hardware prototype before interacting with the software team to bring up the system. The combination of intense time-to-market pressures and the relentless growth in design size and complexity has rendered old development models inefficient and impractical. A new approach is needed to ensure that hardware design takes place within the context of system-level requirements.

This paper presents some background on the evolving role of hardware designers, and outlines the requirements for effective performance in a world of systems-on-chips (SoCs). It presents the technology of virtual prototypes, traditionally seen as tools for system architects and software engineers, and discusses the benefits that virtual prototypes confer upon hardware designers as well. It demonstrates that the result of adopting a virtual prototype-based development process is a higher quality product, delivered to the market faster while consuming fewer project resources.

2. Increasing hardware complexity and gate count

Today's SoC projects present daunting challenges to hardware designers. Developing the RTL implementation for millions of gates is a huge effort; design verification is equally difficult. The development process is long, often consuming an unacceptable level of resources in an attempt to tape out a correct design. The sheer difficulty of this task often means that some design errors end up in silicon.

Several surveys have shown that more than half of all chips require at least one revision to fix bugs before product release. The cost of a chip turn at submicron geometries can be well over a million dollars. Unexpected silicon turns can kill a project, either because the company simply can't afford the extra cost or because the schedule delay means that the product would completely miss its market window.

These challenges lead to profound changes in the way that designers do their jobs. The industry is moving toward a concurrent engineering process in which architects, hardware engineers and software developers interact closely up front and throughout the development cycle. This allows designers to develop their implementation with far more confidence that system-level issues have been addressed. In addition, the concurrent process allows the hardware design to be validated in the system-level environment along with the software, greatly reducing the chance of unpleasant surprises when the hardware prototypes and software are integrated.

3. Traditional sequential development process

The conventional electronic system development process is shown in Figure 1. The process begins with both business and functional requirements written in natural language. These steps are usually performed by a combination of marketing and system architecture resources, leading to the development of a paper system specification document. This specification typically defines the high-level architectural partition between hardware and software.

Figure 1 — The traditional sequential development process serializes software and hardware development.

Once the specification is complete, the detailed hardware architecture is determined — typically manually. At that point, the designers can begin coding RTL (or drawing schematics) to complete the design, which is then fabricated to produce hardware prototypes.

Traditionally, the software teams have had minimal involvement until the hardware prototypes are available. Some of the software architecture definition and algorithm development might be done in parallel with the hardware team, but software engineers have not wanted to do much actual programming until a development prototype is available for creation and debug; only the hardware prototypes could fill this need.

The problems with a purely sequential system development flow are clear — the project timeline is long, and valuable engineering resources are used inefficiently. Rather than having an integrated project team, the programmers are usually working on other projects during the hardware development phase.

During software development, a few of the hardware designers are needed to maintain the prototypes and make engineering change orders (ECOs) to fix design problems found when the hardware and software are integrated together. The rest of the design team typically moves on to new projects, making debugging and resolution of integration problems harder since the remaining designers lack critical knowledge of some parts of the design.

Project teams focused on time-to-market demands realized that hardware and software had to be developed in parallel in order to accelerate the process. This placed more demands on the up-front architectural analysis to provide a crisp partition between hardware and software so that implementation of both could start at about the same time.

4. Idealized concurrent system development process

In response to the limitations of a purely sequential process, system development evolved so that hardware and software teams could work in parallel. Figure 2 shows the idealized parallel electronic system development process, entailing three phases"specification, implementation and integration. In the first phase, a "system engineering" or "architecture" team defines the product's business requirements based upon marketing input, develops an overall system design that can deliver those requirements, and writes a detailed paper specification to guide the software and hardware implementation of the system.

Figure 2 — The parallel development process aims to enable simultaneous software and hardware development.

In the second phase, hardware and software teams implement the specification using their respective technologies. The hardware designers code RTL while the programmers write high-level language (or assembly) code. Since the hardware design must be fabricated into actual chips and boards, the availability of working hardware prototypes usually limits the acceleration of this phase. On the other hand, many systems have far more lines of software than RTL code and so the software implementation may not be 100% complete when the prototypes are ready.

The final phase involves running the software on the hardware prototypes to integrate all of the components of the design and bring up working systems.

5. Challenges of traditional development processes
There are important implications of the traditional development processes for the hardware development team. For a start, they usually are unable to participate in a significant way until the system specification is complete. Although experienced hardware designers can contribute a lot of practical knowledge to the system definition and specification, usually the architects are operating in an abstract environment that has no link to the actual hardware (or software) design. This leads to several significant issues for the hardware designers and the project as a whole.

5.1. Architectural surprises
The late involvement of the hardware team often means that, while the hardware implementation is underway, critical flaws are discovered in the system specification. Ideas that sound good in the abstract may have undesirable implications when implemented in RTL. Any time that the specification changes, it is likely that the designers will have to discard some amount of RTL and start over on some areas of the design. Since the programmers are coding concurrently, assuming a particular hardware/software partition, their jobs may also be affected by specification changes.

The software developers can also run into problems that require the hardware design or the specification to change. For example, this happens quite commonly in the development of multi-media SoCs. The system specification typically defines a set of graphics primitives that are combined to create the wide range of 2-D and 3-D effects demanded by the market. Many of these are supported by hardware built into the SoC while others are implemented in software.

In the traditional development process, the architects don't have solid information on which to base the dividing line between hardware and software. While coding a particular function, the programmers may find that the performance of a software routine will be unacceptable and that hardware assistance is needed. Again, this results in changes to the specification and disruption for the hardware development team.

5.2. System-level modeling
In an effort to better predict system performance and make more intelligent trade-offs, many architects perform sophisticated software modeling and analysis as part of the specification phase. However, without knowledge of the hardware architecture or ability to run the actual software, this system-level effort is very abstract. It is usually impossible to import hardware or software components as they are implemented, so the analysis does not evolve or become more accurate as the project proceeds.

5.3. Partitioning hardware and software
The implementation of hardware and software in parallel can indeed accelerate the overall development schedule, but it requires that the hardware/software partition be defined during the specification phase and not change drastically during implementation. In practice, this is very difficult to accomplish. Especially for SoC projects, trade-offs made during definition and specification are tenuous since the architects do not have any performance data for the hardware or the software.

Hardware-software partitioning is particularly difficult for domains in which the hardware and software interact closely, such as applications with safety-critical implications, hard real-time requirements or multi-media functionality. Airbag deployment during vehicle rollover is an example application where improper deployment can be catastrophic for the occupants; correct operation requires real-time response to information coming from instruments that detect the vehicle's rotational motion.

5.4. Hardware verification
Although some designers feel that they are not responsible for hardware verification, in fact the verification process affects them in many ways. Even if the designer does not personally write testbenches and develop tests, support must be provided to the dedicated verification engineers performing these tasks. This is a significant effort, especially since traditional development processes do not leverage any work done by the system architects in setting up environments for performance evaluation and architectural exploration.

In absence of such leverage, the hardware verification team has no choice except to develop all models and tests from scratch, putting strain on both the designers and themselves. Further, it is quite unusual for chip-level verification environments to be able to execute the actual software that will eventually run on the hardware. This lack of co-verification means that critical portions of the hardware/software integration cannot occur until hardware prototypes are available.

5.5. Deploying hardware prototypes
Another challenge of traditional development processes can be in deploying hardware prototypes. Both the fabrication time for the hardware prototypes and the costs to build them are significant issues. Many SoC projects have large programming teams that may be geographically dispersed, so multiple prototypes are almost always needed. Building the prototypes, distributing them (often navigating international customs offices), maintaining them and keeping them synchronized with hardware ECOs can be a challenge, especially over many miles and time zones.

5.6. Breakdowns in the process
The upshot of all this is that the expected benefits of concurrent hardware/software development process are rarely realized. What usually happens is a highly iterative process in which problems found during hardware and software implementation force changes to each other and to the system specification, delaying the schedule and wasting engineering resources.

Even when iteration is minimal, this process still suffers from reliance on hardware prototypes for hardware/software integration. Further, since important classes of bugs are almost impossible to detect until hardware and software are running together, the chances are high that one or more chip turns will be needed.

A major shift in development methodology is needed so that hardware engineers can participate earlier in the development process, software engineers can run their code before hardware is available and architects can refine their modeling environment to include RTL as it becomes available. Most importantly, hardware prototypes must be removed from the critical path in order to accelerate development and increase the chances for first-silicon success. This shift requires the power and flexibility of virtual prototypes.

6. Introduction to virtual prototypes

A virtual prototype is a software-simulation-based, architectural-level model of the electronic system. The model can include one or more processors, buses, hardware peripheral components, and even models of mechanical subsystems that are part of the overall system. Most notably, the virtual prototype runs the same compiled and linked target code as does the real hardware, accurately predicting the system's real-world behavior. In addition, the virtual prototype must be cycle-accurate so that the system under design is modeled for real-time requirements.

Figure 3 shows the architecture of an advanced virtual prototype for a 3G wireless phone SoC design. The processor models are fast enough to run actual binary code and boot the real-time operating system (RTOS) in seconds. Since a virtual prototype can execute on an off-the-shelf PC, it is easy to provide a copy of the complete system model to all members of an SoC project team. This takes hardware prototypes off the critical path and saves considerable project costs.

Figure 3 — A typical virtual prototype for a 3G wireless phone SoC design combines models for processors and a wide range of peripherals.

6.1. The new design paradigm
A virtual prototype enables architectural exploration and a truly concurrent development process for hardware and software in which both are tightly linked back to architectural specification and system-level validation. Figure 4 shows the steps of this process, using the Comet system-level design tool from Vast Systems Technology.

Figure 4 — The concurrent development process enables simultaneous hardware and software development.

As with the traditional sequential process and the idealized parallel process, concurrent development begins with both business and functional requirements written in natural language. An initial system architectural model is built and this model becomes the executable system specification. The various system functions are mapped into hardware and software as appropriate.

In the new development process, a much higher investment is made in architecture up front. This entails creating a software-simulation-based architectural model of the system. Once this model is created, both hardware and software development can ramp up simultaneously, use fewer overall resources, and complete sooner.

6.2. System architecture with a virtual prototype
The architectural stage of development includes exploration of various architectures on both the software and hardware sides. Architects can perform "what if" analysis on potentially hundreds of models to pick the best one. Once the architectural decisions are made, the development process moves on to the design stage. Finally, both the software and hardware are implemented at the detailed, structural level. The virtual prototype must have high performance, sufficient to run real time software and evaluate results quantitatively. It must be cycle-accurate such that architectural tradeoffs can be made affecting power consumption, performance, cost and other factors.

6.3. Golden reference design
Once the architecture is optimized, the architectural model/executable specification becomes both the golden reference design to drive the hardware development and the prototype on which embedded software is developed. This enables true co-verification, in which real-world software loads can be run against the architectural models or the actual RTL implementation of the design.

6.4. Concurrent hardware and software development
During all design phases for hardware and software — architect, design, develop, debug and verify — engineers use the virtual prototype. In this essentially front-loaded process, test generation from the system level to the detailed design level occurs at each stage as part of the development process. Only in the final integration stage do the engineers use the real silicon hardware. Since both software and hardware development are completed using the same virtual prototype, the final integration stage is easier and shorter.

A high-performance, cycle-accurate virtual prototype, together with tools that enable a concurrent engineering process for embedded-processor-based electronic systems has been shown to:

• Reduce product development risk by about 67%
• Reduce development bench cost by about 50%
• Reduce engineering development time by about 25%
• Reduce engineering resources by about 25%
• Improve product quality by 50%

Accurate, high-performance virtual prototypes not only enable the overlapping of software development with hardware design, but also deliver a unique new element to system-level design — the capability to rapidly model and quantitatively assess various candidate architectures. By enabling the choice of an optimal architecture before completing detailed hardware implementation, let alone the physical system, the architecture team can make accurate tradeoffs early in the development process.

7. Benefits for hardware designers

The benefits of virtual prototypes and the concurrent system development process for the overall project are clear, but hardware designers also benefit in several significant ways.

7.1. Less wasted RTL code development
The ability to perform detailed performance measurements and make trade-offs during the specification phase means that the optimal architecture and the proper hardware/software partition can be determined before detailed hardware implementation begins. This eliminates the iterative nature of the more traditional approaches, in which designers have to rewrite significant portions of their RTL whenever implementation uncovers specification deficiencies.

Early access to quantitative performance metrics also means that the exact requirements for the hardware architecture are known before implementation begins. In absence of such metrics, there is a tendency to over-design the hardware in an effort to prevent possible bottlenecks.

A highly accurate specification phase prevents the hardware designers from wasting time implementing features that ultimately are not needed to meet system requirements. Such hardware architectural details as depth of FIFOs, number of channels for memory interface controllers and arithmetic unit pipeline stages can be determined before a single line of RTL is written.

7.2. Fewer chip turns
Perhaps the most obvious benefit of virtual prototypes for hardware designers is the reduction in risk of a chip turn. Hardware designers can't help but worry about this — in today's economy a canceled project almost always means lost jobs. No one wants to be blamed for a multi-million-dollar failure. The expense of a turn can be high, dwarfing the cost of development tools. A wise investment in better verification can pay back dividends multiple times over.

7.3. Hardware design verification with a virtual prototype
Another major benefit for the design team is the ability to leverage the virtual prototype for hardware verification. The traditional processes have fostered "throw-away" system-level models that quickly become outdated as hardware and software implementation proceeds. The concurrent process enables just the opposite — a tight link between the development stages.

Because the golden models in a virtual prototype are cycle-accurate, detailed RTL implementations can be swapped in at any time. Further, since the detailed hardware-software partition can be determined during the system-level design phase, the modeling scheme can reflect the block-level organization of the chip.

This permits a technique of successive refinement, in which the high-level (but cycle-accurate) models can be replaced by less abstract HDL models, which can in turn be replaced by the detailed RTL implementation. The refinement process applies not only to complete chips, but also to major chip functions since the high-level hierarchy of the virtual prototype matches that of the RTL design.

The virtual prototyping technique preserves the value of the virtual prototype throughout the concurrent development process, a sharp contrast to the throw-away system-level models of traditional approaches. At any point, the RTL models can be swapped back out in favor of the original high-level models to perform performance analysis or run larger bodies of software more quickly.

In fact, after verification to demonstrate the cycle-accurate equivalence of the golden models and the RTL model, they can be swapped at any time. Furthermore, the virtual prototype can be extended to specify a family of related designs using either RTL or architectural models.

8. Conclusion

The demands of SoC development have presented a major challenge to hardware design engineers. The traditional development processes cannot keep pace with the size or complexity of today's systems. High-performance, cycle-accurate, virtual prototypes enable a concurrent system design process that:

• Enables parallel development of hardware and software
• Supports co-verification of hardware and software
• Removes hardware prototypes from the critical path
• Reduces project time and cost
• Makes chip turns much less likely

Virtual prototypes fundamentally change and improve the SoC development process, leading to benefits for the entire team, including the hardware designers.

Graham Hellestrand is founder and CEO of Vast Systems Technology Corp., a provider of system-level design tools. Hellestrand is an emeritus professor of computer science at the University of New South Wales, Australia.