An Object Oriented Framework for the Implementation of SDL Designs Umberto Mascia’, Michele Mosciatti’, Giuseppe Razzano3, Gaetano Scarano3, Roberto Cusani3 PXL, piccola SOC. coop. a r.l., Roma, Italy NCS, Sistemi di Navigazione e Comunicazione S d . , Ardea (RM) Italy Information and Communication Department (INFOCOM Dpt.) University of Roma ”La Sapienza”, Roma, Italy e-mail:
[email protected];
[email protected]; {razzano, scarano, cusani} @infocom.uniromal.it
-
Abstract In thispaper we describe rhe develupment of the sofware module for an embedded system, which redizes Fast Frequency Hopping for a radio device. The module is designed using the SDL modelling language, then implemented in CU language, targeting U custom board equipped with VxWorks operating system. The muin focus of the paper is on a new object oriented libmy, called “SDL Framework” (SDLF), that has been deveIoped with the main objective of allowing fast mapping of SDL elements into native C++ objects. The paper describes the reasons which have lead to the development of SDL-Ffiamework andpresents its main features and performances.
1
Keywords -frequency hopping, SDL, C++, VxWorks, object oriented fmmework, ACE.
1 Introduction A typical embedded system is a board of small size, which, inserted into a bigger device (e.g. a car, a plane, a washing machine.. .), has a specific task, that does not change after it has been developed, Embedded systems interact with external hardware, which means that they directty acquire transducers, drive actuators and control processes variables and parameters. These tasks usually determine hard real-time constraints, that drive the choice of the architecture, inpuffoutput capability and computational power of the embedded system. In this paper we present the development of an embedded system used to implement a frequency hopping transmission technique in a radio device. In particular we focus on the development of the software module of such system. The design was carried out following the SDL modelling approach [l], while C++ language was selected for the implementation phase. ParticuIar attention was paid to the transition from SDL specification to C++ implementation. Our main effort to ease coding work, was in developing a novel library of classes and a predefined environment for the execution of a specific application: a software layer called SDL Framework (SDL-F). The rest of the paper is organized as follows: Section II presents a short description of the system specification and the hardware-software co-design approach; Section III describes the development of the system specifications in the SDL environment. Section IV presents the SDL-F framework and Section V analyzes the requirements of the software module. Fi-
0-7803-8689-2/04/$20.00 Q2004 IEEE
nally some conclusions are drawn in Section VI.
2 System description: Hardware and Software co-design approach The functionalities of an embedded system are usually implemented partly in hardware and partly in software. For this reason, design of this kind of systems concerns three different methodologies: hardware design, software design and design of the interfaces between the hardware and software blocks. Performance constraints, particularly the hard real-time deadlines, determine the basic requirements of the hardware engine that carries out the lowest level interface with the external hardware world. Control functionalities are usually demanded to the software module. In this respect, hardware is usually implemented in field programmable logic (PGA), while software typically runs on a standard Central Processing Unit (CPU). Additionally, when heavy computational load is required, a Digital Signal Processing (DSP) unit can be employed, to optimize the implementation of mathematical software, avoiding the CPU overload. The basic block diagram of the developed system is reported in in Figure 1. Consequently, it is crucial to define the roles of the HW and SW blocks, to optimize the performance of the system, in terms of temporal constraints, physical size and power consumption. Nevertheless, at the same time, it must be considered how different blocks interact. There is no point in moving a code fragment to the hardware block to make its execution faster, if it communicates heavily with a code fragment that is in software: the gain obtained in terms of execution speed, would be lost in communication across the hardware and software boundary [ 2 ] . Several iterations have lead to the HW/SW interface specification in our system. Availability of hardware components and system requirement, which determine the upper bound for the response time of the system, has conditioned the development and optimization of the HWlSW interface. We have chosen to implement main-control non time- critical parts in software, executed on Motorola PPCX60 processor. Performance critical parts, mainly bit-oriented real-time functions, are implemented in configurable hardware ( P G A XC2VlOOO Virtex II family by Xilinx, with a density of 1 million of system gates); and computational intensive software,
534
t
Figure 2: Software architecture Figure 1: General architecture of the embedded system - representation of the static structure of the system (the hier-
like audio codec, on DSP (TMS320C5402 by Texas Instruments in its 100 Mips version).
archy of blocks, sub-blocks and processes); - representation of the dynamic behavior of the processes, that
3 SDL Project SDL (Specification and Description Language) is a general purpose description language for communicating systems, standardized as ITU Recommendation 2.100. Its origins are in the telecommunication fields; but nowadays SDL is widely applied to a diverse number of other areas ranging over aircraft, train control, medical and packaging systems. The language is intended for the specification of complex, event-driven, real-time and interactive applications involving many concurrent activities that communicate using discrete signals. The vision of the system suggested by SDL assigns welldefined and concurrentactivities to separate processes, that can be regarded as the smallest active units of the decomposition.
Each process behaves like a state machine (Extended Finite State Machine, EFSM). Processes are contained in blocks; blocks can be contained in other blocks, according to a description of the system as a hierarchical structure. Communication between processes (and between processes and the external environment) is obtained by means of signals, to be regarded as arbitrary packets of information that are instantaneously routed from the sender process to the receiver one, Thanks to this modelling strategy, SDL is well suited to the representation of independent layers of a communication protocol, that interact each other offering well-defined access points and services, and so reveals its telecommunications roots. An SDL project is typically carried on with a graphic representation, that is more comfortable €or the designer. A textual representation is also defined, that is completely equivalent to the graphic one; but it is mainly used for purposes of automatic processing. Several CASE tools (Computer Aided Software Engineering) are available, that help the designer in the development, offering functionalities as:
is the graphic description of the EFSM as a diagram flow of execution; - verification of formal SDL correctness: - execution of tests and simulations. Some tools offer also a C code generation feature; this aspect will be discussed in the following section. By means of the SDL toot, we specified both the hardware and the software blocks. However, while for the software module the SDL project recovered a great importance throughout all the development phase, since it was directly converted into C++ language implementation, for the hardware module the SDL project helped in the initial phase for the definition of the architecture, which was implemented and simulated using VHDL language in structura1 form. The development used the Integrated Development Environment (ISE) by Xilinx and Modelsim by Mentor for simulations.
4 Implementation of the SDL framework (SDL-F) Several refinements brought the SDL project to a stable state, so that we were able to run some simulations through the CASE tool of choice. This refinement process ended with the final hardware software co-design, i.e. the aIlocation of the system functionalities to the 'Hw and SW modules. During the specification of the SDL model, the performances are not a main concern. SDL description assumes infinite system resources, i.e. each process contains an unlimited size buffer for incoming signals and it uses abstract and infinite size data types [31. The behavior of the system is based on asynchronously communicating processes, and has no native support for hardware interrupts, that are the main source of signals from the environment. Furthermore, the scheduler included in the simulation engine is non-preemptive, which means that a complete SDL state transition is executed without any interruption. The transition from the SDL design to the executable code
535
t
has to face those problems. As previously stated, SDL based CASE tools offer a code generation feature. The policy of the tool is to be the only way for the developer to access to the project: every change to the SDL model must be expressed through the tool, in order to ensure that the code is exactly corresponding to the SDL design. The target language is usually C, but the generated code is not suited to be studied, directly modified or extended. We considered this aspect as a limitation, because we wanted to be able to integrate the code with other preexisting modules, and because the hard real time constraints may require an optimization process by means of a hand-made tuning. The solution was to design a C++ library with two main goals: to make the translation from SDL to C++ code as easy as possible, and to obtain a portable code. The result of this activity is more than a simple library, being not only a collection of reusable classes, but also a generic application that lets the user defining the specific behavior, and so it’s called “SDL Framework” (SDL-F). SDL-F offers: - the components needed to implement the static structure of the system (Blocks, Processes, Services, Procedures, Channels and Signal Routes); - the components needed to implement the dynamic behavior of the system (State Machine, Gates, Signals). The sratic structure is defined by means of a hierarchy of blocks, a tree that ends with processes as leaves. This is the case for a Composite Patrern [43, that is reflected in the relationship between the classes SDL-Composite, SDLBlock, SDLProcess. Thanks to the Composite structure, it’s easy to propagate actions like starting, stopping, querying status, to the whole system. The State Machine is captured in a template class; each state can define the reactions to a set of deliverable signals, with the selection of the specific signal class delegated to a double dispatch mechanism. This is an example of Visirur fattem [4] and a common way to preserve type checking. A critical aspect that affects the performance of SDL systems is the routing of signals, these being the only mean of communication between processes. For the sake of generality, SDL-F offers a standard “send“ operation, that follows all the way from the sender process to the receiver one, through gates, signal routes and channels. In some cases -like ours - this generality comes at the expense of poor performances, and it is useless because each sender knows exactly the receiver process when sending a signal. For this reason, SDL-P offers also an optimized “send” operation, achieved in two steps. During the initialization phase, SDL-F performs a “path-find algorithm” creating a static routing map, which associates each triple (signal type, sender, gate) to the one and only receiver entity. At runtime, each time a process sends a signal, the routing map is used to retrieve the receiving process, so that it can be directly delivered.
The choice of the desired strategy is under the responsibility of the SDL-Gate class, and it is masked to the other classes by means of a common interface: an application of the Strategy Pattem [43. The signals exchanged can be classified as external, when sent by the environment to the system, or internal, when exchanged among the processes internal to the system. Usually the software module of an embedded system receives signal from the hardware (and by means of this, from the external world} in the form of software interrupts. Thus, SDL-F offers a way to transform an interrupt into an instance of a specific signal class and to send it to the receiver process, Whenever an hcoming interrupt is detected by the software module, the interrupt is quickly served via an interrupt service routine, which executes the basic operations characterized by hard real time constraints and ends calling a procedure to generate the specific SDL signal, which is sent to the involved blocks and processes. An example of this operational modality is given by the frequency writing which has to be done by the software module in 30 ps on response of an interrupt issued 2000 times per second by the FPGA. The described optimized send operation is able to satisfy such requirement. The portability of SDL-F source code was another key point for the success of the whole work. Because of the availability of only one final target and one development environment (namely, Wind Ever Tornado II), we decided to develop also a simulation chain, to be executed on ordinary PCs with the Windows operating system. In this way we could advantage of: - increased availability of resources, being a PC an affordable equipment; - increased capability of debugging and logging the software, being a Windows environment much more user friendly than a final embedded target. A strategy of “separation of concerns” arose from the use of the simulation chain. The simulation validates the implementation of the algorithms, and verifies the “formal correctness”; so that when the software module is running on the target, one can restrict the efforts on the differences from the simulator, and stay tuned on the verification of the operational correctness. In this respect, to assure the full portability of the developed framework we have used the ACE library. The Adaptive Communication Environment (ACE) [5] is a freely available, opensource object-oriented (00)framework that implements many core patterns for concurrent communication software. ACE provides a set of reusable C++ wrapper facades and framework components that perform common communication software tasks across a range of OS platforms. The communication software tasks provided by ACE include event demultiplexing and event handler dispatching, signal handling, service initialization, inter-process communication, shared memory management, message routing, dynamic (re)configuration of distributed services, concurrent execution and synchroniza-
536
1 Figure 3: SDL-F hierarchical class structure.
tion. The structure of the classes used to implement the SDL project is reported in Figure 3. The ACE classes give the infrastructure to ensure portability, defining basic blocks such as message queues, tasks, timers, and a reference implementation of useful programming patterns (e.g. the Reactor or the Active Object [6]). SDL-F defines the “SDL Layer”, composed of classes with self-defining names, such as SDLElock, SDLProcess, SDLSignal and so on. These classes use ACE classes through derivation or aggregation, and are intended for further reuse through specialization. The “User Layer” encloses the classes for the specific application, the most important being processes, derived from SDLProcess, and signals, derived from SDLSignal. The user has to follow some predefined steps in order to define his classes, then he can describe the details of the system, mainly translating the SDL code of the state machines transitions into C++ code. Moreover, SDL-F provides some useful tools, such as an efficient memory management that addresses the problem of allocation with different strategies for long-lived entities (blocks, processes, gates, channels) and short-lived ones (signals).
5 Software Module The software module runs on a Motorola MPC860 microprocessor, which is based on a standard 32-bit PowerPC incorporate Memory Management Units (MMUs), instruction and data caches and several input-output peripherals. The main functions allocated to the SW block are: - Processing and management of user data. The radio supports data (synchronous and asynchronous) and voice (plain text and ciphered). In particular voice is sent using a Pulse Code Modulation (PCM) ccdec (64kbit/s) and it is compressed via Continuous Slope Variable Data (CSVD) algorithm - Control functionalities. The SW module handles the settings
and the commands sent by the user via a front panel control module, The software module monitors the correct functioning of the radio, reports errors and abnormal situations, supervisions the operations of other blocks (FPGA, DSP) - Hopping frequency computation. The values of the frequencies are calculated via software and transmitted to the RF block of the radio via a dual port shared memory. To correctly achieve the communications, the system requires strong synchronization over all the nodes of the network. Since the frequency is changed 2000 times per second, the developed module has to grant the computation of the frequency within a small upper limit of time. Furthermore the system must be able to react to all the other procedures which can be requested by other nodes of the network and by the user of the terminal in an asynchronous way. As already mentioned, the software functionalities have been implemented using C++ language over VxWorks operating system [7]. VxWorks is a distributed real-time operating system, which includesintegrated networking facilities and a software development environment for different hosts. VxWorks has multitasking kernel with pre-emptive scheduling and fast interrupt response, with symbolic and source level debugging capabilities and performance monitoring. The main interactions of the developed SW module and the so called external world can be summarized as follows: - data bit stream (plain or ciphered voice samples, or binary data) exchanged with the user; - control protocol information exchanged with the radio that embeds the Frequency Hopping module; - HW/SW control information exchanged with the FPGA part of the Frequency Hopping module. To separate the core functionalities of the SW module from the interfaces with the external world, we ended up with the definition of four blocks that represent the higher level of our block hierarchy. These blocks are sketched in Figure 2 and are: MPC86OCure: which is the core of the system and handles all the functionality that are executed by the software module; DPRlntelface: which is responsible of data exchange with a Dual Port RAM memory, used to allow the communication with the front panel and to transfer the values of the hop sequence; FPGAInterface: which is responsible of the communication with the FPGA chip; Dutalnte@ce: which handles the user data exchange. With an iterative process, each block was further detailed in terms of its sub-blocks,until reaching the level of the processes with their description as EFSMs, according to a canonical SDL style. As already mentioned, the C++ implementation phase, was carried on by means of the developed SDL-F framework, which allowed mapping automatically the SDL entities into C++ objects. The same SDL-F layer has been the foundation of a Test
537
Figure 4: Developed board.
Framework, developed in order to simplify writing and running software tests. Each test was included in a collection that grew during the development. At any time the whole collection could be used in an automatic test run, so giving a continuous report about the correctness of the code, and an impact evaluation of the implications produced by the code modification. The test strategy takes advantage of the hierarchical structure of the SDL entities (processes and blocks), that is walked in a bottom-up way. First, tests were written for each process done, processes being the leaves of the hierarchy tree. In a second step, when all the processes belonging to a brock passed their test, the test for that block was added. We followed this chain of tests until we arrived to test the most external block, i.e. the “system block”. Each test is composed of a test environment and a test system block. The entity under test (process or block) is inserted into the test system block, and stimulated by means of the test environment, which is in charge of sending and receiving signals to and from the observed entity, in order to check the correctness of the entity behavior.
cial CASE tools available off the shelf. Its main advantages are: - gratuity: SDL-F has been developed as a research project jointly from the INFOCOM Dpt. of University of Rome “La Sapienza”, and two SMEs: PXL and NCS. It will be made soon available under an open source license, that is still to be defined in its details; - optimization and maintenance: SDL-F allows the user to have a good visibility of the developed code, thus allowing the programmer to change and optimize the code and to integrate it with preexisting modules. SDL-F is currently under development. The main functionalities to be added in the near future are: - to implement a parser based on the SDL syntax in order to generate the repetitive and mechanical part of the code. The code generator has to produce C++ code based on SDL-F, while the programmer has the responsibility to code each transition of the state machines. - to allow the definition of a state machine as derivation of another one, only redefining the specialized transitions. This will increase the opportunity for reuse of code, and will extend the mapping between the SDL language and an SDL-F based implementation. - to optimize the message queue used to implement the SDL Input Port. Since SDL is based on signal exchange, a fast signal handling will give the chance to use SDL-F without further tuning even in systems with hard real time requirements.
Acknowledgements The authors wish to thank all the people involved in the FFH project for the effort spent to achieve the final target.
REFERENCES www.sd1-forum.org/ Wolf, W.H.;“Hardware-software co-design of embedded systems” Proceedings of the IEEE, Volume:82, Issue:7, July 1994,Page(s): 967 -989 Hannikainen, M.; Knuutila, J.; Hamalainen,T.; Saarinen, J.; ”Using SDL for implementing a wireless medium access control protocol” Multimedia Software Engineering, 2000. Proceedings. International Symposium on , 11-13 Dec. 2000 Pagels): 229 -236 Gamma E., Helm R., Johnson; ”Design Pattems: Elements of Reusable Object-Oriented Software”AddisonWesley 1994 http://www.cs.wustl.edu/Nschmidt/ACE-overview.html Schmidt D. C., Huston S . ; ”C Network Programming: Mastering Complexity with ACE and Patterns”, AddisonWesley Longman,2002 http:/lwww.gocct.codsheetslvxworks.htm
6 ConcIusions The paper has described the development of the software module for an embedded system, which realizes Fast Frequency Hopping for a radio device. The module is designed using the SDL modelling language and implemented in C++ language. The software module is hosted on a custom board equipped, running VxWorks operating system over a Motorola CPU.The implementation ha5 been achieved by means of a new object library, called “SDL Framework” (SDL-F), that was developed with the main objective of allowing fast mapping of SDL eIements into native C++ objects. In this way we reached the objective of preserving the readability of the code while simplifying the integration with existing code and the extension to new features. The SDL-F represents a valid alternative to some commer-
538
