[ Soft Error-Aware Scheduling in High-Level Synthesis ]
– N冗長化 (時間的・空間的三重化とか)
– 面積・性能・信頼性の異なる複数種類の演算器を活用
task と agent の割り当て制限:
– task i はタイプが一致した agent j にのみ割り当てることができる
– task i はただひとつの agent j にのみ割り当てることができる
たとえばレジスタは大きな演算器より信頼性が高いと考えられるので、データの滞在時間を考慮しつつ総信頼性を最大化するように解く。
CPLEX で解くのか。ほっほー
レイテンシや面積の制約がきついときにいい感じだ。
瀬戸先生:
信頼性の値ってのはどういうこと？ → ソフトエラーの確率。
違う種類の演算器の信頼性をかけ算するってのは問題ないの？ → いまのところそれで問題ないと思っているがほかの方法を考えないといけないかも。
名古屋大学の先生:
システム全体の信頼性で考えたときに、使用頻度の高い回路と低い回路のそれを考慮しないといけないと思うのだが → (むむむ、ちょっとこれは議論がわからなかった…)
ライフタイム という言葉がキモな気がするんだけど、ちょっと難しい。
でも手堅くやっている印象。
[ インクリメンタル高位合成に向けた設計記述間差分の計算手法 ]
VDECの吉田先生。
高位合成だと自動生成された RTL が読めない・・・
ASIC 設計がやり直しになるケースは圧倒的に論理設計の問題が多い。ま、IR drop でダメとかも 15% あるそうで、ちょっと怖い。
高位記述間の diff をとりたい。
– でもシンボル名の変更とか難しい
– 最適化がいろいろ行われるのも問題・・・
– ダメ？
DFG になってからやる
– 最大共通部分グラフをみつける
– 大きいのはムリ
– ダメ！
というわけでまんなかでやりましょう。
– 中間命令列に変換してから差分を抽出。
– 列の間の差分計算なので、グラフ間より簡単で、 O(n log(n)) に落ちる
– 演算・制御フローを一貫して表現可能
– LLVM 内部表現を使う
– 弱点はグラフ間差分の方が小さいことがある
命令列の並びは変えずに、命令名 (シンボル名) を変更することで差分を最小化する手法。
1. 中間命令列に変換
2. 文字列比較 (つまり /usr/bin/diff) でがっつり
– 名前の再割り当て
3. 競合グラフをつくり、最大独立集合によって厳密解を求める
Cyneum というのを作っているそうだ。フロントエンドは LLVM.
IDCT コードでやってみた。行計算ループと列計算ループを入れ替えたりしても数秒で抽出してくれる。
NEC 若林さん:
これは loop unrolling とかしたあとに適応するの？ → Yes
グローバルに名前をつけ直すんじゃなくて、ローカルに名前をつけてやればいいのでは？ → basic block の形がかわっちゃっても追跡できたりするようにしたい。step 2 が網羅的なことを全然しないので、マッチする部分が山ほど出てきて効率が悪くなっているってこともない。step 2 でがーっとやって一気に絞り込むのが重要ということですね！
[マルチプロセッサ対応RTOSに対するAPIテストの実施]
名古屋大学には組み込みシステム研究センターがあるのか！
マルチプロセッサになると RTOS の自社開発をする会社が減っている模様。作るのが大変だから。でもそうするといろんなテストをしなければいけない。
TOPPERS/FMP kernel: iTron を拡張したやつ。プロセッサをまたいだAPIの発行 (ほかのプロセッサで走っているタスクにメッセージを投げる) とか、タスクのマイグレーション (ほかのプロセッサへ) ができる。
ターゲットシステムの要件(プロセッサ数とかロック方式)を入れると、テストケースを抽出してテストプログラムを作ってくれる。
ARMの命令セットシミュレータ SkyEye をマルチプロセッサ用に拡張して評価。
48 tests, 79 の不具合発見。実機でも評価。これはカーネルのプラットフォーム依存な部分の評価に必須。ロック周り・割り込み周りとかでの不具合が出てくる。
今後もテストスイートの開発をいろいろ。
確率的に起きる事象を拾えた、ということだが、タイミングを揺らすような工夫はなにか入っている？ → シミュレータを使うと同期のタイミングを設定したりできるので、いろいろ（実機では起きないほどの）揺さぶりをかけることができる。
仕様をモデルを書いてテストケースを自動生成、みたいなことはしないのか？ → RTOSの仕様を記号化して書くとか網羅的にやるとか、書くだけで死ぬし状態爆発が起きるし、むかしやって大変な目に遭われた方もいるので・・・ conformance test くらいが限度になっちゃう。conformance test を通っただけでは誰でもつかってくれないので、形式的テストでそれ以上のことをしたい。 → えーそこは納得しないけどありがとうございました (笑)
[マルチプロセッサ対応RTOS向けテストプログラム生成ツールにおけるプロセッサ間同期の実現]
同期をちゃんといれないと動くテストも動かんもんね。
うーん、しかし、なんか必要性とかがよくわからんかったなあ。まあ、こういうソフトウェア工学的なことは素人だからなんですけど。
[リアルタイム処理向けマルチコアタスク配置の評価関数設計]
SMP ではなく AMP (パーティション方式、つまり静的コア配置) が対象。
マルチコアにタスクを分散配置する問題はタスク数が増えると短時間で解を得ることが難しいNP困難問題。bin-packing 的にヒューリスティクスを使う手法は提案されている。この分野では基本的にタスクはその種類ごとに周期的に発生するもので、単発でぽっと起きたりはしないものらしい（まあ、制御だったらそういうもんか。）
タスク配置問題を解くためには、実用に沿った評価関数と、それを使った配置アルゴリズムの設計が必要。
評価関数3種
– 負荷バランス
– コア間依存
– Worst case response time (タスクセット内の各タスクの応答時間の累計値が極力小さくなるように配置: 適当に配置すると依存関係で待ち時間が発生しちゃう訳ですね)
評価項目3種
– コア間依存数
– 待ち時間率
– 不均衡率 (負荷バランスの偏り具合。0なら均等)
全般的に WCRT は有効。コア間依存でやると・・・依存はゼロになっちゃうけど、うわあああ、という結果。
NEC 若林さん:
コンパイルの時に静的に最適配置できないの？ → リアルタイムなので、同じ優先度で依存のないタスクがかち合ったときにどっちが先に行くか、場合によって違うから
CPUの切り替えのペナルティとかは？レジスタの値を渡したりするのは大変ですよね → そこは実行時間に比べて充分短いという仮定でやっているんだけど、アプリケーションによって違ってくるから、今後やってみることが課題。
はなわさん:
2 core でやっているけど、4 core とかへ適用するのはどれくらい大変ですか？ → 全く同じように適用できますが、やっていると依存待ち時間が長くなることがわかっているので、タスクセットの作り方とかを手直しすることが先かも。
[HW/SW Cosimulation framework based on software component system]
TECS.
HW のほうはどうすんだ、と思ったら ModelSim とか使うのか。
日立 八木さん:
基本的にふつうのCではなくTECSで書かれているものが対象ということでOK? → はい
どれくらい使えますか? → 動作合成ツールが対応している範囲ならそのままのコードで。
瀬戸先生:
TECS を使うとここを HW, ここを SW みたいなのや、どことどこを並列、というのは簡単に指定できるということ？ → そゆことです。データ並列性を何分割するかとかは design property で指定できて、コードをいじる必要はない。
こういう環境は便利だと思うんだけど IDE 的な (デバッグとかの) サポートが必要で、でもそうするとコンポーネントの中で起きている何かが問題だったりすると思うけどどうしていったらいいと思うか → これから考えなきゃいけないんだけど、トレースを使えばまあ、どこで問題が起きているかある程度はわかります。
名古屋大 松原先生:
HW/SW mapping とかは、システムレベル設計ツールがやってくれることなんじゃないかなあ、と思っているんだけど、そういうツールがほしい入力を作るってことだよね → (質疑が追い切れませんでした。ムズカシイ)
[リアルタイムアプリケーション向けタスク処理定義可能なスケジューリングシミュレータ]
いろんなタスクスケジューリングアルゴリズムが提案されているがRTOSのほとんどは固定優先度スケジューリングしかサポートしていない。いろんなアプリに対していろんなスケジューリングを試したい。
従来のシミュレータは
– タスクのパラメータ (起動間隔や実行時間) が固定
– タスク内条件分岐、タスク間依存関係、割り込みなどの非同期処理が定義できない
などの問題が。できたとしてもマルチコアに対応してなかったりとか。
こういうのを一通りカバーできるようにした。
若林さん:
どれくらい強力？ → ISSでの数時間がこれ使うと数分になる
スケジューラを作るひと・スケジューリングアルゴリズムを考える人のためのもの → Yes (松原先生焦る。アルゴリズムもアーキテクチャもシミュレーションなら動かせるので、設計の早い段階でいろいろ試せるようにしたい、ということだそうです)
[Android携帯端末アプリケーション向け消費電力プロファイリング手法]
Android アプリケーションのシミュレーションで消費電力を推定する。さらにメソッド単位で分割して。既存手法はDMMとか使うので大変。
OSから取得できるパラメータからの消費電力見積もり。
全体の消費電力と重回帰分析でつきあわせればバラせるのかな。
使ったリソース量をどうやって拾うかが問題。低レベル API にフックするか /proc を見るか。Android は VM で動いてるんで前者は案外楽勝らしい。無線通信とかのコストのメソッドへの割り振りはCPU時間でざっくり割っちゃう。/proc からどれだけ正確に拾えるかとか、オーバーヘッドはどれくらいかとか、ちゃんと検証している。低レベル API にフックするのはかなりオーバーヘッドがある。
ああでもまだ実装してないのか・・・
塙さん:
WiFi でも通信状況で電力がずいぶん変わってくると思うが。エミュレータというのはどのレベルのエミュレータ？消費電力とどうからむのかはエミュレータでわかるの？ → WiFi ではある程度線型モデルだということを実験で確認している。3G ではムリムリ。
いやー通信量を実行時間で山分けにするのはいくら何でも乱暴じゃないか・・・
[無線によるユビキタス情報配信システムの設計・構築手法の検討]
むかしの実験で三条烏丸から三条寺町まで HTTP サーバつき WiFi / Bluetooth AP を設置したそうな。それにつなぐ端末をもって歩いてもらう実験。お店情報とかが降ってくる。
– 自立して動作して情報提供する多数のノード
– それに接続して情報を収集・加工・提示する端末
なわけだが、やってみるといろいろ保守が大変、と。でもなあ・・・べつに Linux 動いてるんだったら、一度動いてしまえばあとはまとめてネットワーク越しに管理すりゃいいんじゃないかと思うんだけどなあ… 壊れない限りはね。それに、なんかコンテンツを発信するのにわざわざAP設置しないといけないってどうなのよ？