コンテンツにスキップ

空のデザインからアプレットの実行まで#

このトピックでは、空の VisualApplets デザインから実行可能なハードウェアアプレットに至るまでのエンドツーエンドのワークフローについて説明します。読み終えると、ハードウェアを使用する際に、デザイン、シミュレーション、デザインルールチェック、ビルド、フレームグラバーへのデプロイがどのように連携するかを理解できます。また、デザイン時と実行時でそれぞれどこでパラメータを設定するかについても分かるようになります。

主要用語

手元にフレームグラバーのハードウェアがなくても、この学習パスを進めることができます。PC上のVisualAppletsで、デザイン、パラメータ設定、デザインルールチェック、シミュレーションを実行します。BuildにはPC上にFPGAツールチェーン（通常はXilinx Vivado）が必要ですが、ボードは必要ありません。Flash/loadおよびruntime検証には、フレームグラバーと、Basler Framegrabber SDKなどのランタイムソフトウェアが必要です。完全な統合テストを行うには、フレームグラバーとカメラまたはその他の画像ソースも必要になります。

同じワークフローのステップバイステップの手順については、ユーザーマニュアルのハードウェアアプレット：アイデアからアプリケーションまでを参照してください。

microDisplay Xでのアプレットのデザイン、ビルド、および使用に関する簡単なイントロダクションについては、ユーザーマニュアルの入門を参照してください。

ワークフローの概要#

全体的なワークフローはVisualApplets 動作するアプレットの設計は以下のとおりです。

PC上の VisualApplets で:

  1. アプレットをデザインします。デザインパネルにoperatorsをmodulesとして配置し、それらの間にlinksを追加します。モジュールとリンクのプロパティを設定します。
  2. ビルドの前にDRCレベル1および2を実行して、形式上の正当性を確認し、FPGAリソースを見積もります。DRCレベル1および2は、シミュレーションの開始時やビルド時にも自動的に実行されます。
  3. Test Images を使用してデザインをシミュレーションします。シミュレーションは、DRC レベル 1 でエラーが報告されなかった場合にのみ開始されます。
  4. ハードウェアアプレットをビルドし、*.hapファイルを生成します。ビルドにはPC上のFPGAツールチェーンを使用します。フレームグラバーを接続しておく必要はありません。

フレームグラバーおよびホスト上で:

  1. microEnable 5 ファミリーのプラットフォームの場合は、アップレットをボードにフラッシュします。microEnable 6 / imaFlex ボードの場合は、アップレットをハードウェアにロードします。
  2. microDisplay X、Framegrabber SDK、または pylon を使用して、ハードウェア上でアップレットを使用します。

このチュートリアルでは主に出現する microEnable 5 (mE5) および imaFlex フレームグラバー（CXP-12 Quad/Penta、microEnable 6ファミリ）を対象としています。オペレーターライブラリはプラットフォームによって異なります。たとえば、mE5のデザインで使用されるのは ImageBuffer を使用して DRAM ラインバッファリングを行い、imaFlex の設計では LineBuffer.

主要用語

ハードウェアアプレットとは、ビルドによって生成され、フレームグラバーで実行される*.hapファイルのことです。デザインタイムとは、PC上のVisualAppletsで*.vadプロジェクトを編集する時間のことです。ランタイムとは、ホストソフトウェアがアプレットをフレームグラバーのFPGAにロードし、画像を取り込む時間のことです。VisualAppletsでのシミュレーションはランタイムではありません。

新規プロジェクトの開始#

デザインフェーズは完全にVisualApplets内で実行します。インストールディレクトリのbinフォルダにあるVisualApplets.exe、Windowsのスタートメニュー、またはデスクトップショートカット（作成している場合）からアプリケーションを起動します。

プロジェクトがロードされていない場合、メインウィンドウには空のワークスペースが表示されます。プロジェクトを開始するには、FileをクリックしてからNewをクリックするか、Ctrl + nを押します。New Projectダイアログで、プロジェクト名、microEnable 5 marathon VCLなどのターゲットハードウェアプラットフォーム、およびWin 64などのターゲットランタイムを設定します。

情報

これらのプロジェクト設定は後から変更できますが、プラットフォームによって適用されるオペレーターライブラリやビルドオプションが決まるため、プラットフォームを切り替える際には、一部のモジュールの置き換えやパラメータの再設定が必要になる場合があります。

確認後 OK、VisualAppletsによって空のデザインウィンドウが開きます。新しいデザインには常に、次の2つの固定モジュールが含まれています AppletProperties および BoardStatus. AppletProperties は、作者やバージョンなど、デザインの一般的なプロパティを設定するために使用されます。 AppletProperties は、特定のハードウェアプラットフォーム用のインターフェイスプロパティへのアクセスも提供します。 BoardStatus は、PCIeインターフェースのステータスや温度などのプロパティをランタイム時に提供するために使用されます。 プロジェクト情報 タブには、現在のプロジェクト名、ハードウェアターゲット、およびプラットフォーム情報がまとめられています。

VisualAppletsでは、デザインウィンドウのOperator Library内にあるoperatorsを使用して、画像処理pipelineを設計します。オペレーターをダイアグラム内にドラッグして配置します。配置された各インスタンスはmoduleになります。moduleにはinputおよびoutputのportsがあります。あるモジュールの出力ポートともう一方のモジュールの入力ポートを接続してlinkを作成します。ダイアグラムでは、各リンクが矢印として表示されます。モジュールとリンクを組み合わせることで、ビルドによってFPGA上に実装される画像処理pipelineが記述されます。処理順序は接続順に従います。

オペレーターとリンクにはどちらも、寸法、Bit Width、プロトコル、Parallelism、その他の設定などのpropertiesがあります。Linksは接続に沿って独自のプロパティを保持します。編集できるリンクフィールドはupstream operatorによって異なります。編集不可のリンクフィールドには、上流のオペレーターまたはチェーン内でのリンクの位置から値が渡されます。さらに、ルールによってパイプライン全体にプロパティが自動的に伝播されます。たとえば、一部のプロパティはカメラの出力リンクでのみ設定します。これらは、オペレーターによって変更されるまで下流に伝播します。リンクまたはモジュールをダブルクリックすると、プロパティを開いて変更できます。製品内ヘルプおよびOperator Referenceに、オペレーター固有の動作が記載されています。

リンクプロパティとモジュールパラメータ

Baslerでは、デザインを定期的に保存すること、可読性を高めるためにモジュール名を変更すること、およびHierarchicalBox要素を使用してより大きなデザインを構造化することを推奨しています。インストールディレクトリのExamplesにあるサンプルデザインから始めることができます。詳細については、ユーザーマニュアルのProcessing Examplesを参照してください。

デザインタイムでのパラメータの設定#

Linkプロパティは、画像データが接続に沿ってどのように伝送されるかを記述します。最大画像サイズ、画像プロトコル、Bit Width、Parallelismなどの設定が含まれます。最大寸法やParallelismが大きいほど通常はより多くのFPGAリソースが消費されるため、アプリケーションに必要な値のみに設定することをBaslerでは推奨しています。リンクプロパティの編集は実行時ではなく、VisualApplets内でのみ行います。リンクプロパティの詳細については、Parameterizationのチュートリアルトピックを参照してください。

Moduleパラメータには、staticのものとdynamicのものがあります。静的パラメータは、デザイン時にVisualApplets内でしか変更できません。動的パラメータは、VisualAppletsでデフォルトとして設定できるほか、アプレットがフレームグラバー上で実行されている間にホストソフトウェアから後で変更することもできます。

デザイン ルール チェック (DRC)#

デザインの作成とパラメータの設定後、Design Rules Check Level 1およびDesign Rules Check Level 2を実行することをBaslerでは推奨しています。Analysis → Design Rules Check Level 1、またはDesign Rules Check Level 2、あるいはビルドツールバーの該当するアイコンを選択します。

  • Level 2を開始すると、最初にLevel 1が自動的に実行されます。
  • Level 1は、simulationおよびbuildの前にも自動的に実行されます。詳細については、ユーザーマニュアルのDesign Rules Checkを参照してください。

DRC Level 1は、DRC logで正式なデザインの問題を報告し、デザインペイン内の影響を受ける場所をハイライト表示します。一般的な問題には、リンク上の不一致なBit Widthや、ROIまたは画像サイズの不整合が含まれます。ハードウェアアプレットをビルドする前に、Level 1 errorsを解消する必要があります。

DRC Level 2は、さらなるチェックを実行し、estimates FPGA resourceの使用量を算出します。この見積もりは正確な予測ではなく目安として扱ってください。一部のオペレーターでは、ビルド中の後続のロジック最適化によって最終的なリソース使用量が変化する可能性があるため、100%を超える見積もりであっても、場合によってはビルドが成功することがあります。いずれかのリソースが100%を大幅に超えている場合は、デザインを簡素化するか、Parallelismや画像の寸法を減らすか、他のオペレーターを選択してから、チェックを再度実行してください。

以下の図は、エラーのないデザインルールチェックレベル1および2の実行後の一般的なDRC logを示しています。これには、公式ステータスに加え、LUT、フリップフロップ、ブロックRAM、算術リソースの推定使用量が含まれます。

デザインルールチェックレベル1および2の成功

どのモジュールがどれだけの資源を使用しているかを確認するには、Analysis → View FPGA Resourcesを開きます。FPGA Resource Estimationダイアログには、entire designおよびeach moduleの推定内訳が表示されます。このテーブルはCSVとしてエクスポートできます。選択したモジュールのFPGAリソースのみを表示するには、このモジュールのコンテキストメニューを開き、FPGA Resourcesを選択します。ユーザーマニュアルのFPGA Resource Estimationも参照してください。

DRCログに問題が報告された場合は、DRCメッセージをハイライト表示されたモジュールやリンクと組み合わせて使用し、エラーを修正してください。詳細については、ユーザーマニュアルのDesign Rules Checkを参照してください。

デザインペインでは、画像パス上のformal design errorsがredのリンクハイライトでマークされます。Link PropertiesまたはModule Propertiesダイアログにおいて、赤色でマークされたリンクには、特定のエラータイプに関する詳細なツールチップメッセージが表示される場合もあります。

VisualApplets：赤色のリンク

紫 ハイライト表示されるマーク 同期ルールの違反 ブランチ間（O型ネットワークルールなど）。アプレットをハードウェアにデプロイする前に、赤色のエラーと紫色の同期違反を修正する必要があります。信号を用いた処理（つまり、次を使用するリンク） Image Protocol = VALT_SIGNAL) 紫色のリンクが許可されます。

これらの色は、デザイン全体に対する信号機のようなステータスではありません。プロパティ変更を適用した後に表示されるGreenのリンクは、VisualAppletsが更新されたリンクプロパティを伝播および検証したことを意味します。緑色であること自体が、デザインのビルド準備が完了していることを意味するわけではありません。Propagation of Link Propertiesのチュートリアルトピックを参照してください。

VisualApplets：紫色のリンク

リンクルールの詳細については、ユーザーマニュアルのRules of LinksおよびOperator Types and Synchronizationのチュートリアルトピックを参照してください。

シミュレーションとDRCの比較#

DRC Level 1がerrorを報告した場合、シミュレーションを開始できません。同期警告を含むWarningsはシミュレーションをブロックしません。Redの状態はエラーを示し、シミュレーションを停止します。Purpleの状態は同期の問題を示します。その場合でもシミュレーションを実行することは可能ですが、ハードウェア上でアプレットに依存する前に修正する必要があります。

DRC Level 1および2がエラーなく完了した場合でも、simulationが失敗することがあります。たとえば、読み込まれた画像幅がリンクのparallelismの整数倍でない場合や、画像がリンクに設定された最大画像寸法を超えている場合にシミュレーションが失敗します。これらの問題を解決するには、シミュレーションの画像サイズをこれらの制約に合わせるか、リンクプロパティを調整してください。

次の画像は、error in DRC Level 1を示しています。

Design Rules Check Level 1のエラー

次の画像は、DRC Level 2のエラーを示しています。

Design Rules Check Level 2のエラー

シミュレーション#

設計中、シミュレーションによってテスト画像がパイプラインに供給され、ハードウェアなしで中間結果を確認できます。シミュレーションソースを追加して画像を注入し、シミュレーションプローブを追加して特定のリンク上のデータを表示します。VisualAppletsには、%VASINSTALLDIR%/testimagesの下にテスト画像が付属しています。独自の画像をシミュレーションソースに読み込むことも可能です。TIFFが推奨形式ですが、VisualAppletsは他にも多くの一般的な形式での画像の読み込みをサポートしています。

VisualAppletsでの設計のシミュレーション

Analysis → Start Simulationから、またはツールバーのコントロールからシミュレーションを開始すると、VisualAppletsは自動的にDRC Level 1を実行します。Simulationウィンドウにはアクティブなソースとプローブの一覧が表示され、下部のペインにDRC Level 1の結果が表示されます。シミュレーションを行うためにDRC Level 2は必須ではありませんが、FPGAリソースの見積もりを得るために、アプレットをビルドする前にDRC Level 2を実行することをBaslerは推奨しています。その他のすべてのシミュレーションオプション、モード、ウィンドウについては、ユーザーマニュアルのSimulationを参照してください。

1回のシミュレーションセッションで複数のシミュレーションサイクルを実行できます。SimulationウィンドウでProcessing cyclesを設定し、Startをクリックします。シミュレーションソースに画像が1枚のみ含まれている場合、VisualAppletsはその画像をすべてのサイクルで再利用します。ソースに複数の画像が含まれている場合、新しいサイクルごとに次の画像が順番に使用されます。最後の画像の後は、最初からシーケンスが再び開始されます。

画像データパス上のピクセル値について、シミュレーション結果は通常、テスト対象データのハードウェアと一致します。Simulation Probeを使用すると、ズームしてピクセルを詳細に確認できます。画像ヒストグラムなどのツールは、ピクセルデータの解釈に役立ちます。

シミュレーションですべてのハードウェア効果が示されるわけではありません。デッドロック、サイズ不足のバッファ、共有DRAM帯域幅の制限、および一部のオーバーフローケースは、多くの場合フレームグラバー上でしか現れません。シミュレーションの成功は、ハードウェアでのランタイムテストの代わりにはなりません。

ハードウェアアプレットのビルド#

デザインをビルドすると、VisualAppletsはデザインをFPGAビットストリームに変換し、ランタイムソフトウェアインターフェイス用のコンテンツとともにパッケージ化して、ハードウェアアプレットと呼ばれるファイルを生成します。ビルドには、ビルド用コンピューターにインストールおよび設定された、サポートされているAMD/Xilinxツールチェーンが必要です。プラットフォームとVisualAppletsのバージョンに合わせてVivadoを使用してください。どのツールチェーンのバージョンがどのフレームグラバープラットフォームに対応しているかの概要については、Installing VisualAppletsを参照してください。ハードウェアアプレットのビルドに関する詳細な手順については、ユーザーマニュアルのBuildを参照してください。

ビルドにかかる時間は、FPGAロジックの使用量、ハードウェアのターゲットプラットフォーム、およびデザインの複雑さによって異なります。簡単な例であれば数分で完了しますが、大規模なデザインの場合は数時間かかることがあります。ビルドが成功した場合、出力される*.hapファイルは通常、デザインファイルと同じベース名を使用します。例えば、Sobel_Filter.vadからはSobel_Filter.hapが生成されます。

フラッシング、ランタイムローディング、およびホストソフトウェア#

microEnable 5ファミリーボードの場合は、ボード上のファームウェアパーティションに*.hapファイルが含まれるように、microDiagnosticsを使用して新しいアプレットをフラッシュする必要があります。microEnable 6ボードの場合は、アプレットをハードウェアにロードします。Framegrabber SDKのmicroDiagnosticsツールを使用してアプレットをフレームグラバーにフラッシュまたはロードする手順については、Managing Applets in microDiagnosticsを参照してください。

ビルドしたハードウェアアプレットを使用するには、microDisplay Xでアプレットを開きます。microDisplay Xのパラメータツリーにはデザインのモジュール名が反映されるため、VisualAppletsでは分かりやすいモジュール名を選択してください。Dynamicパラメータがそこに表示されます。一部のパラメータは買取り中に変更できますが、その他のパラメータは買取り開始前に設定する必要があります。DMAの次元はその典型的な例です。閾値など、買取り中に変更できるパラメータもあります。

microDisplay Xの機能と買取り動作については、Framegrabber SDKドキュメントのmicroDisplay Xを参照してください。

または、Framegrabber APIを使用して、独自のアプリケーションに買取りとパラメータ制御を統合することもできます。VisualAppletsは、BuildおよびGenerate SDK Exampleを使用して、C++のサンプルプロジェクトを生成できます。これらのプロジェクトには、初期化、メモリ割り当て、Fg_setParameterWithType / Fg_getParameterWithType呼び出し、買取りの開始と停止、クリーンアップが含まれています。SDKサンプルの生成方法については、ユーザーマニュアルのFramegrabber SDKを参照してください。

生成されたコードは出発点として扱ってください。APIリファレンスはFramegrabber SDKドキュメント（basler_fg.hやFramegrabber APIのイントロダクションなど）に記載されています。

デザインタイムとランタイム#

デザインタイムでは、グラフィカルパイプラインの編集、静的および動的パラメータの設定、リンクプロパティの定義、DRC Level 1および2の実行、シミュレーションを行います。シミュレーションを開始するたびに、VisualAppletsは自動的にDRC Level 1を実行します。また、ビルド出力として*.hapファイルを生成します。

runtime時に、ホストソフトウェアはそのアプレットをロードし、dynamicパラメータを設定して、取り込みを開始します。VisualAppletsのデザインで定義されたモジュール名と階層は、パラメータツリーやAPIでも使用されます。一貫した命名規則とドキュメントは、インテグレーターの作業を助け、現場での調整を簡素化します。

VisualAppletsのワークフロー

  • VisualApplets Fundamentalsのチュートリアル トピック — 設計、ビルド、およびハードウェアアプレット
  • Parameterizationのチュートリアル トピック — デザインタイムにおけるリンクプロパティとモジュールパラメータ
  • Pipeline Conceptのチュートリアル トピック — モジュール、リンク、およびパイプライン構造
  • Operator Types and Synchronizationのチュートリアル トピック — オペレータの種類とリンクの色
  • ユーザーマニュアルのDesign Rules Check — DRCレベル1およびレベル2
  • ユーザーマニュアルのSimulation — シミュレーションソース、プローブ、およびモード
  • ユーザーマニュアルのBuild — ハードウェアアプレットの生成
  • Installing VisualApplets — Xilinxツールチェーンのバージョン