（通常の）ソフトウェアでは、gccオプション -Wall を使用してすべての警告を表示する会社で働いていました。次に、それらに対処する必要があります。Verilog または VHDL での重要な FPGA/ASIC デザインでは、多くの場合、多くの警告が表示されます。それらすべてについて心配する必要がありますか？提案する具体的なテクニックはありますか？私のフローは主に FPGA (特にアルテラとザイリンクス) 向けですが、ビルド後にデザインを変更できないため、同じルールが ASIC デザインにも適用されると思います。
2010 年 4 月 29 日更新: 当初は合成と P&R (配置配線) の警告について考えていましたが、シミュレーションの警告も有効です。
これは ASIC の世界 (99% Verilog、1% VHDL) からの私の見解です。
ログ ファイルからすべての警告を削除するように努めています。これは、通常、警告は予測可能な結果が期待できないことを示すツールとして解釈されるためです。
警告を生成できるツールにはさまざまな種類があるため (シミュレーション/デバッガー/リンター/合成/等価性チェックなど)、この説明ではシミュレーター コンパイラーの警告に焦点を当てます。
警告を分析し、2 つの主要なグループに分類します。シミュレーションの結果に影響を与えないと思われるものと、結果に影響を与える可能性のあるものです。まず、ツールのオプションを使用して、できるだけ多くの警告を明示的に有効にします。最初のグループでは、ツールのオプションを使用して、これらの警告メッセージを選択的に無効にします。2 番目のグループでは、Verilog ソース コードを修正して警告を削除し、警告をエラーに昇格させます。これらのカテゴリで後で警告が発生した場合は、シミュレートする前にそれらを修正する必要があります。
上記の方法論の例外は、変更が許可されていない Verilog コードのサードパーティ IP です。
この方法は、RTL シミュレーションではかなりうまく機能しますが、バックアノテートされた SDF を使用してゲート シミュレーションを実行すると、さらに困難になります。文字通り何百万もの警告を分析して排除するのに十分な時間はありません。最善の方法は、スクリプト (Perl) を使用してログ ファイルを解析し、警告を分類することです。
要約すると、私たちは警告を排除するために最善を尽くしますが、そうすることが常に現実的であるとは限りません。
参考までに私がやっていることです。ツールのすべてのログ ファイルを調べます。
マップ、フィット、およびマージのレポートを含むアルテラ Quartus II の場合。また、Design Rule Check (DRC) オプションをオンにして、そのファイルをチェックします。インスタンス化でポートが欠落している、定数幅が正しくないなど、簡単に修正できるメッセージについては、修正します。私が調べている他のもの。意図的に全出力を使用していないため幅の不一致など、コアにあるものについては、.srf ファイルで抑制されるようにマークします。現在または将来、他のメッセージが問題になる可能性があるため、すべての「類似メッセージ」ではなく、特定のメッセージのみを抑制します。
ログファイルに一連の正規表現を適用して、「問題ないとわかっている」行を破棄するスクリプトを作成しました。それは役に立ちますが、正規表現には少し注意する必要があります-jwzはそれらについて何と言いましたか:)
私が考えることができる最も重要な理由は、シミュレーションと合成のミスマッチです。合成ツールは多くの最適化を (当然のことながら) 行いますが、デザインに抜け穴を残すと問題が発生します。合成規格の詳細については、IEEE 1364.1-2002 を参照してください。