Verilog または VHDL デザイン内のすべての警告を削除する必要がありますか?なぜ、あるいはなぜそうではないのでしょうか？

Question

(通常の) ソフトウェアでは、すべての警告を表示するために gcc オプション -Wall が使用されている会社で働いていました。その後、それらに対処する必要があります。Verilog または VHDL での重要な FPGA/ASIC デザインでは、多くの警告が表示されることがよくあります。それらすべてについて心配する必要がありますか？具体的に提案できるテクニックはありますか？私のフローは主に FPGA (特に Altera と Xilinx) を対象としていますが、同じルールが ASIC 設計にも適用されると思います。おそらく、構築後に設計を変更できないため、さらにそうでしょう。

2010 年 4 月 29 日の更新:当初は合成と P&R (配置配線) の警告を考えていましたが、シミュレーションの警告も有効です。

Answer 1

これは、ASIC の世界 (99% Verilog、1% VHDL) から見た私の見解です。

私たちは、ログ ファイルからすべての警告を削除するよう努めています。これは、一般に、警告を、予測可能な結果を​​期待してはならないことを知らせるツールとして解釈するためです。

警告を生成できるツールには多くの種類があるため (シミュレーション/デバッガー/リンター/合成/等価性チェックなど)、ここでは以下に焦点を当てて説明します。 シミュレータコンパイラ 警告。

警告を分析し、次の 2 つの主要なグループに分類します。シミュレーションの結果に影響を与えないと当社が判断するものと、結果に影響を与える可能性のあるものがあります。まず、ツールのオプションを使用して、できるだけ多くの警告を明示的に有効にします。最初のグループでは、ツールのオプションを使用して、これらの警告メッセージを選択的に無効にします。2 番目のグループでは、Verilog ソース コードを修正して警告を削除し、警告をエラーに昇格させます。これらのカテゴリに後で警告が導入された場合は、シミュレーションが許可される前にそれらを修正する必要があります。

上記の方法論の例外はサードパーティ IP であり、その Verilog コードを変更することは許可されていません。

この方法は RTL シミュレーションではかなりうまく機能しますが、バックアノテーション付き SDF を使用してゲート シミュレーションを実行すると、さらに困難になります。文字通り何百万もの警告を分析して排除するのに十分な時間がありません。私たちができる最善のことは、スクリプト (Perl) を使用してログ ファイルを解析し、警告を分類することです。

要約すると、警告を排除するために最善を尽くしていますが、それが常に現実的であるとは限りません。

Answer 2

参照のために、これが私がしていることです。ツールからすべてのログファイルを検査します。

マップ、フィット、マージレポートを含むAltera Quartus IIの場合。また、設計ルールチェック（DRC）オプションをオンにして、そのファイルを確認します。簡単に修正しやすいメッセージの場合、たとえばインスタンス化または誤った一定の幅からポートが欠落している場合、それらを修正します。私が調べる他のもの。コアにあるものについては、例えば幅の不一致など、完全な出力を使用していないため、.srfファイルで抑制されるようにマークします。私は特定のメッセージのみを抑制します。これは、「同様のメッセージ」のすべてではなく、現在または将来、他のメッセージが存在する可能性があるためです。

Answer 3

logfileにregexpsのセットを適用するスクリプトを書き、「問題ない」というラインを捨てました。それは役立ちますが、あなたは正規表現に少し注意する必要があります - JWZはそれらについて何と言ったのですか:)

Answer 4

私が考えることができる最も重要な理由は、シミュレーション合成の不一致です。合成ツールは、多くの最適化を行います（正しくすべきではありません）。デザインに抜け穴を残すと、トラブルを求めています。合成基準の詳細については、IEEE 1364.1-2002を参照してください。

Answer 5

すべての警告を削除する必要はありませんが、すべてレビューする必要があります。これを大きなデザインに可能にするために、いくつかの警告をそのタイプまたはIDによって抑制することができます。

たとえば、一部の合成ツールは、Verilogの場合に警告を発します parameter モジュールインスタンス化中に定義されており、値は割り当てられていません。私にとって、この警告は使用するアドバイスにすぎません localparam. 。 IDで抑制することをお勧めします（例：Lint-01）。

場合によっては、警告を見て、それらを抑制しないでください。たとえば、私のツールは、制約によって仮想クロックを定義するたびに警告を発します。警告は問題があるという意味ではありませんが、私は行方不明をキャッチすることができます source 仮想になることを意図していなかった時計の。

警告の存在の存在が問題を指摘することがあります。たとえば、アプリケーション変数を変更した場合、警告があるはずです。

ケースが多すぎます。警告が避けられない場合があります。いくつかの重要なことを確認できるように警告があるといい時々。デザイナーが自分の仕事を知っている場合、問題はありません。

Answer 6

いくつかの警告が予想されており、警告が発生しない場合は問題があります。

たとえば、本当にラッチが欲しいのに、ラッチを推測することについて警告がない場合、あなたの合成はあなたが意図したものを作っていなかったかもしれません。

いいえ、すべての警告に常に「対処」したいとは限りません。