Cim++: An Object-Oriented Design and Simulation ... - CiteSeerX

Cim++: An Object-Oriented Design and Simulation Framework for Education of Hardware/Software Codesign Hadi Esmaeilzadeh and Zainalabedin Navabi Electrical and Computer Engineering Department, University of Tehran, Tehran, Iran [email protected] and [email protected] Abstract-Hardware/software codesign deals with the design, refinement, optimization, and realization of heterogeneous embedded systems. Training the current hardware designers with this novel design paradigm with exploitation of their priori knowledge about RT Level hardware implementation is the main concern of the proposed framework, Cim++. This paper presents the structure of Cim++ which enables C++ to be used as an OO hardware/software codesign that supports concurrency in description and inheritance in design. Also provided, are examples and comparisons that present the power of Cim++ as a leading hardware design oriented framework.

1

Introduction

Including custom hardware design and software implementation, embedded system design is the current experience of digital system design which differs in many aspects from traditional approach of hardware design and implementation. On the other hand, the hardware/software codesign methodology gathers the design, refinement, optimization, and realization of heterogeneous embedded systems under a unified framework. Bringing up the current designers with this new design paradigm requires toolsets that can simply and densely provide information about codesign and co-optimization while exploiting their priori knowledge and experiences about RT Level implementation of hardware design. Utilizing the object-oriented facilities of C++ for both hardware and software design and implementation, Cim++ is an object-oriented library developed to enable C++ to be used as a framework for hardware/software codesign and cosimulation. Cim++ supports both concurrency, an essential hardware description feature, and inheritance, a powerful technique for reusability enhancement. These features and easy-to-use structure of the Cim++ library makes it a suitable framework for education of hardware/software codesign. Also Cim++ is coupled with a Verilog-C++ like script, CimScript, which hides the simulation aspects from the designer and reduces extra effort required for him/her to adapt with a nonHDL design framework. This paper presents the structure and simulation mechanisms of Cim++ and demonstrates its suitability for being and educational framework for hardware/software codesign. The rest of the paper is organized as follows: Section 2 presents an overview on hardware/software codesign with an

educational insight. Section 3 provides a brief introduction to SystemC, and Section 4 explains the structure of Cim++. Several comparisons and discussions about pros and cons of using SystemC and Cim++ as an educational framework for hardware/software codesign are presented in Section 5. The paper is concluded in Section 6.

2

Hardware/Software Codesign-An Educational Approach

Hardware/Software codesign is the design, refinement, and optimization of the hardware and software parts of a system. The hardware/software codesign paradigm tries to alleviate the problems of heterogeneous systems design. Responding to the ever-increasing needs of the changeable market of the microelectronics industry with reduced design effort and costs and the time-to-market shortening is the primary goal of the codesign. In the embedded system design experiences, the designer involves with two different tasks, designing a custom hardware bearing the time-critical portions of overall system mission and implementation of the other parts as some software programs running on one or more embedded processors. Besides, the designer must simultaneously optimize hardware and software partial designs. Therefore, the designer must benefit from the heterogeneity of the target architecture. Using embedded processors in a system versus designing the whole system, using custom hardware implementation has several advantageous: •

Software is more flexible and cheaper than hardware; its flexibility allows late design changes and simplified debugging and verification opportunities.

•

Software is easily portable which reduces the time-tomarket and the design cost.

•

Since processors are often produced in high-volume, in most cases the use of processors is very cheap compared to the development costs of ASICs.

However, custom hardware implementations are used by the designer, when processors are not capable of meeting the performance constraints. Figure 1 illustrates a possible configuration of an embedded system.

divided into a set of smaller pieces, so-called granules (e.g. basic blocks). In the partitioning step, a cost estimation technique is employed to evaluate some cost metrics for these granules. These evaluations indicate whether a granular must be implemented as a hardware part or software part. For example, Hardware cost metrics are execution time, chip area, power consumption or testability, while software ones may include execution time and the amount of required program and data memory. To implement the system on a heterogeneous target architecture, the mapping requires additional interface parts (implementing the communication and synchronization) between the hardware parts and the processes running on the processors.

Figure 1. A possible embedded system.

After the partitioning phase, the whole system is cosimulated. Also, the target-independent system specification is refined to the lower design abstraction level. The hardware parts are refined to the register transfer level descriptions and on the side the software parts are transformed to the simple low level C/C++ programs. After the completion of refinement stage the system is verified through co-simulation and after passing the verification phase is co-synthesized to the target architecture. Consider that in this refinement phase, the interfacing parts are reduced to the handshaking and data transform mechanisms. Co-synthesis is in fact a simple phase which the hardware synthesis tools map the RTL descriptions to the target FPGA or ASIC library to realize the costume hardware parts of the system while a software compiler translates the C/C++ codes to the object code of the target embedded processor. In a final cosimulation step, the costume hardware portions of the system are simulated together with the processors executing their binary format 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 satisfactory system implementation has been found. It is apparent that hardware/software codesign is an interdisciplinary design experience which brings concepts and ideas from different disciplines such as system-level modeling, hardware design and software design, together. To be able to design an embedded system with the hardware/software design paradigm, a designer who is familiar with the traditional RT level design flow must first move to some higher abstraction levels and learn how properly interface the software and hardware parts of a heterogeneous system. Also, he/she has to acquire some skills about software design and refinement. In most cases, the designers are familiar with these aspects of hardware/software codesign in a separate form. But, what they need to learn, is putting all of these together under a simple and intimate design and simulation framework.

Figure 2. Embedded system design flow.

A general hardware/ software codesign flow is depicted in Figure 2. The codesign process starts with implementation of the specification of the system at the system level as a golden model of the system. After this, the system specification is

This framework must be compatible and very similar to the design tools they currently use such as HDLs like Verilog. Also, the concepts that the framework introduces must be as simple as possible to avoid confusions. It must exploit the priori knowledge of the learning designer to help him to put its

experiences in different areas of design altogether in a unified framework.

3

SystemC, Hardware/Software Codesign Framework

class is the base class of all hardware cores modeled using Cim++. The format of this class must be followed in all hardware describing classes. CimCore class listing is depicted in Figure 4.

SystemC [2] is a C++ library which enables and accelerates system-level intellectual property (IP) model exchange and codesign using a common C++ modeling platform. The fundamental building block of a SystemC description is a process. A process is a C or C++ function that implements the behavior of a component. SystemC provides three different process types that can be used for modeling of a hardware or software component; synchronous processes, asynchronous blocks, and asynchronous processes. In fact a complete modeled system is a set of multiple concurrent processes. Processes communicate with one another through signals. Components of the under-description system are classes that are part of the SystemC library. Also, all the required data and signal types for hardware modeling are provided in SystemC. The user should understand how to use the classes, templates, macros, and functions implemented in the library without a complete and in detail understanding of the way they are implemented. Using the SystemC library, a system can be specified at various design abstraction levels. At the highest level, only the functionality of the system may be modeled. For hardware implementation, descriptions can be written either in a functional style or in a register-transfer level style. Figure 3 depicts an RTL implementation of a simple counter using SystemC. SystemC consists of a set of header files describing the classes and a link library that contains the simulation kernel. The header file can be used by the designer in her/his program. Any ANSI C++-compliant compiler can compile SystemC, together with the program. During linking, the SystemC library, which contains the simulation kernel, is used. The resulting executable serves as a simulator for the system described.

4

Cim++, Codesign Framework with Concurrency and Inheritance Support

4.1 Cim++ and Hardware Concurrency At first glance, it seems that hardware modules are the most important objects of a digital VLSI system or circuit, but in fact, such a system is a composition of some wires, which are connected to each other through some operations. Hence, what a system or circuit performs is changing values on these interconnections. The Cim++ [1], library is a set of classes that encapsulate various kinds of interconnecting wires (see Table 1). Nevertheless, hardware modules cannot be ignored. They are living components, continuously converting values on their incoming wires to values on their outgoing ones. CimCore

Figure 3. SystemC listing of a sample counter.

In Cim++ each hardware object has some evaluation function (which we call always-functions) that always maps values on inputs to values on intermediate and output wires. These objects can be considered as sleeping components, which wake up on the occurrence of events on their inputs. The wake up strategy is implemented as a loop, which gives control to all components in each of its iterations. Each component checks its input wires and executes its evaluation function(s) if necessary. These new values must be held pending until the next iteration. The main benefit of this scheduling method is that it can easily be extended for distributed simulation. In Cim++, hardware description is done using a C++/Verilog like script, designed to simplify the description process and hide simulation semantics from the designer, which is then translated into Cim++ classes. (See Figure 5 and Figure 6 as sample scripts).

4.2 Hardware Inheritance in Cim++ Natively, C++ supports inheritance as a basic object oriented construct, and Cim++ utilizes this existing feature for hardware design, which is illustrated with an example. It is clear that a counter is-a register with counting capability. First a typical synthesizable register is implemented using Cim++ (see Figure 5), then a counter is derived from it (see Figure 6). Only an extra input cntEn is added and then the evaluateData() always-function is overwritten in a way that adds the counting capability to it without recoding a register’s functionality. The coding effort reduction and reusability enhancement in the implementation of the Counter core is clear.

class CimCore { protected: //Input(s); Output(s); Wire(s); Instance(s); Input copy wire(s) //Simulation loop functions virtual void copyInWire () {return;} virtual void clearEvent () {return;} virtual void applyCurrValue () {return;} virtual bool isInterEvent () {return false;} //Always function(s) virtual void evaluate () {return ;} public: CimCore () {;} //Constructor without configuration CimCore (/*In(s), Out(s)*/ ) //Structure configurator constructor {configure(/*In(s), Out(s)*/ );} //Structure configurator virtual void configure (/*In(s), Out(s)*/ ) {;} //Simulation function void simulate () { copyInWire(); do { evaluate(); clearEvent(); applyCurrValue(); } while (isInterEvent()); } };

Figure 4. C++ listing of the CimCore class. All hardware describing classes must be derived form CimCore and overwrite the simulation loop functions and add the required alwaysfunctions.

An important aspect of education is that the medium of education must not add extra complication to the topics that are the main concern of training. SystemC is a template based design framework and has its own specific syntax and semantics. One who wants to design a system using SystemC must first learn SystemC syntax and semantics. This requires many time and leads to deviation from the original objective, learning hardware/software codesign. Since the Cim++ design framework provides a script which is so alike to the Verilog, the learning designer is not exposed with a large amount of syntax and semantic information and can easily go ahead to its desire, hardware/software codesign learning. In addition to the easy learning structure of the framework, it must be able to exploit the priori knowledge of one who wants to use it as an educational medium. The target designers in education of hardware/software codesign are familiar with the RT level design and Cim++ exploits this knowledge effectively. Because the Cim++ framework is designed with RTL design support basis and supports effectively higher level aspects of embedded system design, it easily can be used as the education tool of hardware/software codesign. On the other hand, SystemC is not designed for RTL design however it supports RTL design. Therefore, using Cim++ as the education framework, the learning designer only learns the aspects and principles of hardware/software codesign without confusing with syntax, semantics of design facility. While SystemC as an alternative codesign framework, suffers from its complicated structure which avoids it to be used as an effective education framework for hardware/software codesign, Cim++ with a simple structure and an associated Verilog-C++ like script is an appropriate simulation and design framework for education of hardware/software codesign.

6

Figure 5. Register CimScript. CimCore is the base class of all hardware cores described using Cim++.

Figure 6. Counter CimScript. Inherited from Register, the description of Counter specializes Register with adding counting capability to it.

5

Comparison and Discussion

After an introductory overview on SystemC and Cim++, now a discussion is presented about the educational aspects of these two hardware/software codesign frameworks.

Conclusion

An introduction to the embedded system design and the hardware/software codesign flow was presented. The educational requirements of a hardware/software codesign framework were discussed. SystemC was briefly introduced. Cim++, a C++ library with concurrency and inheritance support, was overviewed. Some comparisons and discussions explained the appropriateness of Cim++ for education of hardware/software codesign. As discussed, the simple structure and ease-of-use nature of Cim++ helps the learning designer to exploit their priori knowledge about system design to learn the new trend of design, hardware/software codesign without convoluting the learner with the sysntax and semantics of the education framework.

References [1] H. Esmaeilzadeh, N. Shahidi, E. Ebrahimi, A. Moghimi, S. Shamshiri, C. Lucas, Z. Navabi, "Cim++: A C++ Library for Object Oriented Hardware Design," in Proc. of International Conference on Informatics, ICI 2004, Sept. 1-3, 2004, pp. 134-141. [2] SystemC. (2003). [Online]. Available: http://www.systemc.org [3] Philip J. Koopman, Jr, Preprint of paper published in: "Embedded System Design Issues," in Proceedings of the International Conference on Computer Design, ICCD 96.

[4] Ralf Niemann, "Hardware/Software Codesign,", 2004. [Online] Available: http://ls12-www.cs.uni-dortmund.de/~niemann/codesign/codesign.html [5] G. De Micheli, M. G. Sami, et al., "Hardware/Software Codesign," Kluwer Academic Publishers 1996 [6] F. Balarin, L. Lavagno, C. Passerone, A. SangiovanniVincentelli, Y. Watanabe, G. Yang, "Concurrent Execution Semantics and Sequential Simulation Algorithms for the Metropolis MetaModel," in Proceedings of Tenth International Symposium on Hardware/Software Codesign, Estes Park, Colorado, USA, May 6-8, 2002, pp. 13 – 18

Table 1. Cim++ wire classes and the supported operations on them.

[7] P. Ranjan Panda, "SystemC - A modeling platform supporting multiple design abstractions," in Proceedings of International Symposium on System Synthesis (ISSS '01), Montreal, October 2001 [8] J. Ruf, "The simulation semantics of systemC," in Proceedings of the conference on Design Automation and Test in Europe, Munich, Germany, 2001, pp. 64-70 [9] J. Gerlach, W. Rosenstiel, “SystemC: A C++ Based Modeling Platform for System Level Design,” in Proceedings of Workshop on Synthesis and System Integration of Mixed Technologies (SASIMI'2000), Kyoto, Japan, April 2000.