Vitis でのエンベデッド プラットフォームの作成

プラットフォーム作成の基本

Vitis™ 環境アクセラレーション アプリケーション開発フローでは、プロジェクトはプラットフォームとプロセッシング サブシステムに分割されます。プラットフォームには、必須の IP ブロック (SoC の PS、Versal™ ACAP の NoC および AI エンジンなど) と、ボード インターフェイス IP ブロック (高速 I/O、メモリ コントローラーなど) が含れます。プロセッシング サブシステムには、システムのアプリケーションに特定の部分が含まれ、プログラマブル ロジックと AI エンジン ブロックで構成されています。この方法は、考慮する部分を分離し、同時開発を促進し、再利用しやすくします。アプリケーション開発者はプラットフォームの下位の詳細を考慮する必要がなく、プロセッシング サブシステムの設計に集中できます。プラットフォーム開発者は、処理サブシステムを気にすることなく、システムの起動と I/O パフォーマンスの調整に集中できます。これにより、サブシステムを異なるプラットフォームに統合したり、プラットフォームを異なるプロセッシング サブシステムで再利用したりできます。

ザイリンクスでは、Alveo™ カードおよびエンベデッド評価ボード用のビルド済みプラットフォームを提供しています。これらのプラットフォームは、ザイリンクス ダウンロード センターからダウンロードできます。プラットフォームとサブシステムの効率的な分離により、Vitis 環境での設計手法および生産性が向上します。エンベデッド デザインでは、プラットフォーム チームがカスタム プラットフォームを開発中に、アプリケーション チームがザイリンクスのビルド済みプラットフォームを使用してサブシステムの開発を開始する並列開発プロセスをザイリンクスではお勧めします。これにより、開発時間を短縮できます。ビルド済みプラットフォームを使用すると、検証済みで正しく機能することがわかっている基盤を使用して、サブシステムを個別に開発、統合、およびテストできます。サブシステムの開発が十分に進行し、安定した状態になったら、サブシステムをカスタム プラットフォームの適切なバージョンに統合できます。この方法により、システム統合プロセスが大幅に効率的なものになります。

次の図に、カスタマイズされたエンベデッド プラットフォームの作成方法を示します。

1: プラットフォームの作成

プラットフォームを作成するには、ベース ブータブル デザインを開始点として使用する必要があります。このデザインとしては、ザイリンクス ベース プラットフォーム、既存の作業中のデザイン、または一から作成されたデザインを使用できます。ベース ブータブル デザインには、次のベース コンポーネントが含まれている必要があります。

  • Vivado® Design Suite からエクスポートしたベース ハードウェア デザイン
  • Linux カーネル、ルート ファイル システム、およびデバイス ツリーなどのベース ソフトウェア デザイン

Vivado® Design Suite デザインでハードウェアおよびボードを作成したら、Vitis 環境の要件を満たすため、Vitis 環境プラットフォームに変換する際にベース コンポーネントにプロパティを追加する必要があります。通常のプラットフォームの作成手順は次のとおりです。

  1. Vivado® Design Suite プロジェクトにハードウェア インターフェイス パラメーターと割り込みサポートを追加して XSA をエクスポートします。
  2. ソフトウェア プラットフォーム コンポーネントをアップデートして、アプリケーション アクセラレーション ソフトウェア スタック (XRT のイネーブル、デバイス ツリーのアップデートなど) をイネーブルにします。
  3. XSCT コマンドまたは Vitis IDE を使用してプラットフォームをパッケージして生成します。

Vitis 環境では、ハードウェア プロジェクトのプロパティからプラットフォームのリソースが認識され、カーネルがプラットフォームにリンクされます。Vitis 環境では、カーネルの制御にソフトウェア スタックが使用されます。

Vitis 環境でのエンベデッド プラットフォーム作成の詳細は、『Vitis 統合ソフトウェア プラットフォームの資料』 (UG1416) を参照してください。詳細な手順は、Vitis プラットフォームの作成チュートリアル を参照してください。

プラットフォーム作成の要件

Vitis プラットフォームで作成したベース デザインは、プラットフォーム作成プロセスが終了したらスタティックになります。

Vitis は、マスター/スレーブ インターフェイスを追加して、特定の IP (SmartConnect、NoC など) に基づいてパラメーターを変更します。場合によっては、PS/CIPS インターフェイスを変更し、Versal™ ACAP と AI エンジン IP をプラットフォームにインスタンシエートすることもできます。

次の表は、ボード上のベース システムを検証するワークフローを示しています。

表 1. プラットフォームのワークフロー
ワークフロー 開発 検証
基本的なボード立ち上げ プロセッサの基本的なパラメーター設定。 スタンドアロンの Hello World とメモリ テスト アプリケーションが正しく実行されるかどうか。
アドバンス ハードウェア設定 プロセッシング システムのアドバンス I/O (USB、イーサネット、フラッシュ、PCIe®、RC など) をイネーブル。

I/O 関連の IP (MIPI、EMAC、HDMI_TX など) を PL に追加。

Vitis 以外の IP (AXI BRAM Controller、Video Processing Subsystem (VPSS) など) を追加。

これらの IP にスタンドアロン ドライバーが含まれる場合は、テスト。
ベース ソフトウェアの設定 ハードウェア プラットフォームに基づいて PetaLinux プロジェクトを作成。

カーネル ドライバーをイネーブル。

ブート モードをコンフィギュレーション。

rootfs をコンフィギュレーション。

Linux が問題なくブートするかどうか。

ペリフェラルが Linux で問題なく動作するかどうか。

ベース コンポーネントの要件

すべてのハードウェア プラットフォームに IP カタログからの Processing System IP ブロックを含める必要があります。

  • VersalACAP、Zynq® UltraScale+™ MPSoC、および Zynq-7000 SoC デバイスがサポートされます。
  • MicroBlaze™ プロセッサは、アクセラレーション カーネルの制御ではサポートされませんが、ベース ハードエアには含めることができます。

エンベデッド プラットフォームの作成

ハードウェア インターフェイスの追加

次の表は、使用可能な Vitis 入力とアクセラレーション エンベデッド プラットフォームの最小要件を示しています。

入力 Vitis の使用可能なタイプ AXI MM カーネルの最小要件
制御インターフェイス PS または AXI Interconnect IP や SmartConnect IP からの AXI マスター インターフェイス カーネル制御用の AXI4-Lite マスター 1 つ
メモリ インターフェイス AXI スレーブ インターフェイス データ交換用のメモリ インターフェイス 1 つ
ストリーミング インターフェイス AXI4-Stream インターフェイス 必要なし
クロック 複数のクロック信号 クロック 1 つ
割り込み 複数の割り込み信号 割り込み 1 つ

一般的な要件

  • プラットフォーム デザインで使用される IP で標準の Vivado IP カタログに含まれていないものは、Vivado Design Suite プロジェクトのローカルに配置されている必要があります。プロジェクト外部の IP リポジトリ パスへの参照は、エクステンシブル XSA を作成する場合はサポートされません。
  • Vitis コンパイラでカーネルへのリンクに使用されるプラットフォーム インターフェイスは、AXI4AXI4-LiteAXI4-Stream、割り込み、クロック、またはインターフェイスのリセット タイプにする必要があります。
  • Vitis コンパイラでカーネルへのリンクに使用される AXI インターフェイスを持つプラットフォーム IP には、クロック ピンも関連付けて v++ をイネーブルにし、必要に応じてクロック乗せ換えロジックを正しく推論して挿入する必要があります。
  • プラットフォーム上またはカーネル上のカスタム バス タイプおよびハードウェアインタフェースは v++ リンカーの --connectivity.sp および --connectivity.sc 指示子ではされません。カスタム バス タイプを指定したデータ バスを Vitis コンパイラでカーネルに接続する必要がある場合は、AXI4AXI4-Lite、または AXI4-Stream インターフェイスに変換する必要があります。

プロジェクト タイプ

Vivado プロジェクト タイプを extensible Vitis platform に設定する必要があります。

新規プロジェクトを作成する際は、Project is an extensible Vitis platform を選択します。

既存の Vivado プロジェクトエクステンシブル Vitis プラットフォーム プロジェクトに変更するには、Project ManagerSettings in the Flow Navigator をクリックし、Project is an extensible Vitis platform をオンします。

set_property platform.extensible true [current_project]

プラットフォーム インターフェイスの追加

ブロック デザインのコンポーネントに PFM プロパティが含まれる場合、v++ リンカーで認識され、アクセラレーション カーネルで使用できるようになります。

Vivado IDE では、プロジェクトがエクステンシブル プラットフォーム プロジェクトとして作成される場合、Platform Setup ウィンドウで PFM インターフェイス プロパティを設定できます。Window menuPlatform Setup をクリックして設定します。これらは、[Tcl Console] ウィンドウから手動で定義できるほか、Tcl スクリプトでも定義できます。

プラットフォーム インターフェイスの Tcl API は、次の 4 つです。

  • AXI メモリ マップド インターフェイス:
    set_property PFM.AXI_PORT { <port_name> {parameters} <port2> {parameters} ...} [get_bd_cells <cell_name>]
  • AXI4-Stream インターフェイス:
    set_property PFM.AXIS_PORT { <port_name> {parameters} <port2> {parameters} ...} [get_bd_cells <cell_name>]
  • クロックおよびリセット:
    set_property PFM.CLOCK { <port_name> {parameters} <port2> {parameters} ...} [get_bd_cells <cell_name>]
  • 割り込み:
    set_property PFM.IRQ {pin_name {id id_number range irq_count}} [get_bd_cells <cell_name>]

PFM プロパティの要件は、次のとおりです。

  • PFM インターフェイス プロパティの値は、Tcl ディクショナリ (名前/"値" のペア) として指定する必要があります。
    重要: 値は二重クォーテーションで囲む必要があります。名前と値の大文字と小文字は区別されます。
  • bd_cell には複数の PFM インターフェイス定義を指定できます。ただし、PFM インターフェイスの各タイプごとに、すべてのポートを 1 つの set_property Tcl コマンドで設定する必要があります。
  • 各 PFM インターフェイス プロパティで、ポート オブジェクトに指定した名前が外部ポートまたは bd_cell のインターフェイスの名前と同じである必要があります。各外部ポートまたはインターフェイス オブジェクトに含めることができるのは、1 つの PFM インターフェイス定義だけです。
  • PFM インターフェイスのタイプごとに異なるパラメーターを設定できます。
  • PFM プロパティに NULL ("") 文字列を設定すると、前に定義した PFM インターフェイスが削除されます。

AXI インターフェイスの追加

AXI メモリ マップド カーネルをサポートするには、プラットフォームが AXI メモリ マップド マスター ポート (M_AXI_GP) と AXI スレーブ ポートを含む 1 つのメモリ インターフェイス持つ AXI 制御インターフェイスを少なくとも 1 つ宣言する必要があります。PS ブロックから直接エクスポートすることも、インターコネクト IP を接続してエクスポートすることもできます。プラットフォームが AXI メモリ マップド カーネルで動作しない場合、これらのインターフェイスは必要ありません。

Tcl コマンドの構文は、次のとおりです。

set_property PFM.AXI_PORT { <port_name> {parameters} <port2> {parameters} ...} [get_bd_cells <cell_name>]

AXI 制御インターフェイスと AXI メモリ インターフェイスは同じ PFM.AXI プロパティを共有します。それぞれ memport タイプは異なります。

  • AXI 制御インターフェイスは M_AXI_GP として定義できます。メモリ インターフェイスは、ほかのタイプ (S_AXI_HP、S_AXI_ACP、S_AXI_HPC、または MIG) を使用します。
  • M_AXI_GP ポートの sptags プロパティはサポートされません。
  • sptag ID: (オプション) 最初の文字がアルファベットで始まる必要のあるユーザー定義の ID。ID の大文字/小文字は区別されます。システム ポート タグ (sptag) は、S_AXI_HP、S_AXI_ACP、または M_AXI_GP などのプラットフォーム ポート接続のクラスを示すシンボル識別子です。複数のブロック デザイン プラットフォーム ポートが同じ sptag を共有できます。
  • memory: (オプション) 関連する MIG IP インスタンスと address_segment を指定します。memory タグは、IP インテグレーターの [Address Editor] ウィンドウの [Cell Name] と [Base Name] 列を組み合わせた独自の名前になります。このタグは、複数のブロック デザイン プラットフォーム ポートが同じ memory タグを共有可能な Memory Subsystem HIP への接続に関連付けられます。

AXI インターコネクトのマスター ポートおよびスレーブ ポートのエクスポートには、次の要件があります。

  • プラットフォームで使用されるインターコネクト上のすべてのポートは、宣言されたプラットフォーム インターフェイスの前にインデックス順で宣言する必要があります。
  • ポートのインデックス番号をスキップすることはできません。
  • S_AXI_ACP ポートのマスター ID の最大数は 8 なので、接続された AXI インターコネクト上で宣言する使用可能なポートは {S00_AXI, S01_AXI, ..., S07_AXI} のいずれかである必要があります。プラットフォーム内で使用されるポートは宣言しないでください。できるだけ多くのポートを宣言すると、sds++ でカスケードされた axi_interconnects を回避できます。
  • S_AXI_HP または MIG ポートのマスター ID の最大数は 16 なので、接続された AXI インターコネクト上で宣言する使用可能なポートは {S00_AXI, S01_AXI, ..., S15_AXI} のいずれかである必要があります。プラットフォーム内で使用されるポートは宣言しないでください。できるだけ多くのポートを宣言すると、v++ で生成されたユーザー システムでカスケードされた axi_interconnects を回避できます。
  • M_AXI_GP ポートに接続されるインターコネクト上で宣言されるマスター ポートの最大数は 64 なので、接続された AXI インターコネクト上で宣言する使用可能なポートは {M00_AXI, M01_AXI, ..., M63_AXI} のいずれかである必要があります。プラットフォーム内で使用されるポートは宣言しないでください。できるだけ多くのポートを宣言すると、v++ で生成されたユーザー システムでカスケードされた axi_interconnects を回避できます。

次に、AXI インターコネクト IP で AXI マスターポートを定義する例を示します。

set parVal []
for {set i 2} {$i < 64} {incr i} {
lappend parVal M[format %02d $i]_AXI \
{memport "M_AXI_GP"}
}
set_property PFM.AXI_PORT $parVal [get_bd_cells /axi_interconnect_0]

次に、SmartConnect IP で MIG を使用して AXI メモリ ポートを定義する例を示します。

set parVal []
for {set i 1} {$i < 16} {incr i} {
lappend parVal S[format %02d $i]_AXI 
{memport "MIG" sptag "Bank0"}
}
set_property PFM.AXI_PORT $parVal [get_bd_cells /smartconnect_0]

次は、制御インターフェイスとメモリ インターフェイスの PFM.AXI_PORT 設定の例です。

set_property PFM.AXI_PORT {
M_AXI_HPM1_FPD {memport "M_AXI_GP"} 
S_AXI_HPC0_FPD {memport "S_AXI_HPC" sptag "HPC0" memory "zynq_ultra_ps_e_0 HPC0_DDR_LOW"}  
S_AXI_HPC1_FPD {memport "S_AXI_HPC" sptag "HPC1" memory "zynq_ultra_ps_e_0 HPC1_DDR_LOW"}  
S_AXI_HP0_FPD {memport "S_AXI_HP" sptag "HP0" memory "zynq_ultra_ps_e_0 HP0_DDR_LOW"}  
S_AXI_HP1_FPD {memport "S_AXI_HP" sptag "HP1" memory "zynq_ultra_ps_e_0 HP1_DDR_LOW"}  
S_AXI_HP2_FPD {memport "S_AXI_HP" sptag "HP2" memory "zynq_ultra_ps_e_0 HP2_DDR_LOW"}
} [get_bd_cells /ps_e]
注記:
  • zynq_ultra_ps_e_0Zynq UltraScale+ MPSoC モジュールのインターフェイス名です。
  • HPC0_DDR_LOW はアドレス範囲名です。

AXI4-Stream インターフェイスの追加

AXI4-Stream ストリーム カーネルをサポートするには、プラットフォームが該当するマスターまたはスレーブ AXI4-Stream インターフェイスを宣言する必要があります。

AXI4-Stream カーネル インターフェイスは PFM.AXIS_PORT sptag インターフェイス プロパティとそれに合った v++ リンカーへの connectivity.sc コマンド引数を使用して指定します。

Tcl コマンドの構文は、次のとおりです。

set_property PFM.AXIS_PORT { <port_name> {parameters} <port2> {parameters} ...} [get_bd_cells <cell_name>]

引数の説明

Port_name
AXI4-Stream ポート名。
パラメーター
type value: ストリーミング インターフェイス ポート タイプ。type の有効な値は、次のとおりです。
  • M_AXIS: 汎用 AXI マスター ポート
  • S_AXIS: 高パフォーマンスの AXI スレーブ ポート

set_property PFM.AXIS_PORT {AXIS_P0 {type "S_AXIS"}} [get_bd_cells /zynq_ultra_ps_e_0]
注記: カーネルとプラットフォーム間の AXI4-Stream インタフェースをリンクする方法については v++ リンカー設定ファイルの構文を参照していください (--connectivity.sc)。

クロックおよびリセットの追加

クロック ソースはプラットフォームと一緒にエクスポートできますが、各クロックに対してプラットフォームの Processor System Reset IP ブロックを使用して、同期リセット信号もエクスポートする必要があります。PFM.CLOCK プロパティは、BD セル、外部ポート、または外部インターフェイスに設定できます。

次は、PFM.CLOCK プロパティを設定する Tcl コマンドです。

set_property PFM.CLOCK { <port_name> {parameters} \
<port2> {parameters} ...} [get_bd_cells <cell_name>]

割り込みの追加

Vitis では、v++ リンク段階中にカーネル出力の IRQ 信号をプラットフォームの IRQ に自動的に接続できます。次は、その Tcl コマンド構文です。

set_property PFM.IRQ {pin_name {id id_number}} bd_cell
set_property PFM.IRQ {port_name {id id_number range irq_count}} [get_bd_cell <cell_name>]

引数の説明

Port_name
bd_cell の IRQ ポート名。
id_number
0 ~ 127 の整数。範囲が指定されている場合は、IRQ 番号または開始番号を指定します。
irq_count
バスのサイズを指定する際にパラメーター伝搬の対象となるインタフェースのラベル付けに使用されます (例: 割り込みコントローラー (intr) インタフェース)。

この例では、32 の IRQ 入力を axi_intc_0 intr ポートに対してイネーブルにする方法を示しています。

set_property PFM.IRQ {intr {id 0 range 32}} [get_bd_cells /axi_intc_0]

この例は、VCK190 ベース プラットフォームでカスケード割り込みコントローラーを使用して 63 個の IRQ をイネーブルにする方法を示しています。

set_property PFM.IRQ {intr {id 0 range 32}}  [get_bd_cells /axi_intc_cascaded_1]
set_property PFM.IRQ {In0 {id 32} In1 {id 33} In2 {id 34} In3 {id 35} In4 {id 36} In5 {id 37} In6 {id 38} In7 {id 39} In8 {id 40} \
                               In9 {id 41} In10 {id 42} In11 {id 43} In12 {id 44} In13 {id 45} In14 {id 46} In15 {id 47} In16 {id 48} In17 {id 49} In18 {id 50} \
                               In19 {id 51} In20 {id 52} In21 {id 53} In22 {id 54} In23 {id 55} In24 {id 56} In25 {id 57} In26 {id 58} In27 {id 59} In28 {id 60} \
                               In29 {id 61} In30 {id 62}} [get_bd_cells /xlconcat_0]

エクステンシブル プラットフォームのエクスポート

ハードウェア プラットフォームは、XSA ファイル形式でカプセル化されます。XSA には、ソフトウェア開発用の固定 XSA とアクセラレーション プロジェクト用のエクステンシブル XSA の 2 つのフォーマットがあります。アクセラレーション フロー用に Vitis エンベデッド プラットフォームを作成する場合は、エクステンシブル XSA を使用する必要があります。

Vivadoプロジェクト タイプが extensible Vitis platform に設定されている場合は、FileExport or WindowPlatform SetupExport Platform ボタンでプラットフォームのエクスポート メニューを使用できます。

Export Hardware Platform ウィンドウでプラットフォーム タイプを選択します。プラットフォームには、4 つのタイプがあります。エクスポートされたプラットフォームがハードウェア ボードで実行されるバイナリを生成するためだけに使用される場合は、[Hardware] を選択します。このプラットフォームを使用してハードウェア エミュレーションを実行する場合は、[Hardware Emulation] または [Hardware and Hardware Emulation] を選択します。これらの 2 つのオプションの違いは、現在のデザインの一部のモジュールがエミュレーションでサポートされていない場合、エミュレーション固有のデザインを作成し、[Hardware Emulation] としてエクスポートしてから、[Combine XSAs] オプションを使用してハードウェア XSA とハードウェア エミュレーション XSA を 1 つの XSA に結合し、両方のジョブを実行できるようにする必要がある点です。

シンプルなデザインの場合:

  1. Hardware and Hardware Emulation を選択して Next をクリックします。
  2. Pre-synthesis for Platform State オンにします。ポスト インプリメンテーションが必要なのは、DFX プラットフォームを作成する場合だけです。Next をクリックします。
  3. Platform Properties と入力します。Next をクリックします。
  4. XSA ファイル名を入力し、エクスポートするターゲット ディレクトリを指定します。Next をクリックします。
  5. サマリを確認して、Finish をクリックします。

これは、次のコマンドを使用すると、コマンド ラインでも実行できます。

set_property pfm_name {vendor:board:name:version} [get_files <bd_file>]
write_hw_platform -hw -force <XSA file>

ハードウェア XSA とハードウェア エミュレーション XSA を作成してまとめるオプションは、次のとおりです。

write_hw_platform -hw <hw_platform> 
write_hw_platform -hw_emu <hw_emu_platform>
combine_hw_platform -hw <hw_platform> -hw_emu <hw_emu_platform> -o <combined_platform>

ソフトウェア コンポーネントのアップデート

XRT へのルート ファイルシステムの追加

Vitis アクセラレーション アプリケーションでは XRT を使用してハードウェアを制御します。XRT を使用すると、Alveo™ データセンターからエンベデッドまで、さまざまなユース ケースで同じプログラミング インターフェイスを使用できます。

rootfs および sysroot に XRT カーネル ドライバー (zocl) とユーザー空間ライブラリ (xrt-dev) を追加する必要があります。xrt-dev をパッケージすると、XRT API を使用する Vitis アプリケーションをコンパイルできるようになります。

zocl のためのデバイス ツリーのアップデート

zocl ドライバー インターフェイスには、割り込み接続を有効にするためにデバイス ツリー ノードが必要です。

次は、xocl デバイス ノードの例です。

&amba {
	zyxclmm_drm {
		compatible = "xlnx,zocl";
		status = "okay";
		interrupt-parent = <&axi_intc_0>;
		interrupts = <0  4>, <1  4>, <2  4>, <3  4>,
			     <4  4>, <5  4>, <6  4>, <7  4>,
			     <8  4>, <9  4>, <10 4>, <11 4>,
			     <12 4>, <13 4>, <14 4>, <15 4>,
			     <16 4>, <17 4>, <18 4>, <19 4>,
			     <20 4>, <21 4>, <22 4>, <23 4>,
			     <24 4>, <25 4>, <26 4>, <27 4>,
			     <28 4>, <29 4>, <30 4>, <31 4>;
	};
};

詳細は、XRT の資料 (https://xilinx.github.io/XRT/master/html/yocto.html) を参照してください。

割り込みコントローラーの入力番号のアップデート

ブロック図では、割り込みコントローラーがアクセラレーション カーネルに接続されていません。自動生成されたデバイス ツリーは、ブロック図のハードウェア デザインを反映しており、v++ リンカーが割り込みコントローラーへカーネルの割り込み信号を接続する可能性は考慮していません。これらの割り込みをイネーブルするには、割り込みコントローラーの割り込み入力番号を上書きします。

次は、system-user.dtsi で AXI Interconnect のノード パラメーターを上書きする方法を示しています。

&axi_intc_0 {
	xlnx,kind-of-intr = <0x0>;
	xlnx,num-intr-inputs = <0x20>;
	interrupt-parent = <&gic>;
	interrupts = <0 89 4>;
};

/etc/xocl.txt を使用したプラットフォーム宣言

プラットフォーム名をエンベデッド プラットフォームの rootfs の /etc/xocl.txt に記述しておくと、XRT でどのプラットフォームかが判別されます。ホスト アプリケーションは、XRT API を使用してプラットフォーム名を取得し、XCLBIN とホスト アプリケーションのプラットフォームとの互換性をチェックできます。

CMA サイズの調整

XRT ではバッファー オブジェクトの割り当てに CMA が使用されます。bootargs やデバイス ツリーで CMA 用に十分なメモリを確保して、アクセラレーション アプリケーション実行中にメモリ不足にならないようにしてください。

Vitis アクセラレーション プラットフォームのパッケージ

Vitis アクセラレーション プラットフォームの要件がすべて整ったら、それらをパッケージして最終的な Vitis アクセラレーション プラットフォームを生成できます。これには、Vitis IDE またはザイリンクス ソフトウェア コマンドライン ツール (XSCT) のいずれかを使用します。

  • Vitis IDE で FileNewPlatform Project をクリックして Vitis プラットフォームを作成します。
  • XSCT を使用すると、platform コマンドでプラットフォームを作成したり、domain コマンドでドメインをプラットフォームに追加できます。XSCT の詳細は、エンベデッド ソフトウェア開発フローザイリンクス ソフトウェア コマンド ライン ツール リファレンス ガイド を参照してください。

プラットフォームは、複数のハードウェアおよびソフトウェア コンポーネントをカプセル化したものです。このカプセル化により、ハードウェア指向のエンジニアからアプリケーション エンジニアへの提出が容易になります。

プラットフォームには、次のファイルおよび情報がパッケージされます。

ハードウェア仕様
これはエクステンシブル XSA ファイルです。
ソフトウェア コンポーネント
これらはプラットフォームに OpenCL ランタイムをイネーブルにする Linux ドメインとして追加されます。
ソフトウェア コンポーネントには、次が含まれます。
  • ブート コンポーネント
    • boot.bin ファイルの生成用にブート コンポーネントおよび Bootgen のプロパティを記述した BIF ファイル。
    • BIF ファイルに記述されるすべてのファイルを含むブート コンポーネント ディレクトリ。
  • イメージ ディレクトリ (オプション): このディレクトリ内のファイルは最終的な SD カード イメージの FAT32 パーティションにコピーされます。
  • Linux ドメイン: プラットフォームには Linux ドメインが必要です。カーネル、RootFS、および sysroot 情報は、プラットフォームの作成時またはアプリケーションの作成時に追加できます。
  • エミュレーション サポート ファイル (オプション)

ルート ファイルシステム

Vitis では FAT32 および Ext4 パーティション タイプがサポートされます。ルート ファイルシステムは、Vitis のアプリケーション作成段階中に割り当てることができるので、プラットフォーム作成段階ではオプションです。

イメージ ディレクトリは、プラットフォーム作成中に設定する必要があります。このディレクトリのすべてのコンポーネントが最終 SD カード イメージにパックされます。ターゲット ファイル システムが FAT32 の場合、ファイルは SD カードのルート ディレクトリに、Ext4 の場合、ファイルは最初の FAT32 パーティションのルート ディレクトリに含まれます。

ブート コンポーネント

アプリケーション ビルド プロセスでブート イメージがパッケージされるようにするには、BIF ファイルを指定する必要があります。

次は BIF ファイルの例です。

/* linux */
the_ROM_image:
{
  [fsbl_config] a53_x64
  [bootloader] <fsbl.elf>
  [pmufw_image] <pmufw.elf>
  [destination_device=pl] <bitstream>
  [destination_cpu=a53-0, exception_level=el-3, trustzone] <bl31.elf>
  [destination_cpu=a53-0, exception_level=el-2] <u-boot.elf>
}

BIF で記述されるファイルすべてを含むブート コンポーネント ディレクトリも指定する必要があります。この例では、コンポーネント ディレクトリに fsbl.elfpmufw.elfbl31.elf、および u-boot.elf が含まれます。これらのブート コンポーネントは PetaLinux で生成できます。

Vitis アプリケーション ビルドおよびパッケージ ステートでは、v++ でブート コンポーネント ディレクトリ内のファイルが検索され、実際のファイル名とパスでプレースホルダーが置換されます。この後 Bootgen が呼び出されて BOOT.BIN が生成されます。

プラットフォームのテスト

アプリケーション開発者にプラットフォームを送信する前に、基本的なプラットフォーム テストを実行して、アクセラレーション アプリケーションで正しく動作することを確認してください。

通常、プラットフォームが次のテストをパスするようにする必要があります。

ブート テスト
Vivado プロジェクトで生成したインプリメンテーション結果の BIT ファイル (ハードウェア インターフェイスの追加から) および PetaLinux で生成したイメージ (ソフトウェア コンポーネントのアップデートから) で問題なく Linux コンソールを起動できるようにする必要があります。
プラットフォーム テスト
Vitis アクセラレーション プラットフォームのパッケージで生成したプラットフォームには、クロックとメモリ情報を示す platforminfo レポートが含まれている必要があります。
XRT 基本テスト
XRT の xbutil query ユーティリティがターゲット ボードで実行でき、正しいプラットフォーム情報をレポートするようにする必要があります。
Vadd テスト
Vitis でプラットフォームを使用した Vector Addition サンプル アプリケーションを生成する必要があります。生成されたアプリケーションと xclbin により、ボードに test pass と表示される必要があります。

エクステンシブル XSA のハードウェア エミュレーションのイネーブル

次の手順は、カスタム プラットフォームの開発者用です。

  1. 必要な BD、RTL、テストベンチ、およびその他のソースを使用して Vivado プロジェクトを作成します。
    1. 2020.1 では、BD で使用できたのは HW EMU だけでしたが、2020.2 からは、その他のソースも使用できるようになりました。
    2. Versal ACAP の場合のみ、テストベンチに BD を直接含めるのではなく、 BD ラッパーを含める必要があります。これは、Vitis が NoC をシミュレーションに挿入するジョブをこのレベルで実行するためです。
    3. Versal ACAP の場合のみ、Vitis プラットフォームで AI エンジン をイネーブルにするには、1 つのスレーブ AXI4 メモリ マップド ポートだけをイネーブルにし、NoC に接続するように AI エンジン ブロックを設定する必要があります。AI エンジン グラフ ソフトウェアに基づく Vitis は、v++ リンク段階で追加の自動接続をします。
    4. DFX プラットフォームの場合は、Vitis ツールがアクセラレータを正しく接続できるように、ダイナミック領域 BD で正しい PFM プロパティを指定する必要があります。
  2. HW エミュレーションを XSA にパッケージするようにデザインをアップデートします。
    1. デザインは XSA にパッケージする前に、シミュレータで正しく実行されていることが重要です。
    2. Versal ACAP の場合のみ、SystemC モデルをイネーブルにするプラットフォーム デザインを準備する必要があります。SELECTED_SIM_MODEL プロパティを TLM に変更するように、CIPS および NoC IP 設定を更新します。これにより、CIPS IP でソフトウェアを実行できる QEMU モデルが使用されるようになります。デザインでは、次の Tcl コマンドを使用できます。また、Vivado で SystemC シミュレーションをイネーブルにするようにパラメーターを設定します。
      foreach tlmCell [get_bd_cells * -hierarchical -filter {VLNV =~ "*:*:axi_noc:*" || VLNV =~ "*:*:versal_cips:*"}] {set_property SELECTED_SIM_MODEL tlm $tlmCell }
      set_param bd.generateHybridSystemC true
    3. sim_1 fileset にテストベンチを作成し、デザインの <top> モジュールをインスタンシエートします。Versal ACAP の場合、Vivado でテストベンチが <top> モジュールを直接インスタンシエートしないようにする必要があります。代わりに、<top>_sim_wrapper モジュールをインスタンシエートしてください。launch_simulation -scripts_only コマンドを呼び出すと、<top>_sim_wrapper.v というファイルが生成されます。このモジュールのインターフェイスは <top> モジュールと同じですが、集約型 NoC モジュールに関連する追加のシミュレーション モデル (デザインにインスタンシエートされたさまざまな論理 NoC モジュールから作成) をインスタンシエートする点が異なります。
    4. デザインをコンパイルし、上記の手順を実行して、シミュレーションを開始します。デザインは QEMU を使用するように設定されているため、Vivado シミュレータでシミュレーションする際に SW が存在しないので、CIPS IP はトランザクションを生成しません。Vivado シミュレーションでは次のエラーメッセージが表示されますが、基本デザインがシミュレータに正しく読み込まれたことを示しています。
      ##############################################################
      #
       #  Simulation does not work as Versal CIPS Emulation (SELECTED_SIM_MODLE=tlm) only works with Vitis tool(launch_emulator tool in Vitis)
      #
      ##############################################################
       
      ERROR: [Simtcl 6-50] Simulation engine failed to start: The Simulation shut down unexpectedly during initialization.
      注記: デザインのトランザクションが正しいかどうかは、オプションで CIPS VIP を使用してデザインのシミュレーションを実行してから、TLM (QEMU) を使用するように変更して確認します。まず、NoC および CIPS IP の SELECTED_SIM_MODEL プロパティを RTL にする必要があります。また、CIPS VIP を駆動し、NoC Verilog モデルの要件も満たす別のテストベンチを作成します。Verilog ベースのシミュレーション用にテストベンチを設定する方法は、CIPS VIP および NoC IP の資料を参照してください。
  3. ハードウェア エミュレーションのみの XSA をパッケージします。
    1. ハードウェア エミュレーション プラットフォームをエクスポートするには、Vivado FileExportExport Platform をクリックするか、次の Tcl コマンドを使用します。
      set_property platform.platform_state "pre_synth" [current_project]
      write_hw_platform -hw_emu -file  platform_hw_emu.xsa
    2. この XSA とプリビルドされた Linux イメージや PetaLinux を一緒に使用すると、カスタム Linux イメージを作成して、完全なプラットフォームを構築できます。その後、残りの Vitis ツールを使用して、XRT で設計するカーネルを追加できます。

エンベデッド プラットフォームを作成する際の注意事項

プラットフォームとカーネルへのロジック機能の分割

FPGA および SoC を含むデザインが複雑になってきたため、複数の開発者やチームが共同で開発することが多くなっています。Vitis ソフトウェア プラットフォームでは、アプリケーション開発とプラットフォーム開発をはっきりと分けることができます。プラットフォーム開発者には、ボード開発者、BSP 開発者、システム ソフトウェア開発者などが含まれます。

システム アーキテクトに不明なロジック機能があったとしても、それらをプラットフォームと一緒にパッケージしたり、アクセラレーション カーネルとして使用したりできます。システム ブロックをわけやすくするため、次のような一般的なガイドラインがあります。

  • 関数をカーネルまたはプラットフォームとして分類する場合は、まずそれがアプリケーションに関連するロジックであるかどうかを考慮します。
  • プラットフォームは、アプリケーションよりも安定している必要があります。アプリケーション関数の変更は、ソフトウェアとカーネルでのみ実行する必要があります。
  • プラットフォームではハードウェアが抽象化されます。ハードウェア ボードを変更する場合、アプリケーションはまったく変更しないか、必要に応じて少しだけ変更するだけで、新しいハードウェアにターゲットを変更できるはずです。
  • Vitis ツールの制約および制限に従ってください。次に例を示します。
    • Vitis アクセラレーション カーネルでサポートされるインターフェイスは、AXI MM、AXI4-Lite、および AXI4-Stream の 3 種類だけです。
    • AXI カーネルでは、外部 I/O ピンがサポートされません。

次の表は、ロジック タイプ別に推奨されるプラットフォームとカーネルを示しています。

ロジック プラットフォーム カーネル
ハード プロセッサ (Zynq および Zynq UltraScale+ MPSoC の PS) プラットフォームのみ
ソフト プロセッサ プラットフォームを推奨 RTL カーネルとしては可
I/O ブロック (外部ピン、MIPI、PHY など) プラットフォームのみ
I/O ブロックに関連する IP (DMA for PCIe®、MAC for Ethernet など) I/O および IP 間のインターフェイスは AXI ではないので、通常はプラットフォーム I/O ブロックと IP 間のインターフェイスは AXI なので、カーネルとしては可
AXI 以外のインターフェイスを使用する IP プラットフォームのみ インターフェイスを AXI MM または AXI4-Stream に変更できる場合のみ可
Linux ドライバー (VPSS など) を含む従来のメモリ マップド IP プラットフォームのみ
HLS AXI メモリ マップド IP プラットフォームでのみ可。制御ソフトウェアを記述する必要があります。 カーネルを推奨。XRT によって制御されます。
Vitis カーネル レジスタの規格に従い、XRT から使用可能なアクセラレーション メモリマップド IP カーネルを推奨
Vitis ライブラリ カーネルとしてのみ可
AXI4-Stream インターフェイスを使用するフリーランニング IP

参考資料

エンベデッド プラットフォームの詳細は、次を参照してください。