複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理部と、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停部と、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御部とを具備する相互接続装置。前記リクエスト待機制御部は、前記先行リクエストが前記複数の応答デバイスのいずれかに出力されたときに前記待機リクエストを前記調停部へ出力する請求項1記載の相互接続装置。前記リクエスト待機制御部は、前記先行リクエストに対するレスポンスが前記複数の応答デバイスのうちのいずれかから出力されたときに前記待機リクエストを前記調停部へ出力する請求項1記載の相互接続装置。前記リクエスト管理部は、前記待機リクエストに前記先行リクエストを識別するための先行リクエスト識別子を生成して前記待機リクエストに付加することにより当該待機リクエストに前記先行リクエストを対応付け、前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に係る前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する請求項1記載の相互接続装置。前記リクエスト管理部は、前記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として前記リクエストに付加する自己リクエスト識別子付加部と、前記自己リクエスト識別子が付加された前記リクエストが前記待機リクエストである場合には前記先行リクエストに該当する前記リクエストについて生成されていた前記リクエスト識別子を前記先行リクエスト識別子として前記待機リクエストに付加する先行リクエスト識別子付加部とを備え、前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に一致する前記自己リクエスト識別子が付加された前記リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する請求項4記載の相互接続装置。前記リクエスト識別子は、前記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る前記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、前記先行リクエスト識別子付加部は、前記グループ識別子に基づいて前記待機リクエストが属する前記グループを特定して当該特定したグループにおいて前記先行リクエストを特定する請求項5記載の相互接続装置。前記リクエスト管理部は、前記リクエストが前記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された前記自己リクエスト識別子に一致する前記リクエスト識別子を前記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備える請求項5記載の相互接続装置。前記リクエスト識別子保持部は、前記リクエストが属する前記グループにおいて前記リクエストが最後に発行されたか否かを示すラストフラグを前記リクエストごとにさらに保持し、前記先行リクエスト付加部は、前記特定したグループにおいて前記待機リクエストを除き最後に発行されたリクエストを前記ラストフラグに基づいて前記先行リクエストとして特定する請求項6記載の相互接続装置。リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順とを具備する相互接続装置の制御方法。リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順とをコンピュータに実行させるためのプログラム。しかしながら、上述の従来技術では、トランザクション処理におけるレイテンシが増大するおそれがある。上述のデッドロック予測論理は、待機中のリクエストM22およびM12の1つ前のリクエストM21およびM11に対するレスポンスが相互接続装置からマスタに返却されたときにデッドロックが回避されたと判断して待機を取り消す。ここで、相互接続装置が発行順にリクエストのそれぞれをスレーブへ転送し、スレーブがリクエストを受け取った順にレスポンスを返却した場合を考える。この場合、先行のリクエストM21およびM11がスレーブへ出力された時点で既にデッドロックは回避されている。しかるに、この場合であっても、デッドロック予測論理は、先行のリクエストM21およびM11に対するレスポンスがマスタに返却されるまでは待機を取り消さない。この結果、リクエストが発行順にスレーブに転送された場合において、先行のリクエストに対するレスポンスが返却されるまでの間、待機の取り消しが遅延してしまう。デッドロックが生じうるリクエストの発行のたびに待機の取り消しが遅延して、トランザクション処理の遅延が増大してしまうおそれがある。本技術はこのような状況に鑑みて生み出されたものであり、相互接続装置においてデッドロックを回避しつつ、レイテンシを低減することを目的とする。本技術は、上述の問題点を解消するためになされたものであり、その第1の側面は、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの上記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに上記先行リクエストを対応付けて管理するリクエスト管理部と、上記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを上記複数の応答デバイスのうち上記調停したリクエストの宛先である応答デバイスに出力する調停部と、上記待機リクエストを待機させて、当該待機リクエストに対応する上記先行リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力するリクエスト待機制御部とを具備する相互接続装置、および、その制御方法ならびに当該方法をコンピュータに実行させるためのプログラムである。これにより、先行リクエストが複数の応答デバイスのいずれかに出力されるまで待機リクエストが待機するという作用をもたらす。また、この第1の側面において、上記リクエスト待機制御部は、上記先行リクエストが上記複数の応答デバイスのいずれかに出力されたときに上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエストが複数の応答デバイスのいずれかに出力されたときに待機リクエストが出力されるという作用をもたらす。また、この第1の側面において、上記リクエスト待機制御部は、上記先行リクエストに対するレスポンスが上記複数の応答デバイスのうちのいずれかから出力されたときに上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエストに対するレスポンスが複数の応答デバイスのうちのいずれかから出力されたときに待機リクエストが出力されるという作用をもたらす。また、この第1の側面において、上記リクエスト管理部は、上記待機リクエストに上記先行リクエストを識別するための先行リクエスト識別子を生成して上記待機リクエストに付加することにより当該待機リクエストに上記先行リクエストを対応付け、上記リクエスト待機制御部は、上記待機リクエストに付加された上記先行リクエスト識別子の示す上記先行リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力してもよい。これにより、待機リクエストに先行リクエスト識別子が付加され、その先行リクエスト識別子に係る先行リクエストが複数の応答デバイスのいずれかに出力された後に待機リクエストが調停部へ出力されるという作用をもたらす。また、この第1の側面において、上記リクエスト管理部は、上記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として上記リクエストに付加する自己リクエスト識別子付加部と、上記自己リクエスト識別子が付加された上記リクエストが上記待機リクエストである場合には上記先行リクエストに該当する上記リクエストについて生成されていた上記リクエスト識別子を上記先行リクエスト識別子として上記待機リクエストに付加する先行リクエスト識別子付加部とを備え、上記リクエスト待機制御部は、上記待機リクエストに付加された上記先行リクエスト識別子に一致する上記自己リクエスト識別子が付加された上記リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエスト識別子および自己リクエスト識別子が待機リクエストに付加され、その先行リクエスト識別子に一致する自己リクエスト識別子が付加されたリクエストが複数の応答デバイスのいずれかに出力された後に待機リクエストが上記調停部へ出力されるという作用をもたらす。また、この第1の側面において、上記リクエスト管理部は、上記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る上記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、上記先行リクエスト識別子付加部は、上記グループ識別子に基づいて上記待機リクエストが属する上記グループを特定して当該特定したグループにおいて上記先行リクエストを特定してもよい。これにより、グループ識別子に基づいて待機リクエストが属するグループが特定され、そのグループにおいて先行リクエストが特定されるという作用をもたらす。また、この第1の側面において、上記リクエスト管理部は、上記リクエストが上記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された上記自己リクエスト識別子に一致する上記リクエスト識別子を上記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備えてもよい。これにより、複数の応答デバイスのいずれかに出力されたリクエストに付加された自己リクエスト識別子に一致するリクエスト識別子がリクエスト識別子保持部から削除されるという作用をもたらす。また、この第1の側面において、上記リクエスト識別子保持部は、上記リクエストが属する上記グループにおいて上記リクエストが最後に発行されたか否かを示すラストフラグを上記リクエストごとにさらに保持し、上記先行リクエスト付加部は、上記特定したグループにおいて上記待機リクエストを除き最後に発行されたリクエストを上記ラストフラグに基づいて上記先行リクエストとして特定してもよい。これにより、特定されたグループにおいて待機リクエストを除き最後に発行されたリクエストが先行リクエストとして特定されるという作用をもたらす。本技術によれば、相互接続装置においてデッドロックが回避され、トランザクション処理のレイテンシが低減するという優れた効果を奏し得る。以下、本技術を実施するための形態以下、実施の形態と称するについて説明する。説明は以下の順序により行う。1.第1の実施の形態順序制御信号をリクエストに付加する例2.第2の実施の形態先行リクエスト履歴保持部にラストフラグを保持しない例<1.第1の実施の形態>[情報処理システムの構成]図1は、本発明の第1の実施の形態における情報処理システムの全体図の一例である。情報処理システムは、マスタ111および112と、スレーブ121および122と、相互接続装置200とを備える。マスタ111および112とスレーブ121および122は相互接続装置200に接続されている。マスタ111および112はデータ転送を主導する接続機器であり、トランザクション処理においてリクエストを発行して相互接続装置200に信号線115および116を介して出力する。マスタ111および112としては、例えばプロセッサが想定される。スレーブ121および122は受動的に動作する接続機器であり、受け取ったリクエストに対するレスポンスを相互接続装置200に信号線125および126を介して出力する。スレーブ121および122としては、例えばメモリが想定される。なお、マスタ111および112は、特許請求の範囲に記載の要求デバイスの一例である。スレーブ121および122は、特許請求の範囲に記載の応答デバイスの一例である。また、相互接続装置200に2台のマスタ111および112を接続する構成としているが、相互接続装置200にマスタを3台以上接続してもよい。スレーブも同様に相互接続装置200に3台以上接続してもよい。相互接続装置200は、スプリットトランザクションを許容する所定のプロトコルに従ってマスタおよびスレーブ間においてデータを転送するものである。相互接続装置200は、リクエスト管理部301および302とバスマトリックス400とを備える。相互接続装置200においては、スプリットトランザクションを許容するプロトコルとして、例えば、AXIAdvancedeXtensibleInterfaceプロトコルが用いられる。ここで、AXIプロトコルでは、リード動作のためのパスとして、リードアドレスチャネルおよびリードデータチャネルが用意されている。マスタからリードアドレスチャネルを介してスレーブにリードアドレスを含むリクエストが転送されると、これに応答してリードデータチャネルを介してスレーブからマスタにリードデータが転送される。また、AXIプロトコルでは、ライト動作のためのパスとして、ライトアドレスチャネル、ライトデータチャネルおよびライトレスポンスチャネルが用意されている。マスタからライトアドレスチャネルおよびライトデータチャネルを介してスレーブにリクエストが転送されると、これに応答してスレーブにおいてライト動作が行われる。そして、そのライト動作の結果が、ライトレスポンスチャネルを介してスレーブからマスタに転送される。AXIプロトコルにおいては、リクエストの転送処理と、そのリクエストに対応するレスポンスの転送処理とが1つのトランザクションの処理を形成する。1つのトランザクションに含まれるリクエストおよびレスポンスには同じトランザクション識別子IDが付与されるのがAXIプロトコルにおける原則である。マスタは、発行順に完了する必要がない複数のトランザクションのそれぞれに異なるトランザクション識別子IDを付与する。一方、複数のトランザクションを発行順に完了させたい場合、マスタは、それらのトランザクションに同じ値のトランザクション識別子IDを付与する必要がある。具体的には、発行順に完了すべき複数のトランザクションにおけるリクエストのそれぞれに、マスタは同じ値のトランザクション識別子を付与する。そして、マスタは、それらのリクエストに対するレスポンスを、リクエストの発行順に受け付けて順に完了させる。言い換えれば、トランザクション識別子が一致する複数のトランザクションは、互いに依存関係のあるトランザクションからなるグループを形成している。なお、トランザクション識別子IDは、特許請求の範囲に記載のグループ識別子の一例である。リクエスト管理部301は、マスタ111から発行されたリクエストのうち、そのリクエストに先行して発行されたリクエストのスレーブへの出力を待つべきリクエストに、その先行のリクエストを対応付けて管理するものである。以下、先行のリクエストがスレーブへ出力されるまで待機しなければならないリクエストを待機リクエストと称する。また、この待機リクエストが待つべきリクエストを先行リクエストと称する。例えば、待機リクエストは、先行リクエストとの間において依存関係のあるリクエストである。リクエスト管理部301は、リクエストが発行されるたびに、そのリクエストが待機リクエストであるか否かにかかわらず、そのリクエストに自己リクエスト番号SNを付加する。自己リクエスト番号SNは、自己リクエスト番号SNが付加されたリクエスト自身を示す一意な番号である。また、リクエスト管理部301は、リクエストが待機リクエストである場合に先行リクエスト番号PNを待機リクエストに付加することにより待機リクエストに先行リクエストを対応付ける。先行リクエスト番号PNは、先行リクエストを識別するための番号である。この結果、発行されたリクエストが待機リクエストでない場合には自己リクエスト番号SNがリクエストに付加されるが先行リクエスト番号PNは付与されない。一方、待機リクエストである場合には自己リクエスト番号SNに加えて先行リクエスト番号PNがリクエストに付加される。なお、自己リクエスト番号SNは、特許請求の範囲に記載の自己リクエスト識別子の一例である。また、先行リクエスト番号PNは、特許請求の範囲に記載の先行リクエスト識別子の一例である。リクエスト管理部301は、自己リクエスト番号SN、または、自己リクエスト番号SNおよび先行リクエスト番号PNを順序制御信号としてリクエストに付加する。リクエスト管理部301は、順序制御信号を付加した順序制御信号付きリクエストをリクエストデマルチプレクサ411へ信号線305を介して出力する。リクエスト管理部302は、待機リクエストに先行リクエストを対応付けて管理するものである。リクエスト管理部302の構成は、リクエスト管理部301と同様である。バスマトリックス400は、リクエストをスレーブ121または122に転送するとともにレスポンスをマスタ111または112に転送するものである。レスポンスにも、対応するリクエストに付加されていた順序制御信号と同様の順序制御信号が付加されているものとする。バスマトリックス400は、リクエストデマルチプレクサ411および412と、レスポンスマルチプレクサ421および422と、リクエストマルチプレクサ431および432と、レスポンスデマルチプレクサ441および442とを備える。また、バスマトリックス400は、自己リクエスト番号取得部610および620とリクエスト遮断部510、530、550、および、570とを備える。リクエストデマルチプレクサ411は、リクエスト管理部301からのリクエストを宛先に応じて分配するものである。詳細には、リクエストデマルチプレクサ411は、宛先がスレーブ121である場合にリクエストをリクエスト遮断部510へ信号線415を介して出力する。また、リクエストデマルチプレクサ411は、宛先がスレーブ122である場合にリクエストをリクエスト遮断部550へ信号線425を介して出力する。リクエストデマルチプレクサ412は、リクエスト管理部302からのリクエストを宛先に応じて分配するものである。リクエストデマルチプレクサ412の構成は、リクエストデマルチプレクサ411と同様である。リクエスト遮断部510は、マスタ111からの待機リクエストを待機状態にすることにより、待機リクエストのスレーブ121への出力を遮断するものである。具体的には、リクエスト遮断部510は、マスタ111からのリクエストをデマルチプレクサ411から受け取る。リクエストに先行リクエスト番号PNが付加されていた場合、すなわちリクエストが待機リクエストである場合、リクエスト遮断部510は待機リクエストを待機させる。そして、リクエスト遮断部510は、待機リクエストに対応する先行リクエストがスレーブに出力された後に、待機を取り消して待機リクエストをリクエストマルチプレクサ431に信号線511を介して出力する。詳細には、リクエスト遮断部510は、リクエストマルチプレクサ431または432を通過してスレーブ121または122に出力されたリクエストに付加された自己リクエスト番号SNを自己リクエスト番号取得部610から受け取る。そのリクエスト番号RNが先行リクエスト番号PNと一致すれば、リクエスト遮断部510は、その待機リクエストの待機を取り消す。リクエスト遮断部510は、待機状態にないリクエストをリクエストマルチプレクサ431に出力する。リクエスト遮断部530は、マスタ112からの待機リクエストのスレーブ121への出力を遮断するものである。リクエスト遮断部550は、マスタ111からの待機リクエストのスレーブ122への出力を遮断するものである。リクエスト遮断部570は、マスタ112からの待機リクエストのスレーブ122への出力を遮断するものである。リクエスト遮断部530の構成は、リクエスト遮断部510と同様である。リクエスト遮断部550および570の構成は、待機状態にないリクエストをリクエストマルチプレクサ432に出力する点以外は、リクエスト遮断部510と同様である。なお、リクエスト遮断部510、530、550、および、570は、特許請求の範囲に記載のリクエスト待機制御部の一例である。自己リクエスト番号取得部610は、リクエストマルチプレクサ431または432を通過してスレーブ121または122に出力されたリクエストに付加された自己リクエスト番号SNを取得するものである。自己リクエスト番号取得部610は、取得した自己リクエスト番号SNを、そのリクエストの送信元のマスタに応じて分配してリクエスト遮断部510および530に信号線615および616を介して出力する。自己リクエスト番号取得部620は、自己リクエスト番号SNをリクエスト遮断部510および530の代わりにリクエスト遮断部550および570に出力する点以外は、自己リクエスト番号取得部610と同様の構成である。リクエストマルチプレクサ431は、リクエスト遮断部510および530からのリクエストを所定の調停ポリシーに従って調停するものである。調停ポリシーとしては、固定優先度方式やラウンドロビン方式などが採用される。また、リクエストマルチプレクサ431は、マスタのそれぞれに予め割り当てたマスタ番号を、リクエストの送信元のマスタに応じてリクエストに付加する。リクエストマルチプレクサ431は、調停したリクエストをスレーブ121に信号線435を介して出力する。リクエストマルチプレクサ432は、リクエスト遮断部550および570からのリクエストを所定の調停ポリシーに従って調停してスレーブ122に出力するものである。なお、リクエストマルチプレクサ431および432は、特許請求の範囲に記載の調停部の一例である。レスポンスデマルチプレクサ441は、スレーブ121からのレスポンスを宛先に応じて分配するものである。詳細には、レスポンスデマルチプレクサ441は、宛先がマスタ111である場合にレスポンスをレスポンスマルチプレクサ421に出力し、宛先がマスタ112である場合にレスポンスをレスポンスマルチプレクサ422に出力する。レスポンスデマルチプレクサ442は、スレーブ122からのレスポンスを宛先に応じて分配するものである。レスポンスデマルチプレクサ442の構成は、レスポンスデマルチプレクサ441の構成と同様である。レスポンスマルチプレクサ421は、レスポンスデマルチプレクサ441および442からのレスポンスを所定の調停ポリシーに従って調停してマスタ111に出力するものである。レスポンスマルチプレクサ422は、レスポンスデマルチプレクサ441および442からのレスポンスを所定の調停ポリシーに従って調停してマスタ112に出力するものである。[AXIプロトコルにおけるチャネル構成]図2は、AXIプロトコルにおけるリードアドレスチャネルを構成する信号を示す図である。リードアドレスチャネルは、リードアドレスをマスタからスレーブに伝達するためのチャネルである。このリードアドレスチャネルは、リードアドレス識別子、リードアドレス、バースト長、バーストサイズ、バーストタイプ、ロックタイプ、キャッシュタイプ、プロテクションタイプ、リードアドレスバリッド、リードアドレスレディの各信号からなる。これらの信号のうち、リードアドレスレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。リードアドレス識別子ARID[3:0]は、信号のリードアドレスグループを識別するための4ビットのタグである。AXIプロトコルでは、マスタがトランザクションを発行する際に、スレーブに対して順序関係を維持することを要求する場合には、同じ識別子を付与することとされている。換言すれば、識別子が異なるトランザクション間では順序関係が維持される保証はない。リードアドレスARADDR[31:0]は、リード対象となる32ビットのアドレスであり、バースト転送における初期アドレスを示す信号である。バースト長ARLEN[3:0]は、バースト転送のデータ数を示す4ビットの信号である。1から16の何れかのデータ数が4ビットにエンコードされて示される。バーストサイズARSIZE[2:0]は、バースト転送の各回における転送サイズを示す3ビットの信号である。20、21、22、23、24、25、26、27の何れかの転送サイズが3ビットにエンコードされて示される。バーストタイプARBURST[1:0]は、バースト転送のアドレス計算のタイプを示す2ビットの信号である。具体的には、FIFOFirstInFirstOut型、連続アクセス、キャッシュラインの何れかのタイプを指定できるようになっている。ロックタイプARLOCK[1:0]は、アトミックアクセスのための情報を示す2ビットの信号である。具体的には、ノーマルアクセス、排他的アクセス、ロック付きアクセスの何れかのタイプを指定できるようになっている。キャッシュタイプARCACHE[3:0]は、キャッシュメモリ制御に必要な情報を示す4ビットの信号である。具体的には、キャッシュ可能か否か、ライトスルーかライトバックか等の制御情報が示される。プロテクションタイプARPROT[2:0]は、プロテクション制御に必要な情報を示す3ビットの信号である。具体的には、特権アクセス、非セキュアアクセス、インストラクションアクセスの各プロテクションレベルを指定できるようになっている。リードアドレスバリッドARVALIDは、アドレスおよび制御信号の有効性を示すバリッド信号である。リードアドレスレディARREADYは、スレーブがアドレスおよび制御信号を受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、リードアドレスバリッドARVALIDおよびリードアドレスレディARREADYがともにアサートされているときに、アドレスおよび制御信号の転送が行われる。図3は、AXIプロトコルにおけるリードデータチャネルを構成する信号を示す図である。リードデータチャネルは、リードデータをスレーブからマスタに転送するためのチャネルである。このリードデータチャネルは、リード識別子タグ、リードデータ、リードレスポンス、リードラスト、リードバリッド、リードレディの各信号からなる。これらの信号のうち、リードレディのみがマスタからの信号であり、これ以外はスレーブからの信号である。リード識別子タグRID[3:0]は、信号のリードデータグループを識別するための4ビットのタグである。このリード識別子タグRID[3:0]はスレーブにおいて生成されるものであり、同一のトランザクションにおいてリードアドレス識別子ARID[3:0]と一致していなければならない。リードデータRDATA[31:0]は、リードトランザクションによるスレーブ140からのリードデータである。ここでは32ビット幅のリードデータバスを想定したが、RDATAのビット幅はリードデータバス幅に応じて変化する。リードデータバスは、8、16、32、64、128、256、512および1024の何れかのビット幅を有する。リードレスポンスRRESP[1:0]は、リードトランザクションによるデータ転送の状態を示す2ビットの信号である。例えば、リードレスポンスには、リードアクセスの成功または失敗を示す信号が含まれる。リードラストRLASTは、当該データがリードトランザクションにおける最終のデータ転送である旨を示す信号である。リードバリッドRVALIDは、要求されたリードデータの有効性を示すバリッド信号である。リードレディRREADYは、マスタがリードデータを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、リードバリッドRVALIDおよびリードレディRREADYがともにアサートされているときに、リードデータの転送が行われる。図4は、AXIプロトコルにおけるライトアドレスチャネルを構成する信号を示す図である。ライトアドレスチャネルは、ライトアドレスをマスタからスレーブに伝達するためのチャネルである。このライトアドレスチャネルは、ライトアドレス識別子、ライトアドレス、バースト長、バーストサイズ、バーストタイプ、ロックタイプ、キャッシュタイプ、プロテクションタイプ、ライトアドレスバリッド、ライトアドレスレディの各信号からなる。これらの信号のうち、ライトアドレスレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。ライトアドレス識別子AWID[3:0]は、信号のライトアドレスグループを識別するための4ビットのタグである。ライトアドレスAWADDR[31:0]は、ライト対象となる32ビットのアドレスであり、バースト転送における初期アドレスを示す信号である。バースト長AWLEN[3:0]は、バースト転送のデータ数を示す4ビットの信号である。バーストサイズAWSIZE[2:0]は、バースト転送の各回における転送サイズを示す3ビットの信号である。バーストタイプAWBURST[1:0]は、バースト転送のアドレス計算のタイプを示す2ビットの信号である。ロックタイプAWLOCK[1:0]は、アトミックアクセスのための情報を示す2ビットの信号である。キャッシュタイプAWCACHE[3:0]は、キャッシュメモリ制御に必要な情報を示す4ビットの信号である。プロテクションタイプAWPROT[2:0]は、プロテクション制御に必要な情報を示す3ビットの信号である。これらは基本的にリードアドレスチャネルの場合と同様である。ライトアドレスバリッドAWVALIDは、アドレスおよび制御信号の有効性を示すバリッド信号である。ライトアドレスレディAWREADYは、スレーブがアドレスおよび制御信号を受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトアドレスバリッドAWVALIDおよびライトアドレスレディAWREADYがともにアサートされているときに、アドレスおよび制御信号の転送が行われる。図5は、AXIプロトコルにおけるライトデータチャネルを構成する信号を示す図である。ライトデータチャネルは、ライトデータをマスタからスレーブに転送するためのチャネルである。このライトデータチャネルは、ライト識別子タグ、ライトデータ、ライトストローブ、ライトラスト、ライトバリッド、ライトレディの各信号からなる。これらの信号のうち、ライトレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。ライト識別子タグWID[3:0]は、信号のライトデータグループを識別するための4ビットのタグである。このライト識別子タグWID[3:0]は、同一のトランザクションにおいてライトアドレス識別子AWID[3:0]と一致していなければならない。ライトデータWDATA[31:0]は、ライトトランザクションによるスレーブへのライトデータである。ここでは32ビット幅のライトデータバスを想定したが、WDATAのビット幅はリードデータバス幅に応じて変化する。ライトデータバスは、8、16、32、64、128、256、512および1024の何れかのビット幅を有する。ライトストローブWSTRB[3:0]は、スレーブ140のメモリにおいて更新されるべきバイト位置を示す4ビットの信号である。ライトデータバスの8ビット毎にライトストローブWSTRB[3:0]の1ビットが割り当てられる。すなわち、[3:0]の値をiとすると、WSTRB[i]は、WDATA[8×i7:8×i]に対応する。ライトラストWLASTは、当該データがライトトランザクションにおける最終のデータ転送である旨を示す信号である。ライトバリッドWVALIDは、ライトデータの有効性を示すバリッド信号である。ライトレディWREADYは、スレーブがライトデータを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトバリッドWVALIDおよびライトレディWREADYがともにアサートされているときに、ライトデータの転送が行われる。図6は、AXIプロトコルにおけるライトレスポンスチャネルを構成する信号を示す図である。ライトレスポンスチャネルは、ライトトランザクションの結果をスレーブからマスタに伝達するためのチャネルである。このライトレスポンスチャネルは、レスポンス識別子、ライトレスポンス、ライトレスポンスバリッド、レスポンスレディの各信号からなる。これらの信号のうち、レスポンスレディのみがマスタからの信号であり、これ以外はスレーブからの信号である。レスポンス識別子BID[3:0]は、ライトレスポンスを識別するための4ビットのタグである。このレスポンス識別子BID[3:0]は、同一のトランザクションにおいてライトアドレス識別子AWID[3:0]と一致していなければならない。ライトレスポンスBRESP[1:0]は、ライトトランザクションによるデータ転送の状態を示す2ビットの信号である。例えば、ライトレスポンスには、ライトアクセスの成功または失敗を示す信号が含まれる。ライトレスポンスバリッドBVALIDは、ライトレスポンスの有効性を示すバリッド信号である。レスポンスレディBREADYは、マスタがライトレスポンスを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトレスポンスバリッドBVALIDおよびレスポンスレディBREADYがともにアサートされているときに、ライトレスポンスの伝達が行われる。[相互接続装置の構成]図7は、第1の実施の形態における順序制御信号およびリクエストのデータ構造の一例を示す図である。待機リクエストに付加される順序制御信号は、自己リクエスト番号SNおよび先行リクエスト番号PNを含む。待機リクエストでないリクエストに付加される順序制御信号は、自己リクエスト番号SNを含むが、先行リクエスト番号PNを含まない。リクエストは、例えば、リードアドレスリクエストであり、リード識別子タグRID、リードデータRDATA、リードレスポンスRRESP、リードラストRLASTなどの信号を含む。なお、リクエストは、リードアドレスリクエストに限定されず、ライトアドレスリクエストであってもよい。図8は、リクエスト管理部301の一構成例を示すブロック図である。リクエスト管理部301は、先行リクエスト履歴保持部310、順序制御信号付加部320、および、履歴削除部330を備える。リクエスト管理部302の構成は、リクエスト管理部301と同様である。先行リクエスト履歴保持部310は、先行して発行されたリクエストに関する情報の履歴以下、先行リクエスト履歴と称する。を保持するものである。具体的には、先行リクエスト履歴は、トランザクション識別子ID、リクエスト番号RN、および、ラストフラグLFを含む。トランザクション識別子IDは、マスタ111または112がAXIプロトコルに従ってリクエスト発行時に付与したトランザクションIDである。リクエスト番号RNは、リクエストを識別するための番号である。ラストフラグLFは、リクエスト番号RNが、同一のトランザクション識別子IDに対応するリクエストのうち最後に発行されたリクエストに係るリクエスト番号RNであるか否かを示すフラグである。例えば、ラストフラグには、リクエストが最後のリクエストである場合に真の値TTrue、そうでない場合に偽の値FFalseが設定される。なお、リクエスト番号RNは、特許請求の範囲に記載のリクエスト識別子の一例である。順序制御信号付加部320は、順序制御信号を生成してリクエストに付加するものである。具体的には、まず、順序制御信号付加部320は、発行されたリクエストにリクエスト番号RNを付与し、そのリクエストに係るトランザクション識別子IDを取得する。順序制御信号付加部320は、取得したトランザクション識別子IDに基づいて、リクエストが属するグループを特定し、そのグループにおける先行リクエストを特定する。具体的には、順序制御信号付加部320は、信号線313を介して先行リクエスト履歴保持部310にアクセスして、取得したトランザクション識別子IDに係る先行リクエスト履歴が先行リクエスト履歴保持部310に保持されているか否かを判断する。該当する先行リクエスト履歴が1つ以上保持されている場合、順序制御信号付加部320は、それらの先行リクエスト履歴のうち、ラストフラグLFが真の値Tの先行リクエスト履歴におけるリクエスト番号RNを先行リクエスト番号PNとして読み出す。そして、順序制御信号付加部320は、その先行リクエスト履歴のラストフラグLFを偽の値Fに更新する。なお、ライトアドレスリクエストにおけるデータの転送単位であるWriteData-Interleave-Depthが1に設定されている場合について考える。この場合、マスタはトランザクションIDに関わらず、ライトアドレスの発行順にライトデータをスレーブに出力しなければならない。このため、順序制御信号付加部320は、先行リクエスト履歴保持部310において、トランザクションIDに関わらず、最後に発行されたライトアドレスリクエストを先行リクエストとして取得する。また、順序制御信号付加部320は、付与したリクエスト番号RNと、取得したトランザクション識別子IDと、真の値Tに設定したラストフラグLFとを含む先行リクエスト履歴を先行リクエスト履歴保持部310に追加する。順序制御信号付加部320は、リクエストに付与されたリクエスト番号RNを自己リクエスト番号SNとしてリクエストに付加する。順序制御信号付加部320は、先行リクエスト番号PNを読み出していたならば、その先行リクエスト番号PNをリクエストにさらに付加する。順序制御信号付加部320は、自己リクエスト番号SN等を付加したリクエストをリクエストデマルチプレクサ411へ信号線305を介して出力する。履歴削除部330は、バスマトリックス400からスレーブ121または122へリクエストが出力されたときに先行リクエスト履歴保持部310において、そのリクエストの先行リクエスト履歴を削除するものである。詳細には、履歴削除部330は、リクエストマルチプレクサ431または432からスレーブ121または122へ出力されたリクエストを取得する。そして、履歴削除部330は、取得したリクエストに付加された自己リクエスト番号SNにリクエスト番号RNが一致する先行リクエスト履歴を削除する。図9は、先行リクエスト履歴保持部310の一構成例を示す図である。先行リクエスト履歴保持部310は、先行リクエスト履歴を保持するためのエントリENT0乃至15を備える。それぞれのエントリには、有効フラグVと先行リクエスト履歴とが保持される。先行リクエスト履歴は、前述したように、トランザクション識別子ID、リクエスト番号RN、および、ラストフラグLFを含む。有効フラグVは、エントリ内の先行リクエスト履歴が有効な履歴であるか否かを示すフラグである。有効フラグVには、例えば、先行リクエスト履歴が有効である場合に真の値TTrueが設定され、無効である場合に偽の値FFalseが設定される。また、リクエスト番号RNには、例えば、リクエストが発行された順に連番が付与される。例えば、トランザクションIDに0が設定されたリクエストAおよびBが発行され、その後にトランザクションIDに1が設定されたリクエストCおよびDが発行された場合を考える。リクエストAが発行されたとき、先行リクエスト履歴保持部310には、リクエストAの先行リクエスト履歴としてトランザクション識別子ID0、リクエスト番号RN0、および、真の値TのラストフラグLFが保持される。次にリクエストBが発行されたとき、リクエストAの先行リクエスト履歴においてラストフラグLFが偽の値Fに更新される。そして、リクエストBの先行リクエスト履歴としてトランザクション識別子ID0、リクエスト番号RN1、および、真の値TのラストフラグLFが追加される。さらに、リクエストCの先行リクエスト履歴としてトランザクション識別子ID1、リクエスト番号RN2、および、真の値TのラストフラグLFが追加される。リクエストDが発行されたとき、リクエストCの先行リクエスト履歴においてラストフラグLFが偽の値Fに更新される。そして、リクエストDの先行リクエスト履歴としてトランザクション識別子ID1、リクエスト番号RN3、および、真の値TのラストフラグLFが追加される。図10は、第1の実施の形態における順序制御信号付加部320の一構成例を示すブロック図である。順序制御信号付加部320は、コンパレータ321、AND論理積ゲート322、ラストフラグ更新部323、履歴追加部324、自己リクエスト番号付加部325、および、先行リクエスト番号付加部326を備える。コンパレータ321およびANDゲート322は、先行リクエスト履歴保持部310のエントリごとに設けられる。コンパレータ321は、リクエストに含まれるトランザクション識別子IDと、対応するエントリに保持されたトランザクション識別子IDとを比較して一致するか否かを判断するものである。コンパレータ321は、判断結果をANDゲート322に出力する。ANDゲート322は、入力された値の論理積を出力するものである。ANDゲート322には、対応するエントリの有効フラグVおよびラストフラグLFと、対応するコンパレータ321の判断結果とが入力される。ANDゲート322には、これらの入力値の論理積をラストフラグ更新部323に出力する。ラストフラグ更新部323は、先行リクエスト履歴におけるラストフラグLFを更新するものである。具体的には、ラストフラグ更新部323は、エントリごとのANDゲート322のそれぞれの出力値を受け取り、1の出力値があるか否かを判断する。1の出力値があれば、ラストフラグ更新部323は、その出力値に対応するエントリからリクエスト番号RNを読み出し、そのエントリのラストフラグLFの値を偽の値Fに更新する。ラストフラグ更新部323は、読み出したリクエスト番号RNを先行リクエスト番号PNとして先行リクエスト番号付加部326に出力する。つまり、リクエストに係るトランザクション識別子IDに対応するリクエスト番号RNのうち、最後に生成されたリクエスト番号RNが先行リクエスト番号PNとして出力される。履歴追加部324は、先行リクエスト履歴を追加するものである。履歴追加部324は、ラストフラグLFの更新後に、先行リクエスト履歴保持部310内のそれぞれのエントリにおける有効フラグVを読み出して、無効なエントリのうちのいずれかを選択する。履歴追加部324は、選択したエントリに先行リクエスト履歴を追加して、そのエントリの有効フラグを真の値Tに更新する。また、履歴追加部324は、追加した先行リクエスト履歴におけるリクエスト番号RNを自己リクエスト番号SNとして自己リクエスト番号付加部325に出力する。自己リクエスト番号付加部325は、自己リクエスト番号SNをリクエストに付加するものである。自己リクエスト番号付加部325は、自己リクエスト番号SNを付加したリクエストを先行リクエスト番号付加部326に出力する。なお、自己リクエスト番号付加部325は、特許請求の範囲に記載の自己リクエスト識別子付加部の一例である。先行リクエスト番号付加部326は、先行リクエスト番号PNが読み出された場合にリクエストに先行リクエスト番号PNを付加するものである。先行リクエスト番号付加部326は、必要に応じて先行リクエスト番号PNを付加したリクエストをリクエストデマルチプレクサ411に出力する。なお、先行リクエスト番号付加部326は、特許請求の範囲に記載の先行リクエスト識別子付加部の一例である。図11は、第1の実施の形態におけるリクエスト遮断部510の一構成例を示すブロック図である。リクエスト遮断部510は、リクエスト番号一致判断部512、リクエスト遮断判定部521、バッファ522、および、待機解除リクエスト出力部523を備える。バッファ522は、複数のエントリを備え、それらのエントリのそれぞれに有効フラグV、ホールドフラグHF、および、順序制御信号付きリクエストが保持される。バッファ522は、例えばFIFOFirstInFirstOutメモリであり、格納された順にリクエストが読み出される。リクエスト番号一致判断部512は、バッファ522のエントリごとに設けられる。ホールドフラグHFには、例えば、リクエストが待機状態である場合に1の値が設定され、待機が取り消された場合に0の値が設定される。リクエスト遮断判定部521は、リクエストを待機させてリクエストの出力を遮断するか否かを判定するものである。リクエスト遮断判定部521は、リクエストデマルチプレクサ411から順序制御信号付きリクエストを受け取り、有効フラグVが0のエントリにそのリクエストを保持する。このとき、リクエスト遮断判定部521は、リクエストに先行リクエスト番号PNが付加されている場合に、そのリクエストを待機状態HF=1に設定してバッファ522に保持する。リクエストに先行リクエスト番号PNが付加されていない場合にそのリクエストを非待機状態HF=0に設定してバッファ522に保持する。リクエストが保持されたエントリにおいて有効フラグVは1に更新される。リクエスト遮断部530、550、および、570の構成は、リクエスト遮断部510の構成と同様である。リクエスト番号一致判断部512は、自己リクエスト番号取得部610からの自己リクエスト番号SNのいずれかと、対応するエントリにおける待機中のリクエストの先行リクエスト番号PNとが一致するか否かを判断するものである。リクエスト番号一致判断部512は、判断結果に基づいて、対応するエントリにおけるホールドフラグHFを更新する。具体的には、一致する場合にホールドフラグHFが0に更新される。待機解除リクエスト出力部523は、待機が解除されたリクエストを出力するものである。待機解除リクエスト出力部523は、バッファ522に最初に保持された順序制御信号付きリクエストを読み出し、そのホールドフラグHFの値が0すなわち、非待機状態であるか否かを判断する。待機状態が解除されていれば、待機解除リクエスト出力部523は、その順序制御信号付きリクエストをリクエストマルチプレクサ431へ出力して、そのエントリの有効フラグVの値を0に更新する。図12は、第1の実施の形態におけるリクエスト番号一致判断部512の一構成例を示すブロック図である。リクエスト番号一致判断部512は、コンパレータ513乃至516とNOR否定論理和ゲート517とを備える。コンパレータ513乃至516は、自己リクエスト番号RNと先行リクエスト番号PNとを比較して一致するか否かを判断するものである。コンパレータ513には、スレーブ122からのレスポンスに付加された自己リクエスト番号SNと先行リクエスト番号PNとが入力される。コンパレータ514には、スレーブ121からのレスポンスに付加された自己リクエスト番号RNと先行リクエスト番号PNとが入力される。コンパレータ515には、リクエストマルチプレクサ432からのリクエストに付加された自己リクエスト番号RNと先行リクエスト番号PNとが入力される。コンパレータ516には、リクエストマルチプレクサ431からのリクエストに付加された自己リクエスト番号RNと先行リクエスト番号PNとが入力される。コンパレータ513乃至516は、それらの自己リクエスト番号RNと先行リクエスト番号PNとが一致するか否かを示す判断結果をNORゲート517に出力する。NORゲート517は、入力された値の否定論理和を出力するものである。NORゲート517には、コンパレータ513乃至516のそれぞれからの判断結果が入力される。NORゲート517は、それらの入力値の否定論理和をホールドフラグHFとしてバッファ522へ信号線526を介して出力する。この結果、自己リクエスト番号SNのいずれかと先行リクエスト番号PNが一致するのである場合、ホールドフラグに0の値が設定されて待機が取り消される。一方、いずれの自己リクエスト番号SNも先行リクエスト番号PNに一致しない場合は、ホールドフラグに1の値が設定されて待機状態が維持される。図13は、自己リクエスト番号取得部610の一構成例を示すブロック図である。自己リクエスト番号取得部610は、分配器611乃至614を備える。自己リクエスト番号取得部620の構成は、自己リクエスト番号取得部610と同様である。分配器611乃至614は、マスタに応じて自己リクエスト番号SNを分配して出力するものである。詳細には、分配器611には、リクエストマルチプレクサ431からのリクエストに付加されたマスタ番号MNおよび自己リクエスト番号SNが入力される。分配器612には、リクエストマルチプレクサ432からのリクエストに付加されたマスタ番号MNおよび自己リクエスト番号SNが入力される。分配器613には、スレーブ121からのレスポンスに付加されたマスタ番号MNおよび自己リクエスト番号SNが入力される。分配器614には、スレーブ122からのレスポンスに付加されたマスタ番号MNおよび自己リクエスト番号SNが入力される。分配器611乃至614は、入力されたマスタ番号に対応するリクエスト遮断部510または530に自己リクエスト番号SNを出力する。ここで、分配器611乃至614は、スレーブの仕様に応じて有効または無効に設定される。スレーブには、トランザクションIDが異なるリクエストに対して、リクエストを受け取った順にレスポンスを返すスレーブと、リクエストを受け取った順と異なる順序でレスポンスを返しうるスレーブとがある。スレーブ121が受け取った順にレスポンスを返すスレーブであれば、自己リクエスト番号取得部610において分配器611および612のみが有効に設定される。このようなスレーブであれば、リクエストマルチプレクサから先行リクエストが出力されたことにより、待機解除条件が満たされるためである。一方、スレーブ121が、リクエストを受け取った順と異なる順序でレスポンスを返しうるスレーブであれば、自己リクエスト番号取得部610において分配器613および614のみが有効に設定される。このようなスレーブであれば、スレーブ121から先行リクエストに対応するレスポンスが返却されたことにより、待機解除条件が満たされるためである。[相互接続装置の動作]図14は、第1の実施の形態における相互接続装置200の動作を示すフローチャートである。この動作は、例えば、相互接続装置200に電源が投入されたとき、または、マスタ111および112とスレーブ121および122が相互接続装置200に接続されたときに開始される。相互接続装置200は、先行リクエスト履歴保持部310および待機リクエスト保持部524を初期化するステップS905。相互接続装置200は、新規にリクエストが発行されたか否かを判断するステップS910。リクエストが発行されたのであればステップS910:Yes、相互接続装置200は、リクエストに先行リクエストを対応付けて管理するためのリクエスト管理処理を実行するステップS920。そして、相互接続装置200は、待機リクエストを待機させるためのリクエスト待機制御処理を実行するステップS950。相互接続装置200は、リクエストマルチプレクサ431および432において、リクエストを調停して宛先のスレーブに出力するステップS960。リクエストが発行されていない場合ステップS910:No、または、ステップS960の後、相互接続装置200は、ステップS910に戻る。図15は、第1の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。リクエスト管理部301および302は、順序制御信号をリクエストに付加するための順序制御信号付加処理を実行するステップS930。リクエスト管理部301および302は、リクエストマルチプレクサ431または432からスレーブ121または122へリクエストが出力されたか否かを判断するステップS941。リクエストが出力されたのであればステップS941:Yes、リクエスト管理部301および302は、出力されたリクエストの先行リクエスト履歴を先行リクエスト履歴保持部310において削除するステップS942。リクエストが出力されていない場合ステップS941:No、または、ステップS942の後、リクエスト管理部301および302は、リクエスト管理処理を終了する。図16は、第1の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。順序制御信号付加部320は、新規のリクエストのトランザクション識別子IDを取得するステップS931。順序制御信号付加部320は、トランザクション識別子IDが一致する先行リクエスト履歴があるか否かを判断するステップS932。該当する先行リクエスト履歴が1つ以上あればステップS932:Yes、順序制御信号付加部320は、それらの先行リクエスト履歴のうち最後のリクエストのリクエスト番号RNを先行リクエスト番号PNとして取得するステップS933。順序制御信号付加部320は、最後のリクエスト番号RNを含む先行リクエスト履歴においてラストフラグLFを更新するステップS934。該当する先行リクエスト履歴がない場合ステップS932:No、または、ステップS934の後、順序制御信号付加部320は、新規のリクエストの先行リクエスト履歴を先行リクエスト履歴保持部310に追加するステップS935。順序制御信号付加部320は、先行リクエスト番号を取得しているか否かを判断するステップS936。先行リクエスト番号を取得している場合ステップS936:Yes、順序制御信号付加部320は、リクエスト番号RNおよび先行リクエスト番号PNを含む順序制御信号をリクエストに付加するステップS937。先行リクエスト番号を取得していない場合ステップS936:No、順序制御信号付加部320は、リクエスト番号RNを含む順序制御信号をリクエストに付加するステップS938。ステップS937またはS938の後、順序制御信号付加部320は、順序制御信号付加処理を終了する。図17は、第1の実施の形態におけるリクエスト待機制御処理を示すフローチャートである。リクエスト遮断部510は、リクエストに先行リクエスト番号PNが付加されているか否かを判断するステップS951。リクエストに先行リクエスト番号PNが付加されていればステップS951:Yes、リクエスト遮断部510は、そのリクエストを待機状態にして保持するステップS952。リクエスト遮断部510は、スレーブ121または122に出力されたリクエストの自己リクエスト番号SNを取得するステップS953。リクエスト遮断部510は、自己リクエスト番号SNが、待機中のリクエストが待っている先行リクエスト番号PNであるか否かを判断するステップS954。自己リクエスト番号SNが先行リクエスト番号PNである場合ステップS954:Yes、リクエスト遮断部510は、待機中のリクエストの待機を解除するステップS955。リクエストに先行リクエスト番号PNが付加されていないステップS951:No、または、ステップS955の後、リクエスト遮断部510は、最も古いリクエストが待機状態になければ、そのリクエストをマルチプレクサへ出力するステップS956。ステップS956の後、リクエスト遮断部510は、リクエスト待機制御処理を終了する。リクエスト遮断部530、550、および、570の動作は、リクエスト遮断部510の動作と同様である。図18は、第1の実施の形態におけるデッドロックが回避された状態の情報処理システムの一例を示す図である。マスタ111がスレーブリクエストA、Bの順にリクエストを発行し、マスタ112がリクエストC、Dの順にリクエストを発行したものとする。リクエストAおよびDはスレーブ121に対して発行され、リクエストBおよびCはスレーブ122に対して発行されたものとする。リクエストAおよびBには、ともにトランザクション識別子ID0が付与され、これらのリクエスト間には依存関係があるものとする。また、リクエストCおよびDには、ともにトランザクション識別子ID1が付与され、これらのリクエスト間にも依存関係があるものとする。一方、トランザクション識別子IDの値が異なるため、リクエストAおよびBと、リクエストCおよびDとの間には、依存関係がない。この場合、相互接続装置200がリクエストを必要に応じて待機させないと、デッドロックが生じるおそれがある。例えば、調停の結果、リクエストBおよびDが、先行のリクエストAおよびCよりも先にスレーブ121および122に出力されると、それぞれのスレーブは、最初にリクエストBおよびDに対するレスポンスを返そうとする。一方、マスタ111および112は、先行のリクエストAおよびCに対するレスポンスが先に返却されることを期待しているため、デッドロックが生じてしまう。しかし、相互接続装置200においてリクエスト遮断部530は、リクエストDを受け取ると、そのリクエストDを待機させて、先行するリクエストCがスレーブ122に出力されたときに待機を取り消す。また、リクエスト遮断部550は、リクエストBを受け取ると、そのリクエストBを待機させて、先行するリクエストAがスレーブ121に出力されたときに待機を取り消す。このため、リクエストBおよびDが、リクエストAおよびCよりも先にスレーブ121および122に出力されることが防止され、デッドロックが回避される。また、相互接続装置200はリクエストがスレーブ121または122に出力された時点で待機を取り消しているため、その後にレスポンスが返却されたときに待機を取り消す構成よりも、レイテンシが低減する。図19は、第1の実施の形態における依存関係有方向グラフの一例を示す図である。依存関係有方向グラフは、リクエスト間の依存関係と、リクエストに対するレスポンスの返却順序とを図示したものである。依存関係有方向グラフに閉ループが生じる場合、デッドロックが生じることを意味する。図19aは、リクエストを待機させない場合の依存関係有方向グラフの一例を示す図である。図19aにおいて、点線の有向線分701は、リクエストA、B間の依存関係を示すものである。点線の有向線分702は、リクエストC、D間の依存関係を示すものである。有向線分701および702の始点は、依存先であり、終点は依存元である。有向線分701および702は、リクエストBがAに依存し、リクエストDがCに依存していることを示している。また、実線の有向線分703は、リクエストA、Dに対するレスポンスの返却順序を示すものである。実線の有向線分704は、リクエストB、Cに対するレスポンスの返却順序を示すものである。有向線分703および704の始点は、最初に返却されるレスポンスであり、終点は、次に返却されるレスポンスである。有向線分703および704は、リクエストBおよびDに対するレスポンスの次に、リクエストAおよびCに対するレスポンスが返却されることを示している。このように、リクエストBおよびDが先に返却されると、依存関係有方向グラフに閉ループが生じる。すなわち、デッドロックが生じてしまう。図19bは、リクエストを待機させた場合の依存関係有方向グラフの一例を示す図である。図19bにおいて、実線の有向線分705および706は、リクエストAおよびCに対するレスポンスの次に、リクエストBおよびDに対するレスポンスが返却されることを示している。これは、リクエストBおよびDを相互接続装置200が待機させたためである。このように、リクエストAおよびCが先に返却されると、依存関係有方向グラフに閉ループが生じない。すなわち、デッドロックが回避される。このように第1の実施の形態によれば、リクエスト管理部301および302は、発行されたリクエストが待機リクエストである場合には待機リクエストに先行リクエストを対応付けて管理する。リクエストマルチプレクサ431および432は、マスタ111および112から発行された複数のリクエストを調停して調停したリクエストを宛先のスレーブ121または122に出力する。リクエスト遮断部510、530、550、および、570は、待機リクエストを待機させる。そして、それぞれのリクエスト遮断部は、待機リクエストに対応する先行リクエストがスレーブ121および122のいずれかに出力された後に待機リクエストをリクエストマルチプレクサ431または432へ出力する。これにより、先行リクエストがスレーブ121または122に出力されるまで、待機リクエストが待機するため、デッドロックが回避される。また、先行リクエストが出力された時点、または、先行リクエストに対するレスポンスがスレーブから出力された時点に、待機リクエストの待機が取り消される。これらの時点において既にデッドロックが回避されているため、デッドロックが回避された時点で直ちに待機が取り消される。このため、その後にレスポンスがマスタに返却されたときに待機が取り消される構成と比較して、トランザクション処理におけるレイテンシが低下する。<2.第2の実施の形態>[相互接続装置の構成例]図20は、第2の実施の形態における先行リクエスト履歴保持部311の一構成例を示す図である。先行リクエスト履歴保持部311は、ラストフラグLFを保持しない点において第1の実施の形態における先行リクエスト履歴保持部310と異なる。第2の実施の形態における相互接続装置200においては、先行リクエスト履歴は、リクエストの発行順に従って、エントリの先頭から順に配列される。そして、相互接続装置200は、新たに発行されたリクエストとトランザクションIDが一致し、最も遅くに保持された先行リクエスト履歴におけるリクエスト番号RNを先行リクエスト番号PNとして取得する。また、相互接続装置200は、削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があれば、それらの先行リクエスト履歴を上詰めにして先行リクエスト履歴の並び順をリクエストの発行順に一致させる。[相互接続装置の動作例]図21は、第2の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。第2の実施の形態におけるリクエスト管理処理は、ステップS942の代わりにステップS943乃至S945を実行する点において第1の実施の形態のリクエスト管理処理と異なる。リクエストが出力されたのであればステップS941:Yes、リクエスト管理部301および302は、出力されたリクエストの先行リクエスト履歴を先行リクエスト履歴保持部311において削除するステップS943。リクエスト管理部301および302は、削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があるか否かを判断するステップS944。削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があればステップS944:Yes、リクエスト管理部301および302は、それらの先行リクエスト履歴を上詰めにするステップS945。削除した先行リクエスト履歴以降に有効な先行リクエスト履歴がない場合ステップS944:No、またはステップS945の後、リクエスト管理部301および302は、リクエスト管理処理を終了する。図22は、第2の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。第2の実施の形態の順序制御信号付加処理は、ステップS934およびS935の代わりにステップS939を実行する点において第1の実施の形態の順序制御信号付加処理と異なる。該当する先行リクエスト履歴があればステップS932:Yes、順序制御信号付加部320は、先行リクエスト番号を取得するステップS933。該当する先行リクエスト履歴がない場合ステップS932:No、または、ステップS933の後、順序制御信号付加部320は、新規のリクエストの先行リクエスト履歴を先行リクエスト履歴保持部311に追加するステップS939。このように第2の実施の形態によれば、先行リクエスト履歴保持部311においてラストフラグLFを保持しないため、先行リクエスト履歴保持部311の容量を削減することができる。なお、上述の実施の形態は本技術を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本技術の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本技術は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、CDCompactDisc、MDMiniDisc、DVDDigitalVersatileDisk、メモリカード、ブルーレイディスクBlurayDisc登録商標等を用いることができる。なお、本技術は以下のような構成もとることができる。1複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理部と、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停部と、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御部とを具備する相互接続装置。2前記リクエスト待機制御部は、前記先行リクエストが前記複数の応答デバイスのいずれかに出力されたときに前記待機リクエストを前記調停部へ出力する前記1記載の相互接続装置。3前記リクエスト待機制御部は、前記先行リクエストに対するレスポンスが前記複数の応答デバイスのうちのいずれかから出力されたときに前記待機リクエストを前記調停部へ出力する前記1記載の相互接続装置。4前記リクエスト管理部は、前記待機リクエストに前記先行リクエストを識別するための先行リクエスト識別子を生成して前記待機リクエストに付加することにより当該待機リクエストに前記先行リクエストを対応付け、前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に係る前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する前記1乃至3のいずれかに記載の相互接続装置。5前記リクエスト管理部は、前記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として前記リクエストに付加する自己リクエスト識別子付加部と、前記自己リクエスト識別子が付加された前記リクエストが前記待機リクエストである場合には前記先行リクエストに該当する前記リクエストについて生成されていた前記リクエスト識別子を前記先行リクエスト識別子として前記待機リクエストに付加する先行リクエスト識別子付加部とを備え、前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に一致する前記自己リクエスト識別子が付加された前記リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する前記4記載の相互接続装置。6前記リクエスト管理部は、前記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る前記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、前記先行リクエスト識別子付加部は、前記グループ識別子に基づいて前記待機リクエストが属する前記グループを特定して当該特定したグループにおいて前記先行リクエストを特定する前記5記載の相互接続装置。7前記リクエスト管理部は、前記リクエストが前記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された前記自己リクエスト識別子に一致する前記リクエスト識別子を前記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備える前記5または6記載の相互接続装置。8前記リクエスト識別子保持部は、前記リクエストが属する前記グループにおいて前記リクエストが最後に発行されたか否かを示すラストフラグを前記リクエストごとにさらに保持し、前記先行リクエスト付加部は、前記特定したグループにおいて前記待機リクエストを除き最後に発行されたリクエストを前記ラストフラグに基づいて前記先行リクエストとして特定する前記6記載の相互接続装置。9リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順とを具備する相互接続装置の制御方法。10リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順とをコンピュータに実行させるためのプログラム。