KUMICO

COLUMN

ソフトエンジニア向けFPGAでOpenCL™を始めるっ! OpenCL™サンプルデザインの動作確認その2

今回は、第5回 OpenCL™サンプルデザインの動作確認その2です。

FPGAでOpenCL™を始めるのってソフトウェアエンジニアにとって技術的に敷居が高いと感じている方向けに、
Intel®のFPGAを利用して数回にわたりコラムを掲載させて頂きます。

OpenCL™って何?という方は、こちらをどうぞ。FPGAの利点も記載されておりますのでご参照ください。

下記は、前回までのおさらいです。

第4回:OpenCL™サンプルデザインの動作確認
https://www.fsi-embedded.jp/kumico/column/689/

第3回:OpenCLTMサンプルデザインのコンパイル
https://www.fsi-embedded.jp/kumico/column/472/

第2回:インストールと環境構築
https://www.fsi-embedded.jp/kumico/column/306/

第1回:ハードとソフトの準備
https://www.fsi-embedded.jp/kumico/column/191/

前回までに用意した下記のファイル・フォルダご用意ください。

■ boardtestのビルド結果
フォルダロケーション:
<home_folder>/intelFPGA_std/18.0/hld/board/terasic/de10_nano/exsamples/boardtest

■ Device Tree Sourceファイル
ファイル名:socfpga.dts

前回では、boardtestを実行した際にエラーが出力され、動作確認が取れませんでした。
boardtestを実行した際に、sysfsの仕組みを利用してRTEがFPGAのコンフィグを行っています。
Linux Kernelが新しくなったことにより、RTEがFPGAのコンフィグを行う方法が古いLinux Kernelの方法のため、エラー表示となっていました。

RTEを利用せずにルートファイルシステムからFPGAをコンフィグする方法に変更することによりFPGAのコンフィグが可能です。

今回は、FPGAをコンフィグする方法を変更して再度チャレンジします。

チャレンジするのは、Device Tree Overlayという方法です。
Device Tree Overlayは、Device Treeファイルを利用して動的にハードウェアを変更する方式となります。
FPGAもソフトから見ればハードウェア資源です。
この方式を利用してルートファイルシステムからFPGAを更新することが可能となっています。

Device Tree Overlayを利用するために、前回まで作成してきたDevice Treeファイルの更新と、新たにハードウェア更新用のDevice Treeファイルを作成する必要があります。

※DeviceTreeファイルの更新方法は、第3回のコラムに書きましたので、DeviceTreeファイル内の更新部のみ記載します。
また、ハードウェア更新用のDevice Treeファイルは、以下に手順を記載します。

準備として、下記を実行してください。

# cd~
# source .quartus18.0.0.std.de10-nano
# cd $QUARTUS_VERSION_DIR/embedded
# ./embedded_command_shell.sh

(1)socfpga.dtbの更新
ホストPCにて、socfpga.dtsファイル以下を追記/変更してdtbファイルを作成した後、SDカードを更新します。
※太字の部分が更新部分です。

~~
~~
fpga_region0: base_fpga_region {
compatible = “fpga-region”;
fpga-mgr = <&fpgamgr0>;
fpga-bridges = <&fpga_bridge0>, <&fpga_bridge1>,
<&fpga_bridge2>;
ranges = <0 0xff200000 0x100000>;
#address-cells = <0x1>;
#size-cells = <0x1>;
};

fpgamgr0: fpgamgr@0xff706000 {
compatible = “altr,socfpga-fpga-mgr”;
//transport = “mmio”;
reg = <0xff706000 0x1000 0xffb90000 0x1000>;
interrupts = <0x0 0xaf 0x4>;
//reg-names = “axi_slave0”, “axi_slave1”;
//clocks = <0x3>;
};
~~
~~

~~
~~
fpga_bridge0: fpgabridge@0 {
compatible = “altr,socfpga-hps2fpga-bridge”;
label = “hps2fpga”;
clocks = <0x3>;
reset-names = “hps2fpga”;
resets = <&rst_mgr 96>;
bridge-enable=<1>;
};

fpga_bridge1: fpgabridge@1 {
compatible = “altr,socfpga-lwhps2fpga-bridge”;
label = “lwhps2fpga”;
clocks = <0x3>;
reset-names = “lwhps2fpga”;
resets = <&rst_mgr 97>;
bridge-enable=<1>;
};

fpga_bridge2: fpgabridge@2 {
compatible = “altr,socfpga-fpga2hps-bridge”;
label = “fpga2hps”;
clocks = <0x3>;
reset-names = “fpga2hps”;
resets = <&rst_mgr 98>;
bridge-enable=<1>;
};
~~
~~

(2)ハードウェア更新用のDevice Treeファイルの作成
ホストPCにて、load_rbf.dtsというファイル名で下記の内容で作成してください。

/dts-v1/ /plugin/;
/ {
fragment@0 {
target-path = “/soc/base_fpga_region”;
#address-cells = <1>;
#size-cells = <1>;
__overlay__ {
firmware-name = “boardtest.rbf”;
#address-cells = <1>;
#size-cells = <1>;
};
};
};

(3)ハードウェア更新用のDevice Treeファイルload_rbf.dtsからload_rbf.dtboの作成
ハードウェア更新用のDevice Treeファイルは今までと異なる方法で作成します。
下記の方法で作成してください。

dtboファイルを生成します。

# dtc -O dtb -o load_rbf.dtbo -b 0 -@ load_rbf.dts

(4)rbfファイルとload_rbf.dtboの更新
SDカードをホストPCでマウント後、/lib/firmwareフォルダを作成した後、rbfファイルとload_rbf.dtboを書き込みます。

# cd <SDCard Mount Position(Linux partition)>/
# sudo mkdir -p /lib/firmware
# sudo cp <home_folder>/intelFPGA_std/18.0/hld/board/terasic/de10_nano/exsamples/boardtest/top.rbf <SDCard Mount Position(Linux partition)>/lib/firmware/boardtest.rbf
# sudo cp load_rbf.dtbo <SDCard Mount Position(Linux partition)>/lib/firmware/

(5)FPGAのコンフィグ
ターゲットを起動(方法は第3回のコラムに掲載しています。)して、ログインします。
ログイン後、下記コマンドによりFPGAをコンフィグします。

# mkdir /sys/kernel/config/device-tree/overlays/boardtest
# cat /sys/kernel/config/device-tree/overlays/boardtest/status
unapplied
# echo load_rbf.dtbo > /sys/kernel/config/device-tree/overlays/boardtest/path

実行後、下記ログがターミナルに出力されていれば成功です。

fpga_manager fpga0: writing boardtest.rbf to Altera SOCFPGA FPGA Manager

念のため状態の確認をします。
先ほどは、unappliedだったのがappliedに変化している事を確認します。

# cat /sys/kernel/config/device-tree/overlays/boardtest/status
applied

(6)init_opencl.shの更新
ターゲットのルートファイルシステムにinit_opencl.shがありますので、下記を最終行に追加して保存します。
Device Tree OverlayによりFPGAのコンフィグレーションを行っているので、OpenCLアプリケーション(今回はboardtest)を実行した際にFPGAのコンフィグレーションを行わないオプションとなります。

# vi init_opencl.sh
~~
~~
export CL_CONTEXT_COMPILER_MODE_INTELFPGA=3

(7)サンプルデザインの実行
ターゲットで、boardtestサンプルデザインを実行してみます。

root@socfpga:~# cd exsamples/boardtest
root@socfpga:~# ./boardtest_host

今回は無事実行できていると思います。

上記「(2)ハードウェア更新用のDevice Treeファイルの作成」手順で、下記のパラメータを変更すれば様々なファイル名に対応可能で、rbfファイルとdtboファイルをSDcardの/lib/firmwareへ対で格納する事で、OpenCLデザインの変更が可能となります。

firmware-name = “xxxxxx.rbf”;

サンプルデザインのビルド方法は、前回までのコラムに掲載しておりますので、色々と試してみてください!

インテル®FPGA SDK for OpenCLはAI推論処理のアクセラレーション処理でも利用されております。
エッジAI向けのAI推論処理実装は日進月歩で進んでおりまして、3ケ月、半年後には新しい手法で実装が必要になるケースも見受けられます。rtlではなく、まずは迅速にFPGAでアクセラレーションを実装する手法としてOpenCLを利用する事は有用と考えます。
FPGAで様々なOpenCLデザインを作成してチャレンジしてみてください!

※参考サイト:インテル® FPGAのサイト
https://www.altera.co.jp/products/design-software/embedded-software-developers/opencl/overview.html
※各ツールのライセンスや購入に関しては、代理店・メーカにお問い合わせください。
※本コラムは、弊社が実際に開発をした中での経験より構成しております。本内容に準じて実施した結果に生じるいかなる影響、損害に関して、責任の無いものといたします。本コラムで紹介しておりますツールについては、合法性、正確性、道徳性、最新性、適切性、著作権の許諾や有無など、その内容については、何らの責任を負うものではありません。また、当社は通知することなく当サイトに掲載した情報の訂正、修正、追加、中断、削除等をいつでも行うことができるものとします。コンテンツのご利用により、万一、ご利用者様に何らかの不都合や損害が発生したとしても、当社は何らの責任を負うものではありません。

個別相談も承っております。下記よりお申し込みください。

個別相談会申し込み

シリーズ記事

関連記事

OTHER COLUMN

MORE  

まこちゃんブログ

NEWS

MORE  

PARTNER

  • Intel
  • Xilinx

お探しの組み込み製品はキーワードで検索!