ASICの開発工程において、検証（シミュレーション）に費やされる時間と労力の削減は、やはり永遠のテーマです。
かつてVerilogのPLI（Programming Language Interface）が存在した時代、C言語をコンパイルしてできたオブジェクトファイルをシミュレータとリンクして動かす仕組み自体は、一応技術的に可能でした。でも、その接続手順が本当にびっくりするほど難解で、おまけにシミュレータベンダー間での互換性がほぼ皆無だったため、多くの設計者が手を出すのを躊躇していました。私自身、当時は「こんな面倒なもの、やってられるか！」と、完全にスルーしていた一人です。
こうした課題を劇的に解決すべく、2000年代半ばのSystemVerilog標準化の波とともに登場したのが「DPI-C（Direct Programming Interface for C）」です。IEEE 1800規格としてDPI-Cが定義され、主要なシミュレータ各社が標準対応してくれたおかげで、従来の難解な手続きや互換性問題は一気に解消されました。
当時、新しいトレンドを常に追いかけていた設計者であれば、私同様にこの便利さにすぐさま飛びついたはずです。しかしその一方で、新しい技術に疎い設計現場では、DPI-Cの標準化から10年以上が経過してもなお「DPI-Cって何？どう使うの？」という状態の技術者が、私がかつて所属していた大手企業の最前線でさえ、他部門を見渡せばいくらでも転がっていたのもまた、否定できない実態です。日本の技術開発の最前線のリアルな姿なんて、実はそれくらいマイペースなものだったりします。
今日現在においても、「存在は知っているけれど、自社の開発フローに組み込めていない」「いまだに前時代的なVerilogテストベンチで泥臭い検証を続けていて、毎日胃を痛めている」という現場があるとすれば、この記事が検証フローを劇的に効率化するキッカケになり、開発手法を「お気楽」で見通しの良いものへと見直す第一歩になれば嬉しいです。そして、そうした変革への一歩を踏み出してみたいと悩んでいる方こそ、弊社のコンサルティング案件の良きお客様になっていただけるはず、と考えています。
ARMをDPI-Cでモデリングするお気楽さとその本質
ARMなどのプロセッサを内蔵したASIC開発では、検証の最終フェーズにおいて、タイミングやサイクル精度を厳密に検証するために「DSM（Design Simulation/Signoff Model）」や純正のFastModel、BFM（Bus Functional Model）を用いるのが常套手段とされています。しかし、開発の初期・中期フェーズからこれら大層なものを使うのは、環境構築が本当に複雑ですし、シミュレータのライセンス制約やビルド・シミュレーションの実行速度の低下を考えれば、お世辞にも最適なアプローチとは言えません。実務に慣れてしまえば、結局最後まで純正モデルを一度も使うことなく検証を終えてしまうことだって普通にあります。
当時（今から20年ほど昔のことです）、ARM7を内蔵したASICを開発するプロジェクトにおいて、便利そうなのにPLIの手間を理由に見送っていた私は、DPI-Cを用いた「コメントを除けば300行にも満たないSystemVerilog記述」による超軽量なARMモデル（バスファンクションモデル）の自作を思いつきました。
「ARMの自作モデル」なんて聞くと、ものすごく難解なものに思われるかもしれませんが、その構造は驚くほど単純です。本質的な仕組みは、以下の2点に集約されます。
- Verilog（SV）側のAMBAバスアクセスタスク ：AMBA（AHB/APBなど）の細かな信号線ハンドシェイクやタイミング制御は、SystemVerilog側でシンプルなタスク（例えば
write_wordなど）として数行で記述しておきます。 - C言語側からの呼び出し（DPI-Cによる標準化） ：このSV側のタスクをC言語のオブジェクトから呼び出せるように
export宣言し、C言語側からは単純なバス読み書き関数として実行します。また、シミュレータが変わってもコンパイル済みのCオブジェクト（.o .soファイル）をそのままリンクできるよう、DPI-CによってCとSV間のインターフェースが厳格に標準化されています。これにより、エミュレータとのリンクも驚くほど簡単になります。
この手法の最大の売り込みポイントは、C言語で記述する検証シナリオ（テストプログラム）側からは、「ARM自体の内部構造や物理的な動作仕様などは完全にどうでもいい」という点にあります。C言語で書くコードは、ARMを意識したものではなく、ごく普通の「シンプルなファームウェア（ペリフェラル制御コード）」そのものです。これを、誰もが使い慣れたフリーのコンパイラ「GCC」を用いたmake環境において一瞬でコンパイルし、シミュレータにリンクして実行するだけで、お気楽にプロセッサ動作を模擬してDUTの検証をスタートできます。
「ARMを内蔵する場合、すでにライセンス料を払っているのだから、提供される純正モデルを使えば追加コストはかからないのでは？」と思われるかもしれません。しかし、ツールの制約に縛られ、遅く重い純正環境で四苦八苦するよりも、DPI-Cによる自作簡易モデルを採用する方が、ビルド速度、デバッグの容易さ、そして後述するエミュレータ環境への移植性の観点から、比較にならないほど巨大なメリットが得られます。
さらに言えば、このDPI-Cモデルの本質は「ARM」だけに留まりません。マイコンI/Fを介した外部マイコンやPCI/PCIeなどの汎用I/F、画像圧縮処理や高度な信号処理など、CPUに限らず、あらゆる重い機能ブロックのC言語アルゴリズムモデル、検証対象DUTの隣のブロックのDPI-Cモデルへの置き換えによる機能シミュレーションの高速化、システム全体の大規模な機能シミュレーションを最高速で回すためなど、DPI-Cは極めて強力な武器となります。
C言語×makeによる検証ソフト環境の革新
従来のVerilogテストベンチだけで複雑なハードウェア制御シナリオを書こうとするのは、はっきり言って時間の無駄ですし、デバッグも困難を極めます。
DPI-Cを用いて、検証のシナリオをC言語（ソフトウェア）側に追い出してしまえば、検証環境は劇的に進化します。テスト用のCプログラムを少し書き換えたいとき、RTLソースの再コンパイルは一切不要です。単にテスト用のC言語ファイルをGCCを使ってmakeし、シミュレータの起動時に新しいオブジェクトファイルをロードさせるだけで、次のテストを一瞬で開始できます。
オブジェクト指向をUVMなどのSystemVerilog側で苦労して実装するよりも、使い慣れたC/C++言語の検証環境側でソフトウェア的に工夫する方が、圧倒的な利便性を享受できる場合も多いものです。この検証ループ（記述・実行・修正）のターンアラウンドタイムを秒単位に縮められるスピード感は、設計現場のフラストレーションを綺麗さっぱり一掃し、生産性を何倍にも跳ね上げてくれます。
最終商品でのドライバーソフトの動作
このDPI-C検証アプローチがもたらす実用的な恩恵は、「DPI-Cの簡易モデル上で開発・デバッグしたC言語のドライバーソフトウェアが、最終実機のプロセッサ上でも、何一つコードを修正することなくそのままビルドして動く」という点にあります。
よくある設計現場の失敗として、ハードウェア検証用にVerilogのタスクで泥臭く書いた「レジスタ設定手順」と、のちにソフトウェア開発チームがC言語で実装する「実機ドライバー」の仕様が乖離してしまい、実機デバッグ段階で原因不明のバグが大量に噴出して地獄を見る、というお約束パターンが挙げられます。
DPI-C活用すれば、検証用コード自体がそのまま「実機のC言語製品ドライバー」になります。ハードウェアのバグを論理シミュレーションで叩き出すのと同時に、製品として出荷される本物のソフトウェアのデバッグまで先行して完了させることができるのです。これほどお気楽で合理的な話はありません。
Cadence PZ1やSynopsys ZeBuでの活用
DPI-Cで構築したARMモデルの素晴らしさは、PC上の論理シミュレータ（IES/VCS/ModelSimなど）の中だけで完結しない、その「圧倒的な移植性の高さ」にあります。
このDPI-Cモデルは、Cadence Palladium Z1やSynopsys ZeBuといった、極めて高価なハードウェア・エミュレーションツールにも、そのまま組み込んでシームレスに動作させることが可能です。
ややこしいエミュレータ環境の制約にも一切引っかからず、移植も極めて容易です。シミュレーションの抽象度を維持したままで、検証スピードだけをメガヘルツ・ギガヘルツ帯の超高速領域へと一気に引き上げることができるため、OSの起動や大規模なアプリケーションレベルの機能検証も、現実的な時間の中で「お気楽」にこなせるようになります。初めてこの技術に取り組んだ渦中（20年前の私ですが）は何もかもがチャレンジの連続でしたが、一度上手くいくと判ってしまえば、本当に造作もない簡単なことでした。エミュレータとシミュレータの速度比較などは、また機会があれば詳説したいと思います。
FPGAエミュレータ環境での利用
高価な専用エミュレータが手元にない現場であっても、DPI-Cモデルは強力な味方になります。私たちが現場で泥臭く構築した、手作りの「FPGAプロトタイピング・エミュレータ環境」でも、このDPI-CのARMモデルをそのまま利用できるからです。
設計現場が実用的なデバッグ環境として泥臭く自作したFPGA評価ボードを、古くはPCI、その後はPCIeを介してLinux PCに装着し、DPI-Cの論理シミュレーション環境と全く同じ検証をFPGAハードウェアで実行します。
これにより、C言語によるテスト資産を1行も書き換えることなく、検証の実行速度をソフトウェア・エミュレーションの限界を超えた数メガヘルツ〜数十メガヘルツの帯域まで引き上げることができ、大規模データの検証を瞬時に完了させることが可能になります。ハードウェア設計とソフトウェア開発の連携が極限まで強化され、開発期間の大幅な短縮をもたらします。私自身、もしもこのお気楽ASIC開発手法を確立していなければ、これまでの「一発完動」のキャリアはあり得なかったと断言できます。
ソフトウェア開発チームへのエレガントな引き継ぎ
論理検証工程においてハードウェア検証チームが作成し、実際に動かし続けたCの検証コード（ドライバーソフト）は、そのままソフトウェア開発チームへ「動く仕様書」として引き継ぐことができます。
「ハード検証段階で一発完動が確認されているCコード」をそのまま使えるため、ソフトウェアエンジニアは余計なハードウェアインターフェース of 動作不良に悩まされることなく、上位のアプリケーション層や通信ミドルウェアの開発に専念できます。
部門間に存在するサイロ（見えない壁）を取り払い、製品開発全体のスピードを極限まで引き上げるための最もエレガントなバトンパスが、ここに実現するのです。
まとめ：お気楽ASIC開発へ、武器を手に取ろう
DPI-Cという強力な武器を正しく理解し、使い倒すことは、ASIC開発における最大の難関である「一発完動」へのプレッシャーに直面する設計者を救い、開発プロセスを劇的に「お気楽」で楽しいものに変える鍵となります。一度開発した制御Cコードを、最初の機能検証から最終実機商品まで一貫して使い続けることによる生産性の向上は、もう計り知れません。
しかし、このような素晴らしい検証技術や手法が存在することを知りつつも、「日々のルーティン開発に追われて立ち上げる余裕がない」「周りにDPI-Cを使いこなせるエンジニアがおらず、最初の一歩を踏み出せない」という現実的な課題もあることと思います。
当サイトでは、お問い合わせフォームからのリクエストベースで技術支援を行っています。もし貴社の開発現場において「検証環境をDPI-Cで一新し、開発期間とバグを劇的に削減したい」「お気楽検証手法」を取り入れたいというお考えがございましたら、ぜひとも最初の一歩として、以下のリンク先から お気軽に お問い合わせやリクエストをお寄せください。私の30年の実務知見を惜しみなく提供し、全力でサポートさせていただきます。一緒に、楽しくて「お気楽」なASIC開発を始めましょう。