vol.114 UPFベースのローパワーSoCにおけるCDC検証

UPFベースのローパワーSoCにおけるCDC検証

米国シノプシス ベリフィケーション・グループ 

スタッフ・アプリケーション・エンジニア Rahul Chirania


本稿では、ローパワー設計手法を使用して複雑なSoCに高度なパワー・マネージメント・ストラテジを実装する際の検証課題についてご説明します。これらの手法を使用したデザインでは、特にパワー・マネージメント・インフラストラクチャがクロック/リセット・ドメイン間の信号に影響を与える場合、デザインに深刻なバグが混入することがあります。具体的には、新しいCDC(Clock-Domain Crossing)パスが作成されたり、同期済みCDCパスの同期が損なわれたりするケースがあります。このようにして生じる複雑なバグは、従来のCDCツールでは対処できないため、CDC検証およびサインオフへの新しいアプローチが求められます。

CDCの問題とは

多くのデジタルICデザインは、1つのユニバーサル・クロック信号を使用して動作を同期し、ロジック信号が新しい値に遷移した後、状態が安定してからサンプルするようにしています。ところがパワー・マネージメント手法を使用すると複数の独立したクロックが追加されるため、クロック・ドメインをまたぐ際に信号の同期が必要となります。そうしないと、非同期クロック信号が各フリップフロップに到達するタイミングが、サイクルごとに変動してしまいます。このようなタイミングの不確実性があると、セットアップおよびホールド・タイム違反がデザイン内でランダムに発生し、これが不安定性を引き起こして機能障害につながることがあります。

 

SpyGlass CDCなどのRTL CDCツールを使用すると、RTレベルの違反を検出して適切な同期回路を追加できます。図1に示す2つのファンクションは異なるクロックで駆動されており、これらの間でやりとりされる信号を何らかの方法で同期しないと不安定性が発生します。

電力考慮デザインでCDCの問題が発生する理由

電力考慮デザインにおいて、電源遮断やマルチ電圧ドメインなどの一般的なローパワー設計手法や、DVFS(Dynamic Voltage and Frequency Scaling)、低VDDスタンバイ、バイアス制御などの高度な手法は、アイソレーション・ロジック、リテンション・セル、パワー・スイッチなどのハードウェアを使用して実装します。また、デザインにおけるアイソレーション、リテンション、レベル・シフトのストラテジはUPF(Unified Power Format)ファイルを使用して定義します。

 

通常、設計者はパワー・マネージメントに関するストラテジをデザインのRTL内で指定します。しかしこれらのストラテジが複雑化するのに伴い、現在はUPFファイルで多数のPST(Power State Table)を記述し、多くの電源ドメインを定義するようになっています。UPFファイルでは、グローバル信号(クロック、リセット、test_enableなど)や制御信号(アイソレーションやパワー・スイッチのイネーブルなど)がソース・ドメインからシンク・ドメインへ渡されるような条件を禁止する必要があります。また、ソース・ドメインのON条件がシンク・ドメインのON条件のスーパーセットになることもUPFで禁止する必要があります。これら条件のいずれかがデザインに存在すると、ソースがOFFの場合に信号がデスティネーション・ドメインに到達せず、機能の不具合を起こすことがあります。動的シミュレーション手法を使用してこれらの問題を発見、修正し、多数のPSTを人手でデバッグするのは非常に時間がかかる上、正確なデバッグも困難です。

 

図2は、パワー・マネージメント手法を適用したデザインを示したものです。このデザインは複数の電源ドメイン(PD)に分割されており、それぞれのPDが個別に管理されていますが、パワー・マネージメント手法を適用する前は、D1からD2への信号パスはハンドシェイク同期モジュールを使用して直接同期されており、RTLにCDCの問題はありませんでした。

 

しかしローパワー・セルを挿入し、PSTで各PDを定義すると、D1からD2へのパスが電力考慮のCDCパスとなります。これは、ソース(D1)がPD1にあり、シンク(D2)がPD2にあり、同期信号がPD3のハンドシェイク同期モジュールから供給されるためです。

 

図2に示すPSTで定義されているように、PD1=ON、PD2=ON、PD3=OFFの場合、データはハンドシェイク同期モジュールによる同期なしでD1からD2へ送信されます。すると電源ドメイン・クロッシングが非同期となり、機能上のバグが発生します。

別の例として、図3を見てみましょう。ソース・フリップフロップとシンク・フリップフロップは元々同じクロック・ドメインに属しており、ソース-シンク間のパスにCDCの問題はありませんでした。しかしパワー・マネージメント・ストラテジに基づいてソース-シンク間にアイソレーション・セルを挿入した結果、クロック・ドメイン1からクロック・ドメイン2への非同期パスが作成され、CDCバグが発生しています。

UPFを考慮したCDC検証

この問題は、CDCツールやローパワー検証ツールを単独で使用したのでは解決できません。CDC解析に求められる条件としては、UPFの情報を取り込めること、デザインのリアルタイム・インストルメンテーションをサポートしていること、インプリメンテーション・ツールと同じ方法でUPFを解釈できること、パワー・マネージメント・ストラテジによって新規に挿入されたロジック・パスに対してインクリメンタルにCDC検証を実行できること、などが挙げられます。

電力を考慮したデザインには、特有の検証課題があります。パワー・マネージメント・ストラテジによって新しいロジックや信号パスが挿入されることがあるため、既存のツールやメソドロジに頼っていたのではRTLサインオフに不安が残ります。パワー・マネージメント・ロジックによって混入するすべての問題を検出するには、UPFを考慮した静的ソリューションが必要です。このようなソリューションには、下流工程のインプリメンテーション・ツールと同じ方法でUPFインストルメンテーションが可能で、最新の構文をサポートしていることも求められます。

著者紹介

Rahul Chirania:シノプシス、ベリフィケーション・グループ 静的検証チームのスタッフ・アプリケーション・エンジニア。ASIC設計/検証など、EDAおよび半導体業界で9年以上の経験。現在はCDC/RDC製品スペシャリストとして、顧客のCDC/RDC検証メソドロジの定義と改良を支援。