(57)【要約】【解決手段】  一部の実施形態によると、本発明は、コンピューティングプラットフォーム用の高効率且つリアルタイムのプラットフォーム電力管理アーキテクチャを提供する。集積化された電圧レギュレータを用いて、一部の実施形態によると、直接電力管理インターフェース（ＤＰＭＩ）も利用して、より直接的な電力管理アーキテクチャを提供するとしてよい。集積化された電圧レギュレータ、例えば、シリコン内電圧レギュレータ（ＩＳＶＲ）は、より高速でより高い応答性で電力状態を遷移させるべく利用され得る。【選択図】  図１Ａ
2013513190.tif 000002
【特許請求の範囲】
【請求項１】
電力管理フレームワークを持つオペレーティングシステムを実行する１以上のプロセッサコアと、
電力管理ユニット（ＰＭＵ）と、
前記ＰＭＵに結合されており、前記ＰＭＵと複数のデバイスとの間で電力状態メッセージのやり取りを行う直接電力管理インターフェースと
を備え、
前記ＰＭＵは、前記複数のデバイスに供給される電力の量を制御する装置。
【請求項２】
前記直接電力管理インターフェースは、前記複数のデバイスからの電力要求メッセージを処理するロジックを有する請求項１に記載の装置。
【請求項３】
前記電力要求は、電力の低減を求める要求を含む請求項２に記載の装置。
【請求項４】
前記直接電力管理インターフェースを前記複数のデバイスに通信可能にリンクさせる内部バスを備える請求項２に記載の装置。
【請求項５】
前記ＰＭＵは、前記オペレーティングシステムの前記電力管理フレームワークの外部で電力状態の変更を実行可能である請求項１に記載の装置。
【請求項６】
前記複数のデバイスは、前記ＰＭＵを含むチップ上の複数の内部デバイスを含む請求項１に記載の装置。
【請求項７】
前記複数のデバイスは、入出力インターフェースを介して前記ＰＭＵに結合されている複数の外部デバイスを含む請求項６に記載の装置。
【請求項８】
前記１以上のプロセッサコアを含むチップ上の複数の内部電圧レギュレータを備える請求項１に記載の装置。
【請求項９】
前記複数のデバイスはそれぞれ、１以上の内部電圧レギュレータが対応付けられている請求項８に記載の装置。
【請求項１０】
電力状態の変更を実行する電力管理フレームワークを持つオペレーティングシステムを実行する１以上のプロセッサコアと、
電力管理ユニット（ＰＭＵ）と、
前記ＰＭＵに結合されており、前記ＰＭＵと複数のデバイスとの間で電力状態メッセージのやり取りを行う直接電力管理インターフェースと
を備え、
前記ＰＭＵは、前記複数のデバイスに供給される電力の量を制御するコンピューティングプラットフォーム。
【請求項１１】
前記直接電力管理インターフェースは、前記複数のデバイスからの電力要求メッセージを処理するロジックを有する請求項１０に記載のコンピューティングプラットフォーム。
【請求項１２】
前記電力要求は、電力を低減することを求める要求を含む請求項１１に記載のコンピューティングプラットフォーム。
【請求項１３】
前記直接電力管理インターフェースを前記複数のデバイスに通信可能にリンクさせる内部バスを備える請求項１１に記載のコンピューティングプラットフォーム。
【請求項１４】
前記ＰＭＵは、前記オペレーティングシステムの前記電力管理フレームワークの外部で電力状態の変更を実行可能である請求項１０に記載のコンピューティングプラットフォーム。
【請求項１５】
前記複数のデバイスは、前記ＰＭＵを含むチップ上の複数の内部デバイスを含む請求項１０に記載のコンピューティングプラットフォーム。
【請求項１６】
前記複数のデバイスは、入出力インターフェースを介して前記ＰＭＵに結合されている複数の外部デバイスを含む請求項１５に記載のコンピューティングプラットフォーム。
【請求項１７】
前記１以上のプロセッサコアを含むチップ上の複数の内部電圧レギュレータを備える請求項１０に記載のコンピューティングプラットフォーム。
【請求項１８】
前記複数のデバイスはそれぞれ、１以上の内部電圧レギュレータが対応付けられている請求項１７に記載のコンピューティングプラットフォーム。
【請求項１９】
前記１以上のプロセッシングコア、前記ＰＭＵおよび前記直接電力管理インターフェースは、システムオンチップの一部である請求項１０に記載のコンピューティングプラットフォーム。
【請求項２０】
電力管理フレームワークを持つオペレーティングシステムを実行するプロセッサを備える装置であって、
前記電力管理フレームワークは、前記プロセッサについて、および、前記プロセッサに結合されている複数のデバイスについて電力状態の変更を実行し、
前記装置はさらに、
前記複数のデバイスに提供する電力を制御する電力管理ユニット（ＰＭＵ）と、
前記ＰＭＵと前記複数のデバイスとの間に、前記複数のデバイスからの電力要求を処理するべく結合されている電力管理インターフェースと
を備える装置。
【請求項２１】
前記電力を前記複数のデバイスに供給する複数の内部電圧レギュレータを備える請求項２０に記載の装置。
【請求項２２】
前記ＰＭＵは、前記複数のデバイスに供給される電力を管理する電力管理ポリシーを有する請求項２０に記載の装置。
【請求項２３】
前記ＰＭＵは、前記オペレーティングシステムの前記電力管理フレームワークを介すことなく、デバイス電力状態を変更可能である請求項２２に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概してコンピューティングシステムに対する電力供給に関し、具体的には高効率プラットフォーム電力システム、方法およびアーキテクチャに関する。
【背景技術】
【０００２】
［関連出願］
本願は、先に出願され、参照により本願に組み込まれる米国仮特許出願第６１／３３５，１５３号（出願日：２００９年１２月３１日）の出願日を優先日と主張する。
【０００３】
ＡＣＰＩ（ａｄｖａｎｃｅｄ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｐｏｗｅｒ  ｉｎｔｅｒｆａｃｅ）等の従来のオペレーティングシステム（ＯＳ）を利用した電力管理方式は、ＯＳを中心とした方式である。プラットフォームおよびデバイスの電力状態の遷移は、ＯＳ電力管理ソフトウェアフレームワークで開始される場合、電力状態の変更を実現するためには通常、ＯＳカーネルスタック、デバイスドライバ、プラットフォームファームウェア、および、最後にプラットフォームの電力管理ユニット（コントローラであることが多い）を上から下へと移動する必要がある。デバイスで開始される場合の逆方向の動作も時間がかかり、通常は同一経路を逆方向に移動しなければならず、ＯＳによる認証（等）のために待機しなければならない。このようなアーキテクチャは、電力の消費が非常に非効率的で無駄が多い。この問題は、電力状態変更に関する応答時間が比較的長く、ＧＰＳデバイス、Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイスおよびＵＳＢデバイス等の他のデバイスとの集積化が困難な従来の電圧レギュレータを利用する技術では許容され得る。したがって、コンピュータ機能を持つプラットフォームでは新しい電力管理方式が望まれている。
【図面の簡単な説明】
【０００４】
本発明を限定するものではなく一例として、添付図面に本発明の実施形態を図示する。添付図面では、同様の参照番号は同様の構成要素を示す。
【図１Ａ】一部の実施形態に係る直接ＰＭＩ（ＤＰＭＩ）電力管理機能が組み込まれたアーキテクチャを一般化した図である。
【図１Ｂ】一部の実施形態に係る、図１Ａに示すＤＰＭＩベースの電力管理アーキテクチャの実装が容易な汎用プラットフォームを示すブロック図である。
【図２】一部の実施形態に係る図１Ａの電力管理フレームワークを詳細に示す図である。
【図３】一部の実施形態に係るＤＰＭＩアーキテクチャを持つＳｏＣプラットフォームを示すブロック図である。
【図４】別の実施形態に係るＯＳ  ＰＭ−ＤＰＭＩアーキテクチャを示す図である。
【図５】一部の実施形態に係る集積化された電圧レギュレータを示す図である。
【図６】一部の実施形態に係る、関連付けられたデバイスに対する電圧供給を制御するマルチセルＩＶＲを示す図である。
【図７】一部の実施形態によるとプラットフォームパッケージを示す断面図である。
【図８】一部の実施形態に係る、許容可能なアクティブセル範囲を決定するルーチンを説明する図である。
【図９】一部の実施形態に係る、許容可能なアクティブセル範囲に基づいてアクティブである必要があるセルの数を決定するルーチンを説明する図である。
【図１０】一部の実施形態に係る、アクティブセルでアクティブである必要があるスイッチレッグの数を決定するルーチンを説明する図である。
【図１１】一部の実施形態に係る、適切なＩＶＲ電力状態処理をＰＭＵがどのように決定するのかを示すルーチンである。
【発明を実施するための形態】
【０００５】
一部の実施形態によると、本発明は、コンピューティングプラットフォーム用の高効率且つリアルタイムのプラットフォーム電力管理アーキテクチャを提供する。集積化した電圧レギュレータおよび、一部の実施形態では、直接電力管理インターフェース（ＤＰＭＩ）を利用して、より直接的な電力管理アーキテクチャを提供し得る。集積化した電圧レギュレータ、例えば、シリコン内電圧レギュレータ（ＩＳＶＲ）は、後述するが、電力状態の遷移をより高速且つより高い応答性で実現するために利用することができる。また、新しいより直接的な電力管理アーキテクチャ（ＤＰＭＩ）を用いて、プラットフォーム用の電圧レギュレータおよび／またはＩＳＶＲをより効率的に管理するとしてよい。
【０００６】
一部の実施形態によると、ＤＰＭＩは、従来のＯＳベースの電力管理チェーンを移動することなく、デバイスと電力管理ユニット（ＰＭＵ）との間で、動作ステータスおよび電力状態変更要求を直接（つまり、従来のＯＳベース方式よりも直接的に）通信可能とするハードウェアプロトコルを提供するとしてよい。このメカニズムによれば、高速且つ集積化されたＶＲ、例えば、ＩＳＶＲに適切なリアルタイム電力状態制御が可能となる。
【０００７】
従来のオペレーティングシステムをベースとした電力管理方式とは異なり、ＤＰＭＩを備えるプラットフォームは、適切であれば、例えば、電力状態変更に応じて、または、動作状態が低下または中止される旨のデバイスの通知に応じて、より効率的にオペレーティングシステムを省略して、より高速に電力を低減することができる。ＩＶＲを用いる場合、電力状態遷移の高速化は、例えば、マイクロ秒およびナノ秒のオーダで実現可能であり、ＩＶＲは、配電制御をより厳密且つ精細に行うことを目的として、他の機能モジュールも含むシステムオンチップ（ＳｏＣ）等のプラットフォームに集積化が可能である。例えば、ＤＰＭＩを用いる場合、ＩＶＲは、高速に、略リアルタイムに、低電力モード、スリープモード、または、ディープスリープモードを開始または終了することによって今まで実現できなかった高い電力利用効率を実現するべく、機能デバイスに集積化が可能である。これは、例えば、ネットブック、スマートフォン、および、モバイルインターネットデバイスプラットフォーム等のモバイル機器において有益である。
【０００８】
一部の実施形態によると、ＩＶＲイネーブルプラットフォームのハードウェア層において直接電力管理インターフェース（省略すると、ＤＰＭＩまたは直接ＰＭＩと呼ぶ）アーキテクチャが提供される。システムの電力管理ユニット（ＰＭＵ）がＩＶＲと集積化されると、直接ＰＭＩによって、デバイスは、電力状態の遷移が必要とされている旨を直接ＰＭＵに（例えば、ＯＳを省略して）通知することができるようになり、ＰＭＵはＯＳおよびＯＳの電力管理フレームワークの関与を必要とすることなく電力状態変更を実行することができるようになる。このため、電力管理が高速化され、ＯＳの実行に利用される電力が抑制される。電力管理動作の多く（または大半）は、ＯＳに対して実質的にトランスペアレントになるので、よりハードウェアに重点を置いた電力管理アーキテクチャが実現される。電力状態変更の応答時間を改善することができ、プラットフォームが電力管理動作で必要とするＣＰＵリソースが少なくなるのが普通である。このため、プラットフォーム電力利用効率を全体的に改善することができる。
【０００９】
図１Ａは、直接ＰＭＩ（ＤＰＭＩ）電力管理機能が組み込まれたアーキテクチャを一般化した図である。図示したプラットフォーム部分は、ＯＳ電力管理フレームワーク１０２、電力管理ユニット１０４（Ｐコード１０５を含む）、直接電力管理インターフェース（ＤＰＭＩ）ロジック１０６、電圧レギュレータ１０８、および、デバイス１ＸＸを含む。構成要素は全て、図示しているように結合されている。デバイス１ＸＸは、ＶＲ１０８から電力供給を受ける。ＶＲ１０８は、ＯＳ  ＰＭフレームワーク１０２、ＰＭＵ１０４およびＤＰＭＩロジック１０６によって制御される。デバイスを「１ＸＸ」という参照番号で表すのは、プラットフォーム内、または、プラットフォーム外のさまざまなデバイスまたはモジュールを意味するためである。デバイスの一部については、図１Ｂに図示している。
【００１０】
動作について説明すると、ＰＭＵ（ＤＰＭＩロジック１０６の支援も受けつつ）およびＯＳ  ＰＭフレームワークは、協働して、プラットフォーム全体の電力管理を実行する。ＯＳフレームワークは、従来のＯＳ  ＰＭフレームワークと同様であるが、ＯＳカーネルに加えてＤＰＭＩ特有の機能が追加されている。一部の実施形態によると、ユーザは、ＤＰＭＩベースの電力管理機能をイネーブルするかディセーブルするかを選択することができる。これによって、アプリケーションソフトウェアの新しいＤＰＭＩ実装プラットフォームに対する後方互換性が得られる。
【００１１】
ＰＭＵおよびＤＰＭＩの利点は、本明細書で教示するように、ＯＳ電力管理フレームワーク１０２の方式内で、または、当該方式から独立して動作可能であるという点にある。このため、例えば、ＯＳ電力管理フレームワーク１０２方式内で動作する場合、ＯＳは、ＡＣＰＩ等の従来の電力状態方式を実行する。同時に、ＰＭＵおよびＤＰＭＩロジックは、より低いレベルで（より高い粒度且つより高速応答で）、多くの場合には、ＯＳフレームワークを介することなく、電力を管理することが可能である。ＯＳは所与の電力状態（例えば、Ｇ状態またはｓ状態）にあるとしてよく、ＰＭＵ１０４／ＤＰＭＩ１０６はこれに応じて、デバイスの電力を管理するとしてよい。例えば、所与のＯＳ／システム状態に応じて、ＰＭＵ／ＤＰＭＩは、デバイス電力状態の変更を、低速化、高速化、および／または、別の方法で行うとしてよく、例えば、オンまたはオフ状態を維持するよう命令したり、または、低電力モードにいる期間を長くしたり、または、短くしたりするとしてよい。
【００１２】
ＰＭＵは、電圧レギュレータ１０８から出力される実際の供給レベルを制御することによって、電力を変化させる。ＰＭＵは、現在の電力状態に基づいて、および、ＯＳ、ＤＰＭＩ、または、プラットフォームセンサまたはその他の情報ソースから通知され得るリアルタイムで発生しているイベントまたは状況の変化に基づいてレベルを設定するとしてよい。ＰＭＵ１０４は、任意の適切な回路または回路モジュールで実現するとしてよい。このような回路または回路モジュールは、これに限定されないが、マイクロコントローラを含む。ＶＲが供給する電力量（通常は、調整可能な供給電圧レベルを用いて制御される）は、さまざまな要因によって決まる。その中でも重要なものとして、システム／プラットフォーム／デバイスの電力状態、デバイスの特定の動作（または動作していないこと）、次に期待されるデバイスの動作、および、電力管理効率に関するその他の要因がある。ＶＲが供給するべき電力量を制御するべく上記の要因および他の要因を処理するためのポリシーは、ＰＭＵで実行される実行可能ソフトウェアまたはファームウェア（「Ｐコード」１０５と呼ぶ）およびＤＰＭＩロジック１０６を組み合わせることによって実行されるとしてよい。
【００１３】
電圧レギュレータ１０８は、複数の適切な電圧レギュレータを任意且つ適切に組み合わせることによって実現され得る。通常はバック型のＤＣ−ＤＣコンバータが用いられるが、他の種類のレギュレータと組み合わせて用いるとしてもよい。複数または多数のＶＲを用いてプラットフォームの複数の別個のデバイスに対する可変供給電力を制御するとしてもよいと考えられる。レギュレータはさまざまなサイズであるとしてよく、複数のレギュレータを一緒に用いて、一の所与のデバイスに電力を供給するべく、ＶＲドメインを定義するとしてよい。
【００１４】
一部の実施形態によると、いわゆるシリコン内電圧レギュレータ（ＩＳＶＲ）を利用するとしてよい。ＩＳＶＲは、後述するが、一般的には複数または多数のＶＲが、電力供給対象のデバイスを構成する１以上のチップに近接して配置されている１以上のチップに実質的に集積化されている。一部の実施形態によると、ＩＳＶＲは、一部分または全体が、電力を供給すべきデバイスが対応付けられているチップ内に集積化されているとしてよい。
【００１５】
ＤＰＭＩロジック１０６は、ＰＭＵを支援して、より効果的且つ効率的に、デバイスからのメッセージを処理する機能を持ち、一部の実施形態では、ＰＭＵとは無関係に、デバイスのメッセージを直接処理する。ＤＰＭＩロジック１０６は、任意の適切なロジック回路で実現するとしてよい。このようなロジック回路は、これらに限定されないが、組み合わせロジック、順次ロジック、ステートマシン、コントローラおよび／または、任意のその他の適切な回路の任意の適切な設定を含むとしてよい。
【００１６】
マイクロコントローラで実現される従来のＰＭＵの欠点は、複数の異なるデバイスからの複数の異なる要求または通知の全てに対して、同時且つ効率的に対処できるのが困難であるという点である。例えば、いくつかのデバイスは、タスクを終了して、アイドルおよび／または低電力状態になる準備が整っていることをＰＭＵに通知しようと試みるとしてよい。ＤＰＭＩロジックは、このようなデバイストラフィックをより高速に処理する機能を持ち、所望の方法でＰＭＵに当該トラフィックを転送する。例えば、メッセージの種類またはメッセージの送信元に応じて、優先するメッセージを変更するとしてよい。また、一部の実施形態によると、ＤＰＭＩは、電力状態変更要求または作業負荷通知等のメッセージを直接処理することが可能であるとしてよい。ＰＭＵおよび／またはＤＰＭＩロジックは、デバイス毎にステート変化を処理および／または実行することができ、同時に、ＯＳ  ＰＭフレームワークがプラットフォーム全体への電力供給を管理できるようにステート変化をＯＳに転送するが、同時に、変化をより高速に実行することができる。この結果、省電力効果の改善がわずかに見られ、例えば、ＯＳを介する必要がある場合に比べて数ミリ秒早く低電力状態が開始される。しかし、このようなわずかな省電力効果は、時間の経過に応じて、そして、多くの様々な動作中のデバイスにわたって積み重なる。
【００１７】
図１Ｂは、図１Ａに示すＤＰＭＩベースの電力管理アーキテクチャの実装が容易な一般的なプラットフォームを示すブロック図である。当該プラットフォームは、１以上のコア１０３、Ｉ／Ｏデバイス／インターフェース１０５、メモリデバイス１０７、グラフィクスプロセッサ１０９、送受信デバイス１１１、ならびに、１以上のコアを含む複数のデバイスに電力を供給するＶＲ（不図示）を管理するＰＭＵ１０４およびＤＰＭＩ１０６を備えている。デバイスの一部またはすべては、用途および構成に応じて、直接または間接的に、例えば、１以上のバスまたはポイント・ツー・ポイント・リンクを介して相互に接続されているので、図示を簡略化するべく接続線は図示していない。同様に、ＶＲは、プラットフォーム全体に分散して設けられており（例えば、別の近接したチップ、または、全体あるいは一部がプラットフォームの主要チップに集積化されている）、さまざまなデバイスに電力を供給するＶＲドメインを形成しているので図示していない。一部のＶＲは、さまざまなデバイスを含む１以上のチップに集積化されているとしてよく、または、電力供給先のデバイスに近接した１以上の別個のモジュールの一部であるとしてもよい。
【００１８】
コアは、ＯＳ  ＰＭフレームワークを実行して、ＰＭＵおよびＤＰＭＩロジックと協働して、デバイスに電力を供給するさまざまなＶＲを制御する。プラットフォームは、パーソナルコンピュータ、サーバ、スマートフォン等のポータブルコンピューティングデバイス、ネットブック、タブレットＰＣまたは任意のその他の適切なコンピューティング装置を実現する。
【００１９】
図２は、図１Ａの電力管理フレームワークを詳細に示す図である。ＯＳドメイン２０１と共に、実行可能コードであるＰコード１０５を持つＰＭＵ１０４、ＤＰＭＩロジック１０６、電圧レギュレータ１０８、および、デバイス１ＸＸが図示されている。これらは全て、図示されているように結合されている。また、ＤＰＭＩロジック１０６をデバイス１ＸＸにリンクさせる内部ＤＰＭＩバス２５０を図示している。ＤＰＭＩロジックは、バス２５０を介してＤＰＭＩロジックと通信を実行するべく、デバイスインターフェースを介してデバイスエージェントにリンクされている。（「バス」という用語を用いているが、１以上のバス以外のリンクを利用するとしてもよいと考えられたい。このようなリンクには、ポイント・ツー・ポイントリンクおよび無線リンクが含まれる。）
【００２０】
ＯＳ  ＰＭフレームワーク１０２に加えて、ＯＳドメインは、アプリケーション２０６、サービス２０７、オペレーティングシステムカーネル２３０、ＰＭＵドライバ２３４、ならびに、デバイスＰＭＩおよびＤＰＭＩドライバ２３６を含む。
【００２１】
ＯＳ  ＰＭフレームワーク１０２は、メッセージフレームワーク２０３、電力管理に関するまたは電力管理に影響を及ぼすさまざまなモジュール２０４、２１６、および、プラットフォーム電力マネージャ２２４を含む。電力管理モジュール２０４／２１６は、高レベルポリシープロビジョニング／ユーザインターフェースモジュール２０８、電力ポリシーエンジン２０９、電力管理サービス品質（ＱｏＳ）エンジン２１０、プラットフォームモードおよび設定テーブル２１１、ＤＰＭＩ管理モジュール２１２、電力プロフィールモジュール２１７、タイマ管理モジュール２１９、プラットフォームセンサ入力モジュール２２１、および、イベントハンドラモジュール２２３を含む。
【００２２】
メッセージフレームワーク２０３は、実行中のアプリケーション２０６（ＣＡＤプログラム、ムービーエディタ等）と実行中のサービス２０７（例えば、インスタントメッセンジャー等）と電力管理モジュールとの間のインターフェースとして機能する。電力管理モジュールは、アプリケーションおよび実行中のサービスから、動作状態、推定タスク期間等の電力関連情報を取得する。電力管理モジュール２０４／２１６で実行されるポリシーに応じて、この情報は、例えば、プラットフォーム全体からデバイス単位まで、さまざまなプラットフォームについて適切な電力状態を設定するために用いられるとしてよい。プラットフォーム電力マネージャ２２４は、モジュールとＯＳカーネル２３０との間のインターフェースとして機能する。（図示内容および上記の内容は、電力管理に関するＯＳの側面であり、ＯＳの全ての特徴を図示および説明しているわけではないと理解されたい。）
【００２３】
ＯＳ  ＰＭフレームワーク１０２は、高レベルのポリシー管理および設定を行い、主に、アプリケーションステータスおよび利用モデルに応じて電力状態の遷移を決定する。この点において、ＯＳ  ＰＭフレームワークは通常、従来のＯＳ  ＰＭ構成に対して後方互換性を持つ。このため、従来のアプリケーションソフトウェアインフラストラクチャは、ＤＰＭＩ実装アーキテクチャによってサポートされ得る。
【００２４】
ＤＰＭＩマネージャ２１２およびユーザインターフェースモジュール２０８は、所定のデバイスのＤＰＭＩ機能をアクティブ化または非アクティブ化する機能を持つ。デバイス１ＸＸのＤＰＭＩエージェントが非アクティブ化されている場合、当該デバイスの電力管理メカニズムは基本的に、ＤＰＭＩを持たないオペレーティングシステム構成と同じである。デバイスのＤＰＭＩエージェントがアクティブ化されると、電力管理を行うことができる。電力管理の大半は、ＤＰＭＩロジック１０６およびＰＭＵのＰコード１０５を介して行われ、ＯＳおよびアプリケーション／サービスに対して略トランスペアレントになる。この場合、ＰＭＵ１０４は、依然としてＯＳ  ＰＭフレームワーク１０２からの電力管理指示に応答することができるが、電力管理動作の大部分は、ＰＭＵとデバイスとの間で行われる。
【００２５】
デバイスは、動作ステータスおよび電力状態変更要求をＰＭＵ１０４にリアルタイムで通知し、ＰＭＵは、即座に供給レール（および、おそらくは、例えば、クロックツリー等のサブシステムも）低電力状態に調整して、必要に応じて高電力状態に「戻す」。このような構成によって、プラットフォームの電力利用効率が改善され得る。ＤＰＭＩがイネーブルされた電力管理アーキテクチャによって、電力状態の遷移の高速化だけではなく、ＯＳ  ＰＭフレームワークが必要とするコンピューティングリソースおよびＣＰＵの利用を低減することによっても、電力利用効率が改善される。
【００２６】
従来のＯＳ  ＰＭフレームワーク内でＤＰＭＩアーキテクチャの拡張を可能とするべく、電力管理ＱｏＳエンジン２１０は、ＤＰＭＩがアクティブ化されると電力管理モードを反映する機能を持つ。同様に、プラットフォームモードおよび設定テーブル２１１は、従来のＯＳ  ＰＭについて既に定義されているモードに加えて、ＤＰＭＩアクティブ化状態でのモードを含むとしてよい。
【００２７】
ＯＳ  ＰＭフレームワーク１０２とハードウェア（ＰＭＵ、デバイス、ＶＲ等）との間の中間層は、ＰＭＵドライバ２３４およびデバイスドライバ２３６を含む。一部の実施形態によると、これらのドライバは、ファームウェアを用いて実施するとしてよい。ＰＭＵドライバ２３４によって、ＰＭＵ１０４は、ＯＳおよびアプリケーション／サービスソフトウェアと通信を行う。ＤＰＭＩ非アクティブ化デバイスについては、ＰＭＵ１０４とＯＳ  ＰＭフレームワーク１０２との間で、電力管理命令をやり取りするのが、（唯一でなければ）主要なメカニズムであるとしてよい。ＤＰＭＩアクティブ化デバイスについては、ＰＭＵは、依然としてＯＳ  ＰＭフレームワーク１０２との間で、ＯＳ  ＰＭフレームワーク１０２とＰＭＵ１０４との間でやり取りされた電力に影響を及ぼすイベントをやり取りするが、電力管理要求の大半は、ＤＰＭＩインフラストラクチャ（ＰＭＵ１０４、ＤＰＭＩロジック１０６、および、ＤＰＭＩ内部バス２５０）を介してやり取りされるとしてよい。
【００２８】
デバイスドライバ２３６は、ソフトウェアフックを提供し、ＯＳおよびアプリケーションソフトウェアに、デバイスを適切な電力管理モードで設定させ、ＤＰＭＩ機能をアクティブ化／非アクティブ化させる。
【００２９】
図示しているプラットフォーム電力管理フレームワークの最も低いＤＰＭＩ層は、ハードウェア層であり、Ｐコード１０５を含むＰＭＵ１０４、ＤＰＭＩロジック１０６、ＶＲ１０８、および、デバイス１ＸＸを含む。ハードウェア層が高速電力管理応答性を実現できるのは、ＰＭＵ１０４、ＶＲ１０８およびデバイス１ＸＸ（例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）デバイス、ＣＤＭＡデバイス、ＵＳＢデバイス等）を密に集積化しているためである。一部の実施形態によると、デバイスの（大半でなければ）多くが、高速且つ精細な電力レール制御を完全に有効活用するべく、ＰＭＵと集積化されており、ある程度までは、ＶＲとも集積化されて、１つのＳｏＣに含められている。言うまでもなく、所与のプラットフォーム用のＳｏＣ等に集積化されていないデバイスがあるとしてもよい。この場合、ＳｏＣの一部のＶＲは、外部デバイスに対する電力レールをサポートするべく割り当てられているとしてよい。
【００３０】
ＤＰＭＩ非イネーブルデバイスでは、ＰＭＵは主に、ＯＳ  ＰＭフレームワーク１０２からの電力管理命令を実行および処理する可能性が高い。しかし、ＤＰＭＩイネーブルデバイスでは、ＰＭＵ機能が２倍になる。一方で、ＯＳ  ＰＭからの電力管理指示の処理を続ける。他方では、追加で自立したエージェントとして機能して、Ｐコード１０５で定義されているポリシーを利用して、ＤＰＭＩロジックと協働して、ＯＳ  ＰＭフレームワークを介することなく、デバイス電力状態を直接管理する。
【００３１】
ＤＰＭＩハードウェアは実質的に、ＤＰＭＩロジック１０６、ＤＰＭＩ内部バス２５０、および、デバイス内のＤＰＭＩエージェントを含む。内部バス２５０は、複数の集積回路の間で共有され、デバイス動作ステータスおよび電力状態要求をＤＰＭＩロジック１０６を介してＰＭＵ１０４に通知するために用いられる。ＤＰＭＩロジック１０６は主に、内部ＤＰＭＩバス通信および外部ＤＰＭＩバス通信を管理して、デバイス間のバス競合を解決し、デバイスからの電力状態変更要求に対するハブとして機能し、ＰＭＵ１０４に対する電力状態要求を優先して通知するとしてよい。ＤＰＭＩロジック１０６はさらに、外部デバイスの供給レールがＶＲ１０８によって供給される場合、例えば、ＰＭＵおよびＤＰＭＩコントローラに集積化される場合等、外部デバイスをＤＰＭＩプロトコルで管理させるべく、ＤＰＭＩ拡張ポート（後述する実施形態で図示）を処理するとしてよい。
【００３２】
Ｐコード１０５は、コントローラとして実装される場合、ＰＭＵ用の低レベルプログラムとして機能する。（同等の適切なコード／ロジックを、別のＰＭＵ実施例で用いるとしてよい）。Ｐコード１０５は、低レベル電力管理エンジン２６４、ＤＰＭＩイネーブルデバイスポリシールックアップテーブル２６５、ＤＰＭＩ非イネーブルデバイスポリシールックアップテーブル２６６、低レベルＯＳ  ＰＭイベントハンドラ２６７、平均電力利用監視モジュール２６８、タイマ管理モジュール２６９、熱管理モジュール２７０、および、センサ管理モジュール２７１を含む。新しい機能（例えば、ＤＰＭＩ関連ポリシー、イベントハンドラ）は従来のＰＭＵ機能（例えば、熱管理、タイミング管理）と統合し得ることが分かる。
【００３３】
低レベル電力管理エンジン２６４は、ＤＰＭＩロジック１０６を介して通知される電力状態イベント、および、ＯＳ  ＰＭフレームワーク１０２からの要求を処理する。電力状態ポリシーは、電力状態の変更を高速化するべく、主にルックアップテーブル２６５、２６６を用いて、Ｐコード内に組み込まれる。所与のデバイスの特定の電力状態は通常、基本的に、適切なＶＲ１０８に対する１以上のコマンドを用いてＰＭＵによって制御される特定の電圧設定に対応する。ＰＭＵは、ＯＳ  ＰＭフレームワークから、または、ＤＰＭＩからの電力状態変更の要求／コマンドを、ポリシールックアップテーブルにロードされている所定の対応関係に従って処理して、ＶＲ電圧設定のターゲット値を設定する。Ｐコードによればさらに、ＰＭＵは、例えば、対象デバイスの平均電力使用の履歴を、平均電力利用監視部２６８およびセンサ監視モジュール２７１を利用して、記録することができる。
【００３４】
図３は、一部の実施形態に係るＤＰＭＩアーキテクチャを持つＳｏＣプラットフォームを示すブロック図である。当該ＳｏＣプラットフォームは通常、１以上のコア３０３、ＰＭＵ３０４、メモリ３０７、タイミング／周辺機器３０５、ＤＰＭＩロジック３０６、Ｉ／Ｏインターフェース３０９、ＶＲ３０８、および、ＩＶＲ３０８から電力供給を受けるＳｏＣ内の集積デバイスを含む。さらに、電力状態がＰＭＵ３０４およびＤＰＭＩロジック３０６によって制御されている外部デバイス３１１が図示されている。ＳｏＣは、ネットブック、いわゆるスマートフォン、または、任意のその他の機器等、特に、省電力効果が重要である携帯可能な機器のための任意の適切なアプリケーションを実行するために利用される。
【００３５】
１以上のプロセッサコアは、ＯＳ  ＰＭフレームワーク３０１を実行する。ＯＳ  ＰＭフレームワーク３０１は、ＳｏＣの特定の設計を可能とするべくモジュールの数を増減させて構成を変更している以外は上述したものと同様であるとしてよい。同様に、ＰＭＵ３０４（Ｐコードを含む）およびＤＰＭＩロジック３０６もまた、上述したように構成されているとしてよい。集積デバイスは、動作時の電力状態を様々な電力状態に制御可能なＳｏＣ内のデバイス（機能ユニット、モジュール）に対応する。ＩＶＲ３０８は、複数のデバイスに電力を供給するための用いられる別々のＶＲまたはＶＲドメインである。このため、各デバイスへの供給は、別個に制御されるとしてよい。ＩＶＲは、例えば、図７を参照しつつ後述するように、全体または一部がＳｏＣチップ、または、ＳｏＣチップに近接して配置されている別個のチップに集積化されているＶＲで実現するとしてよい。
【００３６】
図４を参照すると、別の実施形態に係るＯＳ  ＰＭ−ＤＰＭＩアーキテクチャが図示されている。この電力管理アーキテクチャは、図３のＳｏＣに利用されるとしてよく、同様に他のプラットフォーム、特に、携帯可能な種類のものについても利用されるとしてよい。この電力管理アーキテクチャは、追加で外部デバイス用のハードウェアおよびソフトウェアを含むことを除いて、図２に示したものと同様である。また、ＩＶＲ４７６または他のＶＲ４５６が電力を供給するデバイス（外部または内部）を具体的に図示している。また、電力管理をさらに効率化するべくＰＭＵ４０４によって制御されるクロックツリーゲーティング設定レジスタ４８０を含む。
【００３７】
このＤＰＭＩ方式の実施形態によると、ＶＲ（ＩＶＲ）４７６は、同じ実施形態でＩＶＲと集積化される内部デバイス４５８に電力を供給するために用いられ、他のＶＲ（例えば、ＩＶＲ）４５６は、同じ実施形態でＩＶＲと集積化されていないデバイス４３９に電力を供給するために用いられる。さまざまな種類のデバイス（ＩＶＲと集積化されているもの、ＩＶＲと集積化されていないもの）をサポートするべく、複数の別個のＰＭＩ／ＤＰＭＩドライバ（４３６および４３７）がＯＳ  ＰＭフレームワーク４０２への２つの別個のパスについて提供される。また、ＰＭＵ１０４／ＤＰＭＩロジック４０６と集積化されていないデバイス４３９との間の通信用にＤＰＭＩ拡張ポート４５４も含まれている。
【００３８】
外部ＤＰＭＩポート（バスまたは他のインターコネクト）は、外部デバイスと共有するとしてもよく、外部デバイスの動作ステータスおよび電力状態要求をＤＰＭＩロジック４０６に通知するために用いられるとしてもよい。ＤＰＭＩベースのアーキテクチャは、デバイス（内部デバイスおよび外部デバイスの両方）を高効率ＤＰＭＩフレームワークに組み込むための基礎となるインフラストラクチャである。これによって、第三者の外部デバイスがＤＰＭＩエージェントを自身の構成に含めてデバイス動作ステータスおよび電力状態要求をＤＰＭＩロジックに示す場合、プラットフォーム電力利用効率を犠牲にすることなく第三者の外部デバイスを組み込むことが可能となる。一部の実施形態によると、ＤＰＭＩプロトコルは、例えば、Ｐコードおよび／またはＤＰＭＩロジックに、デバイス用の所定の電力状態遷移ポリシーと共に、ルックアップテーブルを含むとしてよい。第三者デバイスのベンダーは、電力管理ポリシー情報をルックアップテーブルに、例えば、プラットフォームのＰコードに組み込むことが出来るとしてもよい。このため、電力利用効率を改善するべく、当該ベンダーのデバイスについての電力状態を遷移させる際の戦略を完全に自由に定義するとしてよい。
【００３９】
図５は、プラットフォームパッケージ５００に集積化されている（単一セルまたはマルチセルの）電圧レギュレータ（ＩＶＲ）５０１を示す図である。各ＶＲ５０１は、プラットフォームデバイス１ＸＸに対する電圧供給ＶＲを制御するべく結合されている。各ＶＲは通常、図示されているように互いに結合されている監視コントローラ５０２、および、１以上の電圧レギュレータ（ＶＲ）セル５０４（ＶＲセル１からＶＲセルＮ）を含む。
【００４０】
各ＶＲセルの出力は、互いに結合されて、出力する供給電圧ＶＲを制御する。監視コントローラ５０２は、各セルからの負荷情報（例えば、セル内で生成される場合にはセル毎の平均電流、または、サンプリングされた電流）および／またはデバイス負荷からの負荷情報（例えば、出力電圧、合計出力電流等）に基づいて、ＶＲセル５０４に結合されてセルを制御する（ＰＭＵからのコマンドに従って、制御されている電圧を維持するためである）。監視コントローラ５０２は、供給コマンド（例えば、ＶＩＤ）および、可能であれば、デバイス負荷に対する適切な供給レベルを提供するための他の情報を受け取るべくＰＭＵおよび／またはＤＰＭＩロジックに結合されるとしてよい。
【００４１】
一部の実施形態によると、ＤＰＭＩロジックは、デバイス（例えば、プロセッサ、送受信機、ＵＳＢインターフェース、オーディオコーデック等）から、適切なデバイス動作状態および監視されている電流需要に基づいてセルを制御するべく、動作状態情報を受信するとしてよい。一部の実施形態によると、監視コントローラは、現在消費されている負荷電流に基づき、（デバイスの動作状態から決定される範囲内の）適切な数のセルを用意する機能を持つとしてよい。監視コントローラ５０２は、この機能を実行する任意の適切な回路を持つとしてよい。例えば、コントローラ（または、その他の処理ユニット回路）を含むとしてよい。ディスクリートロジック、および、ＶＲセル５０４を制御するという特定の目的を実現するべく構成されているアナログ素子を含むとしてよい。または、論理素子、アナログ回路、および、より汎用化されている制御回路の組み合わせを含むとしてよい。
【００４２】
一部の実施形態によると、各ＶＲセル５０４は、自身のコントローラおよび電力変換回路を持ち、独立して機能する電圧レギュレータを構成しているとしてよい。例えば、ＶＲ５０４は、バック型スイッチおよび出力部から構成されるアレイ構造であって、多相構成を持ち、図示されているように、出力電圧ＶＲを制御するように結合されているアレイ構造に結合されているコントローラを含むとしてよい。一部の実施形態によると、出力部は、ＩＶＲダイおよび／またはＩＶＲパッケージに集積化されて結合されているインダクタを含むとしてもよい。インダクタが結合されている場合、インダクタの飽和度は、負荷電流にはほとんど（または全く）依存していないので、熱に関する特定の条件および限界に応じて、電力セル（ＶＲセル５０４）が短期間だけ連続定格を越える電流を供給できるという利点がある。
【００４３】
一部の実施形態によると、複数のＶＲセル５０４は、互いに同様の構成を持つとしてよく、（同等でなければ）類似の定常出力電流機能を持つ。例えば、各ＶＲセル５０４は、１アンペアから５アンペア、または、１００ミリアンペアから１アンペアの間の範囲内で動作が高効率および高信頼性となり、約１ボルトまたは所与のデバイス電力状態の任意の特定の電圧である制御ＤＣ電圧を供給するとしてよい。また、動的に変化する負荷条件に効果的に対応することを目的として、デバイス負荷１ＸＸの動作周波数に応じて、動的にアクティブ状態および非アクティブ状態となるように、十分に高いスイッチング周波数で動作するとしてよい。例えば、各セルのスイッチング周波数が２０ＭＨｚから１００ＭＨｚ（またはこれ以上）の範囲である場合に、十分なレベルの応答性が得られ、負荷応答が高速化されるとしてよい。例えば、数十ナノ秒になるとしてよい。
【００４４】
（尚、図示している実施形態では、インダクタを含む複数のＶＲセルは、ＳｏＣパッケージの場合のように、１つのチップに集積化されているとしてよく、例えば、プラットフォームの主要ダイまたはダイおよび基板に集積化されているとしてよい。これに代えて、デバイスを含むダイに隣接して設けられている別のダイの一部であるとしてもよく、複数のダイを含む１つの共通ＩＣパッケージの一部であるとしてよい。ＶＲまたはＶＲドメインが対応するデバイス負荷に近接して設けられていることによって、スイッチング損失が過大になることを回避しつつ、例えば、２０ＭＨｚを超える周波数で駆動することが可能になるとしてよい。
【００４５】
図６は、ＤＰＭＩ実装プラットフォーム６００内の対応付けられているデバイス６１１の供給電圧を制御するべく結合されているマルチセルＩＶＲ６０１の実施形態を示す図である。ＩＶＲ６０１は、複数のマルチセルＶＲドメイン６０４（６０４１から６０４Ｎ）を有する。各マルチセルＶＲドメイン６０４は、上述したように複数のセルを含んでおり、プラットフォーム６００内の対応するデバイス６１１（６１１１から６１１Ｎ）に結合されている。各ＩＶＲ６０４は、対応付けられているデバイスに対する供給電圧を制御するべく、例えば、図８から図１０に示すルーチンに従って、動作を高効率化させるべく制御される複数のセルを含む。図５のＩＶＲと同様に、ＩＶＲ６０１は、ＰＭＵ６１４からの情報に基づいて、例えば、ＤＰＭＩロジック６１６によって供給されるデバイス電力ステータス情報に基づいて、各ＩＶＲドメイン６０４内のセルをイネーブルおよびディセーブルするべく各ＩＶＲドメイン６０４を制御する監視コントローラ６０２を含む。
【００４６】
図７は、ＳｏＣまたはマルチコアプロセッサ集積回路（ＩＣ）等用のプラットフォームパッケージを示す断面図である。当該プラットフォームパッケージでは、図示されているように、マルチセル集積型電圧レギュレータ（ＩＶＲ）ダイ７０１およびＤＰＭＩ実装プラットフォームダイ７１０が互いに結合されている。ＩＶＲダイ７０１は、パッケージ基板７２０内に埋設されており、プラットフォームダイは基板７２０に実装され、高効率に信号を伝導させるべくＩＶＲダイ７０１に対向している。（本実施形態では、基板７２０は、プラットフォーム７１０およびＩＶＲ７０１の両方のパッケージ基板として機能する。尚、複数のダイは、互いに実際に接触していてもいなくてもよい。互いに当接する表面部分の一部または全てにわたって、１以上の他の材料がダイ間に設けられているとしてもよい。このような材料は、構造安定化、熱伝達、電力および信号のグリッド等に利用され得る。）
【００４７】
上述したように、ＩＶＲダイ７０１は、１以上のマルチセルＶＲドメインを含むとしてよく、ＤＰＭＩプラットフォームダイ７１０は、１以上のデバイスを含むとしてよい。このパッケージ構成では、ダイが互いに隣接するように実装されており、ＶＲドメインの回路素子は、対応付けられているデバイスに対してより近接して設けることが可能となる。これによって、比較的大量の電流をデバイスに伝導させる上で十分な導電経路が（例えば、ハンダバンプまたはその他の接触素子によって）得られる。（尚、１以上のダイを用いてデバイスおよびＶＲを実現する任意の適切なパッケージ構成を実施するとしてよく、このようなパッケージ構成は本発明の範囲内であると考えられたい。）例えば、ＩＶＲダイは、プラットフォームダイの「下方」にあるのではなく、プラットフォームダイの「上方」にあるとしてよい。これに代えて、ＩＶＲダイはプラットフォームダイに隣接して設けられるとしてよく、ＩＶＲダイは部分的にプラットフォームダイに対向するとしてよく、または、両者は同じダイの一部であるとしてもよい。）
【００４８】
図８は、監視コントローラによって実行されるルーチンであって、対応するデバイスの動作状態に基づいて、許容可能なアクティブセル範囲、つまり、一のマルチセルＶＲ内でアクティブとなるセルの数の範囲を決定し、アクティブなセルの数を制御して、範囲内に留まるようにするルーチンを説明するための図である。例えば、この構成は、所与の電力動作状態のスプリアス負荷電流の変化に応じて追加または削除するセルの数が多くなり過ぎないようにするために望ましいとしてよい。範囲の限界自体は、デバイス／システム／プラットフォームが取り得る動作状態毎に、当該動作状態について期待される最大過渡負荷条件および最大静的負荷条件に基づいて、予め定められているとしてよい。
【００４９】
当該ルーチンは、動作状態が変化すると、例えば、デバイスからの要求に応じてＰＭＵから監視コントローラに通知されると、８０２から開始される。例えば、デバイスがグラフィクスプロセッサである場合、グラフィクスプロセッサ内のデバイスエージェントは、当該グラフィクスプロセッサの状態の変化をＤＰＭＩロジックに通知するとしてよい。８０４において、新たな最大限度および最少限度（ｎｍａｘ,ｎｍｉｎ）を設定する。範囲の適切な限度は、任意の適切な方法を用いて決定することができる。例えば、限度が負荷の動作状態に基づいて定義されているルックアップテーブルから取得することができる。
【００５０】
現在のアクティブセル数（ｎａｃｔ）は、限度（ｎｍａｘ,ｎｍｉｎ）によって設定される範囲外である場合、当該ルーチンによって更新される。８０６において、現在のアクティブセル数（ｎａｃｔ）がｎｍａｘよりも大きい場合、８０８において、ｎａｃｔをｎｍａｘに変更して、ルーチンを終了する。そして、動作状態が再び変化するまで待機する。現在のアクティブセル数（ｎａｃｔ）がｎｍａｘ以下の場合、８１０に進み、ｎａｃｔが小さすぎるか否か、つまり、セルの動作効率が不十分に低いか否かを確認する。ｎａｃｔがｎｍｉｎよりも小さい場合、８１２において、ｎａｃｔはｎｍｉｎに変更され、ルーチンを終了する。そして、動作状態が再び変化するまで待機する。
【００５１】
図９は、許容可能なアクティブセル範囲（例えば、上述したもの）に基づいて、そして、各アクティブセル電流（ＩＣｅｌｌ）値に基づいて、アクティブである必要があるセルの数（ｎａｃｔ）を決定するルーチンを説明する図である。本明細書で用いる場合、「各アクティブセル電流値」および「ＩＣｅｌｌ」という用語は、電流（負荷電流）値を意味する。例えば、アクティブセルの電流に対応する電流の推定値、算出値、測定値、または、これらの値の組み合わせである。この値は、様々な方法で、直接的または間接的に求められるとしてよい。例えば、複数のセルのバランスが十分に取れている場合、アクティブセルのうち任意のセルのサンプル値または平均値で十分であるとしてよい。一方、バランスが十分でなく確実でない場合、最悪セル（例えば、最大電流値をとるセル）からの平均値またはサンプル値を用いるとしてよい。または、合計出力負荷電流値またはあるセルの電流値のいずれを利用するかは必ずしも問題ではない。例えば、監視コントローラは、合計出力電流値を取得して、ターゲット値（またはターゲット範囲）に対して取得した合計出力電流値を直接制御するか、または、例えば、セル負荷のバランスが取れていると仮定できる場合には、合計出力電流値から各アクティブセル電流値の平均値を算出して、各セル電流値のターゲット値に対して制御するとしてよい。さらに、電流または電流信号は、実際に算出または監視されるのではないとしてよい。つまり、電流との間に相関関係がある電圧信号（またはその他の信号）を用いるとしてもよい。したがって、特定の種類の各アクティブセル電流（ＩＣｅｌｌ）値または各アクティブセル電流（ＩＣｅｌｌ）値を求める特定の方法は本発明の教示内容を実施する上で必要ではなく、本発明は特定のものに限定されないことを明確にしておきたい。
【００５２】
図９は、ＩＣｅｌｌを制御してターゲット電流値（Ｉｔａｒｇｅｔ）に近づけるためのルーチンを示す図である。当該ルーチンは、本実施形態において、どの動作状態についても同じである。（各セルの電力変換効率は、合計負荷電流の量の影響を受けるのではなく、当該セルが提供する電流の値の影響を受けることに留意されたい。）各アクティブセル電流（ＩＣｅｌｌ）が小さ過ぎる場合、アクティブセル数（ｎａｃｔ）を少なくして、各アクティブセル電流を大きくするように試みる。各アクティブセル電流（ＩＣｅｌｌ）が大き過ぎる場合、アクティブセル数を大きくして、各アクティブセル電流を少なくするように試みる。
【００５３】
最初に、９０２において、各アクティブセル電流（ＩＣｅｌｌ）値（例えば、複数のアクティブセルの電流値のうち最も大きい電流値）を決定する。ここからは、２つの経路があり（小さ過ぎる場合の経路、大き過ぎる場合の経路）、同時に実行するとしてよい。第１の経路（小さ過ぎる場合の経路）では、ルーチンは、９０４において、ＩＣｅｌｌ値が十分な長さの期間、つまり、十分なウィンドウにわたって維持されるか否かを判断する。このステップは、安定化を目的としたものであり、短期間のドループ（ｄｒｏｏｐ）に応じてセルを落としてしまわないためのものである。ＩＣｅｌｌが十分な長さの期間にわたって所与の値（または所与の値未満）を維持する場合、９０６において、このＩＣｅｌｌ値は小さ過ぎると判断する。例えば、９０６Ａで示すように、ＩＣｅｌｌが小さ過ぎるか否かを判断する際、ルーチンは、ＩＣｅｌｌをアクティブセル数に反比例する量だけ調整するとしてよい。これは、ｎａｃｔが小さくなるにつれてあるセルを落としにくくなるように重み付けするためである。９０６Ａにおいて、ＩＣｅｌｌは、ｎａｃｔ／（ｎａｃｔ−１）で乗算して、このように重み付けする。
【００５４】
ＩＣｅｌｌが小さ過ぎるとは判断されない場合、ルーチンは９０２に戻るが、ＩＣｅｌｌが実際には小さ過ぎる場合には、９０８において、現在アクティブセル数（ｎａｃｔ）がｎｍｉｎより大きいか否かを確認する。ｎａｃｔがｎｍｉｎよりも大きい場合、ルーチンは９１２に進んで、ｎａｃｔをデクリメントして、つまり、セルを落として、９０２に戻る。しかし、９０８において、ｎａｃｔがｎｍｉｎ以下であると判断されると、ルーチンは９１０に進んで（ｎａｃｔは現在のレベルを維持）、スイッチレッグ低減ルーチンを実行させる。スイッチレッグ低減によれば、アクティブセル内の１以上のスイッチレッグを落とすことによって、電力をさらに節約することができる。このようなルーチンの一例を図１０に示す。ここから、ルーチンは９０２に戻る。
【００５５】
（スイッチレッグ低減では、互いに並列に結合されている１以上のスイッチレッグをディセーブルして、フェーズレッグ、例えば、フェーズのインダクタに供給される電力を制御する。これは、フェーズレッグを削減するフェーズ低減とは対照的である。スイッチレッグ低減では、フェーズはアクティブのままであるが、ブリッジ、または、スイッチ、トランジスタのサイズを調整して、ブリッジインピーダンスを増減して、負荷電流の関数としてブリッジ効率を改善する。これは、ブリッジを構成している並列結合されたスイッチレッグのセットを選択してイネーブルまたはディセーブルすることによって行われる。フェーズ低減と比較した場合のスイッチレッグ低減の利点は、回路動作に対してトランスペアレントであり、結合しているインダクタと共に利用する場合にはより効果的である点である。）
【００５６】
以下では、９０２以降の「大き過ぎる場合の経路」を説明する。９１４において、ルーチンは、ＩＣｅｌｌ値が大き過ぎるか否かを判断する。（尚、「小さ過ぎる場合の経路」とは違って、ＩＣｅｌｌ値が十分な長さの期間にわたって維持されていることを最初に確認しない。これは、本実施形態では、例えば、瞬時の負荷ライン増加および持続的な負荷ライン増加を補償することが十分に可能な程度、高速に応答するためである。この点に留意されたい。この経路で処理を実行するためのロジック、例えば、専用ロジック回路は、高速処理に特化して設計されているとしてよい。）
【００５７】
ＩＣｅｌｌが高過ぎるか否かを判断する方法の一例を９１４Ａに示す。ここにおいて、ルーチンでは、（ＩＣｅｌｌ／Ｉｔａｒｇｅｔ）＋１の切り捨て値がｎａｃｔよりも大きいか否かを判断する。（尚、ＩＣｅｌｌが高過ぎると判断しやすいように重み付けされている。このため、１以上のセルが追加されることになる。）ＩＣｅｌｌが高過ぎる場合、９１６において、アクティブセル数を多くする。例えば、９１６Ａにおいて、ｎａｃｔの値を（ＩＣｅｌｌ／Ｉｔａｒｇｅｔ）＋１の切り捨て値に設定する。このようにして、ｎａｃｔは、電流スパイクを高速に補償するべく、１より大きい値だけ大きくすることができる。他の実施形態では、別の方法を利用して、ｎａｃｔを単に、インクリメントまたはデクリメントすることができる。ｎａｃｔを大きくした後、ルーチンは９０２に戻る。
【００５８】
セルをディセーブルすることによって、効率が効果的に改善される。しかし、上記の９１０であり得るケースであるが、アクティブセル数が最少値に到達すると、アクティブセルのトランジスタブリッジのサイズを調整する（つまり、ブリッジ内のアクティブスイッチレッグの数を低減する）ことによっても、効率が改善される。これは、残りのアクティブセルのコントローラで実現されるとしてよい。セルのアクティブスイッチレッグの数を変更するルーチンは、図１０に示すルーチンに反映されているように、セル数を変更するルーチンと同様であるとしてよい。
【００５９】
図１０は、１つのアクティブセル内でアクティブにするべきスイッチレッグの数を決定するルーチンを示す図である。このルーチンは、図９に示したルーチンと同様であるので、詳細な説明は省略する。ＩＬｅｇは、ＩＣｅｌｌと同様であり、セル内の各スイッチレッグ電流である。ｎＬａｃｔは、現在アクティブなスイッチレッグの数である。（ＩＬｅｇは、ＩＣｅｌｌと同様に、さまざまな方法で決定され得るとともに、レッグ電流である必要はなく、合計セル電流に対応するとしてもよい。つまり、ＩＬｅｇは、実際の各レッグ電流とする代わりに、Ｉｔａｒｇｅｔを適切に調整した場合の合計セル出力電流に対応するとしてもよい。）
【００６０】
上記の説明および請求項では、以下に記載する用語は以下で説明するように解釈されたい。「結合」および「接続」を利用する場合がある。「結合」および「接続」は、互いに同義語として用いているわけではないと理解されたい。特定の実施形態では、「接続」という用語は、２以上の構成要素が物理的または電気的に直接接触していることを意味する場合に用いる。「結合」という用語は、２以上の構成要素が互いに協働または相互作用するが、物理的または電気的には直接接触していてもしていなくてもよいことを意味する場合に用いられる。
【００６１】
図１１は、ＤＰＭＩからの電力状態通知に基づいて適切なＩＶＲ電力状態動作をＰＭＵが決定する手順を説明するための図である。図８、９および図１０に示すＩＶＲルーチンは、電力使用の高効率化を実現するべくＩＶＲの監視コントローラが実行する電力状態動作の一例を示す。
【００６２】
最初に、１１０２において、ＰＭＵは電力状態イベントが発生しているか否かをＤＰＭＩロジックに質問する。この後、１１０４において、ＤＰＭＩが電力状態変更要求を受信したか否かを確認する。ＤＰＭＩを介して電力状態イベントが通知されない場合、１１１４において、ＯＳＰＭフレームワークから電力状態イベント発生の通知があるか否かを継続して質問する。１１１４において、ＯＳＰＭ電力状態イベントが発生していない場合、最初の１１０２に戻る。１１１４から、当該手順は、１１１０に進み、適切なＰコード手順を実行して、ＯＳＰＭ電力状態要求を満足させ、ＩＶＲの監視コントローラに対して必要なＩＶＲルーチンを指示する。１１１０の後、ＩＶＲは、１１１２において選択された動作を実行する。例えば、電源電圧／クロック、ツリーステータスを調整したり、アクティブＩＶＲセル範囲を決定したり等する。当該ルーチンはこの後、１１１０から最初の１１０２に戻る。１１０４において、ＤＰＭＩ電力状態イベントが発生すると、当該ルーチンは１１０６に進み、ＤＰＭＩイベントよりも優先度が高いＯＳＰＭ電力状態イベントがあるか否かを判断する。ＯＳＰＭ電力状態イベントの優先度の方が高い場合（例えば、所与のポリシーに基づいて判断される）、当該ルーチンは、１１１０に進み、ＯＳＰＭ要求を満足させる。１１０６においてＤＰＭＩ電力状態イベントの方が優先度が高いと判断される場合、１１０８に移動して、ＰＭＵはポリシールックアップテーブルを確認して、ＤＰＭＩを介して当該イベントが発生しているデバイスのための電力状態要求について適切なＩＶＲ動作を決定する。ＩＶＲの監視コントローラに必要なＩＶＲ動作を指示する。１１０８から１１１０に進み、ＩＶＲの監視コントローラは必要なルーチンを実行する。
【００６３】
図１１に示すルーチンの例は、連続して実行され、ＤＰＭＩを介してデバイスから発生する電力状態要求またはＯＳＰＭから発生する電力状態イベントは、所与の優先順位に従って処理される。ＩＶＲの監視コントローラは、必要な動作を実行して、電力利用効率を高く維持するというプラットフォーム電力管理の目的を実現するように指示される。
【００６４】
本発明は、上述した実施形態に限定されず、請求項に記載する本発明の意図および範囲に応じて変形および変更しつつ実施可能である。例えば、本発明は、あらゆる種類の半導体集積回路（ＩＣ）チップと共に利用可能であると考えられたい。このようなＩＣチップの例には、これらに限定されないが、プロセッサ、コントローラ、チップセット構成要素、プログラマブルロジックアレイ（ＰＬＡ）、メモリチップ、ネットワークチップ等が含まれる。
【００６５】
また、一部の図面では、信号伝導ラインを線で示していると考えられたい。線の中には、より多くの構成要素である信号経路を示すべく太く図示されているものがあり、数字を付して構成要素である信号経路の数を示しているものがあり、および／または、主な情報の流れの方向を示すべく１以上の端部において矢印が付されているものがあるとしてよい。しかし、これは本発明を限定するものと解釈されるべきではない。このように追加される詳細な内容は、回路を理解し易くするべく、１以上の実施形態例に関連付けて用いられているとしてよい。表示している任意の信号ラインは、追加情報を含んでいようといまいと、実際には、複数の方向に進む１以上の信号を含むとしてよい。さらに、任意の適切な種類の信号方式で実現するとしてよく、例えば、差動対、光ファイバラインおよび／またはシングルエンデッドラインで実施するデジタルラインまたはアナログラインであってよい。
【００６６】
サイズ／モデル／値／範囲の例を挙げているが本発明はこれに限定されるものではないと考えられたい。製造方法（例えば、フォトリソグラフィー）は今後発展していくであろうが、デバイスサイズが小型化し得るものと予測される。また、ＩＣチップおよびその他の構成要素に対する公知の電力／グラウンド接続は、図示および説明を簡略化するべく、そして、本発明をあいまいにすることを避けるべく、図中に図示しているとしてもしていなくてもよい。さらに、構造をブロック図で図示しているが、これは、本発明があいまいにならないようにするためであり、このようにブロック図で示す構造を実施する際の具体的事項は、本発明が実施されるプラットフォームに大きく左右される、つまり、当業者によって十分に理解されているはずであるという事実を鑑みてのことである。具体的且つ詳細な内容（例えば、回路）を記載して本発明の実施形態例を説明しているが、本発明はこういった具体的且つ詳細な内容を利用することなく、または、そういった内容を変更しつつ実施し得ることが当業者には明らかである。このため、本明細書は、本発明を限定するものではなく例示するものと考えられたい。
【図１Ａ】
2013513190.tif 000003
【図１Ｂ】
2013513190.tif 000004
【図２】
2013513190.tif 000005
【図３】
2013513190.tif 000006
【図４】
2013513190.tif 000007
【図５】
2013513190.tif 000008
【図６】
2013513190.tif 000009
【図７】
2013513190.tif 000010
【図８】
2013513190.tif 000011
【図９】
2013513190.tif 000012
【図１０】
2013513190.tif 000013
【図１１】
2013513190.tif 000014
【国際調査報告】
2013513190.tif 000015
2013513190.tif 000016