ASIC（Application-Specific Integrated Circuit）開発において、自作のCPUやDSP、OnChipBus、さらには高速シリアル通信まで、今でいうところのSoCの標準IPを四半世紀前に自分で手作りした経験のある設計者なんて変わり者はどこにもいないのかも。本記事では、その類まれな設計事例のあれこれを思い出してみようと思います。
時代を先取りしたCPUの自作
今となってはFPGAでさえ当たり前になったマイクロプロセッサ（MPUをここではCPUと略す）ですが、XilinxのMicroblazeよりもずっと早く独自CPU開発を思い立ち、パイプライン性能より回路規模とカスタマイズ性を重視して80286のアセンブラ書を参考に設計してみたところ、やってみれば案外簡単にできることでした。業務で抱えていた課題解決策としてもいい感じに役立ったこともありますが、CPUを自分で設計してみたことが、なんだか心地よかったので、自分のデザインスタイルとして定着し、その後に様々な応用を行うことになりました。当時、Xilinxさんにその意義と成果を自慢してたことを思い出します。しばらくすると考えることは皆同じなのかASIPデザイナーなどカスタムプロセッサのアーキを設計する言語まで商品化されて出てきましたが（そこそこ有名なプロセッサも実はASIPデザイナーによるものだと聞いた記憶があるのだが具体名はすっかり失念）、あれから二十数年後の今の時代では、今更CPUを一から設計してみようなんて人は出てこないと思いますが、自分で後先構わずやってみたからこそ、いろんなことを経験することができ、それが自分の財産になったように思います。
- CPU開発に至る背景：
- データストリーム中のデータ内容を解析し、そのデータストリームのフォーマットをリアルタイム変換しなければならない要求仕様に対し、ハードコーディングで実現することは従来技術の延長線にあったが、フォーマット変換に要するリアルタイムデータ処理タスクが、当時のマイコンでは明らかに性能不足であったことや、データストリーム仕様そのものが進化過程で今後も規格依存で流動的だったので、ハードコーディングの手法は近道に見えても得策でないと考えました。
- Pros：
- 特定の用途に最適化したアーキテクチャが自由自在に実現できる。
- 回路規模と処理性能の最適化は、自身の裁量で自由自在にコントロールできる。
- IP導入コストやロイヤリティーが不要。FPGAもASICもリターゲットが自由自在で、権利・契約も含めリターゲットに関する障壁が一切発生しない
- 検証不要の汎用機能モジュールとして最大限活用。
- 万が一のバグ対策モジュールとしても活用。
- 論理検証過程でソフトの機能検証が実施可能で、ソフト屋さんからすれば、中身がソフトであることを意識せずに、ハード制御同様の制御APIを通じて様々なMPUタスクを呼び出して活用。
- ハード屋さんとしても、ASIC開発後に様々な機能を追加提供することが可能となり、ドライバ屋さんから追加機能の依頼を受けることも。
- 命令コードそのものを自在にカスタマイズできるため、所望の演算マクロをハード設計し、その実行アルゴリズムはソフトで自在に制御することによるメリットは枚挙にいとまがない。
- 複雑な演算マクロを実装しない、ミニマムMPU16bit単体仕様では10KGateを切る大きさだったので、マルチMPU構成（MPUｘ４など）にして同時並行のリアルタイムタスク処理などにも最適で、回路・電力規模で正規化して比較するなら有名CPUにも負けてなかったはず。
- Cons：
- 他社技術に依存しない反面、ソフトウェアの開発環境からCPU上で動作するソフトウェアも何もかもを自分で設計しつづけた。（自ら好んで苦労を背負っていた）
- ソフトウェアはC言語風な言語を用いて開発できるようにソフト開発環境まで自作したものの、扱う言語があくまでC言語風でしかなかったため、だれも好んでそのC言語風ソフトを設計したがらない（意図せず身内にまで参入障壁をつくってしまった。。）
- 自作のソフト開発環境が貧弱でGCCへの移植を試みたものの、その分野における見識が伴わず移植作業はペンディングしたまま。（いつかやってみようと思ってはいたのだが、、）
- その後、市販CPUが手に入る時代になったものの、契約作業や導入コストを考えれば独自CPUのメリットを謳うことができたが、OSSのCPU選択肢もあったとすれば、それは敢えて見逃した。（ここ１０年ぐらいで考えるなら、OSSでもっといい方法が選択できる）
融通がきかない信号処理回路から柔軟なDSP設計へ
ガチガチのハードワイヤで信号処理回路をASICにて設計すると、言うまでもなく以後の変更が利きません。ASICでリスピンしたことが無かったため、自己防衛的にも、オーディオ信号処理を皮切りに、機器の特性に合わせて後から処理内容をソフトウェアで変更できる特定用途向けのDSPを数多く設計しました。
オーディオ信号処理用DSPの設計：
- ハードワイヤでオーディオ信号処理回路を設計するのが、諸先輩方の従来設計でしたが、ソフトウェアで動作するDSPを設計することで、オーディオ機器の特性に合わせてソフトウェアで処理内容を変更できるようになり、製品のバリエーションを増やす際に開発期間の短縮とコスト削減を実現しました。
OnChipBusの自作と標準化
現在では当たり前となったOnChipBusですが、AMBAが普及する前は、OnChipBusだけでなくIP再利用の考え方が自体が乏しかったので、社内の設計者が好き勝手に仕様を決めて開発している実態がありました。特にDRAMコントローラのようなコマンドプロトコルの制御設計が必要になると設計のハードルが多少上がったこともあり、DRAMコントローラを包含するデータバスと、マイコン制御系のコントロールバスの２系統のバス仕様を設計して社内で標準化することで、開発効率の改善に大きく寄与しました。
標準化というとなんだか大げさな気がしますが、そもそも自分の設計のために作ったバス仕様を皆で使えるように仕様書を整備しただけのことに過ぎません。今思うと”けちんぼ”だった設計仕様をベースにしてたので、その後のAMBAと比べると随分回路規模を小さくすることを優先した設計だったと思います。
DRAMプロトコルがDDR2になるとDRAMコントローラの大改修も必要となったこともありますが、世間でAMBAが一般に流通し始めたこともあり、DRAMコントローラIPを導入することにしました。そこからAMBA仕様とお付き合いするようになり、今日まで結局AMBAを使っています。一般的な設計者であれば、あまり気にされてないのかもしれませんが、自分でバス仕様を社内で標準化までしただけに、特にAHBの設計仕様についてはなぜにこんな迷惑な仕様なんだろうと、ハッキリと悪口を書くのは憚られるのでやめときますが、問題があると思ってます。また機会があれば詳説しようかと。そういう意味では仕様だけでいえばOCPの方がいい面があると感じたのですが、バスIPのPPA比較評価を実施したときに、OCPで有名なベンダーIPの出来が良くなかったこともあって、OCPに触れる機会を逸したまま今日に至ってます。
高速シリアル通信での思い出話
高速シリアル通信において、当時の世界最高速を実現したことがあるのですが、汎用パソコンなどトランザクションレイヤー処理を超有名OS付属のドライバソフトが行っているデバイスとの接続において、あまりにも自デバイスの性能が良すぎたために接続エラーが発生するという笑える問題に直面しました。プロトコルアナライザーで観測したころ、プロトコル上は明らかに相手側の問題なのですが、お客様に説明できるはずもないので、接続相手の速度に合わせて通信速度を調整しなければならなかったことも、今となっては懐かしい思い出です。
まとめ
CPUやDSP、OnChipBus、高速シリアル通信など、多岐にわたる手作り設計の経験は、製品の性能向上や開発効率の改善に大きく寄与しました。これらの事例を通じて、手作り設計の意義とその成果を実感することができます。