投稿者: yasu

[低電力アクセラレータCMA-1におけるウェーブパイプラインの適用]
CMA.
PE アレイは完全な組み合わせ回路。
データーフローはレジスタファイルのところで管理する。そこだけクロックが通ってる。
演算ごとにPEの遅延をモデル化してPEアレイの遅延を推定することでぎりぎりのタイミングを狙えるようにする。
電圧を落としたときの電力性能比を向上。でも電圧が上がるともったいない感じ。
早すぎるのも問題だったりするのか。
最小遅延と最大遅延の間でデータを受け取らないといけない。
[標準CMOSロジックプロセスで実現する不揮発性化した再構成デバイスの検討]
トランジスタの間をフローティングゲートにして標準 CMOS で作れる。むかしの IBM のえらい人が開発したらしい。書き込みには高電圧が必要で、読み出しのところにはアンプがいるみたい。
と思ったけどアンプは使えないので工夫している。おもろい。が、不揮発性メモリでトランジスタ2つで、追加のトランジスタが6つか・・・あれでも面積は 34% しかふえないの？
書き込み電圧はチャージポンプで内部に持たせてもいいんだけど、電圧とかの条件がまだよくわからないのでとりあえず外から入れることにした。
MPLD のアーキテクチャはおもしろそうだ。
[多電源電圧方式による動的再構成プロセッサの低消費電力化および電圧マッピング手法の提案]
High Vth と Low Vth の PE を半分ずつ。
Vdd は PE ごとに High / Low をえらべる。
SE は電圧固定。
Vdd はコンテキスト切り替え時になるべく変更しないようにしたい。
同じ演算でも Vth の違いで 3.5 倍くらい時間が違う。
Vdd 割り当てアルゴリズムでベストケースで 50% くらい電力を削れた。
[LUT間の入力共有に基づく小面積論理クラスタ構造の一提案]
ふつうの LUT と、Double Box (何本かの入力を共有するふたつの LUT) の混在するクラスタから成る FPGA に関する考察。MCNC で評価とってる。
なかなかおもしろい。
[自己組織化マップを用いたFPGA配置手法の提案]
SOM のサイズは 11×11 ノード。
FPGA のアレイサイズと合わせてある。
ベクトルの次元数はモジュールの数と同じ。
入力層は無向グラフとしたネットリスト。近接関係とか fanout を考えないといけないが…
出力層は配線構造。
ネットリストなので接続関係からくる距離にユークリッド距離が適用できなくて内積でやってる。
[ハードウェア設計のためのモデルコンパイラ開発と実証実験]
すみません、おじさんには UML とかわかりません。
[合議制アルゴリズムのアプリケーションを用いたリコンフィギャラブルシステムの評価]
弘中先生の所の RC-SYS をつかって、複数のアルゴリズムで connect 6 を解いてごりごり、というお話。
[動的再構成システムに迎えた部分再構成データの再配置に関する一検討]
Virtex-6 でもやっぱり再配置はむずかしいのか。
Proxy logic が場所ごとに違うのは厄介だな。
[マルチプロセッサ対応システムレベル設計環境SystemBuilderを用いたFPGA向け設計事例]
プロファイラをFPGA上にのっけたお話。
まあ外に引っ張り出すより中で監視した方がいいよね。いろいろ大変だけど。
効果的なSW/HW分割点をさがすのにべんり。
ハードウェアプラットフォームの依存性は理想的にはないんだけど、いまのところは Stratix II で動いている。glue logic のところを作れば移植できると思う。
[高速データバスに接続されたFPGAにおけるHWボトルネックを解消するための設計フレームワーク]
モジュール数を最適化してデータ転送が詰まるのを防ぐ。
XAPP1052 で PCIe transaction layer のスループットが測れるのか。
データ並列のところだけだとちょっとアレかなー　という意見も。そうですね。
[リモートからのLUT書き換えによる動的部分再構成の基礎検討]
学生の時の研究であって会社の仕事じゃないそうです。そうだよね。びっくりした。
SRLC16E として LUT を書き換えるとかできるの？すごいな。
DP-DDI (データを直接回路化してパターン認識するやつ) に適用。
iPhone で LUT の中身を生成するとか新鮮だな。
組み合わせ回路でいろいろできるならこういうのたのしそう。
[動的再構成ビジョンチップアーキテクチャ上での並列テンプレートマッチング]
exact matching なのか。顔認識とかにはまだ使えない。
データも光で入れるのは楽しそうだなー、と。
[再構成型プロセッサDS-HIEにおける電力計測プログラムによる性能評価]
スマートメーター。ディジットシリアル。
平方根とか必要だと大変そうね。
[動的再構成可能ハードウェアを利用したパターンマッチング処理手法の提案]
セキュリティ。
NFA でマッチング。
DFA だと状態遷移表が爆発しちゃうんで。ただし、NFA でも正規表現をサポートしようとすると回路が爆発しちゃうので、正規表現は使えないとのこと。
[ダイナミックリコンフィギャラブルSTPエンジンを用いた適応型Viterbi復号器の設計と実装]
Viterbi の拘束長をビットエラーレートに応じて変更。
拘束長が長い方がスループット下がるの？そりゃそうか。
どうせ一度通信が途切れるんだから送信側より速く切り替えできてもしょうがないんじゃないかと思ったり。
[データを直接回路化したパターン認識装置の性能比較評価]
DDI. ソナースペクトル。消費電力とか。
DDI のいろいろがよくわかった。ふむ。楽しそうすぎる。
[FPGA によるSAT問題のプリプロセッサの実現]
SAT competition というのがあるのか。熱いな。
– 節の削除
– リテラルの削除
– 変数の削除
変数が何万とかあるのか…

[ Virtual HILS – システム全体仮想化による、組込みソフト検証の高効率化 – ]
自動車の電子制御システム。
ECUの数は1台あたり100+台… CANとかで連携したりしている。
OSを載せることができないケースが多い (オーバーヘッドとかの問題) ので、通信、割り込み、制御を全部書く必要がある。テストが大変！
電子的モックアップを使ってやっている。実機 ECU, 実機バイナリ。メカ系のリアルタイムシミュレータに AD/DA がついたりしている。システムがでかい。これを全部がっつり仮想化する。
任意のところで内部状態が観測できるし、ドメインをまたいだ可視化ができる。かっこいい。
HILS が1500万円、VHILSは2000万円 (75%がISSの費用だけど…)。VHILS は実行時間が3倍かかる。
インタフェイスが CAN に限られているのでモデル化はそれほど大変じゃなかった模様だが、アナログの線が入ったらどうしようかなあ、とのこと。
ISS を自作すれば安くなるんだけど、詳細な CPU モデルが手に入るかどうかが問題で、Synopsys とかはそのへんを CPU ベンダから出してもらってやっているとのこと。あるいは CPU ベンダが出している ISS にラッパを噛ませる方法もある、とか。このへんがいろいろ大変そう。
[ ネットワーク混在型Cell/B.E.クラスタにおけるHigh Performance Linpackの性能評価 ]
Roadrunner は Inifiniband だけど、ケーブルが 1万+円 / m.
GbE と 10GbE の混在で安上がりにしたいぜ。
Blade のシャーシ内が GbE でシャーシ間が 10GbE。まあ、機材的にちょっとしょうがない。10GbE のスループットが GbE の 1.2 倍しか出ないのは謎らしい (もっと出ると思うんだけどなあ…) ジャンボフレーム使ってない、とかかしら？
10GbE をどれくらい混ぜると性能にどう影響するか、みたいなのを測定。
HPL 以外のはこれからやりたいと思っている。あと、自動チューニングですね。
[ キャッシュインジェクションを用いた受信キューのキャッシュ制御方式の提案]
IBM Power Edge of Network (PowerEN) を使っている。
FCI, UCI （仮名）が実装されている。
16コア。4コアずつで 2MB L2 を共有。
Host Ether Accelerator からキャッシュインジェクションできる。
プリフェッチとキャッシュインジェクションの組み合わせを提案・実装。
かなり効きます。むー。こういうの重要かもなあ。
Intel- Direct Cache Access (DCA)
NICからのメモリ書き込みに合わせてプリフェッチ。NICも対応している必要アリ。
これちょっとサーベイしよう。
[テスト工数配分方法の評価手法と組込みソフトの派生開発プロジェクトへの適用]
改変母体の過去の不具合が多いモジュールは
1. 改変母体のソースコードが複雑
2. 改変母体の仕様を記録したドキュメントが残っていない
3. 人的な (笑) 要因
なので、それをもとにしたやつを作る場合は頑張ってテストする必要がある、と。
テスト件数というのは手法によっても変わってくるのでは？ → 最低の件数を決めたい
最終的に出てくるのが経験とか傾向のような内的なものになっちゃいがちなんだけど、たとえば日立さんのグループ全体とかをみたら一般化できないか？
etc.
[文書診断法の診断観点と指摘水準におけるコーディング規約の分析]
作業工程の成果物を測りたい。文書診断法。
コーディング規則を用いてプログラムの品質を評価できないかな、というお話。
機械処理ではない。
プログラミング教育に倣い、開発文書の書き方教育を整備。
システム開発文書品質研究会 ASDoQ を立ち上げ。
[テストプログラム生成ツールのフロントエンドプロセッサの開発]
きのうの RTOS の発表に関連した発表。
コード生成と前処理を切り離して、システムが変わっても簡単に対応できるようにする。あるいは担当者間でのばらつきを改称できる。
コード生成ツールが正しいコードを吐いているかのテストはどうするの？→テストケースの分だけはテストが必要です。
[Windowsヒューマノイド・ロボット・コントローラALICEの通信速度評価]
すみません、昼食から戻ってくるのが遅くなりました…
[MCAPIを用いた組込み向け耐故障分散共有メモリの実装]
SCASH なつかしい。
SCASH-FT (耐故障) を作ってる。
組み込み用のネットワークの PEARL (PCI Express Adaptive Link) に移植したい。既に MCAPI (Multicore Communication API) というプロトコルがその上で動いている。
[ユーザ空間の例外処理情報を利用した組み込みシステム向け例外処理実装方式の検討]
複雑なシステムになると watchdog timer による再起動はさすがにダメ。
try と catch みたいなのってお手軽にきっちりした例外処理を実装できる訳で、いいよね、というお話。ただ、いろんな言語が出てきちゃってるので統合するのはムズカシイよね…
[ 単一磁束量子論理回路のためのタイミング故障のモデル化とテスト手法の検討 ]
SFQ 回路。4K くらいで使うんだが、冷やす電気代を考えても消費電力的にお得って、すごいな。クロックツリー合成・自動配線・設計検証などの研究は行われている。今回は故障テスト。
信号伝達にはクロックとデータを同時にえいやっと送る模様。データのパルスとクロックの間のタイミングがあわないと誤動作。
浮動小数点演算器の設計例がでてた。遅延調整の素子がたくさん必要だとのこと。
クロックがデータよりも先に到着する（concurrent flow）とデータがクロックよりも先に到着する (clock follow data) がある。これふつうの半導体とはだいぶ様子が異なる印象。
[ 高速リアルタイムデータ収集用ネットワークレコーダの開発 ]
Virtex-5 FX + 6x10GbE + PCIe x16 + 2xDRAM 128MB + 8xSATA (SSD)
URL フィルタ (hash + binary search) とかを実装して記録したりすることができる。60Gbps で有害サイトフィルタとか :p
ハイスループットな実験の生データ記録とかにいいよね。
[ AFMを用いたネットワーク障害検知方法の検討 ]
drc/dst IP address, port, protocol とかをつかってフローを観測すると多次元解析で異常がわかるんじゃないか的発表。いや、気持ちはわかるけどそれリアルタイムにできるのか…
質問してみたところ、いちおう 10Gbps でも動いているのだそうです。
アイデアは面白いな。だが後出しジャンケンにならない（リアルタイムで検出ができるような）実装はムズカシイかもしれん。
[ 全画面やフレームレートという概念を排除した新しい表示方式の提案 ]
これちょっと面白い。うまく標準化できれば用途も開けそうだけど、どうなんかね。
FPGA のってるけど基本的には LVDS のインタフェイスとして使っていて、だいたいの処理は SH でやってるみたいだ。実装そのものよりプロトコルが問題のような。

[ 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設置しないといけないってどうなのよ？