EDAベンダーと歩む「お気楽ASIC開発」への道：現場の痛みを知る設計者からの提言

ASIC開発において、EDA（Electronic Design Automation）ツールは今や空気や水と同じように、なくてはならない不可欠な存在です。論理シミュレーションから論理合成、等価検証に至るまで、ツールの支えなくしては数千万ゲートを超える現代のチップを設計することは不可能です。

しかし、私たち設計現場の人間と、ツールを提供するEDAベンダーとの間には、時に埋めがたい「温度差」が生じることがあります。EDAベンダーの皆さんは自社ツールのプロフェッショナルですが、果たして「設計フロー全体の痛み」をどこまで深く理解しているのでしょうか。

もちろん、無理難題を言うつもりはありません。30年以上にわたり設計の最前線に立ってきた者として、開発の難局で幾度となく私たちを支えてくれたベンダーのアプリケーションエンジニア（AE）の皆様には、言葉に尽くせないほどの敬意と感謝を抱いています。彼らの献身的なサポートがあったからこそ、数々のプロジェクトを完動させることができました。その感謝の気持ちを前提とした上で、現場の設計者が直面している構造的な課題に触れてみたいと思います。

EDAベンダーの構造的限界とAEの知識ギャップ

設計現場で感じるフラストレーションの中には、EDAベンダー側の組織構造に起因した問題があります。私が論理設計を始めた90年代から今日に至るまで、この構造的なジレンマは形を変えつつも根深く残っていると感じます。

第一の課題は、サポートを担当するAEの方々の専門領域に生じている『知識の偏り』です。AEの皆様は担当する特定のツールに関しては非常に深い知識を持っています。しかし、ASIC開発の全工程——すなわち仕様設計からアーキテクチャ定義、PPA（電力・性能・面積）の極限までの最適化、そして物理設計や検証まで——を実体験として完遂した経験を持つ方は稀です。そのため、設計者がなぜその特定のコードを書き、なぜその検証手法にこだわっているのかという「設計意図」が、十分に伝わらない場面が多々あります。

第二の課題は、ベンダー内部の「組織的テリトリ」という制約です。ツールごとに専任のAEが存在し、かつ顧客ごとに担当範囲が明確に区切られているため、たとえ社内に特定の課題に対する世界一の知見を持つエンジニアがいたとしても、私たちがその方から直接サポートを受けられるとは限りません。この組織的な壁が、対応の遅れや表面的な解決策の提示に繋がってしまうのです。

設計現場のフラストレーション：バグ再現と設計手法の不一致

こうした構造的課題は、特にクリティカルな局面で大きな壁となって設計者に立ちはだかります。

まず挙げられるのが、ツールの「バグ再現」に伴う膨大な労力です。シミュレーターや合成ツールに不具合が疑われる際、ベンダーからは必ず「バグを再現するコードと環境一式」を求められます。しかし、私たちは機密保持契約（NDA）の下で動いており、設計データ丸ごとを渡すわけにはいきません。結果として、設計者は多忙な業務の合間を縫って、不具合箇所だけを抽出する「カットダウン作業」を強いられます。この作業自体が数日を要する重労働であるだけでなく、不思議なことに、切り出した途端にバグが再現しなくなる「回避現象」も珍しくありません。この理不尽な作業負担は、設計者にとってフラストレーションの一つです。

また、「設計手法の理解」における認識のズレも深刻です。例えば、私たちは将来のプロセス移行や再利用性を考慮し、SRAMなどのハードマクロを直接インスタンスするのではなく、必ずラッピング階層を設けます。これは異なるプロセスノードやベンダー固有のマクロであってもコードの移植性を維持するための「基本の”き”」ですが、ツールベンダー側からこうした設計思想を汲み取った提案をいただけることは稀です。現場の当たり前を一から説明しなければならない状況に直面すると、もどかしさを禁じ得ません。

「もっと現場の設計フローを知っていれば、より価値のある提案ができるはず」——こうした建設的な視点こそが、ツール環境を良くすると信じています。

提言1：RTL独自暗号化によるバグ再現アプローチ

こうした「バグ報告の壁」を乗り越えるために、私が実践してきた手法があります。それは、機密情報を保護しつつ、ベンダー側で不具合を確実に再現させるための「RTL独自暗号化」変換スクリプトです。設計者のIP（知的財産）を守りつつ、ベンダーに迅速な修正を促すには、論理構造を維持したまま名前や構造を難読化・置換する技術が有効です。これにより、膨大な時間を浪費する「カットダウン作業」を最小限に抑え、迅速な解決へと繋げることが可能になります。

詳細は、後日公開のコラム（バグ報告等に使える暗号化について）で詳説します。

提言2：未来への期待——セキュアRAGによるサポート革新

さらに未来に目を向ければ、生成AI技術がサポートのあり方を劇的に変える可能性を秘めています。

私が期待しているのは、機密情報を完全に保護したクローズドな環境下で動作する「セキュアなRAG（検索拡張生成）」の導入です。これは、前述した「組織的テリトリ」という限界を打破する鍵となります。AIがベンダー内の膨大なグローバル技術文書や過去のバグ事例から即座に知見を導き出すことで、ローカルのAEが持ち得ない情報へも瞬時にアクセス可能になります。 「誰もが、いつでも最高のサポートを即座に受けられる世界」。そんなポジティブな未来が実現すれば、AEの皆様もより高度で創造的なコンサルティング業務に集中できるようになるはずです。

提言3：ツールとのI/FをTclからLLMによるAI制御へ――「お気楽ASIC開発」への道

EDAツールの駆動といえば、Tcl（Tool Command Language）スクリプトのシェル実行が常套手段です。しかし、厳密な構文が求められるこの前時代的なインターフェースの記述こそが、設計者の開発スピードを鈍らせる要因になっています。ここ数年のLLMの飛躍的発展は、このツール駆動のあり方を根本から変革する可能性を秘めています。

私たちが「これら・・制約条件を適用した論理合成スクリプトを作成して」と自然言語で大雑把に指示を投げれば、LLMがツールの特性やテンプレートスクリプト、結果レポートをを解析し、最適化されたTclスクリプトを自動生成する。さらに、近年活発なスクリプトのモダナイズの流れに乗って、よりデータ処理やライブラリの取り回しが便利なPythonへとインターフェース自体が移行していくことも十分に考えられます。

ただし、ここで重要なのは、「ツールとの直接のインターフェースを、すべて自然言語にしてしまうこと」は絶対に避けるべきという点です。厳密な再現性と論理的一貫性が求められる設計現場において、解釈の曖昧さがつきまとう自然言語のみでの直接実行は致命的なバグの温床になります。あくまで、設計者からは「自然言語によるお気楽な指示」を出し、LLMがそれをTclやPythonといった「厳密に動作が決定できるプログラミング言語」へと確実に落とし込み、記述の曖昧さを完全に排除した上でツールを駆動する。このようなクッションを挟むアプローチこそが、破綻のない「お気楽ASIC開発」の現実的な到達点になるはずです。

まとめ

現在のEDAサポートにおける課題、特に実務経験の不足に起因するギャップは、ASIC開発の現場を知り尽くしたエンジニアの積極採用や、より実践的なコミュニケーションを通じて解消されることを切に願っています。ツールのマニュアル通りの操作方法だけでなく、設計者の「知恵」とツールの「技術」が高度に融合するようなサポートこそが、設計現場が真に求めているものです。

かつて花形だった日本の半導体設計は、現状では「数周回遅れのぼろ負け状態」といえる厳しい局面にあります。しかし、設計者とEDAベンダーが、単なる「買い手と売り手」の関係を超え、共に未来を創るパートナーとして手を取り合えたらどうでしょうか。

私たちが本来実現すべき機能を「最短で確実に手に入れる」ことにフォーカスし、MinimalFabやChipletといった新技術、そして私たちが現場で培ってきた泥臭い設計の知恵を掛け合わせる。そうすれば、世界の半導体設計の遅れを必ず取り戻し、再び世界をリードし驚かせるような「設計の革新力」を日本が手に入れられると私は信じています。

リンク