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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.