ASIC（Application-Specific Integrated Circuit）開発において、自作のCPUやDSP、OnChipBus、さらには高速シリアル通信まで、今でいうところのSoCの標準IPを四半世紀前に自分で手作りしてしまった設計者なんて、なかなかの変わり者ですよね。というか、おそらく他には誰もいないのではないでしょうか。本稿では、そんな「なんでも自分で作ってみたい！」という技術バカな私の、ちょっと無茶で、でも今思えば極めて合理的だった手作り設計のあれこれを、懐かしく思い出してみたいと思います。

時代を先取りしたCPUの自作

今となってはFPGAでさえ当たり前のように搭載されているソフトマイクロプロセッサ（ここではCPUと呼びますね）ですが、私はXilinx社の「MicroBlaze」が登場するよりもはるか昔に、独自のCPU開発を思い立ちました。パイプラインによる処理性能を極めることよりも、徹底的な「省面積」と「カスタマイズ性」を重視して、なんと名機「Intel 80286」のアセンブラ解説書を片手に設計を始めたのです。

今から思えば、よくそんな無謀なことを始めたなと呆れてしまいますが、いざ設計してみると案外すんなりと動いてしまいました。もちろん、業務で抱えていた課題解決のための現実的な選択肢でもあったのですが、それ以上に「CPUを自分で一から設計している」という事実に、なんとも言えない心地よさとワクワクを感じてしまったのです。このときの快感が、私のエンジニアとしての「なんでも自作スタイル」を決定づけることになりました。

当時は、Xilinxの担当者さんに「こんな面白いCPU作ったよ！」と嬉々として自慢していたのを懐かしく思い出します。しばらくすると、大学発のツールや「ASIP（特定用途向けプロセッサ）デザイナー」など、カスタムプロセッサを設計するための言語やツールが商品化されて出てきました（そこそこ有名なプロセッサも、実はそのツールで作られていると聞いた記憶があるのですが、具体的な名前はすっかり忘れてしまいました）。

あれから四半世紀が経った今の時代、わざわざCPUを一から手作りしようなんていう物好きな人は、おそらく出てこないでしょう。でも、当時は後先考えずに「とにかく自分でやってみよう！」と飛びついたからこそ、他では得られない極めて深い経験ができ、それが今の私の最も大きな財産になっています。

  • CPU開発に至る背景：
    • 当時の要求仕様は、データストリームの中身をリアルタイムに解析し、そのフォーマットを瞬時に変換するという、なかなかに厄介なものでした。もちろん、ガチガチのハードコーディング（RTL回路）で組むという従来の方法もありましたが、流れてくるデータのフォーマットそのものが規格の進化とともに流動的だったため、回路を固定してしまうのは得策ではないと考えたのです。かといって、当時の市販マイコンでは、このリアルタイム処理をこなすには明らかにパワー不足でした。「だったら、この処理に特化した、自分好みの専用CPUをRTLで作っちゃえばいいじゃない！」というのが、すべての始まりでした。
  • メリット（Pros）：
    • 特定の用途に超最適化したアーキテクチャが、文字通り自由自在に実現できます。
    • 回路規模と処理性能の絶妙なバランスを、自分の裁量だけで完璧にコントロール可能です。
    • ライセンス料やロイヤリティといった無駄なコストが一切不要で、FPGAからASICへの移行（リターゲット）も、契約上の縛りを気にせず完全に自由に行えます。
    • 一度作ってしまえば、以降は「検証不要の汎用機能モジュール」として、さまざまなプロジェクトに使い回せます。
    • 万が一、ASIC完成後にバグが見つかっても、ソフトウェア側を修正することで回避できる「最強の保険」になります。
    • 論理検証の段階で、すでにソフトウェアの機能検証を並行して進めることができます。ソフトウェアチームから見れば、中身が手作りのCPUであることを意識することなく、通常のハード制御APIを通じてお気楽にタスクを呼び出すだけです。
    • ハード設計者としても、ASIC開発後に「実はC言語でこんな追加機能も実装できますよ」とソフトウェアで柔軟に対応できるため、ドライバー開発チームから頼りにされる嬉しいおまけもついてきます。
    • 命令コードそのものを自由にカスタマイズできるため、特定の演算に特化した「専用ハードマクロ」を実装し、その実行順序はソフトウェアで自在に制御する、といった組み合わせの妙は数え切れません。
    • 複雑な演算をそぎ落としたミニマムな「16bit CPU」単体なら、回路規模は10Kゲートを切るほどコンパクトでした。これをマルチコア構成（4CPU並列など）にして、リアルタイムタスクを同時並行で処理させる構成は、消費電力や回路面積で標準化して比較すれば、当時世の中にあった有名なプロセッサたちにも負けない自信がありました。
  • デメリット（Cons）：
    • 他社の技術（IP）に依存しないということは、コンパイラをはじめとするソフトウェアの開発環境から、その上で動かすテストプログラムまで、本当に「すべて」を自分で設計し続けなければならなかったことです。完全に、自分で好んで苦労を背負い込んでいました。
    • C言語風のコードで開発できるようにソフトウェア開発環境まで自作したのですが、あくまで「C言語風」のオレオレ言語だったため、プロジェクトの他のメンバーが誰もその開発環境を触りたがらないという、意図せぬ「身内への参入障壁」を作ってしまいました。
    • 自作したソフト開発環境はやはり貧弱で、世界標準のGCCへの移植を試みようとしたものの、コンパイラ側の深い見識が伴わず、作業はペンディングしたままになってしまいました。いつかやろう、と思ってはいたのですが。
    • その後、安価に市販CPUのIPが手に入る時代になり、契約やコスト面を考慮すれば自作CPUのメリットも十分アピールできましたが、今から思えば、OSS（オープンソース）のCPUという選択肢があったとしても、当時はあえて見逃していました（ここ10年ほどの基準で言えば、OSSを使ってより賢くスマートなアプローチを選択するべきですね）。他社技術に依存しない反面、ソフトウェアの開発環境からCPU上で動作するソフトウェアも何もかもを自分で設計し続けなければなりませんでした。

融通がきかない信号処理回路から柔軟なDSP設計へ

ガチガチのハードワイヤ（専用回路）で信号処理回路をASICに実装してしまうと、言うまでもなく、後からの変更は1ミリも利きません。私はおかげさまで、30年のASIC開発キャリアの中で自らが書き下ろしたRTLにおける「リスピン（再試作）に繋がるバグゼロ」を誇っていますが、そのための強力な「自己防衛策」としても、この手作りの特定用途向けDSPは大活躍してくれました。

オーディオ信号処理などを皮切りに、機器の特性に合わせて、あとから処理アルゴリズムをソフトウェア的にいくらでも変更できるDSPを数多く自作したのです。

諸先輩方の従来のやり方は、すべてのオーディオフィルター回路をガチガチのハードワイヤで設計するというものでした。しかし、そこにソフトウェアで動作するDSPに置き換えていくことで、オーディオ機器個々の特性や、お客様からの急な仕様変更にもソフトウェアの書き換えだけでダイナミックに対応できるようになりました。結果として、製品のバリエーション展開が劇的にお気楽になり、開発期間の短縮と大幅なコスト削減を同時に実現できたのです。

OnChipBusの自作と標準化

今では当たり前すぎるほど当たり前になった「OnChipBus（オンチップバス）」ですが、AMBA（Advanced Microcontroller Bus Architecture）が業界標準として広く普及する前は、バスという概念はもちろん、IPの再利用という考え方自体が非常に乏しい時代でした。社内の設計者たちが、めいめい好き勝手な仕様で信号線を引き回して開発していたのが実態だったのです。

特に、DRAMコントローラのように複雑なコマンドプロトコル制御が必要になる部分は、設計のハードルがグンと跳ね上がります。そこで私は、DRAMコントローラを包含する高速な「データバス」と、マイコン制御用の「コントロールバス」の2系統からなるバス仕様を自ら設計し、社内で「標準バス」として規定しました。これが社内の開発効率を劇的に高める大ヒットとなったのです。

「標準化」なんて言うとなんだか大げさで格好よく聞こえますが、本当のところは、自分が設計を楽にするために作ったバス仕様を、周りのみんなも使えるように仕様書にまとめただけの、実にシンプルな動機でした。今振り返ると、回路規模を極限まで小さくすることを優先した非常に「ケチんぼ」な設計仕様でしたが、それがかえって当時の限られたリソースには最適だったのだと思います。

その後、DRAMプロトコルがDDR2世代へと進化し、自作DRAMコントローラの大改修が必要になったタイミングと、世の中にAMBA仕様のIPが一般流通し始めた時期が重なったため、ベンダーからAMBAベースのDRAMコントローラIPを導入することにしました。そこから今日に至るまで、結局AMBA仕様と長くお付き合いし続けています。

普通の設計者であれば、与えられたAMBA仕様を深く考えずに使っているのかもしれません。しかし、自分でバス仕様を一から引いて社内標準化までした経験がある私からすると、特にAHB（Advanced High-performance Bus）の設計仕様については、「なんでこんなにPPAにとって不合理で、使いにくい迷惑な仕様なんだろう」と、今でも大いに疑問を感じています。ここでハッキリと悪口を書き連ねるのは大人のマナーとして憚られるのでやめときますが、明らかに問題がある仕様だと思っています。これについては、また別の機会に深く語ってみたいですね。

ちなみに、仕様のスマートさだけで言えば「OCP（Open Core Protocol）」の方が優れていると感じる部分もありました。しかし、実際にバスIPのPPA（電力・性能・面積）比較評価を実施した際、OCPで有名なベンダーのIPの出来が正直あまり良くなく、結局OCPを本格的に採用する機会を逸したまま今日に至っています。

高速シリアル通信での思い出話

高速シリアル通信の設計において、当時としての「世界最高速」を叩き出すハードウェアを自作したことがあります。これは本当に誇らしい実績だったのですが、いざ実機テストを始めると、実に笑えるトラブルに直面してしまいました。

接続相手は、ごく普通の汎用パソコンです。そのパソコン側で、トランザクションレイヤー（データ転送の制御処理）を司っていたのは、あの超有名OSに付属している標準ドライバーソフトでした。

そこに、私の設計した「超高性能な自作デバイス」を接続したところ、なんと、自作デバイス側の処理能力が「優秀すぎた」ために、パソコン側のソフトウェア処理が追いつかず、接続エラーを連発してしまったのです。

プロトコルアナライザー（プロトコルを観測する測定器）で解析してみると、プロトコルの規格上、エラーの原因は100%相手（OSの標準ドライバー）側にありました。しかし、いくらハードウェアとして私の設計が完璧であっても、エンドユーザー様に向かって「パソコン側のドライバ処理が遅すぎてプロトコル違反しているのが原因です」なんて言い訳が通用するはずもありません。こんな時にも活躍するお手製CPUによるドライバ処理で自デバイスの速度をあえて落とし、処理速度に合わせてあげるという「大人の対応」も、今となっては本当に懐かしい、微笑ましい思い出です。

まとめ

CPUからDSP、OnChipBus、そして高速シリアル通信に至るまで、これらの多岐にわたる手作りの経験は、単なる「技術バカの自己満足」ではなく、製品の限界性能を120%引き出し、開発効率を徹底的に向上させるための、極めて実用的で強力なアプローチでした。何より、ブラックボックスのIPに振り回されることなく、トラブルが起きても「自分で全部作ったんだから、自分で100%解決できる」という圧倒的な安心感と主導権を持てることは、ASIC開発において何物にも代えがたい強みなのです。

このような、一見すると「常識外れ」に見える手作りのアプローチや、枠に囚われない柔軟な設計思想こそが、開発期間を縮め、バグを未然に防ぎ、最終製品の市場価値を最大化する鍵になります。

当サイトでは、このような「お気楽で、でも最高に強くて面白い開発環境」を皆様の現場にも構築するための技術コンサルティングを提供しています。「自社に最適なカスタムモジュールを実装したいけれど、どこから手を付ければいいか分からない」とお悩みの皆様、ぜひとも最初の一歩として、以下のリンク先から、私宛てにお気軽にお問い合わせやリクエストをお寄せください。一緒に、楽しくて「お気楽」なASIC開発を始めましょう。

参考文献・リンク