マルチクロックドメイン設計の落とし穴（3/3 ページ）

複数のクロックドメインを利用するSoCには、設計者が見落としがちな注意点がある。それに気付かずにチップを作ってしまうと、なぜ問題が起きているのかを究明することすら難しくなる。そうした落とし穴の存在を認識しつつ、適切な設計手法とEDAツールを適用することにより、チップの再試作を回避し、市場投入までの時間のロスを防ぐことが可能になる。

[Shaker Sarwary（米Atrenta社）,Saurabh Verma（米Atrenta社），EDN]

データの一貫性

　非同期クロックに関するもう1つの重要な問題は、独立して同期がとられた信号が収束するときのシンクロナイザにおけるデータの一貫性である。クロックドメインをまたがる部分では、同期をとるための対策がとられていても、遅延やサイクルレベルの不確定性が生じる。シンクロナイザはメタスタビリティ状態を回避し、下流の論理回路に正常な信号が伝送されるように働くが、この回路の遅延をなくすことはできない。

　一貫性の問題は、相関関係があり、かつ別々に同期がとられた2つの信号がクロックドメインをまたがるときに起きる。各シンクロナイザの遅延が異なることが原因である。一方の回路で信号の遷移をとらえようとする際、最初のサイクルで正しい値をとらえたとする。ところが、もう一方の信号が遅延の影響により次のサイクルで遷移をとらえたとすると、そちらは誤った値になってしまう。改めて遷移をとらえ直すためには、その次のクロックサイクルまで待たなければならない。結果として、少なくとも1サイクル分は転送先で誤った値が使われてしまうことになる。信号が状態変数を表している場合、転送先では未定義、または望ましくない状態が観測されることになり、回路に機能的な障害が起こる。

　これは最もよく起こるCDCの問題の1つで、回路の規模が大きくなるに従って、ますます重要になってきている。過去の設計資産を再利用している回路ブロックやIP（intellectual property）コアを使うと、気付かないところでこの問題が生じる可能性がある。その回避策の1つが、グレイコード（gray code）を利用する方法である。例えば、emptyフラグやfullフラグを計算するために、FIFO（first in, first out）のポインタがクロックドメインをまたがることがある。その場合、バイナリコードをグレイコードに変換し、他方のドメインに転送する。その上で、通常のバイナリコードに変換し直せばよい。また、empty/almost-emptyフラグやfull/almost-fullフラグを計算するために、FIFOブロック内のポインタにアクセスすることがある。この動作によっても、設計者が見落としがちなCDCの問題が発生するかもしれないが、標準的な方法によって問題の発生を回避できる。

　グレイコードの符号化回路は簡単なものに思えるが、実は誤りを犯しやすいものでもある。また、グレイコードの符号化回路内にグリッチがあると、機能的障害が起きることがある。

　もう1つ見落としがちなのは、グレイコードの符号化における設定とバイナリコードの範囲に食い違いがあるケースである。例えば、0から5までカウントして0に戻る深さ6層のFIFOの書き込みポインタを作成したとする。グレイコードの符号化回路が、0から7までカウントする3ビットカウンタを対象としている場合、ポインタが5から0に変化するときに問題が起きる（図4）。このような詳細部分を考慮して設計しないと、グレイコードを採用したことで、かえって問題が生じてしまう。

図4　グレイコードを用いる場合に発生する問題の例

スタティックなCDC検証

　設計経験の度合いにかかわらず、すべての設計者は本稿で紹介したような問題に注意すべきである。CDCにはコーナーケースにかかわる問題がたくさんあり、設計者がすべての詳細部分に注意を払うのは難しい。特にスケジュール的に厳しい場合はそうだ。

　最良の方法は、明確な評価基準を持つ体系的な方法でこの問題に対処することである。この目的を達成するためのものとして、最近ではスタティックなCDC検証ツールを利用できるようになった。シミュレーションやスタティックなタイミング検証など、従来の検証ツールでは対応できなかったメタスタビリティや一貫性などのCDC問題を対象としたものである。つまり、設計者が見落としがちなコーナーケースに対応できている。検証時のサインオフツールセットの一部として、任意の設計フローに対応する体系的な検証方法が実現されている。