CDC(Clock Domain Crossing)検証

CDC(Clock Domain Crossing)検証

CDC検証とは、非同期回路におけるドメイン間の転送にメタスタビリティ対策が施されているか、転送プロトコルが守られているかを検証するためのものです。
ASIC設計においては必須となっているCDC検証ですが、FPGAにおいてもシステム設計が主流となり、CPUやバス、各ペリフェラルが混在することによって非同期設計は当たり前になっています。事実FPGA設計におけるバグの約4割(※1)がクロック系にあたります。
それに伴いCDC検証に対する需要は年々上がってきています。

  • ※1 Wilson Research Groupが実施した設計と検証の市場調査(2016年) の結果より引用。
    詳細はこちら の「Figure 4. Types of Flaws Resulting in FPGA Rework」を参照

CDC問題と一般的な対策

通常CDCの問題をRTL論理シミュレーションで検出することは非常に困難です。デジタルの世界では0/1が明確なため、セットアップタイム、ホールドタイムに違反して不安定な状態を経て0 or 1に収束するような状況が発生しないためです。
しかし下記の例のように実際の物理回路ではデータを期待するタイミングで受信できないケースが起こり得ます。赤線は非同期転送パスになり、このパスを受けるレジスタで問題が発生する可能性があります。


図1 非同期パス例

図2 メタスタビリティ発生原因

setup違反によりレジスタ出力で不安定な状態(メタステーブル)が発生することが問題となります。このような問題への対策としては、基本的に下記のような対策を施します。
 @非同期転送間にロジックを含めない
 A2段のレジスタで受信する
 Bシンクロナイザ間のパスにもロジックを含めない

下記がシンクロナイザ挿入の例になります。ロジックを含めないことで収束時間を短くし次段レジスタで安定値をラッチをするよう設計します。


図3 シンクロナイザの挿入例

ではこのような対策だけで十分でしょうか?多くの設計者が現在もCDC問題に直面していることから考えて十分とは言えません。いくつもの原因がありますが、大きな問題としてデザインの高周波数化による非同期間のパスが年々増加傾向であるため、これらを目視のみでチェックするには限界があるためです。

CDC問題は実機検証において検出できる場合があります。この場合、回路内部のどこに問題あるのかを特定することが困難で、デバッグコストが非常にかかります。しかし最大の問題は、この状況を意図して発生させることはできないことです。実機検証においてCDC問題を検出できた場合は偶発的なものでしかありません。そのため、CDC問題が実機で発生していなければ問題ないと断言することはできず、回路に問題を残したまま製品をリリースすることになります。
ここでご紹介するCDC検証では、これら非同期の問題をRTLの段階ですべて検出し、リスクをなくし品質を向上させるための手法です。

検証手法と導入効果

CDC検証には大きく3つの検証手法があり、それぞれで検証できる項目/効果が異なります。

  • 構造解析
    すべての非同期転送のパスを検出し、メタスタビリティ対策が施されているか、またその対策に不備がないかをチェックします。
    過去に問題が発生しなかった実績のあるRTLを再利用する場合であっても、デザイン仕様により周波数条件等が変わることで 埋もれていたCDC問題が顕在化することもあります。しかし非同期転送パスを毎回目視によりチェックしていれば、その工数から再利用するメリットが低減してしまいます。
    構造解析は静的に解析されるため実行時間は最小限で、すべての非同期パスに対して漏れなく解析が可能です。
  • プロトコルチェック
    非同期間で転送される信号値は受信側が受け取るまでの間、安定していなければなりません。送信側のクロック周波数が高く、受信する前に値が変化してしまうと転送自体が行われないことになります。これではシンクロナイザを挿入したところで意味がありません。またデータ信号は安定していたとしてもそれに付随するイネーブル信号が転送しきる前に変化しても問題となります。
    このように構造解析ではエラーか判断できない(シンクロナイザが挿入されている)パスに対してプロトコルが厳守されているかまで解析することが可能です。
  • メタスタビリティ耐性チェック
    下記の例のようにシンクロナイザを挿入していても、複数ビットの非同期転送したデータが再収束(リコンバージェンス)する場合、一方がメタスタビリティにより1サイクル遅れて転送されてくると再収束した側でそれを吸収できる回路になっていなければなりません。例えばこの複数ビットをコマンドとした信号を非同期間で転送した場合、1ビットだけメタスタビリティにより1クロック遅れると受信側では意味の異なるコマンドになってしまいます。
    メタスタビリティ耐性チェックは、このようなメタスタビリティが発生した場合でも、受信側で正しく動作するかまでを検証することが可能となります。

図4 リコンバージェンスの例

Mentor製品を用いたCDC検証

Questa CDCでは、CDC検証における3つの検証手法に対してデバッグ効率を上げる様々な機能が搭載されています。

  • 構造解析における特長
    • - テストベンチが不要のため開発段階の早期に解析が可能
    • - 静的解析のため実行速度が高速
    • - 非同期パスはCDC対策が施されているパスも含めてすべて検出
    • - リコンバージェンス(再収束)箇所についても検出可能
    • - 豊富な解析項目
    • - Altera、XilinxのIPなどは自動的にマッピングし解析可能
    • - スケマティックによって視覚的にエラー箇所を確認可能
    • - ソースコードとのリンクが可能
    • - スケマティック、ソースコード共にドメイン毎に配色し、非同期
        関係を即座に判断可能
    • - 解析結果はCSVに出力可能

図5 構造解析の結果


  • プロトコルチェックにおける特長
    • - プロトコルチェックに必要なアサーションを自動生成
    • - 生成されたアサーションを使用してダイナミック/スタティック検証が可能
    • - ダイナミック検証時のアサーションのカバー率を計測
    • - 違反箇所を即座に波形にて確認可能

図6 プロトコルチェックの結果


  • メタスタビリティ耐性チェックにおける特長
    • - 下図のようにメタスタビリティ・インジェクタを自動挿入
    • - TCLKとRCLKがニアミスした場合にランダムでメタスタビリティを発生
    • - 実機検証でも意図的に発生不可なメタスタビリティを擬似的に発生可能
    • - シミュレーションによって耐性チェックが可能
    • - インジェクタによってランダムに発生したメタスタビリティは波形比較に
        よって確認可能

      図7 メタスタビリティ・インジェクタの挿入

      まとめ

      ASIC/FPGA設計においてシミュレーションは十分実施されていたとしても非同期設計に関する検証が実機検証のみの場合、埋もれている非同期問題を全て洗い出せていない可能性があります。 CDC検証ツールによる解析の導入により、メタスタビリティが発生するであろう箇所をすべてチェック可能です。またプロトコル違反や、メタスタビリティが発生した際の耐性チェックまで非同期設計における広い範囲の問題を解決することが可能です。

      代表的な導入効果としては以下があります。

      • 実機検証で再現できなかった埋もれている可能性のあるCDC問題をすべて検出可能
      • RTLの段階で早期に解析が可能
      • 静的解析による高速な実行

      Mentor社 Questa CDCを用いることで早期に解析できるだけではなく、解析結果からのスケマティック、ソースコードとのリンクで容易にデバッグが可能となります。また構造解析のみならず、テストベンチを使用したプロトコルチェックやメタスタビリティの耐性チェックまで可能となります。

       


お問い合わせ

資料請求・お問い合わせ