Today's system-on-a-chip (SoC) designs arehardware/software-systems-on-silicon rather than just gates on achip. SoC-based system development is a combination of tightlyintegrated software and hardware using ASIC or FPGA technology asthe main hardware platform.
Many products such as cell phones, PDAs, and GPS devices requirecomplex, low-power SoCs. Software content is the prevailingdifferentiator between products while hardware is the platform adesigner uses to implement the design. Software developersoutnumber hardware developers almost two to one for any givenSoC-based design. Despite the large software effort, SoC and ASICdesign methodologies are very hardware oriented. Softwaredevelopers are developing embedded-system software the same waysystem designers develop board-level software.
Current Design Methods
Software designers can write high-level applications usingoff-the-shelf RTOS emulators or development tools, but are forcedto wait for a hardware prototype or real target hardware to finishtheir development. In real-time systems, hardware interfaces areoften the most crucial part of software developmentgettinghardware early is imperative to completing the design on time.Furthermore, software developers are accustomed to using debuggingtools that run on a PC and execute at speeds that are close to theactual speed of the final product.
On the other hand, SoC (ASIC or FPGA) developers are accustomedto working with the details of the hardware design. Their concernis to verify the hardware with a cycle-accurate, and ultimatelytiming-accurate, simulation. HDL design, gate-level synthesis, andtiming analysis are very involved and relatively slow designprocesses. Designers can use co-simulation tools in theverification process to validate the hardware design. Thesedesigners 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 softwaredeveloper. In addition, ASIC development tools are very expensivecompared to software development tools.
A Software/Hardware Design Gap Exists
Software developers are accustomed to using development toolsand debuggers that execute code quickly. Setting breakpoints andstepping through code occurs with no perceptible delay frominstruction to instruction.
Figure 1: The design gapsoftware-centricversus hardware-centric tools.
Verilog and VHDL developers are accustomed to viewingcycle-by-cycle simulations that return graphical updates orwaveforms in a time-accurate manner. This level of simulationdetail makes Verilog/VHDL simulators very slow compared to RTOSemulators, software development tools, and debuggers. Thedifference in simulation/execution time is typically four to fiveorders of magnitude between HDL simulation and RTOS emulation.Debuggers execute in real-time or near real-time while Verilog andVHDL simulators are benchmarked, at most, at a few thousand cyclesper second.
Software development tools are fast but have no hardwarevisibility. Verilog/VHDL simulators and co-simulators return verydetailed time-accurate hardware visibility, but are too slow foruseful software debugging.
How to Bridge the Design Gap
The obvious way to allow software designers to complete theirsoftware design is to provide them with visibility into thehardware. One way to accomplish this task is to build hardwaremodels in C/C++ and integrate them into RTOS emulators. Hardwaremodels should contain all of the interfaces the software needs,such as register sets, controls, and data buffers, to allowsoftware designers to design device drivers and hardwareinterfaces.
For SoC designers, the gap is rarely seen from a hardwarepoint-of-view. An SoC designer's concern is how to reducesimulation time. One way to reduce simulation time is to model thehardware in a higher level of abstraction, again using C/C++. Whilehigh-level functionality is a good place to start, the SoCdesigner's ultimate task is to make the detailed hardware designwork. For this reason, the design gap must be bridged from thetop down. However, the SoC designer would like to avoid bugsdue to system architecture flaws and requests to change hardwarefrom the software designers.
Figure 2: Design methods and tools for bridging thehardware/software design gap.
In Figure 2 , the higher up the pyramid you go, the higher thelevel of abstraction and the faster code executes and simulates. Asyou go down the pyramid, the hardware modeling becomes moredetailed, thus the simulation/execution time is slower. Inaddition, development time is longer as you go down thepyramidas analysis goes from abstract to detailed, designtime increases. The tools a designer would use throughout thehardware/software design process include:
- RTOS emulator
The common RTOS emulator is an extension of a standardsoftware-development tool and debugger. The debugger is RTOS aware,meaning that the tool has visibility into the RTOS tasks andscheduling functions.
- RTOS emulator with functional hardware extension
The environment contains a software debugger and visibility intothe target hardware. This environment should be processorindependent and should have code compiled to run on the PC's orworkstations' native processor. The peripheral hardware can bemodeled in C/C++ or anther suitable language and connected to thedebugger environment through interfaces that allow the software tosee registers, FIFOs, buffers, and datapaths. The internal workingsof the peripheral can be presented to the user through GUIs, or asextensions to the debugger. The advantage of this environment isthat the software-code execution time is very fast. Several EDAcompanies are providing tools to help create theseenvironments.
- Software development tool with ISS and cycle-accuratehardware model
This is a software development environment that is also hardwareaware. In this case, the platform environment emulates the targetmicroprocessor core using a cycle-accurate ISS. The tool can modelthe peripheral hardware as well as all the memory systems, internaland external, with cycle accuracy at a high-level ofabstraction.
There are several major differences between this type of VirtualPlatform environment and the Hardware-Aware RTOS Emulator:
- The environment is processor specific. In other words, the ISSis an ARM, MIPS, PowerPC, or some other microprocessoremulator.
- RTOS is ported to the microprocessor-based platform rather thanbeing emulated.
- The hardware model is cycle-accurate, letting the designerdebug cycle-timing-critical software algorithms.
- You can debug boot code, since the memory-system model canmodel real hardware behavior.
- Software execution is one to two orders of magnitude slowerthan the run time of the hardware-aware RTOS Emulator. However, itis four to five orders of magnitude faster than RTL simulationusing co-simulators.
A co-simulator is a hybrid tool that combines a softwaredevelopment tool with an HDL simulator. Several EDA companiesprovide this type of tool. Designers use co-simulators primarily todebug microprocessor-based chip designs by hardware and ASICdesigners. You target software written to run in this environmentto exercise the hardware rather than to produce end-productapplication software.
Proposed Design Method
Step 1. Use the RTOS emulatorto write high-level software applications.
Step 2. Use the RTOS emulator with functional hardware extension to write software applications that include hardwaredevice drivers. You can analyze and test system-level functionalityat this point.
Step 3. Use the software development tool with ISS andcycle-accurate hardware model to develop and debug production-readysoftware (RTOS, device drivers, and applications). You can analyzeand test system-level performance at this point.
Step 4. Use co-simulation to complete the detailed SoCdesign.
We need a new method of design to improve an SoC-based systemdevelopment's chances of being completed on time with fewer flaws.You must place new emphasis on getting the system design done earlyand correctly before committing the hardware to implementation or,worst yet, manufacturing. Software being a major factor in hardwaredesign dictates that the design flow has to be top-down with thesoftware at the top of the pyramid. Bridging the design gap isimportant to seamlessly bringing software and hardware developmenttogether to reduce both time-to-market and system flaws.
About the Author