RECONF2005 65-68 (Dec.01: Architecture II)

意図せずして最初のをサボってしまいましたあうあう。

意図せずして最初のをサボってしまいましたあうあう。
日立の動的再構成なデバイスに関するセッション。

構成情報の階層記憶制御による再構成型プロセッサ FE-GAの性能・面積比の向上

演算セルアレイ(ALUセル、MLT(乗算/MAC)セル、基本的に16bit) はクロスバを介してLoad/Store セル・ローカルメモリに接続。コンフィギュレーションマネージャを外部(といってもチップ内部)に持ち、セルの類似性を利用して構成情報を圧縮することで構成情報のサイズを 1/5 くらいまで落とすことができる。圧縮しないと構成情報の転送がボトルネックになってしまう。構成情報はバックグラウンドでロード可能。

Q & A

IPFlex 佐藤さん: 構成情報のサイズはどれくらい?公表できれば教えてください
→ALU, MLT セルの構成情報は 96bit とか。予稿にでています
久我先生@熊本大: 16エントリくらいが面積効率的な落としどころなのか、増やすとどうなるか
→階層化することでそれくらいでも性能が出せるようになった、と

再構成プロセッサ FE-GA のオーディオ処理への応用

AAC 128kbps, 2ch, 44.1kHz のエンコードをシミュレータ上で実行。シミュレータの演算のところは cycle level accurate、制御系は functional level.
102MHz で 8 倍速AACエンコードを実現。FIR とか DCT で、組み込み向け single MAC DSP の 10 倍くらい?
configuration を preload することで、4.8M cycle くらいかかるのが 32k cycle に。さらに圧縮することで、2k 回くらい入れ替えなきゃいけないのを1回にすることができた。
今後は開発環境も整備していく予定。

Q & A

NEC の梶原さん: ALUとMULのブロックが 3:1 で入ってますが、どんな感じで決めたかというのと、今回の実装でのリソース消費状況を教えてください。
→ ALU-MUL-ALU-ALU が8列ある構成は、ALUx4 7列 + MULx4 1列よりだいぶ使用効率が上がる感じでした。
早稲田の木村先生: Cのリファレンスコードからマッピングをされたようですが、loop unrolling とか、そういうtuningはどんな感じでやりましたか?
→ FFT はバタフライまで広げてから mapping. その他のアプリケーションでは 2、3重くらいのループをまんなかまであけて、あとはデータアクセスの順番をチューニングしたりとか
コンパイラを作る上で従来型のプロセッサと違うところは?
→ interconnection の制約のある 2 次元のアレイに、命令列を流し込むと 3 次元になるわけで、そのへんが難しいかも
末吉先生: VLIW の一種みたいなものですよね。接続が限られているうえにしかも non-uniform ですし、大変。アプリケーションひとつにどれくらいかかりました?
→ ふたりくらいで半年とか。ツールほしいです。
佐藤さん@日立: non-uniform なところに DFG をマップするのが大変。C のプログラムをうまくマップするのもやっぱり大変。その 2 点くらいと、configuration / data のロードを演算を止めることなく行えるようにするところのスケジューリングが難しいかな。ポインタを使って圧縮制御をするところも、静的にプログラムを眺められないような場合には、また大変です。
IPFlex の芝さん: Loop unrolling で carry dependency とかがあるとやばいと思うんですが、フィードバックとかの機構はあるんでしょうか?
→ DSP 関係では依存関係が複雑だったりするので、HPC な場合と違ってコンパイラ的には難しいかな。小さなループで依存関係がある場合は、チップの上でなんとかできるが、大きい場合には一度ローカルメモリに吐き出してから処理する必要があります。

再構成プロセッサ FE-GA 上への FFT へのマッピング

日立の佐藤さん。数学のご出身なのですね(かっこいい!)。
ALU-MUL-ALU-ALUな構成だが、右からも左からもデータが流せたりするので、MUL-ALU-ALU-ALU とか、MUL が3つめ4つめにあるような構成を取ることもできる。
基数2の Cooley-Tukey 型を、4×4 cell に入れて、FE-GA にふたつ載せる。
セル利用率 90.5% でサイクル数オーバーヘッドは 3.5%。

Q & A

トヨタITの方: FFTを効率よくするためにクロスバを導入したりしているようなのだが、アプリケーションを載せてみてアーキテクチャにフィードバックしたのはどんな点?
→ クロスバは最初から載せようか、という感じだったのだけれど、MUL をどの列に置くかをわりと自由にとれるような機構 (FFT では最初の行に置きたかった) とかを入れてもらった。あと、メモリから ALU に転送するときの遅延を自由にとれる仕掛けとか。
1k point とか 2k point の場合、基数を4とか8にすると思うのだが、基数が上がった場合に同じような実装で対応できるのでしょうか?
→ まあ、同じバタフライなので、なんとかなるんでないかと。途中で分割する必要はあるけれど。
飯田先生@熊本大: 4×8 というサイズはアプリケーションを作ってみて最適だとわかったのか、大きくしたり小さくする必要はどうなのか。
→ コアを複数接続することによるスケーラビリティはあるので大丈夫だと思う。ただ、いまのところマルチメディアな小さいものしかやっていないので、WLAN のようなのをやると難しいかも。

コメントを残す