DAシンポジウム
Design Automation Symposium

DAS20222022/8/31

RTOS 利用システムのフルハードウェア化における管理ハードウェアの自動生成
南口 比呂1,a)

石浦 菜岐佐1

冨山 宏之2

神原 弘之3

概要：本稿では, RTOS を利用したシステムのフルハードウェア化において, RTOS の機能を提供するハードウェアの自動生成を行う. 六車・安堂らはリアルタイムシステムのタスクおよび RTOS の機能を全てハードウェア実装する手法を提案しているが, RTOS の機能を提供する管理ハードウェアは Verilog HDL
で手動設計している. 本稿では, 設計対象のシステムの構成情報を記述したコンフィギュレーションファ
イルからこの管理ハードウェアを自動生成する. 使用する RTOS に依存する機能の情報をコンフィギュ
レーションファイルに記述することにより複数の RTOS に対応する. また, RTOS のサービスを提供する
モジュールにおいて使用されない機能に対する記述の生成を省くことにより回路規模の削減を図る. 提案のシステムを Perl5 で実装した結果, TOPPERS/ASP3 および FreeRTOS それぞれの仕様に応じた管理
ハードウェアを自動生成できた. タスク数 4, 8, 16 のシステムについてハードウェアを合成した結果, 回路
規模と遅延はそれぞれ概ねタスク数とその対数に比例して増加した.
キーワード：システム設計技術, リアルタイムシステム, RTOS, ハードウェア実装

Automatic Generation of Management Hardware
for Full Hardware Implementation of RTOS-Based Systems
Minamiguchi Hiro1,a)Ishiura Nagisa1

Tomiyama Hiroyuki2

Kanbara Hiroyuki3

Abstract: This article presents an automatic scheme for generating hardware that provides RTOS’s functions for full-hardware implementation of RTOS-based systems. Though Muguruma and Ando et al. haveproposed a method for implementing both tasks of a real-time system and RTOS functions as hardware,
the manager hardware to provide RTOS functions was designed manually in Verilog HDL. In our method,
the manager hardware is automatically generated from a file that describes the configuration of the target
system. Manager hardware for diﬀerent RTOSes can be generated by describing RTOS dependent attributes
in the configuration file. Generation of RTL description for unused function is omitted, which reduces thesize of the resulting hardware. A prototype system based on the proposed method has been implemented in
Perl5, which successfully generated manager hardware modules for 4 tasks for both TOPPERS/ASP3 and
FreeRTOS. Manager hardware modules for 4, 8, and 16 tasks have also been generated, which suggests thecircuit size and the critical path delay increases in proportion to the number of tasks and their logarithms,
respectively.
Keywords: System design technology, Real-Time Systems, RTOS, Hardware Implementation

1

2

3

a)

関西学院大学
Kwansei Gakuin Univ.
立命館大学
Ritsumeikan Univ.
京都高度技術研究所
ASTEM RI/KYOTO.
gtu14556@kwansei.ac.jpⓒ 2022 Information Processing Society of Japan

1. はじめに
近年の情報通信技術の発展により, 日々様々な新しいサービスやデバイスが開発されつつあるが, これに伴って組み込みシステムには益々高い機能が要求されるようになって83

DAシンポジウム
Design Automation Symposium

いる. 特に, 車載機器や無人航空機の制御では機能性に加DAS20222022/8/31

TSK1

えて高い応答性能も要求される. このようなリアルタイム
システムの設計, 開発はリアルタイム OS (RTOS) を用い

TSK2 TSK3 ... TSKn
RTOS
CPU

て行われる. RTOS は決められた期限内に処理を完了する
DMEM

リアルタイム性の実現をサポートする機能を提供するが,システムの高機能化・複雑化に伴う処理量の増加によりリ
アルタイム性の実現が困難になりつつある.

HW
TSK1

TSK2

TSK3 ... TSKn

RTOS を用いるシステムの応答性能を向上させる一手

manager法として, RTOS 機能のハードウェア化が提案されている.

DMEM

文献 [1], [2] は, RTOS のスケジューリング機能をハードウェア化し, 文献 [3], [4] は RTOS の機能の大部分をハード

図 1: RTOS 利用システムのフルハードウェア実装 [5]

ウェア化することによりシステムの応答性能の向上を図っている. しかし, タスク/ハンドラはソフトウェアであるた

ハードウェア化する手法を提案している. その概念を図 1

め, タスク切り替えの際にコンテキストスイッチのオーバに示す. 上図はソフトウェアシステムによる実装であり,ヘッドが発生する課題がある.

タスク (TSKi) は RTOS の管理下で実行される. 下図はこれに対し, 文献 [5] は RTOS の機能とタスク/ハンドラ

上図のシステムを全てハードウェア化したものである. 各の全てをハードウェア実装することにより, タスク数があTSKi は独立したハードウェアモジュールとなり, RTOS

まり多くないシステムを対象に応答性能を飛躍的に向上さの機能は管理ハードウェア (manager) が提供する.

せる手法を提案している. 文献 [6] は文献 [5] の回路規模をタスクは実行可能状態になれば全て並列に実行される.

削減するためにタスク内部に重複していた RTOS のサー

タスクの制御は管理ハードウェア (manager) が各タスクのビス機能を管理ハードウェアに集約する新たなハードウェ状態から実行/停止の信号を出力することにより行う. この

アアーキテクチャを提案した. また, 文献 [7] は文献 [6] の手法では, 各タスクモジュールは独立に並列に実行される

アーキテクチャにおいて, タスクを汎用的な高位合成ツー

ため, CPU 待ち, スケジューリングおよびコンテキストス

ルで合成できる制御手法を提案している.

イッチのオーバヘッドをなくせる. その上, タスクのハー

しかし, 文献 [7] では RTOS の機能を提供する管理ハー
ドウェアを Verilog HDL で手動設計しており, ハード

ドウェア化により高速に処理が行えるため, システムの応
答性能を飛躍的に向上させることができる.

ウェアの自動生成は行えていない. また, RTOS として

TOPPERS/ASP3 のみを想定している.

2.2 前提とするアーキテクチャ

本稿ではこの課題を解決するため, 文献 [7] の管理ハード

本稿では文献 [7] のアーキテクチャを前提とする. そのウェアを自動生成する手法を提案する. 本手法では, タス

ハードウェアの構成を図 2 に示す. T0∼T2 はタスクを,ク数やタスクが利用する RTOS のサービス等のシステム

manager は RTOS 機能をハードウェア化したモジュール

構成情報をコンフィギュレーションファイルに記述し, そである. manager 内の STATUS レジスタは各タスクのスの構成情報に応じた管理ハードウェアの RTL 記述を自動

テータス情報 (状態, 現在の優先度, ベース優先度, タイ生成する. また, RTOS によって異なる仕様の情報をコン

マー等) を, WAIT レジスタは各タスクのサービス待ちに

フィギュレーションファイルに記述することにより, 複数

関する情報を管理する. 下部にある mutex, event flag 等はの RTOS に対応した管理ハードウェアの生成を可能にす

RTOS のサービス機能を提供するサービスモジュールである. さらに, 使用されていない RTOS の機能を省くことにる. shared variable は共有変数の読み書きを, control taskより回路規模の削減を図る.

はタスクの起動/休止や優先度の変更等のサービスを提供

本手法を用いて TOPPERS/ASP3, FreeRTOS のそれぞするモジュールである. サービス間の干渉を避けるため,れの仕様に応じた機能を提供するハードウェアを自動生成

サービスは同時に 1 つのみ実行される. Request Arbiter

することができた. タスク数 4, 8, 16 のシステムについて(RA) は複数のタスクからサービス要求があった場合に, タ

ハードウェアを合成した結果, 回路規模と遅延はそれぞれ

スクの優先度に基づいてその調停を行う調停回路である.

概ねタスク数とその対数に比例することが判明した.

タスク (Ti) は実行可能状態になれば全て並列実行される. manager は STATUS レジスタ内の各タスクの状態に

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

基づいて各タスクを実行/停止する制御信号を出力する.

2.1 概念タ TFi にサービスの ID を, TAi に必要な引数を書き込ん

文献 [5] は RTOS の機能とタスクおよびハンドラ全てをⓒ 2022 Information Processing Society of Japan

タスク (Ti) がサービスを要求する場合, タスクはレジスでサービス処理の完了を待つ. RA は優先度最大のタスク
84

DAシンポジウム
Design Automation Symposium

DAS20222022/8/31

T0

T1

XT

T2

task
ID

manager

TF 0 TA 0

TF 1 TA 1

TF 2 TA 2

mutex
1 2

0 0

1

1

task 1 0

0

0

2 0

0

0

Request Arbiter (RA)WAIT
XT XF XA

event
flag

data
queue

sharedvariable

XA[0] XA[1]
mutex
ID

lock 0STATUS

mutex

XF
lock
unlockRC

max priority
LUT

図 3: mutex モジュールの構成例

controltask

図 2: 文献 [7] のハードウェアの構成
PROG.c

番号を求め, レジスタ XT, XF, XA にそれぞれ優先度最大

PROG.cfgのタスク番号, TFi のサービスの ID, TAi の引数を書き込
configurator

む. サービスモジュールは要求された処理を行い, 返り値
を XA レジスタに書き込む. manager が XA の値を TAi

manager.v
RA.vにコピーしてタスクにサービスの完了を通知すると, タス

mutex.v

eventflag.v

shared_variable.v

クは TAi から返り値を読み取って自身の処理を再開する.

dataqueue.v
control_task.v

service modules

RA は比較回路のツリーで優先度最大のタスク番号を求めそのタスクの要求を XF, XA に書き込む.

図 4: システムの自動生成の流れ

タイムアウトの処理は 1 つのタイマーではなくタスク毎にタイマーを設け, それを manager が管理することにより行う. タスクがタイムアウト付きのサービスを要求すると,
サービスモジュールはそのタスクのタイマーをセットする.
タイマーを manager が毎クロックカウントダウンし, 0 になると manager がサービスモジュールにキャンセル処理を強制し, サービスモジュールはタイムアウトしたタスクの待ちを解除する.

RTOS の機能を提供するサービスモジュール (mutex,

3. 管理ハードウェアの自動生成
3.1 概要
本稿では, 設計するシステムの構成情報から文献 [7] のアーキテクチャにおける manager モジュールを自動生成する.

eventflag, dataqueue 等) は, システムで使用される複数のコンフィギュレーションファイル内にシステムのタス

インスタンスを 1 つのモジュールで扱う. mutex モジューク数およびタスクが利用する RTOS のサービスモジュールの構成例を図 3 に示す. これはシステムに優先度上限プ

ル等の情報を記述し, そこから必要な数のポートとサービ

ロトコルの mutex が 3 つ (ID=0, 1, 2) あり, 3 つのタス

ス機能を提供する manager の回路を生成する. RTOS にク (ID=0, 1, 2) が これらを使用している場合の例である.

よって異なるタスクの優先度の表現, エラーコード, サービ

フラグの配列 lock は, どのタスクがどの mutex をロックスの仕様等をコンフィギュレーションファイルに記述する

しているかを表す. max priority はタスクが獲得していることにより, 複数 RTOS に対応可能とする. また, 必要な

mutex の優先度上限の最大値を求めるテーブルである. タ

RTOS のサービス機能のみを生成することにより回路規模

スクから mutex の獲得要求 (lock) があると, 当該 mutexの削減を図る.

が空いている場合はフラグをセットするとともにそのタス

本稿のハードウェア生成の流れを図 4 に示す. PROG.cクが獲得している mutex の集合からテーブルで最大の優は設計するリアルタイムシステムのソースコードであり,先度上限を求め, その値でタスクのカレント優先度を更新

PROG.cfg はそこから抽出したシステムの構成情報を記述して正常終了を表す返り値を返す. mutex がすでに他のタしたコンフィギュレーションファイルである. configurator

スクによって獲得されている場合には, この要求を出したはコンフィギュレーションファイルの情報から管理ハー

タスクを待ち状態にする. mutex の解放要求 (unlock) がドウェア (manager.v) とサブモジュールである調停回路あった場合には, フラグのリセットとタスクのカレント優(RA.v) およびサービスを実行するモジュール (mutex.v,

先度更新を行い, 当該 mutex を待っているタスクがあれば..., shared variable.v) を生成する. 現時点ではコンフィ

その待ち解除処理を行う.

ギュレーションファイルは手動で記述するが, 将来的にはソースコードを解析して生成する構想である.

ⓒ 2022 Information Processing Society of Japan85

DAシンポジウム
Design Automation Symposium

3.2 システムの構成に応じた管理ハードウェアの生成設計するシステムのタスク数とタスクが利用する RTOSのサービスに応じて必要となるポート, RA モジュール,サービスモジュールおよび STATUS レジスタや WAIT モ
ジュールを生成する. コンフィギュレーションファイルにはこのために必要になる以下の情報を記述する.

• タスクの数• タスクが利用するサービスとそのインスタンス毎の属性
コンフィギュレーションの記述例を図 5 に示す. 2 行目の tasks はタスク数で, 3 行目の service modules は使用されるサービスモジュールのリストである. それぞれのサー
ビスモジュールについて, そのモジュールあるいはサービスのインスタンス毎に必要な属性情報を記述する. 例えば,

4∼8 行目はシステムで使用される 2 つの mutex の情報である. 5 行目は mutex の優先度変更プロトコルであり, 6,

7 行目はインスタンス毎の ID, 使用するサービスコール,
mutex を利用するタスク等の情報を記述している.
使用するタスク数とサービスモジュールの情報から数に対応したポートや RA の回路を生成する. また, タスク
数とサービスモジュール数の情報から対応したサイズの

DAS20222022/8/31

1 system = > {2tasks = > 3 ,3service_modules = > [4mutexes = > [5
protocol = > ceiling6{ id = > 0 , services = > [ loc_mtx , unl_mtx ,tloc_mtx ] , tasks = > [0 , 2] , ceiling= > 2} ,7{ id = > 1 , services = > [ loc_mtx , unl_mtx] , tasks = > [0 , 1 , 2] , ceiling = > 1}8],9eventflags = > {10{ id = > 0 , services = > [ set_flg , wai_flg ,clr_flg ] , and_or = > 1 , clear = > 0}
11},
12
dataqueues = > {13{ id = > 0 , services = > [ snd_dtq , trcv_dtq] , data = > 10}
14},
15
shared_variables = > {16{ services = > [ read , write ] , mem = > 32}
17},
18
control_task = > {19services = > [ wup_tsk , sus_tsk , get_pri ,chg_pri ]
20
}
21
]
22
...
23 }

STATUS レジスタ, WAIT モジュール内のレジスタを生成する.

図 5: コンフィギュレーションの記述例 (PROG.cfg)

サービスモジュールに関しては, 使用するタスク, インス
タンスの数および使用されるサービスコールでレジスタのMAX PRI が MIN PRI より小さい場合は, 優先度が数値

サイズや個数と実装する処理が決まる. 例えば mutex での昇順であり, 逆の場合は降順であると解釈する.

は, mutex の優先度変更プロトコル, インスタンス数, およ図 6(a) は TOPPERS/ASP3 用の記述例であり, 11 行

びそれを使用するタスクのリストから, 必要なビット数の目が優先度の情報である. 優先度最大は 1, 最小は 16 であフラグレジスタとルックアップテーブルを生成し, タスク

り, 数値が小さいほど優先度が高い. (b) の FreeRTOS 用が利用するサービスコールの情報からサービス (ロック, アの記述例も同様である.

ンロック, タイムアウト) の処理を生成する.

優先度で調停を行う RA モジュールは優先度が昇順か降順で比較回路の大小順を決定して調停回路を生成する. ま3.3 複数の RTOS への対応
本稿では, RTOS によって異なる仕様の情報をコンフィ

た, RA に入力する優先度のビット数は優先度の取り得る値から決定する.

ギュレーションファイルに記述することによって複数の(2) サービスの内容

RTOS に対応する.

同じサービスであっても具体的な仕様は RTOS によっ(1) タスクの優先度て異なることがある. 例えば, mutex の場合 TOPPER-

一般にタスクの優先度は整数値で表現されるが, 優先度

S/ASP3 は優先度上限プロトコルを採用しているのに対しが数値の昇順であるか降順であるか, および優先度の上限て, FreeRTOS は優先度継承プロトコルを採用している.

値と下限値は RTOS によって異なる. 例えば, TOPPER-

使用するプロトコル名をサービスモジュールの情報に記

S/ASP3 の場合, 優先度は数値が小さいほど高く, 優先度の述することによりプロトコルに合ったハードウェア記述を取り得る値は 1 から 16 であるのに対し, FreeRTOS の場

生成する.

合は優先度は数値が大きいほど高く, 優先度の取り得る値
は 0 から 31 である.

例えば, TOPPERS/ASP3 用の記述例で図 6(a) では, 5行目でプロトコルが ceiling であることを記述し, 6 行目

本稿では, 優先度最大を表す値 (MAX PRI) と優先度最と 7 行目で各インスタンスの優先度上限の値を記述してい小を表す値 (MIN PRI) をコンフィギュレーションファイ

る. (b) の FreeRTOS 用の記述例も同様である. これらのルに記述し, その情報から RA の比較回路と優先度を扱

情報から protocol が ceiling の場合, 優先度上限プロトコ

うのに必要なビット数のレジスタおよび配線を生成する.

ル, inheritance の場合, 優先度継承プロトコルの mutex モⓒ 2022 Information Processing Society of Japan86

DAシンポジウム
Design Automation Symposium

ジュールの RTL 記述を生成する.

(3) エラーコード
サービスに対するエラコードも RTOS 毎に異なる.
本稿では, サービスモジュールがリターンコードを返す
場合ごとにオリジナルネームを付け, それに対応するエラー
コードをコンフィギュレーションファイルに記述すること
により対応を行う.
例えば, TOPPERS/ASP3 用の図 6(a) では, 12 行目
以降に mutex モジュールに対するエラーコードの記述例を示す. (b) の FreeRTOS 用も同様である. 例えば,

mutex unlock ok は mutex のアンロックの正常終了, mutex other locked unlock error は他のタスクがロックしている mutex をアンロックした時のエラー処理に対するオリ
ジナルネームである. 各オリジナルネームに対して, TOP-PERS/ASP3 であれば E OK や E OACV 等, FreeRTOS
であれば pdTRUE, pdFALSE 等のマクロ定数を記述する
ことにより複数の RTOS に対応する.

3.4 最小限の機能の生成

DAS20222022/8/31

1 system = > {2tasks = > 3 ,3service_modules = > [4mutexes = > [5
protocol = > ceiling6{ id = > 0 , services = > [ loc_mtx , unl_mtx ,tloc_mtx ] , tasks = > [0 , 2] , ceiling= > 2} ,7{ id = > 1 , services = > [ loc_mtx , unl_mtx] , tasks = > [0 , 1 , 2] , ceiling = > 1}
8
]
9
...
10
],
11
priority = > { MAX_PRI = > 1 , MIN_PRI = > 16} ,12error_code = > [13{ mutex_unlock_ok = > ’ E_OK ’} ,14
{ mutex_other_locked_unlock_error => ’
E_OACV ’} ,15
{ m u t e x _ u n l o c k e d _ u n l o c k _ e r r o r = > ’ E_OACV ’},
16{ mutex_timeout = > ’ E_TMOUT ’} ,17
{ mutex_lock_ok = > ’ E_OK ’} ,18
{ m u t e x _ l o c k e d _ l o c k _ e r r o r = > ’ E_OBJ ’} ,
19
...
20
]
21 }

本稿では, サービスモジュールの内の実装に不要な処理(a) TOPPERS/ASP3を省き必要最小限の機能を生成する. 不要な処理が発生する場面は以下が想定される.

• タイムアウトが不要な場合のタイムアウト処理• タスクが使用しないサービスコールの処理
これらに対して, 最小限の機能を生成することにより回路規模削減を図る.
タイムアウト処理に対してはタイムアウトが必要な場
合のみタイムアウト処理を生成し, 不要な場合は生成しな
いことにより最小限の機能を生成する. 例えば, 図 5 の12∼14 行目はデータキューの情報である. データキューのservices である snd dtq はデータ送信のサービスであるため, タイムアウトの処理は生成しない. trcv dtq はタイムアウト付きのデータ受信のサービスであるため, タイムア
ウト処理を生成する.
タスクが使用しないサービスコールの処理に対する RTL
記述を省くことにより回路規模の削減を図る. 例えば, 図 5の 18∼20 行目のコントロールタスクに実装するサービス
コール (wup tsk, sus tsk, get pri, chg pri) が services に記述されているので, これらの実行に必要な RTL 記述の1 system = > {2tasks = > 3 ,3service_modules = > [4mutexes = > [5
protocol = > inheritance6{ id = > 0 , services = > [ loc_mtx , unl_mtx ,tloc_mtx ] , tasks = >[0 , 2]} ,7{ id = > 1 , services = > [ loc_mtx , unl_mtx] , tasks = >[0 , 1 , 2]}
8
]
9
...
10
],
11
priority = > { MAX_PRI = > 31 , MIN_PRI = > 0} ,12error_code = > [13{ mutex_unlock_ok = > ’ pdTRUE ’} ,14
{ mutex_other_locked_unlock_error => ’pdFALSE ’} ,15
{ m u t e x _ u n l o c k e d _ u n l o c k _ e r r o r = > ’ pdFALSE’} ,16{ mutex_timeout = > ’ pdFALSE ’} ,17
{ mutex_lock_ok = > ’ pdTRUE ’} ,18
{ m u t e x _ l o c k e d _ l o c k _ e r r o r = > ’ pdFALSE ’} ,
19
...
20
]
21 }

みを生成する.

4. 実装と実験(b) FreeRTOS

図 6: RTOS の差異の記述例

提案手法に基づいて, 管理ハードウェアを生成するコ
ンフィギュレータを Perl5 で実装した. 生成された Ver-た manager モジュールの詳細は以下である.

ilog HDL を Xilinx 社の Vivado 2016.4 を用いて FPGA

• タスク数 4 つ(Artix-7) をターゲットに論理合成行った.

• data queue は 32B × 10 のデータ領域を保持

コンフィギュレータを用いて TOPPERS/ASP3 および

FreeRTOS の仕様に応じた manager を生成した. 生成しⓒ 2022 Information Processing Society of Japan• shared variable は 32B × 32 ワードメモリを保持• control task がサポートしたサービスコールは TOP87

DAシンポジウム
Design Automation Symposium

DAS20222022/8/31

表 1: manager の回路規模とクリティカルパス遅延

アを生成する手法を提案した. RTOS によって異なる仕様の情報をコンフィギュレーションファイルに記述すること(タスク数 4)

により複数の RTOS に対応するとともに, 必要な RTOS
RTOS

#LUT

#FF

delay [ns]

TOPPERS/ASP3

3243

2039

7.581

本手法に基づき, TOPPERS/ASP3 および FreeRTOSFreeRTOS

3431

2042

7.693

仕様の manager を生成することができた. また, タスク数の機能のみを生成することにより回路規模の削減を図った.

4, 8, 16 の manager モジュールの回路規模とクリティカル
パス遅延はそれぞれ概ねタスク数とその対数に比例するこ
表 2: タスク数を変化させた場合の合成結果
#TASK

#LUT

#FF

delay [ns]

4

4463

2188

7.449

8

7970

3812

9.121

16

14662

7110

12.155とが判明した.
管理ハードウェアの自動生成によって, タスク数に対する回路規模やクリティカルパス遅延が判明したため, ボト
ルネックの分析や回路の最適化が次の課題として挙がられる. また, 現時点ではコンフィギュレーションファイルは人手で記述しているため, プログラムのソースコードを解析してコンフィギュレーションファイルを生成するトラン

PERS/ASP3 では wup tsk, sus tsk, get pri, chg pri

スレータの実装が今後の課題として挙げられる.

の 4 つ, FreeRTOS では, xTaskResume, vTaskSus-

謝辞 本研究に関して有益な御助言を頂いた元立命館

pend, vTaskPriorityGet, vTaskPrioritySet の 4 つで大学の中谷嵩之氏, 元関西学院大学の田村真平氏, およびある.

ご支援を頂いた関西学院大学石浦研究室の諸氏に感謝致生成した manager モジュールの回路規模とクリティカル

します. 本研究の一部 JSPS 科研費 19H04081, 20H00590,

パス遅延を表 1 に示す. 回路規模を表す #LUT はルッ

21K19776 の助成による.

クアップテーブル数, #FF はフリップフロップ数である.
両 RTOS 仕様で生成したサービス処理やタスク数が同じ

参考文献

であるため, 回路規模とクリティカルパス遅延は同程度に

[1]

なった.
本手法を用いてタスク数 4, 8, 16 について TOPPER-

S/ASP3 仕様の manager を生成した. その manager 内の[2]

サービスモジュールは以下の通りとした.

• mutex はインスタンス 2 つ• event flag はインスタンス 2 つ• data queue は 32B × 10 のデータ領域を保持[3]• shared variable は 32B × 32 ワードメモリを保持• control task がサポートするサービスコールは以下の12 である.

[4]

act tsk, can act, ter tsk, chg pri, get pri, wup tsk,
can wup, rel wai, sus tsk, rsm tsk, loc cpu, unl cpu[5]生成した manager モジュールの回路規模とクリティカ
ルパス遅延を表 2 に示す. 回路規模と遅延はそれぞれ概ね[6]

タスク数とその対数に比例して増加している. タスク数に対応したポート, サービス処理, レジスタを生成するため,回路規模はタスク数に比例して増加したと考える. また, ク
リティカルパス遅延の増加は RA の比較回路のツリーの段[7]

P. Kohout, B. Ganesh, and B. 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).
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. International Symposium on Rapid System Prototyping (RSP
2006), pp. 163–168 (June 2006).
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).
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).
Y. Oosako, N. Ishiura, H. Tomiyama, and H. Kanbara.:
Synthesis of full hardware implementation of RTOS-based
systems, in Proc. RSP 2018, pp. 1–7 (Oct. 2018).
六車, 石浦, 安堂, 冨山, 神原: “RTOS 利用システムのフル
ハードウェア化におけるサービス処理機能の集約,” 信学技報, VLD2020-75 (Mar. 2021).
安堂, 石井, 石浦, 冨山, 神原:“RTOS 利用システムの汎用高位合成系を用いたフルハードウェア化,” 信学技報,
VLD2021-51 (Jan. 2022).

数の増加によるものと考える. タスク数 16 では回路規模,
クリティカルパス遅延とも実用には少し大きく, その削減が必要と考えれる.

5. おわりに
本稿では, システムの構成情報に対応した管理ハードウェⓒ 2022 Information Processing Society of Japan88