EDAツール工夫して使ってますか？

大手ベンダーさんほど、社内に独立した「EDA専任部門（CAD部門）」があり、そこからお仕着せの設計手法や標準スクリプトが提供されるものです。そのため、実際の開発を進める現場の設計者たちは、EDA部門が用意したやり方を疑うこともなく、何も工夫せずにただスクリプトを流すだけで終始してしまっている……というのが、悲しいかな多くの設計現場の現実です。そもそも、大半の論理設計者は「ツールの内部動作」について深く考えることなく作業を進めているため、エラーや警告が大量に出ても、その実行結果を正しく解析する術を知りません。スクリプト自体は汎用的に作られてはいますが、それが皆様の設計している個別の回路にとって最適かというと、決してそんなことはないのが実態なのです。もちろん、それなりのスキルやこだわりがある人なら、「よし、自分で一からテンプレートスクリプトを見直そう！」と考えるべきなのですが、実力の高い人ほど日々の激務に追われ、時間の余裕がまったくありません。結果として、よほどの「変人（私のような技術バカですね）」でもない限り、スクリプトの改善を行うモチベーションを保てるはずもなく、理想を追わない開発の悪循環が連鎖していくことになります。

私は、新しい半導体ベンダーさんとお付き合いしてそこから開発環境を構築するたびに、彼らから新たな知見を得られたことに深く感謝しています。しかし同時に、「自分で実際に触って、仕組みを完全に理解しないと気が済まない」という厄介な性分でもあります。そのため、ベンダーから提供されたスクリプトをそのまま使わず、実際に自分の手で「なぜなぜ」を突き詰める深掘りを何度も行ってきました。その結果、その都度行き着いた結論は、「実はベンダー自身も、そこまで深く考えて作っていないんだな」という現実でした。私にしても、ホントはもっと実験して確認すべきことが山ほどあったはずですが、「プロの直観」という、時に危険で、でも強力な武器を使いながら、お気楽に仕事を進めてきたように思います。

昨今のLLM（大規模言語モデル）をはじめとする生成AIの躍進を見ていると、「AIがプログラミングを劇的に変えたように、ASIC開発の設計効率も別次元へ引き上げてくれる未来がすぐそこまで来ているのではないか！」と、胸がワクワクしてしまいます。しかし、AI技術による設計効率の向上は、実はEDAツールベンダー自身が最も古くから宣伝し、取り組み続けてきたテーマでした。それにもかかわらず、末端の設計者にその恩恵がまるで届いていないように感じられるのはなぜでしょうか。

その背景には、この業界特有の閉鎖的な体質や、各社が抱える機密データの保護問題（RTLはビッグデータ化しづらいという難点）があります。さらに言えば、設計品質を評価する上で、最終的には「リリースのタイムリミット（開発期間という時間のファクター）」だけが唯一無二の明確な判断基準になってしまう、という現実があります。どれほど素晴らしいPPA（電力・性能・面積）最適化を謳ったところで、限られたスケジュールの中でバグを完全に取り除いて製品化できなければ、所詮は絵に描いた餅にすぎません。バグがあってはすべてが元も子もないだけに、AIによるお仕着せの自動合成や、PPAを等閑にした設計自動化だけでは、現場を本当の意味で救うブレークスルーにはならないのです。解釈の曖昧さがつきまとう自然言語のみで直接ツールを駆動するようなやり方は、現場に致命的なバグを埋め込むのがオチです。やはり当面の間は、私たち設計者が自分の頭と知恵を絞り、お気楽かつ堅実にツールをハックしていくしかありません。

そこで、私がこれまでのASIC開発プロジェクトで実際にツールを使い倒し、泥臭く検証を重ねて効果を実証してきた、極めて有用でお気楽な「ツール使いこなし術」のトピックスをピックアップしていきます。

機能検証（論理シミュレーター）

• HDLコーディングより、HDLコードを生成するスクリプトに注力しよう
• 最初に使った論理シミュレータModelSim（Questa）あれこれ
• VCSに変えてみて驚いたVCSの当たり前を見直そう！
• PZ1のためにVerilog発祥の地に戻り大手３つのシミュレータを比較してみた
• DPI-Cで検証環境革新しよう！
• Cocotb（Python）による検証：SystemVerilogとどちらがお気楽？

論理合成（DesignCompiler）

• DesignCompilerが面白すぎて人生間違えっちゃた
• いつまでも前時代的なTclスクリプトを使い続けるのってどうよ
• Synopsys社標準スクリプトの使い方
• ベンダー提供スクリプトとの比較・ブラッシュアップする
• コマンド実行方法（駆動フロー）を見直そう

等価検証（Formality）

• ECOでは避けて通れないけどホントに疲れるツール
  • 不一致起きるとツールの使いこなしが難しい
• 変更したら、なくてはならない精神安定剤
  • スクリプト変更による生成回路の等価性確認
  • VHDLからVerilogに。その後はSystemVerilogにも

LINT

• LINTはLedaでやるべきだ！？
  • だって合成も何もかもネットリストはSynopsysなんだから。ＲＴＬのチェックは使うツールの特性に応じるべき
• SpyGlass買収で、やっぱLedaはゴミだった
  • でもLedaからSpyGlassへの移行はそんなに簡単じゃない（これってユーザがやる仕事？）
  • 私が完成させたたスクリプトの解説

CDC検証

• ０-In（QuestaCDC）で初めて知ったCDC検証の奥深さ
• LintがSpyGlassになったのでCDCもSpyGlassCDCにしてみた

Power解析

• PowerProで電力を見てみよう
• JoulesとSpyGlassPowerを比較して分かったベンダー技術者のスキル

エミュレーター

• FPGAは最強マイエミュレータ
  • エミュレーション基板開発の工夫
  • DPI-Cの論理Sim環境をPCI/PCIeテスト環境でそのまま使う
• ZebuやPalladium Z1って高いけど素晴らしい
  • とはいえ、論理Sim環境の移植はあれこれとノウハウの塊だ

オープンソースEDA（OSS EDA）

• OSSのEDAツール（OpenROADやYosys、Verilator）はどこまで実用に耐えるか？

---