GeMRTOS Controller

Introduction #

The GeMRTOS controller manages and synchronizes all the hardware events in the system. As shown in FIG.1, the GeMRTOS controller includes the interrupt input module (200) containing device interrupt request inputs (DIRQIs) (201-203) that receives the device interrupt requests (DIRQs) (101-103), the interrupt output module (204) containing processor interrupt request outputs (PIRQOs) (205-207) sending the processor interrupt requests (PIRQs) (107-109), the controller registers (208), the time module (209), the mutex module (210), the event module (211) and the addressable control logic (212) including an interface element (213) and a decoder element (214).

GeMRTOS controller registers (208) #

The behavior of the GeMRTOS controller is determined by a set of GeMRTOS controller registers (208). Some of these registers may be configured through the interface element of the GeMRTOS controller. They are assigned with a unique memory map address to be read and written. For instance, the R_CTRL register can be used to configure some functions of the GeMRTOS controller such as enabling or disabling the frozen mode. Macros are defined in order to access to these registers.

Mutex module (210) #

In a multiprocessor system, a hardware-implemented mutex is required to preserve coherency in critical sections among the processors. The R_MTX_PRC_GRN GEMRTOS controller register, it is called the mutex register, is the main register of the mutex module and it is used to implement a critical section among the processors. A processor may execute a critical section when the value of the R_MTX_PRC_GRN register is equal to its internal identification register CPUID. The R_MTX_PRC_GRN register can take three different kinds of values:

• 0: there is no processor that grants the critical section. A processor may request the mutex when the R_MTX_PRC_GRN register equals to 0. 
• values from 1 to N: the critical section is granted to the processor with internal identification register CPUID equal to the R_MTX_PRC_GRN register.
• constant MTX_BLCK: the critical section is blocked when the R_MTX_CLR_CNT register is different from 0. The value MTX_BLCK is assigned to the R_MTX_PRC_GRN register when the critical section is released by the processor that grants it. This mechanism blocks the critical section until the count of the R_MTX_CLR_CNT register reaches a value equal to 0. The next processor to grant the critical section is stored in the R_MTX_NXT_PRC register. The R_MTX_NXT_PRC register is used to avoid an active competition among the processors that are requesting access to the mutex.

Before a processor starts executing a critical section code, the processor may request the mutex by repeatedly executing a mutex request and verifying that the mutex is granted to it by checking that the mutex register holds its identification CPUID. However, this mechanism may be inefficient when several processors simultaneously request the mutex. A more efficient mechanism is implemented using the R_MTX_RSV_PRC register. Each processor sets the corresponding bit of the R_MTX_RSV_PRC register according to its internal identification register CPUID executing the GeMRTOS_USER_CRITICAL_SECTION_GET macro instruction when the processor requests access to the mutex. The GeMRTOS controller halts a processor when its corresponding bit is set to 1 in the R_MTX_RSV_PRC register and the mutex is not granted to it. The processor halt mechanism is implemented by asserting a wait_request signal for each processor in the interface element of the GeMRTOS controller. The processor that grants the critical section executes the GeMRTOS_USER_CRITICAL_SECTION_RELEASE macro instruction to release the mutex in order to leave the critical section code.

GeMRTOS controller time module #

Most applications require time support. For an adequate and flexible time basis, the system clock signal is prescaled through the up counter R_TM_PSC_CNT register. Consequently, all time references in GeMRTOS are gotten from this prescaled system clock signal. The prescaled value is set by executing the GeMRTOS_CMD_SET_TIME_PRESCALE(scale) macro instruction.

GeMRTOS controller time modes #

The GeMRTOS controller may stay in one of two time modes:

• unfrozen mode: the GeMRTOS controller starts and remains in unfrozen mode while the condition (1) holds:

The up-counter R_TM_CNT, it is called the time counting register, is incremented at the system time unit rate when the GeMRTOS controller is in unfrozen mode.

• frozen mode: the GeMRTOS controller switches to frozen mode when the C1_FRZ_MDE_ENB is equal to one (frozen mode enabled) and the time elapsed since the next time event, stored in the R_NXT_EVN_CNT, is greater than the threshold time configured in the R_FRZ_TM_THR. In frozen mode, the up-counter R_FRZ_TM_CNT, it is called the frozen time counting register, is incremented at the system time unit rate.

During runtime, the normal mode should be the unfrozen mode. In this mode, the system time is held in the up counter R_TM_CNT register. The GeMRTOS controller holds the next time event in the R_NXT_EVN_CNT register. Each time that the up counter R_TM_CNT register reaches the value stored in the R_NXT_EVN_CNT register, a time event is considered to have occurred. If the code associated with the time event is being executed by a system processor, then the processor executing such code is interrupted; otherwise, the system processor with the lowest priority is interrupted. The interrupted system processor should execute the code to process the time event and then the R_NXT_EVN_CNT register should be updated with the next system event. In this mode, the events are processed according to the time they happen. However, if the event processing takes longer than a certain threshold, it becomes convenient in some applications to freeze this dynamic in order to avoid a domino effect over the system events. When the frozen mode is enabled (C1_FRZ_MDE_ENB signal is equal to one) and the next event remains unprocessed, with an interval equal to or greater than the time defined in the R_FRZ_TM_THR register, then the GeMRTOS controller switches to frozen mode. In frozen mode, the up-counter R_TM_CNT register is frozen and the up-counter R_FRZ_TM_CNT register is incremented at the system time unit rate. Consequently, the up-counter R_TM_CNT register keeps the time (in system time units) that the GeMRTOS controller remains in unfrozen mode, while the up counter R_FRZ_TM_CNT register keeps the time (in system time units) that the GeMRTOS controller remains in frozen mode. When the GeMRTOS controller switches to frozen mode, the GeMRTOS controller produces an event (C1_FRZ_EVN). When all the time events are processed (R_TM_CNT > R_NXT_EVN_CNT), the GeMRTOS controller switches back to unfrozen mode.

Unfrozen/frozen related instructions #

Interrupt input module and interrupt output module #

For most cases, an application is implemented as a set of tasks that has to be executed by system processors. A task may be defined as a program code that is executed by a processor in order to produce a certain function of an application. Because there may be more tasks than system processors, a priority is assigned to each task in order to determine the order that tasks are scheduled on the system . Higher priority tasks are executed first. Lower priority tasks are executed when highest priority tasks do not require system processors to be executed.

The pattern of the tasks requiring execution changes during runtime according to the events that occur. When one event takes place, a system processor must be interrupted in order to execute the code that processes that event. At a GeMRTOS controller level, events that produce processor interrupt requests (PIRQs) , may be classified as:

• time events: these events are configured to happen at a certain system time. Time events may be sorted according to the occurrence time in a total order relationship. The next time event is the earliest time event. A time event takes place when the following condition holds:

                                                 R_NXT_EVN_CNT ≥ R_TM_CNT                         (2)

where the R_NXT_EVN_CNT register holds the earliest occurrence time event and the up-counter R_TM_CNT register keeps the system time. The C1_EVN_TM_OCC signal is asserted when Equation (2) is true; otherwise, it is de-asserted. In the R_NXT_TM_EVN_PRC register, the bit corresponding to the processor that executes the task associated with the next timed event is set to 1. Otherwise, if the next time event is not associated with an executing task, all the bits of the R_NXT_TM_EVN_PRC register should be set to 0.

• device interrupt requests (DIRQs) events: these events are produced by the input/output peripheral devices connected to the of input/output peripheral device ports. Most of these events require the execution of the associated interrupt service routine (ISR) in order to satisfy the demand of the input/output peripheral device. Interrupt requests from device interrupt requests (DIRQs) may be enabled or disabled by setting or clearing, respectively, the corresponding bit in the R_IRQ_ENB register. Therefore, a device interrupt request (DIRQ) will produce a processor interrupt request (PIRQ) when there exists a request from that device and the corresponding bit in the R_IRQ_ENB register is enabled.
• internal interrupt trigger events: a processor may interrupt another processor using the R_TRG_PRC_INT register. Setting the corresponding bit of the R_TRG_PRC_INT register triggers the interrupt (bit 0: processor 1, bit 1: processor 2, etc.).

The processor interrupt requests (PIRQs) may be enabled or disabled by setting the corresponding bit of the R_INT_ENB register. When there exists at least a pending interrupt, then the C1_IRQ_PND signal is set to 1, otherwise, it is set to 0.

A processor should be interrupted (the corresponding processor interrupt request (PIRQ) of the GeMRTOS controller should be asserted) when:

• Critical section is not granted to any processor (the C1_MTX_GRN signal is not set), the processor interrupt is enabled (the corresponding bit of the R_INT_ENB register is set) and:
  • the processor is executing the task associated with the next time event (the corresponding bit of the R_NXT_TM_EVN_PRC register is set) and a time event occurred (the C1_EVN_TM_OCC signal is set), or
  • the processor is executing the lowest priority task (the corresponding bit of the R_LOW_PRI_PRC register is set) and there is an IRQ request pending (the C1_IRQ_PND signal is set), or
  • the processor is executing the lowest priority task (the corresponding bit of the R_LOW_PRI_PRC register is set), a time event occurred (the C1_EVN_TM_OCC signal is set) and no processor is executing the next time event (the C1_EVN_TM_OCC signal is not set).
• Trigger processor interrupt is set (the corresponding bit of the R_TRG_PRC_INT register is set) and the processor interrupt is enabled (the corresponding bit of the R_INT_ENB register is set).

The processor interrupt request outputs (PIRQOs) are registered to avoid spurious triggers. The R_IRQ_PND register preserves the status of the pending processor interrupts that should be reset by the proper processor when it executes the interrupt handler routine (ISR). The R_INT_CLR register allows clearing the bit in the R_IRQ_PND register of the corresponding processor interrupt in the GeMRTOS controller. The R1_IRQ_PND signal is asserted when a pending interrupt is set.

When a processor is interrupted, it should execute the interrupt service routine (ISR). When the ISR is executed, the processor interrupt is disabled in the GeMRTOS controller (R_INT_ENB register). To avoid being interrupted in the ISR, the mutex is requested for access to the critical section and then the processor waits until the mutex access is granted.

When the system requires a processor to execute a higher priority task, the GeMRTOS controller interrupts the processor that is executing the lowest priority task. In the R_LOW_PRI_PRC register, the bit corresponding to the processor that is executing the lowest priority task is set to 1; otherwise, it is set to 0.

Input/output interrupts related instructions #

Event module #

The GeMRTOS controller handles a set of events and determines the way they are managed to preserve the consistency of the system. When a processor is interrupted because an event happened, it must execute the event handler routine associated with that event. Once the critical section is granted in the ISR, the processor must get the event that produced the interrupt by reading the event code in the R_LST_EVN register. 

When a processor executes the GeMRTOS_CMD_EVN_OCC instruction, the R_LST_EVN register is transferred through the system bus to the processor. Several events may be asserted when the processor reads the R_LST_EVN register. In order to avoid inconsistency, the event module sorts the events and assigns to the R_LST_EVN register the code of the asserted event with the lowest sorted order. The following table shows the sorted list of events of GeMRTOS controller:

Event module related instructions #

Different functions are implemented by the GeMRTOS controller to assure consistency during runtime. With the help of its internal register, it is very configurable. The GeMRTOS macro instructions are defined to manage all of this settings.