(57)【特許請求の範囲】
【請求項１】
一又は複数のブレークイベントを発行する方法であって、
第１のイベントソースからの第１のブレークイベントを検出するステップと、
第２のイベントソースからの第２のブレークイベントを検出するステップと、
プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントの前記プラットフォームへの発行を協調するステップであって、前記ランタイム情報は低電力状態ブレークイーブン時間を特定するステップ
とを有する方法。
【請求項２】
前記第１と第２のブレークイベントの発行を協調するステップは、前記ランタイム情報に少なくとも部分的に基づいて保持時間を決定するステップと、前記保持時間に少なくとも部分的に基づいて前記第１と第２のブレークイベントのうち少なくとも一方を延期するステップとを含む、請求項１に記載の方法。
【請求項３】
前記第１と第２のイベントソースのうち少なくとも一方から前記ランタイム情報を取得するステップをさらに含む、請求項１に記載の方法。
【請求項４】
前記ランタイム情報は前記プラットフォームに結合した装置から取得され、前記第１と第２のブレークイベントのうちの少なくとも一方は入出力イベントを含み、前記ランタイム情報は前記入出力イベントの遅延時間を示す、
請求項３に記載の方法。
【請求項５】
前記ランタイム情報は前記プラットフォーム上のアクティブアプリケーションから取得され、前記第１と第２のブレークイベントのうちの少なくとも一方はタイマーイベントを含み、前記ランタイム情報は前記タイマーイベントの遅延可能特性を示す、請求項３に記載の方法。
【請求項６】
前記プラットフォームから前記ランタイム情報を取得するステップをさらに含む、請求項１に記載の方法。
【請求項７】
前記ランタイム情報はプログラム可能性能要件を特定する、
請求項６に記載の方法。
【請求項８】
一又は複数のブレークイベントを発行する装置であって、
入出力モジュールを有し、前記入出力モジュールは、
第１のイベントソースからの第１のブレークイベントを検出する手段と、
第２のイベントソースからの第２のブレークイベントを検出する手段と、
プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントのプラットフォームへの発行を協調する手段であって、前記ランタイム情報は低電力状態ブレークイーブン時間を特定する手段とを有する、
装置。
【請求項９】
前記第１と第２のブレークイベントの発行の協調は、前記ランタイム情報に少なくとも部分的に基づく保持時間の決定と、前記保持時間に少なくとも部分的に基づく前記第１と第２のブレークイベントのうち少なくとも一方の延期とを含む、請求項８に記載の装置。
【請求項１０】
前記入出力モジュールは、前記第１と第２のイベントソースのうち少なくとも一方から前記ランタイム情報を取得する手段をさらに含む、
請求項８に記載の装置。
【請求項１１】
前記ランタイム情報は前記プラットフォームに結合した装置から取得されるものであり、前記第１と第２のブレークイベントのうちの少なくとも一方は入出力イベントを含むものであり、前記ランタイム情報は前記入出力イベントの遅延時間を示すものである、請求項１０に記載の装置。
【請求項１２】
前記ランタイム情報は前記プラットフォーム上のアクティブアプリケーションから取得されるものであり、前記第１と第２のブレークイベントのうちの少なくとも一方はタイマーイベントを含むものであり、前記ランタイム情報は前記タイマーイベントの遅延可能特性を示すものである、
請求項１０に記載の装置。
【請求項１３】
前記入出力モジュールは、前記プラットフォームから前記ランタイム情報を取得する手段をさらに有し、前記ランタイム情報は、プログラム可能性能要件を特定する、請求項８に記載の装置。
【請求項１４】
一又は複数のブレークイベントを発行するシステムであって、
第１のイベントソースと、
第２のイベントソースと、
プロセッサと、
前記プロセッサに結合した入出力モジュールとを有し、前記入出力モジュールは、
前記第１のイベントソースからの第１のブレークイベントを検出する手段と、
前記第２のイベントソースからの第２のブレークイベントを検出する手段と、
前記システムに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントの前記システムへの発行を協調する手段であって、前記ランタイム情報は低電力状態ブレークイーブン時間を特定する手段とを有する、
システム。
【請求項１５】
前記第１と第２のブレークイベントの発行の協調は、前記ランタイム情報に少なくとも部分的に基づく保持時間の決定と、前記保持時間に少なくとも部分的に基づく前記第１と第２のブレークイベントのうち少なくとも一方の延期とを含む、請求項１４に記載のシステム。
【請求項１６】
前記入出力モジュールは、前記第１と第２のイベントソースのうち少なくとも一方から前記ランタイム情報を取得する手段をさらに含む、
請求項１４に記載のシステム。
【請求項１７】
前記第１と第２のイベントソースのうち少なくとも一方は前記システムに結合した装置を含み、前記第１と第２のブレークイベントのうち少なくとも一方は入出力イベントを含むものであり、前記ランタイム情報は前記入出力イベントの遅延時間を特定するものである、請求項１６に記載のシステム。
【請求項１８】
前記第１と第２のイベントソースのうち少なくとも一方はアクティブアプリケーションを実行する前記システムのコンポーネントを含み、前記第１と第２のブレークイベントのうち少なくとも一方はタイマーイベントを含むものであり、前記ランタイム情報は前記タイマーイベントの遅延可能特性を特定するものである、請求項１６に記載のシステム。
【請求項１９】
前記入出力モジュールは、前記システムから前記ランタイム情報を取得する手段をさらに含み、前記ランタイム情報は、プログラム可能性能要件を特定する、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
実施形態は、概してプラットフォームブレークイベント（platform  break  events）の管理に関する。より具体的には、実施形態は、プラットフォーム省電力化のための、異なるソースからのブレークイベントの発行の協調に関する。
【背景技術】
【０００２】
従来のモバイルコンピューティングプラットフォームでは、複数のＩＯ（入出力）装置（例えば、通信インタフェース）とソフトウェアアプリケーションが、協調せずにブレークイベントを発生しがちであり、そのためにプラットフォームとそのコンポーネントは低電力状態に速く入って長時間その状態に留まることが妨げられている。実際、バッテリー寿命が短く最適でないのは、プラットフォームが必要以上に大電力状態に留まる結果である。
【発明の概要】
【課題を解決するための手段】
【０００３】
一実施形態による、一又は複数のブレークイベントを発行する方法は、第１のイベントソースからの第１のブレークイベントを検出するステップと、第２のイベントソースからの第２のブレークイベントを検出するステップと、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントのプラットフォームへの発行を協調するステップとを有する。
【０００４】
他の一実施形態による一又は複数のブレークイベントを発行する装置は、入出力モジュールを有し、前記入出力モジュールは、第１のイベントソースからの第１のブレークイベントを検出する手段と、第２のイベントソースからの第２のブレークイベントを検出する手段と、プラットフォームに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントのプラットフォームへの発行を協調する手段とを有する。
【０００５】
さらに他の一実施形態による一又は複数のブレークイベントを発行するシステムは、第１のイベントソースと、第２のイベントソースと、プロセッサと、前記プロセッサに結合した入出力モジュールとを有し、前記入出力モジュールは、前記第１のイベントソースからの第１のブレークイベントを検出する手段と、前記第２のイベントソースからの第２のブレークイベントを検出する手段と、前記システムに関連するランタイム情報に少なくとも部分的に基づき、前記第１と第２のブレークイベントの前記システムへの発行を協調する手段とを有する。
【図面の簡単な説明】
【０００６】
添付した図面を参照して、以下の明細書と特許請求の範囲とを読めば、当業者には、本発明の実施形態のいろいろな有利性が明らかとなるであろう。
【図１】一実施形態による協調した複数のコンピューティングシステムの一例を示すブロック図である。
【図２】一実施形態によるブレークイベント管理部の一例を示すブロック図である。
【図３】一実施形態によるブレークイベントの発行の協調方法の一例を示すフローチャートである。
【図４】一実施形態によるブレークイベント管理部と複数の合体部を示すブロック図である。
【図５】一実施形態によるプラットフォームの一例を示すブロック図である。
【発明を実施するための形態】
【０００７】
実施形態は、第１のイベントソースからの第１のブレークイベントを検知し、第２のイベントソースからの第２のブレークイベントを検知する方法を提供する。また、本方法は、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第１と第２のブレークイベントのプラットフォームへの発行を協調するステップを提供する。
【０００８】
他の実施形態は、プロセッサにより実行されると、コンピュータに、第１のイベントソースからの第１のブレークイベントを検知させ、第２のイベントソースからの第２のブレークイベントを検知させる一組の命令を有するコンピュータ読み取り可能記憶媒体を含む。また、本命令は、コンピュータに、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第１と第２のブレークイベントのプラットフォームへの発行を協調させるステップを提供する。
【０００９】
また、実施形態は、第１のイベントソースからの第１のブレークイベントを検知し、第２のイベントソースからの第２のブレークイベントを検知する論理を有する入出力（ＩＯ）モジュールを有する装置を含む。また、この論理は、プラットフォームに関連するランタイム情報に少なくとも部分的に基づいて、第１と第２のブレークイベントのプラットフォームへの発行を協調する。
【００１０】
また、実施形態は、第１のイベントソースと、第２のイベントソースと、プロセッサと、そのプロセッサに結合した入出力（ＩＯ）モジュールとを有するシステムを含む。このＩＯモジュールは、第１のイベントソースからの第１のブレークイベントを検知し、第２のイベントソースからの第２のブレークイベントを検知する論理を有する。また、この論理は、システムに関連するランタイム情報に少なくとも部分的に基づいて、第１と第２のブレークイベントのシステムへの発行を協調する。
【００１１】
ここで図１を参照し、異なるソース（例えば、複数の電力管理エンティティ）からの複数のブレークイベント１０（１０ａ−１０ｆ）を、そのブレークイベント１０のプラットフォームへの発行の協調の前後で示す。図示した一例では、マウスなどの装置からの入出力（ＩＯ）イベント１０ａ（例えば、割り込み）が時刻ｔ１に要求され、プラットフォーム上で実行されているアクティブなアプリケーションからのタイマーイベント１０ｂが時刻ｔ２に要求される。また、ネットワークインタフェースカード（ＮＩＣ）などのその他の装置からの一連のＩＯイベント１０ｃが時刻ｔ３で要求される。後でより詳しく説明するが、ＩＯイベント１０ｃは、それ自体が、ＮＩＣ上に又は集中して配置された合体部（coalescing  unit）によりグループ化される。また、オーディオ装置からのＩＯイベント１０ｄが時刻ｔ４に要求される。また、図示した例には、時刻ｔ５とｔ６それぞれにおけるアクティブアプリケーションからのタイマーイベント１０ｅと１０ｆを示した。ネイティブ状態では、ブレークイベント１０は、プラットフォームが、長時間省電力状態に入ることを妨げる時間プロファイルを有する。
【００１２】
したがって、ブレークイベント１０のプラットフォームへの発行を協調して、プラットフォームに電力消費を低減させることができる。例えば、図示したマウスからのＩＯイベント１０ａは、アプリケーションタイマーイベント１０ｂ（後の時刻ｔ２ｄで発行される）の発行と合うように、時刻ｔ１ｄまで遅れさせられる。他の一例として、タイマーイベント１０ｂは遅延できないイベントであるとする。かかる場合、ＩＯイベント１０ａは遅延され、一方タイマーイベント１０ｂはスケジュール通りに発行される。いずれの場合でも、アイドル時間１２は長くなり、プラットフォームはより早く、より長い時間、より深い省電力状態（例えば、ACPI  /  Advanced  Configuration  and  Power  Interface  Specification,  ACPI  Specification,  Rev.  ４.０,  June  １６,  ２００９,省電力状態）に入ることができる。また、ＮＩＣからのＩＯイベント１０ｃは、オーディオ装置からのＩＯイベント１０ｄと、それぞれ後の時刻ｔ３ｄとｔ４ｄにおいて合わせ（align）、時間１４を長くすることができる。同様に、アプリケーションタイマーイベント１０ｅと１０ｆは、それぞれ時刻ｔ５ｄとｔ６ｄまで遅延させ、時間１６を長くすることができる。簡単に言うと、時間１２、１４、１６が長くなったので、プラットフォームの省電力が向上し、バッテリーの寿命が延びる。
【００１３】
図２は、複数のブレークイベント２０を検知して、プラットフォーム／オペレーティングシステム（ＯＳ）２６に関連するランタイム情報２４に少なくとも部分的に基づき、それらを時間的に合わせて（align）協調ブレークイベント２２とするブレークイベント管理部（ＢＭＵ）１８を示す。ＢＭＵ１８は、プラットフォーム２６のモジュールに実装されてもよく、例えばモバイルインターネットデバイス（ＭＩＤ）プラットフォームのシステム制御部（ＳＣＵ）又はラップトッププラットフォームのプラットフォームコントローラハブ（ＰＣＨ）に実装されてもよい。実際、ＢＭＵ１８は、インターフェースと実装手法が若干異なるオペレーティングシステム（ＯＳ）のカーネル空間中にあっても、ユーザ空間にあってもよい。図示した例では、ランタイム情報２４は、ブレークイベント２０のソース２８から、及びプラットフォーム２６自体から取得できる。例えば、プラットフォームに結合した装置から取得したランタイム情報２４は、一又は複数のＩＯイベントの最大遅延時間を指定するＱｏＳ（サービス品質）仕様を含む。また、アプリケーションから取得したランタイム情報２４は、一又は複数のタイマーイベントの遅延可能特性（deferability  characteristic）を示すものであってもよい。例えば、タイマーイベントが遅延可能でなければ、ＢＭＵ１８は、他のブレークイベントを、その遅延可能でないタイマーイベントと時間合わせ（align）するように試みる。タイマーイベントが遅延可能であれば、ＢＭＵ１８はタイマーイベントを管理して、プラットフォームの省電力と性能を最適化できる。
【００１４】
例として、アプリケーションが、タイマーイベントを５０ｍｓごとに、１００ｍｓの最大頻度まで遅延可能である場合、ＢＭＵ１８は、プラットフォーム２６が比較的にアクティブでない間、１００ｍｓごとにタイマーイベントをトリガーする。しかし、他のソースにより発生されるブレークイベントによりプラットフォーム２６がもっとアクティブになると、ＢＭＵ１８は、電力消費に悪い影響を与えずに、タイマーイベントの発行を５０ｍｓに合わせて、アプリケーション性能を良くすることができる。
【００１５】
また、プラットフォーム２６は、ランタイム情報２４を低電力状態ブレークイーブン時間やプログラマブル性能要件等の形式で提供できる。低電力状態ブレークイーブン時間は、低電力状態に入ったり出たりするのに伴う電力コストオーバーヘッドをオフセット／償却するために、プラットフォーム２６が、ある低電力状態にいるべき時間を示す。後でより詳しく説明するが、ＢＭＵ１８は、低電力状態ブレークイーブン時間を用いて、遅延された各ブレークイベントの保持時間を決定できる。これに関して、保持時間がブレークイーブン時間よりずっと長くなると、省電力の利益が急速に低下し、性能が大幅に悪くなる。よって、ＢＭＵ１８は、ブレークイーブン時間と所望の性能とに基づき、合理的な保持時間を決定できる。
【００１６】
プログラマブル性能要件はプラットフォーム２６のユーザにより決定できる。よって、ユーザは性能を高くしたければ、応答を速くして性能を改善するために、（省電力の機会を失う可能性はあるが）保持時間を短くする。他方、ユーザがバッテリー寿命を長くすることを要求するとき、プラットフォーム２６に低電力状態に留まる機会をより多く与えるために、保持時間を比較的長い値に設定できる。
【００１７】
ここで図３を参照して、ブレークイベントの発行の協調方法３０の一例を示す。方法３０は、例えば、特定目的集積回路（ＡＳＩＣ）、相補的金属酸化物半導体（ＣＭＯＳ）、又はトランジスタ・トランジスタ・ロジック（ＴＴＬ）などの回路技術を用いた固定機能ハードウェアで、又はランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、プログラマブルＲＯＭ（ＰＲＯＭ）、フラッシュメモリなどメモリの機械又はコンピュータ読み取り可能媒体に記憶された一組のファームウェア及び／又はロジック命令として実行可能ソフトウェアで、又はこれらの任意の組み合わせで実装可能である。処理ブロック３２において、装置、アプリケーション、及びプラットフォームからランタイム情報を収集し、ランタイム情報に基づいて保持時間を決定する。既述の通り、保持時間の決定では、低電力状態ブレークイーブン時間とプログラマブル性能要件、及びＩＯイベントの最大遅延時間とタイマーイベントの遅延可能特性を考慮し得る。
【００１８】
ブロック３４においてブレークイベントを検知すると、ブロック３６において、保持時間が経過したか判断する。経過していなければ、ブロック３８においてブレークイベントを延期する。ブレークイベントの延期は、状況に応じていろいろな方法で実現できる。例えば、ブレークイベントはキューに入れられる。このキューは装置に関連する合体部（coalescing  unit）中のＢＭＵ１８（図２）と、すなわちブレークイベントを発行する装置と一緒に用いられる。実際、ブレークイベントがバス・マスタリング・トランザクション（例えば、ダイレクトメモリアクセス（ＤＭＡ））と関連する場合、そのブレークイベントは、ＰＣＩｅ（Peripheral  Components  Interconnect  Express）ＯＢＦＦ（opportunistic  buffer  flush/fill）信号をデ・アサートして、ソース装置に対して、ＰＣＩｅバスが利用不可であることを通知することにより延期される。
【００１９】
ブロック４０において延期できないブレークイベントが検出されるか、ブロック３６において保持時間が経過したと判断されると、ブロック４２において、延期されたすべてのブレークイベントがプラットフォームにリリースすなわち発行される。図示したブロック４４において、収集したランタイム情報に基づき、次の保持時間をスケジューリングする。既述の通り、保持時間は動的に調整できる。ブロック４６において、プラットフォーム電力管理部に次の保持時間が通知される。
【００２０】
図４は、システム４８を示す。このシステム４８では、ＢＭＵ５０が、アプリケーションタイマー５４と装置５６（５６ａ−５６ｃ）から様々なブレークイベントを受信するプロセッサ／プラットフォーム５２に結合している。プロセッサ／プラットフォーム５２は、ブレークイベントにより、一又は複数の低電力状態を出る（又は、入るのを妨げられる）。図示した例では、合体部（coalescing  units）５８は、例えば、そうしなければ複数のブレークイベントになってしまう複数のパケットを結合して、１つのブレークイベントにすることにより、ブレークイベントの数を減らす。それゆえ、他の装置やアプリケーションも合体プロセス（coalescing  process）による利益はあるが、合体部５８はネットワークコントローラなどの通信装置にとって特に有用である。
【００２１】
合体部５８は、ブート時における初期化フェーズから、オーバーライドポリシー、装置バッファサイズ、装置レイテンシ許容要件などのシステムパラメータを取得でき、あるいはすでに知っている。これらのパラメータは、合体部５８により用いられ、初期装置・アプリケーションベースの保持時間を決定できる。この保持時間は、必要に応じて、ランタイムビヘイビア（runtime  behavior）に基づき後で調節できる。ランタイムにおいて、合体部５８は、ブレークイベント機能を有する各装置をトラッキングして、その装置が所定時間の間、静穏であったか（例えば、αｍｓの間、割り込みを発生していないか）判断する。静穏であった場合、問題の合体部５８は、（例えば、βｍｓの）保持期間に入る。保持期間では、このソースからの割り込みは、ＢＭＵ５０及び／又はプロセッサ／プラットフォーム５２には中継されない。このアプローチは、装置／アプリケーションごとに、及び各装置／アプリケーションごとに異なるパラメータで、実施される。また、高性能／ベンチマーキングモードなどのストラテジを用いて、合体部５８をバイパスすることもできる。
【００２２】
合体部５８は、装置５６及びアプリケーションタイマー５４に実装できるが、ＢＭＵ５０に配置すると、装置メーカはブレークイベントのアライメント（alignment）をサポートする必要が無くなり、よりスケーラブルになる。合体部５８をＢＭＵ５０に実装するには、バッファがあふれることを防止するため、保持タイマーβの上限を、装置の内部バッファサイズに適合したものにする必要がある。また、余裕があるのに時間切れになったり、最高システム性能が下がることを防止するため、静穏タイマーαは十分大きな値に設定できる。
【００２３】
合体タイマーを適合するため、異なる多くのストラテジを用いることができる。例えば、「静的ポリシー」では、合体ビヘイビアをユーザ設定（又はＯＳプロファイルベースの）システム性能にリンクさせる。よって、ユーザが高い性能プロファイルを好めば、β＝０にして、合体をバイパスする。性能／パワープロファイルをバランスさせるため、ティピカル値としてβ＝５ｍｓを選択できる。低電力モードの場合、省電力を最大化して、ティピカル値としてβ＝１０ｍｓを選択できる。あるいは、あるカウント期間にわたり観測した平均ブレークイベントカウントに基づき、βを閉ループで制御する「動的ポリシー」を用いても良い。それゆえ、このアプローチは、合体をできるだけ押しつけがましくなくし、ブレークイベントのビヘイビアが（平均すれば）大きく変わらないようにする。一般的には小さいβ値から初めて、個々の装置からのブレークイベントの数を、比較的長い（数秒のオーダー）期間にわたり観測し、イベントの平均数が大きく変わるまでβを大きくする。変化に応じて、βをリセットして一から適合させるか、又は繰り返し減らす。
【００２４】
ここで図５を参照して、システム６０を示す。システム６０は、（例えば、パーソナルデジタルアシスタント（ＰＤＡ）やラップトップなどの）計算機能を有する、（例えば、無線スマートフォンなどの）通信機能を有する、画像取得機能を有する、メディア再生機能を有する、又は（例えば、モバイルインターネットデバイス（ＭＩＤ）などの）上記機能の任意の組合せを有するモバイルプラットフォームの一部である。図示した例では、システム６０は、プロセッサ６２、統合メモリコントローラ（ＩＭＣ）７４、ＩＯモジュール６４、システムメモリ６６、ネットワークコントローラ（例えば、ネットワークインタフェースカード）６８、オーディオＩＯデバイス７２、ソリッドステートディスク（ＳＳＤ）７０、その他の一又は複数のコントローラ８０を含む。プロセッサ６２は、一又は複数のプロセッサコア７６を有するコア領域を含み、電力管理ユニット（ＰＭＵ）７８を用いて、既述の通り、コア７６その他のシステムコンポーネントを、性能及び／又は電力管理の観点に基づき、一又は複数のアクティブ及び／又はアイドル状態にする。
【００２５】
図示したＩＯモジュール６４は、チップセットのうちサウスブリッジやサウスコンプレックスと呼ばれることもあるが、ホストデバイスとして機能し、ネットワークコントローラ６８と通信する。ネットワークコントローラ６８は、幅広い目的のため、オフプラットフォームの通信機能を提供する。この目的には、携帯電話（例えば、Ｗ−ＣＤＭＡ（ＵＭＴＳ）、ＣＤＭＡ２０００（ＩＳ−８５６／ＩＳ−２０００）など）、ＷｉＦｉ（例えば、ＩＥＥＥ８０２．１１、１９９９版、ＬＡＮ／ＭＡＮ無線ＬＡＮ）、ブルートゥース（例えば、ＩＥＥＥ８０２．１５．１−２００５、無線パーソナルエリアネットワーク）、ＷｉＭａｘ（例えば、ＩＥＥＥ８０２．１６−２００４、ＬＡＮ／ＭＡＮブロードバンド無線ＬＡＮ）、グローバルポジショニングシステム（ＧＰＳ）、スプレッドスペクトラム（例えば、９００ＭＨｚ）、及びその他のラジオ周波数（ＲＦ）テレフォニー目的を含む。また、ＩＯモジュール６４は、かかる機能をサポートする一又は複数の無線ハードウェア回路ブロックも含む。
【００２６】
ＳＳＤ７０は、一又は複数のＮＡＮＤチップを含み、大容量データ記憶及び／又は大量の並列処理を提供する。シリアルＡＴＡバス（ＳＡＴＡ、例えば、SATA  Rev.  ３.０  Specification,  May  ２７,  ２００９,  SATA  International  Organization/SATA-IO）又はＰＣＩエクスプレスグラフィックスバス（ＰＥＧ、例えば、Peripheral  Components  Interconnect（PCI）  Express  ×１６  Graphics  １５０W-ATX  Specification  １.０,  PCI  Special  Interest  Group）などの標準的バスでＩＯモジュール６４に接続された、別の特定目的集積回路（ＡＳＩＣ）コントローラとして実装されたＮＡＮＤコントローラを含むソリューションもある。また、ＵＳＢ（ユニバーサルシリアルバス、例えば、USB  Specification  ２.０,  USB  Implementers  Forum）フラッシュ記憶デバイスとしてＳＳＤ７０を用いることもできる。
【００２７】
図示したＩＯモジュール６４はＢＭＵ８２を含む。ＢＭＵ８２は、ネットワークコントローラ６８、オーディオＩＯデバイス７２、ＳＳＤ７０、プロセッサ６２で実行中のアクティブアプリケーションなどの複数の異なるソースからのブレークイベントを検出し、システム６０に関連するランタイム情報に基づいてプロセッサ６２へのブレークイベントの発行を調整するように構成されている。一例では、ブレークイベントの発行の調整は、ランタイム情報に基づく保持時間の決定と、その保持時間に基づくブレークイベントの少なくとも一の延期とを含む。例えば、システム６０は、ＶｏＩＰ（voice  over  Internet  Protocol）アプリケーションを実行でき、そのアプリケーションでは、ネットワークコントローラ６８とオーディオＩＯデバイス７２が、他のデバイスにより発生されたＩＯイベントにかかわらず、アクティブにＩＯイベントを発生する。ＢＭＵ８２を用いてネットワークコントローラ６８とオーディオＩＯデバイス７２からのブレークイベントを調整することにより、図示したＩＯモジュール６４は、システム６０のコンポーネントを、より長い時間、より深い低電力状態に入らせ、システム６０により実現される省電力を大幅に改善する。
【００２８】
よって、上記の手法により、複数のＩＯ装置とアプリケーションのアクティビティを調整してアライメントするように計算システムアーキテクチャとインターフェースを画定する全体的アプローチが提供される。結果として、プラットフォームの省電力を最適化するためプラットフォームを最大限アイドル状態にできる。また、かかる調整とアライメントにより、プラットフォームが、理想的な「負荷に比例した」消費電力により近づくことができ、性能がロバストとなる。
【００２９】
本発明の実施形態は、すべてのタイプの半導体集積回路（ＩＣ）チップで利用できる。これらのＩＣチップの例としては、プロセッサ、コントローラ、チップセットコンポーネント、プログラマブルロジックアレイ（ＰＬＡ）、メモリチップ、ネットワークチップ、システムオンチップ（ＳｏＣ）、ＳＳＤ／ＮＡＮＤコントローラＡＳＩＣなどがあるが、これらに限定されない。また、いくつかの図面では、線で信号導線を表した。いくつかの線は太く、より多くの構成信号経路を示し、複数のラベルを有し、複数の構成信号経路を示し、及び／又は１つ以上の端に矢印を有し、主な情報フロー方向を示す。しかし、これは、限定と解釈してはならない。むしろ、かかる付加的詳細は、１つ以上の実施形態と共に、回路の理解を促進するために用いられている。表示したどの信号線も、追加的情報を有していようがいまいが、複数の方向に進む１つ以上の信号を有していてもよく、例えば、差動ペアと実装されたデジタル又はアナログライン、光ファイバライン、及び／又は単一終端ラインなどの所望のタイプの信号方式で実装してもよい。
【００３０】
例示したサイズ／モデル／値／範囲は所与のものであってもよいが、本発明の実施形態はこれに限定されない。（フォトリソグラフィなどの）生産技術が時間とともに成熟してくるので、小さいサイズのデバイスを生産できると期待される。また、ＩＣチップその他のコンポーネントへの周知のパワー／グラウンド接続は、図示と説明とを簡単にするため、及び本発明の実施形態の態様を分かりにくくしないように、図示したものもあれば図示していないものもある。さらに、構成をブロック図の形式で示したが、それは本発明の実施形態を分かりにくくしないようにするため、またかかるブロック図構成の実装に関する具体的事項は実施形態を実装するプラットフォームに大きく依存すること、すなわちかかる具体的事項は当業者の管轄事項であることを考慮したものである。本発明の実施形態を説明するために、（例えば、回路などの）具体的な詳細事項を記載した場合、当業者には言うまでもなく、こうした具体的な詳細事項が無くても、又はそれを変更しても、本発明の実施形態を実施できる。よって、上記の説明は、限定ではなく例示と考えるべきである。
【００３１】
「結合した」との用語は、ここでは問題となるコンポーネント間の、直接的又は間接的な任意のタイプの関係を言い、電気的結合、機械的結合、流体的結合、光学的結合、光磁気的結合、電気機械的結合その他の結合に当てはまる。また、「第１の」、「第２の」等の用語は、ここでは、説明を容易にするためにだけに使われており、特に断らなければ時間的な意味は無い。
【００３２】
当業者には言うまでもなく、本発明の実施形態の幅広い手法は、いろいろな形式で実施できる。それゆえ、本発明の実施形態をその具体的な例に関連して説明したが、当業者には図面、明細書、及び特許請求の範囲を研究すればその他の修正が明らかであるから、本発明の実施形態の範囲は具体例に限定されない。
【図１】
0005628431.tif 000002
【図２】
0005628431.tif 000003
【図３】
0005628431.tif 000004
【図４】
0005628431.tif 000005
【図５】
0005628431.tif 000006