RTL カーネル: krnl_cbc

概要

この部分のチュートリアルでは、もう 1 つの RTL カーネル、krnl_cbc を紹介します。

このカーネルには AXI マスター インターフェイスがあり、オンボード グローバル メモリ内の入力/出力データにアクセスし、AXI ストリーム マスター/スレーブ ポートを介してデータを送受信します。このカーネルは、完全な AES プロセス ファンクションをインプリメントするため、Vitis v++ リンク段階で AXI ストリーム ポートを介して krnl_aes カーネルに接続されます。krnl_cbc では、AES-ECB および AES-CBC モードがサポートされています。

ここでも、波形表示を除き、GUI サポートなしですべての手順を完了するには、コマンド ライン Tcl スクリプトを使用します。krnl_cbc カーネルには 4 つの内部処理パイプがあり、krnl_aes の 4 つの AES エンジンに対応しており、ユーザーに対して透過的になっています。ap_ctrl_chain 実行モデルは krnl_cbc でサポートされており、内部エンジンの数を把握しなくても、ハードウェアの並列アクセラレーション機能を完全に利用できます。AES コア エンジンと外部 AXI ストリーム リンクを持つ CBC 制御ユニット間の接続を実現するのは、実際にはあまり効率的ではありません。Vitis の機能とデザイン フローを示すため、このようにインプリメントしただけです。

カーネルの機能

次の krnl_cbc カーネルのブロック図を参照してください。4 つの同一の CBC エンジンがあり、エンジン制御ユニットを介して AXI 読み出しマスターから入力データを受信します。そして、AXI ストリーム ポートを介して krnl_aes カーネルとの間でデータを送受信し、その結果を engine control ユニットを介して AXI 書き込みマスターに送信します。

必要なカーネル引数を設定するには、AXI 制御スレーブ モジュールが使用されます。krnl_cbc カーネルは、グローバル メモリに格納されている入力/出力グループ別のワードを使用してタスクを終了します。各内部エンジンは、一度に 1 つのワード グループを処理します。連続する入力グループは、engine control モジュールごとにラウンドロビン方式で異なる内部 CBC エンジンに割り当てられます。krnl_cbc カーネルは、すべての内部モジュールに 1 つのカーネル クロックを使用します。

krnl_cbc カーネルは ap_ctrl_chain 実行モデルをサポートします。ap_ctrl_chain は ap_ctrl_hs モデルの拡張であり、カーネルの実行は input sync と output sync 段階に分割されます。制御信号の ap_start および ap_ready は input sync に使用されますが、ap_done および ap_continue は output sync に使用されます。詳細は、「サポートされるカーネル実行モデル」を参照してください。

次の図は、2 ビート入力同期と 2 ビート出力同期の ap_ctrl_chain モジュールの波形例を示しています (カーネルは 2 つのジョブを連続して実行します)。

input sync の場合、クロック エッジ a と b で ap_ready 信号によって ap_start が検証およびディアサートされ、カーネルの実行を同時にトリガーします (これは AXI ストリーム プロトコルの TREADY によって検証された TVALID と多少似ています)。XRT スケジューラは、ap_start 信号のステータスを検出し、信号が Low の場合に ap_start をアサートし、カーネルが新しいタスクを受け入れられるようになったことを示します。ap_ready 信号はカーネルによって生成され、そのステータスを示します。

output sync の場合、クロック エッジ c および d で ap_done が確認され、ap_continue 信号によってディアサートされ、1 つのカーネル ジョブが完了したことを示します。XRT スケジューラが ap_done 信号のアサートを検出すると、XRT が ap_continue をアサートします。通常は、これは 1 サイクルのみを維持するように、セルフクリア信号としてインプリメントする必要があります。

波形からは、これは ap_done 信号がアサートされる前に確認でき、カーネルは ap_ready 信号を使用して XRT に新しい入力データを受け入れられるようになったことを知らせします。このスキームは、タスク パイプラインがハードウェア機能を完全に活用できるように、input sync 段階のバック プレッシャーとして機能します。上記の波形例では、XRT は AXI 制御スレーブ レジスタに ap_start ビットと ap_continue ビットをそれぞれ 2 回ずつ書き込みます。

次の表は、AXI スレーブ ポートに含まれるすべての制御レジスタとカーネルの引数をリストしています。このカーネルでは、割り込みはサポートされません。

名前	アドレス オフセット	幅 (ビット)	内容
CTRL	0x000	5	制御信号。 ビット 0 - ap_start ビット 1 - ap_done ビット 2 - ap_idle ビット 3 - ap_ready ビット 4 - ap_continue
MODE	0x010	1	カーネル暗号モード: 0 - 復号化 1 - 暗号化
IV_W3	0x018	32	AES-CBC モードの初期化ベクター、ワード 3
IV_W2	0x020	32	AES-CBC モードの初期化ベクター、ワード 2
IV_W1	0x028	32	AES-CBC モードの初期化ベクター、ワード 1
IV_W0	0x030	32	AES-CBC モードの初期化ベクター、ワード 0
WORDS_NUM	0x038	32	処理する 128 ビット ワードの数
SRC_ADDR_0	0x040	32	入力データ バッファー アドレス、LSB
SRC_ADDR_1	0x044	32	入力データ バッファー アドレス、MSB
DEST_ADDR_0	0x048	32	出力データ バッファー アドレス、LSB
DEST_ADDR_1	0x04C	32	出力データ バッファー アドレス、MSB
CBC_MODE	0x050	1	暗号処理モード: 0 - AES-ECB モード 1 - AES-CBC モード

IP の生成

このデザイン例では、デザイン IP を使用していません。シミュレーションには検証 IP のみを使用します。

• AXI マスター VIP

• AXI スレーブ VIP

これらの IP は、~/krnl_cbc/gen_ip.tcl と呼ばれる Tcl スクリプトで生成されています。

Vivado IP および Vitis カーネルへのデザインのパック

Vitis の RTL カーネル デザインの重要な手順の 1 つは、RTL デザインを Vitis カーネル ファイル (XO ファイル) にパッケージすることです。GUI の RTL カーネル ウィザードを使用すると、Vitis カーネルを作成しやすくなります。Vivado の IP パッケージャーを使用してデザインを Vivado IP にパッケージし、XO ファイルを生成することもできます。Vivado には Vitis カーネル生成用のコマンドライン フローも提供されており、GUI バージョンと同じジョブを実行できます。

このチュートリアルでは、krnl_aes カーネルの場合と同様に、Vivado Tcl コマンドを使用して、krnl_cbc IP パッケージと XO ファイル生成をバッチ モードで終了します。このデザインの完全なカーネル生成スクリプトは、~/krnl_cbc/pack_kernel.tcl にあります。主な手順は、次のとおりです。詳細は、スクリプトを参照してください。

注記: スクリプトの各ステップには、GUI に対応するツールがあります。GUI バージョンの IP パッケージ ツールの使用方法は、「RTL カーネル」を参照してください。

1: Vivado プロジェクトの作成およびデザインソースの追加

まず、ソース ファイルを含む Vivado プロジェクトを作成する必要があります。スクリプトは Tcl コマンドの create_project、add_files、および update_compiler_order を使用して、この手順を終了します。krnl_cbc の場合、新しく作成されたプロジェクトに追加するのは RTL ソース コード ファイルのみです。

次に、ipx::package_project Tcl コマンドを使用して、IP パッケージ プロセスを次のように初期化します。

create_project krnl_cbc ./krnl_cbc add_files -norecurse { ../rtl/axi_master_counter.sv \ ../rtl/axi_read_master.sv \ ... ... } update_compile_order -fileset sources_1 ipx::package_project -root_dir ./krnl_cbc_ip -vendor xilinx.com -library user -taxonomy /UserIP -import_files -set_current true 

2: クロック、リセット、AXI インターフェイスの推論およびクロックとの関連付け

まず、ipx::infer_bus_interface コマンドを使用して ap_clk および ap_rst_n を AXI バス信号として推論します。一般に、ap_clk が RTL カーネルで使用される唯一のクロックである場合、このコマンドは省略できます。デザインでより多くのクロック (ap_clk_2、ap_clk_3 など) を使用する場合は、ipx::infer_bus_interface コマンドを使用してポートを明示的に推論する必要があります。

ipx::infer_bus_interface ap_clk xilinx.com:signal:clock_rtl:1.0 [ipx::current_core] ipx::infer_bus_interface ap_rst_n xilinx.com:signal:reset_rtl:1.0 [ipx::current_core] 

すべての AXI インターフェイスは自動的に推論されます。このデザインでは、これらの AXI ポートに次が含まれます。

• 制御 AXI スレーブ ポート 1 つ: s_axi_control

• AXIS スレーブ ポート 4 つ: axis_slv0 ~ 3

• AXIS マスター ポート 4 つ: axis_mst0 ~ 3

• AXI マスターポート 2 つ: axi_rmst および axi_wmst

次に、ipx::associate_bus_interfaces コマンドを使用して、自動的に推論推測される AXI インターフェイスとリセット信号を ap_clk に関連付けます。

ipx::associate_bus_interfaces -busif s_axi_control -clock ap_clk [ipx::current_core] ipx::associate_bus_interfaces -busif axi_rmst -clock ap_clk [ipx::current_core] ipx::associate_bus_interfaces -busif axi_wmst -clock ap_clk [ipx::current_core] ipx::associate_bus_interfaces -busif axis_mst0 -clock ap_clk [ipx::current_core] ... ipx::associate_bus_interfaces -busif axis_slv0 -clock ap_clk [ipx::current_core] ... ipx::associate_bus_interfaces -clock ap_clk -reset ap_rst_n [ipx::current_core] 

3: CTRL やユーザー カーネル引数を含む AXI 制御スレーブ レジスタの定義の設定

ここでは、ipx::add_register コマンドを使用して、レジスタを推論された s_axi_control インターフェイスに追加し、set_property コマンドを使用してそのレジスタのプロパティを設定します。たとえば、次の例では、CBC_MODE カーネル引数を使用したこのプロセスを示しています。

ipx::add_register CBC_MODE [ipx::get_address_blocks reg0 -of_objects [ipx::get_memory_maps s_axi_control -of_objects [ipx::current_core]]] set_property description {cbc mode} [ipx::get_registers CBC_MODE -of_objects [ipx::get_address_blocks reg0 -of_objects [ipx::get_memory_maps s_axi_control -of_objects [ipx::current_core]]]] set_property address_offset {0x050} [ipx::get_registers CBC_MODE -of_objects [ipx::get_address_blocks reg0 -of_objects [ipx::get_memory_maps s_axi_control -of_objects [ipx::current_core]]]] set_property size {32} [ipx::get_registers CBC_MODE -of_objects [ipx::get_address_blocks reg0 -of_objects [ipx::get_memory_maps s_axi_control -of_objects [ipx::current_core]]]] 

上記の例には、次が含まれます。

• CBC_MODE はカーネルの引数名です。

• cbc mode はレジスタの説明です。

• 0x050 はレジスタのアドレス オフセットです。

• 32 は、レジスタのデータ幅です (すべてのスカラー カーネル引数は 32 ビット幅の必要あり)。

提供される Tcl スクリプトからは、前の表で定義されたすべてのレジスタが追加され、正しく定義されていることがわかります。ここでは 2 つの特殊なカーネル引数は SRC_ADDR と DEST_ADDR です。これらは AXI マスター アドレス ポインター用で、すべて 64 ビット幅です。次の手順では、これらを AXI マスター ポートに関連付けます。

4: AXI マスター ポートのポインター引数への関連付けおよびデータ幅の設定

ipx::add_register_parameter および set_property コマンドを使用して、アドレス ポインター引数と AXI マスター ポート間の接続を作成します。たとえば、AXI 読み出しマスターの axi_rmst の場合、次のコマンド ラインのようになります。

ipx::add_register_parameter ASSOCIATED_BUSIF [ipx::get_registers SRC_ADDR -of_objects [ipx::get_address_blocks reg0 -of_objects [ipx::get_memory_maps s_axi_control -of_objects [ipx::current_core]]]] set_property value {axi_rmst} [ipx::get_register_parameters ASSOCIATED_BUSIF \ -of_objects [ipx::get_registers SRC_ADDR \ -of_objects [ipx::get_address_blocks reg0 \ -of_objects [ipx::get_memory_maps s_axi_control \ -of_objects [ipx::current_core]]]]] 

次の例に示すように、ipx::add_bus_parameter および set_property コマンドを使用すると、AXI マスター データ幅を正しく設定できます。

ipx::add_bus_parameter DATA_WIDTH [ipx::get_bus_interfaces axi_wmst -of_objects [ipx::current_core]] set_property value {128} [ipx::get_bus_parameters DATA_WIDTH -of_objects [ipx::get_bus_interfaces axi_wmst -of_objects [ipx::current_core]]] 

DATA_WIDTH プロパティが生成されたカーネル XML ファイルに書き込まれます。

5: Vivado IP のパッケージと Vitis カーネル ファイルの生成

この手順では、set_property コマンドを使用して、2 つの必須のプロパティ (sdx_kernel および sdx_kernel_type) を設定します。次に、ipx::update_source_project_archive および ipx::save_core コマンドを実行して、Vivado プロジェクトを Vivado IP にパッケージします。最後に、package_xo コマンドを使用して Vitis XO ファイルを生成します。

set_property sdx_kernel true [ipx::current_core] set_property sdx_kernel_type rtl [ipx::current_core] ipx::update_source_project_archive -component [ipx::current_core] ipx::save_core [ipx::current_core] package_xo -force -xo_path ../krnl_cbc.xo -kernel_name krnl_cbc -ctrl_protocol ap_ctrl_chain -ip_directory ./krnl_cbc_ip -output_kernel_xml ../krnl_cbc.xml 

上記の package_xo コマンドの使用方法では、カーネル記述 XML ファイルを自動的に生成するようにツールを設定していますので、手動で作成する必要はありません。

カーネル XML ファイルの手動作成

Vitis 対応の Vivado IP が存在し、そこから XO ファイルを生成する必要がある場合は、カーネル XML ファイルを手動で作成し、次のようにコマンドで指定することもできます。

package_xo -xo_path ../krnl_cbc.xo -kernel_name krnl_cbc -ip_directory ./krnl_cbc_ip -kernel_xml ../krnl_cbc.xml 

この場合、カーネル実行モデルは package_xo コマンド ライン オプションではなく、hwControlProtocol プロパティを使用して XML ファイルで指定します。

テストベンチ

ザイリンクス AXI VIP を使用した krnl_cbc モジュール用のシンプルな SystemVerilog テストベンチが提供されています。テストベンチ ソースは ~/krnl_cbc/tbench ディレクトリにあります。このテストベンチには krnl_aes モジュールがインスタンシエートされ、AXI ストリーム リンクを使用して krnl_cbc に接続されます。メモリ モードでは 2 つの AXI スレーブ VIP が使用され、2 つの AXI マスター VIP は引数の設定とカーネル実行の制御に使用されます。

krnl_aes の場合、AXI マスター VIP は AES キー拡張動作用に ap_ctrl_hs プロトコルをエミュレートします。krnl_cbc の場合、AXI マスター VIP は連続タスク プッシュのために ap_ctrl_chain プロトコルをエミュレートします。テストベンチでは、入力データと出力データが多くのワードを含むグループに分割されます。input sync と output sync は両方ともテストベンチでエミュレートされます。詳細は、tb_krnl_cbc.sv ファイルを参照してください。

テストベンチへの入力ランダム データは Perl スクリプトの ~/common/plain_gen.pl で生成され、出力チェック用の基準データは OpenSSL ツールで生成されます。~/krnl_cbc/runsim_krnl_cbc_xsim.sh シェル スクリプトを使用して、入力スティミュラスと出力基準を生成し、Vivado XSim でシミュレーションを実行します。

カーネル テスト システムとオーバーレイ (XCLBIN) の生成

krnl_cbc のテスト システム オーバーレイを構築するには、システムに krnl_cbc と krnl_aes の両方を統合する必要だけがあります。

ホスト プログラミング

ホスト プログラミングでは、XRT ネイティブ C++ API を使用して、FPGA でのカーネル実行を制御できます。XRT ネイティブ API は、非常にわかりやすく使いやすいものです。特にホスト カーネル間の頻繁なやり取りを必要とする場合に、XRT OpenCL よりも効率が上がります。XRT ネイティブ API の詳細は、「XRT ネイティブ API」を参照 してください。

ホスト プログラムは、ランダム データをプレーン入力として生成し、OpenSSL AES API を使用して基準暗号データを生成します。AES-ECB および AES-CBC モードの両方がテストされます。PCIe データ転送は、小さなデータ ブロックに対してはまったく効率的ではないので、ホスト プログラムでは、多数の 128 ビット入力データを 1 つのグループに割り当て、一度に複数のグループを FPGA に転送します。コードでは、入力データと出力データの両方に対して、各データ グループの FPGA サブバッファーを作成します。ハードウェアの制限から、各グループのワード数は 16 の倍数で、最大許容値は1008 (~16Kbyte) です。

ホスト テスト プログラムでは、ハードウェア エミュレーション (hw_emu) フローもサポートされており、hw または hw_emu モードの正しい XCLBIN ファイルが選択されます。

ap_ctrl_chain 実行モデルの場合、ホスト プログラムがマルチスレッド技術を使用して、マルチタスクをカーネルに同時にプッシュします。各サブスレッドでは、run.start() 関数の後に run.wait() 関数が続きます。プログラムには、ap_ctrl_hs モード実行をエミュレートするオプションもあります。これら 2 つのモードのパフォーマンスは、明らかに違うのがわかります。

チュートリアルの使用方法

開始前の確認事項

このチュートリアルでは、~/krnl_cbc ディレクトリ内のファイルを使用します。

このチュートリアルでのホスト プログラムの実行を除くすべての手順は、GNU Make によって終了します。このデザイン例では、4 つの Alveo カード (U200、U250、U50、U280) がサポートされています。また、使用する Alveo カードに該当する行のコメント文字を解除して、各カードの ~/krnl_cbc/Makefile を変更する必要があります。

 41 # PART setting: uncomment the line matching your Alveo card 42 PART := xcu200-fsgd2104-2-e 43 #PART := cu250-figd2104-2L-e 44 #PART := xcu50-fsvh2104-2-e 45 #PART := xcu280-fsvh2892-2L-e 46 47 # PLATFORM setting: uncomment the lin matching your Alveo card 48 PLATFORM := xilinx_u200_xdma_201830_2 49 #PLATFORM := xilinx_u250_xdma_201830_2 50 #PLATFORM := xilinx_u50_gen3x16_xdma_201920_3 51 #PLATFORM := xilinx_u280_xdma_201920_3 

または、この変更をせずに、コマンド ライン オプションを使用してデフォルト設定を上書きすることもできます。次の手順では、例として U50 カードの make ツールを使用します。

make xxx PART=xcu50-fsvh2104-2-e PLATFORM=xilinx_u50_gen3x16_xdma_201920_3

開始する前に、XRT および Vitis インストール パスで設定スクリプトを読み込んでいることを確認してください。例:

source /opt/xilinx/xrt/setup.sh source /tools/Xilinx/Vitis/2020.2/settings64.sh

チュートリアルの手順

1.IP の生成

make gen_ip 

これにより、Vivado がバッチ モードで起動し、~/krnl_cbc/gen_ip.tcl が呼び出されて、必要なすべてのデザイン IP と Verification IP が生成されます。

2.スタンドアロン シミュレーションの実行

make runsim 

これにより、~/krnl_cbc/runsim_krnl_cbc_xsim.sh が呼び出され、Vivado XSim でシミュレーションが実行されます。

次の図に、krnl_cbc の制御信号波形を示します。ap_done がアサートされる前に、ap_start パルスが 4 つ発生します。次に、ap_done フラグを確認するため、ap_continue パルスが 4 つ発生します。krnl_cbc には内部プロセッシング パイプが 4 つあるため、4 つのタスク要求を受け付け、並列に処理できます。

3.Vivado IP のパッケージと Vitis カーネル ファイルの生成

make pack_kernel 

これにより、Vivado がバッチ モードで起動し、~/krnl_cbc/pack_kernel.tcl が呼び出されて、RTL ソースが Vivado IP にパッケージされます。この後、Vitis カーネル ファイル ~/krnl_cbc/krnl_cbc.xo が生成されます。

4.カーネル テスト システムのオーバーレイ ファイルの構築

注記: xilinx_u200_xdma_201830_2、xilinx_u250_xdma_201830_2、または xilinx_u280_xdma_201920_3 プラットフォームを使用している場合は、~/krnl_cbc/krnl_cbc_test.xdc の 2 行目、5 行目、または 8 行目のコメントを解除する必要があります。

 1 # if you are using xilinx_u200_xdma_201830_2 platform, please uncomment following line 2 # set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets pfm_top_i/static_region/slr1/base_clocking/clkwiz_kernel/inst/CLK_CORE_DRP_I/clk_inst/clk_out1] 3 4 # if you are using xilinx_u250_xdma_201830_2 platform, please uncomment following line 5 # set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets pfm_top_i/static_region/slr0/base_clocking/clkwiz_kernel2/inst/CLK_CORE_DRP_I/clk_inst/clk_out1] 6 7 # if you are using xilinx_u280_xdma_201920_3 platform, please uncomment following line 8 #set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets pfm_top_i/static_region/base_clocking/clkwiz_kernel/inst/CLK_CORE_DRP_I/clk_inst/clk_out1] 

ハードウェア ターゲットの場合

ハードウェア ターゲットの場合は、次のコマンドを使用します。

make build_hw 

これにより、システム オーバーレイ ファイル ~/krnl_cbc/krnl_cbc_test_hw.xclbin が構築 されます。

ハードウェア エミュレーション ターゲットの場合

ハードウェア エミュレーション ターゲットの場合は、次のコマンドを使用します。

make build_hw TARGET=hw_emu 

これにより、システム オーバーレイ ファイル ~/krnl_cbc/krnl_cbc_test_hw_emu.xclbin が構築 されます。

5.ホスト プログラムのコンパイル

make build_sw 

これで、ホスト C++ プログラムのコンパイルは終了です。hw と hw_emu モジュールの両方に対して実行可能ファイル (~/krnl_cbc/host_krnl_cbc_test) が生成されます。

ターゲット カードのデバイス ID の検出

ホスト マシンに複数の Alveo カードがインストールされている場合は、xbutil list コマンドを使用してターゲット カードのデバイス ID を見つけます。例:

xbutil list ... [0] 0000:d8:00.1 xilinx_u250_gen3x16_base_3 user(inst=131) [1] 0000:af:00.1 xilinx_vck5000-es1_gen3x16_base_2 user(inst=130) [2] 0000:5e:00.1 xilinx_u50_gen3x16_xdma_201920_3 user(inst=129) 

この例では、ターゲット カードが U50 の場合、デバイス ID は 2 です。~/krnl_cbc/host/host_krnl_cbc_test.cpp の 32 行目を次のように変更する必要があります。

 30 // Please use 'xbutil list' command to get the device id of the target alveo card if multiple 31 // cards are installed in the system. 32 #define DEVICE_ID 2

6.ハードウェア エミュレーションの実行

ハードウェア エミュレーション用の XCLBIN ファイル (~/krnl_cbc/krnl_cbc_test_hw_emu.xclbin) が生成されると、ハードウェア エミュレーションを実行して、プラットフォーム環境でカーネルを検証し、デバッグや詳細なプロファイリングを実行できます。また、異なるオプションを使用して、ap_ctrl_hs モードと ap_ctrl_chain モード間のさまざまな動作を比較します。

まず、次のコマンドを使用して hw_emu モードをイネーブルにします。PLATFORM_NAME は、使用している Alveo プラットフォームです。このプラットフォームは xilinx_u200_xdma_201830_2 (デフォルト)、xilinx_u250_xdma_201830_2、xilinx_u280_xdma_201920_3 または xilinx_u50_gen3x16_xdma_201920_3 のいずれかになります。

source setup_emu.sh -s -p PLATFORM_NAME

次に、次のコマンドを使用して、ap_ctrl_chain モードでプログラム (グループ別のワードが 64、グループ番号が 4) を実行します。

./host_krnl_cbc_test -w 64 -g 4 

生成された wdb 波形データベースで、krnl_cbc の AXI ストリーム スレーブ ポートを選択すると、カーネルの動作ステータスを反映させることができます。波形ウィンドウに emu_wrapper.emu_i.krnl_aes_1.inst.krnl_aes_axi_ctrl_slave_inst.status[3:0] 信号を追加して、krnl_aes の AES エンジンのステータスを取得することもできます。

波形のスナップショットは次のとおりです。4 つの AES エンジンが並行して動作し、4 つの連続する入力データ グループを処理していることがわかります。

一方、次のコマンドを使用してエミュレーションを実行すると、ap_ctrl_hs 実行モデルがエミュレートされます。

./host_krnl_cbc_test -w 64 -g 4 -s 

次の図は、この波形を示しています。カーネルが処理する入力データグループは 1 回につき 1 つだけなので、常にアイドル状態のプロセッシング エンジンが 3 つあることがわかります。

次の図は、ap_ctrl_chain モードの AXI 制御スレーブの制御信号の動作を示しています。これは、前のスタンドアロン シミュレーション段階の波形に類似しています。

~/krnl_cbc/xrt.ini ファイルは、次のように XRT エミュレーション オプションを制御するために使用されます。3 行目の user_pre_sim_script=/home/workspace/bottom_up_rtl_kernel/krnl_cbc/xsim.tcl は、XSim が使用するシミュレーション前 Tcl スクリプトへの絶対パスを設定することで、すべての信号の波形をダンプするように指定しています。

注記: 実際のパスに合わせてパスを変更してください。

 1 [Emulation] 2 debug_mode=batch 3 user_pre_sim_script=/home/workspace/bottom_up_rtl_kernel/krnl_cbc/xsim.tcl 4 5 [Debug] 6 profile=true 7 timeline_trace=true 8 data_transfer_trace=coarse 

7.ホスト プログラムのハードウェア モードでの実行

前の手順でハードウェア エミュレーションを試した場合は、次のコマンドをまず実行して、hw_emu モードを無効にする必要があります。

source setup_emu.sh -s off

次に、コンパイルされた host_krnl_cbc_test ファイルを実行して、ハードウェア モードでシステムをテストできます。-s コマンド オプションを使用して ap_ctrl_chain 実行モードを無効にすると、パフォーマンスの違いを比較できます。

./host_krnl_cbc_test # execute in ap_ctrl_chain mode ./host_krnl_cbc_test -s # execute in emulated ap_ctrl_hs mode 

カーネルの実行時間が非常に短いため、CPU/XRT がカーネルと頻繁にやり取りする必要があります。このため、プログラムでレポートされるパフォーマンス データは、CPU/PCIe レイテンシによるさまざまな実行間で異なる場合があります。

---

このチュートリアルはこれで終了です。