Control Engineering Practice 6 (1998) 397 402

Putting hardwaresoftware codesign into practice

G. Schrott *, T. Tempelmeier
Technische Universita t Mu nchen, Institut f u r Informatik, D-80290 Munich, Germany Fachhochschule Rosenheim, Fachbereich Informatik, D-83024 Rosenheim, Germany Received October 1997; accepted December 1997

Abstract This paper reports on an approach to hardware/software codesign, based on a state transition system design language MAD. MAD has been used for software design for some time, but is now being extended to hardware design by adding the hardware description language VHDL as one of its target languages. The experience of adding a new dimension (i.e., hardware) to the design space, and of dealing with some state-of-the-art hardware-development methods and tools is presented. The approach is illustrated with an implementation of a control system for an elevator. 1998 Elsevier Science Ltd. All rights reserved. Keywords: Hardwaresoftware codesign, real-time languages, real-time systems, embedded systems, distributed control, hierarchical control, process control, control applications, software engineering, hardware description languages, programmable logic devices, micro-systems

1. Introduction Hardware description languages (HDLs) are increasingly being used to describe the behavior, structure, dataow, or logic-gates structure of hardware. Hardware in this context may mean programmable logic devices (PLDs) or application-specic ICs (ASICs) in various forms, or even whole boards. From the abstract hardware descriptions, lower-level descriptions (down to the masks for programming the PLDs, or for manufacturing ASICs) are generated automatically by synthesis systems. This has been established in practice for some time, down from the register transfer level. More recently, high-level synthesis systems, starting from a purely behavioral description and automatically synthesizing register transfer-level descriptions, have started to make their way into practice. Todays hardware description languages are remarkably similar to (software) programming languages. This is especially true if one considers real-time programming languages, because (only) these contain concepts such as parallelism and time. For the leading hardware description language, VHDL, the similarity to Ada has been an explicit design principle (Menchini, 1993). A comparison of VHDL and Ada, showing the similarities and dierences between these languages, can be found in (Tempelmeier, 1994a).
* Corresponding author. E-mail: schrott@informatik.tu-muenchen.de. 0967-0661/98/$19.00 1998 Elsevier Science Ltd. All rights reserved PII S 0 9 6 7 - 0 6 6 1 ( 9 8 ) 0 0 0 1 9 - 7

The similarity of software and hardware description languages and the progress in high-level synthesis have made it possible to put design ideas into hardware or software, alikeat least theoretically. This gives rise to the new discipline of hardwaresoftware codesign, the integrated design of hardware and software. Hardware software codesign may start from a common system description in a suitable language. Numerous languages have been used for system descriptions, e.g. Ada, C, CV, ESTEREL, LUSTRE, OOFS, Petri nets, PRAM, Promela, SDL, State-charts, VHDL (Halbwachs, 1993; Tempelmeier, 1994b). From these system descriptions hardware and software descriptions (i.e. programs) can be generated in Ada, C, C # #, HardwareC, Verilog, VHDL, for example. Using the term hardwaresoftware codesign in a broader sense, it could also include hardwaresoftware re-partitioning without assuming a common system description (Tempelmeier, 1994b). Various criteria for the decision as to whether to use hardware or software are in use, e.g. performance (including hardware/software communication overhead), cost, form factor (space, weight, power consumption), safety, architectural cleanness and simplicity. This paper reports on an actual case study, where hardware or software implementations have been derived from an already implemented system description for distributed real-time systems. It is based on the concept of

398

G. Schrott, T. Tempelmeier / Control Engineering Practice 6 (1998) 397 402

multi-agent systems, and allows for a uniform programming of complex process control systems on a microprocessor eldbus network. Agents (Mu ller, 1996) are small autonomous software units that are able to perceive, decide and act, and to communicate with each other in order to coordinate their activities. The specication of the agents is done in a hardware-independent language using the notion of states and guarded commands. To date, the system has been used for PCs, programmable logic controllers (PLCs) and micro-controllers. An already implemented code generator for a nite state machine has now been extended to generate VHDL-code (see Fig. 1). 2. The Approach 2.1. System specication with MAD The proposed multi-agent distributed real-time system (MADRTS) is used to program complex distributed heterogeneous real-time applications (Schrott, 1995). It also highly supports the structured design, testability, and maintainability of the resulting system. Dedicated

computers guarantee the response times needed in timecritical applications; the complexity of control applications is mastered by splitting the application into small units. The MAD language supports the denition of small autonomous units, called agents, which are in some respects similar to tasks in conventional real-time systems. They communicate with each other by sending contracts to start activities of other agents. If more than one agent can perform the activity needed, bids are sent, and the cheapest agent will get the contract. Each agent has a set of dened states, and executes the guarded actions of this state. It interacts via generic sub-agents with physical input/output channels, timers and other specic hardware. In MADRTS, the specication and coding of the control programs are closely related. As in objectoriented programming, the agent executes the contract like a method, without showing the real implementation. A complete MAD program starts with the declaration of the target processor, and is followed by a number of agents. A syntactic denition of an agent written in MAD can be found in (Schrott, 1995). Its semantic structure is explained by means of the following MAD program of an agent controlling the door of an elevator.

agent door2 host VHDL;

Declaration of the target The target processor chosen within the network to execute the agent is dened after the keyword host. Instantiation of sub-agents At the lowest level, generic sub-agents are dened to realize the interface to the technical process (e.g., digital and analog input/output, timer, stepper motor, pid-controller). They are instantiated in the decls denition of a MAD-program with the actual i/o-address and mnemonic identiers, to enhance selfdocumentation of the program. Declaration of contracts The only interface between agents is the contract protocol. In the contracts denition, every contract which can be called by other agents is listed. A contract may transfer parameters, and causes the execution of actions or in most cases a state transition (newstate) in the agents action part. Action part The action part is subdivided into a set of states. Control tasks usually change between dierent states of operation, e.g. at lowest level on or o, at higher level closed, opening, waiting or closing. One state is active and the actions comprising it are executed. Each action is bound by a condition (guard), and only if it is true are the corresponding statements executed. At a lower level, these conditions will be signals from the controlled process; at a higher level they may be timers or conditional expressions on variables. All the conditions of the active state of one agent are tested cyclically, and all the agents xed to one microprocessor are executed one after the other to guarantee an exactly predictable time behaviour. Two distinct states are obligatory on each agent: at start-up the agent goes into the initial state; in the case of an emergency the shutdown state is entered.

decls DigOut motor(out1, on, o); DigOut direction(out2, open, close); DigIn open key(in1, on, o ); DigIn closed key(in2, on, o ); DigIn light barrier(in3, interrupted, ok); Timer delay; contracts open do newstate opening;

states closed/shutdown: true " ' motor.o; opening: true " ' +direction.open; motor.on;, open key.on " ' +motor.o; delay(10000); newstate waiting;, waiting: delay.tout " ' newstate closing; closing/initial: true " ' +direction.close; motor.on;, closed key.on " ' +elevator1.start; newstate closed;, light barrier.interrupted " ' +motor.o; newstate opening;, endagent;

G. Schrott, T. Tempelmeier / Control Engineering Practice 6 (1998) 397 402

399

Fig. 1. Hardwaresoftware codesign technique used in this paper.

Other agents may send the contract door2.open in order to induce the door agent to open the elevator door, wait for 10 seconds and close it again. If the light barrier is interrupted during closing, the door is opened again. If the door is closed, the contract elevator1.start is sent to agent elevator1. In related work, some similarities to MADRTS may be found, e.g. in all the approaches that are based on nite state machines like SDL (Frgemand and Olsen, 1994) or Codesign Finite State Machines (CSFMs) (Chiodo et al., 1994). Also, the concepts of synchronous real-time languages (Halbwachs, 1993) show some similarity to MAD RTS: their structure provides for an instantaneous reaction to external events, a fully deterministic behavior and an automatic transition to silicon. However, they create reactive kernels equivalent to nite automata which need additional layers for physical input/output, for data management and for communication between dierent kernels. 2.2. Object-based hardwaresoftware assignment A thorough survey of the existing literature on hardware/software codesign showed that many of the proposed schemes could be used, in principle. However, a decision was taken only to use target languages of primary importance in embedded systems (in terms of their practical use). This restricted the choice of languages to C and PLC programs, and to VHDL. The authors are well aware that this pragmatic approach ruled out some interesting approaches, but hardware/ software codesign research per se was not the intention of this study. Nor is it within the scope of this paper to evaluate, or even survey, hardware/software codesign methods. The reader is referred to (Buchenrieder, 1994; Micheli and Sami, 1996; Proc. of the 5th Int. orkshop on Hardware/Software Codesign, 1997), instead. The exploration of the hardware/software codesign area led to an approach, which might be described as intuition-guided, object-based, coarse-grain hardware/ software repartitioning and assignment, based on the similarities of hardware description languages to (software) programming languages. MAD objects are used as the smallest design units for hardware or software implementation. This means that

only whole agents (including their sub-agents) are candidates in the hardware/software assignment process. As an example, the door agent of Section 2.1 may be taken as a design unit to be put into hardware. Some reasoning about this hardware/software re-partitioning decision will be presented later on. Fine-grained hardware/software assignment was not considered, due to earlier negative experience with communication overhead, which one of the authors had encountered during a former work assignment in the aerospace industry. Object-based hardwaresoftware assignment partly avoids this problem, and also preserves the existing overall system structure (Tempelmeier, 1994b). 2.3. Translating MAD to VHDL The programming system MADRTS is hosted on a PC under MS-DOS. It contains the compiler for MAD, and code generators and run-time systems for dierent targets. The compiler uses the contract specication to generate the code automatically for the transmission of contracts between agents on the same or on dierent targets. Code generators are available for Intel 80;86, MC68HC11 and programmable logic controllers (Fig. 1); the communication link is implemented for RS 232 serial link and the CAN eldbus. If only digital input/output, no numeric expressions and no parameter passing to contracts are used, a further code generator is available which translates an agent program into a table of a Mealy state machine, M"(Q, , , , , q ) with  Q set of states : Q; PQ state transition input alphabet : Q; P output function output alphabet q initial state.  It is relatively easy to transcribe the nite-state-machine implementation into VHDL. The code is included in the original publication (Schrott and Tempelmier, 1997). The translation to VHDL has been done manually for the prototype. An automatic transition from MAD to VHDL is easily possible, and may be envisaged for the future (Fig. 1). Some remarks on the use of VHDL are given here from the point of view of software engineers.
E

Generally, VHDL allows the description of entities, which represent hardware units (or parts thereof). The ports of the entity form the interface to such a hardware unit. This interface closely resembles the declarations in the MAD program. So, sub-agents for digital input/output and for the timer, as well as contracts, are implemented as interface bits of the hardware entity. In software, nite state machines would perhaps be implemented as nested case-statements. An outer casestatement would cover all possible states, and the nested case- or if-statements would cover all possible inputs in a particular state. A state variable, probably of an enumeration type, would hold the current state.

400

G. Schrott, T. Tempelmeier / Control Engineering Practice 6 (1998) 397 402

VHDL representations usually follow this scheme very closely. However, this solution has to be wrapped up in two or three VHDL-processes, due to the specic timing model of VHDL, and due to the particular coding style of the synthesis tool used. Generally, not all VHDL constructs are synthesizable. So each synthesis tool places certain restrictions on the designer. When following the style guide for nite-state machines provided by the synthesis tools manufacturer (Skahill, 1996), no insoluble synthesis problems were encountered in this case study. Model Technologys V-System for VHDL simulation and Cypress Semiconductors Warp 2, rel. 3.5 and 4.1 for synthesis and post-synthesis simulation have been used. Wilson WindowWares WinEdit served as the editor, providing syntax coloring, error capture, etc., and also as integration tool, allowing calls to the other tools. All the tools are running under Windows95/NT. As hardware targets, Cypress Semiconductors Flash370 CPLDs with 128 macro-cells have been used. These could easily be programmed from a PC. The use of CPLDs further reduced the low-end development eort, because no place and route was necessary, as it would have been for eld programmable gate arrays (FPGAs). Experience with V-System was very good. Experience with Warp 2, rel. 3.5 was rather bad. The problem was not that only a subset of VHDL was syn-

thesizable (of course), but that many undocumented restrictions existed. Admittedly, the tool is available at almost no cost. But, it is the design tool for programming Cypress ICs. Probably, designers have used this tool with a severely restricted subset of VHDL, e.g. only with basic Boolean equations, thus avoiding problems with the tool. Experience with Warp 2, rel. 4.1 (Skahill, 1996) was much better. However, some annoying restrictions, as compared to full VHDL, remain. These restrictions may lead to some more or less unappealing VHDL code. As an intermediate conclusion, the generation of application-specic hardware has come within easy reach of software engineers by virtue of modern hardware-description languages. The hardware agents tted into the chosen chips without any problems. An evaluation of the eciency of silicon area usage of the VHDL compiler was not within the scope of this case study. The authors consider restrictions in the available silicon area of minor importance in the future, and did not take into consideration the use of hand-crafted hardware or software implementations. 3. The resulting architecture To test the MADRTS system, a twin elevator with four oors, built by FischerTechnik (see Fig. 2) was used. In the previous MAD software approach (Schrott, 1995)

Fig. 2. Network for twin elevator, and a view of the FischerTechnik model.

G. Schrott, T. Tempelmeier / Control Engineering Practice 6 (1998) 397 402

401

it was controlled by one MC68HC11 micro-controller on each oor, one in each cage and one at each motor platform, all connected via the CAN eldbus. The agents were distributed over these micro-controllers. After the transfer of the door agents into hardware, the micro-controllers on each oor were replaced by a CPLD Cypress 374 for each door (see Fig. 2). As the CAN protocol has recently become available in VHDL, the interface to the eldbus could also be integrated into the CPLD. Otherwise, additional CAN-SLIO nodes could be used on each oor, to translate the contracts sent via CAN into digital signals connected to the CPLD. This implementation has proved that the new approach renders it possible to construct complex distributed real-time systems with highly reactive modules. The door agents burned into PLD have zero response times to external events, and continue working if higher levels of the real-time system fail. The top-down partitioning of the whole control task into small agents, and their strict cyclic (and therefore predictable) scheduling guarantees short response times if time-critical parts are separated into dedicated micro-controllers or PLDs. On the other hand, MAD-RTS yields the exibility of modern programming paradigms on less-critical agents, and even supports an embedded contract-net protocol on the higher levels (Schrott, 1997). The communication between all agents is automatically included.

4. Hardware or software? In the approach described above, some eort was necessary to get to a really synthesizable VHDL description, but this was not the big challenge. It was also intuitively clear which parts of the system could or should be implemented in hardware or software respectively. But it was hard to nd objective criteria for hardware/software assignment, which would ideally in an algorithmic way produce the answer hardware or software for each part of the system. In the following discussion, the standard criteria from hardwaresoftware codesign publications will be investigated for their suitability to this case study.
E

Performance If there is a performance problem, it may be a good idea to place time-critical parts in hardware. This may also be done when there is an indirect performance problem, e.g. when the requirement to stay below some prescribed processor utilization (Lions, 1996), cannot be fullled without sacricing safety. Sometimes, even slow mechanical processes like elevators may encounter performance problems, e.g. too-slow a reaction to an

interrupt to the light barrier during closing of the door. This could result from a centralized synchronous control system (typically a PLC), where the polling of all the sensors brings the cycle time to the upper acceptable limit. Cost Cost is a good criterion in mass production or, in terms of development cost, in situations where only the software or the hardware paradigm has been mastered by the designers. Form factor The term form factor stands for space, weight or power restrictions, and similar properties of the system under consideration. The form factor is of importance in aerospace applications, or for portable or batterypowered devices, for instance. Flexibility The lack of exibility of hardware solutions, as compared to software solutions, may seem at rst glance to be a serious drawback. However, modern programmable logic devices provide in-system (re-)programmability, i.e. new logic can be down-loaded to such a device without taking the device out of its socket and putting it into a programmer. Safety Hardware solutions are often deemed safer than software solutions. Given the modern design methods for digital hardware, with hardware description languages much like software languages, this obviously does not hold with respect to design errors. However, there may be additional safety against transient errors, because a direct logic implementation will perhaps more easily recover from a fault than a micro-controller with a destroyed stack, for instance. A further gain in safety could be expected from improvements in architectural cleanness and simplicity. Architectural cleanness and simplicity. Object-based hardware/software re-partitioning can improve the cleanness and simplicity of the overall system architecture. For instance, in (Tempelmeier, 1994b) it is suggested that a time management unit be moved from software to hardware, because in this architecture software time management needs four different interrupts to derive one valid time value. Getting rid of these interrupts makes it easier to verify the software. Similarly, as soon as several programs are intermingled on one processor, which implies some form of time multiplexing, verication again becomes dicult. Moreover, any changes in any program require a re-verication of the time behavior of all the intermingled programs in the processor. Essentially, the ne-grained true parallelism, which is available in

A maximum processor utilization of 80% was allowed in this case.

The four interrupts were necessary due to the complex scheme of operating modes in the system.

402

G. Schrott, T. Tempelmeier / Control Engineering Practice 6 (1998) 397 402

hardware solutions, constitutes the most important advantage of hardware over software in the architectural domain. One can reach true parallelism in software by using multiple processors, but this results only in coarse-grained parallelism (with the standard von Neumann architectures). In the example considered above, there were no serious performance problems due to the decentralized control system, and the cost and form factor did not matter. The exibility is sucient, if appropriate logic devices are used. It was thus safety considerations and the desire for architectural cleanness that governed the hardware/ software assignment process. Due to the coarse-grained assignment strategy, an intuition-guided process seems appropriate. Additional computer-generated metrics on performance, cost, and form factor would be helpful in the general case.

References
Buchenrieder, K., 1994. Hardware/Software Co-Design an annotated bibliography. ITpress Verlag, Bruchsal, Chicago. Chiodo, M., Giustro, P., Jurecska, A., Hsieh, H.C., Sangiovanni-Vincentelli A., Lavagno, L., 1994. HardwareSoftware codesign of embedded systems. IEEE Micro 14(4), 2636. Frgemand, O., Olsen, A., 1994. Introduction to SDL-92, Computer Networks and ISDN Systems 26, 11431167. Halbwachs, N., 1993. Synchronous Programming of Reactive Systems, Kluwer Academic Publisher, Dordrecht. Lions, J.L., 1996. Ariane 5 Flight 501 Failure. Technical report. Report by the Inquiry Board. http://www.esrin.esa.it/htdocs/tidc/Press/ Press96/ariane5rep.html. Menchini, P.J., 1993. An Introduction to VHDL. In: NATO ASI Series, Series E: Applied Sciences (Jean P. Mermet, Ed.). Vol. 249. Kluwer Academic Publisher, Dordrecht, pp. 359384. Micheli, G. De, Sami, M. (eds.), 1996. Hardware/Software Co-Design. Nato ASI series E, Vol. 310, Kluwer Academic Publishers, Dordrecht. Mu ller, J.P., 1996. The Design of Intelligent Agents, A Layered Approach, Lecture notes in computer science, Vol. 1177, Springer, Berlin. Proceedings of the 5th Int. Workshop on Hardware/Software Codesign, 1997. IEEE Computer Society Press. Los Alamitos, CA. March 24 26, 1997, Braunschweig, Germany. Schrott, G., 1995. A Multi-agent distributed real-time system for a microprocessor eldbus network. In Proceedings of 7th Euromicro Workshop on Real-Time System, June 14 16, 1995, Odense, Denmark. IEEE Computer Society Press. Los Alamitos, California, pp. 302307. Schrott, G., 1997. Reactive real-time programming with distributed agents, In: Gorlatch, S., Lengauer, C., Griebl, M. (Eds.), Euro-Par97 Parallel Processing, August 2629, 1997, Passau, Germany. Lecture notes in computer science, Vol. 1300, Springer, Berlin, pp. 12361243. Schrott, G., Tempelmeier, T., 1997. Putting hardwaresoftware codesign into practice. In: Maranzana, M. (Ed.), Preprints of the 22nd IFAC/IFIP Workshop on Real Time Programming, Sept 1517, 1997, INSA. Lyon, France, pp. 1926. Skahill, K., 1996. VHDL for Programmable Logic, Addison-Wesley. Reading, Mass. Tempelmeier, T., 1994a. VHDL and Ada. In: Proceedings of the Fourth Symposium Ada in Aerospace, Nov 811, 1993, SAS Royal Hotel, Brussels, Eurospace. Paris, France, pp. 103111. Tempelmeier, T., 1994b. A Note on hardwaresoftware codesign, In: Halang, W.A., (Ed.), Proceedings of the 19th IFAC/IFIP Workshop on Real Time Programming, June 2224, 1994, Isle of Reichenau, Germany, Pergamon Press, Elsevier Science. Oxford, UK, pp. 121126.

5. Conclusion This case study has shown that about the same eort is necessary to implement a hardware solution or a software solution for a logical unit in the elevator control system. MAD-RTS allows for hardware-independent programming; the whole control task is decomposed, top-down, into agents, distributed on to specic targets. The compiler can generate code for these agents, running on conventional processors, but can also create a hardware agent which has a response time close to zero, via a nite state machine and VHDL. More dicult is the question of whether to assign a unit to hardware or to software. Many standard guidelines for this problem do not apply to the example. Safety considerations and architectural cleanliness and simplicity give clues that hardware could be used, but these are rather fuzzy criteria. The general experience with this case studyand in the context of this case studyis that the question of whether to implement in hardware or in software is still undecided.