Hardware-Software Virtual Prototyping- ISQED 2011

 March 15, 2011, ISQED, Santa Clara, CA—Eshel Haritan, vice president from Synopsys described the benefits of developing systems by starting with virtual prototypes. This technology allows the early matching of hardware and software in a system design to speed up the design process and enable greater abilities for verification and debug.

One challenge in systems-level design is to evaluate the quality of the software so it can be used in verification and debug of the system. The increasing levels of integration and convergence of functions plus wireless capabilities is raising the risk of new designs. The design flows are shifting from hardware centric to more software. The architectures are changing from local memory to highly complex memory hierarchies, and the single processor SoC is becoming a multi-core system.

Processors are also changing from single thread to multi-thread to enable more computer availability for the software. This increase in software content has moved the design bottleneck from the hardware to the software ranks and now software accounts for increasing total percentages of the design time. For a software-based radio, the software may take up to 75 percent of the total design time.

To handle this lager increase in software, the hardware designers have added more processors to the design, but this additional hardware dramatically increases the system-level complexity. To achieve more programmability, the hardware designers have to increase the CPU speed or add more cores to get equivalent performance at lower power. For the hardware designers, the challenge is to get more MIPs while consuming less power.

It’s not only the hardware people who have to overcome obstacles, the software engineers have to partition the software for optimal performance. Multiple processors work best on parallel programs, but SIMD architectures need to have memory and cache coherency to ensure operands are valid across the processing spectrum. Here is the conundrum, both the hardware and the software need to be verified to check the other portion of the design.

For other architectures, there are other challenges. Symmetric multi-processors coordinate through the operating system, while asymmetric multi-processors may have a separate operating system for each type of CPU. The SMP OS creates hardware and software dependencies and requires that some basic services be changed to emphasize safety. Synchronizing the processors and creating interrupt service routines across multi-processors is possible, but not easy. Deadlocks and thrashing can result from missed timing windows and identifying an OS deadlock is very hard.

A SMP design can have relatively good hardware coherency but the results still depend upon the software interactions for operations. Issues with cache coherency between CPU sets and memory levels highlights the software dependence on the hardware. In today’s designs, power management is one of the primary design functions to maximize battery life and manage heat dissipation. As a result, chips have an increasing number of power domains and operating modes that are software controlled.

One example of the problems of hardware-software interactions is a cell phone. At the system integration phase, the design consumed excessive power. All of the individual functions worked properly and the overall system had sufficient performance. The problem turned out to be that the accelerometer was never checked to be in the off mode and stayed on all the time. This function then consumed unbudgeted operating power.

This and other examples of products shows the need for some type of hardware-dependent software debug capability. A high-level view of shared resources and interactions has to be coupled with global single step mode to find problems. The integration team needs to have breakpoints and watchpoints for all critical system applications for data and program tracing. The tools must be deterministic and reproducible with non-intrusive debug capabilities, so the act of inspection doesn’t fix the problems. For highly complex systems, some of the software may come from other companies or groups and may be in binary form only, preventing snooping.

One way to address these challenges is to start the developments with virtual prototypes. This system-level approach uses a software model of all of the hardware functions at a high level of abstraction (transaction-level models) to run the software. Adding external connectivity for I/O and user interfaces allows the simulation and control layers to have visibility and control of all levels in the system.

A software server is used to run all software at once through a scripting interface to permit software debug on a pseudo-hardware platform. Software is debugged and ready for integration as the hardware is brought up. This platform-level interface allows the software to see ports, registers, and the operating core hardware and facilitates the debug processes.

Virtual platforms also enable software analysis and profiling as well as cross debug of the code at a high-level language level. Scripting provides automation for triggers and data capture. Other scripts can enable custom trace and analysis through user tools, force faults, and manage assertions and code coverage analyses.

To create a virtual platform, the developer needs tools for model creation. The virtual tool platform needs to support software debug, code disassembly, provide a virtual prototype analyzer, perform profile and performance analysis and open other windows into the system through scripts. On the hardware side, it has to support development languages like SystemC and hardware debug as well as cross tracing across both domains.

The virtual platform must support multiple views of the system so the hardware and software groups can share models through the development process. The only viable alternative is to make an FPGA prototype which doesn’t have the full visibility and cross probe capabilities and may have different timing than the SoC.

A case study of a 4 core ARM chip shows the value of a virtual prototype. At boot, the system did not initialize. A cross trace of the system while executing the “init” program looked at the expected code and showed that the memory was not initialized. By inserting a breakpoint, they were able to identify a virtual memory issue.

The 4 cores had to work in a virtual memory array but the hardware had to translate the virtual memory access to a physical address. It turned out that this was a system-level coherency issue. CPU 0 was still writing to the memory while CPU 1 was trying to execute the “init” program. This is actually a hardware problem, but the snoop control was not working, so they fixed it in software.

Hardware-dependent software and software-dependent hardware development is very challenging. Virtual prototypes can provide a complete view of the system and can speed up the integration and verification phases of the development by allowing the software and hardware to be completed and debugged in parallel. In addition, the software can be tested in system before the hardware exists.