01signal.com

FPGA 設計者のための実践的スキル

中文 | 日本語 | 한국어 | Français | Deutsch | Español | English

このページは、プロの FPGA 設計者になるための全 5 ページのシリーズの 3 ページ目です。ここでは、FPGA 設計者になるために必要な最も重要な実践的スキルを概説していきます。それぞれのスキルがなぜ重要かを明らかにするつもりです。Verilog のパートも、当たり前に見えても飛ばさないでください。意外な話がいくつかあるかもしれません。

始める前に、なぜ VHDL ではなく Verilog だけに触れるのかを説明しておきます。それは単純に、Verilog を推奨しているからです。今後支配的な HDL 言語になると思われるからです。これはとりわけ、中国では VHDL がほとんど聞かれないことによります。とはいえ、以下に述べることは VHDL にも当てはまります。

Verilog の 2 つの顔

なぜ Verilog を知っている必要があるのかは、ほとんど説明を要しないでしょう。実際、世の中には Verilog を知っていることイコール FPGA 設計者だと思っている人がたくさんいます。何人かのプロジェクトマネージャは、若手プログラマを Verilog の講座に送り込み、FPGA のチャンピオンになって帰ってこなかったことに失望しました。

ですからまず第一に、Verilog の構文を知っていることは、この言語の使い方を知っていることとはほど遠いです。これはどの言語にも当てはまりますが、Verilog ではその隔たりがはるかに大きいです。第二に、Verilog コードはコンピュータプログラムではないということを理解することが重要です。それはハードウェアを記述するものです。したがって、原理的にはすべてが並行して起きています。これが、多くのソフトウェア開発者、とくにマルチスレッドプログラミングに慣れていない人がつまずくメンタルの転換点です。

プログラミング言語かどうかというイエス・ノーの問いは、実はもう少し複雑です。Verilog は 2 つの異なる目的で使われるからです。ハードウェアのシミュレーションと、FPGA や ASIC のためのロジックの生成(論理合成)です。

シミュレーションの目的は、しばしば Verilog コードを FPGA 内のロジックに論理合成する前に確認することです。そのためにテストベンチを書きます。これは本質的にはコンピュータプログラムで、人為的に刺激信号(stimulus signal)を作り出し、テスト対象のロジックから出てくる出力信号に対して何かを行います。たいていは信号の値をファイルに書き出したり、期待どおりであるかを確認したりします。

Verilog がシミュレーションに使われるとき、実のところそれはプログラミング言語です。ただし、C や Python、JavaScript のようではありません。それでも、コンピュータは私たちが求めたとおりに動きます。シミュレーションを実行すると、テストベンチも論理合成を意図したコードも、構文で定義されたとおりに正確に振る舞います。

そしてここに大きな落とし穴があります。テストしたのと同じ Verilog コードを論理合成に使うと、Verilog はもはやプログラミング言語ではありません。ちょうど HTML がウェブページに何を表示すべきかを記述するのと同じように、ロジックを記述するものです。さらに悪いことに、HTML とは違って、Verilog コードの解釈はかなり曖昧になりえます。

Verilog コードを論理合成するのは一種の魔術であることを理解しておくことが重要です。私たち人間は望む動作を記述し、論理合成ツール (synthesizer) がロジックリソースの助けを借りて、なんとかそれを実装します。ですから、論理合成ツールが認識し、意図したロジックを生成してくれる特定のコーディングパターンで、この動作を定義する必要があります。普通のプログラミングとは違い、書きたいものをただ書けばいいわけではありません。私たちの要求の結果として論理合成ツールが生成するロジック要素を考える必要があります。Verilog コードは、どんなロジックを生成すべきかについての論理合成ツールへのヒントにすぎないのです。

AI 時代なので、これも付け加えておくべきでしょう。Verilog はバイブコーディングではありません。それは形式言語であり、論理合成ツールは、こちらがおだてて思いどおりに動かせる LLM ではありません。論理合成ツールは LLM が登場するずっと前から存在しており、学習済みのニューラルネットワークではなく、厳格な規則に従って私たちのコードを解釈します。

そして何より重要なのは、お粗末な Verilog コードを書くと、ロジックはシミュレーションのようには振る舞わないということです。シミュレータは、私たちが望むとおりに正確に動きます。シミュレータはコードが言っていることを実行するからです。一方で論理合成ツールは、Verilog コードをきちんと書くよう気をつけないと、黙って違う動作をするロジックを生成することがあります。

この点は決定的に重要で、繰り返す価値があります。Verilog がシミュレーションに使われるとき、それは(かなり貧弱なものにせよ)プログラミング言語です。構文を正しく書けさえすれば、シミュレータは望むとおりに正確に動きます。一方、論理合成ツールは、Verilog の構文が完璧に正しくても、シミュレーションとはまったく違うロジックを生成することがあります。運が良ければ、期待したものが得られないかもしれないという警告を論理合成ツールが出してくれます。他の何百もの警告に埋もれていても、それに気づけばの話ですが。さらに運が良ければ、論理合成ツールはエラーで停止します。しかし、あまりにも多くの場合、黙ってバグを作り込んでしまいます。これを避けるには、どんなコーディングパターンが論理合成に適しているかを知り、それ以外を試さないことです。

そしてここで疑問が生じます。では、適切な Verilog はどうやって学ぶのでしょうか?

Verilog の基本スキル

まず最初の一歩は、もちろん構文を学ぶことです。世の中には Verilog の本やチュートリアルがたくさんあります。残念ながら、その多くはあらゆることを一通り扱っていて、それが不要なだけでなく、論理合成ツールが台無しにしてしまうコーディングパターンを使うように誘惑してくることがあります。

私は以下の最小限のテーマ一式をおすすめします。見つけられるどんな情報源からでもこれらを学べば、構文に関するかぎり準備万端です。出会った Verilog コードの中に知らないものがあれば、お気に入りの AI プロンプトでそれが何を意味するか尋ねましょう。それ以上難しいことはありません。では私のお買い物リストです。

ここまでは簡単な部分です。本当の問題は、Verilog コードを正しく書くことで、論理合成ツールに実際に望むロジックを生成させることです。実のところ、世界中のどの論理合成ツールにも、まったく同じロジックを生成させることです。

私は単純な原則に従っています。私自身の黄金律のリストのルール #4 です。ごく一般的なコーディングパターンを使うようにする、というものです。考え方はこうです。もし論理合成ツールが私のコードを誤解釈するなら、他の多くの人のコードでも同じ間違いをするはずです。そしてそんなことは起きません。そうした人たちはみんな、すぐに別の論理合成ツールを選ぶでしょうから。ですから私は自分が書いたコードを見て、「論理合成ツールがこれを台無しにしたら、他に何人が影響を受けるだろうか?」と問いかけます。答えが「大勢」なら、おそらく安全な側にいます。「おそらく」を強調しておきます。

では、そうした他の大勢の人たちは、いったいどうやって Verilog を書いているのでしょうか? 実はこれは難問です。Verilog の大半は企業の内部で書かれ、公開されないからです。しかも、人はそれぞれ違うコーディングスタイルで書きます。さらに悪いことに、インターネット上の例は未熟な人が書いたものであることがよくあります。そのコードが動いたとしても、必ずしも真似すべきものではありません。別の論理合成ツールでは同じコードが台無しになるかもしれません。論理合成の技が限界まで押し上げられているせいかもしれません。OpenCores の Verilog コードは、品質が優秀なものからシミュレーションでしか動かないものまで幅があります。

では、どうやって見分ければいいのでしょうか。私が思いつく最良の提案は、AMD の IP ツールが生成した Verilog コードを読むことです。これらの IP のいくつか、たとえば DDR メモリコントローラは、論理合成可能な Verilog を生成しますし、それは何をしているか分かっている人が書いています。ただし、自動生成された Verilog コードには、無意味で使われていないコードが大量に含まれていることが多いことに注意してください。これはスクリプトが生成するコードの典型です。別のモジュールをインスタンス化するだけのモジュールがあり、そのモジュールがさらに別のモジュールをインスタンス化する、ということがよくあります。このように無限にモジュールを包み込むのは真似すべきことではありません。同じコードを異なる構成で使えるようにするために、階層を必要なだけ構造化しておく手段にすぎません。自動生成された Verilog コードはパラメータも多くなりがちですが、これも必ずしも真似すべきではありません。あなたの目標は、機能の表現の仕方を真似ることなのであって、乱雑な階層構造を真似ることではないことを忘れないでください。

SystemVerilog についてひと言。これはかなり人気がありますが、私自身はこの言語の方言でコードを書いたことがありません。主な理由は、自分の Verilog をできるだけシンプルに保ちたいからです。論理合成ツールを信頼する必要が少なければ少ないほど良いのです。複雑な構造が必要なときは、シンプルな Verilog を生成する Perl のスクリプト (script) を書きます。論理合成ツールには小さじ 1 杯ずつ与えましょう。さもないと、吐き戻されます。

実装のためのツール

このスキルをマスターするとは、ツールを効率的に使って作業し、それらをうまく制御し、警告メッセージを理解し、再現可能なビットストリーム (bitstream) 生成を可能にし、プロジェクトが大きくなるにつれて管理しやすく保つことです。ひと言でいえば、プロジェクトでの自分の作業をコントロールすることです。

作業に使うツールとしては Vivado が好まれます。AMD が市場を支配しているだけでなく、他のベンダー、とくに新興の中国の FPGA ベンダーは、互換性のある方法でツールを設計する傾向があるからです。これらのツールを IDE として使う方法を知っていることに加えて、Verilog コードと IP をビットストリームに変換するプロセスも理解すべきです。それは論理合成から始まり、その後ベンダーに依存するいくつかのステップが続きますが、原理的にはすべて同じことをします。つまり、論理合成ツールの出力を、FPGA にロードできるビットストリームへと徐々に変換していくのです。この一連の実行ステップはブラックボックスではなく、そう扱うべきでもありません。

ツールがどう動くかを理解する主な理由は、エラーや警告に正しく対応するためです。プロジェクトの実装中には大量の警告が出るので、どれが重要でどれが無視できるかを見分けることが大切です。そしてエラーが起きれば、プロセスは失敗し、問題を解決しなければなりません。そうした問題を解決するスキルは、ツールの動作の背後にある理論を理解することと、積み重ねた経験から来ます。

AI に問題の解決方法を尋ねるのがうまくいくこともありますが、多くの場合 AI は無益なデバッグの長い旅へとあなたを連れていきます。しかも、自分なりの判断なしに AI の言うことを聞くと、どうやら問題を解決したように見えて、実際にはエラーメッセージを消しただけで本物の問題を作り出してしまうことがあります。要するに、自分の脳の代わりは存在せず、これからも存在しません。

もう 1 つの重要な点は、各ツールにそれぞれの癖があることです。たとえば、誤解を招くエラーメッセージです。さらに悪いことには、ツールがコードや設定、制約を黙って無視することもあります。こうしたことを学ぶのは経験の問題でしかなく、その経験を得る一部とは、たとえ具体的な関連がなくても、実際にレポートを読んで、これらのメッセージが何を意味するのかを突き止めることです。

これは私がチェックリストとして提案する概念とルーチンの一覧です。これらは論理合成とビットストリームの取得だけに関係します。シミュレーション、検証、デバッグは後回しにします。

サンプルプロジェクトを試せば、最後の項目を除いて、このリストに挙げたことはすべて経験する可能性が高いです。誰かがすでにサンプルプロジェクトを用意してくれている状態でツールを使うのは簡単です。現実のプロジェクトはこんなにきれいに整理されていることはまれで、ツールを正しく動かし、可能な限り最高の結果を得る責任はあなたにあります。仕組みを理解していなければ、行き詰まったり思いどおりに動かなかったりしたときに直すのに苦労します。忘れないでください。すべてを正しくやっても、おかしなことは常に起きます。

ファイルの海

開発ツールはファイルを生成します。しかも大量に。論理合成から最終的なビットストリームに至るまで、ツールが実行する各ステップは、いくつかのファイルを読み込み、その結果を別のファイルとして出力するコンピュータプログラムのようなものです。

さらに難しくしているのは、ツールがしばしばソースファイルのコピーを作り、元のファイルではなくそのコピーに頼るということです。ツールは中間ファイルも生成し、ソースファイルらしきものではなくそれに頼ります。これは覚えておいてください。とくに、ソースを変更しても結果が何も変わらないときにです。

学習の最初の一歩として、1 つ 1 つのファイルが何をしているのか、何のためにあるのかを理解することを優先するべきではないと思います。それらすべてをマスターしようとするのは無意味ですが、どのファイルが「ソース」と見なされるべきで、どれが「生成された」ものかを知ることは重要です。このファイルの海をうまく泳げるほど、頭を水面上に保てる可能性が高くなります。プロジェクト全体を、別の方向に開発する目的で独立したコピーとして作ろうとしたり、別のコンピュータに移そうとしたりした最初のときに、私の言いたいことが分かるでしょう。

最良の方法は、FPGA プロジェクトを定義する最小限のファイル一式を Git リポジトリで維持することです。ときどき他のファイルをすべて削除し、この最小限の一式からプロジェクトを再ビルドします。最小限のファイル一式からプロジェクトをどう立ち上げられるかの例としては、Xillybus のデモバンドル (demo bundle)(Vivado 用と Quartus 用の両方が入手可能)をダウンロードして、そのうちの 1 つを実装してみてください。最初はソースを普通に Vivado にインポートするのではなく、Tcl スクリプトを実行することに注意してください。恐ろしい解決策に聞こえるかもしれませんが、このスクリプトは Tcl をまったく知らなくても簡単に変更できます。

Vivado について知っておく価値のあることの 1 つは、DCP が圧縮ファイルであり、edif 形式のネットリスト、制約、その他の情報を含んでいることです。たとえば、DCP が配置配線以降のステージの結果である場合、ロジック要素の正確な配置が含まれています。これは、プロセス内の特定のステージを完了した時点での設計のスナップショットです。物は試しに、DCP を解凍して中を覗いてみることをおすすめします。

検証とシミュレーション

完璧な世界なら、ロジック設計は最初の試みで動き、修正すべきバグはありません。もちろん、現実はほとんどいつも違います。

Verilog の初心者向け講座では、必ずこう言われます。まず、FPGA 内でロジックとして欲しい Verilog コードを書きます。これを「論理合成用コード」または「論理合成可能なコード」と呼びます。次に、Verilog でテストベンチを書き、それをシミュレーションで使って、論理合成用コードが正しく動くことを確認します。あるいは実際には、どう正しく動かないかを見てバグを直します。テストベンチはシミュレーションの目的だけで書かれる Verilog コードで、論理合成ツールに近づくことは決してありません。

確かに、通常の作業方法は、Verilog モジュールを 1 つ、あるいはいくつか書いてから、それらが正しく動くことを検証するためのテストベンチを書くというものです。これはプロジェクトが大きくなるにつれて繰り返され、最終的にはプロジェクト全体がシミュレーションされることもあります。そのような大規模なシミュレーションには、それぞれ異なる機能を確認するための、いくつかの異なるテストベンチがあることがよくあります。

しかし、すべてのシミュレーションが同じ方法で行われるわけではありません。シミュレーションには主に 3 つのアプローチがあります。

1 つ目のアプローチは、波形を得るためのシミュレーションです。このアプローチでは、テストベンチはシミュレーションしたいモジュールの入力に供給する信号を作るだけです。これにはクロックやリセット、そして実際の物理信号や他のモジュールが生成する信号の振る舞いを模倣するその他の信号が含まれます。シミュレーションが完了したら、GUI インターフェースを使ってテスト対象のロジックが生成した波形を表示し、正しく動いているか、あるいはなぜ動かないかを確認します。この方法は比較的シンプルなロジックに適しています。たとえば映像出力パターンを実装するステートマシンはこの方法でシミュレーションできます。正しい繰り返し出力パターンは、波形を見るだけで簡単に検証できるからです。

2 つ目のアプローチは、入力はファイルから読み込み、出力はファイルに書き出す方法です。ここでは、テストベンチはいくつかの単純な信号を作りますが、重要な信号は代わりにファイルから読み込まれます。テスト対象モジュールからの出力、あるいは選択したいくつかの出力の値が、別のファイルに書き出されます。テストベンチが読み込むファイルと、テストベンチからの期待される出力を含むファイルを生成するコンピュータプログラムやスクリプトを書くことは、非常によくあります。シミュレーションを実行した後、期待される出力とテストベンチが実際に書き出したものとの間で簡単なテキストの差分を取ることができます。もちろんこれには無限のバリエーションがあります。テストベンチが期待される出力と比較してもいいですし、逆にコンピュータソフトウェアがテストベンチの出力を読んで解析してもかまいません。

このシミュレーション方法は、私が「処理ロジック」と呼んだもの、つまり何らかのデータ処理を実装するロジックに特にとても適しています。また、回帰テスト (regression test)、つまりコードのバージョン間で機能的に何も変わっていないことを確認するシミュレーションにも役立ちます。

3 つ目のアプローチは、テストベンチに正しさを自分で確認させ、何か悪いことが起きたらエラーで停止させる方法です。この方法は Verilog で意味のあるテストパターンを書く必要があり、スクリプト言語でやるよりも難しいことがよくあります。一方で、合否表示を行う自己完結型のテストベンチがあると、FPGA プロジェクトは保守しやすくなります。回帰テストスイートを実行する人は、このやり方で満足するでしょう。

以上が 3 つの主要なアプローチです。私は、シミュレーションされるのは人間が書いた Verilog だけであるかのように言ってきましたが、それは正しくありません。

論理合成後のシミュレーション

先にも述べたとおり、論理合成ツールは Verilog コードが記述する動作とは違うロジックを生成することがあります。この問題に対処する 1 つの方法は、論理合成ツールが生成した出力(つまりネットリスト)をシミュレーションすることです。これを論理合成後のシミュレーション (post-synthesis simulation) と呼びます。

論理合成後のシミュレーションを実行するには、開発ツールに論理合成されたコードの Verilog モデルを作らせます。これは、論理合成用に私たちが書いたものと同じポートを持つ巨大な Verilog モジュールです。ただし内部は、ターゲットの FPGA の実際のロジック要素を表す小さなモジュール(シミュレーションプリミティブ (primitive) と呼ばれます)で構成されています。ですから本当に乱雑な Verilog ファイルですが、テストベンチで、私たちが書いた元の Verilog モジュールの代わりにこれを参照できます。

古典的な方法は、人間が書いた Verilog コードに対してシミュレーションを実行し、次に論理合成後のモデルに対して実行して、出力を比較することです。先に述べた 2 番目の方法(ファイルを入力と出力にする方法)が最適です。論理合成後もロジック設計がまったく同じように振る舞うことを期待するからです。もしそうならなければ、それはあなたの Verilog コーディングスタイルへの大きな打撃だと考えてください。実のところ、Verilog を正しく書いていれば、論理合成後のシミュレーションは必要ないはずです。この種のシミュレーションはむしろ ASIC 業界で一般的で、そこでは最終チップにバグが残ることを極度に警戒しています。もう 1 つ注目すべきは、論理合成後のシミュレーションが元のものとまったく同じ出力を出したとしても、それでも論理合成ツールが期待どおりのことをしたことを保証するものではないということです。

配置配線後のシミュレーション (post-place-and-route simulation) もあります。その名が示すとおり、これは FPGA 内部で配置・接続されたとおりのロジック要素をシミュレーションします。FPGA 内部の伝搬遅延 (propagation delay) を考慮に入れますが、ごく限られた形でしかありません。シミュレーションと現実に起きることとの間には、依然として大きな違いがあります。実際の FPGA 内部の遅延は、温度や電源電圧など、多くの物理的要因に依存するからです。これらの遅延はまた、チップのシリコン中の不純物が全体に散らばっているため、ある程度ランダムでもあります。この不純物が物理的特性を変えるため、電気的な遅延が少しずれます。したがって、物理的な FPGA はそれぞれ異なる遅延を持ちますが、規格の範囲内です。シミュレーションを実行すると、各パスには特定の遅延、通常は許される最大の遅延だけが適用されます。設計が配置配線後のシミュレーションで完璧に動いたとしても、それでも実際の物理的な FPGA で動くことを意味するわけではありません。

ですから総じて、シミュレーションにはかなり深刻な限界があります。1 つには、論理合成ツールが受け付けないようなあなたの望みを、シミュレーションは聞き入れてしまいます。そして論理合成後のシミュレーションでも、FPGA 内部の多くの現実の効果をカバーできません。グリッチ、温度・電源電圧・製造公差による物理的なロジック要素のばらつきなどです。シミュレーションは、タイミング違反の結果としてのロジックの振る舞いも再現できません。たとえば、クロックドメイン (clock domain) を安全でない形でまたぐ場合などです。

設計が正しく書かれ、正しく制約されていれば、シミュレーションと現実は同じように振る舞います。そうでなければ、シミュレーションは無価値です。これは覚えておくことが重要です。

もう 1 つの限界は、シミュレーションはごく短い時間の区間しかカバーできないことです。シミュレーションが 100 万クロックサイクル実行されるとしましょう。それには長い時間がかかることがありますが、クロックが 100 MHz で動くとき、これはわずか 10 ms の実時間をカバーするにすぎません。まれな問題やコーナーケースは、たまたまシミュレーションの窓の中に落ちなかったというだけの理由で、簡単に見逃されてしまいます。

シミュレーションについての私の提案

初心者には何をおすすめするでしょうか。シミュレーションの方法を知っていることは必須で、他の Verilog 関連のスキルを学ぶのと並行して学ぶべきものです。とくに、先の 2 番目のシミュレーション方法、ファイルを入力と出力に使う方法に慣れておきましょう。これは本格的な方法だと考えられています。とりわけ、回帰テストで一般的だからです。論理合成後や配置配線後のシミュレーションでも試してみましょう。少なくとも面接のために。

ただし、シミュレーションに依存しすぎてはいけません。シミュレーションでバグを見つけるたびに、自分の手をピシッと叩きましょう。最初の方法(シミュレーションの波形を見る方法)でバグを見つけたなら、もっと強く叩きましょう。究極の目標は、最初の試みで動くコードを書くことです。シミュレーションが捕まえるのは単純なバグであり、数十億クロックサイクルごとに何かおかしなことを引き起こすバグではありません。後者こそ、永遠に追いかけたくないものです。

最後に、私自身についての小さな秘密を 1 つ。私はシミュレーションをほとんど実行しません。Verilog コードを慎重かつ思慮深く書いて、すぐに正しく動くようにします。少なくとも、FPGA 上で直接直せる程度にバグが少なくなるようにします。ただ、他にこういうやり方をしている人を私は知りませんし、一般的なアプローチとしておすすめできるかは自信がありません。

実は、後々のために覚えておいてほしい、上級者向けのボーナス的なヒントを加えたいと思います。人はシミュレーションを実行するとき、しばしばロジックにリセットを追加します。シミュレーションではすべてのレジスタが未知の状態、すなわち "X" から始まるからです。その結果、システム全体が "X" 状態にとどまり、価値あるものは何も出てきません。よくある間違いは、この X をなくすために手っ取り早くいたるところに非同期リセット (asynchronous reset) を入れることです。そして、これが非常に悪い考えかもしれないことを忘れてしまいます。別のページで説明しているとおりです。ですから、はい、X の問題はぜひ解決しましょう。ただし賢くやるのです。同期リセット (synchronous reset) を使うかもしれませんし、論理合成可能なコードに "initial" ブロックを入れるかもしれません。ほとんどの論理合成ツールはこのブロックを実装します。もともとはシミュレーション専用のつもりだったとしてもです。シミュレーションにコードの書き方を支配させないでください。

テストとデバッグ

あれこれやった末に、あなたは自分の設計をテストし、期待どおりに動かない理由を見つけることになります。デバッグは推理小説のようなもので、被害者も探偵も犯人も同じ人物だ、という言葉があります。

そして実のところ、この推理小説には謎を解く唯一最善の方法というものはありません。バグの源に迫るために、毎回正しいアプローチ、ツール、方法を見つけ出す創造性が問われます。なかには毎回同じデバッグ方法に固執する人もいます。問題を結構すぐ見つけられるときもあれば、いつまでもかかることもあります。

特定のプロジェクトのために専用のデバッグツールや方法を一式開発するのは、非常によくあることです。これは大規模なソフトウェアプロジェクトでも起きますが、FPGA 設計ではしばしば避けられません。テストのためのテストベンチを開発するようなものですが、それがハードウェアで起きるのです。

しかし、バグを見つける唯一最適な方法がないとはいえ、よく使われる特定のツールはあります。いくつか挙げておきます。

多くの人がまず使い始めるのを好むツールは、オンチップロジックアナライザです。どの開発スイートを使っているかによって、このツールは ILA、ChipScope、SignalTap などと呼ばれますが、どれも同じことをします。つまり、あなたのコンピュータをロジックアナライザに変えます。このツールを使えば、シミュレーションで波形を見るのと同じように、FPGA 内部で取り込んだ波形を表示できます。どの信号を見るか、そしてこれらの信号の取り込みをトリガする条件を選べます。

コンピュータと FPGA の間の通信は JTAG インターフェースで行われます。これはビットストリームファイルを FPGA に送るのに使うのと同じものです。ですから追加のハードウェアは必要なく、エレクトロニクスが苦手な多くの FPGA 設計者がこの事実をありがたく思っています。FPGA と、すでに存在するその JTAG リンクが、そのままデバッグツールにもなるのです。

この方法はとても便利なので、多くの FPGA 設計者がこれに依存してしまい、状況によってはもっと適しているかもしれない他の方法を忘れてしまいます。

この方法の主な欠点は、JTAG のデータ帯域幅が比較的低いことです。そのため、調査に大量のデータが必要な場合には、ILA などのツールは適していません。また、データが JTAG リンクを通って届くまでに少し時間がかかります。これは、イベントへの即時応答を得て、他の出来事と関連づけたい場合に問題になりえます。

JTAG リンクの限界が問題になるときは、より高速なインターフェースが必要です。FPGA ボードに PCIe インターフェースがあれば、コンピュータとの間で高いデータレートでデータを転送できます。PCIe インターフェースとコンピュータのドライバの実装は、それ自体がプロジェクトになりえますが、Xillybus を使えば、そうしたリンクを素早く簡単に立ち上げられます。Xillybus を使った同様の解決策は、Xillinux で動く Zynq-7000 ボードでも可能です。

高帯域幅の接続は、大量のデータの中に隠れた一点の問題があるときによく必要になります。たとえば画像処理では、その場合、画像が Xillybus を通してコンピュータに転送され、専用のコンピュータプログラムの助けを借りてコンピュータのモニタで表示されます。

オンチップロジックアナライザを選ぶにせよ Xillybus を選ぶにせよ、これらは無菌的なデバッグツールです。ハードウェアには一切触れません。しかし、何が起きているかを突き止めるために、ハードウェアからのそうした単純で即時の応答が必要になることがあります。

ですからまず、最も単純なデバッグツールをおすすめさせてください。LED です。驚くほどよくあるのは、バグを見つける最速の方法が、さまざまな論理条件を定義し、それらが真になったときに LED が点滅するようにすることだというケースです。とくに、決して起きるはずのないことが実際に起きたときに LED を点滅させるのです。LED は多ければ多いほど楽しいです。これは C コードにデバッグ用の "printf" を挿入するのに少し似ています。同じ要領で、デバッグ用の小さな Verilog コードを追加しましょう。ビットストリームを FPGA にロードし、適当な無茶を試してみれば、この LED がバグが何に関係しているかを明らかにしてくれるかもしれません。

この方法を使うときに覚えておくべき重要なことが 1 つあります。条件が満たされたら、それに応じて LED が少なくとも 20 ms は点灯しているようにしてください。そうしないと、人間の目には見えません。

LED 方法のもっと洗練された版は、オシロスコープを使うことです。これが、このシリーズの最初のページでオシロスコープを買って慣れておくよう提案した理由です。考え方は、FPGA 内部からいくつかの信号を、オシロスコープのプローブで届く出力ピンに接続することです。実際のプロジェクトでは、PCB 上に専用のコネクタがあり、基板設計者が FPGA の未使用ピンをたくさんそこに集めて、デバッグに使えるようにしているのは珍しくありません。

オンチップロジックアナライザと比べると、オシロスコープは見劣りするように思えるかもしれません。一度に 2 つの信号、高価なオシロスコープならもう少し多くを監視できます。帯域幅も限られているので、非常に速い信号は見逃すかもしれません。それでも、手元にある最も強力なツールであることもあります。とくに、繰り返し現れる信号パターンがある場合、オシロスコープでそれを見ていると、何がうまくいかないかを捕まえる助けになります。

そして、ごくハードウェアレベルの何が起きているかを理解するのに、オシロスコープが必要になることもあります。電圧は正しいか? デジタル信号はあるべき姿に見えるか? 電圧信号に何かおかしなノイズが乗っていないか?

そしてこれが、最も地に足のついた種類のデバッグへと私を導きます。信じたくないくらい頻繁に、問題は本当にお間抜けなハードウェアの問題です。とくに特定のプロジェクト向けに開発された PCB ではそうです。電源電圧の 1 つが不安定で、ときどき短いスパイクやディップがあるかもしれません。クロック発振器が期待どおりに振る舞わず、不適切なクロック信号を生成しているかもしれません。凝った理論を組み立てる前に、これらを確認するのは常に良い考えです。

ですから、FPGA 設計がうまくなるには、両方が少しずつ必要です。FPGA 内部からデータを取り出す無菌的な方法と、ハードウェアで手を汚すことの両方です。

そして決して忘れないでください。正しく使えさえすれば、本当に効率的なデバッグツールは 1 つだけです。あなた自身の脳です。

プログラミング言語

プログラミングは FPGA 設計に直接関係するわけではありませんが、仕事を片づけるには最小限のプログラミングスキルが必要です。たとえば、先に述べたように、シミュレーション用のテストデータはしばしば専用に書かれたプログラムやスクリプトで作られます。

習得する価値があるかもしれないプログラミング言語をいくつか挙げておきます。私が学ぶことを提案するあらゆることのなかでも、これは実は簡単な部分で、初日からこれらすべてを知っている必要はまったくありません。というか、一生知る必要がないかもしれません。

他にもいくつかの言語、たとえば MATLAB も役に立ちます。とくにシミュレーション用のテストデータを作成するのに便利です。

プログラミング言語を知ることのもう 1 つの側面は、しばしばソフトウェアチームとの共通言語を生み出すことです。これは、何らかの組み込みプロセッサや、コンピュータさえも関わる FPGA プロジェクトに関係します。ですから、自分自身がある程度プログラマであることは、ソフトウェア担当者とのコミュニケーションに役立ちます。また、自分の FPGA 設計と通信する低レベルのプログラムを、仕様書に基づいて誰かに作ってもらうよりも、自分で書くほうが簡単であることもよくあります。

一般的なおすすめとして、Git の使い方を学び、使ってください。たとえ 1 人でプロジェクトを進めていてもです。バージョン管理は管理職を喜ばせるためだけのものではなく、何かを試して、それから元に戻り、そして戻ったことを後悔できる、価値あるツールです。そして、いじくり回すのが終わった後には、その乱れた跡は何も見えません。

私はバージョンツリーをグラフィカルに表示するために gitk を使っています。

以上でこのシリーズの 3 ページ目を終わります。次のページも実践的スキルを扱いますが、最初はそれほど重要でないものです。主なポイントは、それらがいつ、どのように重要になりうるかを説明することです。

このページは英語から機械翻訳されたものです。不明な点があれば、原文を参照してください。
Copyright © 2021-2026. All rights reserved. (852e87d4)