一般社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATIONAND COMMUNICATION ENGINEERS
社団法人 電子情報通信学会

信学技報
IEICE Technical Report
VLD2019-70,CPSY2019-68,RECONF2019-60(2020-01)
信学技報
TECHNICAL REPORT OF IEICE.

THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS

FreeRTOS を用いたシステムのフルハードウェア合成
中野和香子†

石浦菜岐佐†

冨山

宏之††

神原

弘之†††

† 関西学院大学 理工学部 〒 669–1337 兵庫県三田市学園 2–1†† 立命館大学 理工学部 〒 525–8577 滋賀県草津市野路東 1 丁目 1–1††† 京都高度技術研究所 〒 600–8813 京都市下京区中堂寺南町 134 番地
あらまし

組込みシステムには益々高い機能が実装される一方で厳しい応答性能が要求される. これを解決する一手法として , 大迫らは RTOS 上で動作するプログラムを入力として, RTOS の機能とカーネルオブジェクト全てをハードウェアに合成する手法を提案している. この手法では RTOS として TOPPERS/ASP3 を想定していたのに対し,本稿では同じ手法を FreeRTOS に対応させる手法を提案する. FreeRTOS カーネルではタスクは動的に生成され, タスクの制御用データは線形リストで管理されるが, 本手法ではスケジューラ起動前にタスク生成を行なっているプロ
グラムに対象を限定し, タスク制御用データは配列で管理するようにシステムコールを修正する. ソフトウェアタイ
マー機能はデーモンタスクではなく, 各タスクにタイマーを持たせる形に変換する. 本手法に基づく合成システムを実装し, FreeRTOS 付属のデモプログラム main full.c を縮小したテストプログラムで, タスク機能のテストと , ソフト
ウェアタイマーの評価部分をハードウェア実装した結果, タスクの起動を 19 サイクル, 割込みハンドラの起動を 1 サ
イクルで行えることが確認できた .
キーワード

リアルタイムシステム, RTOS, システム合成, ハードウェアアクセラレータ, FreeRTOS, 高位合成

Full Hardware Synthesis of FreeRTOS-Based Systems
Wakako NAKANO† , Nagisa ISHIURA† , Hiroyuki TOMIYAMA†† , and Hiroyuki KANBARA†††† Kwansei Gakuin University, Gakuen 2–1, Sanda, Hyogo, 669–1337, Japan†† Ritsumeikan University, 1–1–1 NojiHigashi Kusatsu, Shiga, 525–8577, Japan††† ASTEM RI/KYOTO, 134 Chudoji Minamimachi, Shimogyo–ku, Kyoto, 600–8813, Japan
Abstract As higher and higher functionalities are being implemented in embedded systems, it is becoming a diﬃcult task to ensure their real-time performance. As one approach to enhancing response performance of RTOS-based
systems, Oosako proposed a method of implementing both kernel objects and RTOS functionalities as hardware
utilizing high-level synthesis, where TOPPERS/ASP3 was assumed as an RTOS. This article extends this method
to deal with systems based on FreeRTOS. In FreeRTOS, tasks are generated dynamically, whose control data aremanaged in the form of linear lists. We limit ourselves with systems where tasks are generated before scheduler
starts, and keep the task control data in an array. Software timers are dealt with as tasks that have their own
timers. We have implemented a prototype synthesis system and synthesized a reduced version of a demo program
main full.c bundled with FreeRTOS. Resulting hardware took 19 cycles and 1 cycles for activation of a task and ahandler, respectively.
Key words Real-Time Systems, RTOS, System Synthesis, Hardware Accelerator, FreeRTOS, High-Level Synthesis
れる.

1. は じ め に

このようなリアルタイムシステムには, 制限時間内にタスク

近年の情報通信技術の発展によって, 新しいサービス, 機器が処理の実行を完了するリアルタイム性が必要であるが, そのた

提供されるようになっており, 組込みシステムには益々高い機

めにはリアルタイム OS (RTOS) を用いた開発が不可欠であ能が要求されるようになっている. 特に, 車載機器, 自律飛行機,

る. RTOS はタスクの実行時間を制御するための機能を備えてロボットの制御には, 高い機能と同時に高い応答性能が要求さいるが, システムの複雑化に伴って, このリアルタイム性の実現- 105 -

—1—
This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere.
Copyright ©2020 by IEICEIMEM
TSK1 ... TSKn

CYCi
RTOS

ALMi

2. RTOS を用いたシステムのフルハードウェ
ア実装

INTi

2. 1 TOPPRES/RSP3 を用いたシステムのフルハード

CPU

ウェア実装

DMEM

RTOS は複数の逐次処理を並列に動作させるが, この実行単位をタスクと呼ぶ. TOPPERS/RSP3 は時間を管理する機能

HW
TSK1 ... TSKnとして, 特定の周期で実行される周期ハンドラと, 指定時間の経

CYCi

ALMi

過後に実行されるアラームハンドラを持つ. 割込みハンドラは

INTi

割込み信号もしくはイベントにより起動される.

manager
arbiter

文献 [12] では, TOPPERS/ASP3 のサービスコールを用いたプログラムを入力とし, これを実行するプロセッサと機能等価

DMEM

なハードウェアの合成を提案している. その概念を図 1 に示す.

図 1: RTOS を用いたシステムのフルハードウェア実装

上方の TSKi, CYCi, ALMi, INTi はそれぞれのタスク, 周期ハンドラ, アラームハンドラ, 割込みハンドラであり, RTOS の管は難しくなってきている.

RTOS を用いたシステムの高速化手法として, RTOS 機能のハードウェア実装がある. 文献 [1] [2] [3] では, ハードウェアにより RTOS のスケジューラの高速化を行っている. また, 文
献 [4] [5] [6] では RTOS のほとんどの機能をハードウェア実装
している. しかし, これらの手法では, タスクやハンドラなど
はソフトウェアのままであり, プロセッサのタスク切り替えのオーバーヘッドが発生する. また, タスクの処理の負荷が大きい場合は他タスクの実行待ち遅延により, 応答時間が改善されない場合もある.
一方, 高位合成技術 [7] を用いることにより, タスクを専用
ハードウェアに合成し, 高速化する手法がある. 指定したタスクをハードウェアに合成するためのシステムレベル設計手法 [8] [9]が提案されているが, これらの手法では, RTOS および一部のタスクはソフトウェアとして実行される. 文献 [10] [11] は割込
みハンドラを含むシステム全体のハードウェア化を行っているが, 合成対象はベアメタルシステムのみである.
この課題を解決する一手法として, 文献 [12] はタスクおよび

RTOS のサービスコールの機能全てをハードウェアに合成する手法を提案している. しかし現時点でこの手法が適応可能な

RTOS は TOPPERS/ASP3 に限定されている.
本稿では, FreeRTOS と TOPPERS/ASP3 の仕様の違いを明らかにし, 文献 [12] の手法を, FreeRTOS に適応させる手法
を提案する. 本手法ではスケジューラ起動前にタスク生成を行なっているプログラムに対象を限定し, タスク制御用データは配列で管理するようにシステムコールを修正する. ソフトウェア
タイマー機能はデーモンタスクではなく, 各タスクにタイマーを持たせる形に変換する.
本手法に基づき, FreeRTOS のサービスコールを利用して記述された C 言語のプログラムから, Verilog HDL で記述されたハードウェア動作記述を生成するための合成システムを実装し理下で実行される. この手法では, 各タスク/ハンドラは独立したハードウェアモジュールに合成され, RTOS 機能は managerと arbiter というハードウェアが実現する.
タスク/ハンドラは, 実行可能になれば全て並列に実行する.
この制御は manager が各タスク/ハンドラの状態変数の値から
タスク/ハンドラの実行/停止を制御する信号を生成することにより行う. データメモリ (DMEM) の同じバンクに同時にアクセスがあった場合には, 優先度に応じて arbiter が調停を行う.
スケジューリングやコンテキストスイッチ, および CPU 待ちのオーバーヘッドがなくせる上, タスク/ハンドラをハードウェ
ア化して高速実行できるため, システムの応答性能を飛躍的に向上させることができる.
合成されるハードウェアの構成を図 2 に示す. 各タスク/
ハンドラの状態は, manager モジュール内の status レジスタに, カーネルの状態は global status レジスタに格納される.

manager モジュールは, status レジスタの値に基づき, そのタ
スク/ハンドラが実行可能な場合には stall 信号を 0 に, 実行を停止させる場合には stall 信号を 1 にすることにより, タスク/
ハンドラの実行を制御する. 周期ハンドラとアラームハンドラ
は, それぞれが status レジスタ内部にタイマー (カウンタ) を持ち, 実行条件が成立すると manager が stall 信号を 0 にす
る. 割込みハンドラは, manager への IRQ 信号によって起動される. IRQ 信号が送られた時, 割込みが禁止されていなければ, 割込みハンドラへの stall が解除され, ハンドラが起動する.

RTOS のサービスコールの大部分は status レジスタと global
status レジスタを参照/更新する処理として実装できる. status
レジスタと global status レジスタは, メモリ空間にマップし,タスク/ハンドラからはメモリアクセスによって参照/更新でき
る. ロックの取得/解放などの処理は, ハードウェアにより実装
する.

2. 2 FreeRTOS と TOPPERS/ASP3

た. 予備実験では, タスクの起動が 19 サイクル, 割込みハンド
ラの起動が 1 サイクルで行えることを確認した.

TOPPERS/ASP3 と FreeRTOS はいずれもプリエンプティ
ブなスケジューリングを行う RTOS であるが, 仕様には相違点がある.

TOPPERS/ASP3 では, 全てのタスクやハンドラの生成は静的であり, コンパイル時に決定している. これに対し FreeRTOS- 106 -

—2—

arbitermanager
pri
addr
data

addr
data

addr
data
pri

local
mem

addr
data

状態名
Ready

TSK1
Running

pri
local
mem

(a) タスクにおける状態

stall, reset

addr
data

addr
data

task
statuscyclicstatusstall, reset
addr
data

...

local
mem

addr
data

task
status

表 1: FreeRTOS における状態

Blocked

TSKn

SuspendPendingReadystall, reset
addr
data

意味
タスク自身は実行できる状態にあるが, それよりも優先順
位の高いタスクが実行状態にあるために, そのタスクが実行されない状態
タスクが実行されている状態. (タスクの実行中に発生した
割込みまたは例外処理中かつ, タスクコンテキストに戻った後に, そのタスクの実行を再開する状態を含む)
タスクが何らかの条件が揃うのを待つために, 自ら実行を止めている状態
強制的に実行を止められている状態
スケジューラ停止時にタスク起動がかかり, タスクがスケ
ジューラ起動を待っている状態.

(b) ソフトウェアタイマーにおける状態
状態名
Dormant

CYCi

Running

意味
ソフトウェアタイマーは休止中であり, 参照はできるが,そのソフトウェアタイマーは実行されない状態
ソフトウェアタイマーが実行されている状態

end
pri
local
mem

addr
data

addr
data

pri
local
mem

addr
data

addr
data

alarm
statusint
status

表 2: 実行制御と排他制御のためのサービスコール

stall, reset
addr
data

(a) タスク実行制御
サービスコール

機能

xTaskResume

指定したタスクを起床する

vTaskSuspend

指定したタスクを強制待ちにする.

end

vTaskDelay

自タスクを起床待ちさせる

stall, reset

vTaskSuspendAll

ディスパッチ禁止しスケジューラを停止する

xTaskResumeAll

ディスパッチ禁止を解除する

ALMi

addr
data

(b) ソフトウェアタイマー機能

endglobalmem

指定したタスクの優先度を設定する

vTaskPrioritySet

INTi

addr
data

globalstatus

サービスコール

機能

xTimerStart

指定した時間, 自タスクを待ち状態にし, 遅延させる

xTimerStop

自タスクを終了させる

xTimerReset

指定したタスクに終了要求を行う

mutex
mutex

IRQ
行するプロセッサと機能等価なハードウェアの動作記述を自動

図 2: 合成されるハードウェアの構成

合成する手法を提案する.
本手法では一つのカーネルオブジェクトを一つのハードウェ

ではカーネルオブジェクトは静的にも動的にも生成可能であり, タスク, ソフトウェアタイマーなどはスケジューラ起動前
だけでなく, 起動後にも生成が可能である. このためタスク管理のデータ構造は TOPPERS/ASP3 が配列であるのに対し,FreeRTOS は線形リストである.

アモジュールに合成するため, カーネルオブジェクトの生成は静的なものに限定する. すなわち, 全てのカーネルオブジェク
トは main 関数内でスケジューラが起動する前に生成されていることを前提とする. またタスク管理のデータ構造はリストか
ら配列に変更し, サービスコールの中でこのデータ構造にアク時間管理機能は, TOPPERS/ASP3 は周期ハンドラ, アラー
ムハンドラがその機能を担うが, FreeRTOS はソフトウェアタ
イマーが同様の機能を担う. 周期ハンドラ, アラームハンドラ

セスしている部分は全て書き換える. ソフトウェアタイマーは
文献 [12] における周期ハンドラ, アラームハンドラの機能を統合したハードウェアに合成する.

は非タスクコンテキストで実行されるのに対し, ソフトウェア

3. 1 TCB の管理

タイマーは, デーモンタスクと呼ばれるタスクコンテキストで実行される. また, ソフトウェアタイマーには将来の設定した時刻に関数を実行するワンショットタイマー, また一定周期での関数の実行を管理する自動再ロードタイマーの 2 つのモードがあり, それぞれアラームハンドラ, 周期ハンドラの機能に対応している. しかし, ソフトウェアタイマーは起動後にモードの切り替えが可能である.

FreeRTOS の各タスクは, 表 1 (a) の 5 つのうちいずれかの状態をとる. タスク管理を行うデータ構造はタスク制御ブロック (TCB) と呼ばれる. FreeRTOS は状態ごとに線形リストを持ち, タスク状態に対応したリストにそのタスクの TCB をつなぐことによりタスクを管理する. リストによるタスクの管理を図 3 に示す. Task1, Task2, Task5 が Ready 状態の場合, その TCB は, ReadyList につなぐ. 各 TCB はリストのヘッダへのポインタを持っており, これによって自分の状態を知ること

3. FreeRTOS を用いたシステムからの合成ができる. 状態の変更はリストのつなぎ替えにより行う. 図 3
本稿では文献 [12] の手法に基づき, FreeRTOS のサービスにおいて Task1 の状態を Ready から Suspend に変更する場

コールを用いて書かれた C プログラムを入力として, これを実合には, Task1 の TCB を Ready List から外し, Suspend List

- 107 -

—3—

信号を解除する.

表 3: 状態変数

タスクの状態の管理と stall 信号の生成をハードウェアで行(a) タスクの状態変数
変数

意味

xStatexStateValueuxPriority
uxBasePriority
ulNotifiedValueucNotifyState
pcTaskName
uxMutexesHeld
uxCriticalNesting

現在の実行状態
待ち時間
優先度
ベース優先度
タスク通知値
タスク通知状態
タスク名
ミューテックス取得フラグ
クリティカルセクションのネスト数

うために, 本手法では表 3 (a) に示す TCB の 9 個のメンバの
うち manager の制御に必要な 6 個のメンバを manager 内のstatus レジスタに保持し. それ以外はメモリに置く. status レ
ジスタはメモリ空間にマッピングし, タスクモジュールからはメモリのロード/ストア命令でアクセスできるようにする. また, システム全体の状態は manager 内部の global status レジ
スタに保持し, タスクモジュールの制御に使用する.
表 2 はタスク, ソフトウェアタイマーの状態制御に関する主(b) ソフトウェアタイマーの状態変数
変数

意味

ucStatus
xTimerState
xTimerPeriodInTicks
xTimerBasePeriod
flgReset*pcTimerName*pvTimerID

タイマーのモード
実行状態
通知時刻までの相対時間
タイマー設定時間
タイマリセットフラグ
タイマー名
タイマー ID

要なサービスコールである. 例えば, vTaskSuspend は指定した TCB へのポインタに対応するタスクを Suspend 状態に遷移させる. FreeRTOS の殆どのサービスコールは status レジ
スタの参照/更新処理として実装できる.

TCB の管理を配列に変更したことに伴い, タスクの状態変
更を変更する FreeRTOS のサービスコールのコードは全て書き換える. ユーザコードの変更は一切必要ない. 例えば, Sus-pend 状態にあるタスクを Ready 状態にするサービスコール
vTaskResume は図 5 のように書き換える. 11 行目のコードにより status レジスタが Ready 状態に変更できる. 3 行目はエラーチェックであり, 7, 14 行目はサービスコールをシリアライ
ズするのロックの取得/開放処理である.

3. 3 ソフトウェアタイマーの実装
ソフトウェアタイマーは, FreeRTOS において設定した時刻における関数の実行, または一定周期での関数の実行を管理する機能であり, デーモンタスクと呼ばれる 1 個のタスクのコン
テキストでその処理を行う. ソフトウェアタイマーは, 表 1 (b)図 3: 線形リストによるタスク管理の 2 つのうち, どちらかの状態をとる.
本稿の手法では, ソフトウェアタイマーが管理する各コール
バック関数を高位合成で一つハードウェアモジュールに合成す
る. 各モジュールはタイマーの状態をタスク同様に manager モ

図 4: 配列によるタスク状態の変更

ジュール内の status レジスタに格納し, manager は status レ
ジスタの値を基に stall 信号でモジュールの実行/停止を制御すにつなぐ.

る. manager のレジスタには, 表 3 (b) の 7 個のメンバからな

本稿の手法ではこのデータ構造を変更し, 各タスクの TCB
を配列で保持するようにする. また各 TCB のメンバにはリス
トヘッダへのポインタではなく, タスクの状態を直接持たせる
ようにする. 図 4 に本稿の TCB 保持法と状態変更の処理例をるタスクの状態変数のうち manager の制御に必要な 5 個のメンバのみを保存する. ソフトウェアタイマーはワンショットタ
イマー, 自動再ロードタイマーの２つのモードの切り替えが可能であるため, manager はモードを保持するレジスタを持つ.

示す. Task1 の状態を Ready から Suspend に変更する場合にタイマーの具体的な動作は以下の通りである.

は, 単に Task1 の TCB のタスク状態を Ready から Suspend

1) (task) xTimerStart を呼ぶ.

に変更するだけである.

xTimerState, flgReset に 1 をセットする.

3. 2 タスクの実行管理

2) (manager) flgReset が 1 な ら ば xTimerPeriod-

タスクへの stall 信号は Running 状態の時のみ 0 とし, その

InTicks に xTimerBasePrtiod の値をセットする.

他の状態 (Ready, Blocked, Suspend, PendingReady) の時は

flgReset を 0 に戻す.

1 とする. ただし, Running 状態であってもメモリアクセス要
求が待たされている場合には stall 信号を 1 とする. この stall3) (mamager) xTimerPeriodInTicks を デ ク リ メ ン ト
する.

信号の管理は manager モジュールが行う.

4) (manager) xTimerPeriodInTicks が 0 なら stall を 0

本稿の手法で合成するハードウェアでは, Ready になったタにする.

スクは全て実行される. これは, Ready になったタスクの状態
を manager が強制的に Running に書き換えることにより実現する. すなわち, あるタスクが Ready 状態になると, manager
は次のクロックでタスクの状態を Running 状態に更新し, stall- 108 -

コールバック関数の処理を実行する.

5) (timer) 実行が完了すれば, end 信号を 1 にする.
6) (manager) 信号が 1 ならば, reset を 1 にする.
自動再ロードタイマーの場合は xTimerPeriodInTicks

—4—

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

表 4: 合成結果

void vTaskResume ( TaskHandle_t xTaskToResume ){TCB_t * const pxTCB = xTaskToResume ;configASSERT ( xTaskToResume );if ( pxTCB - > xState != eRunning && pxTCB != NULL ){_lo c_s erv i ce _ca ll ();{if ( p r v T a s k I s T a s k S u s p e n d e d ( pxTCB ) != pdFALSE ){pxTCB - > xState = eReady ;}}_un l_s er v ice _ ca ll ();}}(a) 実行サイクル数と遅延
service call...

latency
[ns]

19
14
23
13
15
24
13
14
14
1

272.6
200.9
330.0
186.5
215.2
344.4
186.5
200.9
200.9
14.3

xTaskResume
vTaskSuspend
vTaskDelayvTaskSuspendAll
xTaskResumeAllvTaskPrioritySet
xTimerStart
xTimerStop
xTimerResetinterrupt

図 5: vTaskResume
PROG1.c#cyclePROGk.cdelay = 14.349 [ns]実行開始から状態が変化するまでを測定(b) 回路規模
configurator

kernel_cfg.hkernel_cfg.h

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

moduleTIMi_m.c

INTi_m.clib/*.cACAPkernel_cfg.vh

top.v

manager.v

arbiter.v

lock.v

TSKi.vTIMi.v

INTi.v

図 6: 合成の流れ

#LUT

#FF

top
manager
arbiter
lock0
lock1

129
3,566
652
27
27

1
2,440
9
18
18

LIM INC
CNT INC
C CTRLTmr TstAT TMR1
AT TMR2
ONE TMR1
ISRONR TMR1
ISR OS

5,319
6,829
7,060
9,133
7,321
7,009
7,619
2,471
3,566

367
425
556
619
426
426
394
10
10

total

62,006

5,717

High-level synthesizer: ACAP (2016.10)
Logic synthesizer: Xilinx Vivado (2018.3)
Target: Xilinx Artix-7 (xc7a100tcsg324-3)に xTimerBasePrtiod の値をセットする.
ワンショットタイマーなら タイマー状態を Dormantにする.

4. 実装と実験

7) (manager) 3 に戻る
3. 4 全体の合成

4. 1 実本手法で提案する合成の流れを図 6 に示す. 図の右上方のPROG1.c, ..., PROGk.c が入力となるシステムを構成するプログラムである. まず, システムの main 関数内で呼ばれる
カーネルオブジェクト生成のサービスコールおよびその引数から各種カーネルオブジェクトの構成情報を得る. 例えば,

vTaskSuspend というタスク生成のサービスコール引数から,タスクの関数名, タスク名, タスクのベース優先度, タスクハン
ドルの変数名を取得する. これらの情報から, C の定義ファイ
ル kernel cfg.c, kernel cfg.h, およびレジスタの構成を記述した

kernel cfg.vh を作成する. また, 各タスク, ソフトウェアタイ
マーのトップ関数を含む C ファイル (TASKi m.c) を生成する.
これらのソースコードおよびアプリケーションプログラムから, 高位合成システムを用いて必要なハードウェアを合成する.

manager や arbiter などのシステム構成によってポート数が変わるモジュールの RTL 記述もシステム構成情報に基づいて生成する.

装

本稿の提案手法に基づく合成システムを Perl5 で実装した.
合成システムには ACAP [14] を用いた. ただし現時点では,ヘッダーファイル kernel cfg.c, kernel cfg.h, kernel cfg.vh は自動生成ではなく手で記述している.

ACAP は, C プログラムもしくは MIPS R3000 の機械語プ
ログラムを入力として, これを 32bit の整数演算命令を並列に実行可能なハードウェアに変換する. まず, 入力となるプログラ
ムは GCC を用いてコンパイル/リンクされる. 得られた MIPSの機械語プログラムを CDFG (control dataflow graph) に変換し, 最適化, スケジューリング, バインディングの処理を施して, Verilog HDL を生成する. これにより ACAP は, C プログ
ラムの修正なしに, タスク, 時間管理機能を CPU と機能等価なハードウェアに合成できる. Vivado HLS（注 1） などの高位合成システムの場合でも, ソースコードへ少しの修正を加えること
により同様に合成することが可能であると考えられる.
現時点で, FreeRTOS のサービスコール 132 個中 23 個を実装している.

（注 1）：https://www.xilinx.com/products/design-tools/vivado.html- 109 -

—5—

4. 2 実 験 結 果

また, イベントフラグ, データキュー, セマフォ等に関わる

本 シ ス テ ム に よ り FreeRTOS 付 属 の デ モ プ ロ グ ラ ム

FreeRTOS の他のサービスコールの実装も今後の課題である.

“main full.c” をハードウェア化した. このプログラムは, 機能謝ごとのテストを行うもので, 今回はタスクとソフトウェアタイ

辞本研究に関して有益な御助言を頂いた元立命館大学の中谷嵩之氏, 元マーの機能テストのみに縮小している.
タスク機能のテストは, 共有変数の値をインクリメントする
タスク LIN CNT, CNT INC と, その 2 個のタスクを制御する

関西学院大学の田村真平氏に感謝致します. 本研究は一部 JSPS 科研
費 19H04081 および 15H02679 の助成による.

タスク C CTRL の 3 個のタスクからなる. ソフトウェアタイ文

マー機能のテストはタイマーを作成するタスク Tmr Tst, 2 個のオートリロードタイマー FR Timer, ワンショットタイマー

Oneshot Timer, 割込みサービスルーチン ISR OS, 割り込み
サービスルーチンから起動される ISRONE TMR1 からなる.
生成した Verilog HDL は, 論理合成ツール Xilinx Vivado

2018.3 によって, Xilinx FPGA Artix-7 (xc7a100tcsg324-3) をターゲットに論理合成した.
合成したハードウェアにおける応答性能を表 4 (a) に示す.

#cycle, latency はそれぞれ, 各サービスコールが呼ばれてから状態が更新されるまでの実行サイクル数, 時間を表す. 例えば,

1 行目の xTaskResume は, タスクを強制待ち状態から実行可能状態に遷移させるまでに 19 サイクル要したことを表す. (そして次のサイクルで実行状態に遷移する.) このうち, 状態の更新に要するのは 1 サイクルであり, それ以外の 18 サイクルは
エラーチェックやシリアライズのためのロック取得/開放処理に費やしている. latency は実行サイクル数とクリティカルパス
遅延 14.880 ns の積である. いずれのサービスコールも 357.12

ns 以内に実行することができた. また, 割込みハンドラの起動
は 1 サイクルで行うことができた.
表 4 (b) は各ハードウェアモジュールの回路規模を示す.

#LUT はルックアップテーブル数, #FF はフリップフロップ数である. manager モジュールの回路規模は文献 [12] に比べ小さくなっているが, これは manager モジュール内のカーネルオ
ブジェクト情報を保持するレジスタを manager モジュールの制御に関するもののみに削減したためである.

MIPS R3000 互換のソフトコアプロセッサの回路規模が約
3200 LUT であるため, 高位合成により生成したタスク, 時間
管理機能の回路規模はやや大きいといえる. これについては,
ハードウェアの最適化の余地があると考えられる.

5. む す び
本稿では, FreeRTOS のサービスコールを用いたシステムをハードウェアに自動合成する手法を提案した. 本手法により生成されたハードウェアは, 応答性能を大きく向上させていると考えられる.
現在, 生成したハードウェアの回路規模がやや大きいため, 高位合成の入力となるソースコードの改善, 生成されるハードウェ
アの最適化を進めている. また, Vivado HLS などの汎用の高位合成システムを用いることも検討している.
他の課題として, 複数のタスクが同時に実行されないことを献[1] Y. Cho, S. Yoo, K. Choi, N-E Zergainoh, and A. A. Jerraya: “Scheduler implementation in MPSoC design,” inProc. ASP-DAC 2005, pp. 151–156 (Jan. 2005)[2] M. Vetromille, L. Ost, C. A. M. Marcon, C. Reif, and F. Hessel: “RTOS scheduler implementation in hardware and software for real time applications,” in Proc. RSP ’06 pp. 163–168 (June 2006).
[3] P. Kohout, B. Ganesh, and B. Jacob: “Hardware support
for real-time operating systems,” in Proc. CODES+ISSS’03, pp. 45–51 (Oct. 2003). DOI:http//doi.org/10.1145/
944645.944656[4] T. Nakano, Y. Komatsudaira, A. Shiomi, and M. Imai:“Performance evaluation of STRON: A hardware implementation of a real-time OS,” in IEICE Trans. Fundamentals,
vol. E82-A, no. 11 pp. 2375–2382 (Nov. 1999).
[5] N. Maruyama, T. Ishihara, and H. Yasuura: “An RTOS in
hardware for energy eﬃcient software-based TCP/IP processing,” in Proc. SASP 2010, pp. 58–63 (June 2010).
[6] C. Stenquist: “HW-RTOS—Improved RTOS performanceby implementation in silicon,” White Paper—Renesas RIN32M3 Industrial Network ASSP (May 2014). Available
at available at https://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] D. D. Gajski, N. D. Dutt, A. C-H Wu, and S. Y-L Lin: HighLevel Synthesis: Introduction to Chip and System Design,
Kluwer Academic Publishers (1992).
[8] S. Shibata, S. Honda, H. Tomiyama, and H. Takada: “Advanced system-builder: A tool set for multiprocessor design
space exploration,” in Proc. ISOCC 2010, pp. 79–82 (Nov.
2010).
[9] Y. Ando, S. Honda, H. Takada, M. Edahiro: “Systemlevel design method for control systems with hardwareimplemented interrupt handler,” IPSJ Journal of Information Processing, vol. 23, no. 5, pp. 532–541 (Sept. 2015).
[10] N. Ito, N. Ishiura, H. Tomiyama, and H. Kanbara: “Highlevel synthesis from programs with external interrupt handling,” in Proc. SASIMI 2015, 10–15 (March 2015).
[11] N. Ito, Y. Oosako, N. Ishiura, and H. Tomiyama, and H.
Kanbara: “Binary synthesis implementing external interrupt handler as independent module,” in Proc. RSP 2017,
pp. 92–98 (Oct. 2017).
[12] Y. Oosako, N. Ishiura, H. Tomiyama, and H. Kanbara:“Synthesis of Full Hardware Implementation of RTOSBased Systems,” in Proc. RSP 2018, pp. 1–7 (Oct. 2018).
[13] 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).
[14] N. Ishiura, H. Kanbara, and H. Tomiyama: “ACAP: Binary Synthesizer Based on MIPS Object Codes,” in Proc.
ITC-CSCC 2014, pp. 725–728 (July 2014).

前提にした排他制御を行っているプログラムからの合成が挙げられる. 解決手法としては, 最も高い優先度を持つタスクのみを動作させるモードを導入することを検討している.

- 110 -

—6—