月別アーカイブ: 2008年9月

Virtex-5: PCI express endpoint block plus

東京エレクトロンデバイスの Xilinx Virtex-5 + PCI express 評価ボードを持っているわけだが、このたび自前で ISE のプロジェクトを起こして、Virtex-5 に載っている PCI express endpoint block を使ってみた。意外と簡単。
– Core generator でパラメータを適当に設定して core を作る
– そのままだと BAR0 に 2kB の Block RAM が割り当てられる。とりあえずそのままで問題ないし、容量を変えたりしてもよい
– example_design というディレクトリにあるソース (.v でも .vhd でも) を片っ端からISE のプロジェクトに放り込む
– ピン配置は概ねそのままでよい。4 レーンのインタフェイスで使うことにしたのだが、変更したのは PCI express のコネクタからとるクロックの入力ピンだけ
これで、ふつうに Linux や FreeBSD で scanpci すると見えるようになる。すばらし。
ちなみに、以前 iMPACT を Linux で使おうとしていろいろ苦戦したのだが、結局のところ最近のカーネルを使っている人は libusb を使えばいいらしい。Xilinx の answer #29310 の通りにやって、楽勝だった (libusb は普通に入っていたので、インストールのところはすっ飛ばしたけど)。ただし、Xilinx の説明だと libusb だけ入れればいいように見えますが、fxload というのを入れないと firmware をロードするところがうまくいかないので、要注意 (新しく SuSE 11.0 を入れて、ここではまった…)。
とりあえず PIO でいいなら、BlockRAM のところを何かに置き換えればいいね。
今日は Linux の /dev/mem 経由でアクセスして遊んでみた。明日から何日かかけて勉強して、簡単なドライバを書く予定。

紅茶 @ 吉祥寺

職場が移って、まだお茶をいれる環境ができあがっていないのだけれど (それより大事な計算機 + ネットワーク環境の構築でえらく手間取っており、研究がスタートできない…)、吉祥寺の紅茶事情をちょっとサーベイしてみた。
いままで茶葉は主に代官山か仙川の Lupicia で買っていたのだけれど、代官山は平日は無理だし、仙川は家と同じ市内なんだけど、時間が合わないのでね。でも、Lupicia は吉祥寺にはないみたい。岡山にはあったのにね(笑)。
でも、ちょっと調べたらダージリン専門店のLeafull (この間友人にもらった) とか、いろいろなお茶を扱っている GClef とか、いろいろあるみたい。時間を見つけて行ってみよう。

四国初上陸

岡山に行ったので、勢い余って瀬戸大橋を渡ってきた。四国初上陸2名、経験者1名。
IMG_0085.JPG
与島のサービスエリアから。
IMG_0086.JPG
うどん!
IMG_0087.JPG
うどん!
結局2時間で4杯食べて、おなかいっぱい。讃岐うどんはいいね。また行こう。

RECONF / Sep. 26, 2008

[ 科学技術計算エンジンに使用するディジットシリアル浮動小数点演算器の開発 ]
多倍長演算器を構成するために word parallel ではなく、digit serial の演算器を作った。面積では圧倒的に小さくなるはずで、面積あたりの性能では、高精度の場合に DS な FP ALU のほうが有利になると考えられる。
作ったのはまず、 DS な integer multiplier と divider (これが一番大きな面積を占めるので)。 それを使って FP ALU を作った。デバイスは Rohm 0.18um.
面積あたりの FLOP 数は word parallel に比べてちょっと下がっちゃったが、まだ合成だけでレイアウトをしていないし、レイアウトをすれば word parallel が悪くなるかも。
10進演算器にも応用できる? (井口先生) → できると思うがまだ考えてません。
入力がすべてくるまで中の処理ははじまらない? (天野先生) → 指数部、仮数部、符号の LSB から入れるようにして、最初のデータがきたらすぐスタートするのだが、入出力に数サイクル掛かるのは仕方ない。
バレルシフタは所要サイクル数がデータに依存すると思うが、それによって性能が変わったりはしないの? → worst case に合わせて設計してあります。
乗算器は 1 クロックでやってるの? (泉先生) → DS でも word parallel でも、パイプラインにはしていません。
パイプライン化したらどうなる? → word parallel のほうは性能があがると思うが、入出力のポート数が少ないアドバンテージはかわらないので、そこはいいかなと。
消費電力が下がったりはしませんか? (梶原さん) → 検討させていただきます。
[ 粒度可変論理セルにおける入力粒度最適化の一検討 ]
熊大の学生さん。
VGLC (Variable Grain Logic Cell): ALU と LUT の hybrid cell.
VGLC は複数の BLE (Basic Logic Element) から成る。BLE は LUT と同等のランダムロジック表現と、misc logic という、より入力ビット数の多い (ただし論理関数空間のカバレッジが 100% ではない) 論理関数表現モードを持つ。
BLE の入力数 (入力粒度): ひとつの BLE に実装できる canonical form の入力数を変化させる。
たとえば、
入力数2: 2-LUT と同等の機能、4-misc logic まで実装可能
入力数3: 3-LUT と同等の機能、5-misc logic まで実装可能
のような感じ。
MCNC benchmark で評価。粒度を大きくすると当然使用論理セル数は減少するが、それ以上にセルの面積増加が深刻になる。また、あまり粒度を大きくしても論理セル数の減少は緩やかになって、悲しい。これは、入力ビット数が増えると misc logic で表現できる論理関数のカバレッジが急激に下がってしまうので使用される機会が減ることに一因がある模様。
でも、入力数の多い CF はメモリ使用率の向上に効く。
Elias Ahmed and Jonathan Rose: “The effect of LUT and cluster size on deep-submicron FPGA performance and density” (IEEE Trans. VLSI)という論文が要チェック。
BLE の粒度がかわると BLE の遅延が変わったりはしないの? (谷川先生) → すこしかわるけど、それほど大きく変化しないはず。
Misc と CF とどっちを優先して technology mapping する? (泉先生) → HeteroMap をもとに作っている。基本的に段数最適化。
[ 動的リコンフィギャラブルプロセッサ MuCCRA-2b の実機評価 ]
動作中の LSI は AC 成分がいろいろあるわけだが、テスタで測った電力はどれくらい正確だと思っている? (泉先生) → まあ、桁がわかっている程度かと
画像が乱れた、というのは目で確認している? → はい。いちおうロジアナでも見てますが。
複数PE分を時分割で emulation していて、配線相当分が入っていないと考えていいですか (梶原さん) → はい。でも、PE 内のは入ってます。
最高動作周波数は I/O が絡む形でやっている? (渡辺先生) → 実機評価ではメモリが外にあるので、I/Oも入ってます。FPGA の I/O 遅延も入ってしまうけど…
開発環境は -2 と -2b で同じ? (谷川先生) → 同じコンパイラで作って、(コンテキスト配送がいらないのでそこのところを) ちょっといじってる。
[ ソフトコアプロセッサの高信頼化に向けた三重冗長実装の一検討 ]
一宮さん@末吉研。
Permanent error: LUT, interconnection, RAM などで起きる SEU
Transient error: FF で起きる SEU
MicroBlaze を3つ並べて voter をつける。でも、voter をつけると CP が長くなるらしくて、2割くらい動作周波数が落ちるのと、メモリを3倍食う。
メモリは 3 つの MicroBlaze で共有することで解決するが、さらに 25% 周波数が下がり、オリジナルと比べると 41.5%…
性能を稼ぐためにキャッシュを使うアプローチも。BRAM をキャッシュとして使い、メモリは外部の DDR SDRAM. この場合は voter が DDR SDRAM コントローラの手前に入る。動作周波数はかなりいいが、SDRAM コントローラが大きいのが問題。
メモリは TMR で一番重要だと思うんだけど共有しちゃっていいの? (渡辺先生) → ECC とかあるので、いいかなーと。
SEU の試験方法に何かいいのはある? → bit file を壊してみるとか。
キャッシュを共有してvoter を入れる、というのはどうでしょう? (谷川先生) → MicroBlaze からキャッシュを切り離さないといけないので、ちょっと難しいかもしれません。
[ 書き換え可能ハードウェアを用いた体故障性能向上手法の研究 ]
山口さん。
(面白いネタをたくさん仕込むぜ!と意気込んでおられたのでばっちり録画しました。うひひ)
[ 再構成デバイス MPLD への組み合わせ回路マッピング手法の検討 ]
小田さん@広島市立大。
MPLD は他の PLD と基本構成が全然違うので、マッピングツールが必要。
コンフィギュレーションはメモリへの書き込み動作と同じなので、高速。
メモリとしても PLD としても使える。
基本要素は MLUT で、基本的には LUT と同じ機能で、DP-RAM の片方のポートをメモリ動作用、もう片方を LUT 動作用にしている。配線は固定されており、MLUT がスイッチにもなるようだ。
テクノロジ非依存最適化のところは design compiler で、2入力以下の素子しか使わないようにやる。テクノロジ依存のところ+配置配線は自前。
配線4のときは PCA の Plastic part だ! 1 bit adder とかシフトレジスタみたいに並べられるものはいいけど、配線のほうが大変じゃないかしら。論理を削減しようとして頑張っても、配置配線のほうがずっと重要になる可能性が高いと思います (泉先生) → 今回はそれほど詳しく説明してませんが、次回お楽しみに。
ひとつの MLUT のサイズは? メモリとして作ると、ある程度大きい方が効率がいい (井口先生) → 6 入出力対なので、2^6 x 6
実装例が adder とかなので、算術演算以外の (きれいじゃない) ものもやってほしい
かっこいいんだけど、配線が全部メモリを通るのはちょっと実用的にしんどいかもしれない (ふんがさん) → 実は検討してます。
あと、入出力の数が同じ、というより、入力のほうが多いのが自然かも。

RECONF / Sep.25, 2008

[ FPGA を用いた2次元液体運動シミュレーションの高速化 ]
会津大の佐藤さん (チームオクヤマ)。
無衝突系重力多体問題のベンチマーク
– Cell 125GFLOPS
– GeForce8800 653GFLOPS
– GRAPE-7 728GFLOPS (Altera Cyclone)
PROGRAPE-4 を使った。
必要最低限の演算精度の見極め。
格子を使う差分法やFEM と、ラグランジュ的に必要に応じて粒子を発生させる Smoothed Particle Hydrodynamics (SPH) 法などがある。災害シミュレーションのような、大きな形状の変化を伴うものを想定して後者を使った。粒子間の相互作用として水の動きを計算することができるが、精度を高くするためには粒子の数を増やす必要があり、計算量がしんどくなる。
2次元ダム崩壊問題を、double と 仮数部 12, 14, 16, 18 bit with 8bit exp の5つの演算精度で解き、平均自乗誤差 (MSE) で評価。仮数部 16bit で充分な精度が得られた。
(質疑)
転送はどれくらい?→ 転送オーバーヘッドを隠蔽するために粒子を使い回すようにする。一度 broadcast memory に入れたものを particle register に入れたり。水の場合は重力多体問題より狭い範囲で相互作用するので、3割くらい。
精度検証はどうやってやった? → 仮数部を AND でマスクします (うお、そうか! それなら僕らにもできそうだ・・・)。
粒子が増えたりすると必要な演算精度はかわる?→ 単純に粒子数を増やしても必要な演算精度はかわらない (指数部は必要になるかも?) が、粒子がどこまで近づくように定義するかで仮数部の必要ビット数が変わる。
ひとつの FPGA にふたつのパイプラインが載っているということだが、どれくらい演算器がのっていて、どれくらいほしいと思っている? → 理想は4パイプライン。
[ 動的再構成可能プロセッサへの JPEG エンコーダの実装と評価 ]
岡山大の古島さん (名古屋先生の学生さん)。DAP/DNA-2 に実装。DNA (reconfigurable array) に実装したのは次のふたつ:
– RGB → YCbCr 変換。Cb と Cr は情報量を落とす : 1面に4並列
– 2次元 DCT (2回の 1次元 DCT で実装。バタフライ演算) : 3面に2並列
再構成とかの制御オーバーヘッドがあるので、ふつうの CPU と比べた場合には、画像が大きい方が有利になる。でも、色変換と DCT 以外のところをやる DAP がボトルネックっぽい。エネルギー効率は x25〜52 (compared to Pentium4)。
(質疑)
どうして表色系の変換と DCT を選んだ? → ハフマン符号化とか量子化のところはメモリアクセスが複雑で、そこが DNA に向かない気がしたので。
DCT の実装が 3 つの構成情報にわかれているが、どうやって分割しているか? → バタフライ演算の4ステージが2面に分かれている。それをそれぞれ2回使って縦横でやる。
[ FPGA を用いた生化学シミュレータにおける… (以下略) ]
[ 分散共有メモリの接続を変更可能な PC クラスタ用 SW の提案 ]
必要な資源のみを結合する疎結合型の PC クラスタ。
問題の性質によって結合を変えることができれば、資源効率のよいクラスタ構成を実現できそう → 可変構造型ネットワーク。
まずは DSM をターゲットにしてみることにした。アドレス変換による仮想共有メモリ。
基本的に固定経路で、疎行列計算とかに向く (はず)。
Switching fabric を小さくしつつポート数を稼ぎたいのか? でも実際のところ、最近の問題はもはや、充分なサイズのクロスバがチップに載らないということではなくて、ピン数なんじゃないのか? とか思ったので、一応突っ込んでみた。
でも、データの使用頻度を考慮したインタコネクションというのは面白そう。
[ レーベンシュタイン距離を用いた道路標識認識アルゴリズムの FPGA 実装 ]
ITS: automatic cruise control とか lane keep system が実用化されている。
より高度な動画像認識として道路標識認識システムとか。
標識の切り出しがずれても認識は大丈夫! という仕掛けにしたいぜ。そこでレーベンシュタイン距離 (いわゆる edit distance みたいなやつ) を導入。
赤色・青色分解をしたあとに文字列変換して、テンプレートマッチング。
テンプレートマッチングは2段階。大分類 (丸とか四角とか三角とか) でまず分けて、そのあとに細かいテンプレートにあてる。
標識の数は同時にどれくらい? → いまのところひとつでやっているが、現実には複数の標識が一枚のフレームにでてくることはありうる。現在の処理時間は標識ひとつだけの場合。
車載カメラで撮ると歪まない? → わりと tolerant ではあると思うんだけど、前処理でなんとかしなければならないかも。(わし思うに、歪むのは広角のレンズで近くの標識を撮るような場合で、しかしそんな近くの標識を認識してなんかいわれても運転者は困るわけで、認識の対象はある程度遠くの標識でなければならないのではないだろうか。そういう場合にはゆがみの影響はないよね)
[ FPGA による並列計算機用2次元ネットワークの実機評価システム ]
岡山大の小畑先生チーム。
ネットワークの動きは、シミュレーションではわからないこともある (と、RHiNET-2 の論文に書いてあるらしい :p )。そこで、torus だの mesh だのをいろいろ試すためのシステム。
FPD (DVI じゃない、ちょっと昔に見かけた液晶用のコネクタ。組み込みではいまでもつかってるのかな?) のケーブルを 4 リンク使える NIC. データを記録するための global clock / reset も備える (これは通信には使わない)。
API としては、MPI のサブセットを実装。
ちゃんと並列プログラミングしたりして評価もとっており、手堅い仕事だと思う。楽しそう。
[ FPGA クラスタのためのオペレーティングシステム機能の試作 ]
広島市立大。
従来はバスによる密結合型 FPGA クラスタを扱っていた。今度は Ethernet (通信) と USB (configuration) を使った疎結合型 FPGA クラスタを構築。誰でも簡単に構築できるシステム。性能よりプログラム資産の構築を追及。
制御用独自プロセッサは 16bit で、Picoblaze より強力かつ Microblaze よりは小さい。
[ 招待講演: オペレーティングシステムとリコンフィギャラブルハードウェア ]
谷口先生。
OS には常に性能が求められているので、ハードウェア処理による性能向上を考えたい。
OS の性能低下要因: ディスク I/O とメモリ間データ転送 = 何かを作るわけではない操作なので、どちらも本質的には必要ないはず…
他にもいろいろあるのだが、なんかすごかった。

今日の自転車

19日付で職場が変わったのだけれど、その関係でずっと忙しくて、全然自転車に乗ってなかったのだが、こんどの職場も圧倒的に自転車のほうが速いロケーションなので、休日のトレーニングも兼ねて自転車で行ってみた。
往路は道を間違えたりなんかしたが、35分で到着。復路は30分くらい。電車だと乗ってから降りるまでがそれ以上かかる感じなので、家から駅までと駅から大学までを考えると、断然有利ですね。しかも、僕の研究室は正門から歩くよりも、駐輪場の隅からのほうがアクセスがよいので、トータルだと全然違ってくる。
というわけで、自転車通勤再開の日は近いぞ。
21.51km @ 23.0km/h (56m05s) odo 5452.9km

FPL ’08: Day 3

[ Synthesis ]
#1: Floating Point Datapath Synthesis for FPGAs
Altera の人のプレゼンテーション。
Floating Point Compiler
データパス上で必要な値域や例外は予測することができるので、すべてのノードを IEEE754 に従わせる必要はない。新しい浮動小数点型を定義して、それを使う。正規化と例外処理はしない (例外検出は行い、それは次のノードに送る)。正規化とかしないのは、バレルシフタがやばいから。
– 200+ MHz double precision: 50GFLOPS – 3SE260
– 250+ MHz single precision: 100GFLOPS – 3SE260
やっぱ演算器は作らなきゃいけない、ということだね。ちょっと参考になりそうだ。
#2: Automatic Generation of Run-time Parameterizable Configurations
TMAP: Tunable LUT mapping
FIR フィルタとかの係数をレジスタに書いて演算器で処理する形式から、決めうちにした回路に reconfiguration して使う方法。
– 1999LUTs → 1008LUTs
– 8.4MHz → 11.9MHz
いいんだけど、configuration に時間が掛かる上に、構成情報のデータベースが大きくなるのが問題。これを、うまく coefficient に関係するところだけランタイムで作ってなんとかする話。
– 1301LUTs, 11.5MHz
VHDL に annotation を入れて、それを合成するようなツールを開発。
#3: Generation of partial FPGA configurations at run-time
動的再構成するモジュール間を Bus macro みたいなので、つなぎかたをきめてしまうのではなくて、route table をもつ共通のインタフェイスで接続することで簡単にする。
Route table がもつのは、
– connection ID: relative coordinates of the endpoints
– route specification: list of frame and bit indices of all sw points in the route
– incompatibility information
そんな感じ。
[ Optimization ]
#3: Memory access parallelization in high-level compilation for reconfigurable adaptive computers
Adaptive computing system: CPU + reconfigurable hardware
高位言語からの合成に関する研究の多くは科学技術計算 = regular memory access, loops with constant bounds, perfectly nested loops がターゲット。そうじゃないものを扱うのに問題になるのは、ポインタ。
control flow graph を作って、activate token と cancel token を使う。Token を使うことで依存関係を壊さずにメモリアクセスを並列に行ったり、serialize したり、speculation したりする。

FPL ’08: Day 2

Keynote 3 は 8:30 から… 無理です。
[ Compilers for Reconfigurable Architectures ]
#2: CHiMPS: A C-Level Compilation Flow for Hybrid CPU/FPGA Architectures
Xeon のソケットに挿す FPGA をターゲットに考えている。
Spatial DFG にして並列性を抽出してハードウェア化。
どこを HW に落とすかは pragma を使って指定する。あと、ポインタをほげほげする restrict というキーワードがある以外は、ふつうの C 言語。
メモリからとってくるデータをキャッシュするためのメモリをたくさん用意する。これでレイテンシを下げたり、競合を減らしたりする。キャッシュの一貫性を維持するプロトコルはちゃんとやるとコストが大きいので、書き込みができるのは一度にひとつだけ。Direct mapped cache.
うーん。C から design entry する限りは結局、キャッシュとかそういう Von Neumann の呪縛からは逃げられないのかなー。
小さいキャッシュがたくさんあると、それをメモリコントローラにつなぐところが大変じゃない? →そうでもないぜー
マルチコアとの関係は?→ それもやりたいね。あと、浮動小数点関係とかね。
#3: Combining Data Reuse Exploitation with Data-Level Parallelization for FPGA Targeted Hardware Compilation: A Geometric Programming
Memory subsystem と loop level parallelism の co design.
どの loop nest level で使われるデータ化で、off-chip にするか on-chip にするかをきめる?
むー。こういうことは考えているのだが、この研究のように定式化するところが難しそう…
メモリの使い方でクロック周波数はかわる? → 変わるけど、サイクル数のほうが実行時間に対して支配的。
[ Random # Generation & PLL ]
#1: Sampling from the Exponential Distribution using Independent Bernoulli Variates
固定小数点の、指数分布の乱数を作る方法。exp() を使わないで高速にやる。
よしみさんが cite されてた。
将来的には fixed-floating conversion を使わずに、直接に浮動小数点の値を出せるようにしたい。
#2: Enhancing security of ring oscillator-based TRNG implemented in FPGA
ring osc を乱数生成に使う場合、電源からのノイズとかがけっこう問題。気をつけましょう。気をつけて実装すれば deterministic jitter はけっこう減らせる。
[ Tutorial: Virtex-5 FXT: A new FPGA platform ]
Virte-5 FXT: has PPC440 instead of PPC405. Super-scaler, larger caches, deeper pipeline.
Not just a PPC440, but with: 5×2 crossbar connection, memory interface, 32bit DMA, user defined instruction (by APU), single/double IEEE-754 compliant 128-bit FPU (soft core) …
GTX high-performance transceivers: 150Mbps to 6.5Gbps
Power dissipation = 250mW / channel or less
TXT Family: FX without PPC, but twice # of GTX transceivers. ES 4Q08, MP 1Q09.
8 to 24 transceivers for FXT family, 40 to 48 in TXT family.
Device availability の保守についてはどう考えている?
XC3000 は 15 年前の製品で、まだ売ってるけど、いまからデザインするならば新しいのを使いましょう。1年の FPGA の進歩は人間の15歳分だよ!
でも、binary compatible にすることは考えていません。
[ High performance Computing for Financial and Biological Modeling ]
#1: FPGA Acceleration of Monte-Carlo Based Credit Derivative Pricing
single/double precision floating point の hybrid design とかをしているところが面白そう。構成のおもしろさでは 443 さんの仕事のほうがずっと上だな。
#3: Acceleration of a Production Rigid Molecure Docking Code

FPL ’08: Day 1

[ Opening Keynote ]
FPGA is the programmable platform for Transforming, transporting and computing digital data.
Triple play opportunity:
– DSP
– Packet processing
– Tera computing
Network Trends:
– Global IP traffic will reach 44bn gigabytes / month in 2012, while less than 7bn in 2007.
– Video goes 22% of consumer traffic in 2007, will be 90% in 2012.
– Mobile data traffic will roughly double each year from 2008-2012.
→ focus on reducing power consumption to reduce operating expense.
Stanford Open Slate Program
– Programmable Open Mobile Internet
– 25 Stanford inter-disciplinay faculty + Cisco, Deutsche Telekom, DoCoMo, NEC, Xilinx
Virtual operating system is available: next step is virtual network!
– High speed / reliability / security : various demands
– packet level reconfiguration !?
そのほかいろいろ
– Packet based on-board interconnection
– MIMO, Multi mode radio とかは信号処理の量がヤバい
– Heterogeneous multiprocessing: Intel + FPGA (on FSB)
University Program:
– XUPV5-LX110T
– 周辺回路もりだくさん。PCIe もついてる。やべえ、楽しそう
– OpenSPARC evaluation kit も…
[ NoC session ]
#2
Coarse grain reconfigurable architecture + multistage interconnection
Good old MIN!
2-input 2-output だけど、大きいのは考えなかった? → そのうちねー
#3
many core なシステムへ向けたお話。
programmable router より NoC のほうがいいよ、みたいな。
なんか、両方ともわりと普通の話だったので、ちょっと残念。
[ Keynote #2, FPGAs at CERN ]
CERN では加速器のまわりの、大量の検出器からの信号を処理するのに FPGA を使っている。加速器なので、当然ヤバい粒子がいっぱい飛び出すわけで、radiation がすごいところは古いチップ (Virtex-II Pro とか) を使ってエラー率を下げるみたいな話しも。
[ Image & Video ]
How fast is an FPGA in image processing?
この間の RECONF で聴いたお話とだいたい同じ。ソフトウェアは Intel C++ 使って評価してるのかー。いいかも。
SIMD はプログラミングが大変だといっていたが、使わなかったら speedup はどうなるか? → 測定してない。プログラミングの得意な学生が実装しました。
DSP とか GPU を使わないのはなぜ? → intel のプロセッサはみんなが持っているから。
FPGA Hardware Acceleration for H.264 Motion Estimation
フレームを16×16 のブロックに区切って、SAD が最小になるところを見つけ、motion vector を求める。
256 subtraction+accumulation / SAD → 96giga / sec.
H.264 ではブロックのサイズをフレーム内の場所ごとに選べることと、複数のフレームを reference として選べる (鳥が羽ばたいたりとか、そういう periodic motion をうまく扱えるようになる。たいていの実装では 4 つの reference frame を使う) ことが違う。計算量は 4 倍ちょっと。
1.5 giga macro-reference block access / sec。メモリアクセスも最適化しないとやばい。
Real Time Image Super Resolution on an FPGA
Imperial College のひと。うおー超解像だ!
複数の低解像度のフレームから高解像度のフレームを合成する。
Frequency domain approach と spacial domain approach がある。やったのは後者 (だと思う)。
1. Motion Estimation
2. Image Reconstruction
3. Image Quality: Deblurring, Denoising
ハードウェア処理に適した SR アルゴリズムを開発した。2, 3 を実装している。
XC2V6000 で 1280×720, 61fps 出る。いまのところ、ふつうの HDTV にはこれで充分だし、FPGA のリソースを全部使い切っているわけでは全然ないので、もっと小さいのでも載りそう。一番必要な資源は multiplier. 固定小数点だが、浮動小数点による実装と比べて目に見える違いはない。