ALINT-PROによるCDCリコンバージェンス問題の検証

メタスタビリティに加えて、クロックドメインクロッシング問題は、デジタルデザインの機能的な不安定性を引き起こす可能性があります。受信側クロックドメインの取り込みエッジは、送信側クロックドメインのクロックに対して、いつでも発生する可能性があります。送信データにグリッチがあった場合、受信クロックドメインで「レベル」に変換される可能性があります。また、シンクロナイザを介した信号変化の遅延は、受信クロックで「前」または「次」の信号レベルがキャプチャされるかどうかは保証されないため、予測不可能な場合があります。

図 1: クロックドメインクロッシングによる機能的問題

ソースドメインでの収束ロジックにより、デスティネーションクロックドメインにグリッチが伝わることがあります。ソースクロックドメインの両方のフリップフロップが同時に出力信号をサンプリングする場合、組み合わせ論理パスでの伝搬遅延の違いにより、誤った信号がデスティネーションクロックドメインに転送されてしまうことがあります:

図 2: シンクロナイザ前の組合せロジックではグリッチが発生する場合がある

シンクロナイザの入力でグリッチが発生する可能性を排除することが重要です。シンクロナイザ直前にデータをクロックドメインでレジスタすることは、グリッチによる機能問題を防ぐための最も安全なソリューションです。

ALINT-PRO CDC検証ソリューションは、シンクロナイザスキームの入力にグリッチが発生しないことを保証します。

CDC転送時の遅延の不確実性は、デジタル回路の機能障害を引き起こすもう一つの問題です。受信クロック領域で、関連する2つ以上の制御信号が転送され、リコンバージェンス（再収束）すると機能上の問題が発生することがあります。CDC転送後、これらの信号は受信クロック1周期分だけ互いにシフトしている可能性があります。関連する制御信号のリコンバージェンスにより、不要なグリッチが発生することがあります（図3）。

図 3: 不要なグリッチによるリコンバージェンス問題

以下のデザイン例で、ALINT-PROにおけるリコンバージェンスの問題を説明します：

図 4: リコンバージェンスが発生するデザイン例

CDC解析では"valid_sync"レジスタの入力ピンで、収束深度（コンバージェンスデプス）が2のリコンバージェンス問題を特定します：

図 5: ALINT-PROを使用したリコンバージェンス解析

収束深度が2の場合、CDCシンクロナイザの直後に両方のパスがリコンバージェンスすることを示しています。シンクロナイザはそれ自体が初段のレジスタステージと見なされ、一般的な"valid_sync"レジスタは2番目のレジスタステージと見なされます。.

次の例では、CDCパスがシンクロナイザ後の2番目のレジスタステージでコンバージェンスすることを示しており、収束深度は3になります：

図 6: 収束深度が3におけるリコンバージェンス解析

プロジェクトプロパティの"Design Entry -> Constraints -> CDC"ウィンドウ内の"Convergence analysis depth"パラメータは、CDCパスのリコンバージェンスを検索する最大の深さを示します。コンバージェンス解析の深さの値が大きくなると、特にCDCパスの数が多い大規模なデザインでは、リコンバージェンスパスを見つけるための処理時間が長くなります。実際には、この値を4以上に設定することはお勧めできません。大規模デザインのCDC解析では、コンバージェンス解析の深度の値をさらに2に下げることをお勧めします（図7）：

図 7: Convergence analysis depthの設定

リコンバージェンスが検出された場合、危険なCDCの転送を修正するためにデザインを見直す必要があります。考えられる解決策の1つは、組み合わせロジックをソースクロックドメインに移動させ、その結果生じる信号をデスティネーションドメインに渡すことです（図8）：

図 8: リコンバージェンス問題の修正

ALINT-PROのリコンバージェンス解析は、ハードウェアのグリッチや機能障害の原因となっているCDC関連の深い機能的問題を設計者が発見するのに役立ちます。