AWS ベースの EDA 環境で Rebellions の次世代 AI NPU 開発を加速する

(この記事は、 AWS 기반 EDA 환경으로 Rebellions의 차세대 AI NPU 개발 가속화하기 を翻訳したものです。)

先端半導体の開発においては数多くの Logic Simulation を繰り返し、DFT（Design for Test）や Physical Design のように高いコンピューティング性能を必要とする EDA（Electronic Design Automation）作業を実行する必要があります。設計規模と検証範囲が大きくなるほど、必要な CPU コアやメモリ、共有ストレージのスループットもあわせて増加します。必要な時点で十分なインフラを確保できなければ、EDA ツールの実行時間やジョブの待ち行列が長くなり、開発スケジュール全体に影響を及ぼす可能性があります。

AI 推論用 NPU を開発する Rebellions は半導体設計プロセスの Design Verification（DV）と Physical Design（PD）業務に AI Transformation（AX）を適用し、エンジニアの生産性を約 3 倍に向上させました。しかし、エンジニアリング業務の生産性が高まった後も相対的に長い EDA ツールの実行時間が全体の開発速度を制約し、新たなボトルネックとして浮き彫りになりました。

Rebellions はこのボトルネックを解消して設計開発全般の生産性をさらに高めるため、実際の NPU 開発ワークロードに基づいて AWS 環境における EDA の性能と拡張性を検証しました。

本記事では AWS ParallelCluster と Amazon FSx を活用した EDA 環境の構成とともに、Logic Simulation、DFT、Physical Design の各ワークロードで確認した性能改善の結果を紹介します。

Rebellions の紹介

Rebellions は AI 推論用の NPU チップからコンパイラを含むソフトウェアまでを自社で開発する、AI 推論専用のフルスタック・ファブレス・スタートアップです。大韓民国政府が設立した国民成長ファンドの第 1 号投資企業として国家のソブリン AI インフラエコシステムを先導しており、APAC、中東、欧州などのグローバル市場へ事業を拡大しています。

データセンターインフラ向けの第 1 世代 NPU である ATOM の商用化に成功しました。ATOM は大規模なトラフィックが発生する SKT の「エイダット」通話要約サービスなどに採用されています。また、大韓民国初の NPU-as-a-Service を構築しました。

第 2 世代 NPU である Rebel100（以下 R100）は最高の performance-per-watt と韓国初のペタフロップス級の性能を基盤に、エージェンティック AI の時代に求められる CPU–NPU 統合最適化と、サーバー単位からトークンファクトリー単位まで拡張可能なアーキテクチャを提供します。これにより多様な次世代 AI ワークロードに柔軟に対応できます。2026 年初めに量産に着手し、2026 年下半期から多様な顧客環境へ本格的に適用される予定です。

今後はより多様で複雑化する AI ワークロードに最適化された性能を提供するため、次世代のメモリ中心構造（memory-centric architecture）と HW–SW co-design を中心に、技術および製品アーキテクチャの発展の方向性を継続的に模索していく計画です。

NPU 開発の次のボトルネック、EDA 実行時間

EDA ワークロードは作業によって必要とするリソースの特性が異なります。Logic Simulation は機能や設定、乱数 seed に応じて生成される多数の独立したジョブを限られた時間内に処理しなければなりません。DFT と Physical Design は高い CPU 性能だけでなく、大容量メモリと高速なファイルアクセス性能を必要とします。

こうした作業を固定されたオンプレミスインフラで実行すると、2 つの問題が生じます。まず、プロジェクトのピーク需要を基準に機器を購入すると、平常時にはリソースが余ります。逆に、平均需要に合わせて機器を構成すると、regression や設計マイルストーンのように作業が集中する時期に待ち時間が長くなります。

高性能サーバーを 1 台追加するだけではすべての問題を解決することはできません。Logic Simulation のように独立したジョブが多いワークロードでは並列処理能力が重要であり、Physical Design には高いクロックと十分なメモリを備えたインスタンスが必要です。複数のジョブが共通の設計データやライブラリに同時にアクセスするため、共有ストレージとネットワークの性能もあわせて確保する必要があります。

Rebellions は EDA 作業ごとに適したコンピューティングリソースを選択し、regression や設計マイルストーンのように作業が集中する時点で大規模な実行容量を確保できるかを確認するため、AWS ベースの EDA 環境を検証しました。

図 1. AX と EDA 実行環境の改善による NPU 開発期間の短縮

EDA ワークロードで AWS が提供するメリット

オンプレミスの EDA ファームではプロジェクトの開始前にコンピューティングとストレージの需要を予測して機器を購入する必要があります。Rebellions が新規の高性能サーバーを検討した際には、発注後に最低 20 週のリードタイムが必要で、設置と実際の利用開始までを考慮すると 6 か月から 8 か月待たなければなりませんでした。また、EDA の需要は full regression、DFT、Physical Design など特定の時期に集中するため、ピークを基準に機器を購入すると平常時にリソースが余り、平均需要に合わせると重要な時期にジョブの待ち時間が長くなります。

AWS ではプロセッサアーキテクチャや CPU 性能、メモリ、ローカルストレージ、ネットワーク構成がそれぞれ異なる Amazon EC2 インスタンスの中から、EDA 作業に適した構成を選択できます。たとえば r8i は Intel Xeon 6 プロセッサと大容量メモリを必要とする x86 ベースの EDA 作業に活用できます。c8g は AWS Graviton4 プロセッサを搭載した Arm ベースのインスタンスで、使用している EDA ソフトウェアと関連ライブラリが Arm64 をサポートしていれば、よりコスト効率を高める選択肢として検討できます。x8aedz は高いシングルコア性能と大容量メモリ、ローカル NVMe ストレージを必要とする Physical Design や大規模な EDA 作業に適した選択肢です。これらのインスタンスを作業の特性に応じて選択し、必要な時点で拡張することで、サーバーの購入・設置にかかる時間を短縮し、必要なタイミングに合わせて実行環境を構成できます。

図 2. AWS ParallelCluster と Amazon FSx を活用した EDA リファレンスアーキテクチャ

AWS ParallelCluster は Slurm ベースの EDA クラスターの構築と管理を簡素化します。ユーザーが従来と同じ方法でジョブを投入すると、待機中のジョブに合わせて Amazon EC2 のコンピューティングノードを作成し、ジョブの完了後に使われなくなったノードを減らします。Logic Simulation、DFT、Physical Design のように要求仕様が異なる作業をそれぞれ別の Slurm キューと EC2 構成に紐づけることもできます。最小コンピューティングノード数を 0 に設定すれば、full regression や設計マイルストーンのときだけ多くのコンピューティングリソースを使用し、平常時はすべてのコンピューティングノードを終了できます。

EDA ツールは多数のソースファイルやライブラリを読み込み、ログ、waveform、中間結果を繰り返し書き込みます。複数のコンピューティングノードが同じデータに同時にアクセスするため、共有ストレージのスループットだけでなくアクセスレイテンシーも重要です。AWS では EDA ワークロードの特性に適した Amazon FSx for OpenZFS と Amazon FSx for NetApp ONTAP という高性能ストレージの選択肢を利用できます。

半導体の設計ファイルは企業の中核的な資産であるため、クラウド環境でも外部への流出を防止できる統制が必要です。EDA 環境をお客様が管理する AWS アカウントと VPC のプライベートサブネットに配置し、データセンターからは AWS Site-to-Site VPN を介してのみアクセスするように構成すれば、設計ファイルとコンピューティング環境をインターネットに公開しません。IAM とセキュリティグループによって許可されたユーザーとシステムのみがアクセスできるように制限し、保存データを暗号化するとともに、AWS CloudTrail でユーザーのアクティビティを監査し、Amazon CloudWatch Logs でシステムとジョブのログをモニタリングできます。これにより、設計ファイルを統制されたネットワークと権限の境界内で管理し、外部流出に対する懸念を軽減できます。

Rebellions が適用した EDA on AWS アーキテクチャ

Rebellions は前述した AWS のコンピューティングとストレージの選択肢のうち、AWS ParallelCluster、Amazon EC2 x8aedz および c8g インスタンス、そして Amazon FSx for OpenZFS ストレージを使用して検証環境を構成しました。Rebellions のデータセンターと AWS VPC は AWS Site-to-Site VPN で接続しました。

図 3. Rebellions EDA on AWS 検証アーキテクチャ

EDA エンジニアは Site-to-Site VPN を介して AWS ParallelCluster の Slurm スケジューラーにジョブを投入し、データセンターの RTL 設計ファイルを Amazon FSx for OpenZFS にアップロードします。待機中のジョブが発生すると、必要な Amazon EC2 x8aedz コンピューティングノードが作成され、Logic Simulation、DFT、Physical Design のジョブを実行します。ジョブが完了してアイドル状態になると、すべてのコンピューティングノードは終了し、ヘッドノードと Amazon FSx for OpenZFS、EDA ライセンスサーバーは維持されます。コンピューティングノードでは FSx for OpenZFS の高性能ストレージをマウントして EDA ツールや設計データ、作業領域、結果を共有し、クラスターとジョブのログは Amazon CloudWatch Logs で確認できます。

ファイルアクセス性能の比較

EDA 作業はソースコードやライブラリだけでなく、大量のログ、waveform、中間成果物に繰り返しアクセスします。特に多くのジョブが同時に実行される場合、共有ファイルシステムとネットワークのスループットおよびレイテンシーが全体のスループットを制約する可能性があります。

Rebellions は実際の EDA 作業を実行する前に、オンプレミスの NFS と AWS のストレージシステムのファイルアクセス性能を比較しました。

項目	Rebellions オンプレミス NetApp C400A, 40G Ethernet	AWS EC2 FSx for OpenZFS, 75G Ethernet	性能改善倍率
シーケンシャル書き込み	108MB/s	855MB/s	約 7.9 倍
シーケンシャル読み込み	67MB/s	1,229MB/s	約 18.3 倍
並列書き込み（4 ストリーム同時）	112MB/s	1,134MB/s	約 10.1 倍
4KB ランダムアクセスのレイテンシー	2.98ms	0.10ms	約 29.8 倍

AWS 環境はシーケンシャル書き込みで約 7.9 倍、シーケンシャル読み込みで約 18.3 倍、4 ストリームの並列書き込みで約 10.1 倍高いスループットを示しました。4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。

こうした差にはストレージ自体の性能だけでなく、ネットワーク帯域幅とリソースの割り当て方式も影響しました。オンプレミス環境では 10Gbps イーサネット 4 回線を複数のコンピューティングサーバーで共有し、個々のサーバーは最大 10Gbps の帯域幅を使用していた一方、AWS 環境では個々の Amazon EC2 インスタンスに最大 75Gbps のネットワーク帯域幅が提供され、7 倍以上の帯域幅を活用できました。また、オンプレミスのストレージは全社で共有するリソースでしたが、Amazon FSx for OpenZFS は今回の EDA ワークロード専用に割り当てられ、他のワークロードの I/O の影響を受けませんでした。

単一の Logic Simulation ジョブで CPU 処理が中心であれば、ストレージのスループットが 10 倍に増えても、アプリケーションの実行時間が同じ比率で短縮されるわけではありません。共有ストレージのメリットは多数のジョブが同時にデータを読み込み、ログや結果を書き込む際により明確に表れます。

Logic Simulation 性能の比較

Logic Simulation は半導体を製造する前に、RTL（Register Transfer Level）で記述した回路が意図したとおりに動作することをソフトウェアで検証する作業です。検証対象の RTL（回路設計）ごとに 1 回あたり数分から数十時間かかるテストを数万件、それぞれ数十回繰り返す必要があります。

今回の比較では EDA ツールとして Synopsys VCS を使用し、Rebellions が保有するオンプレミスサーバー（Intel Xeon Processor ベース）の物理コア数に合わせて、最大 64 個のジョブを同時に実行しました。EC2 では多様な CPU とメモリ構成のインスタンスが提供されているため、ワークロードの特性に合った構成を選択できます。今回の実験では多数の物理コアと高いシングルコア性能に加えて、大容量メモリをあわせ持つ x8aedz コンピューティングノード（AMD EPYC 9R45 ベース）と、コスト効率の高い c8g コンピューティングノード（AWS Graviton4 ベース）の結果を比較しました。

テストした UCIe IP と Network-on-Chip の両ワークロードにおいて、AWS 環境はオンプレミス環境よりも一貫して短い実行時間を示しました。同時ジョブ数が 1 個、16 個、32 個、64 個と増加する間、AWS x8aedz コンピューティングノードでのシミュレーションはオンプレミス比で 2.3 倍から 2.6 倍速く完了し、AWS c8g コンピューティングノードでも約 1.3 倍速く完了しました。

図 4. UCIe IP と Network-on-Chip の Logic Simulation 性能比較

Logic Simulation には Synopsys VCS® のような商用シミュレーターのライセンスが必要なため、コンピューティングリソースとライセンス数量のバランスを取ることが重要です。韓国内外の大企業のように Site Licensing を結んでいる場合は、サーバー（CPU core）の数を多く増やして Simulation スループットを確保するのも一つの方法ですが、限られた数のライセンスを運用するスタートアップには、高いシングルコア性能によって個々のジョブ時間を短縮し、保有するライセンスを効率的に活用するアプローチが必要です。

したがって Logic Simulation 環境ではライセンス数量と作業の特性に合わせてコンピューティングリソースを選択する必要があります。AWS では高いシングルコア性能、多数の CPU コア、大容量メモリ、ローカル NVMe ストレージなど、それぞれ異なる特性を持つ多様な Amazon EC2 インスタンスを選択できます。これにより、個々のシミュレーションの実行速度と大規模並列ジョブのスループットを考慮して適切なコンピューティング構成を使用し、必要な時点でのみ拡張できます。

Design for Test（DFT）設計性能の比較

DFT は製造されたチップの欠陥を検査できるよう、診断回路を設計に挿入するプロセスです。数多くの回路で発生しうる多様な欠陥を短時間で検出しつつ、チップの機能と性能への影響を最小限に抑える必要があるため、高い CPU 負荷とストレージ I/O が発生します。

今回の実験では R100 の Neural Core と Shared Memory を対象として、Synopsys TestMAX を使用しました。ジョブ全体の実行時間を合計すると、オンプレミスでは 11 時間 51 分、AWS x8aedz コンピューティングノードでは 4 時間 41 分かかりました。同一のジョブセットを基準に、AWS 環境が約 2.5 倍速く完了しました。

DFT 対象	作業種別	オンプレミス	AWS x8aedz	性能倍率
Neural Core	Memory Built-in Self Test	4 時間 44 分	1 時間 54 分	約 2.5 倍
Neural Core	Scan Insertion	1 時間 40 分	38 分	約 2.6 倍
Shared Memory	Memory Built-in Self Test	2 時間 26 分	1 時間 16 分	約 1.9 倍
Shared Memory	Scan Insertion	3 時間 1 分	53 分	約 3.4 倍

Physical Design 性能の比較

Physical Design はコードで記述された半導体の設計図である RTL から、ファウンドリで製造する物理的な回路レイアウトデータである GDSII を作成するプロセスです。論理合成（RTL Synthesis）、Floor Planning と Placement、Clock Tree Synthesis、Routing、Timing および Power Optimization など、非常に複雑な段階で構成されます。

Physical Design は CPU 負荷とメモリ要求量の大きい作業であり、そこで使用される EDA ツールのライセンスは設計インフラの中で最も比重の大きい投資項目です。したがって EDA ツールを効率的に活用して 1 回あたりの実行時間を短縮するためには、高性能 CPU を確保することが非常に重要です。今回の実験においても R100 の Neural Core を対象に Synopsys Fusion Compiler™ を使用して性能を比較しました。

作業種別	オンプレミス	AWS x8aedz	性能倍率
Logic Synthesis	101 時間	54 時間	約 1.9 倍
Clock Tree Synthesis	75 時間	34 時間	約 2.2 倍
Route	90 時間	41 時間	約 2.2 倍
合計	266 時間	129 時間	約 2.1 倍

オンプレミス環境では上表の全作業に 266 時間かかりましたが、AWS 環境では 129 時間で完了しました。約 11 日かかっていた 1 回の実行を約 5.4 日に短縮し、全体の時間を約 2.1 分の 1 に短縮しました。

今回の結果は、高性能 CPU と大容量メモリを備えた AWS のコンピューティング環境の活用により、長時間実行される Physical Design の反復サイクルを短縮し、EDA ツールをより効率的に活用できることを示しています。

検証結果が示すもの

今回のテストでは次の結果を確認しました。

ファイルアクセス性能は項目に応じて約 7.9 倍から 18.3 倍高いスループットを示し、4KB ランダムアクセスのレイテンシーは約 30 分の 1 と測定されました。
Logic Simulation は 1 個から 64 個の同時ジョブの条件で 2.3 倍から 2.6 倍速く完了しました。AWS Graviton Processor によってコスト効率を高めた c8g インスタンスでは 1.2～1.4 倍速く完了しました。
DFT 作業は 11 時間 51 分から 4 時間 41 分に短縮され、約 2.5 倍速く完了しました。
Physical Design は 266 時間から 129 時間に短縮され、約 2.1 倍速く完了しました。

この結果は最新のプロセッサと大容量メモリ、高帯域ネットワーク、独立して割り当てた共有ストレージが組み合わさったテスト環境の効果です。いずれか 1 つのサービスだけで全体の改善を説明することはできません。

より重要な変化は開発需要が発生した時点で多くのコンピューティングリソースを集中的に投入できる点です。Logic Simulation の大量の待ちジョブに対しては複数のコンピューティングノードを同時に拡張し、Physical Design に対しては高いクロックと大容量メモリを備えたインスタンスを割り当てることができます。ジョブの終了後に動的コンピューティングノードを減らすことで、短いピーク需要のために同じ規模のサーバーを常時保有する必要性も低下します。

コストを評価する 3 つの観点

クラウドとオンプレミスのコストは時期や契約、運用方式によって異なるため、単純なサーバー価格だけで比較するのは困難です。ここでは具体的なコストの数値を断定するのではなく、Rebellions が EDA 環境を検討する中で考慮した 3 つの基準を見ていきます。

まず、開発開始の時点に合わせて最上位のサーバーを導入するのは容易ではありません。新規サーバーを選定して発注すると最低 20 週のリードタイムが必要で、配送と設置を経て実際に使用できるようになるまで 6 か月から 8 か月待たなければなりません。開発スケジュールに間に合わせるには、少なくとも 6 か月前に機器を発注しなければならないということです。機器が予定どおり導入されたとしても、開発の開始が 6 か月遅れたらどうなるでしょうか。実際の開発においては、1 世代前のサーバーを使うことになる可能性があります。AWS では開発が始まる時点で利用可能な最新世代の高性能 CPU を選択し、必要な規模のコンピューティングリソースをプロジェクトに合わせて構成できます。

次に、スタートアップがオンプレミスを導入するにあたっては、すべてのワークロードの最大要求量を考慮して CPU 性能、メモリサイズ、ストレージを選定することになるため、個々の EDA ジョブにとっては不要なリソースを使用する非効率が生じます。オンプレミス環境では複数の EDA ワークロードの最大要求仕様を考慮してサーバーを導入しなければならないため、作業によってはリソースが非効率に使われる可能性があります。たとえば、Physical Design 作業には約 400GB～1TB の大容量メモリが必要です。Rebellions が導入したオンプレミスサーバーはすべて 3TB のメモリを搭載しており、開発の前半には Simulation に、後半には Physical Design に活用しています。一方 Simulation ジョブの場合、IP は 2GB～30GB 程度のメモリしか必要としないため、開発の前半ではリソースを非効率に活用していることになります。ストレージのコストも考慮する必要があります。Rebellions が検討した最新型の 500TB 級ストレージは 10 億ウォンから 20 億ウォンの水準でした。ストレージは平均使用量とピーク使用量の差が大きいものの、オンプレミスではピークを基準に高性能・大容量のシステムをあらかじめ構築しておく必要があります。想定したピークの容量や性能を超えると、実行中の EDA ジョブが中断されるという深刻な問題が発生するおそれもあります。一方 AWS ベースのコンピューティングクラスターでは、ストレージへの大規模な初期投資を抑え、実際の使用パターンに合わせて適切な CPU と必要なストレージ容量を構成できます。

最後に EDA ツールの活用度もあわせて評価する必要があります。高性能な EDA ツールを低性能のサーバーで長時間実行すると、ライセンスを十分に活用することは困難です。したがって EDA 環境のコストは、コンピューティングリソースの時間あたり単価だけでなく、高性能なコンピューティング環境で完了したジョブ数や短縮した実行時間、ライセンスの活用効率を基準に評価すべきです。

おわりに – 真の開発の加速

AX によってテスト生成や分析など、エンジニアの業務効率を大きく高めたとしても、EDA ツールの実行時間がボトルネックとして残っていれば、開発期間全体の短縮には限界があります。ソフトウェア開発手法の革新と、それを支えるコンピューティングインフラがともに改善されなければならないのは、このためです。

Rebellions は実際の NPU 開発ワークロードを AWS で検証し、Logic Simulation、DFT、Physical Design の実行時間を短縮し、共有ストレージのファイルアクセス性能を高められることを確認しました。また、最新のクラウドコンピューティングインフラがサーバー調達リードタイムの長さやピーク需要に合わせたストレージへの過剰投資など、オンプレミス環境の限界を補うことのできる現実的な代替手段であることを確認しました。

AWS ベースの EDA 環境の価値は単により高速なサーバーを 1 台使うことにあるのではありません。作業の特性に合ったコンピューティングとストレージを選択し、regression や設計マイルストーンに大規模なリソースを集中的に投入した後、作業が終われば再び縮小できる点にあります。これにより、固定されたインフラ容量が原因で生じるジョブの待ち時間を短縮し、設計の反復結果をより早く得ることができます。

Rebellions は AX によるソフトウェアの革新と AWS の弾力的なコンピューティングインフラが生み出すシナジーを基盤に、次世代 AI NPU の開発をさらに加速し、グローバル市場に競争力のある AI 推論ソリューションを迅速に送り出してまいります。

参考資料

著者について

翻訳はソリューションアーキテクトの酒井賢が担当しました。原文はこちらです。

Amazon Web Services ブログ