今日の FPGA デザインにおいて、異なるクロック・ドメイン間における信号の接続 ( CDC ( Clock Domain Crossing ）)によるメタステーブルが問題になっています。従来の構造による検証だけでは、CDC 信号の検証に有効ではありません。
このコラムでは CDC の問題とその検証方法について４回に分けてご説明します。
第１回：セットアップタイムやホールドタイムとは
第２回：メタステーブル とは
第３回：一般的なメタステーブル対策とその問題
第４回：メタステーブルの検証方法
第３回：一般的なメタステーブル対策とその問題
一般的なメタステーブル対策は図3-1 にように 後段の受信側クロックドメインに2段以上の FF を挿入します。最近では3段以上を挿入することが多くなりました。何段挿入したら良いかの目安は、Quartus® II TimeQuest タイミング・アナライザ機能で MTBF（平均故障間隔）を確認すれば分かります。なお、メタステーブル期間が短くなるように受信側のFF間は短くすることをお勧めします。
図3-1 一般的なメタステーブル対策
FF を数段挿入すれば、メタステーブルを後段に伝えることは抑えられます。しかし・・・、 まだ問題は残っています。プロトコルやリコンバージェンスの問題です。
プロトコル エラー
図3-2 の波形は最初のクロックで1段目の FF がメタステーブルを起こしているので、１段目の FF の出力 (Ｑ1) の論理が安定しません。そして、2段目の FF がデータ (Q1) を取り込んで 出力 （Q2） を Low(0) にしていますのでメタステーブルは Q2 に伝播していません。
しかし、2回目のクロックの後にデータが変わったので、このケースの場合は1サイクル目のデータを取りそこなっています。これが プロトコル エラーです。
メタステーブルを回避できても データを取れなければ意味がありません。プロトコル エラーを防ぐには 2段目の FF がデータを受信できるまでの間、データ (Ｄ) を安定させておく必要があります。
図3-2 プロトコル・エラー
リコンバージェンス エラー
プロトコル エラーを起こさないように安定してからデータを取り込んでも これが Bus だったらどうでしょう。
メタステーブルを起こしたビットは次のクロックで転送（2サイクル転送）されて、メタステーブルを起こさないその他のビットは前のクロック（1サイクル転送）で転送されます。
これによる不具合が リコンバージェンス エラーです。
図3-3 リコンバージェンス
皆さんは リコンバージェンス エラー対策はされていますか？
今回はここまでです。次回はメタステーブルの検証方法についてご説明します。