12th International Conference on DEVELOPMENT AND APPLICATION SYSTEMS, Suceava, Romania, May 15-17, 2014

978-1-4799-5094-2/14/$31.00 ©2014 IEEE

Hardware Event Treating in nMPRA

Elena-Eugenia (CIOBANU) MOISUC, Alexandru-Bogdan LARIONESCU, Vasile Gheorghita GAITAN Department of Electrical Engineering and Computer Science

Stefan cel Mare University Suceava, Romania

neli.ciobanu@eed.usv.ro, lari@eed.usv.ro, gaitan@eed.usv.ro

Abstract— In real-time systems, events treating is one of the most important aspects. There can be time events, watchdog timer events, deadline events, interrupt events, mutex events, and synchronization and inter-task communication events. Since multiple events can occur simultaneously, it is important to find a way to select the order in which the events will be treated. For that, in this paper it is presented a method of global prioritization of the events by category using a hardware prioritization scheme for the n-task Multi Pipeline Register Architecture (nMPRA) and an analysis of how are treated mutex and inter-task communication events in the same architecture.

Keywords— Real-time systems; event treating; embedded systems; hardware scheduler; mutex; inter-task communication; microprocessors.

I. INTRODUCTION The existing commercial and free Real-Time Operating

Systems (RTOS) for embedded systems can’t allow a task to synchronize simultaneously with multiple events utilized for resource sharing, synchronization and communication between tasks such as semaphores, flags, mutexes, signals, events, messages. This problem was identified in RTOS that run on microcontroller architectures which don’t have cache memory and virtual memory management units. Such RTOS include the following: FreeRTOS, μC-OS/II, KeilOS, μTKernel, μITRON, Hartik, XMK OS, EmbOS, SharcOS, eCOS, Erika, and PortOS [1][2][3]. The general-purpose processors utilized for embedded systems can create different problems, mainly because their inefficient power consumption and non-deterministic performances. Because of that it can determine the use of an oversized platform to assure the proper behavior of the system in the worst case situation. As a consequence, these processors are not suitable for embedded systems with low power consumption requirements and real-time capabilities. Nowadays, FPGA devices [4][5][6] are widespread, are a lot cheaper and they have larger capacities, equivalent to millions of logic gates [7][8][9]. For this reason, this paper proposes a hardware implemented support for event prioritization and treating. The Multi Pipeline Register Architecture (MPRA) presented in [10] and [11] was modified in [12] and transformed into n-task MPRA (nMPRA). The basic idea was to replicate the pipeline registers and to create multiple instances of the CPU, named semi CPU, in order to have a semi CPU for every task i (sCPUi).

The nMPRA consists of an original hardware structure utilized for task scheduling, both static and dynamic, and provides unitary events management. The aim was to improve through hardware the performances of RTOS for microcontrollers, in order to switch faster between the tasks, to improve the response time to external events, to improve the behavior of the interrupts, which are treated as events in this case, and to offer several types of inter-process communication primitives (messages, mutexes, and so on).

The article is structured as follows: section II presents the nMPRA and its main features, in section III it is presented the global prioritization of the events by category, using a hardware prioritization scheme, in section IV is presented an analysis of the treating of the synchronization and communication events, as well as the mutex events, and section V contains the final conclusions.

II. NMPRA The nMPRA is depicted in Fig.1. For each sCPUi we have a

set of pipeline registers, a register file, a PC register, and several control registers. Each sCPUi runs the instructions of the task i (i=0…n-1). All sCPUi share the other components of a pipeline processor, like instruction and data memory and ALU, and they are identical, excepting sCPU0, which is the only one active after reset and is the only one allowed to access the configuration and monitoring registers of the nMPRA [12].

The new architecture has a static and a dynamic scheduler. The static scheduler is preemptive and assigns static priorities to all the tasks. The scheduler can perform fast task switching at the occurrence of an event. All the events associated with a task will inherit the task’s priority, even if it changes dynamically.

The scheduler in the nMPRA is constantly monitoring all the events that are addressed to the sCPUi. The list of possible expected events consists of: timer interrupts (TEvi), watchdog timer events (WDEvi), two deadline events (D1Evi and D2Evi, first one being equivalent to an alarm and second one being equivalent to a fault), interrupts attached to the task i (IntEvi), mutexes used for handling shared resources (MutexEvi), synchronization and communication events between tasks (SynEvi), and the self-sustaining execution signal for the current sCPUi (lr_runs_CPUi).

This paper was supported by the project “Sustainable performance in doctoral and post-doctoral research PERFORM–Contract no. POSDRU/159/ 1.5/S/138963”, project co-funded from European Social Fund through Sectorial Operational Program Human Resources 2007-2013.

66

Fig. 1. nMPRA. PC - Program Counter, IF/ID - Instruction Fetch/Instruction Decode stage, ID/EX-Instruction Decode/Execute stage, EX/MEM - Execute/Memory stage, MEM/WB - Memory/Write Back stage

In Fig. 2 is presented the digital logic for the ready state for every sCPUi in the system. Whenever an event is treated and its source is cleared, the current sCPUi may lose control of the CPU. The events listed above can be validated with the help of the following signals: lr_enTi, lr_enWDi, lr_enD1i, lr_enD2i, lr_enInti, lr_enMutexi and lr_enSyni, which are grouped in a

special register called Task Register (TRi). The only exception is lr_run_sCPUi. The resulting signals lr_TEvi, lr_WDEvi, lr_D1Evi, lr_D2Evi, lr_IntEvi, lr_MutexEvi, lr_SynEvi and lr_run_sCPUi are grouped in a register called Event Status Task Register (ESTRi), which can be accessed to see what events expected by the task i have occurred.

lr_enTi

TEvi

lr_enWDi

WDEvi

lr_enD1i

D1Evi

lr_enInti

IntEvi

lr_enMutexi

lr_enD2i

D2Evi

MutexEvi

lr_enSyni

SynEvi

lr_run_sCPUi

sCPUEvi

mr_stopCPUi

sCPU_Evi

/sCPU_Evi‐1

/sCPU_Evi

/sCPU_Ev0

sCPUi_ready

ENB

n nsCPUi_ID

i = 0 ...n‐1

/sCPU_Ev1

sCPUi_ID_TS

lr_TEvi

lr_sCPU_Evi

lr_WDEvi

lr_D1Evi

lr_D2Evi

lr_IntEvi

lr_MutexEvi

lr_SynEvi

D Q

QCLK

S

RCLK↑

Fig. 2. sCPUi level hardware scheduler – digital logic for ready state

III. GLOBAL PRIORITIZATION OF THE EVENTS In case of simultaneously activation of multiple events

associated with a task (sCPUi), there must be a way to select the order in which the events are treated. For that, every sCPUi has attached an Event Priority Register (EPRi), which contains the priority level of each type of event associated with that sCPUi. The priority is different for each type of events, ranging from 0 to 7 (there are 8 types of events). After reset, at boot time, nMPRA activates sCPU0, which will execute all the initialization software and the startup sequences for all the

other sCPUi (i=1…n-1). sCPU0 sets the priority level for each type of event associated with every sCPUi accordingly to the user’s demands.

We propose o prioritization scheme (Fig. 3) that selects the active event category with the highest priority, in order to be treated. The priority level of each event category can be static or it can be changed dynamically, depending on the system’s demands. If there are multiple active events in the selected category, it must be done another selection of the event from that category that will actually be treated first. This second selection depends on the type of the event category.

67

Fig. 3. Global events prioritization scheme

In Fig. 3 is presented the global prioritization of the events scheme. Since we have eight types of events in the system, we’ll have eight decoding and selecting event schemes similar to the ones in the left side of Fig. 3. Pri_TEvi, Pri_WDEvi, Pri_D1Evi, Pri_D2Evi, Pri_IntEvi, Pri_MutexEvi, Pri_SynEvi and Pri_RunEvi are the priorities of the event categories and they are grouped in the EPRi register. The demultiplexers, activated by the corresponding event activation signal, selects the priority of the event category accordingly to the priority level set in the corresponding field in the EPRi register, generating the priority signals for each event type. The output of the priority field is also used for selecting the MUX multiplexers output, which collects the result of the prioritization scheme from the right side of Fig. 3 and is used for selecting the event type to be treated. The OR gates allow each type of events to select its priority, the AND gates validate a certain priority, and the D flip-flop has the role of achieving synchronization with the system clock. EvPri_0 … EvPri_7 signals represents all 8 possible priorities for the event categories. All the events that are the only ones in their category, like the time-related events (TEvi, WDEvi, D1Evi, and D2Evi) have associated one trap register that point towards their event treating routine. The address of the routine is loaded into the pointer register at startup, after reset, by sCPU0. In case that one of these events has occurred, the task with whom it is associated is becoming active and it has the highest priority among the active events, the Program Counter register of the corresponding sCPUi (PCi) is automatically loaded with the content of the pointer register, determining the execution of the

routine associated with the event. The returning address, which was the value from the PCi register prior to the loading of the routine address, is saved automatically in a backup register inside PCi. After finishing the execution of the event servicing routine, if there are other active events for task i, the routine address for the event with the highest priority among the remaining ones will be automatically loaded into PCi. After servicing all the active events, PCi is loaded with the returning address from the backup register.

The structure of the PCi and trap registers and the mechanism that allows the automatic loading of the procedures’ address will be presented in a future paper.

The procedure described above is valid for every event in the system. In the next section we’ll analyze the case of the syn and mutex events, which can be more than one in their category.

IV. ANALISYS OF THE SYN AND MUTEX EVENTS The synchronization and communication events between

sCPUi (SynEvi) cannot be treated individually, because of the method chosen for their implementation, which uses a set of global registers with fast access.

The Event Register File (ERF) consists of s registers of 2n+k+1 bits, storing the event itself on the most significant bit. The next n bits hold the ID of the source task which activated the event, the following n bits hold the ID of the destination task for which the event is addressed, and the last k bits are

68

used as a message field that can be utilized for any purpose. Writing an event in ERF will be done at the first free address determined by the hardware scheme. When all the locations are written, it is activated the gr_en_mem_full signal, indicating that all the events are used. These events are treated in the same manner as the time-related events, having associated just one trap register that holds the address of the service routine.

The activation of the Select_SynEvi signal determines the automatic load of the routine address in PCi, saving the returning address in the backup register inside PCi.

In the service routine of the syn events we’ll have to search the ERF and read all the events associated with task i and then clear them. The priority of the syn events is given by their position in the ERF. The problem with the syn events is that they are written in the ERF at the first free address, and we can’t predict which event will be written at a specific address. In order to read a syn event from the ERF, we have to search it using a Content Addressable Memory (CAM) principle. The search starts at the 0 address and ends on the first address for which there is a match between the destination task ID and the current task ID. By using a read instruction to read the content of the ERF register, we can find if there is a match, the issuer of the event and what message has been sent to the current task [12]. The mutual exclusion is used whenever the software is using shared resources.

In the nMPRA, the mutexes are implemented using a set of global registers with fast access (it can be made in the execution stage – EX). The Mutex Register File (MRF) is composed from m registers with length n+1 bits that contain the mutex bit in the highest bit position and the ID of the proprietary task that holds the mutex in the lowest priority n bits [12].

The MRF registers can be accessed by any sCPUi and this means they are a shared resource for all sCPUi in the system. Any time a blocked mutex gets freed, it activates the MutexEvi signal. For each sCPUi one can decide what mutex is taken into consideration with the help of lr_en_M0, …lr_en_Mm-1 signals. These signals can be stored in local registers, named Enable Mutex Register (EMRi). There can be one or several EMRi registers, depending on the number of mutex bits implemented in the MRF. In general, we only use one shared resource at a time. Because of that, it is easy to manage the mutexes in software, without the need of having a hardware implemented prioritization scheme for selecting the current mutex.

Using a test and set instruction to access a mutex may lead to the locking of the current task if the mutex is taken, determining it to wait for the mutex to get freed. Since we know what mutex we expect to get free, it is easy to select and treat in software the mutex event after its occurrence. So, the signal Select_MutexEvi has only the purpose to indicate that the mutex we expect is not taken anymore.

The signal is used to select the pointer register associated with the mutexes and to load its content into the PCi register, determining the execution of the mutex servicing routine, just like it was presented in section III of the paper.

V. CONCLUSION The prioritization scheme presented in this paper have the

role to eliminate the treating of the events exclusively through software and to permit their treating in hardware, reducing the time necessary to identify the source of the event and to launch the appropriate event servicing routine. The prioritization scheme is simple and can be applied to all the events. Furthermore, it can be implemented for other event categories that will be introduced into the architecture in the future. The structure of the PCi registers and that of the pointer registers will be detailed in future papers, as well as the analysis of other events.

ACKNOWLEDGMENT This paper was supported by the project “Sustainable

performance in doctoral and post-doctoral research PERFORM–Contract no. POSDRU/159/1.5/S/138963”, project co-funded from European Social Fund through Sectorial Operational Program Human Resources 2007-2013.

REFERENCES [1] Tan, S.L.; Bao Anh, T.N., “Real-time operating system (RTOS) for

small (16-bit) microcontroller”, Consumer Electronics, ISCE '09, IEEE 13th International Symposium on, pp.1007-1011, 25-28 May 2009.

[2] Bao Anh, T.N.; Tan, S.L., “Survey and performance evaluation of real-time operating systems (RTOS) for small microcontrollers”, Micro, IEEE Computer Society, ISSN: 0272-1732, 21 August 2009.

[3] Gaitan N.C., “Real-time acquisition of the distributed data by using an intelligent system”, Electronics And Electrical Engineering, vol. 8, no. 104, pp. 13-18, 2010, ISSN: 1392,1215.

[4] Shawash, J.; Selviah, D.R., “Real-Time Nonlinear Parameter Estimation Using the Levenberg–Marquardt Algorithm on Field Programmable Gate Arrays”, Industrial Electronics, IEEE Trans. on, vol.60, no.1, pp.170-176, Jan. 2013.

[5] Shahbazi, M.; Poure, P.; Saadate, S.; Zolghadri, M.R., “FPGA-Based Reconfigurable Control for Fault-Tolerant Back-to-Back Converter Without Redundancy”, Industrial Electronics, IEEE Trans. on, vol.60, no.8, pp.3360-3371, Aug. 2013.

[6] Shi-Hai Zhu, “Hardware Implementation Based on FPGA of Interrupt Management in a Real-time Operating System”, Information Technology Journal, 2013.

[7] Shahbazi, M.; Poure, P.; Saadate, S.; Zolghadri, M.R., “Fault-Tolerant Five-Leg Converter Topology With FPGA-Based Reconfigurable Control”, Industrial Electronics, IEEE Trans. on, vol.60, no.6, pp.2284-2294, June 2013.

[8] Tran, T.; Ohishi, K.; Yokokura, Y.; Mitsantisuk, C., “FPGA-based High-Performance Force Control System with Friction-Free and Noise-Free Force Observation”, Industrial Electronics, IEEE Trans. on, 2013.

[9] Alecsa, B.C., “FPGA implementation of a matrix structure for integer division’’, Proceedings of the 3rd International Symposium on Electrical and Electronics Engineering, Galati, Romania, 2010.

[10] Dodiu, E.; Gaitan, V.G.; Graur, A., “Custom designed CPU architecture based on a hardware scheduler and independent pipeline registers – architecture description”, IEEE 35’th Jubilee International Convention on Information and Communication Technology, Electronics and Microelectronics, Croatia, 24 May 2012, ISSN: 1847-3946.

[11] Dodiu, E.; Gaitan, V.G., “Custom designed CPU architecture based on a hardware scheduler and independent pipeline registers – concept and theory of operation”, 2012 IEEE EIT International Conference on Electro-Information Technology, Indianapolis, IN, USA, 6-8 May 2012, ISBN: 978-1-4673-0818-2, ISSN: 2154-0373.

[12] V.G. Gaitan, N.C. Gaitan, I. Ungurean, “CPU Arhitecture based on a Hardware Scheduler and Independent Pipeline Registers”, unpublished, IEEE Trans. on VLSI System, 2014.

69