10 3


Published on

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

10 3

  1. 1. Design Automation for Embedded Systems 3, 187–198 (1998) c 1998 Kluwer Academic Publishers. Manufactured in The Netherlands. Simulating Hardware, Software and Electromechanical Parts Using Communicating Simulators NIKOS C. PETRELLIS petrelli@ee.upatras.gr ALEXIS N. BIRBAS, MICHAEL K. BIRBAS, EVANGELINOS P. MARIATOS AND GEORGE D. PAPADOPOULOS University of Patras, Electrical Engineering and Computer Technology Department, Applied Electronics Laboratory, Rio Campus 26500, Patras Greece Received November 25, 1996; Revised October 2, 1997 Abstract. The design of embedded processor circuits for the control of electromechanical systems, in a unified environment, offers many advantages including reduced system design and debug cycles and shorter time to market. Simulation plays a very important role in such a design methodology. In this paper, we will present, a brief description of the design methodology of our research team which focuses on the co-simulation of various heterogeneous parts. More specifically, we will present a couple of flexible interfaces that have been implemented for bridging VHDL with Physical Systems Simulators as well as VHDL simulators with the application programs that control the digital circuit simulated in VHDL. The basic concepts and features used for these implementations are characterised by increased portability, while other significant advantages of the proposed schemes are their speed, their flexibility in supporting various communication protocols and the simplified and fully automated simulation procedure which is transparent to the user. Keywords: co-simulation, heterogeneous systems, VHDL, electromechanical system controllers 1. Introduction A very important area of industrial applications is the control of various electromechanical systems ranging from consumer goods to spacecrafts. Systems of this kind usually consist of several heterogeneous parts: digital processors with peripheral circuitry, the firmware that runs on these processors as well as electromechanical parts controlled by the digital ones. The usual procedure that has been followed until recently, includes the separate treatment of the heterogeneous parts of a system, probably by different groups of engineers. The development and verification of each one of these parts is carried out separately, thus actually ignoring the details of the interaction between them. The firmware on the other hand, is usually written at the later design stages (although the algorithm, that it is based on, may be designed earlier) and depends on the specific application and microprocessor used. As a result, the designers cannot have an overall view of the whole system behaviour, before it is actually implemented, since there are no widely used unified environments which would support the joint simulation of heterogeneous systems. When the separate designs have been completed, the various heterogeneous system parts are implemented and
  2. 2. 188 PETRELLIS ET AL. interconnected (on a prototype for example). If these parts do not interact properly, they have to be redesigned. This approach imposes significant problems like increased cost, incorrect operation and reduced performance of the implemented system, long design/debug loops due to the inaccurate partial simulations of the heterogeneous system components. The necessity for a more efficient design approach is evident. It should give the designer the ability to verify the whole system’s behaviour before the implementation of any of its parts. In this way, design errors could be detected at early stages and any modification on the designed system can be performed with the minimum cost, resulting to essential minimisation of all the aforementioned problems. Towards this direction we have implemented a unified environment which permits the simultaneous design and validation of systems consisting of electromechanical parts, digital circuits and software that controls the digital part. For the design of the software and the hardware components of the system, Object Oriented concepts have been adopted and the first evaluation of the system is carried out on a high-level description which consists of C++ classes. Then this high-level description is refined in more detailed C code segments which form the software part of the system and in VHDL describing the digital part. On the other hand, the mechanical parts of the system can be directly modelled (after the analysis phase) and described in a Physical System Simulator (PSS). At this point, a unified simulation can be carried out including all the parts that the final system consists of, as it will be described in the rest of this document. The basic idea is to use the C language links of the various simulators in order to establish efficient communication channels between them and make feasible the exchange of com- mands and parameter values between the simulated parts of the system. Especially on the side of the VHDL simulator, the C language interface was exploited for the development of generic interface components which are declared as VHDL entities but are described behaviourally in C. Several routines are called within these C descriptions which undertake the task of sending and receiving commands and values from either the application program or the electromechanical system simulator. Concerning the synchronisation of the various simulators, these tools are connected in a “chained” Master/Slave scheme as will be explained later. The specific communica- tion protocol used is not the most efficient in terms of concurrency (like a Time Warp algorithm [1] or an algorithm based on rendezvous for example). A simulator in a Time Warp algorithm may predict the responses of others simulators which it expects results from, in order to proceed its own simulation without delaying waiting these results. If an expected parameter value arrives and is not the predicted one, the simulation has to roll back. In a rendezvous algorithm both simulators are allowed to simulate in parallel, up to the predetermined time points where both know that they have to stop and exchange data. Such synchronisation schemes are efficient only if they are tuned properly, but are not as robust and reliable as the one we are using. Moreover, the VHDL simulator is much slower than the other modules. This difference in the speed of each type of simulator, tends to make useless any concurrency that could have been achieved by other synchronisation protocols. Part of this work has been inspired and developed in the framework of the OMI/Standards II (ESPRIT 8210) project, which aims to the establishment of standard
  3. 3. SIMULATING HARDWARE, SOFTWARE AND ELECTROMECHANICAL PARTS 189 interfaces between the various OMI simulator tools. It should also be mentioned that this is an extension to the work presented in [8]. Moreover, several papers exist in the literature [2, 3] dealing with the problem of Hardware/Software co-simulation but no general and tool transparent solutions have been proposed. Similar problems are the mixed mode and the parallel or distributed simulation. Several representative papers address enough these two areas [4, 9, 10], but no work has been carried out for enabling the simulation of hetero- geneous system parts like the ones that are examined in this paper. The implementation to be presented is based on the VHDL simulator Synopsys and the electromechanical systems simulator PROUESSE, which is a Thomson CSF product. It should be stressed here, that this interface is not tied to the specific simulators but it is characterised by increased portability and within this context, generic points of the interface will be highlighted, indicating how similar interfaces can be constructed for other simulator tools. This paper is organised as follows: Section 2 describes briefly, the proposed methodology and Section 3, the general features of the implemented interfaces. In Section 4, the interface components are presented in detail. An illustrative example, is presented in Section 5 and finally, some performance issues are discussed in Section 6. 2. Our Methodology for the Design of Systems The general methodology is shown in figure 1. The observation of the real world is followed by a formal analysis of the system requirements and a high-level definition of the various functions of the system. Then the modelling of the mechanical system is carried out using the appropriate des- cription method, allowed by the PSS that is used. Thedesignofthedigitalpartalongwiththesoftwareorfirmwarethatwillrunonit, ismade based on Object Oriented techniques. Although, such techniques are used extensively in the computer society, basically for the description of Software modules, we have extended them for the description of the hardware [7]. The Object Oriented techniques offer reusability of the components, as the components themselves support inheritance and extendibility and can easily describe most of the digital circuits. Figure 1. The design methodology.
  4. 4. 190 PETRELLIS ET AL. At this high level of description, it is natural that the allocation of system components in hardware and software has not yet been determined. The simulation results along with some hardware/software partitioning techniques, help the designer to determine the way that these functions can finally be implemented according to the available hardware resources, the cost and speed limits. Then the software and hardware parts are refined in C and compiled in VHDL respect- ively, in an automated manner. The resulting C code segments and the VHDL parts can be simulated together and along with the PSS as we describe in this paper. In this way, more accurate results can be obtained and the designer can have an overview of how the whole system operates. Readily available software modules can be used by slightly modifying the points where dedicated hardware or the electromechanical system has to be accessed for enabling com- munication with the VHDL simulator and the PSS. The same applies for readily available VHDL models which have to be connected to the interface components. The restrictions on the description of the several heterogeneous parts to be simulated, are posed by the various synchronisation problems that may arise if complex schemes are employed (multithread or multiprocess software description, multiple simulator instances or multiple processor instances on a single simulator). For the software, there are no serious restrictions. It has to be noted that it is the behaviour of the software that is tested outside the VHDL simulator. However, the software parts that interact or control special hardware can be described in a lower level description (e.g., assembly) that interacts more closely (even at the clock cycle level) with the VHDL simulator. If multithread or multiprocess is employed in the software module, the threads or processes that do not use directly, the interface with the VHDL simulator, simply have to consider that the process or thread that does use this interface may occasionally get blocked waiting reply by the VHDL simulator. There are no restrictions also on the description of a physical system. The more detailed the description is, the more accurate the results will be, while the simulation will last longer. The VHDL part also allows multiple processor modules to be simulated but the synchronisation problems that have to be considered are obviously more important. Other processor modules can be full processor descriptions, while others can simply interface to external C programs. The interface does not impose restrictions to the number of channels that are going to be used to connect VHDL processor modules with external C programs. After a successful simulation, the VHDL parts can be synthesised to hardware and the physical system can be set up. The final system can be tested then, with much fewer possibilities for error situations. 3. An Overview of the Features of the Proposed Simulation Environment The general characteristics of the developed interfaces, used for the simulation, are the following: (a) The VHDL simulator, the PSS and the application program run on UNIX. (b) They are assumed to be distinct processes.
  5. 5. SIMULATING HARDWARE, SOFTWARE AND ELECTROMECHANICAL PARTS 191 (c) They may run on different machines and the interprocess communication is performed using stream sockets which were selected due to their increased speed and reliability. RPCs had also been considered as an alternative solution but they were not used in the present version because they are not yet fully standard and they are considerably slower than sockets. (d) It is strongly recommended to have a single socket communication channel between the two simulators as well as between the VHDL simulator and the application program in order to avoid various synchronisation problems that may arise if multiple connections were opened. (e) The C language interface facility of the various simulators is used and all the interface code is also written in C with the exception of some adaptive components which are described in VHDL. These may be used on the side of Synopsys for the interconnection of the interface components with the rest of the digital circuit. (f) Synopsys and PSS are co-operating in a “chained” Master/Slave configuration. This means that the C program describing the software, is the primary Master module. Whenever the dedicated hardware should be accessed, the VHDL simulator is waken up and the C process is blocked until the VHDL simulator performs the required action. Moreover, if the value of a physical system parameter should be sampled, the parameter identity is sent to the PSS by the VHDL simulator, along with a timestamp. PSS is also waken up and proceeds its simulation up to the point where its simulation time will be equal to the timestamp that has been received. Then sends back the results to the VHDL simulator and gets blocked. VHDL simulator wakes up and completes the rest of its actions. Any required results are returned back to the C process. 4. Use of the Interface Components The sensors and the actuators are the natural communication links between the digital and the electromechanical parts and are modelled directly by the proposed VHDL-PSS interface component. The user should treat this component as an ordinary one, with more general signal types which need to be converted to “real electronic world types” like standard logic or bit vectors. Even if the sensors include advanced intelligence, this could also be modelled by using additional logic, outside the interface. So, what the designer has to do, is simply adapt the type of the interface component signals (possibly by using VHDL type conversions, e.g., integer to bit vector or vice versa). Then, it could be decoded at any address of the memory or the I/O space enabling the processor to access the values of sensors/actuators as memory locations. The VHDL interface component on the side of the PSS is named “inter” and is presented in figure 2. To a great extent, the efficiency of the implemented interface stems mainly from the inherent structure of this component. Whenever the value of a sensor is to be examined, the signal SEN ACT should be set to the specific sensor identity and the TIME signal to the simulation time of Synopsys, while STRB should change from ‘0’ to ‘1’. The values of SEN ACT and TIME are sent to PROUESSE which proceeds its simulation in order to reach Synopsys simulation time and when this time point is reached the sensor value is returned back to Synopsys via the signal SEN VAL.
  6. 6. 192 PETRELLIS ET AL. Figure 2. The “inter” interface component. When an actuator is to be driven, the actuator identity is assigned to SEN ACT, the value of the actuator to ACT VAL and the Synopsys simulation time to TIME. These values are sent to PROUESSE when STRB changes from ‘0’ to ‘1’. PROUESSE proceeds its simulation again, in order to reach the Synopsys simulation time, and then the received by PROUESSE value is assigned to the actuator and an error indicator is returned if anything goes wrong. Another important issue is the choice of the I/O protocol for the exchange of values between the digital controller and the sensors/actuators of the electromechanical system. The most popular I/O protocols are the sampling and the interrupts mechanisms. Using sampling the sensors are examined in regular time intervals by the controller while by using interrupts, the controller is left free to deal also with tasks other than the examination of the values of the sensors. When the level of these sensors exceeds predefined limits, the controller is interrupted and an interrupt service routine is invoked to decide on the action that should take place. The main drawback of the sampling protocol is that the digital circuit may waste CPU time by examining values of sensors that have not changed, while the main disadvantage of the interrupt mechanism, besides its increased complexity, is that the digital part cannot have a full image of the sensor values. Both protocols can be readily applied using the proposed interface. When “Sampling” is employed as the I/O protocol, the interface component should be directly controlled by the digital circuitry. For example, each sensor or actuator identity can be mapped to a memory address. Then when the processor needs to sample a sensor value it can read it from the corresponding address. If, on the other hand, it should drive an actuator, it may write its value to the corresponding address. The simulation ends either when an error occurs or when the maximum desired simulation duration (declared initially to PROUESSE) is exceeded or when SEN ACT is driven with a special end of simulation code, which is different from all the other sensor/actuator identities. If the I/O protocol is based on interrupts, a separate VHDL process should undertake the control of the interface component, examining its sensors at shorter time intervals. Whenever one of these values exceeds a predefined threshold, the processor interrupt line is activated by this VHDL process and the program being executed is interrupted and the appropriate service routine is activated. Using this protocol, the communication overhead between the two simulators may be increased, due to the fact that the values of the sensors should be sampled very often by this controlling VHDL process.
  7. 7. SIMULATING HARDWARE, SOFTWARE AND ELECTROMECHANICAL PARTS 193 Concerning the VHDL-Application program interface there are two components that should be used in place of the microprocessor of the real digital system. One of them, the Generic Processor Description (GPD), is a standard component which appears externally as a microprocessor with general type port signals while the other one, the Front End Specific Processor Description (FESPA) is used as an intermediate component between the GPD and the rest of the digital circuit. Its structure depends on the specific commercial processor that the GPD-FESPA components replace. The purpose of the FESPA component is to trans- form the general signals of GPD into the specific ones of the commercial processor of the real system. In case of a microcontroller the aforementioned two components replace the core, while the rest of the circuitry of the microcontroller can be modelled around the FESPA component. Analogue circuitry inside a microcontroller cannot be modelled within the VHDL environment since this is not allowed by most VHDL simulators. A PSS though, is usually able to support the description of analogue circuits, so the designer can move the analogue parts to this simulator. The GPD component and the Application Program communicate by calling routines of the packages GPD-IPC and AP-IPC, respectively. These routines are “standard”, i.e., independent of the simulator and the application. The Application Program can ask the GPD to read or write a memory location or it can respond to an interrupt caused by the digital circuit. The application or simulator dependant parts of the interface components are (a) the sensor/actuator declarations in the description of the “inter” component, and (b) the whole FESPA component. For (a), high-level pre-processing can be applied to the C behaviour description of the “inter” component. This would enable the designer to determine the parameters of the electromechanical system that should be observed or controlled. Such a preprocessor has been implemented for the interface between PROUESSE and Synopsys. It asks the high-level definitions of the sensors/actuators (parameter names), as well as their initial values and encapsulates this information in the C description of the interface component “inter”. For (b), a library of FESPA components for the various commercial microprocessors, could be provided. The FESPA description of each microprocessor could be developed, for example, by the microprocessor vendor or even by the designer itself. Such a small library has been developed by the authors, for a couple of simple academic processors but support would be needed by the commercial microprocessor vendors, in order to have popular microprocessor FESPA components readily available for simulation along with our interface. A typical FESPA component could contain a converter for the signals ADDR and the RD VAL, WR VAL ones, which are of integer type to the appropriate Address and Data bus types of the target processor. The width of the buses is taken into account, and the various rise or fall edges are delayed according to the timing diagrams of the processor. The signals WR and RD can also produce the corresponding signals of the specific processor, by simply emulating their timing (pulse widths for example). Finally, an interrupt handling logic would be able to maintain an appropriate look-up table for recognising the interrupt identity and driving the signals INTR, INTR ID.
  8. 8. 194 PETRELLIS ET AL. Figure 3. The GPD and the FESPA components. 5. Example In this section an illustrative example of the proposed interface using the VHDL simulator Synopsys and the Electromechanical system one PROUESSE (a Thomson CSF product), is presented. The example regards an electrical vehicle with a three-phase motor. The main battery current is regulated by a microcontroller so that the speed will not exceed some predefined limits (figure 4). The digital circuit used for the control of the main battery current is similar to the one presented in figure 5. Figure 4. The control of the speed of an electrical vehicle. Figure 5. The digital controller with the AMP processor connected to the interface component.
  9. 9. SIMULATING HARDWARE, SOFTWARE AND ELECTROMECHANICAL PARTS 195 Figure 6. Replacement of the AMP processor with GPD and FESPA components for hardware/software co-simulation. The microprocessor AMP (Advanced Mark Processor) is a processor model, described in VHDL and has been derived from the academic processor MARK2 by expanding its busses (the 8-bit data bus is expanded to 16-bits while the 4-bits address bus is expanded to 12-bits) and enriching its instruction set with eight more basic instructions. The AMP processor is connected to a RAM module and to the interface component “inter” through some adaptive circuitry. In figure 6, the processor AMP is replaced during the simulation with the GPD and FESPA-AMP components and the application program is executed as a separate C process. In this way, the simulation speed is increased while the timing features of the digital circuit still remain observable. This is due to the fact that the instructions can be grouped into those that access I/O or dedicated hardware (these are usually the ones that the designer needs to test) and the rest of them can be described in a high-level language like C, and can be rapidly executed outside the digital system simulator. 6. Performance and Experimental Results The increased flexibility is a significant advantage of the presented interfaces and is mainly due to the inherent structure of the interface components that have been used on the side of the VHDL simulator. These components, as shown in Section 4, can be connected to a digital circuit in many ways, allowing the choice of any communication protocol. The increased speed of the implemented interface stems mainly from the use of the stream sockets which is the fastest interprocess communication. The choice of RPCs (Remote Procedure Calls) was also considered due to their increased abstraction, but such a solution was rejected for the present version of the interface, since they have not become fully standard yet and they proved to reach only half of the speed of the sockets. The interface functions that control the interprocess communication and manipulate the socket streams are common to both interfaces (VHDL-PSS and VHDL-Application program). Consequently, the overhead of these functions characterises the overhead of both interfaces. This overhead was measured experimentally by using UNIX processes that made successive calls to the interface routines and counting the total number of the clock cycles (ccs) that were spent by the CPUs of the workstations where these processes were executed. In order to perform these measurements under worst case conditions, the
  10. 10. 196 PETRELLIS ET AL. Figure 7. The simulation results observed through the PROUESSE waveform window. interprocess communication took place across the local network (through different LANs connected to the same backbone) of our Department at time periods of the day, that this network was extremely loaded. Some illustrative results are presented in Table 1. The same application and the same simulation duration was used for all the types of protocols. The number of messages ex- changed in each case can be considered as typical for each protocol, while the overheads are expressed in clock cycles. The smallest number of messages are exchanged when an interrupt protocol is employed and the hardware interrupts are emulated by software ones (Interrupts 1). In the case where the interrupts are emulated, by using a supporting VHDL processwhichperformssamplinginshorttimeperiodsandinterruptsthemainVHDLcircuit through VHDL signals, when the sampled parameter value exceeds the predefined thresh- old, the number of messages exchanged is large (Interrupts 2). In this case, although large Table 1. Communication overhead measurements. Sampling Interrupts 1 Interrupts 2 Messages 1000 200 50000 Synopsys overhead/msg 420 600 360 Prouesse overhead/msg 950 1400 1050
  11. 11. SIMULATING HARDWARE, SOFTWARE AND ELECTROMECHANICAL PARTS 197 overhead is posed to the system due to often communication, the main VHDL processes do not get blocked, while messages are exchanged. Table 1 also shows that the overhead (per message exchange), to each simulator differs according to how often the communication is. The overhead measured experimentally for the VHDL-PSS interface, never exceeded 8%, including the duration of the PSS simulation. 7. Conclusions The work presented in this paper shows that the joint simulation of the heterogeneous parts of a system consisting of electromechanical, digital parts and application programs becomes feasible enabling the designers of such systems to verify them quickly with the minimum cost. The presented interface of VHDL simulators and electromechanical systems simulators is characterised by efficiency and portability and covers a broad range of co- simulation cases. Based on a flexible pre-processing scheme for the preparation of the necessary application specific files, it automates the whole co-simulation procedure hiding all the implementation details from the user. Future work will focus on the investigation of the possible extensions that may applied to the presented interface in order to support other cases of heterogeneous systems. Several other topologies besides the one that was studied here, will also be examined. Acknowledgments TheauthorsareindebtedtoMr. J.J.BardynofThomsonCSF,DivisionOutilsInformatiques, Colombes FRANCE, for his valuable collaboration. This work has been partially supported by OMI Standards II project (EP 8210), funded by European Commission, in the framework of ESPRIT III. References 1. H. Bauer, C. Sprorrer, and T. Krodel, “On distributed logic simulation using time warp,” VLSI 1991 Proceed- ings, pp. 4a1.1–4a1.11, 1991. 2. D. Becker, R. Singh, and S. Tell, “An engineering environment for hardware-software co-simulation,” 29th Design Automation Conference. ACM/IEEE, pp. 129–134, 1992. 3. D. Gajski and F. Vahid, “Specification and design of embedded hardware-software systems,” IEEE Design and Test of Computers, pp. 53–66, Spring 1995. 4. R. Fujimoto, “Parallel discrete event simulation,” Communication of the ACM, 33(10): 31–53, October 1990. 5. K. Joergensen and P. Odryna, “Simulator backplanes allow concurrent use of multiple simulators,” EDN, pp. 165–172, May 1995. 6. L. Maliniak, “Backplanes mesh simulators into one environment,” Electronic Design, pp. 59–69, August 1994. 7. E. Mariatos, M. Birbas, A. Birbas, and N. Petrellis, “Object oriented prototyping at the system level,” 7th International Workshop on Rapid System Prototyping, pp. 90–95, June 1996. 8. N. Petrellis, A. Birbas, M. Birbas, E. Mariatos, and D. Papadopoulos, “Simulating hardware, software and electromechanical parts using communicating simulators,” 7th IEEE International Workshop on Rapid System Prototyping, IEEE Computer Society Press, Thessaloniki-Greece, pp. 78–82, June 1996. 9. R. Righter and J. Warland, “Distributed simulation of discrete event systems,” Proceedings of the IEEE, 77(1): 99–113, January 1989.
  12. 12. 198 PETRELLIS ET AL. 10. R. Saleh, S. Jou, D. Overhauser, X. Xu, and Wang, “Benchmark circuits for mixed mode simulators,” Custom Integrated Circuit Conference IEEE, pp. 21.1.1–21.1.8, 1994. Nikos C. Petrellis is a Ph.D. candidate at the Electrical Engineering and Computer Technology, Department of University of Patras, Greece. He holds a diploma in Computer Engineering and Informatics from University of Patras (1994). He is involved in various OMI projects and his research interests include Hardware/Software codesign and partitioning, simulation of heterogeneous systems and design of embedded systems. Alexis N. Birbas is currently an Assistant Professor at the Department of Electrical Engineering and Computer Technology of University of Patras, Greece. He holds a diploma in Electrical Engineering from University of Patras and the MSEE and Ph.D. degrees from the University of Minnesota, Mineapolis, USA. He is involved in various OMI projects within ESPRIT and his research interests include VLSI technologies, device electronics and electronic design modelling. Michael K. Birbas received his diploma and Ph.D. degrees from Electrical Engineering Department, University of Patras in 1985 and 1991, respectively. From 1992–1995 he worked as a Ph.D. researcher in the Applied Electronics Lab. of University of Patras. Since 1993 he is with Synergy S.A. where he is currently working as R&D Projects Administrator. His current interests lie in formal methods and Hardware/Software codesign for embedded systems, VLSI implementation of DSP algorithms, parallel processing etc. Evangelinos P. Mariatos received his B.Sc. degree in Physics from University of Patras in 1992 and his Ph.D. from Applied Electronics Lab., University of Patras, in 1997. He is currently working as a System Designer at Synergy S.A.. He has also worked for a number of Greek companies and participated in more than seven ESPRIT projects. His research interests include Hardware/Software codesign, object oriented techniques and intelligent design of complex systems. George D. Papadopoulos is a full professor at the Electrical Engineering and Computer Technology Department of University of Patras, Greece. He is a director of Applied Electronics Laboratory since 1975. He received his BEE from City University of New York in 1963 and his MSEE (1964) and Ph.D. (1970) from MIT. His research interests include microprocessor based design, industrial networks, DSP and industrial automation. He has been at several positions in national and international institutes and he has authored more than 80 papers.