Automatic Generation of Interprocess Communication in the PARAGON System

Size: px

Start display at page:

Download "Automatic Generation of Interprocess Communication in the PARAGON System"

Tracy Bruce
6 years ago
Views:

1 Automatic Generation of Interprocess Communication in the PARAGON System Xun Xiong 1, Peter Gutberlet 1, Wolfgang Rosenstiel 2 1 Forschungszentrum Informatik (FZI), Haid-und-Neu-Straße 10-14, D Karlsruhe, Germany 2 FZI and University of Tübingen, Sand 13, D Tübingen, Germany Abstract PARAGON provides a platform for hardware-software partitioning for systems specified in the C++ language. In this paper, we are going to introduce PARAGON emphasizing how the synchronization and communication among the used processors are built during and after the partitioning. The partitioned specification consists of multiprocessors communicating with abstract methods. It is a C++ specification with the processors encapsulated in processor classes. Built-in communication is modelled by predefined communication class objects. It can be compiled directly and thus makes it easy to execute a simulation. Finally, it is well-suited to further processing by standard processors and hardware synthesis systems. 1. Introduction PARAGON is intended to serve as a hardware-software codesign platform for rapid prototyping. Like any other codesign methodology [5][6], it is directed at combining the advantages of both hardware and software solutions to deal with increasingly complex design tasks, which have high performance demands on one hand and strict design constraints on the other hand. The key part of PARAGON is automatic partitioning which is crucial for the final success of the design. The partitioning algorithm in PARAGON is partially based on our UNITY approach [1][2], but considerable enhancement is made. Also, its partitioning granularity is at a much higher level. The UNITY partitioning system explores a wide range of design space resulting from the analysis of different design implementation alternatives.. This work has been partially supported by the Bundesministerium für Bildung, Wissenschaft, Forschung und Technologie (BMFT) under project 01M2897A (SYDIS). However, it has several restrictions which make it inappropriate for specifying complex systems. Communication is another key word for the HW-SW codesign[3][4] but it is not sufficiently addressed. There is few work reporting on automatic generation of needed synchronization and communication based upon exhaustive analysis of specification language. Even less work can be found about a direct simulation of automatically generated communication. In this paper, we introduce a simple and efficient approach to establish synchronization and communication in our partitioning environment. 2. An Introduction to the PARAGON System PARAGON stands for C/C++ Partitioning with automatically generated interprocess communication. Starting with a system specification in the C++ language, it first uses its C++-frontend to transform the given C++ specification into a system intermediate representation (SIR) [11][12]. The pre-defined communication library, with the communication units modelled as communication classes, is also read into SIR by the C++-frontend. SIR format provides a streamlined CDFG data structure and is used as the exchange format around which all other tools are centered. While maintaining all of the design information contained in the input language, a CDFG flow graph further makes the information about data and control dependencies in the specification available. This information is vital for the subsequent partitioning process. After partitioning, needed synchronization and communication have to be built. They must be inserted in the correct positions and at the right time. The generated SIR represents the partitioned system with communicating processors. It can be processed by the C++-backend to generate a partitioned system which is wholly described in C++ code. It can then be directly compiled and executed for the simulation s purpose. The hardware partitions of the partitioned SIR can be processed by the VHDL-backend which is available within the CASTLE system [11].

2 The generated VHDL output can then be handed over to further synthesis systems (figure 1) like for example our high-level system CADDY [8] and the communication synthesis system SYMPATHY [7] which is also developed in our institute. C++ System Specification Partitioning Parser (C++-Frontend) Generation of Interprocess Communica- Generator (C++-Backend) Compilation Simulation C++ Code Communication Synthesis Integration Communication Library SIR Generator (VHDL Backend) VHDL Code Figure 1: Overview of PARAGON 2.1. Generation of Flow Graph for C++ P A R A G O N High-Level Synthesis SIR stands for system intermediate representation [12]. It allows system specifications to be represented at different levels of abstraction (such as combined control and data flow graphs, hierarchical netlists as well as state transition graphs) to cover a wide spectrum of specification languages and applications. In addition to flow graph representation of specification languages, SIR further provides a standardized way of manipulating and processing these flow graphs. All the tools within PARAGON interact via SIR. This permits uncomplicated manipulation, transformation or synthesis of the representation without having to directly deal with the individual special specification language. The C++-frontend together with the C++-backend build the interface between the C++ language and the SIR graph. The C++-frontend parses C++ code with a parser based on a C++ bison grammar and transforms it into a SIR graph. Inversely, the C++-backend generates the text of the specification language from a given SIR representation. In addition to the complete ANSI-C language set, the current C++-frontend supports most important C++ syntax such as: accessibility with regards to data and methods within the class hierarchy, function and operator overloading, multi-inheritance, and representation of constructor and destructor. The resulting SIR contains all information specified in the input language, which is much easier to handle and extract than in the original specification Introduction to the Partitioning Algorithm Partitioning plays an essential role in the PARAGON system. Since our focal point in this paper is the communication, we only give a brief introduction to our partitioning algorithm. Setup of the Closeness Matrix Evaluation of the Partitioning Classification SIR Design Constraints Clustering Figure 2: Partitioning with clustering algorithm The partitioning process starts with the classification of the system (which is actually the SIR graph generated by the C++-frontend from the input specification) by identifying the parts which could be characterized as CPU-intensive, I/O-intensive, control-intensive, or mixed type respectively. The information used for the characterization can be directly extracted from the SIR representation. The next step is to determine the similarities among the partitioning units. The term similarity refers to two partitioning units that have common or closely related properties and therefore may possibly be kept close to each other during the course of partitioning. Accordingly, a distance between them is defined to measure the extent of similarity. Parts with similar characterization, common global data and variables, similar degree of parallelism, same class derivation or at the same level of the syntax tree hierarchy are, for example, said to be closer to each other. Such parts are more likely to be assigned to the same processor to reduce synchronization and communication costs. Other features such as the number of common communication channels, number of calls (for methods and procedures as partitioning units) are also considered as. Depending on the granularity we chose, these could be procedures, methods, classes, compound statements, statements or assignments.

3 important criteria for measuring the extent of similarity. This step results in a closeness matrix with which a corresponding cluster tree can be built. A clustering algorithm partially based on the one in [2] can be applied to track down the best cutline of the cluster tree in order to obtain the initial partitioning. The resulting partitioning must then be evaluated to see if the design constraints are met. For this purpose, tools for evaluation and performance estimation are used. For partitions which are assigned to standard processors, the performance estimation tool from [12] is used. The area and delay costs for the hardware partitions are obtained by our high-level synthesis system[8]. Finally, the communication and synchronization costs are estimated by the communication synthesis tool reported in [7]. 3.Establishment of the Communication The partitioning produces a SIR-graph, which contains the specification of the processors with built-in synchronization and communication. In PARAGON, the processors are encapsulated as C++ classes. In the processor class, local variables are represented by private data and global data is modelled through explicit communication Modelling of the Communication In the final system implementation, the communication is realized as special hardware components such as global memory, interrupt-channels and connection channels. To give the following communication synthesis more flexibility for optimization, the modelling should be kept at an high abstract level. Next, we demonstrate how we use C++ classes to model the different communication types. class channel channel(int block_size); send(void *data); //sends data of block_size rcv(void *data); //receives data, and waits if data is unready }; class global_var global_var(int block_size); write(void *data); // writes data to the memory read(void *data); // reads current memory value }; class global_ram global_ram(int block_size); write(int addr, void *data); read(int addr, void *data); Figure 3: The communication library We have defined three types of communication objects: channel, global_var and global_ram. Each type has a specific application with specific methods (figure 3). The class channel is responsible for data transfer between different processors and has explicit synchronization. Its methods send and rcv are always called in pairs: if the method rcv is called for a channel, it blocks until data is received via this channel. The data sent to the channel actually comes from the corresponding send call from some other processor. The classes global_var and global_ram differ only in the addressing scheme. The method write writes data to the memory and read always reads the actual value of the memory. read and write can occur in any order and there is no wait involved with them. For this reason, the method calls of global_var and global_ram may be accompanied by additional channel method calls for the synchronization s purpose. The class channel is used when directions for the communication can be determined directly from the specification, for example when parameters are passed to a function call whereby the calling function and the called function are from different partitions. If a direct producer-consumer relationship cannot be detected while dealing with global variables, for example when different processors read and write a global variable in irregular order, global_var and global_ram can be used Modelling of the Global System Structure The whole system can be seen as a group of communicating processors with abstract methods of the communication classes, as illustrated in the example below. RAM CH1 Target Architecture P1 P2 P3 P3 GV1 CH2 Figure 4: The global system structure The system consists of 3 processors: P1, P2 and P3, which communicate with each other via a global RAM RAM1, a global variable GV1 and two data channels CH1 and CH2. To describe this structure in C++, each processor is encapsulated in a class which mainly contains the specification parts assigned to this processor. Local Variables are represented as private data of the processor. Procedures assigned to the processor become its methods. The description of the whole system consists of the global declaration of instances of all necessary communication classes as well as the individual processor classes.

4 3.3. Simulation The recommended system modelling provides the possibility of describing the partitioned specification and its necessary communication connections in such a way, that its semantics can be easily understood by subsequent synthesis systems. As pointed before, the partitioned C++ specification can be compiled and executed for the purpose of simulation. To simulate the communication, we make use of the pipe mechanism of the UNIX interprocess communication in order to implement the three communication classes. To simulate each processor, a pair of pipes are created and a UNIX process is split through the UNIX system call fork. The forked process executes one partition, while the original process continues until enough processes for all partitions are forked. Finally, the original process plays the role as the communication server. This results in the following process organization: Communication Process P1 P2 P3 Figure 5: The process communication in the simulation The UNIX processes which execute partitions do not have to communicate with each other directly: they only communicate with the communication server (figure 5). This largely reduces the amount of needed connections. The communication process shares the global data and the global state of each channel. The processes which execute partitions may read, write or manipulate the global data with the given methods of the communication classes Automatic Generation of the Communication As was previously stated, the partitioning is done in SIR instead of the original input language. Before the partitioning takes place, some transformations are first undertaken to simplify the SIR graph in order to make it more suited for the subsequent partitioning as well as the communication construction. An example of such a transformation is the extraction of complex expressions which are passed as parameters to function calls. This transformation splits a function call into several simpler expressions. A processor class may contain information about the processor regarding price, characteristics and performances of the microprocessor and the micro-controller, power consumption, area, pin number etc. It is formed and completed progressively as the partitioning process advances. When a procedure is assigned to a processor class, it becomes a method of this class. After the procedures are assigned to the given processor classes, communication and synchronization are established. For each processor class, we construct an additional method main that is responsible for the selection of the correct function call. It mainly contains an endless while-loop. The first statement within the loop is a call of the channel method rcv which waits for the data that contains the name of the function to be called. A switch-statement then selects the correct function call. The parameter channels wait for the values of the parameter data. As soon as the data has arrived, the function is called at once and the result of the function call is sent back. After the main method is built, we go through all methods (with each method matching a partition) of each existing processor class. Each time we come across a function call whereby the function is assigned to another processor, the data is sent to that processor whose main method selects the correct function. The data sent out contains the function name and the parameter values. After the data is sent out, the process is stopped by calling the channel method rcv until the expected data is received. The code in figure 7 illustrates this procedure. The technique presented above is only suitable for passing non-pointer parameters. For common access to global data or the exchange of pointer data, the communication class global_var is used instead Optimization of the Parallelism The synchronization thus established is still so strict that a real parallelism between the processors is not yet possible. Real parallelism can, however, be achieved by reorganization of the synchronization. The first improvement of parallelism can be reached by shifting the communication calls without changing the order of the calls, so that communication can take place as early as possible. int a = a1*a2; int b = b1*b2; P2_mode.send(P2:call_ ggt_z2.send(b); int x; ggt_r.rcv(x); return a*b/x; P2_mode.send(P2:call_ int a = a1*a2; int b = b1*b2; ggt_z1.send(b); int z = a*b; inx x; ggt_r.rcv(x); return z/x; Figure 6: Shift the order of the communication calls

5 int gcd(int i1, int i2) int a = i1; int b = i2; while (b!= 0) if (a > b) a -= b; main() int n, m; scanf( %d%d, &n,&m); printf( the result is %d\n, gcd(n, m)); } Proc 2 Proc 1 /* Created by sir2c++ on Fri Jan : 48 : */ #include Part_.h int proc2::gcd(int i1, int i2) int a = i1; int b = i2; while (b!= 0) } int proc2::main() while (1) enum _curcallcode_on_proc2_ callcode; CH_for_callcode_on_proc2.rcv(((int *) (&callcode))); switch (callcode) case _call_gcd_: int i2; int i1; CH_for_i1_of_gcd_on_proc2.rcv((&i1)); CH_for_i2_of_gcd_on_proc2.rcv((&i2)); CH_for_gcd_on_proc2.send(gcd(i1, i2)); int proc1::main() int n, m; int _gcd_; scanf( %d%d, &n, &m); CH_for_callcode_on_proc2.send(((int) proc2::_call_gcd_)); CH_for_i1_of_gcd_on_proc2.send(n); CH_for_i2_of_gcd_on_proc2.send(m); CH_for_gcd_on_proc2.rcv((&_gcd_)); printf( the result is %d\n, _gcd_); } Figure 7: The original and partitioned codes for the gcd example This type of optimization can be carried out locally in the processor. However, special care has to be taken to prevent deadlocks and synchronization errors. The second improvement to parallelism changes the order of the communication calls. This is effective when several function calls are in a row and the functions are all assigned to different processors. The idea is to change the order of the communication calls send, placing them early on in the execution order, so that function calls on different processors can occur simultaneously. P2_mode.send(P2::call_ ggt_z2.send(b); int x; ggt_r.rcv(x); glob_x.write(x); P3_mode.send(P3::call_ kgv); kgv_z1.send(a); kgv_z2.send(b); int y; kgv_r.rcv(y); return x*y; Figure 8: Change the order of the communication calls The optimization of parallelism in the second stage requires global analysis of the interprocess communication and it can be modelled as scheduling problem. 4. Results We have tried several benchmarks to experiment with our approach. In the table 1, we presented the mill_rab example with different partitioning alternatives. The mill_rab algorithm is used to detect whether a given natural number is a prime number. The program code consists of five procedures. Table 1 lists 6 different partitioning possibilities and some of their relevant data. # of comm class obj. P2_mode.send(P2::call_ P3_mode.send(P3::call_ kgv); kgv_z1.send(a); ggt_z2.send(b); kgv_z2.send(b); int x; ggt_r.rcv(x); glob_x.write(x); int y; kgv_r.rcv(y); return x*y; CPU part. & comm CPU C++ FE PA loc SIR size # orig K 1.87 s 3.70 s code part K 5 20 pt K s 3.78 s pt K s 4.39 s pt K s 3.17 s pt K s 4.22 s pt K s 3.43 s Table 1: The mill_rab example CPU C++ BE It can be observed that the number of necessary communication instances increases with the number of the par-. PA = partitioning alternatives; # in column 4 = # of the resulting partitions. FE = (C++-)frondend; BE = (C++-)backend.

6 titioning in most cases (exception: partition 2.1 and partition 3 ). It can further be observed that well selected partitioning can largely reduce the number of needed channels (partition 4.2 and partition 4.1 both have 2 partitions, the former needs however only 9 communication channels in comparison to 14 of the latter). 5. Summary In this paper, we gave an overview of our HW/SW codesign system PARAGON. Furthermore, we briefly introduced our partitioning algorithm based on a flow graph representation generated from the C++ input language. We also presented a methodology to capture and construct the interprocess communication for the partitioned system. Two possibilities to improve the parallelism with and without modification of the order of the communication calls were discussed with examples. The direct partitioning result was a kind of multiprocessing C++ specification whose processors were encapsulated as classes and whose synchronization and communication were modelled as method calls of pre-defined communication class objects. Together with the library for the communication class definitions, the partitioned C++ specification was able to be directly compiled and executed for the purpose of simulation. The partitioned C++ code was also well-suited for further processing by hardware and communication synthesis systems. [7] J. Müller, R. Kumar, Optimizing the Communication Overheads during the Allocation of Global Memories and Busses, Logic and Architecture Synthesis: state of the art and novel approaches, Chapman & Hall, June 1995 [8] P. Gutberlet, W. Rosenstiel, Specification of Interface Components for Synchronous Data Paths, Proc. International Symposium on High-Level Synthesis, 1994 [9] P. Gutberlet, X. Xiong, Hardware/Software Partitioning with C++, Proc. the 2nd SYDIS-Workshop in the GMD, Bonn, 1994 [10] B. Stroustrup, The C++ Programming Language, the 2 nd edition, Eddison-Wesley 1991 [11] Markus Theissinger, Paul Stravers, Holger Veit, Castle: An Interactive Environment for HW-SW Co-Design, Third International Workshop on Hardware/Software Codesign, Grenoble, September 1994, pp [12] 6. References [1] E. Barros, Hardware/Software Partitioning using UNITY, Ph.D thesis 1993, University Tübingen [2] E. Barros, W. Rosenstiel, X. Xiong, A Method for Partitioning UNITY Language in Hardware and Software, Proc. EURODAC, Grenoble, September, 1994, pp [3] K. O Brien, T. B. Ismail, A. A. Jerraya, A Flexible Communication Modelling Paradigm ForSystem-Level Synthesis, Handouts of CODES 93, Cambridge, Massachusetts, October 1993 [4] R. Ernst, Th. Benner, Communication, Constraints and User Directive in COSYMA, Poster session of CODES 94, Grenoble, Sept [5] R. Ernst, J. Henkel, T. Brenner, Hardware-Software Cosynthesis for Microcontrollers, IEEE Design & Test of Computers, Vol. 10, No. 4, December 1993, pp [6] R. Gupta, G. De Micheli, Hardware-Software Cosythesis for Digital Systems, IEEE Design & Test of Computers, Vol. 10, No. 4, December 1993, pp

The Design of Mixed Hardware/Software Systems

The Design of Mixed Hardware/Software Systems Jay K. Adams Synopsys, Inc. 700 East Middlefield Road Mountain View, CA 94043 jka@synopsys.com Donald E. Thomas Deptartment of Electrical and Computer Engineering