Motivation for HW/SW Co-Design

Hardware/Software Codesign can be defined as the cooperative design of hardware and software. Codesign research deals with the problem of designing heterogeneous systems. One of the goals of codesign is to shorten the time-to-market while reducing the design effort and costs of the designed products. Therefore, the designer has to exploit the advantages of the heterogeneity of the target architecture. The advantages of using processors are manifold, because software is more flexible and cheaper than hardware. This flexibility of software allows late design changes and simplified debugging opportunities. Furthermore, the possibility of reusing software by porting it to other processors, reduces the time-to-market and the design effort. Finally, in most cases the use of processors is very cheap compared to the development costs of ASICs, because processors are often produced in high-volume, leading to a significant price reduction. However, hardware is always used by the designer, when processors are not able to meet the required performance. This trade-off between hardware and software illustrates the optimization aspect of the codesign problem. codesign is an interdisciplinary activity, bringing concepts and ideas from different disciplines together, e.g. system-level modelling, hardware design and software design.

The design flow of the general codesign approach is depicted in the figure above. The codesign process starts with specifying the system behavior at the system level. After this, the system specification is divided into a set of smaller pieces, so-called granules (e.g. basic blocks). In a cost estimation step, values for some cost metrics are determined for these granules. These cost metrics include estimations for hardware or software implementations. Hardware cost metrics are, for example, execution time, chip area, power consumption or testability. Software cost metrics may include execution time and the amount of required program and data memory. After the cost estimation has been performed, the hardware/software partitioning phase computes a good mapping of these granules to hardware or software resulting in sets of granules implemented on hardware (hardware parts) or software (software parts). To implement the system on a heterogeneous target architecture, the mapping requires additional interface parts (implementing the communication and synchronization) between ASICs and processors. The specification refinement step transforms the implementation-independent system specification into hardware and software specifications. All specifications include communication mechanisms to allow the exchange of data between processors and ASICs. Hardware is synthesized from the given specification, the software specification is compiled for the chosen processor. The result of this co-synthesis phase is a set of ASICs and a set of assembler programs for the processors. In a final co-simulation step, the ASICs are simulated together with the processors executing their generated assembler programs. If all performance constraints are met and the cost of the design is acceptable, the codesign process stops, otherwise a re-partitioning step is executed to optimize the design until a sufficient system implementation has been found. In addition to the presented problems, there are further problems in the area of hardware/software codesign: The co-validation problem in system-level design includes different methods to detect errors at different abstraction levels. Co-validation methods include formal verification, simulation or emulation. Formal verification allows to prove formally either the equivalence of different design representations or specific properties, e.g. the absence of dead-lock conditions, of the system specification. Therefore, formal verification represents an important issue in particular for safety-critical applications, e.g. ABS. Formal verification of hardware/software systems is often referred as the co-verification problem. Simulation validates the functional correctness for a set of input stimuli. In most cases, only a small set of all combinations of input stimuli can be simulated. For this reason, simulation only ensures the correct behavior with a certain probability. Simulation can be applied during different design steps including also the co-simulation step after co-synthesis as described before. To speed up the simulation time for simulating a partitioned hardware/software system, emulation is used. Emulation systems map the ASICs onto programmable hardware, e.g. FPGA (FPGA: Field Programmable Gate Array) and couple them with processors on a board. Therefore, emulators provide the closest to real prototypes that is possible. Another important related problem in codesign is software compilation. In contrast to general-purpose systems, the quality of the generated assembly code has more importance than the compilation time. State-of-the-art DSP-compilers, for example, produce an overhead of 200-500% (in some cases even more) as compared to hand-crafted assembler code. Therefore, most software development for DSPs is done manually now a days. For this reason, an important goal is the development of (DSP-)specific code-optimizations for compilers to improve the code quality. Very often, ASIPs are used to implement embedded systems. In most cases, no compiler exists for these ASIPs. Therefore, retargetable compilers have gained great importance to generate code for ASIPs automatically. A problem related to hardware/software partitioning is design space exploration, where the partitioning algorithm should produce a number of different solutions in short computation time. This enables the designer to compare different design alternatives to find appropriate solutions for different objective functions, e.g. high-performance, low-cost or low-power designs. A unified design methodology management supporting specification, validation and co-synthesis of both hardware and software is the overall goal of the codesign research.