はじめに

クロックドメイン・クロッシング（CDC）の問題は、FPGA搭載システムの市場出荷後に引き起こされるシステム障害の大きな要因となっている。このような事実があるにも関わらず、FPGAのCDC検証が充分に行われないまま、出荷され続けている。事実を誤って捉えることから生じる動作保証に関する認識の欠如は、エレクトロニクス業界にも大きな影響を与えている。

ASICにおけるテープアウトやFPGA搭載システムの製品出荷の際にはチェックリストが用いられる。このチェックリストはプロセスを遵守し、見落としや確認し忘れがないことを確実に行うために使用されるが、逆にチェックリストを過信するあまりに、これこそが落とし穴となることもある。すべてのプロジェクトにはチェックリストが存在すべきで、優れたプロジェクトには必ずと言っていいほど素晴らしいチェックリストが存在する。

ただしチェックリストに「CDC検証を終了したこと」といったレベルで項目表記されているような場合、何を行ったかのみに注意が行ってしまい、どうやって検証を終了したかに関する詳細が失われてしまうという危険性がある。市場投入後のシステム障害の大きな要因にCDCがある背景を鑑みれば、「CDC検証を終了したこと」となっているようなチェックリストの詳細を今一度確認しておくことは、重要であろう。

増え続けるシステム障害の重大要因となっているクロッキングの問題

クロッキングの問題は多くの場合、２つの非同期クロックドメイン間の境界を超える際にデータ破損や信号損失を引き起こし、クロックドメイン・クロッシング（CDC）の問題と呼ばれる。データや制御信号が１つのクロックドメインから他のクロックドメインへと乗せ換えられるとき（図１）、その信号は送信クロックドメインに関連するタイミング特性を持つが、最終的にはフリップフロップなどのクロック動作の要素によって受信側ドメインでサンプリングされる。

図1. 異なるクロックドメインへのデータ乗換え

受信側でデータ入力の変化がクロックエッジに近すぎる場合には、セットアップ条件やホールド条件に違反することがあり、取り込んだデータは過渡的であり不確定な状態となり、その後ランダムに1か0に落ち着く。その発生や期間は確率的であり、決定的ではない。これはメタステーブル状態と呼ばれる。（図２）メタとは「中間の」という意味合いで使われており、1ステーブルと0ステーブルの中間の過渡的な様子を表現している。

図2. 受信側DFF2の状態がメタステーブルとなる様子

図2.にあるように、メタステーブルの状態では正しく無い値がQから出力され、そのため不正な動作を引き起こしてしまう。受信側のクロック周波数が上がると、それだけ単位時間当たりにサンプリングする回数が増加する。従来は障害発生頻度が半年に一度程度であったものが、周波数が高くなったことによって毎週のように障害が発生するということも起こり得る。確定的な障害ではなく確率的なものであり、よってFPGA搭載のボードで再現させることは難しく、実機デバッグはまず無理である。

このようなメタステーブルの振舞いが発生したとしても、データ信号やコントロール信号を正確に転送されることを保証する目的で、多くの種類のクロック境界面における同期化スキームが存在する。そのような同期化のメカニズムを施さない限り、データ信号やコントロール信号の誤った値がサンプリングされ、その結果、不正な動作となる。

このようなクロッキングの問題は、研究用途のみならず、市場へと出荷されるFPGAベースのシステム製品で発生しており、それはかつてないほど広まっており、重要視されている。2018 年のWilson Research Groupの機能検証リサーチによると、クロッキングの問題は欠陥を持った製品が市場流出する問題の要因としては2番目に多く、過去6年間でほぼ20％増加しており、第1の要因に迫っている。（図3.）

図3. Wilson Research Group 2018 市場流出したFPGA 障害の要因

さらにWilson Research Groupの同じ調査では、2018年においてはFPGA設計の84％で改修が必要となる重大なバグが発生していることが確認されている。（図4.）バグ無しで出荷できたのはわずかに16%であるから、84%では1つ以上のバグが市場流出していることになる。FPGAの分野ではCDC検証を徹底的に行うなど、機能検証に対してより多くの労力を費やす必要があることが明らかになっている。

図4. FPGAプロジェクトにおいて市場流出した要改修バグの数

しかし、最も重要なことは、クロッキングによるバグの市場流出を上昇傾向にしているものは何かを理解することである。それを理解せずに検証労力を費やしたとしても、徒労に終わる可能性がある。
我々が常日頃から認識していることは、設計規模と設計の複雑度は常に増加傾向にあることである。これによりクロック数、クロックドメインの境界を超えるデータ信号やコントロール信号の数が増加することは容易に想像できる。図5に示すように過去6年間、FPGAのクロック数はほぼ同じであり、おそらくわずかに増加している。とは言え、クロックの数はさほど増加していないため、FPGAの障害の増加傾向は複雑度の増加と、クロックドメイン間の境界を超えるデータ信号やコントロール信号数の増加によると類推される。

図5. FPGA設計あたりの非同期クロックドメイン数の傾向

ここで必要なのは、CDC検証の数をいたずらに増やすのではなく、より包括的な検証方法へと検証の質を上げることである。そのためにはCDCに潜在する障害発生の仕組みのすべてを完全に理解した上で、徹底的に分析する必要がある。

クロックドメイン・クロッシングを管理する上で広く使われる簡便な手段

FPGA設計におけるメタスタビリティの問題は広く理解されている。多くのFPGAプロジェクトチームでは、この問題に対する対処法を準備しているはずである。クロックドメイン・クロッシングが存在する箇所に同期化メカニズムを追加し、それに対する設計レビューが続けられる。事前に承認されたシンクロナイザがライブラリ化されており、それを使用するケースもある。FPGAベンダから提供される開発ツールスイートには、ネットリストに対してクロック解析を実行することでCDC箇所の可能性を特定できるため、CDCが適切に扱われているか否かをプロジェクトチームとして判断しやすい。

これで十分ではないと考えるプロジェクトチームでは、クロッキングの問題をさらに特定するために、シミュレーションに頼ることがある。クロックを非同期モデル化し、デザインのフリップフロップでタイミング違反を検知できるようにし、メタステーブルとして振舞う期間、UnknownとしてXを出力させるモデルを使用する。この方法での検証メソドロジでは禁止されたシンクロナイザを使用してCDC信号を遷移させ、ツールが出力するレポートから特定されたクロックドメイン・クロッシングを確認し、適切なシンクロナイザを使用してシミュレーションすることで、確認する。多くのプロジェクトチームが行う解析はここまでである。ではなぜ、クロッキングの問題が製品として市場流出する傾向が広がっているのだろうか。その答えは、このレベルのCDC解析／検証では不充分だからである。

レビューの限界

設計者は通常、バグが見つかるまでは自分が書いたコードにはバグがないと考える。CDCの問題についても同じである。プロジェクトチームはCDC箇所を把握し、簡単なルールに従うことでクロッキングの問題は発生しないと信じている。そのような信念を推し進めることで製品が市場で成功することに賭けることは非常に一般的である。またレビューもクロスチェックの方法で実施される。ただし、レビューは人為的ミス、人的制約、そして人的な想定の影響を受ける。そのため、今日の設計に散見される機能的な問題に関しては、レビューの有効性は限定的である。その2つの良い例がプロトコル違反とリコンバージェンスの問題である。

プロトコル違反

単にすべてのCDC箇所にシンクロナイザが配置されていることを確認するだけでは充分ではない。CDCが正しく動作することを確認するには、シンクロナイザの同期ロジックに求められるプロトコルがすべての条件下で満たされていることを確認する必要がある。

図6.にあるような1ビットのコントロール信号に対して単純な2段DFFシンクロナイザでCDCを受けるインタフェースを例に考えてみる。このような設計におけるシンクロナイザは通常は事前に承認されたライブラリにある。また、このシンクロナイザには、それに関連する同期プロトコルが存在する。つまり送信側の信号は、受信側でサンプリングされるのに十分な時間保持されなくてはならないというプロトコルである。この単純な例ではレビューで充分かも知れないが、同期化スキームとプロトコルがより複雑かつ並列性が高まるにつれ、人為的エラーが混入するようになる。

図6. 2DFFシンクロナイザを介した単ビットコントロール信号の転送

図7.に4ビットのデータバス転送の例を示す。この例では図7.に示すD-Muxシンクロナイザなどのよく知られた同期手法により、受信側でのデータのサンプリングが正しく行われる。この同期手法には異なる同期プロトコルが求められる。つまり、送信側ドメインではデータはイネーブル信号の前もしくは同時、イネーブル信号の有効期間中、イネーブル信号がアクティブではなくなるまでの間、安定していなくてはならない。これもレビューで確認できないことではないかも知れないが、より複雑である。

図7. D-Muxシンクロナイザを介した4ビットデータバスの転送

消費電力、パフォーマンス、配線混雑度などの設計上の制約からレイテンシ削減が必要となり、これによりCDCが機能の深い箇所やパラレルパスにも存在するようになる。たとえばCDCがFIFOとパラレルインタフェースを介して存在することは一般的である。FIFOには固有のプロトコルがあり、このプロトコルが遵守されているかどうかの検証が欠かせない。例えばフル状態のFIFOへの書込みや、エンプティ状態のFIFOからの読出しはあってはならない。このようなCDC同期化プロトコルは、レビューにより検証することは不可能である。

リコンバージェンスの問題

CDCは、ドメインを渡る単一ビットや単一バスに分離することはできない。図8.に示すように通常は１つの信号のみがクロック乗換え対象ではなく、複数の信号がクロック乗換えの対象となることが多い。さらに信号は１つの受信側ドメインだけでなく、複数のドメインに渡ることもある。さらに複雑なのは、両ドメインの信号をさらに３番目のドメインで使用する例である。

図8. 複数ビット、複数ドメイン間における非同期クロックドメイン・クロッシング

このようなシナリオでは、受信側の下流ロジックが、送信側ドメインで定義されている信号間の相関関係に依存することが多い。例えば図9.に示すように複数ビットの組合せでコマンドとして定義される場合、その複数ビット間のタイミング関係は受信側でも維持されなくてはならない。ここで問題となるのがCDCシンクロナイザによる予測できないサイクル遅延である。これによりCDCによって機能的バグを引き起こす可能性がある。

図9. ３ビットの信号によるコマンドの転送時に発生するリコンバージェンスの問題

送信側ドメインで生成したコマンドシーケンスである000 (NOP) → 111 (WRT) は、それぞれのビットはシンクロナイザを介して最終的には受信側に転送されるものの、メタスタビリティ発生に伴うサイクル遅延はビットごとに予測できないため、000 (NOP) → 101 (NXT) → 111 (WRT) と存在しなかったコマンドを受信してしまうことになる。リコンバージェンスとは受信側での最収束を意味する。
このシナリオは比較的簡単なリコンバージェンスの例であるが、実設計ではこれよりはるかに複雑なリコンバージェンスのシナリオが存在することは想像に難く無い。人によるレビューで検証することはまず無理である。

シミュレーションの限界

機能シミュレーションは、レビューされたCDC箇所にシンクロナイザが配置されているかをクロスチェックする解析手法として許容できるだろうか。論理シミュレーションの目的はCDCの影響でデータ破損や信号損失が起こる状態を特定することである。

デジタルシミュレーションは本質的に非デジタルの動作を扱うことはできない。よってフリップフロップやその他の記憶素子のメタスタビリティ状態は、従来のデジタルシミュレーションではモデル化されていない。またシミュレーションにUnknownであるXを入れるやり方は、X伝搬によりシミュレーション結果が意味ないものとなる悲観性に陥るか、もしくは問題点を見過ごす楽観性に陥る可能性がある。メタスタビリティ動作に対する同期化の効果を検証することは困難である。

この課題を解決できたとしても、クロックに対する制約がシリコンの実際の振舞いを正確に反映していることが確実でなくてはならない。これにより初めてシミュレーションでCDCを適切に再現しテストするために必要な環境と言える。この環境を網羅的に実現することは容易ではない。複雑な設計に対して適切なテストシナリオをシミュレーションすることでCDC違反を再現させるには、プロジェクトチームに余裕があるとしても、それよりもはるかに多くのシミュレーションサイクルが必要になる。真の非同期クロックの振舞いを本当に再現するには、制約付きランダムによる制御により、多くの組み合わせをもたらすからである。

最後の課題は、CDCテストの終了をいかに定義するかである。クロックドメイン・クロッシングによってデータ破損や信号損失が発生しても、実際に機能テストがフェイルしない可能性もある。クロックに関する制約条件の正しい組み合わせがテストで有効になっており、メタスタビリティが適切にモデル化されていたとしても、テストで対象となるパスが活性化されなくてはならない。すべてのテストですべてのパスが活性化されるわけではない。

ASICにおけるCDCテクニックの応用

ここまで見てきたように、人によるレビューと機能シミュレーションに頼ることは、最善の場合でも相当困難な見通しであり、最悪の場合は誤りが混入しやすく、プロジェクトチームはシステムに存在する重要なCDCの問題を見逃してしまうだろう。明らかに、人によるレビューと機能シミュレーションのみでは不充分である。その代替として必要なのは、クロッキングのネットワークとCDCを包括的に検証することが可能なシミュレーション以外による手法である。

FPGAとその搭載システム設計者にとっての朗報は、マルチクロックドメイン設計の課題は、ASICセクターにおいて20年近く対応されてきており、すでに活用することが可能な堅牢で幅広いCDCソリューションによって容易に対応することができる。それはフォーマル検証の技術を応用したものであり、FPGA設計に対しても適用可能である。そのようなツールは、人によるレビューとシミュレーションでは不充分な課題を容易に分析し特定することができる。同じく重要なことは、このソリューションは合成後のネットリストではなく、RTLコードに対して実行し、設計プロセスの初期段階で実施できるため、設計の修正がより効率良く行えるという利点がある。

CDC検証手法採用の効果は、堅牢なCDC検証手法の適用が一般的となっているASICセクターと、未だ一般的ではないFPGAセクターにおける差異として見ることができる。図9.に示すのは前出のWilson Research Group 2018による市場調査によれば機能的な障害の根本的要因としてクロッキングを挙げた割合はASICセクターでは26%であるのに対し、FPGAセクターでは43%であった。

図10. 機能的障害の根本的要因として挙げられた「論理・機能」（左）と「クロッキング」（右）の分布

まとめ

FPGA設計は膨大な数のクロッキングの問題を抱えたまま出荷されている。このような問題は、堅牢なCDC検証の採用を推し進めることで、出荷前に特定し対応することができる。さらにCDC解析の品質は、設計をクリーンなものとするためには重要である。フォーマル検証の技術を基盤とすることで徹底的な分析が容易に行えるCDC解析は、結果品質を改善する上で非常に効果的な手段である。

「Design and Verification Landscape」技術情報メールニュース

PALTEKでは本ブログ「Design and Verification Landscape」シリーズの技術情報をメールで年に3-4回発信しています。
ご登録いただいた方には、最新の情報をメールニュースとしてお届けします。
ご希望の方はこちらのフォームよりご登録ください。

※競合製品取り扱い企業様の申込については、お断りする場合がありますので予めご了承ください。

関連ウェビナーのご案内

このブログのシリーズ一覧は下記になります。是非あわせてお読みください。