Bridging the Hardware/Software Design Gap

Today's system-on-a-chip (SoC) designs are hardware/software-systems-on-silicon rather than just gates on a chip. SoC-based system development is a combination of tightly integrated software and hardware using ASIC or FPGA technology as the main hardware platform.

Many products such as cell phones, PDAs, and GPS devices require complex, low-power SoCs. Software content is the prevailing differentiator between products while hardware is the platform a designer uses to implement the design. Software developers outnumber hardware developers almost two to one for any given SoC-based design. Despite the large software effort, SoC and ASIC design methodologies are very hardware oriented. Software developers are developing embedded-system software the same way system designers develop board-level software.

Current Design Methods
Software designers can write high-level applications using off-the-shelf RTOS emulators or development tools, but are forced to wait for a hardware prototype or real target hardware to finish their development. In real-time systems, hardware interfaces are often the most crucial part of software development—getting hardware early is imperative to completing the design on time. Furthermore, software developers are accustomed to using debugging tools that run on a PC and execute at speeds that are close to the actual speed of the final product.

On the other hand, SoC (ASIC or FPGA) developers are accustomed to working with the details of the hardware design. Their concern is to verify the hardware with a cycle-accurate, and ultimately timing-accurate, simulation. HDL design, gate-level synthesis, and timing analysis are very involved and relatively slow design processes. Designers can use co-simulation tools in the verification process to validate the hardware design. These designers typically use test software with co-simulators; however, co-simulators are rarely used for any useful software development. Simulation execution time is excruciatingly slow for a software developer. In addition, ASIC development tools are very expensive compared to software development tools.

A Software/Hardware Design Gap Exists
Software developers are accustomed to using development tools and debuggers that execute code quickly. Setting breakpoints and stepping through code occurs with no perceptible delay from instruction to instruction.

Figure 1:  The design gap—software-centric versus hardware-centric tools.

Verilog and VHDL developers are accustomed to viewing cycle-by-cycle simulations that return graphical updates or waveforms in a time-accurate manner. This level of simulation detail makes Verilog/VHDL simulators very slow compared to RTOS emulators, software development tools, and debuggers. The difference in simulation/execution time is typically four to five orders of magnitude between HDL simulation and RTOS emulation. Debuggers execute in real-time or near real-time while Verilog and VHDL simulators are benchmarked, at most, at a few thousand cycles per second.

Software development tools are fast but have no hardware visibility. Verilog/VHDL simulators and co-simulators return very detailed time-accurate hardware visibility, but are too slow for useful software debugging.

How to Bridge the Design Gap
The obvious way to allow software designers to complete their software design is to provide them with visibility into the hardware. One way to accomplish this task is to build hardware models in C/C++ and integrate them into RTOS emulators. Hardware models should contain all of the interfaces the software needs, such as register sets, controls, and data buffers, to allow software designers to design device drivers and hardware interfaces.

For SoC designers, the gap is rarely seen from a hardware point-of-view. An SoC designer's concern is how to reduce simulation time. One way to reduce simulation time is to model the hardware in a higher level of abstraction, again using C/C++. While high-level functionality is a good place to start, the SoC designer's ultimate task is to make the detailed hardware design work. For this reason, the design gap must be bridged from the top down. However, the SoC designer would like to avoid bugs due to system architecture flaws and requests to change hardware from the software designers.

Figure 2:  Design methods and tools for bridging the hardware/software design gap.

In Figure 2, the higher up the pyramid you go, the higher the level of abstraction and the faster code executes and simulates. As you go down the pyramid, the hardware modeling becomes more detailed, thus the simulation/execution time is slower. In addition, development time is longer as you go down the pyramid—as analysis goes from abstract to detailed, design time increases. The tools a designer would use throughout the hardware/software design process include:

1. RTOS emulator
   The common RTOS emulator is an extension of a standard software-development tool and debugger. The debugger is RTOS aware, meaning that the tool has visibility into the RTOS tasks and scheduling functions.
   
   
2. RTOS emulator with functional hardware extension
   The environment contains a software debugger and visibility into the target hardware. This environment should be processor independent and should have code compiled to run on the PC's or workstations' native processor. The peripheral hardware can be modeled in C/C++ or anther suitable language and connected to the debugger environment through interfaces that allow the software to see registers, FIFOs, buffers, and datapaths. The internal workings of the peripheral can be presented to the user through GUIs, or as extensions to the debugger. The advantage of this environment is that the software-code execution time is very fast. Several EDA companies are providing tools to help create these environments.
   
   
3. Software development tool with ISS and cycle-accurate hardware model
   This is a software development environment that is also hardware aware. In this case, the platform environment emulates the target microprocessor core using a cycle-accurate ISS. The tool can model the peripheral hardware as well as all the memory systems, internal and external, with cycle accuracy at a high-level of abstraction.
   
   There are several major differences between this type of Virtual Platform environment and the Hardware-Aware RTOS Emulator:
   • The environment is processor specific. In other words, the ISS is an ARM, MIPS, PowerPC, or some other microprocessor emulator.
   • RTOS is ported to the microprocessor-based platform rather than being emulated.
   • The hardware model is cycle-accurate, letting the designer debug cycle-timing-critical software algorithms.
   • You can debug boot code, since the memory-system model can model real hardware behavior.
   • Software execution is one to two orders of magnitude slower than the run time of the hardware-aware RTOS Emulator. However, it is four to five orders of magnitude faster than RTL simulation using co-simulators.
   
   
4. Co-Simulator
   A co-simulator is a hybrid tool that combines a software development tool with an HDL simulator. Several EDA companies provide this type of tool. Designers use co-simulators primarily to debug microprocessor-based chip designs by hardware and ASIC designers. You target software written to run in this environment to exercise the hardware rather than to produce end-product application software.

Proposed Design Method

We need a new method of design to improve an SoC-based system development's chances of being completed on time with fewer flaws. You must place new emphasis on getting the system design done early and correctly before committing the hardware to implementation or, worst yet, manufacturing. Software being a major factor in hardware design dictates that the design flow has to be top-down with the software at the top of the pyramid. Bridging the design gap is important to seamlessly bringing software and hardware development together to reduce both time-to-market and system flaws.

About the Author

Jim Bruister is president of SoC Solutions and a 20-plus year veteran of the ASIC and semiconductor industry. Most of Jim's career has been in design and development of SoCs and embedded-microprocessor-based chip design. Jim founded SoC Solutions in 2000 to address the design problems associated with software/hardware SoC co-development. Jim is a graduate of Georgia Tech, and has previously worked for Mostek, VLSI Technology (now Philips), and Home Wireless Networks.