実践的！FPGA開発 / FPGA_seminar_12_fixstars_corporation_20220727

Copyright© Fixstars Group
実践的！FPGA開発セミナー
vol.12
2022/07/27 18:00～

View Slide

Ubuntu on Zynq UltraScale+
MPSoC で組込みシステム開発
応用編

View Slide

Who I am
写真
Masayoshi
MATSUMURA
松村将嘉
ソリューション第一事業部
シニアエンジニア

View Slide

Zynq UltraScale+ MPSoC 評価ボード用公式Ubuntuイメージ
● イメージ配布/ドキュメント URL
○ https://ubuntu.com/download/xilinx
○ https://xilinx-
wiki.atlassian.net/wiki/spaces/A/pages/1413611532/Canonic
al+Ubuntu
● Canonical と Xilinx の提携によるリリース
● 下記の評価ボード向けに提供
○ZCU102, ZCU104, ZCU106
○Kria KV260
● PL Bitstream はボード毎にサンプルデザインが組み込まれている
○ 例) ZCU102の場合: Vitis-AI
○ 後述の “xlnx-config” ツールで自作のものに変更可
● FPGA開発向けサポート
○ドライバ組み込み済み (XRT/zocl 2020.2)
○カスタムプラットフォームの
デプロイ補助ツール (xlnx-config)
● 使い方
○1. イメージをダウンロード
○2. ddコマンド等でSDカードに書き込み
○3. SDカードを評価ボードにセットして電源ON
⇒ これだけでUbuntuが起動します!
4

View Slide

Ubuntuを利用するメリット
● リッチなパッケージ群
○ もちろん apt や snap が利用可能
○ SW開発/デバッグ用ツール : gcc/g++, make, cmake, gdb, valgrind …etc
○ 様々なライブラリ
■ 自身でビルドが必要なSWの場合も、aptで入手できるツール/ライブラリを使ってビルドできるケースが多い
○ emacsも使える
■ ただしc-mode/c++-modeはかなり重い.. font-lock-modeを切ればなんとか使える
● デスクトップ環境
○ デフォルトでは GNOME3
■ その他はaptで導入可能
○ USBキーボード/マウス + ディスプレイ出力(ZCU102の場合:DisplayPort) or VNC経由での操作
● 長期的なサポート
○ 本イメージは 20.04 LTS なので 2030年まで
○ セキュリティが重要な本番運用にも適用可能
⇒ より柔軟で効率的なHW/SW協調の組み込みシステム開発が可能
5

View Slide

xlnx-config ツールについて
● 自作のプラットフォームを簡単にデプロイするための補助ツール
● 下記ファイルを所定のディレクトリにまとめて配置おくと、
自動的にBoot用ファイル (Boot.bin) を生成してくれる
○ ARM Trusted Firmware
○ First Stage BootLoader
○ Platform Management Unit Firmware
○ PL Bitstream ⇒ 自身で作成したFPGAデザイン(Vitisアプリケーションを含む)も組み込み可能
○ Device Tree ⇒ Linux Kernelに伝えるデバイス情報を記述したファイル (今日は少し触ります)
● 本ツールについては下記参照
○ Xilinx-Wiki : https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/2057043969/Snaps+-+xlnx-
config+Snap+for+Certified+Ubuntu+on+Xilinx+Devices
○ セミナー Vol.9 資料 : https://fixstars.connpass.com/presentation/ で公開予定
詳しくはセミナー Vol.9 で紹介しました
変更する必要はあまり無い
(予め用意されているものをそのままコピーしておけば良い)
6

View Slide

Zynq Ultrascale+ MPSoC のシステム構成
※ 本図は “EG” シリーズの構成図
(https://japan.xilinx.com/content/dam/xilinx/imgs/products/zynq/zynq-eg-
block.PNG)
FPGA (PL) ⇒
APU : 多機能処理向けCPU
- ARM Cortex-A53 x4Cores
- Linux など
RPU : リアルタイム処理向けCPU
- ARM Cortex-R5 x2Cores
- LockStep での使用も可
(2Core協調による冗長化)
- FreeRTOS など
7
協調動作させるには？

View Slide

OpenAMP
8
● 異種のCPU/OS間での協調機能を提供
● Linux側をMaster, リアルタイム処理側(FreeRTOS/Baremetal)をRemoteとして扱う
● OpenAMPの主要コンポーネント
○ remoteproc : Master による Remote のLifecycle管理 (LCM)
■ Remote のファームウェアをロード
■ Remote CPUの起動/停止
■ RPMsg用チャネルの確立
■ virtio device の生成
○ RPMsg : 共有メモリを介したプロセッサ間通信 (IPC)
■ 通知用にプロセッサ間割り込み(IPI)を用いる
※ AMP: Asymmetric Multi Processing
(https://xilinx-
wiki.atlassian.net/wiki/spaces/A/pages/18841718/O
penAMP)
(A53) (R5)

View Slide

OpenAMP
9
(https://docs.xilinx.com/v/u/ja-JP/ug1186-zynq-openamp-
gsg)
OpenAMP は下位層として
libmetal 用いている

View Slide

OpenAMP
10
● Zynq Ultrascale+ MPSoC 向けのサポート情報
○ User guide (UG1186) や Xilinx-Wiki に導入方法がまとめられている
■ https://docs.xilinx.com/v/u/ja-JP/ug1186-zynq-openamp-gsg
■ https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841718/OpenAMP
○ その他、解説サイトも多数あり
○ しかし、Linux はあくまでも Petalinux の前提...
⇒ Ubuntuでも動かしてみたい、というのが今回の話題

View Slide

想定環境
● 評価ボード: ZCU102
● 開発環境
● 以降のページに記載するコマンド例は, 特記の無い限り ZCU102上で動作するUbuntu
で実行するものとします
FPGA Device Zynq Ultrascale+ MPSoC XCZU9EG-2FFVB1156
PL Resource LUT:600K, RAM:32.1Mbit, DSP:2520, IO:328
PS CPU/GPU ARM Cortex-A53 x 4Core / ARM Cortex-R5 x 2Core / Mali-400 MP2
PS DRAM DDR4 4GB
CPU Core i7 6800K
OS Ubuntu 20.04
FPGA開発ツール Vitis 2020.2
11

View Slide

手順
12
● Ubuntu 側(A53)の設定
○ 1. デバイスツリーの修正
○ 2. ブートファイル(Boot.bin)の作成
● RPU(R5)用ファームウェアの作成
○ 今回は FreeRTOS / OpenAMP echo test を使用 (Vitis IDEにデフォルトで用意されている)
● テストプログラムの実行
○ Ubuntu からR5にファームウェアを転送して起動
○ Ubuntu で echo test プログラムを実行

View Slide

Ubuntu側の設定 - 1.デバイスツリーの修正
13
● 今回は、Ubuntuイメージでデフォルトで用いられているものをベースに修正
○ 記述内容は UG1186 2020.2 の P.34~ のものを参考とした
● 1. Device Tree Compiler (dtc) のインストール
※ 参考: デバイスツリーはバイナリ形式とテキスト形式があり、本コンパイラはその相互変換を行うもの。
- バイナリ形式(dtb) : 実際のブート時に用いる。
- テキスト形式(dts) : 開発者が編集する際に用いる。ブート時に使うことはできない (dtbに変換が必要)。
● 2. デフォルトのデバイスツリーをテキスト形式に変換
(次ページへ続く)
$ sudo apt install device-tree-compiler
$ dtc -I dtb -O dts -o ~/zcu102_system.dts /usr/share/xlnx-firmware/zcu102/zcu102_system.dtb

View Slide

14
● 3. デバイスツリーの編集
○ 手順2で生成した ~/zcu102_system.dts を編集する
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
rpu0vdev0vring0:
[email protected] {
no-map;
reg = <0x0
0x3ed40000 0x0 0x4000>;
};
rpu0vdev0vring1:
[email protected] {
no-map;
reg = <0x0
0x3ed44000 0x0 0x4000>;
};
rpu0vdev0buffer:
[email protected] {
no-map;
reg = <0x0
0x3ed48000 0x0 0x100000>;
};
rproc_0_reserved: [email protected] {
no-map;
reg = <0x0
0x3ed00000 0x0 0x40000>;
};
};
zynqmp-rpu {
compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
#size-cells = <2>;
ranges;
core_conf = "split";
reg = <0x0 0xFF9A0000 0x0 0x10000>;
r5_0: [email protected] {
#size-cells = <2>;
ranges;
memory-region =
<&rproc_0_reserved>,
<&rpu0vdev0buffer>,
<&rpu0vdev0vring0>,
<&rpu0vdev0vring1>;
pnode-id = <0x7>;
mboxes = <&ipi_mailbox_rpu0 0>,
<&ipi_mailbox_rpu0 1>;
mbox-names = "tx", "rx";
tcm_0_a: [email protected] {
reg =
<0x0 0xFFE00000 0x0 0x10000>;
pnode-id
= <0xf>;
};
tcm_0_b: [email protected] {
reg =
<0x0 0xFFE20000 0x0 0x10000>;
pnode-id
= <0x10>;
};
};
zynqmp_ipi1 {
compatible = "xlnx,zynqmp-ipi-mailbox";
//interrupt-parent = <&gic>;
interrupt-parent = <0x4>;
interrupts = <0 29 4>;
xlnx,ipi-id = <7>;
#size-cells = <1>;
ranges;
/* APU<->RPU0 IPI mailbox controller */
ipi_mailbox_rpu0: [email protected] {
reg = <0xff990600
0x20>,
<0xff990620
0x20>,
<0xff9900c0
0x20>,
<0xff9900e0
0x20>;
reg-names =
"local_request_region",
"local_response_region",
"remote_request_region",
"remote_response_region";
#mbox-cells = <1>;
xlnx,ipi-id = <1>;
};
};
(1) 共有メモリ領域, remoteproc, IPI の設定 : ファイル末尾の “}:” の前に下記を追記

View Slide

15
● 3. デバイスツリーの編集 (続き)
(2) UART1 の無効化
- UART1をR5の入出力として使用できるようにするために、Linux側は無効化する
- “[email protected]” セクションの “status” を “disabled” に変更
[email protected] {
u-boot,dm-pre-reloc;
compatible = "cdns,uart-r1p12¥0xlnx,xuartps";
status = "disabled";
interrupts = <0x00 0x16 0x04>;
[email protected] {
u-boot,dm-pre-reloc;
compatible = "cdns,uart-r1p12¥0xlnx,xuartps";
status = "okay";
interrupts = <0x00 0x16 0x04>;
変更前変更後

View Slide

16
● 4. 編集済みのデバイスツリーをバイナリ形式に変換
$ dtc -I dts -O dtb -o ~/zcu102_system.dtb ~/zcu102_system.dts

View Slide

Ubuntu側の設定 - 2. ブートファイル(Boot.bin)の作成
17
● xlnx-config を用いて、編集済みのデバイスツリーを含むBoot.binを作成
● 1. xlnx-configのインストール
● 2. Platform Asset Container(PAC) 格納用ディレクトリの作成
● 3. PAC Config の作成
$ sudo snap install xlnx-config --classic --channel=1.x
$ sudo mkdir -p /usr/local/share/xlnx-config/pac/hwconfig/
$ sudo mkdir -p /usr/local/share/xlnx-config/pac/hwconfig/openamp_try/zcu102

View Slide

18
● 4. 必要なファイルの格納
○ 今回はPL側のデザインは不問なので、PL Bitstreamはデフォルトのもの(Vitis-AI)を用いる
○ デバイスツリー(dtb)のみ、先の手順で作成したものを用いる
○ 下記の内容の2つのファイルを新規作成
$ cd /usr/local/share/xlnx-config/pac/hwconfig/openamp_try/zcu102/
$ sudo cp /usr/share/xlnx-firmware/zcu102/zcu102_zynqmp_fsbl.elf ./fsbl.elf
$ sudo cp /usr/share/xlnx-firmware/zcu102/zcu102_pmufw.elf ./pmufw.elf
$ sudo cp /usr/share/xlnx-firmware/zcu102/zcu102_system.bit ./system.bit
$ sudo cp /usr/share/xlnx-firmware/zcu102/bl31.elf ./bl31.elf
$ sudo cp ~/zcu102_system.dtb ./system.dtb
the_ROM_image:
{
[bootloader, destination_cpu=a53-0] fsbl.elf
[pmufw_image] pmufw.elf
[destination_device=pl] system.bit
[destination_cpu=a53-0, exception_level=el-3, trustzone] bl31.elf
[destination_cpu=a53-0, load=0x00100000] system.dtb
[destination_cpu=a53-0, exception_level=el-2] /usr/lib/u-boot/xilinx_zynqmp_virt/u-boot.elf
}
■ /usr/local/share/xlnx-config/pac/hwconfig/openamp_try/zcu102/bootgen.bif
name: openamp_try
desscription: An example design for trying OpenAMP
revision: 1
assets:
zcu102: zcu102
■ /usr/local/share/xlnx-config/pac/hwconfig/openamp_try/manifest.yaml

View Slide

19
● 5. PAC Config の有効化 (= Boot.binの作成と配置)
● 6. Reboot
● 7. Reboot後、dmesgで以下のようなログがあればOK
$ sudo xlnx-config -a openamp_try
$ sudo reboot
[ 14.770841] zynqmp_r5_remoteproc ff9a0000.zynqmp-rpu: RPU core_conf: split
[ 14.771264] remoteproc remoteproc0: [email protected] is available

View Slide

RPU(R5)用ファームウェアの作成
20
● Vitis IDE を用いてR5で動作するファームウェアを作成する
○ 本手順は開発環境(x86マシン)で実施
○ 今回は FreeRTOS / OpenAMP echo test をビルドする
● 1. Platform Projectの作成
○ File -> New -> Platform Project
○ Project名は任意に設定
○ Operationg system / Processor は右図のように設定
■ XSAファイルが無い場合, 右側の▼ボタンで zcu102 を
選択してPre-builtの定義を用いることができます
○ 設定が完了したら Finish ボタンをクリック

View Slide

21
● 2. Platform Projectの設定とビルド
○ platform.spr > freertos10_xilinx on psu_cortesr5_0 > Board Support Package > Modify BSP
Settings をクリック
○ Overview ページで “libmetal” と
“openamp” をチェック
○ freertos10_xilinx ページで
“stdin” と “stdout” をともに
“psu_uart_1” に変更
○ OKをクリック
○ 本Platform Projectをビルド

View Slide

22
● 3. Application Projectの作成
○ File -> New -> Application Project
○ Platformは、手順1で作成したものを選択
○ Project名は任意に設定
○ Templates で “OpenAMP echo-test” を選択
■ 注: 選択時にエラーが表示される場合は、
前ページのPlatformの設定とビルドが
正しく完了していることを確認
○ Finishをクリック

View Slide

23
● 4. Application プログラムの修正
○ Masterからメッセージを受信したことがわかるよう、受信時にログを出力するように修正
○ 修正後、Application Projectをビルドする
● 5. elfファイルの転送
○ elfファイルは通常 “//{Debug | Realease}/.elf” に生成
○ 生成されたelfファイルをZCU102のUbuntu環境に転送する
/*-----------------------------------------------------------------------------*
* RPMSG endpoint callbacks
*-----------------------------------------------------------------------------*/
static int rpmsg_endpoint_cb(struct rpmsg_endpoint *ept, void *data, size_t len,
uint32_t src, void
*priv)
{
(void)priv;
(void)src;
LPRINTF("Receive a message, len=%d¥n", len); // ←追加
...

View Slide

テストプログラムの実行
24
● ZCU102上のUbuntuからR5へファームウェアを転送し起動する
● ZCU102上のUbuntuでテストプログラムを実行し、R5で動作するファームウェアと
通信を行う
● 1. R5へのファームウェア(elfファイル)の転送と起動
○ elfファイルは必ず “/lib/firmware/” に格納する必要があります
○ ここでは、elfファイル名は “r5_freertos_echo_test.elf” とします
# elfファイルを /lib/firmwareに格納
$ sudo cp r5_freertos_echo_test.elf /lib/firmware/
# elfファイル名の設定 ※ファイル名部分のみ指定 (“/lib/firmware”は不要)
$ sudo sh -c "echo r5_freertos_echo_test.elf > /sys/class/remoteproc/remoteproc0/firmware"
# R5のファームウェアを起動
$ sudo sh -c "echo start > /sys/class/remoteproc/remoteproc0/state"
# (参考) R5のファームウェアを停止
$ sudo sh -c "echo stop > /sys/class/remoteproc/remoteproc0/state"

View Slide

R5
Firmware
25
● 2. テストプログラムのビルドと実行
○ 今回使用するファームに対応するLinux側のテストプログラムは下記にあります
■ https://github.com/Xilinx/meta-openamp/tree/master/recipes-openamp/rpmsg-examples/rpmsg-echo-test
○ これをビルドして実行します
# ビルド
$ make
# 実行
$ sudo ./echo_test
A53 (Ubuntu)
echo_test
Rpmsg send
Rpmsg recv &
verify
Rpmsg recv
Rpmsg send
loop
back
RPMsg

View Slide

26
● 結果 (開発PCにZCU102のUART(USB)を接続して動作確認)
UART0 (/dev/ttyUSB0)
A53 (Ubuntu)
Error count = 0 ⇒ Verify OK!

View Slide

27
● 結果 (開発PCにZCU102のUART(USB)を接続して動作確認)
UART1 (/dev/ttyUSB1)
R5
メッセージを受信したことが表示されている
(改行がおかしいのは改行コードの不一致..?)

View Slide

まとめ
28
● Ubuntu でも、OpenAMPを用いた A53 - R5 間の通信ができることが確認できた
● Petalinux向けのようなドキュメントやお膳立てがないため、自力で設定が必要
○ デバイスツリーとか. だいたいはPetalinux向けの情報が参考になったが、微妙に異なる箇所はある.
● 一方、ドライバは既に組み込まれており、追加でのインストールは不要だった
○ これが Xilinx公式のUbuntu のメリットと言える

View Slide

おまけ
29
2022 Q3 (7~9月?) に、Ubuntu 22.04 のイメージがリリースされるようです
(https://ubuntu.com/download/amd-xilinx)
ZCU111が対象に
追加されている

View Slide

クラウドサービスを利用した
FPGA 開発の高速化
- 合成時間短縮とコストのバランスを
考察する -

View Slide

Who I am
Eisuke
MOCHIZUKI
望月英輔
ソリューション第四事業部
シニアエンジニア

View Slide

クラウドサービスを開発に利用するモチベーション
● 複数の合成を並行して実行することで、開発の高速化が期待できる
○ IP のパラメータを変更したデザインを複数作成する
○ Timing Violation 解消のために複数のストラテジを試す
● 強力なスペックのマシンを必要に応じて利用可能
○ 大きなサイズのFPGA になると要求スペックも大きくなりがち
32
出典: Vivado ML スタンダード - メモリ要件

View Slide

FPGA 開発に利用可能なクラウドサービス
● 様々なクラウドベンダやサービスが存在
○ Amazon AWS, Microsoft Azure, Google Cloud, Alibaba Cloud, etc ...
○ 各クラウドベンダ内にも様々サービスが存在
■ AWS EC2, S3, Lambda, etc …
● FPGA 開発に利用可能なのはヴァーチャルマシンを提供するサービス
○ HW とOS が用意され、ユーザーがOS 上で作業できる仮想環境のこと
■ OS 上にFPGA 開発環境をインストールして開発を行う
○ AWS EC2, Azure Virtual Machines, Google Compute Engine, Alibaba Cloud ECS, etc …
● 今回のセミナーではAWS EC2 を利用
○ クラウドサービスの最大手で情報が豊富
○ AMD Xilinx Vivado がプリインストールされた環境を利用できる
■ $0.552/hr でフルライセンスが利用可能
● https://aws.amazon.com/marketplace/search?searchTerms=Vivado
■ ただし、いろいろクセがあるので注意 (後述)
33

View Slide

今回のセミナーでの検証内容
● AWS EC2 のインスタンスタイプを変更しながらVivado で合成を行い、
合成時間の変化を検証する
○ インスタンスタイプはPC で言うところのマシンスペックのようなもの
○ インスタンスタイプ毎にvCPU の種類や数、メモリサイズが異なる
○ 合成対象のデザインや条件については次ページに記載
● インスタンスタイプと合成時間から、合成時間に影響する要素を検証する
● 合成時間からトータルコストを算出し、コストパフォーマンスを検証する
34

View Slide

Vivado 合成対象デザイン, 条件
● Alveo U250 をターゲットに下記デザインを合成
○ PCIe x16 からDMA 経由でAlveo U250 上のDDR4 メモリにアクセスするデザイン
● Number of jobs は物理コア数(= vCPU 数の半分)に設定
○ Number of jobs: Vivado 合成時に投入する最大ジョブ数
○ 物理コア数と同じにしておくと速い印象がある
35

View Slide

Vivado 合成ステップ
● 大きく分けて下記3ステップで合成が進む
● 1. Submodule Synthesis
○ デザイン内の各モジュールの論理合成
○ モジュール毎に独立しているため並行して論理合成が可能
● 2. Synthesis
○ デザイン全体の論理合成
○ 数分で完了することが多い
● 3. Implementaion
○ デザイン全体の配置配線
○ 最も時間がかかる
● 各ステップそれぞれの時間を測定し評価対象とした
36

View Slide

vCPU, メモリを変化させて比較
37
● vCPU, メモリの差が合成時間やコストにどのような影響を与えるかを調査
● インスタンスタイプを固定し、サイズを変更する
Instance Type Cost/hr Clock [GHz] Boost [GHz] Cores Threads (vCPU) MEM [GB] CPU INFO
m5n.2xlarge $0.476 2.50 3.50 4 8 32 Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
↑ m5n. は固定し、サイズを変更 ↑ コア数, スレッド数, メモリサイズが変化する

View Slide

vCPU, メモリを変化させたときの合成時間
38
● Sub Synth の時間はvCPU やメモリサイズが増えるほど短くなる傾向にある
○ 並列処理が可能な処理のためvCPU の数が影響しやすいと考えられる
● Implementation の時間はメモリ64GB と128GB で大きな変化なし
○ 合成に必要なメモリを用意しておけばそれ以上は合成時間に影響なし？
■ 今回のAlveo U250 はピークで47GB との記載あり

View Slide

vCPU, メモリを変化させたときのコスト
39
● Total Cost は性能が向上するほどに増えていく
○ Cost/hr の上昇率よりも合成時間の削減率が低いため
● Cost/hr の低いインスタンスタイプがコストパフォーマンスに優れる

View Slide

インスタンスタイプを変化させて比較
40
● インスタンスタイプの差がどのような影響を与えるかを調査
● vCPU, メモリは極力固定し、インスタンスタイプを変更する
Instance Type Cost/hr Clock [GHz] Boost [GHz] Cores Threads (vCPU) MEM [GB] CPU INFO
m5ad.4xlarge $0.824 2.10 2.90 8 16 64 AMD EPYC 7571
m5zn.3xlarge $0.991 3.80 4.50 6 12 48 Intel(R) Xeon(R) Platinum 8252C CPU @ 3.80GHz
↑ インスタンスタイプを変更すると、
ベース/ブーストクロックが変化する
↑ コア数, スレッド数, メモリサイズは極力そろえる

View Slide

インスタンスタイプを変化させたときの合成時間
41
● Boost Clock が高くなるほど合成時間が減少する傾向にある
○ m5zn についてはvCPU の数が他よりも少ないにも関わらず、全体で合成時間が減少
● 合成時間の削減にはBoost Clock が大きく影響する

View Slide

インスタンスタイプを変化させたときのコスト
42
● 合成時間が短いほどTotal Cost が減少
○ Cost/hr が概ね同じなため、合成時間の差がTotal Cost に影響した
● Cost/hr が同じであれば、Boost Clock の大きいインスタンスタイプが
コストパフォーマンス、合成時間共に優れる

View Slide

AWS EC2 での調査結果まとめ
● 合成時間に影響を与える要素
○ CPU クロック: 合成全体に影響を与え、Boost Clock が高い程時間は短くなる
○ CPU コア数: Sub Synth に影響を与え、vCPU が多いほど時間は短くなる
○ メモリサイズ: 合成全体に影響を与えるが、ピーク値以上の場合の影響は軽微
● コストパフォーマンス
○ Cost/hr の低いインスタンスタイプの方がコストパフォーマンスが高い
○ Cost/hr が同等であれば、Boost Clock が高いほどコストパフォーマンスが高い
● クラウドサービスを利用してFPGA 開発を行う際のおすすめフロー
○ 1. 対象デバイスを確認し、合成に必要なメモリサイズを確認する
■ Vivado ML スタンダード - メモリ要件
○ 2. メモリ要件を満たすインスタンスタイプを調査し、Cost/hr の低いものをリストアップ
○ 3. リストアップしたものから最もBoost Clock の高いインスタンスタイプを選択
○ 4. インスタンスを起動し合成スタート
43

View Slide

AWS EC2 利用時の注意点
● Vivado がプリインストールされた環境はUS リージョンでのみ(*)利用可能
○ 物理的に遠いためネットワークレイテンシが大きく、GUI の操作に若干難あり
○ デザインの作成は手元のマシンで行い、合成はクラウドで行うという運用を推奨
● Vivado の新ver. がリリースされると旧ver. は削除される傾向にある
○ 以前は2019.1 が存在したことを確認できているが、今は2021.2, 2022.2 のみ
■ https://aws.amazon.com/marketplace/search?searchTerms=Vivado
● vCPU limit の存在に注意
○ 同時に実行できるインスタンスの数がvCPU の数で制限されている
○ 制限解除にはAWS とのやりとりが必要とのこと
44
* 2022/07/27 現在

View Slide

ここまでクラウドの話をしてきましたが・・・
● FPGA 開発者がわざわざクラウドで合成することは少ないのではないか？
● 強力な合成用マシンを所持していたり、今後導入することを検討している？
○ もう少しだけディープな話をしたいと思います。
● Fixstars で使用している合成マシンの紹介
○ それらのマシンで先程のデザインを合成したらどうなるか？
● 合成時のCPU 温度変化
● 合成時のクロック周波数の変化
● 今後導入するならこんなマシン
45

View Slide

Fixstars で使用している合成マシンの紹介
● Fixstars では下記マシンが主に合成に使用されている
○ No. は高価そうな順に付与した
● それぞれのマシンで合成を行い、合成時間を確認
○ No. 3 は忙しそうだったので競争除外
46
No. Clock [GHz] Boost [GHz] Cores Threads L3 Cache [MB] MEM [GB] MEM Type CPU INFO
1 3.80 4.50 24 48 128 256 DDR4-2666 AMD Ryzen Threadripper 3960X 24-Core Processor
2 3.00 4.80 18 36 24.75 128 DDR4-3200 Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz
3 3.70 4.70 10 20 19.25 128 DDR4-2133 Intel(R) Core(TM) i9-10900X CPU @ 3.70GHz
4 3.60 5.00 8 16 16 64 DDR4-2400 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
5 3.60 4.20 4 8 8 64 DDR4-2400 Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz

View Slide

Fixstars 合成マシンでの合成時間
47
● 比較的安価なNo.4 が最も合成時間が短い
○ Boost Clock が5.0GHz と高いことが影響？
● 比較的高価なNo.2 が最も合成時間が長い
○ Boost Clock も4.8GHz と決して低くないにも関わらず、なぜだろうか？

View Slide

合成時のCPU 温度変化
● 先程のNo.2 でサーマルスロットリングが発生しているのでは？と考え、
合成中のCPU 温度を取得
● ピークが70℃以下で特に問題なさそうだったが、下記知見を得た
○ CPU 温度はSub Synth 中に最も高くなる
○ 水冷ではなく空冷でも十分冷える
48
Implementation
Sub
Synth

View Slide

合成時のクロック周波数の変化
● 先程のNo.2 の合成中のクロック周波数を取得
● ピークのクロックが4.6GHz 程度であることを確認し、下記知見を得た
○ 各コアのクロックは上がったり下がったりを繰り返している
○ Sub Synth 中はクロックが一段下がる
49
Implementation
Sub
Synth

View Slide

● 最も合成時間の短かったNo.4 についてもクロック周波数を取得
● ピークのクロックが5.0GHz に達することを確認し、下記知見を得た
○ 各コアのクロックは一貫して高いクロックを保っている
○ やはりSub Synth 中はクロックが一段下がる
Sub
Synth
50
Implementation

View Slide

● No.4 の合成時間が比較的長い理由は、クロック周波数の頻繁な変化に原因
があるのかもしれない
● BIOS の設定等で改善する可能性があるので、継続調査する
○ クロック周波数がベースクロックの3.0GHz を遥かに下回る1.2GHz 程度まで落ち込んでいる
ので、おそらく省電力系の設定が影響していると考えられる
51

View Slide

今後導入するならこんなマシン
● ここまでの調査結果を踏まえ、FPGA 合成マシンとして導入するなら・・・
● CPU: Boost Clock が大きいもの
○ 5.5 GHz: Intel Core i9-12900KS
○ 5.3 GHz: Intel Core i9-11900KF
○ 5.2 GHz: Intel Core i9-12900KF
○ 5.0 GHz: Intel Core i9-9900K <- Fixstars での合成最速マシン
○ 4.9 GHz: AMD Ryzen 9 5950X
● メモリ: 合成対象のチップのピーク値 x 同時に合成を走らせるデザイン数
○ Alveo U250 x 2デザイン -> 47 GB x 2 = 94 GB 以上
● その他: 予算に合わせて適切に
52

View Slide

Thank you!
お問い合わせ窓口 : [email protected]

View Slide

実践的！FPGA開発 / FPGA_seminar_12_fixstars_corporation_20220727

実践的！FPGA開発 / FPGA_seminar_12_fixstars_corporation_20220727

株式会社フィックスターズ

More Decks by 株式会社フィックスターズ

Other Decks in Technology

Featured

Transcript