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

Fixstars Corporation www.ﬁxstars.com
Copyright © Fixstars Group Copyright © Fixstars Group
実践的！FPGA開発セミナー vol.6
2022/01/26 18:00～

View Slide

100GbEネットワークとの
連携でFPGA はもっと輝く
-低レイテンシ, 低消費電力を活かすために-

View Slide

Copyright © Fixstars Group
Who I am
3 
Eisuke MOCHIZUKI
望月英輔
ソリューション第一事業部　
シニアエンジニア

View Slide

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

View Slide

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

View Slide

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

View Slide

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/）

View Slide

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/）

View Slide

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

View Slide

検証環境
• 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 

View Slide

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

View Slide

検証結果: 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 を使用しているため？

View Slide

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

View Slide

AlveoでLinuxを動かしてみる

View Slide

Who I am
15 
写真
Kenta IDA
井田健太
ソリューション第一事業部　
シニアエンジニア

View Slide

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
• ベンダが提供する方法に従えば、比較的簡単に動作する

View Slide

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

View Slide

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/

View Slide

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

View Slide

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

View Slide

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

View Slide

対象のボード
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

View Slide

システム構成
23 
• ターゲット
• CPUコア：[email protected][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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

Vivadoのデザイン
30 
そこそこ複雑になっているが、コアは紫色の部分

View Slide

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

View Slide

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

View Slide

デバイスツリーの準備
33 
• ざっくりCPUの定義、クロックの定義、
メモリバス上のペリフェラルの定義が含まれる

View Slide

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

View Slide

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から直接カーネルを起動する

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

起動
42 
Dhrystone 25,641[DPS] = 14.6[DMIPS] = 0.116[DMIPS/MHz] なんか遅い？

View Slide

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

View Slide

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

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

fixstars

More Decks by fixstars

Other Decks in Programming

Featured

Transcript