インターコネクト機能として単純なクロスバー方式を採用するという選択もあり得るでしょう。しかしシステム内のエレメントの数が増え始め、さらにエレメント間の距離が意図されたクロック周期に対して長くなってくると、クロスバーではもはやどうにもならず、NoC(Network-on-Chip)方式を採用する必要があります。
前回(連載第1回)は、オンチップ通信がSoC(System on Chip)アーキテクチャの要である理由を説明しました。それらのアーキテクチャ上の意思決定が、帯域幅、スループット、QoS(Quality of Service)、消費電力、安全性、コストを決定付けるとともに、一流製品と三流製品の違いはそこに表れると紹介しました。
このように全ては通信アーキテクチャの選択から始まります。1つのチップ内で通信するエレメントの数が限られているときなら、インターコネクト機能として単純なクロスバー方式を採用するという選択もあり得るでしょう。しかしシステム内のエレメントの数が増え始め、さらにエレメント間の距離が意図されたクロック周期に対して長くなってくると、クロスバーではもはやどうにもならず、NoC(Network-on-Chip)方式を採用する必要があります。NoC方式を採用する必要性を理解するために、まずはクロスバーについて見ていくことにしましょう。
クロスバーアーキテクチャの歴史は古く、さかのぼれば1930年代の電話交換機にまで行き着きます。クロスバー内には、トラフィックの各ソースと各ターゲットをつなぐ通信経路があり、輻輳(複数のソースが同一ターゲットに同時にトラフィックを送信する必要がある状態)が生じていない限り、全ての経路を並行して使用できます。輻輳はターゲットごとのアービタによって処理され、フロー制御はソース側で処理されます。このアーキテクチャは、Arm NIC-400や旧Sonics SMXをはじめとする多くのレガシーインターコネクトファミリーの基盤になっています。
クロスバーをベースとしたスイッチングはこれまで多くの設計で用いられ、ソースとターゲットの数が限られていれば非常にうまく機能します。そのため、一部のモダンIPサブシステムでもよく見かけられます。しかしSoC設計が主流になるにつれ、倍々方式で拡張されるクロスバーアーキテクチャがすぐに非実際的なものになり、意図された機能に対して大げさすぎる(大きすぎる)ことは明白になっていきました。大規模なモダンSoCでは膨大な数のIPブロックが通信できるようにしておかなければなりません。ですが、それらの通信トラフィックのパターンからすると、全てのIPブロックが同時に通信できることが要求されるケースはめったにありません。したがってモダン設計に大規模なクロスバーを使用すれば、常に多くの経路がアイドル状態になり、クロスバーの大部分が十分に活用されない結果になるでしょう。大規模なクロスバーはかなりのダイ面積を占有するため、モダンSoCに実装するのは困難です。プロセス技術がいくら進化しても配線はトランジスタほど速く縮んではくれませんから、大規模クロスバー内の配線の密集は大きな問題になります。
もちろん、大規模なクロスバーをいくつかの小さなユニットに分割し、望ましいトポロジが形成されるようにそれらのユニットをつなぐことは可能です。ただ、複数のクロスバーを組み合わせる場合はたいてい余計な作業がついて回ります。例えば、2つのクロスバー間のインタフェースには、その接続に決められたプロトコルルールを強制するための大量のロジックが必要になります。AMBA AXIプロトコルを採用した既存のソリューションのほとんどで見られるように、クロスバー内で要求と応答を結びつける場合はこれが必須になります。
これ以外にも、クロスバー内のデータ幅は均一でなければならず、単一クロック、単一プロトコルを使用しなくてはならないなどの非効率な要件があることから、SoCの通信インフラとしてカスケード化されたクロスバーを使用することはとても最適な選択とはいえないでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.