序章
FPGA designer であるためにはさまざまなスキルが必要であり、1 ページにまとめることはできません。しかし、特にこの職業に関連する一般的なガイドラインがいくつかあります。これらを FPGA designの 5 つのゴールデン ルールとしてまとめてみました。
ルール #1: 自分が何をしているかを知る
これは最初のルールであり、従うのが最も難しいルールです。それは、コード、 constraint 、または構成コマンドの各行が何を意味し、どのような意味を持つかを理解することを意味します。 logic designの根底にある理論と、 design tools が私たちに与えるものにどのように反応するかを理解することです。
これは、すべてのハイテク開発ツールのベンダーが、 debuggers、シミュレータ、および「簡単にできる」と宣伝されている多数のツールを提供することによって、暗黙のうちに推奨している試行錯誤による作業とは正反対です。
何かを書き留めてソフトウェアを開発し、 debuggerでテストを実行し、それがどうなるかを確認し、何かを修正して繰り返すことは珍しくありません。断続的に、インターネットの例にあるコード スニペットもソフトウェアにコピー アンド ペーストされる可能性があります。この反復作業の習慣は、スマートフォン用の Web サイトやアプリケーションの開発などの単純なソフトウェアでかなり生産的になります。 小さなバグはそれほど深刻ではなく、発生した時点で修正できるというのが一般的な態度です。
しかし、ソフトウェアが洗練されているほど、この方法はデッドロックにつながる速度が速くなります。そして、 FPGA designに関して言えば、反復的な開発手法は、すぐに、そして激しく後退する傾向があります。 FPGA design ツールは、重大なミスを防止したり、警告したりするのにはまったく役に立ちません。ツールが邪魔になることはありません。
ルール 2: 動作することを保証します
または： 「それはうまくいく」では十分ではありません。
FPGA はコンピューターではなく、電子機器です。それでも、 design の特定の原則に従えば、再現性と信頼性は同じです (ルール 1 を参照)。そうでない場合は、何らかの理由で、または明らかな理由もなく、汚いトリックを実行する可能性があります。
目に見えるバグがないからといって、問題がないということにはなりません。それはどの分野にも当てはまります。たとえば、配管工が作業を終了し、パイプから水漏れがない場合、それは作業が正しく行われたことを意味しません。水圧が上昇したり、誰かが誤ってパイプに触れたりして、後でパイプが漏れ始める可能性があります。
それでも、私たちは皆、簡単なテストやより大規模なテストを行うというわなに陥り、すべてがうまくいっているように見えるときにそれが完了したと考えます。単純な Web サイトや、重要なアプリケーションの一部ではないソフトウェアを開発する場合でも、水道管の水漏れは許容範囲内です。しかし、 FPGAsでは、それだけでは十分ではありません。
FPGA 用に design を開発することは、 design が機能することを保証することを意味します。 design ツールに、この正確な目標を達成するために提供される技術を使用して、フェイルプルーフな bitstream を作成するように強制しています。
「こうなったらこうしよう」という観点で考えようとするのではなく、数学的な証明のように、 logic design が正しいことを自分自身に証明することです。 logic は、これらの可能性が個別に考慮されたからではなく、正しい数式が何があっても成り立つという同じ理由で、最も奇妙なコーナー ケースでも機能するはずです。
それが最終的に機能するという事実は、祝う理由にはなりません。それは、正しく機能することの自然な結果です。
ルール #3: 賢明にシミュレートする (またはまったくシミュレートしない)
FPGA newbies による最も一般的な不満の 1 つは、シミュレーションが完全に機能するため、 design は問題なく、別の場所に問題があるに違いないというものです。もちろん、これはナンセンスです。
何よりもまず、 Verilog コーディング スタイルがいくつかの厳密な規則に従わない限り、シミュレーションとハードウェアはまったく異なることを行うことができるということを表にまとめましょう (もちろん、 VHDLでも同じです)。ルール 1 を参照してください。
しかし、シミュレーションは、たとえ正しく行われたとしても、限られた期間とシナリオしかカバーしません。中型の designでも、 100 msなどで FPGA の内部で何が起こっているかをシミュレートするには、非常に時間がかかります。それだけでなく、 design をハードウェア上で実際に実行すると、 designer が想像もしなかった、したがってシミュレートしなかったシナリオに logic がさらされることがよくあります。したがって、シミュレーションを完全に通過した design は、 FPGA がシミュレーションがカバーするよりもはるかに長く実行されるか、予期しないことが起こったという理由だけで、ハードウェア上で完全に大失敗になる可能性があります。
さらに悪いことに、ハードウェアではすべてが並行して行われるため、バグを見つけるのは困難です。ソフトウェアのデバッグとは異なり、 single-stepを実行するオプションは言うまでもなく、一連のイベントに従うことはめったにありません。もちろん、 FPGA内に信号をトレースするためのツールはありますが、どの信号をトレースするか、およびトレース データを収集するために trigger としてどのような条件を使用するかを判断することは必ずしも容易ではありません。
したがって、シミュレーションをできるだけ使用しないことを目標にしてください。 「動作させる」ためにシミュレーションを使用して design を前後に修正している場合、ハードウェアで試したときに問題が発生する可能性があります。
むしろ、最初の実行から完全に動作するように FPGA design を作成してみてください。これには、コードの最初の行を書く前に、何をしているのかを知るだけでなく、熟考する必要があります (上記のルール #1)。シミュレーションは、それが正しいことを確認するか、ばかげたタイプミスを検出する必要があります。この目標を達成するには、学習と改善のプロセスが必要ですが、それは報われます。結局、修正するものが見つからないため、シミュレーションは時間の無駄になります。
これは時間の節約になるだけでなく、ハードウェアで修正するバグが少なくなり、見つけやすくなります。
FPGA design の一般的な最初のレッスンが「最初にシミュレートし、次にハードウェアで実行する」であることは十分承知していますが、それは最初のレッスンに適しています。
ルール #4: Don't push your luck
または： 確立されたコーディング スタイルに固執します。
Verilog は、 synthesisに使用される場合、プログラミング言語ではありません。主な違いは、どのプログラミング言語でも構文的に正しいものを記述した場合、 compiler (または interpreter) は構文が意味することを正確に実行することが保証されていることです。または、最悪の場合、エラーを報告してください。
一方、Synthesizersは、 logic elementsの限られたセットに基づいた logic を生成します。したがって、信頼性の低い logicになるコードや、 FPGAでは実装できないコードを Verilog で書くのは非常に簡単です。さらに悪いことに、 FPGAで Verilog コードを logic として実装する方法がない場合、 synthesizers は異なる動作をする logic を生成することがよくあります。多くの場合、 synthesizer は warningを放出せずにこれを行います。つまり、 FPGA 上の logic は、予想される (つまり、シミュレートされた) 動作とは異なる動作を行いますが、これは warningがない場合に発生します。
さらに悪いことに、 synthesizers のバグは compilersよりもはるかに一般的です。創造的なコーディング スタイルは、そのようなバグを明らかにする可能性があります。
もちろん、上記のすべてが VHDL にも当てはまります。
したがって、この種の問題を回避する唯一の方法は、他の人が広く使用しているコーディング スタイルを採用することです。心に留めておくべき質問は、「このコード スニペットで synthesizer が混乱した場合、私を除いて何人が怒るでしょうか?」ということです。答えが「たくさんの人」なら、あなたは安全です。
確立されたコーディング スタイルに固執することには、別の利点があります。 Portability.好むと好まざるとにかかわらず、今日は 1 つの synthesizerで作業していて、明日にはまったく別の FPGA と別の開発ツールを使用していることに気付くでしょう。
確立されたコーディング スタイルがどのようなものかを理解するには、ツールの組み込み IPsに代わってツールによって生成される Verilog コードを見てください。コードの作成者によって多少の違いはありますが、一部のコーディング パターンは他よりも多く見られます。それらは真似するものです。
言うまでもなく、 RTL paradigmに従って動作します。これは単に確立されたコーディング スタイルではなく、 FPGA ツールが期待するものです。
Verilog に関する教科書やチュートリアルは、通常、包括的であるように努めているため、誤解を招く可能性があります。したがって、構文的には正しいものの多くの可能性をカバーすることがよくありますが、めったに使用されず、 synthesisには不適切でさえあります。
ルール #5: タイミングが全てだ
Logic design はソフトウェア プログラミングではありません。 Verilog ワイヤと registersで正しい値を取得するだけでは十分ではありませんが、適切なタイミングで適切な場所に表示されることも同様に重要です。また、 clocks が正しく処理されていること。
主なトピックは次のとおりです。
- データが pipelinesのさまざまな段階をいつどのように流れるか、特に pipelines が (完全または部分的に) 停止する可能性がある場合について考えてください。実際、同じことがどのデータフローにも当てはまります。
- timing constraints が正しいことを確認します。特に、外部コンポーネントの datasheets を読み取り、計算を行います。このページでは、 timingのチェックについて説明します。
- clocksに注意してください。 使用した瞬間から安定していますか?彼らの jitter は目的に対して十分に低いですか?
- Clock domains crossing: resynchronization logicは必要ですか？もしそうなら、ある domain から別の domain への信号のフェイルプルーフ伝送を保証しますか?詳細はこちら。
要するに、コンピューター プログラムとは異なり、 logic design は何が起こるかだけでなく、それがいつ起こるかについても考慮します。
概要
FPGA design が簡単だとは誰も言っていませんし、これら 5 つのルールのどれも従うのが簡単ではありません。それらのそれぞれは、知識と自己規律のレベルの両方を必要とします.それでも、これらのルールを守るために努力する価値は間違いなくあります。そうすることで、特にプロジェクトの最終段階で、すべてがうまく機能することが期待されるときに、多くのフラストレーションを軽減できます。