Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Zynq MP SoC で楽しむエッジコンピューティング ~RTLプログラミングのススメ~

Zynq MP SoC で楽しむエッジコンピューティング ~RTLプログラミングのススメ~

FPGAセミナー 2023/01/25 の発表資料です。
https://fixstars.connpass.com/event/271738/

Ryuji Fuchikami

January 25, 2023
Tweet

More Decks by Ryuji Fuchikami

Other Decks in Programming

Transcript

  1. 自己紹介 (渕上 竜司@Ryuz88)  福岡在住のソフトウェアエンジニア  ITRON仕様の Real-Time OS 作ったり

    (Z80から Microblaze までいろいろ)  Raspberry PI 用のカメラをZynqに繋いで高速度撮影してみたり  Zynq に OLED繋いで限界までフレームレート上げてみたり  ZynqMP にIMU繋いだりモーター回してみたり  FPGA用のLUTテーブルを直接学習させる深層学習環境を作ってみたり  ZynqMPのRPU(Cortex-R5)のコードを Rust で書いてみたり  RPU用のReal-Time OS 機能を PL(FPGA)に実装してみたり  MIPS や RISC-V のソフトコア書いてみたり  Pybind11 + Verilator で Python でテストベンチ書いてみたり  稀に基板起こしてみたり、ホットプレートリフローしてみたり などなど、いろいろ組み込みコンピューティングを楽しんでいる人間です。 (詳しく知りたい方は是非ブログなどアクセスください) ※ 本日の発表は私個人のものであり、所属する組織を代表するものではありません http://ryuz.my.coocan.jp ↑ すべて個人の趣味です
  2. Zynq UltraScale+ MP SoC のススメ APU RPU PL(Programmable Logic) GPU

    あくまでLinux母体で従来のIoTプログラミングが最低限出来る環境から PL(Programable Logic)プログラミングにて守備範囲を拡張できる 最強のIoTプロセッサだと思う (マイコンより高いが、NUCやGPUと比べればまぁ..) 買ってすぐに Ubuntuつかえるよ~ RustでOpenGLしてみた udmabufは神ソフト あえて私は組み込みRust AXIバス仕様を覚えて CPUやメモリと「もしもし」しよう Verilatorも神ソフト
  3. CPU CPU CPU GPU なぜPLでのRTLプログラミングを薦めるのか SM CPU GPU Memory CPU

    Memory I/O USBなど PL CPU Unified Memory IP MIPIなど専用I/F IP IP IP モーター制御 IP 制御/設定 PCのプログラミングモデル(CUDAでGPUを使う場合) RTLプログラミングで可能となるモデル • メモリ to メモリの演算 • 基本的に同じ演算を超並列で実行 • 演算効率/メモリアクセス効率を出す 為に独特のテクニックがある • フローチャートベースの構造化設計 • 高スループットだが、低レイテンシな 細かい時間制御は苦手 • プロセッサにあらかじめ準備されてい る手段(USBとかMIPIとかI2CとかSPIと かGPIO)でしか外部とインターフェース 出来ない • メモリを介さず直接I/Oに対して低 レイヤプログラミングができる • パイプライン並列処理が書きやすい • HLSで作ったコアの内包も可 • データフローベースの構造化設計 • サイクル単位でタイミング記述がで きる。 IP Core Core Core Core Core Core Core ・・・ PCのプログラミングモデルと比較してみる
  4. SIMD/SIMTの並列とRTLの並列の比較 計算 ユニット1 計算 ユニット2 計算 ユニット3 計算 ユニット4 ・・・

    計算 ユニットN t=0 Load Load Load Load Load t=1 計算A 計算A 計算A 計算A 計算A t=2 計算B 計算B 計算B 計算B 計算B t=3 計算C 計算C 計算C 計算C 計算C ・・・ t=M Store Store Store Store Store 計算 ユニット1 計算 ユニット 計算 ユニット 計算 ユニット ・・・ 計算 ユニットM t=0 stream-in 計算A 計算B 計算C stream-out t=1 stream-in 計算A 計算B 計算C stream-out t=2 stream-in 計算A 計算B 計算C stream-out t=3 stream-in 計算A 計算B 計算C stream-out ・・・ t=N stream-in 計算A 計算B 計算C stream-out CPU/GPU (SIMD/SIMT記述) Programable Logic (RTL記述) 空間 時間 空間 時間 一斉 アクセス 一斉 アクセス 誤解を恐れず言うなら時空間が転置した世界 データは横に流れていく データは縦に流れていく 外部デバイス/メモリバス/CPUバスなどいろいろなものが左右に来る なのでデバイス制御やリアルタイムプログラムをしたいIoTな人に最適 基本的に一斉アクセスに耐えられるリッチなメモリシステム前提 (キャッシュとかシェアドメモリとか広帯域なバスとか) ※ MIMDをあえて無視していることに突っ込まないであげてください(笑) 学校方式(1時間目:国語、2時間目:算数、3時間目:社会、...) 会社方式(Aさんは経理、Bさんは営業、Cさんは開発、...)
  5. 並列プログラミングモデル SIMDプログラミング (AVXとかNEONとか) RTLプログラミング (VerilogとかVHDLとか) SIMTプログラミング (CUDAとかGLSLとか) プログララミング 覚えた! SIMD

    覚えた! SIMT 覚えた! 次のステップに RTLは如何ですか? 低レイヤ並列プログラミングのススメ OpenMPとかHLSとか、便利なんですが抽象度高いので、低レイヤープログラミング志向の方は是非こういうベクトルでスキルアップを! スキルアップ
  6. RTL言語いろいろ  VHDL  Verilog  SystemVerilog  SFL 

    Chisel  Veryl  その他 どちらかはまず覚えましょう(共通言語としての古典HDL) ← 個人的にオススメ(UVM勉強中) ← 最近興味津々 多分もっといろいろあると思いますが... パッケージマネージャ欲しい... フォーマッタとか、Language Server とかも重要 だいぶモダンなプログラミングが できる世界になってきている
  7. RTLプログラミングで何ができるのか?  外部デバイスとの専用インターフェース設計  デバイスとのやり取りをナノ秒単位で細かくコントロールできる  他のスレッドや割り込みに干渉されて周期処理にジッタが入ったりしない  「〇〇センサをアレイ状に配置してみた」のような独自デバイス制御 

    イメージセンサーなどの専用I/F対応も可能  「SPIのポート数が足りない」のような地味な課題にも結構有効  CPUを作る/キャッシュシステムを試作するなど計算機設計  自作CPU/自作OS など、趣味の王道  高性能なIPコアが作れる  CPU/GPUは大量の浮動小数点演算以外は非効率なのでそもそもPLは演算効率が良い(コスト/電力)  DNN用推論エンジンとか、Codecエンジンとか、ネットワークとか  HLSで性能突き詰めていくと「いっそRTLで書きたい病」が発症する領域
  8. 怖くないRTLプログラミングのススメ https://youtu.be/VMd0Uxcs9sM  [ステップ1] Kria KV260をポチる (AVNET/Digi-Key/Mouserなど)  [ステップ2] Ubuntu

    を SD カードに書き込んで起動  [ステップ3] LEDチカチカからはじめましょう!  PL使うLチカ記事を2つ書きました  「KV260でSystemVerilogでLEDチカしてみる」 (https://zenn.dev/ryuz88/articles/kv260_led_blinking)  「KV260でPSからPL経由でLEDチカしてみる」 (https://zenn.dev/ryuz88/articles/kv260_led_blinking_ps)
  9. 続くステップも一歩ずつ  CPUと通信したりDDR4-SDRAMを読み書きしたり  PSからのアクセス、ikwzm氏のudmabufを使ったサンプル準備中  https://github.com/ryuz/jelly/tree/master/projects/kv260_udmabuf_sample  FPGA内のいろいろなリソースやIPを使いこなそう 

    FIFO/DSP/BRAM/SERDES/MMCM/etc. : 高度な計算機設計や、システムプログラムができる  MGT(Multi-Gigabit Transceiver) : PCIe, Ether, SATA, HDMI, 3G-SDI, Aurora など高速通信  各種IPコア : いろんな機能のコアが再利用できるぞ  デバッグの為のツールも覚えよう  シミュレータを覚えると、実機なしで内部変数の変化が全部トレースできる  ILAを覚えると実機で内部のレジスタ値の変化が時系列で見れる 変数の時系列変化を波形として見れるのが RTLデバッグの面白いところ CUDA の Nsight のような横軸に時間を置いた表示 焦らず、出来ることを一個づつ増やしていけば大丈夫!
  10. MIMDプログラミングについて MIMDのプログラミングモデル(例えばメッシュ構造) https://docs.xilinx.com/v/u/en-US/wp506-ai-engine ZynqMP の後継世代: Versal Edge AI Zen5 にも搭載される模様?!

    https://ascii.jp/elem/000/004/096/4096545/ 今回話に出していないませんが、MIMDも重要なアーキテクチャ。 主にHPC系で用いられる技術であり、通信遅延も加味して同期並列プログラ ミングが必要。 ただし、エッジコンピューティングにおいても • 次世代では NoC(Network on Chip) と共にチップ内に搭載されてくる • 複数装置を連携動作させるなどの設備系IoTでは同じ構成を取りうる などの事情があり、注目すべき技術 MIMDのAIエンジン が搭載されている
  11. 高位合成言語について  本日はRTLをオススメしているのであえて触れていませんが、もちろん無視できな い技術  基本的には、C++などの逐次処理言語で記述したアルゴリズムの並列性をコンパイ ラに自動抽出させて、pragma を使ってループアンローリングやパイプライン化な どの並列展開を行う 

    そういう意味では、CPU/GPUでいえば OpenMP/OpenACC などとなんらやってる ことは変らない (ループアンローリングや疑似ベクトル)。  FPGA用だと基本的には AMD/Intel の HLS 。あとは OpenCL/SYCL とかいろいろ  LLVM CIRCT が将来的に非常に気になるところ https://circt.llvm.org/
  12. VS Code など各種エディタ (Language Server) RTLプログラミングのフローの例 論よりRUNできるのがFPGAの良いところ ・Linux + FPGA

    Manager による動的ダウンロード実行 ・ILA による波形デバッグ ・CPU と組み合わせた printf/gdb デバッグ 実機RUN ・Vivado Simulator(xsim) + UVM ・Verilator + SystemC ・Verilator + Pybind11 + OpenCV ・gtkwave シミュレーション実行 プログラミング Vivadoによる配置配線 GUI/CUIどちらも可能 コンパイル ・Sphinx ・WaveDrom ・Mermaid ドキュメンテーション Vivado内のGUIでも行えるが、最近は CUI化して VS Code で殆どやってしまうのがお気に入り 特に Remote Development で PSのプログラムもそのまま面倒見れるのが便利 (パッケージマネージャーのあるRTL言語が欲しいと思う今日この頃...)
  13. プログラミング言語としてのRTLの再考察  特徴  文字通りレジスタ間の演算を直接記述する  言語自体が並列記述を前提としており、様々な並列演算が明示的に書ける  外部の I/O

    や CPU とのデジタル的なやり取りを直接記述する  すべて並列に計算されるのでフローチャートのような演算順序の記述ではなく、データフ ローをそのまま記述することになる  動作周波数に応じたサイクル単位の記述なので厳格なリアルタイム保証ができる  デバイスの持つリソースの総量に収まりさえすれば、かなり自由に色んな用途に割り当て 可能  デメリット  1サイクル内に収まる複雑度まで演算を細かく分解しないといけない(逆に、細かく分解す るほど高周波数で動作できる)  クロック周波数は CPU/GPU 程高くない  リソースが収まらないとコンパイルに失敗する(「遅くなるけど動く」ようなことはない) HDLとしてではなく、ソフトウェア言語として見つめ直す
  14. 並列プログラミング言語としての側面 SystemVerilog の例(記述した演算が同時に行われる)  C++などの逐次記述言語ではなく並列記述言語としてとらえる  分割統治のための仕組みとして下記のようにとらえてみる  always は変数の書き換えスコープ

     module は変数の参照スコープ  module のポート宣言は外部参照の為の import/export ハードウェア記述言語という側面は一旦忘れて捉えなおしてみる ⇒ 並列計算が書きやすい、普通のプログラミング言語なのでは?
  15. 汎用計算機に対するPLの優位性 + × sqrt ÷ + × sqrt ÷ +

    × sqrt ÷ + × sqrt ÷ + + + + × × × × sqrt sqrt sqrt sqrt ÷ ÷ ÷ ÷ GPUなど プロセッサ1 プロセッサ2 プロセッサ3 プロセッサ4 FPGAなど 全種類の演算ができるプロセッサを並列化 ある演算をしているとき他の演算器は遊ぶ Processor ALU add mul div sqrt reg Processor ALU add mul div sqrt reg Processor ALU add mul div sqrt reg Processor ALU add mul div sqrt reg add mul div sqrt reg reg reg reg 演算の前後に依存関係が無ければ パイプライン化は非常に効率が良い ステージ1 ステージ2 ステージ4 ステージ3
  16. RTLプログラミングを始めるときの壁  RTL言語を覚える(SystemVerilogとかVHDLとかChiselとか)  他のプログラミング言語と比べて各段難しくはない  サイクル単位の並列プログラミングに頭の切り替えは必要  プログラミング言語と無関係の覚えることが多い 

    合成ツールはどうやって使うの?  プログラムの中のポートと回路図をどう繋ぐの?  どうやって、PSからクロック引っ張り出すの?  どうやって、Linuxのアプリと通信するの?  PL固有の覚えることが少しある  AXIバス規格とのやりとりのテクニック  非同期クロックの扱い方  自動推論の先にあるハードマクロ(LUT/DSP/BRAM/IOBなど)の理解とタイミングクローズ それほど壁はない? 良書が少ないのが課題? 地味に嵌まることが多い (ここで辞めちゃう人結構いません?)
  17. PLプログラミングの手段  Vitis プラットフォームを作る方法  RTLプログラミングなどでプラットフォームを作り、HLSやRTLなどで カーネルを書いて実行する方法 (CUDA や OpenCL

    っぽいスタイル)  Vivado で開発する方法  HLSやRTLでモジュールを作り、RTLやブロックデザイナでシステムと して組み立てる方法 どっちにしろまずRTLから入るべきでは? (特に外部インターフェースを扱いたい場合は)
  18. IoTプログラマの為のRTLでのLチカ記事  ZynqMP を使えば、従来の IoT プログラム資産を活用しつつ、プログラミングの幅を広げる形 でRTLプログラミングに手を出すことが可能。  ハードウェア記述言語ではなく、並列プログラミング言語としてRTL言語を捉えることで、プ ログラミングのパラダイムが広がる。

     RTLプログラミンの敷居  ZynqMP ボードがお高い(数万円以上する)  LEDチカ の C++版 ⇒ RTL版 のわかりやすいチュートリアルが少ない  SIMD/SIMT ⇒ RTL の流れで説明する並列プログラミングチュートリアルが少ない  AXIバス規格/非同期クロック/ハードマクロ(DSP/BRAM/IOB)などの固有部分のチュートリアル が少ない  結局 LEDチカチカ までのチュートリアルが一番重要では?  最近KV260のRTLでのLチカをブログ記事にしたのでご紹介  KV260でSystemVerilogでLEDチカしてみる https://zenn.dev/ryuz88/articles/kv260_led_blinking  RTLプログラミング考察 https://zenn.dev/ryuz88/articles/rtl_programing_tutorial
  19. SIMD/SIMTの並列とRTLの並列の比較(2) CPU/GPU Programable Logic (RTL記述) 性能不足が実行時にわかるかコンパイル時にわかるかの違い 計算 ユニット1 計算 ユニット2

    計算 ユニット3 計算 ユニット4 ・・・ 計算 ユニットN 命令1 Load Load Load Load Load 命令2 計算A 計算A 計算A 計算A 計算A 命令3 計算B 計算B 計算B 計算B 計算B 命令4 計算C 計算C 計算C 計算C 計算C ・・・ 命令5 Store Store Store Store Store ストール 演算量に必要なFLOPS数の 計算機用意したのに実行してみると ストールしまくりで性能が出ない... プロファイルを取りながら 必死にボトルネックを探して改善 迫る納期に、ゴールの見えない絶望感 処理 A 処理 B 処理 D 処理 E 処理 C コンパイル時に タイミングエラー 処理 A 処理 B 処理 D 処理 E 処理 C FF 学校方式: 体育の後に数学やるとみんな寝る!(コンパイラの最適化限界) 会社方式: 開発部門から経理までの廊下が長くて非効率! 給食の後にしてみたがやっぱりみんな寝る! (コンパイラの)配置最適化が限界なら、社内の伝票配達屋さんを雇おう 設計修正は大変だけど、どこが悪いかは わかるので計画的にゴールを目指せる