[ 部分回路再構成を利用した耐故障性向上アーキテクチャの提案とその実装 ]
壊れたブロックを置き換えたときに、壊れてるところから配線に信号が行っちゃわない？
大丈夫だそうです。
[ 高精度浮動小数点演算器のFPGAでの実装 ]
倍精度だと CPU と勝負するのは厳しいが、四倍精度だと CPU でも emulation になるので、四倍精度の演算器が FPGA にいくつか載れば、CPU に勝てる可能性がある!
乗算は仮数部の下の方とか捨てちゃってもいいよね。
加減算はシフタが巨大になる… 絶対値の比がものすごく大きくて情報落ちが発生するような状況でなければ、多少サボれる。
[ 部分再構成システムにおけるAES-GCMを用いたビットストリームの秘匿と認証 ]
認証暗号 (AES-GCM) を使って、秘匿と認証を同時に行う (2000年くらいから出てきた概念)
Altera は Stratix IV GX で部分再構成に対応らしいぞ!
AES+SHA より小さくて速くなった。
[ FPGAにおける標数5の楕円曲線演算の高位合成を用いた実装 ]
楕円曲線ってソフトウェアでもRSAなんかと比べて遅いの? はい、とても。まだ実用化されてない。
[ ディジットシリアル演算を導入した ]
[ MXコアのMIMD型PE間データ通信における経路決定手法の提案 ]
SIMD から MIMD にして、逐次処理でも性能が出るようになったが、制御が大変。
PE 間のデータ通信も SIMD 的に、全部の PE が同じことを同時にやるのではなく、個別に指定できるようにしたい。
[ A Link Removal Methodology for Application-Specific Networks-on-chip on FPGAs ]
X-Y routing より難しいルーティングを提案してるけ、もう少し賢い、大きな (面積を食う) ルータが必要？
source routing なので、そんなことはない。
[ 粒度可変論理セル向けクラスタ構造の一検討 ]
ALU: 算術演算に向く
LUT: 論理演算に向く
これがデバイスによって規定されてしまうのは都合悪い。2入力標準型とFAをくっつけたロジックセル。
いままではセルをそのまま並べていたのをクラスタ化する検討。
クラスタ化自体の効果は？ ローカル配線による性能向上がでてるだんだけど、スライドはありません。。。
[ RapidMatriX: Algebraic Path Problemのための 2D array processor ]
Algebraic Path Problem: グラフ理論みたいなやつ。
2D SIMD array
3入力1出力の複合演算器。FMA のほかに大小比較やブール演算を含む複合演算を実行。
[ パワーゲーティングを適用した動的リコンフィギャラブルプロセッサの設計と評価 ]
斉藤くん。
電源の GND に高閾値電圧のスリープトランジスタを入れて、ブロックまるごとを殺すのが従来のやりかた。粒度も大きいし、wake-up にも時間がかる。
宇佐美研ライブラリはローカルな GND を作って、そこにスリープトランジスタを入れる。細粒度で制御することができて、 wake up < 5ns。損益分岐点をちゃんと計算していれてやらないといけないのと、ネットリストを加工して挿入しなければならないのがちょっと問題。
全体でリークが多いのは ALU と SMU. Pickout は小さなモジュールで、あまりリークしないので、削減効果は少ない。
ALU + SMU を同時に sleep/wakeup するのと、別々に制御するのと検討した。同じくらいの利き方のときもあるが、後者の方がズバッと効くこともある。面積オーバーヘッドは 7-14%.
レジスタファイルってけっこう大きいから、レジスタファイルを残してほかのところを削ってもだめなんじゃない?
それは心配したんだけど、実は ALU のほとんどは乗算で、それが結構大きいので、意外と大丈夫です。
[ 銀塩ホログラムメモリを用いたマルチコンテキスト・ダイナミック光再構成型ゲートアレイ ]
いままでの光再構成型ゲートアレイは、SPD に FF がついていた。新しいのは、SPD の接合容量を使って SPD 自体をメモリとして使うことで、FF を排除する。面積は減るんだけど、バックグラウンド光が入ったりすることで回路の保持時間が短くなったりするのが心配。
いままでは液晶をホログラムの代わりにしていた(簡単だし)。こんどは銀塩を使います。銀塩だと、ホログラム作成装置が必要。He-Ne レーザ (633nm) で書き込み。コンテキストあたりの面積は液晶の 1/4 以下。
AND 回路を作ってみた。configuration に 69ms で、回路を維持できる時間は 189ms.
ただし、いまは He-Ne レーザーがつきっぱなしで、それがバックグラウンド光の原因にもなっているのを、半導体レーザーとかにすればもっと回路を維持できる時間を延ばせると思う、とのこと。
SPD の面積は LUT とかに比べるとどれくらい？ (ふんがさん)
ひとつ 25.5um 角のを使ってるので、すごく大きい。でも、最近の SPD は 1um 角くらいにはなる。
銀塩ホログラムって一枚いくらくらい？ (尼崎先生)
数千円くらい。最終的には銀塩じゃなくて、 3D なホログラムを使いたい。
光学系が大掛かりで製品化は難しそうだけど？ (NEC 梶原さん)
パッケージに入れるような場合には、チップ自体からレーザーを出して反射させるようなやり方もありで、将来的にはもっとコンパクトに作れると思う。
[ 4コンテキスト光再構成型ゲートアレイによる高速再構成 ]
いままでに出せた最短の再構成時間は 41.7ns.
構成を高速化するにはコンテキストの輝度を高くするのが簡単。単純にこれをやるのは高出力レーザーだが、かわりにコンテキストの明点のビット数を減らすことにした。電力と過熱の問題を回避できる。
反転フォトダイオードを用意して、コンテキストのビットをぽちぽち書き換える方式。
He-Ne で全体を構成し、半導体レーザーで部分再構成。
10コンテキストあったらすべてのコンテキスト間での遷移の差分 (90パターン) を用意するのは大変じゃない?
実用的には LUT のパターンを書き換えることが多いだろう、ということでこうしている。
全体を書き換える方法ももちろん考えています。
[ FPGAを用いたストリーム処理に基づくステレオ画像の特徴点抽出法の検討 ]
小栗先生。
ストリームによるリアルタイム処理で観測・認識・動作を一体化する。
ロボットビジョンでは「とりあえず」メモリに全部データをおく、というのが前提になっちゃっているんだけど、これをやめましょう。カメラからの映像をそのままストリーム処理で分析して、カメラの位置を変えたりする。
メモリのバンド幅の問題とかがないのでいい感じの実装ができた。
記憶がない、というのは無理なんだけど、ランダムアクセスなメモリ (画像とか) には貯めない。シフトレジスタとか FIFO が基本。
こうするとすごく電力が減ると思うんですが、どれくらい効くかわかってますか？ (奥山先生)
まだいろいろなものが一桁くらいいけると思うので、これからやろうと思います。
[ An Approach for Downscaling Images for Real-time Pattern Detection ]
VGA 以上で実時間処理。100MHz で 10 clk / pixel くらいが目標。
さまざまなサイズのパターンを検出しなければならない。
テンプレートをサイズをかえて用意する? 拡大縮小する? 後者にしました。
テンプレートの縮小は平均画素法。n/m 倍に縮小する時に、n 倍に拡大してから各画素の平均をとりながら 1/m する。計算量は大きいが劣化は少なくて済む。
外部メモリをひとつ使用。
XY 別々に拡大縮小できるので、ななめに撮影されたものにも (ある程度) 対応できる。
縮小回路は 2084 slices! (パターン検出回路はまだない)
いいね。
毎回テンプレートを大きくしたり小さくするのはなんで？ (柴田先生)
システム全体を小さくしたいので。
回転は？ (柴田先生)
パターンを回転させると、w x w のパターンについて w^3 あるので、ちょっと大変だなー、と思っている。なんとかしたい。
[ How fast is an FPGA in image processing ? ]
FPGA と最新のマイクロプロセッサの性能比較。
フィルタ・ステレオビジョン・K-means clustering. どれも演算量は多いがわりと簡単で HW 化が有効。でも、SSE3 で
128bit に対する SIMD も毎クロックできるようになった。
FPGA による速度向上率は残念ながら 5-15 倍程度で、マイクロプロセッサでも 30fps の処理ができるようになっている。
電力とかの評価は今後。
ただしFPGA 側はボードが古くて、メモリとかがあれなので、もうちょっとなんとかなるかも。メモリの性能は重要。
プロセッサと FPGA のプロセス・チップサイズを揃えたりして評価するのが重要かも (渡辺先生)
でもそういうデータは手に入らないので、気軽に買える程度、というところで揃えている。
Core2 じゃなくてグラフィックプロセッサを使ったりすると厳しいですか。DSP とか (安永先生)
GPU はクセがあるのでどうだか (乗るか乗らないかもあるし) わからないが、負ける問題は負けるかもしれない。
DSP も... Core2 がこんなに速いとは思いませんでした。
CPU のほうの開発も SSE なんかが入って大変だと思いますが、開発時間はどうですか
両方ともけっこう大変。個人差もあると思うが。
[ An implementation of a watershed algorithm based on connected components on FPGA ]
丸山先生連続でご登壇。
もともと降水の様子をシミュレーションするアルゴリズム。画像処理にも使える (というか画像処理に使う)。
外部メモリの使い方が肝。
ソフトに比べるとどうなんすか? (ふんがさん)
まったく SIMD とか使わないのに比べると x50 とか。SSE とか使われると怖いなー。
[ 複数FPGAを有するシステムでのOS機能の試作と評価 ]
SW/HW 協調処理システムで、マルチユーザで FPGA を使うようなシステム。
HW task 間での通信をサポートするような機能はある？
ありません。
いっぱいタスクがある時の context switching は？
ないので、使っている SW task が終わるまで待つしかないです。
[ 動的再構成可能ハードウェアのコンテキスト仮想化手法 ]
DRP なんかでも、コンテキストの数には限りがある。
コンテキストの遷移シーケンスをプロファイルして、統計情報をコンテキストグループの生成に使用する。分岐予測みたいな感じ。同時に入れるコンテキストをどうセットにするかで、コンテキストを外部メモリとの間で詰め替え直す回数が変わる。
遷移プロファイルがデータに依存しないようなアプリケーションでは静的にやれる。大きく変わるような場合は動的な判断が必要なので、ちょっと考えないといけない（＝次の発表)。
prefetch はしていないの? 評価は LRU と比べているが、理想はどんなものかしら (佐藤さん＠日立)
prefetch は、まだしてません。LRU とプロファイルを組み合わせるような方法を考えたい。
制約コンテキスト数、というのはグループの大きさ? 大きいほうがいいの? (ふんがさん)
やたら大きくすると余計なものがグループに入ってしまうので、必ずしもそうとは限らなくて、大きくすると逆に遅くなることがある。LRU だとそういうことはないけれど。
[ 動的再構成可能ハードウェアのコンテキスト仮想実行支援機構 ]
コンテキスト番号の論理物理変換を導入。全体のクリティカルパスがながくなってクロックが遅くなる (変換のところをパイプラインにすると、切り替えにかかるサイクル数が増えちゃうからダメなのか、やっぱり)。
それは悲しいので、コンテキスト内多状態のように変換テーブルを使わないローカル制御部もつけた階層化バージョンも用意。
コンテキスト間遷移確率 (P) を下げる努力は合成の時にしなければならない。たとえば、ループを回るたびにスイッチしたりすると、それは大変。
JPEG decoder: P=0.3~0.5
Turbo / Viterbi decoder: P <= 0.0003
結構違うんだな。
所用サイクル数をはかると、仮想化だけより階層化をいれたほうが多いのだが、クロック周波数を考慮すると階層化したほうがよい。階層化まで入れた場合、仮想化なしとほとんど同じ実行時間になり、オーバーヘッドを抑えられる。
分岐予測やプリロードはこれから。
viterbi や turbo はだいたいひとつのコンテキストに入るからPが低いの？ (ふ)
はい。だいたいコンテキスト内多状態で回ってます。
分岐がいっぱいあるようなものだと、コンテキスト内でがんばる、ということができないので、P は悪化する。
[ FPGAを用いた生化学シミュレータにおける入力ポート制約を考慮した演算パイプラインスケジューリング ]
もりりん。
スループットを上げたい、ということだけど、レイテンシを重視しているの? (梶原さん)
連立微分方程式なのでもげもげ。
レイテンシでなくて、後続ノード数でやっているのはどうなんですか?
レイテンシをクロック数でちゃんと数えてやると、自由度が下がっちゃってうまくいかないことがある。きちっと検証したわけではないが、ある程度自由度をもたせるためにこれでもいいのかも。
[ 複数のFPGAを用いた高性能流体解析システムの検討 ]
もりしー。
15桁一致でいいよ、というのはアプリケーション的に十分なの？ (谷川先生)
倍精度でいいんだけど、このモジュールだけで評価するのはまだ不十分かな
斜め方向にするのに着目したのが性能向上の決め手？ （jaist 佐藤先生)
そうですねー
[ リコンフィギャラブルプロセッサを用いた複数の拘束長に対応したビタビ復号器の設計と実装 ]
BER がどれくらいになったら拘束長をかえる、ということなら正解がわかってないといけないですよね? (泉先生)
うーん。訂正符号だから分かるのか??
送り側と受け側で拘束長の情報は共有しないといけないのでは? (柴田先生)
そういう設計になっています。
実際に使われている拘束長は? (黒田先生)
3から7くらいかが使われているんだけど、6以上はコンテキストに入りきらなかった。
全部パイプライン展開してる? ループくるくる? (泉先生)
いまのところ全部空間展開してます。
これ以上拘束長をのばしたりするとループになるが、損益分岐点みたいなのはかわる?
わかりません、、、