(57)【要約】【課題】ブロック間バスを介したデータ処理ブロック間の通信性能を向上させる。【解決手段】ブロック間のバスを介してデータ処理ブロックが接続されたデータ処理システムにて、第１のデータ処理ブロックが第２のデータ処理ブロックのメモリへデータの書き込みを行う場合、第１のデータ処理ブロックが、記憶している第２のデータ処理ブロックのメモリの領域割り当て情報を参照してデータ格納領域を確保し、ブロック間のバスを介して、第２のデータ処理ブロックのメモリにデータを書き込み、データを書き込んだデータ格納領域のアドレス及びデータの受信要求を第２のデータ処理ブロックに送信し、第２のデータ処理ブロックが、受信したデータ格納領域のアドレスを基にメモリからデータを読み出すようにして、ブロック間バスを介した読み込みを行うことなく、ブロック間バスを介したデータの書き込みを行えるようにする。【選択図】図１
2017174006.tif 000002
【特許請求の範囲】
【請求項１】
第１のデータ処理ブロックと、前記第１のデータ処理ブロックから送信されるデータが書き込まれるメモリを有する第２のデータ処理ブロックとがブロック間のバスを介して接続されたデータ処理システムにて、
前記第１のデータ処理ブロックは、
前記第２のデータ処理ブロックが有する前記メモリの領域割り当て情報を記憶する記憶手段と、
前記メモリへのデータの書き込みを行う場合、前記記憶手段に記憶された前記領域割り当て情報を参照して、前記メモリに対するデータ格納領域の確保及び解放を行う管理手段と、
前記ブロック間のバスを介して、前記管理手段によって確保した前記メモリの前記データ格納領域にデータを書き込み、該データ格納領域を示す情報及び該データの受信要求を前記第２のデータ処理ブロックに送信する送信手段とを有し、
前記第２のデータ処理ブロックは、
前記第１のデータ処理ブロックから前記受信要求を受けた場合、前記データ格納領域を示す情報に基づいて前記メモリの前記データ格納領域からデータを読み出す受信手段とを有することを特徴とするデータ処理システム。
【請求項２】
前記第２のデータ処理ブロックの前記受信手段は、前記メモリの前記データ格納領域からデータを読み出した後に該データの受信完了を前記第１のデータ処理ブロックに通知し、
前記第１のデータ処理ブロックの前記管理手段は、前記第２のデータ処理ブロックから前記受信完了の通知を受けた場合、前記記憶手段に記憶された前記領域割り当て情報を更新し前記データ格納領域を解放することを特徴とする請求項１記載のデータ処理システム。
【請求項３】
前記第１のデータ処理ブロックの前記送信手段は、
前記管理手段によって確保した前記メモリの前記データ格納領域にデータの書き込みを行う第１の送信手段と、
前記第１の送信手段による前記データ格納領域へのデータの書き込みが行われた後に、該データ格納領域を示す情報及び該データの受信要求を前記第２のデータ処理ブロックに送信する第２の送信手段とを有することを特徴とする請求項１又は２記載のデータ処理システム。
【請求項４】
前記第１のデータ処理ブロックの前記記憶手段は、前記ブロック間のバスを介して接続されている複数の前記第２のデータ処理ブロックがそれぞれ有する前記メモリの領域割り当て情報を記憶しており、
前記第１のデータ処理ブロックの前記管理手段は、前記メモリへのデータの書き込みを行う前記第２のデータ処理ブロックの前記メモリの前記領域割り当て情報を参照して、該第２のデータ処理ブロックの前記メモリから前記データ格納領域を確保することを特徴とする請求項１〜３の何れか１項に記載のデータ処理システム。
【請求項５】
前記メモリの領域割り当て情報は、該メモリを所定の大きさの領域に分割した領域単位でデータが書き込み可能であるか否かを示すことを特徴とする請求項１〜４の何れか１項に記載のデータ処理システム。
【請求項６】
前記第１のデータ処理ブロックが、前記受信手段をさらに有し、
前記第２のデータ処理ブロックが、前記記憶手段、前記管理手段、及び送信手段をさらに有することを特徴とする請求項１〜５の何れか１項に記載のデータ処理システム。
【請求項７】
前記ブロック間のバスは、前記ブロック間のバスを介したデータの書き込み速度に対して、前記ブロック間のバスを介したデータの読み込み速度が遅いバスであることを特徴とする請求項１〜６の何れか１項に記載のデータ処理システム。
【請求項８】
ブロック間のバスを介して接続された他のデータ処理装置が有するメモリの領域割り当て情報を記憶する記憶手段と、
前記メモリへのデータの書き込みを行う場合、前記記憶手段に記憶された前記領域割り当て情報を参照して、前記メモリに対するデータ格納領域の確保及び解放を行う管理手段と、
前記ブロック間のバスを介して、前記管理手段によって確保した前記メモリの前記データ格納領域にデータを書き込み、該データ格納領域を示す情報及び該データの受信要求を前記他のデータ処理装置に送信する送信手段とを有することを特徴とするデータ処理装置。
【請求項９】
ブロック間のバスを介して接続された他のデータ処理装置からのデータが書き込まれるメモリと、
前記ブロック間のバスを介して、前記データが書き込まれた前記メモリのデータ格納領域を示す情報及び該データの受信要求を前記他のデータ処理装置から受けた場合、前記データ格納領域を示す情報に基づいて前記メモリの前記データ格納領域からデータを読み出す受信手段とを有することを特徴とするデータ処理装置。
【請求項１０】
第１のデータ処理ブロックと、前記第１のデータ処理ブロックから送信されるデータが書き込まれるメモリを有する第２のデータ処理ブロックとがブロック間のバスを介して接続されたデータ処理システムのデータ処理方法であって、
前記第１のデータ処理ブロックが、前記第２のデータ処理ブロックが有する前記メモリへのデータの書き込みを行う場合、前記第１のデータ処理ブロックに記憶している前記メモリの領域割り当て情報を参照して、前記第１のデータ処理ブロックが前記メモリに対するデータ格納領域を確保し、
前記第１のデータ処理ブロックが前記第２のデータ処理ブロックに対して、前記ブロック間のバスを介して、確保した前記メモリの前記データ格納領域にデータの書き込みを行い、該データ格納領域を示す情報及び該データの受信要求を送信し、
前記第２のデータ処理ブロックが、前記第１のデータ処理ブロックからの前記受信要求を受けて、前記データ格納領域を示す情報に基づいて前記メモリの前記データ格納領域からデータを読み出すことを特徴とするデータ処理方法。
【請求項１１】
コンピュータを請求項１〜７の何れか１項に記載のデータ処理システムの各手段として動作させるためのプログラム。
【請求項１２】
コンピュータを請求項８又は９記載のデータ処理装置の各手段として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システム、データ処理装置、及びデータ処理方法に関する。
【背景技術】
【０００２】
データ処理を高速に行う手法は、ハードディスクやＣＰＵ（Central Processing Unit）間通信装置等を対象として様々な手法が提案されている。例えば、ハードディスク等の記憶装置内に記憶したファイルを用いたデータ処理を高速に行うための従来技術として、特許文献１に記載された技術が提案されている。特許文献１には、速度の異なる２つの記憶装置を設け、アクセス頻度の高いファイル管理情報を高速な記憶装置に記憶することでデータ処理の速度を向上させる技術が述べられている。また、ＣＰＵ間通信等のチップ間通信では、チップ間バスを介して相手先のチップドメインにあるメモリへデータを直接書き込むことで、データ処理のオーバーヘッドを軽減させる手法が一般的である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平９−２８２１０３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では、アクセス頻度の高いファイル管理情報を高速な記憶装置に格納することでデータ処理能力を向上させようとしているが、その記憶装置の読み取り速度が書き込み速度に比較して遅い場合には相対的な処理能力が低下してしまう。また、チップ間通信に用いられる一般的な手法では、相手先のチップドメインにあるメモリからデータ領域を確保する際、データ領域の管理テーブル情報などアクセス頻度が高いデータをチップ間インターフェース経由で読み込まなければならなかった。ＰＣＩ（Peripheral Component Interconnect）インターフェース等の一般的なチップ間インターフェースは、読み込み速度が書き込み速度よりも遅いことが知られている。以上のことから前述の従来技術では、アクセス頻度の高いデータの読み込み速度がボトルネックになり、データ処理能力が低下してしまう。本発明は、このような事情に鑑みてなされたものであり、ブロック間インターフェースを介したデータ処理ブロック間の通信性能を向上させることを目的とする。
【課題を解決するための手段】
【０００５】
本発明に係るデータ処理システムは、第１のデータ処理ブロックと、前記第１のデータ処理ブロックから送信されるデータが書き込まれるメモリを有する第２のデータ処理ブロックとがブロック間のバスを介して接続されたデータ処理システムにて、前記第１のデータ処理ブロックは、前記第２のデータ処理ブロックが有する前記メモリの領域割り当て情報を記憶する記憶手段と、前記メモリへのデータの書き込みを行う場合、前記記憶手段に記憶された前記領域割り当て情報を参照して、前記メモリに対するデータ格納領域の確保及び解放を行う管理手段と、前記ブロック間のバスを介して、前記管理手段によって確保した前記メモリの前記データ格納領域にデータを書き込み、該データ格納領域を示す情報及び該データの受信要求を前記第２のデータ処理ブロックに送信する送信手段とを有し、前記第２のデータ処理ブロックは、前記第１のデータ処理ブロックから前記受信要求を受けた場合、前記データ格納領域を示す情報に基づいて前記メモリの前記データ格納領域からデータを読み出す受信手段とを有することを特徴とする。
【発明の効果】
【０００６】
本発明によれば、ブロック間バスを介した読み込みを行うことなく、ブロック間バスを介したデータの書き込みが行えるので、ブロック間バスを介したデータ処理ブロック間の通信性能を向上させることができる。
【図面の簡単な説明】
【０００７】
【図１】第１の実施形態におけるデータ処理システムの構成例を示す図である。
【図２】第１の実施形態の動作を表すフローチャートである。
【図３】領域管理テーブルによる領域管理方法を説明するための図である。
【図４】図２のステップＳ２０３における領域取得処理の例を示すフローチャートである。
【図５】更新処理後の領域管理テーブル及びメモリプールの例を示す図である。
【図６】図２のステップＳ２０３における領域解放処理の例を示すフローチャートである。
【図７】更新処理後の領域管理テーブル及びメモリプールの例を示す図である。
【図８】第２の実施形態におけるデータ処理システムの構成例を示す図である。
【図９】第２の実施形態におけるデータ処理システムの動作例を示すフローチャートである。
【図１０】第３の実施形態におけるデータ処理システムの構成例を示す図である。
【図１１】第３の実施形態におけるデータ処理システムの動作例を示すフローチャートである。
【図１２】第４の実施形態におけるデータ処理システムの構成例を示す図である。
【図１３】第４の実施形態における送信制御部の構成例を示す図である。
【図１４】第４の実施形態における受信制御部の構成例を示す図である。
【図１５】第４の実施形態におけるデータ処理システムの動作例を示すフローチャートである。
【図１６】図１５のステップＳ１５０２における領域取得処理の例を示すフローチャートである。
【図１７】送信パケット領域及び返信パケット領域の例を示す図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態を図面に基づいて説明する。
【０００９】
（第１の実施形態）
本発明の第１の実施形態について説明する。図１は、第１の実施形態におけるデータ処理システムの構成例を示すブロック図である。第１の実施形態におけるデータ処理システムは、第１のデータ処理ブロック１０５、第２のデータ処理ブロック１０９、及びブロック間バス１１０を有する。第１のデータ処理ブロック１０５と第２のデータ処理ブロック１０９とは、ブロック間バス１１０を介して接続されている。
【００１０】
ここで、データ処理ブロックとは、例えばＣＰＵ（Central Processing Unit）とメモリ等の周辺デバイスから構成された１つのドメインを表す。また、ブロック間バスとは、例えばＰＣＩ（Peripheral Component Interconnect）やＰＣＩ  Ｅｘｐｒｅｓｓに代表されるチップ間バスや、オンチップバスとして用いられる汎用バスを表す。ブロック間バスは、例えばブロック間のバスを介したデータの書き込み速度に比較してブロック間のバスを介したデータの読み込み速度が遅いバスである。図１に示したデータ処理システムの構成は、例えば異なるチップに配置されたデータ処理ブロックがチップ間バスを介して接続された形態を含む。また、図１に示したデータ処理システムの構成は、例えば１つのチップ内に配置された複数のデータ処理ブロックがオンチップバスを介して接続された形態を含む。
【００１１】
第１のデータ処理ブロック１０５は、送信起動部１０１、送信部１０２、ブロック間通信のメモリ管理部１０３、及びブロック間通信の領域管理テーブル１０４を有する。第２のデータ処理ブロック１０９は、受信通知部１０７、受信部１０６、及びブロック間通信用のメモリプール１０８を有する。図１に示した第１の実施形態におけるデータ処理システムの動作について図２を参照して説明する。図２は、第１の実施形態におけるデータ処理システムの動作例を示すフローチャートである。
【００１２】
まず、ステップＳ２０１にて、送信起動部１０１が送信部１０２へ送信開始指示を出す。このとき、送信起動部１０１は、送信データ格納領域サイズ及び送信データの情報をあわせて送信部１０２に渡す。送信開始指示を受け取った送信部１０２は、ステップＳ２０２にて、送信領域確保要求をメモリ管理部１０３へ送る。このとき、ステップＳ２０１において受け取った送信データ格納領域サイズもあわせてメモリ管理部１０３に渡す。
【００１３】
ステップＳ２０３にて、メモリ管理部１０３が領域管理テーブル１０４を解析して、必要なサイズの送信データ格納領域をメモリプール１０８上に確保する。ステップＳ２０３における処理について、図３〜図５を用いて詳細に説明する。図３は、領域管理テーブルによる領域管理方法を説明するための図である。図３（Ａ）には、初期化直後状態における領域管理テーブル１０４及びメモリプール１０８の一例を示しており、図３（Ｂ）には、動作中状態における領域管理テーブル１０４及びメモリプール１０８の一例を示している。領域管理テーブルは、メモリプールに係る領域割り当て情報であり、例えばメモリプールを所定の大きさの領域に分割した領域単位でデータが書き込み可能であるか否かを示す情報を含んでいる。
【００１４】
ここで、メモリプール１０８のサイズはＱバイトであり、メモリプール１０８での領域取得最小単位はＮバイトであるとする。したがって、取得される領域サイズはＮバイトの倍数となる。また、簡単のためにＱはＮの倍数であるとする。領域管理テーブル１０４の実装は様々な形態が考えられるが、ここではＴａｂｌｅ［Ｑ／Ｎ］［３］で表される２次元配列であるものとする。Ｔａｂｌｅ［Ｉｄｘ］［...］は、メモリプール１０８のアドレス（Ｎ×Ｉｄｘ）を先頭とする領域の状態を表しており、その意味は下記の通りである。
Table[Idx][1, 2, 3]＝[前の空領域Idx、次の空領域Idx、Idx領域の空きサイズ]
【００１５】
例えば、図３（Ｂ）に示した領域管理テーブル１０４の要素３０５〜３０７の値を持つＩｄｘ＝ｎの状態は、次のようになる。「アドレス（ｎ×Ｎ）を先頭とするＳｉｚｅ＿ｎバイトの連続領域が空いており、この空き領域の前の空き領域はＩｄｘ＝ｐであり、この空き領域の後ろの空き領域はＩｄｘ＝ｍである」ということになる。なお、Previous-Idxの値が“−１”であるとき、自身が空き領域リストの先頭であることを表し、Next-Idxの値が“−１”であるとき、自身が空き領域リストの最後尾であることを表すものとする。また、空き領域リスト先頭インデックス３０１の値が“−１”であるとき、空き領域が全く存在しないことを意味する。
【００１６】
次に、図３（Ｂ）に示した動作中状態にあるときにＥバイトの領域の取得要求があった場合の動作を、図４に示すフローチャートを参照して説明する。図４は、図２のステップＳ２０３におけるメモリ領域取得処理の例を示すフローチャートである。なお、特に断らない限り図４の処理はメモリ管理部１０３が行う。
【００１７】
まず、ステップＳ４０１にて、メモリ管理部１０３は、送信部１０２から送信領域確保要求とともに渡された送信データ格納領域サイズにより指定されたＥを下回らない最小のＮの倍数Ｒを求める。次に、ステップＳ４０２にて、メモリ管理部１０３は、領域管理テーブル１０４の空き領域リスト先頭インデックス３０１を参照して空き領域の先頭のインデックスを求める。次に、ステップＳ４０３にて、メモリ管理部１０３は、先頭インデックスが“−１”であるか否かを判断し、“−１”である場合にはメモリプール１０８に空き領域が皆無であるので直ちにステップＳ４０８へ進みエラー終了する。
【００１８】
ステップＳ４０３での判断の結果、先頭インデックスが“−１”でない場合には、メモリ管理部１０３は、ステップＳ４０４にて先頭インデックスが示す情報を参照して空き領域のサイズを求める。図４（Ｂ）に示した例では、先頭インデックスが“２”であるので、メモリ管理部１０３は、領域管理テーブル１０４のＴａｂｌｅ［ｐ］［２］を参照して空き領域のサイズを求める。
【００１９】
次に、ステップＳ４０５にて、メモリ管理部１０３は、ステップＳ４０４において求めた空き領域のサイズが、ステップＳ４０１において求めたＲ以上であるか否かを判別する。ステップＳ４０４において求めた空き領域のサイズがＲよりも小さい場合、メモリ管理部１０３は、ステップＳ４０６にてＴａｂｌｅ［ｐ］［１］を参照して次の空き領域のインデックスを求める。ここで、求めた次の空き領域のインデックスの値が“−１”であれば、メモリ管理部１０３は、ステップＳ４０７にて条件を満たす領域が存在しなかったと判断して、ステップＳ４０８へ進みエラー終了する。一方、ステップＳ４０６において求めた次の空き領域のインデックスの値が“−１”でなければ、メモリ管理部１０３は、ステップＳ４０４へ戻り再びループ処理を繰り返す。
【００２０】
メモリ管理部１０３は、ステップＳ４０５での判断の結果、求めた空き領域のサイズがＲ以上である場合にはステップＳ４０９へ進み、ステップＳ４０９〜Ｓ４１１にて領域管理テーブル１０４の更新処理を行う。このときのインデックスがｉであったとすると、Ｐｉ＝Ｔａｂｌｅ［ｉ］［０］であり、Ｎｉ＝Ｔａｂｌｅ［ｉ］［１］であり、Ｓｉ＝Ｔａｂｌｅ［ｉ］［２］である。更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態は、例えば図５に示すようになる。
【００２１】
図５（Ａ）は、求めた空き領域のサイズがＲである場合に行われるステップＳ４１０での更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態を示している。また、図５（Ｂ）は、求めた空き領域のサイズがＲとは異なる（Ｒより大きい）場合に行われるステップＳ４１１での更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態を示している。なお、ステップＳ４１０及びＳ４１１の処理では、Ｐｉ又はＮｉが“−１”であるときには、対応するリストの更新処理を省くものとする。例えばＰｉ＝−１であるとき、Ｔａｂｌｅ［Ｐｉ］［...］の代入処理を行わない。
【００２２】
図４に戻り、ステップＳ４０９〜Ｓ４１１の処理が終了すると、ステップＳ４１２にて、メモリ管理部１０３は、インデックスｉが空き領域リストの先頭であるか否かを判断する。ここで先頭であると判断したら、ステップＳ４１３にて、メモリ管理部１０３は、領域管理テーブル１０４の空き領域リスト先頭インデックス３０１を更新する。最後に、ステップＳ４１４にて、メモリ管理部１０３は、空き領域のインデックスをメモリプールのアドレスに変換して返す。なお、ｏｆｆｓｅｔは、ブロック間バス１１０のインターフェース規格によって定まるＩＯ空間の値である。例えばＣＰＵのアドレス空間内のＰＣＩウインドウにマッピングされたアドレス等がそれに相当する。以上で図２に示したステップＳ２０３の処理の詳細説明を終わる。
【００２３】
図２に戻り、ステップＳ２０４以降の処理について説明する。ステップＳ２０４にて、送信部１０２が、ステップＳ２０３において取得したメモリプール１０８上の送信データ格納領域に送信データを書き込む。書き込む送信データは、ステップＳ２０１において送信起動部１０１が送信部１０２へ渡したものである。また、送信データの書き込みは、ブロック間バス１１０を経由して行う。
【００２４】
次に、ステップＳ２０５にて、送信部１０２が、送信データ格納領域のアドレスと受信要求通知とを受信通知部１０７へ通知する。送信データ格納領域のアドレス及び受信要求通知の通知はブロック間バス１１０を経由して行う。ステップＳ２０６にて、受信通知部１０７が、受信した送信部１０２からの受信要求とデータ格納領域のアドレスとを受信部１０６へ通知する。通知されるデータ格納領域アドレスは、受信部１０６が解釈可能なアドレス空間での値に変換されたものであり、送信部１０２は自分のアドレス空間と相手のアドレス空間のオフセットを管理しており、これらの変換機能を有する。
【００２５】
次に、ステップＳ２０７にて、受信部１０６が、データ格納領域のアドレスを参照して、メモリプール１０８からデータを読み込む。ここで、受信通知部１０７の構造としては様々な形態が考えられる。例えばスクラッチパッドと割り込み指示ビットからなる通信レジスタで構成することが可能である。この場合、送信部１０２は、ブロック間バス１１０にマッピングされた受信通知部１０７のスクラッチパッドへ送信データ格納領域のアドレスを書き込み、さらに割り込み指示ビットを立てる。これにより、受信部１０６が受信要求とデータ格納領域のアドレスとを受け取ることが可能となる。
【００２６】
なお、受信部１０６は、送信データを読み込んだことを送信側（本例ではデータ処理ブロック１０５）へ通知することが可能である。この方式は特に限定しないが、例えば送信側のメモリの決められた領域に送信データ格納領域のアドレスと受信完了フラグを立てることで読み出し完了を通知することができる。また、例えば送信側の特定のレジスタへ結果を書き込むことでも同様の通知を行うことが可能である。
【００２７】
次に、ステップＳ２０８にて、送信起動部１０１が、送信部１０２に対して送信終了を指示する。送信起動部１０１が送信部１０２に対して送信終了指示を行うタイミングを決定する方法には様々なものが考えうるが、ここでは特に限定しない。ステップＳ２０９にて、送信部１０２が、送信データ格納領域の先頭アドレスとサイズとをメモリ管理部１０３へ送り、その送信データ格納領域の解放を指示する。
【００２８】
ここで、送信部１０２は、送信データが受信部１０６によって確実に読み込まれたかどうかを調べることが可能である。方式は特に限定しないが、ステップＳ２０７の説明で述べた例に倣えば、メモリ上の受信完了フラグを調べる方法や、特定のレジスタを確認する方法等がある。送信部１０２は、例えば受信が完了するまで送信データ格納領域の解放要求を出さない選択も可能である。こうすることで、読み込み前のデータを破壊してしまうことを防止することができる。
【００２９】
ステップＳ２１０にて、メモリ管理部１０３が、領域管理テーブル１０４を操作して、メモリプール１０８上にとられた送信データ格納領域を解放する。以下、ステップＳ２１０における処理について、図３を参考にしながら、主に図６のフローチャートを用いて詳細に説明する。図６は、図２のステップＳ２１０におけるメモリ領域解放処理の例を示すフローチャートである。なお、特に断らない限り図６の処理はメモリ管理部１０３が行う。
【００３０】
まず、ステップＳ６０１にて、メモリ管理部１０３は、解放対象となる領域のアドレスＡとそのサイズＳを受け取る。これらの値は、ステップＳ２０９において送信部１０２がメモリ管理部１０３へ渡したものである。次に、ステップＳ６０２にて、メモリ管理部１０３は、解放対象となる領域のアドレスＡを領域管理テーブル１０４における空き領域リストのインデックスに変換する。ｏｆｆｓｅｔはステップＳ４１４において変換に用いたものと同じである。また、領域管理テーブル１０４の空き領域管理手法については図３を用いて前述した通りである。
【００３１】
次に、ステップＳ６０３にて、メモリ管理部１０３は、ステップＳ６０２において求めたインデックスｉを挟むＰｉ及びＮｉ（Ｐｉ＜ｉ＜Ｎｉ）を求める。この処理は、領域管理テーブル１０４をリスト探索することで行う。次に、ステップＳ６０４にて、メモリ管理部１０３は、対象となるインデックスｉが空き領域リストの終端であるか否かを判断する。ここで、Ｎｉが“−１”であることが空き領域リストの終端であることを表す。
【００３２】
ステップＳ６０４での判断の結果、Ｎｉが“−１”である場合にはステップＳ６０７に分岐し、Ｎｉが“−１”でない場合にはステップＳ６０５に進む。ステップＳ６０５にて、メモリ管理部１０３は、解放対象の領域が次の空き領域と接続されるべきかどうかを判断する。メモリ管理部１０３は、接続されるべきと判断した場合にはステップＳ６０６にて領域管理テーブル１０４の更新処理を行い、接続されるものではないと判断した場合にはステップＳ６０７にて領域管理テーブル１０４の更新処理を行う。更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態は、例えば図７に示すようになる。図７（Ａ）は、ステップＳ６０６での更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態を示している。また、図７（Ｂ）は、ステップＳ６０７での更新処理後の領域管理テーブル１０４及びメモリプール１０８の状態を示している。
【００３３】
図６に戻り、ステップＳ６０５〜Ｓ６０７において領域管理テーブル１０４におけるリストの更新処理を行った後、ステップＳ６０８にて、メモリ管理部１０３は、解放対象となるインデックスｉが空き領域リストの先頭であるか否かを判断する。ここで、Ｐｉが“−１”であることが先頭であることを表す。
【００３４】
ステップＳ６０８での判断の結果、Ｐｉが“−１”である場合、メモリ管理部１０３は、ステップＳ６０９にて空き領域リスト先頭インデックス３０１をｉに書き換える。なお、ステップＳ６０４にて対象となるインデックスｉが空き領域リストの先頭であるときの処理はステップＳ６０７における前述した処理と同様であるので、説明は省略する。以上で図６に示したステップＳ２１０の処理の詳細説明を終わる。
再び図２に戻り、ステップＳ２１０の処理が終了するとすべての処理が完了する。以上で第１の実施形態におけるデータ処理システムの動作説明を終了する。
【００３５】
第１の実施形態によれば、ブロック間バスを介したデータ処理ブロック間の通信において、送信先である第２のデータ処理ブロック１０９のメモリプール１０８の空き領域を示す領域管理テーブルを送信元である第１のデータ処理ブロック１０５が有する。これにより、ブロック間バスを介した読み込みを行うことなく、第２のデータ処理ブロック１０９でのデータ格納領域を決定してデータ通信を行うことが可能となり、データ通信に係るブロック間バスを介した読み込みの発生を抑止することができる。したがって、ブロック間バスを介したデータ通信における読み込み処理のボトルネックを解消し、データ処理ブロック間の通信性能を向上させることができる。
【００３６】
なお、前述した実施形態では第１のデータ処理ブロック１０５が送信を担い第２のデータ処理ブロック１０９が受信を担うようにしているが、双方のデータ処理ブロックが送受信系を組み込むことで双方向通信が可能である。
【００３７】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。なお、第２の実施形態の説明に用いる図面に関し、前述した実施形態と同じ構成要素については同じ参照符号をつけ、説明を省くことにする。図８は、第２の実施形態におけるデータ処理システムの構成例を示すブロック図である。図８において、送信側である第１のデータ処理ブロック１０５に相対して、ブロック間バス１１０を介して受信側であるＮ個（Ｎは自然数）の第２のデータ処理ブロック８０５〜８０７が接続されている。
【００３８】
第１のデータ処理ブロック１０５において第１の実施形態と最も異なる点は、送信先管理部８０４が追加されたことと、ブロック間通信の領域管理テーブル１０４（領域管理テーブル＜１＞〜領域管理テーブル＜Ｎ＞）を複数有する。送信先管理部８０４は、送信先に対応する領域管理テーブル１０４と受信通知部１０７との情報を管理する。
【００３９】
送信起動部８０１は、送信部８０２に対して送信開始指示や送信終了指示を行う際に送信先のデータ処理ブロックを示す送信先識別子を与える。送信先識別子により、送信先（受信側）のデータ処理ブロックが特定することが可能となっている。送信部８０２は、受け取った送信先識別子を送信先管理部８０４へ送って、対応する受信通知部１０７の情報を取得する。また、送信部８０２は、メモリ管理部８０３に対して送信データ格納領域の確保を要求する際に付加情報として送信先識別子を与える。メモリ管理部８０３は、受け取った送信先識別子を送信先管理部８０４へ送って対応する領域管理テーブル１０４の情報を取得する。
【００４０】
このように、第２の実施形態における第１のデータ処理ブロック１０５は、第１の実施形態の機能に対して複数の送信先を管理する機能が追加されている。次に、図８に示した第２の実施形態におけるデータ処理システムの動作について、図９を参照して説明する。図９は、第２の実施形態におけるデータ処理システムの動作例を示すフローチャートである。
【００４１】
まず、ステップＳ９０１にて、送信起動部８０１が送信部８０２に対して送信開始指示を出す。このとき、送信起動部８０１は、第１の実施形態と同様に送信データ格納領域のサイズとデータ内容とあわせて送信部８０２に渡すほか、送信先識別子を送信部８０２に渡す。次に、ステップＳ９０２にて、送信部８０２がメモリ管理部８０３に対して送信領域確保要求を出す。ここでは、取得する領域のサイズの他に、ステップＳ９０１において受け取った送信先識別子もあわせてメモリ管理部８０３に渡す。
【００４２】
ステップＳ９０３にて、メモリ管理部８０３が送信先管理部８０４に対して送信先識別子を渡し、送信先に対応する領域管理テーブル１０４の情報を取得する。送信先識別子と領域管理テーブル情報との対応付け方法としては様々なものが考えられる。例えば、送信先識別子と対応する領域管理テーブルのアドレスとを静的にテーブル管理する方式等がある。この方式によれば、メモリ管理部８０３が取得したアドレスは直接的に所望の領域管理テーブル１０４（領域管理テーブル＜１＞〜領域テーブル＜Ｎ＞のどれか１つ）を示すことになる。
【００４３】
ステップＳ９０４にて、図２に示したステップＳ２０３〜Ｓ２０４と同様の処理が行われる。次に、ステップＳ９０５にて、送信部８０２が送信先管理部８０４に対して送信先識別子を渡し、送信先の受信通知部１０７の情報を取得する。送信先識別子と各第２のデータ処理ブロック８０５〜８０７の受信通知部１０７との対応付け方法としては様々なものが考えられる。例えば、第１の実施形態で述べたように受信通知部１０７が通信レジスタとして構成されている場合には、識別子と受信通知部のＩＯアドレスとを静的なテーブルで管理しておけば良い。
【００４４】
なお、ここで言うＩＯアドレスとは、ブロック間バス１１０のインターフェース規格から定まるＩＯ空間のアドレスのことであり、例えばＰＣＩウインドウ上のマップアドレス等が相当する。この方式によれば、送信部８０２は取得したアドレスに対してアクセスすることで所望の受信通知部１０７へアクセス可能となる。なお、ステップＳ９０３及びＳ９０５において送信先管理部８０４の管理情報が用いられるが，これらの情報は初期化時の任意のタイミングで設定することが可能である。設定方法としては様々な方法が考えられるが，本実施形態では特に限定しない。次に、ステップＳ９０６にて、図２に示したステップＳ２０５〜ステップＳ２０７と同様の処理が行われて、受信側における処理が完了する。
【００４５】
次に、ステップＳ９０７にて、送信起動部８０１が送信部８０２に対して送信終了指示を出す。送信起動部８０１が送信部８０２に対して送信終了指示を行うタイミングを決定する方法には様々なものが考えうるが、ここでは特に限定しない。ステップＳ９０８にて、送信部８０２が送信先識別子を付加して送信データ格納領域の解放要求をメモリ管理部８０３へ行う。なお、ステップＳ９０７〜Ｓ９０８における処理において第１の実施形態の処理との差異は、ステップＳ９０１〜Ｓ９０２の処理と同様に送信先識別子が付加データとして渡ることのみである。
【００４６】
次に、ステップＳ９０９にて、前述したステップＳ９０３と同様にしてメモリ管理部８０３が解放対象の領域管理テーブル１０４を選択する。続くステップＳ９１０にて、図２に示したステップＳ２１０と同様の処理が行われて送信データ格納領域の解放が完了する。以上で、図９に示した第２の実施形態におけるデータ処理システムの動作説明を終わる。
【００４７】
第２の実施形態によれば、第１の実施形態と同様に、ブロック間バスを介した読み込みを行うことなく、受信側である第２のデータ処理ブロックでのデータ格納領域を決定してデータ通信を行うことが可能となる。したがって、データ通信に係るブロック間バスを介した読み込みの発生を抑止することができ、データ通信における読み込み処理のボトルネックを解消し、データ処理ブロック間の通信性能を向上させることができる。なお、本実施形態では第１のデータ処理ブロック１０５が送信を担い、他のデータ処理ブロック群８０５〜８０７が受信を担うようにしているが、双方のデータ処理ブロックが送受信系を組み込むことで双方向通信が可能である。
【００４８】
（第３の実施形態）
次に、本発明の第３の実施形態について説明する。なお、第３の実施形態の説明に用いる図面に関し、前述した実施形態と同じ構成要素については同じ参照符号をつけ、説明を省くことにする。図１０は、第３の実施形態におけるデータ処理システムの構成例を示すブロック図である。図１０において、第１の実施形態と異なる構成要素は、第１のデータ処理ブロック１０５の送信クライアント１００１及び送信通知部１００３である。
【００４９】
送信クライアント１００１は、メモリ管理部１０３を制御して送信データ格納領域の取得を行う。また、送信クライアント１００１は、第２のデータ処理ブロック１０９が有するブロック間通信用のメモリプール１０８へ送信データを直接書き込むとともに、送信通知部１００３に対して送信開始指示を出す。また、送信クライアント１００１は、メモリ管理部１０３に対して送信データ格納領域の解放指示を行う。送信通知部１００３は、送信クライアント１００１からの送信開始指示を受け取ると、第２のデータ処理ブロック１０９が有する受信通知部１０７へ受信要求を通知する。
【００５０】
以下、第３の実施形態におけるデータ処理システムの動作について図１１に示すフローチャートを参照して説明する。図１１は、第３の実施形態におけるデータ処理システムの動作例を示すフローチャートである。まず、ステップＳ１１０１にて、送信クライアント１００１がメモリ管理部１０３に対して、送信データ格納領域の確保を依頼する。このとき、送信クライアント１００１は、取得したい領域のサイズをあわせて渡す。
【００５１】
次に、ステップＳ１１０２にて、図２に示したステップＳ２０２〜Ｓ２０３と同様の処理が行われ、取得された送信データ格納領域のアドレスが、送信クライアント１００１へ返される。次に、ステップＳ１１０３にて、送信クライアント１００１は、ステップＳ１１０２において取得したメモリプール１０８の送信データ格納領域へ送信データを書き込む。送信データ格納領域への送信データの書き込みは、ブロック間バス１１０を経由して行う。
【００５２】
次に、ステップＳ１１０４にて、送信クライアント１００１が送信通知部１００３に対して送信開始指示を出す。このとき、データを書き込んだ送信データ格納領域のアドレスをあわせて送信通知部１００３に渡す。ステップＳ１１０５にて、図２に示したステップＳ２０５〜Ｓ２０７と同様の処理が行われ、データの受信処理が完了する。なお、第１の実施形態において送信部１０２が行った送信データ格納領域のアドレスの変換機能は、送信通知部１００３が有している。
【００５３】
次に、ステップＳ１１０６にて、送信クライアント１００１は、メモリ管理部１０３に対して送信データ格納領域の先頭アドレスとサイズとを送り、その送信データ格納領域の解放指示を行う。続くステップＳ１１０７にて、図２に示したステップＳ２１０と同様の処理が行われて送信データ格納領域が解放される。以上で、図１１に示した第３の実施形態におけるデータ処理システムの動作説明を終わる。
【００５４】
第３の実施形態によれば、ブロック間バスを介した読み込みを行うことなく、第２のデータ処理ブロック１０９でのデータ格納領域を決定してデータ通信を行うことが可能となる。したがって、データ通信に係るブロック間バスを介した読み込みの発生を抑止することができ、データ通信における読み込み処理のボトルネックを解消し、データ処理ブロック間の通信性能を向上させることができる。なお、本実施形態では第１のデータ処理ブロック１０５が送信を担い、第２のデータ処理ブロック１０９が受信を担うようにしているが、双方のデータ処理ブロックが送受信系を組み込むことで双方向通信が可能である。また、本実施形態では送信側と受信側が１つずつの場合について説明したが、第２の実施形態のように送信先管理部８０４を導入すれば、複数の受信先に対応可能である。
【００５５】
（第４の実施形態）
次に、本発明の第４の実施形態について説明する。なお、第４の実施形態の説明に用いる図面に関し、前述した実施形態と同じ構成要素については同じ参照符号をつけ、説明を省くことにする。まず、第４の実施形態におけるデータ処理システムの構成について概略を述べ、次に動作について説明する。
【００５６】
図１２〜図１４を参照して、第４の実施形態におけるデータ処理システムの構成について説明する。図１２は、第４の実施形態におけるデータ処理システムの全体構成例を示すブロック図である。図１２において、１２０１及び１２１１はブロック間通信を行う複数のデータ処理ブロックである。複数のデータ処理ブロック１２０１、１２１１はブロック間バス１１０上に接続されている。なお、データ処理システムの構成は、第１の実施形態で述べた通り、異なるチップに配置された複数のデータ処理ブロックからなる構成や、１つのチップに配置された複数のデータ処理ブロックからなる構成を含む。
【００５７】
データ処理ブロック１２０１は、複数の通信クライアント１２０２、送信制御部１２０３、受信制御部１２０４、内部メモリプール１２０５、及びブロック間通信用のメモリプール１０８を有する。図１２においては、データ処理ブロック１２０１の内部構成のみ図示しているが、複数のデータ処理ブロック１２０１、１２１１は同様の内部構成を有する。
【００５８】
送信制御部１２０３は、通信クライアント１２０２から送信データ格納領域の確保指示や解放指示、送信開始指示を受け取り、送信関連の制御全般を受け持つ。送信制御部１２０３は、送信データ格納領域の確保指示を受け取ると、相手先のデータ処理ブロックのメモリプール１０８から送信データ格納領域を確保するとともに、内部メモリプール１２０５から返信データ格納領域を確保する。通信クライアント１２０２が送信データ格納領域への送信データの書き込みを終えて送信開始指示を出すと、送信制御部１２０３は相手先のデータ処理ブロックに対して受信通知要求を出す。また、送信制御部１２０３は、送信データ格納領域の解放指示を受け取ると、確保した送信データ格納領域及び返信データ格納領域を解放する。
【００５９】
受信制御部１２０４は、他のデータ処理ブロックから受信通知要求を受けると通信クライアント１２０２へ通知する。受信制御部１２０４は、受信通知要求で渡されたアドレスのコマンドヘッダを解釈して通知すべき通信クライアント１２０２と受信データ種別（返信か新規送信か）を特定する。そして、受信制御部１２０４は、受信データ種別と受信データのアドレスを通信クライアント１２０２へ通知して受信指示を出す。受信制御部１２０４からの受信指示を受け取った通信クライアント１２０２は、渡されたアドレスからデータを読み込む。
【００６０】
次に、送信制御部１２０３の構成について図１３を参照して説明する。図１３は、送信制御部１２０３の構成例を示すブロック図である。図１３において、１３０１は送信領域管理部である。通信クライアント１２０２からの送信データ格納領域の確保指示及び解放指示への対応は、送信領域管理部１３０１が行う。送信領域管理部１３０１は、送信先のデータ処理ブロックの識別子（送信先識別子）と領域情報とを、ブロック通信用のメモリ管理部８０３へ渡して送信データ格納領域を確保する。また、送信領域管理部１３０１は、内部メモリ管理部１３０２を用いて内部メモリプール１２０５から返信データ格納領域を確保する。
【００６１】
返信データ格納領域とは、送信先の通信クライアントが実行結果等を格納するための領域である。返信された内容は送信側の通信クライアント１２０２が読み出すため、同じデータ処理ブロック（送信側のデータ処理ブロック）内に返信データ格納領域は確保される。なお、内部メモリ管理部１３０２が行う内部メモリプールの管理手法としては、様々な方法が適用可能である。例えば、一般的に用いられるリンクリストによる空きリスト管理手法などが考えられるが、ここでは限定しない。
【００６２】
通信クライアント１２０２が指示する送信開始指示に対しては、アドレス変換部１３０３が対応する。通信クライアント１２０２が送信要求するアドレスは、送信データ格納領域内部のアドレスであるため、それを送信データ格納領域の先頭アドレスに変換して送信通知部１３０５へ渡す。送信通知部１３０５における送信処理動作については、図１０に示した第３の実施形態における送信通知部１００３の動作に対して送信先管理部８０４が行う送信先の選択動作が加わるのみである。これについては第２の実施形態及び第３の実施形態において既出であるので説明を省く。
【００６３】
次に、受信制御部１２０４の構成について図１４を参照して説明する。図１４は、受信制御部１２０４の構成例を示すブロック図である。図１４において、受信管理部１４０１は、受信通知部１０７から受信通知要求と受信データアドレスを受け取る。なお、受信通知部１０７は第１の実施形態にて既出であるため説明を省く。受信通知部１０７から受け取るアドレスは、メモリプール１０８又は内部メモリプール１２０５のどちらかに含まれる領域のアドレスである。
【００６４】
受信管理部１４０１は、受け取ったアドレスを参照して既定のコマンドヘッダを読み込む。後述する動作説明にて詳細を説明するが、このコマンドヘッダには受信データ種別（返信か新規送信か）と通信クライアントを指定する識別子が含まれている。受信管理部１４０１は、受信データ種別と通信クライアント識別子を受信データアドレスとともにクライアント管理部１４０２へ渡す。
【００６５】
クライアント管理部１４０２は、通信クライアント識別子と対応する通信クライアント１２０２との関係を管理しており、受信管理部１４０１から受けた情報を通信クライアント１２０２へ引き渡す。なお、クライアント管理部１４０２における通信クライアント管理手法としては様々な方法が適用可能であるが特に限定はしない。例えば、初期化時に通信クライアント１２０２が自身の識別子とともにコールバック関数を登録しておく手法等がある。この手法によれば、クライアント管理部１４０２は、識別子に対応したコールバック関数を呼ぶことで、対象となる通信クライアント１２０２へ情報を通知することが可能となる。
【００６６】
次に、第４の実施形態におけるデータ処理システムの動作について図１５を参照して説明する。図１５は、第４の実施形態におけるデータ処理システムの動作例を示すフローチャートである。図１５において特に断らない限り、ステップＳ１５０１〜Ｓ１５０７、及びステップＳ１５１５〜Ｓ１５１７の処理は、送信を起動した側のデータ処理ブロック（例えばデータ処理ブロック１２０１）での動作である。また、ステップＳ１５０８〜ステップＳ１５１４の処理は、受信側のデータ処理ブロック（例えばデータ処理ブロック１２１１）での動作である。
【００６７】
なお、以下の説明で用いる構成要素の参照符号には送信側でも受信側でも同じものを用いる。また、送信側、受信側という役割は説明の便宜のためにつけたものであり、ブロック間バス１１０に接続されたすべてのデータ処理ブロック（１２０１、１２１１）が送信側にも受信側にもなり得る。なお、送信側の機能又は受信側の機能の一方のみを備え、送信側又は受信側としてのみ動作するようなデータ処理ブロックが含まれていてもよい。
【００６８】
ステップＳ１５０１にて、通信クライアント１２０２が受信制御部１２０４のクライアント管理部１４０２に対して、自身の識別子と受信要求通知方法を登録する。受信要求通知方法としては、例えば前述したようなコールバック関数を用いる。例えばＣ言語のプロトタイプで示せば、下記のようになる。引数の意味については、ステップＳ１５１０〜Ｓ１５１１の処理での説明にて後述する。
void (*callback)(int chip_id, int client_id, int kind, void *sendBuf, int sendLength, void *respBuf, int respLength)
このステップＳ１５０１における処理は、システム初期化時に行われることが一般的であり、送信側であるか受信側であるかにかかわらずすべてのデータ処理ブロック（１２０１、１２１１）に共通の処理である。
【００６９】
次に、ステップＳ１５０２にて、通信クライアント１２０２が送信制御部１２０３の送信領域管理部１３０１に対して送信データ格納領域の確保指示を出す。このとき、通信クライアント１２０２は、自身の識別子、送付先の識別子（データ処理ブロック識別子と通信クライアント識別子）、送信データサイズ、及び返信データサイズをあわせて送信領域管理部１３０１に渡す。
【００７０】
ステップＳ１５０２における処理について図１６〜図１７を参照して詳細に説明する。図１６は、ステップＳ１５０２における送信領域管理部１３０１の動作例を示すフローチャートである。ステップＳ１６０１にて、送信領域管理部１３０１は、メモリ管理部８０３から送信パケット領域を取得する。領域の取得方法については第３の実施形態において既出であるので説明を省くが、ここでは送信パケット領域について述べておく。
【００７１】
図１７において、１７０１は送信パケット領域のフォーマットを表す。送信パケット領域１７０１は、送信コマンドヘッダ部１７０２及び送信データ格納領域１７１０に分かれている。送信コマンドヘッダ部１７０２は、送信先処理ブロック識別子１７０３、送信先クライアント識別子１７０４、送信元処理ブロック識別子１７０５、送信元クライアント識別子１７０６、送信データ格納領域サイズ１７０７、及びパケット種別１７０８を有する。また、送信コマンドヘッダ部１７０２は、返信パケット領域開始位置１７０９及び返信データ格納領域サイズ１７１１を有する。
【００７２】
送信コマンドヘッダ部１７０２のサイズはＳｈであり固定である。送信データ格納領域１７１０のサイズは、ステップＳ１５０２において通信クライアント１２０２が与えた送信データサイズと等しい。したがって、送信領域管理部１３０１がステップＳ１６０１において取得する送信パケット領域のサイズは、Ｓｈと送信データサイズの和になる。なお、メモリ管理部８０３が返却するアドレスは、ブロック間バス１１０を介してアクセスするためのアドレスである。これは第１の実施形態で述べた通り、領域管理テーブル１０４が持つ機能を用いて変換した結果である。
【００７３】
図１６に戻り、ステップＳ１６０２にて、送信領域管理部１３０１は、送信パケット領域の確保が成功したか否かを判断する。送信パケット領域の確保が失敗した場合、ステップＳ１６０８にて失敗を通知して処理を完了させる。送信パケット領域の確保が成功した場合、送信領域管理部１３０１は、ステップＳ１６０３にて内部メモリ管理部１３０２から返信パケット領域を取得する。
【００７４】
返信パケット領域のフォーマットは図１７の１７２１に示してある。返信パケット領域１７２１は返信データヘッダ部１７２２及び返信データ格納領域１７３０に分かれている。返信データヘッダ部１７２２は、返信先処理ブロック識別子１７２３、返信先クライアント識別子１７２４、返信元処理ブロック識別子１７２５、返信元クライアント識別子１７２６、返信データ格納領域サイズ１７２７、及びパケット種別１７２８を有する。また、返信データヘッダ部１７０２は、親送信パケット領域開始位置１７２９を有する。なお、領域１７３１はリザーブ領域である。
【００７５】
返信データヘッダ部１７２２のサイズは送信コマンドヘッダ部１７０２と同様にＳｈであり固定である。返信データ格納領域１７３０のサイズは、ステップＳ１５０２において通信クライアント１２０２が与えた返信データサイズと等しい。したがって、送信領域管理部１３０１がステップＳ１６０３において取得する返信パケット領域のサイズは、Ｓｈと返信データサイズの和になる。返信パケット領域は送信側の内部メモリプール１２０５に確保される。これは後述するようにデータ書き込みを受信側で行い、データ読み込みを送信側で行うためである。また、内部メモリ管理部１３０２が返却するアドレスはデータ処理ブロック内部のアドレス空間での値である。なお、ステップＳ１６０３において内部メモリ管理部１３０２が内部メモリプール１２０５からメモリを確保する方法については前述した通り特に限定しない。
【００７６】
再び図１６に戻り、ステップＳ１６０４にて、送信領域管理部１３０１は、返信パケット領域の確保が成功したか否かを判断する。返信パケット領域の確保が失敗した場合、ステップＳ１６０８にて失敗を通知して処理を終了する。返信パケット領域の確保が成功した場合、送信領域管理部１３０１は、ステップＳ１６０５にて送信コマンドヘッダ部１７０２へ情報を書き込む。書き込む情報は図１７に示した１７０３〜１７０９及び１７１１である。送信先データ処理ブロック識別子１７０３及び送信先クライアント識別子１７０４は、送信先を特定する情報である。送信元データ処理ブロック識別子１７０５及び送信元クライアント識別子１７０６は送信元を特定する情報である。送信データ格納領域サイズ１７０７は実際に通信クライアント１２０２が送信データを書き込む送信データ格納領域１７１０のサイズである。返信データ格納領域サイズ１７１１は送信先のクライアントが返信を書き込む返信データ格納領域１７３０のサイズである。パケット種別１７０８は、このパケットが新規送信パケットであるのか、返信パケット（ある新規送信パケットへの返信）であるかを示す。ここでは新規送信パケットとなる。ここに１７０３から１７０７及び１７１１は、すべてステップＳ１５０１において通信クライアント１２０２が与えたデータである。一方、返信パケット領域開始位置１７０９は返信パケット領域１７２１の先頭を表し、領域取得時に送信領域管理部１３０１が動的に決定する。なお、返信パケット領域開始位置１７０９は、送信先データ処理ブロックのアドレス空間に変換された値である。送信領域管理部１３０１は、自身のアドレス空間内における内部メモリプール１２０５のアドレスを、送信先データ処理ブロックがブロック間バス１１０を介してアクセスするための値に変換する機能を有する。
【００７７】
続いて、ステップＳ１６０６にて、送信領域管理部１３０１は、返信データヘッダ部１７２２へ情報を書き込む。書き込む情報は図１７の１７２３〜１７２９である。返信先データ処理ブロック識別子１７２３及び返信先クライアント識別子１７２４は返信先を特定するための情報である。言い換えれば送信元の識別子と等しい。返信元データ処理ブロック識別子１７２５及び返信元クライアント識別子１７２６は、返信元を特定するための情報である。言い換えれば送信先の識別子と等しい。返信データ格納領域サイズ１７２７は、返信データ格納領域１７３０のサイズを表す。パケット種別１７２８はパケット種別１７０８と同様であるが、ここでの値は返信パケットを表す。これら１７２３〜１７２７は、すべてステップＳ１５０１において通信クライアント１２０２が与えたデータである。一方、親送信パケット領域開始位置１７２９は送信パケット領域１７０１の先頭を表し、領域取得時に送信領域管理部１３０１が動的に決定する。なお、親送信パケット領域開始位置１７２９は送信元データ処理ブロックのアドレス空間からアクセスするための値をそのまま格納する。
【００７８】
次に、ステップＳ１６０７にて、送信領域管理部１３０１は、送信データ格納領域１７１０の先頭アドレスを返却して処理を完了する。以上で図１５に示したステップＳ１５０２での処理の説明を終わる。
【００７９】
図１５に戻り、ステップＳ１５０３以降の処理について説明する。ステップＳ１５０３にて、通信クライアント１２０２は、取得した送信データ格納領域へ送信データを書き込む。次に、ステップＳ１５０４にて、通信クライアント１２０２が送信制御部１２０３のアドレス変換部１３０３に対して送信開始を指示する。ここでは、通信クライアント１２０２が送信先のデータ処理ブロック識別子と送信データ格納領域の先頭アドレスとをあわせてアドレス変換部１３０３に渡す。
【００８０】
アドレス変換部１３０３は、受け取った送信データ格納領域の先頭アドレスを送信パケット領域の先頭アドレスへ変換する。この変換は図１７から明らかな通り、送信データ格納領域１７１０のアドレスからヘッダサイズＳｈを引くことで行う。そして、アドレス変換部１３０３は、送信パケット先頭アドレスを送信通知部１３０５へ送付して送信開始指示を中継する。なお、対象が返信パケットの場合も全く同様の処理によって、返信データ格納領域のアドレスを返信パケット領域のアドレスに変換する。
【００８１】
次に、ステップＳ１５０５にて、図９に示したステップＳ９０５と同様の処理を行い、送信通知部１３０５が送信先の受信通知部１０７を特定する。ステップＳ１５０６にて、送信通知部１３０５が送信パケット領域アドレスのアドレス空間を変換する。ここでは送信側のデータ処理ブロックのアドレス空間から、受信側のデータ処理ブロックがブロック間バス１１０を介してアクセスするためのアドレスへ変換する。アドレス空間変換は、第３の実施形態と同様に送信通知部１３０５により行われる。
【００８２】
ステップＳ１５０７にて、送信通知部１３０５が送信先の受信通知部１０７に対して、送信パケットアドレス及び受信要求を通知する。ステップＳ１５０８にて、受信通知部１０７は受信管理部１４０１に対して受信要求を中継する。ここでは送信パケットアドレスをあわせて受信管理部１４０１に渡す。
【００８３】
ステップＳ１５０９にて、受信管理部１４０１は、自データ処理ブロック内のメモリプール１０８へアクセスして送信コマンドヘッダ部１７０２を解析し、クライアント管理部１４０２へ通知する。ここで通知するデータは、送信関連情報と返信関連情報とに分かれる。送信関連情報としては、送信先クライアント識別子１７０４、送信データ格納領域のアドレス１７０７とサイズ１７１０である。返信関連情報としては、返信先のデータ処理ブロック識別子１７０５とクライアント識別子１７０６、及び返信データ格納領域のアドレス１７０９とサイズ１７１１である。なお、返信データ格納領域のアドレスは、返信パケット領域開始位置１７０９にＳｈを加えることで求める。
【００８４】
ここで、パケット種別が新規送信パケットを表している場合には、送信関連情報及び返信関連情報のすべてを通知する。ステップＳ１５０９では、新規送信パケットである場合を扱っているので、すべての情報を通知することになる。なお、パケット種別が返信パケットを表している場合には、送信関連情報のみを通知する。この場合にはアクセス先がメモリプール１０８ではなく、内部メモリプール１２０５になる。また、解析対象となるヘッダは返信データヘッダ部１７２２である。最終的に、選択したデータ群とパケット種別そのものを含めてクライアント管理部１４０２へ通知する。
【００８５】
次に、ステップＳ１５１０にて、クライアント管理部１４０２は、受け取った送信先クライアント識別子に対応した通信クライアント１２０２を選んでそれを呼び出す。前述したコールバック関数を用いるとすれば、chip_idに返信先のデータ処理ブロック識別子、client_idに返信先のクライアント識別子を設定する。さらに、kindには送信パケット種別、sendBuf及びsendLengthにはそれぞれ送信データ格納領域のアドレス及びサイズを設定する。そして、respBuf及びrespLengthにはそれぞれ返信データ格納領域のアドレス及びサイズを設定する。パケット種別が返信パケットであるときは、chip_id、client_id、respBuf及びrespLengthは設定しない。通常は、このコールバック関数が呼ばれると該当する通信クライアントに対して受信要求が通知され、同時に引数に設定したデータが渡される仕組みとなっているのが一般的である。なお、ここで示した通知方法は一例であり、他の手法を用いることも可能である。
【００８６】
ステップＳ１５１０において受信要求を受け取った通信クライアント１２０２は、ステップＳ１５１１にて自データ処理ブロック内にあるメモリプール１０８へアクセスして送信データ格納領域からデータを読み込む。そして送信内容に応じた任意の処理を行う。次に、ステップＳ１５１２にて、通信クライアント１２０２は、ステップＳ１５１１における実行結果等を返信データ格納領域へ書き込む。ここでの書き込み先は、ブロック間バス１１０を経由してアクセスする送信元のデータ処理ブロック側にある内部メモリプール１２０５である。
【００８７】
次に、ステップＳ１５１３にて、通信クライアント１２０２は、アドレス変換部１３０３に対してレスポンス送信（新規送信パケットに対する返信パケットの送信）開始を指示する。ここでは、通信クライアント１２０２は、返信データ格納領域のアドレスをあわせてアドレス変換部１３０３に渡す。ステップＳ１５１４にて、ステップＳ１５０５〜Ｓ１５０７と同様の処理によって、元の送信パケット送信元にある受信通知部１０７へ受信要求を通知する。ここで返信パケット送信側の送信通知部１３０５が行うアドレス操作は、ステップＳ１５０５〜Ｓ１５０７において送信パケット送信元の送信通知部１３０５が行ったものと同様である。
【００８８】
次に、ステップＳ１５１５にて、ステップＳ１５０８〜Ｓ１５１０と同様の処理が行われて通信クライアント１２０２が返信パケットを受け取る。次に、ステップＳ１５１６にて、通信クライアント１２０２が送信データ格納領域の解放を送信領域管理部１３０１へ指示する。ただし、ここで渡すアドレスは返信データ格納領域の先頭アドレスである。なお、通信クライアント１２０２は、受け取ったパケットが返信パケットであることを確認し、その返信データ格納領域を読み込んで内容を確認したものとする。通信クライアント１２０２はその結果を以って自身が起動した送信パケットに伴う一連の作業が完了したことを判断して、送信データ格納領域の解放を指示する。
【００８９】
最後にステップＳ１５１７にて、送信領域管理部１３０１が送信パケット領域と返信パケット領域を解放する。送信領域管理部１３０１はアドレスとして返信データ格納領域１７３０の先頭アドレスを受け取っている。ここからオフセットして返信パケット領域１７２１の先頭アドレスを求め、さらにヘッダに存在する親送信パケット領域開始位置１７２９から送信パケット領域１７０１の先頭アドレスを求める。そして、送信パケット領域先頭アドレス及び返信パケット領域先頭アドレスを、それぞれメモリ管理部８０３及び内部メモリ管理部１３０２へ渡して領域を解放する。メモリ管理部８０３における解放処理方法については、第３の実施形態で述べた方法と同様である。また、内部メモリ管理部１３０２におけるメモリ解放方法については前述した通り限定する必要がないので、ここでは説明を割愛する。
【００９０】
なお、図１５を参照した説明においては、１つの送信パケットが発生してからその返信パケットが送信されて１つの通信コンテキストが完了する場合について説明した。しかし、通信コンテキストのライフサイクルは任意であり、前述したやり取りが送信領域の解放を伴わずに何度も繰り返されることも有り得る。例えば１回の送信後に少なくとも１回以上の返信を受けたことで通信の完了を判断して領域の解放を行う場合がある。あるいは、送信領域を確保した後、１回以上の送信と送信毎に少なくとも１回以上の返信を受け取った後、送信領域を解放する場合もある。本実施形態ではこのような場合にも対応可能であることは明らかである。以上で第４の実施形態におけるデータ処理システムの動作説明を終了する。
【００９１】
第４の実施形態によれば、送信パケットに対して返信パケットを伴うデータ処理ブロック間の通信において、返信パケットを送信元データ処理ブロック内のメモリプールから確保する。これにより、送信先及び送信元それぞれがブロック間バスを介した読み込みを抑止できるため、さらなるデータ処理速度の向上が見込まれる。
【００９２】
（本発明の他の実施形態）
本発明は、前述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００９３】
なお、前記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００９４】
１０１、８０１：送信起動部  １０２、８０２：送信部  １０３、８０３：メモリ管理部  １０４：領域管理テーブル  １０５、１０９、８０５、８０６、８０７、１２０１、１２１１：データ処理ブロック  １０６：受信部  １０７：受信通知部  １０８：メモリプール  １１０：ブロック間バス  ８０４：送信先管理部  １００１：送信クライアント  １００３、１３０５：送信通知部  １２０２：通信クライアント  １２０３：送信制御部  １２０４：受信制御部  １２０５：内部メモリプール  １３０１：送信領域管理部  １３０２：内部メモリ管理部  １３０３：アドレス変換部  １４０１：受信管理部  １４０２：クライアント管理部
【図１】
2017174006.tif 000003
【図２】
2017174006.tif 000004
【図３】
2017174006.tif 000005
【図４】
2017174006.tif 000006
【図５】
2017174006.tif 000007
【図６】
2017174006.tif 000008
【図７】
2017174006.tif 000009
【図８】
2017174006.tif 000010
【図９】
2017174006.tif 000011
【図１０】
2017174006.tif 000012
【図１１】
2017174006.tif 000013
【図１２】
2017174006.tif 000014
【図１３】
2017174006.tif 000015
【図１４】
2017174006.tif 000016
【図１５】
2017174006.tif 000017
【図１６】
2017174006.tif 000018
【図１７】
2017174006.tif 000019