AIの普及によって、半導体業界の基本的な事実が変わったわけではない。ハードウェアとソフトウェアの開発は、依然として多くの場合、別々の経路で進められている。Semiconductor Engineeringが2026年9月15日に公開した分析によると、両者の協調設計の利点は何年も前から知られているが、それを広範に適用することは、AIがまだ解決していない組織的・技術的な障壁に阻まれている。
問題は、まず作業チームの構造そのものから始まる。ハードウェアとソフトウェアのエンジニアは異なるツールや言語を使用し、同期していないスケジュールと開発ペースで作業している。従来のモデルでは、設計がチップの製造段階に到達してから、ソフトウェアチームがシステムをチップに適応させる。その中には、errataとして知られる変更や既知の不具合への対応も含まれる。MIPS/GlobalFoundriesのソフトウェアおよびツール部門責任者であるSam Groveは、この状況を、ソフトウェアチームが次世代の設計に参加するのではなく、製品の稼働を余儀なくされる、遅れた引き渡しだと表現している。
隔たりは組織面だけではない
企業が継続的インテグレーションを導入しようとしても、信頼できる結果を得るまでの速度は依然として中心的な障壁である。Synopsysでシステムソリューションの戦略プログラム担当エグゼクティブディレクターを務めるFrank Schirrmeisterは、仕様からハードウェアとソフトウェアのモデルへ移行する作業は非常に高速化できるが、それにはシステムを十分な速度でシミュレーションできる能力が必要だと指摘する。
仮想プロトタイプ、シミュレーション、emulationツール、FPGAベースのモデルは存在するが、それぞれ精度、性能、実行時間の間で異なるトレードオフを伴う。仮想モデルはソフトウェアがアーキテクチャに与える影響を早期にテストするのに役立つ一方、より詳細なシミュレーションやモデリングは、性能や電力についてより優れた洞察を与える。しかし、最終製品を代表する完全なワークロードを実行することは、小規模な機能や人工的なワークロードをテストするよりはるかに難しい。
チームが仮想プラットフォームからemulation、さらにFPGAベースのモデル、そしてシリコンへと、複数の段階にわたって同じワークロードを実行しようとすると、難しさはさらに増す。チップの実行時間で10秒分のテストをシミュレーションで行うことは実用的でない場合があり、単一のモデルですべての用途をカバーできると仮定するのではなく、各段階で実行可能な部分を特定する必要が生じる。
共通仕様はAIに先立つ条件
専門家は、最初に必要なのは、エンジニアとAIエージェントが共同で利用できる、豊富で統合された仕様を作成することだと考えている。記事によると、現在これを実行しているのは限られた分野だけで、その一つが軍需・宇宙産業であり、そこではより広く行われている。この種の仕様がなければ、AIには、システム要件をRTL設計、ソフトウェア、検証結果へ結び付ける統一された参照先がない。
人工的な実験は、複数のアーキテクチャ上でソフトウェア機能を実行する時間や消費電力の測定に役立つ可能性があるが、それだけでは設計上の意思決定を行うには不十分である。エンジニアは、柔軟性と性能、コストとサイズ、電力予算、熱、環境要因の間でもバランスを取る。Normal Computingの検証ソリューションエンジニアであるArvind Srinivasanは、最も高性能な設計の一つがタスク専用に完全カスタマイズされたものになる可能性がある一方、これらすべての制約をAIアルゴリズムが最適化可能な目標として利用できるよう、統一的に符号化する方法はまだ存在しないと述べている。
AIは現在何ができるのか？
現在の用途は、AIがシステム全体を設計するという考えよりも限定的である。Siemens EDAの主任製品マーケティングマネージャーであるAndy Meierは、顧客が主にRTLやテスト環境の生成にAIを利用していると述べる一方、アーキテクチャ上の意思決定において同程度の規模で利用されているとは考えていない。これは、こうした意思決定に、性能、電力、コスト、ワークロードの挙動の間にあるトレードオフについての幅広い知識が必要だからである。
一方、MIPS/GlobalFoundriesは、特定のタスクにおけるソフトウェアとハードウェアの記述にAIエージェントを利用しており、ツールの限界と誤りを理解することの重要性を強調している。Quadricの最高マーケティング責任者であるSteve Roddyも、設計モデルの構築からシリコンの完成に至るまでの期間に、開発者やAIアシスタントによってソフトウェアが何度も変更される可能性があると指摘する。これは、協調設計がプロジェクトの開始時に一度だけ行う決定ではなく、ソフトウェアの継続的な変化に対応しなければならないプロセスであることを意味する。
Normal Computingは、AIを利用してハードウェアのより抽象度の高い表現を抽出し、RTLが完成する前にソフトウェア開発者が作業できるようにする可能性を提示している。この構想は、仕様またはontologyの表現が共通の参照先になり得ることに基づいているが、その表現を後続のモデルに結び付け、整合性を検証する必要性をなくすものではない。
検証と協業がボトルネック
分析は、既存の方法論を全面的に置き換えるとプロジェクトのリスクが高まるため、進展は段階的になる可能性が高いと指摘している。Srinivasanによると、EDAツールはいまだに問題全体の成果を改善するのではなく、問題の小さな部分を処理している。また、ブラックボックスには、正しさの保証、監査可能性、設計要素と検証結果の関係を明らかにする統一された記録が必要である。
モデル間の同期も、実務上の課題として残っている。タイミングが未定義のSystemCにおける高位モデルは、時間的精度の点でRTLと同等ではなく、両者の整合性を維持するには、検証、認証、ソフトウェアの準備に多大な時間がかかる。したがって、仮想モデルを提供するだけでは不十分であり、シミュレーションおよび分析モデルの連続した連携、設計チームとアプリケーションチーム、顧客サポートチームの間での知識移転が必要になる。
certi.newsの観点では、実際の変化は、単一のツールを投入することでも、業界が直ちにAI主導の自律設計へ移行することでもない。変化とは、チップが完成する前からソフトウェアがアーキテクチャの定義に影響を与え始めたこと、そしてEDAツールがこれまで分離されていた段階を結び付けようとしていることである。しかし、この記事はこの問題が解決されたことを示す証拠を提示しておらず、統一仕様の不足、シミュレーションのコスト、ソフトウェアの変化、監査可能性の必要性が依然として基本的な制約であることを明らかにしている。したがって、アーキテクチャ上の意思決定では人間の専門知識が引き続き決定的に重要であり、AIの影響は、テストと結果のレビューが可能な特定のタスクに集中することになる。