愛知工業大学の藤枝です。前回 ACRi ブログに寄稿したときには ACRi ルーム副室長という立場でしたが、2023年度からは室長となりました。
このたび、我々 (愛工大ディジタルシステム研究室) が ACRi の活動とは別に開発してきた、ディジタル回路の「さわれる」遠隔学習システム SawareruSys が、関係者のご厚意により ACRi ルームでも利用できるようになりました。このシステムには専用のコントローラボードが必要ですが、今後の ACRi 関係のイベントでの配布を予定しておりますので、ご期待ください。
今回のコースでは、2回の連載で、SawareruSys のしくみと、ACRi ルームで SawareruSys を利用する方法について、それぞれ紹介したいと思います。コントローラボードを入手した方で、細かいことはいいからまずは試してみたい、という方は、このコースの後半の記事をご覧ください。
この記事の内容は、おおむね SawareruSys の利用マニュアルの内容と、その開発について国際会議 TALE 2023 にて発表した論文 [1] の内容を要約したものになります。
SawareruSys とは何か？
SawareruSys は、遠隔のサーバに設置された FPGA ボードの入出力に疑似的に触れる機能を備えた、ディジタル回路・FPGA の「さわれる」遠隔学習システムです。遠隔のサーバに FPGA を設置して、ユーザに時間貸し方式で提供する、というアイディアは、ACRi ルーム以前からもありました。私の知る限り、2007年に発表された RBoot [2] というシステムが、こうしたシステムで最古のものであるようです。
こうしたシステムで常に問題になるのは、作った回路の入出力にどのようにアクセスするかです。大学などでの FPGA 実験を遠隔化する研究では，Web ブラウザ上にボードを模したインタフェースを表示するものが多く見られます。画面をクリックするなどして入力を疑似的に操作し、画面表示の切替えにより出力の変化を確認します。出力については、Web カメラからの映像を提供するものもしばしば見られます。当初 ACRi ブログで紹介していた、シリアル通信を使ったり、仮想 I/O (VIO) の IP コアを使ったりといった手段も、大がかりな仕組みを必要としないという点では好ましいです。
しかしながら、既存の手段では、せっかく FPGA というハードウェアを使っているにもかかわらず、ハードウェアに触れている感覚を持ちにくい、というのが、私の問題意識としてありました。FPGA の実験をしているのに、組込みソフトウェアのプログラミング実験と同じように思われてしまっては残念、とも言い換えられます。しかし、入出力がたくさん搭載された実験向けの FPGA ボードはそれなりに高価で、1人1人に貸し出すというのもなかなか難しいです。学生数が多く、複数クラスで曜日を変えて実験室を使っている (本学のような) ケースでは、そもそも物理的にボードの数が足りません。
こうした背景から、私は1つの学術的「問い」を立てました。それは、「ハードウェアに触れている実感を与えつつ、しかし高価な FPGA ボードを貸し出すことのない方法で、ディジタル回路の遠隔学習システムを提供し、実地での実験・実習と同等の教育効果を達成することはできるか」ということです。そして、その「問い」に答える手段が、これです。
遠隔の FPGA ボードの入出力の変化を、手元で確認するためのコントローラボード、SawareruBoard です。コントローラボードの中央に見えるのは、USB 機能をもつ PIC マイコン (PIC18F45K50) です。コントローラボードを利用者の PC に接続すると、USB シリアルデバイスとして認識されます。必要なのは、コントローラボードと FPGA ボードとの間での通信です。コントローラボードの入力が変化したことを FPGA ボードに伝えられれば、また逆に、FPGA の出力が変化したことをコントローラボードに伝えられれば、コントローラボードで遠隔の FPGA ボードの入出力に疑似的に「さわれる」ことになります。
SawareruSys はどう動いているか？
SawareruSys において、2つのボード間での通信を実現するためのシステム構成を、上の図に示します。コントローラボードが接続されたユーザ PC と，FPGA ボードが接続された開発用仮想マシン (VM) のそれぞれで、通信中継のためのコネクタアプリを起動しておきます。コネクタアプリは、ボードとの USB/UART 通信を TCP/IP 通信に中継する、またはその逆を行います。TCP/IP 通信は、実際にはユーザ PC とゲートウェイサーバとの間の SSH ポートフォワーディングを経由して行われます。この部分は、ACRi ルームでリモートデスクトップを使ってサーバを利用するときと、同じ仕組みです。
コントローラボードの入力の変化、あるいは FPGA 上のユーザ回路の出力の変化は、それぞれマイコンのプログラムや FPGA 上の入出力制御 (I/O) 回路によって、コマンド文字列に変換されて送信されます。コマンド文字列は2文字の半角英数字で構成されます。例えば、コントローラボードの右端のスライドスイッチがオンになったことを表すコマンドは IU、ユーザ回路の右端の LED 出力がオンになったことを表すコマンドは 4A、といった具合です。
FPGA 上の I/O 回路に必要な機能は、入出力の変化とコマンド文字列との相互変換だけではありません。ユーザの利便性のためには、FPGA ボードがサーバに繋がっているときとそうでないとき (つまり、実験室などで直接 FPGA ボードを操作しているとき) とで、同じ回路を FPGA に書き込んで動かせることが望ましいです。そのためには、FPGA ボードがどう利用されているかを、自動でチェックする機構が必要です。サーバに繋がっていると判断した場合には、受け取ったコマンド文字列からコントローラボードの入力を再現して、ユーザ回路に渡します。そうでない場合には、FPGA ボードに元々備わっている入力をそのままユーザ回路に渡します。
これらを踏まえた I/O 回路 (を含む、FPGA に書き込まれる回路全体) のブロック図を、上図に示します。I/O 回路には3つの主要な構成要素、UART コントローラ、I/O トランスレータ、スイッチャーが含まれています。UART コントローラは、FIFO インタフェースを備えた、シリアル通信の送受信回路です。FIFO つきの送信回路については、シリアル通信で Hello, FPGA (5) の記事で、拡張の1つの方策として取り上げたものと、ほぼ同じです。
スイッチャーは、サーバからボード種別の応答要求 (コマンド文字列 VX) が送信されるまで、I/O トランスレータを無効化した状態で待機します。その間は、FPGA ボードの元々の入力 (SW) がユーザ回路に渡されます。応答要求を検出すると、スイッチャーはサーバに対して FPGA ボードの種別応答であるコマンド文字列 vx を送信し、I/O トランスレータを有効化します。これ以降、I/O トランスレータによって再現されたコントローラボードの入力が、ユーザ回路に渡されます。ユーザ回路の出力 (AN, SEG, LED) は、FPGA ボードの出力とするとともに、I/O トランスレータによって定期的にサンプリングされ、その変化がコマンド文字列に変換されます。
Dynamic Function eXchange (DFX) 機能
さて、このようなユーザ回路と I/O 回路とを組み合わせて1つの回路にしようとすると、いくつかのやり方が考えられます。例えば、両方のソースコードを持ってきて組み合わせる、I/O 回路部分を IP コアにパッケージして使うなどが挙げられます。SawareruSys ではその中でも、動的再構成 (Dynamic Reconfiguration)、AMD 社の用語だと Dynamic Function eXchange (DFX) という機能を使うことにしました。この機能を使うと、書き換え可能な動的領域と、決まった回路が動作する静的領域とに、FPGA の領域を分けて使うことができます。今回は、ユーザ回路を動的領域に、I/O 回路を含むそれ以外の回路を静的領域に置くことにします。
ACRi ブログ内で DFX について取り上げた記事は今のところないので、せっかくですからユーザガイド [3] の内容を要約しつつ、SawareruSys のベース設計を論理合成する手順について、ここで説明したいと思います。
はじめに、Vivado のプロジェクトを新規作成し、ユーザ回路として空の回路を指定した状態で、回路全体を論理合成します。このときユーザ回路として指定する空の回路には、black_box という属性を付加しておきます。具体的には、Verilog HDL では、
(* black_box *) module DR_TOP (...);
// 入出力の定義（ここでは省略）
endmoduleというように、module 文の直前に (* black_box *) と書きます。VHDL では、
architecture STRUCTURE of DR_TOP is
attribute black_box : string;
attribute black_box of STRUCTURE : architecture is "yes";
begin
end STRUCTURE;
というように、architecture に対して black_box 属性を追加します。module や architecture の中身は空っぽにしておきます。
論理合成後は、Open Synthesized Design で合成結果を開きます。このとき、下図に示す Critical Warning が表示されます。今回は意図的に black_box を含んだ回路を作っているので、これは無視してよいものです。そのまま、メニューの「File」→「Checkpoint」→「Write」で、合成結果をチェックポイント (拡張子 .dcp) としてファイルに保存しましょう。以降、このファイルを step_1.dcp とします。
次に、もう1つ Vivado のプロジェクトを作成し、今度は中身のあるユーザ回路を論理合成します。通常の論理合成では、トップモジュールの入出力は FPGA のチップ外の I/O ピンに接続されるため、それぞれの入出力に I/O バッファが自動的に挿入されます。一方、ここで合成するユーザ回路を、先ほど作った回路全体の中に組み込むため、I/O バッファは不要です。I/O バッファの挿入を抑止するには、論理合成のオプションに -mode out_of_context と指定します。オプションを指定しているときの様子を、下図に示します。
こちらも論理合成が終わったら、Open Synthesized Design で合成結果を開き、メニューの「File」→「Checkpoint」→「Write」でチェックポイントを保存します。以降、このファイルを step_3.dcp とします。
これで必要な回路が揃いました。作成したチェックポイント同士を結合して、マッピングと配置配線を進めていきます。「File」→「Checkpoint」→「Open」で step_1.dcp を開きます。再び black_box 関係の警告が出ますが、無視します。次に、画面下の Tcl Console タブに以下のコマンドを順番に打ち込みます。ただし、/PATH/TO/CHECKPOINT のところは、step_3.dcp を保存したフォルダのパス名に置き換えてください。また、ユーザ回路 (DR_TOP) は DR という名前でインスタンス化されているものとします。
set_property HD.RECONFIGURABLE true [get_cells DR]
cd /PATH/TO/CHECKPOINT
read_checkpoint -cell [get_cells DR] step_3.dcp1行目で DR が動的再構成の対象であることを指定しています。2～3行目で、DR の中身を step_3.dcp に保存されているユーザ回路に置き換えています。ここまで実行すると、空っぽだった DR にちゃんと中身が入ったことが、画面左上の Netlist タブで確認できます。
次に行うのは、ユーザ回路が配置される FPGA 上の範囲 (Pblock) の指定です。画面右上の Device タブで P+ と書かれたアイコンをクリックし、スライス (藍色)、DSP ユニット (深緑)、ブロック RAM (茶色) を含んだ適当な範囲を囲みます。囲み終わると Pblock に名前をつけるよう促されるので、ここでは pblock_DR と入力します。その後、Netlist タブから DR をクリックし、Device タブの Pblock 上にドロップします。ここまでの作業を進めたときの様子を、下図に示します。
設定した Pblock の範囲に問題がないかをチェックします。メニューの「Reports」→「Report DRC」で、Rules の Dynamic Function Exchange のみにチェックを入れた状態で DRC (Design Rules Check) を実行します。エラーが出た場合には、メッセージに従って範囲を修正してやり直します。
ここで設定した Pblock の範囲は、Tcl Console で write_xdc -force PBLOCK.xdc と入力することで、制約ファイル (拡張子 .xdc) として保存できます。制約ファイルを保存しておけば、2回目以降は read_xdc PBLOCK.xdc でファイルを読み込むだけで、Pblock の指定は完了します。
これですべての準備が整いました。マッピング・配置配線・ビットストリームの生成を順番に進めます。もし回路をデバッグするために ILA (Integrated Logic Analyzer) を加えているのであれば、デバッグプローブもここで生成します。Tcl Console タブに以下のコマンドを順番に打ち込みます。
opt_design
place_design
route_design
write_bitstream -force -bin_file base.bit
write_debug_probes -force base.ltx
それぞれのコマンドが、マッピング、配置、配線、ビットストリームの生成、デバッグプローブの生成に対応します。ここで生成された base.bit または base.bin は、step_3.dcp に保存されているユーザ回路を含んだビットストリームになります。必要に応じて、FPGA ボード内の SPI Flash メモリに base.bin を書き込んで、電源投入時に動作テスト用の回路が自動的に書き込まれるようにしておくとよいでしょう。 最後に、ユーザ回路を空の回路に戻し、残りの部分の配置配線の結果を保持した状態で、チェックポイントを保存しておきます。Tcl Console タブに以下のコマンドを順番に打ち込みます。
update_design -cell DR -black_box
lock_design -level routing
write_checkpoint -force base.dcp
別のユーザ回路を使う場合、これで保存された base.dcp を起点に作業すると、read_checkpoint を使って DR の中身を置き換えるだけで、すぐにマッピング (opt_design) 以降の作業に移ることができます。しかも、ユーザ回路以外の部分は配置配線が済んでいるので、処理にかかる時間も比較的短く済みます。
DFX の手順を自動化する
DFX の機能を使う上での主な制限には、
- ユーザ回路部分の入出力は常に同じでなければならない
- マッピング以降は Vivado のプロジェクトを使ったフローではなく、チェックポイントを使ったフローとなる
といったところが挙げられます。1つ目の制限にはラッパ回路を、2つ目の制限には Vivado 用の Tcl スクリプトを、それぞれ自動生成できれば、ユーザがこれらの制限を意識する必要はなくなります。
SawareruSys には、これを実現するための開発フロントエンド DRFront (Dynamic Reconfiguration Frontend) が含まれます。DRFront の画面の一例を以下に示します。
DRFront には、Verilog HDL/SystemVerilog や VHDL のソースコードの解析、トップモジュールのボードへの割当ての支援、ラッパ回路や Tcl スクリプトの自動生成、Vivado の起動といった機能をもちます。また付加的な機能として、HDL 記述やテストベンチのひな型の自動生成にも対応しています。
ビットストリームを生成する手順のために、DRFront が自動生成する Tcl スクリプトの一部を以下に示します。
open_checkpoint $checkpoint_base
read_checkpoint -cell [get_cells DR] $checkpoint_proj
opt_design
place_design
route_design
write_bitstream -bin_file -force ${project_name}.bit
close_project
これはまさに、先ほど説明した、チェックポイントを読み込んでマッピング以降の処理を行う、という手順になります。実際には、複数のチェックポイントが見つかったときに、最新 (と思われる) ものを判定する処理なども含まれています。
まとめ
この記事では、SawareruSys の動作原理の概要と、その中で使われている DFX 機能の使い方について簡単に紹介しました。2018年以前は、DFX に相当する機能 (当時は Partial Reconfiguration とよばれていました) を使うには、有料のライセンスが必要でした。そのせいもあってか、具体的な手順を説明した日本語の資料は、それほど多くありません。使いこなせば色々と面白い活用が考えられる機能ですので、この記事の内容が参考になればと思います。
後半の記事では、コントローラボードを入手された方向けに、SawareruSys の基本的な利用手順を説明します。
愛知工業大学 藤枝直輝
参考文献
[1] N. Fujieda and A. Okuchi: A Novel Remote FPGA Lab Platform Using MCU-based Controller Board, 12th International Conference on Teaching, Assessment and Learning for Engineering (TALE 2023), pp. 188-193, 2023. DOI: 10.1109/TALE56641.2023.10398409
[2] K. Datta and R. Sass: RBoot: Software Infrastructure for a Remote FPGA Laboratory, 15th Annual IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM 2007), pp. 343–344, 2007. DOI: 10.1109/FCCM.2007.53
[3] Advanced Micro Devices, Inc.: Vivado Design Suite ユーザーガイド Dynamic Function eXchange, User Guide UG909 (v2024.1), 2024.