JP4433782B2 - 情報処理装置及びオペレーティングシステム - Google Patents

Description

情報処理装置及び前記情報処理装置に搭載のソフトウェアに関するものである。

図１８は、特許文献１の図５に記載の従来の電力制御装置及びその電力制御方法並びにそのプログラムを示す構成図である。前記電力制御装置は、バッテリ駆動且つプロセッサ搭載の携帯機器、例えば携帯電話、携帯型オーディオ、携帯型ビデオカメラ、ノートブックパーソナルコンピュータ、PDA（Personal Digital Assistants）の消費電力の最適化を実現する技術である。

図１８のように従来の電力制御装置には、ソフトウェア（２５）で動作する中央処理装置CPU（以下、プロセッサという）（２１）及び電力制御回路（２２）が搭載されている。電力制御回路（２２）は、電源電圧/閾値電圧制御回路、クロック周波数発生器、タイマで構成されている。前記電源電圧/閾値電圧制御回路（以下、可変DC/DC変換回路という）は、プロセッサ（２１）に対して印加する電源電圧または閾値電圧を制御する機能を持っている。

前記クロック周波数発生器（以下、CPG：Clock Pulse Generatorという）は、プロセッサ（２１）に提供するクロックパルスを発生し、前記クロックパルスの時間幅、つまり動作周波数を制御する機能を持っている。タイマは、ソフトウェア（２５）に対して一定時間間隔のカウント数、つまり時刻情報を提供する。前記タイマは、前記CPGからプロセッサ（２１）に提供の前記クロックパルスとは別に、タイマ用クロックパルスを前記CPGから受け取り、予めソフトウェア（２５）で設定の前記一定時間間隔でカウント動作を行っている。

ソフトウェア（２５）は、オペレーティングシステム（以下、RTOSという）（２３）と単数ないし複数のタスク（２４）等で構成されている。RTOS（２３）は、単数ないし複数のタスク（２４）の中からタスク起動時刻の順番に、またはタスク優先度の高い順番に、実行可能な実行準備状態のタスク（２４）を保持する。更にRTOS(２３)は、最初に起動されるタスク（２４）の前記タスク起動時刻を現在実行中のタスク（２４）に提供する機能を有する。単数ないし複数のタスク（２４）は、例えばアプリケーションプログラムやミドルウェアプログラム等に相当するユーザープログラムの他に、電力制御プログラムも合わせて構成されている。

前記電力制御プログラムは、実行中のタスク（２４）に対してプロセッサ（２１）に割り付けた起動時刻から現時刻までの実行時間を積算し、その積算実行時間と、予め設定した前記アプリケーションプログラムまたは前記ミドルウェアプログラムのアプリケーションスライスの最悪実行時間（以下、WCET: Worst Case Execution Timeという）から、実行中のタスク（２４）における時間余裕を算出する機能を有する。アプリケーションスライスは、タスクをＮ個のスライス１，２，３…Ｎに分割することをいい、スライス１，２，３，．．．，Ｎの各々のＷＣＥＴと、各スライスからスライスＮまでのＷＣＥＴは、解析や測定を通じて取得される。時間余裕があれば図１８の実行中のタスク（２４）からRTOS（２３）に対し、所望の電源電圧、動作周波数を設定する為のシステムコールSCを発行している。そして、RTOS（２３）の内部処理を行った後、ソフトウェア（２５）でプロセッサ（２１）から前記可変DC/DC変換回路に対して図２のコマンドCを送信する。前記コマンドCを受け取った前記可変DC/DC回路は、ソフトウェア（２５）所望の電源電圧、動作周波数を設定し、制御信号CSを前記DC/DC変換回路からプロセッサ（２１）に送信する。前記制御信号CSを受け取ったプロセッサ（２１）は、所望の前記電源電圧及び前記動作周波数で駆動される。

次に、RTOS（２３）上でのタスク（２４）の動作状態について言及する。図１９は、RTOSのタスク状態遷移図である。タスク（２４）の状態には実行状態（Run状態）（３１）、待機状態（Wait状態）（３２）、実行準備状態（Ready状態）（３３）、初期状態（３４）がある。初期状態（３４）は、あるタスク（２４）生成以前の状態であり、既に生成のタスク（２４a）からRTOS（２３）提供のタスク生成用システムコールを発行して初めて、タスク（２４c）が生成されて実行準備状態（３３）へ遷移する。実行状態（３１）はあるタスク（２４）がプロセッサ（２１）を占有した処理実行中の状態である。待機状態（３２）は、所定の処理を終えたタスク（２４d）がRTOS（２３）提供のイベント受信待ち用システムコールを発行して実行状態（３１）から遷移し、他のタスク（２４）にプロセッサ（２１）の占有を譲ってイベント待ちになる状態である。待機状態（３２）のタスク（２４d）は自分への起動用イベントを受信すると実行準備状態（３３）に遷移する。

実行準備状態（３３）は、実行可能のタスク（２４a）、タスク（２４b）、タスク（２４c）がタスク優先度の高い順番にプロセッサ（２１）を占有する機会を伺っている状態である。そして、実行準備状態（３３）のタスク（２４a）、タスク（２４b）、（２４c）の内、その時点で最も前記タスク優先度が高いタスク（２４a）が実行状態（３１）へディスパッチ（３５）される。また、例えば前記起動用イベントの受信によって待機状態（３２）から実行準備状態（３３）に遷移したタスク（２４d）の前記タスク優先度が、現在実行中のタスク（２４a）の前記タスク優先度よりも優先順位が高い場合、現在実行中のタスク（２４a）は、前記遷移したタスク（２４d）にCPUの占有を明け渡し、実行準備状態（３３）にプリエンプト（３６）され、同時に前記タスク優先度順に実行状態（３１）になる機会を伺う。

特開２００３−１４０７８７号公報

本願発明者等は本願に先立って、携帯電話、PDA、携帯ディジタルカメラ、携帯ディジタルビデオプレイヤー、携帯ディジタルビデオカメラ、携帯ディジタルオーディオレコーダー及びプレイヤー等に代表される、バッテリ駆動の情報処理装置を対象に、特許文献1の前記電力制御装置の従来技術について検討した。

図２０は、本願発明者等が特許文献１に記載される電力制御装置を使用するに当たって作成した電力制御方法の概念図である。なお、図２０は、特許文献１には記載されていない。縦軸は、アプリケーションプログラムにおけるアプリケーションスライスの処理経過、横軸は、アプリケーションプログラムの処理経過時刻を表している。ここで、アプリケーションスライスの数はK個としている。出力時間（１１）は、前記アプリケーションプログラムを仕様上完了させなければならない、または、前記アプリケーションプログラムの処理結果を出していなければならない、予め分かっている時刻である。

特許文献１での電力制御は、電源電圧と動作周波数を制御するという技術である。従って、電力の最適化、つまり低消費電力化を出来るだけ実現するには、電源電圧を下げると同時に動作周波数も下げる必要がある。前記動作周波数を下げるということはすなわち、ゆっくりとアプリケーションプログラムの処理を行うことに相当する。よりよく低消費電力化を行うには、出力時間（１１）以内のギリギリの時刻まで低動作周波数でゆっくりと前記アプリケーションプログラムの処理を行いたい。そこで、本願発明者等は、タスク起動時刻（１２）から前記アプリケーションプログラムの処理を始めて出力時間（１１）に間に合うように、線形計画法に基づいて各アプリケーションスライスに同時間間隔のサブ出力時間（１３）を割り当てることとした。また、各アプリケーションスライスに対し、タスク起動時刻（１２）から各サブ出力時間の整数倍の時間間隔であるWCET（１４）を予め割り当てることとした。例えば、前記線形計画法に基づいて設定したｋ番目のアプリケーションスライスのWCET（１４c）は、サブ出力時間（１３）にｋを掛けた積算見積時間に相当する。

そして、電力制御チェックポイント（６）では、タスク起動時刻（１２）からのプロセッサ（２１）の積算実行時間（１５）と各アプリケーションスライス（４）のWCET(１４)を比較し、逐次、前記電源電圧及び前記動作周波数の制御を行う。例えば、高電源電圧及び高動作周波数と低電源電圧及び低動作周波数という２つの電力の組合せで制御が可能な前記電力制御装置を用いるとする。タスク起動時刻（１２）からアプリケーションスライス（４c）のｋ番目の処理終了時点（１６）の積算実行時間（１５）をアプリケーションスライス（４d）の（ｋ＋１）番目の処理のWCET（１４d）から引いた時間差が、アプリケーションスライス（４d）の（ｋ＋１）番目の処理のWCET（１４d）とアプリケーションスライス（４c）のｋ番目の処理のWCET（１４c）の時間差、つまりｋ番目から（ｋ＋１）番目の間のサブ出力時間（１３）に、前記低動作周波数に対する前記高動作周波数の倍率を掛けた時間値よりも大きい場合、ｋ番目の処理終了時点（１６）で電力を下げる。前記電源電圧及び前期動作周波数を下げても、（ｋ＋１）番目の電力制御チェックポイント（６）時のWCET（１４d）の内に収まる予測出来るので、出力時間（１１）厳守が満たせる。反対に小さい場合は前記電力を上げないと、つまり前記電源電圧及び前記動作周波数を上げないと、出力時間（１１）厳守は満たせない。

上述のような検討をした結果、前記情報処理装置に図１８の前記電力制御装置を適用した場合、消費電力の最適化（省エネルギー化）効果について、２つの課題が残されていることがわかった。

第１の課題は、実行中のタスク（２４a）に対して、割込処理が発生した場合、起動される高優先度のタスク（２４d）で費やした実行時間分、割り込まれた実行準備状態（３３）のタスク（２４a）の処理が遅延する為に出力時間（１１）までの絶対時間に対する余裕時間にズレが生じ、電力制御のタイミングを逸してしまうという事象である。以下、この事象を図２１で説明する。

図２１は、割り込まれたタスクの処理遅延を説明する図である。例えばｋ番目のアプリケーションスライス（４c）を処理している途中で高優先度のタスク（２４d）に割り込まれた場合、割り込まれたタスク（２４a）は実行準備状態（３３）にプリエンプト（３６）されて処理停止状態になる。割り込んだ高優先度のタスク（２４b）の処理が終了すると割り込まれたタスク（２４a）は実行状態（３１）にディスパッチ（３５）される。

しかし、割り込まれたタスク（２４a）が前記処理停止状態でも絶対時間は経過している為、予め割り当てていた（k+1）番目のWCET（１４d）における絶対時間が割り込んだタスク（２４d）の実行時間（３７）分、遅延する。

従って（k+1）番目での処理終了時点（１６）は実行時間（３７）を含んだ結果となり、絶対時間上、誤ったWCET（１４）での電力制御チェックポイント（６）で電力制御を行ってしまう。また出力時間（１１）も同様、実行時間（３７）分、遅延する。従って省出力時間（１１）も保証出来ず、メディア品質を劣化させてしまうこともわかった。

第２の課題は、RTOS（２３）の実行準備状態（３３）に実行可能のタスク（２４）が多く存在している場合、実行可能のタスク（２４）にはJitter（以下、ジッタという）が生じてしまう為に処理開始時刻及びWCETが遅延してしまい、時間余裕が無くなり、出力時間が守れなくなるという事象である。以下、この事象を図２２で説明する。

図２２は、実行状態に遷移した直後のタスクの起動時刻の遅延を説明する図である。高優先度のタスク（２４d）によって割り込まれて実行準備状態（３３）にプリエンプト（３６）されたタスク（２４a）、タスク（２４a）によって生成した実行準備状態（３３）のタスク（２４c）は、直ぐにでもプロセッサ（２１）を占有するべく実行準備状態（３３）で待たされている。しかしタスク（２４a）、タスク（２４c）等のようなタスク優先度が低いタスク（２４）ほど、プロセッサ（２１）を占有するまでの実行準備状態での待機時間（３８）は大きい。本来はタスク（２４a）、タスク（２４c）等の各々で前記起動用イベントを受信した時刻が起動時刻（１２）であるのだが、実際の起動時刻は待機時間（３８）分遅延した遅延起動時刻（３９）から処理を開始し、遅延起動時刻（３９）から出力時間（１１）までしか処理時間がなくなるという課題が残っている。更に、WCET（１４）は各アプリケーション/ミドルウェアプログラムが管理しているので、アプリケーション/ミドルウェアの開始が遅延すれば待機時間（３８）分遅延してずれた遅延WCET（４０）となり、最終の遅延WCET（４０）も出力時間（１１）を越すという課題が残る。従って、前記積算見積時間に不確定要素が含み、省エネルギー効果が鈍くさせてしまうこともわかった。

本願において開示される主な発明の要点は以下のとおりである。
プロセッサと、前記プロセッサに内蔵され又は前記プロセッサの外部に設けられるハードウェアタイマーと、前記プロセッサ及びハードウェアタイマーにクロックを供給するクロックパルス発生器とを有し、前記ハードウェアタイマーは、でアプリケーションタスクの開始から現時点までの処理時間とを計測し、前記アプリケーションタスクは、複数の処理単位に分割され、前記プロセッサは、前記アプリケーションタスクの前記複数の処理単位のうち所定の処理単位を処理するのにかかった時間と前記処理単位の最悪実行時間とを比較し、前記比較結果に基づいて、前記クロックパルス発生器から出力される動作周波数を変更し、前記プロセッサは、前記アプリケーションタスクの処理中の割込みによって起動した他のアプリケーションタスクが前記プロセッサの計算資源を占有した際に、実行準備状態のアプリケーションタスク数をカウントし、前記実行すべき他のアプリケーションタスク以外に前記実行準備状態のアプリケーションタスクが存在する場合は、前記実行準備状態監視タスクにより、前記動作周波数と前記電源電圧を上げ、存在しない場合は、前記実行準備状態監視タスクにより前記動作周波数と前記電源電圧を下げるように構成する。

更に望ましくは、プロセッサは、前記アプリケーションタスクを実行する際に、前記アプリケーションタスク以外に前記実行準備状態の他のアプリケーションタスクが存在すると知らされた場合、前記アプリケーションタスクは、前記最悪実行時間よりも時刻を早めた仮想最悪実行時間と前記所定の処理単位を処理するにかかった時間とを比較する。

更に望ましくは、前記プロセッサは、前記最悪実行時間又は前記仮想最悪実行時間と前記所定の処理単位を処理するのにかかった時間を比較した結果、前記最悪実行時間又は前記仮想最悪実行時間と前記所定の処理単位を処理するのにかかった時間の差が所定時間より大きい場合に、現在実行処理中の前記アプリケーションタスクを実行するための前記動作周波数と前記電源電圧を下げ、前記時間の差が所定時間より小さい場合は、前記動作周波数と前記電源電圧を上げる。

別の表現をすれば、プロセッサと、タイマと、クロック発生回路と、動作電圧供給回路とを具備し、前記タイマは、前記プロセッサにより実行されるアプリケーションタスクの実行時間を計測し、前記アプリケーションタスクは、複数の処理単位に分割され、情報処理装置は、実行準備状態にあるアプリケーションタスクの数を管理し、前記情報処理装置は、前記第１のアプリケーションタスクを前記プロセッサを用いて実行する際に、実行準備状態にあるアプリケーションタスクが所定数より小さい場合は、前記複数の処理単位ごとに、対応する処理単位の処理が終了すべき最悪実行時間を管理し、前記第１のアプリケーションタスクを前記プロセッサを用いて実行する際に、実行準備状態にあるアプリケーションタスクの数が所定数より大きい場合は、前記複数の処理単位ごとに、対応する前記最悪実行時間より短い仮想最悪実行時間を管理する。

本願発明を実施することにより、情報処理装置の低消費電力化を向上させること達成することが出来る。

以下に本願発明を実現する実施例を説明する。
図１は、本発明の代表例を説明する図で、本発明のハードウェア構成の実施例を説明する図である。ここではバッテリ駆動で且つプロセッサ内蔵の情報処理装置を実施例として説明する。

本明細書では、PLL（Phase Locked Loop）回路を使用したクロックパルス発生器（５１）（以下、CPGという）及びタイマTMU（５２）内蔵のプロセッサCPU（２１）で説明する。CPG（５１）ないしTMU（５２）がプロセッサの外付け実装でも本願発明は実施可能である。CPG（５１）は、プロセッサ（２１）が同期動作をする為のクロックパルスをプロセッサ（２１）に供給する。プロセッサ（２１）は、CPG（５１）の設定で所望の動作周波数で動作を可能とする機能を具備する。また、プロセッサ（２１）は、可変DC/DC 変換回路VC（２２）に対して所望の電源電圧の供給するように制御信号（５７）を送信する機能を具備する。更に、プロセッサ（２１）は、バス（５３）でメモリ（５４）と入力器及び出力器（以下、I/Oという）（５５）と接続されている。プロセッサ（２１）は、メモリ（５４）に格納のソフトウェアの命令手順で動作する。前記ソフトウェアは、RTOS（２３）、実行準備状態監視プログラムモジュール（５６）、電力/エネルギー制御プログラムモジュール（５７）、アプリケーション/ミドルウェアプログラムモジュール（５８）等で構成する。

可変DC/DC変換回路（２２）は、バッテリBAT（５９）の電池電圧をプロセッサ（２１）、メモリ（５４）、I/O（５５）等の各デバイスに要する電源電圧に変換し、電源系統（６０）を通して電力を前記各デバイスに供給する。また、可変DC/DC変換回路（２２）は、プロセッサ（２１）のポート（６２）からの制御信号（６１）を受信する機能、及びプロセッサ（２１）に対してプロセッサ（２１）所望の電源電圧に可変制御する機能を具備する。I/O（５５）は、例えば、静止画及び動画像を表示するディスプレイや撮像するカメラ、音を入力するマイクや出力するスピーカー等に相当する。

図２は、本発明を実現する為のソフトウェア構成の実施例を説明する図である。RTOS（２３）は、プロセッサCPU（２１）の演算器等の計算資源及びメモリ（５４）のメモリ資源を管理する。つまり、プロセッサ（２１）に対する外部イベントやTMU（５２）からのタイマイベントによって起動するスレッド又はプロセス等と呼ばれる処理単位であるタスク（６４）を割り当てて、且つ、タスク（６４）が所望するメモリ容量を割り当てる。更に、各タスク（６４）の間で同期、非同期動作を可能とするメッセージ通信機能を各タスク（６４）に提供する。ここで、同期動作とは、一つのタスクが他のタスクに対して情報を伝達し、プロセッサにおける処理を他のタスクに受け渡す動作を言い、非同期動作とは、一つのタスクが他のタスクに対して情報を伝達するが、プロセッサにおける処理を占有し、他のタスクに処理を受け渡さない動作を言う。

実行準備状態監視プログラムモジュール（５６）は、RTOS（２３）において現時点で実行準備状態（３３）になっているタスク（６４）の数を把握する。実行準備状態（３３）のタスク（６４）の数、またはその存在の有無をシステムコール等で教示可能なRTOS（２３）を搭載するならば、実行準備状態監視プログラムモジュール（５６）の代用が可能であるが、本明細書では実行準備状態監視プログラムモジュール（５６）を用いて本願発明を説明する。

電力/エネルギー制御プログラムモジュール（５７）は、プロセッサ（２１）に印加する所望の電源電圧に設定するように、ポート（６２）から制御信号（６１）を可変DC/DC変換回路(２２)へ送信する。更に、同時にCPG（５１）に対し、所望の動作周波数に設定するよう命令する。例えば、電力/エネルギー制御プログラムモジュール（５７）が高電力モード、低電力モードという２つモードで電力制御を実施する場合、高電力モードでは可変DC/DC変換回路（２２）に高電源電圧を設定させる制御信号（６１）を送信し、CPG（５１）に高動作周波数を設定させる命令を発行する。反対に低電力モードでは可変DC/DC変換回路（２２）に低電源電圧を設定させる制御信号（６１）を送信し、CPG（５１）に低動作周波数を設定させる命令を発行する。なお、CPG（５１）の周波数を選択するためのレジスタを有する場合は、命令でなくレジスタに書き込む構成としても良い。

アプリケーション/ミドルウェアプログラムモジュール（５８）は、実際にプロセッサ（２１）で処理させたい所望のプログラムであり、本願発明における電力制御の制御対象である。

RTOS（２３）、実行準備状態監視プログラムモジュール（５６）、電力/エネルギー制御プログラムモジュール（５７）、及びアプリケーション/ミドルウェアプログラムモジュール（５８）にはそれぞれ、各々の機能を呼び出す為のソフトウェアインターフェース、つまりプログラム関数群を設ける。

本明細書では、RTOS（２３）のプログラム関数群をシステムコール（System Call）（６５）、実行準備状態監視プログラムモジュール（５６）のプログラム関数群をレディ・ウォチャー・インターフェース（Ready Watcher Interface)（以下、RWIという）（６６）、電力/エネルギー制御プログラムモジュール（５７）のプログラム関数群をパワー/エネルギー・コントロール・インターフェース（Power /Energy Control Interface）（以下、PECIという）（６７）、及びアプリケーション/ミドルウェアプログラムモジュール（５８）のプログラム関数群をアプリケーション・インターフェース（Application Interface）（以下、APIという）（６８）と呼ぶ。RTOS（２３）及び電力/エネルギー制御プログラムモジュール（５７）は、プロセッサ（２１）の状態レジスタ、制御レジスタ及び内部メモリ等を直接操作する。実行準備状態監視プログラムモジュール（５６）は、システムコール（６５）を通してRTOS（２３）の機能を用いる。RWI（６６）は、タスク（６４）間で同期、非同期通信を行わせる為、メッセージ受信待ち処理、及びメッセージ送信処理を提供する。特にメッセージ受信待ち処理は、タスク（６４）を待機状態（３２）に遷移させる機能を提供する。

アプリケーション/ミドルウェアプログラムモジュール（５８）は、システムコール（６５）とPECI（６７）を通して、RTOS（２３）及び電力/エネルギー制御プログラムモジュール（５７）の機能を用いる。電力/エネルギー制御プログラムモジュール（５７）は、アプリケーション/ミドルウェアプログラムのアプリケーションスライス直後の電力制御チェックポイント（６）で用いる。タスク（６４）は、システムコール（６５）、RWI（６６）、PECI（６７）、API（６８）を呼び出して所望の処理を実施する。

本明細書では本願発明のソフトウェアの動作説明を分かりやすくする為、待機状態監視タスク（６４a）、出力時間管理タスク（６４b）、画像表示タスク（６４c）、PCM出力タスク（６４d）、ビデオ処理タスク（６４e）、オーディオ処理タスク(６４f)及びスリープタスク（６４g）という７つのタスクで構成したAVプレイヤーを想定して説明する。実行準備状態監視タスク（６４a)は、実行準備状態（３３）のタスクの数を監視するためのタスクであり、システムの忙しさ（実行開始命令を発行されて直ぐにでも処理しなければならないタスクの数）を判定するためのタスクである。出力時間管理タスク（６４b)は、画像表示タスク（６４ｃ）やPCM出力タスク（６４d）を用いてディスプレイやスピーカーから画像表示、音声出力をしなければならない出力時間（デッドライン（Deadline))を管理し、その出力時間をRTOS（２３）に把握させ、出力時間が来た際にRTOSから画像表示タスク（６４ｃ）またはPCM出力タスク（６４d）に対して起動イベントを発信させるためのタスクである。画像表示タスク（６４c)は、ディスプレイ等に画像表示するためのタスクであり、PCM出力タスク（６４ｄ）は、音声をスピーカー等から出力するためのタスクである。更に、ビデオ処理タスク（６４e)は、例えばMPEG等の画像に関する圧縮データを解凍するためのタスクであり、オーディオ処理タスク（６４ｆ）は、例えばMP3等の音声に関する圧縮データを解凍するためのタスクである。スリープタスク（６４g)は、システム全体が実行準備状態になった際にスリープ状態に入るためのタスクである。

タスク優先度は、実行準備状態監視タスク（６４a）、出力時間管理タスク（６４b）、PCM出力タスク（６４d）、画像表示タスク（６４c）、オーディオ処理タスク（６４f）、ビデオ処理タスク（６４e）、スリープタスク（６４g）の順に高優先度を割り付ける。

また各タスク（６４）間の同期、非同期通信は、メッセージ（７１）を用いる。実行準備状態監視プログラムモジュール（５６）は、予め定義したメモリフォーマットに従い、RTOS（２３）使用のメモリ（５４）領域からメッセージ（７１）用メモリブロックを各タスク（６４）に提供する。

図３は、メッセージフォーマットを説明する図である。メッセージフォーマットのメッセージ内容は、受信タスクのIDに相当する送信先宛先TO-ID（７２）、送信タスクのIDに相当する送信元宛先FR-ID（７３）、送信内容（７４）で構成する。各タスク（６４）は所望の処理を行う為、前記メッセージフォーマットに従って前記メッセージ内容をメッセージ（７１）に相当する前記メモリブロックに書き込む。そして、各タスク（６４）はメッセージ（７１）を送受信しながら所望の処理を行う。

次に、本願発明であるマルチタスク処理に対応した電力制御方法について説明する。図４は本発明の概念図である。ここでは、簡単のため、高電力モードと低電力モードの２つがあるものとして説明する。まず、仮想出力時間（４１）を設定し、仮想最悪出力時間(以下、仮想WCET)(４２)を設定する。仮想出力時間（４１）は、出力時間（１１）より短くなるように設定する。ここでは、仮想出力時間（４１）を出力時間（１１）の半分の時刻として予め設定し、前記線形計画法により、仮想WCET（４２）を設ける。仮想WCETは、同じアプリケーションスライス（４）に対してWCET（１４）の半分の時刻、仮想サブ出力時間（４３）もサブ出力時間（１３）の半分の時間となる。

RTOS（２３）または実行準備状態監視タスク（６４e）は、実行準備状態（３３）にあるタスク（２４）の数をカウントする。RTOS（２３）または最高タスク優先度の実行準備状態監視タスク（６４e）が実行準備状態のタスク（２４）を監視した結果、実行準備状態（３３）のタスク（２４）がスリープタスク（６４g）以外に全く無い場合は、低電源電圧、低動作周波数とする。これにより、情報処理装置の低電力化を測ることが可能となる。また、スリープ状態に入ることが可能な場合は、スリープタスク（６４g）を実行し、スリープ状態に遷移する。

逆に、実行準備状態（３３）のタスク（２４）がスリープタスク（６４g）以外に１つ存在する場合は、消費電力を低減するために低電力モードとし、タスクを実行する。実行準備状態（３３）にあるタスクが２つ以上存在する場合は、実行中のタスクを早く終了し、実行準備状態（３３）にあるタスクに処理を早く受け渡すために高電力モードに設定する。

実行中のタスク（２４）は、各電力制御チェックポイント（６）で先ずRTOS（２３）または実行準備状態監視タスク（２４e）に問い合わせ、現時点で実行準備状態（３３）のタスク（２４）が存在するかどうかを判別する。判別した結果、実行準備状態（３３）のタスク（２４）が存在する場合は仮想WCET（４２）と比較して時間に間に合っているか、存在しない場合はWECT（１４）と比較して時間に間に合っているかで電力の制御を実施する。即ち、時間に間に合っていない場合は高電力モードに遷移し、時間に間に合っている場合は低電力モードに遷移する。処理を早く終了させ、実行準備状態（３３）にあるタスク（２４）に処理を受け渡すためである。このように実行準備状態（３３）のタスクがある場合に仮想WCETと比較することにより、早く実行中のタスクを終了することが出来、実行準備状態のタスクにＣＰＵを受け渡すことが可能になる。

なお、本実施例では、WCET及び仮想WCETを出力時間に合わせて定めたが、これに制限されないことは当然である。例えば、現実の出力時間より早い時間にあわせてWCET及び仮想WCETを定めても良い。このように構成することにより、現実の出力時間までのマージンを取ることになり、品質保持の信頼性を向上させることが可能となる。

ここで、図５のアプリケーションスライスについて説明する。タスク（２４）は、アプリケーションプログラム開始点（１）から初期化処理（２）を経て、アプリケーションプログラム終了点（３）までの処理を実行する。初期化処理（２）は、アプリケーションプログラム、ミドルウェアプログラム、デバイスドライバプログラム等で使用するメモリ領域の確保や初期化、更にはプロセッサ（２１）で使用の電源電圧、動作周波数及び各レジスタの値の設定等、プロセッサ（２１）上でアプリケーションを動かす為に必要な前処理を行っている。

マルチメディア処理を扱うアプリケーションプログラム及びミドルウェアプログラムは同処理を繰り返し行う性質がある。繰り返し行われる前記同処理の単位をアプリケーションスライス（４）と呼ぶ。図５のアプリケーションスライス（４a）から（４e）の中の値はアプリケーションスライス（４）の繰り返し処理数を表しており、前記値はアプリケーション及びミドルウェアプログラムの内部に実装のアプリケーションスライス処理経過管理部（７）に逐次、格納している。

また、繰り返し判別処理（５）ではアプリケーションスライス（４）の前記繰り返し処理数を判別し、全部のアプリケーションスライス処理を終えたらアプリケーションプログラム終了点（３）でアプリケーションが終了する。

図６は、MPEG-4 ビデオ Decoderプログラムのアプリケーションスライスを説明する図である。例えばQCIFと呼ばれる縦１４４画素、横１７６画素の画像フォーマット（８）にMPEG-4ビデオ Decoderの処理を施すと、MPEG-4 ビデオ Decoderプログラムは画像フォーマット（８）をマクロブロック（９）と呼ばれる縦１６画素、横１６画素の画素ブロック毎に画像へ復号化を施す。従って、前記MPEG-4 ビデオ Decoderプログラムのアプリケーションスライス処理は、マクロブロック毎の画像復号化処理に相当し、アプリケーションスライス（４）の繰り返し処理数はQCIFの画像フォーマット（８）中のマクロブロック数と同数の９９回となり、繰り返し判別処理（５）は９９回、アプリケーションスライス処理を行ったかどうかを判別する。

画像フォーマット（８）が縦９６画素、横１４４画素であるSub QCIFの場合はマクロブロック数が４８となるので、アプリケーションスライス数は４８となる。
また、前記MP3 Decoderプログラムの場合、アプリケーションスライス（４）の前記繰り返し処理数はチャネル数に相当する。ステレオ再生ならば前記繰り返し処理数は２回である。言い換えれば、音声音響復号化処理であるMP3 Decoderプログラムの場合は、チャンネル単位のDecode処理を繰り返しがアプリケーションスライス（４）となる。

図７は、実行準備状態監視タスク動作のフローチャートを説明する図である。RTOS（２３）提供のシステムコール（６５）で生成した実行準備状態監視タスク（６４a）は、初期状態（８１）で実行準備状態監視変数部（８２）を０に初期化した後、RWI（６６）からメッセージ受信待ち判別処理（８３）を呼び出す。
メッセージ受信待ち判別処理（８３）は、実行準備状態監視タスク（６４a）に対する任意の起動イベントであるメッセージ（７１a）が届いているかを判別し、届いていたら実行準備状態監視タスク（６４a）所望の処理である実行準備状態把握処理（８４）を行い、届いていなければメッセージ（７１a）が受信されるまで実行準備状態監視タスク（６４a）を待ち状態にする。

図８は、実行準備状態把握処理のフローチャートを説明する図である。実行状態把握処理（８４）は、実行準備状態監視開始点（９１）から処理を開始し、実行準備状態監視タスク（６４a）への送信されたメッセージ（７１a）のメッセージ判別処理（９２）を行う。

メッセージ判別処理（９２）では、受信したメッセージ（７１a）が、実行準備状態遷移用メッセージか、待機状態遷移用メッセージかを判別する。
前記実行準備状態遷移用メッセージは、例えば、図８のメッセージフォーマットのパラメータAの箇所に送信内容（７４a）に実行準備状態への遷移を表す１が書き込まれ、反対に前記待機状態遷移用メッセージは、待機状態への遷移を表す０が書き込まれたものと予め決めておく。

従って、メッセージ判別処理（９２）は、受信したメッセージ（７１a）のパラメータAの送信内容（７４a）が１か０かを判別する。もし、１ならば、実行準備状態加算処理（９３）を行い、０ならば実行準備状態減算処理（９４）を行う。実行準備状態加算処理（９３）は、実行準備状態監視プログラムモジュール（５６）内の実行準備状態監視変数部（８２）に１を加算し、受信したメッセージ（７１a）の送信先宛先（７２）が記されてあったら送信先宛先（７２）に再送信し、記されていなかったら受信したメッセージ（７１a）を廃棄、つまりメモリに返却する。反対に実行準備状態減算処理（９４）は、実行準備状態監視変数部（８２）に１を減算し、受信したメッセージ（７１a）を廃棄、つまりメモリに返却する。

その後、処理は実行準備状態監視変数判別処理（９５）に進行する。もし、実行準備状態監視変数判別処理（９５）で実行準備状態監視変数部（８２）が０または１であれば、PECI（６７）から電力/エネルギー制御プログラムモジュール（５７）機能である低電力モード処理（９６）を呼び出し、それ以外であれば同じく高電力モード処理（９７）を呼び出す。

図９は、低電力モード処理及び高電力モード処理のフローチャートを説明する図である。低電力モード処理（９６）は、低電力モード処理開始点（１０１）から開始し、低動作周波数変更処理（１０２）、低電源電圧変更処理（１０３）を順に処理をする。低動作周波数変更処理（１０２）は、プロセッサ（２１）に供給する動作周波数を低く設定するよう、CPG（５１）から発生のクロックパルスを変更する。低電源電圧変更処理（１０３）は、プロセッサ（２１）に供給する電源電圧を低くする制御信号（６１）をプロセッサ（２１）から可変DC/DC変換回路（２２）に送信する。可変DC/DC変換回路（２２）は制御信号（６１）を受信すると前記電源電圧を低くする。

高電力モード処理（９７）は、高電力モード処理開始点（１０４）から開始し、高電源電圧変更処理（１０５）、高動作周波数変更処理（１０６）を順に処理をする。高電源電圧変更処理（１０５）は、プロセッサ（２１）に供給する電源電圧を高くする制御信号（６１）をプロセッサ（２１）から可変DC/DC変換回路（２２）に送信する。可変DC/DC変換回路（２２）は、制御信号（６１）を受信すると前記電源電圧を高くする。高動作周波数変更処理（１０６）は、プロセッサ（２１）に供給する動作周波数を高く設定するよう、CPG（５１）から発生のクロックパルスを変更する。

図１０は、ビデオ処理タスク及びオーディオ処理タスク動作のフローチャートを説明する図である。RTOS（２３）提供のシステムコール（６５）で生成したビデオ処理タスク（６４e）は、先ずビデオ処理初期化開始点（１１１）から動作を開始し、RWI（６６）からメッセージ受信待ち判別処理（８３）を呼び出す。

メッセージ受信待ち判別処理（８３）はビデオ処理タスク（６４e）に対する起動イベントであるメッセージ（７１e）が届いているかを判別し、届いていたらビデオ復号化処理（１１２e）を行い、届いていなければメッセージ（７１e）が受信されるまでビデオ処理タスク（６４e）を待ち状態（３２）に移す。

ビデオ復号化処理（１１２e）は、図４、図５、図６に示すマクロブロック処理毎のアプリケーションスライス（４）の繰り返し処理（５）と電力制御チェックポイント（６）での電力制御を行う。ビデオ復号化処理（１１２e）後は、RWI（６６）から待機状態遷移処理（１１３）を呼び出す。待機状態遷移処理（１１３）は、ここではビデオ復号化処理（１１２e）が終了したことを実行準備状態監視タスク（６４a）に知らせる為、前記待機状態遷移用メッセージであるメッセージ（７１a）を実行準備状態監視タスク（６４a）に送信し、最後にビデオ処理タスク（６４e）を待機状態（３２）に遷移させる。

またRTOS（２３）のシステムコール（６５）で生成したオーディオ処理タスク（６４c）は、ビデオ復号化処理（１１２e）をオーディオ復号化処理（１１２f）に置換したものに相当する。従って、ステレオまたはチャンネル処理毎のアプリケーションスライス（４）の繰り返し処理（５）終了後、電力制御チェックポイント（６）で電力制御を行う。

図１１は、タスク内部で行う電力制御アルゴリズムのフローチャートを説明する図である。本明細書では、ビデオ復号化処理（１１２e）及びオーディオ復号化処理（１１２f）の内部にアプリケーションスライス（４）があり、電力制御チェックポイント（６）で電力制御アルゴリズムソフトウェアを埋め込む。

先ず、タスク内電力制御開始点（１２１）から処理を開始し、実行準備状態監視変数部（８２）について、実行準備状態監視変数判別処理（１２２）を行う。実行準備状態監視変数判別処理（１２２）では、実行準備状態監視変数部（８２）が１かどうかを判別する。もし１ならばWCET比較処理（１２３）、１以外ならば仮想WCET比較処理（１２４）を行う。WCET比較処理（１２３）は、例えばビデオ処理タスク（６４e）ないしオーディオ処理タスク（６４f）のタスク起動時刻（１２）からアプリケーションスライス（４c）のｋ番目の処理終了時点（１６）の積算時間（１５）をアプリケーションスライス（４d）の（ｋ＋１）番目の処理のWCET（１４d）から引いた時間差と、前記アプリケーションスライス（４d）の（ｋ＋１）番目の処理のWCET（１４d）と前記アプリケーションスライス（４c）のｋ番目の処理のWCET（１４c）の時間差、つまりｋ番目から（ｋ＋１）番目の間のサブ出力時間（１３）に前記低動作周波数に対する前記高動作周波数の倍率を掛けた時間値を比較する。積算時間（１５）は、TMU（５２）を用いてカウントして時間を積算する。

もし、WCET（１４d）から積算実行時間（１５）を引いた値の方が前記倍率を掛けた時間よりも大きい場合は、電力/エネルギー制御プログラムモジュール（５７）内部管理の電力制御モード部（１２５）を１にする。反対に小さい場合は０にする。更に、アプリケーション/ミドルウェアプログラムモジュール（５８）内部管理のWCET格納部（１２６）の値にサブ出力時間（１３）の値を加算する。なお、WCET（１４）はWCET格納部（１２６）の値である。また、WCET格納部（１２６）は初期化処理（２）でサブ出力時間（１３）とする。

一方、仮想WCET比較処理（１２４）は、前記と同様、例えば、ビデオ処理タスク（６４e）ないしオーディオ処理タスク（６４f）のタスク起動時刻（１２）からアプリケーションスライス（４c）のｋ番目の処理終了時点（１６）の積算時間（１５）をアプリケーションスライス（４d）の（ｋ＋１）番目の処理の仮想WCET（４２d）から引いた時間差と、前記アプリケーションスライス（４d）の（ｋ＋１）番目の処理の仮想WCET（４２d）と前記アプリケーションスライス（４c）のｋ番目の処理の仮想WCET（４２c）の時間差、つまりｋ番目から（ｋ＋１）番目の間の仮想サブ出力時間（４３）に前記低動作周波数に対する前記高動作周波数の倍率を掛けた時間値を比較する。同じく積算実行時間（１５）はTMU（５２）を用いてカウントして時間を積算する。

もし、仮想WCET（４３d）から積算時間（１５）を引いた値の方が前記倍率を掛けた時間よりも大きい場合は、電力/エネルギー制御プログラムモジュール（５７）内部管理の電力制御モード部（１２５）を１にする。反対に小さい場合は０にする。更にアプリケーション/ミドルウェアプログラムモジュール（５８）内部管理の仮想WCET格納部（１２７）の値にサブ仮想出力時間（１３）の値を加算する。なお、仮想WCET（４２）は仮想WCET格納部（１２７）の値である。また仮想WCET格納部（１２７）は初期化処理（２）で仮想サブ出力時間（４３）とする。

電力制御モード判別処理（１２８）は、電力制御モード部（１２５）を判別する。もし電力制御モード部（１２５）が１ならば低電力モード処理（９６）に進み、0ならば高電力モード処理（９７）に進む。
図１２は、出力時間管理タスク動作のフローチャートを説明する図である。出力時間管理タスク（６４b）は、出力時間管理開始点（１３１）から処理を開始する。出力時間管理開始点（１３１b）では、初期化処理として出力時間管理タスク（６４b）自身に再度、起動イベントとしてメッセージ（７１b）を送信する。

メッセージ受信待ち判別処理（８３）は、出力時間管理タスク（６４b）へ起動イベントとしてメッセージ（７１b）が届いているかを判別し、届いていたら出力時間管理処理（１３２）を行い、届いていなければメッセージ（７１b）が受信されるまで出力時間管理処理タスク（６４b）を待ち状態（３２）に移す。

出力時間管理処理（１３２b）は、１フレームのビデオ表示時刻ないし1フレームのオーディオ出力時刻を予めRTOS（２３）に認識させる。その直後、RWI（６６）から待機状態遷移処理（１１３）を呼び出す。待機状態遷移処理（１１３）を呼び出した時点で出力時間管理処理タスク（６４b）は待機状態（３２）に遷移する。
前記ビデオ表示時刻または前記オーディオ出力時刻になると、RTOS（２３）から起動するタイマイベントとしてメッセージ（７１c）を画像表示タスク（６４c）に、またはメッセージ（７１d）をPCM出力タスク（６４d）に送信する。

画像表示タスク（６４c）及びPCM出力タスク（６４d）のフローチャートは図１２で説明の出力時間管理タスク（６４b）と同じである。しかし、出力時間管理処理（１３２b）の部分が、画像表示タスク（６４c）では画像表示処理（１３２c）、PCM出力タスク（６４d）ではPCM出力処理（１３２d）となる。そして、出力時間管理開始点（１３１b）では初期化処理として出力時間管理タスク（６４b）自身にメッセージ（７１b）を送信するが、画像表示開始点（１３１c）、PCM出力開始点（１３１d）ではメッセージ（７１）は送信しない。

画像表示処理（１３２c）は、ビデオ処理タスク（６４e）で処理した画像をディスプレイに表示する。そして実行準備状態監視タスク（６４a）に対してビデオ処理タスク（６４e）の送信先宛先（７２）を記した前記実行準備状態遷移用メッセージ（７１e）を送信し、更に実行準備状態監視タスク（６４a）に受信した送信先宛先（７２）がビデオ処理タスク（６４e）である実行準備状態遷移用メッセージ（７１e）をビデオ処理タスク（６４e）へ送信させる。

PCM出力処理（１３２d）は、オーディオ処理タスク（６４f）で処理したPCM信号をスピーカーに表示する。そして実行準備状態監視タスク（６４a）に対してオーディオ処理タスク（６４f）の送信先宛先（７２）を記した前記実行準備状態遷移用メッセージ（７１f）を送信し、更に実行準備状態監視タスク（６４a）に受信した送信先宛先（７２）がオーディオ処理タスク（６４f）である実行準備状態遷移用メッセージ（７１f）をオーディオ処理タスク（６４f）へ送信させる。

図１３は、スリープタスク動作のフローチャートを説明する図である。スリープタスク（６４g）のスリーププログラム開始点（１４１）から開始し、スリープ処理（１４２）に進む。スリープ処理（１４２）は、プロセッサ（２１）に供給のクロックパルスを停止するようにCPG（５１）で設定し、プロセッサ（２１）を停止させる。スリープタスク（６４g）は最低優先度タスクとしているので、スリープタスク（６４g）以外の全タスクが待機状態、つまりアイドル状態になったらプロセッサは停止する。またTMU（５２）またはI/O（５５）からの割込みが生じるとアイドル状態から通常の動作状態に復帰する。

以上の実装を行うと、実行中のタスクに割込み及び例外処理が入っても、タスク処理の遅延を抑制する制御が可能であり、電力の最適化に効果がある。
図１４は、本発明の情報処理装置の電力制御動作の一実施例を説明する図である。縦軸は、タスク（６４）の消費電力、横軸は時刻とし、各タスクの処理経過を表している。因みにタスク毎の面積は各タスクの消費エネルギーに相当する。

例えばビデオ処理タスク（６４e）の処理は、タスク起動時刻（１２e）で開始し、ビデオ処理タスク（６４e）のデッドラインである出力時間（１１e）まで行う。この時、実行準備状態監視タスク（６４a）の初期化処理（２）は、実行準備状態監視変数部（８２）を１、タスク起動時刻（１２e）での情報処理装置の電力を低電力と設定する。ビデオ処理タスク（６４e）の処理終了までの過程で、アプリケーションスライス（４）の処理毎に電力制御を行う。例えば、３つ目のアプリケーションスライスの処理が終了した段階では、WCETと比較して処理が遅れているため高電力モードに遷移する。

予め設定していたPCM出力タスク（６４d）の起動時刻（１２d）になると、優先度が高いPCM出力タスク（６４d）が起動される。また、実行準備状態監視変数部（８２）に１が加算されて２となる。実行準備状態監視変数部（８２）が２となるので実行準備状態監視タスク（６４a）は、情報処理装置を高電力モードにする。そしてビデオ処理タスク（６４e）はプリエンプト（３６）とされ、実行準備状態（３３）となる。PCM出力タスク（６４d）は、実行状態（３１）となり、予め復号化処理で生成したオーディオのPCM信号をスピーカーに出力する。出力を終了するとオーディオ処理タスク（６４f）にメッセージ（７１f）を送信することでオーディオ処理タスクを実行準備状態とし、図示しないが、実行準備状態監視変数部（８２）に１が加算されて３となる。

PCM出力タスク（６４d）は、終了直前にメッセージ（７１a）を実行準備状態監視タスク（６４a）にメッセージを送信し、実行準備状態監視変数部（８２）に１を減算して２にする。
オーディオ処理タスク（６４f）の起動時刻（１２f）からオーディオ処理タスク（６４f）の処理が始まるが、実行準備状態監視変数部（８２）が２となっているので、オーディオ処理タスク（６４f）の起動時の情報処理装置の電力は高電力モードのままである。

また、オーディオ処理タスク（６４f）は、実行準備状態監視変数部（８２）が２となっているので、オーディオ処理タスク（６４f）の出力時間（１１f）ではなく、オーディオ処理タスク（６４f）の仮想出力時間（４１f）で、アプリケーションスライス（４）の処理毎に電力制御を行う。オーディオ処理タスク（６４f）は、終了直前にメッセージ（７１a）を実行準備状態監視タスク（６４a）にメッセージを送信し、実行準備状態監視変数部（８２）に１を減算して1にする。

オーディオ処理タスク（６４f）が終了すると今までプリエンプト（３６）されて実行準備状態であったビデオ処理タスク（６４e）が実行状態（３１）に復帰し、続きの処理を開始する。復帰時の実行準備状態監視変数部（８２）は１であるので、実行準備状態監視タスク（６４a）は情報処理装置の電力の低電力を設定する。

ビデオ処理タスク（６４e）は、実行準備状態監視変数部（８２）が１であるので、ビデオ処理タスク（６４e）の仮想出力時間（４１e）ではなく出力時間（１１e）でアプリケーションスライス（４）毎に電力制御を行う。
ビデオ処理タスク（６４e）がビデオ処理タスク（６４e）の出力時間（１１e）で終了すると終了直前にメッセージ（７１a）を実行準備状態監視タスク（６４a）にメッセージを送信し、実行準備状態監視変数部（８２）に１を減算して０にする。

実行準備状態監視変数部（８２）は０であるので、実行準備状態監視タスク（６４a）は、情報処理装置の電力モードを低電力に設定する。
予め設定していた画像表示タスク（６４c）の起動時刻（１２c）になると、画像表示タスク（６４c）が起動し、実行準備状態監視変数部（８２）に１が加算されて１となる。実行準備状態監視変数部（８２）は１なので、実行準備状態監視タスク（６４a）は低電力のままにする。

画像表示タスク（６４c）は、画像をディスプレイに表示した後、メッセージ（７１a）を実行準備状態監視タスク（６４a）に送信し、実行準備状態監視変数部（８２）に１を減算して０にする。
オーディオ処理タスク（６４f）の出力時間（１１f）後、予め設定していたPCM出力タスク（６４d）の起動時刻（１２d）になると、実行準備状態監視変数部（８２）に１が加算されて１となる。

上記の制御の効果により、電源電圧及び動作周波数の制御の切り替えタイミングを最適にすることが可能となる。そして消費電力は電源電圧の２乗と動作周波数の積に比例することが一般的に知られている。例えば、電源電圧及び動作周波数の組合せを、1.25[V]、60[MHz]、と1.5[V]、120[MHz]の２電力モードとして電力制御を行う場合、電源電圧の比率は0.83、動作周波数の比率はとなることから、常に1.5[V]及び120[MHz]で動作の消費電力と比較し、約６５％の消費電力を下げることが可能である。また消費エネルギーは電源電圧の２乗と低電源電圧での実行サイクルの積に比例することから、低電源電圧制御と高電源電圧制御の実行サイクル比を５０％から９０％と仮定すると、常に1.5[V]及び120[MHz]で動作の消費エネルギーと比較し、約１５％から約２５％の消費エネルギーを省けることが可能である。

図１５は、本発明の第２の実施例を示す概念図である。図４と異なる点は、複数の仮想WCET（４２）を設けた点にある。第１の実施例では、簡単のため、実行準備状態（３３）のタスク（２４）があるか否かでWCET（１４）を使用するか仮想WCET（４２）を使用するかを決定している。それに対し、本実施例では、仮想WCETを複数設け、実行準備状態（３３）にあるタスク（２４）の数が多い場合は、より短い時間内に終わらせるよう制御するものである。例えば、実行準備状態のタスクが３つ場合（R=3)は、右から３番目の仮想WCETと比較する。このように複数の仮想WCET（４２）を設け、実行準備状態（３３）にあるタスク（２４）の数に対応して選択することにより、よりきめ細かい電力制御が可能となる。また、実行準備状態（３３）にあるタスク（２４）の数が多いということは、プロセッサ（２１）が処理しなければならないタスク（２４）が多いということに該当する。本実施例では、実行準備状態（３３）にあるタスク（２４）が多いほど、早く処理を終了するように電力モードを制御するため信頼性の高い電力制御システムが提供できる。

図１６は、本発明を施した１プロセッサ構成の情報処理装置の一実施例を説明する図である。特に１プロセッサ構成の携帯電話への適用を想定した。
図１のプロセッサCPU（２１）に相当する部分は、ベースバンドプロセッサBB-CPU（２１b）である。ベースバンドプロセッサ（２１b）は主にディジタル通信処理及び通信プロトコル処理を実施するが、通信処理を行っていない時はアプリケーション処理も行う。ベースバンドプロセッサ（２１b）の端子は直接、アンテナ（１５１）に繋がれたアナログ無線回路（以下、RFという）（１５２）、通話する為のマイクロフォン（１５３）、通話と音楽を再生する為のスピーカー（１５４）及びバス（５３）と接続する。
図１のI/O（５５）に相当する部分は、図１６ではCMOSまたはCCDカメラCAM（１５５）と液晶または有機ELディスプレイDPY（１５６）に置換すればよい。

またメモリ（５４）は、フラッシュメモリに代表される不揮発メモリFLMEM（５４a）とSRAMに代表される揮発メモリSRAM（５４b）を用いる。
不揮発メモリ（５４a）には、プログラム命令の本体と固定変数等の静的プログラムデータを格納する。つまり、RTOS（２３）、実行準備状態監視プログラムモジュール（５６）、電力/エネルギー制御プログラムモジュール（５７）、アプリケーション/ミドルウェアプログラムモジュール（５８）を搭載することになる。

一方、揮発メモリ（５４b）は、プログラム命令によって読み書きされる動的変数の実現の為に使用する。つまり揮発メモリ（５４b）は、RTOS（２３）の動的メモリエリア（１５７a）、実行準備状態監視プログラムモジュール（５６）の動的メモリエリア（１５７b）、電力/エネルギー制御プログラムモジュール（５７）の動的メモリエリア（１５７c）、アプリケーション/ミドルウェアプログラムモジュール（５８）の動的メモリエリア（１５７d）を具備する。

図１７は本発明を施した２プロセッサ構成の情報処理装置の一実施例を説明する図である。図１６の情報処理装置では、通信信号処理及び通信プロトコル処理とマルチメディア処理を同時に処理する必要が起こった場合、ベースバンドプロセッサBB-CPU（２１b）にかかる負荷が非常に重い。そこで、通信処理用途のベースバンドプロセッサ（２１ｂ）とマルチメディア処理用途のアプリケーションプロセッサAP-CPU（２１ａ）を情報処理装置に搭載している。ここでもベースバンドプロセッサ（２１ｂ）とアプリケーションプロセッサ（２１ａ）の両者に本願発明を適用することが可能である。

以上、実施例に基づいて説明してきたが、本発明の要旨を逸脱しない限り種々の変更が可能である。例えば、電力モードを低電力モードと高電力モードの２種類で説明してきたが、これに制限されない。即ち、電力モードを複数設け、WCET又は仮想WCETと各アプリケーションスライスの処理終了時の積算実行時間との差、即ち、時間的余裕によって、複数の電力モードから一つの電力モードを選択する構成としてもよい。このように構成することで、よりきめ細かい電力制御を行うことが可能となる。また、電力モードは、モードによって動作周波数と電源電圧とを変更したが、例えば、電源電圧は変えずに動作周波数のみを変更しても良い。

本発明は、情報処理装置、特に、情報処理通信装置に適用して有用なものである。

本発明の代表例を説明する図である。 本発明を実現する為のソフトウェア構成の実施例を説明する図である。 メッセージフォーマットを説明する図である。 本発明の概念図である。 アプリケーションスライスの概念図である。 MPEG-4 ビデオ Decoderプログラムのアプリケーションスライスを説明する図である。 実行準備状態監視タスク動作のフローチャートを説明する図である。 実行準備状態把握処理のフローチャートを説明する図である。 低電力モード処理及び高電力モード処理のフローチャートを説明する図である。 ビデオ処理タスク及びオーディオ処理タスク動作のフローチャートを説明する図である。 タスク内部で行う電力制御アルゴリズムのフローチャートを説明する図である。 出力時間管理タスク動作のフローチャートを説明する図である。 スリープタスク動作のフローチャートを説明する図である。 本発明の情報処理装置の電力制御動作の一実施例を説明する図である。 本発明の第２の実施例を説明する概念図である。 本発明を施した１プロセッサ構成の情報処理装置の一実施例を説明する図である。 本発明を施した２プロセッサ構成の情報処理装置の一実施例を説明する図である。 特許文献１の代表図である。 RTOSのタスク状態遷移図である。 特許文献１に記載の電力制御チェックポイントでの電力制御プログラムの概念図である。 割り込まれたタスクの処理遅延を説明する図である。 実行状態に遷移した直後のタスクの起動時刻の遅延を説明する図である。

符号の説明

１・・・アプリケーションプログラム開始点、２・・・初期化処理、３・・・アプリケーションプログラム終了点、４・・・アプリケーションスライス、５・・・繰り返し判別処理、６・・・電力制御チェックポイント、７・・・アプリケーションスライス処理経過管理部、８・・・画像フォーマット、９・・・マクロブロック、１１・・・出力時間、１２・・・タスク起動時刻、１３・・・サブ出力時間、１４・・・WCET、１５・・・積算実行時間、１６・・・処理終了時点、２１・・・プロセッサ、２２・・・電力制御回路または可変DC/DC Converter、２３・・・RTOS、２４、６４・・・タスク、２５・・・ソフトウェア、３１・・・実行状態、３２・・・待機状態、３３・・・実行準備状態、３４・・・初期状態、３５・・・ディスパッチ、３６・・・プリエンプト、３７・・・実行時間、３８・・・待機時間、３９・・・遅延起動時刻、４０・・・遅延WCET、４１・・・仮想出力時間、４２・・・仮想WCET、４３・・・仮想サブ出力時間、５１・・・CPG、５２・・・TMU、５３・・・バス、５４・・・メモリ、５５・・・I/O、５６・・・実行準備状態監視プログラムモジュール、５７・・・電力/エネルギー制御プログラムモジュール、５８・・・アプリケーション/ミドルウェアプログラムモジュール、５９・・・バッテリ、６０・・・電源系統、６１・・・制御信号、６２・・・ポート、６５・・・System Call、６６・・・RWI、６７・・・PECI、６８・・・API、７１・・・メッセージ、７２・・・送信先宛先、７３・・・送信元宛先、７４・・・送信内容、８１・・・初期状態、８２・・・実行準備状態監視変数部、８３・・・メッセージ受信待ち判別処理、８４・・・実行準備状態把握処理、９１・・・実行準備状態監視開始点、９２・・・メッセージ判別処理、９３・・・実行準備状態加算処理、９４・・・実行準備状態減算処理、９５・・・実行準備状態監視変数判別処理、９６・・・低電力モード処理、９７・・・高電力モード処理、１０１・・・低電力モード処理開始点、１０２・・・低動作周波数変更処理、１０３・・・低電源電圧変更処理、１０４・・・高電力モード処理開始点、１０５・・・高電源電圧変更処理、１０６・・・高動作周波数変更処理、１１１・・・ビデオ処理初期化開始点、１１２・・・ビデオ復号化処理、１１３・・・待機状態遷移処理、１２１・・・タスク内電力制御開始点、１２２・・・実行準備状態監視変数判別処理、１２３・・・WCET比較処理、１２４・・・仮想WCET比較処理、１２５・・・電力制御モード部、１２６・・・WCET格納部、１２７・・・仮想WCET格納部、１２８・・・電力制御モード判別処理、１３１・・・出力時間管理開始点、１３２・・・出力時間管理処理、１４１・・・スリーププログラム開始点、１４２・・・スリープ処理、１５１・・・アンテナ、１５２・・・RF、１５３・・・マイクロフォン、１５４・・・スピーカー、１５５・・・CMOSまたはCCDカメラ、１５６・・・液晶または有機ELディスプレイ、１５７・・・動的メモリエリア。

Claims (7)

1. プロセッサと、前記プロセッサに内蔵され又は前記プロセッサの外部に設けられるハードウェアタイマーと、前記プロセッサ及びハードウェアタイマーにクロックを供給するクロックパルス発生器とを有する情報処理装置であって、
   前記ハードウェアタイマーは、アプリケーションタスクの開始から現時点までの処理時間を計測し、
   前記アプリケーションタスクは、複数の処理単位に分割され、前記複数の処理単位毎に電力制御チェックポイントが設けられ、
   前記プロセッサは、前記電力制御チェックポイントに到達したのを受けて、実行準備状態監視タスクを実行することにより、実行準備状態のアプリケーションタスク数をカウントし、前記実行準備状態のアプリケーションタスクが存在しない場合は、前記アプリケーションタスクの前記複数の処理単位のうち所定の処理単位を処理するのにかかった時間と前記処理単位の最悪実行時間とを比較し、前記比較結果に基づいて、前記クロックパルス発生器から出力される動作周波数を変更し、前記実行準備状態のアプリケーションタスクが存在する場合は、前記アプリケーションタスクの前記複数の処理単位のうち所定の処理単位を処理するのにかかった時間と前記処理単位の前記最悪実行時間より短い仮想最悪実行時間とを比較し、前記比較結果に基づいて、前記クロックパルス発生器から出力される動作周波数を変更することを特徴とする情報処理装置。
2. 請求項１において、
   前記プロセッサは、前記最悪実行時間又は前記仮想最悪実行時間と前記所定の処理単位を処理するのにかかった時間を比較した結果、前記最悪実行時間又は前記仮想最悪実行時間と前記所定の処理単位を処理するのにかかった時間の差が所定時間より大きい場合に、現在実行処理中の前記アプリケーションタスクを実行するための前記動作周波数と前記電源電圧を下げ、前記時間の差が所定時間より小さい場合は、前記動作周波数と前記電源電圧を上げることを特徴とする情報処理装置。
3. 請求項１又は２において、
   前記プロセッサは、前記実行準備状態のアプリケーションタスクの数によって、前記仮想最悪実行時間における前記最悪実行時間を早める度合いを変更することを特徴とする情報処理装置。
4. 請求項１から３の何れか１項において、
   前記プロセッサは、オペレーティングシステムに基づいて動作することを特徴とする情報処理装置。
5. 複数の処理単位に分割された複数のアプリケーションタスクを実行するプロセッサと、タイマとを具備し、第１の電力モードと前記第１の電力モードより消費電力の小さい第２の電力モードとを有する情報処理装置の動作を制御するオペレーティングシステムであって、
   前記オペレーティングシステムは、
   前記情報処理装置に、実行準備状態にあるアプリケーションタスクの数を管理させる第１手段と、
   前記情報処理装置に、前記複数のアプリケーションタスクのうち第１のアプリケーションタスクを前記プロセッサを用いて実行する際に、実行準備状態にあるアプリケーションタスクが所定数より小さい場合は、前記複数の処理単位ごとに、夫々の処理単位の処理が終了すべき最悪実行時間を算出させ、前記第１のアプリケーションタスクを前記プロセッサを用いて実行する際に、実行準備状態にあるアプリケーションタスクの数が所定数より大きい場合は、前記複数の処理単位ごとに、対応する前記最悪実行時間より短い仮想最悪実行時間を算出させる第２手段と、
   前記情報処理装置に、前記第１のアプリケーションタスクの所定の処理単位が終了した時点で、前記タイマにより計測された前記所定の処理単位の実行時間と前記所定の処理単位に対応する前記最悪実行時間又は前記仮想最悪実行時間とを比較させ、前記所定の処理単位に対応する前記最悪実行時間又は前記仮想最悪実行時間と前記所定の処理単位の実行時間との差が所定時間より大きい場合、前記情報処理装置を前記第２の電力モードで動作させ、前記所定時間より小さい場合、前記情報処理装置を前記第１の電力モードで動作させる第３手段を有することを特徴とするオペレーティングシステム。
6. 請求項５において、
   前記オペレーティングシステムは、前記情報処理装置に、前記情報処理装置が前記第２の電力モードで動作している状態で、前記第１のアプリケーションタスクの所定の処理単位が終了した際に、実行準備状態にあるアプリケーションタスクの数が所定数より大きくなった場合に、前記情報処理装置を前記第１の電力モードに遷移させる第４手段を更に有することを特徴とするオペレーティングシステム。
7. 請求項６において、
   前記第１手段は、実行準備状態監視タスクを起動することにより実現され、
   前記実行準備状態監視タスクは、前記複数の処理単位ごとに前記プロセッサにより実行されるオペレーティングシステム。

Images