FPGA開発日記

カテゴリ別記事インデックス https://msyksphinz.github.io/github_pages , English Version https://fpgadevdiary.hatenadiary.com/

NVDLAの勉強 (NVDLA Primerを読んでまとめる: ソフトウェア編)

目次

前回せっかくNVDLAを実行できるようになったので、NVDLAについて理解を深めていこう。

今のところ資料として良さそうなのは、NVIDIAの公開している公式の資料だ。 これを読んでいけば、NVDLAの仕組みについて理解することができそうだ。

  • NVDLA Primer

NVDLA Primer — NVDLA Documentation

今回は、NVDLA Primerを読んで、分かったことを纏めていく。 次はソフトウェア編。なんかソフトウェアプラットフォームの方が面白そうだ。

ハードウェア編はこちら。

msyksphinz.hatenablog.com

ソフトウェアデザイン

NVDLAは完全なエコシステムを持っている。 ディープラーニングのモデルを作成し、それをNVDLAのソフトウェアで使用できるような既存のモデルに変換する。

NVDLAのソフトウェアは2つに分類される。 - コンパイルツール : モデルの変換 - ランタイム実行環境 : NVDLA上のネットワークで動作するランタイムソフトウェア

http://nvdla.org/primer.html

NVDLA Primer — NVDLA Documentation via kwout

コンパイルツール: モデルの作成とコンパイル

コンパイルツールは、コンパイラとパーサを持っている。

コンパイルツールは2つのステップからなっている。 - パーサ : 事前に訓練されたCaffeのモデルを読み込み、ネットワークを通過させる中間表現和作成する。次のコンパイルステップに渡す。 - コンパイラ : 中間表現とNVDLAハードウェアコンフィグレーションを受け取り、ハードウェア例やのネットワークを生成する。

NVDLAのハードウェア構成について知ることは重要であり、コンパイラが適切なレイヤを生成しているかを確認することが可能になる。 例えば、異なる畳み込み動作モード(Winograd畳み込み、もしくは基本的な畳み込み)、あるいは畳み込み操作を複数の小さな動作に分割するなどのモードを選択できるようになる。 このフェーズでは、モデルを8bitから16bitの整数、16ビットの浮動小数点などの小さな精度に分割する。 コンパイラツールが、複数のNVDLAコンフィグレーションを生成できる。

ランタイム環境: デバイス上のモデル推論

ランタイム環境は、互換性のあるNVDLAハードウェア上で動作する。 大きく分けて2つのレイヤに分けられる。 - ユーザモードドライバ(User Mode Driver: UMD) : ユーザモードプログラムのメインインタフェース。ニューラルネットワークコンパイラがネットワークレイヤをコンパイルし、NVDLA Loadableと呼ばれるファイルフォーマットに変換する。ユーザモードランタイムドライバはこのファイルをカーネルモードドライバに投入sる。 - カーネルモードドライバ(Kernel Mode Driver: KMD) : ドライバとファームウェアからなり、NVDLAのレイヤ動作のスケジューリングを行う。NVDLAレジスタに各関数ブロックの構成をプログラミングする。

ランタイム実行は、ネットワークの格納から始まる。 NVDLA Loadable と呼ばれるイメージをロードする。 NVDLA Loadableファイルはレイヤと呼ばれる単位で管理され、レイヤを機能ブロックに実装することで動作する。各レイヤの動きと依存関係を記述し、KMD(Kernel Mode Driver)がづ長をスケジュールする。

UMD(User Mode Driver)は標準的なアプリケーションプログラミングインタフェース(Application Programming Interface)を備えており、Loadable Imageを勝利し、入力と出力のテンソルをメモリに格納し、推論を実行する。 個のレイヤはネットワークをメモリ中に格納し、KMDに処理を渡す。 例えばLinuxでは、ioctl()によってユーザモードドライバからカーネルモードドライバに渡される。 シングルプロセスシステムでは、UMDからKMDの呼び出しは、シンプルな関数呼び出しとして実装される。

KMDのメインエントリポイントは、メモリ中で推論ジョブを受け取り、複数の実行可能なジョブを選択する。 そしてコアエンジンスケジューラにタスクを挿入する。 コアエンジンスケジューラはNVDLAからの割り込みを処理する役割を持っており、各機能ブロックのレイヤをスケジューリングする。 スケジューラは依存グラフを使って後続のレイヤが実行可能になっているかを管理している。 これにより、コンパイラがレイヤを最適な方法でスケジュールし、異なるKMDの実装での性能差が発生することを防いでいる。

UMDスタックとKMDスタックはAPIとして定義されており、ラッパによってさらに上位のレイヤが定義されることを前提としている。 これにより、複数のプラットフォームで動作させることのできるソフトウェアを構築させることを期待している。

http://nvdla.org/primer.html

NVDLA Primer — NVDLA Documentation via kwout

NVDLAシステムインテグレーション

CNNの大きさと機能によって、NVDLAのパラメータを選択すべきである。 このパラメータの選択方法と、システムの面積と性能についてみていく。 各レイヤの実行時間はデータの入力、出力、MAC動作の時間から構成され、ネットワークの実行時間はすべてのレイヤの実行時間を足したものになる。 適切なMACユニット、畳み込みのバッファサイズ、SRAMサイズを選択することにより適切なネットワークを構築できる。

チューニングの質問

与えられた実装で、どれくらいの数学的な精度を保つべきか？

ディープラーニングの訓練操作は通常は32bit浮動小数点の精度で実行されるが、結果として得られるネットワークの精度は8bitの整数として表現される。 しかしいくつかの場合には、16bitの整数もしくは浮動小数点で表現した方が有効な場合がある。

MACユニットの数、必要なメモリ帯域はいくつか？

精度の次に問題となるパラメータは、性能と面積であり、これはMACユニットの数と必要なメモリ帯域に関連薄。 NVDLAを構成するときはこれを慎重に考慮する必要があり、NVDLAはレイヤ毎に処理が行われるため、レイヤ毎に性能を見積もるのが最適である。

MACユニットの数は比較的簡単に決めやすい。 例えば、畳み込みレイヤの入力と出力の数が決まっていれば、畳み込みのカーネルサイズは自然と決定する。 全体のMAC操作の数が決まるので、必要なMACユニットの数が決まるため、必要なクロックサイクルが予測しやすい。

メモリ帯域はの計算は少し難しい。 理想的なケースでは、入力画像を読み取り、出力画像を生成する。 畳み込みのバッファは非常に小さく、入力データと重みを保持できない場合は複数のアスが必要になる。 例えば畳み込みバッファが重みデータの数に対して1/4であるならば、計算は4つのステップに分けなければならない。 同様に、バッファが十分な畳み込みのラインを保持することができなければ、畳み込みは水平方向に複数回分割しなければならない。

オンチップSRAMは必要か？

外部メモリ帯域が、電力と性能において重要であるならば、オンチップSRAMは役に立つ。 このようなSRAMはセカンドレイヤキャッシュと考えられ、メインメモリよりも高い帯域を実現できる。 オンチップSRAMの実装は、より大きな畳み込みバッファの実装に比べるとそれほど重要なものではない。 (例えば、あるレイヤの性能が帯域により制限されるならば、全体の入寮画像を保持するためにSRAMを追加することで十分であり、システムのDRAMを使うよりも性能を向上させることができる。 しかし、レイヤがさらに畳み込みバッファサイズにより制限されるならば、同じ大きさのメモリによりシステムのスループットをより向上させることができる。) このトレードオフを考えるためのもっとも単純な方法は、畳み込みのバッファサイズを増加させることにより、必要な帯域を削減することであり、一方でオンチップSRAMは全体の帯域を向上させる。

NVDLAの面積と性能の例

ResNet-50のネットワークを構築した場合の面積と性能の比較表。

# MACs Conv. buffer size (KB) SDRAM bandwidth (GB/s) Silicon Cell Area (mm2, 28nm) Silicon Cell Area (mm2, 16nm) Int8 ResNet-50 (frames/sec) Power Estimate Peak/Average (mW, 16nm)
2048 512 20 5.5 3.3 269 766 / 291
1024 256 15 3.0 1.8 153 375 / 143
512 256 10 2.3 1.4 93 210 / 80
256 256 5 1.7 1.0 46 135 / 48
128 256 2 1.4 0.84 20 82 / 31
64 128 1 0.91 0.55 7.3 55 / 21
32 128 0.5 0.85 0.51 3.6 45 / 17

サンプルプラットフォーム

シミュレーション

NVDLAのシミュレーションプラットフォームでは、GreenSocs QBox, QEMU CPUモデル、およびSystemCモデルから構成されている。 Linuxカーネルモードどらいばとユーザモードテストユーティリティが、シミュレーションプラットフォームに含まれている。

FPGA

NVDLAを実際のデザインとして合成することのできるVerilogモデルが含まれている。 NVDLA SystemCモデルは使用せず、ソフトウェアによるレジスタ読み込みとレジスタ書き込みが、RTL環境により実行される。 FPGAモデルは制限されたサイクル測定環境を持ち、より大きな、複雑なネットワークに対してソフトウェアによるテストが可能になる。 FPGAプラットフォームの最適なサイクル数、面積、電力などは測定することはできず、検証のための環境である。

FPGAシステムのモデルは標準的なFPGAシステムのリース環境であるAmazon EC2 "F1" 環境を使用している。

モデル

Verilogモデル

Verilogモデルは、合成及びシミュレーションモデルを提供する。

  • スレーブホストインタフェース
  • 割り込み線
  • メインメモリインタフェース
  • セカンドメモリインタフェース

ホストとのメモリインタフェースは非常にシンプルだが、既存のSoCデザインと接続するためにはアダプタが必要である。 NVDLAでは、サンプルインタフェースとしてAXI4とTileLinkが含まれている。

NVDLAのオープンソースのリリースでは、合成スクリプトが含まれている。 物理デザインの設計や、より複雑なNVDLAのシステムを設計するためには、SoCバックエンドフローにおいてデザインを複数に分割して独立に設計を進める必要がある。 分割したデザインのインタフェースは、配線制約を満たすためにリタイミングすることができる。

NVDLAのコアは単一クロックドメインで動作する。バスアダプタは、クロックドメインをNVDLAの内部クロックからバスクロックに変換する機能を持っている。 同様に、NVDLAは単一の電源ドメインで動作しており、デザインは粗粒度・細粒度のパワーゲーティングを適用することができる。 SRAMは動作モデルを提供しており、これをASICなどのRAMに置き換える。 NVDLAのデザインではシングルポートおよびデュアルポートのRAMが必要である。

シミュレーションモデルと検証スイート

ソフトウェア開発のために、NVDLAはTLM2 SystemCシミュレーションモデルが含まれておりトレースプレイヤーベースのテストベンチが含まれている。 ユニット米の完全な検証環境は今後入手可能になる予定である。 検証スイートはテープアウト前にデザインを検証するために使用でき、RAMやクロックゲート、スキャンチェーンの検証なども行うことができる。