JP2013037459A - 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム - Google Patents

相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム Download PDF

Info

Publication number
JP2013037459A
JP2013037459A JP2011171538A JP2011171538A JP2013037459A JP 2013037459 A JP2013037459 A JP 2013037459A JP 2011171538 A JP2011171538 A JP 2011171538A JP 2011171538 A JP2011171538 A JP 2011171538A JP 2013037459 A JP2013037459 A JP 2013037459A
Authority
JP
Japan
Prior art keywords
request
standby
identifier
unit
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
JP2011171538A
Other languages
English (en)
Inventor
Shota Watanabe
翔太 渡邊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2011171538A priority Critical patent/JP2013037459A/ja
Publication of JP2013037459A publication Critical patent/JP2013037459A/ja
Withdrawn legal-status Critical Current

Links

Images

Landscapes

  • Multi Processors (AREA)
  • Information Transfer Systems (AREA)

Abstract

【課題】相互接続装置においてデッドロックを回避しつつ、レイテンシを低減する。
【解決手段】リクエスト管理部は、複数のマスタのいずれかから複数のスレーブのいずれかに対して発行されたリクエストがそのリクエストに先行して発行された先行リクエストの複数のスレーブのいずれかへの出力を待つべき待機リクエストである場合にはその待機リクエストに先行リクエストを対応付けて管理する。調停部は、複数のマスタから発行された複数のリクエストを調停して調停したリクエストを複数のスレーブのうち調停したリクエストの宛先である応答デバイスに出力する。リクエスト待機制御部は、待機リクエストを待機させて、その待機リクエストに対応する先行リクエストが複数のスレーブのいずれかに出力された後に待機リクエストを調停部へ出力する。
【選択図】図１

Description

本技術は、相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラムに関する。詳しくは、リクエストおよびレスポンスを転送する相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラムに関する。
相互接続装置（インターコネクト）に複数の接続機器が接続された情報処理システムでは、相互接続装置を介して接続機器間でデータ転送が行われる。相互接続装置としては、例えば、バスやブリッジなどが想定される。相互接続装置においてデータ転送を主導する接続機器はマスタと呼ばれ、受動的に動作する接続機器はスレーブと呼ばれる。マスタとなる接続機器としては、例えばプロセッサが想定される。スレーブとなる接続機器としては、例えばメモリが想定される。
このような情報処理システムにおいては、データ転送のための一連の動作（トランザクション）のうち、データ転送の要求と実際のデータ転送とをそれぞれ独立して制御することにより、転送効率を向上させることができる。このような制御方式は、スプリットトランザクションと呼ばれる。一方、スプリットトランザクションを許容した場合、マスタが複数のスレーブに対して同時期に依存関係のあるトランザクションを発行すると、データ転送の要求（リクエスト）とデータ転送（レスポンス）との間においてデッドロックが生じるおそれがある。
例えば、相互接続装置にマスタＭ１およびＭ２とスレーブＳ１およびＳ２とが接続されているシステムを想定する。マスタＭ１がスレーブＳ１、Ｓ２に対して順に依存関係のあるリクエストを発行し、一方、マスタＭ２はスレーブＳ２、Ｓ１に対して順に依存関係のあるリクエストを発行した場合を考える。ここで、「依存関係のある」とは、リクエストに対応するデータ（レスポンス）がリクエストの発行の順序と同順で返却されることを発行元のマスタが期待していることを意味する。スレーブＳ１およびＳ２が受け取ったリクエストは、以下のように表現される。
Ｓ１ : Ｍ１1，Ｍ２2
Ｓ２ : Ｍ２1，Ｍ１2
ここで添え字の番号は、マスタが期待するレスポンスの返却順序を示す。例えば、Ｍ１2は「マスタＭ１が発行したリクエストであって、このリクエストに対応するレスポンスの返却が２番目であるとこをマスタＭ１が期待している」ことを意味する。つまり、Ｍ１1、Ｍ１2の順序で、それらに対応するレスポンスを受け取ることをマスタＭ１が期待していることが示されている。
このとき、スレーブＳ１およびＳ２が、それぞれ１番目のリクエストに対するレスポンスを先に返却すれば、デッドロックは起こらない。一方、相互接続装置がスレーブにリクエストを転送する順序がリクエストの発行順と同一でない場合、スレーブがリクエストの発行順と異なる順序でレスポンスを返却することがある。リクエストの転送の順序が発行順と同一にならないのは、同時期に同一のスレーブに対して発行された複数のリクエストを相互接続装置が調停しており、その調停の結果によっては後から発行されたリクエストを先に転送することがあるためである。
例えば、相互接続装置がＭ２2およびＭ１2を転送した後にＭ２1およびＭ１1を転送し、スレーブがリクエストを受け取った順にレスポンスを返却しようとした場合を考える。この場合、マスタＭ１およびＭ２はスレーブＳ１およびＳ２が返却しようとするレスポンスを受け取ることができなくなってしまう。すなわち、マスタ側が最初に返却されることを期待しているのはそれぞれＭ１1およびＭ２1に対するレスポンスであるため、スレーブが最初に返却しようとしているＭ１2およびＭ２2に対するレスポンスを受け取ることができない。このように、相互接続装置が発行順と異なる順序でリクエストを転送した場合、デッドロックが発生するおそれがある。
デッドロックを回避するために、マスタと相互接続装置との間にデッドロック予測論理（Deadlock Prediction Logic）を設けるシステムが提案されている（例えば、特許文献１参照。）。このデッドロック予測論理は、マスタがリクエストを発行したときに、デッドロックの危険性があるか否かを判断し、危険性があると判断すると、マスタから相互接続装置へのリクエストの出力を待機させる。そして、デッドロック予測論理は、デッドロックの危険性がなくなると、待機を取り消して待機中のリクエストを相互接続装置へ出力する。
例えば、リクエストＭ２2およびＭ１2が発行されると、デッドロック予測論理は、デッドロックの危険性があると判断して、それらのリクエストを待機させる。そして、リクエストＭ２1およびＭ１1に対応するレスポンスがマスタに返却されると、デッドロックの危険性がなくなったと判断して、待機を取り消してリクエストＭ２2およびＭ１2を相互接続装置に出力させる。これにより、デッドロックが回避される。
米国特許第７２１９１７８号明細書
しかしながら、上述の従来技術では、トランザクション処理におけるレイテンシが増大するおそれがある。上述のデッドロック予測論理は、待機中のリクエストＭ２2およびＭ１2の１つ前のリクエストＭ２1およびＭ１1に対するレスポンスが相互接続装置からマスタに返却されたときにデッドロックが回避されたと判断して待機を取り消す。ここで、相互接続装置が発行順にリクエストのそれぞれをスレーブへ転送し、スレーブがリクエストを受け取った順にレスポンスを返却した場合を考える。この場合、先行のリクエストＭ２1およびＭ１1がスレーブへ出力された時点で既にデッドロックは回避されている。しかるに、この場合であっても、デッドロック予測論理は、先行のリクエストＭ２１およびＭ１１に対するレスポンスがマスタに返却されるまでは待機を取り消さない。この結果、リクエストが発行順にスレーブに転送された場合において、先行のリクエストに対するレスポンスが返却されるまでの間、待機の取り消しが遅延してしまう。デッドロックが生じうるリクエストの発行のたびに待機の取り消しが遅延して、トランザクション処理の遅延が増大してしまうおそれがある。
本技術はこのような状況に鑑みて生み出されたものであり、相互接続装置においてデッドロックを回避しつつ、レイテンシを低減することを目的とする。
本技術は、上述の問題点を解消するためになされたものであり、その第１の側面は、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの上記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに上記先行リクエストを対応付けて管理するリクエスト管理部と、上記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを上記複数の応答デバイスのうち上記調停したリクエストの宛先である応答デバイスに出力する調停部と、上記待機リクエストを待機させて、当該待機リクエストに対応する上記先行リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力するリクエスト待機制御部とを具備する相互接続装置、および、その制御方法ならびに当該方法をコンピュータに実行させるためのプログラムである。これにより、先行リクエストが複数の応答デバイスのいずれかに出力されるまで待機リクエストが待機するという作用をもたらす。
また、この第１の側面において、上記リクエスト待機制御部は、上記先行リクエストが上記複数の応答デバイスのいずれかに出力されたときに上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエストが複数の応答デバイスのいずれかに出力されたときに待機リクエストが出力されるという作用をもたらす。
また、この第１の側面において、上記リクエスト待機制御部は、上記先行リクエストに対するレスポンスが上記複数の応答デバイスのうちのいずれかから出力されたときに上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエストに対するレスポンスが複数の応答デバイスのうちのいずれかから出力されたときに待機リクエストが出力されるという作用をもたらす。
また、この第１の側面において、上記リクエスト管理部は、上記待機リクエストに上記先行リクエストを識別するための先行リクエスト識別子を生成して上記待機リクエストに付加することにより当該待機リクエストに上記先行リクエストを対応付け、上記リクエスト待機制御部は、上記待機リクエストに付加された上記先行リクエスト識別子の示す上記先行リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力してもよい。これにより、待機リクエストに先行リクエスト識別子が付加され、その先行リクエスト識別子に係る先行リクエストが複数の応答デバイスのいずれかに出力された後に待機リクエストが調停部へ出力されるという作用をもたらす。
また、この第１の側面において、上記リクエスト管理部は、上記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として上記リクエストに付加する自己リクエスト識別子付加部と、上記自己リクエスト識別子が付加された上記リクエストが上記待機リクエストである場合には上記先行リクエストに該当する上記リクエストについて生成されていた上記リクエスト識別子を上記先行リクエスト識別子として上記待機リクエストに付加する先行リクエスト識別子付加部とを備え、上記リクエスト待機制御部は、上記待機リクエストに付加された上記先行リクエスト識別子に一致する上記自己リクエスト識別子が付加された上記リクエストが上記複数の応答デバイスのいずれかに出力された後に上記待機リクエストを上記調停部へ出力してもよい。これにより、先行リクエスト識別子および自己リクエスト識別子が待機リクエストに付加され、その先行リクエスト識別子に一致する自己リクエスト識別子が付加されたリクエストが複数の応答デバイスのいずれかに出力された後に待機リクエストが上記調停部へ出力されるという作用をもたらす。
また、この第１の側面において、上記リクエスト管理部は、上記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る上記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、上記先行リクエスト識別子付加部は、上記グループ識別子に基づいて上記待機リクエストが属する上記グループを特定して当該特定したグループにおいて上記先行リクエストを特定してもよい。これにより、グループ識別子に基づいて待機リクエストが属するグループが特定され、そのグループにおいて先行リクエストが特定されるという作用をもたらす。
また、この第１の側面において、上記リクエスト管理部は、上記リクエストが上記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された上記自己リクエスト識別子に一致する上記リクエスト識別子を上記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備えてもよい。これにより、複数の応答デバイスのいずれかに出力されたリクエストに付加された自己リクエスト識別子に一致するリクエスト識別子がリクエスト識別子保持部から削除されるという作用をもたらす。
また、この第１の側面において、上記リクエスト識別子保持部は、上記リクエストが属する上記グループにおいて上記リクエストが最後に発行されたか否かを示すラストフラグを上記リクエストごとにさらに保持し、上記先行リクエスト付加部は、上記特定したグループにおいて上記待機リクエストを除き最後に発行されたリクエストを上記ラストフラグに基づいて上記先行リクエストとして特定してもよい。これにより、特定されたグループにおいて待機リクエストを除き最後に発行されたリクエストが先行リクエストとして特定されるという作用をもたらす。
本技術によれば、相互接続装置においてデッドロックが回避され、トランザクション処理のレイテンシが低減するという優れた効果を奏し得る。
第１の実施の形態における情報処理システムの一構成例を示すブロック図である。 ＡＸＩプロトコルにおけるリードアドレスチャネルを構成する信号を示す図である。 ＡＸＩプロトコルにおけるリードデータチャネルを構成する信号を示す図である。 ＡＸＩプロトコルにおけるライトアドレスチャネルを構成する信号を示す図である。 ＡＸＩプロトコルにおけるライトデータチャネルを構成する信号を示す図である。 ＡＸＩプロトコルにおけるライトレスポンスチャネルを構成する信号を示す図である。 第１の実施の形態における順序制御信号およびリクエストのデータ構造の一例を示す図である。 第１の実施の形態におけるリクエスト管理部の一構成例を示すブロック図である。 第１の実施の形態における先行リクエスト履歴保持部の一構成例を示す図である。 第１の実施の形態における順序制御信号付加部の一構成例を示すブロック図である。 第１の実施の形態におけるリクエスト遮断部の一構成例を示すブロック図である。 第１の実施の形態におけるリクエスト番号一致判断部の一構成例を示すブロック図である。 第１の実施の形態における自己リクエスト番号取得部の一構成例を示すブロック図である。 第１の実施の形態における相互接続装置の動作の一例を示すフローチャートである。 第１の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。 第１の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。 第１の実施の形態におけるリクエスト待機制御処理の一例を示すフローチャートである。 第１の実施の形態におけるデッドロックが回避された状態の情報処理システムの一例を示す図である。 第１の実施の形態における依存関係有方向グラフの一例を示す図である。 第２の実施の形態に先行リクエスト履歴保持部の一構成例を示す図である。 第２の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。 第２の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。
以下、本技術を実施するための形態（以下、実施の形態と称する）について説明する。説明は以下の順序により行う。
１．第１の実施の形態（順序制御信号をリクエストに付加する例）
２．第２の実施の形態（先行リクエスト履歴保持部にラストフラグを保持しない例）
＜１．第１の実施の形態＞
［情報処理システムの構成］
図１は、本発明の第１の実施の形態における情報処理システムの全体図の一例である。情報処理システムは、マスタ１１１および１１２と、スレーブ１２１および１２２と、相互接続装置２００とを備える。マスタ１１１および１１２とスレーブ１２１および１２２は相互接続装置２００に接続されている。
マスタ１１１および１１２はデータ転送を主導する接続機器であり、トランザクション処理においてリクエストを発行して相互接続装置２００に信号線１１５および１１６を介して出力する。マスタ１１１および１１２としては、例えばプロセッサが想定される。スレーブ１２１および１２２は受動的に動作する接続機器であり、受け取ったリクエストに対するレスポンスを相互接続装置２００に信号線１２５および１２６を介して出力する。スレーブ１２１および１２２としては、例えばメモリが想定される。
なお、マスタ１１１および１１２は、特許請求の範囲に記載の要求デバイスの一例である。スレーブ１２１および１２２は、特許請求の範囲に記載の応答デバイスの一例である。
また、相互接続装置２００に２台のマスタ（１１１および１１２）を接続する構成としているが、相互接続装置２００にマスタを３台以上接続してもよい。スレーブも同様に相互接続装置２００に３台以上接続してもよい。
相互接続装置２００は、スプリットトランザクションを許容する所定のプロトコルに従ってマスタおよびスレーブ間においてデータを転送するものである。相互接続装置２００は、リクエスト管理部３０１および３０２とバスマトリックス４００とを備える。相互接続装置２００においては、スプリットトランザクションを許容するプロトコルとして、例えば、ＡＸＩ（Advanced eXtensible Interface）プロトコルが用いられる。
ここで、ＡＸＩプロトコルでは、リード動作のためのパスとして、リードアドレスチャネルおよびリードデータチャネルが用意されている。マスタからリードアドレスチャネルを介してスレーブにリードアドレスを含むリクエストが転送されると、これに応答してリードデータチャネルを介してスレーブからマスタにリードデータが転送される。また、ＡＸＩプロトコルでは、ライト動作のためのパスとして、ライトアドレスチャネル、ライトデータチャネルおよびライトレスポンスチャネルが用意されている。マスタからライトアドレスチャネルおよびライトデータチャネルを介してスレーブにリクエストが転送されると、これに応答してスレーブにおいてライト動作が行われる。そして、そのライト動作の結果が、ライトレスポンスチャネルを介してスレーブからマスタに転送される。
ＡＸＩプロトコルにおいては、リクエストの転送処理と、そのリクエストに対応するレスポンスの転送処理とが１つのトランザクションの処理を形成する。１つのトランザクションに含まれるリクエストおよびレスポンスには同じトランザクション識別子ＩＤが付与されるのがＡＸＩプロトコルにおける原則である。マスタは、発行順に完了する必要がない複数のトランザクションのそれぞれに異なるトランザクション識別子ＩＤを付与する。一方、複数のトランザクションを発行順に完了させたい場合、マスタは、それらのトランザクションに同じ値のトランザクション識別子ＩＤを付与する必要がある。具体的には、発行順に完了すべき複数のトランザクションにおけるリクエストのそれぞれに、マスタは同じ値のトランザクション識別子を付与する。そして、マスタは、それらのリクエストに対するレスポンスを、リクエストの発行順に受け付けて順に完了させる。言い換えれば、トランザクション識別子が一致する複数のトランザクションは、互いに依存関係のあるトランザクションからなるグループを形成している。なお、トランザクション識別子ＩＤは、特許請求の範囲に記載のグループ識別子の一例である。
リクエスト管理部３０１は、マスタ１１１から発行されたリクエストのうち、そのリクエストに先行して発行されたリクエストのスレーブへの出力を待つべきリクエストに、その先行のリクエストを対応付けて管理するものである。以下、先行のリクエストがスレーブへ出力されるまで待機しなければならないリクエストを「待機リクエスト」と称する。また、この待機リクエストが待つべきリクエストを「先行リクエスト」と称する。例えば、待機リクエストは、先行リクエストとの間において依存関係のあるリクエストである。
リクエスト管理部３０１は、リクエストが発行されるたびに、そのリクエストが待機リクエストであるか否かにかかわらず、そのリクエストに自己リクエスト番号ＳＮを付加する。自己リクエスト番号ＳＮは、自己リクエスト番号ＳＮが付加されたリクエスト自身を示す一意な番号である。また、リクエスト管理部３０１は、リクエストが待機リクエストである場合に先行リクエスト番号ＰＮを待機リクエストに付加することにより待機リクエストに先行リクエストを対応付ける。先行リクエスト番号ＰＮは、先行リクエストを識別するための番号である。この結果、発行されたリクエストが待機リクエストでない場合には自己リクエスト番号ＳＮがリクエストに付加されるが先行リクエスト番号ＰＮは付与されない。一方、待機リクエストである場合には自己リクエスト番号ＳＮに加えて先行リクエスト番号ＰＮがリクエストに付加される。なお、自己リクエスト番号ＳＮは、特許請求の範囲に記載の自己リクエスト識別子の一例である。また、先行リクエスト番号ＰＮは、特許請求の範囲に記載の先行リクエスト識別子の一例である。
リクエスト管理部３０１は、自己リクエスト番号ＳＮ、または、自己リクエスト番号ＳＮおよび先行リクエスト番号ＰＮを順序制御信号としてリクエストに付加する。リクエスト管理部３０１は、順序制御信号を付加した順序制御信号付きリクエストをリクエストデマルチプレクサ４１１へ信号線３０５を介して出力する。
リクエスト管理部３０２は、待機リクエストに先行リクエストを対応付けて管理するものである。リクエスト管理部３０２の構成は、リクエスト管理部３０１と同様である。
バスマトリックス４００は、リクエストをスレーブ１２１または１２２に転送するとともにレスポンスをマスタ１１１または１１２に転送するものである。レスポンスにも、対応するリクエストに付加されていた順序制御信号と同様の順序制御信号が付加されているものとする。バスマトリックス４００は、リクエストデマルチプレクサ４１１および４１２と、レスポンスマルチプレクサ４２１および４２２と、リクエストマルチプレクサ４３１および４３２と、レスポンスデマルチプレクサ４４１および４４２とを備える。また、バスマトリックス４００は、自己リクエスト番号取得部６１０および６２０とリクエスト遮断部５１０、５３０、５５０、および、５７０とを備える。
リクエストデマルチプレクサ４１１は、リクエスト管理部３０１からのリクエストを宛先に応じて分配するものである。詳細には、リクエストデマルチプレクサ４１１は、宛先がスレーブ１２１である場合にリクエストをリクエスト遮断部５１０へ信号線４１５を介して出力する。また、リクエストデマルチプレクサ４１１は、宛先がスレーブ１２２である場合にリクエストをリクエスト遮断部５５０へ信号線４２５を介して出力する。リクエストデマルチプレクサ４１２は、リクエスト管理部３０２からのリクエストを宛先に応じて分配するものである。リクエストデマルチプレクサ４１２の構成は、リクエストデマルチプレクサ４１１と同様である。
リクエスト遮断部５１０は、マスタ１１１からの待機リクエストを待機状態にすることにより、待機リクエストのスレーブ１２１への出力を遮断するものである。具体的には、リクエスト遮断部５１０は、マスタ１１１からのリクエストをデマルチプレクサ４１１から受け取る。リクエストに先行リクエスト番号ＰＮが付加されていた場合、すなわちリクエストが待機リクエストである場合、リクエスト遮断部５１０は待機リクエストを待機させる。
そして、リクエスト遮断部５１０は、待機リクエストに対応する先行リクエストがスレーブに出力された後に、待機を取り消して待機リクエストをリクエストマルチプレクサ４３１に信号線５１１を介して出力する。詳細には、リクエスト遮断部５１０は、リクエストマルチプレクサ４３１または４３２を通過してスレーブ１２１または１２２に出力されたリクエストに付加された自己リクエスト番号ＳＮを自己リクエスト番号取得部６１０から受け取る。そのリクエスト番号ＲＮが先行リクエスト番号ＰＮと一致すれば、リクエスト遮断部５１０は、その待機リクエストの待機を取り消す。リクエスト遮断部５１０は、待機状態にないリクエストをリクエストマルチプレクサ４３１に出力する。
リクエスト遮断部５３０は、マスタ１１２からの待機リクエストのスレーブ１２１への出力を遮断するものである。リクエスト遮断部５５０は、マスタ１１１からの待機リクエストのスレーブ１２２への出力を遮断するものである。リクエスト遮断部５７０は、マスタ１１２からの待機リクエストのスレーブ１２２への出力を遮断するものである。リクエスト遮断部５３０の構成は、リクエスト遮断部５１０と同様である。リクエスト遮断部５５０および５７０の構成は、待機状態にないリクエストをリクエストマルチプレクサ４３２に出力する点以外は、リクエスト遮断部５１０と同様である。なお、リクエスト遮断部５１０、５３０、５５０、および、５７０は、特許請求の範囲に記載のリクエスト待機制御部の一例である。
自己リクエスト番号取得部６１０は、リクエストマルチプレクサ４３１または４３２を通過してスレーブ１２１または１２２に出力されたリクエストに付加された自己リクエスト番号ＳＮを取得するものである。自己リクエスト番号取得部６１０は、取得した自己リクエスト番号ＳＮを、そのリクエストの送信元のマスタに応じて分配してリクエスト遮断部５１０および５３０に信号線６１５および６１６を介して出力する。自己リクエスト番号取得部６２０は、自己リクエスト番号ＳＮをリクエスト遮断部５１０および５３０の代わりにリクエスト遮断部５５０および５７０に出力する点以外は、自己リクエスト番号取得部６１０と同様の構成である。
リクエストマルチプレクサ４３１は、リクエスト遮断部５１０および５３０からのリクエストを所定の調停ポリシーに従って調停するものである。調停ポリシーとしては、固定優先度方式やラウンドロビン方式などが採用される。また、リクエストマルチプレクサ４３１は、マスタのそれぞれに予め割り当てたマスタ番号を、リクエストの送信元のマスタに応じてリクエストに付加する。リクエストマルチプレクサ４３１は、調停したリクエストをスレーブ１２１に信号線４３５を介して出力する。リクエストマルチプレクサ４３２は、リクエスト遮断部５５０および５７０からのリクエストを所定の調停ポリシーに従って調停してスレーブ１２２に出力するものである。なお、リクエストマルチプレクサ４３１および４３２は、特許請求の範囲に記載の調停部の一例である。
レスポンスデマルチプレクサ４４１は、スレーブ１２１からのレスポンスを宛先に応じて分配するものである。詳細には、レスポンスデマルチプレクサ４４１は、宛先がマスタ１１１である場合にレスポンスをレスポンスマルチプレクサ４２１に出力し、宛先がマスタ１１２である場合にレスポンスをレスポンスマルチプレクサ４２２に出力する。レスポンスデマルチプレクサ４４２は、スレーブ１２２からのレスポンスを宛先に応じて分配するものである。レスポンスデマルチプレクサ４４２の構成は、レスポンスデマルチプレクサ４４１の構成と同様である。
レスポンスマルチプレクサ４２１は、レスポンスデマルチプレクサ４４１および４４２からのレスポンスを所定の調停ポリシーに従って調停してマスタ１１１に出力するものである。レスポンスマルチプレクサ４２２は、レスポンスデマルチプレクサ４４１および４４２からのレスポンスを所定の調停ポリシーに従って調停してマスタ１１２に出力するものである。
［ＡＸＩプロトコルにおけるチャネル構成］
図２は、ＡＸＩプロトコルにおけるリードアドレスチャネルを構成する信号を示す図である。リードアドレスチャネルは、リードアドレスをマスタからスレーブに伝達するためのチャネルである。このリードアドレスチャネルは、リードアドレス識別子、リードアドレス、バースト長、バーストサイズ、バーストタイプ、ロックタイプ、キャッシュタイプ、プロテクションタイプ、リードアドレスバリッド、リードアドレスレディの各信号からなる。これらの信号のうち、リードアドレスレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。
リードアドレス識別子ＡＲＩＤ［３：０］は、信号のリードアドレスグループを識別するための４ビットのタグである。ＡＸＩプロトコルでは、マスタがトランザクションを発行する際に、スレーブに対して順序関係を維持することを要求する場合には、同じ識別子を付与することとされている。換言すれば、識別子が異なるトランザクション間では順序関係が維持される保証はない。
リードアドレスＡＲＡＤＤＲ［３１：０］は、リード対象となる３２ビットのアドレスであり、バースト転送における初期アドレスを示す信号である。
バースト長ＡＲＬＥＮ［３：０］は、バースト転送のデータ数を示す４ビットの信号である。「１」から「１６」の何れかのデータ数が４ビットにエンコードされて示される。
バーストサイズＡＲＳＩＺＥ［２：０］は、バースト転送の各回における転送サイズを示す３ビットの信号である。「２0」、「２1」、「２2」、「２3」、「２4」、「２5」、「２6」、「２7」の何れかの転送サイズが３ビットにエンコードされて示される。
バーストタイプＡＲＢＵＲＳＴ［１：０］は、バースト転送のアドレス計算のタイプを示す２ビットの信号である。具体的には、ＦＩＦＯ（First In First Out）型、連続アクセス、キャッシュラインの何れかのタイプを指定できるようになっている。
ロックタイプＡＲＬＯＣＫ［１：０］は、アトミックアクセスのための情報を示す２ビットの信号である。具体的には、ノーマルアクセス、排他的アクセス、ロック付きアクセスの何れかのタイプを指定できるようになっている。
キャッシュタイプＡＲＣＡＣＨＥ［３：０］は、キャッシュメモリ制御に必要な情報を示す４ビットの信号である。具体的には、キャッシュ可能か否か、ライトスルーかライトバックか等の制御情報が示される。
プロテクションタイプＡＲＰＲＯＴ［２：０］は、プロテクション制御に必要な情報を示す３ビットの信号である。具体的には、特権アクセス、非セキュアアクセス、インストラクションアクセスの各プロテクションレベルを指定できるようになっている。
リードアドレスバリッドＡＲＶＡＬＩＤは、アドレスおよび制御信号の有効性を示すバリッド信号である。リードアドレスレディＡＲＲＥＡＤＹは、スレーブがアドレスおよび制御信号を受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、リードアドレスバリッドＡＲＶＡＬＩＤおよびリードアドレスレディＡＲＲＥＡＤＹがともにアサートされているときに、アドレスおよび制御信号の転送が行われる。
図３は、ＡＸＩプロトコルにおけるリードデータチャネルを構成する信号を示す図である。リードデータチャネルは、リードデータをスレーブからマスタに転送するためのチャネルである。このリードデータチャネルは、リード識別子タグ、リードデータ、リードレスポンス、リードラスト、リードバリッド、リードレディの各信号からなる。これらの信号のうち、リードレディのみがマスタからの信号であり、これ以外はスレーブからの信号である。
リード識別子タグＲＩＤ［３：０］は、信号のリードデータグループを識別するための４ビットのタグである。このリード識別子タグＲＩＤ［３：０］はスレーブにおいて生成されるものであり、同一のトランザクションにおいてリードアドレス識別子ＡＲＩＤ［３：０］と一致していなければならない。
リードデータＲＤＡＴＡ［３１：０］は、リードトランザクションによるスレーブ１４０からのリードデータである。ここでは３２ビット幅のリードデータバスを想定したが、ＲＤＡＴＡのビット幅はリードデータバス幅に応じて変化する。リードデータバスは、８、１６、３２、６４、１２８、２５６、５１２および１０２４の何れかのビット幅を有する。
リードレスポンスＲＲＥＳＰ［１：０］は、リードトランザクションによるデータ転送の状態を示す２ビットの信号である。例えば、リードレスポンスには、リードアクセスの成功または失敗を示す信号が含まれる。
リードラストＲＬＡＳＴは、当該データがリードトランザクションにおける最終のデータ転送である旨を示す信号である。
リードバリッドＲＶＡＬＩＤは、要求されたリードデータの有効性を示すバリッド信号である。リードレディＲＲＥＡＤＹは、マスタがリードデータを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、リードバリッドＲＶＡＬＩＤおよびリードレディＲＲＥＡＤＹがともにアサートされているときに、リードデータの転送が行われる。
図４は、ＡＸＩプロトコルにおけるライトアドレスチャネルを構成する信号を示す図である。ライトアドレスチャネルは、ライトアドレスをマスタからスレーブに伝達するためのチャネルである。このライトアドレスチャネルは、ライトアドレス識別子、ライトアドレス、バースト長、バーストサイズ、バーストタイプ、ロックタイプ、キャッシュタイプ、プロテクションタイプ、ライトアドレスバリッド、ライトアドレスレディの各信号からなる。これらの信号のうち、ライトアドレスレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。
ライトアドレス識別子ＡＷＩＤ［３：０］は、信号のライトアドレスグループを識別するための４ビットのタグである。ライトアドレスＡＷＡＤＤＲ［３１：０］は、ライト対象となる３２ビットのアドレスであり、バースト転送における初期アドレスを示す信号である。
バースト長ＡＷＬＥＮ［３：０］は、バースト転送のデータ数を示す４ビットの信号である。バーストサイズＡＷＳＩＺＥ［２：０］は、バースト転送の各回における転送サイズを示す３ビットの信号である。バーストタイプＡＷＢＵＲＳＴ［１：０］は、バースト転送のアドレス計算のタイプを示す２ビットの信号である。ロックタイプＡＷＬＯＣＫ［１：０］は、アトミックアクセスのための情報を示す２ビットの信号である。キャッシュタイプＡＷＣＡＣＨＥ［３：０］は、キャッシュメモリ制御に必要な情報を示す４ビットの信号である。プロテクションタイプＡＷＰＲＯＴ［２：０］は、プロテクション制御に必要な情報を示す３ビットの信号である。これらは基本的にリードアドレスチャネルの場合と同様である。
ライトアドレスバリッドＡＷＶＡＬＩＤは、アドレスおよび制御信号の有効性を示すバリッド信号である。ライトアドレスレディＡＷＲＥＡＤＹは、スレーブがアドレスおよび制御信号を受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトアドレスバリッドＡＷＶＡＬＩＤおよびライトアドレスレディＡＷＲＥＡＤＹがともにアサートされているときに、アドレスおよび制御信号の転送が行われる。
図５は、ＡＸＩプロトコルにおけるライトデータチャネルを構成する信号を示す図である。ライトデータチャネルは、ライトデータをマスタからスレーブに転送するためのチャネルである。このライトデータチャネルは、ライト識別子タグ、ライトデータ、ライトストローブ、ライトラスト、ライトバリッド、ライトレディの各信号からなる。これらの信号のうち、ライトレディのみがスレーブからの信号であり、これ以外はマスタからの信号である。
ライト識別子タグＷＩＤ［３：０］は、信号のライトデータグループを識別するための４ビットのタグである。このライト識別子タグＷＩＤ［３：０］は、同一のトランザクションにおいてライトアドレス識別子ＡＷＩＤ［３：０］と一致していなければならない。
ライトデータＷＤＡＴＡ［３１：０］は、ライトトランザクションによるスレーブへのライトデータである。ここでは３２ビット幅のライトデータバスを想定したが、ＷＤＡＴＡのビット幅はリードデータバス幅に応じて変化する。ライトデータバスは、８、１６、３２、６４、１２８、２５６、５１２および１０２４の何れかのビット幅を有する。
ライトストローブＷＳＴＲＢ［３：０］は、スレーブ１４０のメモリにおいて更新されるべきバイト位置を示す４ビットの信号である。ライトデータバスの８ビット毎にライトストローブＷＳＴＲＢ［３：０］の１ビットが割り当てられる。すなわち、［３：０］の値をｉとすると、ＷＳＴＲＢ［ｉ］は、ＷＤＡＴＡ［（８×ｉ）＋７：（８×ｉ）］に対応する。
ライトラストＷＬＡＳＴは、当該データがライトトランザクションにおける最終のデータ転送である旨を示す信号である。
ライトバリッドＷＶＡＬＩＤは、ライトデータの有効性を示すバリッド信号である。ライトレディＷＲＥＡＤＹは、スレーブがライトデータを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトバリッドＷＶＡＬＩＤおよびライトレディＷＲＥＡＤＹがともにアサートされているときに、ライトデータの転送が行われる。
図６は、ＡＸＩプロトコルにおけるライトレスポンスチャネルを構成する信号を示す図である。ライトレスポンスチャネルは、ライトトランザクションの結果をスレーブからマスタに伝達するためのチャネルである。このライトレスポンスチャネルは、レスポンス識別子、ライトレスポンス、ライトレスポンスバリッド、レスポンスレディの各信号からなる。これらの信号のうち、レスポンスレディのみがマスタからの信号であり、これ以外はスレーブからの信号である。
レスポンス識別子ＢＩＤ［３：０］は、ライトレスポンスを識別するための４ビットのタグである。このレスポンス識別子ＢＩＤ［３：０］は、同一のトランザクションにおいてライトアドレス識別子ＡＷＩＤ［３：０］と一致していなければならない。
ライトレスポンスＢＲＥＳＰ［１：０］は、ライトトランザクションによるデータ転送の状態を示す２ビットの信号である。例えば、ライトレスポンスには、ライトアクセスの成功または失敗を示す信号が含まれる。
ライトレスポンスバリッドＢＶＡＬＩＤは、ライトレスポンスの有効性を示すバリッド信号である。レスポンスレディＢＲＥＡＤＹは、マスタがライトレスポンスを受け取ることができる状態にあるか否かを示すレディ信号である。前述のように、ライトレスポンスバリッドＢＶＡＬＩＤおよびレスポンスレディＢＲＥＡＤＹがともにアサートされているときに、ライトレスポンスの伝達が行われる。
［相互接続装置の構成］
図７は、第１の実施の形態における順序制御信号およびリクエストのデータ構造の一例を示す図である。待機リクエストに付加される順序制御信号は、自己リクエスト番号ＳＮおよび先行リクエスト番号ＰＮを含む。待機リクエストでないリクエストに付加される順序制御信号は、自己リクエスト番号ＳＮを含むが、先行リクエスト番号ＰＮを含まない。
リクエストは、例えば、リードアドレスリクエストであり、リード識別子タグＲＩＤ、リードデータＲＤＡＴＡ、リードレスポンスＲＲＥＳＰ、リードラストＲＬＡＳＴなどの信号を含む。なお、リクエストは、リードアドレスリクエストに限定されず、ライトアドレスリクエストであってもよい。
図８は、リクエスト管理部３０１の一構成例を示すブロック図である。リクエスト管理部３０１は、先行リクエスト履歴保持部３１０、順序制御信号付加部３２０、および、履歴削除部３３０を備える。リクエスト管理部３０２の構成は、リクエスト管理部３０１と同様である。
先行リクエスト履歴保持部３１０は、先行して発行されたリクエストに関する情報の履歴（以下、「先行リクエスト履歴」と称する。）を保持するものである。具体的には、先行リクエスト履歴は、トランザクション識別子ＩＤ、リクエスト番号ＲＮ、および、ラストフラグＬＦを含む。
トランザクション識別子ＩＤは、マスタ１１１または１１２がＡＸＩプロトコルに従ってリクエスト発行時に付与したトランザクションＩＤである。リクエスト番号ＲＮは、リクエストを識別するための番号である。ラストフラグＬＦは、リクエスト番号ＲＮが、同一のトランザクション識別子ＩＤに対応するリクエストのうち最後に発行されたリクエストに係るリクエスト番号ＲＮであるか否かを示すフラグである。例えば、ラストフラグには、リクエストが最後のリクエストである場合に真の値「Ｔ（Ｔｒｕｅ）」、そうでない場合に偽の値「Ｆ（Ｆａｌｓｅ）」が設定される。なお、リクエスト番号ＲＮは、特許請求の範囲に記載のリクエスト識別子の一例である。
順序制御信号付加部３２０は、順序制御信号を生成してリクエストに付加するものである。具体的には、まず、順序制御信号付加部３２０は、発行されたリクエストにリクエスト番号ＲＮを付与し、そのリクエストに係るトランザクション識別子ＩＤを取得する。順序制御信号付加部３２０は、取得したトランザクション識別子ＩＤに基づいて、リクエストが属するグループを特定し、そのグループにおける先行リクエストを特定する。具体的には、順序制御信号付加部３２０は、信号線３１３を介して先行リクエスト履歴保持部３１０にアクセスして、取得したトランザクション識別子ＩＤに係る先行リクエスト履歴が先行リクエスト履歴保持部３１０に保持されているか否かを判断する。該当する先行リクエスト履歴が１つ以上保持されている場合、順序制御信号付加部３２０は、それらの先行リクエスト履歴のうち、ラストフラグＬＦが真の値「Ｔ」の先行リクエスト履歴におけるリクエスト番号ＲＮを先行リクエスト番号ＰＮとして読み出す。そして、順序制御信号付加部３２０は、その先行リクエスト履歴のラストフラグＬＦを偽の値「Ｆ」に更新する。なお、ライトアドレスリクエストにおけるデータの転送単位であるＷｒｉｔｅＤａｔａ−Ｉｎｔｅｒｌｅａｖｅ−Ｄｅｐｔｈが１に設定されている場合について考える。この場合、マスタはトランザクションＩＤに関わらず、ライトアドレスの発行順にライトデータをスレーブに出力しなければならない。このため、順序制御信号付加部３２０は、先行リクエスト履歴保持部３１０において、トランザクションＩＤに関わらず、最後に発行されたライトアドレスリクエストを先行リクエストとして取得する。
また、順序制御信号付加部３２０は、付与したリクエスト番号ＲＮと、取得したトランザクション識別子ＩＤと、真の値「Ｔ」に設定したラストフラグＬＦとを含む先行リクエスト履歴を先行リクエスト履歴保持部３１０に追加する。順序制御信号付加部３２０は、リクエストに付与されたリクエスト番号ＲＮを自己リクエスト番号ＳＮとしてリクエストに付加する。順序制御信号付加部３２０は、先行リクエスト番号ＰＮを読み出していたならば、その先行リクエスト番号ＰＮをリクエストにさらに付加する。順序制御信号付加部３２０は、自己リクエスト番号ＳＮ等を付加したリクエストをリクエストデマルチプレクサ４１１へ信号線３０５を介して出力する。
履歴削除部３３０は、バスマトリックス４００からスレーブ１２１または１２２へリクエストが出力されたときに先行リクエスト履歴保持部３１０において、そのリクエストの先行リクエスト履歴を削除するものである。詳細には、履歴削除部３３０は、リクエストマルチプレクサ４３１または４３２からスレーブ１２１または１２２へ出力されたリクエストを取得する。そして、履歴削除部３３０は、取得したリクエストに付加された自己リクエスト番号ＳＮにリクエスト番号ＲＮが一致する先行リクエスト履歴を削除する。
図９は、先行リクエスト履歴保持部３１０の一構成例を示す図である。先行リクエスト履歴保持部３１０は、先行リクエスト履歴を保持するためのエントリＥＮＴ＃０乃至１５を備える。それぞれのエントリには、有効フラグＶと先行リクエスト履歴とが保持される。先行リクエスト履歴は、前述したように、トランザクション識別子ＩＤ、リクエスト番号ＲＮ、および、ラストフラグＬＦを含む。有効フラグＶは、エントリ内の先行リクエスト履歴が有効な履歴であるか否かを示すフラグである。有効フラグＶには、例えば、先行リクエスト履歴が有効である場合に真の値「Ｔ（Ｔｒｕｅ）」が設定され、無効である場合に偽の値「Ｆ（Ｆａｌｓｅ）」が設定される。また、リクエスト番号ＲＮには、例えば、リクエストが発行された順に連番が付与される。
例えば、トランザクションＩＤに「０」が設定されたリクエストＡおよびＢが発行され、その後にトランザクションＩＤに「１」が設定されたリクエストＣおよびＤが発行された場合を考える。リクエストＡが発行されたとき、先行リクエスト履歴保持部３１０には、リクエストＡの先行リクエスト履歴としてトランザクション識別子ＩＤ「０」、リクエスト番号ＲＮ「０」、および、真の値「Ｔ」のラストフラグＬＦが保持される。次にリクエストＢが発行されたとき、リクエストＡの先行リクエスト履歴においてラストフラグＬＦが偽の値「Ｆ」に更新される。そして、リクエストＢの先行リクエスト履歴としてトランザクション識別子ＩＤ「０」、リクエスト番号ＲＮ「１」、および、真の値「Ｔ」のラストフラグＬＦが追加される。さらに、リクエストＣの先行リクエスト履歴としてトランザクション識別子ＩＤ「１」、リクエスト番号ＲＮ「２」、および、真の値「Ｔ」のラストフラグＬＦが追加される。リクエストＤが発行されたとき、リクエストＣの先行リクエスト履歴においてラストフラグＬＦが偽の値「Ｆ」に更新される。そして、リクエストＤの先行リクエスト履歴としてトランザクション識別子ＩＤ「１」、リクエスト番号ＲＮ「３」、および、真の値「Ｔ」のラストフラグＬＦが追加される。
図１０は、第１の実施の形態における順序制御信号付加部３２０の一構成例を示すブロック図である。順序制御信号付加部３２０は、コンパレータ３２１、ＡＮＤ（論理積）ゲート３２２、ラストフラグ更新部３２３、履歴追加部３２４、自己リクエスト番号付加部３２５、および、先行リクエスト番号付加部３２６を備える。コンパレータ３２１およびＡＮＤゲート３２２は、先行リクエスト履歴保持部３１０のエントリごとに設けられる。
コンパレータ３２１は、リクエストに含まれるトランザクション識別子ＩＤと、対応するエントリに保持されたトランザクション識別子ＩＤとを比較して一致するか否かを判断するものである。コンパレータ３２１は、判断結果をＡＮＤゲート３２２に出力する。
ＡＮＤゲート３２２は、入力された値の論理積を出力するものである。ＡＮＤゲート３２２には、対応するエントリの有効フラグＶおよびラストフラグＬＦと、対応するコンパレータ３２１の判断結果とが入力される。ＡＮＤゲート３２２には、これらの入力値の論理積をラストフラグ更新部３２３に出力する。
ラストフラグ更新部３２３は、先行リクエスト履歴におけるラストフラグＬＦを更新するものである。具体的には、ラストフラグ更新部３２３は、エントリごとのＡＮＤゲート３２２のそれぞれの出力値を受け取り、「１」の出力値があるか否かを判断する。「１」の出力値があれば、ラストフラグ更新部３２３は、その出力値に対応するエントリからリクエスト番号ＲＮを読み出し、そのエントリのラストフラグＬＦの値を偽の値「Ｆ」に更新する。ラストフラグ更新部３２３は、読み出したリクエスト番号ＲＮを先行リクエスト番号ＰＮとして先行リクエスト番号付加部３２６に出力する。つまり、リクエストに係るトランザクション識別子ＩＤに対応するリクエスト番号ＲＮのうち、最後に生成されたリクエスト番号ＲＮが先行リクエスト番号ＰＮとして出力される。
履歴追加部３２４は、先行リクエスト履歴を追加するものである。履歴追加部３２４は、ラストフラグＬＦの更新後に、先行リクエスト履歴保持部３１０内のそれぞれのエントリにおける有効フラグＶを読み出して、無効なエントリのうちのいずれかを選択する。履歴追加部３２４は、選択したエントリに先行リクエスト履歴を追加して、そのエントリの有効フラグを真の値「Ｔ」に更新する。また、履歴追加部３２４は、追加した先行リクエスト履歴におけるリクエスト番号ＲＮを自己リクエスト番号ＳＮとして自己リクエスト番号付加部３２５に出力する。
自己リクエスト番号付加部３２５は、自己リクエスト番号ＳＮをリクエストに付加するものである。自己リクエスト番号付加部３２５は、自己リクエスト番号ＳＮを付加したリクエストを先行リクエスト番号付加部３２６に出力する。なお、自己リクエスト番号付加部３２５は、特許請求の範囲に記載の自己リクエスト識別子付加部の一例である。
先行リクエスト番号付加部３２６は、先行リクエスト番号ＰＮが読み出された場合にリクエストに先行リクエスト番号ＰＮを付加するものである。先行リクエスト番号付加部３２６は、必要に応じて先行リクエスト番号ＰＮを付加したリクエストをリクエストデマルチプレクサ４１１に出力する。なお、先行リクエスト番号付加部３２６は、特許請求の範囲に記載の先行リクエスト識別子付加部の一例である。
図１１は、第１の実施の形態におけるリクエスト遮断部５１０の一構成例を示すブロック図である。リクエスト遮断部５１０は、リクエスト番号一致判断部５１２、リクエスト遮断判定部５２１、バッファ５２２、および、待機解除リクエスト出力部５２３を備える。
バッファ５２２は、複数のエントリを備え、それらのエントリのそれぞれに有効フラグＶ、ホールドフラグＨＦ、および、順序制御信号付きリクエストが保持される。バッファ５２２は、例えばＦＩＦＯ（First-In First-Out）メモリであり、格納された順にリクエストが読み出される。
リクエスト番号一致判断部５１２は、バッファ５２２のエントリごとに設けられる。ホールドフラグＨＦには、例えば、リクエストが待機状態である場合に「１」の値が設定され、待機が取り消された場合に「０」の値が設定される。リクエスト遮断判定部５２１は、リクエストを待機させてリクエストの出力を遮断するか否かを判定するものである。リクエスト遮断判定部５２１は、リクエストデマルチプレクサ４１１から順序制御信号付きリクエストを受け取り、有効フラグＶが「０」のエントリにそのリクエストを保持する。このとき、リクエスト遮断判定部５２１は、リクエストに先行リクエスト番号ＰＮが付加されている場合に、そのリクエストを待機状態（ＨＦ＝１）に設定してバッファ５２２に保持する。リクエストに先行リクエスト番号ＰＮが付加されていない場合にそのリクエストを非待機状態（ＨＦ＝０）に設定してバッファ５２２に保持する。リクエストが保持されたエントリにおいて有効フラグＶは「１」に更新される。リクエスト遮断部５３０、５５０、および、５７０の構成は、リクエスト遮断部５１０の構成と同様である。
リクエスト番号一致判断部５１２は、自己リクエスト番号取得部６１０からの自己リクエスト番号ＳＮのいずれかと、対応するエントリにおける待機中のリクエストの先行リクエスト番号ＰＮとが一致するか否かを判断するものである。リクエスト番号一致判断部５１２は、判断結果に基づいて、対応するエントリにおけるホールドフラグＨＦを更新する。具体的には、一致する場合にホールドフラグＨＦが「０」に更新される。
待機解除リクエスト出力部５２３は、待機が解除されたリクエストを出力するものである。待機解除リクエスト出力部５２３は、バッファ５２２に最初に保持された順序制御信号付きリクエストを読み出し、そのホールドフラグＨＦの値が「０」（すなわち、非待機状態）であるか否かを判断する。待機状態が解除されていれば、待機解除リクエスト出力部５２３は、その順序制御信号付きリクエストをリクエストマルチプレクサ４３１へ出力して、そのエントリの有効フラグＶの値を「０」に更新する。
図１２は、第１の実施の形態におけるリクエスト番号一致判断部５１２の一構成例を示すブロック図である。リクエスト番号一致判断部５１２は、コンパレータ５１３乃至５１６とＮＯＲ（否定論理和）ゲート５１７とを備える。
コンパレータ５１３乃至５１６は、自己リクエスト番号ＲＮと先行リクエスト番号ＰＮとを比較して一致するか否かを判断するものである。コンパレータ５１３には、スレーブ１２２からのレスポンスに付加された自己リクエスト番号ＳＮと先行リクエスト番号ＰＮとが入力される。コンパレータ５１４には、スレーブ１２１からのレスポンスに付加された自己リクエスト番号ＲＮと先行リクエスト番号ＰＮとが入力される。コンパレータ５１５には、リクエストマルチプレクサ４３２からのリクエストに付加された自己リクエスト番号ＲＮと先行リクエスト番号ＰＮとが入力される。コンパレータ５１６には、リクエストマルチプレクサ４３１からのリクエストに付加された自己リクエスト番号ＲＮと先行リクエスト番号ＰＮとが入力される。コンパレータ５１３乃至５１６は、それらの自己リクエスト番号ＲＮと先行リクエスト番号ＰＮとが一致するか否かを示す判断結果をＮＯＲゲート５１７に出力する。
ＮＯＲゲート５１７は、入力された値の否定論理和を出力するものである。ＮＯＲゲート５１７には、コンパレータ５１３乃至５１６のそれぞれからの判断結果が入力される。ＮＯＲゲート５１７は、それらの入力値の否定論理和をホールドフラグＨＦとしてバッファ５２２へ信号線５２６を介して出力する。この結果、自己リクエスト番号ＳＮのいずれかと先行リクエスト番号ＰＮが一致するのである場合、ホールドフラグに「０」の値が設定されて待機が取り消される。一方、いずれの自己リクエスト番号ＳＮも先行リクエスト番号ＰＮに一致しない場合は、ホールドフラグに「１」の値が設定されて待機状態が維持される。
図１３は、自己リクエスト番号取得部６１０の一構成例を示すブロック図である。自己リクエスト番号取得部６１０は、分配器６１１乃至６１４を備える。自己リクエスト番号取得部６２０の構成は、自己リクエスト番号取得部６１０と同様である。
分配器６１１乃至６１４は、マスタに応じて自己リクエスト番号ＳＮを分配して出力するものである。詳細には、分配器６１１には、リクエストマルチプレクサ４３１からのリクエストに付加されたマスタ番号ＭＮおよび自己リクエスト番号ＳＮが入力される。分配器６１２には、リクエストマルチプレクサ４３２からのリクエストに付加されたマスタ番号ＭＮおよび自己リクエスト番号ＳＮが入力される。分配器６１３には、スレーブ１２１からのレスポンスに付加されたマスタ番号ＭＮおよび自己リクエスト番号ＳＮが入力される。分配器６１４には、スレーブ１２２からのレスポンスに付加されたマスタ番号ＭＮおよび自己リクエスト番号ＳＮが入力される。分配器６１１乃至６１４は、入力されたマスタ番号に対応するリクエスト遮断部（５１０または５３０）に自己リクエスト番号ＳＮを出力する。
ここで、分配器６１１乃至６１４は、スレーブの仕様に応じて有効または無効に設定される。スレーブには、トランザクションＩＤが異なるリクエストに対して、リクエストを受け取った順にレスポンスを返すスレーブと、リクエストを受け取った順と異なる順序でレスポンスを返しうるスレーブとがある。スレーブ１２１が受け取った順にレスポンスを返すスレーブであれば、自己リクエスト番号取得部６１０において分配器６１１および６１２のみが有効に設定される。このようなスレーブであれば、リクエストマルチプレクサから先行リクエストが出力されたことにより、待機解除条件が満たされるためである。一方、スレーブ１２１が、リクエストを受け取った順と異なる順序でレスポンスを返しうるスレーブであれば、自己リクエスト番号取得部６１０において分配器６１３および６１４のみが有効に設定される。このようなスレーブであれば、スレーブ１２１から先行リクエストに対応するレスポンスが返却されたことにより、待機解除条件が満たされるためである。
［相互接続装置の動作］
図１４は、第１の実施の形態における相互接続装置２００の動作を示すフローチャートである。この動作は、例えば、相互接続装置２００に電源が投入されたとき、または、マスタ１１１および１１２とスレーブ１２１および１２２が相互接続装置２００に接続されたときに開始される。
相互接続装置２００は、先行リクエスト履歴保持部３１０および待機リクエスト保持部５２４を初期化する（ステップＳ９０５）。相互接続装置２００は、新規にリクエストが発行されたか否かを判断する（ステップＳ９１０）。リクエストが発行されたのであれば（ステップＳ９１０：Ｙｅｓ）、相互接続装置２００は、リクエストに先行リクエストを対応付けて管理するためのリクエスト管理処理を実行する（ステップＳ９２０）。そして、相互接続装置２００は、待機リクエストを待機させるためのリクエスト待機制御処理を実行する（ステップＳ９５０）。相互接続装置２００は、リクエストマルチプレクサ４３１および４３２において、リクエストを調停して宛先のスレーブに出力する（ステップＳ９６０）。リクエストが発行されていない場合（ステップＳ９１０：Ｎｏ）、または、ステップＳ９６０の後、相互接続装置２００は、ステップＳ９１０に戻る。
図１５は、第１の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。リクエスト管理部３０１および３０２は、順序制御信号をリクエストに付加するための順序制御信号付加処理を実行する（ステップＳ９３０）。リクエスト管理部３０１および３０２は、リクエストマルチプレクサ４３１または４３２からスレーブ１２１または１２２へリクエストが出力されたか否かを判断する（ステップＳ９４１）。リクエストが出力されたのであれば（ステップＳ９４１：Ｙｅｓ）、リクエスト管理部３０１および３０２は、出力されたリクエストの先行リクエスト履歴を先行リクエスト履歴保持部３１０において削除する（ステップＳ９４２）。リクエストが出力されていない場合（ステップＳ９４１：Ｎｏ）、または、ステップＳ９４２の後、リクエスト管理部３０１および３０２は、リクエスト管理処理を終了する。
図１６は、第１の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。順序制御信号付加部３２０は、新規のリクエストのトランザクション識別子ＩＤを取得する（ステップＳ９３１）。順序制御信号付加部３２０は、トランザクション識別子ＩＤが一致する先行リクエスト履歴があるか否かを判断する（ステップＳ９３２）。該当する先行リクエスト履歴が１つ以上あれば（ステップＳ９３２：Ｙｅｓ）、順序制御信号付加部３２０は、それらの先行リクエスト履歴のうち最後のリクエストのリクエスト番号ＲＮを先行リクエスト番号ＰＮとして取得する（ステップＳ９３３）。順序制御信号付加部３２０は、最後のリクエスト番号ＲＮを含む先行リクエスト履歴においてラストフラグＬＦを更新する（ステップＳ９３４）。
該当する先行リクエスト履歴がない場合（ステップＳ９３２：Ｎｏ）、または、ステップＳ９３４の後、順序制御信号付加部３２０は、新規のリクエストの先行リクエスト履歴を先行リクエスト履歴保持部３１０に追加する（ステップＳ９３５）。順序制御信号付加部３２０は、先行リクエスト番号を取得しているか否かを判断する（ステップＳ９３６）。先行リクエスト番号を取得している場合（ステップＳ９３６：Ｙｅｓ）、順序制御信号付加部３２０は、リクエスト番号ＲＮおよび先行リクエスト番号ＰＮを含む順序制御信号をリクエストに付加する（ステップＳ９３７）。先行リクエスト番号を取得していない場合（ステップＳ９３６：Ｎｏ）、順序制御信号付加部３２０は、リクエスト番号ＲＮを含む順序制御信号をリクエストに付加する（ステップＳ９３８）。ステップＳ９３７またはＳ９３８の後、順序制御信号付加部３２０は、順序制御信号付加処理を終了する。
図１７は、第１の実施の形態におけるリクエスト待機制御処理を示すフローチャートである。リクエスト遮断部５１０は、リクエストに先行リクエスト番号ＰＮが付加されているか否かを判断する（ステップＳ９５１）。
リクエストに先行リクエスト番号ＰＮが付加されていれば（ステップＳ９５１：Ｙｅｓ）、リクエスト遮断部５１０は、そのリクエストを待機状態にして保持する（ステップＳ９５２）。リクエスト遮断部５１０は、スレーブ１２１または１２２に出力されたリクエストの自己リクエスト番号ＳＮを取得する（ステップＳ９５３）。リクエスト遮断部５１０は、自己リクエスト番号ＳＮが、待機中のリクエストが待っている先行リクエスト番号ＰＮであるか否かを判断する（ステップＳ９５４）。自己リクエスト番号ＳＮが先行リクエスト番号ＰＮである場合（ステップＳ９５４：Ｙｅｓ）、リクエスト遮断部５１０は、待機中のリクエストの待機を解除する（ステップＳ９５５）。リクエストに先行リクエスト番号ＰＮが付加されていない（ステップＳ９５１：Ｎｏ）、または、ステップＳ９５５の後、リクエスト遮断部５１０は、最も古いリクエストが待機状態になければ、そのリクエストをマルチプレクサへ出力する（ステップＳ９５６）。ステップＳ９５６の後、リクエスト遮断部５１０は、リクエスト待機制御処理を終了する。リクエスト遮断部５３０、５５０、および、５７０の動作は、リクエスト遮断部５１０の動作と同様である。
図１８は、第１の実施の形態におけるデッドロックが回避された状態の情報処理システムの一例を示す図である。マスタ１１１がスレーブリクエストＡ、Ｂの順にリクエストを発行し、マスタ１１２がリクエストＣ、Ｄの順にリクエストを発行したものとする。リクエストＡおよびＤはスレーブ１２１に対して発行され、リクエストＢおよびＣはスレーブ１２２に対して発行されたものとする。リクエストＡおよびＢには、ともにトランザクション識別子ＩＤ「０」が付与され、これらのリクエスト間には依存関係があるものとする。また、リクエストＣおよびＤには、ともにトランザクション識別子ＩＤ「１」が付与され、これらのリクエスト間にも依存関係があるものとする。一方、トランザクション識別子ＩＤの値が異なるため、リクエストＡおよびＢと、リクエストＣおよびＤとの間には、依存関係がない。
この場合、相互接続装置２００がリクエストを必要に応じて待機させないと、デッドロックが生じるおそれがある。例えば、調停の結果、リクエストＢおよびＤが、先行のリクエストＡおよびＣよりも先にスレーブ１２１および１２２に出力されると、それぞれのスレーブは、最初にリクエストＢおよびＤに対するレスポンスを返そうとする。一方、マスタ１１１および１１２は、先行のリクエストＡおよびＣに対するレスポンスが先に返却されることを期待しているため、デッドロックが生じてしまう。
しかし、相互接続装置２００においてリクエスト遮断部５３０は、リクエストＤを受け取ると、そのリクエストＤを待機させて、先行するリクエストＣがスレーブ１２２に出力されたときに待機を取り消す。また、リクエスト遮断部５５０は、リクエストＢを受け取ると、そのリクエストＢを待機させて、先行するリクエストＡがスレーブ１２１に出力されたときに待機を取り消す。このため、リクエストＢおよびＤが、リクエストＡおよびＣよりも先にスレーブ１２１および１２２に出力されることが防止され、デッドロックが回避される。また、相互接続装置２００はリクエストがスレーブ１２１または１２２に出力された時点で待機を取り消しているため、その後にレスポンスが返却されたときに待機を取り消す構成よりも、レイテンシが低減する。
図１９は、第１の実施の形態における依存関係有方向グラフの一例を示す図である。依存関係有方向グラフは、リクエスト間の依存関係と、リクエストに対するレスポンスの返却順序とを図示したものである。依存関係有方向グラフに閉ループが生じる場合、デッドロックが生じることを意味する。図１９（ａ）は、リクエストを待機させない場合の依存関係有方向グラフの一例を示す図である。図１９（ａ）において、点線の有向線分７０１は、リクエストＡ、Ｂ間の依存関係を示すものである。点線の有向線分７０２は、リクエストＣ、Ｄ間の依存関係を示すものである。有向線分７０１および７０２の始点は、依存先であり、終点は依存元である。有向線分７０１および７０２は、リクエストＢがＡに依存し、リクエストＤがＣに依存していることを示している。また、実線の有向線分７０３は、リクエストＡ、Ｄに対するレスポンスの返却順序を示すものである。実線の有向線分７０４は、リクエストＢ、Ｃに対するレスポンスの返却順序を示すものである。有向線分７０３および７０４の始点は、最初に返却されるレスポンスであり、終点は、次に返却されるレスポンスである。有向線分７０３および７０４は、リクエストＢおよびＤに対するレスポンスの次に、リクエストＡおよびＣに対するレスポンスが返却されることを示している。このように、リクエストＢおよびＤが先に返却されると、依存関係有方向グラフに閉ループが生じる。すなわち、デッドロックが生じてしまう。
図１９（ｂ）は、リクエストを待機させた場合の依存関係有方向グラフの一例を示す図である。図１９（ｂ）において、実線の有向線分７０５および７０６は、リクエストＡおよびＣに対するレスポンスの次に、リクエストＢおよびＤに対するレスポンスが返却されることを示している。これは、リクエストＢおよびＤを相互接続装置２００が待機させたためである。このように、リクエストＡおよびＣが先に返却されると、依存関係有方向グラフに閉ループが生じない。すなわち、デッドロックが回避される。
このように第１の実施の形態によれば、リクエスト管理部３０１および３０２は、発行されたリクエストが待機リクエストである場合には待機リクエストに先行リクエストを対応付けて管理する。リクエストマルチプレクサ４３１および４３２は、マスタ１１１および１１２から発行された複数のリクエストを調停して調停したリクエストを宛先のスレーブ１２１または１２２に出力する。リクエスト遮断部５１０、５３０、５５０、および、５７０は、待機リクエストを待機させる。そして、それぞれのリクエスト遮断部は、待機リクエストに対応する先行リクエストがスレーブ１２１および１２２のいずれかに出力された後に待機リクエストをリクエストマルチプレクサ４３１または４３２へ出力する。これにより、先行リクエストがスレーブ１２１または１２２に出力されるまで、待機リクエストが待機するため、デッドロックが回避される。
また、先行リクエストが出力された時点、または、先行リクエストに対するレスポンスがスレーブから出力された時点に、待機リクエストの待機が取り消される。これらの時点において既にデッドロックが回避されているため、デッドロックが回避された時点で直ちに待機が取り消される。このため、その後にレスポンスがマスタに返却されたときに待機が取り消される構成と比較して、トランザクション処理におけるレイテンシが低下する。
＜２．第２の実施の形態＞
［相互接続装置の構成例］
図２０は、第２の実施の形態における先行リクエスト履歴保持部３１１の一構成例を示す図である。先行リクエスト履歴保持部３１１は、ラストフラグＬＦを保持しない点において第１の実施の形態における先行リクエスト履歴保持部３１０と異なる。
第２の実施の形態における相互接続装置２００においては、先行リクエスト履歴は、リクエストの発行順に従って、エントリの先頭から順に配列される。そして、相互接続装置２００は、新たに発行されたリクエストとトランザクションＩＤが一致し、最も遅くに保持された先行リクエスト履歴におけるリクエスト番号ＲＮを先行リクエスト番号ＰＮとして取得する。また、相互接続装置２００は、削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があれば、それらの先行リクエスト履歴を上詰めにして先行リクエスト履歴の並び順をリクエストの発行順に一致させる。
［相互接続装置の動作例］
図２１は、第２の実施の形態におけるリクエスト管理処理の一例を示すフローチャートである。第２の実施の形態におけるリクエスト管理処理は、ステップＳ９４２の代わりにステップＳ９４３乃至Ｓ９４５を実行する点において第１の実施の形態のリクエスト管理処理と異なる。
リクエストが出力されたのであれば（ステップＳ９４１：Ｙｅｓ）、リクエスト管理部３０１および３０２は、出力されたリクエストの先行リクエスト履歴を先行リクエスト履歴保持部３１１において削除する（ステップＳ９４３）。リクエスト管理部３０１および３０２は、削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があるか否かを判断する（ステップＳ９４４）。削除した先行リクエスト履歴以降に有効な先行リクエスト履歴があれば（ステップＳ９４４：Ｙｅｓ）、リクエスト管理部３０１および３０２は、それらの先行リクエスト履歴を上詰めにする（ステップＳ９４５）。削除した先行リクエスト履歴以降に有効な先行リクエスト履歴がない場合（ステップＳ９４４：Ｎｏ）、またはステップＳ９４５の後、リクエスト管理部３０１および３０２は、リクエスト管理処理を終了する。
図２２は、第２の実施の形態における順序制御信号付加処理の一例を示すフローチャートである。第２の実施の形態の順序制御信号付加処理は、ステップＳ９３４およびＳ９３５の代わりにステップＳ９３９を実行する点において第１の実施の形態の順序制御信号付加処理と異なる。
該当する先行リクエスト履歴があれば（ステップＳ９３２：Ｙｅｓ）、順序制御信号付加部３２０は、先行リクエスト番号を取得する（ステップＳ９３３）。該当する先行リクエスト履歴がない場合（ステップＳ９３２：Ｎｏ）、または、ステップＳ９３３の後、順序制御信号付加部３２０は、新規のリクエストの先行リクエスト履歴を先行リクエスト履歴保持部３１１に追加する（ステップＳ９３９）。
このように第２の実施の形態によれば、先行リクエスト履歴保持部３１１においてラストフラグＬＦを保持しないため、先行リクエスト履歴保持部３１１の容量を削減することができる。
なお、上述の実施の形態は本技術を具現化するための一例を示したものであり、実施の形態における事項と、特許請求の範囲における発明特定事項とはそれぞれ対応関係を有する。同様に、特許請求の範囲における発明特定事項と、これと同一名称を付した本技術の実施の形態における事項とはそれぞれ対応関係を有する。ただし、本技術は実施の形態に限定されるものではなく、その要旨を逸脱しない範囲において実施の形態に種々の変形を施すことにより具現化することができる。
また、上述の実施の形態において説明した処理手順は、これら一連の手順を有する方法として捉えてもよく、また、これら一連の手順をコンピュータに実行させるためのプログラム乃至そのプログラムを記憶する記録媒体として捉えてもよい。この記録媒体として、例えば、ＣＤ（Compact Disc）、ＭＤ（MiniDisc）、ＤＶＤ（Digital Versatile Disk）、メモリカード、ブルーレイディスク（Blu-ray Disc（登録商標））等を用いることができる。
なお、本技術は以下のような構成もとることができる。
（１）複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理部と、
前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停部と、
前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御部と
を具備する相互接続装置。
（２）前記リクエスト待機制御部は、前記先行リクエストが前記複数の応答デバイスのいずれかに出力されたときに前記待機リクエストを前記調停部へ出力する
前記（１）記載の相互接続装置。
（３）前記リクエスト待機制御部は、前記先行リクエストに対するレスポンスが前記複数の応答デバイスのうちのいずれかから出力されたときに前記待機リクエストを前記調停部へ出力する
前記（１）記載の相互接続装置。
（４）前記リクエスト管理部は、前記待機リクエストに前記先行リクエストを識別するための先行リクエスト識別子を生成して前記待機リクエストに付加することにより当該待機リクエストに前記先行リクエストを対応付け、
前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に係る前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する
前記（１）乃至（３）のいずれかに記載の相互接続装置。
（５）前記リクエスト管理部は、
前記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として前記リクエストに付加する自己リクエスト識別子付加部と、
前記自己リクエスト識別子が付加された前記リクエストが前記待機リクエストである場合には前記先行リクエストに該当する前記リクエストについて生成されていた前記リクエスト識別子を前記先行リクエスト識別子として前記待機リクエストに付加する先行リクエスト識別子付加部と
を備え、
前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に一致する前記自己リクエスト識別子が付加された前記リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する
前記（４）記載の相互接続装置。
（６）前記リクエスト管理部は、前記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る前記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、
前記先行リクエスト識別子付加部は、前記グループ識別子に基づいて前記待機リクエストが属する前記グループを特定して当該特定したグループにおいて前記先行リクエストを特定する
前記（５）記載の相互接続装置。
（７）前記リクエスト管理部は、前記リクエストが前記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された前記自己リクエスト識別子に一致する前記リクエスト識別子を前記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備える
前記（５）または（６）記載の相互接続装置。
（８）前記リクエスト識別子保持部は、前記リクエストが属する前記グループにおいて前記リクエストが最後に発行されたか否かを示すラストフラグを前記リクエストごとにさらに保持し、
前記先行リクエスト付加部は、前記特定したグループにおいて前記待機リクエストを除き最後に発行されたリクエストを前記ラストフラグに基づいて前記先行リクエストとして特定する
前記（６）記載の相互接続装置。
（９）リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、
調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、
リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順と
を具備する相互接続装置の制御方法。
（１０）リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、
調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、
リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順と
をコンピュータに実行させるためのプログラム。
１１１、１１２ マスタ
１２１、１２２ スレーブ
２００ 相互接続装置
３０１、３０２ リクエスト管理部
３１０、３１１ 先行リクエスト履歴保持部
３２０ 順序制御信号付加部
３２１、５１３、５１４、５１５、５１６ コンパレータ
３２２、５２３ ＡＮＤ（論理積）ゲート
３２３ ラストフラグ更新部
３２４ 履歴追加部
３２５ 自己リクエスト番号付加部
３２６ 先行リクエスト番号付加部
３３０ 履歴削除部
４００ バスマトリックス
４１１、４１２ リクエストデマルチプレクサ
４２１、４２２ レスポンスマルチプレクサ
４３１、４３２ リクエストマルチプレクサ
４４１、４４２ レスポンスデマルチプレクサ
５１０、５３０、５５０、５７０ リクエスト遮断部
５１２ リクエスト番号一致判断部
５２１ リクエスト遮断判定部
５２２ バッファ
５２３ 待機リクエスト出力部
６１０、６２０ 自己リクエスト番号取得部
６１１、６１２、６１３、６１４ 分配器

Claims (10)

  1. 複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理部と、
    前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停部と、
    前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御部と
    を具備する相互接続装置。
  2. 前記リクエスト待機制御部は、前記先行リクエストが前記複数の応答デバイスのいずれかに出力されたときに前記待機リクエストを前記調停部へ出力する
    請求項１記載の相互接続装置。
  3. 前記リクエスト待機制御部は、前記先行リクエストに対するレスポンスが前記複数の応答デバイスのうちのいずれかから出力されたときに前記待機リクエストを前記調停部へ出力する
    請求項１記載の相互接続装置。
  4. 前記リクエスト管理部は、前記待機リクエストに前記先行リクエストを識別するための先行リクエスト識別子を生成して前記待機リクエストに付加することにより当該待機リクエストに前記先行リクエストを対応付け、
    前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に係る前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する
    請求項１記載の相互接続装置。
  5. 前記リクエスト管理部は、
    前記リクエストを識別するためのリクエスト識別子を生成して当該リクエスト識別子を自己リクエスト識別子として前記リクエストに付加する自己リクエスト識別子付加部と、
    前記自己リクエスト識別子が付加された前記リクエストが前記待機リクエストである場合には前記先行リクエストに該当する前記リクエストについて生成されていた前記リクエスト識別子を前記先行リクエスト識別子として前記待機リクエストに付加する先行リクエスト識別子付加部と
    を備え、
    前記リクエスト待機制御部は、前記待機リクエストに付加された前記先行リクエスト識別子に一致する前記自己リクエスト識別子が付加された前記リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力する
    請求項４記載の相互接続装置。
  6. 前記リクエスト識別子は、前記生成されたリクエスト識別子と当該生成されたリクエスト識別子に係る前記リクエストが属するグループを識別するためのグループ識別子とを対応付けて保持するリクエスト識別子保持部をさらに備え、
    前記先行リクエスト識別子付加部は、前記グループ識別子に基づいて前記待機リクエストが属する前記グループを特定して当該特定したグループにおいて前記先行リクエストを特定する
    請求項５記載の相互接続装置。
  7. 前記リクエスト管理部は、前記リクエストが前記複数の応答デバイスのいずれかに出力されたときに当該出力されたリクエストに付加された前記自己リクエスト識別子に一致する前記リクエスト識別子を前記リクエスト識別子保持部から削除するリクエスト識別子削除部をさらに備える
    請求項５記載の相互接続装置。
  8. 前記リクエスト識別子保持部は、前記リクエストが属する前記グループにおいて前記リクエストが最後に発行されたか否かを示すラストフラグを前記リクエストごとにさらに保持し、
    前記先行リクエスト付加部は、前記特定したグループにおいて前記待機リクエストを除き最後に発行されたリクエストを前記ラストフラグに基づいて前記先行リクエストとして特定する
    請求項６記載の相互接続装置。
  9. リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、
    調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、
    リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順と
    を具備する相互接続装置の制御方法。
  10. リクエスト管理部が、複数の要求デバイスのいずれかから複数の応答デバイスのいずれかに対して発行されたリクエストが当該リクエストに先行して発行された先行リクエストの前記複数の応答デバイスのいずれかへの出力を待つべき待機リクエストである場合には当該待機リクエストに前記先行リクエストを対応付けて管理するリクエスト管理手順と、
    調停部は、前記複数の要求デバイスから発行された複数のリクエストを調停して当該調停したリクエストを前記複数の応答デバイスのうち前記調停したリクエストの宛先である応答デバイスに出力する調停手順と、
    リクエスト待機制御部が、前記待機リクエストを待機させて、当該待機リクエストに対応する前記先行リクエストが前記複数の応答デバイスのいずれかに出力された後に前記待機リクエストを前記調停部へ出力するリクエスト待機制御手順と
    をコンピュータに実行させるためのプログラム。
JP2011171538A 2011-08-05 2011-08-05 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム Withdrawn JP2013037459A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011171538A JP2013037459A (ja) 2011-08-05 2011-08-05 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2011171538A JP2013037459A (ja) 2011-08-05 2011-08-05 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム

Publications (1)

Publication Number Publication Date
JP2013037459A true JP2013037459A (ja) 2013-02-21

Family

ID=47887039

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011171538A Withdrawn JP2013037459A (ja) 2011-08-05 2011-08-05 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム

Country Status (1)

Country Link
JP (1) JP2013037459A (ja)

Similar Documents

Publication Publication Date Title
CN108885583B (zh) 高速缓存存储器访问
AU2013217351B2 (en) Processor performance improvement for instruction sequences that include barrier instructions
US8321635B2 (en) Synchronizing commands for preventing data corruption
JP3275051B2 (ja) バスブリッジにおけるトランザクション順序を維持し、遅延応答をサポートする方法及びそのための装置
US10248564B2 (en) Contended lock request elision scheme
US9244877B2 (en) Link layer virtualization in SATA controller
US8762651B2 (en) Maintaining cache coherence in a multi-node, symmetric multiprocessing computer
US6170030B1 (en) Method and apparatus for restreaming data that has been queued in a bus bridging device
JP2012073851A (ja) バスシステムおよびそのデッドロック回避回路
US9858190B2 (en) Maintaining order with parallel access data streams
US9348740B2 (en) Memory access controller, multi-core processor system, memory access control method, and computer product
JP2001117859A (ja) バス制御装置
US9372798B2 (en) Data processing apparatus having first and second protocol domains, and method for the data processing apparatus
TW201011537A (en) Apparatus and method for ensuring data coherency within a cache memory hierarchy of a microprocessor
US10452593B1 (en) High-performance streaming of ordered write stashes to enable optimized data sharing between I/O masters and CPUs
US20100042771A1 (en) Information processing apparatus and order guarantee method
EP3644190B1 (en) I/o coherent request node for data processing network with improved handling of write operations
CN111290983A (zh) Usb传输设备及传输方法
US20120102293A1 (en) Transmission device, transmission method, and non-transitory computer-readable storage medium
JP5659817B2 (ja) 相互接続装置
US20080301376A1 (en) Method, Apparatus, and System Supporting Improved DMA Writes
CN114356839B (zh) 处理写操作的方法、设备、处理器及设备可读存储介质
WO2022194021A1 (zh) 并发控制方法、网卡、计算机设备、存储介质
JP6115455B2 (ja) 並列計算機システム、並列計算機システムの制御方法、情報処理装置、演算処理装置および通信制御装置
JP2013037459A (ja) 相互接続装置、および、相互接続装置の制御方法ならびに当該方法をコンピュータに実行させるプログラム

Legal Events

Date Code Title Description
A300 Withdrawal of application because of no request for examination

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20141007