vol.117 RTL Architect:かつてない精度でRTLの並列検討を実現

RTL Architect:かつてない精度でRTLの並列検討を実現

RTLの品質が向上

米国シノプシス 

シニア・プロダクト・マーケティング・マネージャー Jim Schultz


「シフト・レフト」革命

シノプシスのRTL Architectは、フィジカル設計を考慮したRTL解析・検討・最適化を可能にした業界初の環境で、その登場は設計者に新たな創造性への扉を開きました。このツールは、インプリメンテーションおよびサインオフ・エンジンを活用することにより、デジタル設計サイクルの最初期の段階で消費電力、性能、面積(PPA)の最適化を可能にするという意欲的な目標の下に開発されています。チップが複雑さを増し、先端ノードにおけるルールの制約が大きくなる中、インプリメンテーション・ツールによるラストマイルの最適化だけでは、PPAの目標を達成してノードの実効性を確実にするのが困難になっています。RTL Architectは、RTLがインプリメンテーションに与える影響を設計者自身で予測することで「シフト・レフト」を可能にします(図1)。

図1:RTLインプリメンテーションのフィードバックに関する
従来のアプローチとシフト・レフトのアプローチ

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:PREの手順

セットアップ

セットアップ機能を使用すると、ユーザーがスイープ・パラメータと対応する値の範囲を定義するだけで大規模な候補マトリクスを簡単に定義できます。例えば使用率の範囲を{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へのクロス・プローブ

セルVthスイープ

モバイル・アプリケーションのバッテリー動作時間延長や、ビットコイン採掘(マイニング)のエネルギー・コスト抑制など、消費電力の削減はほとんどのチップで大きな問題となります。消費電力には、スタンダード・セル・ライブラリの選択が直接影響します。チップ・メーカーは各テクノロジ・ノードに対してさまざまな種類のスタンダード・セル・ライブラリを提供しています。これらのライブラリは、高Vth、低Vth、公称Vthごとにキャラクタライズされます(Vthはトランジスタのオン/オフに必要なしきい値電圧)。低Vthセルはスイッチング速度が速くセル遅延が小さいため、パスのセットアップ・タイミング要件を容易に満たすことができますが、リーク電流が大きいため消費電力が増大します。Vthスイープを利用すると、RTL設計者は特定のライブラリ・セルの組み合わせにおいてRTLコードが消費電力とタイミングに与える影響を確認できます。

 

図6は、4回の試行によるスイープの実行結果を示したものです。1回目の試行では最高Vthセルのみを使用し、2回目以降はセルのVthを段階的に下げていきます。このグラフには、最高Vthセルのみを使用した場合を基準値として消費電力が何%増えたかが表示されており、結果を簡単に比較できます。最高Vthセルのみを使用した場合、TNS(Total Negative Slack)は約400 nsです。TNSはすべてのセットアップ・タイミング違反の合計であり、配置配線インプリメンテーション・ステージでどれだけの違反修正が必要かを示す目安となります。使用するセルのVthが低くなるほどTNSは小さくなりますが、消費電力は増大します。このスイープの例では、最低Vthセルを有効にしてもTNSの改善効果はなく、消費電力が増えるだけであることが分かります。

図6:Vthスイープによる消費電力と性能の最適化

周波数および電圧スイープ

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の組み合わせに対するV/F曲線を予測したり、または事前に決定したDVFSの組み合わせに対するタイミングと消費電力を解析したりする場合に役立ちます。図8に、3つの異なる電圧で3つの周波数をスイープした結果を示します。これら9回の検討により、各DVFSポイントでの性能を容易に予測できます。

図8:さまざまな電圧および周波数でのタイミング

RTLスイープ

最後に、RTLモジュールのオーナーが別バージョンのRTLを検討したいと考えることがあります。例えば、メモリーの構成を変えて並列に検討を開始したいとか、RTLをリストラクチャリングして複数のモジュールを結合し、モジュール間通信の混雑を軽減したいといった場合です。自動フロアプランナーでは、マクロ配置を含むフロアプランが自動で作成されるため、これらの検討も簡単に実行できます。その後、QoR比較ユーティリティを使用すれば、タイミング、消費電力、面積、およびフロアプランの混雑度への影響を確認できます。

まとめ

PRE(Parallel RTL Exploration)により、RTL設計者は自動化された体系的なアプローチによってデザインの混雑度、消費電力、性能、面積を最適化できるようになります。また、プログラマティック・インターフェイス、広範なデータ収集、および結果比較ユーティリティを基盤としたAIドリブン・スイープも利用できます。

新しい「シフト・レフト」アプローチにより先端プロセス・ノードでのPPAの課題を解決していただけるように、シノプシスのFusion Design Platform(図9)は革新的な統合型ソリューションの開発を継続しています。フィジカル・インプリメンテーションの問題を設計サイクルの早期に特定・修正するRTL Architectにより、RTLの品質が向上し、先端ノードにおいて大胆なPPAの目標を達成できるようになります。

図9:Fusion Design Platform 

詳細は、https://www.synopsys.com/fusion をご参照ください。