JP2006502650A - トランザクションを確立するための集積回路および方法 - Google Patents

Abstract

複数の処理モジュールと、第１のモジュールと少なくとも一つの第２のモジュールとの間に少なくとも一つの接続を設けるネットワークとを備える集積回路が設けられる。前記接続は、それぞれが接続特性のセットを持つ通信チャネルのセットを有する。前記接続は、前記第１のモジュールから前記第２のモジュールへの送信メッセージと前記第２のモジュールから前記第１のモジュールへの応答メッセージとを含むトランザクションをサポートする。前記接続の異なる通信チャネルの接続特性は、個別に調整可能である。それゆえ、モジュール間の接続は実際の要求に効率的に適応できるため、チップ上のネットワークのリソースの利用はより効率的である。この結果、接続は必要以上に多くならず、未使用のネットワークリソースは他の接続に割り当てることができる。

Description

本発明は、複数の処理モジュールと、処理モジュール間の接続を提供するために構成されたネットワークとを有する集積回路、およびそのような集積回路においてメッセージを交換する方法に関する。

シリコン上のシステムは、新機能や既存機能の改良を実装することへの要求が絶え間なく増えていることにより、複雑化し続けている。これは、集積回路上に組み込むコンポーネントの集積度を高めることによって可能になっている。同時に、回路を動作させるクロックの速度も高まる傾向にある。コンポーネントの集積度の高まりに加えてクロック速度が上がることにより、同じクロック・ドメインでの同期動作が可能な領域が小さくなっている。そのため、モジュラー手法が必要になった。モジュラー手法では、処理システムは、複数の、相対的に独立した、複雑なモジュールを含む。従来の処理システムでは、システム・モジュールは、バスを介して互いに通信するのが普通であった。しかしながら、モジュールの数が増えるにつれ、この通信方法は次の理由で非実用的になる。まず、モジュール数が多くなると、バスの負荷が過大になる。また、１つの素子しかバスにデータを渡すことができないので、バスは通信のボトルネックになる。こうした短所を克服する効果的な方法が、通信ネットワークによって得られる。

非常に複雑なチップの相互接続の問題の解決策として、近年、ネットワーク・オン・チップ（ＮｏＣ）が多くの注目を集めている。理由は２つある。第１に、ＮｏＣは、グローバル配線を構成および管理するので、新しいディープサブミクロン技術の電気的問題を解決するのに役立つ。同時にＮｏＣは、配線を共有して、配線数を少なくし、配線の利用度を上げる。ＮｏＣはさらに、エネルギー効率や信頼性が高く、バスよりスケーラブルである。第２に、ＮｏＣは、計算と通信を分離する。このことは、数十億規模のトランジスタ・チップの設計を管理する上で必須である。ＮｏＣがこの分離を実現できるのは、ＮｏＣが最初からプロトコル・スタックを用いて設計されているからである。プロトコル・スタックは、通信サービスの使用とサービスの実装とを分離する、明確に定義されたインターフェースを提供する。

ただし、システム・オン・チップ（ＳｏＣ）の設計時に、オン・チップ通信にネットワークを用いようとすると、検討を要する新たな問題がいくつも持ち上がる。これは、通信モジュール同士が直接接続される既存のオン・チップ相互接続（たとえば、バス、スイッチ、ポイント・ツー・ポイント配線など）と異なり、ＮｏＣでは、モジュール同士がネットワーク・ノードを隔てて通信するためである。結果として、相互接続のアービトレーションが集中型から分散型に変わり、順序が乱れたトランザクション、待ち時間の増加、エンド・ツー・エンド・フロー制御などの課題は、知的所有権ブロック（ＩＰ）またはネットワークによって処理されなければならない。

これらの問題のほとんどは、既に、並列マシン相互接続ネットワークの相互接続という、ローカル・エリア・ネットワークおよびワイド・エリア・ネットワーク（コンピュータ・ネットワーク）の分野における研究課題になっている。両方ともオン・チップ・ネットワークと非常に関連性があり、それらの分野における結果の多くはオン・チップにも適用できる。ただし、ＮｏＣの前提条件はオフ・チップ・ネットワークと異なるため、ネットワーク設計の選択肢のほとんどについて評価をし直す必要がある。オン・チップ・ネットワークは、異なるプロパティ（たとえば、リンク同期がより緊密）および制約条件（たとえば、メモリ・コストがより高い）を有するため、設計の選択肢も異なり、これが最終的にはネットワーク・サービスに影響を及ぼす。

ＮｏＣがオフ・チップ・ネットワークと異なるのは、主にその制約条件と同期においてである。通常、リソースの制約条件は、オン・チップのほうがオフ・チップより厳格である。ストレージ（つまり、メモリ）や計算のリソースはオン・チップのほうが比較的高価であるが、ポイント・ツー・ポイント・リンクの数はオン・チップのほうがオフ・チップより多い。ストレージが高価であるのは、ＲＡＭなどの汎用オン・チップ・メモリが多くの領域を占めるからである。メモリを比較的小さいサイズでネットワーク・コンポーネント内に分散させることは、メモリ内のオーバーヘッド領域が支配的になるため、さらによくない。

また、オン・チップ・ネットワークの場合は、計算も、オフ・チップ・ネットワークに対して比較的高コストになる。オフ・チップ・ネットワーク・インターフェースは、通常、プロトコル・スタックをネットワーク層以上に実装してホスト・プロセッサを通信処理から解放する専用プロセッサを含む。専用プロセッサをネットワーク・インターフェースに内蔵することは、オン・チップでは不可能である。ネットワーク・インターフェースのサイズが、ネットワークに接続されるＩＰと同等か、それより大きくなるからである。さらに、プロトコル・スタックをＩＰそのものの上で実行することも不可能であろう。多くの場合、これらのＩＰは専用機能を１つしか持たず、ネットワーク・プロトコル・スタックを実行する機能を持たないからである。

ネットワーク・コンポーネントを接続する配線およびピンの数は、オン・チップのほうがオフ・チップより桁違いに多い。それらの配線およびピンは、ＮｏＣ通信以外の用途に大量に使われていない限り、広いポイント・ツー・ポイント相互接続（たとえば、３００ビット・リンク）を可能にする。これは、リンクが（８〜１６ビットと）比較的狭いオフ・チップでは不可能である。

さらにオン・チップの配線はオフ・チップより比較的短いため、オフ・チップより格段に緊密な同期が可能である。これにより、通信をより小さな細分性で行うことができるため、ルータ内のバッファ領域を小さくできる。現在の半導体技術では、配線の速度や信頼性も高いので、リンク層プロトコルをよりシンプルにすることができる（たとえば、エラー訂正や再送信が不要）。これは、メモリや計算のリソースの不足を補うことにもなる。

信頼性の高い通信：オン・チップ・リソースの制約条件が厳格であることから、ネットワーク・コンポーネント（ルータやネットワーク・インターフェース）をかなりシンプルにして計算およびメモリの要件を最小限に抑えなければならない。幸いにしてオン・チップ配線は信頼性の高い通信媒体を提供するので、信頼性の高い通信をオフ・チップ・ネットワークで行う場合にかかるかなりのオーバーヘッドを避けることができる。データ・リンク層では、データの完全性が低コストで得られる。ただし、データ損失もまたネットワーク・アーキテクチャに依存する。これは、ほとんどのコンピュータ・ネットワークにおいて、ネットワーク内で輻輳が生じた場合にはデータが単純にドロップされるのと同様である。

デッドロック：コンピュータ・ネットワーク・トポロジは、一般に不規則な（場合によっては動的な）構造を持ち、これがバッファ循環をもたらす可能性がある。デッドロックは、たとえば、トポロジまたはルーティングのいずれかに制約条件を設けることによって避けることもできる。ファットツリー・トポロジは、ＮｏＣへの導入が既に検討されている。この場合、デッドロックは、バッファ・オーバーフロー時にネットワーク内のパケットを戻すことによって回避できる。システム設計におけるタイルベースの手法では、メッシュまたはトーラスのネットワーク・トポロジを用いる。この場合、デッドロックは、たとえば、ターン・モデル・ルーティング・アルゴリズムを用いて避けることができる。デッドロックの主な原因は、バッファ内の循環である。デッドロックを避けるには、ルーティングが循環しないようにしなければならない。これは、信頼性の高い通信を達成するコストを低くするためである。デッドロックの第２の原因は、トランザクションのアトミック・チェーンである。これは、モジュールがロックされている間、トランザクションを格納するキューがアトミック・トランザクション・チェーン外のトランザクションでいっぱいになる場合があり、チェーン内のトランザクションのアクセスが阻止され、ロックされたモジュールに到達できなくなることによる。アトミック・トランザクション・チェーンに対応するプロセッサ（ＭＩＰＳなど）と互換であるようにアトミック・トランザクション・チェーンを実装しなければならない場合は、ネットワーク・ノードがアトミック・チェーン内のトランザクションを選別できなければならない。

データの順序付け：ネットワーク内では、ソースから宛先に送信されたデータの着信順序が、（経路の違い、ドロップ後の再送信などによる）ネットワーク・ノードでの再順序付けのために乱れる場合がある。オフ・チップ・ネットワークでは、データ配信の順序が乱れるのはよくあることである。しかし、データのドロップがないＮｏＣでは、ソースと宛先の間のデータの経路を強制的に同じにして（確定的経路選択）、再順序付けをなくすことができる。このような順序どおりのデータ転送では、必要なバッファ領域が小さくてすみ、再順序付けモジュールが不要になる。

ネットワーク・フロー制御およびバッファリング戦略：ネットワーク・フロー制御およびバッファリング戦略は、ネットワークにおけるメモリ利用度に直接影響する。ワームホール・ルーティングの場合は、ルータ内に（キューごとに）軽快なバッファがあるだけでよいが、ストア・アンド・フォワード・ルーティングやバーチャル・カット・スルー・ルーティングの場合は、少なくともパケットを収容するバッファ領域が必要である。したがって、オン・チップの場合は、バーチャル・カット・スルー・ルーティングやストア・アンド・フォワード・ルーティングよりワームホール・ルーティングのほうが好ましいと考えられる。同様に、入力キューイングは、キューの数が少ないという理由で、バーチャル出力キューイングや出力キューイングなどのバッファリング戦略よりメモリ・コストの低い選択肢であろう。専用（低コスト）ＦＩＦＯメモリ構成も、バーチャル・カット・スルー・ルーティングや仮想出力キューイングをオン・チップで用いて性能を上げることを可能にする。ただし、バーチャル・カット・スルー・ルーティングとバーチャル出力キューイングを同時に用いるのは、やはりコストがかかりすぎる。

時間に関する保証：オフ・チップ・ネットワークでは、パケット交換を用いてベスト・エフォート・サービスを提供するのが普通である。ネットワーク・ノードごとに競合が発生する可能性があるため、待ち時間の保証を提供するのは非常に困難である。レートベースの交換やデッドラインベースのパケット交換のような方式でもスループットの保証を提供することはできるが、バッファリングのコストが高い。そのような時間に関する保証を提供する一選択肢は、どの回路も１つのネットワーク接続の専用として動作する時分割多重アクセス（ＴＤＭＡ）回路を用いることである。回路は、比較的低いメモリ・コストおよび計算コストで保証を提供する。保証した帯域幅の使い残りが生じた場合にそれをベスト・エフォート通信に利用できるようなネットワーク・アーキテクチャにすると、ネットワーク・リソースの利用度が上がる。

オン・チップ相互接続にネットワークを導入すると、その通信は、バスやスイッチなどの直接相互接続から根本的に変化する。これは、通信モジュール同士が直接接続されず、１つまたは複数のネットワーク・ノードで隔てられる、ネットワークのマルチホップ性による。これは、広く普及している、モジュール同士が直接接続される既存の相互接続（すなわち、バス）と対照的である。この変化の影響は、（集中型から分散型に変わる必要のある）アービトレーションと通信プロパティ（たとえば、順序付けやフロー制御）に現れる。

ＮｏＣとバスの違いを概説すると次のようになる。現時点ではオン・チップ相互接続としてバスが最もよく用いられているので、以下では主に、「バス」を相互接続の意味で用いる。バスの特性のほとんどは、他の直接相互接続（たとえば、スイッチ）の特性も含んでいる。マルチレベル・バスは、バスとＮｏＣとの混成である。ここでは、マルチレベル・バスは、ブリッジの機能性に応じて、単純なバスのように、またはＮｏＣのように動作するものとする。通常、バスのプログラミング・モデルは、基本バス・トランザクションのシーケンスとして実装されるロード操作とストア操作からなる。通常、バス・インターフェースは、コマンド、アドレス、データ書き込み、およびデータ読み出しに対応する専用の配線グループを有する。バスは、複数のＩＰによって共有されるリソースである。したがって、ＩＰは、バスを使用する前に、アービトレーションのフェーズを踏まなければならない。このフェーズでは、ＩＰがバスへのアクセス権を要求し、それが認められるまでアクセスをブロックする。

バス・トランザクションには、要求と、場合によっては応答が関与する。要求を発行するモジュールをマスタと呼び、要求に応えるモジュールをスレーブと呼ぶ。一対の要求と応答に対して単一のアービトレーションが存在する場合は、そのバスを非スプリット・バスと呼ぶ。この場合、バスは、（時間がかかっても）応答が配信されるまで、トランザクションのマスタに割り当てられたままである。これに対し、スプリット・バスの場合、そのバスは、別のマスタからのトランザクションの開始を許可する要求があると解放される。ただし、応答に対して新たなアービトレーションを実施して、スレーブがバスにアクセスできるようにしなければならない。

スプリット・バスの場合も非スプリット・バスの場合も、通信を行う双方がトランザクションのステータスに直接かつ即時にアクセスできる。これに対し、ネットワーク・トランザクションは、ソースにある出力バッファから宛先にある入力バッファへの片方向転送であるため、宛先側で発生した何らかのアクションをソース側で知覚することができない。ネットワーク・トランザクションの結果は、追加のトランザクションによってのみ観察できる。要求−応答型の動作も可能ではあるが、別個のネットワーク・トランザクションが少なくとも２つ必要である。したがって、ＮｏＣのバス・ライクなトランザクションは、本質的にスプリット・トランザクションである。

トランザクションの順序付け：従来、バス上では、すべてのトランザクションが順序付けられる（Ｐｅｒｉｐｈｅｒａｌ ＶＣＩ、ＡＭＢＡ、またはＣｏｒｅＣｏｎｎｅｃｔ ＰＬＢおよびＯＰＢを参照。これは低コストで行うことが可能だが、それは、相互接続が、通信を行う双方の間の直接リンクであることから、データの再順序付けを行わないためである。しかし、スプリット・バスでは、スレーブの応答速度が様々である場合に、１つのマスタでトランザクションの全体の順序付けを行うことが性能の足かせになる可能性がある。この問題を解決するために、バス・プロトコルの近年の拡張によって、トランザクションを接続に対して実施することが可能になった。接続内でのトランザクションの順序付けは依然として残るが、接続間での順序付けの制約はなくなった（たとえば、ＯＣＰやＢａｓｉｃ ＶＣＩ）。少数のバス・プロトコルでは、そのアドバンス・モード（たとえば、Ａｄｖａｎｃｅｄ ＶＣＩ）において、接続ごとの、順序の乱れた応答を許容しているが、宛先には、要求と応答の両方が送信時と同じ順序で着信する。

ＮｏＣでは、順序付けはそれほど厳格ではない。グローバル順序付けは、非常に高いコストでのみ可能である。これは、ネットワークの分散的な性質と、グローバル順序付けに必要な集中型アービトレーションの要件とが相反するからである。ソースと宛先のペアの間のローカル順序付けであっても、コストがかかる可能性がある。データは、複数の経路で転送されると、乱れた順序で着信する可能性がある。そのような場合は、順序どおりの配信にするために、データにシーケンス番号のラベルを付け、宛先で再順序付けをしてから配信しなければならない。通信ネットワークは、複数の、部分的に接続されたノードを含む。モジュールからのメッセージは、これらのノードによって、１つまたは複数の他のノードに転送される。この目的のために、メッセージは、ネットワーク内でアドレス指定されたモジュールの場所を示す第１の情報を含む。メッセージはさらに、モジュール内の特定の場所（メモリやレジスタのアドレスなど）を示す第２の情報を含むことができる。この第２の情報は、アドレス指定されたモジュールの特定の応答を呼び出すことができる。

トランザクションのアトミック・チェーン：トランザクションのアトミック・チェーンは、単一のマスタによって開始され、単一のスレーブに対して排他的に実行されるトランザクションのシーケンスである。つまり、このチェーンの最初のトランザクションがスレーブへのアクセスを要求すると、他のマスタからそのスレーブへのアクセスが拒否される。このメカニズムは、マスタ・モジュール間の同期メカニズム（たとえば、セマフォー）を実装する場合に広く用いられる。バスには、アトミック動作を容易に実装できる。これは、中央のアービタが、（ａ）アトミック・チェーンを要求するマスタによる排他的使用のためにバスをロックするか、（ｂ）ロックされたスレーブへのアクセスを許可しないことを認識しているからである。前者の場合は、マスタがいったんバスへのアクセスを許可されれば、マスタはチェーン内のすべてのトランザクションを素早く実施できるので（チェーン内の後続のトランザクションのためのアービトレーション遅延が不要なので）、ロックされる時間リソースはより短くなる。その結果、ロックされたスレーブとバスは、短時間で再び使用可能になる。この手法は、ＡＭＢＡやＣｏｒｅＣｏｎｎｅｃｔで用いられている。後者の場合は、バスがロックされず、他のモジュールも使用できるままであるが、その分、スレーブをロックする時間が長くなる。この手法は、ＶＣＩやＯＣＰで用いられている。

アービトレーションが分散型であるＮｏＣでは、マスタは、スレーブがロックされていることを認識しない。したがって、ロックされたスレーブがトランザクションを受け付けられない状態でも、ロックされたスレーブに対するトランザクションが開始される可能性がある。その結果、それら以外のアトミック・チェーン内のトランザクションは、デッドロックを避けるために、それらをバイパスしてサービスを受けることが可能でなければならない。さらに、ＮｏＣの場合は、モジュールがロックされている時間が格段に長くなる。これは、トランザクション当たりの待ち時間がより長いためである。

媒体アービトレーション：バスとＮｏＣの重要な違いの１つが、媒体アービトレーションの方式である。バスの場合は、マスタ・モジュールが相互接続へのアクセスを要求し、アービタが、相互接続全体に対するアクセスを一度に認可する。アービタ・コンポーネントが１つしかないのでアービトレーションが集中化され、相互接続の状態と同様にすべての要求もグローバルにアービタに認識される。さらに、認可が下されても、ソースから宛先までの完全なパスが排他的に予約される。非スプリット・バスでは、アービトレーションは、トランザクションが開始されたときに一度行われる。結果として、バスは、要求と応答の両方に対して認可される。スプリット・バスでは、要求と応答は別々にアービトレートされる。

ＮｏＣも共有相互接続なので、ＮｏＣでもアービトレーションは必要である。ただし、バスの場合と異なり、アービトレーションは、各ルータで実施され、ローカル情報にのみ基づくので、分散型である。通信リソース（リンクやバッファなど）のアービトレーションは、要求または応答が進展するにつれ、増分に関して実施される。

宛先の名前と経路指定：バスの場合、コマンド、アドレス、およびデータは、相互接続に対してブロードキャストされる。それらはすべての宛先に着信し、そのうちの１つが、ブロードキャストされたアドレスに基づいてアクティブになり、要求されたコマンドを実行する。これが可能なのは、すべてのモジュールが同じバスに直接接続されているからである。ＮｏＣの場合、すべての宛先に情報をブロードキャストするには、すべてのルータおよびネットワーク・インターフェースに情報をコピーしなければならないので、実現は不可能である。これを行おうとすると、ネットワークにデータがあふれることになる。宛先モジュールへの経路を見つけるためには、アドレスをソース側でデコードするのがよい。したがって、トランザクション・アドレスは、（ａ）宛先識別子と（ｂ）宛先における内部アドレスの２つの部分を有する。

待ち時間：トランザクションの待ち時間は２つの要因によって発生する。（ａ）バスへのアクセス時間（バスが認可されるまでの時間）と（ｂ）データを転送するための相互接続にかかる待ち時間である。バスの場合は、アービトレーションが集中型なので、アクセス時間は、バスに接続されているマスタの数に比例する。転送待ち時間自体は、通常は一定であって比較的短い。これは、モジュールが直接リンクされているためである。ただし、転送速度はバス速度によって制限され、これは比較的低速である。

ＮｏＣの場合、アービトレーションは、ルータごとに後続のリンクに対して実施される。ルータごとのアクセス時間は短い。エンド・ツー・エンド・アクセス時間も転送時間も、マスタとスレーブの間のホップ数に比例して長くなる。ただし、ネットワーク・リンクは一方向でありポイント・ツー・ポイントなので、バスより高い周波数で動作でき、したがって待ち時間が短くなる。待ち時間に関する限り、バスを用いるか、ネットワークを用いるかは、相互接続に接続されているモジュールの数（アクセス時間に影響する）、相互接続の速度、およびネットワーク・トポロジの間のトレードオフである。

データ・フォーマット：ほとんどの現代的なバス・インターフェースでは、データ・フォーマットは、トランザクション・タイプ、アドレス、データ書き込み、データ読み出し、および肯定応答／エラーの返しについて、個別の配線グループで定義されている（たとえば、ＶＣＩ、ＯＣＰ、ＡＭＢＡ、またはＣｏｒｅＣｏｎｎｅｃｔ）。これは、パイプライン・トランザクションで用いられる。たとえば、読み出しトランザクションのアドレスの送信と並行して、前の書き込みトランザクションのデータを送信でき、さらにそれより前の読み出しトランザクションの結果のデータを受信できる。さらに、専用の配線グループを持つとトランザクションのデコードを簡略化できる（共用の配線セットを介して送信された様々な種類のデータを選別するメカニズムが不要になるため）。ネットワーク内では、通常、異種データ間の区別はない。データは一律に扱われ、ルータからルータに渡される。これは、ルータでの制御オーバーヘッドとバッファリングを最小限にするためである。もし、前述のグループごとに別々の配線を用いようとすると、経路指定、スケジューリング、およびキューイングを別々に行う必要があり、ルータのコストが上がる。

また、ネットワークでは、プロトコル・スタックの層ごとに、データとともに制御情報（たとえば、パケット・タイプ、ネットワーク・アドレス、またはパケット・サイズ）を供給しなければならない。この制御情報は、データの前後のエンベロープとして編成される。すなわち、最初にヘッダが送信され、次いで実際のデータ（ペイロード）が送信され、場合によってその後にトレーラが続く。同じデータに対して、そのようなエンベロープを複数用意することができ、それぞれは、ネットワーク・プロトコル・スタックの各層に対応する制御情報を搬送する。

バッファリングとフロー制御：マスタによるデータのバッファリング（出力バッファリング）は、計算と通信を分離するために、バスとＮｏＣの両方について行われる。ただし、ＮｏＣの場合は、データをマーシャリングするために出力バッファリングも必要であり、これは、（ａ）（任意で）出力データを、ネットワークで転送される、より小さなパケットに分割することと、（ｂ）データの前後にネットワーク用制御情報（パケット・ヘッダ）を追加することからなる。出力バッファのオーバーフローを避けるためには、マスタは、現在使用可能な領域を超える量のデータを生成するトランザクションを開始してはならない。出力バッファリングと同様に入力バッファリングも、計算と通信を分離するために行われる。ＮｏＣでは、入力バッファリングも、データのアンマーシャリングのために必要である。

さらに、入力バッファのフロー制御が、バスとＮｏＣとで異なる。バスの場合はソースと宛先が直接リンクされているので、宛先は、データを受け付けることができない旨をソースに直接伝えることができる。この情報はアービタも利用することができ、フル・バッファに書き込みを行おうとするトランザクションに対してバスを認可しないようにできる。

これに対し、ＮｏＣの場合は、トランザクションの宛先が、宛先の入力バッファが満杯である旨をソースに直接伝えることができない。その結果、宛先の入力バッファが満杯になってからも、場合によっては複数のソースからのトランザクションを宛先に対して開始することが可能である。入力バッファが満杯の場合、その後の着信トランザクションは受け付けられず、それらはネットワーク内に保存される。しかし、この手法では、最終的にデータがソースにまで保存される可能性があり、その間のリンクがブロックされ、ネットワークの輻輳が発生しやすい。

入力バッファのオーバーフローを避けるためには、エンド・ツー・エンドのフロー制御とともに、接続を用いることができる。マスタと１つまたは複数のスレーブの間の接続のセットアップでは、スレーブのネットワーク・インターフェースにバッファ領域が割り当てられ、マスタのネットワーク・インターフェースには、スレーブ側のバッファ領域の量を表すクレジットが割り当てられる。マスタは、宛先のスレーブの十分なクレジットを持つ場合のみ、データを送信できる。スレーブは、データを処理する際に、マスタに対してクレジットを認可できる。

本発明は、集積回路と、ネットワークの特性をより効率的に利用して集積回路内でメッセージを交換する方法を提供することを目的とする。

この目的は、請求項１による集積回路と、請求項７によるメッセージの交換方法とによって達成される。

その目的のために、複数の処理モジュールＭ；Ｉ；Ｓ；Ｔと、第１のモジュールと少なくとも一つの第２のモジュールとの間に少なくとも一つの接続を設けたネットワークＮ；ＲＮとを備える集積回路が設けられる。前記接続は、それぞれが接続特性のセットを持つ通信チャネルのセットを有する。前記接続は、第１のモジュールから第２のモジュールへの送信メッセージと第２のモジュールから第１のモジュールへの応答メッセージとを有するトランザクションをサポートする。前記接続の異なる通信チャネルの接続特性は、個別に調整可能である。

このため、チップ上のネットワークのリソースの利用は、モジュール間の接続が実際の要求に効率的に適合されうるので、より効率的である。この結果、前記接続は、必要以上に多くなくてよく、未使用のネットワークリソースは、他の接続に割り当てうる。

本発明は、異なる接続特性をもつ接続の接続チャネルを許容するという考えに基づく。

本発明の一態様によれば、異なるモジュール間での通信を管理する少なくとも一つの通信管理手段ＣＭと、前記ネットワークＮのリソースを管理する少なくとも一つのリソース管理手段ＲＭとを備える。

本発明の他の一態様によれば、前記通信管理手段ＣＭに対して、少なくとも一つの前記第２のモジュールへの接続要求を発行する。前記通信管理手段ＣＭは、それぞれが接続特性の特定のセットを持つ通信チャネルを有する接続要求を前記リソース管理手段ＲＭに転送する。前記リソース管理手段ＲＭは、前記接続特性の特定のセットを持つ通信チャネルに基づく前記接続要求が利用可能か否かを決定し、前記接続要求の利用可能性を前記通信管理手段ＣＭに応答する。前記第１および第２のモジュール間の接続は、前記接続の前記通信チャネルの特性を実施するために要求される利用可能な特性または利用可能なネットワークリソースに基づいて確立される。

本発明のさらなる一態様によれば、前記通信管理手段ＣＭは、利用可能な接続特性が前記第１および第２のモジュール間の接続要求を行うのに十分でない場合、利用可能な接続特性に基づいて接続を確立することを拒否する。接続特性は、あるネットワーク・リソースが実施されることを要求する。例えば、スループットはスロットの予約を要求し、フロー制御はバッファリングを要求する。それゆえ、ある特性を要求する接続がオープンされるか、あるいはこれらのリソースの利用可能性に依存しない。したがって、通信管理手段ＣＭは、接続のための最小限の要求に対する制御を行う。

本発明のさらなる一態様によれば、前記通信管理手段ＣＭは、前記モジュールが成功裡にトランザクションを行った場合に、前記第１および第２のモジュール間での接続をリセットするための要求を発行する。この結果、前記ネットワークリソースは、他の接続用に再度利用可能である。

本発明の他の一態様によれば、前記集積回路は、前記モジュールのそれぞれに関連づけられ、前記モジュールと前記ネットワークＮとの間の通信を管理する少なくとも一つのネットワークインタフェース手段ＮＩを備える。したがって、前記モジュールは、前記ネットワークとは独立に設計可能であり、再利用可能である。

本発明はまた、上述した複数のモジュールを備える集積回路内でメッセージを交換する方法に関する。モジュール間のメッセージは、ネットワークを介する接続で交換される。前記接続は、それぞれが接続特性のセットを持つ通信チャネルのセットを有する。前記ネットワーク上の前記接続は、前記第１のモジュールから前記題意２のモジュールへの送信メッセージと前記第２のモジュールから前記第１のモジュールへの応答メッセージとを含むトランザクションをサポートする。前記ネットワークは、前記応答メッセージとは異なる手法で送信メッセージを管理する。すなわち、前記接続チャネルは、個別に構成可能である。

本発明の他の一態様は、従属請求項として記述される。

本発明の上述した、および他の態様は、以下に記述する実施形態を参照して明らかにされる。

以下の実施形態は、システム・オン・チップに関する。すなわち、同一チップ上にある複数のモジュールが、ある種の相互接続を介して互いに通信する。この相互接続は、ネットワーク・オン・チップＮＯＣとして実施される。ネットワーク・オン・チップは、ネットワーク内に配線、バス、時分割多重、スイッチ、および／またはルータを含めることができる。前記ネットワークのトランスポート層では、接続を介してモジュール間通信を実施する。接続は、第１のモジュールと少なくとも１つの第２のモジュールの間にあって、それぞれが接続プロパティのセットを有するチャネルのセットであると考えられる。第１のモジュールと単一の第２のモジュールの間にある接続の場合、接続は２つのチャネルを含む。１つは、第１のモジュールから第２のモジュールに向かう要求チャネルであり、もう１つは、第２のモジュールから第１のモジュールに向かう応答チャネルである。要求チャネルは、第１のモジュールから第２のモジュールへのデータおよびメッセージのために予約され、応答チャネルは、第２のモジュールから第１のモジュールへのデータおよびメッセージのために予約される。ただし、接続が１つの第１のモジュールとＮ個の第２のモジュールを含む場合は、２＊Ｎ個のチャネルを用意する。接続プロパティに含めることができるのは、順序付け（順序どおりのデータ転送）、フロー制御（リモート・バッファを接続用として予約し、生成されたデータのための領域が保証される場合のみ、データの送信をデータ・プロデューサに許可する）、スループット（スループットの下限を保証する）、待ち時間（待ち時間の上限を保証する）、損失の大きさ（データのドロップ）、送信の中止、トランザクションの完了、データの正確さ、優先度、またはデータ配信である。

図１は、第１の実施形態によるシステム・オン・チップを示す。このシステムは、マスタ・モジュールＭ、２つのスレーブ・モジュールＳ１、Ｓ２を含む。各モジュールは、それぞれネットワーク・インターフェースＮＩを介してネットワークＮに接続される。ネットワーク・インターフェースＮＩは、マスタおよびスレーブ・モジュールＭ、Ｓ１、Ｓ２とネットワークＮの間のインターフェースとして用いられる。ネットワーク・インターフェースＮＩは、それぞれのモジュールとネットワークＮの通信を管理するために設けられる。これらにより、各モジュールは、ネットワークまたは他のモジュールとの通信を扱うことなく、各自の専用動作を実施できる。ネットワーク・インターフェースＮＩは、ネットワークを介して互いの間で、読み出しｒｄや書き込みｗｒなどの要求を送信できる。

図２は、第２の実施形態によるシステム・オン・チップを示す。このシステムは、２つのモジュール（すなわち、イニシエータＩおよびターゲットＴ）、ルータ・ネットワークＲＮ、およびモジュールとルータ・ネットワークＲＮの間の２つのネットワーク・インターフェースＡＮＩＰ、ＰＮＩＰを含む。ネットワーク・インターフェースは、２つのネットワーク・インターフェース・ポートＮＩＰを設けており（１つは要求ポート、１つは応答ポート）、これを通して、各モジュールがルータ・ネットワークＲＮと通信したり、ルータ・ネットワークＲＮを介して他のモジュールと通信したりする。ネットワーク・インターフェースは、モジュールを接続できるポートを１つまたは複数有する。タイプが異なる２つのポートを使用できる。１つは、マスタに接続されるアクティブ・ネットワーク・インターフェース・ポートＡＮＩＰであり、もう１つは、スレーブに接続されるパッシブ・ネットワーク・インターフェース・ポートＰＮＩＰである。イニシエータ・モジュールＩとターゲット・モジュールＴの間の通信は、要求−応答トランザクションに基づいて行われる。この場合は、マスタすなわちイニシエータ・モジュールＩが、場合に応じて何らかのデータや必要な接続プロパティを含む要求を発行することによってトランザクションを開始する。要求ＲＥＱは、アクティブ・ネットワーク・インターフェース・ポートＡＮＩＰ、ネットワークＲＮ、およびパッシブ・ネットワーク・インターフェース・ポートＰＮＩＰを介して、スレーブすなわちターゲット・モジュールＴに配信される。要求がターゲット・モジュールＴによって実行され、必要または要求に応じて、データが応答ＲＥＳＰとして返される。この応答ＲＥＳＰには、マスタまたはイニシエータ・モジュールＩに対するデータおよび／または肯定応答を含めることができる。

図１および２に示したモジュールを、前記ネットワーク・インターフェースＮＩにおいてネットワークと対話する、いわゆる知的所有権ブロックＩＰ（相互接続モジュールを内蔵できる計算素子、メモリ、またはサブシステム）とすることができる。ＮＩは、通信サービスにアクセスするためのＮＩポートＮＩＰを設けている。ＮＩは、１つまたは複数のＩＰを接続できるＮＩＰを複数有することができる。同様に、ＩＰを複数のＮＩおよびＮＩＰに接続できる。

ネットワークを介する通信は、接続上のネットワーク・インターフェースによって実施される。接続は、保証されたスループット、上限のある待ち時間およびジッタ、順序付けられた配信、またはフロー制御などの様々なプロパティを有する通信を記述および識別するために用いられる。たとえば、１Ｍｂｓの通信と２５Ｍｂｓの通信を区別し、別々に保証するために、２つの接続を用いることができる。２つのＮＩＰを、（場合によって、異なるプロパティを有する）複数の接続によって接続することができる。ここで定義する接続は、ＯＣＰやＶＣＩにおけるスレッドおよび接続の概念と同様である。ＯＣＰおよびＶＣＩでは、トランザクションの順序付けを緩和するためにのみ接続を用いるが、本願発明者らは、順序付けプロパティのみから、特にバッファリングおよびフロー制御の構成、保証されたスループット、および接続ごとに上限のある待ち時間を含むように一般化する。

図３は、第３の実施形態によるシステム・オン・チップを示す。この第３の実施形態のシステムは、第２の実施形態によるシステムをベースにしており、通信マネージャＣＭとリソース・マネージャＲＭを追加で含む。ここでは、通信マネージャＣＭとリソース・マネージャＲＭをルータ・ネットワークＲＮ内に配置しているが、１つまたは複数のネットワーク・インターフェースＮＩの中に配置することも可能である。

イニシエータ・モジュールＩがターゲット・モジュールＴからデータを読み出すか、ターゲット・モジュールＴにデータを書き込む必要がある場合は、ターゲット・モジュールＴとの接続の要求ＲＥＱが発行される。この要求ＲＥＱは、前記イニシエータＩに関連付けられたネットワーク・インターフェースのアクティブ・ネットワーク・インターフェース・ポートＡＮＩＰの要求ポートに送信される。この要求には、少なくとも１つのターゲット・モジュールの識別に関する情報（すなわち、ターゲットＩＤ）、ならびにイニシエータ・モジュールＩとターゲット・モジュールＴの間の接続のプロパティに関する情報を含めることができる。この２つのモジュールの間の接続のプロパティは、方向によって異なるようにできる。つまり、要求チャネルのプロパティと応答チャネルのプロパティとを異なるものにすることができる。

通信マネージャＣＭは、アクティブ・ネットワーク・インターフェース・ポートＡＮＩＰから要求ＲＥＱを受信した後、２つのモジュールの間のプロパティ・セットを有する通信を、リソース・マネージャＲＭに要求する。つまり、接続のプロパティ（たとえば、スループット、フロー制御）は、接続セットアップの要求時に要求される。リソース・マネージャＲＭは、必要なリソースを割り当て、それらのリソースに基づくそのような接続が可能かどうかを調べる。プロパティは、リソースの実装を必要とする（たとえば、スループットはスロットの予約を必要とし、フロー制御はバッファリングを必要とする）。したがって、何らかのプロパティを必要とする接続は、開かれるか、それらのリソースの利用可能性に依存しない。接続プロパティを利用できるかどうかは、接続セットアップ要求において識別された接続プロパティに対してネットワークがリソースを実現または用意できるかどうかに対応する。リソースの割り当ては、２とおりの方法で実施できる。１つには、チャネルおよび接続の様々なプロパティのすべてに対応するエントリを有するプロパティ・テーブルを、リソース・マネージャＲＭに含めることができる。あるいは、ネットワークの様々なプロパティのすべてを含む１つの中央プロパティ・テーブルを設けることができる。つまり、このテーブルは、集中型でも分散型でもよい。

リソース・マネージャＲＭは、利用可能な接続プロパティを調べた後、利用可能な接続（つまり、要求されたリソース）を予約し、所望のチャネルに関してどの接続が利用可能か（つまり、どの接続プロパティが利用可能か、またはどの接続プロパティの要求されたリソースが利用可能か）を通信マネージャＣＭに応答する。任意で、通信マネージャＣＭは、利用可能なプロパティとの接続を受け入れることができるが、利用可能なプロパティまたはそのリソースが受け入れられない場合には、提案された接続を拒否することも可能である。通信マネージャＣＭが、提案された接続を拒否する場合、通信マネージャＣＭは、（ＡＮＩＰを介して）イニシエータ・モジュールＩにエラー・メッセージを送信し、リソース・モジュールＲＭに対し、予約した前記接続を解放するよう要求する。通信マネージャＣＭが拒否しない場合、リソース・マネージャＲＭは、接続プロパティを設定し、前記イニシエータ・モジュールおよびターゲット・モジュールの間で、受け入れられたプロパティを有する接続を確立する。前記２つのモジュールＩ、Ｔが、イニシエータ・モジュールからの要求どおりにトランザクションを実施した後、通信マネージャＣＭが、前記リソース・マネージャＲＭに対し、接続または接続プロパティをリセットする要求を発行する。

本発明の実施形態による接続は、所望のプロパティで生成または確立されてから使用されなければならない。このことがネットワーク内でのリソースの予約（たとえば、バッファ領域や、時間単位あたりのリンク利用率）につながっている。要求されたリソースが利用できない場合、ネットワークＲＮはその要求を拒否する。接続は利用後に閉じられ、その接続によって占有されていたリソースが解放される。

接続の構成方法にさらなる柔軟性を持たせ、接続ごとのリソース割り当てをよりよいものにするために、接続の送信部分と返信部分を別々に構成することができる。たとえば、マスタとスレーブとで異なる量のバッファ領域をＮＩＰに割り当てたり、要求と応答とで異なる帯域幅を予約したりできる。

送信部分と返信部分に異なるプロパティを用いることの例を、以下で説明する。スループットが保証された接続は、利用可能なリソースより多くのリソースを予約できる場合がある。たとえば、ＡＮＩＰが、スループットを保証された読み出し接続をオープンする場合、ＡＮＩＰは、読み出しコマンド・メッセージ用とデータ読み出しメッセージ用のスロットを予約しなければならない。この２つの比率は非常に大きい場合があり（たとえば、１：１００）、その場合は、多くのスロットまたは帯域幅が読み出しコマンド・メッセージのために無駄になる。

この問題を解決するために、スループット、待ち時間、ジッタのすべてについて、接続の要求部分と応答部分の接続プロパティを別々に構成することができる。その結果、接続の要求部分の接続プロパティをベスト・エフォートにし、応答の接続プロパティにおいてスループットを保証することができる（または、逆も可能）。この例では、ベスト・エフォートの読み出しメッセージと、スループットを保証されたデータ読み出しメッセージを使用できる。この場合は、グローバルな接続保証を提供することはできないが、ベスト・エフォート・トラフィックだけを用いる場合より、全体のスループットを高くし、安定させることができる。

さらなる例として、大きなデータ・ブロックに対して読み出しコマンドだけを実行する接続を考えることができる。そのようなケースでは、フロー制御が実装されていれば、スレーブＳ、Ｔに関連付けられたネットワーク・インターフェースＰＮＩＰは小さなバッファを必要とし、マスタＭ、Ｉに関連付けられたネットワーク・インターフェースＡＮＩＰは大きなバッファを必要とする。また、保証されたスループットが必要とされる例も考えることができる。通常、保証されたスループットは、スロット・テーブルで固定サイズのスロットを予約することによって実現される。スロット・テーブルでは、各スロットに帯域幅の値が関連付けられており、スロットが追加割り当てされるほど、帯域幅の値が加算されるようになっている。このような方式では、割り当て可能な最小限の帯域幅が存在する。したがって、読み出しコマンドのためにのみ帯域幅を割り当てることは、帯域幅の効率的な運用とは言えない。読み出しコマンドで使用する帯域はごくわずかだからである。データ返信応答のほうは、予約分だけでは低速であることを示すのに十分な帯域幅を使用することになるであろう。このような非効率的な帯域幅の運用を防ぐために、接続の要求部分をベスト・エフォートとしてセットアップし（つまり、スループットを保証しない）、応答部分についてのみスループットを保証するようにできる。したがって、全体的な保証は提供されず、適度な負荷がかかるネットワークに対してのみ、そのような接続が良好に実施される。負荷の低いネットワークの場合は、ベスト・エフォートのデータをより高速で転送できるため（たとえば、帯域幅スロットの割り当てを待たなくてよいため）、この解決策でさらに高速になる可能性がある。

要求されるサービスによっては、接続の処理（すなわち、サービスの生成、クローズ、修正）に要する時間が短くなったり（たとえば、順序付けされていない、損失の多い、ベスト・エフォート接続の生成／クローズの場合）、かなり長くなったり（たとえば、スループットを保証されたマルチキャスト接続の生成／クローズの場合）する可能性がある。したがって、接続の生成、クローズ、または修正は、ごくたまに、たとえば、用途の要件が変化した場合の再構成のときなどに一緒に行われると考えられる。

通信は、接続において、要求と、場合によって応答からなるトランザクションによって行われる。要求は、操作（たとえば、read、write、flush、test-and-set、nopなど）をエンコードし、場合によって送信データ（たとえば、書き込みコマンド用）を搬送する。応答は、コマンド（たとえば、ｒｅａｄ）の結果としてのデータおよび／または肯定応答を返す。接続には、少なくとも２つのＮＩＰが関与する。接続におけるトランザクションは、必ず、１つのＮＩＰにおいて開始される。このＮＩＰを、接続のアクティブＮＩＰ（ＡＮＩＰ）と呼ぶ。接続の他のすべてのＮＩＰを、パッシブＮＩＰ（ＰＮＩＰ）と呼ぶ。

１つの接続において、複数のトランザクションが同時にアクティブになる場合がある。これは、スプリット・バスの場合より普通に起こりうる。つまり、接続のＡＮＩＰにおいて、前のトランザクションの応答が保留中の状態でトランザクションを開始することができる。接続に複数のスレーブがあれば、異なるスレーブに対して複数のトランザクションを開始できる。トランザクションは、単一のマスタ−スレーブのペアの間でも、要求と応答の両方についてパイプライン化される。原則として、トランザクションはスレーブ内でもパイプライン化できる（それが可能なスレーブの場合）。

トランザクションは、以下のメッセージから構成できる。

−コマンド・メッセージ（ＣＭＤ）は、ＡＮＩＰによって送信され、ＰＮＩＰに接続されているスレーブにおいて実行されるアクションを記述する。コマンドの例として、read、write、test-and-set、flushなどがある。コマンドだけが、トランザクションにおいて必須のメッセージである。パラメータのない単一のコマンド（たとえば、固定サイズのアドレスなし書き込み）だけを許可するＮＩＰについては、コマンド・メッセージは、たとえ暗黙的でも（つまり、ＩＰによって明示的に送信されなくても）存在すると見なす。

−データ送信メッセージ（ＯＵＴＤＡＴＡ）は、データを実行する必要があるコマンド（たとえば、write、multicast、test-and-setなど）に続いて、ＡＮＩＰによって送信される。

−データ返信メッセージ（ＲＥＴＤＡＴＡ）は、データを生成するトランザクション実行（たとえば、readやtest-and-setなど）の結果として、ＰＮＩＰによって送信される。

−肯定応答完了メッセージ（ＲＥＴＳＴＡＴ）は、コマンドが完了した時点でＰＮＩＰによって返される任意メッセージである。正常完了が伝えられる場合と、エラーが伝えられる場合がある。ＲＥＴＤＡＴＡとＲＥＴＳＴＡＴの両方を含むトランザクションの場合、この２つのメッセージを１つのメッセージにまとめて効率化を図ることができる。ただし、概念的には、これらは同時に存在する。ＲＥＴＳＴＡＴがデータの存在またはエラーを伝え、ＲＥＴＤＡＴＡがデータを搬送するからである。バス・ベースのインターフェースでは、通常、ＲＥＴＤＡＴＡとＲＥＴＳＴＡＴは、２つの独立した信号として存在する。

トランザクションを構成するメッセージは、送信メッセージ（ＣＭＤ、ＯＵＴＤＡＴＡ）と、応答メッセージ（ＲＥＴＤＡＴＡ、ＲＥＴＳＴＡＴ）とに分かれる。トランザクション内では、ＣＭＤは他のすべてのメッセージに先行し、ＲＥＴＤＡＴＡは、ＲＥＴＳＴＡＴに先行する（ＲＥＴＳＴＡＴがある場合）。これらのルールは、マスタとＡＮＩＰの間、およびＰＮＩＰとスレーブの間の両方にあてはまる。接続は、以下のように分類できる。

−単純な接続は、１つのＡＮＩＰと１つのＰＮＩＰの間の接続である。

−ナローキャスト接続は、１つのＡＮＩＰと１つまたは複数のＰＮＩＰの間の接続であって、ＡＮＩＰで開始される各トランザクションが必ず１つのＰＮＩＰによって実行される。ナローキャスト接続の一例では、ＡＮＩＰが、２つのメモリ・モジュールにマッピングされたアドレス空間でトランザクションを実施する。トランザクションは、トランザクション・アドレスに応じて、それら２つのメモリのいずれかでのみ実行される。

−マルチキャスト接続は、１つのＡＮＩＰと１つまたは複数のＰＮＩＰの間の接続であって、送信されるメッセージは複製され、各ＰＮＩＰはそれらのメッセージのコピーを受信する。マルチキャスト接続では、現在、返信メッセージが許可されていない。これは、生成されるトラフィックが膨大になるからである（つまり、宛先ごとに１つの応答が生成されるため）。また、各ＰＮＩＰからの個々の応答を単一のＡＮＩＰ向け応答にまとめなければならない点でも、ＡＮＩＰの複雑さが増すからである。この、まとめる操作だけでも、バッファ領域および／または追加計算が必要になる。

接続のために構成できる接続プロパティとして、保証されたメッセージ完全性、保証されたトランザクション完了、種々のトランザクション順序付け、保証されたスループット、上限がある待ち時間とジッタ、および接続フロー制御がある。

データの完全性とは、メッセージの内容が転送中に（事故であってもなくても）変化しないことである。本発明のネットワークの、より下位の層（すなわち、リンク層）では、データ完全性について既に解決されていると見なす。現在のオン・チップ技術では、破損のないリンク間データ転送が可能だからである。したがって、本発明のネットワーク・インターフェースは、常に、メッセージを破損することなく宛先に配信できることを保証している。

応答をしないトランザクション（たとえば、ｐｏｓｔｅｄ ｗｒｉｔｅ）は、スレーブで実行された時点で完了したとされる。マスタに対する応答メッセージがないため、トランザクションの完了に関する保証を与えることができない。

応答をするトランザクション（たとえば、ａｃｋｎｏｗｌｅｄｇｅｄ ｗｒｉｔｅ）は、ＡＮＩＰからのＲＥＴＳＴＡＴメッセージが受信された時点で完了したとされる。データが応答（ＲＥＴＤＡＴＡ）として受信されるときには、ＲＥＴＳＴＡＴ（場合によっては暗黙的）もデータを検証するために受信されることを想起されたい。トランザクションは、正常に実行されて成功ＲＥＴＳＴＡＴが返される場合や、スレーブでの実行に失敗して実行エラーＲＥＴＳＴＡＴが返される場合や、フロー制御がない接続でバッファ・オーバーフローのために失敗してオーバーフロー・エラーがレポートされる場合がある。応答を必要とするＣＭＤをスレーブが受け付けた場合、スレーブは必ず応答を生成するものとする。

ネットワーク内では、ルータがデータをドロップしないので、メッセージは常にＮＩに配信されることが保証されている。フロー制御がある接続では、ＮＩもデータをドロップしない。したがって、この場合は、メッセージ配信が自動的に保証され、それによってＩＰへのトランザクションの完了も自動的に保証される。

これに対し、フロー制御がない場合は、バッファ・オーバーフローが起こったときにネットワーク・インターフェースでメッセージがドロップされる可能性がある。ＣＭＤ、ＯＵＴＤＡＴＡ、ＲＥＴＤＡＴＡはすべて、ＮＩでドロップされる可能性がある。トランザクションの完了を保証するために、ＲＥＴＳＴＡＴはドロップできないようになっている。したがって、すべての未処理トランザクションのＲＥＴＳＴＡＴメッセージを収容するために、ＡＮＩＰに十分なバッファ領域を設けなければならない。これは、未処理トランザクションの数に上限を設定することによって実現される。

次に、単一接続内での異なるトランザクション間の順序付け要件について説明する。トランスポート層の異なる接続間では、トランザクションの順序付けは定義されない。

１つの接続には、トランザクションの順序付けを観察できるポイントがいくつかある。（ａ）マスタ・モジュールＭ、ＩがＣＭＤメッセージをＡＮＩＰに渡す順序、（ｂ）ＣＭＤがＰＮＩＰによってスレーブ・モジュールＴ、Ｓに配信される順序、（ｃ）スレーブ・モジュールＴ、Ｓが応答をＰＮＩＰに渡す順序、（ｄ）応答がＡＮＩＰによってマスタに配信される順序などである。（ｂ）、（ｃ）、（ｄ）は、すべてが常に存在するわけではないことに注意されたい。さらに、スレーブがトランザクションを実行する順序については前提はない。観察できるのは、応答の順序だけである。スレーブによるトランザクション実行の順序は、システム決定であると考えられ、相互接続プロトコルの一部ではない。

ＡＮＩＰとＰＮＩＰの両方において、同一接続上にある、異なるトランザクションに属する送信メッセージをインタリーブすることが可能である。たとえば、２つの書き込みコマンドを、それらのデータの後にのみ、発行できる。ＯＵＴＤＡＴＡメッセージの順序がＣＭＤメッセージの順序と異なる場合は、ＯＵＴＤＡＴＡをそれぞれ対応するＣＭＤに関連付けるためにトランザクション識別子を導入しなければならない。

送信メッセージは、以下のように、ＰＮＩＰによってスレーブ（ｂを参照）に配信できる：
−Ｕｎｏｒｄｅｒｅｄ（順序付けされない）：異なるトランザクションの送信メッセージのＰＮＩＰでの配信に順序付けが課されない。

−Ｏｒｄｅｒｅｄ ｌｏｃａｌｌｙ（ローカルに順序付けされる）：トランザクションが送信時の順序（ａ）で各ＰＮＩＰに配信されなければならない。ただし、ＰＮＩＰ間では順序付けは課されない。送信メッセージのローカルに順序付けされた配信は、順序付けされたデータ転送か、ＰＮＩＰでの送信メッセージの再順序付けによって実現できる。

−Ｏｒｄｅｒｅｄ ｇｌｏｂａｌｌｙ（グローバルに順序付けされる）：トランザクションが、接続のすべてのＰＮＩＰにわたって、送信時の順序で配信されなければならない。トランザクションの送信部分のグローバルに順序付けされた配信には、コストのかかる同期メカニズムが必要である。

トランザクション応答メッセージは、Ｏｒｄｅｒｅｄとして、スレーブによってＰＮＩＰ（ｃ）に配信できる。このとき、ＲＥＴＤＡＴＡメッセージとＲＥＴＳＴＡＴメッセージは、ＣＭＤがスレーブ（ｂ）に配信されたときと同じ順序か、そうでなければＵｎｏｒｄｅｒｅｄとして返される。応答が順序付けされない場合は、各応答が属するトランザクションを識別するメカニズムがなければならない。通常、これは、トランザクションの識別のためにメッセージに添付されたタグを用いて行われる（ＶＣＩのタグと同様）。

応答メッセージは、以下のように、ＡＮＩＰによってマスタ（ｄを参照）に配信できる：
−Ｕｎｏｒｄｅｒｅｄ（順序付けされない）：応答の配信に順序付けが課されない。ここではさらに、タグを用いて、各応答をそれぞれ対応するＣＭＤに関連付けなければならない。

−Ｏｒｄｅｒｅｄ ｌｏｃａｌｌｙ（ローカルに順序付けされる）：単一のスレーブに向けたトランザクションのＲＥＴＤＡＴＡメッセージとＲＥＴＳＴＡＴメッセージが、元のＣＭＤがマスタによってＡＮＩＰに渡されたときの順序で配信される。同一接続内では、異なるスレーブへのトランザクションに対して順序付けが課されないことに注意されたい。

−Ｇｌｏｂａｌｌｙ ｏｒｄｅｒｅｄ（グローバルに順序付けされる）：１つの接続におけるすべての応答が、元のＣＭＤと同じ順序でマスタに配信される。トランザクションが接続上でパイプライン化されている場合、応答のグローバルに順序付けされた配信には、ＡＮＩＰでの再順序付けが必要である。

上記の順序付けの３×２×３＝１８とおりの組合せのすべてが可能である。これらのうち、次の２つを定義して提示する。順序付けされない接続は、トランザクションのどの部分でも順序付けが前提とされていない接続である。したがって、応答にタグを付けて、どのトランザクションに属するかを識別できるようにしなければならない。順序付けされない接続の実装はコストが低いが、使いにくい場合があり、タグ付けのオーバーヘッドがかかる。

順序付けされた接続は、ＰＮＩＰからスレーブへの送信メッセージのローカルな順序付け、ＰＮＩＰでの順序付けされた応答、およびＡＮＩＰでの応答に対するグローバルな順序付けがある接続として定義される。本願発明者らは、グローバルな順序付けはコストがかかりすぎ、用途が少ないという理由で、送信部分のローカルな順序付けを選択する。応答の順序付けは、タグ付けのないシンプルなプログラミング・モデルを可能にするために選択される。ＡＮＩＰでのグローバルな順序付けは、すべての再順序付けがＡＮＩＰでローカルに行われるので、ほどほどのコストで可能である。ユーザは、送信メッセージと返信メッセージのグローバルな順序付けがある接続を、ＰＮＩＰにおいて、パイプライン化されていない肯定応答済みトランザクションを用いてエミュレートできる（ただし、待ち時間が長くかかる）。

ネットワークでは、接続のスループットを、時分割多重アクセス（ＴＤＭＡ）方式で予約できる。この場合、帯域幅は、固定時間フレーム上の固定サイズ・スロットに分割される。帯域幅は、待ち時間およびジッタの上限とともに、スロットの予約時に保証できる。それらはすべて、複数のスロットで定義される。

既述のように、ネットワークは、メッセージがＮＩに配信されることを保証する。１つのＮＩＰから送信されたメッセージは、ネットワークのマルチホップ性のため、他のＮＩＰでは、すぐには認識されない。したがって、ネットワーク上でのハンドシェイクでは、一度に１つのメッセージしか送信することができない。これにより、接続のスループットが制限され、トランザクションに待ち時間が加わる。この問題を解決し、ネットワークの利用度を上げるために、メッセージをパイプライン化しなければならない。この場合、ＰＮＩＰにおいてデータを着信時と同じレートで処理しきれないのであれば、処理者ＮＩでのバッファ領域が限られているために、フロー制御を導入してプロデューサを低速化しなければならない。さもなければ、データが失われるおそれがある。

接続のレベルにエンド・ツー・エンドのフロー制御を導入することが可能だが、これには、接続に関連付けられるバッファ領域が必要である。エンド・ツー・エンドのフロー制御を行うと、メッセージを収容できるだけの領域がＮＩＰの宛先バッファにある場合のみ、メッセージがネットワークに送信される。

エンド・ツー・エンドのフロー制御は、任意選択であり（つまり、接続が開いているときに要求される）、送信経路と返信経路とで独立に構成できる。フロー制御が提供されない場合は、バッファがオーバーフローすると、メッセージがドロップされる。オフ・チップ・ネットワークの場合と同様に、メッセージをドロップするポリシーを複数持つことが可能である。可能なシナリオとして、（ａ）最も古いメッセージをドロップする（ミルク・ポリシー）や、（ｂ）最も新しいメッセージをドロップする（ワイン・ポリシー）などがある。

フロー制御の一例は、クレジット・ベースのフロー制御である。クレジットは、受信者ＮＩの空のバッファ領域に関連付けられる。送信者のクレジットは、データを送信すると下がる。ＰＮＩＰがデータをスレーブに配信すると、送信者にクレジットが付与される。送信者のクレジットがデータの送信に不十分である場合は、送信者側のＮＩが送信を停止する。

接続に対して差別化されたサービスの必要性を示すために、トラフィックのいくつかの例を以下に示す。ビデオ処理ストリームは、一般に、損失がなく、スループットを保証された、順序どおりのビデオ・ストリームを必要とするが、破損サンプルが許容されることもある。そのようなストリームのための接続は、必須のスループット、順序付けされたトランザクション、およびフロー制御を必要とする。ビデオ・ストリームがマスタで生成される場合は、書き込みトランザクションだけが必要である。そのような場合、フロー制御された接続であれば、トランザクションの完了をさらに要求する必要はない。メッセージは絶対にドロップされず、書き込みコマンドとそのデータは必ず宛先に配信されるからである。データの完全性は、本発明のネットワークでは常に実現される（ただし、このケースでは必須ではないと考えられる）。

別の例は、キャッシュ更新である。この場合は、破損や損失がなく、待ち時間の短いデータ転送が必要であるが、順序付けとスループットの保証はあまり重要ではない。このようなケースでは、接続には、時間関連の保証は不要である。短い待ち時間は、好ましくはあっても、不可欠ではないからである。短い待ち時間は、ベスト・エフォート接続でも達成可能である。接続はさらに、損失のないトランザクションにするために、フロー制御とトランザクション完了の保証を必要とする。ただし、順序付けは不要である。キャッシュ更新には順序付けは重要ではなく、順序の乱れたトランザクションを許容すれば応答時間を短くできるからである。

ＮｏＣサービスのセットを、ネットワーク細目から抽出して定義する。これらのサービスをＩＰ設計で用いることにより、計算と通信を分離できる。既存のオン・チップ相互接続プロトコルに近づけるために、要求−応答トランザクション・モデルを用いる。これにより、現在のＩＰをＮｏＣに移行しやすくなる。高帯域幅やトランザクションの並列性など、ＮｏＣの機能をフル活用するために、接続指向通信を実現する。各接続は、それぞれ異なるプロパティで個別に構成できる。それらのプロパティには、トランザクション完了、種々のトランザクション順序付け、帯域幅の下限、待ち時間とジッタの上限、フロー制御などがある。

そのようなネットワークをオン・チップＮｏＣサービスに対して実現することは、用途をＮｏＣの実装に依存させず、設計をより堅牢にし、アーキテクチャに依存しないサービス品質戦略を可能にする、サービス・ベースのシステム設計のための前提条件である。

別の状況では、別のタイプのフロー制御がありうる（たとえば、書き込みコマンドの損失は絶対避けたいが、読み出しデータの損失は気にしない、など）。モジュールが読み出しコマンドと書き込みコマンドの両方を実行できる場合に重要になるのは、書き込みトランザクションは常に成功しなければならないが（たとえば、割り込みコントローラに書き込む場合）、読み出しトランザクションは、再試行が可能なのでクリティカルではないということである（したがって、読み出しが実行された後は、読み出しトランザクションのＣＭＤがドロップされ、読み出しが二度と行われないか、ＲＥＴＤＡＴＡがドロップされる）。別の例では、書き込みが配信されれば必ず成功することがわかっている場合に、フロー制御された接続が要求される。このケースでは、肯定応答は必須ではない。フロー制御がない場合は、肯定応答が必須であり、そのためにマスタが複雑になり、トラフィックが増える。

本発明による集積回路では、メッセージをドロップするかどうかの決定を、トランザクションごとには行わず、接続の送信部分と返信部分とについて、一括して行う。たとえば、フォーマットがｒｅａｄｓ＋ａｄｄｒｅｓｓ（またはｗｒｉｔｅｓ＋ａｄｄｒｅｓｓ＋ｄａｔａ）であるすべての送信メッセージについて損失なしを保証し、すべての返信メッセージ（データ読み出しであっても、肯定応答書き込みであっても）について、パケットをドロップ可能とすることができる。

接続は次のように開くことができる。

connid = open (
nofc/fc,
outgoing unordered/local/global,
outgoing buffer size,
return unordered/local/global,
return buffer size);
つまり、すべての送信メッセージが特定のプロパティを有し、すべての返信メッセージが特定のプロパティを有する。ここで、ｆｃはフロー制御を表し、ｎｏｆｃはフロー制御なしを表す。

ネットワークに接続されるモジュールが、（要求を開始し、応答を受信する）マスタと（要求を受信し、返信応答を送信する）スレーブのどちらかであることを考慮したうえでの、ＮｏＣにおけるデッドロックの代替の解決法は、要求と応答のそれぞれに対して別々の仮想ネットワーク（別々のバッファ付き）を持ち続けることである。

本発明の一実施形態によれば、複数のモジュールを含む集積回路においてメッセージを交換する方法は、特定のプロパティを有する、２つのモジュールの間の接続を要求し、前記特定のプロパティを有する、前記２つのモジュールの間の前記要求した接続が可能かどうかを決定し、利用可能なプロパティを有する接続を応答し、前記プロパティを有する接続を前記２つのモジュールの間で確立し、前記２つのモジュールの間でトランザクションを実施する。さらに、利用可能な接続は受け入れられることができ、前記接続のプロパティはリセット可能である。

本発明のさらなる一実施形態によれば、ネットワークは、保証された時間間隔内でメッセージが転送される第１のモードと、利用可能なリソースによる最大限の速度でメッセージが転送される第２のモードとを有し、送信トランザクションは、読み出しメッセージであって、第２のモジュールに対し、データを第１のモジュールに送信するよう要求し、返信トランザクションは、この要求を受けた第２のモジュールによって生成されたデータであり、送信トランザクションは、第２のモードに従って転送され、返信トランザクションは第１のモードに従って転送される。肯定応答される書き込みトランザクションの場合、マスタの書き込みコマンドと送信データは、保証されたスループットを用い、スレーブからの肯定応答はベスト・エフォートを用いる。時間関連の保証を除き、上記の各例には、バッファリングに関する違いもある。データ・メッセージの場合は、コマンドおよび肯定応答の場合より、多くのバッファリングが割り当てられる可能性がある。したがって、読み出しトランザクションの場合は、返信部分用のバッファが送信部分用のバッファより大きくなる。肯定応答される書き込みの場合は、送信部分用のバッファが大きく、肯定応答用のバッファは小さい。

さらなる一実施形態によれば、異なるチャネルごとに異なる帯域幅を割り当てることが可能である。ただし、制限もある。スロット・テーブルを用いる。これは、１つの時間窓に多くのスロットを含める。これらのスロットを接続に割り当てることによって、帯域幅が予約される。たとえば、１μｓの時間フレームに対して１００スロットを有するテーブルを用いる場合、各スロットは、１μｓの１００分の１、すなわち、１０ｎｓに対して割り当てられる。ネットワークがリンクごとに１Ｇｂ／ｓを用意している場合、スロットごとの帯域幅は、１Ｇｂ／ｓの１００分の１、すなわち、１０Ｍｂ／ｓになる。したがって、割り当て可能な、スループットを保証されたトラフィックは、１０Ｍｂ／ｓの複数倍に限られる。長いバーストを生成する読み出しコマンドの場合は、最小帯域幅の１０Ｍｂ／ｓを割り当てても、おそらくは、そのほんのわずかしか使用しないので、多すぎることになる。ただし、実際には、この帯域幅は、スループットを保証された別のトラフィックではなく、ベスト・エフォートのトラフィックで使用できる。その結果、保証の必要なトラフィックがすべてスロット・テーブルに収まるとは限らない。より多くのスロットを使用する選択肢もあるが、その場合は、ルータのコストが上がる。したがって、ベスト・エフォート・コマンドがよりよい解決策であろう。

本発明のさらなる一実施形態によれば、マスタと２つのスレーブの間の接続が提供され、マスタからスレーブまでの異なるチャネルごとに異なるプロパティが割り当てられる。これらのスレーブの１つは高速メモリであり、もう１つは低速メモリである。マスタと高速メモリを接続するチャネルのほうに、より高いスループットが割り当てられる。

前述のとおり、ＮｏＣは、既存のオフ・チップ・ネットワークとも既存のオン・チップ相互接続とも異なるプロパティを有する。したがって、既存のプロトコルおよびサービス・インターフェースをそのままＮｏＣに採用することはできず、採用するためには、ＮｏＣの特性を考慮しなければならない。たとえば、ＴＣＰ／ＩＰなどのプロトコルは、ネットワークに損失があることを前提としており、信頼できる通信を提供するために多大な複雑さを含んでいる。したがって、そうしたプロトコルは、データ転送の信頼性の問題がより低いレベルで既に解決されていると見なせるＮｏＣでは適切ではない。一方で、ＶＣＩ、ＯＣＰ、ＡＭＢＡ、ＣｏｒｅＣｏｎｎｅｃｔなどの既存のオン・チップ・プロトコルもまた、そのままでは適用できない。たとえば、それらは、データの順序付けされた転送を前提としている。つまり、２つの要求が同じマスタから開始された場合、それらは同じ順序で宛先に着信する。これは、ＮｏＣでは、自動的には維持されない。トランザクションのアトミック・チェーンとエンド・ツー・エンドのフロー制御もまた、ＮｏＣインターフェースにおいては格別の注意を必要とする。

ネットワーク・サービスを定義する際の目標は次のとおりである。第１に、サービスは、できるだけネットワーク内部から抽出されなければならない。これは、計算と通信を分離するという課題に取り組むうえで重要な要素である。計算と通信を分離すると、ＩＰ（計算部分）と相互接続（通信部分）とを互いに独立に設計することができる。結果として、サービスは、ＯＳＩ参照モデルのトランスポート層に配置される。この層は、ネットワークの実装から独立している最初の層である。第２に、ＮｏＣインターフェースは、できるだけバス・インターフェースに近いものでなければならない。そうすれば、ＮｏＣを非破壊的に導入できる。つまり、わずかな変更だけで、既存のＩＰ、方法体系、およびツールを使い続けることができる。結果として、スプリット・バス用インターフェースと同様の要求−応答インターフェースが用いられる。第３に、インターフェースは、従来のバス・インターフェースを、ＮｏＣの能力をフル活用できるように拡張する。たとえば、接続ベースの通信は、（バスの場合の）順序付け制約を緩和するだけでなく、クレジットに基づくエンド・ツー・エンドのフロー制御や保証されたスループットなどの新しい通信プロパティを可能にする。これらすべてのプロパティを、接続ごとに個別に設定できる。

これまで述べてきた実施形態は本発明を制限するものではなく例示するものであること、および、当業者であれば、添付の請求項の範囲から逸脱することなく様々な代替実施形態を設計できることに注意されたい。請求項においては、括弧で囲まれたどの参照符号も、請求項を制限するものとして解釈されてはならない。「含む（ｃｏｍｐｒｉｓｉｎｇ）」という語は、請求項に列挙した要素またはステップ以外の要素またはステップの存在を除外するものではない。要素の前に付く「ａ」または「ａｎ」は、そのような要素が複数存在することを除外するものではない。複数の手段を列挙した装置請求項において、それらの手段のいくつかは、同一アイテムのハードウェアで実施できる。特定の手段が、互いに異なる従属請求項に再び記載されているという単なる事実は、それらの手段の組合せを有利に使用することができないということを示すものではない。

さらに、請求項中のどの参照符号も、請求項の範囲を制限するものとして解釈されてはならない。

第１の実施形態によるチップ上のシステムを示す図。 第２の実施形態によるチップ上のシステムを示す図。 第３の実施形態によるチップ上のシステムを示す図。

Claims (7)

1. 複数の処理モジュールと、第１のモジュールと少なくとも一つの第２のモジュールとの間に少なくとも一つの接続を設けたネットワークとを備える集積回路であって、
   前記少なくとも一つの接続は、通信チャネルのセットを有し、各通信チャネルは、接続特性のセットを有し、前記接続の異なる通信チャネルの接続特性は個別に調整可能であり、
   前記接続は、前記第１のモジュールから前記第２のモジュールへの送信メッセージおよび／または前記第２のモジュールから前記第１のモジュールへの応答メッセージを含むトランザクションをサポートすることを特徴とする集積回路。
2. 異なるモジュール間での通信を管理する少なくとも一つの通信管理手段と、
   ネットワークのリソースを管理する少なくとも一つのリソース管理手段と、を備えることを特徴とする請求項１に記載の集積回路。
3. 前記第１のモジュールは、少なくとも一つの前記第２のモジュールとの接続要求を前記通信管理手段に発行し、
   前記通信管理手段は、それぞれが前記リソース管理手段への接続特性の特定のセットを有する通信チャネルとの接続に前記接続要求を転送し、
   前記リソース管理手段は、前記接続特性の特定のセットをもつ通信チャネルに基づいて、前記接続要求が利用可能であるか否かを決定し、前記接続要求の利用可能性を前記通信管理手段に応答し、
   前記第１および第２のモジュール間の接続は、前記接続の前記通信チャネルの利用可能な特性に基づいて確立されることを特徴とする請求項２に記載の集積回路。
4. 前記通信管理手段は、利用可能な接続特性が前記第１および第２のモジュールの間で要求された接続を行うのに十分でない場合、前記利用可能な接続特性に基づいて接続を確立することを拒否することを特徴とする請求項２または３に記載の集積回路。
5. 前記通信管理手段は、前記モジュールが成功裡にトランザクションを行ったとき、前記第１および第２のモジュール間での接続のリセットを要求することを特徴とする請求項２、３または４に記載の集積回路。
6. 前記モジュールのそれぞれに関連づけられ、前記モジュールおよび前記ネットワーク間での通信を管理する少なくとも一つのネットワークインタフェース手段を備えることを特徴とする請求項２、３、４および５のいずれかに記載の集積回路。
7. 複数のモジュールを備える集積回路内でメッセージを交換する方法であって、
   前記複数のモジュール間のメッセージは、ネットワークを介した接続で交換され、
   前記接続は、それぞれが接続特性のセットを持つ通信チャネルのセットを有し、前記通信チャネルは独立に構成可能であり、
   前記ネットワークを介する前記接続は、前記第１のモジュールから前記第２のモジュールへの送信メッセージと前記第２のモジュールから前記第１のモジュールへの応答メッセージとを含むトランザクションをサポートすることを特徴とする方法。

Images