ロードマップでわかる！当世プロセッサー事情 第232回

SoC技術論　開発期間に大きく影響する検証とデバッグ

　今回はモバイル向けSoCを作る際の手順の話を先に進めたい。採用するCPUコアとGPUコア、バスと周辺回路などが全部固まったら、それぞれのIP（知的財産）を入手するなり、もしくは自分たちで作るわけであるが、そうしたものは最終的にEDA(Electronic Design Automation)ツールと呼ばれる設計用装置に全部叩き込むことになる。

　もっとも自動調理器ではないので、材料だけ入れればできあがりというわけではない。EDAツールそのものも多種存在しており、複数のEDAツールを使いながらテープアウトに向けて作業を進めてくことになる。しかし、この中にまで踏み込んでしまうと、これはもうSoC技術論ではなくASIC設計の詳細になってしまうので、今回は割愛させていただく。

このボードの正体は？　詳しくは次のページで！

SoCを作るうえで避けて通れない
検証とデバッグ

　今回は、そうした設計の先となる話である。連載228回で説明したように、SoCでは論理設計→物理設計→マスク製造→シリコン製造→パッケージング→完成という手順をとるわけだが、連載228回では意図的に外した項目がある。それが「検証とデバッグ」である。

連載228回で解説したSoCを作る手順。「検証とデバッグ」を意図的に外している

　プラモデルでも電子回路でもプログラムでもいいのだが、自分で設計して自分で作った、という経験をお持ちの方はおわかりだろうが、最初に想定した設計で最後まで行なった、というケースはまずないかと思う。

　作ってる途中で「あ、これ忘れてた」「あ、これまずい」となって、軽い変更ならその場で手直しできるが、うっかりすると設計の根幹からやり直すことになりかねない。

　これは当然SoCにも通じる話である。「IPを買ってきて実装するだけなので簡単」というのは、あくまで「フルスクラッチで設計する」よりも簡単という比較の問題であって、論理設計レベルですら小規模なもので数十人、大規模なものだと数百人、下手をすると千人規模の設計チームが関わることになる。

　これだけの人間が関わるプロジェクトで、お互いに意思の疎通を取りながらきちんと物を作り上げてゆくのは非常に困難である。全体が複雑すぎて俯瞰してみることが困難なため、なにか穴があってもわからないことがしばしばある。

　そのため普通は仕様のミスマッチや、あるべきものがないといったトラブルが頻発する。こうしたトラブルがあるともちろんSoCはできあがらない。

　こうした大規模開発はソフトウェアの現場でもよくあることだが、ソフトウェア開発と大きく違うのは、プログラミング→テストのサイクルに膨大な時間と金額がかかることだ。たとえば下図のように開発を進めたとする。

SoCができるまでの工程

　ここで検証に入ったところで「あ、ミスがあった」とわかったとして、もう一度論理設計からやり直したら、軽く2年近くの時間と（プロセス次第ではあるが）億単位の金額がかかるわけで、現実問題としてそうしたミスは許されなくなっているのが実情だ。

　こうした大規模開発では、ミスはそれなりの頻度で発生しているわけで、それをこんな悠長な方法で設計してたら永遠に開発が終わらない。そこで実際には論理設計のレベルでも、まず小さいコンポーネント単位で設計、テストを繰り返し、これが動いたら今度は複数のブロックをつないで結合テストをし、それが動いた段階で初めて物理設計に入る。

実際の工程。小さいコンポーネント単位で論理設計し、結合できたら物理設計に移行する

　もっとも物理設計を始めても、「この方式だと実装できない」という事態がしばしばあるので、この段階で手戻りが発生することも珍しくない。

　ただ、この段階で手戻りが出るのはまだ幸せな方で、物理設計が終わってダイの試作を開始し、これに合わせて検証環境、つまり開発用のボードを設計してる時や、設計が終わって実装している最中に手戻りが見つかると、せっかく作ったダイが無駄になる。

　同様に、この後の本番の検証で手戻りが発生しても同じことで、「出荷後に発覚してリコールになるよりマシ」という程度でしかない。