特許 6552512 入出力メモリマップユニット及びノースブリッジ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6552512

(24)【登録日】2019年7月12日

(45)【発行日】2019年7月31日

(54)【発明の名称】入出力メモリマップユニット及びノースブリッジ

(51)【国際特許分類】

   G06F 12/1009 20160101AFI20190722BHJP

【ＦＩ】

   G06F12/1009 105

【請求項の数】16

【全頁数】62

(21)【出願番号】特願2016-550678(P2016-550678)

(86)(22)【出願日】2014年10月24日

(65)【公表番号】特表2017-502435(P2017-502435A)

(43)【公表日】2017年1月19日

(86)【国際出願番号】US2014062249

(87)【国際公開番号】WO2015061731

(87)【国際公開日】20150430

【審査請求日】2017年10月18日

(31)【優先権主張番号】61/896,092

(32)【優先日】2013年10月27日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】591016172

【氏名又は名称】アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド

【氏名又は名称原語表記】ＡＤＶＡＮＣＥＤ ＭＩＣＲＯ ＤＥＶＩＣＥＳ ＩＮＣＯＲＰＯＲＡＴＥＤ

(73)【特許権者】

【識別番号】508301087

【氏名又は名称】エーティーアイ・テクノロジーズ・ユーエルシー

【氏名又は名称原語表記】ＡＴＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＵＬＣ

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川 裕司

(74)【代理人】

【識別番号】100111615

【弁理士】

【氏名又は名称】佐野 良太

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨 圭介

(72)【発明者】

【氏名】ビディアナサン カリャナサンダーラム

(72)【発明者】

【氏名】フィリップ エヌジー

(72)【発明者】

【氏名】マギー チャン

(72)【発明者】

【氏名】ビンセント クエバ

(72)【発明者】

【氏名】アンソニー アサロ

(72)【発明者】

【氏名】ジムシェド ミルザ

(72)【発明者】

【氏名】グレゴリー ダグラス ダンリー

(72)【発明者】

【氏名】ブライアン ブルッサール

(72)【発明者】

【氏名】ベンジャミン チェン

(72)【発明者】

【氏名】ヤニブ アディリ

【審査官】 酒井 恭信

(56)【参考文献】

【文献】 特開昭６３−２９８６５２（ＪＰ，Ａ）

【文献】 特開平０２−０２３４５８（ＪＰ，Ａ）

【文献】 特開平０６−２３６３５３（ＪＰ，Ａ）

【文献】 米国特許第０５７５８１２０（ＵＳ，Ａ）

【文献】 特表２００１−５１７８２９（ＪＰ，Ａ）

【文献】 特表２００８−５４２８７８（ＪＰ，Ａ）

【文献】 特開２０１２−２４３１１７（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０００６８０５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１０／０２２３４４７（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／１０ − １２／１０９

(57)【特許請求の範囲】

【請求項1】

ダーティビットを処理することを含む、コンピュータシステムのページテーブルを管理する方法であって、
少なくとも１つの仮想メモリアドレスの対応する物理アドレスへのマッピングを提供するページテーブル内の１つ以上のページテーブルエントリにアクセスすることであって、アクセスすることは、アクセスフラグに従い、１つのアトミックアップデートにおいて実行されるためにハードウェアを介して生じ、アクセスすることは、前記アクセスフラグの少なくとも１つのアクセスビットを変更させ、前記アクセスフラグは、アドレストランスレーションのためのセキュア又は非セキュアなテーブルエントリを示すために用いられ、前記アトミックアップデートはシングルアトミックオペレーションである、ことと、
アクセスされた前記１つ以上のページテーブルエントリにおいて特定された物理メモリアドレスを、前記物理メモリアドレスと、前記物理メモリアドレス上で実行された１つ以上のメモリオペレーションとに基づいて変更することであって、変更することは、前記１つ以上のメモリオペレーションを用いて前記物理メモリアドレスを設定及びクリアすることを含む、ことと、
ページがクリーン又はダーティであるか否かを示す前記ページテーブル内のダーティビットを、前記アトミックアップデートにおいて変更された物理メモリアドレスに応じて変更することであって、前記アトミックアップデート中に、前記アクセスフラグの少なくとも１つのアクセスビット及び前記ダーティビットが、アクセスされた１つ以上のテーブルエントリに対して更新される、ことと、を含む、
方法。

【請求項2】

前記変更することは、単一のテーブルエントリで実行される、請求項１の方法。

【請求項3】

前記変更することは、ハードウェアで管理される、請求項１の方法。

【請求項4】

アクセスフラグのアクセスビットが０に設定されたページテーブルエントリがトランスレーション索引バッファ（ＴＬＢ）に読み込まれることに応じて、メモリ内のページテーブルエントリのアクセスフラグのアクセスビットに１が設定される、請求項１の方法。

【請求項5】

コンピュータシステムであって、
プロセッサと、
１つ以上のページテーブルを含むメモリと、を備え、
前記プロセッサは、
アクセスフラグに従って、少なくとも１つの仮想メモリアドレスの対応する物理アドレスへのマッピングを提供するページテーブル内の１つ以上のページテーブルエントリにアクセスすることであって、１つのアトミックアップデートにおいて前記１つ以上のテーブルエントリにアクセスし、前記アクセスフラグの少なくとも１つのアクセスビットを変更させ、前記アクセスフラグは、アドレストランスレーションのためのセキュア又は非セキュアなテーブルエントリを示すために用いられ、前記アトミックアップデートはシングルアトミックオペレーションである、ことと、
アクセスされた前記１つ以上のページテーブルエントリにおいて特定された物理メモリアドレスを、前記物理メモリアドレスと、前記物理メモリアドレス上で実行された１つ以上のメモリオペレーションとに基づいて変更することであって、変更することは、前記１つ以上のメモリオペレーションを用いて前記物理メモリアドレスを設定及びクリアすることを含む、ことと、
ページがクリーン又はダーティであるか否かを示す前記ページテーブル内のダーティビットを、前記アトミックアップデートにおいて変更された物理メモリアドレスに応じて変更することであって、前記アトミックアップデート中に、前記アクセスフラグの少なくとも１つのアクセスビット及び前記ダーティビットが、アクセスされた１つ以上のテーブルエントリに対して更新される、ことと、を行うように構成されている、
コンピュータシステム。

【請求項6】

前記アクセスすることに基づいて前記アクセスフラグのアクセスビットを更新することを含む、請求項１の方法。

【請求項7】

前記アクセスビット及び前記ダーティビットは、シングルアトミックオペレーションの間に前記ページテーブルエントリに基づいて更新される、請求項６の方法。

【請求項8】

前記ダーティビットがダーティを示す場合に、前記ダーティビットを、クリーンを示すように変更する、請求項１の方法。

【請求項9】

前記プロセッサは、単一のテーブルエントリに対して変更を行うように構成されている、請求項５のコンピュータシステム。

【請求項10】

前記コンピュータシステムは、ハードウェアメモリコントローラ内の変更を管理し、ハードウェア管理に基づいて変更するように構成されている、請求項５のコンピュータシステム。

【請求項11】

アクセスフラグのアクセスビットが０に設定されたページテーブルエントリがトランスレーション索引バッファ（ＴＬＢ）に読み込まれることに応じて、メモリ内のページテーブルエントリのアクセスフラグのアクセスビットに１が設定される、請求項５のコンピュータシステム。

【請求項12】

前記アクセスフラグは、セキュア又は非セキュアなトランスレーションを示すために用いられる、請求項５のコンピュータシステム。

【請求項13】

前記アクセスフラグのハードウェアマネージメントが、アドレストランスレーションのステージのために有効になっている場合には、アクセスフラグフォールトは、トランスレーションに応じるために生成されない、請求項５のコンピュータシステム。

【請求項14】

前記プロセッサは、前記アクセスすることに基づいて前記アクセスフラグのアクセスビットを更新するように構成されている、請求項５のコンピュータシステム。

【請求項15】

前記アクセスビット及び前記ダーティビットは、シングルアトミックオペレーションの間に前記ページテーブルエントリに基づいて更新される、請求項１４のコンピュータシステム。

【請求項16】

前記ダーティビットがダーティを示す場合に、前記プロセッサは、前記ダーティビットを、クリーンを示すように変更する、ように構成されている、請求項５のコンピュータシステム。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本出願は、２０１３年１０月２７日に出願された米国仮特許出願第６１／８９６，０９２（発明の名称：入出力メモリマップユニット及びノースブリッジ）の利益を主張し、その内容が引用されて本明細書に組み込まれている。

【0002】

開示された実施形態は、概して、メモリマップ及びトランスレータに関し、特に、入出力メモリマップユニット及びノースブリッジに関する。

【背景技術】

【0003】

ページテーブルは、仮想アドレスと物理アドレスとの間のマッピングを記憶するコンピュータオペレーティングシステムの仮想メモリシステムによって使用されるデータ構造である。仮想アドレスは、ハードウェア、又は、より具体的にはＲＡＭによって使用されている物理アドレスの間、プロセスにアクセスすることによって使用されている。

【0004】

仮想メモリを使用するオペレーティングシステムにおいて、全てのプロセスは、メモリの大規模な連続するセクションで動作している印象が与えられている。実際に、各プロセスのメモリは、物理メモリの異なる領域に分散されてもよいし、別のストレージ（一般的にハードディスク）に移動（ページアウト）されてもよい。

【0005】

プロセスは、そのメモリ内のデータにアクセスを要求する場合、そのデータが格納されている実際のメモリの物理アドレスへのプロセスによって提供される仮想アドレスをマップするオペレーティングシステムに依存する。ページテーブルは、オペレーティングシステムが、ページテーブルエントリ（ＰＴＥ）として知られるマッピングとともに、仮想アドレスから物理アドレスへのマッピングを記憶するものである。

【0006】

アクションは、仮想から物理アドレスへの変換時に行われる。ＴＬＢのミスが発生した場合にトランスレーションが再開されることにより、ルックアップを、ハードウェアを介して正確に行うことができる。

【0007】

ＣＰＵのメモリマネージメントユニット（ＭＭＵ）は、オペレーティングシステムのページテーブルから最近使用されたマッピングのキャッシュを記憶する。これは、連想キャッシュでありトランスレーション索引バッファ（ＴＬＢ）といわれている。

【0008】

仮想アドレスが物理アドレスに変換される必要がある場合、ＴＬＢは、最初に検索される。マッチが検出された場合（ＴＬＢヒット）には、物理アドレスが返され、メモリアクセスを継続することができる。しかしながら、マッチなし（ＴＬＢミスという）の場合には、ハンドラは、典型的に、マッピングが存在（ページウォーク）するか否かを確認するためにページテーブル内のアドレスマッピングをルックアップする。１つ存在する場合には、ＴＬＢに書き戻され（これは、ハードウェアが仮想メモリシステムでＴＬＢを介してメモリにアクセスするように、行われなければならない）、且つ、フォールト命令が再開される（これも同様に並行して発生するかもしれない）。これ以降のトランスレーションはＴＬＢヒットを見つけ、メモリアクセスが継続されるであろう。

【0009】

ページテーブルルックアップは、２つの理由で失敗する。第１に、仮想アドレスのためのトランスレーションが可能でない場合には、仮想アドレスが無効であることを意味する。これは、典型的に、プログラミングエラーの原因で発生し、オペレーティングシステムは、問題に対処するためのいくつかのアクションを実行しなければならない。最新のオペレーティングシステムでは、問題のあるプログラムに対してセグメンテーションフォールトを送信するであろう。

【0010】

また、ページが物理メモリに常駐していない場合には、ページテーブルルックアップが失敗することがある。これは、要求されたページが他のページの領域となる物理メモリの外に移動した場合に、生じるであろう。この場合、ページは、ハードディスクドライブ等のメディア上に配置された第２のストアにページアウトされる（第２のストア又は「バックングストア」は、ディスクパーティション又はスワップファイルである場合に「スワップパーティション」とよく呼ばれ、ファイルである場合には「スワップファイル」又は「ページファイル」とよく呼ばれる）。これが発生した場合、ページをディスクから取り出して、物理メモリに戻す必要がある。同様のメカニズムでは、仮想メモリにマップされ、オンデマンドで物理メモリにロードされるメモリマップファイルで使用される。

【0011】

物理メモリがフルでない場合には、これは簡単な処理である。ページは、物理メモリに書き戻され、ページテーブル及びＴＬＢは、更新され、命令が再開される。しかしながら、物理メモリがフルの場合には、物理メモリの１つ以上のページは、要求されたページのための領域を作るためにページアウトされる必要がある。ページテーブルは、予め物理メモリにあったページがもはや存在しないことをマークし、ディスク上のページが物理メモリに現在存在していることをマークするために、更新される必要がある。また、ＴＬＢは、ページアウトされたページの除去及び命令の再開を含むように、更新される必要がある。ページアウトされたページは、ページリプレースメントアルゴリズムの対象となる。しかしながら、これらのアルゴリズムは、ハードウェアマネージメントの使用を介してもたらされ得る必要な機能を提供するのに失敗する。

【0012】

ＡＲＭプロセッサは、メモリサブシステムと相互作用するためにＡＣＥプロトコルを使用する。ＡＭＤｘ８６メモリサブシステム（ノースブリッジ）は、ＣＣＩプロトコルを使用する。ＡＲＭ ＡＣＥプロトコル及びＡＭＤ ＣＣＩプロトコルは、互換性がない。事実、ブリッジ接続する必要のあるプロトコル間の相違点が多数ある。いくつかの実施例では、要求、応答及びプローブ／スヌープエンコーディングを含む。ＡＣＥプロトコルは、メモリサブシステムにプッシュデータを書き込み、ＣＣＩプロトコルは、用意できた場合に、メモリサブシステム要求の書き込みデータを有する。プローブ／ビクティムデッドロックにおいて、ＡＣＥプロトコルは、プローブレスポンスのメモリサブシステムへの変更されたデータコピーバックを確実にプロセッサに渡すために許可し、ＣＣＩはこれを許可しない。ＡＣＥ及びＣＣＩパワーマネージメントコントロールシグナル及びハンドシェイクは、実質的に異なっている。両方のプロトコルは、異なるクロック周波数で動作するプロセッサ及びメモリサブシステムを可能とし、その一方で、ＣＣＩは、クロックを使用し、より高速なクロックドメインでクロック比の調整を処理するためのスキームを有効にし、ＡＣＥは、Ｒｅａｄｙ／Ｖａｌｉｄハンドシェイクを使用する。これらの２つのプロトコルを効果的にブリッジできるシステムが必要とされている。

【0013】

ＡＲＭベースシステムは、ｃＨＴベースシステムよりも異なるＣＰＵライトバックを有するプローブ／スヌープの競合状態を処理する。ｃＨＴシステムにおいて、ＣＰＵは、依存関係なしでプローブレスポンスを常に提供するために必要である。プローブがＣＰＵビクティムにヒットした場合に、ＣＰＵは、ビクティムが既に送信された（後にキャンセルされるであろう）かどうかを示し、プローブレスポンスでのライトバックデータを供給する。ビクティムが未だ設定されていない場合には、状態は、プローブの種類に応じてダウングレードされる。ＡＲＭシステムにおいて、ＣＰＵは、ブロックし、さらには、ライトバックが完了するまでプローブレスポンスを配信しない。これは、ＣＰＵ／クラスタ内でキューに入れられたプローブのために発生してもよく、未だ出されていない。したがって、統合ノースブリッジ（ｕｎｉｆｉｅｄ ｎｏｒｔｈｂｒｉｄｇｅ）は、ＡＲＭビクティム／プローブ衝突処理に基づいて、デッドロックになることがあるという問題が存在する。

【発明の概要】

【課題を解決するための手段】

【0014】

本発明は、新規のアトミックテスト［０］、ＯＲ及びマスクを介した、ハードウェアでのページテーブルアクセス及びダーティビットマネージメントを提供する。

【0015】

本発明は、ＡＣＥをＣＣＩにトランスレーション可能とするガスケットを提供する。このガスケットは、さらに、ＡＣＥ及びＣＣＩ間のトランスレータ要求、ビクティム及びプローブ衝突のためのデッドロック回避、ＡＲＭバリアハンドリング、並びに、電力管理相互作用を提供する。

【0016】

本発明は、統合ノースブリッジをデッドロックするＡＲＭビクティム／プローブ衝突を処理するためのソリューションを提供する。これらのソリューションは、専用のライトバック仮想チャネル、４ホップのプロトコルを使用するＩＯ要求のためのプローブ、及び、ビクティムが要求をパスするようにデータを用いて古いリクエストを更新するＭＣＴでのＷｒＢａｃｋ並べ替え機能を含む。

【0017】

より詳細な理解は、添付の図面と併せて実施例として与えられる以下の説明から得ることが可能である。

【図面の簡単な説明】

【0018】

【図1】１つ以上の開示された実施形態が実施される例示的なデバイスを示すブロック図である。

【図2】統合ノースブリッジ及びアトラスクラスタ（ａｔｌａｓ ｃｌｕｓｔｅｒ）間の処理のトランスレーションを提供するためのガスケットを含む例示的なシステムを示す図である。

【図3】全てのＣ６エントリを介してマスクされるインタラプトのフローを示す図である。

【図4】既存のＰ状態ロジックとの接続の例示的な図である。

【図5】ＷＦＩを用いたＰ状態シーケンスの例示的な図である。

【図6】ＷＦＥを用いたＰ状態シーケンスの例示的な図である。

【図7】ガスケット静止を用いたＰ状態シーケンスの例示的な図である。

【図8】ガスケット及び統合ノースブリッジ間のＮＢＳＹＮを横切る全てのインフライトトラフィックのフローの保証を提供する方法８００を示す図である。

【図9】デッドロックのフローを示す図である。

【発明を実施するための形態】

【0019】

本発明は、新規のアトミックテスト［０］、ＯＲ及びマスクを介したハードウェアでのページテーブルアクセス及びダーティビットマネージメントを提供する。また、本発明は、ＡＣＥをＣＣＩにトランスレーション可能なガスケットを提供する。さらに、このガスケットは、ＡＣＥ及びＣＣＩ間のトランスレータの要求、ビクティム及びプローブ衝突のためのデッドロック回避、ＡＲＭバリアハンドリング、並びに、電力管理相互作用を提供する。また、本発明は、統合ノースブリッジをデッドロックするＡＲＭビクティム／プローブ衝突を処理するためのソリューションを提供する。これらのソリューションは、専用のライトバック仮想チャネル、４ホップのプロトコルを使用するＩＯ要求のためのプローブ、及び、ビクティムが要求をパスするようにデータを用いて古いリクエストを更新するＭＣＴでのＷｒＢａｃｋ並べ替え機能を含む。

【0020】

図１は、一つ以上の開示された実施形態が実装され得る例示的なデバイス１００のブロック図である。デバイス１００は、例えば、コンピュータ、ゲームデバイス、ハンドヘルドデバイス、セットトップボックス、テレビ、携帯電話又はタブレットコンピュータを含んでもよい。デバイス１００は、プロセッサ１０２と、メモリ１０４と、ストレージ１０６と、１つ以上のインプットデバイス１０８と、１つ以上のアウトプットデバイス１１０と、を含む。デバイス１００は、必要に応じてインプットドライバ１１２及びアウトプットドライバ１１４を含んでもよい。デバイス１００は、図１に示されていない付加的な構成要素を含んでもよいことが理解されるであろう。

【0021】

プロセッサ１０２は、中央処理ユニット（ＣＰＵ１０２）、グラフィックス処理ユニット（ＧＰＵ）、同一のダイ上に配置されたＣＰＵ及びＧＰＵ、又は、１つ以上のプロセッサコアを含んでもよい。各プロセッサコアは、ＣＰＵ又はＧＰＵであってもよい。メモリ１０４は、プロセッサ１０２と同一のダイ上に配置されてもよいし、プロセッサ１０２とは別個に配置されてもよい。メモリ１０４は、揮発性又は不揮発性メモリ１０４（例えば、ランダムアクセスメモリ１０４（ＲＡＭ）、ダイナミックＲＡＭ又はキャッシュ）を含んでもよい。

【0022】

ストレージ１０６は、固定又はリムーバブルストレージ（例えば、ハードディスクドライブ、ソリッド状態ドライブ、光ディスク又はフラッシュドライブ）を含んでもよい。インプットデバイス１０８は、キーボード、キーパッド、タッチスクリーン、タッチパッド、検出器、マイクロフォン、加速度計、ジャイロスコープ、バイオメトリックスキャナ又はネットワーク接続（例えば、ワイアレス１４Ｅ８０２シグナルの送信及び／又は受信のためのワイアレスローカルエリアネットワークカード）を含んでもよい。アウトプットデバイス１１０は、ディスプレイ、スピーカ、プリンタ、触覚フィードバックデバイス、１つ以上のライト、アンテナ又はネットワーク接続（例えば、ワイアレス１４Ｅ８０２シグナルの送信及び／又は受信のためのワイアレスローカルエリアネットワークカード）を含んでもよい。

【0023】

インプットドライバ１１２は、プロセッサ１０２及びインプットデバイス１０８と通信し、プロセッサ１０２が、インプットデバイス１０８からの入力を受けることを許容する。アウトプットドライバ１１４は、プロセッサ１０２及びアウトプットデバイス１１０と通信し、プロセッサ１０２が、アウトプットデバイス１１０に出力を送ることを許容する。インプットドライバ１１２及びアウトプットドライバ１１４は、任意のコンポーネントであり、デバイス１００は、インプットドライバ１１２及びアウトプットドライバ１１４が存在しない場合には、同様に動作することに留意する。

【0024】

ページテーブル内のテーブルエントリのアクセスにおいて、ハードウェアは、アクセスビットを１に設定してもよい。Ｔｅｓｔ［０］ａｎｄＯＲアトミック（又は全て１のＯｐ２を有するＴｅｓｔ［０］ＳｅｔａｎｄＣｌｒ）が使用されてもよく、レジスタによって有効にされてもよい。ダーティビットメカニズムは、有益となり得る。例えば、要求が書き込み権限を必要とし、ＡＰ［２］が１’ｂ１である場合には、ハードウェアは、ＤＢＭビット（ラストページテーブル記述子のビット５１）をチェックし、ダーティビットが１’ｂ１に設定されている場合には、ＡＰ［２］を１’ｂ０に設定してもよい。Ｔｅｓｔ［０］ＳｅｔａｎｄＣｌｒアトミック（アトミックｏｐの３２ｂ及び６４ｂバージョンの両方がサポートされている）は、このステップで使用されてもよい。

【0025】

例えば、次のオペレーションは、ページテーブルを管理するハードウェアの機能として使用されてもよい。
Ｍｅｍ［Ａｄｄｒ］＝Ｍｅｍ［Ａｄｄｒ］［０］？（（Ｍｅｍ［Ａｄｄｒ］｜Ｏｐ１）＆Ｏｐ２）：Ｍｅｍ［Ａｄｄｒ］； （式１）

【0026】

式１は、設定がオペレーションを実行している場合であって、ビット０＝テストビットである場合に、メモリ１（Ｍｅｍ［Ａｄｄｒ］）を変更することを提供し、そうでなければ何もしない（Ｍｅｍ［Ａｄｄｒ］［０］）。オペレーションは、メモリアドレス上のオペランドＯｐ１及びＯｐ２のオペレーティングである。例えば、メモリアドレスは、Ｏｐ１及びＯｐ２に基づくＡＤＤＲで設定され及びクリアされてもよい。これは、ページテーブルを管理するハードウェアでの機能を提供する。

【0027】

アクセスビットのメカニズムが有効になっている場合、ダーティビットメカニズムが有効であってもよい。代わりにダーティビットメカニズムとともに、式２は、ＡＰ［２］が、ページがダーティかクリーンであるかをに示すことを許容する。
ＡＰ［２］＝１ − ページクリーン：ＡＰ［２］＝０ − ページダーティ （式２）

【0028】

アクセスビット及びＡＰ［２］ビットの両方は、単一のＴｅｓｔ［０］ＳｅｔａｎｄＣｌｒアトミックオペレーションの同じブロック／ページトランスレーションテーブルエントリからアップデートされてもよい。

【0029】

アクセスフラグを管理するためのハードウェアを使用することは有益である。例えば、セキュア及び非セキュアのＰＬ１＆０のステージ１トランスレーションのために、実装では、アクセスフラグのハードウェアマネージメントを提供してもよい。この場合、０に設定されたアクセスフラグを有するトランスレーションテーブルエントリが、トランスレーションルックアサイドバッファ（ＴＬＢ）に読み込まれている場合、ハードウェアは、メモリ内のトランスレーションテーブルエントリのアクセスフラグビットに１を書き込む。セキュアのためのアクセスフラグ及び非セキュアのＰＬ１＆０のステージ１トランスレーションのハードウェア管理の提供をする実装では、ハードウェアアクセスフラグフィールドＩＤ＿ＭＭＦＲ２［３１：２８］を使用してもよく、この実装の選択を示すためには、アクセスフラグのハードウェア管理を有効にするビットを１に設定することによって、ＳＣＴＬＲ．ＨＡビットを実装してもよい。

【0030】

ショート記述トランスレーションテーブル形式を使用する場合に、両方のＳＣＴＬＲ．ＡＦＥが、アクセスフラグの使用を可能にするために１に設定されている場合には、アクセスフラグのハードウェアマネージメントが行われ、ＳＣＴＬＲ．ＨＡは、アクセスフラグのハードウェアマネージメントを可能にするために１に設定される。ＳＣＴＬＲのバンキングは、ビットが、セキュア／非セキュアビットのための異なる決定を許容するセキュア及び非セキュアアドレストランスレーションのために独立して定義されるのを可能にする。アクセスフラグのハードウェアマネージメントが、アドレストランスレーションのステージのために有効になっている場合には、アクセスフラグフォールトは、対応するトランスレーションのために生成されない。これは、１つのアトミックアップデートでアップデートを可能にし、ハードウェアで管理されていない場合には起きることがない。

【0031】

本発明は、中央処理装置（ＣＰＵ１０２）のシンクロナイザとコアクラスタとの間のクロックドメインに置かれる「ガスケット」の実施形態に関する。ガスケットは、キャッシュコーヒーレントインターコネクト（ＣＣＩ）へのトランザクションと、スヌープへのシステムプローブのトランザクションとのトランスレーションを提供してもよい。また、ガスケットは、メモリマップ、転送サイズ、及び、統合ノースブリッジ（ＵＮＢ）／コヒーレントハイパートランスポート（ｃＨＴ）環境と相互作用するコアクラスタに必要な他の機能を変換してもよい。

【0032】

図２を参照すると、統合ノースブリッジ２８０とアトラスクラスタ２９０との間のトランザクションのトランスレーションを提供するガスケット２１０を含む例示的なシステム２００が示されている。図２に示すように、アトラスクラスタ２９０は、アトラスバスインタフェースのいくつかのチャネル２２０を含む。これらのチャネル２２０は、ＡＣＥリードレスポンスチャネル２２０ａと、ＡＣＥリードアドレスチャネル２２０ｂ１と、ＡＣＥライトアドレスチャネル２２０ｂ２と、ＡＣＥライトデータチャネル２２０ｃと、ＡＣＥライトレスポンスチャネル２２０ｄと、ＡＣＥスヌープレスポンスチャネル２２０ｅと、ＡＣＥスヌープアドレスチャネル２２０ｆと、を含んでもよい。チャネル２２０は、アトラスクラスタ２９０の各ガスケット２１０を使用して、ＣＣＩ２３０を介して統合ノースブリッジ２８０に変換されてもよい。例えば、チャネル２２０ａは、ＣＣＩリードレスポンス２３０ａに変換されてもよく、チャネル２２０ｂｌ，２２０ｂ２（まとめて２２０ｂ）は、ＣＣＩリクエスト２３０ｂに変換されてもよく、チャネル２２０ｃは、ＣＣＩライトデータ２３０ｃに変換されてもよく、チャネル２２０ｄは、ＣＣＩライトリード２３０ｄ１及びＣＣＩライトバッファリリース２３０ｄ２（まとめて２３０ｄ）に変換されてもよく、チャネル２２０ｅは、ＣＣＩプローブレスポンス２３０ｅに変換されてもよく、チャネル２２０ｆは、ＣＣＩプローブ２３０ｆに変換されてもよい。

【0033】

ローレイテンシシンクロナイザ２７０は、本明細書でさらに説明するように、ＣＣＩバス２３０から統合ノースブリッジ２８０に使用されてもよい。

【0034】

ＣＰＵ１０２からの要求は、アドバンスドイクステンシブルインタフェース（ＡＸＩ）コヒーレンシエクステンション（ＡＣＥ）コマンドから同等のＣＣＩコマンドに変換される必要がある。一般的に、各アームの要求タイプは、特定のＣＣＩ要求タイプにマップする。ＡＲＭコマンドタイプは、読み取り及び書き込みアドレスチャネルのＡｘＤｏｍａｉｎ及びＡｘＳｎｏｏｐに符号化される。ガスケット２１０の特定のトランスレーションは、多くの異なる形態にしてもよい。例えば、ＣＣＩリードレスポンス２３０ａからＡＣＥリードレスポンスチャネル２２０ａへのトランスレーションにおいて、リードデータキュー２３５が実施されてもよい。

【0035】

ＡＣＥリードアドレスチャネル２２０ｂ１及びＡＣＥライトアドレスチャネル２２０ｂ２からのトランスレーションでは、例えばマルチプレクサ２３７を使用する等して組み合わされてもよく、それからリクエスト／メモリトランスレータ２４０に入力されて、ガスケットリクエストキュー２４５を介してＣＣＩリクエストジェネレータ２５０に入力される。

【0036】

ＣＣＩプローブ２３０ｆからの変換において、ガスケットは、キュー２５９に出力するプローブ／スヌープトランスレータ２６０を含む。キュー２５９は、ＡＣＥスヌープアドレスチャネル２２０ｆに出力するために、プローブ／レスポンスインターロック２６５からの入力情報を受信する。

【0037】

ＣＣＩライトデータ及びＣＣＩリードデータ２３０ｄからＡＣＥライトレスポンスチャネル２２０ｄへのトランスレーションにおいて、ガスケット２１０のライトプロセッサ２５５が使用されてもよい。ＡＣＥスヌープレスポンスチャネル２２０ｅは、キュー２５７に入力され、キュー２５７は、ライトプロセッサ２５５からの入力を受信している間、マルチプレクサ２５４及びＣＣＩプローブレスポンス２３０ｅにデータを提供する。ＡＣＥライトデータチャネル２２０ｃは、キュー２５２に入力され、キュー２５２は、ライトプロセッサ２５５からの入力を受信している間、マルチプレクサ２５４に出力する。マルチプレクサ２５４は、ＣＣＩライトデータ２３０ｃに出力する。

【0038】

表１に示される次のトランザクションが使用されてもよい。

【表1】

【0039】

表１には、図２のパスａで行われるトランスレーションが示されている。ＡＣＥトランスレーションが左側に示され、ＣＣＩトランスレーションが上部に示されている。好ましいトランスレーションがグリーン（暗い影）で示され、代替のトランスレーションがピーチ（薄い影）で示されている。

【0040】

バスコネクションは、ＣＣＩがビット４７を介してアドレスアップをサポートしながら、ビット４３までのアドレスをサポートしてもよい。さらに、プロセッサは、完全なアドレス空間を使用できないかもしれず、そして上位４ビットのうちの１つ以上が使用されず、ゼロであると想定してもよい。そうでなければ、非稼働の上位ビットは、ゼロとして稼働され、又は、ＡＣＥ属性を移動するオーバーロードであってもよい。

【0041】

ビット［４４］を含む、現在定義されているオーバーロードは、ＡｘＰＲＯＴ［１］を移動し、ＡｘＰＲＯＴ［１］は、「セキュア」又は「非セキュア」アクセス（それぞれ０又は１）を示す。これは、バンクレジスタアクセスのための汎用インタラプトコントローラ（ＧＩＣ）によって使用される。このビットは、他の目的地に転送する前にＳＲＩロジックによってゼロにされてもよい。

【0042】

ガスケット２１０は、記載されているような要求を変換することに加えて、ＡＣＥタグをＣＣＩタグに変換するのに必要とされてもよいし、されなくてもよい。ＡＣＥタグ空間がＣＣＩタグ空間内に収まる場合には、その後のタグは、ガスケット２１０を変更せずにパスされてもよい。けれども、ＡＣＥプロトコルは、２つ以上のトランザクションを順に保持することを示すために同じタグの再使用を許容し、統合スブリッジ２８０は、一般的に順序を維持しない。結果として、同じタグ／ｉｄを共有するＡＣＥ要求は、統合ブリッジ２８０に達することから、重複タグとのトランザクションを防止するガスケット２１０内にシリアル化されてもよい。

【0043】

リクエスト／プローブの組合せの統合テーブルは、表２で提供されている。

【表2】

【0044】

表２では、リクエスト／プローブの組合せの統合テーブルが示されている。それらは、生成されたＩＤスヌープであるＡＲＭトランザクションを含んでもよい。グリーンスヌープ（濃い色のボックス）が好ましく、一方、ピーチスヌープ（明るい色のボックス）は代替のスヌープである。

【0045】

ＣＣＩエンコードされたプローブ２３０ｆは、プローブ／スヌープトランスレータ２６０を介して同等のＡＣＥスヌープトランザクションに変換されてもよい。ＡＣＥプロトコルは、スヌープチャネル上の通常のリードコマンドと、専用のキャッシュメンテナンスコマンドと、の組み合わせで使用する。表３のトランスレーションが使用されてもよい。

【表3】

【0046】

表は、使用され得るトランスレーションを提供する。トランスレーションは、ＡＣＥスヌープに基づくＣＣＩプローブ生成仕様を定義する。

【0047】

単一のＣＰＵ１０２クラスタが使用される場合において、ガスケット２１０によって受信したプローブは、上記の場合に限定した要求のＩＯ／グラフィックスプロセッシングユニット（ＧＰＵ）の結果であってもよい。

【0048】

ガスケット２１０がＣＣＩインタフェースからリードレスポンス２３０ａを受信する場合、クラスタ２９０への同等の応答をＡＣＥバス２２０ａで生成する必要がある。特定の状況において、ガスケット２１０は、データの全てのビートがＣＣＩインタフェース２３０ａから受信されるまで、ＡＣＥレスポンス２２０ａの起動を遅延させてもよい。これを必要とするいくつかの同一の状況がある。バーストの順序が異なっていてもよい。ＲｄＢｌｋＸトランスレーションは、ＡＣＥバス２２０によって期待されるラッピングバースト順にデータを提供する。エラーチェッキングコレクション（ＥＣＣ）エラーは、レスポンスの再生をもたらしてもよい（例えば、ＣＣＩリードデータが不完全でもよい）。

【0049】

システムメモリ１０４のマップは、インタラプトコントローラデコード等の目的でＤＲＡＭ対ＩＯを識別するために使用されなければならない。ＡＲＭ環境は、非ＤＲＡＭアドレスからＤＲＡＭを区別し、非ＤＲＡＭ空間をさらにサブ分割するためにＡＲＭメモリマップを使用する。ｃＨＴ環境は、アドレス領域の種類を示すための明確なＩ／Ｏ及び他のシグナルを使用する。ガスケット２１０は、ＳＲＩへの各要求とともに送信される期待された補助アドレスタイプシグナルを生成するために、メモリマップを使用してもよい。メモリマップは、ＡＲＭトランザクションをｃＨＴに変換するために使用されてもよい。アドレスベースレジスタは、ＧＩＣベースアドレスレジスタ（Ｒｅｑｌｏ及びＲｅｑＡｐｉｃを設定するため）、拡張コンフィグベース（ＲｅｑＥｘｔＣｆｇを設定するため）、及び、ＤＲＡＭベース（ＲｅｑＮｏｎＣａｃｈｅを設定するため）を含む。

【0050】

ＡＲＭベースシステムは、ｃＨＴベースシステムよりも異なるライトバックのＣＰＵ１０２を有するプローブ／スヌープの競合状態を処理する。ｃＨＴベースシステムにおいて、ＣＰＵ１０２は、いかなる依存関係なしにプローブレスポンスを常に提供するために要求される。プローブがＣＰＵ１０２ビクティムにヒットした場合、ＣＰＵ１０２は、ビクティムが既に送信されたか否かを示し（後にキャンセルされるであろう）、プローブレスポンスでライトバックデータを供給する。ビクティムがまだ設定されていない場合には、その状態は、プローブの種類に応じてダウングレードされる。ＡＲＭシステムにおいて、ＣＰＵ１０２は、ブロックし、さらには、ライトバックが完了するまでプローブレスポンスを提供しない。これは、ＣＰＵ１０２／クラスタ内でキューに入れられたプローブのために発生してもよく、未だ発せられていない。

【0051】

ＡＲＭプロセッサのデッドロックを回避するために、ライトバックは、ＤＲＡＭに排出するためのライトバックを許容する、独立した仮想チャネルへのアクセスを有してもよい。ＭＣＴの中で、これらのライトバックは、通常依存していたかもしれない同じアドレスに対して、より古い読み出しをパスしなければならない。これを実装するために必要とされる具体的な変更点は、ガスケット２１０を横断するライトバックのための非ブロッキングパス、ＳＲＱを横断するライトバックのための非ブロッキングパス、及び、クロスバーを介する非ブロッキングパスである。ライトバックは、ＭＣＴに到着するとき、以前の要求の依存関係を確立する必要がないが、むしろパスすることを許可される。また、最も古い読み取りは、ライトバックに依存してマークされ、ライトバックが完了した後に、既にに発せられた任意のＤＲＡＭリードオペレーションを再発行することを強制してもよい。

【0052】

プローブが完了していない、又は、ソースの実施が受信されていた場合、より以前の読み取りは、同じアドレスへのライトバック到着による「インタラプテッド」としてもよい。リードレスポンスがソースに発行され、且つ、ライトバックが到達する場合、プローブが応答される又はされないを知らせることができなくてもよい。これは、ＣＰＵ１０２にプローブレスポンスが与えられ、その後にライトバックが発せられた可能性がある。しかしながら、この場合に、ソースは、データを有するプローブレスポンスを受信してもよい。これが起きた場合、レスポンスは、再度発せられる必要がなくてもよい。ＭＣＴは、これを予測できないかもしれない。ＭＣＴが、ライトバックを並べ替えし、ＤＲＡＭへの読み取りを再発している場合、ＭＣＴは、新しいデータでレスポンスを再発するとよい。レスポンスが、ターゲット実施の前／ターゲット実施とともに存在している限り、新しいデータは、任意の事前のレスポンスに上書きするであろう。

【0053】

ガスケット２１０と同様に、メモリ１０４へのパスは、ＣＰＵ１０２がライトバックを発することができないように満たされている別の潜在的デッドロックのシナリオがある。プローブが、既に発行されたライトバック（内部でのバッファ）と一致して受信され、ＣＰＵ１０２がプローブを停止した場合に、デッドロックは、ライトバックが独自の仮想チャネルを有している場合であっても起きてよい。ＣＰＵ１０２／クラスタは、ライトバックと非ライトバック書き込みとをインターリーブしないことにより、この状況を回避する。したがって、発行されていないライトバックでのプローブ依存性がある場合、ライトバックタイプの書き込みがガスケット２１０に存在することができ、これらのライトバックが排出してもよく、発行される（及びドレインされる）ブロッキングライトバックを許容することである。発行された非ライトバックの書き込みがある場合、クラスタは、プローブに依存性がある任意のライトバック（未発のライトバックでさえも）を生成しなくてもよい。

【0054】

ガスケット２１０は、統合ノースブリッジ２８０ドメインのＳＲＩによって期待される５クロック分離に従う有効なデータを書き込むコマンドの書き込みを保証することの可能な予測されたＦＩＦＯの使用を含む、ドライビングのためのシンクロナイザ２７０スキップクロックロジックを観測し、シンクロナイザ２７０からのシグナルを受信する必要があるかもしれない。インカミングレスポンスは、５クロック分離に従ってもよい。ガスケット２１０は、ＡＣＥタイミングとともにＣＰＵ１０２へのレスポンスを転送してもよい。シンクロナイザ２７０は、シンクロナイザ２７０ＦＩＦＯがリーディング／ライティングを１０クロック後に有効にするか否かを示す信号を提供する。リーディング及びライティングを可能にするために別個のシグナルがある。ドライビングドメイン内のロジックは、シグナルがシンクロナイザ２７０の出力で受信されたとき、要求されたタイミングリレーションシップが観測されるようなシンクロナイザ２７０にシグナルを送信してもよい。ライトデータの場合において、これは、適切なリレーションシップと統合ノースブリッジ２８０によって観測されるＣＰＵ＿ＮｂＤａｔＶａｌの後に、ガスケット２１０が、ＣＰＵ＿ＮｂＤａｔ５の有効なクロックを駆動しなければならないことを意味する。同様に、ガスケット２１０は、ＮＢ＿ＳｙｓＤａｔＶａｌアサーション後の正確な５つの可能なクロックのＮＢ＿ＳｙｓＤａｔ上の有効なリードデータをサンプリングすることを期待すべきである。

【0055】

ＡＲＭライト（ｗｒｉｔｅ）は、ＣＣＩ許可よりも、サイズ及び／又はバイトの組み合わせでより多くの柔軟性を有する。したがって、特定のＡＣＥライトが複数のＣＣＩライトで破損する可能性がある。リクエストキュー２４５及び／又はライトバッファは、特定のバイトを追跡する必要があってもよく、すなわち、転送された及び適切なコマンドを生成する必要があり、全ての「サブライト」が完了し及びリリースされたときに、エントリ及びバッファを唯一割り当てる。

【0056】

ＣＣＩ／ｃＨＴは、バイトが、プレフィックスデータビート等のデータストリームに沿って可能になるように提供する。残りのデータビートのための有効な情報のバイトの全ては、単一のプレフィックスデータビートで提供される。有効なバイトは、アドレスとカウントフィールドとの文脈で解釈される。

【0057】

サポートされているサイズの説明は、ダブルワード（４バイト）オペレーションを含み、それは、６４バイトアラインブロック内の連続した完全なダブルワードの任意の数を転送する。カウントフィールドは、転送され得るダブルワードデータ要素の数の符号化を、指定されたアドレスから始まり昇順に行う。０から１５のカウントコードの各々は、転送される１〜１６のデータ要素を表す。６４バイト境界を越える要求は、アドレスの昇順に発せられた複数のトランザクションに分割されてもよい。

【0058】

バイトライトは、ナチュラリーアラインド３２バイトアドレスレジョンのバイトの任意の組み合わせで転送されてもよい。アラインド３２バイトバウンダリを横切る転送は、アセンディングアドレスオーダーに発せられたマルチプルＨｙｐｅｒＴｒａｎｓｐｏｒｔトランザクションに分割されてもよい。

【0059】

ＣＰＵ＿ＣＭＤ＿ＷＲＢＹＴＥ：５’ｂ０１０１０（整列３２バイトブロック内の１から３２のキャッシュ不可書き込み、潜在的な非連続バイト。ライト１又は２データビート。アクセス最下位バイトがバイト４から７である場合、ＲｅｑＡｄｄｒ［２］＝１。）

【0060】

ＣＰＵ＿ＣＭＤ＿ＷＲＤＷＯＲＤ：５’ｂ０１０１１（６４バイトブロックのうち１から１６の連続するダブルワードのノンキャッシュアブルライト。ライト１から４ビート。）

【0061】

ＡＣＥプロトコルは、データの各ビートと一緒にできるバイトを提供する。バイトイネーブルは、アドレス又は長さ情報と無関係に対応するデータバイトに適用する。任意の「サイズ」のＡＣＥの書き込みについて、バイトの任意の組み合わせの可能性が許可される。結果として、バイトライト（非連続、非ダブルワード整列、又は、複数のサイズの非ダブルワード）は、３２バイト境界にまたがり、及び複数の転送を要求してもよい。任意のＡＣＥライトは、最大２ＣＣＩタイプのバイトライトに変換されてもよい。

【0062】

ＣＰＵ１０２／クラスタ内での組み合わせライトは、１６バイト転送になってもよい。複数のＣＰＵ１０２で１６バイトライトが組み合わされているとしても、結果としてのバッファは、常に単一のＣＣＩＤＷＯＲＤライトに変換されることができる。任意の時間のライトは、無効な任意のバイトストローブとともに受信され、そのバッファは、シングルバイトライトトランザクション及び全ての他のバッファとともに直ぐにフラッシュされてもよく、複数のライトを組み合わせるかどうかにかかわらず、単一のＤＷＯＲＤライトで書き込まれてもよい。

【0063】

ここに記載のプロセッサコアは、ある程度のライト結合を提供する。しかしながら、プロセッサは、ライトデータの１６バイトを結合することのみ可能であってもよい。いくつかの用途のために、フルキャッシュラインまでのライト結合のためのかなりの利点があってもよい。ガスケット２１０に実装されたライトバッファの数は、ライトリクエストエントリの数より少なくてもよい。ライトデータは、ＳＲＩによってバッファから引き出されるまで保持されるのみであってもよく、一方で、ライトリクエストは、レスポンスがＣＰＵ１０２に送信されるまで（ＳＲＩバッファリリースベースオフのターゲット終了の後である）保持される必要がある。いくつかの又はこれらの全てにおいて、ライトバッファは、ライト結合能力を有してもよい。

【0064】

ライト結合能力の追加は、バッファをフラッシュすることが必要である。いくつかの可能なアルゴリズムがあり、構成モード及び並列の何れかの複数を実装する必要性があってもよい。ポッシブルバッファフラッシュトリガは、いつでも完全に有効なバッファであるマンダトリフラッシュと、いつでも未送信バッファが枯渇されているマンダトリフラッシュと、いつでもＣＰＵ１０２ライトがＣＰＵ１０２に既にオープンなバッファにヒットしないことと、いつでもオープンバッファの数のプログラムの制限が達成されていることと、及び、バッファを示す他のヒューリスティックがもはや書き込まれないことと、を含む。バッファフラッシュの制限は、正確なキャッシュ能力属性（バッファラブル）とともにライトを結合するときのみに含まれていてもよく、バリアのためにすべてのバッファをフラッシュする必要があり、ある実施形態において、ＤｖｍＳｙｎｃのためのすべてのバッファをフラッシュする必要があってもよい。

【0065】

バリアトランザクションは、そうでなければＡＲＭプログラミング／一貫性モデルが提供されない特定の順序保証を提供するために使用されてもよい。ＡＣＥプロトコルは、セパレートリード及びライトトランザクションチャネルを提供し、従って、バリアトランザクションは、リード／ライトペアとして発せられてもよい。両方のトランザクションが完了したら、それは、バリアの後に発せられたトランザクションが、バリアの前のトランザクションの後にオーダーされると想定しても安全である。ＡＣＥプロトコルは、バリアの２つのタイプ、メモリと同期を定義する。

【0066】

メモリバリアは、適切なドメイン内の別のマスターが、バリアの前に発せられた全てのトランザクションを観測することができた場合、保証するためにマスターによって発せられてもよい。メモリバリアは、メモリベースの通信のために使用されてもよい。例えば、メモリ１０４へのデータの配列を書き込むとき、マスターコンポーネントは、配列が可能であることを示すために、メモリフラグを設定する前にメモリバリアを発してもよい。フラグを観測することができる任意の他のマスターコンポーネントは、アレイに書き込むトランザクションを観測しなければならない。

【0067】

同期バリアは、バリアの前に発せられたトランザクションが、バリアが完了したときに適切なドメイン内のすべてのマスターによって観測可能であることを保証するために、マスターによって発せられてもよい。システムドメインの同期バリアは、バリアトランザクションの前に発せられたトランザクションが、バリアが完了する前に宛てられているエンドポイントスレーブに達していなければならない追加の要求を有する。同期バリアは、サイドバンドシグナリング通信の様々な形態で使用されてもよい。例えば、メモリ１０４へのデータの配列を書き込むとき、マスターコンポーネントは、アレイが可能であることを示すために、インタラプトを生成する前に同期バリアを使用してもよい。同期バリアが完了するとき、更新された配列は、ドメイン内のすべてのマスターコンポーネントによって観測されることを保証される。

【0068】

ｃＨＴプロトコルは、後の書き込みの観測が先の書き込みの観測を意味するような書き込み順序を提供する。これらの必要性は、メモリと同期バリア命令の処理の間にいかなる区別もない。両方は、全ての先のリクエストがＣＰＵ１０２に完了したことを示す前にＳＲＩにガスケット２１０によって発せられていることを単に確実にすることにより、ガスケット２１０内で完全に処理されてもよい。より古いリクエストが発せられたら（又は、より保守的に完了）、ガスケット２１０は、ＣＰＵ１０２にバリアトランザクションバックのレスポンスを送信してもよい。

【0069】

ＡＣＥは、リード及びライトリクエストチャネルの許可を提供するＡＲＰＲＯＴ［２：０］及びＡＷＰＲＯＴ［２：０］を提供する。これらのビットは、次のとおり定義される。

【0070】

ＡｘＰＲＯＴ［０］:０／１ 非特権／特権アクセス

【0071】

ＡｘＰＲＯＴ［１］:０／１ セキュア／非セキュアアクセス

【0072】

ＡｘＰＲＯＴ［２］：０／１ データ／命令アクセス

【0073】

唯一の非特権／特権ビットは、ＳＲＩを介してパスされる。これは、ＳＲＩが、ＧＩＣディストリビュータにプログラミングインタフェースを提供するために計画されているように必要であり、一部のレジスタは、仮想化をサポートするときに特権レベルに基づいてバンクされる。アドレス統合ノースブリッジ２８０のサポートされているアドレス空間は、コアのそれよりも大きいので、上位アドレスビットは、特権インジケータでオーバーロードにされてもよく、転送される必要があってもよい任意の追加のアクセス許可ビットのために同様なことを行ってもよい。

【0074】

ガスケット２１０は、電源マネージメントオペレーションへの関与のいくつかの度合を有している。ガスケット２１０は、クラスタによって提供される様々なイベントのカウントに必要なＣＡＣレジスタを実装し、パワーマネージメント状態を変更するための「静止」機能を提供することによって相互作用をしてもよい。ガスケット２１０は、入力シグナルを介してパワーマネージメントの要求によりさらにＣＣＩリクエストをブロックするように相互作用してもよく、優れたＣＣＩリクエストの完了を待つことで、その後にインタフェースがアイドルであることを示す出力シグナルを駆動する。

【0075】

パワーマネージメントの目的のために、サイクルカウントは、周波数に基づいて重み付けされてもよい。クラスタは、周波数情報へアクセスを有しない。周波数は、所望のＰ状態のレジスタのソフトウェアプログラミングの結果として統合ノースブリッジ２８０によって設定される。パワーマネージメントソフトウェア（ＰＥＰ）は、ガスケット２１０の周波数変化が発生する毎に重みを更新するＳＭＵをシグナルとしてもよい。他の方法として、Ｐ状態周波数テーブルは、ガスケット２１０に複製してもよく、現在のＰ状態の更新ライトは、ガスケット２１０によって観測され、重みで透過的に更新されてもよい。

【0076】

上記の方法に限定されるものではなく、カウンタのいくつかの数は、興味を起こさせると考えられるＰＭＵイベントシグナルのいくつかをカウントしプログラムされるように供給されてもよい。各カウンタは、どのＰＭＵイベント（バスリード／ライトの指示又はクロックイベント）がカウントされるのを示すかがプログラムされてもよい。例えば、サイクルの構成は、アクティブサイクルをカウントするイベント／インタラプト（ＷＦＥ／ＷＦＩ）シグナルのために待ちでカウントする。ＰＯＲ及びＳＭＵは、これらのカウンタのそれぞれに重みを提供してもよい。

【0077】

パワーマネージメントは、ソフトウェア及びインタラプトコントローラとインタフェースで接続している。１つの実施において、ソフトウェアコンポーネントはマイクロコードであり、インタラプトコントローラはＡＰＩＣである。ＡＲＭアーキテクチャにおいて、マイクロコードを実装するための規定はなく、インタラプトコントローラは、ＧＩＣである。

【0078】

パワーマネージメントは、実装固有のものである。ＳＯＣの特定のハードウェアは、ＯＳには確認できない。ＯＳは、各実装がベンダー固有のソフトウェアの後ろに隠している具体的に定義されたインタフェースを介して電源マネージメントハードウェアにアクセスする。Ｃ状態とＰ状態は、ＡＣＰＩコールを介してＯＳに通知され、ＯＳはマイクロコードによって捕捉され処理されるリクエストを生成する。ＡＲＭにおいて、コードのこの層は、Ｗｉｎｄｏｗｓ（登録商標）及びＡｎｄｒｏｉｄ（登録商標）の両方に供給されてもよい。Ｗｉｎｄｏｗｓ（登録商標）ＲＴにおいて知られているこのコードは、プラットフォームエンジンプラグイン（ＰＥＰ）及びＡｎｄｒｏｉｄ（登録商標）で、パワーマネジメントドライバコードがカーネルに直接コンパイルされてもよい。これらは、Ｃ状態のためのＣＰＵｉｄｌｅ及びＰ状態変更のためのＣＰＵｆｒｅｑの形式で入ってくる。パワーマネージメントハードウェアへのインタフェースは、ユーコードインタフェースに類似しており、ＰＥＰ又はカーネルドライバで行われてもよい。簡単にするために、リファレンスは、ＡＲＭの実装を説明しながらＡｎｄｒｏｉｄ（登録商標）カーネルドライバに提供されるであろう。ＰＥＰは、ＯＳソフトウェアスタックで異なる名前と構成であり、Ａｎｄｒｏｉｄ（登録商標）カーネルドライバ又はマイクロコードとしてＯＳにマイクロアーキテクチャを抽象化するのと同じ役割を果たしている。１つは、Ａｎｄｒｏｉｄ（登録商標）の電源マネージメントカーネルドライバアーキテクチャを取ることができ、ここでの記載に基づいてマイクロソフトプラットフォームにそれを適用する。

【0079】

ＡＰＩＣ又はＧＩＣは、マイクロコード（ユーコード）又は電源マネージメントハードウェアのカーネルドライバインタフェースとは異なり、ＯＳに対してアーキテクチャビジブルである。ＳＯＣハードウェアは、アーキテクチャに対応するインタラプトコントローラを実装してもよい。したがって、一般的な電源マネージメントハードウェアは、両方のインタフェースを収容してもよい。

【0080】

ＧＩＣｖ２の仕様が実装されてもよい。ＧＩＣｖ３と異なり、レガシーＧＩＣ−４００は、８コアまでサポートするために１つのハードワイヤードコンポーネントで配布及び配信（ＣＰＵ１０２インタフェース）の両方を実装する。ＣＰＵ１０２インタフェースの出力は、ＦＩＱ／ＩＲＱピン毎のコアと仮想化対応である。このアーキテクチャは、ＡＰＩＣに似ており、エッジは、Ｃ状態を終了する起動リクエストを生成するとともに、ソフトウェア（ＣＣ＿ＩＮＴ＿ＭＡＳＫ）とハードウェアの両方を使用してマスクされてもよい。

【0081】

パワーマネージメントは、ソフトウエアサポートの要求でフローする。インタラプトは、最初にユーコードによって傍受され、これらのユーアーチインタラプトを内部でサービスし、それからＯＳにアーキテクチュラリビジブルの１つを転送する。ｕａｒｃｈインタラプトは、ストップクロック（ＳｔｐＣｌｋ）及びスタートクロック（ＳｔａｒｔＣｌｋ）を含む。ＡＲＭコアはユーコードを実装していないので、ＧＩＣインタラプトはＯＳに表示される。ＡＲＭ上のＳｔｐＣｌｋ及びＳｔａｒｔＣｌｋをサポートするために、ベンダー固有のインタラプトハンドラは、ＯＳによってデバイスとして扱われ得る統合ノースブリッジ２８０のために登録されてもよい。

【0082】

ＡＰＩＣインタラプトの配信は、リモートライト（外部インタラプトのために）及びローカルインタラプトピンの何れかを介して行われてもよい。ローカルインタラプトの実施例は、ＡＰＩＣ３３０である。これは、リクエストパーフォーマンス状態がサーマルイベントにより絞られ又は復元されているＯＳに意味するように使用されている。ＧＩＣインタラプト配信は、ＡＰＩＣリモートライトに似たデータファブリックへのＡＸＩインタフェースを介したものと、共有ペリフェラルインタラプト（ＳＰＩ）又はプライベートペリフェラルインタラプト（ＰＰＩ）の形でローカルインタラプトピンを介したものとの両方である。各ＳＰＩは、単一のコアをターゲットとするようにプログラムされてもよい。ＳＰＩを使用することにより、統合ノースブリッジ２８０は、ファブリック及びインタラプトをリクエストするＧＩＣにＡＸＩメッセージを生成する必要がない。ＡＰＩＣ３３０において単一ＳＰＩが採用されてもよい。マルチコアをターゲットにしたインタラプトのために、ＳｔｐＣｌｋ、ＳｔａｒｔＣｌｋ、ＤｂＲｅｑ及びＤｂＲｅｑ２等の統合ノースブリッジ２８０は、インタラプトタイプ毎にコア毎に１つのＳＰＩ ｉｄを確保し、コアをターゲットにするＳＷ構成の要求であってもよい。４つのみのコアがある場合には、ＳｔｐＣｌｋ、ＳｔａｒｔＣｌｋ及びＤｂＲｅｑの実装により、最大１６のＳＰＩが使用されてもよい。

【0083】

代替としては、ｎＬＥＧＡＣＹＩＲＱ［ｎ］／ｎＬＥＧＡＣＹＦＩＱ［ｎ］ピンに統合ノースブリッジ２８０マルチターゲットインタラプトをフックすることであり、ＰＰＩからＧＩＣ−４００として可能とされる。ステータスレジスタは、同じピンに符号化されたサブタイプを決定するためのインタラプトハンドラのために供給されてもよい。これは、従来のピンと共有するインタラプトが、同じ優先度を共有することを要求してもよいが、ＳｔｐＣｌｋ、ＳｔａｒｔＣｌｋ及びＤｂＲｅｑが最高の優先度に設定されてもよい。

【0084】

現在、ＡＰＩＣは、ｎｂｃｏｒ４４０（例えばＮＢＡＰＣ＿Ｉｎｔｒ）にインタラプトエッジを駆動し、それからコア（例えばＮＢＣＯＲ＿ＩｎｔｒＥｄｇｅ）にレベルインタラプトピンを設定する。ユーコードは、それから保守を行うときにＳｐｒＣｌｒｌｎｔ（Ｆ３ｘＢ４）を介してそれをクリアにする。ＧＩＣｖ２は、レベルピン（例えばＩＲＱ／ＦＩＱからｎｂｃｏｒ４４０）を駆動する。しかし、これらは、コアがインタラプトを確認した後、これらの代わりに、ＧＩＣ４１０自体でクリアされてもよい。これは、アーキテクチャ定義されたＧＩＣ４１０ピンのためのＳｐｒＣｌｒＩｎｔを実施する必要性を最小限にする。ｎｂｃｏｒ４４０の中のＩＲＱ／ＦＩＱピンが、トリガ起動などのＩｎｔｒＥｄｇｅとして変化し、使用されてもよい。

【0085】

既存のｕＡｒｃｈインタラプトは、ＧＩＣ４１０の中で駆動され、ＦＩＱ上に出てくる。また、ＳｔｐＣｌｋＥｄｇｅ、ＳｔａｒｔＣｌｋＥｄｇｅ及びＤｂＲｅｑＥｄｇｅを含み、これらのインタラプトの殆どのためにｎｂｃｏｒ４４０のレベルインタラプトピンを実装する必要は、もはやない。既存のピンは、レベルからエッジに変換され、ｎｂ−＞コアからｎｂ−＞ＧＩＣに再ターゲットされてもよい。２つの別々のレベルのインタラプト状態をクリアするインタラプトハンドラのための理由はない。上記の３つの使用される唯一のレベル表示は、ＳｔａｒｔＣｌｋＥｄｇｅであり、それは、通常とｉｓｏｃヒステリシスカウンターとの間で切り替えるために使用される。使用は、ＳｔａｒｔＣｌｋが行われるまでのスワップを遅らせるのみであり、起こるシナリオはＣｌｅの周りであり、これは我々が安全に無視することができる。唯一の例外はＤｂＲｅｑであり、それは、キャンセルを生成するためにそのレベル表示を使用し、そうして我々は、ＤｂＲｅｑ２が取られ及びそうしてそのポイントを超えるキャンセルを回避することを表示するＳｐｒＣｌｒｌｎｔを介してシグナルにＳＷを必要とする。これは、ＤｂＲｅｑ２のためにＦＩＱエッジをクリーニングに追加している。

【0086】

現在、統合ノースブリッジ２８０Ｃ状態は、外部インタラプトをカバーするＩｎｂＷａｋｅで終了する。また、コアを起動する必要のあるローカルソースインタラプトのために、それらがＡＰＩＣ ＩｎｔｒＥｄｇｅ及びＤｂＲｅｑからマップにすることのできるタイプは、キーオフにされてもよい。ＧＩＣのために、ローカルインタラプトが処理されてもよい。ローカルＳＰＩからＧＩＣへの入力がフリーランニングクロックである場合には、ローカル入力がＦＩＱ／ＩＲＱ又はエラーや仮想化対応でそれを行うことを想定し、そうして我々は単に終了をアイドルにして再マップする。入力がＧＩＣに入る前にゲートされたロジックを通過する場合には、これらのインタラプトのソースは終了をアイドルにしてもよい。

【0087】

ｘ８６／ＡＣＰＩ上にプロセッサのアイドルをヒットした場合に、ＯＳのリクエストは、停止命令を介して停止し、又は、ＩＯは、ＡＣＰＩによってＣ状態アドバタイズドオフセットを設定した後に読み込む。停止又はＩＯリードは、マイクロコードでトラップされ、それから統合ノースブリッジ２８０に停止特殊ブロードキャストサイクル（ＳＢＣ）を発し、ファブリックが静止するのを待ち、それから、ＣｏｎｎｅｃｔＭａｓｋサイドバンドを無効にする。ラストコアエンタリングＣ状態からＳＢＣは、全てのコアのＣ状態の開始をシグナルするＦＣＨに下流システムマネージメントコマンドを生じさせる。これは、より深いＣ状態にアップグレードを管理するモニターを駆動するために使用されてもよい。ＣｏｎｎｅｃｔＭａｓｋサイドバンドは、パワーマネージメントを開始するために使用される。

【0088】

ＡＲＭ／Ａｎｄｒｏｉｄ（登録商標）において、ＯＳは、事前に定義されたＡＰＩを介して供給されるＣＰＵｉｄｌｅカーネルドライバのコードを呼び出す。ＣＰＵｉｄｌｅは、メモリ１０４のマップされたアドレスを介して停止ＳＢＣをＮＢに発してもよい。ｘ８６において、これはＦＤＦ９１ベースでマップされている。これは、統合ノースブリッジ２８０にハードコードされており、そうしてＡＲＭコアは、そのアドレスにメモリ１０４リクエストを生成できるようにする必要があってもよい。これは、モニタートレーニングと同様にＦＣＨ通信を満たす。ＣＰＵｉｄｌｅは、それからＳＴＡＮＤＢＹＷＦＩサイドバンドをアサートするＷＦＩ命令を発する。ＳＴＡＮＤＢＹＷＦＩは、反転され、それから統合ノースブリッジ２８０の内部でＣｏｎｎｅｃｔＭａｓｋ内として扱われる。

【0089】

特定のコアにおいて、ＣｏｎｎｅｃｔＭａｓｋをみることは、停止中、デアサートであってもよく、又は、ＨＴＣ ＳＢＣ（Ｐ状態用）は、ＣＫに差し迫ったクロッキングリクエストのためのデータファブリックを用意するためのハードウェアを開始してもよい。実際のクロッキングリクエスト発生に進む前に、以下の処理が完了してもよい。

【0090】

１．ブロックプローブは、全てのコアを発し、それらのプローブレスポンス及び／又は完了するデータ移動のために待つことによって影響を受けたコアから全てのペンディングプローブを排出する。これは、ＣＰＣが全てフラッシュされる場合には適用されない。

【0091】

２．それらのＮｂＢｕｓｙをドロップして影響を受けたコアを待つ。ＮｂＢｕｓｙはローパワー状態（例えばスクラビングの間）でのコアの抵抗である。

【0092】

３．ＮＢＳＹＮ ＦＩＦＯへのラウンドトリップ遅延をカバーするのに十分な時間を無条件に待つ。ＦＩＦＯの中でインフライトトラフィックによってトリガされた新しいイベントは、反対を提起するのに十分な時間を有してもよい。

【0093】

４．ペンディングＡＰＭのためのブロック及びウエイトが、返答又は応答されるＣａｃインタフェースに要求する。

【0094】

５．パワーダウンのためのヒステリシスを満足する。ヒステリシスは、プローブの到着率（通常）及びインターリクエストプローブギャップ（ｉｓｏｃ）の両方のために実装される。ＣＰＣは全てフラッシュされる場合に適用されない。

【0095】

パワーマネージメントは、ＣｏｎｎｅｃｔＭａｓｋデアサーションの存在下で無効にされてもよい。ＥｎａＣＰＵＤｉｖ１ＬｏｗＰｗｒ？＝０を有するｄｉｖ−１にクロック除数を設定することは、ローパワーエントリをスキップしてもよく、ＣＫにクロッキングリクエストをもたらさなくてもよい。

【0096】

統合ノースブリッジ２８０は、有効なプローブ（プローブ有効ＣＣ１として参照）を有するゲートされたコアクロックと、無効なプローブ（プローブ無効ＣＣ１として参照）を有するゲートされたコアクロックと、フラッシュされたキャッシュ（キャッシュフラッシュオンホールトＣＦＯＨとして参照）を有するゲートされたコアクロックと、リテンションモード（ＲＣＣ３）と、を含むクロッキングリクエストタイプをＣＫに生成してもよい。

【0097】

有効なプローブ（プローブ有効ＣＣ１として参照）を有するゲートされたコアクロックのために、ＣＫは、ターゲットコアに全てのクロックゲートをデアサートしてもよく、それからプローブに関連したゲートを再度有効にする。Ｌ２は、再有効プローブゲートを無視しコアを残し、自身のクロックがプローブの存在下でランプアップ／ダウンを行うことに留意する。他のコアは、ＷＦＩを送信するときのゲートそれ自体をクロックしてもよく、ＣＫによりクロックゲートすることをさらに必要としない。ＣＣ１は、ＣＣＲからＥｎａＣＰＵＤｉｖ１ＬｏｗＰｗｒ？＝０を有するｄｉｖ−１の設定によって単に無効なパワーマネージメントとしてコア上で実装されてもよい。

【0098】

無効なプローブ（プローブ無効ＣＣ１として参照）を有するゲートされたコアクロックに関して、プローブゲートが再有効になっていない以外は、プローブ可能な場合と同様である。このモードは、いくつかのコアで使用されておらず、チキン（ｃｈｉｃｋｅｎ）ビットとしてのみ存在する。プローブの存在下において、パワーマネージメントは、ヒステリシスを保証する準備ロジックとともに、Ｃ状態の終了及び再入力を要求するために必要とされる。

【0099】

フラッシュされたキャッシュ（キャッシュフラッシュオンホールトＣＦＯＨとして参照）を有するゲートされたコアクロックのために、このモードは、無効なプローブ及び入ってくるプローブをサービスするために立ち上げることなしに、ゲートされた状態のクロックへの存在を可能にする。このモードは、全てのＣＰＣがフラッシュされているときにのみ有益である。

【0100】

保持モード（ＲＣＣ３）に関して、これはプローブ無効ＣＣ１の深いバージョンであり、コア電圧が、パワーゲーティング（ＰＧ）ヘッダーを調整しフィードバック回路を介してその電圧を維持することによって低減される。遅延特性は、プローブ無効ＣＣ１に似ているが、より多くの電力を節約している。ＲＣＣ３は、フラッシング又はフラッシングなしで適用されてもよく、フラッシングが、それをより良いＣＦＯＨモードにする。

【0101】

いくつかのコアは、保持モードを可能にするために、パワーコントローラとＱチャネルハンドシェイクとを必要とすることで、このモードを実施してもよい。このハンドシェイクを行うことなしに、クラスタは、コアに自動的にクロックゲートし、プローブにサービスするため、及び、ファブリックの介入なしにインタラプト上のＷＦＩから終了するために、自動的にクロックをランプする。このハンドシェイクを行った後、クラスタは、何れかのタスクを完了するようにローパワー状態からの終了を可能にするために、ハンドシェイクの完了に依存してもよい。保持モードは、ハンドシェイクによって許可されたとき、ファブリック内の電力コントローラの制御下で入力／終了とされる。このように、ＷＦＩにおいて、クラスタは、第１のアサート有効ＳＴＡＮＤＢＹＷＦＩでもよく、そのクロックをゲートオフしてもよい。いくらかの後に、保持ハンドシェイクが許可されていることを示すＣＰＵＱＡＣＴＩＶＥをデアサートにするだろう。パワーコントローラは、保持を要求するＣＰＵＱＲＥＱをアサートにしてもよい。クラスタは、ＣＰＵＱＡＣＣＥＰＴ又はＣＰＵＱＤＥＮＹをアサートにすることにより、３ウェイハンドシェイクの３番目の部分を介して許可又は拒否してもよい。それ以前に、インタラプトは、自動的にコアを目覚めさせ、ハンドシェイクの場合にＣＰＵＱＤＥＮＹを生じる。ＣＰＵＱＡＣＣＥＰＴを発見した後、保持エントリはコミットされたとみなされ、クラスタは、保持を終了するパワーコントローラに依存し、それからクロックゲーティング又はＷＦＩを終了する前にＣＰＵＱＡＣＣＥＰＴをデアサートにする。

【0102】

コアＣ状態コミットポイントは、統合ノースブリッジ２８０の中でＳｅｔＣＰＵＬｏｗＰｗｒである。この機能をサポートするために、ハンドシェイクが完了する必要があってもよい。ハンドシェイクの開始をトリガする最高の場所は、ＣＰＵＬｏｗＰｗｒＲｅｑアサーションであり、これは、ＳＴＡＮＤＢＹＷＦＩアサーションを占めており、それからＣＰＵＷＡＣＣＥＰＴアサーションまでＶｃｅＬｏｗＰｗｒＲｄｙをブロックする。これは、コアがコミットしている保証となる。

【0103】

ＧＩＣ−４００は、ＣＰＵ１０２インタフェースからＦＩＱ／ＩＲＱピンで直接インタラプト入力を公開する。これらのインタラプトは、ＰｗｒＭｇｔＯｒＳｔｐＧｎｔＣＣ６ＭａｓｋＩｎｔＣＰＵによってコアからマスクされてもよく、ＲＣＣ３（又はＣＣ６の中）にコアの常駐をカバーする。ＦＩＱ／ＩＲＱエッジは、ＲＣＣ３からの終了をトリガし得るＩｏｂｃＯｒＨａｌｔをクリアするために、既存のロジックを使用して起動イベント（ＣｏｒｅＷａｋｅＵｐＩｎｔ）を生成するのに使用されてもよい。終了が完了すると、ＰｗｒＭｇｔＯｒＳｔｐＧｎｔＣＣ６ＭａｓｋＩｎｔＣＰＵをデアサートにすることができ、全てのインタラプトが送られてもよい。インタラプト配信は、ＣＰＵＱＡＣＴＩＶＥをデアサートにトリガしてもよく、統合ノースブリッジ２８０が、ＣＰＵＱＲＥＱをデアサートすることによって保持ハンドシェイクを終えてもよい。

【0104】

ＣＰＵＱＡＣＴＩＶＥは、保持におけるコアをターゲットとするプローブにデアサートとしてもよく、ＲＣＣ３は、キャッシュフラッシュの後に有効にしてもよい。このようにして、プローブは起動状態にならない。Ｌ２は、l２＿ｓｎｐ＿ａｃｔｉｖｅがｃｋ＿ＣＰＵ＿ｌｏｇｉｃを起動するＬ１のためのスヌープフィルタを実装する。これは、Ｌ１フラッシュコアがＬ２からのプローブを参照できないことを意味し、システムプローブに入ってくる保持の終了がないことを保証すべきである。

【0105】

さらに、コアは、仮想メモリ１０４（ＤＶＭ）の操作の分散を受けたＣＰＵＱＡＣＴＩＶＥをデアサートする。ＤＶＭ操作は、ＴＬＢシュートダウン、ＢＴＢ無効化及びｉキャッシュ無効化を含み、コアは、ＣＰＵＥＣＴＬＲ ＳＭＰビットをクリアすることにより、非対称マルチプロセッシング（ＡＭＰ）モードに対称（ＳＭＰ）から切り替えることによって、コヒーレンシ（例えばそのパワーダウンシーケンス）で取り出されていない限り、プロトコルにおけるコアの関与を必要とする。ＣＣ６フローにおいて、パワーダウンは、ＤＶＭターゲットのための無効化として機能する。しかし、保持のために、終了時のリセットは、引き出されなくてもよく、ＤＶＭ操作のサービス又は構造を無効にするランプアップの何れかであり、ＴＬＢ及びＢＴＢを含み、前の保持へのエントリが発生してもよい。ｉキャッシュは、キャッシュフラッシュシーケンスで無効化されていてもよい。ＤＶＭ操作は、プローブとは異なり、非インタラプトソースからの保持の終了をサポートするために稀であると仮定してもよく、ＤＶＭのトリガされた終了は、コアが非プローバブルＣ１状態である間にプローブに沿った終了パスに類似していてもよい。以下のコードは、プローブパスを処理してもよい。
ＣｌｒＣＰＵＬｏｗＰｗｒＰｒｅ＿ｍｌ［ｉ］＝（〜ＣＰＵＬｏｗＰｗｒＲｅｑ［ｉ］｜ＳｒｑＣＰＵＰｒｂＲｅｑ［ｉ］｜ＥａｒｌｙＩｎｔｒＲｅｑ［ｉ］）＆ＣＰＵＬｏｗＰｗｒＡｃｔｉｖｅ［ｉ］＆〜ＷａｉｔＣｌｒＣＰＵＬｏｗＰｗｒ［ｉ］＆〜ＣｌｒＣＰＵＬｏｗＰｗｒＦｏｕｎｄ；
ＳｒｑＣＰＵＰｒｂＲｅｑ［ｉ］＝（（ＡｎｙＳｒｑＰｒｂＶａｌ＿ｄｌ｜ＳｒｑＡｎｙＣＰＵＰｒｂＲｓｐ）＆〜ＳｒｑＭａｓｋＰｒｂＷａｋｅＵｐＣＰＵ［ｉ］）｜ＣｋＥｘｉｔＴｏＰｓｔａｔｅ＿ｄｌ。

【0106】

ＤＶＭ検出のローパワーからの終了が発生してもよく、ＩｏｂｃＯｒＨａｌｔの変更なしで終了が一度完了すると、エントリが発生してもよい。ｉキャッシュがフラッシュされていても、ＳＭＰモードでのコアは、ｉキャッシュ無効化ＤＶＭに応答する必要があってもよく、ＤＶＭ操作のＣＰＵＱＡＣＴＩＶＥデアサートを表示してもよい。

【0107】

コアサイドのＱチャネルのロジックは、コアが保持している間に処理されてもよい。これは、動作電圧が所定の位置であり、保証された低いｄｉ／ｄｔそのものであることを意味する。これは、ＮＢ ＡｌｔＶｉｄと同じ制約である。バックアップのため及び潜在的に低い保持電圧のために、モードは、ソフトウェアでのＴＬＢ及びＢＴＢを無効化するようサポートしてもよく、それからＳＭＰビットをオフにしてもよい。このモードにおいて、Ｑチャネルハンドシェイクのアンワインド（ｕｎｗｉｎｄ）は、終了の唯一のソースとしてインタラプトを仮定することにより矮小化してもよいし、共にＱチャネルハンドシェイクを無効にしてもよい。後者は、簡単なアーキテクチャであるが、予想外の方法でコアへのインタフェースのリスクを伴う。

【0108】

統合ノースブリッジ２８０からＣＫへのＲＣＣ３シグナリングにおいて、ＸＶコンピュータユニット内のコアは、例えば非コア毎のＣ状態で、ＲＣＣ３の全てを一度に入り、このように、ＲＣＣ３エントリとともにｎｂｓｙｎパワーオフに常に結合する。これは、ＲＣＣ３（対プローブ可能Ｃ１）及びｎｂｓｙｎ電源オフの両方のシグナルへのＮＢ＿ＰｗｒＭｇｔＲｅｑＰｒｂＥｎ＝＝０を許容する。ＲＣＣ３の１つの実装の間、これらは、分離される必要がなくてもよく、ＲＣＣ３はコア毎であり、ｎｂｓｙｎ電源オフはＣＰＣ又はクラスタ毎である。ｎｂｓｙｎ電源オフは、別々のＮＢ−＞ＣＫインタフェースシグナルに分離されてもよく、ＮＢ＿ＰｗｒＭｇｔＲｅｑＣｃｉＥｎとしてそれを参照し、これはＲＣＣ３又はＣＣ６に入るラストコアがクリアされるのみである。

【0109】

ＣＣ６を入力するために、統合ノースブリッジ２８０は、ＣＫに対してクロッキングリクエストのパワー切り替えを要求してもよい。ＣＣ６は、キャッシュとコア状態がフラッシュされたときにのみ許可される。ＣＣ６は、ＲＣＣ３対追加の電力節約を提供するが、終了時に状態の復元を要求して、終了待ち時間が増加する。Ｌ２からの復元のときのＣＣ６終了は、Ｌ２がＣＣ６（別名ＸＣ６）の中であることを含む全てのＣＰＣである場合にＤＲＡＭから、〜２０μｓから〜４０μｓ及び〜８０μｓのときである。ＲＣＣ３終了は〜ｌμｓである。ＣＣ６終了は、ＣＣ１又はＲＣＣ３より異なっていないトリガであり、それは、ＩｏｂｃＯｒＨａｌｔをクリアする保留中のＡＰＩＣインタラプトエッジを使用するのに用いられ、したがって終了条件を生じる。

【0110】

ＧＩＣ−４００は、プロセッサスリープビットを実装していない。ハードウェアの実装は、ＧＩＣ−４００でのディストリビュータと共通の配置のＣＰＵ１０２インタフェースからのアウトプットで動作することが期待される。ＧＩＣ−４００は、３つのモードでそのＣＰＵ１０２インタフェースでのＦＩＱ／ＩＲＱの動作をプログラムしてもよい。これらは、
（１）ＧＩＣからのｎＩＲＱＣＰＵ［ｎ］／ｎＦＩＱＣＰＵ［ｎ］ピンが全ての状況で駆動される通常モード、
（２）レガシーＦＩＱ／ＩＲＱピンを有するＧＩＣアウトプットをオーバーライドするバイパスモード、及び
（３）低電力終了のためのタイプのインタラプトの存在下での電力コントローラにｎＩＲＱＯＵＴ［ｎ］／ｎＦＩＱＯＵＴ［ｎ］ピンを代わりにドライブし、コアにＩＲＱ／ＦＩＱピンをマスクするバイパス無効モード、を含む。

【0111】

実施例の方法として、通常モードは、実施され及び存在する統合ノースブリッジマスキング及びインタラプト起動メカニズムが使用されてもよい。ＧＩＣは、全ての状況にアップしていると仮定し、電源マネージメントは、エッジがコアによって表示されていないケースの周りに配信することを保留してもよい。これは、アラウンドＣ６（ＲＣ３及びＣ６のために使用され、存在するＣ状態インタラプトマスキング）を意味し、ＣＣ１のための無効は、ハードウェアマスクを形成してもよい。Ｃ６において、マスク（Ｃ６終了リセット）をクリアすることは、ソフトウェアによって実行されてもよい。全てのＳｔｐＣｌｋマスクは、アラウンドＣ６で行われてもよい。Ｃ６マスクは、ＧＩＣ−４００フローのソフトウェアの代わりにハードウェアによって設定されているので、別個の統合ノースブリッジのマスクは、ＳｔｐＣｌｋイベントの周りのエッジをフィルタすることを要求されない。統合ノースブリッジハードウェアは、ＩｏｂｃＯｒＨａｌｔステータス及びＳＴＡＮＤＢＹＷＦＩアサーションに基づいてＳｔｐＣｌｋマスクを内部で決定してもよい。ＳｔｐＣｌｋマスキングは、これがＳｔｐＣｌｋを取るための保持からコアを終了してもよいように、ＲＣ３コアに設定されない。

【0112】

Ｃ６終了において、対象とされるコアがリセットしてもよく、例外ベクトルからコードのフェッチングを開始してもよく、ピンストラップカミングアウトのリセットを介して、０、ＦＦＦＦ００００又は別のアドレスで固定されるアドレスに配置される。このアドレスは、ブートＲＯＭに通常マップされる。例外ベクトルは、リセットハンドラがエントリであるインサイドのジャンプテーブルに実装する。リセットエントリにジャンプし、それからリセットハンドラを発生する。このコードは、リセットが、ワーム／コールドリセット対Ｃ６終了のために引き出されたかどうかを判断するために、Ｃ６ＥｘｉｔＲｅｓｅｔ ＳＰＲをチェックしてもよい。Ｃ６終了は、それからＣ６ハンドラにジャンプしてもよく、ワーム／コールドリセットがブートコードにジャンプしてもよい。統合ノースブリッジ２８０が、例外ベクトルが配置されているアドレスを指定する選択を有していることを与えられると、統合ノースブリッジ２８０は、効果的なｕｎｉｑｕｉｆｙ Ｃ６終了対ワーム／リセットのブート後にベクトルを再配置することを選択してもよく、そのためリセットハンドラはタイプをチェックする必要がない。これは、異なるメモリ１０４の領域に配置されるＣ６ハンドラを可能にしてもよく、このため、Ｃ６終了のＲＯＭから最初のフェッチを回避するためにブートＲＯＭの代わりにより速いＤＲＡＭが配置されてもよい。これを可能にするために、ガスケット２１０は、例外ベクトル配置のソフトウェアのプログラマビリティを実現してもよく、このため、ＢＩＯＳがリセットフローを完了した後、ＢＩＯＳは、将来のＣ６終了の他のオフセットにそれを設定してもよい。例外ベクトルのメモリ１０４のマッピングは、ブート結果の確保を有することに注意し、その場合には、ＰＳＰは、ＤＲＡＭを初期化し、ガスケット２１０にクレジットを送る前にそこに安全なブートコードをデポジットし、効果的にＤＲＡＭにマップされるブートコードを可能にする。安全ではないブートは、ヒューズ構成されたアドレスとしてブートＲＯＭに配置されてもよい。Ｃ６終了又は安全なブートは、ＤＲＡＭでＦＤＦ７レンジにあるＣ６領域のアドレスに例外ベクトルをピンストラップしてもよい。ガスケット２１０は、それから、ヒューズ又はＣ６ＥｘｉｔＲｅｓｅｔＣＣＩシグナリングに基づくこれらのレンジの間で選択する。

【0113】

コアは、ｉｍｐｌｉｃｉｔＸＣ６を実行する。これは、ＣＣ６に入っている最後のコアの上のＸＣ６に自動的に入ることを意味する。ＲＸＣ３は、最終的な結果としてのクラスタ状態が全てのＲＣＣ３又はＲＣＣ３とＣＣ６コアとの混合であるＣ状態に入っている最後のコア上でＬ２の保持を必要とすることによって実行されてもよい。ＲＸＣ３は、キャッシュフラッシュの後に一般的に使用されてもよい。

【0114】

Ｌ２は、フラッシュされずに（Ｌ２休止中モード）残っていてもよく、ＲＸＣ３からサービスプローブに強化する。最後のコアは、最後のキャッシュフラッシュ（潜在的なＸＣ６要求の一部）としてマークされなくてもよく、プローブは、それをその状態に返す前にそのＬ１がフラッシュされているにもかかわらずＲＸＣ３からの強化によって取り扱われてもよい。ＲＣＣ３は、キャッシュフラッシュの後のみの存在を許すのに使用されてもよく、モニターによって後退される。

【0115】

ＲＸＣ３モードは、およそ８０ｕｓであることを期待されたＤＲＡＭセーブ／リストアペナルティに起因して、より高いＸＣ６終了遅延時間の危険性を減少する。ＲＸＣ３は、これを〜ｌμｓに減らす。これは、プローブのための長い遅延時間である。しかし、インタラプトのために短い。クラスタは、ＸＣ６とＲＸＣ３（ＣＣ６とＲＣＣ３とともに）との間でダイナミックに再構成するＳＭＵに応じてもよい。ＲＸＣ３サポートは、ＲＣＣ３の拡張であってもよい。ＲＣＣ３に入ることを要求している最後のコアにおいて、統合ノースブリッジ２８０は、コアの側のＬ２とともにＱチャネルハンドシェイクを実行してもよい。

【0116】

一般的にＸＣ状態のサポートに対し、Ｌ２スタンバイハンドシェイク（ＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＷＦＩＬ２）が実行されてもよい。これは、ＮｂＢｕｓｙ要求を満たし、それは、アーキテクチャ的なアイドルであるにもかかわらず、それがパワーマネージメントの準備ができていないシグナリングのＣＰＣの方法である。ＡＲＭにおいて、ＡＣＩＮＡＣＴＭ及びＳＴＡＮＤＢＹＷＦＩＬ２のためのコミットポイントは、プローブドレイン及びＮｂＢｕｓｙから異なる。したがって、ハンドシェイクは、ローパワーに委ねる前に実行されてもよく、それからプロトコルにより、Ｌ２は、統合ノースブリッジ２８０が欲するものに関係なく、ＳＴＡＮＤＢＹＷＦＩＬ２を見ることを禁ずることが許される。コミットメントの後にドレインし、Ｌ２は、ハングアップを防ぐＮｂＢｕｓｙをドロップすることを保証する。したがって、ＸＣ状態のために、ＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＷＦＩＬ２は、ＲＣＣ３又はＣＣ６に入っている最後のコア上で実行されてもよく、そのハンドシェイクは、ＲＸＣ３のためにＬ２ Ｌ２ＱＡＣＴＩＶＥ／Ｌ２ＱＲＥＱｎハンドシェイクと平行に進行してもよい。ＸＣハンドシェイクプラス、ラストコアのＲＣＣ３ハンドシェイクの両方が完了しているとき、ＳｅｔＣＰＵＬｏｗＰｗｒは、進行することを許されてもよい。

【0117】

ＲＣＣ３と同様に、ＲＸＣ３は、ＴＬＢ、ＢＴＢ無効、ＳＭＰモード無効（ＸＣ６と同様）又はＳＭＰモードの下で残された非フラッシュの何れかが許可されてもよい。単一のクラスタの実行において、一度そのクラスタがＲＸＣ３に入ったら、システムのコアは、ＤＶＭを出さなくてもよく、Ｌ２ＱＡＣＴＩＶＥデアサーションは、帰属されなくてもよい。キャッシュがフラッシュされ、インタラプトがＧＩＣ−４００でマスクされることで、Ｌ２ＱＡＣＴＩＶＥデアサーションのために他のいかなる条件もあってはならず、Ｌ２ Ｑｃｈａｎｎｅｌインタフェースは、ＣＰＵ１０２の１つのように些細であってもよい。クリーンアップは、保持からの最初の終了を一度実行されてもよく、インタラプト配信が起こる。マルチクラスタＳＯＣとともに、クラスタがＳＭＰモードから無効であった場合には、ＤＶＭブロードキャストハンドリングを扱うことが実行されてもよい。この状況において、Ｌ２は、保持電圧をＬ２ＱＡＣＴＩＶＥに下げる間に処理を残してもよく、終了を指定されたコア上でＬ２ＱＡＣＴＩＶＥデアサーションからＩｏｂｃＯｒＨａｌｔクリーニングを生成してもよい。

【0118】

複雑なパワーゲート（登録商標）モード（ＸＣ６）が使用されてもよい。ＸＣ６エントリは、ＲＸＣ３とちょうど同じようなＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＷＦＩＬ２ハンドシェイクを使用してもよい。ＸＣ６の間、ガスケット２１０がパワーオフとなり、全てのクレジットが統合ノースブリッジ２８０によりリリースされるまで、ガスケット２１０は統合ノースブリッジ２８０と通信することができない。このように、ガスケット２１０は、クレジットを受け取る準備があるとき、ＲｅｓｅｔＵｃｏｄｅＧｏをドライブする責任があってもよく、これは、デアサーションのリセットの後にすぐにありそうである。ガスケット２１０は、全てのコアのデアサートのためにＲｅｓｅｔＵｃｏｄｅＧｏをＳＴＡＮＤＢＹＷＦＩＬ２及びＳＴＡＮＤＢＹＷＦＩに結び付けることができてもよい。ＳＴＡＮＤＢＹシグナルは、パワーゲート（登録商標）の間に１に隔離し、それから０にリセットする。０は、隔離がＣＰＬによってリリースされるまで、ガスケット２１０に露出されなくてもよい。その場合、ガスケット２１０は、アサーティングＲｅｓｅｔＵｃｏｄｅＧｏによってクレジットを受け取る準備をしてもよい。このシーケンスは、ブートとしてＸＣ６終了のために同じであってもよい。後者のために、統合ノースブリッジ２８０は、ブート理由の確保のためにＲｅｓｅｔＵｃｏｄｅＧｏアサーションのクレジットのリリースを延ばしてもよい。これは、ＣＣ６終了の場合でなくてもよい。

【0119】

キャッシュ／ステートフラッシュが実行されてもよい。存在する統合ノースブリッジ２８０モニターは、最初の停止エントリで深いＣ状態滞留を予測することを試みる。この成功のどちらの結果も即時のフラッシュリクエスト又は失敗を許容し、これは、浅いＣ状態（ＣＣ１）を残す。このように、ショートＣ状態インターバルにおいて、失敗が予測されてもよく、インタラプトの起動は、低い遅延時間であるＣＣ１から移行の必要があってもよい。このモニターは、タイムアウトの後、より深いＣ状態への移行に予測された失敗を許容する第２の待ちメカニズムにより、予測できないこと又はワークロードの変化をカバーすることによって、支持されている。ＣＣ６＋状態は、これらのモニターによって支持され、ＲＣＣ３は、浅い（プリフレッシュ）及び深い（ポストフラッシュ）の何れかで考慮されてもよい。また、コア（ＣＣ）状態毎及びＣＰＣ（ＸＣ）毎のモニターカバーの２つの異なるレベルがある。

【0120】

モニター及び待ちメカニズムの何れかによって発生するフラッシュリクエストにおいて、ＳｔｐＣｌｋは、目標とされたコアに送られてもよい。コアは、キャッシュ（及び／又はＲＣＣ３対ＣＣ６に従う状態）をフラッシュしてもよく、統合ノースブリッジ２８０にフラッシュされた状態のシグナルに適切なビットをマークし、それから類似しているプリフラッシュに停止を再び入れる。統合ノースブリッジ２８０は、停止とともにフラッシュ状態を観測してもよく、ＣＫにクロッキング／パワーリクエストを引き起こす場合により深いＣ状態に進んでもよい。

【0121】

クラスタは、ハードウェアＬ２フラッシュウィジェットを実装し、通常明白なＸＣ６で使用され、コアは、フラッシュを開始するために利用することができない。潜在的なＸＣ６は、コア上で実行されるので、コアは、基礎的なソフトウェア及びｘ８６のコアと同一のインタフェースのハードウェアにするようなフラッシュを開始してもよい。

【0122】

コアは、Ｌ２ＦＬＵＳＨＲＥＱがアサートされ得る前にＷＦＩであってもよい。コアは、ＳＰＲを通してフラッシュリクエスト開始することに使用されなくてもよく、完成を待っている。このように、統合ノースブリッジ２８０のフローは、低パワーで入っているラストコア上のＬ２フラッシュリクエストを含まなくてもよいので、ソフトウェアは、キャッシュメンテナンスオペレーションを用いたＬ２フラッシュを実行してもよい。このアプローチで、スペシャルロジックは、フラッシュングＬ２のために統合ノースブリッジ２８０を要求しなくてもよく、統合ノースブリッジ２８０は、Ｌ２が、低パワーに入るラストコアが観測されるための要求のときにフラッシュされることを想定してもよい。

【0123】

ｘ８６ユーコードにおいて、ＡＰＩＣインタラプトは、スリープでないとき、自動的にマスクされる。長い期間のサービスルーチン、例えばキャッシュ及び／又は状態フラッシュのために無中断のコードの長い範囲を避け、ユーコードは、インタラプトチェック（ｉｎｔｃｈｋ）において散在し、ペンディングインタラプトのためにコアのインタラプトエッジを試し、存在するならばフラッシュを中止する。クラスタは、同じソフトウェア機能をサポートしない。その代わりに、インタラプトは、以下に記す図３の全部のＣ６エントリフロー３００を通してマスクされることになる。ステップ３１０で、適切なシステムコントロールレジスタＣビット、データ、又は、統合キャッシュの有効は、追加のデータキャッシュアロケーションを防ぐためにクリアとなってもよい。ステップ３１５で、Ｌ２プリフェッチは、ＣＰＵ拡張コントロールレジスタのビット［３８，３６：３５，３３：３２］にゼロを書くことによって無効にしてもよい。ＩＳＢ命令は、ＣＰＵ拡張コントロールレジスタ書き込みが完了していることを確実にして、ステップ３２０で実行されてもよい。ＤＳＢ命令は、任意の前のプリフェッチリクエストの完成を確実にするために、ステップ３２５で実行されてもよい。ステップ３３０で、Ｌ１データキャッシュからの全てのデータは、クリーンになり無効にされてもよい。このプロセッサのためのＬ２デュープリケートスヌープラグＲＡＭは、空であってもよい。これは、このプロセッサに発せられたマルチプロセッサの中の他のプロセッサから、いかなる新しいデータキャッシュスヌープ又はデータキャッシュメンテナンスオペレーションを妨ぐ。ステップ３３５で、ＣＰＵＥＣＴＬＲ．ＳＭＰＥＮビットがクリアされてもよい。ＳＭＰＥＮビットでこれをクリアすることは、マルチプロセッサの他のプロセッサによって、キャッシュ命令、ＴＬＢ又はＢＴＢメインテナンスオペレーションブロードキャストからプロセッサを防ぐことにより、コヒーレンシとなることを可能とする。ステップ３４０で、システムは、インタラプトがパワーダウンしているプロセッサに送信されないことを確実にする。ＤＢＧＯＳＤＬＲ．ＤＬＫダブルロックコントロールビットは、デバッグインタフェースに静止していることを強いるステップ３４５でセットされる。ＩＳＢ命令は、コミットされた前のステップからシステムレジスタの変更の全てを確実にするためにステップ３５０で実行される。ＤＳＢ命令は、クリアされたＳＭＰＥＮビットが完了する前に、マルチプロセッサの中のどのプロセッサによっても出される、全てのキャッシュ命令、ＴＬＢ及びブランチ予想メインテナンスオペレーションを確実にするステップ３５５で実行される。ＷＦＩ命令は、実行され、プロセッサがアイドル及びＷＦＩローパワー状態であることを示すステップ３６０において、アウトプットのためにモニターされるＳＴＡＮＤＢＹＷＦＩアウトプットである。プロセッサ１０２アウトプットクランプは、ステップ３６５で活動的にされる。パワーは、ステップ３７０でプロセッサ１０２のパワードメインを取り除く。

【0124】

インタラプトマスキングは、ステップ３１０の前にＣＰＳＲ．Ｉ／Ｆビットを設定することによって行われる。ステップ３１０は、プロセッサをノンコヒーレントにしてもよく、このように、ハンドラがこれを知り、入ることでインタラプトを要求しなくてもよい。

【0125】

Ｉｎｔｃｈｋは、実行される必要がなくてもよい。なぜならば、
（１）ハードウェアＬ２フラッシュウィジェットを実装することによって、唯一のソフトウェアキャッシュフラッシュ要求がＬ１であり、これは、Ｃ６エントリがシングルディジットマイクロセコンドレンジのみであるキャッシュフラッシュオーバーヘッドを意味する５０００サイクルのみ受け取ることであることと、
（２）クラスタは、インタラプトが例えＣＰＳＲ．Ｉ／Ｆ及び次の命令を行うことを進めることによってマスクされた場合であっても、ＩＲＱ／ＦＩＱアサーション上のＷＦＩを終了してもよいからである。
これは、Ｃ６エントリの中止メカニズムとして用いられてもよく、ここで、パワーコントローラが、ＣＰＵ１０２によって要求されたパワーダウンを介して次のことを避ける選択をする。これは、ステップ３１０の前にＣＰＳＲ．Ｉ／Ｆマスキングで始まる途中停止不可全体シーケンスを有効にするステップ３４０で提示されるフロー３００のオプションの態様であってもよい。

【0126】

キャッシュフラッシュは、ＳＯＣのロングポールではないキャッシュフラッシュの非インタラプトの間隔で、最悪のケースＣ６インタラプト潜在性のためにＣ６ ｅｎｔｒｙ＋ｅｘｉｔに増加されなくてもよい。フローは、最後のコアに入っているＣＣ６、別名ＸＣ６状態への提案されたフローから変化し、Ａ１５のそれに類似したソフトウェアフローを用いたＬ２をフラッシュする必要がある。理由は、黙示のＸＣ６が実装されるからである。ソフトウェアＬ２フラッシュは、より長くとるようにしてもよい。合理的なインタラプトサービス潜在性を保証するために、ｉｎｔｃｈｋは、パフォーマンスのために、ｘ８６による同一性のために含まれてもよい。ｉｎｔｃｈｋは、ＣＣＩ＿ＩＮＴ＿ＥＤＧＥレジスタ（Ｆ３ｘ２Ｆ０）を介してＦＩＱ／ＩＲＱ状態によって統合ノースブリッジ２８サイドに実装されてもよい。このように、キャッシュフラッシュルーチンにおいて、ソフトウェアは、ＣＰＳＲ．Ｉ／Ｆビットを設定してもよく、それから、キャッシュフラッシュのチャンク（ｃｈｕｎｋ）でプレマスクされた端部のポーリングをインターリーブしてもよい。チャンクサイズは、例えばまれにフラッシ帯域幅に影響を及ぼさないｉｎｔｃｈｋとし、効率間の妥協で決定されてもよく、無中断の間隔に、開始と終了の待機時間の状態に対して取るに足らないようにされてもよく、ＲＣＣ３のために〜２μｓ及びＣＣ６のために〜２５μｓである。エッジが、ステップ３５０でキャッシュフラッシュの間にレジスタの中に見られる場合、フラッシュルーチンは、キャッシュの割り当て（ステップ３１０）とＬ２プリフェッチ（ステップ３１５）を再有効化することによってコヒーレンスを再度有効にしてもよく、それからインタラプトをとるＣＰＳＲ．Ｉ／Ｆをクリアにする。

【0127】

シーケンスが、ＣＰＵＥＣＴＬＲ．ＳＭＰＥＮを無効にするステップ３３５に進行した場合、ステップ３６０まで実行する（ステップ３４０をスキップする）。これらのステップの間に、統合ノースブリッジ２８０がＦＩＱ／ＩＲＱを対象にする場合、次の命令のＷＦＩイン及びアウトのステップ、キャッシュアロケーション、Ｌ２プリフェッチ及びＳＭＰが再有効される。そうでないない場合、システムはＣ６をコミットする。統合ノースブリッジ２８０は、Ｃ状態にコミットしながら適切にインタラプトをマスクすることを行ってもよく、ステップ３４０は不要であってもよい。ステップ３４０は、パワーコントローラ無効インタラプト及びＣ６エントリへ通信することの間のハザートを避けるために要求されてもよく、ステップは、統合ノースブリッジ２８０がサポートする。この実装は、パワーコントローラでソフトウェアを無効にセットするステップ３４０を要求し、そして、エントリをシグナルするＷＦＩを続行する前に、ＡＣＫバックシグナリングの適当なマスキング及び全てのペンディングＩＲＱ／ＦＩＱデリバリを静止することを要求する。実施は、インタラプト無効の要望を伝達するステップ３６０を使用してもよく、インタラプト及びコミットの間のハードウェアインターロックに応じてもよい。

【0128】

１つのコアのみは、コアがＣＣ６を出るときにＬ２をフラッシュしてもよく、これは、アボートされるＬ２フラッシュを許可することによって難しくなる。Ｌ２Ｉコントロールビットは、最後のコアを上へ示し、マルチプルコアの完了の存在では、Ｌ１はフラッシュし、Ｌ２の登録取り消す。これは、１つのコアが最後になること及びＬ２フラッシュを行うことをコアに強いることを許可する。これを行う１つの方法は、コアがベクタを設定する最後のコアであることを確認するメモリ１０４で、別々のキャッシュフラッシュドベクタでアトミックアクセスを実行することである。Ｌ２フラッシュを行うコアは、アボートのために任意のＰｗｒＳｔａｔｕｓＬｏ（Ｆ５ｘＦ０）ＣＣ６ビットクリーニングをポールしてもよい。

【0129】

コアは、ＳＭＵブロック内部でＤＡＰコントローラを実施してもよい。これは、ＣｏｒｅＳｉｇｈｔデバッグ実施の一部である。スタンダードデバッグは、ＪＴＡＧ及びＢＰピンの何れかを介してのＤＡＰへのインタフェースの道具である。ＤＡＰは、クラスタのパワー状態を知ることなく、クラスタ又はシステムリクエストを生成してもよい。ＤＡＰリクエストは、ＫＤＳＭと呼ばれているＶＤＤドメインに存在するＣｏｒｅＳｉｇｈｔロジックとされてもよい。ＫＤＳＭは、ＡＣＰポートを介してのリクエストをクラスタにデバッグし、システムは、ガスケット２１０へのＡＸＩバスを介して要求する。クラスタ及びシステムの何れかにアクセスするＤＡＰのために、ＶＤＤは、ＰＣ６から傾斜をつけられる必要がある。さらに、ガスケット２１０を介してシステムにリクエストするために、ＲＸＣ３又はＸＣ６が出される必要があってもよく、再びｎｂｓｙｎスピニングを得て、後者の場合、ＵｃｏｄｅＲｓｅｔＧｏ及びクレジットリリースを要求する。暗黙のＸＣ６の実施のために、１つ以上のコアはＣＣ６から現れてもよい。

【0130】

デバッグリクエストをサービスするローパワー状態から適切なロジックを得ることは、ＤＡＰが、パワーマネジメントロジックでＣＳＹＳＰＷＲＲＥＱ／ＣＳＹＳＰＷＲＡＣＫインタフェースを実施する。デバッグリクエストを挿入する前に、ＤＡＰは、ＣＳＹＳＰＷＲＲＥＱを最初にアサートしてもよい。ＤｂＲｅｑインタラプトは、クラスタがＲＸＣ３及びＸＣ６の何れかである間にＣＳＹＳＰＷＲＲＥＱがアサートされる場合に、シグナルされてもよい。ＤｂＲｅｑは、全てのコアを起動させてもよく、インタラプトハンドラは、ＮＢ＿ＭＩＳＣを介してＤｂＲｄｙをシグナルしてもよい。ＤｂＲｄｙは、ＣＳＹＳＰＷＲＡＣＫにシグナルされてもよい。これは、リクエストするＤＡＰを許可する。終了において、ＤＡＰは、ＣＳＹＳＰＷＲＲＥＱをデアサートしてもよい。コアを許可するために、ローパワーに再入力するＣ状態から、ＣＳＹＳＰＷＲＲＥＱは、ＤｂＲｅｑハンドラをポールするためにＳＰＲ上で露出されてもよい。デアサーションを見ることにおいて、ハンドラは、ＤｂＲｄｙをクリアしてもよく、このようにＣＳＹＳＰＷＲＡＣＫデアサートしてもよく、インタラプトから戻る。ＯＳアイドルのルーチンは、引き継いでもよく、ＷＦＩリエントリを許可し、それからＣ状態エントリプロセスを再開する。これは、ＰＤＭモードに似ている。しかし、クラスタは、ＳＢＩ＿ＩＡＩにＨＤＴ２インタフェースを実装しておらず、これは、ＳＢＩ＿ＩＡＩを介してシグナルされた終了を有する代わりに必要とされてもよい終了のためのポールを意味する。

【0131】

ｘ８６において、Ｐ状態は、ＡＣＰＩコールを介してＯＳに露出されてもよい。ＯＳは、事前に定義されたＭＳＲを呼び出すことによってＰ状態変化を要求し、ユーコードが、統合ノースブリッジ２８０のＣｏｆＶｉｄＣｔｌレジスタにＰ状態 ｉｄを捕らえ、書きこむ。Ｐ状態 ｉｄは、プログラムされた周波数（ＦＩＤ／ＤＩＤ）と電圧（ＶＩＤ）セッティングとを有するＰ状態テーブルエントリにマッピングする。電流と、要求された周波数と、電圧セッティングとの間で異なるかどうかによって、周波数及び／又は電圧の変化が要求されてもよい。統合ノースブリッジ２８０は、内部で２つの要求まで生成されてもよく、電圧の増加は、電圧の低下を前もって命令されている周波数の変化の前であるような要求を命令してもよい。電圧変化は、コアとの相互作用なしで統合ノースブリッジ２８０とＣＰＬとの間の内部で満足されている。周波数変化は、コアの相互作用を要求する。統合ノースブリッジ２８０は、他のＣＵ／ＣＰＣによって、又は、電圧変化、外部ＳｔｐＣｌｋ若しくはキャッシュフラッシュ等の他のパワーマネージメントリクエストに沿った統合ノースブリッジ２８０によって要求されたこれらの周波数変化を命令する。周波数変化が選択されるとき、統合ノースブリッジ２８０は、ＣＵ／ＣＰＵのｎｏｎ−ＣＣ６コア及び終了からのブロックＣＣ６コアの有効な全てのＳｔｐＣｌｋを目標にする。コアは、ＳｔｐＣｌｋを取り、周波数変化、静止の全ての未処理のトラフィックを認識するためにＨＴＣ ＳＢＣシステムマネージメントブロードキャストに送り、それからＣｏｎｎｅｃｔＭａｓｋをドロップする。一度ＳｔｐＣｌｋの目標とされた全てのコアは、これらのステップを完了し、これらペンディングＣＣ６は、エントリを完了し、統合ノースブリッジ２８０は、ＣＰＬに周波数変化リクエストをしてもよい。完了において、統合ノースブリッジ２８０は、ＣＵ／ＣＰＣにＳｔａｒｔＣｌｋエッジを発生させ、その静止を終了しＯＳに戻しユーコードを促す。

【0132】

ＡＲＭ実装において、ＡＣＰＩコールの代わりに、ＯＳは、ＣＰＵｆｒｅｑカーネルドライバを呼び出す。これは、Ｃ状態のためのＣＰＵｉｄｌｅルーチンのそれと似ているアンドロイドにベンダー中立ＡＰＩインタフェースを実装する。Ａｎｄｒｏｉｄ（登録商標）のために、ＣＰＵｆｒｅｑインタフェースは、最大のパーセンテージによって示されるパーフォーマンスレベルのそれである。ＣＰＵｆｒｅｑルーチンは、ｏｕｒ ８ ｄｉｓｃｒｅａｔＰ状態レベルの１つをパーセンテージレベルのマップとしてもよく、統合ノースブリッジ２８０のＣｏｆＶｉｄＣｔｌレジスタの中に要求してもよい。その時点から、周波数変化の同様なフローが期待されてもよく、ピッカー選択、静止、周波数リクエスト及び非静止を必要とする。静止及び非静止部分は、実装において異なっているものである。ここで、以下に述べられている図５及び図６で示されている２つの方法は、プロトコル／ハードウェアの複雑性及び性能の形式で提示されるリスクを軽減するために、個々に又は纏めて実施されてもよい。一般に、これらの方法は、ＷＦＩ又はＷＦＥ状態で定義されたＡＲＭのプロセッサを配置するＧＩＣを用いてＣＰＵに割り込んでもよい。何れかの状態は、さらに命令を実行すること、及び、クロックドメインの境界を越えて新しいトランザクションの開始をすることからＣＰＵ４２０を防止してもよい。図５及び図６については、以下詳細にインタフェース／フローを提供する。静止の両方のタイプは、リスク軽減のために実装されてもよく、コンフィグによって１つを有効にしてもよい。インタラプトベースの１つは、Ｓ３のために実施される必要があってもよく、ガスケット２１０ベースの１つと置き換えられなくてもよく、Ｐ状態をサポートする付加するコストは、ゼロの近くであってもよい。ガスケット２１０ベースの１つは、より良い性能を有してもよいが、プロトコル及びｃｒｏｓｓ−ＩＰ検証リスクを伝える。

【0133】

既存のＰ状態ロジックに接続の実施例のダイアグラム４００は、図４に示されている。図４は、既存のＰ状態ロジックを示す。図４に示すように、インタラプトを提供する一般化されたＡＲＭインタラプトコントローラであるＧＩＣ４１０がある。ＧＩＣ４１０は、統合ノースブリッジ２８０の中に配置されていてよい。また、ＣＰＵ４２０も示されている。ＣＰＵ４２０は、アトラスクラスタ２９０の一部であってもよい。ガスケット４３０は、図４に示されており、ガスケット２１０の一部であってもよい。また、ＮＢＣＯＲ４４０が示されている。ＮＢＣＯＲ４４０は、既に議論されているＣＣＩプロトコルを含む統合ノースブリッジ２８０の一部であってもよい。ＧＩＣ４１０及びＣＰＵ４２０の各々に見られるように、ガスケット４３０は、ＮＢＣＯＲ４４０と通信してもよい。これらの通信及び信号の各々は、下記において説明されるであろう。

【0134】

インタラプトベースの静止又は非静止は、Ｐ状態がＦＩＱにＳｔｐＣｌｋをフッキングすることによってＳｔｐＣｌｋベースの静止を行うことである最小ハードウェアコストのアプローチを提供してもよい。ＦＩＱは、セキュアインタラプトとして使用されてもよい。信頼ゾーンは、コアとＧＩＣ４１０に実装されていない場合、ＦＩＱは可能であってもよく、ＳｔｐＣｌｋは、簡単で、性能に殆どリスクを提供しなくもよい。通常のインタラプト（ＩＲＱへ有線）のために、ソフトウェアの規則では、ＩＲＱ例外ベクタ上の非再入である。これは、優先順位の高いＩＲＱインタラプトが到着した場合、優先順位の高いインタラプトが、現在コアによってサービスされたインタラプト優先順位の低いＩＲＱをプリエンプトすることは許されないことを意味する。パフォーマンス上の理由からＡｎｄｒｏｉｄ（登録商標）は、上下の半分のインタラプトサービスルーチンを破る。上半分では、半分がインタラプトできない。コンベンションは、コールを返すこと、及び、インタラプトコードを返すことの前に、単にインタラプトをとることであり、行われるのに必要なことを把握し、それから実際の仕事を行うＯＳで下半分をスケジュールする。下半分は、それから実際の仕事を行うことである。

【0135】

しかし、全体的な異なる例外タイプでは、ハードウェアは、例えば、スタックポインタ、コールリターンのために使われるリンクレジスタ及びステータスレジスタ等のバンキングクリチカルコントロールフローレジスタによって完全にプリエンプト可能であることを保証する。慣例によると、ＩＲＱは、ＦＩＱをマスクしない、これによりＩＲＱハンドラのとき後者がとられてもよい。非セキュアシステムにおいて、ＳｔｐＣｌｋは、少しの待ち時間でもよく、Ｐ状態の変化のために必要とされ、与えられたコアは、静止された状態につぎ込まれる通常の作業が取り出される。しかし、信頼ゾーンが実装されている場合、ＦＩＱインタラプトは、セキュリティモニタのフレームワークに落とし込む必要があってもよい。Ｐ状態変化は、登録されてもよく、他のＳｔｐＣｌｋソースは、安全なサービスとして供給する。ＦＩＱピンは、他のサービスと共有されてもよい。これを行う１つの方法は、慣例に従って最小限であるとＦＩＱルーチンの上半分に依存することであるが、システム全体のパフォーマンスに影響を与える信頼されるサービスに不正な動作をするリスクがある。ＳｔｐＣｌｋは、バリア同期静止として行われてもよく、そして遅く着いたスレッドは、ひどく並列化されたプログラムとして扱われる。代替は、ＦＩＱ例外ハンドラの再入をすることである。真の他のアーキテクチャと同様の再入の代わりに、返信アドレスがスタックにプッシュされ、リンクレジスタは、かかる一つの例外のために再入を可能にし、各例外モードにバンクされ、リターンアドレスのため、バンクされたリンクレジスタバンクを用いてスーパーバイザモード（ＳＶＣ）への切り替えを行うこと、そうして、例外ベクタへの別のエントリのためにＦＩＱリンクレジスタを解放することである。これは、ＦＩＱへの再入の２つの場合を許容してもよい。他の信頼されたサービスのＳｔｐＣｌｋのプリエンプションをサポートするために、その後、ＳｔｐＣｌｋを除いた他の信頼されたサービスのためにマスクされたインタラプトを残しながら、ＦＩＱ例外ハンドラは、ＳＶＣモードに切り替える必要がある。

【0136】

Ｐ状態ＳｔｐＣｌｋのサービスにおいて、コードは、統合ノースブリッジ２８０にＨＴＣ ＳＢＣシステムマネージメントブロードキャストを送ってもよく、データ同期バリア（ＤＳＢ）によって全ての顕著なトラフィックを静止し、インタラプトのための待ち（ＷＦＩ／ＷＦＥ）の信号を送る。この場合のＤＳＢ命令は、静かな待ちとして機能する。未処理の要求への全ての応答のための静かな待ち時間は、トークンと同様にリリースするが、ＤＳＢは応答を待つのみである。有効であり／用意ができているインタフェースのＡＣＥ実装が与えられ、反応を見ることは、静止のために十分であってもよい。トークンベースＳＤＰインタフェースを用いての実装は、ＳＯＣ１５が必要であれば、静止シナリオのために本当の静かな待ちを必要としてもよい。ＷＦＩ／ＷＦＥは、統合ノースブリッジ２８０への周波数変化のための準備の信号を単に送ることだけである。

【0137】

統合ノースブリッジ２８０がＰ状態変化のためにＷＦＩのフォームでのコアの準備を見て、統合ノースブリッジ２８０は、クラスタへのプローブが選択されることから遮断することによってクラスタへのプローブを静止してもよく、既に選んだプローブの自由なそのパイプラインを排出してもよく、クラスタがそれらを完了すると、それらのバッファを解放する顕著なプローブを待ってもよい。一度プローブが排出されると、統合ノースブリッジ２８０は、ＣＰＬでＰ状態変更をスケジュールする前にクラスタと追加ＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＦＩＬ２を行う必要がある。ＡＣＩＮＡＣＴＭは、ＳｒｑＣＰＵＰｒｏｂｅｓＤｒａｉｎｅｄ及びＳＴＡＮＤＢＹＷＦＬＩＬ２ハンドシェイクがＳｅｔＣＰＵＬｏｗＰｗｒピッカーで準備をブロックする追加の用語であってもよいものである。このＬ２ハンドシェイクは、Ｐ状態の場合を除いて、ＲＸＣ３及びＸＣ６のために実行されるものと似ており、それはキャッシュフラッシュで些細なものでなく、プローブは活発にドレインされる。プローブドレインの命令は、ｘ８６で実行されてもよいことの逆であり、コミットはドレインの前に起き、クラスタのために、ドレインはコミットの前の最初にあるとよい。統合ノースブリッジ２８０は、ＥｎＤｒａｉｎＰｒｂＯｎＨｔＳｔｐＣｌｋを介してこのモードをサポートし、コミットの前にプローブドレインを開始する。コアのために、ＥｎＤｒａｉｎＰｒｂＯｎＨｔｃＳｔｐＣｌｋ＝１は、インタラプトベースの静止が有効であるときに要求されてもよい。

【0138】

ＳｔａｒｔＣｌｋのＷＦＩ変形は、クラスタがＰ状態変化の最中にある間、含んでもよく、クラスタは、インタラプトをせず又はシステム要求をしなくてもよい。インタラプトエッジは、パワーマネジメントイベントの間にｘ８６のＡＰＩＣエッジでされているように統合ノースブリッジ２８０によってマスクされている。しかし、ソフトウエアは、統合ノースブリッジ２８０への要求を必要とするので、既に記述されたｉｎｔｃｈｋを実行しなくてもよい。このように、ｉｎｔｃｈｋの代わりに、統合ノースブリッジ２８０は、一度ＣＰＬがＰ状態変化を完了して静止からコアを起動してもよい。これは、ＳｔａｒｔＣｌｋインタラプトで行われてもよい。しかし、ＳｔａｒｔＣｌｋインタラプトは、ＳｔｐＣｌｋがプリエンプトされる必要があることを意味する。ＦＩＱ再入がＳｔｐＣｌｋの間に許容される場合、信用ゾーンが再入を既に要求している場合、３レベルまで加わる。他の安全なサービスは、非再入にされてもよいし、ＳｔｐＣｌｋを超えた非スタンダードインタラプト再入を実行にしてもよい。ＳｔｐＣｌｋがＳｔａｒｔＣｌｋである中でのインタラプトに好ましい唯一のインタラプトが与えられ、ショートカットが、スタックを押す代わりに多目的レジスタでリンクレジスターアドレスを除く等が行われてもよい。後者は、最も高いＦＩＱ優先度を有するようにＳｔａｒｔＣｌｋの構成を必要とし、信用ゾーンの与えられたベンダーサポートを可能としなければならない。

【0139】

ＷＦＩ５００を用いたＰ状態のシーケンスの例示的な図は、図５に示されている。ＷＦＩ５００を用いたＰ状態シーケンスは、ステップ５１０においてドライバリクエストＰ状態を含んでもよい。ステップ５２０において、全てのコアへのＳｔｐＣｌｋ送信は、実行され、それからＳＴＡＮＤＢＹＷＦＩのための待ちがなされる。ステップ５２０とほぼ同時に、ステップ５３０は、ｎＦＩＱ上で見られるＳｔｐＣｌｋ及びソフトウェアがＦＩＱインタラプトハンドラルーチンを入力することを提供する。ステップ５４０において、ＦＩＱインタラプトハンドラは、ＨＴＣ ＳＢＣブロードキャストＤＳＢ（静止）及びＷＦＩ命令を起動する。ステップ５５０において、プローブは、ドレインされ／静止され及びＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＷＦＩＬ２ハンドシェイクが始められる。ステップ５６０において、コアＦＩＤ／ＤＩＤ／ＶＩＤが変化し、ＳｔａｒｔＣｌｋはＳＰＩを介して送られる。ステップ５７０において、ｎＦＩＱは、ＷＦＩからコアを起動し、インタラプトハンドラにジャンプし、ＳｔａｒｔＣｌｋインタラプトをクリアする。

【0140】

ＳｔｐＣｌｋからの起動のもう１つの方法は、静止の後のＷＦＩの代わりにＷＦＥを使用することである。ＷＦＥの起動は、ＥＶＥＮＴＩピンを介してインタラプト及びイベントの何れかで動作できる。このように、全てのインタラプト、ＩＲＱ及びＦＩＱは、マスクオフされてもよく、ＥＶＥＮＴＩ上でまだ起動でき、ＳｔａｒｔＣｌｋの目的に基本的に役に立つ。ＷＦＥ ＳｔａｒｔＣｌｋを有効にするために、ＳＴＡＮＤＢＹＷＦＥは、全てのＰ状態（ＨｔｃＳｔｐＣｌｋＡｃｔｉｖｅＣｏｒｅに基づく）及び他の全ての状況のためのＳＴＡＮＤＢＹＷＦＩのために〜ＣｏｎｎｅｃｔＭａｓｋに多重送信されてもよい。ＳｔａｒｔＣｌｋは、それから終了を始動するこのモードでＥＶＥＮＴＩに接続されてもよい。コアがＷＦＥから終了すると、まだＳｔｐＣｌｋハンドラにあってもよく、インタラプトと終了をアンマスクとするであろう。

【0141】

複数のクラスタをサポートするために、他の全ての状況でＰ状態及びＥＶＥＮＴＯを行うとき、ＳｔａｒｔＣｌｋエッジは、ＥＶＥＮＴＩに多重送信されてもよい。通常モードにおいて、全てのＥＶＥＮＴＯは一緒にＯＲｅｄとなり、ＥＶＥＮＴＩに追いやられる。いくつかのＥＶＥＮＴＯがないかもしれないので、それらは交換されてもよく、内部のＳｔａｒｔＣｌｋエッジがＥＶＥＮＴＩにマップされてもよい。

【0142】

コアのために、ｃｏｎｆｉｇによるＳｔａｒｔＣｌｋ変形の何れも有効であってよい。既存のＳｔａｒｔＣｌｋＥｄｇｅは、ＥＶＥＮＴＯ及びＳｔａｒｔＣｌｋに割り当てられたＧＩＣ４１０のディストリビュータＳＰＩピンの両方に送られてもよい。ＷＦＥ ＳｔａｒｔＣｌｋモードが有効であるとき、ＣｏｎｎｅｃｔＭａｓｋ及びＥＶＥＮＴＩは適切なＷＦＥシグナリングを選択してもよく、ＳｔａｒｔＣｌｋと関連したＳＰＩ ｉｄは無効であってもよい。ＷＦＩ ＳｔｐＣｌｋモードのために、ＳｔａｒｔＣｌｋ ＳＰＩ ｉｄのＧＩＣ４００のプログラミングは、引き受けてよい。

【0143】

コアは、ＳｔｐＣｌｋサービスのときにおいて、ＳＥＶ命令を実行してよいユーザーコードであってもよい。異なるコアは、異なる時間にインタラプトをしてもよく、もう一つのコアがＳｔｐＣｌｋをする前にＳＥＶを実行する間、１つのコアが、ＳｔｐＣｌｋハンドラでＷＦＥを既に実行したかもしれない任意のソフトウェアの保証なしで可能である。適切なこのフローのサービスのために、ＳｔｐＣｌｋハンドラは、ＷＦＥを実行する前に、ソフトウェアの同期を行ってもよい。統合ノースブリッジ２８０は、ハードウェア手旗信号及びスクラッチレジスタを提供する。ＳｔｐＣｌｋハンドラは、ＷＦＥに進むためにＰｗｒＳｔａｔｕｓＬｏレジスタからＣＣ６状態を利用するとともに、ハンドラで各々のコアの存在をアトミカリーに更新するためにハードウェアメカニズムを使用してもよい。

【0144】

Ｌ２は、ＳＴＡＮＤＢＹＷＦＥＬ２インタフェースを実装しなくてもよい。ＷＦＥの前の提供で、コアがＤＳＢ命令を実行してもよく、全ての未解決リクエストを静止し、Ｌ２へのペンディングリクエスト又は割り当てがあってはならない。これは、Ｌ２プリフェッチ又はＤＲＡＭへのビクティムがあってはならないことを保証してもよい。このような場合には、保証するために、ソフトウェアはＤＳＢの後にＷＦＥを遅延してもよく、それによってＰ状態変化にコミットすることから統合ノースブリッジ２８０が遅れ、ＳＴＡＮＤＢＹＷＦＩＬ２を待たずに発生する必要がある。

【0145】

ＷＦＥ６００を用いたＰ状態静止の例示的な図が、図６に示されている。静止６００は、ステップ６１０においてＰ状態を要求するドライバを含む。ステップ６２０において、ＳｔｐＣｌｋは、全てのコアに送られ、システムは、ＳＴＡＮＤＢＹＷＦＥのために待つ。ほぼ同時に、ＳｔｐＣｌｋはｎＦＩに見られてもよく、ソフトウェアはステップ６３０でＦＩＱインタラプトハンドラルーチンに入る。ステップ６４０において、ＦＩＱインタラプトハンドラが準備され、ＨＴＣ ＳＢＣが放送され、コア間のソフトウェアの同期は（ＳＥＶ用）、ＤＳＢ（静止）で発生し、Ｌ２の静止のためのソフトウェアの遅延は、ＷＦＥ命令で発生する。ステップ６５０においてプローブは、ドレインされ／静止されることである。ステップ６６０において、コアＦＩＤ／ＤＩＤ／ＶＩＤは変化し、ＳｔａｒｔＣｌｋはＥＶＥＮＴＩを介して送られる。ステップ６７０において、ＥＶＥＮＴＩはＷＦＥからコアを起動させ、ＳｔｐＣｌｋハンドラー（ｎＦＩＱ）に戻る。

【0146】

静止に基づくＳｔｐＣｌｋ／ＳｔａｒｔＣｌｋは、既存の統合ノースブリッジ２８０から最少の付加される論理を必要とする。しかし、パフォーマンスでのリスクであり、信用ゾーンのインタラプトがコアの内部で取り扱われる必要がある場合、更なるソフトウェアの複雑さが加わる。これらのリスクを減らすために、静止の代わりのモードは、ガスケット２１０で実装され、クラスタに見えなくなることを許可される。動作し続けるためにクラスタとガスケット２１０との間のＡＣＥインタラプトのハイレベルにおいて、ＮＢＳＹＮの何れかの端部でのＣＣＩインタフェースを静止する。ガスケット２１０は、新しいリクエストをブロックし、コアの代わりに未解決な応答を待ってもよい。これは、ガスケット２１０で主に追加のハードウェアと上記のリスクを引きかえており、プロトコル依存性はこの実装に付属している。主なプロトコル依存性は、プローブとライトバックとの間にある。ＡＣＥにおいて、ライトバック（ビクティムリクエスト）は、他の依存性のないＤＲＡＭに対し前に進む通常の要求から別の仮想チャネル上に配置されている。クラスタは、これらのライトバックが完了するまでブロックするライトバックにヒットしているプローブの許可によってこれを頼る。したがって、プローブを静止する統合ノースブリッジ２８０のために、コアはライトバックを完了することを許されなければならない。図８に示される方法８００は、ガスケット２１０と統合ノースブリッジ２８０との間で、ＮＢＳＹＮ全体の全てのインフライトトラフィックのドレインを保証することを提供される。ステップ８１０において、Ｐ状態変更要求を提供する方法８００は、統合ノースブリッジ２８０がＳｔｐＣｌｋとしての働きを静止している側波帯を通してガスケット２１０に信号を送る。ステップ８２０において、ガスケット２１０は、統合ノースブリッジ２８０に送られることから新しい非ライトバックリクエストをブロックし、全ての未解決なものをドレインする。行われたとき、ガスケット２１０は、統合ノースブリッジ２８０への「静止された」レスポンスの信号を送る。これは、ＨＴＣ ＳＢＣシステムマネージメントコマンドのように動作する。ステップ８３０において、統合ノースブリッジ２８０は、選択されることから新しいプローブをブロックし、そのプローブバッファクレジットをチェックすることで完了する未解決なプローブのために待つ。ステップ８４０において、ガスケット２１０は、プローブが統合ノースブリッジ２８０から未解決のときのみライトバックをブロックする。ペンディングのライトバックが統合ノースブリッジ２８０にある限り、ガスケット２１０はＮｂＢｕｓｙを駆動してもよい。ステップ８５０において、統合ノースブリッジ２８０は、全てのプローブバッファが戻され、ガスケット２１０がＮｂＢｕｓｙアサートでないとき、Ｐ状態変更のみ開始することを許可されてもよい。

【0147】

非静止部分は、統合ノースブリッジ２８０を不活性化することにより、及び、「静止された」レスポンスを再移動することにより、ガスケット２１０の応答をすることで実行されてもよい。統合ノースブリッジ２８０は、新しいリクエストを開始する前に、ＡＣＫ（レスポンス）が、以前のハンドシェイクからデアサートされていることを保証する必要がある。このように、統合ノースブリッジ２８０への変更は、静止のためにガスケット２１０へのサイドバンドリクエスト／ＡＣＫであってもよく、Ｐ状態のためのＳｔｐＣｌｋの使用が非活動的であってもよい。これは単純でなければならない、現在のデザイン中の既にある両方の状態を駆動し沈めるからである。しかし、これは更なる働きをガスケット２１０に加えてもよい。それらはキャッシュフラッシュ及びＳ３のために必要としてもよいものとして一緒にＳｔｐＣｌｋを排除することはない。キャッシュフラッシュのために、ｉｎｔｃｈｋが使用されてもよく、Ｓ３は重いＯＳであり及び関係するＢＩＯＳである。

【0148】

ガスケット静止７００を用いたＰ状態シーケンスの例示的な図が、図７に示されている。このＰ状態の変化は、２本の境界の間に配置するガスケット２１０のインタフェーストランザクションプログレスの行き詰まりを通して起きてもよい。シーケンス７００に示されるように、ステップ７１０においてＰ状態の要求しているドライバを含む。ステップ７２０において、ＮＢ−ＱｕｉｅｓｃｅＲｅｑは、ガスケット２１０に送られる。ほぼ同時に、ステップ７３０において、ＮＢ−ＱｕｉｅｓｃｅＲｅｑは、ガスケット２１０によって見られる。ステップ７４０において、統合ノースブリッジは、選択されることから新しいプローブ及びレスポンスをブロックし、デアサートへのＮｂＢｕｓｙのために待つ。ステップ７５０において、コアＦＩＤ／ＤＩＤ／ＶＩＤは変化し、ＮＢ−ＱｕｉｅｓｃｅＲｅｑは、トラッフィクを再開するためにガスケット２１０に告げるようにデアサートされる。ステップ７６０において、ドライバは、新しい周波数でのユーザーコードを続ける。

【0149】

統合ノースブリッジＰ状態は、ＣＰＵ Ｐ状態としての同じメカニズムから実行されてもよい。マルチクラスタシステムのために、全てのクラスタは、ＣＰＵ Ｐ状態によってちょうど目標とされるシングルクラスタと対称となるように静止されることが必要である。統合ノースブリッジＣ状態は、不変で維持されてもよい。

【0150】

Ｓ３開始は、ＯＳとＢＩＯＳとの間で協同によって実行されてもよい。ＳｔｐＣｌｋサポートは、全てのデバイスがＤ３に置かれたあと、ＦＣＨへのＩＯリードによって開始されてもよい。ＦＣＨは、それから外部のＳｔｐＣｌｋフローを開始する。ＡＲＭ ＳｔｐＣｌｋフローは、全てのコアのＧＩＣ４１０へのＳＰＩを介してＳｔｐＣｌｋに信号を送ることを提供するように使用されてもよい。インタラプトハンドラは、インタラプトをマスクしてもよく、それから統合ノースブリッジ２８０にＳｔｐＧｎｔ ＳＢＣを送ってもよい。その時、コアは、パワーオフまでＳｔｐＧｎｔでマスクされたインタラプトを維持してもよい。インタラプトハンドラは、ＳｔａｒｔＣｌｋを考慮する必要がないが、後者が静止ベースのインタラプトをサポートすることを提供するＰ状態変化のコードを共有する場合、そのように行ってもよい。Ｐ状態変化対ソフトウェアデルタは、特別なブロードキャストサイクルのちょうど符号化されたタイプである。統合ノースブリッジ２８０は、ＤＲＡＭセルフリフレッシュへのエントリを開始するために全てのコアでＳｔｐＧｎｔ状態を使用してもよい。ＦＣＨがＳｔｐＧｎｔを受信した後、ＦＣＨは、時限待機を開始し、ウォームリセットを引き、ＶＤＤＮＢをランプダウンしてもよい。終了時に、Ｓ３は、コールドリセットに類似していてもよく、Ｓ３終了対ブートを識別するためのソフトウェアに依存してもよい。

【0151】

ＣＳフローは、主に終了の加速安全を助けるためのＳ３上の別のソフトウェア層である。ハードウェアは、保存及び再開プロセスの間のその状態の追跡を保つソフトウェアのためのいくつかのＣＳの特定レジスタフィールドをサポートする。

【0152】

ＣＡＣは、コアＣＡＣマネージャ（別名ＤＰＭ）において統合ノースブリッジ２８０との間をインタフェースし、クラスタ内に存在しなくてもよい。ＤＰＭは、ガスケット２１０に実装されてもよい。ＤＰＭは、ＦＵ要求／応答インタフェースを介して統合ノースブリッジ２８０と通信してもよい。ＤＰＭは、クラスタパフォーマンスモニタアウトプットを使用してもよく、ＣＡＣの重みを割り当ててもよい。それが実装されている場合、双方向アプリケーションのパワーマネージメント（ＢＡＰＭ）は、サポートされてもよい。それが実装されていない場合、ＢＡＰＭは、温度ベースであってもよく、したがって、正確性が低く及びエネルギーの蓄積が無効にされてもよい。しかし、何れの場合も、ＳＭＵは、既存ＳｍｕＰ状態Ｌｉｍｉｔを介してＢＡＰＭ Ｐ状態制限を通信してもよい。

【0153】

インテリジェントＰ状態（ｉＰ状態）の１つの実施例は、ＦＰ調整である。これは、ｘ８６コアのＨＤＴ２インタフェースで実装される。クラスタは、ＣｏｒｅＳｉｇｈｔと呼ばれる似たインタフェースを有する。ＣＰＬに要求するｉＰ状態サポートは、コアサイトにＨＤＴ２をマップすることを変化する。ｉＰ状態は、ＡＶＦＳ機能と共有される統合ノースブリッジ２８０でＳＭＵ Ｐ状態のハードウェアメカニズムを使用してもよい。ＳＭＵ Ｐ状態のためのＳＭＵと統合ノースブリッジ２８０との間のインタフェースは、同じことの維持を期待されている。

【0154】

Ｃ状態ブーストは、残りのコアがＣＣ６であるとき、潜在的により高い電圧でＦｍａｘにブーストされるようにコアのサブセットを許容する。Ｃ状態ブーストは、ＳＭＵの相互作用なしで、統合ノースブリッジ２８０ハードウェアで完全に処理される。なぜならば、それは、Ｐ状態変化とＣＣ６のバックエンドで動作するので、Ｐ状態とＣ状態をサポートするために必要とされた変化の増加がない。

【0155】

専用のライトバックチャネルは、デッドロックを回避するために使用されてもよい。１つのハードトークンは、ＣＰＵ１０２からＶｉｃＢｌｋ要求のためにＸＣＳ／ＳＰＢＣ／ＳＰＢＤ／ＭＣＱ／ＭＰＢＤが加えられてもよい。コアは、未解決ビクティムとの衝突においてプローブに応答しない。ビクティムチャネルは、ドレインするために使用されてもよく、ビクティムコマンドが実行された後、コアはミスとしてプローブに応答してもよい。ＣＰＵ１０２ビクティムは、保証の方法でＭＣＴに到達することができる。

【0156】

デッドロック９００のフローを示す図９を参照する。リード（Ｒｄ）は、ステップ９１０においてＭＣＴに到着する。プローブは、ステップ９２０において起動され、プローブは、９３０においてＣＰＵ１０２でビクティムにヒットする。ＣＰＵ１０２は、ＭＣＴに達するステップ９４０でＷｒＶｉｃＢｌｋを発する。しかし、それからＭＣＴのアドレスベースの順序付けロジックは、キックし、元のＲｄがステップ９５０で完了するまでＤＣＴに発され取得するＷｒＢｌｋを許容できない。Ｒｄは、プローブレスポンスがステップ９６０においてコアから受信されるまで完了しないであろう。ＷｒＶｉｃＢｌｋが、ステップ９７０においてコアに送り返されるためのＴａｒｇｅｔＤｏｎｅまで、Ｒｄのためのプローブのミスで応答しないであろう。これは、デッドロックコンディションである。

【0157】

ＣＰＵ１０２は、ガスケット２１０にライトデータチャネル上でデータをプッシュしてもよい。ＣＰＵ１０２は、ＣＰＵ１０２が競合プローブに応答する前に、ライトバックが完了したことを示す書き込み応答を待っている。これは、ノースブリッジ２８０がガスケット２１０からデータを引き出し、ガスケット２１０がライトバッファリリースによって通信が行われた対象を受信した後に、提供されてもよい。ＣＰＵ１０２がライトバックを発した場合、ガスケット２１０とＳＲＩは、メモリ１０４にライトバックを届けてもよい。ＣＰＵ１０２へのプローブを介して以前の読み取りからのデッドロック９００は、ライトバックが完了するのを待っている。ライトバックは、このように直ちに、例えば、プローブに応答すること及びビクティム状態をダウングレードすることを含むコヒーレントを維持するための責任をガスケット２１０にとらせることで、ガスケット２１０のＣＰＵ１０２から承認されてもよい。ガスケット２１０は満たされていてもよく、ブロッキングライトバックは、ＣＰＵ１０２の内部にあってもよく、未だプローブをブロックしていてもよい。デッドロック９００は、発されたライトバックによって要因となってもよく、これらは、内部ＣＰＵ１０２がプローブをブロックするキューを要求することである。ＣＰＵ１０２からＭＣＴへの仮想チャネルは、ライトバックが古い要求を通過させるＭＣＴで作成されてもよい。

【0158】

ガスケット２１０は、非ライトバックの書き込みで満たされてもよい。しかしながら、これらは既に前に進むように生成することが保証されており、プローブのデッドロックを起こす内部にキューされたＣＰＵ１０２ライトバックをブロックすることから完全なガスケット２１０を防ぐインターリービングライトバック及び非ライトバックのＣＰＵ１０２の制限がある。

【0159】

キャッシュでダーティラインをヒットするプローブは、ビクティムが実際にＤＲＡＭにドレインされるまで反応しなくてもよい。それゆえに、デッドロックフリーシステムを生成するために、新しいライトバックチャネルが加えられなければならない。この新しいライトバックチャネルの専用のバッファは、ＸＣＳ／ＳＰＢＣ／ＳＰＢＤ／ＭＣＱ／ＭＣＤに割り当てられてもよく、そのため、保証されて前に進むことが、ビクティムのために用意されてもよい。ＳＲＱは、コアからのビクティム／ライトバックのための専用の固い割当られたトークンを必要としてもよい。このライトバックチャネルは、ガスケット２１０の後ろに広がってもよく、ガスケット２１０のトークンアロケーションスキームは、ビクティムがコアからＳＲＱに向かって進んで生成されること、及び、ＳＲＱが常にビクティムのために可能なトークンを有するであろうことを確実にしてもよい。

【0160】

デッドロックを防止するために、４ホッププロトコルは、プローブがＰｒｂＴｇｔフレーバーを発することが強制されてもよい。１つのＣＰＵ１０２クラスタのみがあることにより、ＣＰＵ１０２からの要求のみが、ＧＰＵにプローブを送信しなければならず、それらの応答はＭＣＴに行く。同様に、ＧＰＵから要求するＲｄＢｌｋＳは、ＣＺのＰｒｂＴｇｔ上のみであってもよく、応答はＭＣＴに戻る。Ｉ／Ｏリクエストは、ＭＣＴに戻るプローブレスポンスを受信することを強いられてもよく、それからＭＣＴは、ダーティ又はクリーンデータで最終的な応答を送信してもよい。これは、再びＤＲＡＭを読むことのスキームの実装を許容してもよい。プローブ／ビクティムの衝突は、プローブレスポンスが失速すること、及び、前に進むようにビクティムに期待することにより処理される。

【0161】

ビクティムが完了したら、プローブレスポンスミスを発してもよい。これは、ＭＣＴで古いリクエストをパスするビクティムのための許容量を専用のライトバックチャネルに要求し、ホストブリッジのためのプローブターゲットを発するＭＣＴのために、代わりに、プローブソースを読み取る。プローブターゲットを発することは、プローブレスポンス、ＤＲＡＭリードデータ及び可能性のあるビクティム通過のケースを統合することと、ＳＲＩに戻りシングルリードレスポンス（または変換ケースでのＴｇｔＤｎ）を発することと、をＭＣＴに許容してもよい。

【0162】

ＸＢＡＲ−＞ＭＣＴリクエストは、より若いパッシングビクティムからのプローブダーティデータ又はデータを受け入れるためのＭＣＤのエントリを今割り当てる。他のＸＢＡＲ―＞ＭＣＴがＭｃｄＬｏとＭｃｄＨｉの両方を要求するようにトークンが保存される。データ（例えばＣＰＵ１０２読み込み）を搬送していないことを要求する非ホストブリッジは、直ちにｍｐ１でこれらのトークンを解放する。ホストブリッジ（ＨＢ）は、ｍｐ１（新しい用語Ｈｂ４ＨｏｐＭｃｄＬｏＢｕｆＡｖａｉｌ／Ｈｂ４ＨｏｐＭｃｄＨｉＢｕｆＡｖａｉｌ）でリリースされている未使用のチャネルのためのトークンを読み込む。前のコマンドのみが、ＭＣＤトークンに割り当てられたデータを有する。データコマンドのためのＭＣＤトークンマネージメントロジックは、変更されない。

【0163】

ライトバックとプローブとの間のデッドロックを解決するために、仮想チャネルは、ライトバックのために加えられてもよい。この機能の一部は、それが一度ＭＣＴに達するとライトバックに前もって古い読み取りの並べ替えをすることの許容を伴う。これは、このバイパスが発生したときに以前のＤＲＡＭの読み取りを再発行するようなかなりの数の変更を伴う。ＣＰＵ１０２は、プローブされたブロックがビクティムされるプロセスである場合、プローブレスポンスに返さなくてもよい。その代わりに、ＣＰＵ１０２は、単にビクティムを送信する。取られる手法は、ビクティムが効果的なプローブレスポンスであること、及び、そのように処理されてもよいことを検出することである。

【0164】

ビクティムが着いたとき、より古いｏｐｓでアドレス一致のためにチェックされてもよい。一致が発見された場合、ビクティムは、以下の基準を満たしているかどうかがチェックされてもよい。

【0165】

プローブレスポンスを待っている読み込み（プリフェッチではない）に対する一致。

【0166】

プローブレスポンスを待っている書き込みに対する一致。

【0167】

複数のアドレスの一致が発見された場合、最も古い１つが選択される。これは、最も古いｏｐが、引退する前のｏｐのために待つことのない原則を用いたＭＣＡで現在保存されているＭＣＱＷａｉｔＯｐＲｅｔフラッグのコピーによって確認される。

【0168】

そうしてビクティムが着いたとき、それは、以下の３つのフローの１つに続いてもよい。

【0169】

１．ビクティムは、レスポンスを探している前のｏｐに一致しない場合、過去に存在していたように扱われる。

【0170】

２．ビクティムがレスポンスのために待っているライトに一致した場合、ビクティムは、プローブレスポンスとして扱われ、先のライトのＭＣＤエントリにマージされる。ビクティムが割り当てられた新しいＭＣＤエントリがリリースされる。ビクティムのこのタイプは、自身のＭＣＤエントリを有していないから、進められたデータのソースであると考えられることができない。このビクティムは、ＤＲＡＭにライトされない（これは、ビクティムがマージするライトによって扱われる）。これは、ＭＣＱエントリ自身に割り当てられ、それが行われたときＴｇｔＤｎに送ってもよい。

【0171】

３．ビクティムがレスポンスのために待っているリードに一致した場合、ビクティムがＤＲＡＭに送られる必要があるので、ビクティムは、リードのＭＣＤエントリとマージして、自身のＭＣＤエントリに書き込まれる。新しいＭＣＤエントリのビクティムデータは、ノーマルビクティムとして扱われ、ＤＲＡＭに書き込まれてから転送されてもよく、完了したときＴｇｔＤｎに送る。第２のＭＣＤライトポートは、新しいＭＣＤエントリに書き込むためにフロー＃３（ｖｉｃｔｉｍ−ｍａｔｃｈｅｓ−ｒｅａｄ）に必要とされてもよい。

【0172】

（実施形態）
１．入出力メモリマップユニット（ＩＯＭＭＵ）を備え、ＩＯＭＭＵは、アクセスビットメカニズムを有し、ページテーブルエントリにアクセスする場合に、アクセスビットを設定するように構成されている、プロセッサ。

【0173】

２．前記アクセスビットメカニズムは、レジスタによって有効になる、実施形態１のプロセッサ。

【0174】

３．前記ＩＯＭＭＵは、ダーティビットメカニズムをさらに有する、実施形態１又は２のプロセッサ。

【0175】

４．前記ダーティビットメカニズムは、前記アクセスビットメカニズムが有効な場合のみ有効である、実施形態３のプロセッサ。

【0176】

５．ある程度のＡＰ［２］ビットは、ページがダーティ又はクリーンかどうかを示す、実施形態３又は４のプロセッサ。

【0177】

６．アクセスビット及びＡＰ［２］ビットは、同じページトランスレーションテーブルエントリから更新される、実施形態３〜５の何れか１つのプロセッサ。

【0178】

７．前記アクセスビット及びＡＰ［２］ビットは、シングルアトミックオペレーションで更新される、実施形態６のプロセッサ。

【0179】

８．前記シングルアトミックオペレーションは、ｔｅｓｔ−０−ｌｏｇｉｃａｌＯＲオペレーションを含む、実施形態７のプロセッサ。

【0180】

９．前記シングルアトミックオペレーションは、ｔｅｓｔ−ｓｅｔ−ｃｌｅａｒオペレーションを含む、実施形態７のプロセッサ。

【0181】

１０．前記アクセスフラグは、ハードウェアメカニズムによって管理される、実施形態１〜９の何れか１つのプロセッサ。

【0182】

１１．０に設定されたアクセスフラグを有するトランスレーションテーブルエントリが、トランスレーションルッカサイドバッファ（ＴＬＢ）に読み込まれる場合に、前記ハードウェアメカニズムは、前記トランスレーションテーブルエントリの前記アクセスフラグビットに１を書き込む、実施形態１０のプロセッサ。

【0183】

１２．ハードウェアアクセスフラグのフィールドは、この実装の選択を示すことに用いられる、実施形態１０又は１１のプロセッサ。

【0184】

１３．ＳＣＴＬＲ．ＨＡビットは、前記アクセスフラグのハードウェアマネージメントを有効にするために用いられる、実施形態１０〜１２の何れか１つのプロセッサ。

【0185】

１４．短い記述トランスレーションテーブルフォーマットを使用する場合、前記アクセスフラグのハードウェアマネージメントは、前記アクセスフラグの使用を可能にするためにＳＣＴＬＲ．ＡＦＥビットがセットされ、且つ、前記アクセスフラグのハードウェアマネージメントを可能にするために前記ＳＣＴＬＲ．ＨＡビットがセットされる場合に、実行される、実施形態１０〜１３の何れか１つのプロセッサ。

【0186】

１５．ＳＣＴＬＲのバンキングは、前記ＳＣＴＬＲ．ＡＦＥ及び前記ＳＣＴＬＲ．ＨＡビットが安全及び安全でないアドレストランスレーションのために単独で定義されている、実施形態１４のプロセッサ。

【0187】

１６．前記アクセスフラグのハードウェアマネージメントが、アドレストランスレーションのステージのために許可される場合に、アクセスフラグの結果は、対応するトランスレーションのために発生することがない、実施形態１０〜１５の何れか１つのプロセッサ。

【0188】

１７．前記ＩＯＭＭＵは、仮想メモリ（ＤＶＭ）無効の配布を実行するメカニズムをさらに有する、実施形態１〜１６の何れか１つのプロセッサ。

【0189】

１８．前記ＤＶＭ無効メカニズムは、ホストＩＳＯＣポステッドインタフェースを用いることを含む、実施形態１７のプロセッサ。

【0190】

１９．ＩＳＯＣポステッドライトメッセージは、解読され、プロセッサリクエストを命じる相似する無効フォーマットに変更される、実施形態１８のプロセッサ。

【0191】

２０．前記無効メッセージは、中央演算処理装置（ＣＰＵ）から前記ホストＩＳＯＣポステッドライトチャネルの前記ＩＯＭＭＵレベル２への無効メッセージを含む、実施形態１７〜１９の何れか１つのプロセッサ。

【0192】

２１．前記無効メッセージは、無効入出力ＴＬＢで使用される、実施形態２０のプロセッサ。

【0193】

２２．前記無効メッセージは、中央演算処理装置（ＣＰＵ）から前記ホストＩＳＯＣポステッドライトチャネルのＩＯＭＭＵレベル２への同期メッセージを含む、実施形態１７〜１９の何れか１つのプロセッサ。

【0194】

２３．前記同期メッセージは、完成待ち命令と類似している、実施形態２２のプロセッサ。

【0195】

２４．前記ＩＯＭＭＵレベル２は、完成メッセージに戻る、実施形態２２又は２３のプロセッサ。

【0196】

２５．前記無効メッセージは、前記ＩＯＭＭＵレベル２からＯＲＢ又は統合ノースブリッジまでのダイレクトメモリアクセス（ＤＭＡ）ＩＳＯＣポステッドライトである完成メッセージを含む、実施形態１７〜１９の何れか１つのプロセッサ。

【0197】

２６．前記完成メッセージは、命令パイプラインがフラッシュされ、全てのアウトスタンディング入出力ＴＬＢが完了した場合に送られる、実施形態２５のプロセッサ。

【0198】

２７．前記ＤＶＭオペレーションは、ＣＰＵ、ＩＯＭＭＵ及びＡＴＣのエントリが無効になるように使用される、実施形態１７〜２６の何れか１つのプロセッサ。

【0199】

２８．前記ＩＯＭＭＵレベル２は、前記ＤＶＭ無効コマンドを受ける際にグラフィックス処理単位（ＧＰＵ）ＡＴＣに無効コマンドを生成する、実施形態１７〜２７の何れか１つのプロセッサ。

【0200】

２９．前記ＩＯＭＭＵレベル２は、前記メッセージタイプに基づき前記ＤＶＭ無効コマンドを処理する、実施形態２８のプロセッサ。

【0201】

３０．前記ＩＯＭＭＵレベル２は、関連したオペレーションを前記ＧＰＵ ＡＴＣに向かうようにする、実施形態２８又は２９のプロセッサ。

【0202】

３１．前記ＩＯＭＭＵレベル２は、前記ＧＰＵに適用できないオペレーションを取り除くために前記オペレーションをフィルタに通す、実施形態３０のプロセッサ。

【0203】

３２．前記ＩＯＭＭＵは、ドメインＩＤ及びＰＡＳＩＤの前記ＧＰＵ使用法の経過を追うようにさらに構成されている、実施形態２８〜３１の何れか１つのプロセッサ。

【0204】

３３．前記ＩＯＭＭＵは、ＤＶＭ無効の間に使用される１つ以上のレジスタをさらに有する、実施形態１７〜３２の何れか１つのプロセッサ。

【0205】

３４．前記１つ以上のレジスタは、インターナルグラフィックのために有効なＡＳＩＤを確認するために用いられる前後のシャドウレジスタを含む、実施形態３３のプロセッサ。

【0206】

３５．前記１つ以上のレジスタは、インターナルグラフィックデバイスのＲＥＱＩＤを含むレジスタを有する、実施形態３３又は３４のプロセッサ。

【0207】

３６．前記１つ以上のレジスタは、ｑｕｅｕｅＩＤ毎の未処理のＡＴＳ無効の最大の数を含むレジスタを有する、実施形態３３〜３５の何れか１つのプロセッサ。

【0208】

３７．前記１つ以上のレジスタは、ＡＴＳ ＴＬＢ無効のｑｕｅｕｅＩＤを含むレジスタを有する、実施形態３３〜３６の何れか１つのプロセッサ。

【0209】

３８．前記１つ以上のレジスタは、前記無効がインターナルグラフィックスデバイスの目標であることを確認するのに用いられる前記インターナルグラフフィクスデバイスのドメインＩＤを含むレジスタを有する、実施形態３３〜３７の何れか１つのプロセッサ。

【0210】

３９．前記レジスタからの価値は、前記ＡＴＳコマンドに挿入される、実施形態３３〜３８の何れか１つのプロセッサ。

【0211】

４０．前記ＩＯＭＭＵは、１６のＰＡＳＩＤＭＡＰレジスタをさらに有する、実施形態１７〜３９の何れか１つのプロセッサ。

【0212】

４１．前記ＰＡＳＩＤＭＡＰレジスタは、ＳＲＢＭインタフェースを介してアクセス可能である、実施形態４０のプロセッサ。

【0213】

４２．ライトがＰＡＳＩＤＭＡＰレジスタで生成される場合に、同じデータがＩＯＭＭＵに書き込まれる、実施形態４０又は４１のプロセッサ。

【0214】

４３．前記ＩＯＭＭＵへのアクセスは、リードの実行によってフラッシュされる、実施形態４２のプロセッサ。

【0215】

４４．前記ＩＯＭＭＵのＰＡＳＩＤ有効レジスタは、ＰＡＳＩＤがもはや必要でないときにクリアされる、実施形態４０〜４３の何れか１つのプロセッサ。

【0216】

４５．前記ＡＴＣは、前記ＶＭＩＤが再配置されるちょうど前に、ＶＭＩＤによって無効にされる、実施形態４４のプロセッサ。

【0217】

４６．ディストリブーテッド仮想メモリ（ＤＶＭ）メッセージを処理するように構成された回路を有するノースブリッジを含む、プロセッサ。

【0218】

４７．前記ノースブリッジは、トランスレーションロッカブルバッファ（ＴＬＢ）エントリを実行するようにさらに構成された回路を有する、実施形態４６のプロセッサ。

【0219】

４８．前記ＤＶＭメッセージは、入出力コントロール（ＩＯＣ）ブロックに送られる、実施形態４６又は４７のプロセッサ。

【0220】

４９．ＤＶＭオペレーションは、ガスケットからＷｒＤｗｏｒｄとして送られ、ガスケットは、統合ノースブリッジ（ＵＮＢ）と前記プロセッサとの間を通信するデバイスを含む、実施形態４６〜４８の何れか１つのプロセッサ。

【0221】

５０．前記ＷｒＤｗｏｒｄは、１２８ビットデータペイロードを含む、実施形態４９のプロセッサ。

【0222】

５１．異なるアドレスは、ＤＶＭオペレーションの異なるタイプのために使用される、実施形態４６〜５０の何れか１つのプロセッサ。

【0223】

５２．ＷａｉｔＳｐｕＳｅｃｕｒｅＢｏｏｔＩｎｉｔがゼロに等しくなるまで、前記プロセッサにトークンリリースを停止させるように構成された回路をさらに有する、実施形態４６〜５１の何れか１つのプロセッサ。

【0224】

５３．前記プロセッサは、ＤｒａｍＶａｌｉｄ又はＨｔＩｎｉｔＳｔａｔｕｓＶａｌｉｄビットを引くことがない、実施形態５２のプロセッサ。

【0225】

５４．前記プロセッサが安全なブートモードにある場合に、プロセススタックポインタ（ＰＳＰ）は、前記ノースブリッジレジスタ及び前記ダイナミックランダムアクセスメモリ（ＤＲＡＭ）の全てをセットアップする、実施形態５２又は５３のプロセッサ。

【0226】

５５．前記ＤＶＭメッセージは、無効又はＳｙｎｃＯｐメッセージを含む、実施形態４６〜５４の何れか１つのプロセッサ。

【0227】

５６．前記ＤＶＭメッセージは、無効であるＳＭＭＵエントリを結果とする、実施形態５５のプロセッサ。

【0228】

５７．前記ＤＶＭメッセージは、完了メッセージが送られる前に未処理のリクエストをページに完了しなければならない、実施形態５５又は５６のプロセッサ。

【0229】

５８．デバイスから前記ＵＮＢへの同時性ポステッドクレジットをリリースするように構成された回路をさらに有する、実施形態５５〜５７の何れか１つのプロセッサ。

【0230】

５９．デバイスから前記ＵＮＢへの同時性ポステッドライトを受け入れるように構成された回路をさらに有する、実施形態５５〜５８の何れか１つのプロセッサ。

【0231】

６０．新しいレジスタに新しいチャネルをトークンに割り当てることによって有効になる前記チャネルをさらに有する、実施形態５５〜５９の何れか１つのプロセッサ。

【0232】

６１．前記新しいチャネルは、ＤＶＭ Ｏｐ及びＤＶＭ Ｓｙｎｃリクエストによって使用される、実施形態６０のプロセッサ。

【0233】

６２．グローバルタイムスタンプカウンタをさらに有する、実施形態４６〜６１の何れか１つのプロセッサ。

【0234】

６３．前記グローバルタイムスタンプカウンタは、キューを介してプロセッサインタフェースに供給される、実施形態６２のプロセッサ。

【0235】

６４．前記キューは、ファーストインファーストアウトキューである、実施形態６３のプロセッサ。

【0236】

６５．セマフォオペレーションへのアトミックアクセスをサポートするアドレスへ排他的なアクセスを供給するように構成された回路を有する、実施形態４６〜６４の何れか１つのプロセッサ。

【0237】

６６．前記回路は、排他的なロードがＭＣＴにおいて見られる場合に作動する、実施形態６５のプロセッサ。

【0238】

６７．前記プロセッサからのＶｉｃＢｌｋリクエストのためのハードトークンをさらに有する、実施形態４６〜６６の何れか１つのプロセッサ。

【0239】

６８．前記プロセッサは、ライトデータチャネルのデータを前記ガスケットにプッシュするようにさらに構成されている、実施形態６７のプロセッサ。

【0240】

６９．前記データは、前記ノースブリッジが前記ガスケットから前記データを引き出し、前記ガスケットがターゲットダンシグナルを受けた後に、前記ライトデータチャネルの前記データでプッシュされる、実施形態６８のプロセッサ。

【0241】

７０．前記ターゲットダンシグナルは、ライトバッファリリースシグナルによって通信される、実施形態６９のプロセッサ。

【0242】

７１．前記プロセッサがライトバックを発する場合、前記ガスケット及び前記ＳＲＩは、メモリに前記ライトバックを届ける、実施形態６７〜７０の何れか１つのプロセッサ。

【0243】

７２．デッドロックコンディションは、前記プロセッサが完了するライトバックを待つ間に存在する、実施形態７１のプロセッサ。

【0244】

７３．前記プロセッサから前記ＭＣＴへの仮想チャネルをさらに有し、前記ＭＣＴでは、より古いリクエストをパスするライトバックを許容する、実施形態６７〜７２の何れか１つのプロセッサ。

【0245】

７４．追加のライトバックチャネル及び前記追加のライトバックチャネルのための専用バッファをさらに有する、実施形態６７〜７３の何れか１つのプロセッサ。

【0246】

７５．前記プロセッサからの前記ビクティム／ライトバックのための前記ＳＲＱのためにトークンが割り当てられた専用ハードをさらに有する、実施形態７４のプロセッサ。

【0247】

７６．前記ＳＲＱは、ビクティムのための可能なトークンを常に有するであろう、実施形態７５のプロセッサ。

【0248】

７７．ホストブリッジリードのためにプローブターゲットを発する前記ＭＣＴのための回路をさらに有する、実施形態４６〜７６の何れか１つのプロセッサ。

【0249】

７８．前記プローブターゲットを発することは、堅実なプローブレスポンス、ＤＲＡＭリードデータ、可能なビクティムパッシングケース、及び、ＳＲＩにシングルリードレスポンスバックを発することを前記ＭＣＴに許容する、実施形態７７のプロセッサ。

【0250】

７９．ＭＣＴリクエストへの全てのＸＢＡＲは、より若いパッシングビクティムからプローブダーティデータ又はデータを受け入れるＭＣＤエントリを割り当てる、実施形態７７又は７８のプロセッサ。

【0251】

８０．ＭｃｄＬｏ及びＭｃｄＨｉトークンを確保することをさらに有する、実施形態７９のプロセッサ。

【0252】

８１．ホストブリッジリードを実行するように構成された回路をさらに有する、実施形態４６〜８０の何れか１つのプロセッサ。

【0253】

８２．前記ホストブリッジリードは、ＭＣＤエントリの割り当て及びＭｃａＤａｔＰｔｒを有効に設定する、実施形態８１のプロセッサ。

【0254】

８３．前記ホストブリッジリードは、クリーニングＭＣＤバイトマスクをさらに含む、実施形態８２のプロセッサ。

【0255】

８４．前記ホストブリッジリードは、ホストブリッジリクエストのためのディセーブリングデータフォワーディングをさらに含む、実施形態８３のプロセッサ。

【0256】

８５．前記ホストビリッジリードは、プローブターゲットを発することをさらに含む、実施形態８４のプロセッサ。

【0257】

８６．前記ホストブリッジリードは、ホストブリッジＲｄＳｚリクエストを介してＭＣＱＲｄＲｓｐＷａｉｔＳｙｓビットを設定することをさらに含む、実施形態８５のプロセッサ。

【0258】

８７．前記ホストブリッジリードは、前記プロセッサプローブがペンディングすること及び前記プローブがダーティデータを返却することの何れかの間に前記ＤＣＴリードレスポンスが着いた場合に、ウエイトビットとしてのＭＣＱＷａｉｔＧ５ＣａｎＤｅｔのオーバーローディングをさらに含む、実施形態８６のプロセッサ。

【0259】

８８．前記ホストブリッジリードは、ＭＰＤＢへの前記ＤＣＴデータライトが一度完了してＸＢＡＲ ｒｄレスポンスを送ることをさらに含む、実施形態８７のプロセッサ。

【0260】

８９．前記ホストブリッジリードは、ＭＣＱＲｄＲｓｐＷａｉｔＳｙｓをクリーニングし、プローブミスで起こる際の続くＸＢＡＲ ＲｄＲＳＰ ｐｉｃｋを許容することをさらに含む、実施形態８７又は８８のプロセッサ。

【0261】

９０．前記ホストブリッジリードは、ＤＣＴレスポンスがプロセッサプローブレスポンスのミスの後に到着した場合に、ＸＢＡＲリードレスポンスを発することをさらに含む、実施形態８７〜８９の何れか１つのプロセッサ。

【0262】

９１．２つの安全なメモリレンジは、ＳＭＭタイプ機能を安全なメモリ領域で使用するために登録することをさらに有する、実施形態４６〜９０の何れか１つのプロセッサ。

【0263】

９２．前記安全なメモリ領域へのアクセスは、ＰＳＰを除く全てのデバイスから無効である、実施形態９１のプロセッサ。

【0264】

９３．前記プロセッサは、安全モードの場合のみ、前記安全なメモリ領域にアクセスできる、実施形態９１又は９２のプロセッサ。

【0265】

９４．前記安全なメモリ領域へのリード／ライトアクセスは、レジスタのリードイネーブル（ＲＥ）／ライトイネーブル（ＷＥ）ビットを介して制限されてもよい、実施形態９１〜９３の何れか１つのプロセッサ。

【0266】

９５．前記プロセッサが前記安全なメモリ領域にアクセスできる場合に、決定する要求とともにＮＳビットを送ることをさらに有する、実施形態９１〜９４の何れか１つのプロセッサ。

【0267】

９６．ｃｏｒｅＳｉｇｈｔアクセスは、ＤＲＡＭへの通常のライトのようにこれらのアクセスによる前記ガスケットによって処理される、実施形態４６〜９６の何れか１つのプロセッサ。

【0268】

９７．ＧＮＢとＮＢとの間のインタラプトワイヤをさらに有する、実施形態４６〜９６の何れか１つのプロセッサ。

【0269】

９８．前記インタラプトワイヤは、レベルインタラプトである、実施形態９７のプロセッサ。

【0270】

９９．無損失ＣＣＩトランスポートを保証するためにＰＬＬ再ロックを始動する前に前記プロセッサとノースブリッジとのインタフェースを静止するように構成された回路をさらに有する、実施形態４６〜９８の何れか１つのプロセッサ。

【0271】

１００．前記静止することは、ＳｔｐＣｌｋ／ＳｔａｒｔＣｌｋハンドシェイクメカニズムを用いることを含む、実施形態９９のプロセッサ。

【0272】

１０１．前記ノースブリッジと前記ガスケットとの間のサイドバンドを生成することをさらに有する、実施形態９９又は１００のプロセッサ。

【0273】

１０２．前記静止することは、前記ＳｔｐＣｌｋハンドラでＷＦＥを使用することを含む、実施形態１００又は１０１のプロセッサ。

【0274】

１０３．ＸＣ６のためにアディングインタラプトレートモニタサポートをさらに有する、実施形態４６〜１０２の何れか１つのプロセッサ。

【0275】

１０４．ＸＣ６エントリ決定に直面している間に漸減率が低下することをさらに有する、実施形態１０３のプロセッサ。

【0276】

１０５．Ｌ２ミスのトラッキング及びバスアクセスのために追加のカウンタをさらに有する、実施形態４６〜１０４の何れか１つのプロセッサ。

【0277】

１０６．ライトバックとプローブとの間のデッドロックを解決するライトバックのための仮想チャネルをさらに有する、実施形態４６〜１０５の何れか１つのプロセッサ。

【0278】

１０７．ライトバックは、それらが一度ＭＣＴに達すると古いリードの前に再整理されてもよい、実施形態１０６のプロセッサ。

【0279】

１０８．前記再整理は、初期のＤＲＡＭリードを再発することを含む、実施形態１０７のプロセッサ。

【0280】

１０９．ビクティムが達した場合に、より古いオペレーションでアドレス一致のための前記ビクティムをチェックすることをさらに有する、実施形態１０６〜１０８の何れか１つのプロセッサ。

【0281】

１１０．アドレス一致が起きた場合に、前記一致が、プローブレスポンスを待っているリード又はプローブレスポンスを待っているライトに対してであるかどうかをチェックする、実施形態１０９のプロセッサ。

【0282】

１１１．複数のアドレス一致が検出された場合に、最も古いアドレスマッチが選ばれる、実施形態１０９又は１１０のプロセッサ。

【0283】

１１２．前記ビクティムがレスポンスのために待っているライトに一致する場合に、前記ビクティムは、プローブレスポンスとして扱われ、以前のライトのＭＣＤエントリにマージされる、実施形態１０９〜１１１の何れか１つのプロセッサ。

【0284】

１１３．前記ビクティムに割り当てられたＭＣＤエントリをリリースすることをさらに有する、実施形態１１２のプロセッサ。

【0285】

１１４．前記ビクティムがレスポンスのために待っているリードに一致する場合に、前記ビクティムは、前記リードのＭＣＤエントリにマージされ、そのＭＣＤエントリ自身に書き込まれる、実施形態１０９〜１１１の何れか１つのプロセッサ。

【0286】

１１５．前記ビクティムは、第２のＭＣＤライトポートを介してＭＣＤエントリ自身に書き込まれる、実施形態１１４のプロセッサ。

【0287】

１１６．インビジブルフレームバッファ（ＩＶＦＢ）をさらに有する、実施形態４６〜１１５の何れか１つのプロセッサ。

【0288】

１１７．前記ＩＶＦＢは、前記ＰＳＰによって設定され、任意のサイズに設定される、実施形態１１６のプロセッサ。

【0289】

１１８．前記ＩＶＦＢへのリードアクセスが制限されている、実施形態１１６又は１１７のプロセッサ。

【0290】

１１９．任意のホストは、前記ＩＶＦＢに書き込むことができる、実施形態１１６〜１１８の何れか１つのプロセッサ。

【0291】

１２０．送られるベクタを除くｆｄｆ７の安全を強いる場合に、決定されるＳｅｃｕｒｅＥｎａｂｌｅのためのシグナルアクセスＣＣＩをさらに有する、実施形態４６〜１１９の何れか１つのプロセッサ。

【0292】

１２１．前記ガスケットは、ＳＭＮインタフェースでコンフィグレジスタを実行するように構成されている、実施形態４６〜１２０の何れか１つのプロセッサ。

【0293】

１２２．前記状態は、そのＸＣ６キャッシュ／状態フラッシュルーチンの間、前記プロセッサによって保存される、実施形態１２１のプロセッサ。

【0294】

１２３．前記状態は、前記Ｃ６リセットハンドラを介して前記プロセッサによってリストアされる、実施形態１２２のプロセッサ。

【0295】

１２４．前記プロセッサは、ラップオーダーとして知られているバーストオーダーをサポートし、前記ラップオーダーは、データが送信され又は受信されることを期待されるオーダーである、実施形態４６〜１２３の何れか１つのプロセッサ。

【0296】

１２５．ＭＰＢＤ又はＳＲＤから戻されるデータは、ラップオーダーに戻される、実施形態１２４のプロセッサ。

【0297】

１２６．ラップオーダーの中でＭＰＢＤから読み込まれるデータは、期待されるバーストオーダーの中でＳＲＤに書き込まれてもよい、実施形態１２４又は１２５のプロセッサ。

【0298】

１２７．ＳＲＤは、前記プロセッサにデータを戻すためにラップオーダーで読み込まれるであろう、実施形態１２６のプロセッサ。

【0299】

１２８．前記ＣＣ６領域が構成可能である、実施形態４６〜１２７の何れか１つのプロセッサ。

【0300】

１２９．ビットは、前記ＣＣ６領域の再構成可能性を示すセキュアブートレジスタで設定される、実施形態１２８のプロセッサ。

【0301】

１３０．前記ビットは、セキュアブートプロセスの間、前記ＰＳＰによって書き込まれる、実施形態１２９のプロセッサ。

【0302】

１３１．統合ノースブリッジ（ＵＮＢ）と前記プロセッサとの間で通信されるガスケットをさらに有する、実施形態４６〜１３０の何れか１つのプロセッサ。

【0303】

１３２．前記ガスケットは、前記プロセッサクロックドメインに存在する、実施形態１３１のプロセッサ。

【0304】

１３３．前記ガスケットは、キャッシュコーヒレントインターコネクト（ＣＣＩ）にトランザクションを変換するように構成されている、実施形態１３１又は１３２のプロセッサ。

【0305】

１３４．前記ガスケットは、システムプローブをスヌープに変換するように構成されている、実施形態１３１〜１３３の何れか１つのプロセッサ。

【0306】

１３５．統合ノースブリッジ（ＵＮＢ）／コーヒレントＨｙｐｅｒＴｒａｎｓｐｏｒｔ（ｃＨＴ）環境とともにメモリマップをインターオペレートに変換するように構成されている、実施形態１３１〜１３４の何れか１つのプロセッサ。

【0307】

１３６．前記ガスケットは、転送サイズをＵＮＢ／ｃＨＴ環境とともにインターオペレートに変換するように構成されている、実施形態１３１〜１３５の何れか１つのプロセッサ。

【0308】

１３７．前記ガスケットは、アドバンスイクステンシブルインタフェース（ＡＸＩ）コーヒレンシイクステンション（ＡＣＥ）コマンドから、同等ＣＣＩコマンドへのプロセッサからのリクエストを変換するように構成されている、実施形態１３１〜１３６の何れか１つのプロセッサ。

【0309】

１３８．前記プロセッサからの各リクエストは、特別なＣＣＩリクエストタイプにマップする、実施形態１３７のプロセッサ。

【0310】

１３９．前記プロセッサからのリクエストのタイプは、リード及びライトアドレスチャネルのＡｘＤｏｍａｉｎ及びＡｘＳｎｏｏｐフィールドにエンコードされる、実施形態１３７〜１３８の何れか１つのプロセッサ。

【0311】

１４０．前記バスのビットは、ＡＣＥ属性を伝えるためにオーバーロードになり得る、実施形態１３７〜１３９の何れか１つのプロセッサ。

【0312】

１４１．前記ガスケットは、ＡＣＥタグをＣＣＩタグに変換するように構成されている、実施形態１３７〜１４０の何れか１つのプロセッサ。

【0313】

１４２．同じタグをシェアするＡＣＥリクエストは、前記ガスケットの中で順番とされる、実施形態１４１のプロセッサ。

【0314】

１４３．前記ガスケットは、同等のＡＣＥスヌープトランザクションへのＳＲＩからＣＣＩエンコーデッドプローブに変換されるように構成されている、実施形態１３７〜１４２の何れか１つのプロセッサ。

【0315】

１４４．前記ガスケットが前記ＣＣＩインタフェースからリードレスポンスを受信した場合に、クラスタへのＡＣＥバスに同等のレスポンスを生成する、実施形態１３７〜１４３の何れか１つのプロセッサ。

【0316】

１４５．前記ガスケットは、データの全てのビートが前記ＣＣＩインタフェースから受信されるまで前記ＡＣＥレスポンスの起動を遅延するように構成されている、実施形態１４４のプロセッサ。

【0317】

１４６．前記ガスケットは、ＳＲＩへの各リクエストとともに送られる前記期待された補助アドレスタイプシグナルを生成するメモリマップを使用するように構成されている、実施形態１３７〜１４５の何れか１つのプロセッサ。

【0318】

１４７．前記ガスケットは、ｃＨＴにトランザクションを変換する前記メモリマップを使用するように構成されている、実施形態１４６のプロセッサ。

【0319】

１４８．ライトバックによりアクセスされる独立した仮想チャネルをさらに有し、前記ライトバックは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）にドレインできる、実施形態４６〜１４７の何れか１つのプロセッサ。

【0320】

１４９．前記ガスケットを横断する前記ライトバックのためのノンブロッキングパスをさらに有する、実施形態１４８のプロセッサ。

【0321】

１５０．ＳＲＱを横断するライトバックのためのノンブロッキングパスをさらに有する、実施形態１４９のプロセッサ。

【0322】

１５１．クロスバーを介するノンブロッキングパスをさらに有する、実施形態１５０のプロセッサ。

【0323】

１５２．ＭＣＴに到着した場合に、前記ライトバックは、他のリクエストにパスする、実施形態１４８〜１５１の何れか１つのプロセッサ。

【0324】

１５３．最も古いリードは、前記ライトバックに依存してマークされる、実施形態１５２のプロセッサ。

【0325】

１５４．前記ライトバックは、ノンライトバックライトにインターリーブされない、実施形態１４８〜１５３の何れか１つのプロセッサ。

【0326】

１５５．前記ガスケットは、シンクロナイザからシグナルを駆動及び受信するためにスキップクロックロジックを観測するように構成されている、実施形態１３１〜１５４の何れか１つのプロセッサ。

【0327】

１５６．前記ガスケットは、ライトコマンドが５クロック分離に従うことを確実に予想したファーストインファーストアウト（ＦＩＦＯ）キューを使用するように構成されている、実施形態１５５のプロセッサ。

【0328】

１５７．前記ガスケットは、前記ＡＣＥタイミングとともに前記プロセッサへレスポンスを向かわせるように構成されている、実施形態１５５又は１５６のプロセッサ。

【0329】

１５８．前記シンクロナイザは、前記シンクロナイザＦＩＦＯが後で１０クロックをリーディング／ライティングするために可能となるかどうかを示すシグナルを前記ガスケットに提供する、実施形態１５５〜１５７の何れか１つのプロセッサ。

【0330】

１５９．前記ガスケットは、マルチプルＣＣＩライトにＡＣＥライトを分割するように構成されている、実施形態１３７〜１５８の何れか１つのプロセッサ。

【0331】

１６０．キュー及び／又はライトバッファは、転送されることを必要とする前記特定のバイトを追跡するように、適切なコマンドを生成するように構成されている、実施形態１５９のプロセッサ。

【0332】

１６１．エントリは、前記複数のライトの全てが完了され及びリリースされた場合に、割り当てを取り消される、実施形態１５９又は１６０のプロセッサ。

【0333】

１６２．ライトは、キャッシュラインを満たすように結合される、実施形態１３７〜１６１の何れか１つのプロセッサ。

【0334】

１６３．前記ガスケットは、ライトリクエストエントリの数よりも少ないライトを含む、実施形態１６２のプロセッサ。

【0335】

１６４．前記ライトデータは、前記ＳＲＩによって前記バッファから引かれるまで保持される、実施形態１６２又は１６３のプロセッサ。

【0336】

１６５．前記ライトリクエストは、前記レスポンスが前記プロセッサに送られることができるまでオープンを保つ、実施形態１６２〜１６４の何れか１つのプロセッサ。

【0337】

１６６．前記レスポンスは、ターゲット完了信号のオフに基づくＳＲＩバッファリリースの後に前記プロセッサに送られ得る、実施形態１６５のプロセッサ。

【0338】

１６７．前記ガスケットは、前記バッファをフラッシュするようにさらに構成されている、実施形態１６２〜１６６の何れか１つのプロセッサ。

【0339】

１６８．前記バッファは、バッファフラッシュトリガに基づいてフラッシュされる、実施形態１６７のプロセッサ。

【0340】

１６９．前記バッファフラッシュトリガは、いつでも前記バッファが完全に有効である、実施形態１６８のプロセッサ。

【0341】

１７０．前記バッファフラッシュトリガは、いつでも前記未送信バッファが使い果たされている、実施形態１６８のプロセッサ。

【0342】

１７１．前記バッファフラッシュトリガは、いつでもプロセッサライトが、プロセッサに対して既にオープンなバッファにヒットしない、実施形態１６８のプロセッサ。

【0343】

１７２．前記バッファフラッシュトリガは、いつでもオープンバッファの数のプログラムの限界に達している、実施形態１６８のプロセッサ。

【0344】

１７３．前記バッファフラッシュトリガは、前記バッファがもはや書き込まれないことを示している、実施形態１６８のプロセッサ。

【0345】

１７４．正しいキャッシュ可能性の属性のみのライトが結合され得る、実施形態１６７〜１７３の何れか１つのプロセッサ。

【0346】

１７５．バリアのための全てのバッファがフラッシュされる、実施形態１６７〜１７４の何れか１つのプロセッサ。

【0347】

１７６．全てのバッファがＤｖｍＳｙｎｃのためにフラッシュされる、実施形態１６７〜１７５の何れか１つのプロセッサ。

【0348】

１７７．前記ガスケットは、トランザクションのオーダーが維持されるバリアトランザクションを実行するように構成されている、実施形態１３７〜１７６の何れか１つのプロセッサ。

【0349】

１７８．前記バリアトランザクションはメモリバリアを含む、実施形態１７７のプロセッサ。

【0350】

１７９．前記メモリバリアは、マスターコンポーネントが前記バリアの前に発せられた全てのトランザクションを観測することができる前記バリアの後に、前記コンポーネントが任意のトランザクションの問題を観測できるかどうかを保証する、実施形態１７８のプロセッサ。

【0351】

１８０．前記バリアトランザクションはシンクロナイゼーションバリアを含む、実施形態１７７のプロセッサ。

【0352】

１８１．前記シンクロナイゼーションバリアは、前記バリアが完了するときの前記適切なドメインの全てのマスターコンポーネントによって前記バリアが観測できる前に発せられた全てのトランザクションを保証するマスターコンポーネントによって発せられる、実施形態１８０のプロセッサ。

【0353】

１８２．前記シンクロナイゼーションバリアは、サイドバンドシグナリンコミュニケーションで使用される、実施形態１８０又は１８１のプロセッサ。

【0354】

１８３．前記バリアトランザクションは、全てのより以前のリクエストが、前記プロセッサの完了を示す前に前記ＳＲＩへの前記ガスケットによって発せられていることを確認することにより、前記ガスケットによって処理される、実施形態１７７〜１８２の何れか１つのプロセッサ。

【0355】

１８４．前記ガスケットは、全てのより古いリクエストが発せられた前記プロセッサへの前記バリアトランザクションのための前記レスポンスを送る、実施形態１８３のプロセッサ。

【0356】

１８５．前記ガスケットはジェネリックインタラプトコントローラ（ＧＩＣ）を含む、実施形態１３１〜１８４の何れか１つのプロセッサ。

【0357】

１８６．前記ＧＩＣは、プロセッサインタフェース、ディストリビュータ及びインタラプトトランスレーションサービス（ＩＴＳ）を含む、実施形態１８５のプロセッサ。

【0358】

１８７．前記ディストリビュータは、ローカルＳＲＩによって受信するであろうＭＳＩパケットを介してソースからインタラプトを受信するように構成されている、実施形態１８６のプロセッサ。

【0359】

１８８．前記プロセッサは、前記ＩＯＭＭＵにアップデートするページテーブルと通信するディストリブテッドバーチャルメモリ（ＤＶＭ）トランザクションを発するように構成されている、実施形態１〜１８７の何れか１つのプロセッサ。

【0360】

１８９．前記ＤＶＭトランザクションはポステッドライトに変換される、実施形態１８８のプロセッサ。

【0361】

１９０．前記ＤＶＭコマンドは、前記ＤＶＭベースアドレスからオフセットするアドレスの一部によって同一視される、実施形態１８８又は１８９のプロセッサ。

【0362】

１９１．前記プロセッサは、リードチャネルでの１つ以上のＤＶＭオペレーション（ＤｖｍＯｐ）のシーケンスを発する実施形態１８８〜１９０の何れか１つのプロセッサ。

【0363】

１９２．前記ガスケットは、ＤＷＯＲＤライトオペレーションでの各ＤｖｍＯｐを変換するように構成されている、実施形態１９１のプロセッサ。

【0364】

１９３．前記ライトデータは、前記ＤｖｍＯｐからの必要なインフォメーションを含む、実施形態１９２のプロセッサ。

【0365】

１９４．前記プロセッサは、任意の前のＤｖｍＯｐをプッシュし、それらが完了することを確認する前記リードチャネルのＤｖｍＳｙｎｃオペレーションを発するように構成されている、実施形態１８８〜１９３の何れか１つのプロセッサ。

【0366】

１９５．ＤｖｍＳｙｎｃオペレーションを受信する各エージェントは、全てのペンディングＤｖｍＯｐ及びＤｖｍＳｙｎｃを完了している自身のＤｖｍＣｏｍｐｌｅｔｉｏｎオペレーションを発する、実施形態１９４のプロセッサ。

【0367】

１９６．前記ＩＯＭＭＵは、任意の前のオペレーションをプッシュする前記ホストブリッジにＦＥＮＣＥ／ＦＬＵＳＨコマンドを発する、実施形態１９５のプロセッサ。

【0368】

１９７．前記ＩＯＭＭＵは、全てのＤｖｍＯｐ及びアイソクロナウスポステッドＢＹＴＥライトを介したＤｖｍＳｙｎｃの完了を信号で送る、実施形態１９６のプロセッサ。

【0369】

１９８．前記ＤｖｍＳｙｎｃ ｏｐｓは連続的に処理され得る、実施形態１９４〜１９７の何れか１つのプロセッサ。

【0370】

１９９．前記ガスケットは、前記ＤｖｍＳｙｎｃ ｏｐｓを連続的に処理するように構成されている、実施形態１９８のプロセッサ。

【0371】

２００．前記ガスケットは、マルチパートＤｖｍＯｐの一部を合成し得るプロセッサ毎の１つのＤＶＭバッファを含む、実施形態１９９のプロセッサ。

【0372】

２０１．前記ガスケットは、プロセッサリード及びライトアドレスチャネルを合成するようにさらに構成されている、実施形態１３７〜２００の何れか１つのプロセッサ。

【0373】

２０２．インプット及びシグナルシェアードキューで結合されている前記リード及び前記ライトアドレスチャネルが実装されている、実施形態２０１のプロセッサ。

【0374】

２０３．マルチプレクサは、前記単一のシェアードキューに関連付けられ、２つのインプットの１つを選択するために使用される、実施形態２０２のプロセッサ。

【0375】

２０４．別々のキューは、前記リード及び前記ライトアドレスチャネルのために実装され、前記キューはアウトプットに結合される、実施形態２０１のプロセッサ。

【0376】

２０５．ＤＳＭホックは、前記ガスケットの前記ＡＣＥサイドにモニターされるように構成されている、実施形態１３７〜２０４の何れか１つのプロセッサ。

【0377】

２０６．前記ガスケットはレジスタの構成を含む、実施形態１３１〜２０５の何れか１つのプロセッサ。

【0378】

２０７．前記ガスケットはアドレスレジスタベースのレジスタを含む、実施形態２０６のプロセッサ。

【0379】

２０８．前記ガスケットは実行状態リセットベクタアドレスレジスタを含む、実施形態２０６又は２０７のプロセッサ。

【0380】

２０９．前記ガスケットはＧＩＣアドレススペースレジスタを含む、実施形態２０６〜２０８の何れか１つのプロセッサ。

【0381】

２１０．前記ガスケットは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）コンフィグレーションベースアドレスレジスタを含む、実施形態２０６〜２０９の何れか１つのプロセッサ。

【0382】

２１１．前記ガスケットは、コンフィグレーション及びコントロールビットレジスタを含む、実施形態２０６〜２１０の何れか１つのプロセッサ。

【0383】

２１２．前記コンフィグレーション及びコントロールビットレジスタは、セットリクエストキューサイズの指示を含む、実施形態２１１のプロセッサ。

【0384】

２１３．前記コンフィグレーション及びコントロールビットレジスタは、特殊なトランザクションが順番にされるかどうかの指示を含む、実施形態２１１又は２１２のプロセッサ。

【0385】

２１４．前記コンフィグレーション及びコントロールビットレジスタは、ＣＣＩリクエストマッピングの代替ＡＣＥが利用されるかどうかの指示を含む、実施形態２１１〜２１３の何れか１つのプロセッサ。

【0386】

２１５．前記コンフィグレーション及びコントロールビットレジスタは、ＡＣＥスヌープマッピングの代替ＣＣＩプローブが利用されるかどうかの指示を含む、実施形態２１１〜２１４の何れか１つのプロセッサ。

【0387】

２１６．前記コンフィグレーション及びコントロールビットレジスタは、ガスケット静止無効指示を含む、実施形態２１１〜２１５の何れか１つのプロセッサ。

【0388】

２１７．前記コンフィグレーション及びコントロールビットレジスタは、ライトバック順序無効指示を含む、実施形態２１１〜２１６の何れか１つのプロセッサ。

【0389】

２１８．前記コンフィグレーション及びコントロールビットレジスタは、全てのマルチトランザクションパーシャルライトのためのバイトライト強制の指示を含む、実施形態２１１〜２１７の何れか１つのプロセッサ。

【0390】

２１９．前記コンフィグレーション及びコントロールビットレジスタは、ＤｖｍＳｙｎｃオペレーションの強制順序の指示を含む、実施形態２１１〜２１８の何れか１つのプロセッサ。

【0391】

２２０．前記ガスケットは、レジスタに関連したＣＡＣを含む、実施形態２０６〜２１９の何れか１つのプロセッサ。

【0392】

２２１．ＳＭＮスレーブインタフェースは、ガスケットレジスタにアクセスするために提供される、実施形態２０６〜２２０の何れか１つのプロセッサ。

【0393】

２２２．前記ＳＭＮスレーブインタフェースは、リセットの間、任意の必要なレジスタをロードするように構成されている、実施形態２２１のプロセッサ。

【0394】

２２３．前記ＳＭＮスレーブインタフェースは、ＣＡＣに関連するレジスタにパワーマネージメントアクセスを提供するように構成されている、実施形態２２１又は２２２のプロセッサ。

【0395】

２２４．前記ＳＭＮスレーブインタフェースは、チキン（ｃｈｉｃｋｅｎ）ビットへのソフトウエアアクセスを提供するように構成されている、実施形態２２１〜２２３の何れか１つのプロセッサ。

【0396】

２２５．前記ＳＭＮスレーブインタフェースは、パッケージＣＣ６状態を入力及び離れる場合に前記レジスタの内容を保存及び復元する手段を提供するように構成されている、実施形態２２１〜２２４の何れか１つのプロセッサ。

【0397】

２２６．前記ガスケットはシングルトークンプールを含み、トークンは、ＳＲＩへの要求を送るために使用される、実施形態１３１〜２２５の何れか１つのプロセッサ。

【0398】

２２７．前記ガスケットは、パワーマネージメントに関与するように構成されている、実施形態１３１〜２２６の何れか１つのプロセッサ。

【0399】

２２８．前記ガスケットは、前記プロセッサが配置されている中のクラスタによってさらに提供される種々のイベントをカウントする前記必要なＣＡＣレジスタを実行するように構成されている、実施形態２２７のプロセッサ。

【0400】

２２９．前記ガスケットは、パワーマネージメント状態の変更のために静止機能を提供するように構成されている、実施形態２２７又は２２８のプロセッサ。

【0401】

２３０．前記静止機能は、ＣＣＩリクエストをさらにブロックする、実施形態２２９のプロセッサ。

【0402】

２３１．前記ガスケットは、周波数に基づき重み付けされたサイクルカウントを保存するように構成されている、実施形態２２７〜２３１の何れか１つのプロセッサ。

【0403】

２３２．前記ＧＩＣは、パワーマネージメントインタフェースに相互作用するように構成されている、実施形態１８５〜２３１の何れか１つのプロセッサ。

【0404】

２３３．全てのインタラプトは、マイクロアーキテクチャインタラプトをサービスし、任意のアーキテクチャビジブルインタラプトをオペレーティングシステム（ＯＳ）で進めるマイクロコードによって遮られる、実施形態２３２のプロセッサ。

【0405】

２３４．前記マイクロアーキテクチャインタラプトは、ストップクロック（ＳｔｐＣｌｋ）及びスタートクロック（ＳｔａｒｔＣｌｋ）を含む、実施形態２３３のプロセッサ。

【0406】

２３５．インタラプトは、ローカルインタラプトピンを介して、又は、リモートライトによって届けられる、実施形態２３２〜２３４の何れか１つのプロセッサ。

【0407】

２３６．ＧＩＣインタラプトは、データファブリックにＡＸＩインタフェースを通して、シェアードペリフェラルインタラプト（ＳＰＩ）又はプライベートペリフェラルインタラプト（ＰＰＩ）を含むローカルインタラプトピンを介して届けられる、実施形態２３２〜２３５の何れか１つのプロセッサ。

【0408】

２３７．全てのノースブリッジマルチターゲットインタラプトタイプは、ＰＰＩとして生成され得る、実施形態２３６のプロセッサ。

【0409】

２３８．インタラプトハンドラのための追加のステータスレジスタをさらに有する、実施形態２３７のプロセッサ。

【0410】

２３９．前記ＧＩＣへのローカルＳＰＩインプットが全てフリーランニングクロックである場合に、終了をアイドルにして前記ＳＰＩインプットを再マップする、実施形態２３６のプロセッサ。

【0411】

２４０．クロッキングリクエストは、停止状態又はＨＴＣ ＳＢＣ状態の間、ＣｏｎｎｅｃＭａｓｋシグナルがデアサートのときに生成される、実施形態１〜２３９の何れか１つのプロセッサ。

【0412】

２４１．全てのコアに発するプローブがブロックされる、実施形態２４０のプロセッサ。

【0413】

２４２．全てのペンディングプローブは、完了するこれらのプローブレスポンス及び／又はデータムーブメントのために待つことによって、任意の影響したコアからドレインされる、実施形態２４１のプロセッサ。

【0414】

２４３．前記プロセッサは、ＮｂＢｕｓｙシグナルをドロップする全ての影響したコアのために待つ、実施形態２４２のプロセッサ。

【0415】

２４４．前記プロセッサは、ＮＢＳＹＮファーストインファーストアウト（ＦＩＦＯ）キューへのラウンドトリップをカバーする十分な時間で無制限に待ち、前記ＦＩＦＯキューのインフライトトラッフィクによってトリガされる新しいイベントが対象を提起する十分な時間を有する、実施形態２４３のプロセッサ。

【0416】

２４５．前記プロセッサは、ブロックし、応答され又は認識される前記ＣＡＣインタフェースのペンディングＡＰＭリクエストのために待つ、実施形態２４４のプロセッサ。

【0417】

２４６．前記プロセッサは、パワーダウンのためのヒステリシスを満たしている、実施形態２４５のプロセッサ。

【0418】

２４７．対象とされたコアへの全てのクロックゲートは、デアサートされ、それからプローブに関連するクロックゲートが再度可能になる、実施形態２４０〜２４６の何れか１つのプロセッサ。

【0419】

２４８．コア電圧は、アジャスティングパワーゲーティング（ＰＧ）ヘッダーによって減少し、フィードバック回路を介してその電圧を維持する、実施形態２４０〜２４７の何れか１つのプロセッサ。

【0420】

２４９．調整すること及び維持することは、フラッシング又はフラッシングなしで適用される、実施形態２４８のプロセッサ。

【0421】

２５０．Ｑチャネルハンドシェイクは、前記調整すること及び維持することを許可するパワーコントローラとともに使用される、実施形態２４８又は２４９のプロセッサ。

【0422】

２５１．前記Ｑチャネルハンドシェイクの完了においてローパワー状態が終了し得る、実施形態２５０のプロセッサ。

【0423】

２５２．前記Ｑチャネルハンドシェイクの完了の後にコアＣ状態コミットポイントが存在し得る、実施形態２５０又は２５１のプロセッサ。

【0424】

２５３．前記Ｑチャネルハンドシェイクは、ＣＰＵ ＬｏｗＰｗｒＲｅｑアサーションを開始される、実施形態２５２のプロセッサ。

【0425】

２５４．ＶｃｅＬｏｗＰｒｗＲｄｙは、前記コアがコミットしたことを示しているＣＰＵ ＱＡＣＣＥＰＴアサーションまでブロックされている、実施形態２５３のプロセッサ。

【0426】

２５５．ファストインタラプトリクエスト（ＦＩＱ）／インタラプトリクエスト（ＩＲＱ）エッジは、起動イベントを生成するために使用される、実施形態２４０〜２５４の何れか１つのプロセッサ。

【0427】

２５６．前記起動イベントは、ＲＣＣ３リテンションモードからの終了をトリガする、実施形態２５５のプロセッサ。

【0428】

２５７．ＲＣＣ３リテンションモードからの終了の際に全てののインタラプトが届けられる、実施形態２５６のプロセッサ。

【0429】

２５８．前記プロセッサは、受信するＤｖｍＯｐのＣＰＵ ＱＡＣＴＩＶＥをデアサートする、実施形態１〜２５７の何れか１つのプロセッサ。

【0430】

２５９．ＣＣ６フローにおいて、パワーダウンは、全てのＤＶＭターゲットのために無効として行動する、実施形態２５８のプロセッサ。

【0431】

２６０．前記プロセッサは、ＤＶＭディテクションのローパワーモードから終了するように構成されている、実施形態２５８又は２５９のプロセッサ。

【0432】

２６１．前記プロセッサは、パワーゲーティングモード（ＣＣ６モード）を使用するように構成されている、実施形態１〜２６０の何れか１つのプロセッサ。

【0433】

２６２．前記ＣＣ６モードに入るために、前記ノースブリッジは、クロックにクロッキングリクエストでパワートグルを要求する、実施形態２６１のプロセッサ。

【0434】

２６３．前記プロセッサは、キャッシュ及びコア状態がフラッシュされているとき、前記ＣＣ６モードに入ることができる、実施形態２６２のプロセッサ。

【0435】

２６４．前記ＣＣ６モードの終了の際に、状態の復元が必要とされる、実施形態２６１〜２６３の何れか１つのプロセッサ。

【0436】

２６５．前記ＧＩＣは、いくつかのモードの１つでプロセッサインタフェースにおいてＦＩＱ／ＩＲＱの動作をプログラムする、実施形態２６１〜２６４の何れか１つのプロセッサ。

【0437】

２６６．いくつかのモードの１つは、ノーマルモードを含み、前記ＧＩＣからのｎＩＲＱＣＰＵ［ｎ］／ｎＦＩＱＣＰＵ[ｎ]ピンは、全ての状況でドライブされる、実施形態２６５のプロセッサ。

【0438】

２６７．いくつかのモードの１つは、レガシーＦＩＱ／ＩＲＱピンと前記ＧＩＣインプットをオーバーライドするバイパスモードを含む、実施形態２６５のプロセッサ。

【0439】

２６８．いくつかのモードの１つは、コアにＩＲＱ／ＦＩＱピンを生成するバイパス無効モードを含み、ローパワー終了のためのタイプのインタラプトの存在でのパワーコントローラにｎＩＲＱＯＵＴ［ｎ］／ｎＦＩＱＯＵＴ［ｎ］をドライブする、実施形態２６５のプロセッサ。

【0440】

２６９．前記ＣＣ６モードの終了において、対象となるコアは、リセットがかかり、例外ベクタからコードのフェッチを開始する、実施形態２６１〜２６８の何れか１つのプロセッサ。

【0441】

２７０．前記例外ベクタは、ジャンプテーブルでのハンドラリセットを含む、実施形態２６９のプロセッサ。

【0442】

２７１．前記プロセッサは、ラストコアエンタリングＣ状態のＬ２リテンションの要求によって複雑なリテンションモード（ＲＸＣ３）が入るように構成されている、実施形態１〜２７０の何れか１つのプロセッサ。

【0443】

２７２．前記ＲＸＣ３モードは、Ｌ２スタンドバイハンドシェイクを実装することを含む、実施形態２７１のプロセッサ。

【0444】

２７３．前記Ｌ２スタンドバイハンドシェイクは、前記ＲＣＣ３モード及び前記ＣＣ６モードの何れかに入るラストコアで実行される、実施形態２７２のプロセッサ。

【0445】

２７４．前記プロセッサは、複雑なパワーゲイティングモード（ＸＣ６）に入るように構成されている、実施形態１〜２７３の何れか１つのプロセッサ。

【0446】

２７５．前記ＸＣ６モードの間、前記ガスケットはパワーオフとなる、実施形態２７４のプロセッサ。

【0447】

２７６．前記ガスケットは、全てのクレジットがノースブリッジによってリリースされるまで、前記ノースブリッジに通信できない、実施形態２７５のプロセッサ。

【0448】

２７７．前記ガスケットは、クレジットを受け入れられる用意があるときに、ＲｅｓｅｔＵｃｏｄｅＧｏをドライブする、実施形態２７５又は２７６のプロセッサ。

【0449】

２７８．モニター及びウエイトメカニズムの何れかによって生成されたフラッシュリクエストにおいて、ＳｔｐＣｌｋシグナルは、前記対象とされたコアに送られる、実施形態１〜２７７の何れか１つのプロセッサ。

【0450】

２７９．前記対象とされたコアは、前記キャッシュをフラッシュし、前記ノースブリッジにフラッシュされた状態をシグナルする適切なビットをマークする、実施形態２７８のプロセッサ。

【0451】

２８０．前記ノースブリッジは、クロックにクロッキング／パワーリクエストを生成するとき、より深いＣ状態に移行する、実施形態２７９のプロセッサ。

【0452】

２８１．ＣＰＵ ｆｒｅｑ ｒｏｕｔｉｎｅは、ディスクリートＰ状態レベルにパーフォーマンスレベルパーセンテージをマップする、実施形態１〜２８０の何れか１つのプロセッサ。

【0453】

２８２．前記ディスクリートＰ状態レベルは、前記ノースブリッジにＣｏｆＶｉｄＣｔｌを介して要求される、実施形態２８１のプロセッサ。

【0454】

２８３．インタラプトベースの静止及び非静止ルーチンが実装される、実施形態２８１又は２８２のプロセッサ。

【0455】

２８４．前記静止ルーチンは、ＳｔｐＣｌｋベース静止ルーチンを含む、実施形態２８３のプロセッサ。

【0456】

２８５．ＳｔｐＣｌｋは、セキュアインタラプトとして使用されるＦＩＱにフックされる、実施形態２８４のプロセッサ。

【0457】

２８６．トラストゾーンが実装された場合、Ｐ状態が変化し、ＳｔｐＣｌｋソースがセキュアとして登録される、実施形態２８４又は２８５のプロセッサ。

【0458】

２８７．スーパーバイザモードは、バンクされたリンクレジスタで使用するために使用され、これにより、ＦＩＱへのリエントリの２つの例を許容する、実施形態２８６のプロセッサ。

【0459】

２８８．ＦＩＱの例外ハンドラは、他の信頼されたサービスのＳｔｐＣｌｋプリエンプションをサポートするために前記スーパーバイザモードに切り替わる、実施形態の２８７プロセッサ。

【0460】

２８９．Ｐ状態ＳｔｐＣｌｋのサービスにおいて、ＨＴＣ ＳＢＣシステムマネージメントブロードキャストは、ノースブリッジに送られる、実施形態２８４〜２８８の何れか１つのプロセッサ。

【0461】

２９０．全ての未処理のトラッフィクは、データシンクロナイゼーションバリア（ＤＳＢ）命令を介して静止される、実施形態２８９のプロセッサ。

【0462】

２９１．インタラプトのための待ち（ＷＦＩ）は、信号で送られる、実施形態２９０のプロセッサ。

【0463】

２９２．前記ＷＦＩを受信する際に、前記ノースブリッジは、選択されることからブロックすることによって、前記クラスタに対するプローブを静止する、実施形態２９１のプロセッサ。

【0464】

２９３．前記ノースブリッジは、既に選択されたプローブの前記ノースブリッジのパイプラインに自由にドレインする、実施形態２９２のプロセッサ。

【0465】

２９４．ノースブリッジは、クラスタが未処理のプローブを完了するようにそれらのバッファを解除する当該未処理のプローブのために待つ、実施形態２９３のプロセッサ。

【0466】

２９５．前記プローブがドレインされて、前記ノースブリッジが、前記Ｐ状態変化をスケジュールする前に前記クラスタとともにＡＣＩＮＡＣＴＭ／ＳＴＡＮＤＢＹＷＦＩＬ２ハンドシェイクを実行する、実施形態２９３又は２９４のプロセッサ。

【0467】

２９６．クラスタがＰ状態変化の間、前記クラスタは、インタラプトを取らなくてもよく、ステムリクエストをしなくてもよい、実施形態２８１〜２９５の何れか１つのプロセッサ。

【0468】

２９７．インタラプトエッジは、前記ノースブリッジによってマスクされる、実施形態２９６のプロセッサ。

【0469】

２９８．前記Ｐ状態変化が完了すると、前記ノースブリッジは、静止からコアを起動する、実施形態２９６又は２９７のプロセッサ。

【0470】

２９９．前記ノースブリッジは、ＳｔａｒｔＣｌｋを介してコアを起動する、実施形態２９８のプロセッサ。

【0471】

３００．前記ＳｔａｒｔＣｌｋは、最も高いＦＩＱプライオリティを有する、実施形態２９９のプロセッサ。

【0472】

３０１．前記ノースブリッジは、イベント（ＷＦＥ）のために待ちを介して前記コアを起動する、実施形態２９８のプロセッサ。

【0473】

３０２．前記ＷＦＥは、インタラプト又はＥＶＥＮＴＩピンを介したイベントからトリガされる、実施形態３０１のプロセッサ。

【0474】

３０３．前記コアがＷＦＥから終了するとき、インタラプト及び終了のアンマスクする前記ＳｔｐＣｌｋハンドラの中に存在する、実施形態３０１又は３０２のプロセッサ。

【0475】

３０４．前記ガスケットは前記静止を実装する、実施形態２８１〜３０３のプロセッサ。

【0476】

３０５．前記クラスタと前記ガスケットとの間の前記ＡＣＥインタフェースが動作を継続し、ＮＢＳＹＮの何れかの端部の前記ＣＣＩインタフェースが静止される、実施形態３０４のプロセッサ。

【0477】

３０６．前記ガスケットは、新しいリクエストをブロックし、未処理の応答を待つ、実施形態３０４又は３０５のプロセッサ。

【0478】

３０７．Ｐ状態変化リクエストにおいて、前記ノースブリッジは、静止するサイドバンドを通して前記ガスケットに通知する、実施形態３０４〜３０６の何れか１つのプロセッサ。

【0479】

３０８．前記ガスケットは、前記ノースブリッジに送られることからノンライトバックリクエストをブロックし、全ての未処理のライトバックをドレインする、実施形態３０７のプロセッサ。

【0480】

３０９．前記ガスケットは、全ての未処理のライトバックがドレインされたとき、静止されたレスポンスをノースブリッジに信号で送る、実施形態３０８のプロセッサ。

【0481】

３１０．前記ノースブリッジは、選択されてからの新しいプローブをブロックし、完成する未処理のプローブのために待つ、実施形態３０９のプロセッサ。

【0482】

３１１．前記ガスケットは、プローブが前記ノースブリッジから未処理でないときのみ、ライトバックをブロックする、実施形態３１０のプロセッサ。

【0483】

３１２．前記ガスケットは、前記ノースブリッジにペンディングのライトバックがある限り、ＮｂＢｕｓｙを起動する、実施形態３１１のプロセッサ。

【0484】

３１３．全てのプローブバッファが返され、前記ガスケットがＮｂＢｕｓｙアサートでないときのみ、Ｐ状態変化を開始することを許される、実施形態３１２のプロセッサ。

【0485】

３１４．前記非静止は、前記静止リクエストを活動していない前記ノースブリッジによって実行され、前記ガスケットは、前記静止されたレスポンスを取り除くことによって応答する、実施形態３０４〜３１３の何れか１つのプロセッサ。

【0486】

３１５．前記ノースブリッジは、前記リクエストが新しいリクエストの開始の前に以前のハンドシェイクからデアサートされたことを保証する、実施形態３１４のプロセッサ。

【0487】

多くのバリエーションが、ここで開示されていることに基づいて可能であることを理解すべきである。特徴と要素は、特に組合せにより上述されているが、各々の特徴と要素は、他の特徴と要素なしに単独で、又は、他の特徴と要素の有無に関わらない様々な組合せで使用されてもよい。

【0488】

提供される方法は、多目的コンピュータ、プロセッサ又はプロセッサコアで実装されてもよい。適切なプロセッサは、例として、汎用プロセッサ、特別な目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連した１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他のタイプのいかなる集積回路（ＩＣ）、及び／又は、状態マシンを含む。このようなプロセッサは、処理されたハードウェア説明言語（ＨＤＬ）命令の結果、及び、ネットリスト（コンピュータ可読媒体に記憶され得る命令）を含む他の中間的なデータを用いた製造プロセスで構成することによって製造されてもよい。そのような処理の結果は、実施形態の範囲を実施するプロセッサを製造するための半導体製造プロセスで使われるマスクワークであってもよい。

【0489】

ここで提供されている方法又はフローチャートは、多目的コンピュータ又はプロセッサによる実行のための非一時的なコンピュータ可読記憶媒体に取り入れられるコンピュータープログラム、ソフトウェア又はファームウェアで実施されてもよい。非一時的なコンピュータ可読記憶媒体の例は、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体記憶装置、磁気媒体内蔵ハードディスク及びリムーバブルディスク等の磁気媒体、磁気光学メディア、並びに、ＣＤ−ＲＯＭディスク及びデジタル多用途ディスク（ＤＶＤ）等の光学媒体を含む。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】