HyperFFT回路を実機で動かしてみて心境の変化

シミュレーションで正しいとわかったので、ハードウェアFFTを実際のFPGAにインプリメントしてみました。

FPGAにロジアナコアを入れて、JTAGで見た実機の信号と、シミュレーション時のパターンが完全に一致しました！

これはうまくいっているかも・・と喜んだのも束の間。

同じデータを変換しても、たまにビットが変わることが確認されました。

どうやら、スピードグレード-1のFPGAをスピードグレード-3として論理合成していたので、実際にはスピードが間に合っていなかったと思い、検証を続けていたのですが、どうやら原因はそれだけではないことがわかってきました。

FFTエンジンを回すと、Linuxがいきなりカーネルパニックしたり。まだメインメモリにはアクセスしていないから、Linuxは関係ないはずなのに・・

どうやら、原因がわかってきました。

この回路は、Radix-8のバタフライ演算を1クロックで計算するため、216個のDSP48Eが400MHzで動いています。すると消費電力がハンパない。

BRAM216個だったら全然驚かないのですが、DSP48Eが216個はかなりきます。

SLICEやBRAMとは比べ物にならないほど電流を食うのかもしれません。

発熱でさらに電力が増えると、電源電圧が低下する。

どうやらこのFFT回路は、今までにCosmo-Zで作ったどんなデザインより消費電力が多いようです。狭い基板に詰め込みすぎて、電源が足りなくなって全力が出せない。まるでU.S.S.ディファイアントのような基板です。

クロック400MHzで動かして51.2μ秒で計算するというのはあきらめました。

ハイエンドなFPGAには乗算器いっぱい(数千個とか)あるから、これを有効活用するためにDSP48Eを全力でぶんまわす数値計算アプリを作ろう！という考えは正しくないと思えてきました。

自分の中で何かが変わりました。GPUとFPGAのどっちが速いかなんてことを考えるのはあまり意味がありません。結局は電力です。

クロック上げてDSPいっぱい動かして最高速度を極めるよりも、クロック下げて広い面積で処理したほうが、同じ性能でもトータルの消費電力をされられるかもしれません。

これからはエコ設計でいこう。

ワットあたりの処理能力というのを追究してみたいと思う次第です。

結局、クロック250MHzで動かして、ちょっと遅めの82μ秒で計算することにしたら、電源も発熱もかなり落ち着いて安定しました。