いくつかのコンピュータ・プロセッサは、複数の処理エンジンまたは「コア」を含むことがある。いくつかの例では、処理エンジンは、処理負荷に基づく異なる電圧レベルおよび/または動作周波数(「クロック周波数」とも称する)で動作できることがある。いくつかの例では、プロセッサは、悪意のあるアプリケーション(たとえば、電力ウィルス)または他の電力消費アプリケーションによって引き起こされる電力スパイクから保護されることがある。たとえば、電力スパイクが検出されると、プロセッサ(または処理エンジン)は、供給電圧および/または動作周波数を低減することによってスロットリングされてもよい。しかしながら、いくつかのスロットリング機構は、実際にはスロットリングを必要としない状況でトリガーされることがあり、よって、プロセッサのパフォーマンスに不必要な影響を与える可能性がある。
一つまたは複数の実施形態では、プロセッサは、スロットリング機構の過去の挙動に基づいてスロットリングを動的に調整するスロットリング論理を含んでいてもよい。いくつかの実施形態では、スロットリング論理は、実行イベントの推定されるエネルギー消費を反映するスコアを生成してもよい。スロットリング論理は、生成されたスコアがスロットリング閾値を超えることを判定してもよく、それに応じて、処理エンジンの動作周波数をスロットリングしてもよい。いくつかの実施形態では、スロットリング論理は、スロットリング・イベントの数に基づいて閾値を動的に調整する。このようにして、閾値は、いくつかの状況においてスロットリングを低減するように動的に調節されうる。よって、スロットリング論理は、スロットリングに起因する不必要なパフォーマンスへの影響を低減しうる。いくつかの実施形態のさまざまな詳細が、図26~図31を参照して、下記でさらに説明される。さらに、図1~図25を参照して、例示的なシステムおよびアーキテクチャが下記で説明される。
例示的なシステムおよびアーキテクチャ
以下の実施形態は、具体的な実施形態を参照して説明されるが、実施形態は、これに関して限定されない。特に、本明細書に記載される実施形態の同様の技法および教示は、他のタイプの回路、半導体デバイス、プロセッサ、システムなどに適用されうることが考えられている。たとえば、開示された実施形態は、サーバーコンピュータ(たとえば、タワー、ラック、ブレード、マイクロサーバーなど)、通信システム、記憶システム、任意の構成のデスクトップコンピュータ、ラップトップ、ノートブック、およびタブレットコンピュータ(2:1タブレット、ファブレットなどを含む)を含む任意のタイプのコンピュータ・システムにおいて実装されうる。
さらに、開示される実施形態は、ハンドヘルド機器、システムオンチップ(SoC)、および埋め込みアプリケーションなどの他のデバイスにおいても使用できる。ハンドヘルド機器のいくつかの例は、スマートフォンなどの携帯電話、インターネットプロトコル機器、デジタルカメラ、携帯情報端末(PDA)、ハンドヘルドPCを含む。埋め込みアプリケーションは、典型的には、マイクロコントローラ、デジタル信号プロセッサ(DSP)、ネットワークコンピュータ、セットトップボックス、ネットワーク・ハブ、ワイドエリアネットワーク(WAN)スイッチ、ウェアラブルデバイス、または以下に教示する機能および動作を実行することができる他の任意のシステムを含むことができる。さらに、実施形態は、携帯電話、スマートフォンおよびファブレットのような標準的な音声機能を有する移動端末において、および/または、多くのウェアラブル、タブレット、ノートブック、デスクトップ、マイクロサーバー、サーバーなどのような標準的な無線音声機能通信能力をもたない非移動端末において実装されてもよい。
ここで図1を参照すると、本発明のある実施形態によるシステムの一部のブロック図が示されている。図1に示されるように、システム100は、図示のようにマルチコアプロセッサであるプロセッサ110を含むさまざまなコンポーネントを含むことができる。プロセッサ110は、外部電圧レギュレータ160を介して電源150に結合されてもよく、外部電圧レギュレータ160は、第1電圧変換を実行して、一次調整電圧Vregをプロセッサ110に提供することができる。
見て取れるように、プロセッサ110は、複数のコア120a~120nを含む単一ダイプロセッサであってもよい。さらに、各コアは、一次調整電圧を受信し、IVRと関連する当該プロセッサの一つまたは複数のエージェントに提供される動作電圧を生成する統合電圧レギュレータ(integrated voltage regulator、IVR)125a~125nと関連付けられてもよい。よって、それぞれの個々のコアの電圧、よって電力およびパフォーマンスの細かい粒度の制御を可能にするために、IVR実装が提供されてもよい。よって、各コアは、独立した電圧および周波数で動作することができ、大きな柔軟性を可能にするとともに、電力消費をパフォーマンスとバランスさせるための幅広い機会を提供する。いくつかの実施形態では、複数のIVRを使用することにより、構成要素を別々の電力プレーンにグループ化することができ、それにより、電力はIVRによって制御され、グループ内の構成要素のみに供給される。電力管理中、プロセッサがある低電力状態に置かれるとき、あるIVRの所与の電力プレーンは、パワーダウンされるか、または電源を切られることができ、一方、別のIVRの別の電力プレーンはアクティブのままであるか、または完全に電力供給される。同様に、コア120は、各コア120の動作周波数を独立して制御するために、一つまたは複数の位相ロックループ(PLL)のような独立したクロック発生回路を含むか、それに付随してもよい。
引き続き図1を参照すると、入出力インターフェース(IF)132、別のインターフェース134、および統合メモリ・コントローラ(integrated memory controller、IMC)136を含む追加の構成要素がプロセッサ内に存在してもよい。見て取れるように、これらの構成要素のそれぞれは、別の統合電圧レギュレータ125xによって電力供給されてもよい。ある実施形態では、インターフェース132は、インテル(登録商標)クイックパスインターコネクト(Quick Path Interconnect、QPI)相互接続のための動作を可能にすることができ、これは、物理層、リンク層、およびプロトコル層を含む複数の層を含むキャッシュ・コヒーレント・プロトコル内のポイントツーポイント(PtP)・リンクを提供する。次に、インターフェース134は、周辺コンポーネント相互接続エクスプレス(PCIe(商標))プロトコルを介して通信することができる。
また、電力制御ユニット(power control unit、PCU)138が示されており、これは、プロセッサ110に関する電力管理動作を実行するためのハードウェア、ソフトウェアおよび/またはファームウェアを含んでいてもよい。見て取れるように、PCU 138は、デジタルインターフェース162を介して外部電圧レギュレータ160に制御情報を提供し、電圧レギュレータに、適切な調整された電圧を生成させる。PCU 138はまた、別のデジタルインターフェース163を介してIVR 125に制御情報を提供し、生成された動作電圧を制御する(または、低電力モードにおいて対応するIVRを無効にする)。さまざまな実施形態では、PCU 138は、ハードウェアベースの電力管理を実行するために、多様な電力管理論理ユニットを含んでいてもよい。そのような電力管理は、完全にプロセッサ制御されてもよく(たとえば、さまざまなプロセッサ・ハードウェアによって;それは、作業負荷および/または電力、熱または他のプロセッサ制約条件によってトリガーされてもよい)、および/または電力管理は、外部ソース(たとえば、プラットフォームまたは電力管理ソースまたはシステムソフトウェア)に応答して実行されてもよい。
図1において、PCU 138は、プロセッサの別個の論理として存在するものとして示されている。他の場合には、PCU 138は、コア120の所与の一つまたは複数の上で実行されてもよい。いくつかの場合には、PCU 138は、マイクロコントローラ(専用または汎用)またはそれ自身の専用の電力管理コード(Pコードと呼ばれることもある)を実行するように構成された他の制御論理として実装されてもよい。さらに他の実施形態では、PCU 138によって実行されるべき電力管理動作は、プロセッサにとって外部で、たとえば別個の電力管理集積回路(power management integrated circuit、PMIC)またはプロセッサにとって外部の別の構成要素などによって、実装されてもよい。さらに他の実施形態では、PCU 138によって実行されるべき電力管理動作は、BIOSまたは他のシステムソフトウェア内で実装されてもよい。
実施形態は、複数のコアのそれぞれが独立した電圧および周波数点で動作することができるマルチコアプロセッサに特に好適でありうる。本明細書で使用されるところでは、用語「ドメイン」は、同じ電圧および周波数点で動作するハードウェアおよび/または論理の集まりを意味するために使用される。さらに、マルチコアプロセッサは、固定機能ユニット、グラフィックス・エンジンなどの他の非コア処理エンジンをさらに含むことができる。そのようなプロセッサは、コア以外の独立したドメイン、たとえば、グラフィックス・エンジンに関連する一つまたは複数のドメイン(本明細書ではグラフィックス・ドメインと称される)、および本明細書でシステム・エージェントと称される非コア回路に関連する一つまたは複数のドメインを含むことができる。マルチドメイン・プロセッサの多くの実装は、単一の半導体ダイ上に形成できるが、他の実装は、単一パッケージの異なる半導体ダイ上に異なるドメインが存在することができるマルチチップ・パッケージによって実現できる。
図示の簡単のために示されていないが、非コア論理および他の構成要素、たとえば内部メモリ、たとえばキャッシュメモリ階層の一つまたは複数のレベルなどの追加的な構成要素が、プロセッサ110内に存在してもよいことを理解されたい。さらに、図1の実装では統合電圧レギュレータとともに示されているが、実施形態はそれに限定されない。たとえば、他の調整された電圧が、外部電圧レギュレータ160、または調整された電圧の一つまたは複数の追加的な外部ソースから、オンチップ・リソースに提供されてもよい。
本明細書に記載される電力管理技術は、オペレーティングシステム(OS)ベースの電力管理(operating system(OS)-based power management、OSPM)機構とは独立であり、かつ、それと相補的でありうることに留意されたい。ある例示的なOSPM技法によれば、プロセッサは、さまざまなパフォーマンス状態またはレベル、いわゆるP状態、すなわちP0ないしPNで動作することができる。一般に、P1のパフォーマンス状態は、OSが要求できる最高の保証されたパフォーマンス状態に対応しうる。このP1の状態に加えて、OSはさらに、より高いパフォーマンス状態、すなわちP0の状態を要求することができる。よって、このP0状態は、電力および/または熱予算が利用可能であるときに、プロセッサ・ハードウェアが、保証されるよりも高い周波数で動作するようプロセッサまたはその少なくとも一部を構成することができる、日和見的(opportunistic)、オーバークロック(overclocking)、またはターボ・モード状態であってもよい。多くの実装において、プロセッサは、製造中に融合された(fused)かまたは他の仕方でそのプロセッサに書き込まれたその特定のプロセッサの最大ピーク周波数まで超える、P1保証最大周波数より上の複数のいわゆるビン周波数を含むことができる。さらに、あるOSPM機構によれば、プロセッサは、さまざまな電力状態またはレベルで動作することができる。電力状態に関して、OSPM機構は、一般にC0、C1~Cn状態というC状態と呼ばれる種々の電力消費状態を指定することができる。コアがアクティブであるときは、コアはC0状態で動作し、コアがアイドルであるときは、コアは、コア非ゼロC状態(たとえば、C1~C6状態)とも呼ばれるコア低電力状態にされてもよく、各C状態は、より低い電力消費レベルにある(ここで、C6がC1より深い低電力状態、などとなる)。
種々の実施形態において、多くの異なるタイプの電力管理技術が、個別にまたは組み合わせて使用されうることを理解されたい。代表的な例として、電力コントローラは、何らかの形態の動的電圧周波数スケーリング(dynamic voltage frequency scaling、DVFS)によって電力管理されるようにプロセッサを制御してもよい。DVFSでは、一つまたは複数のコアまたは他のプロセッサ論理の動作電圧および/または動作周波数が、ある種の状況において電力消費を低減するように動的に制御されうる。一例では、DVFSは、最低消費電力レベルで最適なパフォーマンスを提供するために、米国カリフォルニア州サンタクララのインテル社から入手可能なEnhanced Intel SpeedStep(商標)技術を用いて実行されてもよい。別の例では、DVFSは、一つまたは複数のコアまたは他の計算エンジンが、条件(たとえば、作業負荷および利用可能性)に基づいて、保証された動作周波数よりも高い周波数で動作することを可能にするIntel TurboBoost(商標)技術を用いて実行されてもよい。
ある種の例で使用されうる別の電力管理技術は、異なる計算エンジン間の作業負荷の動的スワッピングである。たとえば、プロセッサは、異なる電力消費レベルで動作する非対称なコアまたは他の処理エンジンを含むことができ、そのため、電力が制約されている状況においては、一つまたは複数の作業負荷を、より低い電力のコアまたは他の計算エンジン上で実行されるように動的に切り換えることができる。別の例示的な電力管理技術は、ハードウェア・デューティーサイクル法(hardware duty cycling、HDC)である。これは、コアおよび/または他の計算エンジンが、デューティーサイクルに従って周期的に有効化され、無効化されるようにしてもよい。それにより、一つまたは複数のコアは、デューティーサイクルの非アクティブ期間中には非アクティブに、デューティーサイクルのアクティブ期間中にはアクティブにされてもよい。
電力管理技術は、動作環境に制約条件が存在する場合にも使用されうる。たとえば、電力および/または熱的制約条件に遭遇した場合、動作周波数および/または電圧を低減することによって電力を低減することができる。他の電力管理技術には、命令実行レートをスロットリングすること、または命令のスケジューリングを制限することを含む。さらに、所与の命令セットアーキテクチャの命令が、電力管理動作に関する明示的または暗黙的なディレクション(direction)を含むことが可能である。これらの具体例を用いて説明したが、多くの他の電力管理技術が具体的な実施形態において使用されうることを理解されたい。
実施形態は、サーバー・プロセッサ、デスクトップ・プロセッサ、モバイル・プロセッサなどを含むさまざまな市場のためのプロセッサにおいて実装されることができる。ここで図2を参照すると、本発明のある実施形態によるプロセッサのブロック図が示されている。図2に示されるように、プロセッサ200は、複数のコア210a~210nを含むマルチコアプロセッサであってもよい。ある実施形態では、そのような各コアは、独立した電力ドメインのものであってもよく、作業負荷に基づいて、アクティブ状態および/または最大パフォーマンス状態に出入りするように構成できる。一つまたは複数のコア210は、他のコアに対して不均質であってもよく、たとえば、異なるマイクロアーキテクチャ、命令セットアーキテクチャ、パイプライン深さ、電力およびパフォーマンス能力を有してもよい。さまざまなコアは、相互接続215を介して、さまざまな構成要素を含むシステム・エージェント220に結合されてもよい。見て取れるように、システム・エージェント220は、最終レベル・キャッシュであってもよい共有キャッシュ230を含んでいてもよい。加えて、システム・エージェントは、たとえばメモリバスを介して、システムメモリ(図2には示されていない)と通信するための統合メモリ・コントローラ240を含んでいてもよい。システム・エージェント220は、さまざまなインターフェース250および電力制御ユニット255をも含み、これらは、本明細書に記載される電力管理技術を実行するための論理を含んでいてもよい。
さらに、インターフェース250a~250nによって、周辺装置、大容量記憶装置などのさまざまなオフチップ構成要素への接続を行うことができる。図2の実施形態では、この特定の実装で示されているが、本発明の範囲は、この点に関して限定されない。
ここで図3を参照すると、本発明の別の実施形態によるマルチドメイン・プロセッサのブロック図が示されている。図3の実施形態に示されるように、プロセッサ300は、複数のドメインを含む。具体的には、コア・ドメイン310は、複数のコア310a~310nを含むことができ、グラフィックス・ドメイン320は、一つまたは複数のグラフィックス・エンジンを含むことができ、システム・エージェント・ドメイン350がさらに存在していてもよい。いくつかの実施形態では、システム・エージェント・ドメイン350は、コア・ドメインとは独立した周波数で実行されてもよく、電力制御イベントおよび電力管理を扱うために常時電力オンのままであってもよい。それにより、ドメイン310および320が動的に高電力状態および低電力状態に出入りするように制御されることができる。ドメイン310および320のそれぞれは、異なる電圧および/または電力で動作することができる。3つのドメインのみをもつように示されているが、本発明の範囲はこの点で限定されず、他の実施形態ではさらなるドメインが存在しうることに留意されたい。たとえば、少なくとも1つのコアをそれぞれ含む複数のコア・ドメインが存在してもよい。
一般に、コア310a~310nのそれぞれは、さまざまな実行ユニットおよび追加的な処理要素に加えて、低レベル・キャッシュをさらに含んでいてもよい。また、さまざまなコアは、互いに、および最終レベル・キャッシュ(LLC)の複数のユニット340a~340nで形成される共有キャッシュメモリに結合されてもよい。さまざまな実施形態では、LLC 340は、コアおよびグラフィックス・エンジンならびにさまざまなメディア処理回路の間で共有されてもよい。見て取れるように、リング相互接続330は、コアを一緒に結合し、コア、グラフィックス・ドメイン320、およびシステム・エージェント・ドメイン350の間の相互接続を提供する。ある実施形態では、相互接続330は、コア・ドメインの一部であってもよい。しかしながら、他の実施形態では、リング相互接続は、それ自身のドメインであってもよい。
さらに見て取れるように、システム・エージェント・ドメイン350は、関連するディスプレイの制御および該ディスプレイへのインターフェースを提供することができるディスプレイ・コントローラ352を含んでいてもよい。さらに見て取れるように、システム・エージェント・ドメイン350は、本明細書に記載される電力管理技術を実行するための論理を含むことができる電力制御ユニット355を含んでいてもよい。
図3にさらに示されるように、プロセッサ300は、ダイナミックランダムアクセスメモリ(DRAM)のようなシステムメモリへのインターフェースを提供することができる統合メモリ・コントローラ(IMC)370をさらに含むことができる。プロセッサと他の回路との間の相互接続を可能にするために、複数のインターフェース380a~380nが存在してもよい。たとえば、ある実施形態では、少なくとも1つの直接メディアインターフェース(direct media interface、DMI)インターフェース、ならびに一つまたは複数のPCIe(商標)インターフェースが設けられてもよい。さらに、追加的なプロセッサまたは他の回路のような他のエージェント間の通信を提供するために、一つまたは複数のQPIインターフェースが提供されてもよい。図3の実施形態ではこの高いレベルで示されているが、本発明の範囲は、この点に関して限定されないことを理解されたい。
図4を参照すると、複数のコアを含むプロセッサのある実施形態が示されている。プロセッサ400は、マイクロプロセッサ、埋め込みプロセッサ、デジタル信号プロセッサ(DSP)、ネットワークプロセッサ、ハンドヘルドプロセッサ、アプリケーション・プロセッサ、コプロセッサ、システムオンチップ(SoC)、またはコードを実行する他のデバイスなどの任意のプロセッサまたは処理装置を含む。プロセッサ400は、ある実施形態では、非対称なコアまたは対称なコア(図示した実施形態)を含んでいてもよい、少なくとも2つのコア、すなわちコア401および402を含む。しかしながら、プロセッサ400は、対称または非対称でありうる任意の数の処理要素を含んでいてもよい。
ある実施形態では、処理要素は、ソフトウェア・スレッドをサポートするためのハードウェアまたは論理を指す。ハードウェア処理要素の例は、スレッド・ユニット、スレッド・スロット、スレッド、プロセスユニット、コンテキスト、コンテキストユニット、論理プロセッサ、ハードウェア・スレッド、コア、および/または実行状態またはアーキテクチャ状態のようなプロセッサについての状態を保持することができる任意の他の要素を含む。言い換えると、ある実施形態では、処理要素は、ソフトウェア・スレッド、オペレーティングシステム、アプリケーション、または他のコードのような、コードと独立して関連付けられることができる任意のハードウェアを指す。物理プロセッサは、典型的には、集積回路を指し、これは、潜在的に、コアまたはハードウェア・スレッドなどの任意の数の他の処理要素を含む。
コアは、しばしば、独立したアーキテクチャ状態を維持することができる集積回路上に位置する論理であって、独立して維持される各アーキテクチャ状態が少なくともいくつかの専用の実行リソースと関連付けられるものを参照する。コアとは対照的に、ハードウェア・スレッドは、典型的には、独立したアーキテクチャ状態を維持することができる集積回路上に位置する任意の論理であって、それらの独立して維持されるアーキテクチャ状態は、実行リソースへのアクセスを共有するものを参照する。見て取れるように、ある種のリソースが共有され、他のリソースがあるアーキテクチャ状態専用である場合、ハードウェア・スレッドとコアの名称の間の境界線は重なり合う。だが、しばしば、コアおよびハードウェア・スレッドは、オペレーティングシステムによって、個々の論理プロセッサとして見なされ、ここで、オペレーティングシステムは、それぞれの論理プロセッサ上で個々に動作をスケジューリングすることができる。
物理的なプロセッサ400は、図4に示されるように、2つのコア、すなわちコア401およびコア402を含む。ここで、コア401および402は、対称なコア、すなわち、同じ構成、機能ユニット、および/または論理を有するコアと考えられる。別の実施形態では、コア401は順序外のプロセッサ・コアを含み、コア402は順序内のプロセッサ・コアを含む。しかしながら、コア401および402は、ネイティブコア、ソフトウェア管理コア、ネイティブ命令セットアーキテクチャ(ISA)を実行するように適応されたコア、変換されたISAを実行するように適応されたコア、共設計コア(co-designed core)、または他の既知のコアなど、任意のタイプのコアから個別に選択されうる。だが、議論をさらに進めるために、コア401内に示される機能ユニットが、以下でさらに詳細に説明される。コア402内のユニットは同様の仕方で動作する。
図示されるように、コア401は、2つのアーキテクチャ状態レジスタ401aおよび401bを含み、これらは、2つのハードウェア・スレッド(ハードウェア・スレッド・スロットとも称される)に関連付けられてもよい。したがって、ある実施形態では、オペレーティングシステムなどのソフトウェア・エンティティは、プロセッサ400を4つの別個のプロセッサ、すなわち、4つのソフトウェア・スレッドを同時並行して実行することができる4つの論理プロセッサまたは処理要素として見なす可能性がある。上述のように、第1のスレッドはアーキテクチャ状態レジスタ401aに関連し、第2のスレッドはアーキテクチャ状態レジスタ401bに関連し、第3のスレッドはアーキテクチャ状態レジスタ402aに関連してもよく、第4のスレッドはアーキテクチャ状態レジスタ402bに関連してもよい。ここで、アーキテクチャ状態レジスタ(401a、401b、402a、および402b)は、上述のように、処理要素、スレッド・スロット、またはスレッド・ユニットに関連付けられてもよい。図示したように、アーキテクチャ状態レジスタ401aは、アーキテクチャ状態レジスタ401bにおいて複製されるので、論理プロセッサ401aおよび論理プロセッサ401bのために個々のアーキテクチャ状態/コンテキストが記憶されることができる。コア401では、アロケータおよびリネーマ・ブロック430における命令ポインタおよびリネーム論理のような他のより小さいリソースも、スレッド401aおよび401bのために複製されてもよい。並べ替え/リタイア・ユニット435内の並べ替えバッファ、分岐ターゲットバッファおよび命令トランスレーションルックアサイドバッファ(BTBおよびI-TLB)420、ロード/ストア・バッファ、およびキューのようないくつかのリソースは、パーティション分割によって共有されてもよい。汎用内部レジスタ、ページテーブル・ベース・レジスタ、低レベル・データ・キャッシュおよびデータTLB 450、実行ユニット440、および並べ替え/リアイア・ユニット435の一部などの他のリソースは、完全に共有される可能性がある。
プロセッサ400はしばしば、完全に共有されるか、パーティション分割を通じて共有されるか、または処理エレメントによって/に対して専用されうる他のリソースを含む。図4では、プロセッサの例示的な論理ユニット/リソースを有する純粋に例示的なプロセッサの実施形態が示されている。プロセッサは、これらの機能ユニットの任意のものを含んでいてもよく、または省略してもよく、また、図示されていない任意の他の既知の機能ユニット、論理、またはファームウェアを含んでいてもよいことに留意されたい。図示のように、コア401は、単純化された代表的な順序外(out-of-order、OOO)プロセッサ・コアを含む。しかし、異なる実施形態では、順序内プロセッサが利用されてもよい。
コア401はさらに、フェッチされた要素をデコードするための、フェッチ・ユニットに結合されたデコード・モジュール425を含む。ある実施形態では、フェッチ論理は、スレッド・スロット401a、401bにそれぞれ関連付けられた個々のシーケンサを含む。通例、コア401は、プロセッサ400上で実行可能な命令を定義/指定する第1のISAと関連付けられる。しばしば、第1のISAの一部であるマシンコード命令が、実行されるべき命令または動作を参照/指定する命令の一部(オペコードと呼ばれる)を含む。デコード・モジュール425は、これらの命令を、それらのオペコードから認識し、デコードされた命令を、第1のISAによって定義される処理のために、パイプライン内で次に渡す回路を含む。たとえば、ある実施形態では、デコーダ・モジュール425は、トランザクション命令などの特定の命令を認識するように設計または適応された論理を含む。デコーダ・モジュール425による認識の結果、アーキテクチャまたはコア401は、適切な命令に関連するタスクを実行するために、特定のあらかじめ定義されたアクションを行う。ここに記載されるタスク、ブロック、動作、および方法のいずれも、単一または複数の命令に応答して実行されてもよく、そのうちのいくつかは、新規のまたは旧来の命令であってもよいことに留意することが重要である。
一例では、アロケータおよびリネーマ・ブロック430は、命令処理結果を記憶するためのレジスタ・ファイルのようなリソースを予約するためのアロケータを含む。しかしながら、スレッド401aおよび401bは、順序外実行が可能である可能性があり、その場合、アロケータおよびリネーマ・ブロック430は、命令結果を追跡するための並べ替えバッファのような他のリソースも予約する。リネーマ・ブロック430はまた、プログラム/命令参照レジスタをプロセッサ400内部の他のレジスタにリネーム〔名称変更〕するためのレジスタ・リネーマを含んでいてもよい。並べ替え/リアイア・ユニット435は、順序外実行および順序外で実行された命令の後の順序内のリタイアをサポートするために、上述の並べ替えバッファ、ロード・バッファ、およびストア・バッファなどの構成要素を含む。
スケジューラおよび実行ユニット(単数または複数)ブロック440は、ある実施形態では、実行ユニット上で命令/動作をスケジュールするスケジューラ・ユニットを含む。たとえば、浮動小数点命令は、利用可能な浮動小数点実行ユニットを有する実行ユニットのポート上でスケジュールされる。また、実行ユニットに関連付けられたレジスタ・ファイルも、情報命令処理結果を格納するために含められる。例示的な実行ユニットは、浮動小数点実行ユニット、整数実行ユニット、ジャンプ実行ユニット、ロード実行ユニット、ストア実行ユニット、および他の既知の実行ユニットを含む。
より低レベルのデータ・キャッシュおよびデータ・トランスレーションルックアサイドバッファ(D-TLB)450が実行ユニット(単数または複数)440に結合される。データ・キャッシュは、メモリ・コヒーレンス状態に保持される可能性のあるデータ・オペランドのような、最近使用された/操作された要素を格納する。D-TLBは、最近の仮想/線形から物理アドレス変換を記憶する。個別的な例として、プロセッサは、物理メモリを複数の仮想ページに分割するページテーブル構造を含んでいてもよい。
ここで、コア401および402は、最近フェッチされた要素をキャッシュするための、より高いレベルの、またはより外側のキャッシュ410へのアクセスを共有する。より高いレベルまたはより外側とは、キャッシュ・レベルが増大することまたは実行ユニット(単数また複数)からより遠く離れることをいう。ある実施形態では、より高いレベルのキャッシュ410は、最終レベルのデータ・キャッシュ、すなわちプロセッサ400上のメモリ階層内の最後のキャッシュであり、たとえば、第2レベルまたは第3レベルのデータ・キャッシュである。しかしながら、より高いレベルのキャッシュ410は、命令キャッシュと関連しうる、または命令キャッシュを含むので、それに限定されない。最近デコードされたトレースを記憶するために、トレースキャッシュ、すなわち命令キャッシュのあるタイプが、代わりに、デコーダ・モジュール425の後に結合されてもよい。
図示された構成では、プロセッサ400は、本発明のある実施形態に従って電力管理を実行しうるバス・インターフェース405および電力制御ユニット460をも含む。このシナリオでは、バス・インターフェース405は、システムメモリおよび他の構成要素のような、プロセッサ400の外部の装置と通信する。
メモリ・コントローラ470が、一つまたは多数のメモリなどの他のデバイスとインターフェースすることができる。一例では、バス・インターフェース405は、メモリとインターフェースするためのメモリ・コントローラおよびグラフィックス・プロセッサとインターフェースするためのグラフィックスコントローラとのリング相互接続を含む。SoC環境では、ネットワークインターフェース、コプロセッサ、メモリ、グラフィックス・プロセッサ、および任意の他の既知のコンピュータ装置/インターフェースのような、さらに多くの装置が、単一のダイまたは集積回路上に統合されて、高い機能性および低い消費電力とともに小さな形状因子を提供してもよい。
ここで、図5を参照すると、本発明のある実施形態によるプロセッサ・コアのマイクロアーキテクチャのブロック図が示されている。図5に示されるように、プロセッサ・コア500は、多段パイプラインにされた順序外れプロセッサであってもよい。コア500は、統合された電圧レギュレータまたは外部の電圧レギュレータから受領されうる、受領された動作電圧に基づいてさまざまな電圧で動作することができる。
図5に示されるように、コア500は、フロントエンド・ユニット510を含み、これは、実行される命令をフェッチし、該命令を、プロセッサ・パイプラインにおける後の使用のために準備するために使用されうる。たとえば、フロントエンド・ユニット510は、フェッチ・ユニット501、命令キャッシュ503、および命令デコーダ505を含んでいてもよい。いくつかの実装では、フロントエンド・ユニット510は、マイクロコード記憶およびマイクロ演算記憶とともに、トレースキャッシュをさらに含んでいてもよい。フェッチ・ユニット501は、たとえばメモリまたは命令キャッシュ503からマクロ命令をフェッチし、それらをプリミティブ、すなわちプロセッサによる実行のためのマイクロ演算にデコードするために、それらを命令デコーダ505に提供してもよい。
フロントエンド・ユニット510と実行ユニット520との間には、マイクロ命令を受け取り、それらを実行のために準備するために使用されうる順序外(OOO)エンジン515が結合される。より具体的には、OOOエンジン515は、マイクロ命令フローを並べ替え、実行に必要なさまざまなリソースを割り当てるために、また、論理レジスタの、レジスタ・ファイル530および拡張レジスタ・ファイル535などのさまざまなレジスタ・ファイル内の記憶位置への名称変更を提供するために、さまざまなバッファを含んでいてもよい。レジスタ・ファイル530は、整数および浮動小数点演算のための別々のレジスタ・ファイルを含んでいてもよい。構成、制御、および追加的な動作の目的のために、一組の機械固有レジスタ(machine specific registers、MSR)538が存在し、コア500内(およびコアの外部)のさまざまな論理にとってアクセス可能であってもよい。
実行ユニット520内にはさまざまなリソースが存在してもよく、それはたとえば、他にもある特化したハードウェアの中でも、さまざまな整数、浮動小数点、および単一命令複数データ(SIMD)論理ユニットを含む。たとえば、そのような実行ユニットは、他にもある実行ユニットの中でも、一つまたは複数の算術論理ユニット(ALU)522および一つまたは複数のベクトル実行ユニット524を含んでいてもよい。
実行ユニットからの結果は、リタイア論理、すなわち並べ替えバッファ(reorder buffer、ROB)540に提供されてもよい。より具体的には、ROB 540は、実行される命令に関連する情報を受領するためのさまざまなアレイおよび論理を含んでいてもよい。次いで、この情報は、ROB 540によって検査され、命令が有効にリタイアさせられ、結果データがプロセッサのアーキテクチャ状態にコミットされることができるかどうか、または命令の適正なリアイアを妨げる一つまたは複数の例外が発生したかどうかを判定する。むろん、ROB 540は、リアイアに関連する他の動作を取り扱うことができる。
図5に示されるように、ROB 540は、キャッシュ550に結合されており、このキャッシュは、ある実施形態では、低レベル・キャッシュ(たとえば、L1キャッシュ)であってもよいが、本発明の範囲は、この点に関して限定されない。また、実行ユニット520は、キャッシュ550に直接結合されることができる。キャッシュ550から、データ通信は、より高いレベルのキャッシュ、システムメモリなどで行われうる。図5の実施形態ではこの高いレベルで示されているが、本発明の範囲は、この点に関して限定されないことを理解されたい。たとえば、図5の実装は、インテル(登録商標)x86命令セットアーキテクチャ(ISA)のような順序外マシンに関するものであるが、本発明の範囲は、この点に関して限定されない。すなわち、他の実施形態は、順序内プロセッサ、ARMベースのプロセッサのような縮小命令セット・コンピューティング(RISC)プロセッサ、またはエミュレーションエンジンおよび関連する論理回路を介して異なるISAの命令および動作をエミュレートできる別のタイプのISAのプロセッサで実装されてもよい。
ここで図6を参照すると、別の実施形態によるプロセッサ・コアのマイクロアーキテクチャのブロック図が示されている。図6の実施形態では、コア600は、電力消費を低減するように設計された比較的限定されたパイプライン深さを有する、インテル(登録商標)のAtom(商標)ベースのプロセッサのような、異なるマイクロアーキテクチャの低電力コアであってもよい。見て取れるように、コア600は、命令デコーダ615に命令を提供するよう結合された命令キャッシュ610を含む。分岐予測器605は、命令キャッシュ610に結合されてもよい。命令キャッシュ610は、L2キャッシュなどの別のレベルのキャッシュメモリ(図6では、図解の簡単のために示されていない)にさらに結合されてもよいことに留意されたい。次に、命令デコーダ615は、デコードされた命令を、所与の実行パイプラインへの記憶および送達のために、発行キュー(issue queue、IQ)620に提供する。マイクロコードROM 618が命令デコーダ615に結合される。
浮動小数点パイプライン630は、128、256または512ビットなどの所与のビット幅の複数のアーキテクチャレジスタを含んでいてもよい浮動小数点(FP)レジスタ・ファイル632を含む。パイプライン630は、パイプラインの複数の実行ユニットのうちの1つで実行するために命令をスケジュールする浮動小数点スケジューラ634を含む。図示した実施形態では、そのような実行ユニットは、算術論理ユニット(ALU)635、シャッフルユニット636、および浮動小数点(FP)加算器638を含む。次に、これらの実行ユニットにおいて生成された結果は、レジスタ・ファイル632のレジスタおよび/またはバッファに戻されてもよい。むろん、これらの少数の例示的な実行ユニットで示されているが、別の実施形態では、追加のまたは異なる浮動小数点実行ユニットが存在してもよいことを理解されたい。
整数パイプライン640が設けられてもよい。図示した実施形態では、パイプライン640は、128または256ビットのような所与のビット幅の複数のアーキテクチャレジスタを含んでいてもよい整数(INT)レジスタ・ファイル642を含む。パイプライン640は、パイプラインの複数の実行ユニットのうちの1つで実行するための命令をスケジュールする整数実行(integer execution、IE)スケジューラ644を含む。図示した実施形態では、そのような実行ユニットは、ALU 645、シフタユニット646、およびジャンプ実行ユニット(jump execution unit、JEU)648を含む。次に、これらの実行ユニットで生成された結果は、レジスタ・ファイル642のレジスタおよび/またはバッファに戻されてもよい。むろん、これらの少数の例示的な実行ユニットで示されているが、別の実施形態では、追加のまたは異なる整数の実行ユニットが存在してもよい。
メモリ実行(memory execution、ME)スケジューラ650は、TLB 654にも結合されるアドレス生成ユニット(address generation unit、AGU)652内の実行のためのメモリ動作をスケジュールしてもよい。見て取れるように、これらの構造は、L0および/またはL1データ・キャッシュであってもよいデータ・キャッシュ660に結合してもよく、該L0および/またはL1データ・キャッシュはL2キャッシュメモリを含むキャッシュメモリ階層の追加的なレベルに結合する。
順序外実行のサポートを提供するために、並べ替えバッファ680に加えて、アロケータ/リネーマ670が設けられてもよい。これは、順序外で実行された命令を順序どおりに並べ替えるように構成されてもよい。図6の図ではこの特定のパイプラインアーキテクチャで示されているが、多くの変形および代替が可能であることを理解されたい。
図5および図6のマイクロアーキテクチャによるような非対称なコアを有するプロセッサでは、電力管理の理由により、コア間で作業負荷が動的に交換されてもよいことに留意されたい。なぜなら、これらのコアは、異なるパイプライン設計および深さを有するが、同じまたは関連するISAのものであってもよいからである。そのような動的なコア交換は、ユーザーアプリケーションにとって(そして可能性としてはカーネルにとっても)透明な仕方で実行されうる。
図7を参照するに、さらに別の実施形態によるプロセッサ・コアのマイクロアーキテクチャのブロック図が示されている。図7に示されるように、コア700は、非常に低い電力消費レベルで実行するために、多段の順序内パイプラインを含んでいてもよい。そのような一例として、コア700は、米国カリフォルニア州サニーヴェールのARM Holdings社から入手可能なARM Cortex A53設計に従ったマイクロアーキテクチャを有していてもよい。ある実装では、32ビットと64ビットの両方のコードを実行するように構成された8段のパイプラインが提供されてもよい。コア700は、命令をフェッチし、それらの命令をデコード・ユニット715に提供するように構成されたフェッチ・ユニット710を含み、デコード・ユニット715は、命令、たとえば、ARMv8 ISAなどの所与のISAのマクロ命令をデコードすることができる。さらに、デコードされた命令を格納するために、キュー730がデコード・ユニット715に結合してもよいことに留意されたい。デコードされた命令は、発行論理725に提供され、そこで、デコードされた命令は、複数の実行ユニットのうちの所与のものに対して発行されうる。
図7をさらに参照すると、発行論理725は、複数の実行ユニットのうちの1つに命令を発行することができる。図示した実施形態では、これらの実行ユニットは、整数ユニット735、乗算ユニット740、浮動小数点/ベクトル・ユニット750、二重発行ユニット760、およびロード/ストア・ユニット770を含む。これらの異なる実行ユニットの結果は、書き戻し(writeback、WB)ユニット780に提供されてもよい。図示の簡単のために単一の書き戻しユニットが示されているが、いくつかの実装では、各実行ユニットに、別々の書き戻しユニットが付随していてもよいことを理解されたい。さらに、図7に示されるユニットおよび論理のそれぞれは高レベルで表されているが、具体的な実装は、より多くの、または異なる構造を含みうることを理解されたい。図7のようなパイプラインを有する一つまたは複数のコアを使用して設計されたプロセッサは、モバイル装置からサーバーシステムまで広がる多くの異なる最終製品において実装されうる。
図8を参照すると、さらに別の実施形態によるプロセッサ・コアのマイクロアーキテクチャのブロック図が示されている。図8に示されるように、コア800は、非常に高いパフォーマンス・レベル(これは、図7のコア700よりも高い電力消費レベルで生起しうる)で実行される、多段のマルチ発行式の順序外パイプライン(multi-stage multi-issue out-of-order pipeline)を含んでいてもよい。そのような一例として、プロセッサ800は、ARM Cortex A57設計によるマイクロアーキテクチャを有してもよい。ある実装では、32ビットと64ビットの両方のコードを実行するように構成された15段(以上)のパイプラインが提供されてもよい。さらに、パイプラインは、3(以上)の幅および3(以上)の発行の動作を提供することができる。コア800は、命令をフェッチし、それらをキャッシュ820に結合されたデコーダ/リネーマ/ディスパッチャ・ユニット815に提供するように構成されたフェッチ・ユニット810を含む。ユニット815は、命令、たとえば、ARMv8命令セットアーキテクチャのマクロ命令をデコードし、該命令内のレジスタ参照を名称変更し、該命令を(最終的には)選択された実行ユニットに発送することができる。デコードされた命令は、キュー825に格納されてもよい。図8では図示の簡単のために単一キュー構造が示されているが、複数の異なるタイプの実行ユニットのそれぞれについて別々のキューが提供されてもよいことを理解することに留意されたい。
図8にはまた、発行論理830が示されており、そこから、キュー825に格納されたデコードされた命令が、選択された実行ユニットに対して発行されうる。また、発行論理830は、発行論理830が結合する実行ユニットの複数の異なるタイプのそれぞれについて、別個の発行論理を有する具体的な実施形態において実装されてもよい。
デコードされた命令は、複数の実行ユニットのうちの所与のものに対して発行されうる。図示した実施形態では、これらの実行ユニットは、一つまたは複数の整数ユニット835、乗算ユニット840、浮動小数点/ベクトル・ユニット850、分岐ユニット860、およびロード/ストア・ユニット870を含む。ある実施形態では、浮動小数点/ベクトル・ユニット850は、128ビットまたは256ビットのSIMDまたはベクトルデータを扱うように構成されてもよい。さらに、浮動小数点/ベクトル実行ユニット850は、IEEE-754倍精度浮動小数点演算を実行してもよい。これらの異なる実行ユニットの結果は、書き戻しユニット880に提供されてもよい。いくつかの実装では、各実行ユニットに、別々の書き戻しユニットが付随していてもよいことに留意されたい。さらに、図8に示されるユニットおよび論理のそれぞれは高レベルで表されているが、具体的な実装は、より多くの、または異なる構造を含みうることを理解されたい。
図7および図8のマイクロアーキテクチャによるような非対称なコアを有するプロセッサでは、電力管理の理由により、作業負荷が動的に交換してもよいことに留意されたい。これらのコアは、異なるパイプライン設計および深さを有するが、同じまたは関連するISAのものでありうるからである。そのような動的なコア交換は、ユーザーアプリケーションにとって(そして可能性としてはカーネルにとっても)透明な仕方で実行されてもよい。
図5~図8の任意の一つまたは複数のようなパイプラインを有する一つまたは複数のコアを使用して設計されたプロセッサは、モバイル機器からサーバーシステムまで広がる、多くの異なる最終製品において実装されうる。ここで図9を参照すると、本発明の別の実施形態によるプロセッサのブロック図が示されている。図9の実施形態において、プロセッサ900は、複数のドメインを含むSoCであってもよく、各ドメインは、独立した動作電圧および動作周波数で動作するように制御されてもよい。具体的な例解用の例として、プロセッサ900は、i3、i5、i7などのインテル(登録商標)Architecture Core(商標)ベースのプロセッサ、またはインテル・コーポレイションから入手可能な別のそのようなプロセッサであってもよい。しかしながら、たとえばアップルA7プロセッサ、クアルコム・スナップドラゴン・プロセッサ、またはテキサス・インスツルメンツOMAPプロセッサのような他の実施形態では、米国カリフォルニア州サニーヴェールのAdvanced Micro Devices社(AMD)から入手可能なもののような他の低電力プロセッサ、ARM Holdings社もしくはそのライセンシーからのARMベースの設計、または米国カリフォルニア州サニーヴェールのMIPS Technologies社もしくはそのライセンシーもしくは採用者からのMIPSベースの設計が代わりに存在してもよい。そのようなSoCは、スマートフォン、タブレットコンピュータ、ファブレットコンピュータ、Ultrabook(商標)コンピュータ、または他のポータブル・コンピューティング装置のような低電力システムで使用されてもよく、これは、不均一なシステム・アーキテクチャに基づくプロセッサ設計を有する不均一なシステム・アーキテクチャを組み込んでいてもよい。
図9に示される高レベルの図では、プロセッサ900は、複数のコア・ユニット910a~910nを含む。各コア・ユニットは、一つまたは複数のプロセッサ・コア、一つまたは複数のキャッシュメモリ、および他の回路を含んでいてもよい。各コア・ユニット910は、一つまたは複数の命令セット(たとえば、x86命令セット(より新しいバージョンで追加されたいくつかの拡張も));MIPS命令セット;ARM命令セット(NEONのような任意的な追加の拡張も)、または他の命令セットまたはそれらの組み合わせをサポートすることができる。コア・ユニットのいくつかは、不均一なリソース(たとえば、異なる設計のもの)であってもよいことに留意されたい。さらに、そのようなコアのそれぞれは、ある実施形態では共有レベル2(L2)のキャッシュメモリであってもよいキャッシュメモリ(図示せず)に結合されてもよい。不揮発性記憶930が、さまざまなプログラムおよび他のデータを記憶するために使用されてもよい。たとえば、この記憶は、マイクロコードの少なくとも一部、BIOSのようなブート情報、他のシステムソフトウェア等を記憶するために使用されてもよい。
各コア・ユニット910はまた、当該プロセッサの追加的な回路への相互接続を可能にするために、バス・インターフェース・ユニットのようなインターフェースを含んでいてもよい。ある実施形態では、各コア・ユニット910は、一次キャッシュ・コヒーレント・オン・ダイ相互接続(primary cache coherent on-die interconnect)として作用しうるコヒーレント・ファブリックに結合する。該コヒーレント・ファブリックはメモリ・コントローラ935に結合する。そのメモリ・コントローラ935は、DRAMのようなメモリ(図9では図示の簡単のため示していない)との通信を制御する。
コア・ユニットに加えて、少なくとも1つのグラフィックス・ユニット920を含む、追加的な処理エンジンが当該プロセッサ内に存在し、これは、一つまたは複数のグラフィックス処理ユニット(GPU)を含んでいてもよく、グラフィックス処理を実行するとともに、可能性としては該グラフィックス・プロセッサ上で汎用的な動作(いわゆるGPGPU動作)を実行する。さらに、少なくとも1つの画像信号プロセッサ925が存在してもよい。信号プロセッサ925は、SoCの内部またはオフチップのいずれかの一つまたは複数の捕捉装置から受領された到来画像データを処理するように構成されてもよい。
他のアクセラレータも存在してもよい。図9の例では、ビデオ符号化器950は、ビデオ情報のためのエンコードおよびデコードを含む符号化動作を実行してもよく、たとえば、高精細度ビデオコンテンツのためのハードウェア加速サポートを提供する。ディスプレイ・コントローラ955がさらに設けられて、システムの内部および外部ディスプレイのサポートを提供することを含め、ディスプレイ動作を加速してもよい。加えて、セキュリティ・プロセッサ945が存在しては、セキュアブート動作、さまざまな暗号演算などのセキュリティ動作を実行してもよい。
各ユニットは、電力マネージャ940を介してその電力消費を制御されてもよく、該電力マネージャは、本明細書に記載されるさまざまな電力管理技術を実行するための制御論理を含んでいてもよい。
いくつかの実施形態では、プロセッサ900は、さらに、さまざまな周辺装置が結合しうる、コヒーレント・ファブリックに結合された非コヒーレント・ファブリックを含んでいてもよい。一つまたは複数のインターフェース960a~960dは、一つまたは複数のオフチップ装置との通信を可能にする。そのような通信は、他にもあるタイプの通信プロトコルの中でもPCIe(商標)、GPIO、USB、I2-C、UART、MIPI、SDIO、DDR、SPI、HDMI(登録商標)などの、多様な通信プロトコルを介してであってもよい。図9の実施形態ではこの高レベルで示されているが、本発明の範囲は、この点に関して限定されないことを理解されたい。
ここで図10を参照すると、代表的なSoCのブロック図が示されている。図示した実施形態では、SoC 1000は、スマートフォンまたはタブレットコンピュータもしくは他のポータブル・コンピューティング装置などの他の低電力装置に組み込むために最適化される低電力動作用に構成されたマルチコアSoCであってもよい。一例として、SoC 1000は、より高いパワーおよび/または低パワーのコア、たとえば、順序外コアおよび順序内コアの組み合わせのような、非対称なまたは異なるタイプのコアを使用して実装されてもよい。種々の実施形態において、これらのコアは、インテル(登録商標)Architecture(商標)コア設計またはARMアーキテクチャ設計に基づいてもよい。さらに他の実施形態では、インテル・コアとARMコアとの混合が、所与のSoCにおいて実装されてもよい。
図10において見て取れるように、SoC 1000は、複数の第1のコア1012a~1012dを有する第1のコア・ドメイン1010を含む。一例では、これらのコアは、順序内コアのような低電力コアであってもよい。ある実施形態では、これらの第1のコアは、ARM Cortex A53コアとして実装されてもよい。次に、これらのコアはコア・ドメイン1010のキャッシュメモリ1015に結合する。さらに、SoC 1000は、第2のコア・ドメイン1020を含む。図10の図では、第2のコア・ドメイン1020は、複数の第2のコア1022a~1022dを有する。一例では、これらのコアは、第1のコア1012よりも高い電力消費のコアであってもよい。ある実施形態では、第2のコアは、ARM Cortex A57コアとして実装されてもよい順序外コアであってもよい。次に、これらのコアは、コア・ドメイン1020のキャッシュメモリ1025に結合される。図10に示す例は各ドメイン内に4つのコアを含むが、他の例では、所与のドメイン内により多数のまたはより少数のコアが存在していてもよいことを理解することに留意されたい。
図10をさらに参照すると、グラフィックス・ドメイン1030も提供され、これは、たとえば、コア・ドメイン1010および1020の一つまたは複数のコアによって提供される、グラフィックス作業負荷を独立して実行するように構成された一つまたは複数のグラフィックス処理ユニット(GPU)を含んでいてもよい。一例として、GPUドメイン1030は、グラフィックスおよび表示レンダリング動作を提供することに加えて、多様な画面サイズの表示サポートを提供するために使用されてもよい。
見て取れるように、これらさまざまなドメインは、ある実施形態ではキャッシュ・コヒーレント相互接続ファブリックであってもよいコヒーレント相互接続1040に結合し、該コヒーレント相互接続1040は、統合されたメモリ・コントローラ1050に結合する。コヒーレント相互接続1040は、いくつかの例では、L3キャッシュなどの共有キャッシュメモリを含んでいてもよい。ある実施形態では、メモリ・コントローラ1050は、DRAMの複数チャネルのようなオフチップメモリ(図10では、図示の簡単のために示されていない)との通信の複数チャネルを提供する直接メモリ・コントローラであってもよい。
異なる例では、コア・ドメインの数が変化することがありうる。たとえば、モバイル・コンピューティング装置に組み込むのに好適な低電力SoCについては、図10に示されるような限られた数のコア・ドメインが存在しうる。さらに、そのような低電力SoCでは、より高い電力のコアを含むコア・ドメイン1020は、より少数のそのようなコアを有していてもよい。たとえば、ある実装では、低下した電力消費レベルでの動作を可能にするために、2つのコア1022が設けられてもよい。さらに、それら異なるコア・ドメインが割り込みコントローラに結合されて、それら異なるドメイン間の作業負荷の動的な交換を可能にしてもよい。
さらに他の実施形態では、デスクトップ、サーバー、高性能コンピューティング・システム、基地局などの他のコンピューティング装置に組み込むために、SoCがより高いパフォーマンス(および電力)レベルにスケーリングできるという点で、より多数のコア・ドメインおよび追加的な任意的なIP論理が存在してもよい。そのような一例として、それぞれが所与の数の順序外コアを有する4つのコア・ドメインが提供されてもよい。さらに、任意的なGPUサポート(これは、例として、GPGPUの形をとることができる)に加えて、特定の機能(たとえば、ウェブサービス、ネットワーク処理、スイッチングなど)のために、最適化されたハードウェアサポートを提供するための一つまたは複数のアクセラレータも提供されてもよい。さらに、そのようなアクセラレータをオフチップ構成要素に結合するために、入出力インターフェースが存在してもよい。
ここで図11を参照すると、別の例示的なSoCのブロック図が示されている。図11の実施形態では、SoC 1100は、マルチメディア・アプリケーション、通信および他の機能のための高いパフォーマンスを可能にするために、さまざまな回路を含んでいてもよい。よって、SoC 1100は、スマートフォン、タブレットコンピュータ、スマートテレビなどのような、幅広い多様なポータブルなおよび他の装置に組み込むのに好適である。図示した例では、SoC 1100は、中央処理装置(CPU)ドメイン1110を含む。ある実施形態では、複数の個々のプロセッサ・コアがCPUドメイン1110内に存在してもよい。一例として、CPUドメイン1110は、4つのマルチスレッド・コアを有するクワッドコア・プロセッサであってもよい。そのようなプロセッサは、均質または不均質のプロセッサ、たとえば、低電力および高電力プロセッサ・コアの混合であってもよい。
次に、GPUドメイン1120が、グラフィックスを扱い、APIを計算するために、一つまたは複数のGPUにおいて高度なグラフィックス処理を実行するために提供される。DSPユニット1130は、マルチメディア命令の実行中に起こりうる高度な計算に加えて、音楽再生、オーディオ/ビデオなどの低電力マルチメディア・アプリケーションを処理するために、一つまたは複数の低電力DSPを提供してもよい。次に、通信ユニット1140は、さまざまな無線プロトコル、たとえばセルラー通信(3G/4G LTEを含む)、無線ローカルエリアプロトコル、たとえばBluetooth(商標)、IEEE802.11などを介して接続性を提供するためのさまざまな構成要素を含むことができる。
さらに、ユーザージェスチャーの処理を含む、高精細度ビデオおよびオーディオコンテンツの捕捉および再生を実行するために、マルチメディアプロセッサ1150が使用されてもよい。センサーユニット1160は、複数のセンサーおよび/または所与のプラットフォーム内に存在するさまざまなオフチップセンサーとインターフェースするためのセンサーコントローラを含んでいてもよい。画像信号プロセッサ(image signal processor、ISP)1170は、スチールカメラおよびビデオカメラを含むプラットフォームの一つまたは複数のカメラからの取り込まれたコンテンツに関して画像処理を実行することができる。
ディスプレイ・プロセッサ1180は、所与のピクセル密度の高精細度ディスプレイへの接続のためのサポートを提供してもよい。かかるサポートは、そのようなディスプレイ上で再生するためにコンテンツを無線で通信する能力を含む。さらに、位置ユニット1190は、複数のGPSコンステレーションをサポートする全地球測位システム(GPS)受信機を含み、そのようなGPS受信機を使用して得られた非常に正確な位置決め情報をアプリケーションに提供することができる。図11の例では、この特定の一組の構成要素を用いて示されているが、多くの変形および代替が可能であることを理解されたい。
ここで、図12を参照すると、実施形態が一緒に使用されることができる例示的なシステムのブロック図が示されている。見て取れるように、システム1200は、スマートフォンまたは他のワイヤレス通信機であってもよい。ベースバンド・プロセッサ1205は、システムから送信されるかまたはシステムによって受信されるべき通信信号に関してさまざまな信号処理を実行するように構成される。次に、ベースバンド・プロセッサ1205は、多くの周知のソーシャルメディアおよびマルチメディアアプリのようなユーザーアプリケーションに加えて、OSおよび他のシステムソフトウェアを実行するための、システムのメインCPUであってもよい、アプリケーション・プロセッサ1210に結合される。アプリケーション・プロセッサ1210は、さらに、当該装置のための多様な他のコンピューティング動作を実行するように構成されてもよい。
次に、アプリケーション・プロセッサ1210は、ユーザー・インターフェース/ディスプレイ1220、たとえば、タッチスクリーン・ディスプレイに結合することができる。さらに、アプリケーション・プロセッサ1210は、不揮発性メモリ、すなわちフラッシュメモリ1230と、システムメモリ、すなわちダイナミックランダムアクセスメモリ(DRAM)1235とを含むメモリ・システムに結合してもよい。さらに見て取れるように、アプリケーション・プロセッサ1210は、さらに、ビデオおよび/またはスチール画像を記録することができる一つまたは複数の画像捕捉装置などの捕捉装置1241に結合する。
引き続き図12を参照すると、加入者識別情報モジュールと、可能性としてはセキュアな記憶および暗号プロセッサとを備えるユニバーサル集積回路カード(universal integrated circuit card、UICC)1246も、アプリケーション・プロセッサ1210に結合される。システム1200は、アプリケーション・プロセッサ1210に結合しうるセキュリティ・プロセッサ1250をさらに含んでいてもよい。複数のセンサー1225がアプリケーション・プロセッサ1210に結合して、加速度計および他の環境情報のような多様な感知情報の入力を可能にしてもよい。オーディオ出力装置1295が、たとえば、音声通信、再生されるもしくはストリーミングされるオーディオ・データなどの形で音を出力するためのインターフェースを提供してもよい。
さらに示されるように、NFCアンテナ1265を介してNFC近接場で通信する近接場通信(NFC)非接触インターフェース1260が提供される。図12には別個のアンテナが示されているが、いくつかの実装では、さまざまな無線機能を可能にするために、1つのアンテナまたは複数アンテナの異なるセットが提供されてもよいことを理解されたい。
電力管理集積回路(power management integrated circuit、PMIC)1215は、プラットフォーム・レベルの電力管理を実行するためにアプリケーション・プロセッサ1210に結合する。この目的のために、PMIC 1215は、所望によりある種の低電力状態に入るよう、アプリケーション・プロセッサ1210に電力管理要求を発してもよい。さらに、プラットフォーム制約条件に基づいて、PMIC 1215は、システム1200の他の構成要素の電力レベルを制御してもよい。
通信が送受信されることを可能にするために、さまざまな回路が、ベースバンド・プロセッサ1205とアンテナ1290との間で結合されてもよい。特に、無線周波(RF)トランシーバ1270および無線ローカルエリアネットワーク(WLAN)トランシーバ1275が存在してもよい。一般に、RFトランシーバ1270は、符号分割多元接続(CDMA)、グローバル移動通信システム(GSM)、ロングタームエボリューション(LTE)、または他のプロトコルに従って、3Gまたは4G無線通信プロトコルのような所与の無線通信プロトコルに従って、無線データおよび呼を送受信するために使用されてもよい。加えて、GPSセンサー1280が存在してもよい。無線信号、たとえばAM/FMおよび他の信号の受信または送信のような他の無線通信も提供されてもよい。さらに、無線LANトランシーバ1275を介して、ローカル無線通信が実現されることもできる。
ここで図13を参照すると、実施形態が一緒に使用されうる別の例示的なシステムのブロック図が示されている。図13の例解では、システム1300は、タブレットコンピュータ、2:1タブレット、ファブレット、または他のコンバーチブルなまたはスタンドアローンのタブレットシステムのようなモバイル低電力システムであってもよい。図示されるように、SoC 1310が存在し、装置のためのアプリケーション・プロセッサとして動作するように構成されてもよい。
多様な装置がSoC 1310に結合されてもよい。図示した例解では、メモリ・サブシステムは、SoC 1310に結合されたフラッシュメモリ1340およびDRAM 1345を含む。加えて、タッチパネル1320のディスプレイ上に仮想キーボードを提供することを含め、表示機能およびタッチを介したユーザー入力を提供するために、タッチパネル1320がSoC 1310に結合される。有線ネットワーク接続を提供するために、SoC 1310は、イーサネット〔登録商標〕インターフェース1330に結合する。周辺ハブ1325がSoC 1310に結合され、さまざまなポートまたは他のコネクタのいずれかによってシステム1300に結合されうるような、さまざまな周辺装置とインターフェースすることを可能にする。
SoC 1310内の内部電力管理回路および機能性に加えて、PMIC 1380がSoC 1310に結合され、たとえば、システムがバッテリー1390によって給電されているか、ACアダプター1395を介してAC電力によって給電されているかに基づいて、プラットフォームベースの電力管理を提供する。この電源ベースの電力管理に加えて、PMIC 1380は、さらに、環境条件および使用条件に基づいてプラットフォームの電力管理活動を実行してもよい。さらに、PMIC 1380は、制御およびステータス情報をSoC 1310に通信して、SoC 1310内でさまざまな電力管理アクションを引き起こすことができる。
引き続き図13を参照すると、無線機能を提供するために、無線LANユニット1350がSoC 1310に結合され、アンテナ1355にも結合される。さまざまな実装において、無線LANユニット1350は、一つまたは複数の無線プロトコルに従って通信を提供することができる。
さらに示されるように、複数のセンサー1360がSoC 1310に結合してもよい。これらのセンサーは、さまざまな加速度計、環境センサー、およびユーザージェスチャーセンサーを含む他のセンサーを含むことができる。最後に、オーディオ・コーデック1365がSoC 1310に結合され、オーディオ出力装置1370へのインターフェースを提供する。むろん、図13ではこの特定の実装を用いて示しているが、多くの変形および代替が可能であることを理解されたい。
ここで図14を参照すると、ノートブック、Ultrabook(商標)または他の小型形状因子システムのような代表的なコンピュータ・システム1400のブロック図が示されている。プロセッサ1410は、ある実施形態では、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、埋め込みプロセッサ、または他の既知の処理要素を含む。図示した実装では、プロセッサ1410は、システム1400のさまざまな構成要素の多くと通信するためのメイン処理ユニットおよび中央ハブとして機能し、本明細書に記載されるような電力管理回路を含んでいてもよい。一例として、プロセッサ1410は、SoCとして実装される。
プロセッサ1410は、ある実施形態では、システムメモリ1415と通信する。例解用の例として、システムメモリ1415は、所与の量のシステムメモリを提供するために、複数のメモリデバイスまたはモジュールを介して実装される。
データ、アプリケーション、一つまたは複数のオペレーティングシステムなどの情報の永続的な記憶を提供するために、大容量記憶1420がプロセッサ1410に結合してもよい。さまざまな実施形態では、より薄く、軽量なシステム設計を可能にし、システムの応答性を改善するために、この大容量記憶装置は、SSDを介して実装されてもよく、または、この大容量記憶装置は、主にハードディスクドライブ(HDD)を使用して実装され、より少量のSSD記憶がSSDキャッシュのはたらきをし、電力停止イベントの間にコンテキスト状態および他のそのような情報の不揮発性記憶を可能にする。それにより、システム活動の再開始時に、高速なパワーアップができる。やはり図14に示されるように、たとえばシリアル周辺インターフェース(SPI)を介して、フラッシュデバイス1422がプロセッサ1410に結合されてもよい。このフラッシュデバイスは、基本入出力ソフトウェア(BIOS)およびシステムの他のファームウェアを含むシステムソフトウェアの不揮発性記憶を提供することができる。
さまざまな入出力(I/O)装置が、システム1400内に存在しうる。特に、図14の実施形態では、タッチスクリーン1425をさらに提供する高精細度LCDまたはLEDパネルであってもよいディスプレイ1424が示されている。ある実施形態では、ディスプレイ1424は、高性能グラフィックス相互接続として実装できるディスプレイ相互接続を介してプロセッサ1410に結合されてもよい。タッチスクリーン1425は、別の相互接続を介してプロセッサ1410に結合されてもよく、該別の相互接続はある実施形態ではI2-C相互接続であってもよい。図14にさらに示されるように、タッチスクリーン1425に加えて、タッチによるユーザー入力は、シャーシ内に構成されてもよく、やはりタッチスクリーン1425と同じI2-C相互接続に結合されてもよいタッチパッド1430を介して行うこともできる。
知覚的な計算および他の目的のために、さまざまなセンサーがシステム内に存在してもよく、種々の仕方でプロセッサ1410に結合されてもよい。ある種の慣性センサーおよび環境センサーが、センサー・ハブ1440を通じて、たとえば、I2-C相互接続を介して、プロセッサ1410に結合してもよい。図14に示される実施形態では、これらのセンサーは、加速度計1441、周囲光センサー(ambient light sensor、ALS)1442、コンパス1443、およびジャイロスコープ1444を含んでいてもよい。他の環境センサーは、いくつかの実施形態ではシステム管理バス(system management bus、SMBus)バスを介してプロセッサ1410に結合する一つまたは複数の熱センサー1446を含んでいてもよい。
やはり図14に見られるように、さまざまな周辺装置は、低ピン数(low pin count、LPC)相互接続を介してプロセッサ1410に結合してもよい。図示した実施形態では、さまざまな構成要素が、埋め込みコントローラ(embedded controller)1435を通じて結合されることができる。そのような構成要素は、キーボード1436(たとえば、PS2インターフェースを介して結合される)、ファン1437、および熱センサー1439を含むことができる。いくつかの実施形態では、タッチパッド1430も、PS2インターフェースを介してEC 1435に結合されてもよい。さらに、信頼されるプラットフォームモジュール(trusted platform module、TPM)1438のようなセキュリティ・プロセッサも、このLPC相互接続を介してプロセッサ1410に結合することができる。
システム1400は、ワイヤレスを含む多様な態様で外部装置と通信することができる。図14に示される実施形態では、それぞれが特定の無線通信プロトコル用に構成された無線機に対応することができるさまざまな無線モジュールが存在する。近接場のような短距離の無線通信のための1つの態様は、ある実施形態ではSMBusを介してプロセッサ1410と通信することができるNFCユニット1445を介してであってもよい。このNFCユニット1445を介して、互いに近接した装置が通信できることに留意されたい。
図14にさらに示されるように、追加の無線ユニットは、無線LANユニット1450およびBluetooth(商標)ユニット1452を含む他の短距離無線エンジンを含むことができる。WLANユニット1450を使用するとWi-Fi(商標)通信が実現でき、一方、Bluetooth(商標)ユニット1452を介して、短距離のBluetooth(商標)通信が実現できる。これらのユニットは、所与のリンクを介してプロセッサ1410と通信することができる。
加えて、たとえばセルラーまたは他の無線広域プロトコルによる無線広域通信が、WWANユニット1456を介して実現できる。WWANユニット1456は、加入者識別情報モジュール(SIM)1457に結合することができる。さらに、位置情報の受信および使用を可能にするために、GPSモジュール1455が存在してもよい。図14に示される実施形態では、WWANユニット1456およびカメラモジュール1454のような統合された捕捉装置は、所与のリンクを介して通信することができることに留意されたい。
オーディオ入出力を提供するために、オーディオ・プロセッサは、デジタル信号プロセッサ(DSP)1460を介して実装でき、これは、高精細度オーディオ(high definition audio、HDA)リンクを介してプロセッサ1410に結合することができる。同様に、DSP 1460は、統合された符号化器/復号器(コーデック)および増幅器1462と通信することができ、これらは、シャーシ内に実装されうる出力スピーカー1463と結合することができる。同様に、増幅器およびコーデック1462は、マイクロフォン1465からオーディオ入力を受領するように結合されることができ、該マイクロフォンは、ある実施形態では、デュアルアレイマイクロフォン(たとえば、デジタルマイクロフォンアレイ)を介して実装されて、システム内のさまざまな動作の音声作動される制御を可能にするよう高品質オーディオ入力を提供することができる。また、オーディオ出力は、増幅器/コーデック1462からヘッドフォンジャック1464に与えられることができることに留意されたい。図14の実施形態ではこれらの特定の構成要素とともに示されているが、本発明の範囲は、この点に関して限定されないことを理解されたい。
実施形態は、多くの異なるシステムタイプで実装されうる。ここで図15Aを参照すると、本発明のある実施形態によるシステムのブロック図が示されている。図15Aに示されるように、マルチプロセッサシステム1500は、ポイントツーポイント相互接続システムであり、ポイントツーポイント相互接続1550を介して結合される第1のプロセッサ1570および第2のプロセッサ1580を含む。図15Aに示されるように、プロセッサ1570および1580のそれぞれは、第1および第2のプロセッサ・コア(すなわち、プロセッサ・コア1574aおよび1574bならびにプロセッサ・コア1584aおよび1584b)を含むマルチコアプロセッサであってもよいが、潜在的には、プロセッサには、ずっと多くのコアが存在してもよい。各プロセッサは、本明細書に記載されるようなプロセッサベースの電力管理を実行するために、PCUまたは他の電力管理論理を含むことができる。
引き続き図15Aを参照すると、第1のプロセッサ1570は、統合されたメモリ・コントローラ(IMC)1572と、ポイントツーポイント(P-P)インターフェース1576および1578とをさらに含む。同様に、第2のプロセッサ1580は、IMC 1582およびP-Pインターフェース1586および1588を含む。図15に示されるように、IMC 1572および1582は、前記プロセッサをそれぞれのメモリ、すなわち、メモリ1532およびメモリ1534に結合するが、これらは、それぞれのプロセッサにローカルに取り付けられたシステムメモリ(たとえば、DRAM)の一部であってもよい。第1のプロセッサ1570および第2のプロセッサ1580は、それぞれP-P相互接続1562および1564を介してチップセット1590に結合されてもよい。図15Aに示されるように、チップセット1590は、P-Pインターフェース1594および1598を含む。
さらに、チップセット1590は、P-P相互接続1539によって、チップセット1590を高性能グラフィックエンジン1538と結合するためのインターフェース1592を含む。次に、チップセット1590は、インターフェース1596を介して第1のバス1516に結合されてもよい。図15Aに示されるように、さまざまな入出力(I/O)装置1514が、第1のバス1516を第2のバス1520に結合するバスブリッジ1518とともに第1のバス1516に結合されてもよい。ある実施形態では、たとえば、キーボード/マウス1522、通信装置1526、および、コード1530を含みうるディスクドライブもしくは他の大容量記憶装置などのデータ記憶ユニット1528を含むさまざまな装置が、第2のバス1520に結合されてもよい。さらに、オーディオI/O 1524が第2のバス1520に結合されてもよい。実施形態は、スマートセルラー電話、タブレットコンピュータ、ネットブック、Ultrabook(商標)などのモバイルデバイスを含む他のタイプのシステムに組み込まれることができる。
ここで図15Bを参照すると、本発明のある実施形態による第2のより具体的な例示的システム1501のブロック図が示されている。図15Aおよび図15Bにおける同様の要素は同様の参照番号を付されており、図15Bの他の側面を埋没させることを避けるために、図15Aのある種の側面は図15Bから省略されている。
図15Bは、プロセッサ1570、1580が、統合されたメモリおよびI/O制御論理(control logic、CL)1571、1581をそれぞれ含んでいてもよいことを示している。よって、制御論理1571および1581は、統合されたメモリ・コントローラ・ユニットを含み、I/O制御論理を含む。図15Nは、制御論理1571および1581にメモリ1532、1534が結合されるだけでなく、I/O装置1513も制御論理1571および1581に結合されていることを示している。レガシーI/Oデバイス1515はチップセット1590に結合される。
少なくとも1つの実施形態の一つまたは複数の側面は、プロセッサのような集積回路内の論理を表すおよび/または定義する機械可読媒体上に記憶された表現コードによって実装されてもよい。たとえば、機械可読媒体は、プロセッサ内のさまざまな論理を表す命令を含んでいてもよい。機械によって読まれるとき、命令は、該機械に、本明細書に記載される技術を実行するための論理を製造させることができる。「IPコア」として知られるそのような表現は、集積回路の構造を記述するハードウェア・モデルとして、有形の機械可読媒体に記憶されうる集積回路のための論理の再利用可能な単位である。ハードウェア・モデルは、集積回路を製造する製造機械に該ハードウェア・モデルをロードする、さまざまな顧客または製造施設に供給されてもよい。集積回路は、本明細書に記載される実施形態のいずれかに関連して記載される動作を実行するように製造されてもよい。
図16は、ある実施形態による動作を実行するための集積回路を製造するために使用されうるIPコア開発システム1600を示すブロック図である。IPコア開発システム1600は、より大きな設計に組み込まれる、または集積回路(たとえば、SoC集積回路)全体を構築するために使用されることができるモジュール式の再利用可能な設計を生成するために使用されてもよい。設計設備(design facility)1630は、高レベルプログラミング言語(たとえば、C/C++)におけるIPコア設計のソフトウェアシミュレーション1610を生成することができる。ソフトウェアシミュレーション1610は、IPコアの挙動を設計、試験、および検証するために使用できる。次いで、レジスタ転送レベル(register transfer level、RTL)設計が、シミュレーションモデルから生成され、合成されることができる。RTL設計1615は、ハードウェアレジスタ間のデジタル信号の流れをモデル化する、集積回路の挙動の抽象化であり、これは、モデル化されるデジタル信号を用いて実行される関連論理を含む。RTL設計1615に加えて、論理レベルまたはトランジスタレベルでのより低レベルの設計も、生成、設計、または合成されうる。よって、初期設計およびシミュレーションの具体的な詳細は、変化しうる。
RTL設計1615または同等物は、設計設備によって合成されてハードウェア・モデル1620にされてもよく、ハードウェア・モデル1620は、ハードウェア記述言語(HDL)または物理的な設計データの他の何らかの表現であってもよいHDLは、IPコア設計を検証するためにさらにシミュレーションまたは試験されてもよい。IPコア設計は、不揮発性メモリ1640(たとえば、ハードディスク、フラッシュメモリ、または任意の不揮発性記憶媒体)を使用して、サードパーティー製造設備1665への送達のために記憶されることができる。代替的に、IPコア設計は、有線接続1650または無線接続1660を通じて(たとえば、インターネットを介して)送信されてもよい。次いで、製造設備1665は、少なくとも部分的にIPコア設計に基づく集積回路を製造してもよい。製造された集積回路は、本明細書に記載される構成要素および/またはプロセスに従って動作を実行するように構成されることができる。
以下に説明される図17A~図25は、本明細書に記載される構成要素および/またはプロセスの実施形態を実施するための例示的なアーキテクチャおよびシステムを詳述する。いくつかの実施形態では、本明細書に記載される一つまたは複数のハードウェア・コンポーネントおよび/または命令は、以下で詳細に説明するようにエミュレートされるか、またはソフトウェアモジュールとして実装される。
上記に詳述した命令の実施形態は、以下に詳述する「一般的ベクトル・フレンドリー命令フォーマット(generic vector friendly instruction format)」において具現されてもよい。他の実施形態では、そのようなフォーマットは利用されず、別の命令フォーマットが使用されるが、書き込みマスク・レジスタ、さまざまなデータ変換(スウィズル(swizzle)、ブロードキャストなど)、アドレッシングなどの以下の記述は、一般に、上記の命令の実施形態の記述に適用可能である。さらに、例示的なシステム、アーキテクチャ、およびパイプラインを以下に詳述する。上記命令の実施形態は、そのようなシステム、アーキテクチャ、およびパイプライン上で実行されてもよいが、詳述されるものに限定されない。
命令セットは、一つまたは複数の命令フォーマットを含んでいてもよい。所与の命令フォーマットは、とりわけ、実行されるべき動作(たとえば、オペコード)およびその動作が実行されるべきオペランド(単数または複数)および/または他のデータ・フィールド(単数または複数)(たとえば、マスク)を指定する、さまざまなフィールド(たとえば、ビットの数、ビットの位置)を定義しうる。いくつかの命令フォーマットは、命令テンプレート(またはサブフォーマット)の定義を通じてさらに細分化される。たとえば、所与の命令フォーマットの命令テンプレートは、命令フォーマットのフィールドの異なるサブセットを有するように定義されてもよく(含まれるフィールドは典型的には同じ順序であるが、少なくともいくつかのフィールドは、含まれるフィールドがより少ないので、異なるビット位置を有する)、および/または所与のフィールドが異なる仕方で解釈されるように定義されてもよい。よって、ISAの各命令は、所与の命令フォーマットを使用して、(および、もし定義されていれば、その命令フォーマットの命令テンプレートの与えられた一つで)表現され、動作およびオペランドを指定するためのフィールドを含む。たとえば、例示的なADD命令は、特定のオペコードと命令フォーマットとを有し、命令フォーマットは、そのオペコードを指定するオペコード・フィールドと、オペランド(source1〔ソース1〕/destination〔宛先〕およびsource2〔ソース2〕)を選択するためのオペランド・フィールドとを含む;命令ストリームにおけるこのADD命令の出現は、特定のオペランドを選択するオペランド・フィールド内の特定の内容を有する。アドバンストベクトル拡張(Advanced Vector Extensions、AVX)(AVX1およびAVX2)と呼ばれ、ベクトル拡張(Vector Extensions、VEX)符号化方式を使用するSIMD拡張のセットがリリースおよび/または公開されている(たとえば、非特許文献1、非特許文献2を参照)。
Intel(登録商標) 64 and IA-32 Architectures Software Developer's Manual、September 2014
Intel(登録商標) Advanced Vector Extensions Programming Reference、October 2014
例示的な命令フォーマット
本明細書に記載される命令(単数または複数)の実施形態は、異なるフォーマットで具現されうる。さらに、例示的なシステム、アーキテクチャ、およびパイプラインを以下に詳述する。命令(単数または複数)の実施形態は、そのようなシステム、アーキテクチャ、およびパイプライン上で実行されてもよいが、これらに限定されない。
一般的ベクトル・フレンドリー命令フォーマット(Generic Vector Friendly Instruction Format)
ベクトル・フレンドリー命令フォーマットは、ベクトル命令に好適な命令フォーマットである(たとえば、ベクトル演算に特有のある種のフィールドがある)。ベクトル・フレンドリー命令フォーマットを通じてベクトル演算およびスカラー演算の両方がサポートされる実施形態が記載されているが、代替実施形態はベクトル演算、ベクトル・フレンドリー命令フォーマットのみを使用する。
図17A~17Bは、本発明の実施形態による、一般的ベクトル・フレンドリー命令フォーマットおよびその命令テンプレートを示すブロック図である。図17Aは、本発明の実施形態による一般的ベクトル・フレンドリー命令フォーマットおよびそのクラスA命令テンプレートを示すブロック図であり、図17Bは、本発明の実施形態による一般的ベクトル・フレンドリー命令フォーマットおよびそのクラスB命令テンプレートを示すブロック図である。具体的には、一般的ベクトル・フレンドリー命令フォーマット1700のためにクラスAおよびクラスB命令テンプレートが定義されており、その両方とも、メモリ・アクセスなし1705命令テンプレートおよびメモリ・アクセス1720命令テンプレートを含む。ベクトル・フレンドリー命令フォーマットのコンテキストにおける一般的(generic)という用語は、その命令フォーマットが、いかなる特定の命令セットにも拘束されないことをいう。
記載される本発明の実施形態では、ベクトル・フレンドリー命令フォーマットは、32ビット(4バイト)または64ビット(8バイト)のデータ要素幅(またはサイズ)をもつ64バイトのベクトル・オペランド長(またはサイズ)(よって、64バイトのベクトルは、16個の倍長語サイズの要素または代替的に、8個の四倍長語サイズの要素からなる)と;16ビット(2バイト)または8ビット(1バイト)のデータ要素幅(またはサイズ)をもつ64バイトのベクトル・オペランド長(またはサイズ)と;32ビット(4バイト)、64ビット(8バイト)、16ビット(2バイト)または8ビット(1バイト)のデータ要素幅(またはサイズ)をもつ32バイトのベクトル・オペランド長(またはサイズ)と;32ビット(4バイト)、64ビット(8バイト)、16ビット(2バイト)または8ビット(1バイト)のデータ要素幅(またはサイズ)をもつ16バイトのベクトル・オペランド長(またはサイズ)をサポートするが、代替的な実施形態は、より多くの、より少ない、または異なるデータ要素幅(たとえば、128ビット(16バイト)のデータ要素幅)をもつ、より多くの、より少ない、および/または異なるベクトル・オペランド・サイズ(たとえば、256バイトのベクトル・オペランド)をサポートしてもよい。
図17AにおけるクラスA命令テンプレートは、下記を含む:1)メモリ・アクセスなし1705命令テンプレート内には、メモリ・アクセスなしのフル丸め制御タイプ動作1710命令テンプレートおよびメモリ・アクセスなしのデータ変換タイプ動作1715命令テンプレートが示されている;2)メモリ・アクセス1720命令テンプレート内には、メモリ・アクセス時間的1725命令テンプレートおよびメモリ・アクセス非時間的1730命令テンプレートが示されている。図17BにおけるクラスB命令テンプレートは、下記を含む:1)メモリ・アクセスなし1705命令テンプレート内には、メモリ・アクセスなしの書き込みマスク制御、部分的丸め制御タイプ動作1712命令テンプレートおよびメモリ・アクセスなしの書き込みマスク制御、vsizeタイプ動作1717命令テンプレートが示されている;2)メモリ・アクセス1720命令テンプレート内には、メモリ・アクセス、書き込みマスク制御1727命令テンプレートが示されている。
一般的ベクトル・フレンドリー命令フォーマット1700は、図17A~17Bに示される順序で下記でリストされる以下のフィールドを含む。
フォーマット・フィールド1740――このフィールド内の特定の値(命令フォーマット識別子値)は、ベクトル・フレンドリー命令フォーマットを一意的に識別し、よって、命令ストリーム内のベクトル・フレンドリー命令フォーマットにおける命令の出現を識別する。よって、このフィールドは、一般的ベクトル・フレンドリー命令フォーマットのみを有する命令セットについては必要とされないという意味で、任意的である。
基本動作フィールド1742――その内容は、異なる基本動作を区別する。
レジスタ・インデックス・フィールド1744――その内容は、直接的に、またはアドレス生成を通じて、レジスタ内であれメモリ内であれ、ソース・オペランドおよび宛先オペランドの位置を指定する。これらは、PxQ(たとえば、32x512、16x128、32x1024、174x1024)レジスタ・ファイルからN個のレジスタを選択するために十分な数のビットを含む。ある実施形態では、Nは、3つまでのソースおよび1つの宛先レジスタであってもよいが、代替的な実施形態は、より多数またはより少数のソースおよび宛先レジスタをサポートしてもよい(たとえば、2つまでのソースをサポートしてもよく、これらのソースのうちの一つが宛先としても機能する、3つまでのソースをサポートしてもよく、これらのソースのうちの一つが宛先としても機能する、2つまでのソースおよび1つの宛先をサポートしてもよい)。
修正子フィールド1746――その内容は、メモリ・アクセスを指定する一般的ベクトル命令フォーマットの命令の出現を、メモリ・アクセスを指定しないものの出現から区別する。つまり、メモリ・アクセスなし1705命令テンプレートとメモリ・アクセス1720命令テンプレートの間の区別をする。メモリ・アクセス動作は、メモリ階層に対して読み出しおよび/または書き込みを行なう(いくつかの場合には、レジスタ内の値を使用して、ソースおよび/または宛先アドレスを指定する)が、非メモリ・アクセス動作は行なわない(たとえば、ソースおよび宛先がレジスタである)。ある実施形態では、このフィールドはまた、メモリ・アドレス計算を実行するための3つの異なる方法の間で選択もするが、代替的な実施形態は、メモリ・アドレス計算を実行するためのより多数の、より少数の、または異なる方法をサポートしてもよい。
増強動作(augmentation operation)フィールド1750――その内容は、多様な異なる動作のうちのどれが基本動作に加えて実行されるべきかを区別する。このフィールドは、コンテキスト固有である。本開示のある実施形態では、このフィールドは、クラス・フィールド1768、アルファ・フィールド1752、およびベータ・フィールド1754に分割される。増強動作フィールド1750は、一般的な一群の動作を、2、3、または4個の命令ではなく、単一命令で実行できるようにする。
スケール・フィールド1760――その内容は、メモリ・アドレス生成(たとえば、2scale*インデックス+ベースを使用するアドレス生成)のためのインデックス・フィールドの内容のスケーリングを許容する。
変位フィールド1762A――その内容は、メモリ・アドレス生成の一部として(たとえば、2scale*インデックス+ベース+変位を使用するアドレス生成のために)使用される。
変位因子フィールド1762B(変位フィールド1762Aが変位因子フィールド1762Bのすぐ上に隣接していることは、一方または他方が使用されることを示すことに注意)――その内容は、アドレス生成の一部として使用され、メモリ・アクセスのサイズ(N)によってスケールされる変位因子を指定する。ここで、Nはメモリ・アクセスにおけるバイト数である。(たとえば、2scale*インデックス+ベース+スケールされた変位を使用するアドレス生成のために使用される。)冗長な下位ビットは無視され、よって、有効アドレスの計算において使用される最終的な変位を生成するために、変位因子フィールドの内容は、メモリ・オペランドの合計サイズ(N)を乗算される。Nの値は、完全なオペコード・フィールド1774(本明細書で後述)およびデータ操作フィールド1754Cに基づいて、ランタイムにおいて、プロセッサ・ハードウェアによって決定される。変位フィールド1762Aおよび変位因子フィールド1762Bは、それらがメモリ・アクセスなし1705命令テンプレートについては使用されないという意味で任意的であり、および/または異なる実施形態は、それら2つのうちの一つのみを実装してもよく、あるいはどちらも実装しなくてもよい。
データ要素幅フィールド1764――その内容は、いくつかのデータ要素幅のうちのどの一つが(いくつかの実施形態では、すべての命令について;他の実施形態では、命令のいくついかについてのみ)使用されるべきであるかを区別する。このフィールドは、一つのデータ要素幅のみがサポートされる、および/またはデータ要素幅がオペコードの何らかの側面を使用してサポートされる場合には必要とされないという意味で任意的である。
書き込みマスク・フィールド1770――その内容は、データ要素位置ごとに、宛先ベクトル・オペランド内のそのデータ要素位置が基本動作および増強動作の結果を反映するかどうかを制御する。クラスA命令テンプレートはmerging-writemasking〔マージ‐書き込みマスク〕をサポートし、クラスB命令テンプレートはmerging-writemaskingとzeroing-writemasking〔ゼロ化‐書き込みマスク〕の両方をサポートする。マージの際には、ベクトル・マスクにより、宛先内の要素の任意の集合が、任意の動作(基本動作および増強動作によって指定される)の実行中に更新から保護されることができ;他の一つの実施形態では、対応するマスク・ビットが0を有する宛先の各要素の古い値を保持する。対照的に、ゼロ化の際には、ベクトル・マスクにより、宛先内の要素の任意の集合が、任意の動作(基本動作および増強動作によって指定される)の実行中にゼロにされることができ;ある実施形態では、対応するマスク・ビットが0値を有するとき、宛先の要素が0に設定される。この機能のサブセットは、実行されている動作のベクトル長(すなわち、最初から最後までの、修正されている要素の範囲)を制御する能力であるが、修正される諸要素が連続的である必要はない。よって、書き込みマスク・フィールド1770は、ロード、ストア、算術、論理等を含む部分的なベクトル動作を許容する。記載される本発明の実施形態では、書き込みマスク・フィールド1770の内容は、使用される書き込みマスクを含むいくつかの書き込みマスク・レジスタのうちの一つを選択するが(よって、書き込みマスク・フィールド1770の内容が、実行されるべきマスキングを間接的に同定する)、代替的な実施形態または追加的な実施形態は、マスク書き込みフィールド1770の内容が実行されるべきマスキングを直接指定することを許容する。
即値フィールド(immediate field)1772――その内容は、即値(immediate)の指定を許容する。このフィールドは、即値をサポートしない一般的ベクトル・フレンドリー・フォーマットの実装では存在せず、即値を使用しない命令では存在しないという意味で任意的である。
クラス・フィールド1768――その内容は、異なるクラスの命令を区別する。図17A~図17Bを参照すると、このフィールドの内容は、クラスA命令とクラスB命令の間で選択する。図17A~図17Bでは、角丸の四角形が、特定の値がフィールド内に存在することを示すために使用される(たとえば、図17A~図17Bのクラス・フィールド1768について、それぞれ、クラスA 1768AおよびクラスB 1768B)。
クラスAの命令テンプレート
クラスAの非メモリ・アクセス1705命令テンプレートの場合、アルファ・フィールド1752は、RSフィールド1752Aとして解釈され、その内容は、種々の増強動作タイプのうちのどれが実行されるかを区別する(たとえば、丸め1752A.1およびデータ変換1752A.2は、それぞれメモリ・アクセスなし、丸めタイプ動作1710およびメモリ・アクセスなし、データ変換タイプ動作1715命令テンプレートのために指定される)。一方、ベータ・フィールド1754は、指定されたタイプの動作のうちのどれが実行されるべきかを区別する。メモリ・アクセスなし1705命令テンプレートでは、スケール・フィールド1760、変位フィールド1762A、および変位スケール・フィールド1762Bは存在しない。
メモリ・アクセスなし命令テンプレート――フル丸め制御タイプ動作
メモリ・アクセスなしフル丸め制御タイプ動作1710命令テンプレートでは、ベータ・フィールド1754は丸め制御フィールド1754Aとして解釈され、その内容は静的な丸め(static rounding)を提供する。本発明の記載された実施形態では、丸め制御フィールド1754Aは、全浮動小数点例外抑制(suppress all floating point exceptions、SAE)フィールド1756および丸め動作制御フィールド1758を含むが、代替的な実施形態は、これらの概念を両方とも同じフィールドにエンコードしてもよく、またはこれらの概念/フィールドのうちの一方または他方のみを有することをサポートしてもよい(たとえば、丸め動作制御フィールド1758のみを有していてもよい)。
SAEフィールド1756――その内容は、例外イベント報告を無効にするか否かを区別する。SAEフィールド1756の内容が抑制が有効であることを示すときは、所与の命令は、いかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも持ち上げない。
丸め動作制御フィールド1758――その内容は、一群の丸め動作(たとえば、切り上げ、切り捨て、0への丸め、最も近いものへの丸め)のうちのどれを実行するかを区別する。よって、丸め動作制御フィールド1758は、命令ごとに丸めモードの変更を許容する。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め動作制御フィールド1750の内容が、そのレジスタ値をオーバーライドする。
メモリ・アクセスなし命令テンプレート――データ変換タイプ動作
メモリ・アクセスなしデータ変換タイプ動作1715命令テンプレートでは、ベータ・フィールド1754は、データ変換フィールド1754Bとして解釈され、その内容は、いくつかのデータ変換のうちのどれが実行されるべきか(たとえば、データ変換なし、スウィズル(swizzle)、ブロードキャスト)を区別する。
クラスAのメモリ・アクセス1720命令テンプレートの場合、アルファ・フィールド1752は、放逐ヒント(eviction hint)フィールド1752Bとして解釈され、その内容は、放逐ヒントのうちのどれが使用されるべきかを区別する(図17Aでは、時間的1752B.1および非時間的1752B.2がそれぞれ、メモリ・アクセス時間的1725命令テンプレートおよびメモリ・アクセス非時間的1730命令テンプレートについて指定される)。一方、ベータ・フィールド1754は、データ操作フィールド1754Cとして解釈され、その内容は、いくつかのデータ操作操作動作(プリミティブとしても知られる)のうちのどれが実行されるべきかを区別する(たとえば、操作なし、ブロードキャスト、ソースのアップコンバート、および宛先のダウンコンバート)。メモリ・アクセス1720命令テンプレートは、スケール・フィールド1760、および任意的に変位フィールド1762Aまたは変位スケール・フィールド1762Bを含む。
ベクトル・メモリ命令は、メモリからのベクトル・ロードおよびメモリへのベクトル・ストアを実行し、変換サポートがある。通常のベクトル命令と同様に、ベクトル・メモリ命令は、データ要素毎に、データをメモリから/メモリへ転送し、実際に転送される要素は、書き込みマスクとして選択されるベクトル・マスクの内容によって指定される。
メモリ・アクセス命令テンプレート――時間的
時間的データは、キャッシュから恩恵を得るために十分早く再利用される可能性が高いデータである。しかし、これはヒントであり、異なるプロセッサは、ヒントを完全に無視することを含む、異なる方法で、ヒントを実装することがある。
メモリ・アクセス命令テンプレート――非時間的
非時間的データは、第一レベル・キャッシュ内のキャッシュから恩恵を得るために十分早く再利用されそうにないデータであり、放逐のために優先されるべきである。しかし、これはヒントであり、異なるプロセッサは、ヒントを完全に無視することを含む、異なる方法で、ヒントを実装することがある。
クラスBの命令テンプレート
クラスBの命令テンプレートの場合、アルファ・フィールド1752は、書き込みマスク制御(Z)フィールド1752Cとして解釈され、その内容は、書き込みマスク・フィールド1770によって制御される書き込みマスキングがマージングであるべきか、ゼロ化であるべきかを区別する。
クラスBの非メモリ・アクセス1705命令テンプレートの場合、ベータ・フィールド1754の一部は、RLフィールド1757Aとして解釈され、その内容は、異なる増強動作タイプのうちのどれが実行されるべきかを区別する(たとえば、丸め1757A.1およびベクトル長(VSIZE)1757A.2は、それぞれ、メモリ・アクセスなし、書き込みマスク制御、部分的丸め制御タイプ動作1712命令テンプレートおよびメモリ・アクセスなし、書き込みマスク制御、VSIZEタイプ動作1717命令テンプレートについて指定される)。一方、ベータ・フィールド1754の残りの部分は、指定されたタイプの動作のうちのどれが実行されるべきかを区別する。メモリ・アクセスなし1705命令テンプレートでは、スケール・フィールド1760、変位フィールド1762A、および変位スケール・フィールド1762Bは存在しない。
メモリ・アクセスなし、書き込みマスク制御、部分的丸め制御タイプ動作1710命令テンプレートでは、ベータ・フィールド1754の残りの部分は、丸め動作フィールド1759Aとして解釈され、例外イベント報告は無効にされる(所与の命令は、いかなる種類の浮動小数点例外フラグも報告せず、いかなる浮動小数点例外ハンドラも発生させない)。
丸め動作制御フィールド1759A――ちょうど丸め動作制御フィールド1758と同様に、その内容は、一群の丸め動作のうちのどれを実行するかを区別する(たとえば、切り上げ、切り捨て、ゼロへの丸め、最も近いものへの丸め)。よって、丸め動作制御フィールド1759Aは、命令ごとに丸めモードの変更を許容する。プロセッサが丸めモードを指定するための制御レジスタを含む本発明のある実施形態では、丸め動作制御フィールド1750の内容は、そのレジスタ値をオーバーライドする。
メモリ・アクセスなし、書き込みマスク制御、VSIZEタイプ動作1717命令テンプレートでは、ベータ・フィールド1754の残りの部分は、ベクトル長フィールド1759Bとして解釈され、その内容は、いくつかのデータ・ベクトル長のうちのどれが実行対象とされるべきか(たとえば、128、256、または512バイト)を区別する。
クラスBのメモリ・アクセス1720命令テンプレートの場合、ベータ・フィールド1754の一部は、ブロードキャスト・フィールド1757Bとして解釈され、その内容は、ブロードキャスト・タイプ・データ操作動作が実行されるべきか否かを区別し、ベータ・フィールド1754の残りの部分は、ベクトル長フィールド1759Bとして解釈される。メモリ・アクセス1720命令テンプレートは、スケール・フィールド1760および任意的に、変位フィールド1762Aまたは変位スケール・フィールド1762Bを含む。
一般的ベクトル・フレンドリー命令フォーマット1700に関し、フォーマット・フィールド1740、基本動作フィールド1742、およびデータ要素幅フィールド1764を含む完全なオペコード・フィールド1774が示されている。完全なオペコード・フィールド1774がこれらのフィールドのすべてを含む一実施形態が示されているが、完全なオペコード・フィールド1774は、これらのフィールドのすべてはサポートしない実施形態においては、これらのフィールドの全部よりも少ないものを含む。完全なオペコード・フィールド1774は、動作コード(オペコード)を提供する。
増強動作フィールド1750、データ要素幅フィールド1764、および書き込みマスク・フィールド1770は、一般的ベクトル・フレンドリー命令フォーマットにおいて、これらの特徴が命令ごとに指定されることを許容する。
書き込みマスク・フィールドとデータ要素幅フィールドの組み合わせは、それらが異なるデータ要素幅に基づいてマスクを適用することを許容するという点で、タイプ付きの命令(typed instructions)を生成する。
クラスAおよびクラスB内に見出されるさまざまな命令テンプレートは、種々の状況において有益である。本発明のいくつかの実施形態において、プロセッサ内の異なるプロセッサまたは異なるコアは、クラスAのみ、クラスBのみ、または両方のクラスをサポートしてもよい。たとえば、汎用コンピューティングのために意図されている高性能汎用順序外コアは、クラスBのみをサポートしてもよく、主としてグラフィックスおよび/または科学的(スループット)コンピューティングのために意図されているコアは、クラスAのみをサポートしてもよく、両方のために意図されているコアは両方をサポートしてもよい(もちろん、両方のクラスからのテンプレートおよび命令の何らかの混合を有するが、両方のクラスからのテンプレートおよび命令のすべては有さないコアも本発明の範囲内である)。また、単一のプロセッサが複数のコアを含んでいてもよく、それらのコアはすべて同じクラスをサポートする、または異なるコアは異なるクラスをサポートする。たとえば、別個のグラフィックスおよび汎用コアを有するプロセッサでは、主としてグラフィックスおよび/または科学的コンピューティングのために意図されたグラフィックス・コアの一つはクラスAのみをサポートしてもよく、一方、汎用コアの一つまたは複数は、クラスBのみをサポートする汎用コンピューティングのために意図された順序外実行およびレジスタ名称変更を有する高性能汎用コアであってもよい。別個のグラフィックス・コアを有しない別のプロセッサは、クラスAおよびクラスBの両方をサポートする一つまたは複数の汎用順序内または順序外コアを含んでいてもよい。もちろん、一方のクラスからの特徴は、本開示の異なる実施形態においては他方のクラスでも実装されてもよい。高レベル言語で書かれたプログラムは、多様な異なる実行可能形式にされる(たとえば、ジャストインタイム・コンパイルされるまたは静的にコンパイルされる)。実行可能形式は:1)実行のためにターゲット・プロセッサによってサポートされるクラス(単数または複数)の命令のみを有する形式;または、2)すべてのクラスの命令の異なる組み合わせを使用して書かれた代替的な諸ルーチンを有しており、現在コードを実行しているプロセッサによってサポートされている命令に基づいて、実行すべきルーチンを選択する制御フロー・コードを有する形式を含む。
例示的な特定のベクトル・フレンドリー命令フォーマット
図18A~図18Cは、本発明の実施形態による、例示的な特定のベクトル・フレンドリー命令フォーマットを示すブロック図である。図18Aは、フィールドの位置、サイズ、解釈、および順序、ならびにそれらのフィールドのいくつかの値を指定するという意味で特定的である、特定のベクトル・フレンドリー命令フォーマット700を示す。特定のベクトル・フレンドリー命令フォーマット1800は、x86命令セットを拡張するために使用されてもよく、よって、フィールドのいくつかは、既存のx86命令セットおよびその拡張(たとえば、AVX)において使用されるものと類似しているか、または同一である。このフォーマットは、拡張をもつ既存のx86命令セットのプレフィックス・エンコード・フィールド、実オペコード・バイト・フィールド、MOD R/Mフィールド、SIBフィールド、変位(displacement)フィールド、および即値フィールドと整合したままである。図18A~図18Cからのフィールドが対応している図17A~図17Cからのフィールドが示されている。
説明の目的で、一般的ベクトル・フレンドリー命令フォーマット1700の文脈において、特定のベクトル・フレンドリー命令フォーマット1800を参照して本発明の実施形態を説明するが、本発明は、請求項に記載される場合を除いて、特定のベクトル・フレンドリー命令フォーマット1800に限定されないことが理解されるべきである。たとえば、一般的ベクトル・フレンドリー命令フォーマット1700は、さまざまなフィールドについて多様な可能なサイズを考えているが、特定のベクトル・フレンドリー命令フォーマット1800は、特定のサイズのフィールドを有するものとして示されている。具体例として、データ要素幅フィールド1764は、特定のベクトル・フレンドリー命令フォーマット1800においては1ビット・フィールドとして示されているが、本発明はそれに限定されない(すなわち、一般的ベクトル・フレンドリー命令フォーマット1700は、データ要素幅フィールド1764の他のサイズを考えている)。
一般的ベクトル・フレンドリー命令フォーマット1700は、図18Aに示される順序で以下に挙げるフィールドを含む。
EVEXプレフィックス(バイト0~3)1802――4バイト形式でエンコードされる。
フォーマット・フィールド1740(EVEXバイト0、ビット[7:0])――最初のバイト(EVEXバイト0)はフォーマット・フィールド1740であり、それは0x62(本開示の一実施形態においてベクトル・フレンドリー命令フォーマットを区別するために使用される一意的な値)を含む。
第2~第4バイト(EVEXバイト1~3)は、特定の機能を提供するいくつかのビット・フィールドを含む。
REXフィールド1805(EVEXバイト1、ビット[7-5])――EVEX.Rビット・フィールド(EVEXバイト1、ビット[7]-R)、EVEX.Xビット・フィールド(EVEXバイト1、ビット[6]-X)、およびEVEX.Bバイト1、ビット[5]-B)から構成される。EVEX.R、EVEX.X、およびEVEX.Bビット・フィールドは対応するVEXビット・フィールドと同じ機能を提供し、1の補数形式を用いてエンコードされる。すなわち、ZMM0は1111Bとしてエンコードされ、ZMM15は0000Bとしてエンコードされる。命令の他のフィールドは、当技術分野で知られているように、レジスタ・インデックスの下位3ビット(rrr、xxx、およびbbb)をエンコードし、よって、Rrrr、Xxxx、およびBbbbは、EVEX.R、EVEX.X、およびEVEX.Bを加えることによって形成されうる。
REX'フィールド1710――これはREX'フィールド1810の最初の部分であり、拡張された32レジスタ・セットの上位16または下位16のいずれかをエンコードするために使用されるEVEX.R'ビット・フィールド(EVEXバイト1、ビット[4]-R')である。本発明のある実施形態では、このビットは、以下に示す他のビットとともに、実オペコード・バイトは62であるBOUND命令から(周知のx86 32ビット・モードで)区別するためにビット反転フォーマットで格納されるが、MOD R/Mフィールド(後述)において、MODフィールドにおける11という値を受け入れない;本発明の代替的な実施形態は、このビットおよび下記の他のビットは反転フォーマットで格納されない。下位16レジスタをエンコードするために値1が使用される。換言すれば、R'RrrrはEVEX.R'、EVEX.R、および他のフィールドからの他のRRRを組み合わせることによって形成される。
オペコード・マップ・フィールド1815(EVEXバイト1、ビット[3:0]-mmmm)――その内容は、含意される先頭オペコード・バイト(0F、0F 38、または0F 3)をエンコードする。
データ要素幅フィールド1764(EVEXバイト2、ビット[7]-W)――これは、記法EVEX.Wで表わされる。EVEX.Wは、データ・タイプ(32ビットデータ要素または64ビットデータ要素のいずれか)の粒度(サイズ)を定義するために使用される。
EVEX.vvvv 1820(EVEXバイト2、ビット[6:3]-vvvv) EVEX.vvvvの役割は次のものを含んでいてもよい:1)EVEX.vvvvは、反転した(1の補数)形式で指定され第1のソース・レジスタ・オペランドをエンコードし、2つ以上のソース・オペランドをもつ命令について有効である;2)EVEX.vvvvは、ある種のベクトル・シフトについて1の補数形式で指定された宛先レジスタ・オペランドをエンコードする;または3)EVEX.vvvvは、いかなるオペランドもエンコードせず、そのフィールドはリザーブされ、1111bを含むべきである。よって、EVEX.vvvvフィールド1820は、反転した(1の補数)形式で格納された最初のソース・レジスタ指定子の下位4ビットをエンコードする。命令に依存して、指定子サイズを32個のレジスタに拡張するために、余分な異なるEVEXビット・フィールドが使用される。
EVEX.U 1768クラス・フィールド(EVEXバイト2、ビット[2]-U)――EVEX.U=0の場合、そのことは、クラスAまたはEVEX.U0を示し、EVEX.U=1の場合、そのことはクラスBまたはEVEX.U1を示す。
プレフィックス・エンコード・フィールド1825(EVEXバイト2、ビット[1:0]-pp)――基本動作フィールドのための追加ビットを提供する。EVEXプレフィックス・フォーマットでレガシーSSE命令のサポートを提供することに加え、これは、SIMDプレフィックスをコンパクト化する恩恵も有する(SIMDプレフィックスを表現するために1バイトを必要とするのではなく、EVEXプレフィックスは2ビットしか必要としない)。ある実施形態では、レガシー・フォーマットとEVEXプレフィックス・フォーマットの両方でSIMDプレフィックス(66H、F2H、F3H)を使用するレガシーSSE命令をサポートするために、これらのレガシーSIMDプレフィックスは、SIMDプレフィックス・エンコード・フィールド中にエンコードされ、ランタイムにおいて、デコーダのPLAに提供される前に、レガシーSIMDプレフィックスに展開される(よって、PLAは、これらのレガシー命令のレガシー・フォーマットとEVEXフォーマットの両方を、修正なしに実行することができる)。より新しい命令はオペコード拡張としてEVEXプレフィックス・エンコード・フィールドの内容を直接使うことができるが、ある種の実施形態は、整合性のために同様の仕方で展開するものの、これらのレガシーSIMDプレフィックスによって異なる意味が指定されることを許容する。代替的な実施形態は、2ビットのSIMDプレフィックス・エンコードをサポートし、よって展開を必要としないよう、PLAを再設計してもよい。
アルファ・フィールド1752(EVEXバイト3、ビット[7]-EH;EVEX.EH、EVEX.rs、EVEX.RL、EVEX.write mask control〔書き込みマスク制御〕、およびEVEX.Nとしても知られる;αでも示される)――前述のように、このフィールドはコンテキスト固有である。
ベータ・フィールド1754(EVEXバイト3、ビット[6:4]-SSS;EVEX.s2-0、EVEX.r2-0、EVEX.rr1、EVEX.LL0、EVEX.LLBとしても知られる;βββでも示される)――前述のように、このフィールドはコンテキスト固有である。
REX'フィールド1810――これはREX'フィールドの残りの部分であり、拡張された32レジスタ・セットの上位16または下位16のいずれかをエンコードするために使用されうるEVEX.V'ビット・フィールド(EVEXバイト3、ビット[3]-V')である。このビットはビット反転形式で格納される。値1は、下位16レジスタをエンコードするために使用される。換言すれば、V'VVVVは、EVEX.V'とEVEX.vvvvを組み合わせることによって形成される。
書き込みマスク・フィールド1770(EVEXバイト3、ビット[2:0]-kkk)――その内容は、前述したように、諸書き込みマスク・レジスタのうちのあるレジスタのインデックスを指定する。本発明のある実施形態では、特定の値EVEX.kkk=000は、その特定の命令について書き込みマスクが使用されないことを含意する特別な挙動を有する(これは、すべて1に固定構成にされた書き込みマスクまたはマスキング・ハードウェアをバイパスするハードウェアの使用を含む多様な仕方で実装されうる)。
実オペコード・フィールド1830(バイト4)は、オペコード・バイトとしても知られる。オペコードの一部はこのフィールドで指定される。
MOD R/Mフィールド1840(バイト5)は、MODフィールド1842、Regフィールド1844、およびR/Mフィールド1846を含む。前述のように、MODフィールド1842の内容は、メモリ・アクセス動作と非メモリ・アクセス動作を区別する。Regフィールド1844の役割は、2つの状況に要約できる:宛先レジスタ・オペランドまたはソース・レジスタ・オペランドのいずれかをエンコードすること、またはオペコード拡張として扱われ、いかなる命令オペランドをエンコードするためにも使用されないことである。R/Mフィールド1846の役割は、次を含んでいてもよい:メモリ・アドレスを参照する命令オペランドをエンコードすること、または宛先レジスタ・オペランドまたはソース・レジスタ・オペランドのいずれかをエンコードすること。
スケール、インデックス、ベース(Scale, Index, Base、SIB)バイト(バイト6)――前述のように、スケール・フィールド1850の内容はメモリ・アドレス生成のために使用される。SIB.xxx 1854およびSIB.bbb 18517――これらのフィールドの内容は、レジスタ・インデックスXxxxおよびBbbbに関して以前に言及されている。
変位フィールド1762A(バイト7~10)――MODフィールド1842が10を含む場合、バイト7~10は変位フィールド1762Aであり、これはレガシーの32ビット変位(disps32)と同じように機能し、バイト粒度で機能する。
変位因子フィールド1762B(バイト7)――MODフィールド1842が01を含む場合、バイト7は変位因子フィールド1762Bである。このフィールドの位置は、レガシーx86命令セット8ビット変位(disp8)と同じである。これはバイト粒度で機能する。disp8は符号拡張されているため、-128~127バイトのオフセットしかアドレッシングできない。64バイトのキャッシュラインに関しては、disp8は8ビットを使用するが、該8ビットは、4つの実際に有用な値-128、-64、0、および64のみに設定できる。しばしばより広い範囲が必要とされるため、disp32が使用されるが、disp32は4バイトを必要とする。disp8およびdisp32とは対照的に、変位因子フィールド1762Bは、disp8の再解釈であり、変位因子フィールド1762Bを使用するときは、実際の変位は、変位因子フィールドの内容にメモリ・オペランド・アクセスのサイズ(N)を乗算したものによって決定される。このタイプの変位はdisp8*Nと呼ばれる。これは、平均命令長を減少させる(変位のために単一バイトが使用されるが、レンジがはるかに大きい)。そのような圧縮された変位は、有効変位がメモリ・アクセスの粒度の倍数であるという仮定に基づいており、よって、アドレス・オフセットの冗長な下位ビットはエンコードされる必要はない。換言すれば、変位因子フィールド1762Bは、レガシーのx86命令セットの8ビット変位を置き換える。よって、変位因子フィールド1762Bは、disp8がdisp8*Nにオーバーロードされる点を唯一の例外として、x86命令セットの8ビット変位と同じ方法でエンコードされる(よって、ModRM/SIBエンコード規則に変更はない)。換言すれば、エンコード規則やエンコード長に変更はなく、ハードウェアによる変位値の解釈においてのみ変更がある(バイトごとのアドレス・オフセットを得るためにメモリ・オペランドのサイズによって変位をスケーリングする必要がある)。即値フィールド1772は、前述のように動作する。
完全なオペコード・フィールド
図18Bは、本開示のある実施形態による、完全なオペコード・フィールド1774を構成する、特定のベクトル・フレンドリー命令フォーマット1800の諸フィールドを示すブロック図である。具体的には、完全なオペコード・フィールド1774は、フォーマット・フィールド1740、基本動作フィールド1742、およびデータ要素幅(W)フィールド1764を含む。基本動作フィールド1742は、プレフィックス・エンコード・フィールド1825、オペコード・マップ・フィールド1815、および実オペコード・フィールド1830を含む。
レジスタ・インデックス・フィールド
図18Cは、本開示のある実施形態による、レジスタ・インデックス・フィールド1744を構成する、特定のベクトル・フレンドリー命令フォーマット1800の諸フィールドを示すブロック図である。具体的には、レジスタ・インデックス・フィールド1744は、REXフィールド1805、REX'フィールド1810、MODR/M.regフィールド1844、MODR/M.r/mフィールド1846、VVVVフィールド1820、xxxフィールド1854、およびbbbフィールド1856を含む。
増強動作フィールド
図18Dは、本開示のある実施形態による、増強動作フィールド1750を構成する、特定のベクトル・フレンドリー命令フォーマット1800の諸フィールドを示すブロック図である。クラス(U)フィールド1768が0を含むとき、それはEVEX.U0(クラスA 1768A)を示し、1を含むとき、それはEVEX.U1(クラスB 1768B)を示す。U=0でありMODフィールド1842が11(メモリ・アクセス動作なしを意味する)を含むときは、アルファ・フィールド1752(EVEXバイト3、ビット[7]-EH)は、rsフィールド1752Aとして解釈される。rsフィールド1752Aが1(丸め1752A.1)を含むときは、ベータ・フィールド1754(EVEXバイト3、ビット[6:4]SSS)は、丸め制御フィールド1754Aとして解釈される。丸め制御フィールド1754Aは、1ビットのSAEフィールド1756および2ビットの丸め動作フィールド1758を含む。rsフィールド1752Aが0(データ変換1752A.2)を含むとき、ベータ・フィールド1754(EVEXバイト3、ビット[6:4]SSS)は、3ビットのデータ変換フィールド1754Bとして解釈される。U=0でありMODフィールド1842が00、01、または10(メモリ・アクセス動作を意味する)を含むときは、アルファ・フィールド1752(EVEXバイト3、ビット[7]-EH)は、放逐ヒント(EH)・フィールド1752Bとして解釈され、ベータ・フィールド1754(EVEXバイト3、ビット[6:4]SSS)は、3ビットのデータ操作フィールド1754Cとして解釈される。
U=1であるときは、アルファ・フィールド1752(EVEXバイト3、ビット[7]-EH)は、書き込みマスク制御(Z)フィールド1752Cとして解釈される。U=1でありMODフィールド1842が11(メモリ・アクセス動作なしを意味する)を含むときは、ベータ・フィールド1754(EVEXバイト3、ビット[4]S0)の一部は、RLフィールド1757Aとして解釈され;1(丸め1757A.1)を含むときは、ベータ・フィールド1754の残り(EVEXバイト3、ビット[6-5]S2-1)は、丸め動作フィールド1759Aとして解釈され、一方、RLフィールド1757Aが0(VSIZE 1757.A2)を含むときは、ベータ・フィールド1754の残り(EVEXバイト3、ビット[6-5]S2-1)は、ベクトル長フィールド1759B(EVEXバイト3、ビット[6-5]L1-0)として解釈される。U=1でありMODフィールド1842が00、01、または10(メモリ・アクセス動作を意味する)を含むときは、ベータ・フィールド1754(EVEXバイト3、ビット[6:4]SSS)は、ベクトル長フィールド1759B(EVEXバイト3、ビット[6-5]L1-0)およびブロードキャスト・フィールド1757B(EVEXバイト3、ビット[4]B)として解釈される。
例示的なレジスタ・アーキテクチャ
図19は、本発明のある実施形態によるレジスタ・アーキテクチャ1900のブロック図である。図示した実施形態では、幅512ビットの32個のベクトル・レジスタ1910があり、これらのレジスタは、zmm0~zmm31として参照される。下位の16個のzmmレジスタの下位256ビットは、レジスタymm 0~16上にオーバーレイされる。下位の16個のzmmレジスタの下位128ビット(ymmレジスタの下位128ビット)は、レジスタxmm 0~15上にオーバーレイされる。特定のベクトル・フレンドリー命令フォーマット1800は、以下の表に示されるように、これらのオーバーレイされたレジスタ・ファイル上で動作する。
換言すれば、ベクトル長フィールド1759Bが、最大長と、一つまたは複数の他のより短い長さとの間で選択し、それぞれのかかるより短い長さは、前の長さの半分の長さであり、ベクトル長フィールド1759Bのない命令テンプレートは、最大ベクトル長で機能する。さらに、ある実施形態では、特定のベクトル・フレンドリー命令フォーマット1800のクラスB命令テンプレートは、パックされたまたはスカラーの単精度/倍精度浮動小数点データおよびパックされたまたはスカラーの整数データに対して機能する。スカラー動作は、zmm/ymm/xmmレジスタ内の最下位のデータ要素位置に対して実行される動作であり、より高位のデータ要素位置は、実施形態に依存して、命令の前と同じままにされるか、ゼロにされる。
書き込みマスク・レジスタ1915――図示した実施形態では、それぞれ64ビットのサイズの8つの書き込みマスク・レジスタ(k0~k7)がある。代替的な実施形態では、書き込みマスク・レジスタ1915は、サイズが16ビットである。前述のように、本発明のある実施形態では、ベクトル・マスク・レジスタk0は、書き込みマスクとして使用されることができず;通常k0を示すエンコードが書き込みマスクのために使用されるとき、それは0xFFFFの固定構成の書き込みマスクを選択し、事実上、その命令についての書き込みマスクを無効にする。
汎用レジスタ1925――図示した実施形態では、16個の64ビット汎用レジスタがあり、メモリ・オペランドをアドレス指定するために既存のx196アドレス指定モードとともに使用される。これらのレジスタは、RAX、RBX、RCX、RDX、RBP、RSI、RDI、RSP、およびR19~R15の名前で参照される。
スカラー浮動小数点スタック・レジスタ・ファイル(x87スタック)1945上には、MMXパックされた整数フラット・レジスタ・ファイル1950がエイリアスされる――図示した実施形態では、x87スタックは、x87命令セット拡張を使用して32/64/80ビット浮動小数点データに対してスカラー浮動小数点演算を実行するために使用される8要素のスタックであり、一方、MMXレジスタは、64ビットのパックされた整数データに対して演算を実行するために使用されるとともに、MMXレジスタとXMMレジスタとの間で実行されるいくつかの動作のためにオペランドを保持するために使用される。
本発明の代替的な実施形態は、より広いまたはより狭いレジスタを使用してもよい。さらに、本発明の代替的な実施形態は、より多くの、より少ない、または異なるレジスタ・ファイルおよびレジスタを使用してもよい。
例示的なコア・アーキテクチャ、プロセッサ、およびコンピュータ・アーキテクチャ
プロセッサ・コアは、異なる方法、異なる目的、および異なるプロセッサで実装されうる。たとえば、そのようなコアの実装は、1)汎用コンピューティングのために意図された汎用順序内コア、2)汎用コンピューティングのために意図された高性能汎用順序外コア、3)主にグラフィックスおよび/または科学的(スループット)コンピューティングのために意図された専用コアを含みうる。異なるプロセッサの実装は:1)汎用コンピューティングのために意図された一つまたは複数の汎用順序内コアおよび/または汎用コンピューティングのために意図された一つまたは複数の汎用順序外コアを含むCPUと、2)主にグラフィックスおよび/または科学用(スループット)のために意図された一つまたは複数の特殊目的コアを含むコプロセッサとを含んでいてもよい。そのような異なるプロセッサは、異なるコンピュータ・システム・アーキテクチャをもたらし、このアーキテクチャは、1)CPUとは別個のチップ上のコプロセッサ;2)CPUと同じパッケージ内の別個のダイ上のコプロセッサ;3)CPUと同じダイ上のコプロセッサ(この場合、そのようなコプロセッサは時に、統合グラフィックスおよび/または科学的(スループット)論理などの特殊目的論理として、または特殊目的コアとして称される)、4)同じダイ上に、記述されたCPU(時にアプリケーション・コアまたはアプリケーション・プロセッサと称される)、上述されたコプロセッサ、および追加的な機能を含んでいてもよいシステムオンチップを含みうる。次に、例示的なコア・アーキテクチャが記述され、その後、例示的なプロセッサおよびコンピュータ・アーキテクチャを記述する。
例示的なコア・アーキテクチャ
順序内および順序外のコア・ブロック図
図20Aは、本発明の実施形態による、例示的な順序内(in-order[インオーダー])パイプラインおよび例示的なレジスタ名称変更(register renaming)、順序外(out-of-order[アウトオブオーダー])発行/実行パイプラインの両方を示すブロック図である。図20Bは、本発明の実施形態によるプロセッサに含まれるべき、順序内アーキテクチャ・コアの例示的な実施形態および例示的なレジスタ名称変更、順序外発行/実行アーキテクチャ・コアの両方を示すブロック図である。図20A~図20Bの実線のボックスは、順序内パイプラインおよび順序内コアを示し、一方、破線のボックスの任意的な追加は、レジスタ名称変更、順序外発行/実行パイプラインおよびコアを示している。順序内側面が順序外側面のサブセットであることを考え、順序外側面が記述される。
図20Aでは、プロセッサ・パイプライン2000は、フェッチ段2002、長さデコード段2004、デコード段2006、割り当て段2008、名称変更段2010、スケジューリング(ディスパッチまたは発行としても知られる)段2012、レジスタ読み出し/メモリ読み出し段2014、実行段2016、書き戻し/メモリ書き込み段2018、例外処理段2022、およびコミット段2024を含む。
図20Bは、実行エンジン・ユニット2050に結合されたフロントエンド・ユニット2030を含むプロセッサ・コア2090を示し、両者はメモリ・ユニット2070に結合されている。コア2090は、縮小命令セット・コンピューティング(RISC)コア、複雑命令セット・コンピューティング(CISC)コア、超長命令語(VLIW)コア、またはハイブリッドまたは代替コア・タイプであってもよい。さらに別のオプションとして、コア2090は、たとえば、ネットワークまたは通信コア、圧縮エンジン、コプロセッサ・コア、汎用コンピューティング・グラフィックス処理ユニット(GPGPU)コア、グラフィックス・コア等のような特殊目的コアであってもよい。
フロントエンド・ユニット2030は、命令キャッシュ・ユニット2034に結合された分岐予測ユニット2032を含み、この分岐予測ユニットは、命令トランスレーションルックアサイドバッファ(TLB)2036に結合され、この命令TLBは命令フェッチ・ユニット2038に結合され、命令フェッチ・ユニットはデコード・ユニット2040に結合される。デコード・ユニット2040(またはデコーダ)は、命令をデコードし、出力として、一つまたは複数のマイクロオペレーション、マイクロコードのエントリーポイント、マイクロ命令、他の命令、または他の制御信号を生成することができ、これらは、もとの命令からデコードされるか、または他の仕方でもとの命令を反映するか、またはもとの命令から導出される。デコード・ユニット2040は、さまざまな異なる機構を使用して実装されてもよい。好適な機構の例は、ルックアップテーブル、ハードウェア実装、プログラマブル論理アレイ(PLA)、マイクロコード読み出し専用メモリ(ROM)などを含むが、これらに限定されない。ある実施形態では、コア2090は、(たとえば、デコード・ユニット2040内、またはさもなくばフロントエンド・ユニット2030内に)ある種のマクロ命令のためのマイクロコードを格納する、マイクロコードROMまたは他の媒体を含む。デコード・ユニット2040は、実行エンジン・ユニット2050内の名称変更/アロケータ・ユニット2052に結合される。
実行エンジン・ユニット2050は、退役(retirement[リタイア])ユニット2054に結合された名称変更/アロケータ・ユニット2052と、一つまたは複数のスケジューラ・ユニット2056のセットとを含む。スケジューラ・ユニット2056は、予約ステーション、中央命令ウインドウなどを含む、任意の数の異なるスケジューラを表わす。スケジューラ・ユニット2056は、物理レジスタ・ファイル・ユニット2058に結合される。物理レジスタ・ファイル・ユニット2058のそれぞれは、一つまたは複数の物理レジスタ・ファイルを表わし、そのうちの異なるものが、スカラー整数、スカラー浮動小数点、パックされた整数、パックされた浮動小数点、ベクトル整数、ベクトル浮動小数点、状態(たとえば、実行されるべき次の命令のアドレスである命令ポインタ)などといった一つまたは複数の異なるデータ・タイプを記憶する。ある実施形態では、物理レジスタ・ファイル・ユニット2058は、ベクトル・レジスタ・ユニット、書き込みマスク・レジスタ・ユニット、およびスカラー・レジスタ・ユニットを含む。これらのレジスタ・ユニットは、アーキテクチャ・ベクトル・レジスタ、ベクトル・マスク・レジスタ、および汎用レジスタを提供することができる。物理レジスタ・ファイル(複数可)ユニット2058は、レジスタ名称変更および順序外実行が実装されうるさまざまな仕方(たとえば、並べ替えバッファ(単数または複数)および退役レジスタ・ファイルを使用すること;将来のファイル(単数または複数)、履歴バッファ(単数または複数)、および退役レジスタ・ファイル(単数または複数)を使用すること;レジスタ・マップおよびレジスタ・プールを使用することなど)を示すために、退役ユニット2054とオーバーラップしている。退役ユニット2054および物理レジスタ・ファイル・ユニット2058は、実行クラスター(単数または複数)2060に結合される。実行クラスター(単数または複数)2060は、一つまたは複数の実行ユニット2062のセットと、一つまたは複数のメモリ・アクセス・ユニット2064のセットとを含む。実行ユニット2062は、さまざまな動作(たとえば、シフト、加算、減算、乗算)およびさまざまなタイプのデータ(たとえば、スカラー浮動小数点、パックされた整数、パックされた浮動小数点、ベクトル整数、ベクトル浮動小数点)に対して実行しうる。いくつかの実施形態は、特定の機能または機能のセットに専用のいくつかの実行ユニットを含んでいてもよいが、他の実施形態は、みなすべての機能を実行する一つだけの実行ユニットまたは複数の実行ユニットを含んでいてもよい。スケジューラ・ユニット(単数または複数)2056、物理レジスタ・ファイル・ユニット(単数または複数)2058、および実行クラスター(単数または複数)2060は、複数である可能性があるとして示されている。これは、ある種の実施形態はある種のタイプのデータ/動作のための別々のパイプラインを生成するためである(たとえば、スカラー整数パイプライン、スカラー浮動小数点/パックされた整数/パックされた浮動小数点/ベクトル整数/ベクトル浮動小数点パイプライン、および/または、メモリ・アクセス・パイプライン;そのそれぞれがそれら自身のスケジューラ・ユニット、物理レジスタ・ファイル・ユニット、および/または実行クラスターを有する――そして別個のメモリ・アクセス・パイプラインの場合、このパイプラインの実行クラスターだけがメモリ・アクセス・ユニット(単数または複数)2064を有するある種の実施形態が実装される)。また、別々のパイプラインが使用される場合には、これらのパイプラインのうちの一つまたは複数は、順序外発行/実行であってもよく、残りは順序内であってもよいことも理解しておくべきである。
メモリ・アクセス・ユニット2064のセットは、メモリ・ユニット2070に結合される。メモリ・ユニット2070は、レベル2(L2)キャッシュ・ユニット2076に結合されたデータ・キャッシュ・ユニット2074に結合されたデータTLBユニット2072を含む。ある例示的実施形態では、メモリ・アクセス・ユニット2064は、ロード・ユニット、記憶アドレス・ユニット、および記憶データ・ユニットを含んでいてもよく、これらのそれぞれは、メモリ・ユニット2070内のデータTLBユニット2072に結合される。命令キャッシュ・ユニット2034は、メモリ・ユニット2070内のレベル2(L2)キャッシュ・ユニット2076にさらに結合される。L2キャッシュ・ユニット2076は、一つまたは複数の他のレベルのキャッシュに結合され、最終的にはメインメモリに結合される。
例として、例示的なレジスタ名称変更、順序外発行/実行コア・アーキテクチャは、次のようにパイプライン2000を実装してもよい:1)命令フェッチ2038が、フェッチおよび長さデコード段2002および2004を実行し;2)デコード・ユニット2040が、デコード段2006を実行し;3)名称変更/アロケータ・ユニット2052が、割り当て段2008および名称変更段2010を実行し;4)スケジューラ・ユニット2056が、スケジュール段2012を実行し;5)物理レジスタ・ファイル・ユニット2058およびメモリ・ユニット2070が、レジスタ読み出し/メモリ読み出し段2014を実行し;実行クラスター2060が、実行段2016を実行し;6)メモリ・ユニット2070および物理レジスタ・ファイル・ユニット2058が、書き戻し/メモリ書き込み段2018を実行し;7)さまざまなユニットが、例外処理段2022に関与してもよく;8)退役ユニット2054および物理レジスタ・ファイル・ユニット2058が、コミット段2024を実行する。
コア2090は、本明細書に記載される命令を含む、一つまたは複数の命令セット(たとえば、x86命令セット(より新しいバージョンで追加されたいくつかの拡張を含む));カリフォルニア州サニーヴェールのMIPS TechnologiesのMIPS命令セット;カリフォルニア州サニーヴェールのARM HoldingsのARM命令セット(NEONのような任意的な追加的拡張を含む)をサポートすることができる。ある実施形態では、コア2090は、パックされたデータ命令セット拡張(たとえば、AVX1、AVX2)をサポートする論理を含み、それにより、多くのマルチメディア・アプリケーションによって使用される動作が、パックされたデータを使用して実行されることを許容する。
コアが、マルチスレッド(動作またはスレッドの2つ以上の並列セットを実行すること)をサポートしてもよく、時間スライスされたマルチスレッド、同時マルチスレッド(単一の物理コアが、その物理コアが同時にマルチスレッドしている各スレッドのための論理コアを提供する)、またはそれらの組み合わせ(たとえば、インテル(登録商標)Hyperthreading技術におけるように、時間スライスされたフェッチおよびデコードならびにその後の同時マルチスレッド)を含む多様な仕方でそうしうることを理解しておくべきである。
レジスタ名称変更(register renaming[レジスタ・リネーミング])は、順序外実行のコンテキストで記述されているが、レジスタ名称変更は、順序内アーキテクチャにおいて使用されてもよいことを理解しておくべきである。プロセッサの図示された実施形態は、別個の命令およびデータ・キャッシュ・ユニット2034/2074および共有されるL2キャッシュ・ユニット2076をも含んでいるが、代替的な実施形態は、命令およびデータの両方のための単一の内部キャッシュ、たとえば、レベル1(L1)の内部キャッシュまたは複数レベルの内部キャッシュを有していてもよい。いくつかの実施形態において、システムは、コアおよび/またはプロセッサの外部にある内部キャッシュおよび外部キャッシュの組み合わせを含んでいてもよい。あるいはまた、キャッシュのすべてがコアおよび/またはプロセッサの外部にあってもよい。
特定の例示的順序内コア・アーキテクチャ
図21A~図21Bは、チップ内のいくつかの論理ブロック(同じタイプおよび/または異なるタイプの他のコアを含む)のうちの一つであろう、より特定的な例示的な順序内コア・アーキテクチャのブロック図を示す。これらの論理ブロックは、アプリケーションに依存して、いくらかの固定機能論理、メモリI/Oインターフェース、および他の必要なI/O論理と、高帯域幅相互接続ネットワーク(たとえばリング・ネットワーク)を通じて通信する。
図21Aは、本発明の実施形態による、ダイ上相互接続ネットワーク2102への接続、およびレベル2(L2)キャッシュのローカル・サブセット2104とともに、単一プロセッサ・コアのブロック図である。ある実施形態では、命令デコーダ2100は、パックされたデータの命令セット拡張を有するx86命令セットをサポートする。L1キャッシュ2106は、スカラーおよびベクトル・ユニットへのキャッシュ・メモリへの低遅延アクセスを許容する。ある実施形態では(設計を簡略化するため)、スカラー・ユニット2108およびベクトル・ユニット2110は、別個のレジスタ・セット(それぞれスカラー・レジスタ2112およびベクトル・レジスタ2114)を使用し、それらの間で転送されるデータは、メモリに書き込まれ、次いでレベル1(L1)キャッシュ2106から読み戻されるが、本発明の代替的な実施形態は、異なるアプローチ(たとえば、単一のレジスタ・セットを使用するか、または書き込んで読み戻されることなく、2つのレジスタ・ファイルの間でデータが転送されることを許容する通信経路を含む)を使用してもよい。
L2キャッシュのローカル・サブセット2104は、プロセッサ・コア毎に一つの別々のローカル・サブセットに分割されるグローバルL2キャッシュの一部である。各プロセッサ・コアは、L2キャッシュの自分自身のローカル・サブセット2104への直接アクセス経路を有する。プロセッサ・コアによって読み出されたデータは、そのL2キャッシュ・サブセット2104に記憶され、他のプロセッサ・コアが自身のローカルL2キャッシュ・サブセットにアクセスするのと並列に、迅速にアクセスされることができる。プロセッサ・コアによって書き込まれたデータは、自分自身のL2キャッシュ・サブセット2104に記憶され、必要ならば、他のサブセットからフラッシュされる。リング・ネットワークは、共有されるデータのコヒーレンシーを保証する。リング・ネットワークは、プロセッサ・コア、L2キャッシュ、および他の論理ブロックのようなエージェントがチップ内で互いに通信することを許容するために双方向である。各リング・データ経路は、1方向につき2112ビット幅である。
図21Bは、本発明の実施形態による、図21Aにおけるプロセッサ・コアの一部の拡大図である。図21Bは、L1キャッシュ2104のL1データ・キャッシュ2106A部分と、ベクトル・ユニット2121およびベクトル・レジスタ2114に関するさらなる詳細とを含む。具体的には、ベクトル・ユニット2121は、整数、単精度フロート、倍精度フロート命令のうちの一つまたは複数を実行する16幅のベクトル処理ユニット(vector processing unit、VPU)である(16幅のALU 2128を参照)。VPUは、メモリ入力に対する、スウィズル(swizzling)・ユニット2120によるレジスタ入力のスウィズル、数値変換ユニット2122A~Bによる数値変換、および複製ユニット2124による複製をサポートする。書き込みマスク・レジスタ2126が、結果として生じるベクトル書き込みの叙述(predicating)を許容する。
図22は、本発明の実施形態による、2つ以上のコアを有してもよく、統合メモリ・コントローラを有してもよく、統合グラフィックスを有してもよいプロセッサ2200のブロック図である。図22の実線で囲まれたボックスは、単一コア2202A、システム・エージェント2210、一つまたは複数のバス・コントローラ・ユニット2216のセットを有するプロセッサ2200を示し、一方、破線で囲まれたボックスの任意的な追加は、複数コア2202A~N、システム・エージェント・ユニット2210内の一つまたは複数の統合メモリ・コントローラ・ユニット2214のセット、および特殊目的論理2208を有する代替的なプロセッサ2200を示す。
このように、プロセッサ2200の異なる実装は:1)CPUであって、特殊目的論理2208は統合されたグラフィックスおよび/または科学的(スループット)論理(これは一つまたは複数のコアを含んでいてもよい)であり、コア2202A~2202Nは一つまたは複数の汎用コア(たとえば、汎用順序内コア、汎用順序外コア、両者の組み合わせ)である、CPU;2)コプロセッサであっって、コア2202A~Nは、主にグラフィックスおよび/または科学的(スループット)のために意図されている多数の特殊目的コアである、コプロセッサ;および3)コプロセッサであって、コア2202A~Nは、多数の汎用順序内コアである、コプロセッサを含みうる。よって、プロセッサ2200は、汎用プロセッサ、コプロセッサ、または、特殊目的プロセッサ、たとえば、ネットワークまたは通信プロセッサ、圧縮エンジン、グラフィックス・プロセッサ、GPGPU(汎用グラフィックス処理ユニット)、高スループットの多集積コア(many integrated core、MIC)コプロセッサ(30個以上のコアを含む)、埋め込みプロセッサなどであってもよい。プロセッサは、一つまたは複数のチップ上に実装されてもよい。プロセッサ2200は、たとえば、BiCMOS、CMOS、またはNMOSなどの多くのプロセス技術のいずれかを使用して、一つまたは複数の基板の一部であってもよく、および/または一つまたは複数の基板上に実装されてもよい。
メモリ階層は、コア内の一つまたは複数のレベルのキャッシュと、セットまたは一つまたは複数の共有されるキャッシュ・ユニット2206と、統合メモリ・コントローラ・ユニット2214のセットに結合された外部メモリ(図示せず)とを含む。共有されるキャッシュ・ユニット2206のセットは、レベル2(L2)、レベル3(L3)、レベル4(L4)、または他のレベルのキャッシュ、最終レベル・キャッシュ(LLC)、および/またはそれらの組み合わせのような、一つまたは複数の中間レベル・キャッシュを含んでいてもよい。ある実施形態では、リング・ベースの相互接続ユニット2212は、統合グラフィックス論理2208、共有されるキャッシュ・ユニットのセット2206、およびシステム・エージェント・ユニット2210/統合メモリ・コントローラ・ユニット(単数または複数)2214を相互接続するが、代替的な実施形態は、そのようなユニットを相互接続するために、いくつもある周知の技術を使用してもよい。ある実施形態では、一つまたは複数のキャッシュ・ユニット2206とコア2202-A~Nとの間でコヒーレンシーが維持される。
いくつかの実施形態では、コア2202A~Nのうちの一つまたは複数は、マルチスレッド可能である。システム・エージェント2210は、コア2202A~Nを協調させ、動作させるコンポーネントを含む。システム・エージェント・ユニット2210は、たとえば、電力制御ユニット(PCU)および表示ユニットを含んでいてもよい。PCUは、コア2202A~Nおよび統合グラフィックス論理2208の電力状態を制御するために必要とされる論理および構成要素であってもよいし、それらを含んでいてもよい。表示ユニットは、一つまたは複数の外部接続されたディスプレイを駆動するためのものである。
コア2202A~Nは、アーキテクチャ命令セットに関して均一または不均一であってもよく、すなわち、コア2202A~Nのうちの2つ以上が同じ命令セットを実行することができてもよく、他のコアは、その命令セットのサブセットのみを、または異なる命令セットを実行することができてもよい。
例示的なコンピュータ・アーキテクチャ
図23~図24は、例示的なコンピュータ・アーキテクチャのブロック図である。ラップトップ、デスクトップ、ハンドヘルドPC、パーソナル・デジタル・アシスタント、エンジニアリング・ワークステーション、サーバー、ネットワーク装置、ネットワーク・ハブ、スイッチ、組み込みプロセッサ、デジタル信号プロセッサ(DSP)、グラフィックス装置、ビデオ・ゲーム装置、セットトップボックス、マイクロコントローラ、携帯電話、ポータブル・メディア・プレーヤー、ハンドヘルド装置、およびさまざまな他の電子装置のための、当技術分野で知られている他のシステム設計および構成も好適である。一般に、本明細書に開示されているプロセッサおよび/または他の実行論理を組み込むことができる非常に多様なシステムまたは電子装置が、一般に好適である。
ここで図23を参照すると、本発明のある実施形態によるシステム2300のブロック図が示されている。システム2300は、コントローラ・ハブ2320に結合された一つまたは複数のプロセッサ2310、2315を含んでいてもよい。ある実施形態では、コントローラ・ハブ2320は、グラフィックス・メモリ・コントローラ・ハブ(GMCH)2390および入出力ハブ(IOH)2350(これは別個のチップ上にあってもよい)を含み、GMCH 2390は、メモリおよびグラフィックス・コントローラを含み、それにメモリ2340およびコプロセッサ2345が結合されている;IOH 2350は、入出力(I/O)装置2360をGMCH 2390に結合する。あるいはまた、メモリ・コントローラおよびグラフィックス・コントローラの一方または両方が、(本明細書に記載されるような)プロセッサ内に統合され、メモリ2340およびコプロセッサ2345は、プロセッサ2310に直接結合され、コントローラ・ハブ2320は、IOH 2350と単一のチップ内にある。
追加的なプロセッサ2315の任意的な性質は、図23では破線で示されている。各プロセッサ2310、2315は、本明細書に記載される処理コアの一つまたは複数を含んでいてもよく、プロセッサ1100の何らかのバージョンであってもよい。
メモリ2340は、たとえば、動的ランダムアクセスメモリ(DRAM)、相変化メモリ(PCM)、またはこれら2つの組み合わせであってもよい。少なくとも一つの実施形態については、コントローラ・ハブ2320は、フロントサイド・バス(FSB)のようなマルチドロップ・バス、QuickPath Interconnect(QPI)のようなポイントツーポイント・インターフェース/相互接続、または同様の接続2395を介して、プロセッサ2310、2315と通信する。
ある実施形態では、コプロセッサ2345は、たとえば、高スループットMICプロセッサ、ネットワークまたは通信プロセッサ、圧縮エンジン、グラフィックス・プロセッサ、GPGPU、埋め込みプロセッサ等のような特殊目的プロセッサである。ある実施形態では、コントローラ・ハブ2320は、統合グラフィック・アクセラレータを含んでいてもよい。
アーキテクチャ、マイクロアーキテクチャ、熱、電力消費特性などを含む性能指標のスペクトルに関して、物理資源2310、2315間には、多様な相違がありうる。
ある実施形態では、プロセッサ2310は、一般的なタイプのデータ処理動作を制御する命令を実行する。命令内に埋め込まれるのは、コプロセッサ命令であってもよい。プロセッサ2310は、これらのコプロセッサ命令を、取り付けられたコプロセッサ2345によって実行されるべきタイプであると認識する。よって、プロセッサ2310は、これらのコプロセッサ命令(またはコプロセッサ命令を表わす制御信号)を、コプロセッサ・バスまたは他の相互接続上でコプロセッサ2345に対して発行する。コプロセッサ2345は、受信されたコプロセッサ命令を受け入れ、実行する。
ここで図24を参照すると、本開示のある実施形態によるSoC 2400のブロック図が示されている。図22における同様の要素は、同様の参照番号を帯びている。また、破線のボックスは、より高度なSoCでの任意的な機能である。図24において、相互接続ユニット(単数または複数)2402は:一つまたは複数のコア202A~Nのセットおよび共有されるキャッシュ・ユニット(単数または複数)2206を含むアプリケーション・プロセッサ2410と;システム・エージェント・ユニット2210と;バス・コントローラ・ユニット(単数または複数)2216と;統合されたメモリ・コントローラ・ユニット(単数または複数)2214と;統合されたグラフィックス論理、画像プロセッサ、オーディオ・プロセッサ、およびビデオ・プロセッサを含みうるセットまたは一つまたは複数のコプロセッサ2420と;静的ランダムアクセスメモリ(SRAM)ユニット2430と;直接メモリ・アクセス(DMA)ユニット2432と;一つまたは複数の外部ディスプレイに結合するための表示ユニット2440とに結合される。ある実施形態では、コプロセッサ(単数または複数)2420は、たとえば、ネットワークまたは通信プロセッサ、圧縮エンジン、GPGPU、高スループットMICプロセッサ、埋め込みプロセッサなどの特殊目的プロセッサを含む。
本明細書に開示される機構の実施形態は、ハードウェア、ソフトウェア、ファームウェア、またはそのような実装アプローチの組み合わせで実装されてもよい。本発明の実施形態は、少なくとも一つのプロセッサ、記憶システム(揮発性および不揮発性メモリおよび/または記憶素子を含む)、少なくとも一つの入力装置、および少なくとも一つの出力装置を有するプログラマブルシステム上で実行されるコンピュータプログラムまたはプログラムコードとして実装されてもよい。
プログラムコードは、本明細書に記載される機能を実行し、出力情報を生成するために、入力命令に適用されうる。出力情報は、既知の仕方で、一つまたは複数の出力装置に適用されうる。本願の目的のためには、処理システムは、たとえば、デジタル信号プロセッサ(DSP)、マイクロコントローラ、特定用途向け集積回路(ASIC)、またはマイクロプロセッサなどのプロセッサ有する任意のシステムを含む。
プログラムコードは、処理システムと通信するために、高レベルの手続き型またはオブジェクト指向型のプログラミング言語で実装されてもよい。プログラムコードはまた、所望であれば、アセンブリ言語または機械語で実装されてもよい。実際、本明細書に記載の機構の範囲は、いかなる特定のプログラミング言語に限定されるものでもない。いずれの場合においても、言語は、コンパイルされる言語またはインタープリットされる言語でありうる。
少なくとも一つの実施形態の一つまたは複数の側面は、プロセッサ内のさまざまな論理を表わす機械読み取り可能媒体上に記憶された代表的な命令によって実装されてもよく、該命令は、機械によって読み取られたときに、機械に、本明細書に記載された技術を実行するために論理を製造させる。「IPコア」として知られるそのような表現は、有体の機械可読媒体上に記憶され、さまざまな顧客または製造施設に供給されて、実際に論理またはプロセッサを作る製造機械にロードされてもよい。
そのような機械可読記憶媒体は、限定なしに、機械または装置によって製造または形成される物品の非一時的な有体な構成を含んでいてもよく、かかる構成は、記憶媒体、たとえばハードディスク、フロッピーディスク、光ディスク、コンパクトディスク読み出し専用メモリ(CD-ROM)、書き換え可能コンパクトディスク(CD-RW)、磁気光学ディスクを含む他の任意の型のディスク、半導体デバイス、たとえば読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、たとえば動的ランダムアクセスメモリ(DRAM)、静的ランダムアクセスメモリ(SRAM)、消去可能なプログラマブル読み出し専用メモリ(EPROM)、フラッシュメモリ、電気的に消去可能なプログラマブル読み出し専用メモリ(EEPROM)、相変化メモリ(PCM)、磁気カードまたは光学カード、または電子的な命令を記憶するのに好適な他の任意のタイプの媒体を含む。
よって、本開示の実施形態は、本明細書に記載される構造、回路、装置、プロセッサ、および/またはシステム特徴を定義する、ハードウェア記述言語(HDL)のような、命令を含む、または設計データを含む、非一時的な、有体の機械可読媒体をも含む。そのような実施形態は、プログラム・プロダクトと称されることもある。
エミュレーション(バイナリー変換、コード・モーフィングなど)
いくつかの場合には、ソース命令セットからの命令をターゲット命令セットに変換するために命令変換器が使用されてもよい。たとえば、命令を、コアによって処理されるべき一つまたは複数の他の命令に翻訳(たとえば、静的なバイナリー変換、動的コンパイルを含む動的なバイナリー変換を使用して)、モーフィング、エミュレートまたは他の仕方で変換してもよい。命令変換器は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの組み合わせで実装されうる。命令変換器は、オンプロセッサ、オフプロセッサ、または部分的にオンプロセッサ、部分的にオフプロセッサであってもよい。
図25は、本発明の実施形態による、ソース命令セットにおけるバイナリー命令を、ターゲット命令セットにおけるバイナリー命令に変換するためのソフトウェア命令変換器の使用を対照するブロック図である。図示した実施形態では、命令変換器はソフトウェア命令変換器であるが、代替的に、命令変換器はソフトウェア、ファームウェア、ハードウェア、またはそれらのさまざまな組み合わせで実装されてもよい。図25は、高レベル言語2502におけるプログラムがx86コンパイラ2504を用いてコンパイルされて、少なくとも一つのx86命令セット・コア2516をもつプロセッサによってネイティブに実行されうるx86バイナリー・コード2506を生成しうることを示している。少なくとも一つのx86命令セット・コア2516をもつプロセッサは、少なくとも一つのx86命令セット・コアをもつインテル・プロセッサと実質的に同じ結果を達成するために、少なくとも一つのx86命令セット・コアをもつインテル・プロセッサと実質的に同じ機能を実行できる任意のプロセッサを表わす。それは、(1)インテルx86命令セット・コアの命令セットの実質的な部分または(2)少なくとも一つのx86命令セット・コアをもつインテル・プロセッサ上で動作するようにターゲットされたアプリケーションまたは他のソフトウェアのオブジェクト・コード・バージョンを、互換的に実行するまたは他の仕方で処理することによる。x86コンパイラ2504は、追加的なリンケージ処理を用いてまたは用いずに、少なくとも一つのx86命令セット・コア2516をもつプロセッサ上で実行できるx86バイナリー・コード2506(たとえば、オブジェクトコード)を生成するように動作可能なコンパイラを表わす。同様に、図25は、高レベル言語2502におけるプログラムが、代替的な命令セット・コンパイラ2508を用いてコンパイルされて、少なくとも一つのx86命令セット・コア2514のないプロセッサ(たとえば、カリフォルニア州サニーヴェールのMIPS TechnologiesのMIPS命令セットを実行する、および/またはカリフォルニア州サニーヴェールのARM HoldingsのARM命令セットを実行するコアをもつプロセッサ)によってネイティブに実行されうる代替的な命令セット・バイナリー・コード2510を生成しうることを示す。命令変換器2512は、x86のバイナリー・コード2506を、x86の命令セット・コア2514のないプロセッサによってネイティブに実行されうるコードに変換するために使用される。この変換されたコードは、代替命令セット・バイナリー・コード2510と同じである可能性は高くない。なぜなら、これができる命令変換器は作成することが困難であるからである。しかしながら、変換されたコードは、一般的な動作を達成し、代替命令セットからの命令で構成される。よって、命令変換器2512は、エミュレーション、シミュレーションまたは他の何らかのプロセスを通じて、x86命令セット・プロセッサもしくはコアをもたないプロセッサもしくは他の電子装置が、x86バイナリー・コード2506を実行することを許容するソフトウェア、ファームウェア、ハードウェア、またはそれらの組み合わせを表わす。
プロセッサにおけるスロットリング閾値の調整
ここで図26を参照すると、一つまたは複数の実施形態によるシステム2600のブロック図が示されている。いくつかの実施形態では、システム2600は、電子装置またはコンポーネントのすべてまたは一部であってもよい。たとえば、システム2600は、セルラー電話、コンピュータ、サーバー、ネットワーク装置、システムオンチップ(SoC)、コントローラ、無線トランシーバ、電源ユニットなどであってもよい。さらに、いくつかの実施形態では、システム2600は、データセンター、コンピューティングクラスターなどのような、関連したまたは相互接続された装置のグループの一部であってもよい。
図26に示されるように、システム2600は、システムメモリ2605および電源2650に動作上結合されたプロセッサ2610を含んでいてもよい。さらに、図26には示されていないが、システム2600は、他の構成要素を含んでいてもよい。一つまたは複数の実施形態において、システムメモリ2605は、任意のタイプのコンピュータメモリ(たとえば、動的ランダムアクセスメモリ(DRAM)、静的ランダムアクセスメモリ(SRAM)、不揮発性メモリ(NVM)、DRAMとNVMの組み合わせなど)で実装できる。電源2650は、プロセッサ2610に電力を提供してもよい。
一つまたは複数の実施形態において、プロセッサ2610は、ハードウェア処理装置(たとえば、中央処理装置(CPU)、システムオンチップ(SoC)など)であってもよい。図示のように、プロセッサ2610は、一つまたは複数の処理エンジン2620(本明細書では「コア」とも呼ばれる)および電力制御ユニット2630を含むことができる。各処理エンジン2620は、ソフトウェア命令を実行することができる。
一つまたは複数の実施形態において、電力制御ユニット2630は、処理エンジン2620の電力状態を制御するためのプロセッサ2610のハードウェアユニットであってもよい。たとえば、電力制御ユニット2630は、動作周波数、電圧レベルなどを制御することができる。構成記憶2640は、電力状態を制御するために電力制御ユニット2630によって使用されるデータを含んでいてもよい。
図示のように、各処理エンジン2620は、スロットリング論理2625を含んでいてもよい。スロットリング論理2625は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの組み合わせで実装されてもよい。一つまたは複数の実施形態において、スロットリング論理2625は、過熱、ハードウェア損傷などのような潜在的に有害な状況を回避するために、処理エンジン2620による電力消費を制限することができる。たとえば、スロットリング論理2625は、最悪の場合の電力消費レベルを引き起こすことができ、それにより処理エンジン2620に損傷を引き起こしうる悪意のあるアプリケーションに対する「電力ウィルス(power virus)」保護を提供しうる。いくつかの例では、スロットリング論理2625によって提供される保護は、たとえば、プロセッサのさまざまなコアの間での電力の配分などのオペレーティングシステムの電力管理技術によって扱われる他の電力管理問題とは独立であってもよい。
一つまたは複数の実施形態において、スロットリング論理2625は、処理エンジン2620内の実行イベントを追跡してもよく、実行イベントの推定されるエネルギー消費を反映するスコアを生成してもよい。いくつかの実施形態において、生成されるスコアは、さまざまな実行イベントの容量重み(capacitance weights)に基づく移動平均であってもよい。スロットリング論理2625は、生成されたスコアがスロットリング閾値を超えるか否かを判定し、そうであれば、処理エンジン2620の動作周波数をスロットリングしてもよい(たとえば、周波数を20%、50%、最小周波数まで、など低下させる)。
一つまたは複数の実施形態において、スロットリング論理2625は、処理エンジン2620におけるスロットリング・イベントの数を追跡してもよく、スロットリング・イベントの数に基づいて閾値を動的に調整してもよい。このようにして、スロットリング論理2625によって実行されるスロットリングは、実際にはスロットリングを必要としない状況においてトリガーされることを防止または低減するために動的に調整されてもよい。よって、スロットリング論理2625は、スロットリングによる不必要なパフォーマンス影響を低減してもよい。さらに、スロットリング論理2625によって実行されるスロットリングは、実行の制御および/またはシステム2600のハードウェア構成要素(たとえば、電源2650、電力制御ユニット2630などの動作パラメータ)の指定において柔軟性を提供するように、動的に調整されてもよい。スロットリング論理2625に関連するさまざまな側面が、図27~図31を参照して以下に記載される。
ここで図27を参照すると、一つまたは複数の実施形態による、例示的なシステム2700の図が示されている。システム2700は、概して、スロットリング論理2625(図26に示される)の例示的実装に対応してもよい。一つまたは複数の実施形態において、システム2700は、マルチコアプロセッサ(たとえば、図26に示されるプロセッサ2610)に含まれてもよい。いくつかの実装では、システム2700の構成要素は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装されてもよい。たとえば、いくつかの実施形態では、コンポーネント2720~2760は、プロセッサの順序外(out of order、OOO)回路2710に含まれてもよい。
図27に示されるように、システム2700は、処理コンポーネント(たとえば、図26に示される処理エンジン2620)における実行イベントを監視するイベント追跡器2720を含んでいてもよい。いくつかの例では、イベント追跡器2720は、命令、操作(たとえば、「uop」)などの実行アクティビティを追跡(すなわち、モニタリング)するために、一つまたは複数のカウンタまたは他の技法を使用してもよい。そのような追跡は、スライディング時間窓(すなわち、時間的に前方に移動している一定サイズの区間)のような定義された時間期間にわたって実行されてもよい。いくつかの例では、イベント・追跡器2720によって追跡されるイベントは、以下のイベント・タイプを含みうる:FMA、SIMD、LOAD、STORE、FMA ADD、FAST ADDER、FP16、TMUL、BPNID、DSBQREAD、BPQREAD、Mite覚醒、IDQ読み取り、MLC要求ヒット、MLC置換、およびその他のイベント。
一つまたは複数の実施形態において、イベント追跡器2720は、容量計算器2730にイベント情報(たとえば、イベント数、ビット幅など)を提供してもよい。いくつかの実施形態では、容量計算器(capacitance calculator)2730は、追跡されたイベントに関連する動的容量重み2740を取得するか、または別の仕方で決定してもよい。たとえば、容量計算器2730は、各イベント・インスタンスに、イベントのタイプに対応する容量重み2740を乗算してもよい。いくつかの実施形態では、相対的により大きい容量重み2740を有するイベントは、実行中に相対的により大きい電力消費を必要とする動作(たとえば、ベクトル浮動小数点演算、ロード、ストアなど)を含んでいてもよい。さらに、相対的により小さな容量重み2740を有するイベントは、実行中に相対的により小さな電力消費を必要とする動作を含んでいてもよい。
いくつかの実施形態では、容量計算器2730は、いくつかのイベントの容量重み2735を、これらのイベントのビット幅に基づいて調整してもよい。たとえば、所与の動作について、512ビットバージョンの容量重み2740は、64ビットバージョンの容量重み2740よりも大きいように調整されてもよい。いくつかの実施形態において、追跡されるイベントのサブセットは、イベントのビット幅に応じたスケーリング因子によって調整されてもよい。いくつかの例では、スケーリング因子によって調整される、追跡されるイベントのサブセットは、以下のイベント・タイプを含んでいてもよい:FMA、SIMD、LOAD、STORE、FMA ADD、FAST ADDER、およびFP16。
一つまたは複数の実施形態において、容量計算器2730は、追跡されたイベントの動的容量値を合計してもよく、スライディング窓にわたる平均総容量を決定してもよい。たとえば、容量計算器2730は、固定された数の最近のクロックサイクルにおいて発生したイベントの容量重み2740を合計してもよく、この合計をサイクル数で除して、クロックサイクル当たりの平均総容量を決定してもよい。いくつかの実施形態において、容量計算器2730は、平均容量値(たとえば、クロックサイクル当たりの平均総容量)を比較器2750に提供してもよい。
一つまたは複数の実施形態において、比較器2750は、平均容量値がスロットリング閾値(単数または複数)2760を超えるかどうかを判定してもよい。もしそうなら、比較器2750は、スロットリング・ユニット2770に処理エンジン2620の動作周波数をスロットリングさせてもよい。たとえば、スロットリング・ユニット2770は、動作周波数を、指定された周波数レベル(たとえば、最小周波数)まで、所与の割合または比率だけ(たとえば、20%の低減)など、低減してもよい。いくつかの実施形態では、比較器2750(またはスロットリング・ユニット2770)は、各スロットリング・イベント(すなわち、周波数スロットリングの各インスタンス)の指示2755を閾値チューナ2780に提供してもよい。
一つまたは複数の実施形態において、閾値チューナ2780は、スロットリング・イベントの数をカウントするか、または他の仕方で決定してもよく、スロットリング・イベントの数に基づいて閾値2760を動的に調整してもよい。たとえば、スロットリング・イベントの数が最大値を超える場合、閾値チューナ2780は、特定の量または割合だけ閾値2760を増加させてもよい(たとえば、3%、5%、8%などの増加)。別の例では、スロットリング・イベントの数が最小値を下回る場合、閾値チューナ2780は、所与の量だけ閾値2760を減少させてもよい(たとえば、3%、5%、8%などの減少)。いくつかの例では、閾値チューナ2780は、閾値2760とともに他の動作パラメータを調整してもよい。
一つまたは複数の実施形態において、システム2700は、複数のスロットリング閾値2760を含んでいてもよく、スロットリング閾値2760の少なくとも一部は、実行イベントの相異なるビット幅(たとえば、64ビット、512ビットなど)に関連付けられる。たとえば、比較器2750は、スライディング窓内のイベントのビット幅を(たとえば、イベント追跡器2720によって提供される情報から)決定し、そのタイプのイベント・タイプおよびイベントのビット幅に関連付けられた特定の閾値2760を選択してもよい。いくつかの例では、スロットリング閾値2760のベースライン値(すなわち、閾値チューナ2780による調整の前の値)は、システム2700の製造者によって(たとえば、プロセッサ製造中の試験に基づいて)提供されてもよい。いくつかの例では、各スロットリング閾値2760は、特定のビット幅のイベントについての最大許容容量値に対応してもよい。いくつかの実施形態では、容量重み2740および/またはスロットリング閾値2760は、ハードウェアレジスタ、不揮発性メモリデバイスなどに格納されてもよい。
一つまたは複数の実施形態において、スロットリング閾値2760は、最大電流保護(IccP)ライセンスの発行に応答してリフレッシュされてもよい。たとえば、図26を参照すると、電力制御ユニット2630は、さまざまな処理エンジン2620からの要求を受け取ることがあり、各要求が特定の電流レベルを指定する。これらの要求に応答して、電力制御ユニット2630は、IccPライセンスを発行してもよい。該IccPライセンスは、処理エンジン2620がIccPライセンスにおいて指定された最大電流レベルで動作することを許容する。このようにして、IccPライセンスは、スロットリング論理2625によって提供されるスロットリングとは別の電力保護を提供することができる。いくつかの例では、電力制御ユニット2630が処理エンジン2620に対してIccPライセンスを発行すると、その処理エンジン2620に関連するスロットリング閾値(単数または複数)2760も(たとえば、電力制御ユニット2630によって)更新されてもよい。
いくつかの実施形態では、電力制御ユニット2630は、IccPライセンスを付与する通信において、スロットリング閾値2760をリフレッシュしてもよい。たとえば、図31を参照すると、一つまたは複数の実施形態による例示的なデータ・フォーマット3100が示されている。データ・フォーマット3100は、IccPライセンスを付与するために、電力制御ユニットからのメッセージにおいて使用されうる。図示のように、データ・フォーマット3100は、ヘッダ・フィールド3110、スロットル・エネルギー・フィールド3120、スロットリング閾値フィールド3130、ローカル・ヒステリシス・サイズ・フィールド3140、有効インジケータ・フィールド3150、およびIccPライセンス付与フィールド3160を含んでいてもよい。データ・フォーマット3100は、例のために与えられており、実施形態を限定することは意図されていないことに留意されたい。たとえば、データ・フォーマット3100は、追加的なフィールド、より少数のフィールド、異なるフィールドなどを含むように修正されてもよいことが考えられている。
ここで図28を参照すると、一つまたは複数の実施形態による、スロットリングのための方法2800のフロー図が示される。さまざまな実施形態において、方法2800は、ハードウェア(たとえば、処理装置、回路、専用論理、プログラマブル論理、マイクロコードなど)、ソフトウェア(たとえば、処理装置上で実行される命令)、またはそれらの組み合わせを含みうる処理論理によって実行されてもよい。いくつかの実装では、方法2800は、図26~図17に示される一つまたは複数の構成要素(たとえば、スロットリング論理2625、システム2700など)を使用して実行されてもよい。ファームウェアまたはソフトウェアの実施形態では、方法2800は、光学、半導体、または磁気記憶デバイスなどの非一時的な機械読み取り可能媒体に記憶されたコンピュータ実行命令によって実装されてもよい。機械可読媒体は、少なくとも1つの機械によって使用される場合、前記少なくとも1つの機械に、方法を実行するための少なくとも1つの集積回路を製造させるデータを記憶することができる。例示のために、方法2800に含まれるアクションは、一つまたは複数の実施形態による例を示す図26~図27を参照して以下に説明されうる。しかしながら、本明細書で論じられるさまざまな実施形態の範囲は、この点に関して限定されない。
ブロック2810は、処理エンジンにおける実行イベントの検出を含んでいてもよい。たとえば、図26~図27を参照すると、イベント追跡器2720が、処理エンジン2620における実行イベント(たとえば、実行される命令、操作など)を追跡してもよい。
ブロック2820は、それらの実行イベントについての容量値を合計することを含んでいてもよい。ブロック2830は、時間窓にわたる平均を計算することを含んでいてもよい。たとえば、図26~図27を参照すると、容量計算器2730は、追跡されたイベントに関連する動的容量重み2740を決定してもよく、各イベント・インスタンスに、対応する容量重み2740を乗算してもよい。さらに、容量計算器2730は、追跡されたイベントの動的容量値を合計してもよく、スライディング窓にわたる平均総容量を決定してもよい。
菱形2840は、平均が閾値を超えるかどうかを判定することを含んでいてもよい。菱形2840において、平均が閾値を超えないと判断される場合、方法2800は、ブロック2810に戻ってもよい(すなわち、処理エンジンにおける実行イベントの検出を継続する)。しかしながら、菱形2840において平均が閾値を超えることが決定される場合、方法2800は、ブロック2850に続いてもよい。たとえば、図27を参照すると、比較器2750は、平均容量値がスロットリング閾値2760を超えるかどうかを判定してもよい。
ブロック2850は、処理エンジンの動作周波数をスロットリングすることを含んでいてもよい。たとえば、図27を参照すると、比較器2750が平均容量値がスロットリング閾値2760を超えると判定することに応答して、スロットリング・ユニット2770は、処理エンジン2620の動作周波数をスロットリングする(すなわち、低減する)ことができる。
ブロック2860は、スロットリング・イベント・カウントをインクリメントすることを含んでいてもよい。たとえば、図27を参照すると、スロットリング・ユニット2770が処理エンジンの動作周波数をスロットリングすることに応答して、閾値チューナ2780は、スロットリング・イベントのカウンタをインクリメントしてもよい。ブロック2860の後、方法2800は、ブロック2810に戻ってもよい(すなわち、処理エンジンにおける実行イベントの検出を続ける)。
ここで図29を参照すると、一つまたは複数の実施形態による、スロットリング閾値を調整するための方法2900のフロー図が示される。さまざまな実施形態において、方法2900は、ハードウェア(たとえば、処理装置、回路、専用論理、プログラマブル論理、マイクロコードなど)、ソフトウェア(たとえば、処理装置上で実行される命令)、またはそれらの組み合わせを含みうる処理論理によって実行されてもよい。いくつかの実装において、方法2900は、図26~図27に示される一つまたは複数の構成要素(たとえば、スロットリング論理2625、システム2700など)を使用して実行されてもよい。ファームウェアまたはソフトウェアの実施形態では、方法2900は、光学、半導体、または磁気記憶デバイスなどの非一時的な機械読み取り可能媒体に記憶されたコンピュータ実行命令によって実装されてもよい。機械読み取り可能媒体は、少なくとも1つの機械によって使用される場合、前記少なくとも1つの機械に、方法を実行するための少なくとも1つの集積回路を製造させるデータを記憶してもよい。例示のために、方法2900に含まれるアクションは、図26~図27を参照して以下に説明されうる。これらは、一つまたは複数の実施形態による例を示す。しかしながら、本明細書で論じられるさまざまな実施形態の範囲は、この点に関して限定されない。
ブロック2910は、処理エンジンにおけるスロットリング・イベントのカウントを決定することを含んでいてもよい。たとえば、図27を参照すると、閾値チューナ2780が、スロットリング・ユニット2770によって実行されるスロットリング・イベントのカウントをモニタリングしてもよい。
菱形2920は、スロットリング・イベントのカウントが最大値を超えるかどうかを判定することを含んでいてもよい。たとえば、図27を参照すると、閾値チューナ2780は、スロットリング・ユニット2770によって実行されるスロットリング・イベントのカウントが定義された最大数を超えるかどうかを判定してもよい。
菱形2920において、スロットリング・イベントのカウントが最大値を超えると判断される場合、方法2900はブロック2930に進んでもよく、そこでスロットリング閾値が増加されてもよい。ブロック2935では、処理エンジンのベースライン周波数が低下させられてもよい。たとえば、図26~図27を参照すると、閾値チューナ2780は、スロットリング・イベントのカウントが最大数を超えると判定し、それに応じて、閾値2760を増加させ(たとえば、3%、5%、8%など増加)、同時並行して、処理エンジンのベースライン周波数を低下させてもよい(たとえば、2%、5%、10%など低下)。本明細書で使用されるところでは、「ベースライン周波数」という用語は、スロットリングされていない状態(たとえば、スロットリング・ユニット2770によってスロットリングされていないとき)の処理エンジンによって使用される動作周波数を指す。よって、スロットリング・ユニット2770によって実行されるスロットリングは、処理エンジンのベースライン周波数からの低減である。いくつかの例では、非スロットリング状態の動作周波数の低減は、スロットリング中に実施される周波数低減よりも相対的により小さくてもよい。たとえば、スロットリング中に実行される周波数低減は、スロットリングされていない状態の周波数低減の整数倍であってもよい(たとえば、2X、5X、10Xなど)。いくつかの実施形態では、閾値チューナ2780は、プロセッサ2610をサポートする電力インフラストラクチャーの全体的な容量(たとえば、電源2650、電力制御ユニット2630などのパフォーマンス容量または仕様など)に基づいて、閾値2760に対する増加と、ベースライン周波数への低下のバランスを取ってもよい。ブロック2935の後、方法2900は、ブロック2910に戻ってもよい(すなわち、スロットリング・イベントのカウントの決定を継続する)。
しかしながら、菱形2920において、スロットリング・イベントのカウントが最大値を超えないと判定される場合、方法2900は、菱形2940に続いてもよく、そこで、処理エンジンが追加的なパフォーマンスを必要とするかどうかが判定されてもよい。もしそうでなければ、方法2900はブロック2910に戻ってもよい。たとえば、図26~図27を参照すると、閾値チューナ2780は、処理エンジン2620が、追加的な処理パワーから実質的に利益を得ないソフトウェアアプリケーションを実行していると判断してもよく、それに応じて、既存の閾値2760および/または処理エンジンのベースライン周波数を維持してもよい(すなわち、修正しない)。
しかしながら、菱形2940において、処理エンジンが追加的なパフォーマンスを必要とすると判定される場合、方法2900はブロック2950に続いてもよく、そこで、スロットリング閾値が低減されてもよい。ブロック2955では、処理エンジンのベースライン周波数が増加されてもよい。たとえば、図26~図27を参照すると、閾値チューナ2780は、処理エンジン2620が、追加的な処理パワーから利益を得ることができるソフトウェアアプリケーションを実行していると判断してもよく、それに応じて、閾値2760を減少させ(たとえば、3%、5%、8%などの減少)、同時並行して、処理エンジン2620のベースライン周波数を増加させてもよい(たとえば、2%、5%、10%等の増加)。いくつかの実施形態では、ベースライン周波数の増加は、スロットリング中に実行される周波数減少よりも絶対値が相対的に小さくてもよい。たとえば、スロットリング中に実行される周波数低減は、スロットリングされていない状態の周波数増加低減(frequency increase reduction)の絶対値の整数倍であってもよい(たとえば、2X、5X、10Xなど)。いくつかの実施形態では、閾値チューナ2780は、処理エンジン2620をサポートする電力インフラストラクチャーの全体的な容量に基づいて、閾値2760の減少とベースライン周波数への増加とのバランスを取ることができる。ブロック2955の後、方法2900は、ブロック2910に戻ってもよい(すなわち、スロットリング・イベントのカウントの決定を継続する)。
ここで図30を参照すると、一つまたは複数の実施形態による、スロットリングのための方法3000のフロー図が示される。さまざまな実施形態において、方法3000は、ハードウェア(たとえば、処理装置、回路、専用論理、プログラマブル論理、マイクロコードなど)、ソフトウェア(たとえば、処理装置上で実行される命令)、またはそれらの組み合わせを含みうる処理論理によって実行されてもよい。いくつかの実装において、方法3000は、図26~図27に示される一つまたは複数の構成要素(たとえば、スロットリング論理2625、システム2700など)を使用して実行されてもよい。ファームウェアまたはソフトウェアの実施形態では、方法3000は、光学、半導体、または磁気記憶デバイスなどの非一時的な機械読み取り可能媒体に記憶されたコンピュータ実行命令によって実装されてもよい。機械読み取り可能媒体は、少なくとも1つの機械によって使用される場合、前記少なくとも1つの機械に、方法を実行するための少なくとも1つの集積回路を製造させるデータを記憶してもよい。
ブロック3010は、スライディング窓における実行イベントの平均容量スコアを決定することを含んでいてもよい。たとえば、図26~図27を参照すると、イベント追跡器2720が、処理エンジン2620内の実行イベントを追跡してもよい。容量計算器2730は、追跡されたイベントに関連付けられた動的容量重み2740を決定してもよく、各イベント・インスタンスに、対応する容量重み2740を乗算してもよい。容量計算器2730は、追跡されたイベントの動的容量値を合計してもよく、全容量の移動平均を決定してもよい。
ブロック3020は、平均容量スコアがスロットリング閾値を超える場合に周波数スロットリングを実行することを含んでいてもよい。たとえば、図26~図27を参照すると、比較器2750が平均容量値がスロットリング閾値2760を超えると判定することに応答して、スロットリング・ユニット2770は、処理エンジン2620の動作周波数をスロットリングしてもよい。
ブロック3030は、周波数スロットリング・インスタンスのカウントを決定することを含んでいてもよい。たとえば、図26~図27を参照すると、スロットリング・ユニット2770が処理エンジン2620の動作周波数をスロットリングすることに応答して、閾値チューナ2780は、スロットリング・イベントのカウンタをインクリメントしてもよい。
ブロック3040は、周波数スロットリング・インスタンスのカウントが最大スロットリング値を超えるという判定に応答して、スロットリング閾値を増加させ、同時並行してベースライン周波数を減少させることを含んでいてもよい。たとえば、図26~図27を参照すると、閾値チューナ2780は、スロットリング・ユニット2770によって実行されるスロットリング・イベントのカウントが、定義された最大数を超えると判定してもよく、それに応じて、閾値2760を増加させ、同時並行して、処理エンジン2620のベースライン周波数を減少させてもよい。ブロック3040の後、方法3000は、完了されてもよい。
以下の節および/または実施例は、さらなる実施形態に関する。
実施例1では、スロットリングのためのプロセッサが、命令を実行するための複数のプロセッサ・コアと、スロットリング論理とを含む。スロットリング論理は:スライディング窓における実行イベントについての平均容量スコアを決定し;平均容量スコアがスロットリング閾値を超える場合に周波数スロットリングを実行し;周波数スロットリング・インスタンスのカウントを決定し;周波数スロットリング・インスタンスのカウントが最大スロットリング値を超えるという判定に応答して、スロットリング閾値を増加させ、同時にベースライン周波数を低下させる。
実施例2では、実施例1の主題は、任意的に、スロットリング論理が:周波数スロットリング・インスタンスのカウントが最大スロットリング値を超えないという判定に応答して、現在実行されているアプリケーションが追加的なパフォーマンスを必要とするという判定に応答して、スロットリング閾値を低下させ、同時にベースライン周波数を増加させることを含むことができる。
実施例3では、実施例1~2の主題は、任意的に、スロットリング論理が:周波数スロットリング・インスタンスのカウントが最大スロットリング値を超えないという判定に応答して、現在実行されているアプリケーションが追加的なパフォーマンスを必要としないという判定に応答して、スロットリング閾値を維持することを含むことができる。
実施例4では、実施例1~3の主題は、任意的に、スロットリング論理が:第1の処理コアにおける実行イベントを検出し;検出された実行イベントに関連する複数の容量重みに基づいて容量値を決定し;容量値を合計し;スライディング窓において容量値の合計をサイクル数で除算して、平均容量スコアを得ることを含むことができる。
実施例5では、実施例1~4の主題は、任意的に、複数の容量重みが、検出された実行イベントのビット幅に基づいて調整されることを含むことができる。
実施例6では、実施例1~5の主題は、任意的に、前記スロットリング閾値が複数のスロットリング閾値のうちの1つであり、前記複数のスロットリング閾値のうちの少なくともいくつかが実行イベントの別個のビット幅に関連付けられている、ことを含むことができる。
実施例7では、実施例1~6の主題は、任意的に、第1の処理エンジンへの最大電流保護(IccP)ライセンスの発行に応答して、スロットリング閾値がリフレッシュされることを含むことができる。
実施例8では、実施例1~7の主題は、任意的に、スロットリング論理が、プロセッサをサポートする電力インフラストラクチャーの全体的な容量に基づいて、スロットリング閾値への増加とベースライン周波数への低下とのバランスをとることを含むことができる。
実施例9では、スロットリングのための方法は:第1のプロセッサ・コアにおける実行イベントについて平均容量スコアを計算し;平均容量スコアがスロットリング閾値を超えるかどうかを判定し;平均容量スコアがスロットリング閾値を超えるという判定に応答して、プロセッサの周波数をスロットリングし;第1のプロセッサ・コアにおけるスロットリング・イベントのカウントを決定し;複数の時点において、スロットリング・イベントのカウントが最大スロットリング値を超えるかどうかを判定し;スロットリング・イベントのカウントが第1の時点において最大スロットリング値を超えるという判定に応答して、スロットリング閾値を増加させることを含む。
実施例10では、実施例9の主題は、任意的に、スロットリング・イベントのカウントが第1の時点において最大スロットリング値を超えるという判定に応答して、スロットリング閾値の増加と同時に第1のプロセッサ・コアのベースライン周波数を低下させることを含むことができる。
実施例11では、実施例9~10の主題は、任意的に、スロットリング・イベントのカウントが第2の時点において最大スロットリング値を超えないという判定に応答して、第1のアプリケーションが追加的なパフォーマンスを必要とするかどうかを判定し;第1のアプリケーションが追加的なパフォーマンスを必要とするという判定に応答して、スロットリング閾値を低下させ、同時にベースライン周波数を増加させることを含むことができる。
実施例12では、実施例9~11の主題は、任意的に、スロットリング・イベントのカウントが第3の時点において最大スロットリング値を超えないという判定に応答して:第2のアプリケーションが追加的なパフォーマンスを必要とするかどうかを判定し;第2のアプリケーションが追加的なパフォーマンスを必要としないという判定に応答して、スロットリング閾値およびベースライン周波数を維持することを含むことができる。
実施例13では、実施例9~12の主題は、任意的に、第1のプロセッサ・コアにおける実行イベントを検出し;検出された実行イベントに関連する複数の容量重みに基づいて容量値を決定し;容量値を合計し;容量値の合計をスライディング窓におけるサイクル数で除して、平均容量スコアを得ることを含むことができる。
実施例14では、実施例9~13の主題は、任意的に、検出された実行イベントのビット幅に基づいて複数の容量重みを調整することを含むことができる。
実施例15では、実施例9~14の主題は、任意的に、第1のプロセッサ・コアへの最大電流保護(IccP)ライセンスの発行中にスロットリング閾値をリフレッシュすることを含むことができる。
実施例16では、スロットリングのためのコンピューティング装置は、一つまたは複数のプロセッサと;前記一つまたは複数のプロセッサによって実行されると当該コンピューティング装置に実施例9~15のいずれかの方法を実行させる複数の命令が記憶されているメモリとを含む。
実施例17では、少なくとも1つの機械読み取り可能媒体は、少なくとも1つの機械によって使用される場合に、前記少なくとも1つの機械に実施例9~15のいずれかの方法を実行させるデータが記憶されている。
実施例18では、スロットリングのための電子装置は、実施例9~15のいずれかの方法を実行するための手段を含む。
実施例19において、スロットリングのためのシステムは:命令を実行するための複数のコアを備えるプロセッサであって、第1のコアがスロットリング回路を備える、プロセッサと;該プロセッサに結合されたシステムメモリとを含む。スロットリング回路は、第1のコアにおける実行イベントについての平均容量スコアを決定し;平均容量スコアがスロットリング閾値を超える場合に周波数スロットリングを実行し;スロットリング・インスタンスのカウントを決定し;スロットリング・インスタンスのカウントが最大スロットリング値を超えるという判定に応答して、スロットリング閾値を増加させる。
実施例20では、実施例19の主題は、任意的に、スロットリング・インスタンスのカウントが最大スロットリング値を超えるという判定に応答して、スロットリング回路が、スロットリング閾値を増加させる一方、第1のコアのベースライン周波数を低下させることを含むことができる。
実施例21では、実施例19~20の主題は、スロットリング・インスタンスのカウントが最大スロットリング値を超えないという判定に応答して、実行されているアプリケーションが追加的なパフォーマンスを必要とするという判定に応答して、スロットリング回路が、スロットリング閾値を低下させ、同時に第1のコアのベースライン周波数を増加させることを含むことができる。
実施例22では、実施例19~21の主題は、任意的に、スロットリング・インスタンスのカウントが最大スロットリング値を超えないという判定に応答して、実行されているアプリケーションが追加的なパフォーマンスを必要としないという判定に応答して、スロットリング回路が、スロットリング閾値と、第1のコアのベースライン周波数とを維持することを含むことができる。
実施例23では、実施例19~22の主題は、任意的に、スロットリング回路が:第1のコアにおける実行イベントを検出し;実行イベントに関連する複数の容量重みに基づいて容量値を決定し;容量値を合計し;容量値の合計をスライディング窓におけるサイクル数で除して平均容量スコアを得ることを含むことができる。
実施例24では、スロットリングのための装置は:第1のプロセッサ・コアにおける実行イベントについて平均容量スコアを計算する手段と;平均容量スコアがスロットリング閾値を超えるかどうかを判定する手段と;平均容量スコアがスロットリング閾値を超えるという判定に応答して、プロセッサの周波数をスロットリングする手段と;第1のプロセッサ・コアにおけるスロットリング・イベントのカウントを決定する手段と;複数の時点において、スロットリング・イベントのカウントが最大スロットリング値を超えるかどうかを判定する手段と;スロットリング・イベントのカウントが第1の時点において最大スロットリング値を超えるという判定に応答して、スロットリング閾値を増加させる手段とを含む。
実施例25では、実施例24の主題は、任意的に、スロットリング・イベントのカウントが第1の時点において最大スロットリング値を超えるという判定に応答して、スロットリング閾値の増加と同時に第1のプロセッサ・コアのベースライン周波数を低下させる手段を含むことができる。
実施例26では、実施例24~25の主題は、任意的に、スロットリング・イベントのカウントが第2の時点において最大スロットリング値を超えないという判定に応答して、第1のアプリケーションが追加的なパフォーマンスを必要とするかどうかを判定し;第1のアプリケーションが追加的なパフォーマンスを必要とするという判定に応答して、スロットリング閾値を低下させ、同時にベースライン周波数を増加させる手段を含むことができる。
実施例27では、実施例24~26の主題は、任意的に、スロットリング・イベントのカウントが第3の時点において最大スロットリング値を超えないという判定に応答して:第2のアプリケーションが追加的なパフォーマンスを必要とするかどうかを判定し;第2のアプリケーションが追加的なパフォーマンスを必要としないという判定に応答して、スロットリング閾値およびベースライン周波数を維持する手段を含むことができる。
実施例28では、実施例24~27の主題は、任意的に、第1のプロセッサ・コアにおける実行イベントを検出する手段と;検出された実行イベントに関連する複数の容量重みに基づいて容量値を決定する手段と;容量値を合計する手段と;容量値の合計をスライディング窓におけるサイクル数で除して、平均容量スコアを得る手段とを含むことができる。
実施例29では、実施例24~28の主題は、任意的に、検出された実行イベントのビット幅に基づいて複数の容量重みを調整する手段を含むことができる。
実施例30では、実施例24~29の主題は、任意的に、第1のプロセッサ・コアへの最大電流保護(IccP)ライセンスの発行中にスロットリング閾値をリフレッシュする手段を含むことができる。
いくつかの実施形態によれば、スロットリング・イベントのカウントに基づいてスロットリング閾値を動的に調節する実施例が提供される。いくつかの実施形態では、移動平均は実行イベントの推定されるエネルギー消費を反映することができる。移動平均がスロットリング閾値を超える場合に、動作周波数がスロットリングされてもよい。いくつかの実施形態では、スロットリング閾値は、スロットリングを減少させ、および/またはパフォーマンスを向上させるように調整されてもよい。このようにして、スロットリングによるパフォーマンスへの影響が軽減されうる。
図26~図31は、さまざまな例示的実装を示しているが、他の変形も可能であることに留意されたい。たとえば、一つまたは複数の実施形態が、図1~図25を参照して記載された例示的な装置およびシステムにおいて実施されうることが考えられている。
上記の実施例のさまざまな組み合わせが可能であることを理解されたい。実施形態は、多くの異なるタイプのシステムにおいて使用されうる。たとえば、ある実施形態では、コンピューティング装置は、本明細書に記載されるさまざまな方法および技法を実行するように構成されることができる。もちろん、本発明の範囲は、コンピューティング装置に限定されず、代わりに、他の実施形態は、命令を処理するための他のタイプの装置、または、コンピューティング装置上で実行されることに応答して、装置に本明細書に記載された方法および技法の一つまたは複数を実行させる命令を含む一つまたは複数の機械読み取り可能媒体に向けられることができる。
本明細書を通じて「一つの実施形態」または「ある実施形態」への言及は、その実施形態に関連して記載された特定の特徴、構造、または特性が、本発明内に包含される少なくとも1つの実施形態に含まれることを意味し、「一つの実施形態において」または「ある実施形態において」という句の出現は、必ずしも同じ実施形態を指すものではない。さらに、特定の特徴、構造、または特性は、図示した特定の実施形態以外の他の好適な形態で設けられることができ、そのような形態はすべて、本願の請求項に包含されうる。
本発明を限られた数の実施形態に関して説明してきたが、当業者は、そこから数多くの修正および変形を理解するであろう。添付の特許請求の範囲は、本発明の真の精神および範囲内にあるすべてのそのような修正および変形をカバーすることが意図されている。