Technology Reports 2007

複数クロックのデザインを完動させる

はじめに

  今日のコンシューマを中心とした高機能製品には、高いパフォーマンスと低電力消費が求められ、このニーズに応える手法として複数クロックのアーキテクチャや洗練されたパワーモデルの採用が増えています。100ナノメータ以下の複雑なSoC設計においては機能検証が困難になり、設計フローのボトルネックにもなってきています。これに応える検証技術としてアサーションベース検証やランダムテストなどの導入が進んでいる一方、シミュレーションでは検証できない新しい部類の問題が浮上しています。それがCDC - Clock DomainCrossingと呼ばれる領域です。異なるクロックドメイン間で行われるデータ転送は注意深く扱わない限り、バグは検証工程をくぐり抜け、シリコンに潜むことになります。

各CDC信号について充分に理解し、プランニングすることは非常に困難なタスクです。 ColletInternational, 2005 IS/ASIC Design ClosureStudyによれば、2005年の時点でデザインの15%以上において20以上のクロックドメインが存在し、事実上、数千にも及ぶCDC信号が存在することになります。このレポートでは、クロックに関する問題はリスピンの原因の中で二番目に多いとも報告されています。

Clock Domain Crossingの問題

  データが2つのクロックドメイン間で転送される際、送信側のクロックエッジと受信側FFが近い場合、データが破損する可能性があります。例えば送信側FFのデータが変化した同じタイミングで受信側FFがデータを取り込んだ場合、受信側FFでは0でも1でも無い、その中間の電位となります。この電位はやがては0か1に落ち着くものの、このFFからドライブされる論理はランダムな値となります。この効果はメタスタビリティと呼ばれるものです。

 もし1ビットの信号がドメイン間で転送され、2つ以上の受信側FFでラッチされたり、或いは複数ビットの信号がドメイン間で転送されるような場合、上記で説明した不具合は他の不具合と組み合わさり、データ破損はより複雑になります。1つの受信側FFが変化前の値をラッチし、他の受信側FFが変化後の値をラッチする可能性があるのです。3ビットのデータが他のクロックドメインに転送される場合について考えてみます。その値があるクロックサイクルで「111」であり、次の値が「000」であったとします。しかし受信側FFにおいて「101」⇒ 「000」という遷移が起こる可能性があるのです。

 このようなエラーが発生した場合、解決は極めて困難です。データの破損は数時間、或いは数日に一度の確率で、クロックエッジがちょうど悪いタイミングで起こった場合にのみ発生します。このタイミングでデザイン全体がフェイルする可能性があるのです。この問題はテストベクタを用いたシステムテストでは再現させることはできません。ファームウェアを用いてこの問題を解決できる可能性も高くありません。というのは単純なコントロールで回避できる問題ではなく、データの破損として現れるからです。エンジニアが数ヶ月かけて見つけ出し、原因を理解し、そして解決するような問題です。実際には相当数のユニットが顧客の手元でフェイルするまで、問題として認識出来ない可能性もあります。特に今日の複雑なチップ設計では、このようなバグによる製品のリコールや製品のやり直しは、恐ろしく高価なものとなってしまいます。

(図をクリックすると拡大表示します) (図をクリックすると拡大表示します)

(図をクリックすると拡大表示します) (図をクリックすると拡大表示します)

シンクロナイザーはあくまでも部分的な解決策

  このようなバグを避けるため、クロックドメイン間でデータや制御信号を転送する場合、設計者はシンクロナイザー(同期化回路)を使います。これは実際には新しい検証の課題を創出します。即ちクロックドメイン間のシンクロナイザーが、全ての起こり得る状況において正しく動作していることを検証することです。これまで何年も、数多くのエンジニアがシミュレーション技術を用いてこの問題に取り組んで来ました。しかしシミュレーション単体ではCDCバグを見つける為に適した解ではなく、結局シミュレーションで検知したエラーと実際のハードウェア上で発生するエラーとは合致しませんでした。最新のテストベンチのメソドロジであっても同様です。シミュレーション環境は機能上の問題を見つけるには向いていますが、中間レベルの電位について、例えそれがいくつかのクロックサイクル内に解決したとしても、その検証には向かないからです。

完全なるCDC検証のソリューション

  実際に求められているのは、全てのCDCの振る舞いに対する、自動化された検証ソリューションです。全てのクロック及びCDC信号を特定して検証しなくてはなりません。全てのクロックドメイン境界を渡る信号が、安全に管理され、クロックドメインに対する全てのシンクロナイザーが正しく構成されていることを確認する必要があります。

 最初のステップは、デザインの完全且つ自動的な構造解析です。基本的な構造の正当性が確認されたら、ユーザー定義のパラメータについて、その正当性が立証されなくてはなりません。完全なCDCソリューションに求められるのは、続いてフォーマル検証で証明されるかシミュレーションで検証されるべきアサーションの自動生成です。しかもカバレッジの測定及びレポートも必須となります。またCDC ソリューションには、クロックドメインを渡る信号上へのジッター効果の付加も重要です。これはメタスタビリティの効果をモデリングし、メタスタビリティが発生しても、デザインの機能としてフィールドで異常な振る舞いをしないことを、シミュレーションを使って検証する為です。

 複数のクロックドメイン無しでパフォーマンスやパワーが最適化された設計は現実的ではありません。メンター・グラフィックスの0-In CDC製品によって実現している、完全自動化された検証ソリューションが必要になります。これにより、複数クロックを含むデザインであっても、リスピンすることなく完動するという確信が持てるでしょう。

(図をクリックすると拡大表示します) (図をクリックすると拡大表示します)

メンター・グラフィックスでは、このCDCを使う為のメソドロジを5つのステップにまとめました。詳しくは下記からホワイトペーパーをご覧ください。

ダウンロードはこちら