cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

設計手法レポートの使用方法パート 2:設計手法違反の QoR への影響

takayos
Xilinx Employee
Xilinx Employee
3 0 480

このブログ エントリの解析は、別の OS と比較したときに QoR の品質が低下していた実際のお客様の問題に基づいています。ザイリンクスでは、(Xilinx Answer 61599) に記載されているように異なる OS 間の再現性は保証されていませんが、このケースでの違いの大きさはさらに調査する必要があります。

Windows では最初は良い結果が得られましたが、後に Linux の方でより良い結果が得られました。最終的には、この問題はデザインで見つかったスーパー クリティカルな設計手法違反に関連していることがわかりました。

 

問題について

同一のデザインで Linux Windows のタイミングに大きな違いが見られました。

OS で同一のデザインを実行したときに、Linux では WNS = -0.439 nsWindows では WNS = +26 ps でした。

ビルドを複数回異なるマシンで実行しましたが、どの OS でも同じ結果になりました。

次の [Design Timing Summary] のスクリーン ショットは、Linux でデザインを実行した場合のタイミング違反を示しています。Windows で実行したときはタイミング違反は見つかりませんでした。

注記: 次のオプションを使用すると、デザインのタイミング サマリを確認できます。

  • Vivado GUI で [Reports] タブ → [Timing] [Report Timing Summary] をクリックします。
  • 次の Tcl コマンドを実行します。

report_timing_summary -file <filepath>/timingreport.txt

 

Linux で実行した場合:

takayos_0-1608591914243.png

 

Windows で実行した場合:

takayos_1-1608591914260.png

 

根本的な原因の解析:

最初に、すべてのデザイン ソース、制約セット、合成およびインプリメンテーション指示子、および Vivado ツール設定が 2 つの OS 間で同一であることを確認します。また、一方の OSのみで Vivado パッチが使用されていたり、Vivado_Init.tcl ファイルでツール パラメータ-が設定されていないか確認します。

さらに、配置配線後に Tcl コンソールから write_xdc を実行することにより、両方のビルドに同じ制約が適用されていることを確認できます。

クロッキング/アーキテクチャ/CDC などに関連する警告/クリティカル警告を確認するには、設計手法レポートを開きます。

Vivado GUI で設計手法レポートを開くには、[Report] タブ → [Report Methodology] をクリックするか、または Tcl コンソールに「report_methodology」と入力します。

レポートが開くと、デザインに関連するいくつかの警告とクリティカル警告が表示される場合があります。

次に示すように、デザインのクロックの関係性に関する不適切な手法 (TIMING-6 および TIMING-7) が見つかりました。

takayos_2-1608591914283.png

 

Timing-6 クリティカル警告は、Vivado でタイミング解析が一緒に実行される 2 つのクロックが検出されたが、共通のプライマリ クロックがないことを示しています。

これらの 2 つのクロックは、共通のプライマリ クロックから派生しておらず、既知の位相関係がない場合でも、デフォルトでは関連性があり同期しているものとみなされ、タイミング解析が実行されます。この DRC 警告では、タイミング エンジンによりこれらのクロックを同期させることができない可能性があることがレポートされています。

Timing-7 クリティカル警告は、Vivado でタイミング解析が一緒に実行される 2 つのクロックが検出されたが、共通ノードがないことを示しています。この DRC では、2 つのクロック ツリー間の共通ノードが判断できないため、タイミング エンジンによりハードウェアでこれらのクロックを同期させることができない可能性があることがレポートされています。

設計手法のクリティカル警告は、場合によってデザインの QoR に影響する可能性があります。つまり、このようなクリティカル警告がデザインにあると複数回デザインを実行した場合に結果が同じにならない可能性があるということです。スーパー クリティカルとして処理する必要がある設計手法のクリティカル警告は、次のとおりです。

  • TIMING-6
  • TIMING-7
  • TIMING-8
  • TIMING-14
  • TIMING-35

デザインにこれらの違反があると QoR に影響を与える可能性があるため、できるだけ早く違反を解決する必要があります。

TIMING-6 および TIMING-7 - これらの警告およびクリティカル警告の解決方法:

解決方法は、2 つのクロック ドメインが非同期であるか、同期であるかによって異なります。クロックが非同期の場合、2 つのドメイン間のパスにタイミング例外 (set_max_delay -datapath_onlyset_clock_groupsset_false_path など) を使用する必要があります。

デザインを解析した結果、この DRC には set_false_path 制約を使用する必要があることがわかりました。

これらのクロック間のタイミング パスを検索するには、次のコマンドを実行します。

report_timing -from [get_clocks <CLOCK_NAME1>] -to [get_clocks <CLOCK_NAME2>].

TIMING-6、TIMING-7、および report_methodology のその他すべてのクリティカル警告と警告の詳細は、『Vivado Design Suite ユーザー ガイド: デザイン解析およびクロージャ テクニック』 (UG906) を参照してください。

 

解決方法と結論:

TIMING-6 および TIMING-7 違反を修正すると、Windows Linux の両方でデザインが同じ結果になりました。

ザイリンクスでは異なる OS 間での再現性は保証していませんが、上記のいずれかのスーパー クリティカル警告がデザインで見つかった場合は、QoR が低下する可能性があります。このケースでは、これらの違反が原因で、一方の OS が他方の OS よりも悪い結果になりました。