実は生成AI/MMLを活用する機会について、モデレータであるHarry Foster氏からパネルディスカッションに声をかけられた半年前と今とでは、私の答えは大きく異なっている。半年前はどのようなメリットが得られるのか、ツールをどのような状況で使用するべきかなど、かなり慎重に検討していた。しかし今では、設計や検証のフローに付随するすべての作業において、生成AI/LLMを活用できない部分はまったくない、という考えに至っている。

逆に生成AI/LLMを活用するというビジョンを実現する上での課題、障害は、遭遇する問題のほとんどは技術的というよりカルチャー的なものに帰すると考えている。エンジニアはスケジュールに追われ、設計や検証のさまざまなマイルストーンの達成に追われている。生成AI/LLMをうまく活用するには、彼らは一歩、ステップバックして、問題を少し異なる視点、適切な抽象度で考えることができるように支援する必要がある。
そしてほとんどのエンジニアはデータの扱いやプロンプトに精通していない。つまりそのような教育を受けてきていないからであり、それが現在直面している課題であると言える。

私の役割は設計や検証におけるメソドロジの検討だが、その一環として、生成AI/LLMを検討している。特にLLMには興味深い可能性を期待している。Erikが一歩ステップバックすると表現した部分は恐らく、仮にEDA GPTのようなものがあって、それに正しい設計を依頼するにしても、何から設計させるのか、何が正しいのかを考える必要があり、つまりは仕様がより重要になるということだと思う。

そしてハードウェア設計や検証に関しては、そのドメインのエキスパートであることが必要だが、生成AIを使う上で必ずしもドメイン・エキスパートでなくても良くなる可能性がある。生成AIのツールとは自然言語でやり取りするので、ツールの操作についても自然言語で思考する事ができる。生成AIにコードを生成させることもできるだろうし、コード生成というコア機能の周囲にフレームワークを構築することすら、自然言語で実現できる可能性がある。ワークフローの一部だけでなく、完全なワークフローを自然言語によって自動化できれば、それによって設計や検証が次のレベルに移行することになるだろう。

障害や課題に関して言えば、モデルをトレーニングする際のデータについて確信できる法的枠組のようなものが必要になると思う。生成AIをワークフローのどこに統合するかによりセキュリティ要件に影響を与える可能性もある。加えてLLMを活用するためには、膨大なコンピューティング資源が必要になることも忘れてはいけない。となると持続可能な方法で活用できるかどうかは、今後ますます重要になる。

チップの設計検証に関して生成AI/LLMの活用機会は様々あり、Coding Assistance、Know-How Assistance、Analysis Assistance、Debug Assistance、Optimization Assistanceに大別される。

Coding Assistanceは設計や検証のコーディングに関するもので、RTLコード、ソフト、テストベンチ、ツールスクリプト、コンフィギュレーションなどの生成が対象となる。仕様書からコードやアサーションの生成、高位記述から低位記述の生成、既存コードからより高効率のコードの生成などがある。

Know-How Assistanceは設計、インフラ、ツール、フローについて存在する大量のドキュメントから、洞察やアイデア、情報を生成するものである。
Analysis Assistanceはログやレポートなどを基にサマライズ、アナライズ、ビジュアライズに関する支援を行う。Debug-Assistanceは例えばリグレッションにおけるフェイル、物理設計におけるタイミングフェイルなどに合わせて、どのようにトリアージして解決するかに関する支援である。
Optimization Assistanceはカバレッジクロージャ、最適化のレシピ、アーキテクチャ探索などに関するものである。

課題としては、例えばAnalysis-Assistanceでは扱うファイルが膨大となること、Coding-AssistanceではHWコードのトレーニングデータ、ベンチマークデータが充分ではないなどがある。Debug-Assistanceでは現在はEDAツールを呼び出しているが、設計の論理を理解しモデリングする際に、ハードウェア内でのリーズニングをモデリングする研究を進めている。

生成AI/LLMの重要な要素は1)充分なデータ、2)充分な計算機資源、そして3)優れたモデルである。データ量については例えばGitHub上にあるデータ、計算機資源についてはNVIDIAの環境などが活用できる。モデルについても近年開発が進んでおり一定の成熟も見られる。そして機能検証において生成AI/LLMはまだ初期段階であり、既存ツールを補完するものとして見ている。その理由を３つ挙げる。

１つ目の理由は、例えばGitHub上のデータについても高品質の検証データが少ないという現実がある。星の評価数で言えば、その多くはRISC-Vプロジェクトであるが500ほどしかない。他の人気あるプログラミング言語での星の評価数は50万にもなる。

理由の２つ目は、ASICやSoCなどモデルそのものが大規模で、生成AI/LLMが扱うには大き過ぎるという問題がある。現在生成AI/LLMの対象となっているテキストはおよそ10万トークンであり、これはRTLの行数に換算すると1000行程度にしかならない。つまりスケーラビリティの問題があることになる。

理由の３つ目は法的な懸念点である。Siemens内部のプロジェクトではCopilotを採用したが、Copilotを使っていても誰かのコピーライトに抵触する可能性があり、コード引用を明確にしなくてはならない。そこでGitHubに直接問合せし、引用を明確にする限りGitHubが法的な責任を負うとのコミットを得て活用している。しかし法的な案件には常にグレーゾーンが存在することも事実である。

以上のような理由から、機能検証において生成AI/LLMの活用度はまだ初期段階、既存ツールを補完するものと捉えている。

得られたコードの正当性について、GPTの活用方法というべきか、合理性のある期待値設定について、私の考えを述べたい。仮に１万ものソリューションが量産され提示されても、開発の生産性は上がらないだろう。生成によって常に正しい結果が得られるのではなく、活用プロセスに人が介在し、レビュープロセスが存在するべきだと思う。作業の９割、例えばキータイプの９割が省略でき、いち早くアイデアが得られる事、いち早くアイデアが実現できる事が期待値であり、完璧なコードが得られる必要はないと思っている。

コピーライトについては、第一に、私はモデルがそのまま正確に複製されているのを見たことはない。膨大な量のドキュメントがあり、互いに影響し合いながら生成されるため、まったく同じものが作成されることはむしろ少ないと思う。ただしIPベンダーにとっては問題になるかも知れない。IPが顧客に提供され、それが生成AI/LLMの学習対象にされてしまうことで、IPに含まれるナレッジを模倣するようなモデルを生成する可能性は否定できない。もちろん、どのような契約を締結しているのかにも大きく依存すると思う。

私は法律家ではないので技術的観点から話をしたいが、現在インターネットの世界は学習済みのLLMモデルで溢れている。しかしLLMモデルの学習にどのようなデータが使われたかを逆にたどるのは非常に困難だ。仮に学習データをウィキペディアに限定したとしても、ウィキペディアの記事そのものが誰かのパラグラフをコピーしただけかもしれない。ましてや学習データをトレースバックして法的な観点から検査をすることに充分なリソースを充てるのは現実的ではない。そこで私たちの社内では、生成AI/LLMを用いてコード生成をする際には、生成されたコードをレビューし、技術仕様書の内容と一致することを確認することに充てるリソースを常に確保するようにしている。また最終コードに対する著作権も管理している。

例えば、シミュレーションにおいて非常に多くのテストシナリオがあって、その内部で何が起きているのかをデバッグする際、あるいはカバレッジを上げようとするのに役立つ、特定のトレースを生成するのには使えると思う。どういうことかと言うと、それは一般的には、いくつかの事象が発生する一連のシーケンスとの相関関係が得られれば、デバッグや、カバレッジを上げるのに役立てることはできると思う。生成AI/LLMが教えてくれることを100%信用することはできないものの、ユーザーを支援してくれる使い方はできる。

逆にLLMが生成する何かによって、まったく新たな検証を行うのには適していないと思う。例えばサインオフのシミュレーションのために、生成AI/LLMを使うべきではないだろう。というのはモデルが行ったことを、すべて人がダブルチェックしなくてはならないからだ。

コード生成の生産性向上のために使うのであれば、どっちみち人間がコードを書く際にはミスを犯すものだから、そして人が書いたコードですら完全に信用することはできないから、それを支援するのには向いていると思う。そしてもちろん、最終的には検証をしなくてはならない。

とても良い質問だと思う。私は生成AI/LLMを活用することで、質の高いRTLを書けるようになることから、質の高いRTLを書くとはどういうことかを理解し、それを説明できるようになることへとシフトしていくのだと思っている。生成AI/LLMでプロンプトした際に自分が意図したコードとは異なるコードが生成されると、どこが良くなかったのかが直感的に理解できる。

人は本質的に曖昧性を持った生き物であり、実は仕様書を書くことは上手ではないと思う。現段階では生成AI/LLMに対して仕様書を入力とし、そこからコードを生成させるのは良い考えだとは思わない。社内でもコード生成のために仕様書などのドキュメントを直接使用することは禁止している。

先ほど申し上げたように、生成AI/LLMの活用分野としてはCoding Assistance、Know-How Assistance、Debug Assistance、Analysis Assistance、Optimization Analysisなど多岐に渡っている。どうしてもコード生成に注目が集まりがちなのだが、設計者がどこに時間を使っているかを考えてみてほしい。それは恐らくコーディングではないだろう。なかなか思ったように動作しなかったり、問題が発生した時に解決方法を模索したり、他のエンジニアの協力を得てダブルチェックしたり第三者視点でチェックする作業に時間が割かれているのではないだろうか。生成AI/LLMが有効な分野の１つは、Questions & Answersのシステムで、そこから始めるのでも良いと思う。モデルのチューニングなどしなくても実践的に使うことができ、結果として生産性を上げることができると思う。

今の段階は、まずは生成AI/LLMを適用、活用することにより、生産性を向上させる段階だと思う、DVConでも機能検証における生成AI/LLMの典型的なアプリケーションについて論文があった。その背景に創造性が必要なことは理解してもらえると思う。生成AI/LLMを検証のあらゆる場面で適用することはできるが、その品質はシニアの検証エンジニアのレベルには達していない。また多くの場合、結果を100％信頼することもできない。つまり現存する決定論的アルゴリズムに基づく検証は、依然として非常に重要な役割を果たすと思う。

そして生成AI/LLMを既存のツールと組み合わせることで、生産性を向上させる段階になると思う。その中からだんだんと特定プロジェクトや、あなたのドメインに対して微調整された生成AI/LLMになっていくと思う。再学習されたモデルやあなたが適用するどのようなアプローチでも、それが少数のショットであっても、最大限の生産性を引き出すことができるようになると考えている。