(57)【要約】【課題】リクエストが競合した場合にリクエスト間で均衡が取れた処理を実行し処理速度を向上させる演算処理装置及び演算処理装置の制御方法を提供する。【解決手段】命令制御部は、命令をデコードしてリクエストを発行する。キャッシュ制御パイプライン１３２は、ローカルリクエストポート１１１〜１１３、外部リクエストポート１２１及びオーダーポート１２２から出力されたリクエストが処理実行可能か否かを判定し、処理実行困難の場合はリクエストを破棄して再出力を要求する終了処理を行い、処理実行可能の場合は前記リクエストの要求に応じた要求処理を行うパイプライン処理を実行する。処理順調整回路２００は、要求処理が行われた完了リクエストを出力した完了リクエストポートにより出力された後続リクエストについてキャッシュ制御パイプライン１３２に終了処理を行わせる。【選択図】図２
2020095464.tif 000002
【特許請求の範囲】
【請求項１】
命令をデコードしてリクエストを発行する命令制御部と、
前記リクエストを受け付けて出力する複数のリクエストポートと、
前記リクエストポートから出力されたリクエストが処理実行可能か否かを判定し、前記リクエストが処理実行困難の場合は前記リクエストを破棄して再出力を要求する終了処理を行い、処理実行可能の場合は前記リクエストの要求に応じた要求処理を行うパイプライン処理を実行する制御パイプラインと、
前記制御パイプラインにより前記要求処理が行われた完了リクエストを出力した完了リクエストポートから出力された後続リクエストについて前記制御パイプラインに前記終了処理を行わせる順序調整部と
を備えたことを特徴とする演算処理装置。
【請求項２】
前記リクエストポートのいくつかに対応させて配置され、メモリ空間に対する処理を要求する前記リクエストを前記リクエストポートへ出力する演算処理部をさらに備え、
前記リクエストポートは、前記演算処理部から出力された前記リクエストを受け付け、
前記順序調整部は、前記完了リクエストと同じ前記メモリ空間内のアドレスに対する処理を要求する前記後続リクエストについて、前記制御パイプラインに前記終了処理を行わせる
ことを特徴とする請求項１に記載の演算処理装置。
【請求項３】
前記演算処理部、前記リクエストポート、前記制御パイプライン及び前記順序調整部を有する演算処理グループを複数有し、
第１演算処理グループの前記リクエストポートの一部は、他の演算処理グループからの他グループリクエストを受け付け、
前記第１演算処理グループの前記順序調整部は、前記第１演算処理グループの前記演算処理部からのリクエストがある場合、前記他の演算処理グループからの前記他グループリクエストに対する前記終了処理を前記制御パイプラインに行わせる
ことを特徴とする請求項２に記載の演算処理装置。
【請求項４】
前記第１演算処理グループの前記順序調整部は、前記他の演算処理グループからの前記他グループリクエストに対する前記終了処理の実行回数が閾値以上となった場合、前記制御パイプラインによる前記他グループリクエストに対する前記終了処理を停止させることを特徴とする請求項３に記載の演算処理装置。
【請求項５】
前記リクエストは、前記制御パイプラインを経由して他の処理機構に転送され、前記他の処理機構で処理される要求であることを特徴とする請求項１に記載の演算処理装置。
【請求項６】
演算処理装置の制御方法において、
前記演算処理装置が有する命令制御部が、命令をデコードしてリクエストを発行し、
前記演算処理装置が有する複数のリクエストポートが、受け付けた前記リクエストをそれぞれ出力し、
前記演算処理装置が有する制御パイプラインが、前記リクエストポートから出力されたリクエストが処理実行可能か否かを判定し、前記リクエストが処理実行困難の場合は前記リクエストを破棄して再出力を要求する終了処理を行い、処理実行可能の場合は前記リクエストの要求に応じた要求処理を行うパイプライン処理を実行し、
前記演算処理装置が有する順序調整部が、前記制御パイプラインにより前記要求処理が行われた完了リクエストを出力した完了リクエストポートから出力された後続リクエストについて前記制御パイプラインに前記終了処理を行わせる
ことを特徴とする演算処理装置の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、演算処理装置及び演算処理装置の制御方法に関する。
【背景技術】
【０００２】
ＣＰＵ（Central  Processing  Unit）などのプロセッサは、演算処理を実行するＣＰＵコアを複数有する。以下では、ＣＰＵコアを単に「コア」とよぶ。さらに、プロセッサは、メモリアクセス性能を向上するため複数のレベルのキャッシュを有する。コアは、個々に割り当てられたＬ１（Level  1）キャッシュと呼ばれる第１レベルのキャッシュを占有して利用する。さらに、プロセッサは、複数のコアにより共有される上位レベルのキャッシュを有する。この上位レベルのキャッシュのうちの最上位レベルのキャッシュは、ＬＬＣ（Last  Level  Cache）と呼ばれる。
【０００３】
さらに、プロセッサは、複数のコア及びＬＬＣを有するクラスタに分けられる。クラスタは、他のクラスタとオンチップネットワークで相互に接続される。また、クラスタ間は、各クラスタが有するデータの持ち出しを表す管理表によりキャッシュコヒーレンシが保たれる。この管理表は、クラスタ間のキャッシュ持ち出し状態を記録するためのディレクトリ資源である。
【０００４】
また、オンチップネットワークは、プロセッサの動作クロックに対して非常に遅い低速バスであるチップセットインタフェースに接続される。チップセットインタフェースは、ノンキャッシャブルアクセスによりコアから読み出し及び書き込みが可能な空間を有する。その他に、プロセッサ間を接続するためのインターコネクト及びＰＣＩ（Peripheral  Component  Interconnect）デバイスに接続するためのＰＣＩｅ（Peripheral  Component  Interconnect  Express）バスがオンチップネットワークに接続される。
【０００５】
コアから出力されたリクエストはリクエストポートに一旦保持され、そこからコア間及びポート間に配置されたプライオリティ回路を経て、一つのリクエストが選択された後に、選択されたリクエストがキャッシュ制御パイプラインに投入される。
【０００６】
キャッシュ制御パイプラインは、投入されたリクエストが既に処理中のリクエストのアドレスと競合するかの判定、リクエストに対する処理内容の判定、処理ユニットの回路資源が獲得可能か否かの資源判定などを行う。その後、キャッシュ制御パイプラインは、適切なリクエストについてリクエスト処理ユニット内のリクエスト処理回路に処理を依頼する。
【０００７】
そして、制御パイプラインは、リクエストポートから投入されたリクエストがアドレスの競合の発生や回路資源を獲得できないなどの理由により処理開始できない場合、リクエストをアボート処理してリクエストポートに差し戻す。したがって、例えばアドレスが競合するリクエストの開始済みの処理が完了するまで、他のリクエストにはアボート処理が繰り返えされる。リクエストポート内の他のアドレスのリクエストは、アボートされたリクエストを追い抜いてリクエスト処理ユニットで処理されることが可能である。
【０００８】
このようなリクエストの処理方法として、資源を利用できないリクエストをパイプラインから取り出し、待機後に資源が使用可能になると投入順序を制御する回路を経由してパイプラインへ再度投入する従来技術がある。また、同一リクエスト元の後続リクエストのアクセスラインが同一の場合、前のリクエストのアクセス情報を使用するとともに、他のリクエスト元にラインアドレスを保持するキャッシュディレクトリの使用権を与える従来技術がある。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開平７−７３０３５号公報
【特許文献２】特開昭６４−３７５５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、従来のプロセッサでは、最初にリクエスト処理ユニットの資源を獲得できたリクエストが処理される。そのため、同一のアドレスの異なるリクエストが資源獲得で競合しあう場合、制御パイプラインに投入されたタイミングで資源獲得できたリクエストがその処理が実行されてしまい、特定のリクエストが資源獲得に失敗してアボートを繰り返すおそれがある。一方で、別のリクエストはタイミングよく資源獲得して処理を実行されることがある。この結果、リクエストの要求元の間でまたはリクエスト間で処理の進みやすさに不均衡が生じるというおそれがある。
【００１１】
さらに、この処理の不均衡は、オンチップネットワークにおけるバーチャルチャネル用のバッファ資源などのパイプラインを用いて管理されるその他の資源の競合でも発生するおそれがある。
【００１２】
この点、パイプラインから取り出したリクエストを資源が使用可能になると投入順序を制御してパイプラインへ再投入する従来技術では、資源が確保できる確証はなく、処理が進まないリクエストが発生し、リクエスト間で均衡が取れた処理の実現は困難である。また、同一リクエスト元の後続リクエストのアクセスラインが同一の場合に他のリクエスト元にキャッシュディレクトリの使用権を与える従来技術では、処理が遅れているリクエストの処理が優先されない場合があり、リクエスト間で均衡が取れた処理の実現は困難である。
【００１３】
開示の技術は、上記に鑑みてなされたものであって、リクエストが競合した場合にリクエスト間で均衡が取れた処理を実行し処理速度を向上させる演算処理装置及び演算処理装置の制御方法を提供することを目的とする。
【課題を解決するための手段】
【００１４】
本願の開示する演算処理装置及び演算処理装置の制御方法の一つの態様において、命令制御部は、命令をデコードしてリクエストを発行する。複数のリクエストポートは、前記リクエストを受け付けて出力する。制御パイプラインは、前記リクエストポートから出力されたリクエストが処理実行可能か否かを判定し、前記リクエストが処理実行困難の場合は前記リクエストを破棄して再出力を要求する終了処理を行い、処理実行可能の場合は前記リクエストの要求に応じた要求処理を行うパイプライン処理を実行する。順序調整部は、前記制御パイプラインにより前記要求処理が行われた完了リクエストを出力した完了リクエストポートから出力された後続リクエストについて前記制御パイプラインに前記終了処理を行わせる。
【発明の効果】
【００１５】
１つの側面では、本発明は、リクエストが競合した場合にリクエスト間で均衡が取れた処理を実行し処理速度を向上させることができる。
【図面の簡単な説明】
【００１６】
【図１】図１は、実施例に係るＣＰＵのブロック図である。
【図２】図２は、ＬＬＣの一例の回路図である。
【図３】図３は、処理順調整回路のブロック図である。
【図４】図４は、処理順調整回路の保持情報をまとめた図である。
【図５】図５は、リクエスト投入時の処理開始動作を表すフローチャートである。
【図６】図６は、初回登録処理のフローチャートである。
【図７】図７は、アドレスマッチ有効状態情報設定処理のフローチャートである。
【図８】図８は、後続リクエスト処理のフローチャートである。
【図９】図９は、外部リクエスト有効フラグ設定処理のフローチャートである。
【図１０】図１０は、パイプライン処理完了時の動作のフローチャートである。
【図１１】図１１は、アドレスマッチ有効状態情報リセット処理のフローチャートである。
【図１２】図１２は、従来のＣＰＵによるデータ処理の一例のシーケンス図である。
【図１３】図１３は、実施例に係るＣＰＵによるデータ処理の一例のシーケンス図である。
【発明を実施するための形態】
【００１７】
以下に、本願の開示する演算処理装置及び演算処理装置の制御方法の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する演算処理装置及び演算処理装置の制御方法が限定されるものではない。
【実施例１】
【００１８】
図１は、実施例に係るＣＰＵのブロック図である。演算処理装置であるＣＰＵ１は、命令をデコードして演算処理リクエストを発行する命令制御部（不図示）、演算処理回路（不図示）、Ｌ１命令キャッシュ２１及びＬ１データキャッシュ２２を有するコア２０を複数有する。このコア２０が、「演算処理部」の一例にあたる。Ｌ１命令キャッシュ２１及びＬ１データキャッシュ２２は、図１では、それぞれＬ１Ｉ及びＬ１Ｄと表した。コア２０は、演算処理を実行する。
【００１９】
さらに、ＣＰＵ１は、複数のコア２０が複数のクラスタ１０〜１３に分けられる。各クラスタ１０〜１３は、それぞれに対応して設けられた複数の最上位レベルキャッシュ（ＬＬＣ）１００を有する。このクラスタ１０〜１３が、「演算処理グループ」の一例にあたる。クラスタ１０〜１３は、いずれも同じ機能を有するので、以下では、クラスタ１０を例に説明する。
【００２０】
クラスタ１０に属する複数のコア２０は、クラスタ１０に属するＬＬＣ１００を共有される。すなわち、クラスタ１０は、複数のコア２０及びそれらが共有する１つのＬＬＣ１００をひとまとまりとした演算処理ブロックである。
【００２１】
ＬＬＣ１００は、タグ記憶部１０１、データ記憶部１０２、管理表格納部１０３、制御パイプライン１０４、リクエスト受信部１０５、処理順調整部１０６、ローカルオーダー制御部１０７、ミスアクセス制御部１０８及びプライオリティ制御部１０９を有する。ＬＬＣ１００は、ＭＡＣ（Memory  Access  Controller）３０に接続される。
【００２２】
ＬＬＣ１００は、リクエストにより要求されたデータについてのキャッシュミスが発生した場合、ＭＡＣ３０にデータの取得を依頼する。その後、ＬＬＣ１００は、メモリ４０からＭＡＣ３０が読み出したデータを取得する。ＬＬＣ１００は、ＭＡＣ３０を介して接続するメモリ４０に格納されたデータに対して「ホーム」のＬＬＣ１００と呼ばれる場合がある。
【００２３】
タグ記憶部１０１は、有効ビット、アドレス及び状態などのタグデータを格納する。データ記憶部１０２は、タグデータで示されたアドレスにデータを格納する。
【００２４】
管理表格納部１０３は、ＬＬＣ１００がホームとなるメモリ４０に格納されたデータの現在の位置を表す管理表を格納する。言い換えれば、管理表格納部１０３は、クラスタ１０〜１３の間のデータの持ち出し状態を記録するためのディレクトリ資源を格納する。このディレクトリ資源は、キャッシュコヒーレンシ制御に用いられる。
【００２５】
リクエスト受信部１０５は、各コア２０から出力されたローカルリクエストを受信するポートを有する。また、リクエスト受信部１０５は、クラスタ１０のＬＬＣ１００がホームの場合、他のクラスタ１１〜１３のＬＬＣ１００の制御パイプライン１０４から自己が管理するデータの送信を要求する外部リクエストを受信するポートを有する。また、リクエスト受信部１０５は、クラスタ１０のＬＬＣ１００が他のクラスタ１１〜１３がホームとなるデータを保持する場合、そのデータの他のクラスタ１１〜１３へのオーダーと呼ばれる転送要求を、そのデータのホームとなるクラスタから受信するポートを有する。この外部リクエスト及びオーダーが、「他グループリクエスト」の一例にあたる。
【００２６】
リクエスト受信部１０５は、ローカルリクエスト、外部リクエスト及びオーダーを受け付ける。そして、リクエスト受信部１０５は、ローカルリクエスト、外部リクエスト及びオーダーを保持しつつ、プライオリティ制御部１０９へそれぞれを出力する。その後、リクエスト受信部１０５は、ローカルリクエスト、外部リクエスト又はオーダーに対する完了応答を受けた場合、保持する情報を破棄する。
【００２７】
プライオリティ制御部１０９は、ローカルリクエスト、外部リクエスト及びオーダーをリクエスト受信部１０５から複数取得した場合、いずれか一つを処理対象として選択する。以下では、ローカルリクエスト、外部リクエスト及びオーダーのそれぞれを区別しない場合、単に「リクエスト」と呼ぶ。プライオリティ制御部１０９は、選択したリクエストを制御パイプライン１０４へ投入する。
【００２８】
制御パイプライン１０４は、プライオリティ制御部１０９から投入されたリクエストをパイプライン処理する。パイプライン処理は、処理段階が複数に分かれており、それぞれの処理段階がステージと呼ばれる場合がある。例えば、制御パイプライン１０４は、ステージ０〜ｎのパイプライン処理を行う。その場合、ステージ０の処理が、リクエストが投入された時点の処理である。そして、ステージｎの処理が、パイプライン処理が完了し処理応答を出力する時点の処理である。
【００２９】
例えば、制御パイプライン１０４は、投入されたリクエストがローカルリクエストの場合、クラスタ１０のＬＬＣ１００は、ミスアクセス制御部１０８及びローカルオーダー制御部１０７へアドレスを通知しアボート判定を行わせる。
【００３０】
また、制御パイプライン１０４は、ミスアクセス制御部１０８によるアボート判定と並行して、タグ記憶部１０１を検索する。ローカルリクエストにマッチするタグデータがタグ記憶部１０１に存在する場合、制御パイプライン１０４は、キャッシュヒットと判定する。そして、制御パイプライン１０４は、そのタグデータにより示されるデータをデータ記憶部１０２から取得する。その後、制御パイプライン１０４は、取得したデータをローカルリクエストの送信元へ出力する。また、制御パイプライン１０４は、ローカルリクエストの処理完了をリクエスト受信部１０５に通知する。
【００３１】
一方、ミスアクセス制御部１０８又はローカルオーダー制御部１０７からアボート処理の指示を受けた場合、制御パイプライン１０４は、投入されたローカルリクエストを破棄して、アボート通知をリクエスト受信部１０５へ出力する。これに対して、管理表格納部１０３を確認してデータがクラスタ１０のＬＬＣ１００に存在しないと判定した場合、制御パイプライン１０４は、その時点でデータを有するクラスタ１１〜１３を管理表格納部１０３から取得し、取得したクラスタに対してオーダーを送信する。
【００３２】
これに対して、ローカルリクエストにマッチするタグデータがタグ記憶部１０１に存在しない場合、制御パイプライン１０４は、キャッシュミスと判定する。そして、制御パイプライン１０４は、ミスアクセス制御部１０８にアドレスを格納させるとともに、データの取得要求をＭＡＣ３０へ出力する。その後、制御パイプライン１０４は、ＭＡＣ３０からデータを取得すると、取得したデータをデータ記憶部１０２に格納させ、タグ記憶部１０１に格納したデータを指すタグデータを格納させる。さらに、制御パイプライン１０４は、取得したデータをローカルリクエストの送信元へ出力する。また、制御パイプライン１０４は、ローカルリクエストの処理完了をリクエスト受信部１０５に通知する。
【００３３】
一方、リクエストが示すデータが、クラスタ１０のＬＬＣ１００がホームとなるデータでない場合、制御パイプライン１０４は、そのデータのホームであるクラスタ１１〜１３に対する外部リクエストをオンチップネットワーク７を介して送信する。その後、制御パイプライン１０４は、外部リクエストの送信先からデータの入力をオンチップネットワーク７を介して受ける。そして、制御パイプライン１０４は、処理完了をリクエスト受信部１０５へ通知する。
【００３４】
また、投入されたリクエストが外部リクエストの場合、制御パイプライン１０４は、リクエストの送信元を他のクラスタ１１〜１３として、ローカルリクエストと同様の処理を行う。この場合、制御パイプライン１０４は、取得したデータをリクエストコンプリートと呼ばれる応答を用いてリクエストの送信元のクラスタ１１〜１３へ送信する。この時、制御パイプライン１０４は、管理表格納部１０３に格納された管理表にデータの移動先を登録して、管理表を更新する。
【００３５】
また、投入されたリクエストがオーダーの場合、制御パイプライン１０４は、ローカルオーダー制御部１０７にアドレスを通知してアボート判定を行わせる。ローカルオーダー制御部１０７からアボート処理の指示を受けた場合、制御パイプライン１０４は、投入されたオーダーを破棄して、アボート通知をリクエスト受信部１０５へ出力する。これに対して、ローカルオーダー制御部１０７からアボート処理の指示を受けない場合、制御パイプライン１０４は、自己が有するデータをオーダーで指定された他のクラスタ１１〜１３へオンチップネットワーク７を介して送信する。その後、制御パイプライン１０４は、処理完了をリクエスト受信部１０５へ通知する。
【００３６】
また、リクエストがインターコネクトコントローラ５を介して他のＣＰＵ１へ送信される命令やＰＣＩｅインタフェース６を介してＰＣＩｅバス６０へ送信される命令の場合、制御パイプライン１０４は、リクエストをオンチップネットワーク７へ送出する。ただし、このリクエストのＣＰＵ１への送信は、実際には、メモリ４０に対して直接データの読み書きを行うＤＭＡ（Direct  Memory  Access）転送によりリクエストを送信する。
【００３７】
この場合、制御パイプライン１０４は、リクエストをパケット化してオンチップネットワーク７へ発行する。リクエストがインターコネクトコントローラ５を介して他のＣＰＵ１へ送信される命令やＰＣＩｅインタフェース６を介してＰＣＩｅバス６０へ送信される命令は、ＣＰＵ１の動作クロックに対する遅延がそれほど大きくはない。また、これらの命令は、キャッシュには格納されないノンキャッシャブル（ＮＣ：Non  Cachable）リクエストである。以下では、リクエストがインターコネクトコントローラ５を介して他のＣＰＵ１へ送信される命令やＰＣＩｅインタフェース６を介してＰＣＩｅバス６０へ送信される命令を、「通常ＮＣリクエスト」という。インターコネクトコントローラ５やＰＣＩｅインタフェース６が有する通常ＮＣリクエスト用のバッファが一杯になった場合、制御パイプライン１０４は、その後の通常ＮＣリクエストに対して、バッファが空くまでアボート処理を行う。
【００３８】
また、リクエストがオフチップコントローラ８０へ送信される命令の場合、制御パイプライン１０４は、リクエストをオンチップネットワーク７及びチップセットＩＦ（Interface）８を介して、オフチップコントローラ８０へ送出する。チップセットＩＦ８からオフチップコントローラ８０へ繋がるバスはＣＰＵ１の動作クロックに対して非常に低速である。また、この命令は、キャッシュには格納されないノンキャッシャブルリクエストである。以下では、リクエストがオフチップコントローラ８０へ送信される命令を、「低速ＮＣリクエスト」という。低速ＮＣリクエストは、例えば、ファームやセキュリティメモリに対する命令である。後述するオンチップＩＦ８が有する低速ＮＣリクエスト用のバッファが一杯になった場合、制御パイプライン１０４は、その後の低速ＮＣリクエストに対して、バッファが空くまでアボート処理を行う。この通常ＮＣリクエスト及び低速ＮＣリクエストが、「制御パイプラインを経由して他の処理機構に転送され、他の処理機構で処理される要求」の一例にあたる。
【００３９】
また、制御パイプライン１０４は、投入されたリクエストに対する強制アボートの指示を処理順調整部１０６から受けた場合、リクエストの状態に関わらずリクエストを破棄して、アボート通知をリクエスト受信部１０５へ出力する。
【００４０】
また、リクエストがストアリクエストの場合、制御パイプライン１０４は、ＭＡＣ３０に対してデータの格納要求を送信する。次に、制御パイプライン１０４は、データのストが完了するまで、リクエストで指定されたアドレスを保持する。そして、制御パイプライン１０４は、同一アドレスに対するストアリクエストに対してアボート処理を行う。制御パイプライン１０４は、データ格納完了の通知をＭＡＣ３０から受けて、保持するアドレスを開放する。
【００４１】
ローカルオーダー制御部１０７は、コア２０が出力したリクエストやＬＬＣ１００の配下のコア２０に対する外部リクエストやオーダーをきっかけとして発生したリクエストに対するオーダー処理発行済みアドレスを保持する。ローカルオーダー制御部１０７は、コア２０から出力された新規リクエストや外部リクエストやオーダーの指定するアドレスが、保持するアドレスにマッチした場合、制御パイプライン１０４にそのリクエストのアボート処理を行わせる。
【００４２】
ミスアクセス制御部１０８は、キャッシュミスのアドレスを保持する。ミスアクセス制御部１０８は、コア２０から出力されたリクエストが保持するアドレスにマッチした場合、制御パイプライン１０４にそのリクエストのアボート処理を行わせる。制御パイプライン１０４がＭＡＣ３０からキャッシュミスしたデータを取得した場合、ミスアクセス制御部１０８は、制御パイプライン１０４からの通知を受けて保持するアドレスを開放する。
【００４３】
処理順調整部１０６は、制御パイプラインに投入されたリクエストの情報の入力を受ける。そして、処理順調整部１０６は、投入されたリクエストについてアボート判定を行う。リクエストをアボートさせると判定した場合、処理順調整部１０６は、強制アボートの指示を制御パイプライン１０４へ出力する。処理順調整部１０６によるアボート判定については後で詳細に説明する。
【００４４】
ＭＡＣ３０〜３３は、制御パイプライン１０４からデータの取得要求を受けて、指定されたデータをメモリ４０〜４３から読み出す。そして、ＭＡＣ３０〜３３は、読み出したデータを制御パイプライン１０４へ送信する。
【００４５】
ＭＡＣ３０〜３３は、制御パイプライン１０４からデータの格納要求を受けて、メモリ４０〜４３の指定されたアドレスにデータを格納する。格納が完了すると、ＭＡＣ３０〜３３は、データの格納完了の通知を制御パイプライン１０４へ出力する。
【００４６】
オンチップネットワーク７は、クラスタ１０〜１３のＬＬＣ１００、インターコネクトコントローラ５、ＰＣＩｅインタフェース６及びチップセットＩＦ８が接続される。オンチップネットワーク７は、複数のメッセージクラスにより分類されるバーチャルチャネル（ＶＣ：Virtual  Channel）を有する。バーチャルチャネルには、例えば、外部リクエストＶＣ、オーダーＶＣ、リクエストコンプリートＶＣ、オーダーコンプリートＶＣ、通常ＮＣリクエストＶＣ及び低速ＮＣリクエストＶＣなどが存在する。通常ＮＣリクエストＶＣ及び低速ＮＣリクエストＶＣは、いずれもノンキャッシャブルアクセス用のバーチャルチャネルである。低速ＮＣリクエストＶＣは、オフチップの低速バスであるチップセットＩＦ８宛てのリクエスト用のバーチャルチャネルであり、それ以外のメモリマップドレジスタは通常ＮＣリクエストＶＣを使って転送される。これにより、低速ＮＣリクエストＶＣが低速バスに降り滞留しても、通常ＮＣリクエストＶＣは分離されているため制御パイプライン１０４は新たなリクエストが通常ＮＣリクエストＶＣへ発行可能である。オンチップネットワーク７の内部には、バーチャルチャネル毎のバッファが存在し、その資源数管理をリクエストの発行側である制御パイプライン１０４が行う。
【００４７】
図２は、ＬＬＣの一例の回路図である。ＬＬＣ１００は、図２に示すように、ローカルリクエストポート１１１〜１１３、外部リクエストポート１２１、オーダーポート１２２及びＭＩＢ（Move  In  Buffer）ポート１２３を有する。さらに、ＬＬＣ１００は、プライオリティ回路１３１、キャッシュ制御パイプライン１３２、タグＲＡＭ（Random  Access  Memory）１３３、データＲＡＭ１３４、オーダロック回路１３５、ストアロック回路１３７及び持出管理表１３８を有する。
【００４８】
ローカルリクエストポート１１１〜１１３、外部リクエストポート１２１、オーダーポート１２２及びＭＩＢポート１２３は、図１に示すリクエスト受信部１０５の機能を実現する。このローカルリクエストポート１１１〜１１３、外部リクエストポート１２１及びオーダーポート１２２が、「リクエストポート」の一例にあたる。
【００４９】
ローカルリクエストポート１１１〜１１３は、それぞれ異なるコア２０に接続される。ローカルリクエストポート１１１〜１１３は、ローカルリクエストの入力を受けるポートである。以下では、ローカルリクエストポート１１１〜１１３を区別しない場合、ローカルリクエストポート１１０という。
【００５０】
外部リクエストポート１２１及びオーダーポート１２２は、オンチップネットワーク７を介して他のクラスタ１１〜１３に接続される。ただし、図２ではオンチップネットワーク７を省略した。外部リクエストポート１２１は、他のクラスタ１１〜１３から送信された外部リクエストの入力を受けるポートである。オーダーポート１２２は、他のクラスタ１１〜１３から送信されたオーダーリクエストの入力を受けるポートである。
【００５１】
ＭＩＢポート１２３は、ＭＡＣ３０に接続される。ＭＩＢポート１２３は、ＭＡＣ３０からメモリ４０から読み出されたデータの入力を受けるポートである。
【００５２】
プライオリティ回路１３１は、図１に例示したプライオリティ制御部１０９の機能を実現する。プライオリティ回路１３１は、ローカルリクエストポート１１１〜１１３、外部リクエストポート１２１、オーダーポート１２２及びＭＩＢポート１２３から入力されたリクエストの中から１つのリクエストを選択してキャッシュ制御パイプライン１３２へ投入する。
【００５３】
キャッシュ制御パイプライン１３２は、図１に例示した制御パイプライン１０４の機能を実現する。キャッシュ制御パイプライン１３２は、ステージ０〜ｎのステージ０のパイプライン処理を実行する。キャッシュ制御パイプライン１３２は、ステージ０においてプライオリティ回路１３１から投入されたリクエストを、タグＲＡＭ１３３、データＲＡＭ１３４、オーダロック回路１３５、ＭＩＢ回路１３６、ストアロック回路１３７及び持出管理回路１３８を用いてパイプライン処理する。また、キャッシュ制御パイプライン１３２は、ステージｎにおいて処理が完了したリクエストの処理応答を処理順調整回路２００及びリクエストの送信元のリクエストポートへ通知する。また、キャッシュ制御パイプライン１３２は、処理順調整回路２００からの強制アボートの指示を受けて、投入されたリクエストに対してアボート処理を行う。このアボート処理が「終了処理」の一例にあたる。ここでは、キャッシュ制御パイプライン１３２によるパイプライン処理が、０〜ｎステップまでの段階で処理される場合で説明する。このキャッシュ制御パイプライン１３２が、「制御パイプライン」の一例にあたる。
【００５４】
タグＲＡＭ１３３は、図１に例示したタグ記憶部１０１の機能を実現する。また、データＲＡＭ１３４は、図１に例示したデータ記憶部１０２の機能を実現する。タグＲＡＭ１３３は、データＲＡＭ１３４のキャッシュラインに関するタグデータを格納する。
【００５５】
オーダロック回路１３５は、図１に例示したローカルオーダー制御部１０７の機能を実現する。オーダロック回路１３５は、コア２０に対してのオーダー処理発行済みアドレスを記録するロック資源である。オーダロック回路１３５は、新規リクエストが保持するアドレスにマッチした場合は、オーダー処理が完了するまでそのアドレスに対するオーダーをアボートさせる。
【００５６】
ＭＩＢ回路１３６は、図１に例示したミスアクセス制御部１０８の機能を実現する。ＭＩＢ回路１３６は、キャッシュミスアドレスを保持する。そして、ＭＩＢ回路１３６は、リクエストが指定するアドレスが保持するとマッチした場合、そのリクエストが要求するデータのメモリ４０への取得を行う先行リクエストが存在することを示すので、そのリクエストをアボートさせる。
【００５７】
ストアロック回路１３７は、ＭＡＣ３０に対してストアリクエストを発行したアドレスを記録するロック資源である。ストアロック回路１３７は、ストア順序が確定した通知をＭＡＣ３０から受けるまで同一アドレスの後続のストアリクエストをアボートさせる。
【００５８】
持出管理回路１３８は、図１に例示した管理表格納部１０３の機能を実現する。持出管理回路１３８は、クラスタ間のキャッシュコヒーレンシ制御に用いられる。
【００５９】
処理順調整回路２００は、処理順調整部１０６の機能を実現する。図３は、処理順調整回路のブロック図である。処理順調整回路２００は、図３に示すように、全体動作管理部２０１、モード管理部２０２、対象アドレス保持部２０３、待ちリクエスト管理部２０４及びアドレスマッチ判定部２０５を有する。さらに、処理順調整回路２００は、パイプライン制御部２０６、外部リクエストポート管理部２０７、オーダーポート管理部２０８及びアボートカウンタ２０９を有する。
【００６０】
また、図４は、処理順調整回路の保持情報をまとめた図である。処理順調整回路２００は、全体動作情報３０１、モード識別情報３０２、アドレスマッチ有効状態情報３０３、アボートカウンタ２０９、待ちリクエストリスト３０５及び対象アドレス情報３０６を有する。
【００６１】
全体動作情報３０１は、処理順調整回路２００がリクエストの処理順の監視を行っているか否かを示す全体有効フラグを表す情報である。全体有効フラグは、フラグが立っていれば処理順調整回路２００がリクエストの処理順の監視を行っていることを表し、フラグが立っていなければ処理順調整回路２００がリクエストの処理順の監視を行っていないことを表す。全体動作情報３０１は、例えば、全体動作管理部２０１により保持される。
【００６２】
モード識別情報３０２は、アドレス競合モード、通常資源競合モード及び低速資源競合モードという３つの監視モードのいずれで処理順調整回路２００が動作中かを表す情報である。アドレス競合モードとは、ローカルリクエスト、外部リクエスト及びオーダーの競合を監視するモードである。通常資源競合モードは、通常ＮＣリクエストの競合を監視するモードである。低速資源競合モードは、低速ＮＣリクエストの競合を監視するモードである。モード識別情報３０２は、例えば、モード管理部２０２により保持される。
【００６３】
アドレスマッチ有効状態情報３０３は、リクエストで指定されたデータに対してＬＬＣ１００がホームの場合、外部リクエストの監視が有効であるか無効であるかを示す外部リクエスト有効フラグを表す情報である。外部リクエスト有効フラグが立っていれば、外部リクエストの監視が有効である。リクエストで指定されたデータに対してＬＬＣ１００がホームの場合、アドレスマッチ有効状態情報３０３は、外部リクエストポート管理部２０７により保持される。
【００６４】
また、リクエストで指定されたデータに対してＬＬＣ１００がホームでない場合、アドレスマッチ有効状態情報３０３は、オーダーの監視が有効であるか無効であるかを示すオーダー有効フラグを表す情報である。オーダー有効フラグが立っていれば、オーダーの監視が有効である。リクエストで指定されたデータに対してＬＬＣ１００がホームでない場合、アドレスマッチ有効状態情報３０３は、オーダーポート管理部２０８により保持される。
【００６５】
アボートカウンタ２０９は、オーダーのアボート回数を表すカウンタ値を保持する。
【００６６】
待ちリクエストリスト３０５は、コア２０毎に、ウェイトビット、完了ビット及びエントリＩＤ（Identifier）が登録される。ウェイトビットは、待ちリクエストであるローカルリクエストが存在するか否かを表す。完了ビットは、待ちリクエストとなったローカルリクエストの処理が完了したか否かを表す。エントリＩＤは、コア２０に対応するローカルリクエストポート１１０の資源のエントリ番号を表す。例えば、ローカルリクエストポート１１０が４エントリを有する場合、エントリＩＤは、２ビットの情報となる。図４では、クラスタ１０が有するコア２０をそれぞれコア＃００〜＃ｘｘと表した。ここでは、ウェイトビットが１の場合、そのコア２０のエントリＩＤから発行されたリクエストが待ちリクエストとなったことを表す。これに対して、ウェイトビットが０の場合、そのコア２０から出力されたリクエストに待ちリクエストが存在しないことを表す。
【００６７】
また、待ちリクエストリスト３０５は、クラスタ１１〜１３に対応させて、ウェイトビット、完了ビット及びエントリＩＤが登録される。例えば、外部リクエストポート１２１が８エントリを有する場合、エントリＩＤは、３ビットの情報となる。また、待ちリクエストリスト３０５は、オーダーポート１２２に対応させて、ウェイトビット及びエントリＩＤが登録される。待ちリクエストリスト３０５は、例えば、待ちリクエスト管理部２０４により保持される。
【００６８】
対象アドレス情報３０６は、ローカルリクエスト、外部リクエスト及びオーダーの競合を監視する場合の、監視対象とするアドレス値である。対象アドレス情報３０６は、例えば、対象アドレス保持部２０３により保持される。
【００６９】
以下に、図３及び４を参照して、処理順調整回路２００の詳細について説明する。この処理順調整回路２００が、「順序調整部」の一例にあたる。
【００７０】
全体動作管理部２０１は、パイプライン処理のステージ０においてキャッシュ制御パイプライン１３２に投入されたリクエストの情報をプライオリティ回路１３１から取得する。リクエストの情報には、リクエストの種別、アドレス、送信元の情報などが含まれる。次に、全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを確認して、リクエストの処理順の監視が実行中か否かを判定する。
【００７１】
監視が実行中でない場合、全体動作管理部２０１は、モード管理部２０２及び待ちリクエスト管理部０２４にリクエストの情報を送るとともに初回登録の実行を指示する。その後、投入されたリクエストが監視対象となる場合、全体動作管理部２０１は、監視開始の通知をモード管理部２０２から受ける。そして、全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを監視実行中に変更し、監視動作を開始する。投入されたリクエストが監視対象とならない場合、全体動作管理部２０１は、監視動作を行わずに処理を終了する。
【００７２】
これに対して、監視が実行中の場合、全体動作管理部２０１は、モード管理部２０２及び待ちリクエスト管理部０２４にリクエストの情報を送るとともに後続リクエスト処理の実行を指示する。ここで、後続リクエストとは、既にパイプラインに投入されたリクエストと競合する後発のリクエストを指す。
【００７３】
その後、全体動作管理部２０１は、監視の終了の通知を待ちリクエスト管理部２０４から受ける。そして、全体動作管理部２０１は、全体動作情報３０１における全体有効フラグを監視動作無効を表す状態に変更して監視動作を終了する。
【００７４】
モード管理部２０２は、初回登録の実行の指示を全体動作管理部２０１から受ける。さらに、モード管理部２０２は、リクエストの情報を全体動作管理部２０１から取得する。そして、モード管理部２０２は、取得したリクエストの情報からリクエスト種別を判定する。
【００７５】
次に、モード管理部２０２は、リクエスト種別から、取得したリクエストに対する監視モードがアドレス競合モード、通常資源競合モード又は低速資源競合モードのいずれかを判定する。具体的には、モード管理部２０２は、リクエスト種別がローカルリクエストの場合にアドレス競合モードによる監視を実行すると判定する。また、リクエスト種別がＮＣ通常リクエストの場合、モード管理部２０２は、通常資源競合モードによる監視を実行すると判定する。また、リクエスト種別がＮＣ低速リクエストの場合、モード管理部２０２は、低速資源競合モードによる監視を実行すると判定する。
【００７６】
アドレス競合モードで動作する場合、モード管理部２０２は、モード識別情報３０２をアドレス競合モードに設定する。次に、モード管理部２０２は、監視開始を全体動作管理部２０１に通知する。次に、モード管理部２０２は、アドレス競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。さらに、モード管理部２０２は、リクエストの情報に含まれるアドレスを対象アドレス保持部２０３に通知する。
【００７７】
通常資源競合モードで動作する場合、モード管理部２０２は、モード識別情報３０２を通常資源競合モードに設定する。次に、モード管理部２０２は、監視開始を全体動作管理部２０１に通知する。さらに、モード管理部２０２は、通常資源競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。
【００７８】
低速資源競合モードで動作する場合、モード管理部２０２は、モード識別情報３０２を低速資源競合モードに設定する。次に、モード管理部２０２は、低速資源競合モードによる監視開始を全体動作管理部２０１に通知する。さらに、モード管理部２０２は、低速資源競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。
【００７９】
これに対して、投入されたリクエストが監視対象とならない場合、モード管理部２０２は、監視を行わないと判定する。リクエストが、アドレス競合モード、通常資源競合モード及び低速資源競合モードという３つの監視モードのいずれの対象にも当たらない場合とは、例えば、リクエストがシステムレジスタアクセスなどの場合である。その後、モード管理部２０２は、全体動作管理部２０１に監視動作の停止を指示し、登録処理を終了する。
【００８０】
監視が実行中の場合、モード管理部２０２は、後続リクエスト処理の実行の指示を全体動作管理部２０１から受ける。さらに、モード管理部２０２は、キャッシュ制御パイプライン１３２に投入されたリクエストの情報を全体動作管理部２０１から取得する。そして、モード管理部２０２は、取得したリクエストの情報からリクエスト種別を判定する。また、モード管理部２０２は、モード識別情報３０２を確認し、現在の監視モードを特定する。
【００８１】
次に、モード管理部２０２は、投入されたリクエストが動作中の監視モードの監視対象にあたるか否か判定する。投入されたリクエストが動作中の監視モードの監視対象にあたらない場合、モード管理部２０２は、待ちリクエスト管理部２０４及びパイプライン制御部２０６に対して、アボート指示を送らずにリクエストをキャッシュ制御パイプライン１３２へ投入させる処理を実行させる。
【００８２】
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合、モード管理部２０２は、リクエストの情報とともにアドレスの確認依頼をアドレスマッチ判定部２０５へ出力する。また、監視モードが通常資源競合モードで且つリクエストが監視対象の場合、モード管理部２０２は、ＮＣ通常リクエストについての待ちリクエストの判定依頼を待ちリクエスト管理部２０４へ出力する。また、監視モードが低速資源競合モードで且つリクエストが監視対象の場合、モード管理部２０２は、ＮＣ低速リクエストについての待ちリクエストの判定依頼を待ちリクエスト管理部２０４へ出力する。
【００８３】
対象アドレス保持部２０３は、モード管理部２０２から通知されたキャッシャブルリクエストによる要求の対象となるアドレスを記憶して保持する。
【００８４】
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合、アドレスマッチ判定部２０５は、リクエストの情報とともにアドレスの確認依頼の入力をモード管理部２０２から受ける。次に、アドレスマッチ判定部２０５は、リクエストの情報からリクエストが指定するアドレスを取得する。そして、アドレスマッチ判定部２０５は、対象アドレス情報３０６から監視対象のアドレスを取得し、リクエストが指定するアドレスと一致するか否かを判定する。アドレスが一致しなければ、アドレスマッチ判定部２０５は、アドレスの不一致を待ちリクエスト管理部２０４へ出力する。アドレスが一致した場合、アドレスマッチ判定部２０５は、リクエストの情報とともに待ちリクエストの判定依頼を待ちリクエスト管理部２０４へ出力する。
【００８５】
初回登録処理の場合、待ちリクエスト管理部２０４は、監視モードの情報とともに監視開始の指示をモード管理部２０２から受ける。また、また、待ちリクエスト管理部２０４は、リクエストの情報の入力を全体動作管理部２０１から受ける。
【００８６】
投入されたリクエストがキャッシャブルリクエストであれば、待ちリクエスト管理部２０４は、アドレス競合モードによる監視開始時の指示をモード管理部２０２から受ける。次に、待ちリクエスト管理部２０４は、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する。
【００８７】
次に、待ちリクエスト管理部２０４は、リクエストが要求するデータのホームはクラスタ１０か否かを判定する。クラスタ１０がホームでない場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３におけるオーダー有効フラグの設定処理の実行をオーダーポート管理部２０８に指示する。これに対して、クラスタ１０がホームの場合、待ちリクエスト管理部２０４は、外部リクエスト有効フラグの設定処理の実行を外部リクエストポート管理部２０７に指示するとともにリクエストの情報を送信する。
【００８８】
リクエストがＮＣ通常リクエストであれば、待ちリクエスト管理部２０４は、通常資源競合モードによる監視開始の指示をモード管理部２０２から受ける。次に、待ちリクエスト管理部２０４は、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０の情報及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する。
【００８９】
リクエストがＮＣ低速リクエストであれば、待ちリクエスト管理部２０４は、低速資源競合モードによる監視開始の指示をモード管理部２０２から受ける。次に、待ちリクエスト管理部２０４は、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０の情報及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する。
【００９０】
後続リクエスト処理の場合、待ちリクエスト管理部２０４は、以下の処理を実行する。監視モードがアドレス競合モードで且つリクエストが監視対象であって、リクエストが指定したアドレスが対象アドレス情報３０６に一致すると、待ちリクエスト管理部２０４は、待ちリクエストの判定依頼をアドレスマッチ判定部２０５から受ける。さらに、待ちリクエスト管理部２０４は、リクエストの情報の入力をアドレスマッチ判定部２０５から受ける。次に、待ちリクエスト管理部２０４は、リクエストの情報を用いて、リクエストがローカルリクエスト、外部リクエスト又はオーダーのいずれであるかを判定する。
【００９１】
リクエストがローカルリクエストの場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３を用いて外部リクエスト監視が有効か否かを判定する。外部リクエスト監視が無効であれば、待ちリクエスト管理部２０４は、外部リクエスト監視開始の判定処理の実行を外部リクエストポート管理部２０７に指示する。
【００９２】
次に、待ちリクエスト管理部２０４は、リクエストの情報から送信元のコア２０の情報を取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部２０４は、そのコア２０から出力されたリクエストと同じアドレスに対するローカルリクエストが要求した処理が完了済みか否かを判定する。以下では、リクエストが要求した処理が完了したことを、「要求処理の完了」という。この要求処理が完了したリクエストが「完了リクエスト」の一例にあたる。
【００９３】
要求処理が完了済みの場合、待ちリクエスト管理部２０４は、投入されたローカルリクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
【００９４】
ウェイトビットが１であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部２０４は、投入されたローカルリクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、ウェイトビットが０であり、待ちリクエストが存在しない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを１にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【００９５】
リクエストが外部リクエストの場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３を確認して、外部リクエスト監視が有効か否かを判定する。外部リクエスト監視が有効であれば、待ちリクエスト管理部２０４は、リクエストの情報から送信元のクラスタ１１〜１３の情報を取得する。以下では、送信元のクラスタ１１〜１３を送信元クラスタと言う。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元クラスタの欄における完了ビットの値を確認する。そして、待ちリクエスト管理部２０４は、その送信元クラスタから出力されたリクエストと同じアドレスに対する外部リクエストの要求処理が完了済みか否かを判定する。
【００９６】
要求処理が完了済みの場合、待ちリクエスト管理部２０４は、投入された外部リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元クラスタの欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
【００９７】
ウェイトビットが１であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部２０４は、投入された外部リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、ウェイトビットが０であり、待ちリクエストが存在しない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元クラスタの欄におけるウェイトビットを１にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【００９８】
これに対して、外部リクエスト監視が無効の場合、待ちリクエスト管理部２０４は、外部リクエスト監視開始の判定処理の実行を外部リクエストポート管理部２０７に指示する。
【００９９】
リクエストがオーダーの場合、待ちリクエスト管理部２０４は、オーダー有効フラグの設定処理の実行指示をオーダーポート管理部２０８へ出力する。その後、待ちリクエスト管理部２０４は、オーダーの判定依頼の入力をオーダーポート管理部２０８から受ける。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のオーダーポートの欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
【０１００】
ウェイトビットが０であり、待ちリクエストが存在しない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５におけるオーダーポートの欄におけるウェイトビットを１にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【０１０１】
一方、監視モードが通常資源競合モードで且つリクエストが監視対象である場合、待ちリクエスト管理部２０４は、ＮＣ通常リクエストについての待ちリクエストの判定依頼をモード管理部２０２から受ける。次に、待ちリクエスト管理部２０４は、リクエストの情報から送信元のコア２０の情報を取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部２０４は、そのコア２０から出力されたＮＣ通常リクエストの要求処理が完了済みか否かを判定する。
【０１０２】
要求処理が完了済みの場合、待ちリクエスト管理部２０４は、投入されたＮＣ通常リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
【０１０３】
ウェイトビットが１であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部２０４は、投入されたＮＣ通常リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、ウェイトビットが０であり、待ちリクエストが存在しない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを１にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【０１０４】
また、監視モードが低速資源競合モードで且つリクエストが監視対象である場合、待ちリクエスト管理部２０４は、ＮＣ低速リクエストについての待ちリクエストの判定依頼をモード管理部２０２から受ける。次に、待ちリクエスト管理部２０４は、リクエストの情報から送信元のコア２０の情報を取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄における完了ビットの値を確認する。そして、待ちリクエスト管理部２０４は、そのコア２０から出力されたＮＣ低速リクエストの要求処理が完了済みか否かを判定する。
【０１０５】
要求処理が完了済みの場合、待ちリクエスト管理部２０４は、投入されたＮＣ低速リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、要求処理が完了していない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する。
【０１０６】
ウェイトビットが１であり、既に待ちリクエストが存在し待ちリクエストの保持が困難な場合、待ちリクエスト管理部２０４は、投入されたＮＣ低速リクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。これに対して、ウェイトビットが０であり、待ちリクエストが存在しない場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元のコア２０の欄におけるウェイトビットを１にして待ちリクエストを追加登録する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【０１０７】
また、リクエストが動作中の監視モードの監視対象にあたらない場合、待ちリクエスト管理部２０４は、判定処理を終了する。この場合、待ちリクエスト管理部２０４は、強制アボートの実行の指示を行わない。
【０１０８】
キャッシュ制御パイプライン１３２による投入されたリクエストに対するパイプライン処理が完了すると、待ちリクエスト管理部２０４は、処理応答の入力をパイプライン制御部２０６から受ける。キャッシュ制御パイプラインによる投入されたリクエストに対するパイプライン処理は、要求処理の実行又はアボート処理のいずれかである。
【０１０９】
次に、待ちリクエスト管理部２０４は、リクエストの送信元の情報及びエントリＩＤを処理応答から取得する。そして、待ちリクエスト管理部２０４は、送信元の情報及びエントリＩＤが一致する情報が待ちリクエストリスト３０５に存在するか否か、すなわちパイプライン処理完了したリクエストが待ちリクエストか否かを判定する。リクエストが待ちリクエストでない場合、待ちリクエスト管理部２０４は、パイプライン処理完了時の処理を終了させる。
【０１１０】
これに対して、リクエストが待ちリクエストの場合、待ちリクエスト管理部２０４は、処理応答がアボート通知か否かを判定する。処理応答が要求処理の完了通知の場合、待ちリクエスト管理部２０４は、要求処理が完了したリクエストがオーダーか否かを判定する。リクエストがオーダー以外の場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における要求処理が完了したリクエストに対応する欄の完了ビットを１に設定して完了フラグを追加する。これに対して、リクエストがオーダーの場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５におけるオーダーポートのウェイトビットを０にして待ちリクエストを無くす。
【０１１１】
次に、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５に登録されたローカルリクエストの待ちリクエストが全て完了したか否かを判定する。待ちリクエストリスト３０５に登録されたローカルリクエストの待ちリクエストが全て完了した場合、待ちリクエスト管理部２０４は、クラスタ１０が監視対象のリクエストが要求するデータのホームか否かを判定する。
【０１１２】
クラスタ１０が監視対象のリクエストが要求するデータのホームの場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３のリセットを外部リクエストポート管理部２０７に指示する。これに対して、クラスタ１０が監視対象のリクエストが要求するデータのホームでない場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３のリセットをオーダーポート管理部２０８に指示する。これに対して、ローカルリクエストで処理されていない待ちリクエストが残っている場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３の状態を維持する。
【０１１３】
その後、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５に登録された全ての待ちリクエストの要求処理が完了したが否かを判定する。全ての待ちリクエストの要求処理が完了した場合、待ちリクエスト管理部２０４は、監視の終了を全体動作管理部２０１に通知する。これに対して、要求した処理が完了していない待ちリクエストが残っている場合、待ちリクエスト管理部２０４は、リクエストの監視を継続する。
【０１１４】
一方、処理応答がアボート処理の場合、待ちリクエスト管理部２０４は、パイプライン処理が完了したリクエストがオーダーか否かを判定する。リクエストがオーダーでない場合、待ちリクエスト管理部２０４は、そのままリクエストの監視を継続する。
【０１１５】
これに対して、リクエストがオーダーの場合、待ちリクエスト管理部２０４は、オーダーのアボートをオーダーポート管理部２０８へ通知する。その後、待ちリクエスト管理部２０４は、リクエストの監視を継続する。
【０１１６】
オーダーを受信する可能性があるクラスタ１０は、投入されたリクエストのホームである。そして、オーダーポート管理部２０８は、リクエストがキャッシャブルリクエストの場合、初回登録処理時に、オーダー有効フラグの設定指示を待ちリクエスト管理部２０４から受ける。そして、オーダーポート管理部２０８は、アドレスマッチ有効状態情報３０３におけるオーダー有効フラグを１に設定する。これにより、オーダー監視が有効になる。さらに、オーダーポート管理部２０８は、アボートカウンタ２０９を初期化して、カウンタ値を０に設定する。
【０１１７】
後続リクエスト処理において、投入されたリクエストがオーダーの場合、オーダーポート管理部２０８は、オーダー有効フラグの設定処理の実行指示を待ちリクエスト管理部２０４から受ける。次に、オーダーポート管理部２０８は、アドレスマッチ有効状態情報３０３を参照してオーダー監視が有効か否かを判定する。オーダー監視が有効の場合、オーダーポート管理部２０８は、オーダーの判定依頼を待ちリクエスト管理部２０４へ出力する。
【０１１８】
これに対して、オーダー監視が無効の場合、オーダーポート管理部２０８は、ホームのクラスタ１０から応答されたデータをキャッシュに格納する際に、アドレスマッチ有効状態情報３０３においてオーダー有効フラグを１に設定する。これによりオーダー監視が有効となる。オーダーポート管理部２０８は、アボートカウンタ２０９を初期化して、カウンタ値を０にする。その後、オーダーポート管理部２０８は、オーダーの判定依頼を待ちリクエスト管理部２０４へ出力する。
【０１１９】
リクエストの要求処理が完了し、クラスタ１０が監視対象のリクエストが要求するデータのホームでない場合、オーダーポート管理部２０８は、アドレスマッチ有効状態情報３０３のリセットの指示を待ちリクエスト管理部２０４から受ける。そして、オーダーポート管理部２０８は、アドレスマッチ有効状態情報３０３のオーダー有効フラグを０に設定する。これにより、オーダー監視が無効となる。
【０１２０】
パイプライン処理でオーダーのアボート処理が行われた場合、オーダーポート管理部２０８は、オーダーのアボートの通知を待ちリクエスト管理部２０４から受ける。そして、オーダーポート管理部２０８は、アボートカウンタ２０９のカウンタ値を１つインクリメントする。
【０１２１】
次に、オーダーポート管理部２０８は、アボートカウンタ２０９のカウンタ値が閾値以上であるか否かを判定する。アボートカウンタ２０９のカウンタ値が閾値以上の場合、アドレスマッチ有効状態情報３０３におけるオーダー有効フラグを０に設定して、オーダー監視を無効にする。アボートカウンタ２０９のカウンタ値の閾値は、オーダーの要求処理の実行を停止することで処理が進まない状態に陥っていることを検出できる値であればよい。例えば、オーダーのアボートが９回行われた場合にＣＰＵ１のキャッシャブルリクエストの処理が停滞している可能性が高いと考えられるならば、閾値を９に設定することができる。
【０１２２】
外部リクエストポート管理部２０７は、リクエストがキャッシャブルリクエストの場合、クラスタ１０が投入されたリクエストのホームであれば、初回登録処理時に、外部リクエスト有効フラグの設定処理の実行指示を待ちリクエスト管理部２０４から受ける。さらに、外部リクエストポート管理部２０７は、リクエストの情報を待ちリクエスト管理部２０４から取得する。そして、外部リクエストポート管理部２０７は、リクエスト情報を用いてリクエストが排他性を有するローカルリクエストか否かを判定する。
【０１２３】
リクエストが排他性を有するリクエストの場合、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを１に設定する。これにより、外部リクエスト監視が有効になる。これに対して、リクエストが排他性を有するリクエストでない場合、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを０に設定する。これにより、外部リクエスト監視は無効となる。
【０１２４】
後続リクエスト処理において、投入されたリクエストがローカルリクエストであり、外部リクエスト監視が無効の場合、外部リクエストポート管理部２０７は、外部リクエスト監視開始の判定処理の実行の指示を待ちリクエスト管理部２０４から受ける。そして、外部リクエストポート管理部２０７は、以下の外部リクエスト監視開始の判定処理を実行する。
【０１２５】
外部リクエストポート管理部２０７は、投入されたリクエストが排他性を有するローカルリクエストか否かを判定する。リクエストが排他性を有するローカルリクエストの場合、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３において外部リクエスト有効フラグを１に設定する。これにより、外部リクエスト監視が有効になる。
【０１２６】
これに対して、リクエストが排他性を有するローカルリクエストでない場合、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３である外部リクエスト有効フラグを０のまま維持する。この場合、外部リクエスト監視は無効のままとなる。
【０１２７】
また、後続リクエスト処理において、投入されたリクエストが外部リクエストであり、外部リクエスト監視が無効の場合、外部リクエストポート管理部２０７は、外部リクエスト監視開始の判定処理の実行の指示を待ちリクエスト管理部２０４から受ける。そして、外部リクエストポート管理部２０７は、外部リクエスト監視開始の判定処理を実行する。
【０１２８】
パイプライン処理が完了し、クラスタ１０が監視対象のリクエストが要求するデータのホームの場合、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３のリセットの指示を待ちリクエスト管理部２０４から受ける。そして、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを０に設定する。これにより、外部リクエスト監視が無効となる。
【０１２９】
初回登録処理時には、パイプライン制御部２０６は、キャッシュ制御パイプライン１３２に対して強制アボート処理を指示せず、キャッシュ制御パイプライン１３２に投入されたリクエストに対しての通常のパイプライン処理を継続させる。
【０１３０】
後続リクエスト処理時には、パイプライン制御部２０６は、投入されたリクエストに対する強制アボートの実行の指示を待ちリクエスト管理部２０４から受ける。そして、パイプライン制御部２０６は、強制アボートをキャッシュ制御パイプライン１３２に指示する。これにより、キャッシュ制御パイプライン１３２は、投入されたリクエストのアボート処理を行う。
【０１３１】
パイプライン制御部２０６は、パイプライン処理のステージｎのタイミング、すなわちパイプライン処理が完了すると処理の結果により要求処理の完了通知又はアボート処理の通知のいずれかの処理応答をキャッシュ制御パイプライン１３２から受ける。処理応答には、リクエストの送信元の情報及びエントリＩＤが含まれる。そして、パイプライン制御部２０６は、受信した処理応答を待ちリクエスト管理部２０４へ出力する。
【０１３２】
次に、図５を参照して、リクエスト投入時のＣＰＵ１の処理開始動作を説明する。図５は、リクエスト投入時の処理開始動作を表すフローチャートである。
【０１３３】
全体動作管理部２０１は、キャッシュ制御パイプライン１３２に投入されたリクエストの情報をプライオリティ回路１３１から取得する（ステップＳ１）。リクエストの情報には、アドレスなどが含まれる。
【０１３４】
次に、全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを確認して、リクエストの処理順の監視が実行中か否かを判定する（ステップＳ２）。
【０１３５】
監視が実行中でない場合（ステップＳ２：否定）、全体動作管理部２０１は、モード管理部２０２及び待ちリクエスト管理部０２４にリクエストの情報を送るとともに初回登録の実行を指示する。これにより、処理順調整回路２００は、初回登録処理を実行する（ステップＳ３）。
【０１３６】
これに対して、監視が実行中の場合（ステップＳ２：肯定）、全体動作管理部２０１は、モード管理部２０２及び待ちリクエスト管理部０２４にリクエストの情報を送るとともに後続リクエスト処理の実行を指示する。これにより、処理順調整回路２００は、後続リクエスト処理を実行する（ステップＳ４）。
【０１３７】
次に、図６を参照して、初回登録処理の流れを説明する。図６は、初回登録処理のフローチャートである。図６に示すフローは、図５におけるステップＳ３で実行される処理の一例にあたる。
【０１３８】
モード管理部２０２は、リクエストの情報を全体動作管理部２０１から取得する。そして、モード管理部２０２は、取得したリクエストの情報からリクエスト種別を取得する（ステップＳ１０１）。
【０１３９】
次に、モード管理部２０２は、取得したリクエスト種別から、アドレス競合モードで動作するか否かを判定する（ステップＳ１０２）。具体的には、モード管理部２０２は、リクエスト種別がローカルリクエストの場合にアドレス競合モードによる監視を実行すると判定する。
【０１４０】
アドレス競合モードで動作する場合（ステップＳ１０２：肯定）、モード管理部２０２は、モード識別情報３０２をアドレス競合モードに設定する。次に、モード管理部２０２は、アドレス競合モードによる監視開始を全体動作管理部２０１に通知する。全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを監視実行中に変更し、監視動作を開始する（ステップＳ１０３）。
【０１４１】
次に、モード管理部２０２は、アドレス競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。待ちリクエスト管理部２０４は、アドレス競合モードによる監視開始の指示をモード管理部２０２から受けて、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する（ステップＳ１０４）。
【０１４２】
また、モード管理部２０２は、リクエストの情報に含まれるアドレスを対象アドレス保持部２０３に通知する。そして、対象アドレス保持部２０３は、モード管理部２０２から通知されたアドレスを記憶して保持する（ステップＳ１０５）。
【０１４３】
さらに、待ちリクエスト管理部２０４、外部リクエストポート管理部２０７及びオーダーポート管理部２０８は、アドレスマッチ有効状態情報設定処理を実行する（ステップＳ１０６）。アドレスマッチ有効状態情報設定処理については、後で詳細に説明する。
【０１４４】
この場合、待ちリクエスト管理部２０４は、強制アボート処理の通知をパイプライン制御部２０６に対して行わない。そのため、パイプライン制御部２０６は、キャッシュ制御パイプライン１３２に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン１３２は、投入されたリクエストに対して通常のパイプライン処理を継続する（ステップＳ１０７）。
【０１４５】
一方、アドレス競合モードで動作しない場合（ステップＳ１０２：否定）、モード管理部２０２は、通常資源競合モードで動作するか否かを判定する（ステップＳ１０８）。具体的には、モード管理部２０２は、リクエスト種別が通常ＮＣリクエストの場合に通常資源競合モードによる監視を実行すると判定する。
【０１４６】
通常資源競合モードで動作する場合（ステップＳ１０８：肯定）、モード管理部２０２は、モード識別情報３０２を通常資源競合モードに設定する。次に、モード管理部２０２は、アドレス競合モードによる監視開始を全体動作管理部２０１に通知する。全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを監視実行中に変更し、監視動作を開始する（ステップＳ１０９）。
【０１４７】
次に、モード管理部２０２は、通常資源競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。待ちリクエスト管理部２０４は、通常資源競合モードによる監視開始の指示をモード管理部２０２から受けて、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０の情報及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する（ステップＳ１１０）。
【０１４８】
この場合も、待ちリクエスト管理部２０４は、強制アボート処理の通知をパイプライン制御部２０６に対して行わない。そのため、パイプライン制御部２０６は、キャッシュ制御パイプライン１３２に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン１３２は、投入されたリクエストに対して通常のパイプライン処理を継続する（ステップＳ１１１）。
【０１４９】
一方、通常資源競合モードで動作しない場合（ステップＳ１０８：否定）、モード管理部２０２は、低速資源競合モードで動作するか否かを判定する（ステップＳ１１２）。具体的には、モード管理部２０２は、リクエスト種別が低速ＮＣリクエストの場合に低速資源競合モードによる監視を実行すると判定する。
【０１５０】
低速資源競合モードで動作する場合（ステップＳ１１２：肯定）、モード管理部２０２は、モード識別情報３０２を低速資源競合モードに設定する。次に、モード管理部２０２は、低速資源競合モードによる監視開始を全体動作管理部２０１に通知する。全体動作管理部２０１は、全体動作情報３０１が表す全体有効フラグを監視実行中に変更し、監視動作を開始する（ステップＳ１１３）。
【０１５１】
次に、モード管理部２０２は、低速資源競合モードによる監視開始の指示を待ちリクエスト管理部２０４に通知する。待ちリクエスト管理部２０４は、低速資源競合モードによる監視開始の指示をモード管理部２０２から受けて、全体動作管理部２０１から取得したリクエストの情報から送信元のコア２０の情報及びエントリＩＤを取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５の取得したコア２０に対応する欄のウェイトビットを１にし、且つ、エントリＩＤを表す値を登録して待ちリクエスト情報を追加する（ステップＳ１１４）。
【０１５２】
この場合も、待ちリクエスト管理部２０４は、強制アボート処理の通知をパイプライン制御部２０６に対して行わない。そのため、パイプライン制御部２０６は、キャッシュ制御パイプライン１３２に対して強制アボート処理を指示しない。そこで、キャッシュ制御パイプライン１３２は、投入されたリクエストに対して通常のパイプライン処理を継続する（ステップＳ１１５）。
【０１５３】
一方、低速資源競合モードで動作しない場合（ステップＳ１１２：否定）、モード管理部２０２は、監視を行わないと判定する。そして、モード管理部２０２は、全体動作管理部２０１に監視動作の停止を指示し、登録処理を終了する。
【０１５４】
次に、図７を参照して、アドレスマッチ有効状態情報設定処理の流れについて説明する。図７は、アドレスマッチ有効状態情報設定処理のフローチャートである。図７に示すフローは、図６におけるステップＳ１０６で実行される処理の一例にあたる。
【０１５５】
待ちリクエスト管理部２０４は、リクエストが要求するデータのホームは自クラスタか否かを判定する（ステップＳ１６１）。
【０１５６】
自クラスタがホームでない場合（ステップＳ１６１：否定）、待ちリクエスト管理部２０４は、オーダー有効フラグの設定処理の実行をオーダーポート管理部２０８に指示する。オーダーポート管理部２０８は、待ちリクエスト管理部２０４からのオーダー有効フラグの設定指示を受けて、アドレスマッチ有効状態情報３０３におけるオーダー有効フラグを１に設定する（ステップＳ１６２）。これにより、オーダー監視が有効になる。
【０１５７】
その後、オーダーポート管理部２０８は、アボートカウンタ２０９を初期化して、カウンタ値を０に設定する（ステップＳ１６３）。
【０１５８】
一方、自クラスタがホームの場合（ステップＳ１６１：肯定）、待ちリクエスト管理部２０４は、外部リクエスト有効フラグの設定処理の実行を外部リクエストポート管理部２０７に指示するとともにリクエストの情報を送信する。外部リクエストポート管理部２０７は、待ちリクエスト管理部２０４から受信したリクエストの情報を用いてリクエストが排他性を有するローカルリクエストか否かを判定する（ステップＳ１６４）。
【０１５９】
リクエストが排他性を有するリクエストの場合（ステップＳ１６４：肯定）、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを１に設定する（ステップＳ１６５）。これにより、外部リクエスト監視が有効になる。
【０１６０】
これに対して、リクエストが排他性を有するリクエストでない場合（ステップＳ１６４：否定）、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを０に設定する（ステップＳ１６６）。これにより、外部リクエスト監視は無効となる。
【０１６１】
次に、図８を参照して、既にリクエストの監視が開始された後の後続リクエスト処理の流れについて説明する。図８は、後続リクエスト処理のフローチャートである。図８におけるステップＳ４で実行される処理の一例にあたる。
【０１６２】
モード管理部２０２は、キャッシュ制御パイプライン１３２に投入されたリクエストの情報を全体動作管理部２０１から取得する。そして、モード管理部２０２は、取得したリクエストの情報からリクエスト種別を取得する（ステップＳ２０１）。また、モード管理部２０２は、モード識別情報３０２を確認し、現在の監視モードを特定する。
【０１６３】
次に、モード管理部２０２は、現在の監視モードがアドレス競合モードであり、且つ、取得したリクエストがアドレス競合モードにおける監視対象であるか否かを判定する（ステップＳ２０２）。
【０１６４】
監視モードがアドレス競合モードであり且つリクエストが監視対象の場合（ステップＳ２０２：肯定）、モード管理部２０２は、リクエストの情報とともにアドレスの確認依頼をアドレスマッチ判定部２０５へ出力する。アドレスマッチ判定部２０５は、リクエストの情報からリクエストが指定するアドレスを取得する。そして、アドレスマッチ判定部２０５は、対象アドレス情報３０６から監視対象のアドレスを取得し、リクエストが指定するアドレスと一致するか否かを判定する（ステップＳ２０３）。
【０１６５】
アドレスが一致しない場合（ステップＳ２０３：否定）、アドレスマッチ判定部２０５は、アドレスの不一致を待ちリクエスト管理部２０４は通知する。そして、処理はステップＳ２１０へ進む。
【０１６６】
これに対して、アドレスが一致した場合（ステップＳ２０３：肯定）、アドレスマッチ判定部２０５は、リクエストの情報とともに待ちリクエストの判定依頼を待ちリクエスト管理部２０４へ出力する。待ちリクエスト管理部２０４は、リクエストの情報を用いて、リクエストがローカルリクエストか否かを判定する（ステップＳ２０４）。
【０１６７】
リクエストがローカルリクエストの場合（ステップＳ２０４：肯定）、待ちリクエスト管理部２０４及び外部リクエストポート管理部２０７は、外部リクエスト有効フラグ設定処理を実行する（ステップＳ２０５）。この外部リクエスト有効フラグ設定処理については後で詳細に説明する。
【０１６８】
次に、待ちリクエスト管理部２０４は、リクエストの情報から送信元の情報を取得する。そして、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元に対応する欄における完了ビットの値を確認する。そして、待ちリクエスト管理部２０４は、その送信元から出力されたリクエストと同じアドレスに対するローカルリクエストの要求処理が完了済みか否かを判定する（ステップＳ２０６）。
【０１６９】
要求処理が完了済みの場合（ステップＳ２０６：肯定）、待ちリクエスト管理部２０４は、投入されたリクエストに対する強制アボートの実行をパイプライン制御部２０６に指示する。そして、パイプライン制御部２０６は、強制アボートをキャッシュ制御パイプライン１３２に指示する（ステップＳ２０７）。
【０１７０】
これに対して、要求処理が完了していない場合（ステップＳ２０６：否定）、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元に対応する欄におけるウェイトビットを確認して待ちリクエストが保持可能か否かを判定する（ステップＳ２０８）。
【０１７１】
ウェイトビットが０であり、待ちリクエストが存在しない場合（ステップＳ２０８：肯定）、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５における送信元に対応する欄におけるウェイトビットを１にして待ちリクエストを追加する（ステップＳ２０９）。
【０１７２】
この場合、待ちリクエスト管理部２０４による強制アボートの実行の指示は行われず、パイプライン制御部２０６は、投入されたリクエストに対する通常のパイプライン処理をキャッシュ制御パイプライン１３２に実行させる（ステップＳ２１０）。
【０１７３】
これに対して、ウェイトビットが１であり、既に待ちリクエストが存在する場合（ステップＳ２０８：否定）、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５を参照して、リクエストが投入されたポートが待ちリクエストを保持しており且つパイプライン処理が完了していないポートか否かを判定する（ステップＳ２１１）。
【０１７４】
リクエストが投入されたポートが待ちリクエストを保持しており且つパイプライン処理が完了していないポートの場合（ステップＳ２１１：肯定）、処理はステップＳ２１０へ遷移する。これに対して、リクエストが投入されたポートが待ちリクエストを保持していない又はパイプライン処理が完了したポートの場合（ステップＳ２１１：否定）、処理はステップＳ２０７へ遷移する。
【０１７５】
一方、リクエストがローカルリクエストでない場合（ステップＳ２０４：否定）、待ちリクエスト管理部２０４は、リクエストの情報を用いて、リクエストが外部リクエストか否かを判定する（ステップＳ２１２）。
【０１７６】
リクエストが外部リクエストの場合（ステップＳ２１２：肯定）、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３を確認して、外部リクエスト監視が有効か否かを判定する（ステップＳ２１３）。外部リクエスト監視が有効の場合（ステップＳ２１３：肯定）、処理は、ステップＳ２０６へ移る。
【０１７７】
これに対して、外部リクエスト監視が無効の場合（ステップＳ２１３：否定）、待ちリクエスト管理部２０４及び外部リクエストポート管理部２０７は、外部リクエスト有効フラグ設定処理を実行する（ステップＳ２１４）。この外部リクエスト有効フラグ設定処理については後で詳細に説明する。その後、処理は、ステップＳ２１０へ移る。
【０１７８】
一方、リクエストが外部リクエストでない場合（ステップＳ２１２：否定）、待ちリクエスト管理部２０４は、リクエストがオーダーか否かを判定する（ステップＳ２１５）。リクエストがオーダーの場合（ステップＳ２１５：肯定）、待ちリクエスト管理部２０４は、オーダー有効フラグの設定処理の実行指示をオーダーポート管理部２０８へ出力する。オーダーポート管理部２０８は、オーダー有効フラグの設定処理の実行指示の入力を受けて、アドレスマッチ有効状態情報３０３を参照してオーダー監視が有効か否かを判定する（ステップＳ２１６）。オーダー監視が有効の場合（ステップＳ２１６:肯定）、処理は、ステップＳ２０８へ遷移する。
【０１７９】
これに対して、オーダー監視が無効の場合（ステップＳ２１６:否定）、処理は、ステップＳ２１０へ遷移する。
【０１８０】
一方、リクエストがオーダーでない場合（ステップＳ２１５：否定）、オーダーポート管理部２０８は、リクエストがキャッシュフィルリクエストか否かを判定する（ステップＳ２１７）。リクエストがキャッシュフィルリクエストでない場合（ステップＳ２１７：否定）、処理は、ステップＳ２１０へ遷移する。
【０１８１】
これに対して、リクエストがキャッシュフィルリクエストの場合（ステップＳ２１７：肯定）、オーダーポート管理部２０８は、アドレスマッチ有効状態情報３０３においてオーダー有効フラグを１に設定する（ステップＳ２１８）。これにより、オーダー監視が有効となる。
【０１８２】
その後、オーダーポート管理部２０８は、アボートカウンタ２０９を初期化して、カウンタ値を０にする（ステップＳ２１９）。その後、処理は、ステップＳ２１０へ遷移する。
【０１８３】
一方、監視モードがアドレス競合モードでなくリクエストが監視対象でない場合（ステップＳ２０２：否定）、モード管理部２０２は、監視モードが通常資源競合モードで且つリクエストが監視対象か否かを判定する（ステップＳ２２０）。監視モードが通常資源競合モードで且つリクエストが監視対象の場合（ステップＳ２２０：肯定）、処理は、ステップＳ２０６へ進む。
【０１８４】
これに対して、監視モードが通常資源競合モードでなくリクエストが監視対象でない場合（ステップＳ２２０：否定）、モード管理部２０２は、監視モードが低速資源競合モードで且つリクエストが監視対象か否かを判定する（ステップＳ２２１）。監視モードが低速資源競合モードで且つリクエストが監視対象の場合（ステップＳ２２１：肯定）、処理は、ステップＳ２０６へ進む。
【０１８５】
これに対して、監視モードが低速資源競合モードなくリクエストが監視対象でない場合（ステップＳ２２１：否定）、リクエストは監視の対象となっていないため、処理は、ステップＳ２１０へ進む。
【０１８６】
次に、図９を参照して、外部リクエスト有効フラグ設定処理の流れについて説明する。図９は、外部リクエスト有効フラグ設定処理のフローチャートである。図９に示すフローは、図８におけるステップＳ２０５で実行される処理の一例にあたる。
【０１８７】
ステップＳ２０５における処理の場合、待ちリクエスト管理部２０４は、アドレスマッチ有効状態情報３０３を用いて外部リクエスト監視が有効か否かを判定し、外部リクエスト監視が有効であれば外部リクエスト有効フラグ設定処理を終了する。外部リクエスト監視が無効であれば、待ちリクエスト管理部２０４は、外部リクエストポート管理部２０７に以下の処理を行わせる。また、ステップＳ２１３における処理の場合、ただちに以下の処理が行われる。
【０１８８】
外部リクエストポート管理部２０７は、投入されたリクエストが排他性を有するローカルリクエストか否かを判定する（ステップＳ２５１）。
【０１８９】
リクエストが排他性を有するローカルリクエストの場合（ステップＳ２５１：肯定）、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３において外部リクエスト有効フラグを１に設定する（ステップＳ２５２）。これにより、外部リクエスト監視が有効になる。
【０１９０】
これに対して、リクエストが排他性を有するローカルリクエストでない場合（ステップＳ２５１：否定）、外部リクエストポート管理部２０７は、アドレスマッチ有効状態情報３０３である外部リクエスト有効フラグを０のまま維持する（ステップＳ２５３）。
【０１９１】
次に、図１０を参照して、パイプライン処理完了時の動作の流れについて説明する。図１０は、パイプライン処理完了時の動作のフローチャートである。
【０１９２】
パイプライン制御部２０６は、処理応答をキャッシュ制御パイプライン１３２から受信する（ステップＳ３０１）。そして、パイプライン制御部２０６は、処理応答を待ちリクエスト管理部２０４へ出力する。
【０１９３】
待ちリクエスト管理部２０４は、処理応答の入力をパイプライン制御部２０６から受ける。次に、待ちリクエスト管理部２０４は、リクエストの送信元の情報及びエントリＩＤを処理応答から取得する。そして、待ちリクエスト管理部２０４は、送信元の情報及びエントリＩＤが一致する情報が待ちリクエストリスト３０５に存在するか否か、すなわちパイプライン処理完了したリクエストが待ちリクエストか否かを判定する（ステップＳ３０２）。リクエストが待ちリクエストでない場合（ステップＳ３０２：否定）、待ちリクエスト管理部２０４は、パイプライン処理完了時の処理を終了させる。
【０１９４】
これに対して、リクエストが待ちリクエストの場合（ステップＳ３０２：肯定）、待ちリクエスト管理部２０４は処理応答がアボート通知か否かを判定する（ステップＳ３０３）。
【０１９５】
処理応答がアボート通知でない場合（ステップＳ３０３：否定）、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５におけるパイプライン処理が完了したリクエストに対応する欄の完了ビットを１に設定して完了フラグを追加する（ステップＳ３０４）。ただし、リクエストがオーダーの場合、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５におけるオーダーポートのウェイトビットを０にして待ちリクエストを無くすことで、オーダーの処理完了を表す。
【０１９６】
その後、待ちリクエスト管理部２０４、外部リクエストポート管理部２０７及びオーダーポート管理部２０８は、アドレスマッチ有効状態情報リセット処理を実行する（ステップＳ３０５）。
【０１９７】
次に、待ちリクエスト管理部２０４は、待ちリクエストリスト３０５に登録された全ての待ちリクエストの要求処理が完了したが否かを判定する（ステップＳ３０６）。全ての待ちリクエストの要求処理が完了した場合（ステップＳ３０６：肯定）、待ちリクエスト管理部２０４は、監視の終了を全体動作管理部２０１に通知する。そして、全体動作管理部２０１は、全体動作情報３０１における全体有効フラグを監視動作無効を表す状態に変更して監視動作を終了する（ステップＳ３０７）。
【０１９８】
これに対して、要求処理が完了していない待ちリクエストが残っている場合（ステップＳ３０６：否定）、処理はステップＳ３１２へ進む。
【０１９９】
一方、処理応答がアボート処理の場合（ステップＳ３０３：肯定）、待ちリクエスト管理部２０４は、パイプライン処理が完了したリクエストがオーダーか否かを判定する（ステップＳ３０８）。リクエストがオーダーでない場合（ステップＳ３０８：否定）、処理はステップ３１２へ進む。
【０２００】
これに対して、リクエストがオーダーの場合（ステップＳ３０８：肯定）、待ちリクエスト管理部２０４は、オーダーのアボートをオーダーポート管理部２０８へ通知する。オーダーポート管理部２０８は、オーダー処理のアボートの通知を受けて、アボートカウンタ２０９のカウンタ値を１つインクリメントする（ステップＳ３０９）。
【０２０１】
次に、オーダーポート管理部２０８は、アボートカウンタ２０９のカウンタ値が閾値以上であるか否かを判定する（ステップＳ３１０）。アボートカウンタ２０９のカウンタ値が閾値未満の場合（ステップＳ３１０：否定）、ステップＳ３１２へ進む。
【０２０２】
これに対して、アボートカウンタ２０９のカウンタ値が閾値以上の場合（ステップＳ３１０：肯定）、アドレスマッチ有効状態情報３０３におけるオーダー有効フラグを０に設定して、オーダー監視を無効にする（ステップＳ３１１）。
【０２０３】
その後、処理順調整回路２００の各部は、監視を継続する（ステップＳ３１２）。
【０２０４】
次に、図１１を参照して、アドレスマッチ有効状態情報リセット処理の流れについて説明する。図１１は、アドレスマッチ有効状態情報リセット処理のフローチャートである。図１１に示すフローチャートは、図１０におけるステップＳ３０５で実行される処理の一例にあたる。
【０２０５】
待ちリクエスト管理部２０４は、待ちリクエストリスト３０５に登録されたローカルリクエストの待ちリクエストが全て完了したか否かを判定する（ステップＳ３５１）。ローカルリクエストの全ての待ちリクエストが完了した場合（ステップＳ３５１：肯定）、自クラスタがホームであれば、外部リクエストポート管理部２０７がアドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを０に設定する。また、自クラスタがホームでなければ、オーダーポート管理部２０８が、オーダー有効フラグを０に設定する（ステップＳ３５２）。これにより、外部リクエスト監視又はオーダー監視が無効となる。
【０２０６】
これに対して、ローカルリクエストで処理されていない待ちリクエストが残っている場合（ステップＳ３５１：否定）、自クラスタがホームであれば、外部リクエストポート管理部２０７がアドレスマッチ有効状態情報３０３における外部リクエスト有効フラグを１のまま維持する。また、自クラスタがホームでなければ、オーダーポート管理部２０８が、オーダー有効フラグを１のまま維持する（ステップＳ３５３）。これにより、外部リクエスト監視又はオーダー監視が有効のまま維持される。
【０２０７】
次に、図１２及び１３を参照して、本実施例に係るＣＰＵ１を用いた場合と従来のＣＰＵを用いた場合のデータ処理の速度の比較について説明する。図１２は、従来のＣＰＵによるデータ処理の一例のシーケンス図である。また、図１３は、実施例に係るＣＰＵによるデータ処理の一例のシーケンス図である。
【０２０８】
ここでは、監視するリクエストが要求したデータのホームがクラスタ１０であり、クラスタ１０〜１３のいずれにおいてもコア＃００とコア＃０１とがアドレスが同一のローカルリクエストを発行した場合で説明する。
【０２０９】
図１２に示すローカルリクエスト４０１は、クラスタ１０において、ＬＬＣ１００が、コア＃００が発行したリクエストとアドレスが同じコア＃０１が発行したリクエストである。その後、コア＃００が発行したリクエストを処理する間に、クラスタ１０のＬＬＣ１００は、クラスタ１１〜１３のＬＬＣ１００から外部リクエスト４０２〜４０４を受ける。
【０２１０】
従来のＣＰＵでは、ローカルリクエストの処理が完了していない場合でも、外部リクエストがローカルリクエストに優先される場合がある。その場合、クラスタ１０においてコア＃０１が発行したリクエストが処理されずに、データ転送４０５で示すようにデータがクラスタ１１のＬＬＣ１００へ送られる。
【０２１１】
クラスタ１１のＬＬＣ１００は、コア＃００が発行したリクエストを処理する間に、クラスタ１０のＬＬＣ１００からクラスタ１２へのオーダー４０８の入力を受ける。ここでも、従来のＣＰＵでは、ローカルリクエストの処理が完了していない場合でも、オーダーがローカルリクエストに優先される場合がある。その場合、クラスタ１１においてコア＃０１が発行したリクエストが処理されずに、データ転送４０７で示すようにデータがクラスタ１２のＬＬＣ１００へ送られる。
【０２１２】
クラスタ１２のＬＬＣ１００は、コア＃００が発行したリクエストを処理する間に、クラスタ１０のＬＬＣ１００からクラスタ１３へのオーダー４０８の入力を受ける。ここでも、クラスタ１２においてコア＃０１が発行したリクエストが処理されずに、データ転送４０９で示すようにデータがクラスタ１３のＬＬＣ１００へ送られる。
【０２１３】
クラスタ１３のＬＬＣ１００は、コア＃００が発行したリクエストを処理する間に、クラスタ１０のＬＬＣ１００からデータをホームへ戻すオーダー４１０の入力を受ける。ここでも、クラスタ１３においてコア＃０１が発行したリクエストが処理されずに、データ転送４１１で示すようにデータがクラスタ１１のＬＬＣ１００へ送られる。
【０２１４】
以上の処理により、期間４１２の間に、各クラスタ１０〜１３においてコア＃００のリクエストは処理されたが、コア＃０１のリクエストは処理されずにデータがクラスタ１０〜１３の間を移動する。
【０２１５】
その後、期間４１３において、クラスタ１０〜１３のそれぞれのコア＃０１のリクエストを処理するように順にデータが移動されて処理が行われる。このように、従来のＣＰＵでは、データ処理の全体の時間として、期間４１２と期間４１３を合わせた時間がかかる。
【０２１６】
これに対して、本実施例に係るＣＰＵ１であれば図１３に示すように処理を行う。すなわち、コア＃００及び＃０１からリクエストを受けた、クラスタ１０のＬＬＣ１００が、クラスタ１１〜１３のＬＬＣ１００から外部リクエスト５０１〜５０３を受ける。本実施例に係るＣＰＵ１の処理順調整回路２００は、外部リクエスト及びオーダーに優先させてローカルリクエストをキャッシュ制御パイプライン１３２に処理させ、ローカルリクエストの待ちリクエストが無くなってから外部リクエスト又はオーダーを実行させる。
【０２１７】
そのため、クラスタ１０のＬＬＣ１００は、コア＃００及び＃０１からのリクエストを処理した後に、クラスタ１１へリクエストコンプリートを送信する。すなわち、クラスタ１０のＬＬＣ１００は、外部リクエスト５０１の応答としてデータをクラスタ１１へ送信する。これにより、期間５０４の間にクラスタ１０のコア＃００及び＃０１が発行したリクエストの処理が完了する。その後、クラスタ１０のＬＬＣ１００は、外部リクエスト５０２に基づいてクラスタ１２へのデータの転送を指示するオーダー５０５をクラスタ１１へ送信する。
【０２１８】
クラスタ１１のＬＬＣ１００は、オーダー５０５を受信しても、コア＃００及び＃０１のリクエストの処理を継続し、コア＃００及び＃０１からのリクエストを処理した後に、クラスタ１２へオーダーコンプリートを送信する。すなわち、クラスタ１１のＬＬＣ１００は、データ転送５０７に示すようにデータをクラスタ１２へ送信する。これにより、期間５０６の間にクラスタ１１のコア＃００及び＃０１が発行したリクエストの処理が完了する。
【０２１９】
その後、クラスタ１０のＬＬＣ１００は、クラスタ１１からの処理完了の応答を受けて、オーダー５０８をクラスタ１２へ送信する。クラスタ１２のＬＬＣ１００は、オーダー５０８を受信しても、コア＃００及び＃０１のリクエストの処理を継続し、コア＃００及び＃０１からのリクエストを処理した後に、クラスタ１３へオーダーコンプリートを送信する。すなわち、クラスタ１２のＬＬＣ１００は、データ転送５１０に示すようにデータをクラスタ１３へ送信する。これにより、期間５０９の間にクラスタ１２のコア＃００及び＃０１が発行したリクエストの処理が完了する。
【０２２０】
その後、クラスタ１０のＬＬＣ１００は、クラスタ１２からの処理完了の応答を受けて、データをホームへ戻すオーダー５１１をクラスタ１３へ送信する。クラスタ１３のＬＬＣ１００は、オーダー５１１を受信しても、コア＃００及び＃０１のリクエストの処理を継続し、コア＃００及び＃０１からのリクエストを処理した後に、データ転送５１３に示すようにデータをクラスタ１０へ戻す。これにより、期間５１２の間にクラスタ１２のコア＃００及び＃０１が発行したリクエストの処理が完了する。
【０２２１】
以上の処理により、本実施例に係るＣＰＵ１は、期間５０４、５０６、５０９及び５１２を合わせた期間でデータ処理が完了する。このように、本実施例に係るＣＰＵ１は、各クラスタ１０〜１３においてローカルリクエストをまとめて処理し、その後にデータを移動させることで、データ処理の全体の時間を短縮して処理速度を向上させることができる。
【０２２２】
以上に説明したように、本実施例に係るＣＰＵは、アドレスが競合するキャッシャブルのリクエストの場合、外部リクエスト及びオーダーに対してローカルリクエストを優先して処理する。これにより、全クラスタで共有が完了するまでに必要なクラスタ間ネットワーク通信に係るレイテンシコストを削減することができる。また、本実施例に係るＣＰＵは、既に発行したリクエストを処理したリクエストポートのリクエストに優先させて、処理が完了していないリクエストポートを優先させる。これにより、キャッシャブルのリクエストが競合した場合にリクエスト間で均衡が取れた処理を実行することができる。これにより、未処理のコアのリクエストが待機しているにもかかわらず一度リクエストが処理されたコアからのリクエストが再び受理されることを防止でき、特定のコアの処理が進み、処理の進まないコアが発生すること軽減することができる。
【０２２３】
また、本実施例に係るＣＰＵは、ノンキャッシャブルのリクエストについても既に発行したリクエストを処理したリクエストポートのリクエストに優先させて、処理が完了していないリクエストポートを優先させる。これにより、ノンキャッシャブルのリクエストが競合した場合にもリクエスト間で均衡が取れた処理を実行することができる。さらに、本実施例に係るＣＰＵは、処理に時間が掛かるリクエストと、それ以外のリクエストとを分けることで、処理に時間がかかるリクエストが滞留しても、それ以外のリクエストの発行が可能であり、処理効率を向上させることができる。また、特に処理に時間がかかるリクエストにおいて順序不平等が発生すると追い抜かれたコアは非常に長い待ち時間が発生してしまうが、本実施例に係るＣＰＵは、リクエスト間で均衡が取れた処理を実行することで、コアの待ち時間を短縮することができる。
【０２２４】
また、以上の説明では同一のＣＰＵ内のクラスタ間でのリクエストの処理順の調整について説明したが、他のＣＰＵのクラスタから送られてきたリクエストも外部リクエスト及びオーダーと同様に処理することで、順序の公平性を保つことが可能である。
【符号の説明】
【０２２５】
１  ＣＰＵ
５  インターコネクトコントローラ
６  ＰＣＩｅインタフェース
７  オンチップネットワーク
８  チップセットＩＦ
１０〜１３  クラスタ
２０  コア
２１  Ｌ１命令キャッシュ
２２  Ｌ１データキャッシュ
３０〜３３  ＭＡＣ
４０〜４３  メモリ
６０  ＰＣＩｅバス
８０  オフチップコントローラ
１００  ＬＬＣ
１０１  タグ記憶部
１０２  データ記憶部
１０３  管理表格納部
１０４  制御パイプライン
１０５  リクエスト受信部
１０６  処理順調整部
１０７  ローカルオーダー制御部
１０８  ミスアクセス制御部
１０９  プライオリティ制御部
１１１〜１１３  ローカルリクエストポート
１２１  外部リクエストポート  
１２２  オーダーポート
１２３  ＭＩＢポート
１３１  プライオリティ回路
１３２  キャッシュ制御パイプライン
１３３  タグＲＡＭ
１３４  データＲＡＭ
１３５  オーダロック回路
１３６  ＭＩＢ回路
１３７  ストアロック回路
１３８  持出管理回路
２００  処理順調整回路
２０１  全体動作管理部
２０２  モード管理部
２０３  対象アドレス保持部
２０４  待ちリクエスト管理部
２０５  アドレスマッチ判定部
２０６  パイプライン制御部
２０７  外部リクエストポート管理部
２０８  オーダーポート管理部
２０９  アボートカウンタ
【図１】
2020095464.tif 000003
【図２】
2020095464.tif 000004
【図３】
2020095464.tif 000005
【図４】
2020095464.tif 000006
【図５】
2020095464.tif 000007
【図６】
2020095464.tif 000008
【図７】
2020095464.tif 000009
【図８】
2020095464.tif 000010
【図９】
2020095464.tif 000011
【図１０】
2020095464.tif 000012
【図１１】
2020095464.tif 000013
【図１２】
2020095464.tif 000014
【図１３】
2020095464.tif 000015