年収700万を稼ぐFPGAエンジニアのための高収入のヒント

高い給与を獲得したい FPGA エンジニアにとって、考慮すべき重要な戦略がいくつかあります。何よりもまず、FPGA の設計と開発のスキルを磨くことが重要です。 Verilog や VHDL などの言語の専門家になり、FPGA 開発ツールやプラットフォームを習得すれば、この分野で貴重な人材となります。

大学時代にFPGAに触れてから74年以上が経ちました。 EDA プラットフォームで初めてデジタル ストップウォッチ、クイズ ブザー、パスワード ロックなどの実験を完了したときの興奮を今でも覚えています。当時、私はまだ HDL ハードウェア記述言語に慣れていなかったので、MAX+plus II 回路図環境で XNUMX シリーズ ロジック デバイスを使用してデザインを構築しました。その後、大学院での研究とその後の仕事中に、Quartus II、Foundation、ISE、Libero を使用し、Verilog HDL 言語も学びました。この学習プロセスを通じて、私は Verilog の賢さを徐々に理解していきました。小さなコードで複雑な回路図設計を完成させることができ、この言語の移植性と操作性は回路図設計よりもはるかに優れていることに気づきました。

FPGA ロジック設計における標準の重要性

業界で働いたことのある友人は、企業が特に大規模な設計 (ソフトウェアまたはハードウェア) について標準を重視していることを知っています。基準に従わずに達成することはほぼ不可能です。ロジック設計も例外ではありません。標準に従っていないと、1 か月後のデバッグ時にエラーが見つかる可能性があります。自分が書いたコードを振り返ると、エラー チェックはおろか、多くのシグナル関数を忘れているかもしれません。プロジェクトの途中で誰かが辞めてしまうと、後任者は設計を一からやり直すことになるでしょう。元のバージョンに新しい機能を追加する必要がある場合、ほとんどの場合最初からやり直す必要があり、デザインの再利用性を実現することが困難になります。

ロジックに関しては、次の基準が重要だと思います。

1. 設計ドキュメント: 設計アイデアや詳細な実装などを文書に記載し、厳密な審査と承認を経て初めて次のステップの作業を実行できます。このアプローチにより、プロジェクトを制御可能かつ達成可能な状態に保つことができます。
2. コードの標準化: 信号の命名を標準化し、信号名には小文字を使用し、パラメータには大文字を使用し、低レベルの有効信号を でマークします。 _n 最後に（例： rst_n)、シミュレーション検証でのエラー検出を容易にするために、ポート信号を 1 行に 1 つの信号で配置します。
3. クロックドメイン管理: 各モジュールに 1 つのクロックのみを使用し、複数のクロック ドメインを含むデザインではクロック ドメイン分離用の専用モジュールを使用して、シンセサイザがより最適な結果を合成できるようにします。
4. ラッチの組み合わせロジックを避ける: FPGA デザインでは、純粋な組み合わせロジックを使用してラッチを生成することは禁止されています。コンフィギュレーション レジスタなど、D フリップフロップを備えたラッチが許可されます。
5. 信号の同期: 一般に、システムの動作周波数を高めるには、FPGA に入力される信号を最初に同期する必要があります。
6. すべての出力を登録する: 動作周波数を高め、設計におけるタイミングの収束を達成するには、すべてのモジュール出力を登録する必要があります。
7. ゲートクロックを避ける: 低電力デザインでない限り、デザインの不安定性が増大するため、ゲート クロックを使用しないでください。
8. クロックイネーブル信号: カウンタで分周した信号を他のモジュールのクロックとして使用することは禁止されています。代わりに、クロック イネーブル信号を使用してください。

高性能のためのタイミング設計

私の上司はファーウェイとジュンロンで働いていた経歴を持っているので、当然のことながら、ファーウェイとアルテラでのロジック設計の実践についていくつか話してくれました。私たちのプロジェクト基準は基本的にファーウェイの慣行に基づいています。過去数か月の仕事の中で、私にとって最も深い印象に残ったのは、ファーウェイの格言でした。「タイミングは設計されたものであり、シミュレーションしたり作り上げたものではない」という言葉です。当社では、すべてのプロジェクトが厳格な審査を受けます。審査に合格した場合のみ、次のステップの作業を実行できます。論理設計を例に挙げると、すぐにコードを書き始めるのではなく、まず全体の設計計画と詳細な論理設計計画を書く必要があります。これらの計画が検討され、実現可能であると判断された後、コーディングを開始できます。一般に、これらのタスクに費やす時間は、コーディングに費やす時間よりもはるかに長くなります。

全体的な計画には、主にモジュール分割、第 1 レベルと第 2 レベルのモジュールのインターフェイス信号とタイミング、および将来の設計のテスト方法が含まれます。このレベルの計画では、タイミングが第 1 レベルのモジュール (そして最終的には第 2 レベルのモジュール) に確実に収束することが重要です。これはどういう意味ですか？詳細設計を行う際には、必ずいくつかの信号のタイミングを調整します。ただし、これらのタイミング調整は、デザイン全体ではなく、せいぜい第 1 レベルのモジュールに影響を与える可能性があります。学生時代、タイミング設計を理解していなかったので、ある信号のタイミングが合わずに他のモジュールの信号のタイミングを調整しなければならないことがよくあり、とてもイライラしたのを覚えています。

詳細な論理設計計画では、各レベルのモジュールのインターフェイスのタイミングがすでに設計されており、各レベルのモジュールがどのように実装されるかは基本的に決まります。これを実現しているので、コーディングも自然と速くなります。最も重要なことは、このアプローチにより、設計を制御可能な状態に保つことができ、1 か所のエラーによって設計全体をやり直す必要がなくなるということです。

回路の動作周波数に影響を与える要因は何ですか?

回路の動作周波数は主にレジスタ間の信号伝播遅延とクロック スキューに関係します。 FPGA のクロックが長いラインに沿って動作する場合、クロック スキューは非常に小さいため無視できます。ここでは、簡単にするために、信号伝播遅延に影響を与える要因のみを考慮します。信号伝播遅延には、レジスタの開閉遅延、配線遅延、および組み合わせロジックによる遅延が含まれます。回路の動作周波数を上げるには、これら 3 つの遅延に取り組み、それらをできるだけ小さくする必要があります。

1. ルーティングを変更して遅延を削減する: クロックや制御信号などの重要な信号のルーティングを指定して、 FPGA 可能な限り少なくします。これにより、ルーティング遅延を効果的に削減できます。
2. 組み合わせロジックの数を減らす: 論理ゲートの代わりに、可能な限りルックアップ テーブル (LUT) を使用します。さらに、ゲートの数を減らすためにカスケード レジスタを使用する人もいますが、最良の方法はパイプラインを使用してゲートの数を減らすことです。

概して、ゲート数を減らし、配線を変更することは、回路の動作周波数を向上させる効果的な方法です。実際の設計では、多くの場合、これら両方が組み合わされます。しかし、これは絶対的なものではありません。場合によっては、配線を変更しても遅延が軽減されないこともあり、その場合はゲート数を減らすことが最も効果的な方法となります。

論理設計の課題: システム アーキテクチャとシミュレーション検証

入社当初、上司から「論理設計の難しさはRTLレベルのコード設計ではなく、システムアーキテクチャ設計とシミュレーション検証にある」と言われました。現在、中国では合成可能な設計がより重視されていますが、システム アーキテクチャの設計やシミュレーション検証に関する情報はあまりないようで、これは中国の設計レベルが比較的低いことを反映している可能性があります。

学生時代は、RTL レベルのコードが適切に実行されていれば、シミュレーション検証は単なる形式的なものだと常に考えていたため、HDL 動作記述の構文を軽蔑的に無視し、テストベンチについて学ぶことに消極的でした。波形を描画するのは便利でした。システム アーキテクチャ設計については何も知りませんでした。会社でいくつかのことに遭遇して初めて、それがまったく違うことに気づきました。

実際、海外では、シミュレーション検証に費やす時間と人員は、RTL レベルのコードに費やす時間と人員の 2 倍と考えられます。現在、シミュレーション検証はミリオンゲートチップを設計するためのクリティカルパスです。

シミュレーション検証: モデリングと自動化

シミュレーション検証の難しさは、主に、設計の正しさを完全かつ正確に検証するためのモデル化方法 (主にコード カバレッジを増やすため) にあります。この際、検証速度も重要です。

検証とは、簡単に言えば、刺激源の十分なカバレッジを生成し、エラーを検出する方法です。個人的には、シミュレーション検証においては、検証の自動化を実現することが最も基本であると考えています。これが、テストベンチを作成する必要がある理由でもあります。私の現在のデザインの 1 つでは、各シミュレーションの実行に約 1 時間かかります (実際には小規模なデザインです)。波形を描画するだけでは検証の自動化は実現できないため、波形を描画してシミュレーションすると、まず波形が死ぬほど描画されます (特に複雑なアルゴリズムと入力統計分布を含む設計の場合)、2 番目に波形を見るのが致命的、3 番目に、エラー検出率はほぼゼロです。では、自動化を実現するにはどうすればよいでしょうか?私のレベルはまだ非常に限られているので、BFM (バス関数モデル) については簡単に話すことしかできません。

MAC コア (バックプレーンは PCI バス) を作成する例を挙げると、MAC_BFM、PCI_BFM、および PCI_BM (PCI 動作モデル) が必要です。 MAC_BFM の主な機能は、ランダムな長さとフレーム ヘッダーを持つイーサネット フレーム (刺激ソース) を生成することであり、内容もランダムです。送信中に、それを PCI_BM にもコピーします。 PCI_BFM の機能は、PCI バスの動作をシミュレートすることです。たとえば、テスト対象のデバイスが正しいフレームを受信すると、PCI バスにリクエストが送信され、PCI_BFM がそれに応答してデータを取り込みます。 PCI_BM の主な機能は、MAC_BFM が送信するものと PCI_BFM が受信するものを比較することです。 MAC_BFM の送信情報と PCI_BFM の受信情報を持っているため、設計が合理的である限り、テスト対象デバイスが正常に動作しているかどうかを常に自動的かつ完全にテストすることができ、自動検出を実現します。

ファーウェイは中国でのシミュレーション検証で比較的好調だと推定されている。彼らは比較的優れた検証プラットフォームを確立しており、通信に関連する BFM のほとんどは適切に行われています。友人から聞いたところによると、現在はテスト対象のデバイスをテスト プラットフォームに配置し、テスト対象のデバイスが正しく機能しているかどうかを自動的に検出するためのパラメータを設定するだけで済みます。

言語に関する考慮事項

HDL 言語に関しては、中国では VHDL と Verilog のどちらが優れているかについて多くの人々が議論しています。実はこれはあまり意味がないと個人的には思っています。外部の大企業のほとんどは基本的に RTL レベルのコードに Verilog を使用しているため、私は今でも皆さんにできるだけ Verilog を学ぶことをお勧めします。シミュレーションに関して言えば、VHDL は動作モデリングにおいて Verilog よりも弱いため、VHDL で行われたシミュレーション モデルはほとんどありません。もちろん、Verilog も完璧ではありません。実際、複雑な動作モデリングにおける Verilog の能力にも限界があります。たとえば、配列はまだサポートされていません。一部の複雑なアルゴリズム設計では、動作モデルを記述するための抽象化に高級言語が必要です。海外ではSystemCやE言語を使ったシミュレーションモデルが多く、Verilogを使うのは時代遅れと言われています。中国のファーウェイの検証プラットフォームはSystemCで書かれているようです。

今後の展望

システムアーキテクチャの設計に関しては、私が取り組んでいる設計が十分な規模ではないため、まだ経験が浅いです。ただ、コンピュータ システム アーキテクチャについてある程度の知識が必要だと感じています。分割の主な基礎は機能であり、その後、適切なバス構造、ストレージ構造、プロセッサ アーキテクチャが選択されます。システムアーキテクチャを分割することで、各機能モジュールが明確になり、実装が容易になるはずです。しばらくして、この部分について少し経験してから、いくつかの洞察を共有すると思いますので、今は誤解を招かないようにします。

パーソナルインサイト

最後に簡単にまとめておきます。すべては、より多くの練習、より多くの思考、より多くの質問に帰着します。練習は完璧を作る。他の人の解決策を何百回も読むよりも、自分で練習する方が良いです。練習の動機は、部分的には興味から、部分的にはプレッシャーから来ます。個人的には後者の方が重要だと思います。要件があるとプレッシャーがかかりやすくなります。つまり、勉強のための勉強ではなく、実際のプロジェクト開発で練習するのが最善です。

練習の過程で、問題の原因をさらに考えて考える必要があります。問題を解いた後、さらに数回「なぜ」と尋ねます。これも経験を積む過程です。プロジェクトのログを書く習慣があれば、さらに良いでしょう。その中にある問題、理由、解決策、解決方法を書き留めます。最後に、さらに質問してください。考えても問題が解決しない場合は、質問してください。結局のところ、個人の能力には限界があります。クラスメート、同僚、検索エンジン、ネットユーザーに聞いてください。記事や友人のアドバイスが問題を迅速に解決するのに役立つかもしれません。

結論

機能シミュレーション後は、FPGA で設計を行っているため、基本的に RTL レベルのコードは設計中の合成結果および機能シミュレーション結果と一致することが保証されます。合成レイアウト後の静的タイミング レポートがタイミング制約に違反することを警告されない限り、ボード上でのデバッグに進むことができます。実際、ファーウェイとZTEでは、FPGAの設計時にタイミングシミュレーションを行っていません。これは、タイミングシミュレーションには時間がかかり、静的タイミング解析レポートを見るより効果が必ずしも優れているとは限らないためです。

もちろん、ASIC設計であればシミュレーション検証の負担は大きくなります。マルチクロック ドメイン設計が関係する場合、通常はポスト シミュレーションが行われます。ただし、ポストシミュレーションを実行する前に、通常は正式な検証ツールが使用され、静的タイミング解析レポートを使用してデザイン要件の違反がないかチェックされます。これを実行すると、シミュレーション後の作業負荷が大幅に軽減されます。

この要件が調達または生産リリースに影響を与える場合は、最終ファイルをレビューに送付する前に、電子部品の調達および表面仕上げの比較と比較してください。