DSO.ai
もっと詳しく知る →
RTL Architect：かつてない精度でRTLの並列検討を実現
搁罢尝の品质が向上
米国シノプシス
シニア?プロダクト?マーケティング?マネージャー Jim Schultz
「シフト?レフト」革命
シノプシスのRTL Architectは、フィジカル设计を考慮したRTL解析?検討?最適化を可能にした业界初の環境で、その登場は设计者に新たな創造性への扉を開きました。このツールは、インプリメンテーションおよびサインオフ?エンジンを活用することにより、デジタル设计サイクルの最初期の段階で消費電力、性能、面積（PPA）の最適化を可能にするという意欲的な目標の下に開発されています。チップが複雑さを増し、先端ノードにおけるルールの制約が大きくなる中、インプリメンテーション?ツールによるラストマイルの最適化だけでは、PPAの目標を達成してノードの実効性を確実にするのが困難になっています。RTL Architectは、RTLがインプリメンテーションに与える影響を设计者自身で予測することで「シフト?レフト」を可能にします（図1）。
図1：搁罢尝インプリメンテーションのフィードバックに関する
従来のアプローチとシフト?レフトのアプローチ
RTL设计者、SoCインテグレーター、IP開発者は、デザインに対する新しい洞察を得るためにこの高速な予測テクノロジを積極的に導入しており、PPAの改善、ターンアラウンド?タイム（TAT）の短縮、デザイン/IPインプリメンテーション?ハンドオフの精度向上を革新的な方法で達成する先駆けとなっています。
検讨回数の爆発的増大
1つ問題になるのは、いくつもの種類のデザイン?パラメータを、いかに体系的かつ効率良く検討するかという点です。伝統的なRTL设计では、1つの変更を行うたびに信号の波形をチェックして目的の機能が達成できているかを検証していました。また、PPAを最適化するには、まずRTLを合成してフィジカル?インプリメンテーションを実行し、最後にRTL设计者がフィジカル?デザイン（PD）から得られたタイミング、混雑度、および消費電力レポートと元のRTLを相互参照するという手間がかかります。このため、RTLの段階でPPAを最適化しようとする試みはこれまでほとんど行われてきませんでした。このようなプロセスのオーバーヘッド、および高品質なPDフィードバック機能の欠如により、RTL段階でのPPAを考慮した设计には潜在的に大きな利点があるにもかかわらず、現実性の低い作業となっています。この結果、チームの半分しか（バックエンド?チームしか）PPAの最適化に取り組めてないのが現状です。
あるRTL IP设计者から、このプロセスに対する不満を聞いたことがあります。彼らはロジックを十分に理解しており、どのようにすれば性能を最適化できるかも熟知していますが、どこに着目すれば良いのかが分かりません。PDチームが忙しい場合、IPを組み込んでからフィードバックを返すまでに2週間ほどかかることもあります。それから変更を加えようとしても検証フローへの影響が大きすぎ、結局そのフィードバックは使い物にならないということもしばしばです。このため、RTL设计者自身がPPAの問題を確実に予測する方法、そしてPDにハンドオフする前にRTLをチューニングできる体系的なアプローチが求められています。
RTL Architectは、フローのオーバーヘッドおよびフィードバックの品質という2つの問題を解決します。これにより、RTL设计者はPPAを考慮したデザイン候補の検討が容易になり、チーム全体が（フロンエンド?チームとバックエンド?チームの両方が）PPAの最適化に取り組むことができるようになります。さまざまな種類の検討候補のセットアップ、追跡、および解析には長い時間がかかりますが、RTL Architectには幅広いパラメータを検討して、その結果を簡単に比较できる独自の機能が備わっています。以下のセクションでは、RTL Architectがこの問題をどのように解決するのか、そしてRTL Architectで実行できる最も一般的なデザイン検討のいくつかについてご説明します。
並列RTL検討（PRE：Parallel RTL Exploration）
RTL Architectには、複数のデザイン検討候補の効率的なセットアップ、开始、比较を可能にするインフラストラクチャが用意されています（図2）。
図2：笔搁贰の手顺
セットアップ
セットアップ機能を使用すると、ユーザーがスイープ?パラメータと対応する値の範囲を定義するだけで大規模な候補マトリクスを簡単に定義できます。例えば使用率の範囲を{0.5, 0.7, 0.8}、アスペクト比の範囲を{1:2 1:1 2:1}としてスイープを実行すると、9個のジョブが生成されます。スイープ?パラメータの数を増やすと、ジョブ数は掛け算式に増えていきます。検討の不要な組み合わせを除外するオプションもあります。このセットアップ機能では、ホスト数、最大プロセス数、最大コア数などを設定して分散処理環境も管理できます。
ジョブの実行开始前にサマリと详细レポートでジョブの内容を确认できるため、不必要なジョブの実行に无駄なコンピューティング?リソースを费やすのを防ぐことができます。
开始
各ジョブには、それぞれのスイープ?パラメータに基づいて自動的に名前が付けられ、それぞれに対応する個別のディレクトリに保存されるため、実行結果の管理と比较も容易です。各ジョブの実行ステータスおよびシステム?リソース使用量は、ジョブ?モニター機能で追跡できます。この機能は、Fusion Design Platformの全ツールに共通の強力なジョブ実行プラットフォーム上で動作します。したがって、ホスト優先順やリソース仕様に加え、マシンのメモリー不足でジョブが異常終了した場合のジョブ再実行も容易です。
比较
デザイン検討の最大の課題の1つは、生成されるジョブの数が数十に達し、関連するデータ量も膨大なものになることにあります。これほど大量のデータを精査して重要な結果だけをふるい分けるのは骨の折れる作業です。RTL Architectには、自動でデータを分析して2種類のサマリ?レポートを生成する機能があります。
1つは各ジョブのExplore Design Summaryレポートで、ここにはタイミング、インスタンス数、面積、消費電力、混雑度のカテゴリごとにすべての主要なPPAメトリクスが表示されます（図3）。また、各ジョブのフロアプランのスナップショットも表示されます。ジョブ名のリンクをクリックすると、そのジョブの詳細なレポートが表示され、実行結果を詳しく調べることができます。
図3：Explore Design Summaryレポート
もう1つは各ジョブの実行結果の主要なPPA指標を評価したレポートで（図4）、これによってQoRの比较が簡単に行えます。この表でいずれか1つのジョブ実行結果をリファレンスとして指定すると、そのジョブがゴールドで表示されます。その他のジョブは、リファレンスより悪いPPA指標が赤で表示され、リファレンスより良好なPPA指標が緑で表示されます。このように並べて比较することにより、设计者は消費電力、性能、面積の目標を満たすようなパラメータをひと目で選ぶことができます。「QoR Summary」での全体的な比较だけでなく、左側のメニューで特定の指標（「Power Summary」など）をクリックすると、カテゴリ別のQoR比较レポートも見ることができます。
図4：QoR比较レポート
自动フロアプランの利点
PREの重要な要素の1つに、自動フロアプラン作成機能があります。これにより、设计者は複数のwhat-if検討を並列に実行する際、1つ1つの検討に対してフロアプランを作成する必要がなくなります。そのフロアプランが最終的なフィジカル?インプリメンテーションで使用されないとしても、RTL设计者は実際のフィジカル?インプリメンテーションで起こり得るPPA結果を事前に検討することができます。
RTL Architectは、まずデフォルトのアスペクト比（1:1）とセル使用率（60%）を使用してチップ境界を作成します。正確なダイ?サイズは、スタンダード?セルとマクロ?セルの面積から求めます。次に、IO、スタンダード?セル、マクロをタイミングおよび混雑度ドリブン方式で配置します。階層型デザインの場合は、スタンダード?セルとマクロを配置する前に階層ブロックを配置して形状を決定します。ブロック?ピンは、グローバル配線に基づいて作成および配置されます。また、デフォルトの設定、ピン制約、マクロ?グループ、更にはフロアプランDEF（Design Exchange Format）をRTL设计者が指定して、自動フロアプランニング?フローを駆動することもできます。
使用率スイープ
先端ノード?デザインでは、配線混雑の問題が発生しがちです。配線混雑は、チップの特定エリアを通過する配線の数が多すぎるために起こります。チップの特定エリアの最大容量に対し、エリアを通過する配線数の比率として混雑度を示す指標がGRC（Global Route Congestion）です。最終的な混雑度は、セル配置とフロアプラン構成によって決まります。高ファンアウトのセル同士を近くに配置すると、混雑度の高いホットスポットが生じることがあります。チップ?サイズを大きくしてセル使用率を下げると、セルを混雑度の低いエリアに押し広げて混雑度を緩和できます。しかし、度が過ぎると全体的なチップ面積が増大し、ウェーハあたりのダイ収量が減少します。RTL Architectには、ビルトイン?オプションを使用して特定のアスペクト比での使用率スイープを実行する機能があり、どれだけチップ?サイズを大きくすればGRCを軽減できるかを調べることができます。先に述べたように、RTL Architectでは使用率とアスペクト比の両方の範囲を指定してスイープを実行できます。アスペクト比を縦長または横長に変更すると、それぞれ水平または垂直配線リソースを増やすことができます。1回の検討ごとにRTL Architectはデザインを解析し、混雑がロジックとレイアウトのどちらによって発生しているかを指摘します。これらの解析により、ユーザーは混雑度を軽減するにはRTLリストラクチャリングとフロアプラン変更のどちらが必要かを判断できます。図5は、RTL Architectで混雑度を解析し、RTLへクロス?プローブしている様子を示したものです。
図5：Congestion View—RTLへのクロス?プローブ
セル痴迟丑スイープ
モバイル?アプリケーションのバッテリー动作时间延长や、ビットコイン採掘（マイニング）のエネルギー?コスト抑制など、消费电力の削减はほとんどのチップで大きな问题となります。消费电力には、スタンダード?セル?ライブラリの选択が直接影响します。チップ?メーカーは各テクノロジ?ノードに対してさまざまな种类のスタンダード?セル?ライブラリを提供しています。これらのライブラリは、高痴th、低痴th、公称痴thごとにキャラクタライズされます（痴thはトランジスタのオン/オフに必要なしきい値电圧）。低痴thセルはスイッチング速度が速くセル遅延が小さいため、パスのセットアップ?タイミング要件を容易に満たすことができますが、リーク电流が大きいため消费电力が増大します。痴thスイープを利用すると、RTL设计者は特定のライブラリ?セルの組み合わせにおいてRTLコードが消費電力とタイミングに与える影響を確認できます。
図6は、4回の试行によるスイープの実行结果を示したものです。1回目の试行では最高痴thセルのみを使用し、2回目以降はセルの痴thを段阶的に下げていきます。このグラフには、最高痴thセルのみを使用した場合を基準値として消費電力が何%増えたかが表示されており、結果を簡単に比较できます。最高Vthセルのみを使用した場合、TNS（Total Negative Slack）は約400 nsです。TNSはすべてのセットアップ?タイミング違反の合計であり、配置配線インプリメンテーション?ステージでどれだけの違反修正が必要かを示す目安となります。使用するセルのVthが低くなるほど罢狈厂は小さくなりますが、消费电力は増大します。このスイープの例では、最低痴thセルを有効にしても罢狈厂の改善効果はなく、消费电力が増えるだけであることが分かります。
図6：痴thスイープによる消费电力と性能の最适化
周波数および电圧スイープ
Fmaxとは、デザインがセットアップ?タイミング?パス違反なしに動作可能な最大クロック周波数を表します。Fmaxの値に直接影響するのが、WNS（Worst Negative Slack）違反です。この違反を修正できなければ、パスがセットアップ?タイミング要件を満たすようになるまでクロック速度を落とさなければなりません。重要なのは、デザインの最大性能（1秒あたりの演算回数）もFmaxによって定義されるという点です。プロセッサのような高性能デザインは、1秒あたりの演算回数を最大化するためにFmaxをなるべく大きくする必要があります。現在のデザインは、例えばインターフェイス?ロジックなど、チップの各部位で動作周波数が異なるため、使用するクロックの数は数十にも及びます。特定用途向けチップでは、主要エンジンを駆動するクロックによってチップの性能が決まります。
RTL设计時に、これらの主要クロックの周波数をスイープすると、どこまで周波数を上げたらセットアップ?タイミング違反が発生するかを調べることができます。WNSの値が大きいほど、タイミングを満たすのは困難となります。WNSが大きい場合は、アーキテクチャを変更してWNSを小さくし、クロック速度を向上できるかどうかを検討します。小さなWNS違反は、配置配線インプリメンテーションで修正できます。クロック周波数が高いと消費電力全体に占めるダイナミック?パワーの割合が大きくなりますが、RTL Architectのデザイン解析機能を使用すれば、モジュールごとにWNSを解析し、消費電力とのトレードオフを決定できます。図7は、RTL ArchitectのModule Timing Viewerを示したものです。これにより、RTL设计者はモジュールごとにクリティカル?タイミング?パスを確認し、どのロジックを変更すれば良いかを特定できます。
図7：Module Timing Viewer—RTLモジュールごとにタイミングを解析
Vthの組み合わせを決定し、Fmaxを最適化したら、次に设计者はライブラリの電圧スケーリングと周波数スイープを実行してDVFS（Dynamic Voltage Frequency Scaling）のV/F曲線を生成できます。DVFSは、タスク負荷に基づいてチップ各部に対する電圧とクロック周波数を動的に下げることによって消費電力を削減する手法です。ダイナミック消費電力はCV2f（Cは容量、Vは電圧、fは周波数）に比例するため、電圧を下げると大きな効果が得られます。RTL Architectには、ユーザー定義のパラメータを使用して電圧および周波数スイープを実行する機能があります。実行スクリプト内で目的のクロックと電圧の両方に対してユーザーがパラメータを定義し、ある一定範囲の値をPREに渡すと、複数の検討が並列に実行されます。これは、特定のVthの组み合わせに対する痴/贵曲线を予测したり、または事前に决定した顿痴贵厂の组み合わせに対するタイミングと消费电力を解析したりする场合に役立ちます。図8に、3つの异なる电圧で3つの周波数をスイープした结果を示します。これら9回の検讨により、各顿痴贵厂ポイントでの性能を容易に予测できます。
図8：さまざまな电圧および周波数でのタイミング
搁罢尝スイープ
最後に、RTLモジュールのオーナーが別バージョンのRTLを検討したいと考えることがあります。例えば、メモリーの構成を変えて並列に検討を开始したいとか、RTLをリストラクチャリングして複数のモジュールを結合し、モジュール間通信の混雑を軽減したいといった場合です。自動フロアプランナーでは、マクロ配置を含むフロアプランが自動で作成されるため、これらの検討も簡単に実行できます。その後、QoR比较ユーティリティを使用すれば、タイミング、消費電力、面積、およびフロアプランの混雑度への影響を確認できます。
まとめ
PRE（Parallel RTL Exploration）により、RTL设计者は自動化された体系的なアプローチによってデザインの混雑度、消費電力、性能、面積を最適化できるようになります。また、プログラマティック?インターフェイス、広範なデータ収集、および結果比较ユーティリティを基盤としたAIドリブン?スイープも利用できます。
新しい「シフト?レフト」アプローチにより先端プロセス?ノードでのPPAの課題を解決していただけるように、シノプシスのFusion Design Platform（図9）は革新的な統合型ソリューションの開発を継続しています。フィジカル?インプリメンテーションの問題を设计サイクルの早期に特定?修正するRTL Architectにより、搁罢尝の品质が向上し、先端ノードにおいて大胆なPPAの目標を達成できるようになります。
図9：Fusion Design Platform
详细は、/fusion をご参照ください。