　数年前に出現したサブシステム規模のIP（サブシステムIP）は、SoC（System-On-Chip）デザインのゆっくりとした変化のきっかけとなりました。緩慢であっても止めることができないその変化は、多くの予期しない結果をもたらしています。実際のシステムでは、セルベースのSoC、さらにはFPGAにさえも、サブシステムIPを組み込んだものが出現しています。変化の影響はチップの境界を越えて広がることが分かります。

　上位階層にまでデザインの再利用範囲を拡大する、というサブシステムIPのシンプルな概念は、常に魅力にあふれています。インタフェースブロックをうまく再利用できるなら、オーディオサブシステムの全体、マシンビジョンサブシステムの全体なども再利用できないでしょうか。実際には、CPU、アクセラレータ、メモリ階層、I/Oコントローラー、外部インタフェースなど、適度なサイズのSoC全体を取り上げて、それをさらに大きなチップの内部でインスタンス化します（図 1）。

図1.サブシステムIPブロックには、さらに大きなシステムの中で機能を実行するのに必要な全てのI/O、処理、メモリが含まれることがあります

　成功の基準はシンプルであるように見えます。サブシステムIPが必要とする機能をSoCのメインCPUが容易に実行できる必要があり、その機能は、差別化に必要な全ての動作をファームウェアの変更だけで賄えるほど、汎用性がなければなりません。

　さらにハードウェアデザインは、サブシステムの全構成ブロックのフロアプラン、配置、ルーティング、タイミングクロージャを行わずに済む必要があります。多くの場合、サブシステムは何らかの種類のストリーム指向処理をチップの性能ぎりぎりのデータレートで実行しているか、または、それだけでは再利用の準備が整っていない独自のアクセラレータを使用しているため、この最後の基準が満たされます。

自己完結であること

　これら基準下でのサブシステムIPは、自己完結型システムであると同時にそれより大きなチップ階層のメンバーでもあります。この状況、特にサブシステムとそれ以外の世界とのつながり方には興味深い意味があります。

　一般に、サブシステムは独自のプロセッサまたはマルチコアクラスタ、アプリケーション固有である独自のアクセラレータを備えています。後者は、特定のビデオコーデックのように固有なものであるか、または高度暗号化規格（AES）アクセラレータのように一般的なものである場合があります。サブシステムは広範囲のチップデザインで再利用されるため、IP設計者はIPを包含するチップのリソースを共有することを想定するわけにはいきません。コンピューティング上、サブシステムIPは自己完結していなければなりません。

　同様に多くの場合、サブシステムIPはキャッシュ、バッファまたはスクラッチパッドメモリ、（恐らくは）DRAMからなる独自のメモリ階層を含んでいます。流行のプログラミングモデルがコヒーレントな単一の共有メモリを想定するとき、これは場違いに思われるかもしれません。一方、デザインと検証の作業を最小化するためにIPを再利用するのであれば、チームを巻き込んで2つの異なるコヒーレントキャッシュ構造を統合したいとは思わないでしょう。メモリインスタンスをわずかに冗長化し、サブシステムIPとそれ以外のSoCの部分との間に、単純で容易に検証できるインタフェースを持つ方がよいでしょう。

　DRAMにはさらに困難な問題があります。状況によっては、実際のオンダイ容量を超える作業領域が必要になります。しかし、十分な帯域幅を利用できるのに、マルチクライアントDRAMコントローラーを共有する複雑な処理を行いますか？　また、完全に分離されたDRAMポートを設けるコストと複雑な処理を望みますか？　選択肢を与えるIPプロバイダーも、与えないプロバイダーもあります。

　そこでI/Oの問題に行き着きます。多くの場合、サブシステムIPにはDDR3ポート、バス接続、または専用ペリフェラルへのリンク用に、独自の専用I/Oピンがあります。また、サブシステムは独自のパワーマネジメント方式を持っていると考えられるため、個別の電源レールと専用POL（ポイントオブロード）、レギュレータを必要とする場合があります。そのため、ハードDRAMコントローラー、プロトコルコントローラー、シリアルトランシーバーが一連の固定位置に存在する場合の配置、特にFPGAでの配置が制約されることがあります。これらの要件は、明らかにパッケージとボードに重大な影響を及ぼします。

IP統合

　　　　　　 1|2|3 次のページへ