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

Vivado での report_qor_suggestions コマンドを使用した QoR (結果の品質) の改善

Xilinx Employee
Xilinx Employee
4 0 581

概要

FPGA デザインでパフォーマンス ターゲットを満たすのに苦労することがよくあります。さまざまな理由がありますが、次のようなものが挙げられます。

  • UltraFast 設計手法に従っていない
  • タイミング制約が正しく設定されていない
  • リソースを使い過ぎている
  • 制御セットが多すぎる
  • クロッキングが最適ではない
  • ターゲット パフォーマンスに対してロジック段数が多すぎる
  • フロアプランが誤っている
  • 配線が密集している
  • 制約が原因でツールによる最適化が制限されている

このような問題を検出して最小限のエフォートで修正できる方法はありますか。

QoR (結果の品質) 推奨項目レポート (RQS)

QoR 推奨項目レポート (RQS) では、デザインの問題を検出して、ツールのオプションやセルでのツールの動作に影響するプロパティをソリューションとして提供したり、ソリューションを自動化できない箇所でのテキスト変更を推奨します。

Vivado 2019.1 では、RQS で推奨項目が出力されるようになりました。これにより、推奨項目を監視して、これらのインプリメンテーションを自動化し、各推奨項目の検証を向上し、さらに複雑な推奨項目を出力できるようになります。ここでは、このフローでの新しいコマンドとフローの調整について見ていきます。

1.png

 

  1. report_qor_suggestions コマンドを実行すると、新しい推奨項目が生成され、既存の推奨項目がレポートされます。次の図に示すように、このコマンドはインプリメンテーション プロセスのどの段階の後でも実行できます。
  2. 推奨項目のレビュー後に write_qor_suggestions コマンドを使用すると、選択した推奨項目を含む RQS ファイルを書き出すことができます。推奨項目は、このプロセスの間自動的に ENABLED (表示される推奨項目のプロパティ) になっています。
  3. 次に RQS ファイルは、通常 synth_design コマンドおよび opt_design コマンドを実行する前に推奨項目 run に読み込まれます。このフローでは、APPLICABLE_FOR フロー段階を通過した後に AUTOMATIC 推奨項目が適用されます。

AUTOMATIC 推奨項目が APPLIED (適用) されるには、APPLICABLE_FOR 段階が推奨項目 run に呼び出されるときに ENABLED になっている必要があります。次の図に 1 つの推奨項目が APPLICABLE_FOR 段階を通過するときにどう処理されるかを示します。

2.png

推奨項目 run では、report_qor_suggestions コマンドを再度実行できます。このプロセス全体を繰り返すことが可能で、1 つ前の run の推奨項目と現在の run の推奨項目を 1 つのファイルにまとめ、最新の推奨 run に入力できます。

推奨項目の一部が不要の場合は、次のコマンドを使用して推奨項目の書き出しを制限できます。

write_qor_suggestions -of_objects [get_qor_suggestions -filter {some_fillter}]

フロー中に report_qor_suggestions コマンドを複数実行すると、同じ推奨項目がフローの異なる段階で生成されることがありますが、RQS で重複した推奨項目が自動的に管理されます。

それでも、重複した推奨項目が表示される可能性はあります。たとえば、合成を実行したときや opt_design の推奨項目を実行すると、同じ結果になる可能性があります。このような場合は RQS 1 つの推奨項目のみが APPLIED (適用) されます。このとき合成の推奨項目が優先されます。

また、チェックポイントが書き出されるときは、推奨項目の現在の状態がチェックポイントに保存されます。このため、推奨項目を読み込んだ後にチェックポイントを書き出した場合は、このチェックポイントを開き直したときに推奨項目を再び読み込む必要がありません。

ケース スタディ例

例を 1 つ挙げて推奨項目がどう適用されるか見てみましょう。

次に、この特定のサンプル デザインで place_design コマンドを実行した後に表示される可能性のある推奨項目のリストを示します。

3.png

 

推奨名

まず、リストの名前に注目してみましょう。最初の推奨項目には「RQS_XDC-1-1」という名前が付いています。[Name] を見ると、推奨項目のカテゴリーがわかります。XDC には、合計 6 つのカテゴリーがあります。

  • Utilization (使用率)
  • XDC
  • Clocking (クロッキング)
  • Congestion (密集)
  • Timing (タイミング)
  • Strategy (ストラテジ)

大まかではありますが、次の図に示すように、使用率、XDC、およびクロッキングに影響する推奨項目は、デザイン サイクル早期で解決する必要があります。

4.png

 

これらの推奨項目は通常多数のパスに影響し、後のデザイン クロージャ プロセスで発生する密集およびタイミング上の問題の深刻さを低減します。クロッキング、使用率、および XDC の推奨項目と同時にアプリケーションのタイミングと密集の推奨項目を解決しようとすること自体には問題はありませんが、その場合は使用率を増やしてしまう可能性があります。

この理由からクロッキングおよび XDC の問題の解決前にタイミングおよび密集での問題を解決しようとすることは通常は推奨しません。これは、ザイリンクス UltraFast 設計手法での推奨事項に沿っています。

タイミングおよび密集での問題は、通常、特定のモジュールまたは特定のタイミング パスに集中する傾向にあります。

  • 密集は配置後にのみ発生し、配線後に精度が改善します。
  • タイミングの推奨項目は、通常、RQS でタイミング違反が発生しているパスのみでレポートされます。RQS ではデフォルトでクロック グループごとに 100 個のクロック パスが確認されます。タイミング エラーがあっても、これらのパスで発生してない場合は、RQS で推奨項目が表示されません。パス数を増やすには、次のコマンドを実行します。

 report_qor_suggestions -max_paths <value more than 100>

ストラテジ推奨項目については、今後のブログにて説明します。

自動推奨項目

次に、表の一番下の推奨項目 RQS_CLOCK-1-1 を見てみましょう。この推奨項目は、ツールにより AUTOMATIC (自動的) に実行されます。この推奨項目により BUFG で駆動されているネットに CLOCK_DELAY_GROUP プロパティが適用されます。

最後から 2 番目の推奨項目 RQS_CLOCK-2-1 は手動 (AUTOMATIC = 0) でユーザーが実行するものです。この推奨項目では、BUFGCE_DIV BUFGCE および MMCM 分周器をビルトイン分周器に置き換えてクロッキング トポロジを最適にするように提案しています。Vivado ではこれらのバッファーの置き換えを自動で実行する機能がないため、RTL での変更が必要です。

エフォートは、AUTOMATIC 推奨項目では低く、マニュアルでは高くなります。次に、自動と手動の推奨項目それぞれに必要なアプローチを示します。

  • 自動
    • オブジェクトにプロパティを適用
    • オプションをコマンドに追加
    • 制約を若干変更
  • 手動
    • RTL デザインの変更が必要
    • 制約のアップデートが必要
    • ユーザー解析が必要

推奨項目のうち 80% 弱が自動です。手動推奨項目ではエフォートが必要なため、一部のクロッキングおよび使用率の手動推奨項目を実行せずに、密集の自動推奨項目を実行しても問題にならないかもしれません。ただし、これらの問題を最初に解決したときのみ最大の QoR が得られます。

QoR ゲイン

次に、次の条件を使用した 30 個のデザインの結果を示します。

  • place_design コマンドの Explore 指示子を使用
  • 推奨項目なしの基準 run と同じフローでの推奨項目 run の比較
    • place_design コマンド実行時にクロッキング推奨項目を生成
    • route_design コマンド実行時にその他の推奨項目を生成
    • 自動推奨項目のみの比較

QoR ゲインは次の 2 つの方法で計測できます。

  • WNS での絶対改善を確認する (メトリクスを確認する簡単な方法)
  • 基準 run でエラーが発生していたクロックすべてでの平均的ゲイン (より確実な QoR ゲイン計測)

次の例は、先ほど確認した表の元になるデザインです。

5.png

 

青色は基準 run、オレンジ色は推奨 run WNS を示します。RQS でデザインの WNS が大幅に改善されることがわかります。30 個のデザインでの平均的な WNS ゲインは 0.648 ns です。

6.png

 

このグラフでは、計測値がはっきりと示されています。タイミングが満たされないクロックすべてに対する平均的な改善率が示されています。この方法では、1 つの信号に大きなエラーあるが、複数のクロックでタイミングが満たされないような場合に数値を平準化します。

これらのデザインでの平均的ゲインは 12.1% です。

また、ゲインが顕著なものがあります。上位 4 つのデザインでは、QoR の向上が平均 34.7% ありました。

ゲインをプロファイルすると、次がわかります。

  • 少数のパスに大きな影響がある特定の問題があるときに 20+% QoR ゲインが見られる。これは、簡単に解決できます。
  • クロッキングの問題を解決すると 10+% QoR ゲインが見られる。
  • 通常デザイン クロージャ段階の最後に個々のタイミング パスの問題を解決すると、多少の QoR ゲインが見られる。

簡単に解決可能な問題が既に解決されている場合は、通常ゲインが見られるのが困難です。このプロファイルから、RQS デザイン サイクル全体に影響があり、デザインで大きな変更を加えた場合には実行するべきであることがわかります。

手動推奨項目により手動で変更を加えた場合に得た QoR ゲインを計測するのは困難ですが、その場合は、上記の数値をさらに上回る可能性があります。

次のステップ

RQS を開始する場合は、チュートリアルから始めるのが最適です。

https://japan.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug938-vivado-design-analysis-closure-tutorial.pdf

また、QoR の向上に関するブログを参照してください。次に 'report_qor_assessment' に関するブログ記事をリリース予定です。