(57)【要約】【課題】ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されており、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うことが可能なマルチプロセッサシステムにおいて、リクエストパケットの送出順とリクエストパケットの実行の開始順を一致させる。【解決手段】各ノードは、送信先のノードに向けて、ある処理の要求を示すリクエストパケットを送信したときに、送信先のノードを示す情報を記憶しておき、送信先のノードから処理の要求に対する応答を示すレスポンスパケットを受信するまで、送信先のノードに対して新たなリクエストパケットを送信することを禁止する。【選択図】図３
2007148753.tif 000002
【特許請求の範囲】
【請求項１】
ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されており、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うことが可能なマルチプロセッサシステムであって、
各ノードは、前記送信先のノードに向けて、ある処理の要求を示すリクエストパケットを送信したときに、前記送信先のノードを示す情報を記憶しておき、前記送信先のノードから前記処理の要求に対する応答を示すレスポンスパケットを受信するまで、前記送信先のノードに対して新たなリクエストパケットを送信することを禁止する、
ことを特徴とするマルチプロセッサシステム。
【請求項２】
請求項１記載のマルチプロセッサシステムであって、
前記各ノードは、
前記送信先のノードを示す情報を記憶するために、（全ノード数−１）よりも少ない数の複数の記憶部を備える、
ことを特徴とするマルチプロセッサシステム。
【請求項３】
請求項１または請求項２記載のマルチプロセッサシステムであって、
前記送信先のノードを示す情報は、送信したリクエストパケットと、前記送信したリクエストパケットが送信済みであることを示すフラグと、で構成される、
ことを特徴とするマルチプロセッサシステム。
【請求項４】
請求項１ないし請求項３のいずれかに記載のマルチプロセッサシステムであって、
前記マルチプロセッサシステムは、１つの半導体基板上に集積化されている
ことを特徴とするデバイスシステム。
【請求項５】
ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されるマルチプロセッサシステムにおいて、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うためのデータ通信方法であって、
各ノードにおいて、
前記送信先のノードに向けて、ある処理の要求を示すリクエストパケットを送信する工程と、
前記リクエストパケットを送信したときに、前記送信先のノードを示す情報を記憶する工程と、
前記送信先のノードから前記処理の要求に対する応答を示すレスポンスパケットを受信するまで、前記送信先のノードに対して新たなリクエストパケットを送信することを禁止する工程と、
を備えることを特徴とするデータ通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されており、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うことが可能なマルチプロセッサシステムに関する。
【背景技術】
【０００２】
マルチプロセッサシステムには、複数のプロセッサ間におけるデータ通信を行うための通信経路として、ノードとしての各プロセッサをループ状に接続する通信経路（「ループバス」あるいは「リングバス」とも呼ぶ）を用いているものがある（例えば、特許文献１，２参照）。
【０００３】
【特許文献１】特開平９−９１２６２号公報
【特許文献２】特開２００１−１２５８７５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、ループバスを用いた場合のノード間のデータ通信には、以下で説明する問題がある。
【０００５】
図１２および図１３は、ループバスを用いた場合におけるノード間のデータ通信の問題点について示す説明図である。
【０００６】
図１２および図１３は、説明を容易にするため、ノード１〜ノード３の３つのノードがループバスを介して接続されている場合を示している。
【０００７】
そして、ノード１からノード２に、連続して３つのリクエストを示すパケット（以下、「リクエストパケット」と呼ぶ）を送信する場合を例に説明することとする。
【０００８】
ここで、本明細書および図面においては、送信するリクエストパケットを、［ＲＤ−Ｒｅｑ＃１：１２］のように記述することとし、これに対して応答されるレスポンスを示すパケット（以下、「レスポンスパケット」と呼ぶ）を、［ＲＤ−Ｒｓｐ＃１：２１］のように記述することとする。「−」の前の「ＲＤ」はリクエストの種類を示し、リードリクエストは「ＲＤ」、ライトリクエストは「ＷＲ」と記述される。「−」の後の「Ｒｅｑ＃１：１２」はノード１からノード２への１番目のリクエストであることを示している。また、同様に、「Ｒｓｐ＃１：２１」はノード２からノード１への１番目のレスポンスであることを示している。なお、「Ｒｅｑ＃１：１２」のうち、「：１２」は送信元がノード１で送信先がノード２であることを示し、「Ｒｅｑ＃１」はノード１から送信する１番目のリクエストであることを示している。同様に、「Ｒｓｐ＃１：２１」のうち、「：２１」は送信元がノード２で送信先がノード１であることを示し、「Ｒｓｐ＃１」はノード２から送信する１番目のレスポンスであることを示している。
【０００９】
図１２および図１３では、具体的には、ノード１はノード２に対して、３つのリクエストパケットとして、１番目にはリードリクエスト［ＲＤ−Ｒｅｑ＃１：１２］を送信し、２番目のリクエストパケットとしてライトリクエスト［ＷＲ−Ｒｅｑ＃２：１２］を送信し、３番目のリクエストパケットとしてリードリクエスト［ＲＤ−Ｒｅｑ＃３：１２］を送信することとする。
【００１０】
なお、図１２および図１３には、８段階の動作状態が示されているが、各動作状態は、各ノードに、パケットが到着した状態を示している。
【００１１】
まず、動作状態１では、ノード１には、３つのリクエストパケットが発生しており、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が送信待ち状態となっている。
【００１２】
次に、動作状態２では、ノード１からノード２に向けて１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が送出され、ノード２にはノード１から送出された１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が到着する。そして、ノード１では、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が送信待ち状態となる。また、ノード２では、到着した１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が受信されて、対応する処理が実行される。
【００１３】
そして、動作状態３では、ノード１からノード２に向けて２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が送出され、ノード２にはノード１から送出された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が到着する。そして、ノード１では、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が送信待ち状態となる。
【００１４】
しかしながら、このとき、ノード２では、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対応する処理が実行中であり、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］を受信して、対応する処理を実行することができない。
【００１５】
そこで、次の動作状態４において、ノード２では、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］がそのままノード３に向けて送出され、ノード３にはノード２から送出された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が到着する。
【００１６】
また、動作状態４では、ノード１からノード２に向けて３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が送出され、ノード２にはノード１から送出された３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が到着する。
【００１７】
このとき、動作状態３で実行中であった１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］は終了しており、１番目のリクエストパケットに対する応答を示すレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が発生して送信待ち状態となっているので、ノード２では、到着した３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が受信されて、対応する処理が実行される。
【００１８】
次に、動作状態５では、ノード２からノード３に向けて、１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が送出され、ノード３にはノード２から送出された１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が到着する。また、ノード３からノード１に向けて、動作状態４において到着した２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が送出され、ノード１にはノード３から送出された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が到着する。
【００１９】
そして、動作状態６では、ノード１からノード２に向けて、動作状態５において到着した２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が送出され、ノード２には、ノード１から送出された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が到着する。
【００２０】
また、ノード２からノード３に向けて、送信待ち状態であった３番目のリクエストパケットに対するレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が送出され、ノード３には、ノード２から送出された３番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が到着する。そして、ノード２では、到着した２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が受信されて、対応する処理が実行されるとともに、２番目のリクエストパケットに対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が発生して送信待ち状態となる。
【００２１】
また、ノード３からノード１に向けて、動作状態５において到着した１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が送出され、ノード１にはノード３から送出された１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が到着する。
【００２２】
そして、動作状態７では、ノード２からノード３に向けて、２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が送出され、ノード３にはノード２から送出された２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が到着する。
【００２３】
また、ノード３からノード１に向けて、動作状態６において到着した３番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が送出され、ノード１には、ノード３から送出された３番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が到着する。
【００２４】
動作状態８では、ノード３からノード１に向けて、動作状態７において到着した２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が送出され、ノード１には、ノード３から送出された２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が到着する。
【００２５】
以上説明した動作説明からわかるように、ノード２で受信されて実行されるリクエストパケットは、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］、３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］、２番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］の順となって、送信された順番と異なる場合がある。
【００２６】
上記のように、リクエストパケットの送出順と、リクエストパケットの実行の開始順が異なると、例えば、動作の順番を守る必要がある処理が順に実行されるような場合に問題が発生する可能性がある。このため、上記のように、リクエストパケットの送出順と、リクエストパケットの実行の開始順が異なることがないようにすることが望ましい。
【００２７】
また、１つのノードから複数の別のノードにリクエストパケットを順番に送出した場合にも、ノードに関係なく、リクエストパケットの送出順と、リクエストパケットの実行の開始順と、が一致することが望ましい。
【００２８】
本発明は、上述の課題を解決するためになされたものであり、ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されており、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うことが可能なマルチプロセッサシステムにおいて、リクエストパケットの送出順とリクエストパケットの実行の開始順を一致させる技術を提供することを目的とする。
【課題を解決するための手段】
【００２９】
上述の課題の少なくとも一部を解決するために、本発明は、
ループ状の通信経路により接続された複数ノードのうち、少なくとも２以上のノードがプロセッサで構成されており、送信元のノードから送信先のノードに向けて前記通信経路上にパケットを送出することにより、ノード間のデータ通信を行うことが可能なマルチプロセッサシステムであって、
各ノードは、前記送信先のノードに向けて、ある処理の要求を示すリクエストパケットを送信したときに、前記送信先のノードを示す情報を記憶しておき、前記送信先のノードから前記処理の要求に対する応答を示すレスポンスパケットを受信するまで、前記送信先のノードに対して新たなリクエストパケットを送信することを禁止する、
ことを特徴とする。
【００３０】
上記構成によれば、リクエストパケットの送出順とリクエストパケットの実行の開始順を一致させることができる。
【００３１】
なお、前記各ノードは、
前記送信先のノードを示す情報を記憶するために、（全ノード数−１）よりも少ない数の複数の記憶部を備えることが好ましい。
【００３２】
上記のようにしても、（全ノード数―１）の記憶部を備える場合と同等の処理性能を維持することが可能である。
【００３３】
また、前記送信先のノードを示す情報は、送信したリクエストパケットと、前記送信したリクエストパケットが送信済みであることを示すフラグと、で構成されるようにしてもよい。
【００３４】
上記の場合、例えば、送信待ちのリクエストパケットを記憶しておく送信バッファを利用して、送信した後も、対応するレスポンスパケットを受信するまで、送信したリクエストパケットを送信バッファで記憶するようにしておけば、送信済みフラグをセットしておくための容量の小さな記憶部を用意することにより、容易に実現することが可能である。
【００３５】
なお、前記マルチプロセッサシステムは、１つの半導体基板上に集積化することが可能である。
【００３６】
本発明は、上記マルチプロセッサシステムとしての構成の他、上記マルチプロセッサシステムを備える種々の画像処理装置として構成することもできる。また、これら装置発明の態様に限ることなく、データ通信方法といった方法発明の態様で実現することも可能である。なお、本法発明の態様においても、先に示した種々の付加的要素を適用することが可能である。
【発明を実施するための最良の形態】
【００３７】
以下、本発明の実施の形態について、実施例に基づき以下の順序で説明する。
Ａ．実施例：
Ａ１．マルチプロセッサシステムの構成：
Ａ２．通信制御部の構成および動作：
Ａ３．送受信制御部の動作：
Ａ４．通信動作の具体例：
Ａ４．１．具体例１：
Ａ４．２．具体例２：
Ａ５．実施例の効果：
Ｂ．変形例：
【００３８】
Ａ．実施例：
Ａ１．マルチプロセッサシステムの構成：
図１は、本発明のマルチプロセッサシステムの一実施例としての概要構成を示す説明図である。このマルチプロセッサシステムＭＰＳは、通信経路１０を介して接続される第１〜第５の５つのノード（図中、「ノード１」〜「ノード５」と表記）として、３つのプロセッサ２０Ａ〜２０Ｃ、メモリコントローラ２０Ｄ、および、Ｉ／Ｏインタフェース２０Ｅを備えている。また、マルチプロセッサシステムＭＰＳは、各構成要素を１つの半導体基板上に集積化したマイクロプロセッサである。
【００３９】
第１〜第３のノードとしてのプロセッサ２０Ａ〜２０Ｃは、それぞれＣＰＵの他、キャッシュメモリ、ＲＯＭ、ＲＡＭ、通信制御部等の周辺回路を含むユニットを意味している。また、第４のノードとしてのメモリコントローラ２０Ｄおよび第５のノードとしてのＩ／Ｏインタフェースも、同様に、通信制御部等の周辺回路を含むユニットを意味している。
【００４０】
なお、以下の説明において、第１〜第３のノードとしてのプロセッサ２０Ａ〜２０Ｃ、第４のノードとしてのメモリコントローラ２０Ｄおよび第５のノードとしてのＩ／Ｏインタフェースを、それぞれループ状の通信経路１０に接続されるノードとして説明する場合には、第１〜第５のノードの符号を、２０Ａ〜２０Ｅとして説明することとする。
【００４１】
通信経路１０は、第１〜第５のノード２０Ａ〜２０Ｅのそれぞれが備える通信制御部（図中、「ＲＢＣ」と表記）２２Ａ〜２２Ｅの入力と出力とを、順番に接続することにより、ループ状に形成されている。そして、各ノード２０Ａ〜２０Ｅの間では、それぞれループ状の通信経路１０に接続されている通信制御部２２Ａ〜２２Ｅを介して、所定の通信内容を示すデータを通信制御部の入力から受信するとともに、通信制御部の出力から送信して、１方向にのみ伝達することにより、互いの通信が実行される。
【００４２】
所定の通信内容としては、送信先のノードにデータを書き込むためのライトリクエストメッセージや、送信先のデバイスからデータを読み出すためのリードリクエストメッセージ、これらのリクエストメッセージに対するレスポンスメッセージ等がある。そして、各ノード間で送受信されるデータは、いわゆるパケットとして構成されている。
【００４３】
図２は、各ノード間で送受信されるパケットのデータ構造について示す説明図である。
【００４４】
図２に示すように、通信経路１０を介して伝送されるパケットは、６４ビットの固定長を有しており、大きく分けて前半３２ビットのヘッダ部と、後半３２ビットのペイロード部と、で構成される。
【００４５】
ヘッダ部は、さらに、前半１６ビットの制御情報部分と、後半１６ビットのアドレス部で構成される。制御情報部分は、先頭から順に、通信内容の種類（リードリクエストメッセージやライトリクエストメッセージ等）を示すフィールド（（図中、「ＴＹＰＥ」と表記）、データサイズを示すフィールド（図中、「Ｄｓｉｚｅ」と表記）、送信先（あて先）ＩＤを示すフィールド（図中、「ＤＩＤ」と表記）、送信元ＩＤを示すフィールド（図中には、「ＳＩＤ」と表記）で構成されている。アドレス部は、送信先のデバイスに書き込むデータや、送信先のデバイスから読み出されるデータを書き込むためのメモリ（図示省略）に確保されている通信用メモリ領域のアドレスを示すフィールドで構成されている。
【００４６】
ペイロード部は、３２ビット全てが、送受信される通信データを格納するためのフィールドである。
【００４７】
ここで、通信経路１０は、上記パケットを伝送するための３２本の通信配線と、３２本の通信配線によりパラレル転送されるデータの状態を示す２ビットの状態制御データを伝送するための２本の通信配線の、計３４本の通信配線で構成されている。
【００４８】
従って、各ノード２０Ａ〜２０Ｅの通信制御部２２Ａ〜２２Ｅは、システムクロック１サイクルで、２ビットの状態制御データと、１つのパケットを構成する６４ビットのデータのうち、３２ビットのデータと、をパラレル転送することができる。つまり、あるノードの通信制御部から見ると、前段のノードの通信制御部から、６４ビットのパケットの３２ビットのヘッダ部と３２ビットのペイロード部とが、１サイクルごとに交互に送信されてくることになる。なお、以下では、２ビットの状態制御データに対応するビットを「状態制御ビット」と呼び、３２ビットのデータに対応するビットを「パケットビット」と呼ぶこととする。
【００４９】
ここで、２ビットの状態制御ビットのうち、一方の１ビットは、同じサイクルにおける３２ビットのパケットビットのデータがヘッダ部を表すデータであるかペイロード部を表すデータであるかを示すビット（Ｈビット）である。
【００５０】
具体的には、例えば、Ｈビットが「１」である場合には、同じサイクルのパケットビットのデータはヘッダ部を表すデータであることを示し、Ｈビットが「０」である場合には、同じサイクルのパケットビットのデータはヘッダ部を表すデータではないこと、すなわち、ペイロード部を表すデータであることを示す。
【００５１】
従って、あるノードの通信制御部から見ると、前段のノードの通信制御部から、システムクロック１サイクルごとに、Ｈビットとして「１」と「０」とが交互に送信されてくることになる。
【００５２】
また、２ビットの状態制御ビットのうち、他方の１ビットは、同じサイクルにおける３２ビットのパケットビットのデータが空パケットを構成するデータであるか否かを示すビット（Ｖビット）である。
【００５３】
具体的には、例えば、Ｖビットが「０」である場合には、同じサイクルにおける３２ビットのパケットビットのデータが空パケットを構成するデータであることを示し、Ｖビットが「１」の場合には、同じサイクルにおける３２ビットのパケットビットのデータが空パケットを構成するデータではなく、通常のパケットを構成するデータであることを示す。なお、通常のパケットとは、ヘッダ部に送信先ＩＤ等の制御情報を格納し、ペイロード部に通信内容に応じた通信データを格納したパケットを意味している。
【００５４】
なお、本実施例では、マルチプロセッサを構成するプロセッサ、メモリコントローラ、および、Ｉ／Ｏインタフェース等の各機能ブロックをノードとして説明しているが、各ブロックに備えられる通信制御部をノードとみることも可能である。
【００５５】
Ａ２．通信制御部の構成および動作：
図３は、ノードに備えられる通信制御部の一構成例を示す説明図である。なお、図３では、各ノードの通信制御部２２Ａ〜２２Ｅを代表して、第１のノード２０Ａの通信制御部２２Ａの構成例を示しているが、他のノードの通信制御部２２Ｂ〜２２Ｅも基本的に同じ構成である。
【００５６】
通信制御部２２Ａは、入力レジスタ２２１と、出力レジスタ２２２と、送受信制御部２２３と、送信済みフラグ部２２４と、送信バッファ２２５と、受信データバッファ２２６と、プロセッサＩ／Ｆ制御部２２７と、を備えている。
【００５７】
送信バッファ２２５は、後述するように、プロセッサＩ／ＦからプロセッサＩ／Ｆ制御部２２７を介して送信要求されたパケットを格納する複数の送信レジスタを備えている。この送信レジスタの数は、具体的には、通信経路１０に接続される全ノード数から自分の数を引いた値「４」よりも小さい「３」とされており、３つのレジスタ２２５Ａ〜２２５Ｃを備えている。
【００５８】
受信バッファ２２６は、後述するように、入力レジスタ２２１から送受信制御部２２３を介して入力されるパケットを格納する１つの受信レジスタ２２６Ａを備えている。ただし、複数の受信レジスタを備えるようにしてもよい。
【００５９】
プロセッサＩ／Ｆ制御部２２７は、図示しないプロセッサＩ／Ｆとの間で実行される、通信経路１０を介して送信するべきパケット、および、通信経路１０を介して受信したパケット、の受け渡しを制御する。例えば、図示しないプロセッサＩ／Ｆから送信要求されたパケット（例えば、ライトリクエストパケット、リードリクエストパケット等）を示すデータを、送信バッファ２２５に用意されている３つの送信レジスタ２２５Ａ〜２２５Ｃのうち、空いているレジスタに書き込みを行い、空いているレジスタが無い場合には、空いているレジスタが発生するまで待って、そのレジスタに書き込みを行う。また、受信バッファ２２６に用意されている受信レジスタ２２６Ａに新しいデータが書き込まれた場合には、そのデータをプロセッサＩ／Ｆへ受け渡す。
【００６０】
なお、本例の通信制御部２２Ａは、プロセッサとしてのノード２０Ａに備える通信制御部であるので、プロセッサＩ／Ｆとの間でのデータの受け渡しを制御するプロセッサＩ／Ｆ制御部２２７を備えているが、メモリコントローラとしてのノード２０ＤやＩ／Ｏインタフェースとしてのノード２０Ｅの場合には、適宜対応するＩ／Ｆとの間でのデータの受け渡しを制御するＩ／Ｆ制御部を備えることとなる。
【００６１】
入力レジスタ２２１は、通信制御部の入力側に接続される通信経路１０の３４ビットの配線幅に等しいビット数の記憶領域を有するレジスタである。同様に、出力レジスタ２２２は、通信制御部の出力側に接続される通信経路１０の３４ビットの配線幅に等しいビット数の記憶領域を有するレジスタである。
【００６２】
入力レジスタ２２１は、入力側の通信経路１０を介して前段のノードから送信されてくる３４ビットのデータを、システムクロックＳＣＫの各サイクルの書き込みタイミングで書き込む。同様に、出力レジスタ２２２は、送受信制御部２２３から出力されてくる３４ビットのデータを、入力レジスタ２２１と同じ、システムクロックＳＣＫの各サイクルの書き込みタイミングで書き込む。
【００６３】
従って、通信制御部２２Ａは、２サイクルのシステムクロックごとに１つのパケットを受信するとともに、送信することになる。具体的には、入力レジスタ２２１では、パケットのヘッダ部が書き込まれる第１サイクルと、パケットのペイロード部が書き込まれる第２サイクルとで、１つのパケットの受信が行われる。また、出力レジスタ２２２では、入力レジスタ２２１における第１および第２サイクルを基準に説明すると、入力レジスタ２２１に対して１サイクル遅れてパケットのヘッダ部が書き込まれる第２サイクルと、パケットのペイロード部が書き込まれる第１サイクルとで、１つのパケットの送信が行われる。なお、以下の説明においても、入力レジスタ２２１にパケットのヘッダ部が書き込まれるサイクルを第１サイクル、パケットのペイロード部が書き込まれる第２サイクルとして、説明することとする。
【００６４】
送受信制御部２２３は、後で詳述するように動作して、自分宛のパケットの受信、自分宛でないパケットの転送、および、未送信パケットの送信を制御する。
【００６５】
具体的には、送受信制御部２２３は、第１サイクルで入力レジスタ２２１に書き込まれたヘッダ部に記載のあて先に基づいて、自分宛のパケットであるか否か判断して、自分宛のパケットでない場合には、第１サイクルおよび第２サイクルの２サイクルで入力レジスタ２２１に書き込まれた６４ビットのパケットを、そのまま出力レジスタ２２２に向けて出力して、１サイクルずれた第２サイクルおよび第１サイクルで出力レジスタ２２２に書き込ませる。
【００６６】
一方、自分宛のパケットである場合には、第１サイクルおよび第２サイクルで入力レジスタ２２１に書き込まれた６４ビットのパケットを、受信バッファ２２６に向けて出力して、１サイクルずれた第２サイクルおよび第１サイクルで受信バッファ２２６の受信レジスタ２２６Ａに書き込ませる。
【００６７】
また、送受信制御部２２３は、入力レジスタ２２１に書き込まれたパケットが自分宛のパケットおよび空パケットの場合には、送信バッファ２２５の３つの送信レジスタ２２５Ａ〜２２５Ｃに書き込まれている未送信のパケットのうち、最も古いパケットを、１サイクルずれた第２サイクルおよび第１サイクルで出力レジスタ２２２に書き込ませる。なお、送信済みフラグ部２２４に用意されている３つの送信済みフラグ２２４Ａ〜２２４Ｃは、３つの送信レジスタ２２５Ａ〜２２５Ｃに対応して設けられており、例えば、それぞれ対応するレジスタに書き込まれているパケットが送信済みの場合には、「１」にセットされており、未送信の場合には「０」にリセットされる。従って、未送信のパケットの有無は、この送信済みフラグの状態を調べることにより判断可能である。
【００６８】
Ａ３．送受信制御部の動作：
送受信制御部２２３は、以下で説明するように、自分宛のパケットの受信、自分宛でないパケットの転送、および、未送信パケットの送信を制御する。
【００６９】
図４および図５は、送受信制御部で実行される送受信制御の手順について示す説明図である。
【００７０】
送受信制御部２２３は動作を開始すると、まず、送信バッファ２２５の送信レジスタ２２５Ａ〜２２５Ｃ、受信バッファ２２６の受信レジスタ２２６Ａ、および、フラグ部２２４の送信済みフラグ２２４Ａ〜２２４Ｃをクリア（初期化）する（ステップＳ１０２）。
【００７１】
そして、パケットの到着監視を開始する（ステップＳ１０４）。パケットの到着は、第１サイクルで、入力レジスタ２２１に書き込まれた状態制御ビットのうち、Ｈビットの状態を監視することにより判断することができる。例えば、第１サイクルのＨビットは、同じサイクルのパケットビットのデータがヘッダ部を表すデータであることを示す「１」となっており、第２サイクルのＨビットは「０」となっているので、Ｈビットが「１」であるか「０」であるかを判断することにより、パケットの到着を監視することができる。
【００７２】
パケットが到着した場合には（ステップＳ１０４：ＹＥＳ）、到着したパケットが空パケットであるか否か判断する（ステップＳ１０６）。空パケットは、第１サイクルで、入力レジスタ２２１に書き込まれた、状態制御ビットのうち、Ｖビットの状態を監視することにより判断することができる。例えば、Ｖビットは、同じサイクルのパケットビットのデータが空パケットを構成するデータであることを示す場合には「０」となっており、同じサイクルのパケットビットのデータが通常のパケットを構成するデータであることを示す場合には「１」となっているので、Ｖビットが「０」であるか「１」であるかを監視することにより、空パケットを監視することができる。
【００７３】
到着したパケットが空パケットでない場合には（ステップＳ１０６：ＮＯ）、後述するように、ステップＳ１３０以降の処理を実行する。
【００７４】
一方、到着したパケットが空パケットである場合には（ステップＳ１０６：ＹＥＳ）、未送信データがあるか否か判断する（ステップＳ１１０）。未送信データの有無は、送信済みフラグ部２２４の送信済みフラグ２２４Ａ〜２２４Ｃの状態を調べることにより判断可能である。例えば、送信済みフラグ２２４Ａ〜２２４Ｃは、それぞれ対応する送信レジスタ２２５Ａ〜２２５Ｃに書き込まれているデータが、送信済みの場合には「１」にセットされ、未送信の場合には「０」にクリアされているので、送信済みフラグ２２４Ａ〜２２４Ｃが「１」であるか「０」であるかを調べることにより、判断することができる。
【００７５】
未送信データが無い場合には（ステップＳ１１０：ＮＯ）、空パケットを表すデータを出力レジスタ２２２に向けて出力して、出力レジスタ２２２に書き込ませることにより、空パケットを送信させる（ステップＳ１１２）。そして、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００７６】
一方、未送信データがある場合には（ステップＳ１１０：ＹＥＳ）、送信可能データがあるか否か判断する（ステップＳ１１４）。送信可能データがあるか否かは、未送信データのあて先が、送信済みデータのあて先と同じであるか否か調べることにより、判断可能である。具体的には、送信済みデータと同じあて先の場合には。送信不可と判断し、異なるあて先の場合には送信可と判断する。
【００７７】
送信可能データが無い場合には（ステップＳ１１４：ＮＯ）、ステップＳ１１２に戻って、空パケットを他のノードへ送信させた後、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００７８】
一方、送信可能データがある場合には（ステップＳ１１４：ＹＥＳ）、未送信データのうち、送信レジスタへの書き込みの最も古いものを選び出す（ステップＳ１１６）。この選び出しは、例えば、３つの送信レジスタ２２５Ａ〜２２５Ｃへの書き込みの順番を記憶しておくことにより、容易に可能である。あるいは、ＦＩＦＯ形式のレジスタを利用することにより、容易に可能である。
【００７９】
そして、選び出した未送信データを出力レジスタ２２２に向けて出力して、出力レジスタ２２２に書き込ませることにより、そのデータの表すパケットを、ヘッダ部に記載のあて先へ送信させる（ステップＳ１１８）。
【００８０】
また、送信したデータの表すパケットが送信先から送られたリクエストパケットに対するレスポンスパケットであるか否か判断する（ステップＳ１２０）。レスポンスパケットであるか否かは、ヘッダ部の通信内容を示すフィールド（ＴＹＰ）の記載を調べることにより判断可能である。
【００８１】
送信したデータの表すパケットがレスポンスパケットである場合には（ステップＳ１２４：ＹＥＳ）、送信したデータが格納されて（書き込まれて）いた送信レジスタを開放する（ステップＳ１２４）。そして、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００８２】
一方、送信したデータの表すパケットがレスポンスパケットでない場合には（ステップＳ１２４：ＮＯ）、送信したデータの格納されていた送信レジスタに対応する送信済みフラグを「１」にセットする（ステップＳ１２６）。そして、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００８３】
ところで、到着したパケットが空パケットでない場合には（ステップＳ１０６：ＮＯ）、さらに、パケットのあて先が自分宛か否かを判断する（ステップＳ１３０）。あて先の判断は、到着したパケットを構成するヘッダ部の送信先ＩＤを示すフィールド（ＤＩＤ）の記載が、自分宛であるか否かを調べることにより可能である。
【００８４】
そして、到着したパケットが自分宛でない場合には（ステップＳ１３０：ＮＯ）、第１サイクルで入力レジスタ２２１に書き込まれたパケットビットのデータ、および、１サイクル後の第２サイクルで入力レジスタ２２１に書き込まれるパケットビットのデータを、出力レジスタ２２２に向けて出力して、出力レジスタ２２２に書き込ませることにより、入力レジスタ２２１に書き込まれたパケットを他のノードへ転送させる（ステップＳ１３２）。そして、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００８５】
一方、到着したパケットが自分宛のパケットである場合には（ステップＳ１３０：ＹＥＳ）、そのパケットがライトレスポンス（ＷＲレスポンス）パケットであるか否か判断する（ステップＳ１３４）。ライトレスポンスパケットか否かの判断は、ヘッダ部の通信内容を示すフィールド（ＴＹＰ）の記載を調べることにより可能である。
【００８６】
到着したパケットがライトレスポンスパケットである場合には（ステップＳ１３４：ＹＥＳ）、送信バッファ２２５の３つの送信レジスタ２２５Ａ〜２２５Ｃのうち、対応するライトリクエストパケットが格納されている送信レジスタを開放するとともに、送信済みフラグ部２２４の３つの送信済みフラグ２２４Ａ〜２２４Ｃのうち、その送信レジスタに対応してセットされている送信済みフラグをクリアする（ステップＳ１３６）。そして、ステップＳ１１０に戻って、ステップＳ１１０〜Ｓ１２６の処理を実行する。
【００８７】
一方、到着したパケットがライトレスポンスパケットでない場合には（ステップＳ１３４：ＮＯ）、受信バッファ２２６の受信レジスタ２２６Ａが開放されており、受信することが可能であるか否か判断する（ステップＳ１３８）。
【００８８】
受信レジスタ２２６Ａが開放されておらず、受信することが不可である場合には（ステップＳ１３８：ＮＯ）、ステップＳ１３２に戻って、入力レジスタ２２１に書き込まれたパケットを他のノードへ転送させた後、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００８９】
一方、受信レジスタ２２６Ａが開放されており、受信可能である場合には（ステップＳ１３８：ＹＥＳ）、第１サイクルで入力レジスタ２２１に書き込まれたパケットビットのデータ、および、１サイクル後の第２サイクルで入力レジスタ２２１に書き込まれるパケットビットのデータを、受信バッファ２２６に向けて出力して、受信レジスタ２２６Ａを更新させるとともに、プロセッサＩ／Ｆ制御部２２７を介して、プロセッサＩ／Ｆに対してパケット受信を通知させる（ステップＳ１４０）。
【００９０】
そして、受信したパケットがライトリクエスト（ＷＲリクエスト）パケットであるか否か判断する（ステップＳ１４２）。ライトリクエストパケットか否かの判断は、ヘッダ部の通信内容を示すフィールド（ＴＹＰ）の記載を調べることにより可能である。
【００９１】
受信したパケットがライトリクエストパケットである場合には（ステップＳ１４２：ＹＥＳ）、ライトレスポンスパケットを表すデータを出力レジスタ２２２に向けて出力して、出力レジスタ２２２に書き込ませることにより、ライトレスポンスパケットをライトリクエストパケットの送信元に向けて送信させる（ステップＳ１４４）。そして、ステップＳ１０４に戻って、次のパケットの到着を監視する。
【００９２】
一方、受信したパケットがライトリクエストパケットでない場合には（ステップＳ１４２：ＮＯ）、さらに、受信したパケットがリードレスポンス（ＲＤレスポンス）パケットであるか否か判断する（ステップＳ１４６）。リードレスポンスパケットか否かの判断は、ヘッダ部の通信内容を示すフィールド（ＴＹＰ）の記載を調べることにより可能である。
【００９３】
受信したパケットがリードレスポンスパケットである場合には（ステップＳ１４６：ＹＥＳ）、送信バッファ２２５の３つの送信レジスタ２２５Ａ〜２２５Ｃのうち、対応するリードリクエストパケットが格納されている送信レジスタを開放するとともに、送信済みフラグ部２２４の３つの送信済みフラグ２２４Ａ〜２２４Ｃのうち、その送信レジスタに対応してセットされている送信済みフラグをクリアする（ステップＳ１４８）。そして、ステップＳ１１０に戻って、ステップＳ１１０〜Ｓ１２６の処理を実行する。
【００９４】
一方、到着したパケットがリードレスポンスパケットでない場合には（ステップＳ１４６：ＮＯ）、ステップＳ１１０に戻って、ステップＳ１１０〜Ｓ１２６の処理を実行する。
【００９５】
以上のようにして、送受信制御部２２３は、自分宛のパケットの受信、自分宛でないパケットの転送、および、未送信パケットの送信を制御する。
【００９６】
Ａ４．通信動作の具体例：
以下では、通信経路１０を介して各ノード２０Ａ〜２０Ｅの間で実行される通信動作について、具体例を用いて説明する。なお、説明を容易にするため、図１に示した構成を省略して、５つのノードのうち、ノード１〜ノード３の３つのノードのみを示す構成として説明する。
【００９７】
また、「発明が解決しようとする課題」において説明した図１２および図１３と同様に、送信するリクエストパケットを、［ＲＤ−Ｒｅｑ＃１：１２］のように記述することとし、これに対して応答されるレスポンスパケットを、［ＲＤ−Ｒｓｐ＃１：２１］のように記述することとする。
【００９８】
そして、具体例１は、図６〜図９を用いて、ノード１からノード２に対して３つのリクエストパケットを送信する場合を例に説明する。また、具体例２は、図１０および図１１を用いて、ノード１からノード２に対して２つのリクエストパケットを送信し、ノード１からノード３に対して１つのリクエストパケットを送信する場合を例に説明する。
【００９９】
なお、図６〜図９には１０段階の動作状態が示されており、図１０および図１１には６段階の動作状態が示されているが、上述したように、各ノードでは、システムクロック２サイクルごとに１つのパケットが送受信されるので、各動作状態は、先頭の動作状態（状態１）から順に、２サイクルのシステムクロック単位で変化した状態であり、各ノードにパケットが到着した状態を示すこととする。
【０１００】
また、ライトリクエストパケット、リードリクエストパケット、ライトレスポンスパケット、リードレスポンスパケット等の通信内容の違いを区別する必要が無い場合には、これらを単に「リクエストパケット」あるいは「レスポンスパケット」と呼ぶ場合もある。
【０１０１】
Ａ４．１．具体例１：
図６〜図９は、各ノード間で実行される通信動作の具体例１を示す説明図である。
【０１０２】
まず、先頭の動作状態１において、ノード１の送信レジスタ２２５Ａ〜２２５Ｃには、パケット［ＲＤ−Ｒｅｑ＃１：１２］，［ＷＲ−Ｒｅｑ＃２：１２］，［ＲＤ−Ｒｅｑ＃３：１２］の３つのリクエストパケットが順に格納されている。そして、これら３つのリクエストパケットは未送信のパケットであるので、それぞれの送信レジスタ２２５Ａ〜２２５Ｃに対応する送信済みフラグ２２４Ａ〜２２４Ｃは、全てクリア状態となっている。
【０１０３】
そして、図示は省略するが、各ノードでは、次のノードに空パケットを送出し、次のノードには空パケットが到着している。なお、具体例１および具体例２の説明において、空パケットの送出および到着については、特に必要としない限り図示および説明を省略することとする。
【０１０４】
また、図中において、送信レジスタと送信済みフラグとの対応関係を、送信レジスタを示す矩形図形と、送信済みフラグを示す矩形図形との間を線で結ぶことにより示している。また、送信済みフラグのクリア状態を、矩形図形の図柄を空白とすることで示し、送信済みフラグのセット状態を、矩形図形の図柄をハッチングとすることで示している。
【０１０５】
そして、動作状態２において、ノード１では、１番目の送信レジスタ２２５Ａに格納されたリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ａがセットされる。このとき、ノード２には、ノード１から送信された１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が到着する。ノード２に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１０６】
次に、動作状態３において、ノード１では、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスがまだ返ってきていないので、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］および３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］をノード２に対して送信することができない。すなわち、送信可能なデータが存在していない。このため、図示しない空パケットがノード２に向けて送出される。なお、ノード２では、受信した１番目のリクエストパケット［ＲＤ―Ｒｅｑ＃１：１２］に対応する処理が実行中であり、処理が終了すると１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が発生し、図示しない送信レジスタに格納される。
【０１０７】
そして、動作状態４において、ノード１では、動作状態３と同様に、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスがまだ返ってきていないので、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］および３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］をノード２に対して送信することができない。このため、図示しない空パケットがノード２に向けて送出される。
【０１０８】
また、ノード２では、終了した１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が、ノード３に向けて送出される。このとき、ノード３には、ノード２から送信された１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が到着する。ノード３に到着したパケットは、自分宛のパケットではないので、ノード１に転送される。
【０１０９】
次に、動作状態５において、ノード３では、上述したように、動作状態４で到着したレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が自分宛のパケットではないので、そのままノード１に向けて送出される。このとき、ノード１には、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１１０】
ノード１では、１番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が受信されると、１番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］が格納されていた１番目の送信レジスタ２２５Ａは開放され、対応する送信済みフラグ２２４Ａもクリアされる。これにより、ノード２に対するリクエストパケットの送信が可能となる。
【０１１１】
そこで、ノード１では、２番目の送信レジスタ２２５Ｂに格納されている２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ｂがセットされる。このとき、ノード２には、ノード１から送信された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が到着する。ノード２に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。なお、２番目のリクエストパケットは、ライトリクエストであるので、受信バッファに格納されると、これに応じて、図示しない送信レジスタには、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が発生し、図示しない出力レジスタに書き込まれる。
【０１１２】
次に、動作状態６において、ノード２では、動作状態５で受信した２番目のリクエストパケット［ＷＲ―Ｒｅｑ＃２：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が、ノード３に向けて送出される。このとき、ノード３には、ノード２から送信された２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が到着する。ノード３に到着したパケットは、自分宛のパケットでないので、ノード１に転送される。
【０１１３】
ノード１では、動作状態３と同様に、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］に対するレスポンスがまだ返ってきていないので、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］をノード２に対して送信することができない。また、動作状態５で開放された送信レジスタ２２５Ａは空である。すなわち、送信可能なデータが送信レジスタに存在していない。このため、図示しない空パケットがノード２に向けて送出される。
【０１１４】
次に、動作状態７において、ノード３では、上述したように、動作状態６で到着したレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が自分宛のパケットではないので、そのままノード１に向けて送出される。このとき、ノード１には、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１１５】
ノード１では、２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が受信されると、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］が格納されていた２番目の送信レジスタ２２５Ｂは開放され、対応する送信済みフラグ２２４Ｂもクリアされる。これにより、ノード２に対するリクエストパケットの送信が可能となる。
【０１１６】
そこで、ノード１では、３番目の送信レジスタ２２５Ｃに格納されている３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ｃがセットされる。このとき、ノード２には、ノード１から送信された３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が到着する。ノード２に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１１７】
次に、動作状態８において、動作状態６と同様に、ノード１では、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］に対するレスポンスがまだ返ってきていないので、他のリクエストパケットをノード２に対して送信することができない。また、動作状態５および７で開放された送信レジスタ２２５Ａ，２２５Ｂは空である。すなわち、送信可能なデータが送信レジスタに存在していない。このため、図示しない空パケットがノード２に向けて送出される。なお、ノード２では、受信した３番目のリクエストパケット［ＲＤ―Ｒｅｑ＃３：１２］に対応する処理が実行中であり、処理が終了すると３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が発生し、図示しない送信レジスタに格納される。
【０１１８】
そして、動作状態９において、ノード１では、動作状態８と同様に、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］に対するレスポンスがまだ返ってきていないので、他のリクエストパケットをノード２に対して送信することができない。また、動作状態５および７で開放された送信レジスタ２２５Ａ，２２５Ｂは空である。このため、図示しない空パケットがノード２に向けて送出される。
【０１１９】
また、ノード２では、終了した３番目のリクエストパケット［ＲＤ―Ｒｅｑ＃３：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が、ノード３に向けて送出される。このとき、ノード３には、ノード２から送信された３番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が到着する。ノード３に到着したパケットは、自分宛のパケットではないので、ノード１に転送される。
【０１２０】
次に、動作状態１０において、ノード３では、上述したように、動作状態９で到着したレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が自分宛のパケットではないので、そのままノード１に向けて送出される。このとき、ノード１には、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］に対するレスポンスパケット［ＲＤ−Ｒｓｐ＃１：２１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１２１】
ノード１では、３番目のレスポンスパケット［ＲＤ−Ｒｓｐ＃３：２１］が受信されると、３番目のリクエストパケット［ＲＤ−Ｒｅｑ＃３：１２］が格納されていた３番目の送信レジスタ２２５Ｃは開放され、対応する送信済みフラグ２２４Ｃもクリアされる。これにより、ノード２に対するリクエストパケットの送信が可能となる。
【０１２２】
以上のようにして、ノード１からノード２に対して、送信レジスタ２２５Ａ〜２２５Ｃに格納されていた３つのリクエストパケット［ＲＤ−Ｒｅｑ＃１：１２］，［ＷＲ−Ｒｅｑ＃２：１２］，［ＲＤ−Ｒｅｑ＃３：１２］が順番に送信され、ノード２においては、送信されたリクエストパケットの順番通りに受信されて、対応するそれぞれの処理が順番通りに実行される。
【０１２３】
Ａ４．２．具体例２：
図１０および図１１は、各ノード間で実行される通信動作の具体例２を示す説明図である。
【０１２４】
まず、先頭の動作状態１において、ノード１の送信レジスタ２２５Ａ〜２２５Ｃには、パケット［ＷＲ−Ｒｅｑ＃１：１２］，［ＷＲ−Ｒｅｑ＃２：１３］，［ＷＲ−Ｒｅｑ＃３：１２］の３つのリクエストパケットが順に格納されている。そして、これら３つのリクエストパケットは未送信のパケットであるので、それぞれの送信レジスタ２２５Ａ〜２２５Ｃに対応する送信済みフラグ２２４Ａ〜２２４Ｃは、全てクリア状態となっている。
【０１２５】
そして、動作状態２において、ノード１では、１番目の送信レジスタ２２５Ａに格納されたリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ａがセットされる。このとき、ノード２には、ノード１から送信された１番目のリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］が到着する。ノード２に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。なお、１番目のリクエストパケットは、ライトリクエストであるので、受信バッファに格納されると、これに応じて、図示しない送信レジスタには、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：２１］が発生し、図示しない出力レジスタに書き込まれる。
【０１２６】
次に、動作状態３において、ノード２では、動作状態２で受信した１番目のリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃１：２１］が、ノード３に向けて送出される。このとき、ノード３には、ノード２から送信された１番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃１：２１］が到着する。ノード３に到着したパケットは、自分宛のパケットではないので、ノード１に転送される。
【０１２７】
ここで、２番目の送信レジスタ２２５Ｂに格納されている２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］のあて先はノード３であり、対応する送信済みフラグ２２４Ａが既にセットされている１番目のリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］の送信先であるノード２とは異なっている。従って、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］は送信可能とされる。
【０１２８】
そこで、ノード１では、２番目の送信レジスタ２２５Ｂに格納されたリクエストパケット［ＷＲ−Ｒｅｑ＃２：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ｂがセットされる。このとき、ノード２には、ノード１から送信された２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］が到着する。ノード２に到着したパケットは、自分宛のパケットではないので、ノード３に転送される。
【０１２９】
そして、動作状態４において、ノード２では、上述したように、動作状態３で到着した２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］が自分宛のパケットではないので、そのままノード３に向けて送出される。このとき、ノード３には、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］が到着する。ノード３に到着したパケットは、自分宛のパケットであるので受信して、図示しない受信バッファに格納される。そして、対応する処理が実行される。なお、２番目のリクエストパケットも、ライトリクエストであるので、受信バッファに格納されると、これに応じて、図示しない送信レジスタには、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：３１］が発生し、図示しない出力レジスタに書き込まれる。
【０１３０】
また、ノード３では、上述したように、動作状態３で到着したレスポンスパケット［ＷＲ−Ｒｓｐ＃１：２１］が自分宛のパケットではないので、そのままノード１に向けて送出される。このとき、ノード１には、１番目のリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃１：２１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信され、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１３１】
ノード１では、１番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃１：２１］が受信されると、１番目のリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］の格納されていた１番目の送信レジスタ２２５Ａが開放され、対応する送信済みフラグ２２４Ａもクリアされる。これにより、ノード２に対するリクエストパケットの送信が可能となる。
【０１３２】
そこで、ノード１では、３番目の送信レジスタ２２５Ｃに格納されている３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］がノード２に向けて送出され、対応する送信済みフラグ２２４Ｃがセットされる。このとき、ノード２には、ノード１から送信された３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］が到着する。ノード２に到着したパケットは自分宛のパケットであるので、図示しない受信バッファに格納される。そして、対応する処理が実行される。なお、３番目のリクエストパケットも、ライトリクエストであるので、受信バッファに格納されると、これに応じて、図示しない送信レジスタには、３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が発生し、図示しない出力レジスタに書き込まれる。
【０１３３】
次に、動作状態５において、ノード２では、動作状態４で受信した３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が、ノード３に向けて送出される。このとき、ノード３には、ノード２から送信された３番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が到着する。ノード３に到着したパケットは、自分宛のパケットではないので、ノード１に転送される。
【０１３４】
また、ノード３では、動作状態４で受信した２番のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃２：３１］が、ノード１に向けて送出される。このとき、ノード１には、ノード３から送信された２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：３１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１３５】
ノード１では、２番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃２：３１］が受信されると、２番目のリクエストパケット［ＷＲ−Ｒｅｑ＃２：１３］が格納されていた２番目の送信レジスタ２２５Ｂは開放され、対応する送信済みフラグ２２４Ｂもクリアされる。これにより、ノード３に対するリクエストパケットの送信が可能となる。
【０１３６】
そして、動作状態６において、ノード３では、動作状態５で到着したレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が自分宛のパケットではないので、そのままノード１に向けて送出される。このとき、ノード１には、３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］に対するレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が到着する。ノード１に到着したパケットは、自分宛のパケットであるので受信されて、図示しない受信バッファに格納される。そして、対応する処理が実行される。
【０１３７】
ノード１では、３番目のレスポンスパケット［ＷＲ−Ｒｓｐ＃３：２１］が受信されると、３番目のリクエストパケット［ＷＲ−Ｒｅｑ＃３：１２］の格納されていた３番目の送信レジスタ２２５Ｃが開放され、対応する送信済みフラグ２２４Ｃもクリアされる。これにより、ノード２に対するリクエストパケットの送信が可能となる。
【０１３８】
以上のようにして、ノード１からノード２およびノード１からノード３に対して、送信レジスタに格納されていた３つのリクエストパケット［ＷＲ−Ｒｅｑ＃１：１２］，［ＷＲ−Ｒｅｑ＃２：１３］，［ＷＲ−Ｒｅｑ＃３：１２］が順番に送信され、送信されたリクエストパケットの順番通りに、それぞれのノードで受信されて、対応するそれぞれの処理が順番通りに実行される。
【０１３９】
Ａ５．実施例の効果：
具体例１で説明したように、本実施例では、ある送信元のノードからある送信先のノードに対して複数のリクエストパケットを順番に送信した場合に、その送信先のノードにおいて、送信元のノードから送信された順番通りに、リクエストパケットを受信して、対応する処理を実行させることができる。
【０１４０】
また、具体例２で説明したように、本実施例では、あるノードから複数の異なったノードに対してリクエストパケットが順番に送信された場合にも、送信先のノードに関係なく送信した順番通りに対応する処理を実行させることが可能である。
【０１４１】
なお、１つのノードから送信される複数のリクエストパケットに対して、１つの送信済みフラグを設けることによっても、実施例と同様に、複数の異なったノードに対してリクエストパケットを順番に送信し、送信先のノードに関係なく送信した順番通りに対応する処理を実行させることは可能である。
【０１４２】
しかしながら、この場合には、いずれかのノードに対して１つのリクエストパケットを送信すると、これに対するレスポンスが返ってくるまで、送信済みフラグがセットされることになるので、他のノードに対してもリクエストパケットを送信することができないことになる。このため、この場合には、本実施例の場合に比べて、複数のリクエストパケットに対する処理の実行効率が悪くなる。
【０１４３】
言い換えれば、本実施例は、複数のリクエストパケットに対する処理を高速に実行することができる。
【０１４４】
なお、上記具体例の説明では、説明を容易にするため、図１に示した構成を省略して、５つのノードのうち、ノード１〜ノード３の３つのノードのみを示す構成として説明したが、図１に示した５つのノードにおいて同様である。
【０１４５】
Ｂ．変形例：
以上、本発明の実施の形態について説明したが、本発明はこのような実施の形態になんら限定されるものではなく、その要旨を逸脱しない範囲において種々の態様にて実施することが可能である。例えば、以下のような変形が可能である。
【０１４６】
Ｂ１．変形例１：
上記実施例のマルチプロセッサシステムでは、５つのノードを備える場合を例に示しているが、これに限定されるものではなく、複数のノードを備える場合に本発明を適用することが可能である。
【０１４７】
Ｂ２．変形例２：
上記実施例のマルチプロセッサシステムでは、５つのノードに対して、各送信バッファ２２５に備える送信レジスタの数を３とするとともに、これに対応して送信済みフラグ部２２４に備える送信済みフラグの数を３とした場合を例に示している。しかしながら、これに限定されるものではなく、送信レジスタの数および送信済みフラグの数は、２以上で、かつ、通信経路に接続される全ノード数から自分を引いた数以下であればよい。
【０１４８】
接続されている全ノード数から自分を引いた数の送信レジスタおよび送信済みフラグの数を備えるようにすれば、あるノードから別のあるノードに対して、別のあるノード以外の他のノードに対してリクエストが送信済みであるか否かに関係なく、リクエストを送信することができる。ただし、全ノードに対して連続してリクエストが送信されるような状況が発生する可能性を考えると、ノード数と処理の実行する処理の内容にもよるが、その可能性は非常に小さいと考えられる。従って、全ノード数から自分を引いた数の送信レジスタおよび送信済みフラグを備える構成とする必要性は低く、全ノード数から自分を引いた数よりも小さい数とするほうが、システムを構成する上で効率的である。
【０１４９】
Ｂ３．変形例３：
上記実施例では、あるノードに対して送信したリクエストパケットに対するレスポンスパケットが返ってくるまで、送信したリクエストパケットを送信レジスタに格納しておくとともに、あるノードに対してリクエストパケットを送信したことを示す送信済みフラグをセットしておく場合を例に示したが、これに限定されるものではない。送信済みフラグは、送信レジスタに格納されているデータのうち、送信先ＩＤの示すノードに対して、リクエストパケットが送信済みであることを示しているものである。従って、少なくとも、送信先のノードを示す情報、実施例では送信先ＩＤ、を記憶しておき、その送信先のノードからのレスポンスパケットを受信するまで、そのノードへのリクエストパケットの送信を禁止する構成とすることも可能である。
【図面の簡単な説明】
【０１５０】
【図１】本発明のマルチプロセッサシステムの一実施例としての概要構成を示す説明図である。
【図２】各ノード間で送受信されるパケットのデータ構造について示す説明図である。
【図３】ノードに備えられる通信制御部の一構成例を示す説明図である。
【図４】送受信制御部で実行される送受信制御の手順について示す説明図である。
【図５】送受信制御部で実行される送受信制御の手順について示す説明図である。
【図６】各ノード間で実行される通信動作の具体例１を示す説明図である。
【図７】各ノード間で実行される通信動作の具体例１を示す説明図である。
【図８】各ノード間で実行される通信動作の具体例１を示す説明図である。
【図９】各ノード間で実行される通信動作の具体例１を示す説明図である。
【図１０】各ノード間で実行される通信動作の具体例２を示す説明図である。
【図１１】各ノード間で実行される通信動作の具体例２を示す説明図である。
【図１２】ループバスを用いた場合におけるノード間のデータ通信の問題点について示す説明図である。
【図１３】ループバスを用いた場合におけるノード間のデータ通信の問題点について示す説明図である。
【符号の説明】
【０１５１】
１０...通信経路
２０Ａ...プロセッサ（ノード）
２０Ｂ...プロセッサ（ノード）
２０Ｃ...プロセッサ（ノード）
２０Ｄ...メモリコントローラ（ノード）
２０Ｄ...Ｉ／Ｏインタフェース（ノード）
２２Ａ〜２２Ｅ...通信制御部
２２１...入力レジスタ
２２２...出力レジスタ
２２３...送受信制御部
２２４...送信済みフラグ部
２２４Ａ〜２２４Ｃ...送信済みフラグ
２２５...送信バッファ
２２５Ａ〜２２５Ｃ...送信レジスタ
２２６...受信データバッファ
２２６Ａ...受信レジスタ
２２７...プロセッサＩ／Ｆ制御部
ＳＣＫ...システムクロック
ＭＰＳ...マルチプロセッサシステム
【図１】
2007148753.tif 000003
【図２】
2007148753.tif 000004
【図３】
2007148753.tif 000005
【図４】
2007148753.tif 000006
【図５】
2007148753.tif 000007
【図６】
2007148753.tif 000008
【図７】
2007148753.tif 000009
【図８】
2007148753.tif 000010
【図９】
2007148753.tif 000011
【図１０】
2007148753.tif 000012
【図１１】
2007148753.tif 000013
【図１２】
2007148753.tif 000014
【図１３】
2007148753.tif 000015