Comments
Transcript
MicroBlaze とPowerPCコアをハード ウェア テスト ジェネレータ
EMBEDDED SYSTEMS MicroBlaze と PowerPC コアをハード ウェア テスト ジェネレータとして使用 FPGAエンベデッド プロセッサとC-to-RTLコンパイルの組み合わせで 複雑なハードウェア モジュールのテスト時間を短縮 David Pellerin CTO Impulse Accelerated Technologies [email protected] との間に高性能のデータ チャネルを提供し、オンチップ相互接続と して機能します。 同様に、Virtex-II ProTMおよびVirtex-4TM FPGAにインプリメン トされたPowerPCハード プロセッサ コアは、図1に示すようにプ Milan Saini Technical Marketing Manager Xilinx, Inc. [email protected] ロセッサ ローカル バス（PLB）とオンチップ メモリ（OCM）の各イン ターフェイスを通じて高性能の通信チャネルを提供します。 ザイリンクスが提供するこれらのインターフェイスを使用してイン システム ユニット テストを定義することにより、大規模化するアプ FPGAデザインにプロセッサ コアを現在使用しているかどうかに リケーションの重要コンポーネントを短時間で検証することができま PowerPC エン す。アプリケーション全体を実際の状態でモデル化するシステム テ ベデッド プロセッサを使用すれば、FPGAベースの種々のアプリケー ストと異なり、ユニット テストでは、境界条件やコーナーケースな ション コンポーネントのユニット テストとデバッグの時間短縮が可能 どのように、システムレベルの視点ではテストが難しい、あるいは不 です。 可能な特定コンポーネントの潜在的な問題箇所に焦点を当てること 関わらず、ザイリンクスの MicroBlaze かIBM TM TM TM エンベデッド プロセッサ上で実行されるCコードはインシステ ムのソフトウェア/ハードウェア テストベンチとして使用可能で、 ができます。このようなユニット テストは、アプリケーション全体 の品質と安定性を向上させます。 FPGAへのテスト入力、結果の検証、性能測定などを行うことができ ます。このような操作においてエンベデッド プロセッサはシステム 上でFPGAを検証するためのツールとして、またハードウェア シミュ レーションの補完ツールとして動作します。 ユニット テスト ハードウェア/ソフトウェアを統合したテスト方法には、上に述べ たユニット テストを含め、アプリケーションの重要モジュールに対 この方法を拡張して、エンベデッド プロセッサへのCコンパイル するさまざまなテストが含まれます。従来、システム設計者やFPGA だけではなく、Cからハードウェアへのコンパイルも含めることによ アプリケーション開発者は、HDLシミュレータを使用してこれらの り、ソフトウェアとハードウェア両用の高性能のテストベンチを最小 テストを行ってきました。 限の労力で作成し、実際の状態を正確にモデル化することができます。 FPGA設計者はシミュレータを使用してテストベンチを作成し、ス この手法の鍵となるのは、エンベデッド プロセッサ上で実行する ティミュラス（テスト ベクタまたは同等の入力）を入力し、得られた テスト用ソフトウェア（C言語テストベンチ）と、FPGAファブリック 出力を確認することにより特定モジュールを検証します。大量のデー に実装されるその他のコンポーネント（テスト対象となるハードウェ タを処理するアルゴリズムの場合、このようなテスト方法ではテスト アを含む）の間の高性能の標準インターフェイスです。これらのイン 時間が非常に長くなったり、あるいは実際の状態を適切にエミュレー ターフェイスには、ターゲット プラットフォーム上で使用可能な通 ションすることができなくなることがあります。インシステムのプロ 信チャネルが利用されます。 トタイプ テスト環境を追加することにより、シミュレーション ベー たとえば、MicroBlazeソフトコア プロセッサは、Fast Simplex Link（FSL）と呼ばれる高速シリアル インターフェイスへアクセスし ます。FSLは、MicroBlazeプロセッサと周囲のFPGAファブリック 16 スの検証が強化され、テストシナリオをより複雑で実際的なものに することができます。 システム レベルのテストにおいては、再現が難しく予期しない EMBEDDED SYSTEMS 状態や境界条件に焦点が当てられている場合は、ユニット テストが これはSystemCを使用してもできますが、SystemCライブラリ 最も効果的です。たとえば、複数の畳み込みを次々と行う画像処理 は複雑なので（特にチャネルを通じたデータフロー抽象化のサポート アプリケーションにおいては、標準の画像においてフィルタが通常遭 の場合） 、このようなテスト ベンチ作成プロセスもやや複雑なものと 遇する状況の範囲外にあるピクセルの組み合わせをテストすること なります。CoDeveloperのImpulse Cライブラリではよりシンプル により、ある特定フィルタに注意を集中することができます。 な方法がとられており、ストリームと呼ばれるバッファ通信チャネル システム レベルの視点からすべての組み合わせをテストすること を使用して、 （並列のソフトウェア モジュールまたはハードウェア モ は不可能なので、ユニット テストでは、特定の対象領域や境界条件/ ジュールを表わす）複数のCプロセスを記述・接続できる関数セット コーナーケース用に一連のテストを構築します。実際のハードウェア が用意されています。 でこれらのテストを実行すれば、テストのために通常のクロックレー Impulse Cでも信号と共有メモリによる通信をサポートしており、 トよりも低速で実行することができ、特定のアプリケーション コン 外部データや係数などの静的データへのアクセスが必要なハード ポーネントにおける実際の性能値を定量可能な形で得ることができ ウェア プロセスのテストに有効です。 ます。 データ スループットとプロセッサの選択 このテスト手法にC-to-RTLコンパイルを導入することは、テス ト効率を上げる上で効果があります。たとえば、エンベデッド プロ インシステム テスト用にプロセッサを評価する場合、まず、 セッサと専用ハードウェアの両方で実行できるソフトウェア/ハード MicroBlazeプロセッサなどのソフト プロセッサにはターゲット ウェア混用テスト ルーチンを即座に作成するために、CoDeveloper FPGAデバイス上に一定のエリアが必要である点を考慮する必要が （Impulse Accelerated Technologies製） などのツールを使用して、 あります。アプリケーション全体の中の比較的小さな要素に対するテ FPGA内で動作するプロトタイプのハードウェアやカスタムのテスト スト ジェネレータとしてMicroBlazeプロセッサを使用しているだけ 生成ハードウェアを作成して、サンプルの入力を生成し、テスト出力 であれば、この余分なリソースの使用が問題となることはほとんどあ を検証することができます。 りません。しかし、もしテスト対象デバイスによってFPGAリソース がすでに限界に近い状態にある場合は、テスト 図 1 ハードウェアおよびソフトウェアによるテスト コンポーネントはターゲット FPGA にマップ され、OPB または FSL バスを介して MicroBlaze または PowerPC プロセッサと通信します。 段階でより高集積デバイスをターゲットにする か、代わりにPowerPCコア内蔵のVirtex-II Pro ハードウェア プロセス ソフトウェア プロセス ハードウェア プロセス Impulse C アプリケーション ハードウェア プロセス やVirtex-4プラットフォームの使用を検討する 必要がでてきます。 合成にかかる時間も考慮すべき点です。使用 する合成ツールによっては、最終のアプリケー ションにMicroBlazeコアを追加すると、その ハードウェア プロセス アプリケーションをFPGAへ 合 成、マッピン OPB、FSL、他のインターフェイス MBlaze、PPC、 他のプロセッサ FPGA ハードウェア リソース グする時間が著しく増大する恐れがあります。 コンパイル、テスト、デバッグを繰り返し行う 場合は、この点を検討する必要があります。 設計の反復による時間が問題となるような場 ハードウェア プロセス ソフトウェア プロセス ハードウェア プロセス 合も、やはり、合成不要のハード コアである PowerPCコアのほうがMicroBlazeコアよりも ハードウェア プロセス ハードウェア プロセス VirtexまたはSpartan FPGA 有利です。16KBのデータ キャッシュと16KB の命令キャッシュを使用できるPowerPC 405 プロセッサでは、キャッシュ メモリだけで小さ いテスト プログラムを実行してテスト アプリ CoDeveloperはC言語のソフトウェア プロセスからFPGAでハー ケーションの性能を向上させることが可能です。 ドウェアを作成し、ソフトウェアからハードウェアへ、あるいはハー テストデータ速度の高速性（プロセッサからFPGAへのスループッ ドウェアからソフトウェアへのインターフェイスを自動的に生成しま ト） が主な問題となる場合は、MicroBlazeコアをFSLバスとともに使 す。生成されたこれらのインターフェイスは、MicroBlazeプロセッ 用したり、PowerPCとそのオンチップメモリ （OCM） インターフェイ サとそのFSLインターフェイス、あるいはPowerPCとそのPLBイン スを使用したりすることにより、ソフトウェア コンポーネントとハー ターフェイスに合わせて最適化することができます。共有メモリを含 ドウェア コンポーネント間のデータ ストリーミングに関して最大限 むデータを移動するために、他の方法もサポートしています。 の性能を達成することができます。 CoDeveloperとImpulse Cライブラリを使用すれば、ストリーム C言語によるデスクトップ シミュレーションとモデリング ハ ード ウ ェ ア ユ ニ ット テ スト にC言 語 を 使 用 す る 場 合 は、 読み取り/書き込み用の共通関数セットを使って、複数のストリーミ ング ソフトウェア/ハードウェア インターフェイスを利用することが Microsoft 社のVisual Studio 、GCC/GBD、または同様のC開 できます。これらのストリーム読み取り/書き込み関数は、ストリー 発環境やCデバッグ環境を使用し、ソフトウェアでアルゴリズムのデ ミング通信用の抽象プログラミング モデルを提供します。図2は、 TM TM バッグ用にソフトウェア/ハードウェア モデルを作成する必要があり 典型的なストリーミング インターフェイスのソフトウェア側におい ます。デスクトップでシミュレーションを実行するには、完全なアプ て、Impulse Cライブラリがどのようにストリームベースの通信をサ リケーション（テスト対象デバイス、プロデューサおよびコンシュー ポートしているかを示しています。 マ用テスト機能、その他必要なテストベンチ要素） をC言語で記述し、 標準のデスクトップ コンパイラでコンパイルして実行します。 17 EMBEDDED SYSTEMS 図 2 エンベデッド プロセッサ上で実行されるソフトウェアベースのユ ニット テストにおいては、データ ストリームを通じてテスト対象 ハードウェア ユニットと通信が行われます。 等のアルゴリズムよりも桁違いに高速のハードウェアを、C言語から 直接生成することができます。これにより、高速で出力を生成する ハードウェア テスト ジェネレータを得ることができます。 CベースのテストがあればHDLシミュレータは不要? これまで述べたようなCベースのテスト方法は、設計者が心得てお きたい便利な方法の1つですが、総合的なハードウェア シミュレータ に完全に置き換えられるようなものではありません。HDLシミュレー ションは、サイクル数を決定してハードウェア インターフェイスに 関する問題を解消するのに効果的な方法です。また、あるハードウェ ア モジュールをシステム上でテストするには、事前にコンパイル/合 成/マッピングを行う必要があります。これらの操作には長い時間が テスト ジェネレータをハードウェアへ移行 かかるのが普通ですが、HDLシミュレータはこれを短縮するのにも スティミュラス ジェネレータなどの重要なテスト機能は、テス 役立ちます。ハードウェア シミュレータを使用すればテスト対象デ ト生成ソフトウェア ルーチンの性能を最大限に引き出すために ザインの内容を詳しく調べることができるほか、シングルステップ実 ハードウェアへ移植することができます。これらの機能をVHDLや 行などの方法を使用してエラーを特定することもできます。 VerilogTMで再度インプリメントする代わりに、自動化されたC-to- テストに極めて厳密なタイミングが要求される場合にエンベデッ RTLコンパイルを使用すれば、テスト プロデューサまたはコン ド プロセッサを使用してテストデータを作成すると、多くの場合、 シューマ機能を持つハードウェアを即座に作成できます。これらの機 タイミング クロージャを得るために必要なデータ速度の数分の一程 能は、データストリームを実装して他のテスト入力を提供するFIFO 度の速度しか得ることができません。実際、プロセッサ上にステート やその他のインターフェイスを使用して、テスト対象デバイスと連携 マシンとしてテストルーチンが実装されている場合は、ステートマシ して動作します。 ンを動作させることのできる速度がハードウェアのテスト ロジック CoDeveloperのC-to-RTLコンパイラは、Cプロセス(ストリーム、 のクロック周波数よりも遅くなってしまいます。このためほとんどの 信号、共有メモリを通じて通信する個々の関数)を解析して、Xilinx 場合、CPUの速度と合わせるためにハードウェアの速度を落とす必 Platform Studio（EDK）やXilinx ISE、ならびにSynplicity®などの 要が生じ、スティミュラスを提供し期待される応答を測定します。あ サードバーティの合成ツールと互換性を持つ、合成可能なHDLを生 るいは、バッファ インターフェイス（ソフトウェアからハードウェア 成します（図3） 。生成されたRTLは内部コード ループのレベルで自 へのブリッジ）を作成し、ストリーミング プログラミング モデルを 動的に並列化され、プロセス応答時間を短縮し、出力データ ストリー 使用してテスト データを管理することもできます。 ムのデータ速度を向上させます。 ハードウェア シミュレーションでは、配線後のシミュレーション パイプライン化されたプロセスを複数生成するといったシステム モデルを使用して、シミュレーションされた任意のクロック速度でデ レベルの並列化を実行できる自動コンパイル機能を使用すれば、 ザインを実行してこれを観察することができますが、プロセッサベー エンベデッド マイクロプロセッサ上にソフトウェアで実装された同 スのテストベンチの性能と、すべてハードウェアで構成されたシステ 図 3 ハードウェアおよびソフトウェア C コードのコンパイルとデバッグ は標準 IDE 内で行われます。インターフェイスは自動的に生成され、 生成された HDL はザイリンクスのツールで合成され、Virtex-II、 Virtex-II Pro、 あるいは Virtex-4 デバイスにダウンロードされます。 Impulse プラットフォーム ライブラリ Impulse C デザイン ファイル Visual Studio、 CodeWarrior、 GCC、その他 ムにおいて予想される性能との差を考えると、このようなアプリケー ションのソフトウェアベースのテストを完全なハードウェア シミュ レーションに置き換えることができないことは明らかです。 結 論 エンベデッド プロセッサを使用したインシステム テストは、 シミュレーション ベースのテスト方法を補完する意味で優れた手法 で、実際のハードウェア インターフェイスを使用することも可能で あり、場合によってはより実際に近い入力スティミュラスを使用し RTLを生成 ハードウェア インターフェイスを 生成 ソフトウェア インターフェイスを 生成 て、より低速なクロックで効率的にハードウェアをテストすることが できます。クロック速度が遅くても、被テスト ハードウェアはRTL シミュレーションの場合よりはるかに高速に動作するため、シミュ レーションが改善されることになります。 HDL ファイル HDL ファイル ソフトウェア ライブラリ この方法とCからハードウェアへのコンパイル ツールとを組み合 わせれば、ハードウェア テストベンチを含む、システムの大きな部 分をC言語でモデル化することができます。このようにして作成し たシステムは、マニュアルで作成したHDLに繰り返し移植したり、 Cコードのレベルから最適化することで、ますます高性能化する システム コンポーネントや、これに対応するユニットレベルあるいは システムレベルのテストを作成することができます。 詳細についてはwww.impulsec.comをご覧ください。 e-mail: [email protected]、Tel. 425-576-4066 18