マルチダイ・システム検証の課題を解決する

マルチダイ・システムが求められる理由

マルチダイ・システムとは、複数の同種または異種ダイを1つのパッケージに収めた半導体デバイスを言います。マルチダイ・システムは一部の用途で何年も前から使われていますが、ここにきて採用が広がっており、今後は高性能コンピューティング（HPC）、人工知能（AI）、自動車、モバイルなどさまざまなエンド・アプリケーションで使用されるようになると考えられます。このテクノロジの採用が広がっているのには、主に2つの要因があります。

1つは、大規模なモノリシック・システム・オン・チップ（SoC）をチップレットと呼ばれる複数の小規模なダイに分割するトレンドです。このトレンドの背景には、大規模なチップが半導体製造装置のレチクル・サイズの限界に近付いているといった技術的な側面があります。しかし、たとえ大規模なモノリシック・ダイの製造自体が可能でも、そのようなダイは歩留まりが低下するため、小さなダイをたくさん製造した方が経済性の面で有利です。例えば、データセンター、自動車、モバイル、ゲーミングなどのアプリケーション分野の大規模なCPU、GPU、AIアクセラレータなどは分割の適用対象となります。

もう1つは、これまでプリント基板（PCB）上に実装されていた複数のディスクリート・チップを1つのパッケージ内に集約するトレンドです。マルチダイ・システムにおけるダイ間通信の方が、PCB上でのチップ間通信に比べ消費電力ははるかに少なく、スループットも大幅に向上します。マルチダイ・システム統合は、デジタル・チップと光学部品を1パッケージに収めたCPO（Co-Packaged Optics） など、ネットワーク分野でよく見られます。

分割か集約かにかかわらず、マルチダイ・システムにはいくつかの大きな利点があります。まず、図1に示したようにI/O密度が大幅に向上するため、スループットを容易に高めることができます。また、既存のダイ を組み合わせることで製品の組み立て時間を大幅に短縮できます。特に、用途別に派生品種を揃えることが容易になるため、より柔軟なソリューション・ポートフォリオを実現できます。マルチダイ・システムは既存の実証済みダイを再利用するため、プロジェクトのリスクが軽減され、市場投入までの期間（TTM）を短縮できます。これは、コストのかかる先端ノードでの製造に適さないアナログ・ブロックなどのコンポーネントを集約する場合には特に大きな利点となります。

マルチダイ・システム検証の課題

このようにマルチダイ・システムには大きな利点があるものの、従来のモノリシックSoCからマルチダイ・システムへの移行に踏み切るのは容易なことではありません。図2に示すように、マルチダイ・システムの実現にはこれまでにない多くの課題が立ちはだかっています。本稿では、マルチダイ・システムの検証課題に焦点を当て、以下の内容についてご説明します。

• システム検証に必要な容量と性能の問題への対処
• アーキテクチャ設計時に立てた仮定のバリデーション
• 検証が完了したかどうかの判定

マルチダイ・システムとモノリシックSoCでは規模と複雑さの違いはありますが、検証を開始する際に機能の完全性を検証することを目標とする点は同じです。大きな違いは、マルチダイ・システムではシステムレベルでの検証が必要という点です。したがって、使用するツールとコンピューティング・リソースには、このような検証をサポートできるだけの十分な容量と性能が要求されます。多くの場合、必要なメモリーも非常に大容量になり、これらの初期化やダンプだけでもシミュレーション全体のボトルネックとなってしまいます。シミュレーションおよびエミュレーション・モデルには、デザインの規模に合わせて拡張できること、そして利用可能なリソースを最大限に活用できることが求められます。また、アナログ・コンポーネントを考慮することも重要で、これらはデジタルとしてモデル化するか、ミックスドシグナル環境で協調シミュレーションする必要があります。

これらの基本的な要件に加え、マルチダイ・システムの検証ではデザインの規模と複雑さの増大が根本的な課題となります。シミュレーション手法は、一度に1個のダイまたは少数のダイに対するテストベンチを利用し、完全なシステム検証への統合パスを提供するなど、スケーラブルでなければなりません。アーキテクチャ設計時に立てた仮定をRTLデザインでバリデーションできるのは、システムレベルにおいてのみです。また、マルチダイ・システムのシステム検証ではダイ間通信とそれによる遅延、ジッター、コヒーレンシ、電力、保証付き分配、エラーへの影響を考慮する必要があります。モノリシックSoCの検証では、これらを考慮することはほとんどありませんでした。

何をもって検証完了とするかの判断も、モノリシックSoCよりマルチダイ・システムの方が困難です。まず各ダイを検証し、その網羅率を主にUVM（Universal Verification Methodology）で実装される機能カバレッジ・モデルで測定する必要があります。ダイレベルのバグはシステムレベルでは修正できないため、この作業は不可欠です。システムレベル検証では、正しいデータが正しい場所に、目標のスループットとレイテンシで到達するかを確認することに焦点を当てます。これを検証するには、ソフトウェアとファームウェア、および明示的なカバレッジ・モデルを含むシナリオを使用します。このアプローチは、Portable Stimulus Standard（PSS）によって十分にサポートされています。

効果的なマルチダイ・システム検証

これらの課題に対処するには、マルチダイ・システムとは単一のデザインではなく、個別に製造されたデザイン（ダイ）を通信ファブリックで相互接続して組み合わせたものであることを理解することが鍵となります。図3の例に示すように、モノリシック・デザインを複数のダイに分割して相互接続すると、多くの検証課題が生じます。

すべてのダイが個別に、または数個ずつまとめて十分に検証されている場合、マルチダイ・システム検証では複数のダイにまたがる複雑な機能に焦点を当てる必要があります。これには性能要件の検証も含まれますが、これは選択したパーティショニングおよび決定したアーキテクチャに大きく依存します。前述の通り、ここでは機能と性能の両方を重視したシナリオに焦点を当てる必要があります。

システムレベル・テストを実行するには、すべてのダイのRTLデザインを1つの実行ファイルにアセンブルしてシミュレーションする必要がありますが、これは簡単なことではありません。
 

• 「個別の」デザインおよびテストベンチをどうすれば1つのシミュレーション環境にアセンブルできるのか
• ダイレベルのテストベンチを再利用または同期できるか
• コンピューティング・サーバにシミュレーションのビルドと実行に必要なメモリーが搭載されているか
• シミュレーションをサーバで分散実行できるか
• どうすれば名前衝突を回避できるか

上に挙げた最後の質問については、マルチダイ・システムやマルチチップ・テストベンチをアセンブルした経験のない検証エンジニアには馴染みがないかもしれません。複数のダイのRTLデザインをただ単に一緒にコンパイルしただけでは、名前の衝突が容易に発生します。図3の例では、A、B、Cという同じ名前の異なるモジュールが各ダイに存在します。これらの名前衝突を回避する簡単な方法の1つは、各ダイを個別のライブラリにコンパイルすることです。こうすると、異なるダイに重複する名前があっても衝突や曖昧さの問題は生じません。

個々のダイのRTLコードには変更を加える必要がありません。図4に示すように、最上位のアセンブリおよび構成ファイルでダイ同士の接続方法を記述します。この結果、マルチダイ・システムの名前スコープは厳密に階層化されます。RTLコンパイラではC/C++コード内の名前衝突を解決できないため、C/C++テストベンチの場合は特に注意が必要です。

一般に、ダイレベルの複数のテストベンチを1つのシステム・テストベンチに統合するのは大変な作業です。モニター、スコアボード、カバレッジ・コードなどの受動検証コンポーネントは再利用できますが、システムレベルでは必要がなく無効にしなければならないこともあります。しかし、スタンドアロン・テストベンチで直接アクセスできる多くのインターフェイスは、統合後のデザインでは内部に隠れてしまうため、スティミュラス生成は大きく変わります。マルチダイ・システム用のシミュレーション・ソリューションは、スタンドアロン・テストベンチの同期実行をサポートする必要があります。これにより、分散シミュレーションへのマッピングが容易になるという利点が生まれます。

マルチダイ・システムに向けたシノプシスの検証ソリューション

シノプシスの機能検証ソリューションVCS^®は、強力かつ柔軟なアプローチによるマルチダイ・システムのシミュレーションを実現しています。図4に示した構成ファイルを使用して、単一の実行ファイルによるマルチダイ・システム・シミュレーションをサポートすることで名前衝突をなくし、完全なシステム・デザインとテストベンチをアセンブルします。また、シノプシスVCSは図5に示すようにマルチダイ・システムの分散シミュレーションをサポートすることで、検証容量とスケーラビリティの課題に対処しています。ダイは個別にコンパイルされるため、名前衝突の問題は起こらず、それぞれを個別のコンピューティング・サーバ上で実行できます。

シノプシスのVCS^®は、1つのシミュレーションをプライマリに指定し、このプライマリの制御によりクライアント-サーバ構成で非同期分散実行することが可能です。これにより、図5に示したようにわずかな同期ポイントだけですべてのシミュレーションのロックステップが維持されます。この分散アプローチにより、コンピューティング・リソースとメモリーの利用効率が大幅に向上し、クラウド運用ならではの弾力性とスケーラビリティも活用できます。前述の通り、ダイ間の接続は構成ファイルによって指定されます。このため、シミュレーション間の通信と同期の構造も構成ファイルによって指定されます。

VCSは、システムレベル・テストベンチと個々のダイレベル・テストベンチの両方をサポートするという要件も満たしています。図6に、利用可能な2つのモードを示します。上側のモードは、2つの別々のダイレベル・テストベンチを組み合わせ、これらを連携しながら同期実行します。下側のモードは、複数のダイにまたがる1つのテストベンチを実行します。いずれのモードでも、1つの実行ファイルの場合に比べシミュレーション容量が大幅に増大し、多くの場合性能も向上します。

シミュレーションの課題に加え、マルチダイ・システムではスタティック検証も複雑になります。シノプシスのSpyGlass^®プラットフォームによるクロック・ドメイン・クロッシング（CDC）およびリセット・ドメインクロッシング（RDC）チェックもその1つです。クロック・タイミングはダイ同士を接続するバンプやシリコン貫通ビア（TSV）の影響を受けるため、これに関連する遅延をモデル化するセルをテクノロジに含める必要があります。こうした複雑さを避けるには、接続を抽象化し、すべてのダイのクロック・ピンが非同期であり、したがってクロックがダイに対して異なる入力であるようなすべての信号にシンクロナイザが必要であるという単純な仮定を立てるようにします。

マルチダイ・システムでは、パワー・インテントの検証も困難です。パワー・インテントをファンクション・インテントに重ね合わせることのできるUnified Power Format（UPF）規格はありますが、マルチダイ・システムではこれは不可能です。ダイは事前に製造されているため、パワー機能はアーキテクチャに組み込まれています。1つのダイを分割すると、パワー・インテントも分割されます。しかし、ダイごとのパワー・インテント仕様と事前に定義された電源モード（オフ、スタンバイなど）があれば、シノプシスのマルチ電圧ローパワー・スタティック・ルール・チェッカーVC LP™は、モノリシックSoCと同様にマルチダイ・システムのパワー・インテントを検証できます。

最後に、ダイ間インターフェイスも検証する必要がありますが、最近ではUCIe（Universal Chiplet Interconnect Express）を採用する設計者が増えているため、この検証は容易になっています。シノプシスは、UCIe IPおよび検証用IP（VIP）の両方に関して業界で最も充実したソリューションを提供しています。シノプシスのUCIe  Controller and PHY IPをダイに統合し、すべてのシングルダイおよびマルチダイ・システム・シミュレーションでシノプシスのUCIe VIPを使用することで、重要なインターフェイスの動作の正しさを検証できます。

シノプシスは、マルチダイ・システム検証ソリューション以外にも、スケーラブルなマルチダイ・ソリューションを幅広くご提供しています。シノプシスの包括的なマルチダイ・システム・ソリューションにより、早期段階でのアーキテクチャ検討、迅速なソフトウェア開発とシステム・バリデーション、効率的なダイ/パッケージ協調設計、堅牢で安全なダイ間接続、高品質な製造、およびシリコン・ライフサイクル全体での信頼性が実現します。

マルチチップ・シミュレーションへの拡張

シノプシス・ユーザー会SNUG Silicon Valley 2023において、NVIDIAは実際のマルチチップ・デザインにVCSを適用した事例を発表しました。この中で、同社は以下の利点が得られたと述べています。

• 種類の異なるマルチチップ・シミュレーション環境を非常に簡単に作成できる
  • 「統合/再利用の悪夢」を完全に回避できた
  • マルチチップ環境という理由だけで参加チームに特別な作業が発生することがない
  • 各シングルチップ・シミュレーション環境の機能を完全に維持

• モノリシック実行ファイルの巨大なリソース・フットプリントを回避できた
  • メモリーや実行時間のペナルティが小さい
  • 各実行ファイルの通信オーバーヘッドは約10%と許容範囲内

NVIDIAのチームは、VCSの分散シミュレーションを使用した結果、柔軟性と性能が向上し、再利用が容易になったと述べています。事実、単一のシミュレーション実行ファイルを使用した従来のアプローチに比べ、全体的なシミュレーション速度が2倍以上に向上したとしています。

まとめ

マルチダイ・システムは、大規模SoCの分割およびディスクリート・チップの集約の両面で重要性と存在感を増しています。しかしマルチダイ・システム統合の利点を手に入れるには、比較的新しい複雑な検証作業の課題を克服しなければなりません。シノプシスのマルチダイ・システム検証ソリューションは、機能、CDCおよびRDCの正しさ、パワー・インテント、ダイ間接続に関して業界最高水準の検証手法をご提供します。検証チームは、マルチダイ・システムに移行して検証作業が不可能になったり、膨大なコンピューティング・リソースを消費したり、市場投入までの期間（TTM）が伸びたりすることを心配する必要がなく、マルチダイ・システムへの移行に踏み切ることができます。