lynxeyedの電音鍵盤

MBDとFPGAと車載で使うデバイスの備忘録

裏付けの無い開発手法とFPGA石器時代

FPGA/CPLD

それは10年前と変わっていないのか

以前の記事( 魔法のようなSoCはない - Lynx-EyEDの電音鍵盤 新館)に付け加えたい事があったのでちょっと書いてみました。

最近FPGAの図書がまた増えつつあるCQ関連ムックですが、
例えばコレとか FPGAスタータ・キットで初体験!オリジナル・マイコン作り
Qsysをつかってモジュールをマウスでバスにぶら下げる…はずが、なぜかHDLを１から書いて車輪の再発明していたりとか、ゼロから作る○○の様な記事が多い。

正直これらの記事を見てて、
FPGAってこんなに開発難しいんですか。該当するインターフェース乗ったマイコンの方が遥かに良いですね☆
という感想持たれてもしかたないのでは。


現在では各FPGAベンダで各モジュールをブロックの様にくみ上げて、最後にトップモジュールにインスタンシエートする機構を用意しています。ここにソフトマクロCPUがほぼ必然的に入ってしまうベンダもありますがｗ(コレについては結論参照)

使用可能ロジックギリギリで設計してしまったなら*1いざ知らず、なぜこのような機構を利用しないのでしょうか。


この根底にあるのは、紛れも無く
HDL書かない手法とか負けだと思うんだ
という圧力でしょう。


どこからの圧力？自分自身の内面からです。
残念ながら今まで培って来た(それも10数年以上)努力を否定されている様に思えるのでしょう。


この意見に対する反論は大まかに言って以下の通りです

  1. １から組めば理解できるんですっ！！！
  2. ベンダ提供のお気楽ツール使うと一つのFPGAベンダに依存してしまうことになり、他ベンダFPGAへの移植が困難
  3. どうせその手のツールはつかったところで動かない。だっていままでそうだったし

それに対する答えは要約すると以下の通りです

  1. 理解する前にハードルが高すぎて死ぬ。それに検証どうするんですか？
  2. え、その前にLUTオンリーなドノーマルFPGAってあるんですか？
  3. 今あなたは管理職なんですね。お疲れさまです


(1) １から組めば理解できる

この台詞、免罪符の如く良く聞きます。
たしかに個人の勉強にはなるでしょう。
例えばHDLで記述した条件分岐がどのような順序でセレクタを推論するのか分かっていた方が良いに決まっています。すこし事情が異なりますがC言語で開発するとしても、そのMCUのアセンブラを多少なりとも理解してた方が対処しやすいのと同じです。
もし、ベンダーが作成した機能モジュールのHDLが理解できないから自作する、という理由であるとすればもう少しHDLの勉強に時間を割くべきです。


加えて、作ったあとどうするのでしょうか？


FPGAで単一モジュールだけを動作させる事はまず無いでしょう。
例えばDRAMアクセスコントローラを入れただけでは、何の役にも立ちません。

  • このモジュールからデータを読み込む機能ブロック
  • 書き込む機能ブロック
  • この両者がぶつからない様に監視するインスタンス

が必要です。

つまるところ、ある程度汎用性のあるバスの規格も考えて自作しなくてはなりません。
さらに帯域を増やすためにこれらを並列化するにはどうしたら良いでしょうか？

自作モジュールの検証は？
自作バスの検証は？


この反論(1)に類似した内容で、「QsysやXPSと言ったツールだって中身を作る人がいるんだ」というものがあります。
→じゃ、そのモジュールの検証結果と妥当性示してくださいね。使えませんから。加えて、もしオリジナルバスで作った場合、他の開発者にそれを学習させて使わせる訳ですが、仕様書って書きました？コードカバレッジどうなってます？



いずれにせよ、莫大なリソースをつぎ込める大企業ならともかく、これら全ての要件を満たすまえに力尽きるでしょう。



(2) ベンダ提供のお気楽ツール使うと一つのFPGAベンダに依存してしまうことになり、他ベンダFPGAへの移植が困難

なるほど、言いたい事は分かります。時代はグローバル（）ですよね。
でもそれって、「C言語で記述すればどんなアーキテクチャのCPUにも簡単に移植できますよね」理論と一緒かも。

ベンダ個性の無いFPGAって無いと思われます…。
例えば、積和演算器はたいていFPGA内部にありますけど、実装がベンダーごとに違いますよね(ex.前置加算付き積和演算器)

大抵、ハードマクロなどベンダごとの差別化要素があり、依存しない訳が無いです。
いま、Cortex-AクラスのハードCPUがオンチップでFPGA搭載される方向に進んでいます。この流れでベンダごとにチップはおろか開発手法から差別化が加速するものと思われます。
すなわち、よほど、単純なロジックでない限りベンダに依存しない開発は不可能です

(3) どうせその手のツールはつかったところで動かない。だっていままでそうだったし

10年前の話をステレオタイプに触れ込むのは、どうなんでしょうね。

いずれにせよFPGAは順序や論理回路を放り込む箱に過ぎず、箱の組み立て方に囚われるのは賢明とは言えません。

Xの功罪

では、HDL推奨派に十字架を背負わせて魔女裁判でもすれば良いのでしょうか。

決してそうでは無いでしょう。

例えばザイリンクス。
開発者は検証されたバスに準拠したモジュールを使う方が容易で合理的である事に気が付いてはいるものの、そのバスを使うとなると必然的にソフトマクロCPUのおまけ付きになってしまうのです。バスを選択するとCPUとそのアーキテクチャも必然的に選択してしまっている訳です。
C/C++開発環境と、HDL開発環境を行き来しなくてはなりません。


もちろんCPUを切り離して、オリジナルバスマスタを用意できなくはないですが、新たに有償ツールを使うはめになったり、車輪の再発明が容易ならぬ事態になる事も多くここで敗戦処理と軍事裁判がですね（ry

また、機能モジュールをブロックの様に組み合わせても、そのモジュールのHDLソースが隠蔽されているケースも多く、開発者に不安を与える一因となっています。

こうなると、HDLのみの開発に頼るのも理解できなくはないです。

AlteraいいよAltera

AlteraのQsysでは抽象化を一部犠牲にし、バスとCPUとCPUアーキテクチャの関係を完全に分離しています。

NiosIIがないとしてもUSB Blaster経由でJTAGから、あるいはSPIを使って外部からバス配下のモジュールにアクセスできます。
つまりソフトマクロCPUを載せる前からデバッグ出来るので、問題の切り分けが容易です。このモジュール自身も複数のアダプタで構成されており、自分の好むインターフェースに挿げ替えも可能です。

Qsysを使った開発手法では、マウスで欲しい機能を選択し組み立てて行くだけですが、必要な場合はHDLコードを見たり自分でAvalonバスインターフェースを持ったモジュールを作成することもできます。
もちろん検証モジュールも用意されています。

ソフトマクロCPUで抽象化を図ったベンダとは異なり、モジュール間の接続を完全に意識させ、デバッグ環境を充実させています。JTAGからバスマスタにブリッジ出来るのはとても便利です。


最近CQから出版されたDE0本は何故か、Alteraツールで開発していながら、Qsysをあまり活用できていない様に思います。コレについてはしかるべき方法で取り上げたいと思います。

*1:そのような設計をした時点でアウトだけど