SoC内部の相互接続アーキテクチャ：増加するトラフィックを効率良くさばく（2/3 ページ）

[Ron Wilson，EDN]

多種多様なトラフィック

　複雑化が進むSoCにおいては、上述した各ブロックの帯域幅の合計値は必要なものではなく、中央型バスは必ずしも適切な解決策ではない。その主な理由は2つある。1つは、トラフィックには大きく特徴の異なるものが存在するということだ。もう1つの理由は、機能ブロックにおいて、データの性質とタイミング要件にも大きな違いがあることである。

　チップ上の配線を実現する上で重要なのは、ブロックとブロックとの間に着目して適切なものにすることである。バスを用いれば、この目標を達成できるケースは多い。もしバスで達成できない場合には、ほかの何らかの手法を適用することになる。

　マルチメディア向けのSoCを見れば、設計者が対処しなければならない多様なデータフローが存在することがわかる。通常のマルチメディア向けSoCはCPUを備えており、それが少なくとも2つのまったく異なる性質のデータフローを生成する。その2つとは、新しい命令の連続的なフェッチフローと、ロード/ストア処理の散発的かつ双方向のトラフィックフローである。通常、CPUブロックにおけるキャッシュの存在により、このトラフィックパターンには変更が加わる。つまり、CPUコアからのトラフィックでは、キャッシュが空になったときかいっぱいになったときにランダムなバースト伝送が生じることになる。この状況は、ほかのトラフィックの性質とはかなり異なる。

　例えば、無線システム用SoCにおけるベースバンド信号は、A-Dコンバータから定期的に、また時には非常に短い間隔で送信される1ワードまたは2ワードのデータのようなものになる。カメラやDVDプレーヤから入力される映像も、同様の形式である。それに対し、映像圧縮エンジンがローカルメモリーに送信する中間データは、整然としたピクセルストリームというよりも、ほとんどランダムな順序でエンジンにロード/ストアされるマクロブロックの列のようなものになることもある。このように、データの種類ごとに本質的に異なる性質が存在する。CPUコアの場合のように、ローカルメモリーやステートマシンによって、その性質が変更される可能性もある。

帯域幅の問題、遅延の問題

　トラフィックの種類によってその性質が異なるように、機能ブロックの種類による性質の違いも存在する。つまり、CPUや、ハードワイヤードの信号処理パイプライン、ビデオエンコーダ、シリアルポート、DRAMインターフェースといったものには、それぞれに異なる要件/要求が存在するということである。それぞれのブロックに対してバスの帯域幅だけに注目してしまいがちだが、米MIPS Technologies社のソリューションズアーキテクチャ担当バイスプレジデントを務めるGideon Intrater氏は、「プロセッサの帯域幅に対する要件は、広い帯域幅を必要とするほかのデバイスと比較してそれほど高くない。しかし、遅延の影響を非常に受けやすい」と指摘する。例えば、CPUのキャッシュコントローラがデータを必要とすることはまれだが、そのまれなケースではCPU全体が待ち状態になる可能性がある。

　これとは対照的に、帯域幅のみが重要な機能ブロックもある。Intrater氏は「高性能なネットワーク機器がこれに当たる。PON（passive optical networking）がその代表例だ。DVDレコーダにおけるMPEGエンコーダや、HDTV（high definition television）におけるH.264デコーダなどのビデオエンジン、プリンタにおけるラスタライザ、デジタルカメラにおけるJPEGエンコーダなどの画像処理エンジンもこれに該当する」と述べた。「幸い、ほとんどのシステムにおいて、広い帯域幅を必要とするデバイスは遅延の影響は受けにくい。そのため、遅延の影響を受けやすいプロセッサが、広帯域幅を必要とするこれらのデバイスの妨げになることはあまりない」と同氏は語る。

　これ以外に、特殊な要件を持つブロックもある。離散コサイン変換を利用する画像/映像処理プロセッサは、通常は8×8ピクセル形式のマクロブロック内の画素を処理するために、走査線構成のメモリーにまたがった画素データを収集する。その際、アクセスを分散させることなく、これらのブロックを容易にロード/ストアできなければならない。この問題は対処がかなり難しい部類に入る。

　しかし、最も厄介なのは、広く用いられているDRAMの存在である。複雑な同期インターフェースとセグメント化されたメモリーアレイを持つDRAMは、誤ったシーケンスで要求を発行すると大きな遅延を生じる。そのため、アクセス方法によっては実効帯域幅が大きく低下する可能性がある。多くの場合、理論的なスループットに近い性能が得られるのは、読み書きの要求体系が1つだけの場合である。この厳しい要件は、CPUのL2キャッシュコントローラのトラフィックパターンにはうまく適合している。しかし、異なる種類の複数のプロセッサが1つのDRAMポートを共有している場合のトラフィックパターンとはまったく適合していない。

　相互接続アーキテクチャの目標は、簡単に言えば、すべてのデータが最小のエネルギによって適切なタイミングで到着するように、トラフィックパターンをブロックの要求に適応させることである。しかし、ここに大きな問題がある。その問題とは「トラフィックパターンを理解するために、設計者らが、完成したシステムがどのように使われるのかというモデルを理解しなければならないことだ」とLautzenheiser氏は指摘する。

　「どのように使われるのかというのは重要なことであり、それにはユーザーの知覚という目には見えないものがかかわってくる。映像を表示する携帯機器では、バスがビデオデコーダに1秒当たり何メガバイトのデータを伝送するのかということではなく、ユーザーが画面上のちらつきを感じるか否かということが成功するための判断基準となる。そのような定性的なユーザーの知覚を予測するには、システム配線における負荷が最も大きくなるのはどのようなケースなのかということを探らなければならない。ユーザーの手に物理的なプロトタイプを提供する前にこの作業を終えるには、システムレベルのモデリングが必要になる」（同氏）。

　実際、システム設計において、ESL（electronic system level）ツールが確固たる役割を確立した唯一の分野がここだろう。

　インターコネクトIP（intellectual property）企業である米Arteris社（フランスにも拠点を持つ）で社長兼CEO（最高経営責任者）を務めるCharlie Janac氏は、「システム設計者が、IPブロック自体を完全に定義する前に、データフローのモデル化から開始できることが最も望ましい。システム設計者ではなく、データフローがチップを定義するのだ」と述べる。

　このような考えに基づき、Lautzenheiser氏などの専門家らは、どのブロックをどこに接続すべきかという概念レベルから始めるアーキテクチャ設計フローを提案している。その簡単な接続図を基に、ブロックのESLモデリングや実使用時のモデルに関する情報を最大限に利用して、量、性質、要件の観点からデータフローを定量化する。そして最後に、オンチップの配線がこれらの基準を満たしていることを確認するのである。

　しかし、このプロセスには繰り返し作業が必要となる。Lautzenheiser氏は、「設計の工程では、予期せぬ事態が必ず発生する。従って、迅速に繰り返しが可能であるように、アーキテクチャ設計と実装との間を容易に行き来できるようにする必要がある。また、アーキテクチャを大きく改訂することなく変更に対応できるように、基盤となる構造を拡張可能なものにすることが重要だ」と語る。