(Part1) 数十億ゲート規模のASIC統合の課題：クロック・ドメイン・クロッシング

クロック・ドメイン・クロッシング（CDC）エラーがASIC不具合の原因に

現在の数十億ゲート規模のASICには、多数のサードパーティIPブロック、外部インターフェイス、可変周波数による省電力機能などが含まれ、数十から場合によっては数百もの非同期クロック・ドメインが存在します。従来のRTLシミュレーションでは、非同期クロックの境界でデータ転送の問題を引き起こすメタスタビリティ効果を検証できません。また、スタティック・タイミング解析（STA）でも非同期クロック・ドメインの問題には対処できません。このため、これらの手法に頼ることは困難です。
 

CDCはデジタル設計者にはよく知られた問題で、基本的には以下に示す4つの一般的なCDCシナリオで発生します。非同期クロック・ドメイン間のジッタによって生じるメタスタビリティは、適切なクロック・シンクロナイザを使用しないと機能エラーを起こすことがあります。これ以外にも、同期した複数のパスを結合するロジックがシンクロナイザの不確実性によってタイミング不一致を引き起こすリコンバージェンスの問題など、複雑なパスやシナリオがデザインの奥深くに埋もれていることもあります。この種のバグは、多くの場合最終的なシリコンで問題を引き起こすため、適切に対処しないとチップのリスピンという高いコストが発生してしまいます。

このよく知られた問題が、数十億ゲート規模のASIC開発でますます困難な課題となっているのはなぜでしょうか。その課題に対応するために、CDC検証アプローチの規模を拡大するにはどうすれば良いでしょうか。CDC検証はテープアウトのための重要なサインオフ条件ですが、現在のASIC開発チームにとってCDC検証を達成する上で何が重要な課題となっているのでしょうか。

ターンアラウンド・タイムの問題

CDCクリーンはリリース・サインオフのための必須条件であり、これを達成するにはかなりの時間と労力を要するため、製品開発ライフサイクルの中で十分に考慮しておく必要があります。当然、その工数はデザインの規模に比例します。現在の数十億ゲート規模ASICには数百ものクロックがあり、クロック・クロッシングの数は数百万に達する可能性があるため、フルチップCDC解析をフラットレベルで実行するには数日の計算時間と数テラバイトのメモリーが必要になることもあります。ここで大きな問題となるのが、ターンアラウンド・タイムです。どうすれば良いでしょうか。
 

これは大規模なASICの開発全般に言えることですが、まずは分割統治のアプローチをとる必要があります。階層的なボトムアップ式アプローチを採用すれば、合成やスタティック・タイミング解析と同じようにCDC解析を1ブロックずつ実行できます。こうすると、CDC解析を開発フローの早期段階に前倒し（シフトレフト）し、開発を進めながら反復アプローチによりブロック単位でCDCの問題を解決できます。こうすると、リリース直前までCDC解析を後回しにして、CDCのバグ修正に大きなコストと混乱が生じるのを防ぐことができます。そして次の階層に進む際に、クリーンになったブロックを抽象CDCモデルで置き換えます。このモデルは、次の階層に関連するクロック・パスのみを含み、内部で完結するクロック・クロッシング・パスはすべて抽象化されます。このサブシステムがCDCクリーンになったら、次の階層レベルでも同じ工程を繰り返します。シノプシスのVC SpyGlass^® CDCは、CDCサインオフ抽象モデル（SAM）フローによる効率的な階層アプローチをサポートします。これにより、結果品質（QoR）を低下させずに必要なメモリーを数分の1に削減し、ターンアラウンド・タイムを1/3以下に短縮できます。

ホワイトノイズの問題

ここまでは計算時間のコストについて述べてきましたが、人手によるエンジニアリングのコストについてはどうでしょうか。CDC解析について次に大きな課題となるのが、違反のホワイトノイズの問題です。デザインに数百万ものCDCクロッシング・パスが存在すると、膨大な数の違反が発生します。その中から本当の問題を特定するのは、干し草の山の中から針を見つけるようなものです。もちろん、ここで問題となるのは、重大な違反を見落としてしまい、CDCのバグがすり抜けてしまうことです。これは大規模なASICの開発においてまさに重大な問題であり、解析を人手に頼っているわけにはいきません。ここで救いとなるのが、データ・サイエンスです。機械学習（ML）アプローチはこの種の分類問題に適しており、違反を根本原因が共通する「クラスタ」に分類してくれるため、問題への対処が容易になります。こうすれば、同じ問題に起因している違反が数百、数千も存在していることがすぐにわかるため、違反の解析は一気に扱いやすくなります。場合によっては、上位5つのクラスタで違反の95%以上を占めることもあります。この場合、これら5つの問題を修正するだけで違反のホワイトノイズは劇的に減少し、干し草の山の中に残っている針を見落とす可能性がはるかに低くなります。
 

VC SpyGlass CDCは、出力された違反データに対してMLベースの根本原因解析（RCA）を実行することにより、このホワイトノイズの問題を解決します。このML RCAアプローチは違反のクラスタを特定するだけでなく、考えられる原因をデバッグの手がかりと根本原因とともに特定し、開発者を解決策へと導きます。修正は、例えば同期が不足している場合などはRTLの変更で行うこともありますが、多くの場合はCDC制約ファイルの手直しや追加という形で行われます。制約の手直しを反復することにより、違反の数が急速に減少し、本当に修正が必要なCDCの問題を迅速に特定することができます。

制約は適切か

上で制約について触れましたが、ここにも注意が必要です。CDC解析は制約駆動型のフローです。当然、開発者が誤った制約を書いてしまえば誤ったCDC解析となってしまい、本当のCDC違反が制約エラーによって隠蔽されることがあります。このように隠蔽された違反が原因でシリコンに不具合が生じることがあります。設計ワークフローでSDC（Synopsys Design Constraints）ファイルなどの入力制約ファイルが必要となった場合は、これらの重要な入力ファイルが適切かどうかをチェックすることが重要です。例えば、制約を動的アサーションに変換し、シミュレーションなど通常の動的検証環境でバリデーションすれば、制約を二重にチェックできます。こうすることで、制約の妥当性をより高いレベルで確認できます。

ウェーバーは適切か

制約以外にも、違反に対してウェーバーを使用することがあります。これも通常、CDC解析ワークフローへの入力ファイルであり、解析結果から人手で生成します。ウェーバーが適切でないと、本当のCDCエラーが隠蔽されることがあります。ウェーバーが最初は適切であっても、例えば設計の終盤で機能や性能の問題に対処するためにRTLの変更やネットリストのECOが発生すると、以前は有効であった条件が無効になっている可能性もあるため、ウェーバーのチェックが必要です。

より難しいコンバージェンスの問題

CDCの問題のほとんどは静的に解析できますが、デザイン内の特に深いパスによって発生する複雑なリコンバージェンスなどのシナリオでは、動的なアプローチが必要になることがあります。例えば、順次リコンバージェンスでは深さが定義されていないため、どの深さでも問題が発生する可能性があります。
 

このような難しいケースには、メタスタビリティ・インジェクションを使用したシミュレーションが適しています。VC SpyGlass CDCは、メタスタビリティ・モデルのCDCデータベースを生成し、設定可能な確率に基づいてシミュレーション実行時にランダム・ジッタを動的に挿入します。シノプシスのシミュレータVCS^®は、実行時にこのデータベースをネイティブに読み出します。エラーは、シノプシスの自動デバッガVerdi^®でデバッグします。Verdiではメタスタビリティを挿入した信号をプローブでき、ユーザーはカバレッジ・レポートを頼りにCDCが観測された信号を特定します。このレポートには、ジッタが挿入された回数も報告されます。

サードパーティ製IPブロックへの対処

前述のとおり、数十億ゲート規模のASICのほとんどは多くのサードパーティ製IPブロックで構成されます。これらIPのCDCにはどのように対処すれば良いでしょうか。どのようなアプローチをとるべきでしょうか。サプライヤから供給されるIPはCDCクリーンでしょうか。
 

IPサプライヤからは、フローに統合可能なCDC制約は提供されていても、サインオフ抽象モデル（SAM）は提供されていないかもしれません。この場合は、まずIPブロックの周囲にラッパー・レベルを作成し、これを使用してSAMを生成し、階層型アプローチに流し込むという方法をとることができます。ASICを構成するすべてのサードパーティ製IPブロックに対してフラット型のCDCを実行するという方法は、何としても避けたいところです。

デバッグ生産性の問題

検証ワークフロー全般に言えることですが、生産性はデバッグ・ツールの機能によって大きく左右されます。CDCデバッグの場合、回路図の可視化機能と波形解析機能を組み合わせたソリューションが最も効果的です。また、使い慣れたデバッグ環境であること、そして複数の検証プラットフォームを通じて一貫性があることも望まれます。シノプシスのデバッグ・ソリューションVerdiは優れた一貫性によりクロス・プラットフォームの標準化が可能で、CDCデバッグの生産性が向上します。

MBISTへの対処

最後に、MBISTの挿入にどう対処するかという問題があります。通常、MBISTは製品開発ライフサイクルの終盤に挿入され、最終デザインの全ロジックの約3%を占めます。当然、MBISTを挿入するとデザインにおけるCDCクロッシングが大幅に増加します。最終リリースのCDCサインオフを考える場合は、この点に注意が必要です。
 

この問題には、現実的な解決策があります。まず、MBIST挿入前に反復設計によりCDCクリーンを達成します。次に、MBISTを挿入し、挿入後に再び反復設計によりCDCクリーンを達成します。MBISTのクロック・クロッシング・パスを個別に処理することで、この問題を封じ込めて扱い易くすることができます。

スタティック・ソリューション：VC SpyGlass CDC

VC SpyGlass CDCは、スケーラブルな性能と容量を備え、高いデバッグ生産性を実現する包括的なCDCサインオフ・メソドロジを提供します。
 

VC SpyGlass CDCはシノプシスのスタティック解析ソリューションの1つで、シノプシス Verification Continuum^®プラットフォームに統合されています。VCSなど他のツールとネイティブに連携するほか、Verdiとの統合による一貫性のあるデバッグ環境で高い生産性を実現します。