実践的！FPGA開発セミナー vol.6

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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group ネットワークにおけるレイテンシの重要性 ● ネットワークのレスポンスはUXに直結する ○ http://abehiroshi.la.coocan.jp/ ● レスポンス改善には系全体の遅延(=レイテンシ)を低下させることが効果的 ● 5Gの普及も関係し、伝送/伝搬遅延は低下傾向 ● サーバー側が阻害要因とならないよう、処理遅延の低下が求められている ● 用途にもよるが、FPGA は低レイテンシを実現しやすいと言われている ○ なぜか？ 4 

Slide 5

Slide 5 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group • 一般的な NIC + CPU 構成の場合、下記のフローで処理が行われる • 処理前後でデータをメインメモリに転送するため、① -> ④の時間が伸びがち • CPU での処理にどれだけ待たされるかはその時次第で、処理時間にばらつきが発生 NIC + CPU 構成の場合の処理フロー 5  ① Network からのデータをNIC 経由でメインメモリに転送 ②,③ CPU が手があいていれば処理をしてくれる ④ 処理が完了したデータをメインメモリからNIC 経由で Network に転送

Slide 6

Slide 6 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group FPGA を使用した場合の処理フロー 6  • FPGA を使用した場合、以下のようなフローが実現可能 • (うまくつくれば)データをメモリに配置しない低遅延なデータフローが実現可能 • (うまくつくれば)処理時間を常に一定にすることが可能 ① Network からのデータを FPGA 内で直接処理する ② FPGA 内で処理したデータをNetwork に直接出力する

Slide 7

Slide 7 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group FPGA だけでNetwork 処理をする場合の問題点 7  • 前頁までを踏まえればFPGA は理想的なデバイスであり、もっといろいろな場所で使用されていてもおかしくは無いはず・・・ • だが、FPGA 内ですべてのNetwork 処理を完結させるのは結構面倒 • OS が担当していた部分をすべて実装する必要がある NIC + CPU FPGA ユーザーが設計 , 実装ユーザーが設計 , 実装 OS が担当 FPGA 上に設計, 実装 NIC が担当 FPGA が実装された基板を設計 , 実装出展：Wikipedia (https://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%85%A7%E3%83%A2%E3%83%87%E3%83%AB) (※CC BY-SA 3.0により許諾されています。https://creativecommons.org/licenses/by-sa/3.0/）

Slide 8

Slide 8 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group FPGA だけでNetwork 処理をする場合の問題点 - 解決策 8  • 面倒なネットワーク処理の実装を簡略化できる方法が存在 • 基板の設計, 実装 -> 各ベンダーが販売しているアクセラレータカードを利用 • OS が担当していた機能 -> TCP/IP オープンソース実装が存在 • Limago: an FPGA-based Open-source 100 GbE TCP/IP Stack NIC + CPU FPGA ユーザーが設計 , 実装ユーザーが設計 , 実装 OS が担当 FPGA 上に設計, 実装オープンソース実装を利用 NIC が担当 FPGA が実装された基板を設計 , 実装アクセラレータカードを利用出展：Wikipedia (https://ja.wikipedia.org/wiki/OSI%E5%8F%82%E7%85%A7%E3%83%A2%E3%83%87%E3%83%AB) (※CC BY-SA 3.0により許諾されています。https://creativecommons.org/licenses/by-sa/3.0/）

Slide 9

Slide 9 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group FPGA だけでNetwork 処理をする場合の問題点 - 解決策 - 2 • アクセラレータカード • Alveo U250 データセンターアクセラレータカード (Xilinx) • UltraScale+ 100G Ethernet Subsystem コアが利用可能 • QSFP x2 ポート搭載: 100GbE に接続可能 • この1枚で、100GbE に接続する環境を整えることができる • 100GbE: 理論値100Gbps の通信速度を持つネットワーク規格 • 家庭用に一般に普及しているのは1GbE • TCP/IP のオープンソース実装 • Limago: an FPGA-based Open-source 100 GbE TCP/IP Stack • 100GbE のTCP/IP をFPGA 上に実装 • 下記アクセラレータカードに対応 • VCU118, Alveo U200, Alveo U280 • 今回のセミナー向けにAlveo U250 に対応させた • 最大64 セッション同時接続に対応 • 上記を利用し、ネットワーク + FPGA で優位性が見られるかを検証 9  QSFP x2

Slide 10

Slide 10 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 検証環境 • NIC + CPU 構成 • Client: 100GbE NIC + CPU • Cable : 100GbE Optical Cable • Server: 100GbE NIC + CPU • FPGA 構成 • Client: 100GbE NIC + CPU • Cable : 100GbE Optical Cable • Server: Alveo U250 10 

Slide 11

Slide 11 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 検証結果: Ping 11  • Ping を100回実行しレイテンシを測定 NIC + CPU 構成 • avg : 0.109 ms • mdev: 0.018 ms FPGA 構成 • avg : 0.056 ms • mdev: 0.018 ms 平均値はFPGA が明らかに低く良好な結果ばらつきには大きな差はみられず

Slide 12

Slide 12 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 検証結果: Iperf • Iperf を並列数を変化させながら、各点10秒間実行してスループットを測定 • 並列数: 負荷をかけるClient 側で動作するスレッド数と同義 12  NIC + CPU 構成 • 90.3 Gbps @ P=8 FPGA 構成 • 92.8 Gbps @ P=64 両者ともに理論値100 Gbps に肉薄 FPGA でもNIC と同等のスループットが得られることが確認できた NIC + CPU 構成ではP=8 をピークに低下 12スレッドのCPU を使用しているため？

Slide 13

Slide 13 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group まとめ 13  • FPGA と100GbE の連携はアクセラレータカードとオープンソース実装を組み合わせることで実現可能 • レイテンシ面ではNIC + CPU に対して優位性があることを確認 • スループット面でもNIC + CPU と同等の性能を実現 • 電力は今回は測定できず(すみません) FPGA エンジニアとしてお伝えしたいこと • FPGA は汎用性ではCPU に劣り、単純な計算力ではGPU やDSP に分があります。 • ですが今回のようにネットワークと直結する等、低レイテンシが求められる分野では優位性があるということが伝わっていれば幸いです。 • Xilinx Versal ACAP のように、CPU もDSP もFPGA も全て搭載しているデバイスも登場してきているので、今後の展開に期待したいと思っています。

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group FPGA上でLinuxを動かす 16  • Linuxで動作する豊富なソフトウェア資産を使いたい • e.g. ドライバ、ネットワークスタック、ライブラリ • 現実的には、各FPGAベンダーのCPU内蔵FPGA製品を使う • Xilinx: Zynq等, Intel: Cyclone V SoC等 • CPU内蔵ではないFPGAの場合 • 各社が提供するソフトCPUコアを使う • Xilinx： Microblaze (MMU構成) • Intel: Nios II/f • ベンダが提供する方法に従えば、比較的簡単に動作する

Slide 17

Slide 17 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group ベンダ提供ツールが用意してくれるもの 17  • ベンダ提供のLinux環境構築ツールは様々なものを自動的に用意してくれる • ハードウェア構成を表すデバイスツリー • ファームウェアをロードして実行するブートローダー • デバイスツリーに基づいて基本的なハードウェアの初期化を行うファームウェアやセカンドブートローダー • 対象のハードウェア上で動作するように設定されたLinuxカーネルイメージ • システムの動作に必要なものが含まれているルートファイルシステムイメージ • 上記のものに含まれるプログラムをコンパイルするためのクロスコンパイル用ツールチェイン • ターゲット上のプログラムをデバッグするためのデバッガ • ベンダはYocto Projectや YoctoをカスタマイズしたものをLinux環境構築ツールとして提供 • Xilinx: PetaLinux

Slide 18

Slide 18 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group RISC-VのCPUコア 18  • RISC-V: オープンソースの命令セットアーキテクチャ(ISA) • 実装自体はオープン、クローズド、有償、無償、どちらもある • ISAがロイヤリティ・フリーのためコアのライセンス料が他のCPUより安いことが期待されることが多い • ISAを独自拡張して実験してもOKなので、 CPUアーキテクチャの研究にも良く用いられる (というかそれが目的で作られた) • 現在ではFPGAで動作するソフトCPUコアや、実際にSoC上に実装されたものどちらも容易に入手可能出典: https://www.sifive.com/boards/hifive-unmatched 実際にLinuxが動作するSoC SiFive Freedom U740搭載ボード (SiFive HiFive Unmatched) RISC-Vのページに記載されている SoCやCPUコア一覧出典: https://riscv.org/exchange/cores-socs/

Slide 19

Slide 19 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group Linuxの動作に必要な機能 19  • 最低限の命令セットサポート • RISC-V 32bitの基本命令 (I) • 乗算命令 (M) • アトミック命令 (A) • 圧縮命令 (C) は必須ではない (カーネルの設定で無効化可能) • MMUによる仮想メモリのサポート • 厳密にはMMU無しの構成も可能だが、実用性に欠く • タイマーによる時刻取得と指定時刻での割り込み • スケジューリングに必要

Slide 20

Slide 20 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group Linuxの動作に必須ではないがほしい機能 20  • コンソール入出力 • フレームバッファによるコンソール出力、キーボードによる入力 • シリアル(UART)通信による入出力 • デバッガ接続機能 • トラブルシューティングにデバッガが無いとかなりキビシイ • FPGAなので内部信号の観測ロジックなどを埋め込め無くはないが非効率的 • 比較的高速なOSイメージの転送手段 • ルートファイルシステムやカーネルのイメージを何度も更新するので

Slide 21

Slide 21 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group VexRiscv 21  • オープンソースのRISC-V実装 • SpinalHDLで記述されている • Chiselから派生したハードウェア記述言語 • Chisel同様ScalaのDSL • 文法はChiselとかなり異なる印象 • 基本機能のコアに対してプラグイン方式で機能拡張が行える • 基本機能：RV32IA (RISC-V 32bitの基本命令+アトミック命令) • MMUの有無、乗算器の構成、除算器の構成、圧縮命令のサポート、CSRのサポート • デバッガインターフェースもプラグインでサポート可能 • FPGA向けの実装として、FPGAでよく使われるバスIFをサポート • Wishboneだけでなく、AXI4やAvalonMMをサポートしている • Vivadoぽちぽちまんに優しい設計 • LiteXというFPGA向けシステム設計ツールのCPUコアとしてLinux動作実績あり https://github.com/SpinalHDL/VexRiscv

Slide 22

Slide 22 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 対象のボード 22  • Alveo U50… のつもりでしたが、間に合わなかったので手持ちの別のボードを使用 • LiteFury (https://github.com/RHSResearchLLC/NiteFury-and-LiteFury) • Artix-7 XC7A100T-L2FGG484EとDDR3 256[MiB]搭載したFPGAボード • M.2 2280 M key形状 • PCIe Gen2 x4接続可能 • 日本からも送料含めて1万円強くらいで買える • PCIe接続できるボードとしてはかなり安い出典: https://github.com/RHSResearchLLC/NiteFury-and-LiteFury

Slide 23

Slide 23 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group システム構成 23  • ターゲット • CPUコア：VexRiscv@125[MHz] MMUあり構成 • メモリ：DDR3 SDRAM (256[MiB]) • タイマー：ACLINTのうちタイマー機能を最低限実装 (IPIはなし) • UART： Xilinx AXI UART 16550 • デバッグ • JTAG信号生成：AXI GPIO (ホストCPU制御) • UART： Xilinx AXI UART 16550 • ホストインターフェース • PCIe DMAコア： Xilinx XDMA

Slide 24

Slide 24 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 課題 24  • Alveoは基本的にPCIeやGT以外の外部IOを持っていない • LiteFuryは一応引き出せるが基本的に出ていない • FPGA上のRISC-Vコアにデバッグ等のためにアクセスする手段が必要 • UARTによるコンソール入出力 • JTAGによるデバッガ接続 • Linuxカーネルやrootfsはどこに置くか • rootfsはどうやって作成するか

Slide 25

Slide 25 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group ターゲットとホストのUART通信 25  • ホストとの通信はPCIe経由 • FPGA側はPCIeのコアとしてXDMAを用いるのが最も容易 • XDMAの機能を使うためには、Xilinxのドライバが必要 • ホスト上でターミナルソフトを用いてターゲットにアクセスしたい 1. XDMAドライバを改造して UART通信デバイスとして扱えるようにする 2. ドライバを改造せずにユーザーモードだけで頑張る

Slide 26

Slide 26 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group ターゲットとホストのUART通信 26  • XDMAにはホストからのMMIOアクセスを FPGA側のAXI4 Liteのアクセスに変換する機能がある • /dev/xdma0_user をmmapして読み書きするだけ • ホストからFPGA上のIPのレジスタを操作可能 • ユーザーモードで動作する UART 16550用ドライバ (axiuartd) を作成 • socatでブリッジされた疑似端末(pts)のペアを作成する • axiuartdがFPGA上のUART16550を制御し、片方のptsにブリッジする • もう片方のptsをターミナルで開く

Slide 27

Slide 27 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group ターゲットへのデバッガ接続 27  • OpenOCDにはRaspberry PiなどのGPIOを操作してJTAGの通信を行う機能がある • Bitbang driver • 前述のとおり、PCIe経由でFPGA上のレジスタにアクセスできるので、 AXI GPIOを接続しておけば、OpenOCDでJTAG通信を行える • ちょっと無理やり感あるが…

Slide 28

Slide 28 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group OSイメージ類の置き場所 28  • LiteFuryやAlveo U50は大容量の不揮発性メモリインターフェースを持たない • コンフィグレーション用のQSPIフラッシュ程度 • DDR3 SDRAM 256[MiB] (LiteFury) や HBM2 8[GiB] (Alveo U50) があるのでこれらのRAM上にホストからイメージを転送しておく • イメージ転送後、CPUをリセットして実行を開始する

Slide 29

Slide 29 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group OSイメージ類の置き場所 29  • ルートファイルシステムはinitramfsにする • 本番のルートファイルシステムをマウントする前の準備をするためのメモリ上に展開されるルートファイルシステム • 通常はinitramfsでの処理完了後に不揮発性ストレージ上のルートファイルシステムをマウントして移動する • そのままinitramfsを使い続けることも可能なので、今回はinitramfsを使い続ける

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group 合成結果 31  • コアのサイズ LUT ：3000, Register 2500+, BRAM 5, DSP 4 • もっと大きいかと思っていたが意外と小さい • MicroBlazeのMMUアリ構成も大体同じようなサイズ • Artix7-100でもまだまだ載せられそう

Slide 32

Slide 32 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group デバイスツリーの準備 32  • デバイスツリー • 主に組込み向けのプラットフォームでハードウェアの構成を定義する構造 • cf. ACPI • 基本的にベンダーのSDKが生成してくれる • PetaLinuxの場合はハードウェア情報 (*.xsa) から生成 • 今回はベンダーのSDKはないので、手書きする • 書き方はざっくりは LinuxカーネルのDocumentationに載っている • Zynq用に PetaLinuxなどで生成したものを参考にするとよい

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group カーネルとrootfsイメージの準備 34  • いくつか方法があるが比較的シンプルなBuildrootを使ってイメージを作成する • Buildroot (https://buildroot.org/) • クロスコンパイル用のツールチェーン、カーネルイメージ、rootfsを構築するツール • Yoctoと並んでよく利用される • Yoctoよりシンプルでわかりやすい • 現時点の最新版 (2021.11) で、RISC-V向けのイメージ生成をサポート

Slide 35

Slide 35 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group Linux起動までの下準備を行うファームウェア 35  • RISC-VのCPUはM, (H), S, Uの動作モードをもっている • M: Machine Mode 一番権限が強いモード。リセット直後もMモード • S: Supervisor Mode OSが動作するモード • U: User Mode ユーザーアプリケーションが動作するモード • LinuxカーネルはSモードで動作するので、 MモードからSモードに移行する処理が必要 • また、Mモードでしかできない処理を肩代わりするプログラムも必要 • これらの処理をばらばらに作ると困るので、 OpenSBI(https://github.com/riscv-software-src/opensbi)が用意されている • OpenSBIが次のブートローダーもしくはLinuxカーネルを呼び出す • Linuxカーネルやrootfsがメモリ上に配置されていない場合は、U-Boot 等を呼び出してカーネルやrootfsをロードする必要がある • Zynqでも同様のながれになっているはず • 今回はホストが直接RAMにイメージを置くのでOpenSBIから直接カーネルを起動する

Slide 36

Slide 36 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group RAM上の配置 36  • 図の配置になるように、あらかじめホストからDRAM上にイメージを書き込んでおく • Zynq等でLinuxを動かす場合はそんなことはできないので、ブートローダーがSDカード等からイメージをメモリに読み出す • 注意点：デバイスツリーはLinux Kernelイメージより上位の領域に配置する必要がある

Slide 37

Slide 37 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group デバイスツリーの配置制約 37  • カーネルのバイナリは先頭アドレスが 0xC000_0000 としてビルドされる • ページテーブル初期化までのコードは、アライメントの制約を満たせば、他のアドレスにロードしても実行可能 • 今回は 0x8100_0000 にロードしている • ページテーブル初期化前はデバイスツリーにアクセスするために、暫定的な仮想アドレス (0x4000_0000) にマップしてアクセスする

Slide 38

Slide 38 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group デバイスツリーの配置制約 38  • ページテーブル初期化前後は、カーネルのイメージの先頭アドレスが 0xC000_0000 となるようにページエントリが設定される • カーネルイメージ以降の領域しかページテーブルがマップされないので、カーネルより前の領域はアクセス不能 →デバイスツリーなどはカーネルより上位に置く必要がある

Slide 39

Slide 39 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group CPUリセット解除～BOOTROM実行開始 39  • CPUコアのリセットが解除されると、0x8000_0000 番地から実行を開始する • ユーザーとの対話の入出力のために、UART 16550コアを初期化する • UART経由で「boot」と入力されるまで待つ • デバッグ用なので、別に待たなくてもよい • OpenSBIの先頭アドレス (0x8001_0000) へジャンプする • OpenSBIがCPUのコア番号(HART ID)やデバイスツリーのアドレスを要求するので呼び出し時の引数に指定

Slide 40

Slide 40 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group OpenSBIの初期化～Linuxカーネルの実行 40  • OpenSBIはデバイスツリーに基づいて対象プラットフォームを特定し、各ハードウェアに必要な初期化を行う。 • e.g. コンソール出力用にUARTペリフェラルのドライバを初期化タイマーハードウェアの初期化 • 初期化処理が終わったら、カーネルの先頭アドレスにジャンプする • このとき、未定義命令の例外が発生するのであれば、 CPUコアがC命令を実装していないのにカーネルがC命令有効でビルドされている可能性がある (実際はまった)

Slide 41

Slide 41 text

Fixstars Corporation www.ﬁxstars.com Copyright © Fixstars Group Linuxカーネル起動～rootfsマウント 41  • カーネルさえ呼び出せば後は簡単！と思っていたら結構問題が起きた • アクセス違反でカーネルパニック • 0xbff0_0000 みたいなアドレスにアクセスしている • →デバイスツリーがカーネルイメージより下位に配置されているのが原因 • rootfsがマウントできない • どうもカーネルのコマンドラインで指定するinitrdのサイズは実際のrootfsイメージサイズにぴったりの必要がある模様 • 長すぎると末尾のゴミでエラー • ある程度進んだらハングアップ(1) • ログメッセージ送信中にハングアップしていた • カーネル内で udelay を呼んでいたが、タイマーが正常に機能しておらず無限ループになっていた • ある程度進んだらハングアップ(2) • どうもアイドル関数が呼ばれている状態から抜け出せていない • ACLINTの実装ミスでタイマー割り込みが正常に動作していなかったため、タスクのディスパッチが行われなかった