テープアウトのタイミングを逃さない: Google Cloud による迅速なチップ設計
Google Cloud Japan Team
※この投稿は米国時間 2021 年 5 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウドはエンドツーエンドのチップ設計フローを加速させる実績のある方法を提供します。以前のブログでは、フロントエンドのシミュレーション ワークロードがより多くのコンピューティング リソースを利用することで、どのようにスケーリングを可能にしているかを例に、クラウド固有の弾力性をご紹介しました。クラウドのもう一つのメリットは、強力で最新かつグローバルなインフラストラクチャを利用できることです。オンプレミス環境は、継続する需要には素晴らしい効果を発揮しますが、電子設計自動化（EDA）ツールのアップグレードは、標準的なオンプレミスのデータセンター インフラストラクチャのアップグレード（3 年から 5 年ごと）よりもかなり頻繁に発生します（6 か月から 9 か月ごと）。
これはつまり、お使いの EDA ツールが適切なインフラストラクチャを利用していれば、さらに優れたパフォーマンスを達成できることを示しています。設計工程の特定のフェーズで特に有用です。
たとえば物理的な検証ワークロードで考えてみましょう。通常、物理的な検証はチップ設計の最終ステップとして行われます。この工程は、簡単に言うと、製造工場から提供される工程設計キット（PDK）に対して設計ルールのチェック（DRC）を検証するものです。物理合成工程から生み出されるレイアウトが、製造のため工場（自社またはその他）に渡される準備が整ったかどうか確認します。物理的な検証ワークロードは、高度なノードに対応する大容量メモリ（1 TB 以上）を搭載したマシンを必要とする傾向があります。このようなコンピューティング リソースを利用できると、より多くの物理的な検証を並列して実行できるので、テープアウトされる（製造工程に回される）設計の信頼性が高まります。
もう一つのフェーズは機能の検証ワークロードです。前述の物理的な検証工程とは異なり、機能の検証は通常、設計の早期段階で実施され、少ないメモリのマシンで対応できます。しかも、設計サイクルの大半の時間（コンピューティングの可用性に直接置き換えられる）を機能の検証（特にダイナミック検証）が占めます。多くの設計チームの目標である、検証のスピードを上げることは通常、適切なサイズのコンピューティング リソースの可用性に依存しています。
機能の検証と物理的な検証の両方に対応する、断続的で多様なインフラストラクチャ要件は、オンプレミスのデータセンターを持つ組織で問題となる可能性があります。オンプレミスのデータセンターは使用率を最大限高めるよう、最適化されています。最高のツール パフォーマンスを実現する適切なサイズのコンピューティングの利用に直接対処するものではありません。IT 部門とコンピュータ支援設計（CAD）部門が適切なハードウェアを追加でプロビジョニングすることを選択しても、新しいハードウェアをオンプレミスでプロビジョニング、獲得、セットアップするには、最先端の企業であっても、通常数か月かかります。ほとんどの場合オンプレミス クラスタを利用しますが、必要に応じてクラウド リソースもシームレスに利用できる「ハイブリッド」フローが理想的です。
ハイブリッド チップ設計の活用
より優れたコンピューティングをすぐに利用できるハイブリッド環境を活用することで、標準的な検証ワークフローを改善できます。たとえば、フロントエンド シミュレーション ワークフローを選択し、オンプレミス クラスタとクラウド クラスタを複製する環境を設計する例を考えてみましょう。環境の簡素化に関しては自由度が少しあります（後述します）。簡素化されたセットアップは GitHub リポジトリにありますのでお試しください。
ハイブリッド チップ設計フローでは、次のような重要な考慮事項があります。
オンプレミスとクラウド間の接続: クラウドへの接続を確立することは、設計フローの最も基本的なステップの一つです。これは長い年月をかけて理解が浸透した分野であり、高可用性を備えた安全な接続が大半のセットアップに実装されています。
Google のチュートリアルでは、オンプレミス クラスタとクラウド クラスタの両方をクラウドでの別の 2 つのネットワークとして提供し、このネットワーク間をすべてのトラフィックが通過できます。これは実際のネットワーク構成ではありませんが、基本的な接続モデルを説明するには十分です。ライセンス サーバーへの接続: 大半のチップ設計フローは EDA ベンダーから提供されるツールを活用します。このようなツールは通常ライセンス交付を受けていますが、ツールを動かすには有効なライセンスのあるライセンス サーバーが必要です。ライセンス サーバーへのレイテンシが認められる限り、ライセンス サーバーはハイブリッド フローのオンプレミスに保持できます。レイテンシを短縮するため、ライセンス サーバーを Compute Engine VM（特に単一テナントノード）上のクラウドにインストールすることもできます。クラウドにライセンス サーバーを再ホストできるかについては、EDA ベンダーと一緒に状況を確認する必要があります。
Google のチュートリアルではオープンソース ツール（Icarus Verilog シミュレータ）を使用していますので、ライセンス サーバーは不要です。データソースを特定し、データを同期する: 実行中の EDA ジョブには、EDA ツール自身、ツールが実行されるインフラストラクチャ、ツール実行用のデータソースという 3 つの重要な要素があります。ツールはあまり変更せず、クラウド インフラストラクチャにインストールできます。一方、データソースは主にオンプレミスで作成され、定期的に更新されます。これには、設計を記述した SystemVerilog ファイル、テストベンチ、レイアウト ファイルなどが含まれます。同一性を維持するには、オンプレミスとクラウド間のデータを同期することが重要です。さらに、本番環境では、高パフォーマンス同期メカニズムを維持することも重要です。
Google のチュートリアルでは、皆様のオンプレミスにあるファイル システム階層と類似したものをクラウドに作成します。ツールを呼び出す前に、最新の入力ファイルを転送します。ワークロード スケジューラ構成とジョブ送信の透明性: バッチジョブを活用する大半の環境はジョブ スケジューラを使用してコンピューティング ファームにアクセスします。最適な環境では、コストとパフォーマンスのバランスが保たれ、ジョブ スケジューラへの予測（予防）ラッパーを実現するため、システム内でパラメータが構築されます（後述の図を参照）。Google のチュートリアルでは、オープンソースの SLURM ジョブ スケジューラと自動スケーリング クラスタを使用します。わかりやすくするため、このチュートリアルには、ジョブ送信エージェントは含まれません。
他のクラウドネイティブ バッチ処理環境（Kubernetes など）も、ワークロード管理向けにさらにオプションを提供します。
Google のオンプレミス ネットワークは「onprem」と呼ばれ、クラウド クラスタは「burst」と呼ばれます。「onprem」クラスタと「burst」クラスタの特徴は次の図をご覧ください。
セットアップが完了したら、シングルタイル構成と 2 タイル構成用の OpenPiton 回帰を実行します。結果は次の表をご覧ください。
「burst」クラスタで実行される回帰は「onprem」での実行よりも平均 30% 速く、検証のサインオフまでと物理的な検証の処理時間が短縮されます。使用したコマンドの詳細はリポジトリで確認できます。
市場投入までの時間を短縮するハイブリッド ソリューション
もちろん、オンプレミスのデータセンターは引き続きチップ設計において重要な役割を果たすでしょう。とはいえ情勢は変化します。クラウドベースの高パフォーマンスのコンピューティングは、これ自体がチップ設計工程においてオンプレミスのデータセンターを拡張できる、実績ある実行可能なテクノロジーです。ハイブリッド チップ設計フローの活用に成功している企業は、エンジニアリング チームの流動的なニーズに適切に対応できます。Google Cloud でのシリコン設計について詳しくは、ホワイトペーパー「Google Cloud を使用してチップ設計プロセスを加速する」をご覧ください。
-シリコン ソリューション チーフ アーキテクト Sashi Obilisetty
-ビッグデータ ソリューション アーキテクト Mark Mims
