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

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

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

グリッチの問題

　もう1つ、CDCの問題で注意しなければならないのはグリッチの存在である。一般に、すべての組み合わせ論理回路では短いグリッチを生じる可能性がある。これらは、次のクロックエッジによってアクティベートすれば解消するため、通常は問題にならない。また、グリッチは、同期転送では問題とはならない。しかし、異なるクロックドメイン間での転送ではグリッチが問題になる可能性がある。回路がグリッチをパルスとして受信すると、機能的な障害が発生する。従って、グリッチが生じる可能性のある組み合わせ論理回路を、異なるクロックドメインをまたがる経路上に使わないようにすることが重要だ。演算は、クロックドメインを交差する前か、転送先ドメインが信号を捕捉した後に実行すべきである。

　異なるクロックドメインをまたがる場合、グリッチは制御/データの両方に影響する。すなわち、イネーブル線とデータ線の両方で問題となり、どちらもデータ転送の安全性に影響を及ぼす。そのため、クロックドメインをまたがるイネーブル信号の経路上には組み合わせ論理回路を使わないようにする必要がある。また、クロックドメインをまたがるデータ経路上では、イネーブル制御用フリップフロップ回路の一部で用いている再循環マルチプレクサ以外の論理回路を使わないようにする（図2）。

図2　グリッチが及ぼす影響の回避策

　この同期方式は一般的なものだが、CDCの回路では、組み合わせ論理回路によってイネーブル信号を生成することが多い。マルチプレクサの代わりにANDゲートを利用した回路を用いたり、マルチプレクサをデータ経路上のほかの組み合わせ論理回路とともに使ったりすることもある。いずれにせよ、データが転送先に同期転送されることと、グリッチが発生しないことを保証するためにイネーブル信号に頼っていることになる。イネーブル信号によって同期をとる回路において、ドメインをまたがる部分でほかの論理回路が使われると、回路は検出困難なグリッチの危険性にさらされる。

　グリッチのない簡単なマルチプレクサを使っているつもりでも問題が生じる可能性がある。この問題は、次のような理由で起きる。

　論理合成、最適化、技術マッピングなどの下流の設計ツールによって回路を変換すると、グリッチによって機能的障害が起きる論理回路が使われることがある。例えば、グリッチのない簡単なマルチプレクサが、グリッチが発生し得るANDゲートとORゲートに変換されてしまうのである（図3）。単体のマルチプレクサが、このように変換されることなどあり得ないと思うかもしれないが、データ経路上に多くの論理回路が使われるときには、このようなことが起きる可能性は十分にある。合成ツールや最適化ツールでは、マルチプレクサの論理回路を経路上のほかの論理回路と組み合わせることによって、タイミング特性を改善し、面積を縮小し、消費電力を低減しようとすることがあるからだ。結果として、最終的な回路がグリッチの生じやすいものになってしまう場合がある。

図3　マルチプレクサの合成結果　グリッチのない簡単なマルチプレクサ（a）が、グリッチが発生し得るAND/ORゲートの組み合わせ回路に変換されることがある（b）。

　このような問題を回避するには、ツールがこのような変換を行わないように制御しなければならない。残念ながら、設計者は回路の設計や実装の際に、こうした細かい部分を見落としていることが多い。しかもグリッチは簡単に予測できるような現象ではないので、シミュレーションやスタティックなタイミング検証では、非同期のクロックドメインをまたがる部分で発生するグリッチを検出できない。このような現象が生じる回路をチップに作り込んでしまうと、根本的な原因を特定するのは難しい。なぜチップに障害が起きているのかを突き止めるには、かなりの時間と労力が必要だ。

　このような問題を体系的に識別、検出し、コストのかかるチップの再試作を回避するには、スタティックなCDC解析が行えるツールを利用するとよい。