Design Exploration in HwSw Co-design of Real-Time Objectoriented Embedded Systems the Sched

Design Exploration in Hw/Sw Co-design of Real-Time Object-oriented Embedded Systems: the Scheduler Object SILVA Jr, Elias T. 1,4; Wehrmeister, Marco A.1; PEREIRA, Carlos E. 2; WAGNER, Flavio R.1 ;BECKER, Leandro B. 31 Computer Science InstituteFederal University of Rio Grande do Sul, Brazil{etsilvajr, mawehrmeister, flavio}@inf.ufrgs.br2 Electrical Engineering DepartmentFederal University of Rio Grande do Sul, Brazilcpereira@eletro.ufrgs.br3 Automation and Control Systems DepartmentFederal University of Santa Catarina, Brazillbecker@das.ufsc.br4 Telecommunication and Computer DepartmentFederal Center of Technological Education of Ceará, Brazilelias@cefetce.brAbstract. This paper proposes a design flow for multithread object-oriented real-timeapplications, running on top of an embedded platform based on a customizable Javaprocessor, which is prototyped using affordable FPGAs. The proposed approach enforcesdesign space exploration activities, on which aspects such as temporal behavior,footprint, power and energy consumption are taken into account. In this paper a casestudy of a task scheduler implementation as software or as hardware module is presented.While both implementations are compatible from an interface point of view they lead todifferent timing and footprint requirements. An evaluation in terms of memoryoccupation and numbers of FPGA logic cells is presented.1. IntroductionReal-Time systems depend not only on the logical results of computation, but also on the timeliness of those results [5] [6]. Most real-time systems are special purpose and complex, require a high degree of fault tolerance, and are typically embedded in a larger system. They also include substantial knowledge about the application and its environment, since they are characterized by a high coupling between a computer-based system (a controlling system) and a technical process (or thecontrolled system). Examples include industrial automation, flexible manufacturing systems, process control and flight control, among others.Particularly, embedded real-time systems are becoming larger and more complex, demanding development tools that work at higher abstraction levels. In order to reduce time-to-market, developers look for reusable components (either hardware or software components). Moreover, the designer must have the opportunity to trade off between software (for flexibility) and hardware (for performance and low power) implementations of components and sub-systems.The project SEEP (Platform-Based Design of Embedded Systems) that is under development at the Federal University of Rio Grande do Sul proposes a new methodology for embedded real-time systems design. The project offers a complete toolset for embedded systems modeling, analysis, validation, and synthesis. This allows fast design space exploration in the hardware and software co-design of embedded real-time systems. The approach is based on the reuse of hardware and software components and on the configuration of architectural platforms implemented using programmable devices such as FPGAs.This paper illustrates the design methodology underlying the SEEP project using as example a “scheduler” object, as defined by the RTSJ [4]. Design space exploration regarding the scheduler implementation in software or hardware while keeping the same high-level object model is described along the paper.The remaining of the paper is organized as follows. Section 2 gives a brief overview of the SEEP methodology. Section 3 introduces the hardware and software platform used to develop object-oriented real-time embedded applications, which includes the femtoJava processor, a customizable Java processor. Section 4 discusses the scheduler implementation in hardware and in software. Section 5 presents a case study that allows a comparison between the two implementations in terms of performance and cost, and in Section 6 conclusions are drawn.2. SEEP Methodology OverviewThe SEEP project proposes a complete and integrated methodology for the design and test of embedded real-time systems, taking into account non-functional requirements such as temporal behavior and power consumption. The SEEP methodology makes extensive use of object-oriented concepts, from system specification to implementation, aiming to obtain reusable system components for which different implementations meeting different design trade-offs are available. The methodology supports designers in a rapid, but cost-effective, design space exploration.The SEEP methodology is depicted in Figure 1. It starts with the definition and further validation of a high-level object-oriented model, which follows the recently proposed UML-RT profile [14]. Problem domain objects are identified and class hierarchies mapping concepts and semantics of the application domain are described. Then, a system exploration step follows, allowing the designer todecide on major functional trade-offs, for instance by selecting the right algorithms for implementing the desired functionality. Then, architectural design space exploration is performed, where the designer will decide on major architectural blocks for the system implementation, assigning functions to architectural components. This exploration is based on already available platforms and on a library of IP (“intellectual property”) components. The result is an abstract macro-architecture, which implements a hardware-software partitioning, where some functions are mapped to software tasks while other ones are mapped to dedicated hardware blocks. This high-level architectural model still abstracts all low-level implementation details. Two platforms are being currently considered in the SEEP project. The first one is based on a family of Java processors (see Section 3.1), implemented on conventional FPGAs, while the second one is a commercial platform, containing a large FPGA with two embedded PowerPC processors.Figure 1 – The SEEP design methodologyHardware and software synthesis follows in the development cycle. As part of the software synthesis process, an operating system may be required to implement, for instance, services for inter-process communication and for task scheduling. This operating system must be also dedicated to the application and optimized for the given design requirements. A VHDL description of a cycle-and-pin accurate micro-architecture is generated for the hardware part. Inputs to this task are VHDL descriptions of the selected architectural blocks, already available in the component library. These descriptions may be parameterized, and their configuration depends on design decisions taken at the design exploration steps.3. A Configurable RT-Java Processor3.1 FemtoJAVA ProcessorFemtoJava [10] is a stack-based microcontroller that executes Java bytecodes, whose major characteristics are a reduced and configurable instruction set, Harvard architecture, and small size. FemtoJava implements an execution engine for Java in hardware, through a stack machine compatible with the Java Virtual Machine (JVM) specification. A compiler that follows the JVM specification is being used and allows the synthesis of an ASIP (application-specific integrated processor) version of FemtoJava. Only the execution core and some tools to extract the software at design time are really necessary.An immediate advantage of native execution of Java bytecodes is software compatibility. This feature guarantees the availability of cross-platform development of software. In some conventional Java platforms (for example, PCs or workstations) one can just implement and run a Java program. Running the program is equivalent to simulating the behavior of the application in the target microcontroller, with all resources and convenience of a desktop environment in the development phase.The first FemtoJava implementation used a subset of the JVM bytecodes, with only 68 instructions. The instructions supported were basic integer arithmetic and bitwise operations, conditional and unconditional jumps, load/store instructions, stack operations, and two extra bytecodes for arbitrary load/store. In this core, all instructions are executed in 3, 4, 7, or 14 cycles, because the microcontroller is cacheless and several instructions are memory bound. In order to support multithread applications, the instruction set of FemtoJava was expanded [8] [9]. Enhancement in performance are obtained with pipelined and VLIW versions of the processor [13].3.2 RTSJ-based API (software support)The Java programming language has gained in popularity over the last years as a suitable programming language for embedded and real-time systems development, especially due to the definition of the Real-Time Specification for Java (RTSJ) [4]. RTSJ defines an Application Programming Interface (API) for the Java language that allows the creation, verification, analysis, execution, and management of real-time threads, whose correction also depends on the fulfillment of timing requirements. Unfortunately, the popularization and use of this API is still incipient given the limited availability of Java Virtual Machines (JVM) that conform to such specification. On the other hand, the situation is different in the embedded systems domain, since there are several proposals that optimize the JVM to embedded targets. Such optimizations aim to reduce the required footprint for a JVM as well as to improve the application’s performance. The Sashimi environment [10] is an example of JVM optimization for embedded systems. It provides a powerful and easy-to-use development environment for embedded systems that has been successfully applied to different casestudies. The Sashimi environment was recently extended to incorporate an API that supports the object-oriented specification of concurrent tasks and allows the specification of timing constraints [9]. Those facilities raise the design abstraction level and optimize the development of real-time embedded systems. Figure 2 shows the UML model of the API used in this work, which is a subset of the RTSJ specification. This API offers an alternative to simplify the design of a real-time object-oriented application running on a Java native code processor. Using that API together with the Sashimi environment, programmers can design concurrent real-time applications and synthesize them into the FemtoJava processor.Figure 2 – RTSJ-based APIThe API uses the concept of schedulable objects, which are instances of classes that implement the Schedulable interface, like the RealtimeThread. It also uses a set of classes to store parameters that represent a particular resource demand from one or more schedulable objects. For example, the ReleaseParameters class (superclass from AperiodicParameters and PeriodicParameters) includes several useful parameters for the specification of real-time requirements. Moreover, it supports the expression of the following elements: time values (absolute and relative time), timers, periodic and aperiodic tasks, and scheduling policies. The term ‘task’ derives from the scheduling literature, representing a schedulable element within the system context. It is also a synonym for schedulable object.A scheduling structure for the FemtoJava processor has been designed, in order to provide a framework with different scheduling policies. The adopted approach allows designers to program theiralgorithms using higher levels of abstraction. Therefore, they can make use of the Java programming language together with the provided API. The intent was to minimize architecture-dependent characteristics, making the scheduling framework as general as possible.In order to offer an alternative to meet application time constraints, a class called HardwareScheduler is implemented to interact with the hardware version of the scheduler. No modifications in the application code are required to switch among the available scheduler implementations, either in software or hardware. From the developer’s viewpoint, the rules to use the API are the same.4. Alternative Implementations for the Scheduler Object4.1 Scheduler Object in SoftwareThe scheduling structure consists of an additional process that is in charge of allocating the CPU for those application-processes that are ready to execute, exactly like in an RTOS. Application developers should choose the most suitable scheduling algorithm at design time. Therefore, a customized scheduler is synthesized with the whole application into the embedded target.Currently, the framework supports both static and dynamic scheduling algorithms. More specifically, it provides efficient dispatching and context switching mechanisms that are able to work with any fixed-priority algorithm, like Rate Monotonic (RM) [3]. Additionally it includes support for dynamic scheduling with the EDF (Earliest Deadline First) algorithm.4.2 Scheduler Object in HardwareThe hardware scheduler contains tables that store task descriptors sent by the FemtoJAVA processor, as well as operators to manipulate those tables. It is encapsulated by a class called HardwareScheduler, which interacts with hardware and performs the context switch and dispatch. Context switch and dispatch imply a minimum cost relative to the scheduling activities, especially when using complex scheduling algorithms.By moving the scheduling algorithm from software to hardware, this operating system function no longer competes with application tasks for a processor. The scheduling function has now its dedicated hardware unit, which can: 1) run more complex scheduling algorithms; and 2) provide a really non-intrusive task scheduling, thus enhancing predictability [2]. Additionally, the scheduler coprocessor can be used to obtain accurate execution time measurements for the real-time tasks being executed, an important parameter to perform schedulability analysis.4.2.1 ArchitectureThe proposed architecture for the system is shown in Figure 3. The main components of the hardware scheduler, which works as a co-processor, are:- The General Register block,- The Scheduler block,- The SyncEvent block, and- The AsyncEvent block.The General Register block contains all tasks descriptors independently of their state (running, blocked, ready, idle). At any given moment, the main processor may include or remove tasks in this block, which should confirm or refuse new tasks.The SyncEvent block is similar to the AsyncEvent block and monitors the application tasks related to the system real time clock (periodic or one-shot tasks). The execution of this kind of task depends on the time tick and is supposed to occur periodically or at specific times.The Scheduler block receives tasks that are ready to execute, sent by blocks SyncEvent or AsyncEvent, and put them into its table in the right order according to the established schedule policy. The Scheduler sends tasks to the processor in two situations:1) The task currently running finishes its execution. The processor performs a read operation andreceives the next task from the co-processor.2) The task recently inserted in the first position of the Scheduler block table has higher prioritythan the task currently executing in the processor. The co-processor interrupts the processor, preempting the running task.4.2.2 Hardware scheduler commandsTo configure the hardware scheduler, FemtoJava can use five different commands:- Include a task – The co-processor receives a set of parameter that describes the task to manage. Figure 4 shows the details of those parameters.- Remove a task – The co-processor removes a previously programmed task.- Start a task – The co-processor moves a previously programmed task to Active state and can schedule that task when its event arrives.- Task finished; ask for the next task – The co-processor supplies the ID (identification code) of the first task in the ready task queue.- Preempt task; ask for the next task – It happens when the running task is preempted. The co-processor supplies the ID of the first task in the ready task queue and re-schedules the running task.All these operations are transparent to the application designer who can only use the API, choosing the hardware or the software implementation of the scheduler.Figure 4 – Sequence of task programming parameters for a priority-based scheduling algorithm4.2.3 Hardware scheduler interfaceFemtoJava communicates with the co-processor and with I/O devices through a 32-bit bus. Since they are both synthesized on the same chip, the communication overhead is minimized. The main effort of the communication system is during the start-up process, which usually does not have time constraints. For each task, a block similar to that one shown in Figure 4 is sent from FemtoJava to the co-processor. In this example, the set of seven 32-bit parameters is used to describe a synchronous task in a priority-based scheduling algorithm. The first word is a control-word, which has the following fields:St_Priority – Static priority of the task.EV – Define which external input will start the task (only for asynchronous tasks).ID – Task identifier.Sync_or_Async – Define if this is a Synchronous (Periodic or one-shot) or an Asynchronous (Sporadic) task.Start – Indicates when the task should be activated (if synchronous).Period – Indicates the activation period of the task (if periodic).5. Design Space Exploration for Scheduler Object: a Case StudyThis section illustrates the use of the proposed API in an embedded system design, highlighting software and hardware implementation aspects of the scheduler. The system to be modeled consists of a synthetic workload that simulates realistic applications. The use of hardware and software scheduler versions is shown in two implementation examples.5.1 Software ImplementationThree different classes modeled the application example. The main class for this case study is named TaskTest. This class is responsible for object allocation, initialization, and starting (applied for the real-time tasks). Its source code is shown in Table 1. As it can be observed, only static objects are allocated, due to design restrictions of the current environment, presented in Section 3.Table 1: Main class for the example applicationpublic class TaskTest {public static RelativeTime _300_ms = new RelativeTime(0,300,0);public static RelativeTime _250_ms = new RelativeTime(0,250,0);public static PeriodicParameters pp_300_ms = newPeriodicParameters(null, null, _300_ms, null, _300_ms);public static PeriodicParameters pp_250_ms = newPeriodicParameters(null, null, _250_ms, null, _250_ms);public static Task t1 = new Task(pp_300_ms);public static Task t2 = new Task(pp_250_ms);public static EDFScheduler mySched = new EDFScheduler();public static void initSystem() {Scheduler.setDefaultScheduler(mySched);// Add task in the scheduler task listt1.addToFeasibility();t2.addToFeasibility();// Start the taskst1.start();t2.start();FemtoJava.sleep();}}One important aspect regarding the code of Table 1 relates to the initSystem() method, which represents the starting point of the application execution flow. Therefore, it provides objectinitialization and real-time tasks startup. The real-time tasks are attached to scheduler by the addToFeasibility() method and their startup can be identified by the call to the start() method. Another consideration relates to calling the sleep() method. This means that this initialization class will not be used anymore and that it should be blocked. Such strategy should be performed only in the system initialization method. The software scheduler used in the example is the EDF, but the other scheduler classes are also used in a similar way.Table 2: Task class for the example applicationpublic class Task extends RealtimeThread {private int m_SchedCount = 0;public Task2(ReleaseParameters releaseParam) {super(null, releaseParam);m_ResumeTime = m_taskReleaseTime;}public void mainTask() {while (m_SchedCount < 15) {m_SchedCount++;// ... Repetitive operationswaitForNextPeriod();}finish();}public void exceptionTask() {// handle deadline missing}}The following discussion relates to the Task class, which has two instances: t1 and t2. The first instance is triggered periodically every 300 ms, with a deadline of 300 ms (see Table 1). The second one is triggered periodically every 250 ms, and its deadline is 250 ms. In order to implement these features using the provided API, the Task class needs to extend RealtimeThread class, as shown in Table 2. Moreover, it must define release parameters to implement the modeled features. Therefore, the class PeriodicParameters of the API is used, whose instance is passed as parameter to the superclass constructor (see Table 2). The task class also presents the methods mainTask() and exceptionTask(). The former represents the task body, i.e., the code executed when the task is activated by calling the start() method (see Table 1). Since this task is periodic, there must be a loop, which denotes the periodic execution. The loop execution frequency is controlled by calling the waitForNextPeriod() method, which releases the processor until the next period. The exceptionTask() method represents the exception handling code that is triggered in case of a deadline miss, i.e., if the mainTask() method does not finish until the established deadline.The RAM occupation for this example is 123 bytes and includes the internal data structures used by all classes of the application, including itself. This value is applicable to all scheduler implementation and does not consider stack grow during runtime. The ROM occupation is 2886 bytes and indicates the code size for the application and API classes. The EDFScheduler class code consumes 812 bytes, while the code for the other software scheduler classes is a little bit smaller.5.2 Hardware ImplementationThe implementation of the scheduler co-processor was described in VHDL, and synthesis and analysis were performed using the Quartus II (version 4) environment from Altera. The compilation targeted at the EP20K30ETC144-1 device and consumed 134 logic cells (11% of the total). Currently, the algorithm available for hardware scheduling is a priority-based scheduling. Ongoing work aims to implement other scheduler algorithms in order to evaluate performance and energy consumed by their hardware solutions.Table 3: Main class for the example application using Scheduler in hardwarepublic class TaskTest {public static RelativeTime _300_ms = new RelativeTime(0,300,0);public static RelativeTime _250_ms = new RelativeTime(0,250,0);public static PeriodicParameters pp_300_ms = newPeriodicParameters(null, null, _300_ms, null, _300_ms);public static PeriodicParameters pp_250_ms = newPeriodicParameters(null, null, _250_ms, null, _250_ms);public static Task t1 = new Task(pp_300_ms);public static Task t2 = new Task(pp_250_ms);public static HardwareScheduler mySched = new HardwareScheduler();public static void initSystem() {Scheduler.setDefaultScheduler(mySched);// Add task in the scheduler task listt1.addToFeasibility();t2.addToFeasibility();// Start the taskst1.start();t2.start();FemtoJava.sleep();}}To use the hardware scheduler, the developer follows the same methodology as explained in Section 5.1. Using the example shown in Tables 1 and 2, the application can be completely reused. The single required modification is the scheduler class used, which will be changed from EDFScheduler to HardwareScheduler, as shown in Table 3. Since the co-processor only executes scheduling actions, context switch and dispatching are still processed in software by the HardwareScheduler class. Moreover, the code generation to configure the hardware scheduler causes a small overhead in the addToFeasibility method, whose implementation from Scheduler class is overridden in the HardwareScheduler class. From the developer’s viewpoint, however, there is no difference beyond that highlighted in Table 3.Using HardwareScheduler, the RAM occupation is the same as for software schedulers. The ROM occupation of the HardwareScheduler is 2528 bytes (78% of total memory available on the EP20K30ETC144-1 device), for all the classes used by the example application. The HardwareScheduler class consumes 366 bytes, related to context switch and dispatch.6. Conclusions and future worksThe paper presented how developers can use the same API to implement a multithread object-oriented real-time embedded application, choosing hardware- or software-implemented scheduler. Program memory occupation and area (for hardware version) were evaluated for both implementations.The application development process is not influenced by architectural choices and does not consider if the scheduler must be implemented in hardware or software. Moreover, the developer can reuse all the application code if he/she needs to change the scheduler implementation, as long as he/she uses the proposed methodology.The main principle investigated here, which is the encapsulation of a hardware facility, will be explored for other system functions, like inter-process communication or even inter-processor communications, increasing reusability and reducing costs. The authors also intend to implement more complex scheduling algorithms, like TAFT (Time-Aware Fault-Tolerant) [15].The evaluation of software implementations regarding performance and energy consumption has been already performed [7]. The authors are currently evaluating performance and energy consumed by the hardware solution, in order to compare them with the software solution. The results will be incorporated in the final version of this paper if accepted.References1. A.C. Beck Filho, J. Mattos, F.R. Wagner, L. Carro. CACO-PS: A General-Purpose Cycle-Accurate Configurable Power Simulator. In Proceedings of the 16th Symposium on Integrated Circuits and Systems Design, (São Paulo, Brazil, September 2003). IEEE Computer Society Press 2. C.E. Pereira, M. Pontremoli. Hardware Support for Distributed Real-Time Operating Systems.IFAC Control Engineering Practice. Vol. 5 Number 10, Elsevier-Science. October 19973. C.L. Liu, J.W. Layand. Scheduling Algorithms for Multiprogramming in a Hard-Real-TimeEnvironment. Journal of the Association for Computer Machinery, v. 20, n. 1. p. 46-61, 19734. G. Bollella, J. Gosling, Benjamin Brosgol. The Real-Time Specification for Java. (2001)/rtsj-V1.0.pdf5. J.A. Stankovic. Misconceptions about Real-Time Computing: A Serious Problem for Next-Generation Systems. IEEE Computer, 21(10):10--19, Oct. 1988.6. J.A. Stankovic et al. Strategic Directions in Real-Time and Embedded Systems. ACM ComputingSurveys 28, 4 (Dec. 1996), Pages 751 - 7637. L.B. Becker, M.A. Wehmeister, C.E. Pereira. Power and Performance Tuning in the Synthesis ofReal-Time Scheduling Algorithms for Embedded Applications. In: 17th Symposium on Integrated Circuits and Systems Design, 2004, Porto de Galinhas. Proceedings: ACM Press, 20048. L.S. Rosa Jr. et al. Scheduling Policy Costs on a Java Microcontroller. In Proceedings of theworkshop on Java Technologies for Real-Time and Embedded Systems (JTRES), (Catania, Italy, 2003) pp. 520 – 5339. M.A. Wehmeister, L.B. Becker, C.E. Pereira. Optimizing Real-Time Embedded SystemsDevelopment Using a RTSJ-based API. In: Workshop on Java Technologies for Real-Time and Embedded Systems - JTRES 2004, Agia Napa, Cyprus, October 25-29, 2004. Proceedings Springer LNCS, pp. 292-30210. S.A. Ito, L. Carro, R.P. Jacobi. Making Java Work for Microcontroller Applications. IEEE Design& Test of Computers, vol. 18, n. 5, Sept/Oct. 2001, pp. 100-11011. Sun Microsystems (2004). Java 2 Platform API Specification. Sun document in/j2se/1.5.0/index.jsp12. J.Y.T. Leung and J. Whitehead. On the Complexity of Fixed-Priority Scheduling of Periodic, Real-Time Tasks. Performance Evaluation, v. 2, n. 4, p. 237-250, 1992.13. V.F. Gomes, A.C. Beck Filho, L. Carro. A VHDL Implementation of a Low Power Pipelined JavaProcessor for Embedded Applications. In: X IBERCHIP WORKSHOP - IBERCHIP 2004, Cartagena de Indias, Colombia.14. Object Management Group. UML Profile for Schedulability, Performance, and TimeSpecification. March 2002. </cgi-bin/doc?ptc/02-03-02>15. E. Nett, M. Gergeleit, and M. Mock Enhancing OO Middleware to become Time-Aware,Special Issue on Real-Time Middleware in Real-Time Systems, 20(2): 211-228, March, 2001, Kluwer Academic Publisher. ISSN-0922-6443.。