前回、MicroBlazeが登場するよりもはるか昔に独自のCPUを手作りしたお話や、特定用途向けのDSPを自作したエピソードをご紹介しました。それらは一見すると「技術バカの暴走」に見えるかもしれませんが、実はそこには、ASIC開発の難易度を劇的に下げ、開発プロセスを最高にお気楽にするための「本質的なアプローチ」が隠されています。

今回は、その手作り設計の思想をさらに発展させ、皆様のASIC設計を「まるでFPGAを開発しているかのような柔軟さ」に変える、お気楽ASIC設計手法の本命—— 「CPUライク設計手法」 を提唱したいと思います。

一度焼いてしまったら1ミリも回路を直せないASICだからこそ、ガチガチのハードコーディング（専用のステートマシン）で回路を固めてしまう設計から脱却し、頭を柔らかくして、もっとお気楽に進めてみませんか。

DSPとFPGAの中間を狙う設計手法

「ASIC開発で柔軟性を持たせる」と言っても、FPGAのようにすべての領域をソフトウェアや再構成可能ロジックで動かす必要はありません。そんなことをすれば、PPA（電力・性能・面積）のメリットが完全に吹き飛んでしまいます。

私がお勧めしたいのは、従来のガチガチの専用RTL（ハードワイヤ）回路と、汎用CPU（ソフトウェア）の 「ちょうど中間」の抽象度 を狙うアプローチです。

具体例として、私が手がけたオーディオ信号処理用のASICを挙げてみましょう。

高度なオーディオエフェクトやフィルター演算（たとえば24bitの多タップIIR/FIRフィルター/サンプルレート変換など）を汎用CPUで処理させようとすると、処理が追いつかないか、膨大な電力を消費してしまいます。そのため、こうした重たいフィルター演算は、PPAが最適化された専用の「演算ハードマクロ（ハードワイヤ回路）」に担当させます。

その一方で、どのチャンネルの音声をどこのフィルターに通すかといった「信号パスの選択（ルーティング）」や「音量フェード、信号ミックス」などの、タイミング的に比較的ルーズで、かつ後から変更されやすい平易な処理は、すべてレジスタやソフトウェアからダイナミックに変更可能な設計にしておきます。

これにより、特定のオーディオエフェクトをソフトウェア制御で動的に切り替えたり、音量調整のカーブを後から滑らかに微調整したりすることが自在になりました。製品のバリエーション展開が劇的に簡単になり、お客様からの急な仕様変更のリクエストに対しても、ASICの再設計（リスピン）をすることなく、ソフトウェアのアップデートだけで悠々と、お気楽に対応することができたのです。

ソフトウェアで任意の信号タイミングを生成する

もう一つの強力な具体例が、SDカードインターフェースに代表される各種バスプロトコルの制御です。

一般的な設計アプローチでは、SDカードのプロトコル制御（コマンドの送受信やウェイトサイクルなど）をすべてステートマシン（FSM）でガチガチにRTLに書き込みます。しかし、これが実機デバッグ段階で数々の悲劇を生む原因になるのです。

接続するSDカード（市販のカードは星の数ほどあり、その素性も千差万別です）によってプロトコルの解釈が微妙に異なっていたり、タイミングが仕様書ギリギリで動いていたりして、実機でどうしても認識しない、というトラブルを皆さんも一度は経験したことがあるはずです。加えて、NANDによる高速・大容量化が進む中で、SD規格自体が発展途上であった時期のコントローラの設計においてRTLでガチガチに組んでしまっていたら、規格の解釈に多少でも誤りがあれば、もうその時点でアウト（最悪はリスピン）です。

そこで、私はプロトコルの細かな信号タイミングの生成を、RTLのステートマシンに任せるのをやめ、 「ソフトウェア（制御ファームウェア）で端子をパタパタさせる」 手法を採用しました。

もちろん、高速なデータ転送自体は専用のDMAロジックに任せますが、初期化コマンドのやり取りや、ウェイトタイミングの挿入といった「プロトコル制御」の部分は、ソフトウェアからレジスタ経由で制御ピン（CLKやCMDライン）を任意のクロック数だけ叩くような、きわめてシンプルなCPUライクな機構（GPIOや小さなコマンドシーケンサのようなもの）を設けておきます。

このアプローチのおかげで、ASICが手元に届いた後の実機テストにおいて、接続先カードの「おかしな挙動（プロトコルの独自解釈など）」に直面しても、ファームウェア側で「数クロック遅らせてから信号を叩く」といった回避ロジックを1行追加するだけで、完璧に問題をクリアできました。新たな規格の追加や進化に対しても、ASICの改修を一切必要とせず、開発期間の劇的な短縮とノーミスでの商品化を達成できたのです。

CPUライクな信号処理が生み出す圧倒的なメリット

このように、従来のハードワイヤによる「決め打ち設計」から意図的に脱却し、CPUがソフトウェア命令に従って動作するように、制御信号処理をCPUライクに設計するメリットは計り知れません。

特に昨今の多機能デバイス開発においては、市場のトレンド変化や顧客からの要望追加スピードはすさまじいものがあります。もしすべてをハードウェアで実装していたら、そのたびにプロジェクトは「再設計・再検証」のデスマーチに突入してしまいます。

CPUライクなアプローチを取り入れておくことで、ASICというハードウェアを物理的に変更することなく、 「ソフトウェアアップデートによって新機能を追加する」「既存機能のバグや効率を大幅に改良する」 という離れ業が、お気楽に、かつ迅速に行えるようになります。

市場のニーズに合わせた製品価値の最大化を、設計完了後であっても悠々とコントロールできる。これこそが、「私失敗しないので！」を実践してきた「お気楽ASIC開発」の秘密なのです。

回路規模と自由度のトレードオフ

ただし、ここでプロとしての重要なバランス感覚が求められます。

何でもかんでもソフトウェア（CPUやシーケンサ）で処理させようとすると、今度は「回路規模（またはソフトウェアを格納する内蔵RAMの面積）」が膨れ上がり、ASICとしてのメリットが失われてしまいます。

ポイントは、 「ハードワイヤで実装した場合と比較して、回路規模の増加を数倍以内（できれば1.5倍〜3倍程度）に抑えつつ、最大限の自由度を手に入れる」 という、絶妙なトレードオフの落としどころを見極めることです。

このバランスを調整するためには、設計の早い段階から、

  • どの機能が将来変更される可能性が高いか（＝ソフトウェア制御にするべき部分）
  • どの機能が将来も絶対に変わらないか、かつ超高速処理が求められるか（＝専用RTLにするべき部分）

を冷静に見極める、実務に即した「アーキテクチャの目利き」が必要です。このバランス設計さえ適切に行うことができれば、無駄にチップ面積を肥大化させることなく、お気楽で強いデバイスを設計することが十分に可能です。

検証工程を劇的に省力化

このCPUライク設計を取り入れると、検証にかかる工数が劇的に、それこそ次元が変わるほど削減されます。

従来のガチガチなハードワイヤ設計では、さまざまな機能が絡み合う「複合動作（システムレベルのシナリオ検証）」を、RTLのテストベンチ上で一生懸命に再現し、検証しようとしていました。しかし、そんな複雑な制御シナリオをRTLテストベンチだけで書こうとするのは、はっきり言って時間の無駄ですし、デバッグも困難を極めます。検証が複雑化すればするほど、「一体どこまでやれば検証が完了したと言えるのか」というカバレッジを競う泥沼にハマってしまい、いつまで経っても設計が終わりません。

CPUライク設計であれば、ハードウェア（RTL）自体は単純な命令を忠実に実行するだけの存在になります。そのため、論理シミュレータ上でのハードウェア検証は「基本的な命令が正しく動作するか」というミニマムな確認だけで済んでしまいます。複雑なシステムレベルのシナリオ検証は、ハードウェアのテストベンチ上で再現するのではなく、ソフト開発環境で作成したプログラム（ファームウェア）側にすべて委ねてしまえば良いのです。

このように、検証そのものを複雑化させないことこそが、ASIC開発を究極に「お気楽」にするための大原則です。この考え方は、私が提唱している、開発スタート時にあらかじめ「検証の終わり」をきっちり宣言してゴールを手前に引き寄せる手法、 「検証の終わり」を開発スタート時に決める！ ～ PVM（Proclaimed Verification Methodology）のすすめ！という検証思想の根幹でもあります。

そして、この「ソフトウェア側で検証シナリオを回してお気楽にデバッグする」というアプローチをさらに強力に進化させ、検証環境を劇的に変えてくれるのが、SystemVerilog標準の 「DPI-C」 を使い倒す手法です。これについては、次のコラムでそのお気楽さと圧倒的な優位性をたっぷりとお話ししましょう。

まとめ：ガチガチのRTLから脱却して、もっとお気楽に設計しよう

CPUからDSP、標準バスに至るまで手作りしてきた私だからこそ、断言できます。

ASIC設計は、決して「一度決めたら二度と変えられない、ガチガチで恐しい開発」ではありません。

「CPUライクな設計手法」をアーキテクチャにほんの少し忍ばせておくだけで、ASIC開発の難易度はFPGA開発並みに引き下がり、一発完動のプレッシャーからも解放されます。回路規模と自由度の絶妙なバランスを取り、検証工程を劇的に省力化する。これこそが、エンジニアが主導権を握り続け、楽しくお気楽に成果を出すための鍵となるのです。

とはいえ、「具体的にどうやってRTLとソフトウェアの境界線を引けばいいのか分からない」「自社のシステムにこのCPUライクなアプローチを導入して、検証コストを削減したいけれど、最初の一歩が踏み出せない」というお悩みもあることと思います。

貴社の開発要件に合わせて、PPAを最適化しつつ「お気楽でバグの出ない、最高にスマートなCPUライク設計環境」を現場に構築するお手伝いをいたします。ぜひとも、最初の一歩として、以下のリンク先から、私宛てにお気軽にお問い合わせやリクエストをお寄せください。ASIC開発をもっと楽しく、もっと「お気楽」に変えていきましょう。

参考文献・リンク