今日の FPGA デザインにおいて、異なるクロック・ドメイン間における信号の接続 ( CDC ( Clock Domain Crossing ）)によるメタステーブルが問題になっています。従来の構造による検証だけでは、CDC 信号の検証に有効ではありません。このコラムでは CDC の問題とその検証方法について４回に分けてご説明します。
第１回：セットアップタイムやホールドタイムとは
第２回：メタステーブル とは
第３回：一般的なメタステーブル対策とその問題
第４回：メタステーブルの検証方法
第２回：メタステーブル とは
図2-1 は、非同期関係にある 2つのクロック間をまたぐデータが存在します。このような場合は、後段の FF （フリップフロップ)において メタステーブルが発生することがあります。
図2-1 メタステーブルが起こる回路例
前回のコラムで説明しましたが、FF は一般的にインバータを2つ使ったループ回路でデータを保持します。データがループを1周する前に入力信号を閉じると出力信号が中間電位になることがあります（図2-2参照）。これがメタステーブルです。
図2-2 メタステーブルの波形
運悪く Low(0) と High(1) の間の中間電位になってうまく釣り合うと、サーフィンでうまく波に乗れたように、長い時間メタステーブル状態が続きます。バランスが崩れだすと CMOS 回路なので Low か High に落ち着きます。
メタステーブルの問題点
メタステーブルは多くの点で問題です。ソフトエラーやデバイスの不具合だと思われているケースで、再現性の無いエラーはメタステーブルが原因であることが多くあります。メタステーブルの問題点をいくつかご紹介します。
1．メタステーブル状態は、FFの遅延よりも相当長い時間になることがあります。
2．メタステーブル状態が終わっても、Low か High のどちらに落ち着くかわかりません。
3．シミュレーションや実機検証でも確認できません。
4．再現性がありません。
5．CDC 対策が有効かどうかの判断が困難です
メタステーブルが増えた理由
最近になって メタステーブルが多くなった理由として次のことがあげられます。
1．動作周波数の向上 ⇒ クロックの回数が増えるので メタステーブル確率が上昇
2．クロック・ドメイン数の増加
3．レジスタ数の増加
メタステーブルの検証は非常に困難
メタステーブルは製造プロセス、温度、電圧などの微妙なバランスで起こるので、論理シミュレーションやタイミングシミュレーションでの検証は不可能です。そして、1分間に１回起こる確率の回路なら実機でも検証できますが、数か月に１回起こる確率の回路では実機でも検証は困難です。
また、対策が効果的かどうかの判断も困難です。よって、メタステーブルによる不具合解析は非常に時間がかかります。
例えば、弊社のグループ会社が作成した画像処理系 ＩＰは 3つのクロックドメインしかないのに CDC が原因で不具合が頻繁に発生しました。この不具合原因が CDC だと判明するまでに、約一ヶ月半もの期間を要してしまいました。
一般には、回路構造からメタステーブルの可能性がある箇所を抽出するツールを使いますが、数百以上の箇所がエラーやワーニングとしてレポートされます。
そのレポートから、一つ一つ手作業でモレなく解析するのは非常に困難な作業となります。
今回はここまでです。次回はメタステーブルの一般的な対策とその問題点についてご説明します。