A Brief Survey of the Recent Developments in Hardware-Software Codesign

Transcription

1 A Brief Survey of the Recent Developments in Hardware-Software Codesign J. Cai 1, D. W. Lloyd 1 and Innes Jelly 1 1 Computing Research Centre, Sheffield Hallam University, England. Abstract This report provides an overview of the recent developments in Hardware-Software Codesign ( codesign ). Representative and exemplary papers at the leading edge of this active research area have been included. This work focuses upon the codesign methodology, the system model and the partitioning method. Finally, a conclusion is deduced. Keywords: Codesign, model, methodology, cosynthesis, cosimulation, Partitioning, VHDL. 1

2 Contents 1 Introduction Background Comparison of Codesign Methods Codesign Methodologies Four Typical Methodologies The Other Methodologies Target Architectures Conclusion References

3 1 Introduction The traditional design path ( Figure 1 ) for computer systems is, early in the design cycle, divided into two separate proceedings which are hardware and software paths respectively. In fact, this separation reflects the varieties of technical constraints in the early stage of computer development history. Theoretically, each application area has its individual, optimal mixture of hardware and software which is best suited to that specific application domain. As technologies progress there is a growing interest in the exploitation of combining hardware and software developments into a more unified discipline called "Hardware- Software Codesign". We have organised the rest of this report into three sections. The fundamentals of Hardware- Software Codesign is introduced in section 2 while section 3 presents details of selected papers. The more important information is listed in tables in order to be compared clearly. A conclusion is given in section 4. 2 Background Although Hardware-Software Codesign is not a completely new topic, interest in it has been growing significantly in recent years. The First International Workshop on Hardware- Software Codesign held in 1992 would be recognised as a milestone in the evolution of codesign. A considerable amount of current research work is concentrating on codesign methodologies and their supporting environments. This is made possible because of the three recent developments[1]. First, today s computing systems deliver increasingly higher performance to end users. Second, new architectures based on programmable hardware circuits can accelerate the execution of specific computations or emulate new hardware designs. Third, recent progress in synthesis and simulation tools for hardware circuits has paved the way for integration CAD environment for codesign of hardware-software systems. We can roughly describe a codesign procedure as the framework in Figure 2. At the very beginning of the system development, the system consisting of both hardware and software components is specified by a unified specification language( CSP, HDLs, C...) or other means(graph-based representation...). The system specification unbiased on hardware or software is most appreciated, which could facilitate the following processes. Supported by cosimulation and performance estimation as well as combining with the various system constraints, hardware-software partitioning(stage 1 in Fig.2) is then carried out. Hardware and software syntheses can be realised in parallel(stage 2,3). After a mixed system implementation is created(stage 4) the evaluation according to the system specification follows(stage 5). The above procedure is usually repeated until a satisfied hardware-software implementation is reached. As compared with Figure 1, it is evident that codesign approach maintains the flexibility of choosing the best solution to a specific application area. The traditional approach can only improve the performance of software or hardware respectively so as to only explore the limited space of design alternatives and then result in a better solution to that part of solution space. 3

4 Figure 1. Traditional Design Path Figure 2. Codesign Framework 4

5 3 Comparison of Codesign Methods As a starting point of the project "Codesigning Parallel Multi-media Systems", we investigated the recent developments in codesign which acts as basis for our project. Table 1 lists the main papers we surveyed. They are not exhaustive but include representative and exemplary papers at the leading edge of this active research area. The criteria used for assessing the work in Table 1 are methodology, system model, partitioning method and architecture. The details relevant to the assessment is illustrated by Table 2 and several figures from Figure 3 through Figure Codesign Methodologies Four Typical Methodologies Papers No. 1, 3, 4, and 8 presented the most comprehensive work which could be classified into four typical categories of codesign methodology. 1. CSP Based Methodology Paper No.1[2] presents a behavioural model of a class of mixed hardware-software systems and defines a codesign methodology for such systems. The methodology includes hardware partitioning, behavioural synthesis, software compilation, and examination on a testbed consisting of a commercial CPU, field-programmable gate arrays, and programmable interconnections. The methodology focuses on two system design tasks: cosimulation and cosysthesis. Based on CSP model it provides the ability to reason naturally about the system s concurrency level. Its hardware-software partitioning takes place at the task level, which needs extensive statistical information supporting the partitioning scheme. The methodology has been weakened by the lack of effective partitioning strategies. It instead provides the effective and rapid system simulation. 2. Graph Based Methodology In contrast with paper No. 1, Rajesh K. Gupta et al. ( paper No. 3)[4] demonstrates the feasibility of synthesising hardware-software systems by using timing constraints to delegate tasks between hardware and software so that performance requirements can be met. The methodology seeks automatic synthesis of the system from a unified specification that is written by using HardwareC. System functionality is then captured and converted into a graph-based representation which expresses the system timing constraints and functionality. The novel aspect of this paper is that it presents automatic system partitioning. From a given set of sequencing graphs and timing constraints between operations, two sets of sequencing graphs are created such that one can be implemented in hardware and the other in software. A key difference to paper No. 1 is that the system partitioning takes place at the operaion level. Finally,the lower level specification language Hardware C as an extension of system synthesis could be replaced by the more powerful ones, which would bring about higher level system description. 5

6 No. Author Title Main Topic 1 Donald E. Thomas et al. ( Carnegie Mellon University ) A model and Methodology for Hardware-Software Codesign[2] A methodology with mixed system model that facilitates cosynthesis and cosimulation 2 Asawaree Kalavade et al. ( University of California, Berkeley ) A Hardware-Software Codesign Methodology for DSP Application[3] A codesign methodology applicable to digital signal processing and communications system 3 Rajesh K. Gupta et al. ( Stanford University ) Hardware-Software Cosynthesis for Digital Systems[4] A synthesis oriented approach to digital circuit design 4 Sanjaya Kumar et al. ( University of Virginia ) A Framework for Hardware/Software Codesign [5] An integrated hardware-software model, System cosimulation and evaluation 5 Nam S. Woo et al. ( AT&T Bell Labs & Princeton University ) Codesign from Cospecification[6] A cospecification methodology 6 Mani B. Srivastava et al. ( University of California at Berkeley ) Rapid-Prototyping of Hardware and Software in a Unified Framework[7] Handling of board level module generation, System software generation, and hardware integration in a unified framework 7 Kunle A. Olukotun et al. ( Stanford University ) A Software-Hardware Cosynthesis Approach to Digital System Simulation[8] A cosynthesis approach to digital system simulation 8 Massimiliano Chiodo et al. ( Magneti Marelli & University of California at Berkeley & Politenico di Torino ) Hardware-Software Codesign of Embedded Systems[9] A formal methodology for specifying, modelling, automatically synthesising, and verifying mixed software-hardware systems 9 Martyn Edwards et al. ( UMIST, Manchester,UK ) A Development Environment for the Cosynthesis of Embedded Software/Hardware Systems[10] An integrated cosynthesis environment 10 Rajesh K. Gupta et al. ( University of Illinois at Urbana-champaign & Standford University ) Program Implementation Schemes for Hardware- Software Systems[11] An approach to system cosynthesis Table 1. The Paper List for Comparison 6

7 No. Top Level System Specification means Implementation of Application Hardware Proposed Application Area Partitioning method 1 High-level description language based on CSP[12] ASICs and offshelf hardware Embedded systems, e.g. speech phoneme recognition and deta compression/encryption Manual operation 2 A graph-based representation Custom data paths, FSMs, glue logic and programmable processors Digital-processing and communications systems, e.g. full-duplex telephone channel simulator and Modem transmitter/receiver Manual operation 3 HDL ( HardwareC ) ASICs Embedded real-time systems, e.g. Ethernet-based network coprocessor and mixed implementation of a graphics controller Semi-automatic aided by algorithm based on the cost model 4 VHDL ASICs and offshelf hardware 5 Prototype codesign specification language ( based on C ) ASICs Parallel digital systems, e.g. several hardware/software alternatives for a sort function Embedded systems, e.g. tic-tactoe playing system Manual operation Manual operation 6 VHDL ASICs and offshelf hardware The systems which interact with their environment in real-time, e.g. custom VME board for a real-time speech recognition system and multi-sensory robot control system Manual operation 7 HDL ( Verilog ) not mentioned Digital systems, e.g. clocked state machine Aid by Algorithm 8 Higher level language ( Esterel, StateCharts, or a subset of VHDL ) ASICs Small control-dominated embedded systems, e.g. automotive electronics Manual operation 9 C programming language FPGAs and offshelf hardware Embedded systems, e.g. data decoding function Aid by tools 10 HDL ( HardwareC ) ASICs Systems that contain both application-specific and predesigned reprogrammable components not mentioned Table 2. The List with Specified Details 3.VHDL Based Methodology 7

8 Paper No. 4[5] suggests an alternative for codesign methodology which is based on coloured Petri net model[13,14]. Thanks to the VHDL s descriptive ability, the system functions are specified as concurrent processes in VHDL that interact. System functions are mapped onto separate physical units and then software processes. The iterative performence decomposition, hardware/software partitioning, refinement, and alternative evaluation for each system function constitute the main route of this approach. VHDL, at the same time, provides building tools facilitating the procedure above. A clear advantage of adopting VHDL throughout the codesign process is that it offers more benefits than other hardware description language do. Its demonstration of creating executable models of computer architectures independent of implementation attributes has been proved by the example[15]. On the other hand, the method which VHDL description for a software component in the system can be easily transfered into the software development remains to be researched. 4. CFSM Based Methodology A rigorous codesign methodology that supports automatic synthesis, optimisation, and verification is introduced by Paper No. 8[9]. Supported by the model of Codesign Finite State machine( CFSM ), an extension of classical Finite State Machine( FSM ), design starts within a unified framework that is unbiased towards an implementation. After interactive partitioning, this approach automatically synthesises the entire design, including hardwaresoftware interface, which is via two auxiliary models, standard logic netlist and s-graph, derived from CFSM specification. FSM model derived from CFSM is compatible with the input format of many formal verification algorithms. In addition to the formal methodology, another key feature of this approach is the graceful transition from specification to implementation, which is achieved through the maintenance of the finite state machine model throughout. In this reaserch there is no indication of how to partition a specification into software and hardware using algorithms. Because of the obstacle of state explosion, this methodology is well-suited to small control-dominated embedded systems The Other Methodologies Nam S. Woo et al. have been working on investigating automatic partitioning of behaviour into hardware and software. Their research[6] focused on specification methods for codesign. By using Object-Oriented Functional Specifications( OOFS ) a system is described into three groups--hardware, software, and codesign and then treated separately. While OOFS for codesign group can been translated into C++ and Bestmap-C for implementation of software and hardware respectively by the compiler, partitioning still needs manual operation, which indicates further research to be done. Nevertheless, this research offers promising technology transfer from Software Engineering to Codesign. Paper No. 6 s main contribution was the handling of board level module generation, system software generation, and hardwaresoftware integration in a unified framework[7]. A simulation compiler in paper No. 7[8] can receive specification written in HDL and make software-hardware partitioning and scheduling based on a simulation architecture. The aim of this partitioning algorithm is speedingup the execution time of whole system. Paper No. 9 brought forward a development environment for design, cosynthesis and performance evaluation of embedded software/hardware systems. C source program for system specification is translated into machine code for an i960 microprocessor and FPGA configuration data for performance critical regions of the source program[10]. As in paper No. 7, The aim of partitioning is 8

9 speedup. The environment provides the profiler tool identifying critical regions and the partitioner facilitating designer making decisions. Paper No. 10 and No. 3 treated same topic but No. 10 is exact supplement to the content of No. 3. Asawaree kalavade et al. s research into methodology for DSP application[3] could give us some heuristics relevant to codesigning multi-media system since the research has been involved in the design methodology for the heterogeneous systems including analogue components such as physical telephone channel. 3.2 Target Architectures In this section we consider the system architectures which are assumed by the codesign methodologies described above. Figure 3 illustrates the target architecture supposed in paper No. 3 and No. 10 while paper No. 1 adopts the target architecture as in Figure 4. A comprehensive and complicated architecture from paper No. 6 appears in Figure 6 Compared with an alternative( Figure 5) presented in paper No. 9. Figure 3. The Target Architecture Figure 4. The Target Architecture in Paper No. 3 and No. 10 in Paper No. 1 Figure 5. The Target Architecture in Paper No. 9 9

10 Comparing the architectures from Fig. 3 through Fig. 6, the ones in Fig. 3 and 4 suffer more restriction in terms of communication bottle-neck due to their architecture models of a single shared buses. Despite some improvement in Fig. 5 the most successful architecture is demonstrated in Fig. 6 which could be applied to a diverse set of application. The architecture is templated into a structure with 4 layers, which provides flexibility and scalebility. However the mapping of processes in the specification into different layers can cause the most complex arrangement 4 Conclusion Figure 6. The Target Architecture in Paper No. 6 Analysis of the papers listed in table 1 led to the following conclusions. Due to advances in hardware technology and the maturity of hardware synthesis and simulation tools, the complexity and scale of codesign systems are substantially increasing. This has resulted in comprehensive research into the technology transfer from Software Engineering to Codesign in order to harness the complexity, enhance the reliability and reduce the cost. Establishing a system model for each methodology plays an important role. This is particularly true for the complex systems. As the papers in table 1 show, paper No.1 models system by using CSP model, No.4 by Petri nets, and No. 8 Codesign Finite State Machine and some others also adopt corresponding models developed for the system simulation and synthesis. The importance of system model is evident but is often ignored by the developers 10

11 who are dealing with small scale systems. A system model can provide a detailed understanding of system behaviour and a transformation capability that allows generation of design alternatives. A system model s ability to span different levels of system development is essential for the validation of system-level models and their hardware/software implementations. A large number of codesign methods in table 2 employs HDLs and VHDL for system specification. Compared with other HDLs, VHDL deserves special attention because of the following reasons[16]. 1. It has become an IEEE standard used as an interface between humans and design automation tools. 2. Many different design methodologies and design technologies are supported by VHDL. 3. It is independent of both technology and process. 4. It supports behavioural description of hardware from the digital system level to the gate level. 5. Its philosophy is similar to that of many modern programming languages so that it is well facilitated by the design decomposition aids ( e.g. packages, configuration declarations and the concept of multibodies). Different applications require different target architecture which best matches the system s cost-effectiveness as well as their varieties of constraints. In general, it is possible to classify applications into a certain number of different domains according to their computational complexities and respectively specific constraints so that the target architecture could rather be chosen in scientific and systematic manner than in experience. Unfortunately, there has been less research into this interesting area. 5 References [1] Giovanni De Micheli, "Computer-Aided Hardware-Software Codesign", in IEEE Micro, Vol. 14, No. 4, August 1994, pp [2] Donald E. Thomas, Jay K. Adams, and Herman Schmit, "A Model and Methodology for Hardware- Software Codesign", in IEEE Design & Test of Computers, Vol. 10, No. 3, September 1993, pp [3] Asawaree Kalavade and Edward A. Lee, "A Hardware-Software Codesign Methodology for DSP Application", in IEEE Design & Test of Computers, Vol. 10, No. 3, September 1993, pp [4] Ralesh K. Gupta and Giovanni De Micheli, "Hardware-Software Cosynthesis for Digital Systems", in IEEE Design & Test of Computers, Vol. 10, No. 3, September 1993, pp [5] Sanjaya Kumar, James H. Aylor, Barry W. Johnson, and Wm. A. Wulf, "A Framework for Hardware/Software Codesign", in IEEE Computer, Vol. 26, No. 12, December 1993, pp [6] Nam S. WOO, Alfred E. Dunlop, and Wayne Wolf "Codesign from Cospecificaton", in IEEE Computer, Vol. 27, No. 1, January 1994, pp [7] Mani B. Srivastava and Robert W. Brodersen, "Rapid-Prototyping of Hardware and Software in a Unified Framework", Proc. Intl. Conf. Comp. Aided Design, IEEE Press, 1991, pp [8] Kunle A. Olukotun, Rachid Helaihel, Jeremy Levitt, and Ricardo Ramirez, "A Software-Hardware Cosynthesis Approach to Digital System Simulation", in IEEE Micro, Vol. 14, No. 4, August 1994, pp

12 [9] Massimiliano Chiodo, Paolo Giusto, Attila Jurecska, Harry C. Hsieh, Alberto Sangiovanni-Vincentelli, and luciano Lavagno, "Hardware-Software Codesign of Embedded Systems", in IEEE Micro, Vol. 14, No. 4, August 1994, pp [10] Martyn Edwards and John Forrest, "A Development Environment for the Cosynthesis of Embedded Software/Hardware Systems", Personal Communications, [11] Rajesh K. Gupta, Claudionor N. Coelho Jr., and Giovanni De Micheli, "Program Implementation Schemes for Hardware-Software systems", in IEEE Computer, Vol. 27, No. 1, January 1994, pp [12] C.A.R. Hoare, Communicating Sequential Processes, Prentice-Hall, Englewood Cliffs, N.J., [13] T. Agerwala, "Putting Petri Nets to Work", IEEE Computer, 12, no. 12, ( December 1979 ), [14] Joel M. Schoen, Editor, Performance and Fault Modeling with VHDL, Prentice-Hall, Englewood Cliffs, N.J., [15] Maximo H. Salinas, Barry W. Johnson, and James H. Aylor, "Implementation-Independent Model of an Instruction Set Architecture in VHDL", in IEEE Design & Test of Computers, Vol. 10, No. 3, September 1993, pp [16] Roger Lipsett, Carl Schaefer, and Cary Ussery, VHDL: Hardware Description and Design, Kluwer Academic Publishers,