Synthesis of Full Hardware Implementation of
RTOS-Based Systems
Yuuki OOSAKO

Nagisa ISHIURA

School of Science and Technology
Kwansei Gakuin University
Sanda, Hyogo, Japan

Hiroyuki TOMIYAMA

Hiroyuki KANBARA

College of Science and Engineering
Ritsumeikan University
Kusatsu, Shiga, JapanASTEM RI Kyoto
Kyoto, Japan

Abstract—This paper presents a method of automaticallysynthesizing a hardware design from a set of source codes
for a real-time system utilizing an RTOS. It generates a full
hardware implementation where all the tasks and handlers inthe system as well as all the necessary services provided by
the RTOS kernel are implemented as hardware. Every task andhandler is synthesized into an independent hardware module
so that it may run in parallel with the other tasks/handlers assoon as it is ready. This leads to task switching with extremely
low overhead and reduced computation time both by paralleland hardware execution. Moreover, this eliminates the necessityof the task queue management; task scheduling is realized bya relatively simple manager hardware which instructs eachtask/handler to run or stall based on the values of its status
variables. Since most of the API calls from tasks/handlers are
reduced to reads/writes of these status variables, they can be
expanded inline into the tasks/handlers’ source codes which arecompiled into hardware designs by a high-level synthesizer. We
have implemented a prototype synthesis system which assume
the use of the TOPPERS/ASP3 real-time kernel. A hardware
implementation synthesized from a sample1.c code, bundled in
the TOPPERS/ASP3 release, took 23 cycles for waking up a
waiting task and only 1 cycle for activating an interrupt handler.
Index Terms—real-time systems, RTOS, system synthesis,
hardware accelerator, TOPPERS/ASP3, high-level synthesis

I. I NTRODUCTION
Today embedded systems are used in broad range of domains. Recent applications includes unmanned aerial vehicle,
autonomous cars, service robots, etc. A real-time operating
system (RTOS) is an indispensable component for building
such real-time systems, which helps microprocessors to perform multiple tasks within the stipulated time. As the systems
are deployed in more and more sophisticated and time-criticalapplications, it is becoming a difficult task to ensure their realtime performance.
One approach to enhancing response performance of RTOSbased systems is to implement some or all functions of RTOS
in hardware. Literatures [1], [2], and [3] accelerated RTOS
schedulers with hardware support. There have been evenattempts to implement most of the functionalities of RTOS
in hardware [4], [5], [6]. However, in this approach, tasks andhandlers remain executed as software, which inevitably incurs
the overhead of processor’s task switching. Moreover, responsec
978-1-5386-7557-1/18/$31.00 ⃝2018
IEEE

1

time may not be improved if the heavy loads on tasks are thebottle neck.
On the other hand, with high-level synthesis technology[12], the tasks and handlers are converted into dedicatedhardware which leads to considerable speed-up. Automatedsystem design methods were proposed in [7] and [8], whereselected tasks or handlers were synthesized into hardware,
but RTOS and some tasks remained as software executed ona CPU. Literature [9] and [10] converted a whole system
including interrupt handlers into hardware, but they only dealt
with bare-metal systems without an RTOS.
In this paper, we attempt to solve this problem by implementing both the RTOS functionalities and tasks/handlers into
hardware. Unlike the existing RTOS acceleration methods, we
get rid of scheduling queues in our method. All the tasks andhandlers are implemented as independent hardware modules
which may run as soon as they are ready. Then complex
scheduling mechanism is reduced to a simple controller whichallows/holds the execution of the tasks/handlers.
Our prototype system takes a set of C source codes implementing a real-time system using the TOPPERS/ASP3
kernel and automatically generates Verilog HDL codes. In apreliminary experiment, the generated hardware took 23 cycles
for waking up a waiting task and only 1 cycle for activating
an interrupt handler.
II. R EAL -T IME O PERATING S YSTEMAn RTOS (Real-Time Operating System) runs multiple
sequential programs concurrently on a single or multiple
CPUs. We refer each sequential entity a task. The task isinitially inactive and becomes ready when certain activating
conditions are met. Among the ready tasks, one of them is
executed and the others are waiting for their turns. The RTOS
scheduler is in charge of the choice. In real-time systems, thedeadline is defined to each task and the computation of the task
must be finished by the deadline. RTOSs are equipped withmechanisms to realize this. One of them is task prioritization,
where a priority is set to each task and the task with the highest
priority is executed. Depending on the policy of the RTOS,
priority may be dynamically updated. A handler is a routine
invoked to deal with events. While a cyclic handler is activated
at a specified regular interval, an alarm handler is activated ata specified time. An interrupt handler is a routine invoked bymanagerarbiter

TSK TSK TSK TSK CYC CYC ALM INT
RTOS

pri
local
mem

addr
data

CPU

addr
data
pri

DMEM

local
mem

addr
data

addr
data

addr
data

addr
data

pri

HW
TSK TSK TSK TSK CYC CYC ALM INT

local
mem

task
statustask
statuscyclicstatusmanager
arbiterstall, reset
addr
data

TSK1

stall, reset
addr
data

...

IMEM

TSKn

stall, reset
addr
data

CYCi

end
pri

DMEM

local
mem

Fig. 1. Full Hardware Implementation of RTOS-Based Systems

addr
data

addr
data

alarm
statusstall, reset
addr
data

ALMi

end
pri

a triggering signal or event. Usually, those handlers run in ahigher priority than tasks. RTOSs provides many services otherthan task scheduling, such as mutual exclusion and inter-task
communication.
When designing real-time systems, we must pay attention
to the delays caused by the following factors:
1) Scheduling overhead, incurred by moving new and preempted tasks between the queues and selecting a job to
execute.
2) Context switching overhead, incurred by saving thecontext (the contents of some registers) of the runningtask/handler, loading the context of the next task/handler,
and resuming execution.
3) Waiting for CPU availability, where a ready task may
have to wait for another task/handler with equal or
higher priority in the running state to finish their execution.
Hardware schedulers [1], [2], [3] or hardware RTOS [4],[5], [6] can reduce the delay from the first factor, but not
those from the second and the third. Some hardware support
on the processor side is needed to reduce the overhead fromcontext switching. Some parallel features are needed also on
the processor side to eliminate the third overhead.
III. F ULL H ARDWARE I MPLEMENTATION OF RTOS-BASEDS YSTEMS
A. Overview
We propose in this paper a method of synthesizing full
hardware implementation of real-time systems. Given a setof source codes of a system that runs on top of an RTOS,
hardware implementation (in HDL) is auto-generated which
is functionally equivalent to the system running on a CPU.
Fig. 1 illustrates the concept and a rough sketch of theresulting hardware configuration. The original system is designed to run on a CPU where binary codes of multiple tasks

2

local
mem

addr
data

addr
data

int
statusstall, reset
addr
data

INTi

end
global
mem

addr
data

globalstatus

mutex
mutex

IRQ

Fig. 2. Detailed configuration of synthesized hardware(TSK), cyclic/alarm/interrupt handlers (CYC, ALM, INT), andan RTOS are stored in the instruction memory (IMEM). We
assume that all the tasks/handlers are created statically atcompile time rather than dynamically at run time. Then, oursystem converts IMEM and CPU into equivalent hardware(HW). Every task and handler is synthesized into an independent hardware module. We assume that task/handler modules
which are in ready states may run in parallel regardless of
their priorities, then a typical scheduler and waiting queues are
eliminated. Instead, a manager module controls the run/stallof the task/handler modules. Since multiple accesses from themodules may come to the data memory (DMEM) at the sametime, they are arbitrated by an arbiter module. The prioritiesof the tasks/handlers are reflected in this arbitration.
In this paper, we assume that mutual exclusion is well
implemented in the original software version on an assumptionthat multiple tasks/handlers might run in parallel. Namely, asource code where mutual exclusion is implemented assumingthat only one task/handler is running at any point of time isout of the scope of our method.
B. Hardware Configuration
Fig. 2 shows a detailed hardware configuration synthesizedby our method. TSKi, CYCi, ALMi, and INTi are mod-

ules for a task, a cyclic handler, an alarm handler, and aninterrupt handler, respectively. The manager module controls
the tasks/handlers and the arbiter module arbitrates memory
accesses.
Each task/handler has a stall input. When stall==1, the clock
is suppressed within the task/handler. Thus the task/handler
runs when stall==0, and stops when stall==1. Besides, eachhandler as a reset input which is used to restart the handler.
When reset==1, the task returns to its initial state.
The manager determines the value of the stall and reset
inputs based on the values of the registers to store the statusof each task/handler (task status, cyclic status, alarm status,
and int status in the figure). The status registers include thecurrent status, the current priority, the waiting factor of thetask/handler, for example. In the case of a cyclic and alarm
handler, the remaining time until time-out is also included.
When a task is in an inactive state, for example, the stall
signal is set to 1, and as soon as it goes into a running state,
the stall signal is cleared to 0.
The status registers are placed in the memory space. Whena task/handler requests a memory access with an address, thestatus register is read/written if the register is mapped to theaddress, otherwise the request is forwarded to the memory
through the arbiter. Most of the service calls are implemented
as sequences of reads/writes of the status variables.
The cyclic and alarm handlers do not use external timers
but have their own clock counters as part of their status
registers. The counters are decremented at every clock andthe handlers are activated (the stall signals are reset) when the
counters become zero. As for interrupt handling, the manager
watches the external interrupt signal (IRQ) and updates thestatus registers of the interrupt handlers, which activates thehandlers.
Since all the ready tasks and handlers may run in parallel, multiple access may occur simultaneously on the same
memory bank. The arbiter arbitrates the memory accesses.
The arbitration is done based on the priorities of the tasks
and handlers. Namely, only the memory access from thetask/handler of the highest priority is granted and the stall
signals are sent back to the other tasks/handlers.
Another concern regarding parallel execution oftasks/handlers is simultaneous occurrences of service calls,
which may cause conflicting or inconsistent updates on status
registers. To avoid this, the manager allows only one systemcall at a time; if there are multiple calls simultaneously, only
one of them is processed first and the others are deferred.
This serialization is realized using a mutex.
The mutex is also implemented in hardware. If there
are multiple lock requests from tasks/handlers, only one ofthem is granted, and stall signals are sent back to the othertasks/handlers.
IV. D ETAILS OF THE METHOD BASED ON TOPPERS/ASP3
This section describes the details of the proposed method,
based on the TOPPERS/ASP3 kernel1 as an example.

TABLE IS TATES OF TASK IN TOPPERS/ASP3
State
Dormant
Ready
Running
Waiting
Suspended
Waiting-suspended

Meaning
The task is not active, or its processing has ended
The task is ready and waiting for the CPU
The task is being executed
The task is suspended because some condition is
not satisfied
The task is forcibly suspended
The task is both waiting and suspended

TABLE IIS ERVICE CALLS FOR EXECUTION CONTROL AND MUTUAL EXCLUSION
Service call
act tsk(ID tskid)
slp tsk()tslp tsk(TMO timeout)
wup tsk(ID tskid)
rel wai(ID tskid)
sus tsk(ID tskid)

rsm tsk(ID tskid)
dly tsk(RELTIM time)
ext tsk()ras ter(ID tskid)
ter tsk(ID tskid)

Service callsta cyc(ID cycid)
stp cyc(ID cycid)
sta alm(ID almid,
RELTIM almtim)
stp alm(ID almid)

Service call
loc mtx(ID mtxid)
unl mtx(ID mtxid)3(b) Handler control
Function
Moves the cyclic handler from the nonoperational state to the operational state
Moves the cyclic handler from the operational state to the non-operational state
Sets the activation time of the alarm handler
and moves the alarm handler from the nonoperational state to the operational state
Moves the alarm handler from the operational state to the non-operational state(c) Mutual exclusion
Function
Acquire the mutex
Release the mutex

TOPPERS/ASP3 is the third generation real-time kernel
developed in the TOPPERS project2 based on µITRON4.0
specification [11].
The tasks are created statically at system compilation time.
In the terminology of the TOPPERS kernel, a task is in one of
the six states in TABLE I. The tasks are initially in the dormant
state and become ready when conditions are met. The readytasks are managed in queues and selected one is moved to therunning state to be executed. The tasks may move or be forced
to the waiting or the suspended (or even both) states. All the2 http://www.toppers.jp

1 https://www.toppers.jp/en/asp-kernel.html(a) Task control
Function
Moves the task from the dormant state to theready state
Moves the invoking task to the waiting state
Same as slp tsk() but with time-out
Cancels the waiting state of the task
Forcibly cancels the WAITING state of thetaskMoves the task from the running state or
ready state to the suspended state, or fromthe waiting state to the waiting-suspended
stateMoves the task from the suspended state
to the ready state, or from the waitingsuspended state to the waiting state
Moves the invoking task to the waiting state
for the specified time
Moves the invoking task from the runningstate to the dormant state
Moves the task to the dormant state
Forcibly moves the task to the dormant stateTABLE III
VARIABLES TO EXPRESS TASK STATUS
VariabletskstattskpritskbpritskwaitwobjidlefttmoactcntwupcntrasterdisterMeaning
Current status
Current priority
Base priority
Wait factor
Waiting object ID
Remaining time until time-out
Activation request count
Wake-up request count
Termination request is raised
Termination is disabledtasks share a single memory space. The size and the starting
address of the stack for each task/handlers are specified in aconfiguration file. TABLE II lists major service calls regarding
the control of tasks and handlers. For example, in the first row,
the act tsk call with a task ID moves the task from the dormant
state to the ready state.
A. Tasks
The stall signal to a task is set to 0 only when the task is ina running state. Otherwise (when it is either dormant, ready,waiting, suspended, waiting-suspended) the stall signal is set
to 1. In addition, the stall signal is also set to 1 when requests
for memory access or mutex lock from the task is deferred.
Since all the ready tasks may be executed in parallel, thetasks in the ready state immediately moves to the runningstate, so long as dispatch is not prohibited. This pseudoscheduling is handled by the manager module; when sometask become ready and the dispatch is not disabled, then the
manager updates the state of the task from ready to runningand clears the stall signal at the next clock cycle.
A running task ends its execution by calling ext tsk. This
moves the task into the dormant state. On notifying this, themanager sets reset = 1 and stall = 1 to bring the task to theinitial state.
The status of each task is kept in task status registers in the
manager module. In the ASP3 kernel the object to represent
a task (in terms of the C struct) has 10 members listed in
TABLE III, and we provide exactly 10 registers corresponding
to the members. The status registers are mapped in the memory
space and are accessed by load/store operations from thetask modules. Besides of the task objects, some global status
variables are also used to control the execution of the task
modules. They store the interrupt prohibition flag, the interrupt
mask, the dispatch prohibition flag, and the CPU lock flag.
Most of the service calls of the ASP3 kernel are implemented by a sequence of reads and updates of the task object
members. This means that the original C code for the service
call can be used almost as it is to generate task modules byhigh-level synthesis. For example, Fig. 3 is the C code to
implement the act tsk call (which moves the task from thedormant state to the ready state). The only modification fromthe original code is in lines 11 and 21. These calls are foracquisition and release of the mutex to serialize service calls.

4

1: ER act_tsk(ID tskid) {2:
3:
if (IS_TASK_CONTEXT && tskid == TSK_SELF) {4:
tskid = TOPPERS_HW_SELF_ID;
5:
}
6:
7:
if (tskid <= 0 || TNUM_TSKID < tskid) {return E_ID;}8:
volatile T_RTSK *target =9:&(task_status[tskid-1].rtsk);
10:11:_loc_service_call();
12:
13:
uint_t actcnt = target->actcnt;
14:
15:
ER rc = E_OK;
16:
if (glob_status.f_cpu_locked) {rc = E_CTX;}
17:
else if (actcnt >= TMAX_ACTCNT) {rc = E_QOVR;}
18:
else if (target->tskstat != TTS_DMT) {rc = E_QOVR;}
19:
else {target->tskstat = TTS_RDY;}
20:
21:_unl_service_call();
22:
23:
return rc;
24: }Fig. 3. C Implementation of act tsk

For the sake of efficiency, the body of this function is inline
expanded into the tasks C code and then put into a high-level
synthesizer.
B. Handlers
Cyclic and alarm handlers are dealt with basically in thesame way as in the tasks; the manager controls the stall signals
to the handlers based on the values of the status registers
for the handlers. On the other hand, the handler notifies thecompletion by setting end signal to 1.
In the case of the cyclic handler, the manager holds two
member variables per handler; cycstat represents the status of
the handler (like tskstat of a task) where cycstat==1 means
it is running and cycstat==0 means it is dormant; lefttim isa timer variable to keep the remaining time until the next
activation (in millisecond). The cycle time is written into thetimer variable when the handler is started and is decremented
at each millisecond. Associated with the timer variable, themanager has a sub-counter variable that keeps the fraction ofa millisecond in terms of the clock period; it is decremented
at each clock cycle to measure a millisecond. When the valueof the cycle timer becomes 0, the stall signal to the handler is
set to 0, and the cycle time is set again to the timer variable.
The detailed flow of cyclic handler execution is as follows.
The manager uses an auxiliary variable f reset in addition
to cycstat and lefttim, by which a request to start the cyclic
handler is notified to the manager.
1) (task) calls sta cyc(). This call sets f reset = 1 andcycstat = 1.
2) (manager) if f reset==1, then sets the cycle time tolefttim, and sets f reset==0.
3) (manager) decrements lefttim at each millisecond.
4) (manager) if lefttim==0, then sets cycstat = 1 and stall= 0 to run the handler and re-sets cycle time to lefttim.
5) (handler) when the final state is reached, emits end = 1.

6) (manager) if end==1, then sets stall = 1 and reset = 1
to force the handler to the initial state (this sets cycstat= 0 and stall = 1).
7) (manager) sets reset = 0 and goto 3.
The alarm handler works in almost the same way as thecyclic handler. The difference is that the alarm handler is notrepeatedly executed. Thus, the manager does not have to re-set
variable lefttim.
The interrupt handler is also controlled by the same mechanism as the other types of handlers. When an interrupt israised on the IRQ port, the stall signal is set to 0 to activate thehandler, provided the interrupt is not prohibited at the point.
In the model of TOPPERS, interrupts are grouped in termsof lines; multiple devices of the same types are connected toa single line. When an interrupt is raised from one of thedevices on a line, the interrupt service routines (ISRs) for all
the devices on the line are executed sequentially. A priority
is defined to each line, which may be changed dynamically,
and the prohibition flag and the priority mask are provided toeach line.
In our scheme, one interrupt handler module is generated
per line, which includes hardware to execute the service
routines of all the devices on the line.
When an interrupt is raised on a line, the manager checks
the following conditions:• The CPU lock flag is clear.
• The interrupt lock flag is clear.
• The interrupt request prohibition flag of the line is clear.
• The interrupt priority of the line is higher than theinterrupt mask of the line.
If all the conditions are met, the manager sets a register exec
representing the state of the handler to 1, which turns stall = 0
and the handler is run. The handler notifies its completion to
the manager by setting end = 1. Then the manager sets reset= 1, which turns exec = 0 and stall = 1.
C. Mutex
We designed a hardware mutex module to provide thefunction of the mutex. If multiple locks are requested simultaneously from tasks/handlers, just one of them is granted, andstall signals are set to 1 for all the other tasks/handlers.
The detailed flow of handling the mutex is as follows. A
task/handler calls loc mtx to request for a mutex. The mutex
is successfully acquired if member variable acquired of the
mutex object is 1.
1) (task/handler i) calls loc mtx.
2) (manager) sets the i-th request port of the mutex module
LCKi to 1.
3) (mutex) sets the i-th acknowledge port ACQi to 1. If
there are multiple requests on the same clock cycle, thesmallest i where LCKi==1 is chosen.
4) (manager) stalls the j-th task where LCKj==1 andACQj==0.
5) (manager) returns the value of LCKi for a read access tothe member variable acquired from the i-th task/handler.

5

PROG.cfg

PROG1.c...

PROGk.cconfigurator

kernel_cfg.hkernel_cfg.h

TSKi_m.c

CYCi_m.c../include/*.h../target/dummy_gcc/*.h../arch/gcc/*.h../kernel/*.h../syssvc/*.hlib/*.c

ALMi_m.c

INTi_m.c

ACAP

top.v

manager.v

arbiter.v

mutex.v

TSKi.v

CYCi.v

ALMi.v

INTi.vFig. 4. Flow of system synthesis

6) (task/handler i) if acquired==1, then enters the criticalsection.
D. Flow of Synthesis
The tasks and handlers are compiled into register transfer
level hardware by high-level synthesis, while the manager andthe arbiter with the necessary number of ports are generated
by a script. All the other modules such as mutex units aremanually designed. The number of the tasks/handlers andnecessary mutexes are defined in the configuration file, so it
is extracted from the file.
V. P RELIMINARY R ESULT
A. Implementation
A prototype synthesis system based on the proposed method
has been implemented in Perl5 utilizing a high-level synthesizer ACAP [13].
ACAP synthesizes RTL hardware design in Verilog HDLfrom C programs via MIPS binaries. Namely, given C programs are compiled and linked into a binary executable file by
GCC, from which a CDFG (control dataflow graph), a popular
data structure for high-level synthesis, is constructed. With thisscheme, ACAP can synthesize original C codes of tasks andhandlers into hardware almost with no changes. Modern highlevel synthesizer such as Vivado HLS3 may be used instead,with a little modification on the source codes.
The flow of synthesis in the implemented system is shownin Fig. 4. The names and initial settings (such as the base priorities) of the tasks/handlers are extracted from the configuration
file PROG.cfg, and definition files kernel cfg.c, kernel cfg.hand the files containing main routines for tasks/handlers (suchas TASKi m.c)4 are generated. Those main files are compiled
with the body of the functions composed in PROG1.c, · · ·,3 https://www.xilinx.com/products/design-tools/vivado.html

4 ACAP requires one main function per one hardware module.

tasks. EXC TASK terminates the system by calling a service
call ext ker, after outputting a log.
The generated Verilog codes are synthesized by Xilinx Vivado (2016.4), targeting a Xilinx FPGA Artix-7(xc7a100tcsg324-3).
TABLE IV (a) shows the response performance of thesynthesized hardware in terms of the clock cycles and thelatency it took from the point where service call is made until
the status update is completed. For example, the first row(act tsk) indicates that it took 23 cycles to move the target
task from the dormant state to the ready state (it needs one
extra cycle to move the task to the running state). The updateof the state alone needs just 2 cycles; the other 21 cycles werespend for error checking (validity of the task id, etc.) and for
acquiring/releasing the mutex for service call serialization. The
latency is the product of the cycles and the critical path delayof the circuit which was 13.098ns. All the service calls were
processed less than a half micro second. Especially, activationof interrupt handler took just 1 cycle.
TABLE IV (a) (b) lists the size of each module in termsof the numbers of look-up tables (#LUT) and flip-flops (#FF).
For reference, a MIPS R3000 compatible processor core takes
about 3,200 LUTs. The sizes of top through mutex1 may bereasonable but those of TASK1 through INTNO1 are little toolarge. There seems to be a lot of room for optimizing the
hardware, which we would like to work on.

TABLE IVS YNTHESIS RESULT FOR sample1.
(a) Cycles and latency
service call#cycle latency [ns]act tsk
23
301.3
wup tsk
28
366.7
12
157.2
ext tskras ter26
340.5
ter tsk
23
301.3
16
209.6
slp tsk
loc mtx25
327.5
unl mtx
10
131.0
19
248.9
sta cycsta alm
20
262.0
interrupt113.1(b) Hardware size
module
#LUT
#FF
top
96
1
5,305
3,027
manager
arbiter573
10
mutex029
16
29
16
mutex1
MAIN TASK
5,382632
EXC TASK
4,703
399
5,320
950
TASK1
TASK2
6,620
649
TASK3
6,258
649
8,252
850
ALMHDR1
CLCHDR1
6,714
852
INTNO1
5,669
639
total
54,950 8,689
High-level synthesizer: ACAP (2016.10)
Logic synthesizer: Xilinx Vivado (2016.4)
Target: Xilinx Artix-7 (xc7a100tcsg324-3)

PROGk.c which are compiled by ACAP into hardware designs
in Verilog HDL. At the same time, Verilog HDL design for the
manager and the arbiter with the necessary number of ports,
and the necessary number of the mutexes are generated.
At this point, we have implemented 38 out of 178 service
calls of the TOPPERS/ASP3.
B. Synthesis Results
A hardware model is synthesized from sample1.c code bundled in the TOPPERS/ASP3 release. It consists of MAIN TSK
which controls the entire system, EXC TASK which handles
the CPU exception, three concurrent tasks TASK1, TASK2,
TASK3, cyclic, alarm, and interrupt handlers ALMHDR1,
CLCHDR1, INTNO1. The main task receives character datafrom a serial port that work for commands to the system,
which can test the following 22 service calls:
act tsk, can act, ter tsk, chg pri, chg pri, chg pri,get pri, wup tsk, can wup, rel wai, sus tsk, rsm tsk,
ras ter, rot rdq, rot rdq, rot rdq, sta cyc, stp cyc,sta alm, stp alm, loc cpu, and unl cpu.
The tasks do no particular processing but just write data into
the memory to indicate that they are running. The cyclic,
alarm, and interrupt handlers rotates the ready queue of thehighest priority to allocate CPU time to the the highest priority

6

VI. C ONCLUSION
We have presented a method of synthesizing full hardware
implementation of real-time systems using an RTOS. The
synthesized hardware is able to achieve very quick response.
Currently, the size of the synthesized hardware is little toolarge. We are now working on reduction of the redundancy of
the input source codes for high-level synthesis and optimization of the generated hardware. We are also considering theuse of commercially available high-level synthesizers.
Another issue is how to apply our method to source codesthat implement mutual exclusion using the fact that only one
task/handler is running at any point of time. One idea to solve
this problem is to provide an execution mode in which only
the tasks/handlers of the highest priority are executed, or only
one task/handler may run at the same time.
We are now also working on implementing other necessary
service calls of TOPPERS/ASP3 regarding event flags, data
queues, message buffers, etc. We are also planning to investigate the applicability of our method to other RTOSs such as
FreeRTOS5 .
Acknowledgment: We would like to thank to Mr. Takayuki
Nakatani who was with Ritsumeikan University, Mr. Masaharu
Yano who was with Kyoto University, Mr. Shimpei Tamura
who was with Kwansei Gakuin University and all the membersof Ishiura Lab. of Kwansei Gakuin University for their discussion and advice on this research. This work has been partly
supported by JSPS KAKENHI under Grant Nos. 16K00088,
16K01207, and 15H02680.
5 https://www.freertos.org

R EFERENCES[1] Youngchul Cho, Sungjoo Yoo, Kiyoung Choi, Nacer-Eddine Zergainoh,and Ahmed A. Jerraya: “Scheduler implementation in MPSoC design,” inProc. Asia and South Pacific Design Automation Conference (ASP-DAC
2005), pp. 151–156 (Jan. 2005) DOI:http//doi.org/10.1109/ASPDAC.
2005.1466148[2] Melissa Vetromille, Luciano Ost, Csar A. M. Marcon, Carlos Reif,and Fabiano Hessel: “RTOS scheduler implementation in hardware andsoftware for real time applications,” in Proc. International Workshop
on Rapid System Prototyping (RSP ’06) pp. 163–168 (June 2006).
DOI:http//doi.org/10.1109/RSP.2006.34[3] Paul Kohout, Brinda Ganesh, and Bruce Jacob: “Hardware support
for real-time operating systems,” in Proc. International Conference on
Hardware/Software Codesign and System Synthesis (CODES+ISSS ’03),
pp. 45–51 (Oct. 2003). DOI:http//doi.org/10.1145/944645.944656[4] Takumi Nakano, Yoshiki Komatsudaira, Akichika Shiomi, and Masaharu
Imai: “Performance evaluation of STRON: A hardware implementationof a real-time OS,” in IEICE Trans. Fundamentals, vol. E82-A, no. 11
pp. 2375–2382 (Nov. 1999). DOI:http//doi.org/[5] Naotaka Maruyama, Tohru Ishihara, and Hiroto Yasuura: “An RTOS
in hardware for energy efficient software-based TCP/IP processing,” inProc. IEEE Symposium on Application Specific Processors (SASP 2010),
pp. 58–63 (June 2010).
[6] Carl Stenquist: “HW-RTOS—Improved RTOS performance byimplementation in silicon,” White Paper—Renesas R-IN32M3
Industrial Network ASSP (May 2014). Available at available athttps://www.renesas.com/en-us/media/support/partners/r-in-consortium/
technology/R-IN32 HWRTOS Whitepaper 5 20 14.pdf(accessed
2018-06-11).
[7] Seiya Shibata, Shinya Honda, Hiroyuki Tomiyama, and Hiroaki Takada:“Advanced system-builder: A tool set for multiprocessor design space exploration,” in Proc. International SoC Design Conference (ISOCC 2010),
pp. 79–82 (Nov. 2010). DOI:http//doi.org/10.1109/SOCDC.2010.5682967[8] Yuki Ando, Shinya Honda, Hiroaki Takada, Masato Edahiro: “Systemlevel design method for control systems with hardware-implemented
interrupt handler,” IPSJ Journal of Information Processing, vol. 23, no. 5,
pp. 532–541 (Sept. 2015). DOI:http//doi.org/10.2197/ipsjjip.23.532[9] Naoya Ito, Nagisa Ishiura, Hiroyuki Tomiyama, and Hiroyuki Kanbara:“High-level synthesis from programs with external interrupt handling,” inProc. Workshop on Synthesis And System Integration of Mixed Information Technologies (SASIMI 2015), 10–15 (March 2015).
[10] Naoya Ito, Yuuki Oosako, Nagisa Ishiura, and Hiroyuki Tomiyama,and Hiroyuki Kanbara: “Binary synthesis implementing external interrupt handler as independent module,” in Proc. International Symposiumon Rapid System Prototyping (RSP 2017), pp. 92–98 (Oct. 2017).
DOI:http//doi.org/10.1145/3130265.3130317[11] ITRON Committee, TRON association: µITRON4.0 Specification (1999,
2002). Available at http://www.ertl.jp/ITRON/SPEC/FILE/mitron-400e.
pdf (accessed 2018-06-11).
[12] Daniel D. Gajski, Nikil D. Dutt, Allen C-H Wu, and Steve Y-L Lin:
High-Level Synthesis: Introduction to Chip and System Design, Kluwer
Academic Publishers (1992).
[13] Nagisa Ishiura, Hiroyuki Kanbara, and Hiroyuki Tomiyama: “ACAP:
Binary Synthesizer Based on MIPS Object Codes,” in Proc. ITC-CSCC
2014, pp. 725–728 (July 2014).

7