RTL Architect：かつてない精度で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で実行できる最も一般的なデザイン検討のいくつかについてご説明します。

セットアップ

セットアップ機能を使用すると、ユーザーがスイープ・パラメータと対応する値の範囲を定義するだけで大規模な候補マトリクスを簡単に定義できます。例えば使用率の範囲を{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）。また、各ジョブのフロアプランのスナップショットも表示されます。ジョブ名のリンクをクリックすると、そのジョブの詳細なレポートが表示され、実行結果を詳しく調べることができます。

使用率スイープ

先端ノード・デザインでは、配線混雑の問題が発生しがちです。配線混雑は、チップの特定エリアを通過する配線の数が多すぎるために起こります。チップの特定エリアの最大容量に対し、エリアを通過する配線数の比率として混雑度を示す指標がGRC（Global Route Congestion）です。最終的な混雑度は、セル配置とフロアプラン構成によって決まります。高ファンアウトのセル同士を近くに配置すると、混雑度の高いホットスポットが生じることがあります。チップ・サイズを大きくしてセル使用率を下げると、セルを混雑度の低いエリアに押し広げて混雑度を緩和できます。しかし、度が過ぎると全体的なチップ面積が増大し、ウェーハあたりのダイ収量が減少します。RTL Architectには、ビルトイン・オプションを使用して特定のアスペクト比での使用率スイープを実行する機能があり、どれだけチップ・サイズを大きくすればGRCを軽減できるかを調べることができます。先に述べたように、RTL Architectでは使用率とアスペクト比の両方の範囲を指定してスイープを実行できます。アスペクト比を縦長または横長に変更すると、それぞれ水平または垂直配線リソースを増やすことができます。1回の検討ごとにRTL Architectはデザインを解析し、混雑がロジックとレイアウトのどちらによって発生しているかを指摘します。これらの解析により、ユーザーは混雑度を軽減するにはRTLリストラクチャリングとフロアプラン変更のどちらが必要かを判断できます。図5は、RTL Architectで混雑度を解析し、RTLへクロス・プローブしている様子を示したものです。

セルVthスイープ

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

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

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

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設計者はモジュールごとにクリティカル・タイミング・パスを確認し、どのロジックを変更すれば良いかを特定できます。