JP4560409B2 - データを交換する集積回路および方法 - Google Patents

Description

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

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

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

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

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

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

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

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

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

信頼性の高い通信：オン・チップ・リソースの制約条件が厳格であることから、ネットワーク・コンポーネント（ルータやネットワーク・インタフェース）をかなりシンプルにして計算およびメモリの要件を最小限に抑えなければならない。幸いにしてオン・チップ配線は信頼性の高い通信媒体を提供するので、信頼性の高い通信をオフ・チップ・ネットワークで行う場合にかかるかなりのオーバーヘッドを避けることができる。データ・リンク層では、データの完全性が低コストで得られる。

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

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

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

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

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

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

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

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

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

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

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

マスタがスレーブにデータを送信する必要があるときに、スレーブは、スレーブのバッファ領域が満杯であっても、マスタを直接停止することができない。バッファ・オーバーフローを避けるためには、スレーブはそのマスタのためのバッファ領域を予約し、マスタに対し、バッファ領域の利用可能性（すなわち、より多くのバッファ領域を使い切るタイミング）を常に知らせるという、何らかの同意がマスタとスレーブの間に必要である。ただし、この方法では、ネットワークに余計なトラフィックが発生し、（たとえば、悲観的なバッファ割り当てのために）ネットワーク・リソースの利用が効率的でなくなるおそれがある。

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

エンド・ツー・エンドのフロー制御は、モジュール間の接続においてデータがドロップされないようにするために、マスタとスレーブの間に実装される。データが、要求された順序どおり、かつ、時間どおりに着信するので、ネットワーク内で競合や「トラフィック・ジャム」が発生しない。ただし、エンド・ツー・エンドのフロー制御の実装にはコストがかかる。

本発明の目的は、低コストでのトランザクションの完了を保証する集積回路と、この集積回路にてメッセージを交換する方法を提供することにある。

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

この目的のため、複数の処理モジュールＭ，Ｓと、第１のモジュールＭと少なくとも一つの第２のモジュールＳとの間で少なくとも一つの接続を提供する集積回路が設けられる。前記接続は、前記第１のモジュールから前記第２のモジュールへの送信メッセージと、前記第２のモジュールから前記第１のモジュールへの応答メッセージとを含むトランザクションをサポートする。前記集積回路は、前記第１および第２のモジュールＭ，Ｓにより交換されるデータをドロップする少なくとも一つのドロップ手段ＤＭを有する。

したがって、トランザクションの完了のための代替の方式が設けられ、完全かつ中間のトランザクションの完了は、特定の場合のみ適用される。

本発明は、特定の場合にデータのドロップを許容するアイデアに基づいている。

本発明の一態様によれば、モジュールＭ，ＳとネットワークＮ，ＲＮとの間のインタフェースを管理する少なくとも一つのインタフェース手段ANIP,PNIPを備えた集積回路が設けられる。前記インタフェース手段ANIP,PNIPは、データをドロップする第１のドロップ手段ＤＭを有する。データのドロップとトランザクションの完了は、前記インタフェース手段により制御されうる。

本発明の他の一態様によれば、集積回路は、データをドロップすることなくデータを進める複数のネットワークルータを有するネットワークＮ，ＲＮを備えている。すなわち、前記インタフェース手段のみがデータをドロップすることが許容される。

本発明の他の一態様によれば、前記ドロップ手段ＤＭは、データがドロップされたときにエラーメッセージを生成する。このため、前記データの供給源は、前記データのドロップを通知され、その供給源は前記データを後に再送信でき、その場合、他のトランザクションの一部となる。

本発明の他の一態様によれば、前記度ドロップ手段ＤＭは、前記エラーメッセージを第１のドロップ手段ＤＭに送信する。したがって、エラーメッセージは、前記インタフェース手段内の前記ドロップ手段に送信される。

本発明の他の一態様によれば、前記ドロップ手段ＤＭは、前記エラーメッセージを前記第１のモジュールＭに送信する。このエラーメッセージは、直接前記第１のモジュールに送信される。

本発明の他の一態様によれば、前記インタフェース手段ANIP,PNIPは、受信されたエラーメッセージを格納する。このため、前記インタフェース手段は、トランザクションの完了を追跡することができる。

前記第１のモジュールＭに接続されたインタフェース手段ANIPは、エラーメッセージをドロップしないようにする。

本発明はまた、複数のモジュールを備えた集積回路内でメッセージを交換する方法に関する。前記複数のモジュール間のメッセージは、ネットワークを介する接続にて交換され、前記第１および第２のモジュールＭ，Ｓにより交換されるデータはドロップされうる。

本発明はまた、上述した複数のモジュールを有する集積回路内でメッセージを交換する方法に関する。

本発明の他の一態様は、従属請求項に記載されている。

本発明のこれらの態様と他の態様は、以下の実施形態を参照して明確化される。

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

図１は、第１の実施形態によるシステム・オン・チップを示す。このシステムは、マスタ・モジュールＭ、スレーブ・モジュールＳを含む。図１にはスレーブ・モジュールを１つだけ示しているが、システムは複数のスレーブ・モジュールを含むこともできる。各モジュールは、それぞれネットワーク・インタフェースＮＩを介してネットワークＮに接続される。ネットワーク・インタフェースＮＩは、マスタおよびスレーブ・モジュールＭ、ＳとネットワークＮの間のインタフェースとして用いられる。ネットワーク・インタフェースＮＩは、それぞれのモジュールとネットワークＮの通信を管理するために設けられる。これらにより、各モジュールは、ネットワークまたは他のモジュールとの通信を扱うことなく、各自の専用動作を実施できる。各ネットワーク・インタフェースは、データおよびメッセージをバッファリングするバッファを含む。

この実施形態による通信は、トランザクション・ベースである。これらのトランザクションは、要求と、場合によって応答からなる。通常、要求は、マスタＭによって開始され（ａ）、２つのネットワーク・インタフェースＮＩおよびネットワークＮを介してスレーブＳに送信される（ｂ）。スレーブＳは応答する場合があり（ｃ）、応答はマスタＭに返信される（ｄ）。ただし、スレーブＳからの応答が必須でないトランザクションもありうる。そのような場合、トランザクションは、スレーブＳによって実行された時点で完了する。応答があるトランザクションは、応答がマスタＭに配信された時点で完了する。したがって、マスタは、応答を受信した場合のみ、トランザクションの完了を検知できる。ネットワークにフロー制御が実装されている限り、応答だけでなく要求の配信も保証され、したがって、トランザクションの完了が保証される。ただし、エンド・ツー・エンドのフロー制御が実装されていない場合は、要求も応答もドロップされる可能性があるため、トランザクションの完了は保証されない。

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

ここで、ネットワークＮ、ＲＮ（すなわち、ルータ）はデータをドロップしないものとする。アクティブ・ネットワーク・インタフェースＡＮＩＰは、パッシブ・ネットワーク・インタフェースＰＮＩＰと同様に、ドロップ・マネージャＤＭをそれぞれ含む。これらのドロップ・マネージャＤＭは、データまたはメッセージのドロップを担当する。つまり、ネットワーク・インタフェースだけがデータまたはメッセージをドロップできる。特に、要求は、アクティブ・ネットワーク・インタフェース・ポートＡＮＩＰだけがドロップでき、応答は、パッシブ・ネットワーク・インタフェース・ポートＰＮＩＰだけがドロップできる。可能なシナリオとして、（ａ）最も古いメッセージをドロップする（ミルク・ポリシー）や、（ｂ）最も新しいメッセージをドロップする（ワイン・ポリシー）などがある。

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

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

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

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

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

トランザクションを構成するメッセージは、送信メッセージ（CMD、OUTDATA）と、応答メッセージ（RETDATA、RETSTAT）とに分かれる。トランザクション内では、ＣＭＤは他のすべてのメッセージに先行し、RETDATAは、RETSTATに先行する（RETSTATがある場合）。これらのルールは、マスタとＡＮＩＰの間、およびＰＮＩＰとスレーブの間の両方にあてはまる。

応答をしないトランザクション（たとえば、posted write）は、スレーブで実行された時点で完了したとされる。マスタに対する応答メッセージがないため、トランザクションの完了に関する保証を与えることができない。応答をするトランザクション（たとえば、acknowledged write）は、ＡＮＩＰからのRETSTATメッセージが受信された時点で完了したとされる。データが応答（RETDATA）として受信されるときには、RETSTAT（場合によっては暗黙的）もデータを検証するために受信されることを想起されたい。トランザクションは、正常に実行されて成功RETSTATが返される場合や、スレーブでの実行に失敗して実行エラーRETSTATが返される場合や、フロー制御がない接続でバッファ・オーバーフローのために失敗してオーバーフロー・エラーがレポートされる場合がある。応答を必要とするＣＭＤをスレーブが受け付けた場合、スレーブＳは必ず応答を生成するものとする。

ドロップ・マネージャＤＭは、バッファ・オーバーフローが発生した場合にデータをドロップできる。CMD、OUTDATA、RETDATAはすべて、ドロップされる可能性がある。トランザクションの完了を保証するために、RETSTATはドロップできないようになっている。したがって、すべての未処理トランザクションのRETSTATメッセージを収容するために、ＡＮＩＰに十分なバッファ領域を設けなければならない。これは、未処理トランザクションの数に上限を設定することによって実現される。

上記システムに複数のスレーブＳがある場合は、応答メッセージまたは応答メッセージを以下のようにまとめることができる。（マスタＭが開始した）各書き込みトランザクションがすべてのスレーブＳによって正常に実行された場合は、すべてのスレーブＳがRETSTAT=RETOKメッセージを返す。これらを、ＡＮＩＰが１つのメッセージにまとめてマスタに配信できる。

書き込みトランザクションが一部のスレーブによってのみ正常に実行された場合は、RETOKとRETERRORが混ざったRETSTATになる。それらは、次のいずれかのようにまとめることができる。

ａ）単一のRETSTAT=RETERROR（エラーが発生したことを明示するため）、または
ｂ）単一のRETSTAT（ただし、エラーがあった場所をエンコードした、より大きく、より記述的なもの）
すべてのRETSTATを１つのマスタ向けRETSTATにまとめるか、＜スレーブ識別，エラー・コード＞のペアをまとめて１つのマスタ向けRETSTATを形成することができる。

フロー制御がない接続の場合は、ドロップ・マネージャＤＭがメッセージをドロップでき、その場合は、RETSTAT=RETLOSTメッセージも生成される。その場合も、上記と同様にまとめることができる。

マスタ・モジュールＭは、トランザクションに対する応答を必ず受信しなければならない。これは、ドロップ・マネージャＤＭによって達成される。パッシブ・ネットワーク・インタフェース・ポートＰＮＩＰ内のドロップ・マネージャＤＭが、たとえば、バッファ・オーバーフローが発生したためにデータまたはメッセージをドロップした場合、ドロップ・マネージャＤＭは必ずＡＮＩＰにFAIL/ERRORメッセージを返す。この返信ステータス（RETSTAT）・メッセージは、アクティブ・ネットワーク・インタフェース・ポートＡＮＩＰのドロップ・マネージャによって絶対にドロップされない。これは、トランザクションを開始したＡＮＩＰが、その開始したすべてのトランザクションの応答メッセージのための領域を予約するからである。このように、領域を予約しておいて、メッセージがドロップされたときに必ずエラー・メッセージを生成することが、フロー制御を導入する１つの方法である。RETSTATメッセージは中間ネットワーク・ノードで生成することもできるが、スレーブ・モジュールのインタフェースで生成することが好ましい。

上記ドロップ方式を実装することによって、トランザクションの完了が保証される。すなわち、開始されたトランザクションの結果が、以下のように必ず通知される。

ａ）スレーブに配信され、スレーブで正常に実行された場合は、スレーブがRETSTAT＝ＯＫを生成する。

ｂ）スレーブに配信されなかった場合は、ＰＮＩＰがRETSTAT＝REQLOSTを生成し、ＡＮＩＰに返す。

ｃ）スレーブに配信されたが、正常に実行されなかった場合は、スレーブがRETSTAT＝ERRORを生成する。

ｄ）スレーブに配信され、スレーブで正常に実行されたが、応答メッセージがドロップされた場合は、ＡＮＩＰがRETSTAT＝RETLOSTを生成し、マスタＭに配信する。

これは、フロー制御された接続では、メッセージ（この場合はRETSTAT（ＯＫまたはERROR））をドロップしないことによって達成され、フロー制御されない接続では、メッセージがドロップされることを許容し、メッセージがドロップされたときにＲＥＳＴＡＴ（REQLOSTまたはRETLOST）を生成し、メッセージがドロップされないときにRETOKまたはRETERRORを通常どおりに生成することによって達成される。

ただし、トランザクションを完了させるのはRETSTATなので、RETSTATを絶対ドロップしないことがきわめて重要である。これは、RETSTAT用バッファをマスタのＡＮＩＰに配置することによって実現される。マスタのＡＮＩＰは、トランザクションの開始時にRETSTAT用の領域を予約し、未処理トランザクションの数に上限を設ける（RETSTATバッファのサイズが有限のため）。

送信接続のフロー制御と返信接続のフロー制御は、原則として独立している。したがって、送信にも返信にもフロー制御がある場合、RETSTATメッセージは、上記のａ）またはｃ）に従う。送信にフロー制御があって返信にフロー制御がない場合、RETSTATメッセージは、上記のａ）またはｃ）またはｄ）に従う。送信にフロー制御がなく返信にフロー制御がある場合、RETSTATメッセージは、上記のａ）またはｂ）またはｃ）に従う。

上記システムについては、接続を以下のように分類できる。

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

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

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

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

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

ネットワークを介する通信は、接続上のネットワーク・インタフェースによって実施される。すなわち、マスタ・モジュールとスレーブ・モジュールは、ネットワークからは見えない。接続は、保証されたスループット、上限のある待ち時間およびジッタ、順序付けられた配信、またはフロー制御などの様々なプロパティを有する通信を記述および識別するために用いられる。本発明の実施形態による接続は、所望のプロパティで生成または確立されてから使用されなければならない。このことがネットワーク内でのリソースの予約（たとえば、バッファ領域や、時間単位あたりのリンク利用率）につながっている。要求されたリソースが利用できない場合、ネットワークＲＮはその要求を拒否する。接続は利用後に閉じられ、その接続によって占有されていたリソースが解放される。

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

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

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

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

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

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

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

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

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

一代替実施形態では、前述のドロップ手段を、ネットワークのいくつかのルータに実装して、それらのルータがデータをドロップできるようにすることができる。ただし、そのような場合、それらのルータは、上記の方式に従い、特に、上記のエラー・メッセージを生成しなければならない。

本発明の別の代替実施形態では、接続ベースではないシステムにトランザクションの完了を実装できる。そのようなシステムは、単一接続を有するシステムと等価だからである。

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

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

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

Claims (2)

1. 集積回路であって：
   第１及び第２の処理モジュールと、
   前記第１の処理モジュールから前記第２の処理モジュールへの送信メッセージと、前記第２の処理モジュールから前記第１の処理モジュールへの応答メッセージとを含むトランザクションをサポートするネットワークオンチップと、
   前記第１及び第２の処理モジュールのそれぞれと前記ネットワークオンチップとの間のインタフェース手段とを具え、
   前記インタフェース手段は、前記第１及び第２の処理モジュールにより交換されるデータを選択的に廃棄する廃棄手段を具え、
   トランザクションの完了又は失敗を示す完了確認メッセージは廃棄されず、コマンドメッセージ、送信メッセージ及び応答メッセージは廃棄されえ、
   データの廃棄及びトランザクションの完了は前記インタフェース手段により制御される、
   集積回路。
2. 前記第２の処理モジュールに対応する前記インタフェース手段で前記廃棄手段によりデータが廃棄された場合、前記第１の処理モジュールに対応する前記インタフェース手段へエラーメッセージが送信される、請求項１に記載の集積回路。

Images