Hardware support in a middleware for distributed and real-time embedded applications

Abstract

One of the main challenges in the development of tools and methodologies for a multiprocessor real-time embedded system is to reuse already developed software, but at the same time obtaining low memory footprint, low energy consumption, and minimal area, obviously addressing the real-time constraints. This work aims to face these problems at the middleware level. We show that adaptations in the platform architecture, for instance exploring hardware implementations of middleware services, such as task scheduling and communication, can drive better gains in application requirements like energy and performance, which are essential for embedded applications. This approach is coupled with a high flexibility in choosing either a hardware or a software implementation, because services are encapsulated into objects and the application development and the design space exploration at middleware level can be performed independently from each other, in a fully transparent way. Furthermore, the use of the object-oriented approach reduces time-to-market and development costs.

An Infrastructure for Hardware-Software Co-Design of Embedded Real-Time Java Applications

“…Regarding communication services, we highlight the work carried out by Yau [7], where an ORB (Object Request Broker) is implemented in hardware. In [2], this idea is extended, by encapsulating hardware implementations of operating systems services (task management and also communication) into objects, thus using a framework to reduce development time.…”

“…In [2] a middleware for multiprocessor-based embedded systems is proposed to encapsulate hardware implemented services into objects, reducing development time, while simultaneously achieving realtime predictability, better performance, and lower energy consumption. This work extends that one by including the possibility to manage application threads developed either in software or in hardware.…”

A virtual platform for multiprocessor real-time embedded systems

“…The latencies are high because the protocol stack is implemented in software. This throughput can be optimized using a hardwareimplemented communication service [23] or a processor with higher performance [8]. To evaluate the memory consumption of the provided services, Table 3 shows code memory (ROM) and variables memory (RAM) sizes.…”