このページは、プロの FPGA 設計者になるための全 5 ページのシリーズの 4 ページ目です。今回は、最初はそれほど重要でないいくつかのスキルを扱います。まず、そもそもなぜそういうことをするのかを説明するところから始めます。
なぜ重要でないものに触れるのか?
スキルについてのページを書きながら、「いや、これはそれほど重要ではありません」と言うのは少し変に思えるかもしれません。しかし、このシリーズは、こうしなさいと指示するものではありません。むしろ、各テーマがなぜ重要か(あるいはそれほど重要でないか)を説明しようとしています。ですから、重要性の低いテーマについても同じことをするのは理にかなっています。
実践的スキルの中には、よく役立つけれど過大評価されているものがあります。ある時点で身につける必要があるかもしれないスキルですが、一生必要にならない可能性もあります。テーマが過大評価される理由は、ボード用のサンプル設計によく登場するからです。重要なものだからではなく、特定の技術で素晴らしく印象的なデモを作るのが比較的簡単だからです。
念のためはっきりさせておくと、以下に挙げるスキルはすべて役に立ちます。ただ、プロジェクトに取り組むために必要になったときに、そのプロジェクトの要件に固有の他の多くの技術テーマと一緒に身につけることが多いというだけです。
I2C と SPI
この 2 つについて何も知らなくても、FPGA 設計者として一生やっていけます。しかし現実的には、実務でかなり早いうちに出会う可能性が高いです。
I2C(IIC、Inter-Integrated Circuit)、それに非常によく似たプロトコル、そして SPI(Serial Peripheral Interface)は、PCB 上の電子部品との間でデータを送受信するための、群を抜いて最も一般的な規格です。これらはマスタ/スレーブ (master / slave) の構成に基づいており、マスタが読み出しまたは書き込み操作を開始し、スレーブがそれに応答することがあります。ほとんどの場合、マスタはプロセッサか比較的高度な部品で、スレーブは電子設計の中で周辺機能を担う、より単純な部品です。
I2C とそれから派生したプロトコルはデータレートが非常に低く(通常 100 kbit/s 程度)、主に部品のパラメータを設定するために使われます。たとえば、その部品が A/D コンバータなら、I2C を使って、どの電圧リファレンスを使うか、出力を符号付き整数と符号なし整数のどちらで出すかを選択できます。このプロトコルの主な利点は、接続がわずか 2 本のワイヤで済むことです。クロック(SCL)とデータ(SDA)です。グラウンド(GND)への接続もありますが、これは通常 PCB の共通グラウンドを通して行われ、別配線が必要になることはまずありません。
このプロトコルは実のところバスなので、各データ交換サイクルには 7 ビットのアドレスが含まれます。その結果、この 2 本のワイヤに複数の部品を並列に接続できます。この場合、各部品は異なるアドレスを持つ必要があります。
I2C 規格はもともと Philips が特許を取得していました。非常に便利だったため、驚くほどよく似た亜種が多数一般的に使われています。たとえば SMBus、PMBus、DDC2 などです。これらの規格は I2C の主要な考え方を採用していますが、パラメータ(とくにデータレート)や主な使用シナリオが少し異なります。たとえば、今日販売されているすべてのコンピュータモニタには、どのグラフィックスモードに対応するかの情報を含む小さなフラッシュメモリがあります。コンピュータのグラフィックスカードとモニタの間のケーブルには、このフラッシュメモリに接続された 2 本のワイヤがあります。これにより、グラフィックスカードは DDC2 プロトコルでこのメモリのデータを読み出せます。これは実質的に I2C と同じです。
ですから、I2C を理解していれば、多くの異なる部品がどうやって互いに会話するかを知っていることになります。
次は SPI です。このプロトコルは通常、マスタとスレーブの部品間に 4 本のワイヤ(SCLK、MOSI、MISO、SSn)を必要とします。このプロトコルも、I2C やその亜種と同じように、部品の設定に使われることがあります。しかし SPI の主な用途は、より高いデータレートでのデータ伝送です。部品が 20〜50 MHz の SCLK 周波数に対応するのは珍しくありません。ですからアプリケーションデータを伝送するのに実用的なプロトコルです。たとえば、2 つのオーディオチャンネル用の A/D コンバータは 48,000 Hz × 2 × 16 ビット = 1.536 Mbit/s を生成します。このデータレートは SPI にとって朝飯前です。実際、SPI でサンプルを伝送するオーディオチップがいくつかあります。
FPGA と、ビットストリーム (bitstream) を読み込むフラッシュメモリとの接続が、しばしば QSPI であることも言及する価値があります。このインターフェースは通常の SPI と同じですが、データワイヤが 1 本ではなく 4 本あり、データ転送がより高速になります。
では、結論の問いに移りましょう。FPGA 設計者になる一環として I2C と SPI を学ぶべきでしょうか? 私の考えでは、これら自体は FPGA 設計とは何の関係もありません。しかし、電子製品を開発する小さなチームで働くなら、I2C でどれかの部品を設定する必要が生じる可能性が高いです。あるいは、FPGA に接続された部品の 1 つが SPI で通信するかもしれません。FPGA のビットストリームを格納したフラッシュメモリを、自分のロジックから直接使うこともあるでしょう。
これら 2 つのプロトコルには多くの用途がありますが、最も重要なのは、データシートに登場したときにそれらとその亜種を見分けられることです。部品がこれらのプロトコルの 1 つを使っていても、その名前を明示していないことがよくあります。I2C の背後にある原理を知っていれば、データシートが似たインターフェースを説明しているのを見逃すことはありません。SPI も同じです。
そして、面接で経験豊富な FPGA 設計者だと主張しながら、これら 2 つのプロトコルについて何も知らなければ、あまり印象的ではないかもしれません。
さらに、経験を積むためのプロジェクトの提案です。I2C やその亜種を使う、安価な温度センサや別の種類の単純な部品を見つけるのはとても簡単です。そういう部品を買って、Dupont ワイヤか、その他の手軽な方法で FPGA ボードに接続しましょう。そして、I2C 経由でそれとやり取りするために必要なすべてをゼロから書いてみましょう。オシロスコープがあれば、それで信号を監視しましょう。これがあなたの最初の自作プロジェクトになるかもしれません。
ブロックデザイン
ほとんどの FPGA 設計ツールは、ロジック設計ブロックをグラフィカルインターフェースで接続する機能を提供しています。原理的には、このインターフェースの使用は Verilog でモジュールをインスタンス化 (instantiation) するのとほぼ同じです。グラフィカルに描かれた配線は、Verilog のポート接続のようなものです。ブロックデザインツールはしばしばもう少し多くの機能を提供します。たとえば、GUI で行った接続がユーザーの意図どおりに動くように、小さなロジックを自動的に挿入したりします。
ブロックデザイン方式が最も力を発揮するのは、ブロックのすべて、あるいはほとんどが FPGA ベンダーから(IP ブロックの形で)供給されているときです。とくにプロセッサが関わる場合、ブロックデザインは通常、周辺機能を実装する IP ブロックとプロセッサを接続する自然な方法です。割り込みコントローラ、DMA コントローラ、バスアービタなどです。Ethernet コントローラのような、より「古典的な」周辺機能もあります。
明らかなプロセッサ関連ブロックのほかにも、FPGA でよく実装される幅広い機能を実装する IP ブロックが多数あります。クロックリソースや I/O ピンに隣接するロジックのような FPGA 要素から、単純な演算ユニット、デジタルフィルタ、さらに複雑なロジックに至るまでです。ブロックデザインだけで FPGA 設計全体を作れるようにするのが狙いだったようです。
とはいえ、これらの既成 IP ブロックだけでまともな FPGA プロジェクトを作った人を、私は聞いたことがありません。プロセッサとその周辺機能だけで構成されるプロジェクトは別ですが、プロセッサだけが欲しいなら、なぜ FPGA を使うのでしょうか? はるかに高価で複雑です。
しかし、ブロックデザイン全体は、他のどの Verilog モジュールや IP と同じように、Verilog モジュール内でインスタンス化できますし、通常そうします。したがって、ブロックデザインは通常、より大きな Verilog ベースのプロジェクトの一部になります。この文脈では、プロセッサとその周辺機能だけを含むブロックデザインは理にかなっています。それは大きなプロジェクトの中の 1 つのモジュールにすぎないからです。
では、これは、学ぶべき、あるいは学ばなくてもよいスキルという観点で何を意味するのでしょうか?
最も単純なスキルは、ブロックデザインを作成し、ブロックを追加して接続することです。何をいつクリックするかを教えてくれるチュートリアルはたくさんあります。そうしたチュートリアルはとても簡単に実行して完了できるので、1 つか 2 つ流し見してみてはどうでしょうか。もしそうするなら、プロセス全体で各ステップや各選択肢を理解しようと苦労する必要はありません。ポイントは、ブロックデザインがどう行われるかの感触をつかむことです。詳細に飛び込むのは、それが関連するようになったときにすればいいのです。
次のスキルは、ブロックデザインをプロジェクトに含め、Verilog モジュール内でインスタンス化することです。これもとても簡単で、例もたくさんあります。プロジェクトで任意の IP を使うのと変わりません。Verilog プロジェクトで FIFO IP を使う方法を知っていれば、ブロックデザインでも同じことができると知っているのと同じです。
最も重要なスキルは、Verilog で書いたものをブロックデザインで使えるブロックにすることです。さらに重要なのは、このブロックを Vivado 自身の GUI(あるいは使っている開発スイート)で設定可能にすることです。直接の目的がない限り、このやり方を学ぶことはおすすめしません。ほとんどの FPGA 設計者は、この種のことをする必要がまったくありません。
では結論はどうなるでしょうか? どの GUI ツールでもそうですが、少し遊んでみて、あとはタスクを完了するのに必要なだけを段階的に学んでいきましょう。とくに、ブロックデザインで何でもできると期待しないでください。利用できるブロックのセットを見ると、そうするのが正しい道だと思わされてしまうかもしれませんが。
FPGA 内部のプロセッサを扱う
多くのプロジェクト、とくに独立した電子製品には、その中で何らかのソフトウェアが動いており、したがってプロセッサが関わっています。このプロセッサは、FPGA 内部のブロックであることも、FPGA 外部の別の物理的な部品であることもあります。それぞれの場合で課題はまったく異なります。
まず FPGA 内部のプロセッサのシナリオから始めます。これは「ハードプロセッサ (hard processor)」、たとえば AMD の Zynq ファミリのように、ARM プロセッサがシリコンに組み込まれているものです。「ハードプロセッサ」は、演算ユニット、PLL、ブロックメモリなどと同様、FPGA 内部の他のロジック要素と同じようなものです。ただし、プロセッサブロックは比較的大きく、ピンがたくさんあります。
FPGA が「ハードプロセッサ」を持っていなくても、「ソフトプロセッサ (soft processor)」でソフトウェアを動かせます。たとえば、AMD の Microblaze や Altera の Nios プロセッサです。違いは、プロセッサが FPGA の通常のロジック要素(「ロジックファブリック」)で実装されていることです。この方法はより遅く、より多くのエネルギーを消費し、ロジックリソースを消費しますが、しばしば十分で、コスト効率の良い選択です。
「ハードプロセッサ」も「ソフトプロセッサ」も、原理的には他の IP と同じように FPGA のロジックと接続する、1 つの Verilog モジュールのようなものです。したがって、それらを FPGA の一部と見なし、FPGA 設計者がそれらの責任を負うと考えるのはごく自然です。
ロジック設計でプロセッサをセットアップするのは、通常比較的簡単な作業で、そのための例やテンプレートがたくさんあります。しかし、そこで終わることはほとんどありません。プロセッサは特定の周辺機能を持つ必要があり、これらはプロセッサのメモリ空間の既知のアドレスでソフトウェアから利用できなければなりません。周辺機能はしばしば割り込み要求出力を持ち、それらをプロセッサに正しく接続し、正しく設定する必要があります。
ソフトウェアチームは通常、プロセッサが電源投入時やリセット信号を受けたときに動くソフトウェアを誰か他の人が担当することを期待しています。このソフトウェアは、とりわけプロセッサ自身のハードウェアレジスタに書き込んで、設定どおりに動くようにするルーチンで構成されています。これは聞こえるほど難しくはなく、開発ツールがこの目的のために、より大きなソフトウェアプロジェクトに含める C コードを生成してくれます。しかし、これらのファイルを生成し、FPGA 設計の残りの部分と同期していることを保証するのは誰の責任でしょうか? 小さな開発チームでは、それは FPGA 設計者です。
それで足りなければ、開発する製品に固有のロジックを実装する周辺機能をプロセッサ向けに作成することも求められるかもしれません。このロジック用のドライバを C で書くことは、たいてい大歓迎されます。
では、これは FPGA 設計者になる一環として学び始めるべきものでしょうか? ソフトウェアとハードウェアの交差点で働きたいなら、おそらくはいと言いたいです。すでに C プログラマで、低レベルプログラミングが好きなら、これはあなたに向いているかもしれません。とくに、プロセッサの分厚いユーザーズマニュアルをときどき読むのが苦でなければ。そこに「周辺機能 X を 2 ユニット、周辺機能 Y を 3 ユニット持つにはどうすればいいか?」の答えがあります。
では、どんなテーマを学ぶべきでしょうか。プロセッサがどうやってソフトウェアを動かすか、どうやってメモリにアクセスするか、割り込みがどう動くか、電源投入時にプロセッサがどう始まるかについての基本的な理解を得ることだと言いたいです。プロセッサのアドレスマップを見て、メモリ領域がどのように異なるセグメント(オンチップ RAM、外部 RAM、内部レジスタ、外部バスアクセスセグメントなど)に分割されているかを見て、その全体がどう動くかを理解しましょう。
AMBA プロトコル(AXI3、AXI4、AXI4 Lite など)の原理、とくに VALID / READY ハンドシェイクを理解することもおすすめします。周辺機能を設計することがあるなら、AXI スレーブを実装する必要が生じる可能性が高いです。AXI をネイティブに使わないプロセッサ(たとえば Altera のプロセッサ)を使う場合でも、原理は同じです。
おそらく、プロセッサの電源投入時やリセット時に動くソフトウェアもあなたの担当になるでしょう。ですから、このソフトウェアがどう作られ、プロセッサ自身のハードウェアレジスタとどう関係するかに慣れておくと助けになるかもしれません。また、設計を求められるかもしれない周辺機能にアクセスするためのドライバルーチンを自分で書くほうが簡単です。こうした理由から、C でのプログラミングが得意でないと、あまり先へは進めません。AI にコードを書かせるとしても、そのコードが何をするのかを正確に理解する必要があります。
しかし何より、長いサンプルプロジェクトを一通り流して、プロセッサを設定し、クリック、クリック、クリックして、最後にボード上でとても印象的なことが起きても、そこから学べることは多くないと心得てください。学ぶ価値のあることはすべて誰かがすでにやっており、あなたは最終行にたどり着くまでクリックしながら重要な部分を飛ばしてしまいました。そうしたサンプルプロジェクトに価値があるものがあるとすれば、それは終わった後に起きることです。そのサンプルから何を理解したか? プロジェクトの何を変えられるか? 自分で何を試せるか?
FPGA 外部のプロセッサを扱う
FPGA を含むプロジェクトでは、プロセッサが独立した部品であるか、別の基板の一部であることがよくあります。製品の中心部分として、本格的な PC(通常のデスクトップあるいは産業用の x86 ベースのマザーボード)があることも珍しくありません。こうした環境では、FPGA を周辺機器と見なすのが一般的です。FPGA の目的はプロジェクトごとに異なりますが、通常、プロセッサ(または PC)がプロジェクトの中心と考えられ、FPGA(とその周辺の電子回路)はソフトウェアによって制御・管理される部分と見なされます。
プロセッサが別の物理的な部品であるため、通常はソフトウェアを含めてそれに関するすべてを担当する別のチームがあります。プロセッサに関連する FPGA 設計者の作業は、主にそれとのインターフェースです。プロセッサが FPGA の動作を制御することだけを期待されているなら、通信はコマンドだけ、場合によってはレジスタの読み書きだけで済むかもしれません。この場合、より単純なプロトコル、とくに I2C と SPI がよく使われます。この 2 つは上ですでに扱いました。SPI は、比較的低いデータレートでのデータ交換に選ばれることもあります。
I2C と SPI は、一般に組み込みプロセッサと組み合わせてのみよく使われることに言及しておく価値があります。PC マザーボードが関わる場合、これらのプロトコルはプロジェクト固有の周辺機能と組み合わせて使われることはあまりありません。SMBus はファンの制御や温度の読み取りによく使われますが、こうしたプロトコルを自作の周辺機能と組み合わせて使うことはあまり一般的ではありません。
組み込みプロセッサ(および DSP)では、FPGA とのインターフェースが、そのプロセッサ(または特定ベンダーのプロセッサファミリ)に固有のインターフェースを介して行われることもあります。たとえば、プロセッサがアドレス/データバスインターフェースでアクセスするための多くの物理ピンを FPGA に接続していることがあります。このバスとインターフェースするロジックを実装するには、プロセッサのベンダーが定義した(必ずしも賢く設計されたわけではない)プロトコルを正確に理解する必要があります。満たすべきタイミング要件もあります。ただし、こうした種類のタスクに備える意味はありません。複雑な I/O プロトコルを持つ他の外部部品とインターフェースするのと変わらないからです。
PC やハイエンドの組み込みプロセッサとのインターフェースは、通常 PCIe(PCI Express)インターフェースで行います。これは堅牢でよくサポートされた通信チャネルで、最も単純な設定で 200 MB/s(ペイロードデータ)のデータレートを可能にしますが、上限はありません。PCIe プロトコルの新しいバージョンが定期的に登場し、バージョンごとにデータレートが上がります。実際のデータレートの限界は、多くの場合プロセッサ自身が扱える量です。
PCIe の欠点は、主にコンピュータの周辺チップ向けに意図された複雑なプロトコルであることです。PCIe 向けに何かを実装するなら、コンピュータと接続するロジックの開発に専用の人員を割り当て、ドライバの開発にソフトウェアチームも割り当てていることが暗黙の前提です。Xillybus を使うと、この解決策が両側の複雑さを処理してくれるので、この作業はずっと簡単になります。
では、外部プロセッサのあるシナリオに備えてどんなスキルを学ぶべきでしょうか。まず第一に、C プログラミングが得意だと大いに助かります。プロセッサから FPGA にアクセスするためのドライバルーチンを書けますし、少なくともサンプルコードを提供できます。AI がこのコードを書いてくれますが、そのコードが何をするかを正確に理解していないと、C のバグが FPGA から来たもののように見えてしまうかもしれません。
それ以外に、事前に学ぶことをおすすめするものはあまりありません。必要な技術スキルは、プロセッサと FPGA がどう接続されているかに大きく依存し、それはプロジェクトごとに異なります。
その他のインターフェース規格
いくつかの入手可能な FPGA 開発ボードを見ていくと、特定の部品やコネクタが他のものよりよく載っている傾向があることに気づきます。これは、FPGA プロジェクトでよく使われる技術の指標と解釈できます。それは部分的に事実で、いくつかを取り上げます。
HDMI
HDMI コネクタは FPGA ボードによく載っています。目的は通常、コンピュータモニタに表示するための映像出力を FPGA が生成できるようにすることです。コネクタのワイヤはしばしば FPGA に直接つながっています。FPGA は I/O ブロックの SERDES の助けを借りて、必要な高速信号を生成できるからです。ボードによっては、FPGA と HDMI コネクタの間に別の部品(「ビデオエンコーダ」)があります。
このコネクタの普及は、実際に現実を反映しています。多くの FPGA プロジェクトが何らかの映像処理と出力を伴うのです。FPGA ボードをコンピュータモニタに接続し、その構成で実験しておくと、将来役立つでしょう。とくに、VGA の基本、画面が水平・垂直にどう走査されるか、存在するさまざまな標準表示モードを学びましょう。HDMI コネクタが FPGA に直接つながっているなら、信号を生成するロジックを実装してみてもいいですが、それが努力に見合うかは自信がありません。学ぶのが単純なプロトコルではありませんし、動かなければそういうプロジェクトのデバッグは困難です。配線上のデータレートは非常に高く、コンピュータモニタは FPGA の出力に反応しないとき、何が悪いかを教えてくれません。この目的のための既成 IP ブロック (IP core) があります。それを使い、代わりに映像データの生成に集中することをおすすめします。
ちょっとしたヒントを 1 つ。モニタに RGB ピクセルを送りたいはずです。この場合、HDMI ではなく、DVI プロトコル(VGA と関連があります)に従いましょう。DVI と HDMI の信号は互換です。しかし HDMI は標準的なハイビジョンテレビ向けのより厳格なプロトコルで、表示モードが狭い範囲に限られています。よく使われる表示モードのピクセルは YCbCr 形式で表現され、不要な難しさをもたらします。HDMI コネクタが使われるのは、DVI コネクタとそのケーブルが大きくて扱いにくいからです。しかし、コンピュータモニタへの信号はほとんどの場合 HDMI ではなく DVI 規格に従います。
映像出力プロジェクトを試してみると、FPGA 自身のブロック RAM では 1 フレームの画像を収めるのに足りないことがよくあるとすぐに分かるでしょう。それで次のテーマに移ります。
DDR メモリ
FPGA 自身の RAM は比較的乏しいリソースです。プロジェクトがメガバイトやギガバイトの扱いを必要とするとき、外部メモリが必要です。これは映像を伴うプロジェクトでよくありますが、コプロセッシング/ハードウェアアクセラレーション、ネットワークスイッチングなど他のアプリケーションでも同じです。
群を抜いて最もよく使われる外部 RAM は DDR SDRAM で、コンピュータで使われているものと同じ種類です。だからこそ FPGA 開発ボードにもよく載っており、SODIMM のこともあれば、より多くの場合基板に直接はんだ付けされています。価格が安く帯域幅も優れていますが、コンピュータを念頭に設計されています。したがって、アクセス要求が連続したアドレス範囲の長いバーストであるときに帯域幅効率が良くなります。あまり知られていない事実は、アクセスパターンが規律正しくないときに性能が本当にひどいということです。「ランダムアクセスメモリ」(RAM)と呼ばれているにもかかわらず、他のアクセスパターンでは帯域幅性能が劇的に落ちます。たとえば、一度に 1 つのデータ要素が必要で、そのたびに前回とは無関係なアドレスから取る場合、これらのメモリは極端に性能が悪くなります。
DDR メモリとのインターフェースプロトコルは非常に複雑ですが、FPGA 設計者がそれについて詳しく知る必要はほとんどありません。評判のよい FPGA ベンダーはすべて、自社の FPGA で使える信頼性が高くかなり効率的な DDR メモリコントローラを、無料の IP コア (IP core) として提供しています。したがって、FPGA 設計者は AXI4 または同様のプロトコルを使って、この IP とインターフェースするだけで済みます。
DDR メモリは学ぶ価値のあるテーマでしょうか? さまざまな分野の FPGA プロジェクトでよく使われるので、学ぶ比較的良い理由があると言いたいです。DDR メモリを使い、おそらく映像出力も生成するプロジェクトは良い練習になります。また、メモリのアレイ構造と、データにアクセスする前にローを選択する必要があることを理解するために、DDR メモリのデータシートを一通り読むこともおすすめです。異なる操作(CAS、RAS、リフレッシュなど)間の遅延要件も見て、それらがどう帯域幅効率を低下させうるかを把握する価値があります。これらのメモリについて最も重要なのは、いつ使うべきでないかを知ることです。
SFP+ ケージ
多くの開発ボード、とくにベンダーの公式ボードには SFP+ ケージがあります。この部品は、基板の端にある比較的大きな金属部品なので、視覚的に目立ちます。このコネクタは、FPGA がマルチギガビットトランシーバ (MGT)(AMD の FPGA では GTX、GTH、GTY などと呼ばれます)を持つ場合にのみ存在します。ケージの内部では、コネクタが FPGA の 1 つまたは複数の MGT に直接接続します。
MGT はギガビットレート、通常 1 Gbit/s 以上の双方向通信を可能にする機能ユニットです。これはいくつかのよく知られたプロトコルの縁の下の力持ちです。とくに PCIe、SuperSpeed USB、SATA、ギガビット/10G Ethernet、DisplayPort です。このウェブサイトには MGT についての連載ページ一式があり、MGT 全般を説明するページから始まります。
SFP+ ケージの主な用途は、光ファイバモジュールを挿し込むことです。これにより、光ファイバケーブルで 2 つの FPGA ボードを接続したり、FPGA ボードを同様のインターフェースを持つ別のユニット、たとえば光ファイバネットワークルータに接続したりできます。光ファイバモジュールは通常 FPGA 開発ボードのキットには含まれていませんが、それほど高価ではありません。光ファイバを使わずに 2 つの SFP+ コネクタを直接接続できるケーブルもあります。
SFP+ ケージが FPGA ボードにこれほどよく載っているからといって、すぐに MGT の専門家になるべきだという意味でしょうか? そうは言いません。ボードによく載っているのは、とりわけ基板上の部品が安価で、追加部品や多くの接続を必要としないからです。また、代替案(通常は各 MGT に接続された 4 本の RF ケーブルからなります)に比べて、2 つの FPGA ボードを接続するエレガントな方法でもあります。
そして MGT は扱いやすいものではありません。ある意味ではデジタル無線チャネルに似ています。リンク上にはビットエラーがあり、送信側のクロック周波数は受信側のクロックと正確には同じでないことが多く、受信側はデータチャネルの中でデータフレームの先頭を見つける必要があり、話は尽きません。
そのため、MGT は通信プロトコルを処理する IP ブロックと組み合わせて使われるのが一般的です。とくに、MGT を持つ事実上すべての FPGA には、PCIe プロトコルを実装するハード IP ブロックもあります。コンピュータで使われる他のいくつかのよく知られたプロトコル用の IP コア (IP core) もあります。2 つの FPGA 間の接続には、Xillyp2p がシンプルなインターフェースを提供します。
ですから、MGT はどこにでもありますが、このテーマが最初に学ぶべきものとはかぎりません。
Ethernet
多くの FPGA 開発ボードには Ethernet コネクタがあります。その理由は FPGA の種類によります。
最も説明しやすいのは、FPGA が内部にプロセッサを持つ場合、たとえば AMD の Zynq デバイスです。これらのボードでは、Ethernet コネクタはほとんどの場合、その目的のためのプロセッサ専用ピンに接続されています。これは、組み込みプロセッサを搭載した任意のボードの Ethernet コネクタと同じです。
プロセッサのない FPGA のボードはどうでしょうか。まず第一に、そうした FPGA でも「ソフトプロセッサ」(たとえば MicroBlaze や Nios)を含めることができます。そうしたプロセッサは、他のプロセッサと同じように Ethernet コネクタを有効活用できます。これは必ずしも一般的な使用シナリオではありませんが、FPGA ベンダーは長い間、データセンターで FPGA を使うというアイデアを宣伝しようとしてきました。彼らは FPGA とコンピュータの間に精神的つながりを作りたかったのです。Ethernet コネクタはその一部です。
FPGA にプロセッサがまったくない場合、Ethernet コネクタはコンピュータと通信するのに使えます。TCP/IP がまず思い浮かぶかもしれませんが、このプロトコルはソフトウェアでの実装に合わせて作られています。このプロトコルをロジックで実装するのは複雑で、機能も限られます。プロトコルスタックは ARP 要求にも応答する必要があり、できれば ICMP パケットにも応答する必要があります。
したがって、Ethernet を(プロセッサのない)FPGA ボードをコンピュータに接続するのに使う唯一の実用的な方法は、ブロードキャストパケットを使うことです。FPGA ボードとコンピュータはポイントツーポイントで接続されます。ケーブル上で送信される Ethernet フレームはすべて、ブロードキャスト MAC アドレスを持ちます。これは多くの場合、ブロードキャスト UDP/IP パケットを使うことで実現されます。ですから、これは私たちが通常コンピュータを Ethernet ネットワークに接続する方法とはほど遠いものです。
エレガントでないこと以外に、この解決策には重大な欠点があります。Ethernet プロトコルはパケットの配送を保証しません。Ethernet パケットにビットエラーがあれば、黙って破棄されます。コンピュータのネットワークカードも、まったく理由なくランダムにパケットを破棄することがあります。これは通常の使用では気づかれません。
したがって、データ損失が許されないなら、FPGA は送信するすべてのデータを再送のためにバッファに保持しなければなりません。そうした再送を要求するために、エラー検出機構を備えたプロトコルを適用する必要があります。これを Ethernet 上で正しくやるのは本当に複雑になります。
あるいは、データ損失の可能性を受け入れるかです。もしくは、学生やホビイストのプロジェクトでよくあるように、この可能性は無視されます。システムをテストしたときには起きないからです。プロフェッショナルでないプロジェクトなら、それで十分です。
結論としてはこうです。ボード上で動くプロセッサ、とくに Linux が動くプロセッサがあるなら、Ethernet コネクタをぜひ使いましょう。しかし、それ以上に深く掘り下げることはおすすめしません。
以上でこのシリーズの 4 ページ目を終わります。これでプロフェッショナルスキルの議論も終わりです。次のページはまったく別の方向に進みます。この職業にはどんな性格が好まれるのでしょうか?