FPGAの可能性を広げるプロセッサコア（後編）：主要プロダクトと実装時の課題を解説！（2/2 ページ）

カスタムアクセラレータの構築

　FPGAにプロセッサコアを搭載する際の大きな魅力として語られているのが、特定用途向けのハードウエアアクセラレータを周辺機能として実装できることだ。ただし、その実現方法は、FPGAやプロセッサコアごとに異なる。

　Niosの設計ツールは、カスタム命令を定義する機能を備えている。同ツールによって、新しい命令をNiosパイプラインに組み込むのに必要となる、デコーディングと実行ロジックの変更を生成することができる。単一の処理が、クリティカルループにおけるボトルネックになっている場合には、この手法が有効である。また、この手法の代わりに、アクセラレーションを行う対象であるCコードから直接RTLコードを合成することによって、カスタムアクセラレータを構築することもできる。この場合、新しいロジックブロック用のAvalonラッパーをコンパイルして、その結果を設計データの中にドロップすればよい。

　Xilinxは、MicroBlazeにおいて、Niosの事例と同じような、2段階からなるアプローチをとっている。同社の組み込みプラットフォームマーケティング担当マネージャを務めるNavanee Sundaramoorthy氏は、「アクセラレータの実装には2つの方法がある。まず、大規模なアクセラレータはAXIに接続する。一方、FIR（Finite Impulse Response：有限インパルス応答）フィルタや飽和乗算器などの小規模なものは、MicroBlazeパイプラインに直接接続する」と述べる。

　ソフトコアはRTLコードで記述されているので、ライセンス上の問題さえなければ、ユーザー側でRTLコードを改変して好きなように拡張することが可能である。しかし、プロセッサコアの論理設計に関する知識と、結果として得られるシステムの正確性や性能への影響については、プロセッサコアのベンダーの責任ではなくユーザーの自己責任になることに留意すべきだろう。

複雑になりがちな検証/デバッグ

　プロセッサコアを搭載するFPGAの設計を検証する際には、プロセッサコアそのものの検証、サブシステムを含めたマイクロプロセッサとしての検証、組み込みソフトウエアのデバッグなどのように、検証/デバッグを行う規模によって異なるいくつかの問題が存在する。また、問題の複雑さは、実装するプロセッサコアによって変わってくる。

　FPGAベンダーは、自社製品に使用するハードコアまたはソフトコアと周辺機能IPについては完璧に検証済みだと主張する。また、自社のシステム構築用ツールを使ってユーザーが構築したサブシステムも構造的には正しいとしている。確かに、これらの主張について、議論の余地はほとんどないと言っていいだろう。しかし、そのほかの部分となると、問題はずっと複雑である。

　例えば、サードパーティ製のプロセッサコアの実装について、FPGAベンダーはそのサードパーティと異なる主張をするか、あるいは何も主張しない。また、カスタムアクセラレーションによってプロセッサコアに変更を加える予定がある場合には、そのFPGA向けのシステム構築用ツールを使用する場合でもFPGAベンダーとの間で検証計画について同意しておく必要がある。慎重な検証マネージャならば、プロセッサコアを搭載するFPGAの設計全体に対して再検証を行いたいと考えるかもしれない。そのためには、そういった検証を行うためのツールやテストベンチに加えて、技術的な知見も必要になる。

図3　サブシステムの検証手法　 FPGAに実装するプロセッサコアのサブシステムを検証するには、ツールや検証用IPの活用が必須である。

　プロセッサコアの検証の次に行わなければならないのはシステムの検証である。Cadence Design Systemsの製品マーケティング担当検証ディレクタを務めるAdam Sherer氏は、「FPGAベンダーのツールが、インタフェース用のRTLコードを正しく生成できるということは事実だ。しかし、このツールは、システムの相互作用を事前に検証することはできない。ミッドティア設計をこれまでうまくこなしてきたFPGAの設計チームが、プロセッサコアの実装に手こずるという事例を多く目にしてきた。設計内容に、プロセッサ、バス、周辺機能が加わると、『プログラミングして試行する』という彼らの検証スタイルで対応できる範囲を超えてしまう。そういった複雑な設計をFPGAで行う場合には、高速なモデルの利用やASICを設計する際に用いるような検証手法が必要になる」と語る。このような検証手法には、マイクロコンピュータのサブシステム内におけるすべての機能ブロックをシミュレートできるモデルだけでなく、機能ブロック用のサードパーティ製検証IPや、検証作業の進捗を管理/追跡できるテストベンチも必要になるかもしれない（図3）。これらのプロセスは、多くのFPGA設計チームが使用してきたプロセスよりも複雑であり、高度なスキルが求められる。

　LatticeのKendrick氏も、システム検証は多くの設計チームにとって複雑な問題になり得るという意見に同意する。Kendrick氏は、「LatticeMicoのユーザーは、複雑さを緩和するために、まずは検証済みのオープンソースの参照設計を基に、自分たちの要件に合わせて改造することが多い」と説明する。さらに、同氏は、「設計を起こす最初の段階でRTLシミュレーションを使用するユーザーもいる。だが、多くのユーザーは、動作する参照設計に対して慎重に変更を加えていき、それを直接評価ボードに組み込んで動作させてみるという方法をとっている」とも述べている。

　組み込みソフトウエアのデバッグの問題については、SoC（System on Chip）の世界では、ARMが提供している「CoreSight」のようなデバッグ用のサブシステムに頼る傾向がますます高まっている。このようなサブシステムは、Xilinxが提案するEPP（Extensible Processing Platform）製品に用いられる予定のハードコアの中に搭載されている場合があるが、ベンダーはいつもそのことを明らかにしているわけではない。例えば、CoreSightは、SmartFusionのCortex-M3コアに搭載されているようだ。しかし、CoreSightが、FPGAベンダーのプロプライエタリなプロセッサコアをサポートしているかどうかは、また別の問題である。Sundaramoorthy氏によると、MicroBlazeには、シングルステップとブレークポイントが可能なJTAG（Joint Test Action Group）アクセスがあるという。Niosにも同様の機能がある。とはいえ、普段使用しているデバッグツールが、使用するプロセッサコアをサポートしているとは限らない。例えば、LatticeMicoは、オープンソースを特徴とするにもかかわらず、その動作モニタリング機能のインタフェースは同社製デバッガへのインタフェースしか備えていない。

　システム動作をさらに詳細に検証するには、カスタムテスト（アサーション）を作成して、FPGAの設計データに組み込むという方法がある。しかし、大規模なFPGAの設計データのコンパイルには丸1日かかることもしばしばなので、この選択肢はあまり魅力的ではない。このほか、Xilinxの「ChipScope」のような、ロジックファブリックに組み込まれているデバッグ機能を使用すれば、個々のFPGAレジスタという細部における動作を確認することができる。ただし、実装に関する詳細な知識がなければ、FPGAのロジックセルと実行されるソースコードのひも付けは、途方もない作業になってしまうだろう。Cadenceが提案しているように、ハードウエアに落とし込む前に、高速なシステムレベルのモデルを用いた検証から始めることが、手順として適切だと考えられる。