改めて探る、IPベース設計の課題：SoC設計の抽象化は実現できたのか？（1/3 ページ）

IPの集積に悩む設計者

図1　IPの再利用の例（その1）　LSI社は、ネットワークSoCにおいて、インターフェースIPを新しいパケット処理のコアに統合した。

図2　IPの再利用の例（その2）　設計要件が大幅に変更された結果、IPが再利用されているのはI/O周りのみとなっている。

　SoC（System on Chip）の設計において、生産性の向上を追求するということは、抽象化と自動化を追求するということでもある。設計フローの各ステップにおける抽象化の度合いが高まれば、処理しなければならない設計上の要素の数は少なくなる。また、自動化できる部分が多くなれば、各要素に対して人間が介入しなければならないところが少なくなる。理想的なのは、設計者がSoCの動作の抽象的表現について把握し、それが目的にかなったものであるかどうかを検証するだけでテープアウトの承認まで持ち込めるようにすることだ。だが、現状の設計環境はまだその域には達していない。

　抽象化のレベルを高めるための手段として、高位設計（C言語から派生した言語を用いる場合が多い）の活用を強く推進する動きが何年も前から存在する。しかし、限られた構造的要素を除き、ビヘイビアやトランザクションレベルの表現を基に、合成によって実装を生成することは困難であった。合成が行えない場合、設計者は、高位版のコードを基に、RTL（Register Transfer Level）コードを手作業で作成しなければならない。

　EDAベンダーが合成手法の実現に悪戦苦闘する中、SoCの設計では高位抽象化の別の手法が使用されるようになった。それがIP（Intellectual Property）の再利用である。この手法は非常に一般的に使われている。というよりも、今日のSoCの多くは、IPを再利用しなければ成り立たない（図1、図2）。米Applied Micro Circuits社のセントラルエンジニアリング担当ディレクタを務めるJitu Kahne氏は、「設計期間があまり確保できない場合には、チップの80％はIPで構成する」と述べている。

　IPへの高い依存性の背景には、設計における抽象化のレベルを向上させようという意図がある。理想的には、IPブロックを、設計チームが決して開ける必要のないブラックボックスとして扱えることが望ましい。IPの再利用により、設計チームはある大きなブロックを、内部構造がどのようなものかにかかわらず、機能とI/Oだけに注目して扱うことができる。設計チームはサインオフに至るまでこの抽象化を維持し、ブラックボックスの中身を確認することなく、複数のブラックボックスを組み合わせて集積することができればよいということである。

　とはいえ、IPの再利用も高位設計と同様、理想どおりにはいかないというのが現実である。米PMC-Sierra社のエンジニアリング担当バイスプレジデントを務めるKen Wagner氏は、「IPの再利用は、ある意味では幻想のようなものだ。特に、サードパーティ製のIPを使用する場合、多大な労力が必要となる」と述べる。

　このような労力が必要となる最大の理由は、作業が自動化されていないことである。また、抽象化を維持したまま重要な設計サイクルを通過するのが不可能であることも理由の1つだ。Kahne氏によると、Applied Micro Circuits社では設計サイクルのうち60〜70％をIPの集積作業が占めるという。それにもかかわらず、設計フローの中でIPの選定/集積が作業の中心となる部分において、使用できるツールがほとんど存在しないというのが実情なのだ。

　米QUALCOMM社のエンジニアリング担当シニアディレクタを務めるKarim Arabi氏によると、同社製品の設計で用いているIPのうち80〜90％は、次の世代のチップでもそのまま使われる。「それでも、集積作業は毎回やり直す必要がある。だが、IPの選択（製品への適合性の評価）や集積を自動化するツールは存在しない。また、ECO（Engineering Change Order）の処理は純粋に手作業で行っている」（Arabi氏）という。

IPの動作の把握

　設計者はIP化された回路ブロックの動作をどのようにして把握し、そのブロックを配置した後のSoCの動作をどのようにして確認するのだろうか。ブラックボックスの中身を見ないで済ませたいと考えるならば、どちらも重要な疑問として位置付けられるはずである。

　対象とするIPが、USB 2.0などの標準的な機能を実装するものである場合、上述した疑問に対する答えは比較的簡単である。米Open-Silicon社のエンジニアリング担当バイスプレジデントを務めるTaher Madraswala氏は、「IEEEは、チップ内外の多くのインターフェースを標準化するという素晴らしい作業を成し遂げた」と考えている。ブロックがIEEEの規格や業界の事実上の標準を実装するものならば、ブロックの動作が大きく異なることはほとんどない。また、ブロックの動作を確認するためのサードパーティ製のVIP（Verification Intellectual Property：検証IP）も存在する。

　しかし、すべてのIPが標準的な機能を実装したものだというわけではない。PMC-Sierra社のWagner氏は、「顧客は、仕様を満たすIPを選択するために、多大な投資を行うことを覚悟しなければならない」と述べている。IPのパッケージには、実行可能なビヘイビア/トランザクションレベルのモデルが含まれている場合があるが、それらは必ずしもRTLベースのロジックの動作を正確に表現できていないものかもしれない。信頼できるモデルがなければ、設計者は、RTLベースのシミュレーションやFPGAを利用したエミュレーション、データシートの熟読によって、IPの正確な動作を把握しなければならない。また、IPを配置した後のSoC全体の動作を理解するには、ミックスドシグナルのシミュレーションを利用するか、あるいは、与えられた情報に基づいて独自のTLM（トランザクションレベルモデル）を記述する必要がある。こうした作業には多大な労力が必要であり、誤りも生じやすい。このような問題があることから、RTLのコードからTLMを抽出する作業をツールで自動化したいという話に行き着くことになる。

　IPの動作をモデル化するにあたって考慮すべきなのは、ほとんどのIPブロックが構成可能（コンフィギュラブル）であり、また、CPUコアなど一部のIPはプログラム可能（プログラマブル）であるという点だ。すなわち、システム開発に向けてIPの高位モデルを作成する際には、構成の設定や、場合によってはソフトウエアの変更といった作業が大量に発生する可能性があるということである。