News and Views 2016 Spring / Vol. 17: 上流設計&組込み

Successive Refinement Methodology - ローパワー設計の段階的な詳細化

はじめに

ローパワーアーキテクチャの検討は、半導体の価値を左右する性能指標として欠かせないものとなりました。最近では、IEEE1801(UPF: Unified Power Format)を用いて通常の設計とローパワー設計を同時に行い検証するプロジェクトが大半を占めるようになりました。UPFで検証が済んだローパワー設計は実装フローのゴールデンリファレンスとなります。このUPFのメリットを十分に発揮するために、IEEE 1801-2009の標準化当時から、ローパワー設計の段階的な詳細化を実現する「Successive Refinement Methodology」が考案されています。本仕様の元となるAccellera標準と比べ、より抽象的なローパワー設計を実現する機能として、パワーマネジメントに関する戦略的かつ抽象的なスキームが追加されました。

この機能は、設計対象のコンポーネントが、段階的に、より大きなブロックへと統合され、最終的に完全なシステムとして構成されていく過程で、ローパワー設計を構築するのに適しています。再利用可能なIPを作成するIP開発者から、IPブロックのコンフィギュレーションを決定してパワーマネジメントのブロックと統合するシステム設計者、論理設計を物理実装に割り当てる実装担当者など、プロセスに関わるすべての技術者がメリットを享受できます。しかし、このメソドロジに対する認知が業界においてさほど広がっていないのが現状のようです。

UPFの従来からの使用法

UPFを用いたローパワー設計は、論理設計やパワーマネジメントブロックの実装とは独立して表現できます。UPF定義からは、設計工程と検証工程の双方へとフローが流れます。検証工程では、設計そのものとローパワー設計を重ね合わせた状態で設計の挙動をテストし、実装の正当性を保証します。実装段階では、UPF定義が実装ツールに指示を出し、ローパワーに関するロジックを挿入します。設計が正しく実装されたかどうかを検証することが主な目的であるため、このフローで使われるUPFは実装指向になりがちでした。しかし、ここには課題もあるのです。

実装指向偏重のフローの課題

実装指向とは、抽象度がより低いことを意味します。このアプローチでは、システム設計者が個々の実装の詳細観点に立ってパワーマネジメントのスキームを定義しなければなりません。つまり、電源ネット、電源ポート、スイッチ、その他の実装詳細を個別に定義する必要があります。そのため、次のような問題が想定されます。

  • 設計の初期段階ではターゲットのプロセス技術が決定されていない場合が多く、上位のローパワー設計記述に対して暫定的な実装スタイルを選択しておきます。そのため、最終確定後のプロセス技術との互換性が確保できず、再度記述し直すことになります。
  • システム設計者はUPFを読み込み、記述自体が正しいか、また定義された全体的なパワーマネジメントのスキームが意図した目的を達成するかを検証します。多大な検証労力を割いても、ターゲットのプロセス技術確定後にUPFファイルを修正すれば、検証プロセスのやり直しが発生します。
  • 複数のSoCや同一システムの異なる世代開発、あるいは実績あるシステムを別のプロセス技術に移植する際、大量のIPブロックを再利用します。実装が特定されている場合には、再利用性、移植性が大幅に下がり、UPFの再記述、再検証といった大きな課題が発生します。
  • 再利用性、移植性の低下は、IPプロバイダにとっては特に問題です。というのも、顧客がどのプロセス技術にするか決定していない状態で、IPとローパワー記述を併せて顧客に提供しなければならないからです。

機能検証には実装詳細が必要となるため、パワーアウェアの検証はフロー終盤まで延期されがちです。抽象度の高いローパワー設計ができれば、ターゲットのプロセス技術や実装方法に左右されなくなるはずですが、その場合、バックエンドでの実装固有の詳細情報をどのように追加するのでしょうか。また抽象度を超えた検証整合性はどのように確保できるのでしょうか。そこで必要となるのが、Successive Refinement Methodologyなのです。「Successive」には継続的な、次に続くといった、「Refinement」には精緻化、精錬化といった意味があります。

SUCCESSIVE REFINEMENT METHODOLOGY

図1. Successive Refinement Methodologyによるフロー図1. Successive Refinement Methodologyによるフロー

より多くのステークホルダーが、Successive Refinement Methodologyからメリットを享受します。IPプロバイダは、特定のコンフィギュレーションに縛られずにIPブロック固有のローパワー制約を設定できます。IPユーザは、物理的技術に依存する実装を前提とせずに制約範囲内でIPをコンフィギュレーションできます。シミュレーション可能でありながら、技術非依存のゴールデンリファレンスが利用可能となります。

図1.は、制約UPF、コンフィギュレーションUPF、実装UPFを示したものです。制約UPFはIP固有のローパワー設計(パワードメイン/ステート/アイソレーション/リテンションなど)を記述したもので、RTLと共にIPの一部としてソース提供されます。コンフィギュレーションUPFは制約をベースにアプリケーションごとに個別記述するもので、電源記述、パワーステート、論理式など、シミュレーションで必要となる情報をエンドユーザが作成します。実装UPFはプロセス技術に依存するコンフィギュレーションの個別実装を記述するもので、電源ネット、電源ポート、スイッチなど、実装に必要な情報をエンドユーザが作成します。

IPプロバイダは制約という形でUPFを提供し、それはユーザが変更してはならないものです。IPはコンフィギュレーションを設定した上で使用しますが、この際にUPFのコンフィギュレーションも設定します。最後に、実装詳細を加えて抽象度の高いレベルから詳細までを網羅しようとするのがSuccessive Refinement Methodologyによるアプローチです。ここから先は、各段階で使用するUPFについてもう少し詳細を見てみましょう。

制約UPF

制約UPFファイルは、ローパワー設計を最も抽象的に捉えたもので、ローパワー設計意図の制約として特定の設計コンポーネントに適用します。制約UPFファイルは、ソフトIPプロバイダから提供され、対応するIPコンポーネントを用いたシステムの検証や実装に使用します。IPユーザは、制約UPFファイルを差し替えたり変更したりすることはできません。制約UPFファイルに含まれる情報は以下の通りです。

  1. アトミックパワードメインの定義
  2. リテンション要件
  3. アイソレーション要件
  4. 有効パワーステート

アトミックとは、これ以上パーティショニングすることのできないドメインという意味合いでUPFでは使用されています。ポートやライブラリのセルマッピング、またリテンションやアイソレーションの実装に関する情報は記載されません。そのような情報は、システム設計と実装が進むにつれて、IPユーザが追加していきます。

コンフィギュレーションUPF

コンフィギュレーションUPFファイルにおけるIPのコンフィギュレーションは、IPとともに配布される制約UPFファイルで定義された制約に従ってIPユーザが行います。IPの各インスタンスの制約UPFファイルを読み込み、制約を適用していきます。コンフィギュレーションUPFファイルでは、これ以外に、システムのパワーマネジメントスキームの詳細を定義します。この詳細定義が各IPインスタンスに適用された制約に沿ったものであるかどうかは、検証ツールを使ってチェックできます。コンフィギュレーションUPFファイルでは以下を定義します。

  1. パワーマネジメントをRTL設計から論理制御するためのポートの追加
    (create_logic_portコマンド)
  2. パワードメインのアイソレーション方策と制御の定義
    (set_isolationコマンド)
  3. パワードメインのリテンション方策と制御の定義
    (set_retentionコマンド)
  4. パワードメインの制御信号の論理式によるパワーステートの更新
    (add_power_state –updateコマンド)

コンフィギュレーションUPFファイルは、実装やプロセス技術個別の詳細を含みません。抽象的に記述され、不要な実装詳細を含まず、RTL検証で使用できるようにする必要がある一方、バックエンドエンジニアが実装詳細を追加するときには再利用できるものでなければなりません。例えば、スイッチ設計の論理的な情報や電圧値やセル情報などは、コンフィギュレーションUPFでは扱いません。

実装UPF

Successive Refinement Methodologyに基づく実装UPFファイルは、設計実装に必要な詳細とプロセス技術個別の情報を定義します。最終的に、制約UPF、コンフィギュレーションUPF、そして実装UPFのすべてを合わせることで、設計全体にわたるローパワー設計意図を定義します。

実装UPFファイルには、パワースイッチや電圧レール(パワーネット)の詳細を記述します。実装エンジニアが指定したパワーネットの各パワードメインへの割当てと接続や、実装固有のパワースイッチ構成などを定義します。実装UPFファイルには、以下の情報が含まれます。

  1. 実装設計で必要なパワーネットワーク要素の作成
    (create_supply_port / create_supply_net / create_supply_setコマンド)
  2. スイッチ設計の論理的な表現
    (create_power_switchコマンド)
  3. パワーネットと電源セットの接続
    (connect_supply_net / associate_supply_set)
  4. 電圧値などのテクノロジ参照、セル参照

制約UPFやコンフィギュレーションUPFは実装の詳細と分離されているので、これらのUPFで表現したローパワー設計意図は、他のプロセス技術をターゲットにした場合にも流用できます。

UPFをIPとともに使用する

パワーマネジメントの観点から設計IPを正しく使用するには、IPの制約UPFをユーザが変更することなく、提供されたままの状態で使用できることが欠かせません。IPの使用にあたっては、通常、コンフィギュレーションの設定が必要になりますが、パラメータ化されたIPの場合には、有効なIPコンフィギュレーションすべてに対して矛盾のない制約UPFをIPプロバイダが提供し、ユーザが制約UPFを編集しなくて済むようにする必要があります。1つの解として、すべてのパラメータ値を取り込み、コンフィギュレーション済みのRTLコードと対応する制約UPFの両方を生成できるユーティリティやスクリプトなどを提供する方法があります。

SoCの完全なシステム設計内には、同じIPコンポーネントが複数インスタンスとして含まれることもあれば、異なるIPコンポーネントの複数インスタンスが含まれる場合もあります。各IPコンポーネントにはそれぞれ固有の制約UPFファイルがあり、各UPFファイルの適用範囲は対応するIPブロックに限られます。一方、システムのコンフィギュレーションUPFファイルは、システム全体を俯瞰して記述します。コンフィギュレーションファイルは、load_upfコマンドを用いて各インスタンスの制約UPFファイルの読み込みを開始し、後続行のコマンドで、システム全体のパワーマネジメントのために各IPインスタンスをどうコンフィギュレーションするか定義します。

IPプロバイダは、IPのRTL設計、制約UPFファイルと共にサンプルのコンフィギュレーションUPFファイルを提供することもあります。通常、サンプルファイルには論理コンフィギュレーションのローパワー設計意図の一例が記述されており、これをベースとしてIPユーザは独自のシステム設計向けのコンフィギュレーションUPFファイルを記述できます。コンフィギュレーションUPFファイルの記述が完成したら、すべてのIPコンポーネントの制約UPFファイルとコンフィギュレーションUPFファイル、システムとそのコンポーネントのRTLをシミュレーションで検証できるようになります。検証が終了した後には、これらのファイルは「ゴールデンリファレンス」とみなされ、その後のプロジェクトサイクルを通じてあらゆるツールが読み込む対象となります。

まとめ

SoC設計の複雑化が進む中、ローパワーは重要な性能指標となりました。市場では、より短期間のTATを求める熾烈な競争が繰り広げられていますが、短い設計サイクルと早期のテープアウトが可能になるのは、設計コンポーネントの検証整合性が実装段階に至るまで保証され、それを頼りにできる場合のみです。そのためにも、入手するソフトIPと対応する制約UPFは重要な役割を果たします。

Successive Refinement Methodologyでは、UPF 2.0のすべてとUPF 2.1の一部新機能を含むIEEE 1801 UPFを基本的に完全サポートします。UPF機能の一部を利用するだけでも、このメソドロジの効果をある程度活かすことはできますが、ツールチェーン全体ですべてのUPF要素を利用して初めて、最大限の効果が発揮されます。IEEE P1801 UPFのワーキンググループは、このメソドロジをより効率的に導入し、さらに簡潔なものとなるよう、UPF標準の改良を続けています。