(57)【要約】【課題】マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を図る。【解決手段】複数のプロセッサエレメント（１０３，１０４，１０５）を含み、アプリケーションソフトウェアを実行可能なマルチプロセッサ（１０７）において、上記アプリケーションソフトウェアからの要求に応じて、上記複数のプロセッサエレメントに割り当てられるタスクを決定するための処理を行う処理部（２１０）を設ける。上記処理部は、上記アプリケーションソフトウェアからの要求に応じて、上記複数のプロセッサエレメントに割り当てられるタスクを決定する。このことが、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を達成する。【選択図】図１
2007133723.tif 000002
【特許請求の範囲】
【請求項１】
複数のプロセッサエレメントを含み、上記複数のプロセッサエレメントによって、アプリケーションソフトウェアを実行可能なマルチプロセッサであって、
上記アプリケーションソフトウェアからの要求に応じて、上記複数のプロセッサエレメントに割り当てられるタスクを決定するための処理を行う処理部を含むことを特徴とするマルチプロセッサ。
【請求項２】
複数のプロセッサエレメントを含み、上記複数のプロセッサエレメントによって、アプリケーションソフトウェアを実行可能なマルチプロセッサであって、
それぞれ上記複数のプロセッサエレメントへの処理の割り付けが互いに異なる複数のタスクと、
上記アプリケーションソフトウェアからの要求に応じたタスクを、上記複数のタスクの中から選択するためのタスクマネージャと、を含むことを特徴とするマルチプロセッサ。
【請求項３】
上記タスクと、それを構成するサブタスクと、上記サブタスクの処理時間の予算と評価結果、上記サブタスクを実現するハードウェアコードと動作周波数を含むハードウェアパラメータを含むタスク管理テーブルと、
上記ハードウェアパラメータの実体、及び上記ハードウェアパラメータと処理時間との相関情報を含むハードウェアモデルと、を有し、
上記タスクマネージャは、上記タスク管理テーブルと上記ハードウェアモデルとに基づいてタスクスケジューリングを行う請求項２記載のマルチプロセッサ。
【請求項４】
上記タスクマネージャは、上記アプリケーションソフトウェアからの要求に基づく上記タスクの変更後、上記タスク管理テーブルと上記ハードウェアモデルテーブルとに基づいて実現性の判別を行い、この判別において、上記アプリケーションソフトウェアからの要求が満たされないと判断した場合に、上記ハードウェアパラメータの変更、又は現在のタスクよりも優先順位が低いタスクに変更する請求項２記載のマルチプロセッサ。
【請求項５】
アプリケーションソフトウェアのソフトウェア処理が複数のプロセッサエレメント割り付けられることによりタスク単位で実行可能なマルチプロセッサにおけるタスクスケジューリング方法であって、
上記複数のタスクについての優先度を示すタスク優先度テーブルに基づいて、上記プロセッサエレメントに割り付けられたタスクの割り付けを変更する処理を含むタスクスケジューリング方法。
【請求項６】
上記タスク優先度テーブルは、上記複数のタスクについての優先度情報と共に、上記タスクを実行するためのハードウェアパラメータを含む請求項５記載のタスクスケジューリング方法。
【請求項７】
タスク管理のためのタスク管理テーブルと、ハードウェアモデル情報のハードウェアモデルテーブルとを用いて、処理時間要求が満たされるか否かの判定を行い、その判定結果に応じて、要求される処理時間を実現するためのハードウェアパラメータを、上記タスク管理テーブルと上記ハードモデルテーブルを用いて再計算する請求項６記載のタスクスケジューリング方法。
【請求項８】
上記タスク優先度テーブルに基づく優先順位第１位のタスク実行中に、処理時間の要求変更があれば、優先順位第１位のタスクのハードウェアパラメータの変更か、又は優先順位第２位以下のタスクの選択と上記タスクを実行するハードのパラメータ変更がアプリケーションソフトウェアの要求を満たすなら、選択されたタスクとハードウェアパラメータによる実行を新たなタスクとして選択する請求項６記載のタスクスケジューリング方法。
【請求項９】
アプリケーションソフトウェアの処理時間要求が、処理データ単位によって規定されるとき、タスクの中間チェックポイントとチェックポイントの予算を保持するタスクチェックポイントテーブルに基づいて、第１の処理データ単位に対してタスクのチェックポイントの実行が予算を超えたときに、次の第２の処理データ単位に対してタスクの予算を超えないように、第１の予算を超えた時間を第２のタスクに対して元の予算から差し引いて、タスク処理時間を決定する請求項７記載のタスクスケジューリング方法。
【請求項１０】
複数のプロセッサエレメントを含むマルチプロセッサでアプリケーションソフトウェアが実行されるとき、上記アプリケーションソフトウェアからの要求に応じてタスクのスケジューリングを可能とするコンパイラであって、
上記アプリケーションソフトウェアを細分化したモジュールと、上記モジュールが処理する入力データを分割して並列に処理できるか否かを示すフラグ、上記モジュールの入出力のデータ転送量とデータ転送先のモジュールの情報を含むモジュールテーブルと、
上記モジュールをサブタスク候補として選択し、上記サブタスク候補の各々に対して、上記サブタスクが利用するハードウェアコード、ハードウェアパラメータとそれを適用した上記サブタスクの処理時間の予想値、上記サブタスクを組み合わせて構成するタスク候補を含むタスク候補管理テーブルと、
上記サブタスク候補が利用する上記マルチプロセッサ内の上記ハードウェアコードの実体と、上記ハードウェアパラメータと処理時間の相関を表すハードウェアモデルと、データ転送のみを行うハードウェアについてのデータ転送最大能力を有するハードウェア動作モデルテーブルと、
第１プロセッサエレメントへ割り付けて実行する第１タスク候補と、上記第１プロセッサエレメントとは異なる第２プロセッサエレメントへ割り付けて実行する第２タスク候補とがタスク候補管理テーブルにあるとき、上記複数のタスク候補のどれを優先するかを指定し、タスク候補を実行するためのハードウェアパラメータとタスク処理時間の最小値と最大値の候補、上記タスクに対する処理時間要求値とこれに対応するハードウェアパラメータの候補を有するタスク候補優先度テーブルと、を参照し、
上記タスクに対する処理時間要求値が実現可能か否かを上記プロセッサエレメント毎に判別するとともに、上記データ転送のみを行うハードウェアのデータ転送最大能力を超えるか否かを判別する第１処理と、
上記第１処理での判別結果に基づいて、上記タスク候補管理テーブルをタスク管理テーブルとして出力する第２処理と、を含むコンパイラ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のプロセッサを含んで成るマルチプロセッサにおいて、プログラムの並列性を抽出して各プロセッサに適したタスク分割と配置を行うための技術に関し、例えばヘテロジニアスマルチプロセッサにおけるスケジューリングに適用して有効な技術に関する。
【背景技術】
【０００２】
半導体集積回路の一例とされるマイクロプロセッサにおいては、微細化に伴う動作周波数（クロック周波数）の限界や、電力増大により、演算処理の高速化が限界に近づいている。そこで、複数のプロセッサを１チップに集積して成るヘテロジニアスマルチプロセッサにおいて、処理を並列化する技術が注目されている。
【０００３】
マルチプロセッサは、大型計算機やパソコン用に開発されてきているが、その場合の複数のプロセッサは同種のプロセッサとされる。これに対してヘテロジニアスマルチプロセッサの場合には、複数の異種プロセッサを１チップに配置して成るもので、組込みシステムを対象にして、より小面積と低電力を志向し、扱う処理に応じて最適なプロセッサの組み合わせが検討される。
【０００４】
ヘテロジニアスマルチプロセッサは、処理効率の良さが利点とされ、その利点を生かすには、アプリケーションソフトウェア処理をどのプロセッサエレメント（ＰＥ）へ割付るかが重要とされる。処理の割付は、ＯＳ（オペレーティングシステム）によって行われる。オペレーティングシステム（ＯＳ）は、タスクと呼ばれる処理単位ごとに順次割付を行う。このことから、プロセッサエレメントへの処理の割り付けを、「タスクスケジューリング」と称する。
【０００５】
タスクスケジューリングにおいては、アプリケーションソフトウェアの要求に基づき、プロセッサエレメントへタスクを適切に割付ることが重要となる。タスクスケジューリングを人手で行うことは、以下の理由により困難とされる。
【０００６】
第１の理由は、アプリケーションソフトウェア要求のトレードオフを考慮しなければならないことにある。アプリケーションソフトウェアの要求は、マルチプロセッサ構成が決まった後のソフトウェアで実現可能な要求に関し、ある処理がある一定の時間内に終了するというリアルタイム制約、マルチプロセッサ全体が一定の電力に収まるという電力制約からなる。リアルタイム制約と電力制約は、トレードオフの関係にある。リアルタイム制約の遵守は、高性能化すれば達成できるため、例えば、動作周波数の向上やが解となり得る。一方、電力制約の遵守は、動作周波数の低減が解となりうる。以上のトレードオフを人手で考慮して、最適なスケジューリングを実現するのは困難となる。
【０００７】
第２の理由は、ヘテロジニアスマルチプロセッサを対象とするため、異質のプロセッサエレメントというハードリソースを考慮しなければならないことにある。すなわち、異質のプロセッサエレメントであるが故に、レイテンシやスループットなどの性能要因が異なり、どの処理を割り付けるかにも依存する。また、これらの性能要因は、プロセッサエレメント間でのデータのタイミングにも影響を与える。以上の多数の要因を人手で考慮して、最適なスケジューリングを実現するのは困難となる。
【０００８】
以上の理由により、スケジューリングを自動的に決定するコンパイラが研究されている（例えば非特許文献１参照）。また、マルチプロセッサ全体のタスクのスケジュールという観点で、電力を考慮した技術が知られている（特許文献１，２参照）。
【０００９】
【特許文献１】特開２００２−２０２８９３号公報
【特許文献２】特開２００４−１９９１３９号公報
【非特許文献１】H.Honda, H.Kasahara, S.Narita, and S.Mizuno, 捻arallel Processing Scheme of a Basic Block in a Fortran Program on OSCAR   Systems and Computers in JAPAN, Vol.22, No.11, pp.1-13, 1991
【発明の開示】
【発明が解決しようとする課題】
【００１０】
上記の従来技術について本願発明者が検討したところ、システム実行前にスケジューリングをスタティックに決定するようにしているため、アプリケーションソフトウェア要求に対する柔軟性という観点から、以下の２点について改善の余地があることが見いだされた。
【００１１】
第１に、システム機器出荷後、または異なるシステム機器に同一のアプリケーションソフトウェアを搭載する場合の柔軟性の欠如である。近年、車や情報家電など、高機能なアプリケーションソフトウェアも製品寿命が長くなっており、システム機器出荷後に、アプリケーションソフトウェアの要求が変更されることはある。特に、性能要求が高くなることは、十分考えられる。また、地上波ディジタルテレビジョンなど、人気の高いアプリケーションソフトウェアは、カーナビゲーションシステムゲーションシステム、情報家電、携帯電話など様々な機器に搭載されることが予想されるが、同一のＬＳＩとアプリケーションソフトウェアに対する要求は、それが搭載される機器により必然的に異なっている。これら二つのケースについて、柔軟性をシステム機器メーカサイドで保障するには、ソフトウェアの制御により、タスクスケジューリングを簡単に変更できることが望まれる。
【００１２】
第２に、動的な要因で、当初の予算通りにアプリケーションソフトウェア要求が満たせないときの動的なスケジューリング変更である。動的な要因としては、マルティメディア系のアプリケーションソフトウェアなどに代表されるデータ依存性が挙げられる。かかるケースにおいても、タスクスケジューリングを簡単に変更できることが望まれる。
【００１３】
本発明の目的は、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を図るための技術を提供することにある。
【００１４】
本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１５】
本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
【００１６】
すなわち、複数のプロセッサエレメントを含み、上記複数のプロセッサエレメントによって、アプリケーションソフトウェアを実行可能なマルチプロセッサにおいて、上記アプリケーションソフトウェアからの要求に応じて、上記複数のプロセッサエレメントに割り当てられるタスクを決定するための処理を行う処理部を設ける。
【００１７】
上記処理部は、上記アプリケーションソフトウェアからの要求に応じて、上記複数のプロセッサエレメントに割り当てられるタスクを決定する。このことが、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を達成する。
【００１８】
複数のプロセッサエレメントを含み、上記複数のプロセッサエレメントによって、アプリケーションソフトウェアを実行可能なマルチプロセッサにおいて、それぞれ上記複数のプロセッサエレメントへの処理の割り付けが互いに異なる複数のタスクと、上記アプリケーションソフトウェアからの要求に応じたタスクを、上記複数のタスクの中から選択するためのタスクマネージャとを含んでマルチプロセッサを構成する。
【００１９】
上記タスクマネージャは、上記アプリケーションソフトウェアからの要求に応じたタスクを、上記複数のタスクの中から選択する。このことが、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を達成する。
【００２０】
このとき、上記タスクと、それを構成するサブタスクと、上記サブタスクの処理時間の予算と評価結果、上記サブタスクを実現するハードウェアコードと動作周波数を含むハードウェアパラメータを含むタスク管理テーブルと、上記ハードウェアパラメータの実体、及び上記ハードウェアパラメータと処理時間との相関情報を含むハードウェアモデルとを設けることができ、その場合において、上記タスクマネージャは、上記タスク管理テーブルと上記ハードウェアモデルとに基づいてタスクスケジューリングを行うように構成することができる。
【００２１】
また、上記タスクマネージャは、上記アプリケーションソフトウェアからの要求に基づく上記タスクの変更後、上記タスク管理テーブルと上記ハードウェアモデルテーブルとに基づいて実現性の判別を行い、この判別において、上記アプリケーションソフトウェアからの要求が満たされないと判断した場合に、上記ハードウェアパラメータの変更、又は現在のタスクよりも優先順位が低いタスクに変更するように構成することができる。
【００２２】
アプリケーションソフトウェアのソフトウェア処理が複数のプロセッサエレメント割り付けられることによりタスク単位で実行可能なマルチプロセッサにおけるタスクスケジューリング方法において、上記複数のタスクについての優先度を示すタスク優先度テーブルに基づいて、上記プロセッサエレメントに割り付けられたタスクの割り付けを変更する処理を含める。
【００２３】
上記の手段によれば、上記複数のタスクについての優先度を示すタスク優先度テーブルに基づいて、上記プロセッサエレメントに割り付けられたタスクの割り付けを変更される。このことが、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を達成する。
【００２４】
このとき、上記タスク優先度テーブルは、上記複数のタスクについての優先度情報と共に、上記タスクを実行するためのハードウェアパラメータを含んで構成することができる。
【００２５】
タスク管理のためのタスク管理テーブルと、ハードウェアモデル情報のハードウェアモデルテーブルとを用いて、処理時間要求が満たされるか否かの判定を行い、その判定結果に応じて、要求される処理時間を実現するためのハードウェアパラメータを、上記タスク管理テーブルと上記ハードモデルテーブルを用いて再計算するように構成することができる。
【００２６】
上記タスク優先度テーブルに基づく優先順位第１位のタスク実行中に、処理時間の要求変更があれば、優先順位第１位のタスクのハードウェアパラメータの変更か、又は優先順位第２位以下のタスクの選択と上記タスクを実行するハードのパラメータ変更がアプリケーションソフトウェアの要求を満たすなら、選択されたタスクとハードウェアパラメータによる実行を新たなタスクとして選択するように構成することができる。
【００２７】
アプリケーションソフトウェアの処理時間要求が、処理データ単位によって規定されるとき、タスクの中間チェックポイントとチェックポイントの予算を保持するタスクチェックポイントテーブルに基づいて、第１の処理データ単位に対してタスクのチェックポイントの実行が予算を超えたときに、次の第２の処理データ単位に対してタスクの予算を超えないように、第１の予算を超えた時間を第２のタスクに対して元の予算から差し引いて、タスク処理時間を決定するように構成することができる。
【００２８】
複数のプロセッサエレメントを含むマルチプロセッサでアプリケーションソフトウェアが実行されるとき、上記アプリケーションソフトウェアからの要求に応じてタスクのスケジューリングを可能とするコンパイラにおいて、第１処理と第２処理とを設ける。上記第１処理は、各種テーブルに基づいて上記タスクに対する処理時間要求値が実現可能か否かを上記プロセッサエレメント毎に判別するとともに、上記データ転送のみを行うハードウェアのデータ転送最大能力を超えるか否かを判別する。上記第２処理は、上記第１処理での判別結果に基づいて、上記タスク候補管理テーブルをタスク管理テーブルとして出力する。上記各種テーブルは、モジュールテーブル、タスク候補管理テーブル、ハードウェア動作モデルテーブル、及びタスク候補優先度テーブルを含む。
【００２９】
上記モジュールテーブルは、上記アプリケーションソフトウェアを細分化したモジュールと、上記モジュールが処理する入力データを分割して並列に処理できるか否かを示すフラグ、上記モジュールの入出力のデータ転送量とデータ転送先のモジュールの情報を含む。
【００３０】
上記タスク候補管理テーブルは、上記モジュールをサブタスク候補として選択し、上記サブタスク候補の各々に対して、上記サブタスクが利用するハードウェアコード、ハードウェアパラメータとそれを適用した上記サブタスクの処理時間の予想値、上記サブタスクを組み合わせて構成するタスク候補を含む。
【００３１】
上記ハードウェア動作モデルテーブルは、上記サブタスク候補が利用する上記マルチプロセッサ内の上記ハードウェアコードの実体と、上記ハードウェアパラメータと処理時間の相関を表すハードウェアモデルと、データ転送のみを行うハードウェアについてはデータ転送最大能力を有する。
【００３２】
上記タスク候補優先度テーブルは、第１プロセッサエレメントへ割り付けて実行する第１タスク候補と、上記第１プロセッサエレメントとは異なる第２プロセッサエレメントへ割り付けて実行する第２タスク候補とがタスク候補管理テーブルにあるとき、上記複数のタスク候補のどれを優先するかを指定し、タスク候補を実行するためのハードウェアパラメータとタスク処理時間の最小値と最大値の候補、上記タスクに対する処理時間要求値とこれに対応するハードウェアパラメータの候補を有する。
【発明の効果】
【００３３】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記の通りである。
【００３４】
すなわち、マルチプロセッサにおけるタスクスケジューリングにおいて、アプリケーションソフトウェアに対する柔軟性の向上を図るための技術を提供することができる。
【発明を実施するための最良の形態】
【００３５】
図１には、本発明に係るマルチプロセッサの一例とされるヘテロジニアスマルチプロセッサを搭載して成るカーナビゲーションシステム機器が示される。図１に示されるカーナビゲーションシステム機器１００は、自動車を目的地に誘導するもので、そのための各種演算処理を行うヘテロジニアスマルチプロセッサ１０７を含んで成る。このヘテロジニアスマルチプロセッサ１０７によれば、システム機器出荷後、又は異なるシステム機器に同一のアプリケーションソフトウェアを搭載する場合のアプリケーションソフトウェア要求に変更があった場合に柔軟に対応可能とされ、また、動的なスケジューリングにより、可能な限り予算遵守を行い、サービス品質の向上を図ることができる。
【００３６】
先ず、ヘテロジニアスマルチプロセッサ１０７のカーネル部分の概要について説明する。
【００３７】
図１に示されるヘテロジニアスマルチプロセッサ１０７は、互いに種類が異なる複数のプロセッサエレメント（ＰＥ）を含んで成る。ここで、複数のプロセッサエレメント（ＰＥ）には、ＣＰＵ（汎用プロセッサ）１０３、ＤＳＰ（信号処理プロセッサ）１０４、及びＤＲＰ（ダイナミックリコンフィギュラブルプロセッサ）１０５が含まれる。プロセッサエレメントと、共用メモリ（ＣＭ）１０２とは、共用バス１０１によって互いに信号のやり取りが可能に結合され、公知の半導体集積回路製造技術により、単結晶シリコン基板などの一つの半導体基板に形成される。上記ＣＰＵ１０３は、タスクスケジューリング機能を有するマスタプロセッサであり、タスクマネージャ（ＴｓｋＭ）２１０と、基本ソフトウェア（ＢＳｏｆｔ）２０９を搭載する。基本ソフトウェア２０９は、ＯＳ（オペレーティングシステム）や、ＤＲＰ１０５におけるプロセッサエレメントのドライバを含む。
【００３８】
タスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８は、ヘテロジニアスマルチプロセッサ１０７に対して、アプリケーションソフトウェアの要求とそれに伴うタスクの優先順位を示すもので、そのテーブル情報は、後述するタスクスケジューリング決定や、タスク選択の判断基準に用いられる。
【００３９】
図２には、アプリケーションソフトウェア実行時の動的なスケジューリングの概要が示される。
【００４０】
本システム機器１００は、通常時には、予め設定されているレギュラー状態（ＲＳ）８００のタスクを実行する。タスクマネージャ２１０は、各種テーブル群８０６に基づいてタスクリスケジューリングを行う。ここで上記各種テーブル群８０６には、タスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８、タスク管理テーブル８０９、ハードウェアモデルテーブル（Ｈ−Ｍｏｄｌ）８１４、タスクチェックのためのチェックポイントテーブル（ＴＡ−ＣＨＣ）８１３が含まれる。上記タスク管理テーブル８０９の情報には、タスクバジェット（Ｔ−Ｂｕ）、タスクエバリエーション（Ｔ−Ｅｖ）、バスパラメータ（Ｐａｒｍ）が含まれる。
【００４１】
ＲＳ８００は、タスクの終了や後述するチェックポイントの時点で、タスクマネージャ（ＴｓｋＭ）２１０に、現在のタスクの実行状態が通知される（８１０）。通知を受けたタスクマネージャ２１０は、最初に定めたリアルタイム制約に基づく実行計画通りにアプリケーションソフトウェアが動作しているか否かをタスクチェックのためのチェックポイントテーブル（ＴＡ−ＣＨＣ）８１３に基づいてチェックし、それが良好なら何もしない。これに対して、実行計画の時間をオーバして動作中であれば、イレギュラー状態８０１への遷移を検討する。このとき、ＩＲＳ８０１のタスク選択にタスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８が参照される。選択するタスクで実行計画の修正が可能か否かは、タスクの評価結果や予算、ハードウェアパラメータからなるタスク管理テーブル８０９が参照される。このとき、動作周波数などのハードウェアパラメータの見直しが、ハードウェア動作モデル（Ｈ−Ｍｏｄｌ）８１４を用いて行われる。計画修正を行った後、ＩＲＳ８０１のタスク実行を指示する（８０２）。ハードウェアパラメータの見直し指示も行われる（８１２）。
【００４２】
レギュラー状態（ＲＳ）８００からイレギュラー状態（ＩＲＳ）８０１に遷移された後も、現在のタスクの実行状態が通知され（８１２）、元の実行計画に戻れば、ＲＳ８００へ復帰される（８０３）。
【００４３】
次に、上記アプリケーションソフトウェアとしてＭＰＥＧデコーダを例として、アプリケーションソフトウェア実行時のタスクスケジューリングとタスクマネージャの動作について説明する。
【００４４】
図３には、ＭＰＥＧデコーダのデータの流れが示される。
【００４５】
図３に示されるＭＰＥＧデコーダは、ビデオデータをデコードするためのビデオ処理部２３１、オーディオデータをデコードするためのオーディオ処理部２３２と、それらを制御する制御部２３０とを含んで成る。ビデオ処理部２３１は、入力されたビデオデータをバッファリングするためのビデオバッファ（ＶＢｕｆ）２０７と、その出力データをデコードするためのビデオデコーダ（ＶＤｃｏｄ）２２５とを含んで成る。オーディオ処理部２３２は、入力されたオーディオデータをバッファリングするためのオーディオバッファ２０６と、その出力データをデコードするためのオーディオデコーダ（ＡＤｃｏｄ）２２４とを含んで成る。
【００４６】
入力データ２００がデマルチプレクサ（ＤＭＸ）２１９により、ビデオデータ２０２とオーディオデータ２０１とに分離され、それと同時に、ビデオデコーダ（ＶＤｃｏｄ）２２５と、オーディオデコーダ（オーディオデータ）２０１の実行タイミングデータがシステム制御部（Ｓｃｎｔｌ）２２３に渡される。システム制御部２２３は、タイミングデータ２２２と２２１を、ビデオデコーダ２２５とオーディオデコーダ２２４に転送する。ビデオデコーダ２２５とオーディオデコーダ２２４とは、それぞれ対応する入力データをデコードする。このデコーダ２２５，２２４の出力データ２０４，２０３は、それぞれＶＤａｔａ，ＡＤａｔａとして、図示されない後段回路に伝達される。
【００４７】
次に、レギュラー状態のタスク実行について説明する。
【００４８】
図４には、図３に示されるＭＰＥＧデコーダをヘテロジニアスマルチプロセッサ１０７に割り付けた場合が示される。
【００４９】
例えば、デマルチプレクサ（ＤＭＸ）２１９は、ＣＰＵ１０３上のタスクｔ１１として割り付けられており、オーディオデコーダ２２４はＤＳＰ１０４上のタスクｔ２に、ビデオデコーダ２２５は、ＤＲＰ１０５上のタスクｔ３に、それぞれ割り付けられている。これらの処理モジュールのタスクの他に、データ転送もタスクとして割り付けられている。
【００５０】
図４においてＣＰＵ１０３は、ＤＳＰ１０４、ＤＲＰ１０５にタスク実行の起動をかけ、実行状態の監視を行うマスタプロセッサとして機能する。各プロセッサエレメント（ＰＥ）、すなわち、ＣＰＵ１０３、ＤＳＰ１０４、ＤＲＰ１０５は、それぞれローカルメモリ（ＬＭ）２１８，２１７，２１６を含み、プロセッサエレメント内で閉じる処理については、対応するローカルメモリ（ＬＭ）を利用する。各プロセッサエレメント間でのデータ転送は、共有バス１０１を用いて行われる。共有メモリ（ＣＭ）１０２は、最初のデータと最終結果のみを保持する。ＣＰＵ１０３は、基本ソフトウェア（Ｂｓｏｆｔ）２０９内のＯＳを介してプロセッサエレメント上のタスクの起動を行う。タスクのスケジューリング計画は、ＯＳ内のテーブルに格納されている。タスクに起動をかけるには、対応する制御レジスタ（ＣＲ）２１３，２１４，２１５が用いられる。起動指示が制御レジスタ（ＣＲ）に設定された後は、各プロセッサエレメント上の割り込み処理か、ポーリングにより各プロセッサエレメント上のタスクが起動される。各プロセッサエレメント上のタスクは、終了時点か中間のチェックポイントに達したとき、状態レジスタ（ＳＲ）２０８に、その旨を通知する。その通知を受けて、タスクマネージャ（ＴｓｋＭ）２１０は、タスクの状態の良否を判別する。この判別において、実行計画に対して状態が悪いと判断された場合にはイレギュラー状態８０１への遷移が検討される。
【００５１】
図５には、上記ＭＰＥＧデコーダにおけるタスク制御のタイミングが示される。
【００５２】
先ず、図３における入力データ２００は、共有メモリ１０２からバス１０１を介して、ローカルメモリ２１８に転送される。その後、ＣＰＵ１０３上で、タスクｔ１１とｔ１２の処理が行われ、データ３０１と３０２が、バス１０１を介してローカルメモリ２１７と２１６に転送される。ここで、データ３０１は、図３におけるデータ２０１と２２２を含み、データ３０２は、図３におけるデータ２０２と２２１を含む。データ３０１と３０２を受け取ったＤＳＰ１０４とＤＲＰ１０５は、それぞれタスクｔ２とｔ３の処理を行い、最終結果２０３と２０４を、バス１０１を介して共用メモリ１０２に転送する。
【００５３】
上記の処理は、フレームと呼ばれる単位で行われる。ＣＰＵ１０３では、一つのフレーム処理が終了する前に、次のフレームの処理が開始される。ＤＳＰ１０４とＤＲＰ１０５では、一つのフレームのデコード処理が終了されてから、第２番目のデータ３０１と３０２のデコード処理が開始される。
【００５４】
図６には、上記ＭＰＥＧデコーダにおける別のタスク制御のタイミングが示される。
【００５５】
ここでは、データの転送元がバスマスタとなりデータ転送タスクを受け持つとして、タスクの制御タイムチャートが示される。ただし、共用メモリ１０２とのデータ転送だけは、転送元でなく、常に各プロセッサエレメントがバスマスタとなる。
【００５６】
図５において、データ２００の転送は、ＣＰＵ１０２のタスクｄｔ１１によって行われ、データ３０１と３０２の転送は、ＣＰＵ１０２のタスクｄｔ１２とｄｔ１３によって行われる。これにより、ＣＰＵ１０２では、一連のタスクｄｔ１１、ｔ１１、ｔ１２、ｄｔ１２、ｄｔ１３が実行されることとなる。タスクスケジューリングのマスタから見ると、それはＴ１という一つのタスクとなる。タスクｄｔ１１、ｔ１１などは、サブタスクと定義する。同様にして、ＤＳＰ１０４上では、タスクｔ２と、データ２０３の転送を行うサブタスクｄｔ２を併せてタスクＴ２となり、ＤＲＰ１０５上では、タスクｔ３と、データ２０４の転送を行うサブタスクｄｔ３を併せてタスクＴ３となる。
【００５７】
ＣＰＵ１０３上で、タスク制御を行う基本ソフトウェア２０９とタスクマネージャ２１０は、タスクＴ１、Ｔ２、Ｔ３の３つのタスクの制御と状態監視を行う。ただし、この例では、基本ソフトウェア２０９としてはタスク制御のみが記載され、タスクマネージャ２１０としては、レギュラー状態でのタスクの状態監視のみが記載されている。
【００５８】
まず、基本ソフトウェア２０９は、タスクＴ１の起動をかけるため、タスクＴ１：ｓ（ｓｔａｒｔ）をＣＰＵ１０３の制御レジスタ２１５にセットする。ＣＰＵ１０３では、タスクＴ１の実行に入り、それが終了すると、タスクＴ１；ｅを状態レジスタＳＲ２０８にセットする。この値はタスク状態として、タスクマネージャ２１０によって監視される。次のフレームのタスクＴ１の起動は、前フレームのタスクＴ１の終了以前に行われるが、前フレームのタスクＴ１の終了通知が、次のフレームのタスクＴ１の起動条件になっているため、タスクＴ１：ｅが終了してから、次のタスクＴ１が起動される（３１１，３１０）。タスク起動３１１を契機に、タスクＴ１のウェイトが解除され、次のタスクＴ１が起動される（３１０）。タスクＴ２やＴ３の起動と終了も同様である。上記のタスクの起動条件は、後に詳述するように、ＯＳのテーブルに記載されている。
【００５９】
次に、アプリケーションソフトウェアの実行計画と計画見直しが行われる場合について説明する。
【００６０】
図７及び図８には、アプリケーションソフトウェアの実行計画の一例が示される。
【００６１】
図７及び図８において、横軸はタスクのチェックポイントを示し、縦軸は時間を示している。縦軸の右に１ｆｌａｍｅなどとあるのは、フレームの番号を示す。リアルタイム制約はフレームごとに定められており、１フレームあたり約２０ｍｓの実行時間が予算とされ、この制約を遵守するため、中間ポイントもチェックされる。楕円は、タスクのチェックポイントでの守るべき時間の上限を示している。例えば、１フレーム（１ｆｌａｍｅ）目のチェックポイントＴ２／３（ｃｈｃｋ）−ｅでは、約１０ｍｓ以前にタスク実行を終了しなけれならない。チェックポイントとして、Ｔ１-e、Ｔ２-s,Ｔ３−ｓ，Ｔ２−ｅ，Ｔ３−ｅのほか、Ｔ２（ｃｈｃｋ）−ｅとＴ３（ｃｈｃｋ）−ｅのタスク実行の中間のチェックポイントも定めている。これにより、タスクの予算未達を早期に監視できるようにする。尚、このチェックポイントについては後に詳述する。
【００６２】
図７に示されるように、実行時間の予算内にタスクの実行時間が収まれば特に問題は無い。しかし、次に述べるように実行予算を超えたときには、レギュラー状態８００からイレギュラー状態８０１への遷移が起こる。
【００６３】
図８において、菱形８１は、２フレーム目のタスクＴ２の実行状態が、タスクＴ２（ｃｈｃｋ）−ｅの段階で、予算を超えていることを示している。これを無視して当初の予定通り実行し続けると、２フレーム目のＴ２の終了が、３フレーム目のタスクＴ２のスタートと同等の時間になる。タスクＴ２のスタートは前フレームのタスクＴ２の終了が条件であるため、３フレーム目のタスクＴ２のスタートが遅れる可能性が高くなる。この状態を回避するため、イレギュラー状態８０１により新たな実行計画の検討が必要とされる。
【００６４】
図９には、イレギュラー状態８０１による新たな実行計画が示される。図９において、３フレーム目のタスクＴ２の新たな実行計画が星印で示される。タスクＴ３については、レギュラー状態８００のとき（図８参照）と変わらない。星印の新たななＴ２の実行計画は、図８におけるＴ２の実行計画の１／２の実行時間で処理する必要があり、これを実現するのが、以下に詳述するイレギュラー状態のタスクと、このタスクへのリスケジューリングである。
【００６５】
図１０には、タスクＴ２の処理であるオーディオデコーダ２２４を構成する処理のデータの流れが示される。
【００６６】
第１処理（ＢＤｅｃ＆ＥｒＤ）６０３では、入力データ２０６のエラーチェックが行われ、その後、フレームデータを周波数帯域ごとの複数のサブバンドというデータに分解される。その後、第２処理６００では、サブバンド毎に、サイドインフォーメンションという情報が取得され（ＧｅｔＳＴ）、この情報に基づいて量子化処理（ＤＱ）が行われる。そして、第３処理６０１では、サブバンドごとのデコード結果が合成され（ＣＳ）、フィルタバンク処理（ＦＢ）が行われる。
【００６７】
デコーダ２２４を実現するイレギュラー状態のタスクは、第２処理６００がサブバンド毎に行われるため、二つのプロセッサエレメント、例えばＣＰＵ１０３とＤＳＰ１０４とで並列に実行される。
【００６８】
図１１には、図１０における各処理の割当先とされるプロセッサエレメントが示される。
【００６９】
図１１に示されるように、上記第１処理６０３はｔ２１タスクとして、ＣＰＵ１０３に割り当てる。第２処理６００は、サブバンドが例えば１：２の割合で、ＣＰＵ１０３とＤＳＰ１０４とに割り振られ、ＣＰＵ１０３ではタスクｔ２２１として実行され（６００１）、ＤＳＰ１０４ではタスクｔ２２２として実行される（６００２）。最後に、第３処理６０１は、ＤＳＰ１０４において、タスクｔ２３として実行される。
【００７０】
図１２には、図９において、２フレーム目のＴ２ｃｈｃ−ｅのときに予算を超えていることが判明し、イレギュラー状態への遷移するときから、３フレーム目のＴ２のイレギュラータスクが予算内に終了して、レギュラー状態Ｔ２へ再び復帰するまでのタスク制御が示される。
【００７１】
図１２において、それぞれタスクＴ２ｉ１−１とＴ２ｉ１−２とを含むタスクＴ２ｉ１，Ｔ２ｉ２，Ｔ２ｉ３は、各プロセッサエレメントで処理するサブタスクとデータ転送のサブタスクとを含む。図１２では、ＤＳＰ１０４でタスクＴ２の実行が終了され、状態レジスタ２０８にタスクＴ２ｃｈｃ：ｅがセットされると、タスクマネージャタスクマネージャ２１０は上限予算を超えているため、図８において４００で示される場合の終了予想を行い、３フレーム目の予算遵守も危ういと判断する。そこでタスクマネージャ２１０は、イレギュラー状態８０１への移を決定し、基本ソフトウェア２０９のＯＳに対して、３フレーム目のタスクＴ２の休止と、このタスクＴ２のイレギュラータスクＴ２ｉ１の発行を指示する(Ｔｒ  ｔｏ  ＩＲ)。
【００７２】
これを受けてＯＳは、イレギュラータスクＴ２ｉ１：ｓをＣＰＵ１０４の制御レジスタ２１５にセットし、ＣＰＵ１０４でタスクＴ２ｉ１の実行を開始する。タスクＴ２ｉ１の前半部であるＴ２ｉ１−１の実行が終了すると、タスクＴ２ｉ１−１：ｅをタスクの状態レジスタ２０８にセットする。タスクＴ２ｉ１−１の終了とＴ２の終了（Ｔ２：ｅ）により、ＯＳはタスクＴ２ｉ２：ｓをＤＳＰの制御レジスタ２１３にセットし、それによりタスクＴ２ｉ２の実行が開始される。その後、タスクＴ２ｉ１−２の実行が終了すると、タスクＴ２ｉ１−２：ｅがタスクの状態レジスタ２０８にセットされ、これを受けて、ＯＳはタスクＴ２ｉ３：sをＤＳＰの制御レジスタ２１３にセットし、それによりタスクＴ２ｉ３の実行が開始される。最後に、タスクマネージャ２１０は、タスクＴ２ｉ３の終了通知（Ｔ２ｉ３：ｅ）を受けて、３フレームでの予算遵守を確認し、レギュラー状態８００への遷移を行う（Ｔｒ  ｔｏ  Ｒ）。具体的には、タスクＴ２ｉ１の休止と、タスクＴ２の再発行である。
【００７３】
次に、図２に示されるタスクマネージャ２１０での具体的な処理について、図１３及び図１４に基づいて説明する。
【００７４】
タスクマネージャ２１０は、レギュラー状態８００で、実行中のタスクからタスクの状態の通知を受け（８１０）、当初の実行計画（図７参照）通りにタスクが実行されているか否かをチェックする。この処理は、図９における処理９００に対応する。チェックポイントは、図７に示されるタスクスタートＴ２／３−ｓ，中間チェックポイントＴ２／３（ｃｈｃｋ）−ｅ，タスクエンドＴ２／３−ｅであるが、このチェックポイントは、状態レジスタ２０８のビット１０１０によって種々の設定可能とされる。図１３におけるデータライン８０５は、この情報をタスクマネージャ２１０に通知することを示している。
【００７５】
図１４に示されるように、タスクマネージャ２１０では、第１処理９００と第２処理９０１とが行われる。
【００７６】
第１処理９００では、先ず、ＳＲ２０８に基づいて、現在の状態が、スタートか、エンドか、チェックポイントかが判断される（９０２）。そしてこのポイントでのスタートからの経過時間が上限予算を超過しているか否かの判別が行われる（９０３）。チェックポイントは、チェックポイントテーブル８１３に記載されており、例えばタスクＴ２では、ｔ２ｆｈが終了した時点（第２処理６００が終了した時点に相当）を中間チェックポイントとして、タスクＴ２の実行開始からの上限予算は８ｍｓｅｃである。図８に示される例では、この上限予算を超えて２０ｍｓｅｃに達しており、このままタスクを実行すると、次のフレームの予算達成も危うい状態となる。
【００７７】
そこで、図１４に示される第２処理９０１において、イレギュラー状態８０１のタスクの実行を検討する。このとき、イレギュラータスクは、タスク優先度テーブル８０８で、タスクの優先順位が第２位のタスクで表現されている。イレギュラー状態が二つある可能性があるためである。本例では、オーディオ処理２１９を実現するための優先順位第１位は、レギュラータスクＴ２とされ、優先順位第２位は、図１２で述べたタスクＴ２ｉ１−１，Ｔ２ｉ１−２，Ｔ２ｉ２，Ｔ２ｉ３のグループとされる。
【００７８】
第２処理９０１では、イレギュラー状態８０１の決定処理９０５と、イレギュラー状態８０１への遷移処理９０６を含む。
【００７９】
処理９０５では、先ず、図９において星印９１で示されるタスク実行予算の再立案を行う。この処理においては、自由度を持たせ過ぎて、この予算立案が、タスクスケジュールに破綻をきたさないように注意を要する。本例では、タスクＴ２の中間チェックポイントで破綻をきたしているときには、図９に示されるように、次のフレームを予算内に納める計画を立てる。そして、タスク管理テーブル８０９を参照して、イレギュラー状態用の新たなタスク管理テーブル９０４を生成する。
【００８０】
具体的には、優先順位第２位のタスク群を候補として、図９の計画を達成するには、これらのタスク群の新たな予算Ｔ−Ｂｕをいくらにすればよいかを計算し、新たな予算を実現できるタスクの候補をタスク優先度テーブル８０８から探し、候補となるタスクの周波数などのハードウェアパラメータの変更を検討する。
【００８１】
先ず、図２３に示されるように、現在のチェックポイントである（Ｔ−ＩＤ，ＳＴ−ＩＤ）＝（２，２）の予算が８ｍｓｅｃ（＝８０００μｓｅｃ）で、（Ｔ−ＩＤ）＝１のタスク予算５ｍｓｅｃと合わせると、２フレームでは予算は１３ｍｓｅｃである。しかし、現時点で２０ｍｓｅｃ経過しているため、オーバタイムは７ｍｓｅｃとなる。遅れを生じているＴ−ＩＤ＝２（Ｔ２）のタスクの予算は１５ｍｓｅｃであるため、次の３フレームではオーバタイム７ｍｓｅｃを取り戻すため、このタスクの実行を８ｍｓｅｃで終了させる必要があり、これがタスクＴ２の新たな予算となる。
【００８２】
次に、タスクＴ２の新たな予算の実現性について検討する。
【００８３】
この予算は、現在実行中のＴＡ−Ｐｒ＝１のタスクＴ２では困難であるが、ＴＡ−Ｐｒ＝２のタスク群では実現の可能性がある。このことは、図２５に示されるタスク優先度テーブル８０８のＴ−ＢｕのＭｉｎ（最小値）が、ＴＡ−Ｐｒ＝１のタスクでは１０ｍｓｅｃで予算８ｍｓｅｃより大きく、ＴＡ−Ｐｒ＝２のタスクでは６ｍｓｅｃで予算８ｍｓｅｃより小さいことから理解できる。
【００８４】
次に、ＴＡ−Ｐｒ＝２のタスクの周波数のパラメータを決定する。このパラメータ決定は、タスク優先度テーブル８０８を用いた概略決定と、タスク管理テーブル８０９とハードウェア動作モデル８１４を用いて決定結果の検証を含む。この手順を以下に示す。
【００８５】
先ず、タスク優先度テーブル８０８から、概略値を決定する。図２５のＰ−Ｍｏｄｌ（パラメータモデル）の項で、Ｐｒｏとあるのは、性能がプロセッサエレメントパラメータ（ＰＥ−Ｐａｒｍ）に比例することを示している。バスパラメータ（Ｂｕｓ−Ｐａｒｍ）は固定とされる。すなわち、処理時間はＰＥ−Ｐａｒｍに反比例する。そこで、ＴＡ−Ｐｒ＝２のＳｔｄのＴ−Ｂｕが１１．５ｍｓｅｃ、ＰＥ−Ｐａｒｍが１００ＭＨｚの場合に、８ｍｓｅｃを実現するには、１４３．７５ＭＨｚ（＝１００ＭＨｚ×１１．５/８）となり、１０ＭＨｚ単位で切り上げると１５０ＭＨｚとなる。予算８ｍｓｅｃに対して、１０％程度の余裕を見て、７．２ｍｓｅｃの実現パラメータを求めることにすると、同様にして概略値は１６０ＭＨｚとなる。
【００８６】
次に、上記概略値１６０ＭＨｚが妥当か否かについて、図２０に示されるタスク管理テーブル８０９と、図１８に示されるハードウェア動作モデル８１４を用いて検証する。タスク管理テーブル８０９によれば、ＡＰ−ＩＤ＝２３１で、ＴＡ−Ｐｒ＝２のタスク群が対象となる。Ｈａｒｄ−ＩＤの欄は、ハードウェア動作モデル８１４でどのハードリソースを利用するかを示す番号である。図１８には、タスク優先度テーブル８０８のＰ−Ｍｏｄｌと同様に、パラメータに対する性能特性がハード毎に記載されている。図１８において、Ｆｉｘのハードであるバスを利用するタスク以外は、ＰＥのパラメータを利用する。Ｆｉｘのハードはそのままで、Ｐｒｏのパラメータは１６０ＭＨｚにし、図２０のＴ−Ｅｖを周波数に反比例させて、ＴＡ−Ｐｒ＝２のタスク群のみについて得た結果が、図２１に示される。図２１において、Ｐａｒａの欄は、同一のタスク内で並列処理するタスクであり、並列Ｐ１の１番目と２番目という意味でＰ１−１とＰ１−２とある。これらの並列処理は、どちらか大きいほうの処理時間をとり、並列処理以外は、全て処理時間を足し合わせると、７，０２５μｓｅｃ（＝７．０２５ｍｓｅｃ）となり、Ｔ−Ｂｕの８ｍｓｅｃから１０％余裕を持った７．２ｍｓｅｃを下回るため、１６０ＭＨｚを新たなパラメータとする。図２１の結果は、イレギュラー状態８０１となるＡＰ−ＩＤ＝２３１の管理テーブルのみを示したが、イレギュラー状態８０１のＡＰ−ＩＤも含めて、構成した結果が、新たなタスク管理テーブル９０４となる。
【００８７】
イレギュラー状態８０１への遷移処理９０６では、ＯＳへのタスク生成が行われる。タスクは、予めＯＳに登録しておくが、ここでは、ＴＡ−Ｐｒ＝１のタスクＴ２の休止と、ＴＡ−Ｐｒ＝２のタスク群Ｔ２ｉ１−１かＴ２ｉ３を休止から待ち状態にする。さらに、Ｔ２ｉ１−１などのタスク群に対して、周波数を変更するためにメッセージボックスを通して、周波数の値を登録する必要がある。周波数のタスクへの受け渡し方法は、ＯＳの動作との関係で後述する。ＯＳへのタスク発行と休止の処理は、図１３において、８０２、８０３で示される。
【００８８】
タスクマネージャ２１０は、図９の計画が予定通り実現されると、イレギュラー状態８０１からレギュラー状態８００へ復帰する。図示はしていないが、この処理は、レギュラー状態８００からイレギュラー状態８０１へ遷移するときの逆である。図１４の判別処理９０３において予算遵守していることが判明した段階でタスク管理テーブルを、９０４からタスク管理テーブル８０９に復帰し、現在実行中のイレギュラータスクを休止し、レギュラータスクを待ち状態に復帰する。復帰のタイミングは、イレギュラー状態への復帰と同様に早めに行う。図７では、３フレーム目のチェックポイントが予定とおりであることを確認して、４フレーム目に復帰する。
【００８９】
次に、タスクマネージャ動作を実現するレジスタとタスク管理テーブルについて説明する。
【００９０】
上記の処理を実現するためのレジスタとタスク管理テーブル、及びタスクの優先順位を示すテーブルについて説明する。
【００９１】
図１５には、各プロセッサエレメントの制御レジスタＣＲ２１３，２１４，２１５のフォーマット例が示される。
【００９２】
１０００はタスクの起動を指令するための領域で、Ｔ−ＩＤ１００２は起動するタスクのＩＤを示し、Ｓｔａｒｔ１００３は、起動をかけるとき論理値‘１’を設定する。Ｔ−ＩＤの値は後述する。１００１は、プロセッサエレメントのハードウェアパラメータの変更を指令するための領域で、Ｃｈｇ１００６に論理値‘１’が立っていれば変更を指令し、変更する周波数の値をＦ１００４に、電圧の値をＶ１００５に設定する。Ｆ１００４はＭＨｚを単位とし、Ｖ１００５は０．１Ｖを単位とする。本例では、周波数の変更のみ記載したが、一般には電圧の変更も可能性はある。
【００９３】
図１６には、タスクマネージャ２１０に各プロセッサエレメントのタスクとハードウェアパラメータの状態を通知するためのマスタプロセッサとされるＣＰＵ１０３上の状態レジスタＳＲ２０８のフォーマットが示される。
【００９４】
１０１０は現フレームのタスクの状態を示し、１０１１は並列実行している前フレームのタスクの状態を示す。後述するように、タスクの起動条件には、前フレームのタスクの状態も必要であるので、前フレームの状態も設定可能としている。１０１２は、各プロセッサエレメントの現在のハードウェアパラメータの値を示す。意味は、制御レジスタと同様である。
【００９５】
１０１０において、Ｔ−ＩＤ１０１３はタスクのＩＤを示し、ＳＴ−ＩＤ１０１４はタスクの途中経過を示すためのＩＤを示す。タスクの実行開始により論理値‘０’が設定される。チェックポイントとなるサブタスクは、ユーザがチェックポイントテーブル８１３にて設定する。１０１２において、Ｆ０ととＶ０は、ＣＰＵ１０３の現在の周波数と電圧を示す。Ｆ１とＶ１はＤＳＰ１０４の、Ｆ２とＶ２はＤＲＰ１０５の動作周波数と電圧を示す。単位はＣＲのＦとＶと同一である。
【００９６】
次に、タスクやサブタスクのノーテーションとして、ＩＤの定義について図１７に基づいて説明する。
【００９７】
図１７において、ＡＰ−ＩＤは、アプリケーションソフトウェアとの対応として図３と図１０の符号に対応する。このアプリケーションソフトウェアを実現するタスクが、Ｔ１，Ｔ２，Ｔ３，Ｔ２ｉ１，Ｔ２ｉ２，Ｔ２ｉ３である。この他、アプリケーションソフトウェアに対応しないタスクとして、タスクマネージャがある。アプリケーションソフトウェアに対応しないタスクはＡＰ−ＩＤを論理値‘０’とする。これらのタスクに対して、ＩＤとして図１７に示されるＴ−ＩＤを定義する。アプリケーションソフトウェアに関与するタスクは、さらにサブタスクに分かれる。例えばタスク（Ｔａｓｋ）Ｔ１は、サブタスクとして図３に示される入力データ２００に対応するサブタスクがある。サブタスクにも、ＩＤとして図１７に示されるＳＴ−ＩＤが定義される。
【００９８】
図１８には、利用ハードウェアを区分するためのＨａｒｄ−ＩＤが示される。
【００９９】
利用ハードウェアは、入力ハード→処理を実現するハード→出力ハードの表記方法を取っている。例えば、Ｈａｒｄ−ＩＤ１８１０の利用ハードウェアは、ＣＰＵ１０３上でのアプリケーションソフトウェア処理を意味し、ＣＰＵ１０３のローカルメモリ２１８からデータを入力し、ＣＰＵ１０３上で処理し、結果をローカルメモリ２１８に出力することを意味している。
【０１００】
処理の内容には、アプリケーションソフトウェア処理とデータ転送処理とが含まれる。前者は、Ｈａｒｄ−ＩＤが１８１０から１８１１までのプロセッサエレメント内の処理となり、後者はバスを介した処理となる。後者には、アプリケーションソフトウェアの初期に共有メモリ１０２からデータを入力する「アプリケーションソフトウェア初期のＰＥ（プロセッサエレメント）への入力」、アプリケーションソフトウェアの最後に共有メモリ１０２へデータを出力する「アプリケーションソフトウェア最後のＰＥからの出力」、「同一ＰＥ間のデータ転送」、及び「異なるＰＥ間のデータ転送」がある。本例では「同一ＰＥ間でのデータ転送は共有メモリ１０２が各プロセッサエレメントに一つしかなく、転送は起こり得ないため、該当無しとなる。
【０１０１】
図１８に示されるＨａｒｄ−ＩＤに対応するハードウェアの特性に対するパラメータ依存を規定するのが、ハードウェア動作モデル８１４の目的とされる。本例では、ハード特性としてレイテンシ、パラメータとして周波数のみを取り上げている。Ｂ−Ｐａｒｍは基本となるＭＨｚ単位の周波数である。これに対して、Ｐ−Ｍｄｌは、性能の周波数依存を示す。Ｐｒｏは、性能が周波数に比例することを意味し、Ｆｉｘは周波数を固定して扱う。性能はレイテンシの逆数を意味しており、Ｐｒｏはレイテンシが周波数に反比例することを意味する。本例では、非常に簡単なモデルを想定しているが、この枠組みを拡張して、さらに高度なモデルを定義することも可能となる。
【０１０２】
図１９には、バス１０１の性能限界が示される。
【０１０３】
バス１０１のデータ転送が最大３．２Ｇｂｐｓとされる。プロセッサエレメント内の性能限界は、処理内容に強く依存するため、タスクと独立には記載できない。このため、ハードウェア動作モデル８１４では対象外とする。
【０１０４】
次に、図２０及び図２１に基づいて、タスク管理テーブル８０９，９０４について詳述する。
【０１０５】
図２０には、アプリケーションソフトウェアに関連する標準ハードウェアパラメータを用いたタスク管理テーブル８０９が示され、図２１には、イレギュラー状態のためのタスク管理テーブル９０４のうち、ハードウェアパラメータを変更した部分のみが示される。
【０１０６】
図２０において、ＡＰ−ＩＤ，Ｔ−ＩＤ，ＳＴ−ＩＤ、Ｈａｒｄ−ＩＤは、図１７と図１８で述べた表記方法に従い、アプリケーションソフトウェアの処理部分、タスク、サブタスク、利用ハードウェアを示している。例えば、ＡＰ−ＩＤ２３０に対応して、Ｔ−ＩＤが１のタスクＴ１があり、このタスクはＳＴ−ＩＤが１から５までのサブタスクからなる。ＳＴ−ＩＤが論理値‘１’のサブタスクｄｔ１１は、Ｈａｒｄ−ＩＤ１８１３のハードウェア（共有メモリ１０２→バス１０１→２１８）を利用する。
【０１０７】
ＡＰ−ＩＤが２３１の処理を実行するタスク群には２種類あり、ＴＡ−Ｐｒにより優先順位を定めている。優先順位１位のタスクはＴ−ＩＤ＝２で、優先順位２位のタスクは、Ｔ−ＩＤが４，５，６の組合せである。
【０１０８】
Ｐａｒａの項は、Ｔ−ＩＤ内で並列処理をするサブタスク群を示し、Ｐ１−１とＰ１−２は、並列処理１の１番目と２番目の処理であることを示す。
【０１０９】
サブタスクの各々に対応して、標準的なパラメータＰａｒｍ、Ｐａｒｍによるサブタスクの評価結果Ｔ−Ｅｖが示される。ＰａｒｍはＭＨｚ単位の周波数を示し、Ｔ−Ｅｖは１μｓｅｃ単位の処理時間を示す。さらに、図７の実行計画を達成するためのアプリケーションソフトウェアの制約によって決定されるＡＰ−ＩＤ毎のタスク群の予算Ｔ−Ｂｕがμｓｅｃ単位で示される。
【０１１０】
タスクマネージャ２１０は、上記構成のタスク管理テーブルを用いて、図１４に示される第２処理９０１において、タスク実行予算の再立案とイレギュラー状態の決定を行う。優先順位第１位のＴ−ＩＤ＝２のタスクが破綻をきたしたときに、優先順位第２位のタスク群Ｔ−ＩＤ＝４〜６の処理に期待する予算を計算し、予算内で実現するには、周波数Ｐａｒｍをどう変更させると実現するかを検討する。図２１に示される新たな管理テーブル９０４におけるＮ−ＰａｒｍとＮ−Ｔ−Ｅｖが、上記予算計算の結果である。多少のマージンをもたせたタスク予算がＮ−Ｔ−Ｂｕ８０００である。パラメータ変更したイレギュラー状態８０１では、図２１の新たなタスク管理テーブルを、図２０の変更のない部分をマージして実行状態の監視に用いられる。
【０１１１】
次に、タスクの実行状況を監視するためのテーブルチェックポイントテーブル８１３について、図２３に基づいて説明する。タスクの実行状況は、タスク管理テーブル８０９のＴ−Ｅｖに沿ってチェックして行けば良いが、チェックポイントが多いと、オーバヘッドが大きくなるため、ユーザがタスク管理テーブル８０９から最小限のチェックポイントを選択するようにする。
【０１１２】
図２３には、タスクチェックポイントテーブルの構成例が示される。タスク一つにつき、開始（Ｓｔａｒｔ）と終了（ｅｎｄ）は必須である。開始は、全てのタスク対象にＳＴ−ＩＤ＝０に設定される。終了は、タスク毎にＳＴ−ＩＤに設定する。その他、チェックのオーバヘッドが問題とならないタスクは、半分程度の経過時間で終了するサブタスクのＩＤをＳＴ−ＩＤとして登録し、このサブタスクの終了時をチェックポイントとする。図２３では、タスクＴ２とタスクＴ２ｉ１の中間チェックポイントが示される。タスクの実行開始からの予算を超えると、タスクマネージャ２１０はイレギュラー状態８０１の遷移を検討する。
【０１１３】
図２２には、ＯＳによって参照されるＯＳ用タスク管理テーブルが示される。このテーブル１７０６は、タスクマネージャ２１０によって利用されない。ＯＳに依存して実装方法が異なるため、ここではＯＳのタスク管理に必要な情報を記載している。このテーブルはＯＳ依存性を持つシステム制御プログラムを生成するための入力にもなり得る。ＯＳ用タスク管理テーブル１７０６は、タスクＩＤ（Ｔ−ＩＤ）毎に起動条件、及び起動処理が定義される。上記起動条件には、Ｔ−ＩＤ毎の事象、状態レジスタ（ＳＲ）２０８の設定情報値が定義されている（図１６参照）。上記Ｔ−ＩＤの各々に対応して、起動条件を判断して、ＯＳはタスクの起動処理を行う。例えば、Ｔ−ＩＤ＝１、すなわちＴ１の起動条件は、アプリケーションソフトウェアのＳｔａｒｔ時点か、前フレームのｔ１１，即ちＰｔ１１がｅｎｄとなる時点である。これを状態レジスタＳＲ２０８で表現すると、開始（Ｓｔａｒｔ）は、（Ｔ−ＩＤ，Ｓｉｔｕ，ＰＴ−ＩＤ，Ｓｉｔｕ）＝（０，０，０，０）で表現でき、Ｐｔ１１がｅｎｄは、（＊，＊，１，１）となる。ここで＊は、論理不定を示す。これらの条件が満たされたときに、ＣＰＵの制御レジスタ２１５を（Ｔ−ＩＤ，Ｓｔａｒｔ）＝（１，１）に設定することにより、Ｔ１の起動を指令する。他のタスクの起動も、同様にして、起動条件に従い、タスクの起動処理を行う。
【０１１４】
上記のタスク起動の処理は、実装依存であるが、一例をあげれば、以下のようにして実施できる。状態レジスタ（ＳＲ）２０８が変化を受けたら割り込みを発生し、割り込みルーチン内で起動条件を判定し、起動条件が整ったことをイベントフラグでＯＳに通知し、ＯＳはイベントフラグを見て“起動処理”に相当するマスタ上のタスクを起動する。
【０１１５】
このとき、イレギュラー状態の遷移に伴うハードウェアパラメータの変更は、上記の割り込み処理内で、これから起動するタスクに依存して、ＳＲ２０８内の現在のパラメータと、タスク管理テーブル８０９と９０４を見比べ、パラメータ変更の必要性とハードウェアパラメータを判定して、メッセージボックスに制御レジスタの領域１００１の値を入れておく。メッセージボックスの内容は、全タスクによって参照され、その結果、動的に変更する制御レジスタの領域１００１の値も設定可能とされる。
【０１１６】
図２５には、タスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８の構成例が示される。
【０１１７】
タスク優先度テーブル８０８は、同一処理を実現する複数のタスクがあるときに、優先順位を設定し、同時に後で優先順位を設定した理由付けを定性的に与えることができる。リスケジューリングを行うときのために、要求変更への採否とタスクのパラメータを決定可能なように、タスクのパラメータ限界と性能レンジも設定される。
【０１１８】
タスク優先度テーブル８０８において、優先順位を決定する定性的な要因は、性能Ｐｅｒ．と安定性Ｓｔａｂ．である。他にも電力など他の要因も考え得る。Ｐｅｒ．は、同一周波数でのスループットの優劣を示し、安定性は、バス競合やＯＳのオーバヘッドなど動的な不確定要素が少なく性能が安定して得られる度合いの優劣を示している。このケースでは、ＴＡ−Ｐｒが１のタスク選択は、同一周波数に対しての性能は低いが（Ｐｅｒ．＝２）、動的な不確定要素が少なく安定性では優れる（Ｓｔａｂ．＝１）を示している。この例では、ＴＡ−Ｐｒが１のタスクＴ２は並列処理はないためバス競合やＯＳの不確定要素は少ないが、一つのＰＥで処理するので同一周波数に対する性能は、並列処理タスクよりも低い。一方、ＴＡ−Ｐｒが２のタスク群Ｔ２ｉ１−１からＴ２ｉ３までは、複数のＰＥで並列処理されるので、タスクＴ２と逆に不確定要素は多いが、同一周波数に対する性能は高い。
【０１１９】
定量的な数字は、ＰＥ−Ｐａｒｍ、Ｂｕｓ−Ｐａｒｍ、及びＴ−Ｂｕに示す。ＰＥ−ＰａｒｍとＢｕｓ−Ｐａｒｍは、最小値Ｍｉｎと最大値ＭａｘをＭＨｚ単位で設定する。図２５では、Ｂｕｓ−Ｐａｒｍは固定として、ＰＥ−Ｐａｒｍのみを変化させる仕様としている。最小の周波数ＰＥ−Ｐａｒｍに対して最大の処理時間Ｔ−Ｂｕが決まり、最大の周波数に対して最小の処理時間が決まる。Ｔ−Ｂｕの最大値は、アプリケーションソフトウェアの要求から決まるリアルタイム制約の値を示し、最小値（性能最大）は、電力予算を遵守するために、これ以上性能を上げれないという限界を示している。標準値ＳＴｄ．は、最小値と最大値の間に納まり、ユーザが周波数を標準に定めるなどして決定する。優先順位１位の標準値は、アプリケーションソフトウェア要求のリアルタイム制約とになり、標準に実行するレギュラー状態のタスクの予算とパラメータの値を示す。
【０１２０】
上記の最小値と最大値から、予算を要求されたときに大凡のパラメータが求められるように、Ｐ−Ｍｏｄｌを設定する。これは、Ｔ−Ｂｕの大凡のパラメータ依存を示す。図２６において「Ｐｒｏ．」とあるのは、性能がパラメータに比例することを示している。すなわち、処理時間がパラメータに反比例する。
【０１２１】
次に、システム動作前のタスクスケジューリング用のコンパイラについて説明する。
【０１２２】
図２４には、図２０に示されるタスク管理テーブル８０９を生成するコンパイラ（ＴＡ−ＳＣＤ）１７０３と、その後、図２２に示されるＯＳ用タスク管理テーブル１７０６、図２３のチェックポイントテーブル８１３、図２２の“起動処理”に相当するタスク起動Ｐｇ.１７１２を作成する手順、及びＯＳを制御するシステム制御プログラム１７０４の作成手順が示される。
【０１２３】
コンパイラ（ＴＡ−ＳＣＤ）１７０３には、ハードウェアにより決まるハードウェア動作モデル８１４、アプリケーションソフトウェアのモジュール情報のみを示すＭＤＬ−ＦＬ１７００、アプリケーションソフトウェアの要求とタスクを決定するための情報１７０２、及び電量予算（Ｐ−Ｂｕ）１７２０が参照される。ハードウェア動作モデル８１４は、図１８に示されるハードウェア特性情報である。
【０１２４】
ＭＤＬ−ＦＬ１７００はモジュールテーブルとされ、このテーブルには、タスクを組み上げて行く場合の基本になるアプリケーションソフトウェアの処理モジュールの情報が含まれる。この情報に基づいて、コンパイラ１７０３では、タスクの組み上げの処理時間が大きくならないように、また、あまり細分化しすぎないように複数の処理モジュールに分割される。このとき、同一の処理でデータを並列化して処理できるモジュールは、その旨指定しておく。さらに、タスク分割の補助情報として、処理モジュールの入出力のデータ転送量とデータ転送先のモジュールの指定も付加する。
【０１２５】
アプリケーションソフトウェアの要求とタスクを決定するための情報１７０２は、処理モジュールからタスクとなる候補をタスク管理テーブル９０４の初期入力として与える情報１７０１、及びアプリケーションソフトウェアの要求とタスクの特性を見て、タスクの優先順位を与えるタスク優先度テーブル８０８の情報を含む。
【０１２６】
タスク管理テーブルの初期入力として与える情報１７０１は、ＭＤＬ−ＦＬ１７００で指定した処理モジュールを統合したサブタスクの候補を利用するハードウェアＩＤ（Ｈａｒｄ−ＩＤ）と共に指定し、同時に、周波数の標準パラメータＳ−Ｐａｒｍの候補も指定する。サブタスクを組み上げたタスクの候補も指定する。タスク管理テーブル８０９のサブタスクをさらに詳細に分割したモジュール単位で記載したテーブルである。
【０１２７】
タスク優先度テーブル８０８は、上記情報１７０１で同一処理を実現する複数のタスクがあるときに、優先順位を設定する。優先順位は、初期には定性的な選択基準で設定し、ＴＡ−ＳＣＤ１７０３の処理結果を見て、定量的な予算値を設定する。
【０１２８】
電量予算（Ｐ−Ｂｕ）１７２０は、ヘテロジニアスマルチプロセッサ全体の電力予算で最大値を示す。これは、タスク優先度テーブル８０８を人手指定するときに、周波数の上限を定めるのに利用する。ＴＡ−ＳＣＤ１７０３の内部では、タスクをあるＰＥで実行したときの電力計算を行い、電力予算内に収まるか否かを判断する制約として用いる。
【０１２９】
上記各種テーブル情報を用いて、ＴＡ−ＳＣＤ１７０３は、タスクのスケジューリングを行う。人手で設定されている候補に従い、リアルタイム遵守が可能か、データ転送はバスの最大レートを超えることはないかをチェックし、その結果１７０９と共に、評価結果Ｔ−Ｂｕを併せてとして出力する。この結果が所望の結果でなければ（ＮＧ１７１０）、矢印１７１０に沿って、人手で候補１７０１を変更することができる。
【０１３０】
ＴＡ−ＳＣＤ１７０３の処理結果に問題がなければ（ＯＫ１７１１）、決定したタスクの起動条件やチェック条件を検討して、ＯＳ用タスク管理テーブル１７０６、チェックポイントテーブル８１３、図２２に示されるタスクＩＤ毎の起動処理に相当するマスタＯＳ上でのタスクに相当するＰＥタスクの起動Ｐｇ.１７１２、及び図１４に示されるタスクマネージャ２１０の作成が行われる。
【０１３１】
そして、システム制御プログラム１７０４が作成される。入力としてＯＳ用タスク管理テーブル１７１３、マスタＯＳ上のタスクとなる１７１２、図２２に示される起動条件や周波数パラメータの設定を実現する、ＯＳ固有のイベントフラグやメッセージボックスのＡＰＩ１７０７を組み合わせて作成する。
【０１３２】
次に、本システム機器１００の出荷後、または異なるシステム機器に同一のアプリケーションソフトウェアを搭載する場合のアプリケーションソフトウェア要求に変更があった場合に、柔軟に対応するための具体的な構成について説明する。
【０１３３】
本例は、図１に示されるように、アプリケーションソフトウェア要求の変更に伴い、タスク優先度テーブル８０８の内容を変更し、その結果、タスク管理テーブル８０９とチェックポイントテーブル８１３も新たに再構築し、ＯＳが標準的に起動するタスクも変更する。
【０１３４】
この処理は、上記タスクマネージャ２１０での処理９０１（図１４参照）のモードを変更して実現する。尚、モードが異なるため、図２６では便宜上９０１２として区別する。
【０１３５】
新たなアプリケーションソフトウェアの要求として、２３１のオーディオデコーダ処理が９ｍｓｅｃのリアルタイム制約となったとする。この要求は、これまでの要求である図２５のＴ−ＢｕのＭａｘ値１５ｍｓｅｃを下回り、より高性能な要求である。さらに、図２５に示される、これまでの標準的なタスクＴ２のＴ−ＢｕのＭｉｎも下回っているため、このタスクでは実現不可能であり、Ｔ２ｉ１−１〜Ｔ２ｉ３のタスクを用いても、現在定められているＳｔｄ．のパラメータでは１１．５ｍｓｅｃのＴ−Ｂｕであるため、実行できない。
【０１３６】
そこで、図２７に示されるように、タスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８の内容を変更する。タスクＴ２は実行不可能であるため、ＴＡ−Ｐｒを０に設定し、Ｔ２ｉ１−１〜Ｔ２ｉ３のタスクをＴＡ−Ｐｒを１に設定する。ＴＡ−Ｐｒが１のＴ−ＢｕのＳｔｄを、アプリケーションソフトウェア要求である９ｍｓｅｃに設定し、これまでのＳｔｄを基に、反比例計算により、ＰＥ−Ｐａｒｍの値を１３０ＭＨｚに設定する。
【０１３７】
図２６に示される処理９０１２は、第１処理９０５２と第２処理９０６とを含む。
【０１３８】
上記第１処理９０５２では、新たなタスク優先度テーブル８０８を入力して、タスク管理テーブル８０９を参照してＴ−Ｂｕ９ｍｓｅｃの実現性を、仮に定めたＰＥ−Ｐａｒｍの正当性と共にチェックして、タスク管理テーブル８０９とタスク優先度テーブル８０８を見直す。さらに、チェックポイントテーブル８１３のデータもタスク優先度テーブル８０８から新たに導出する。この第１処理９０５２は処理５とほぼ同様な処理であるが、処理５がイレギュラー状態の決定であるのに対して、処理９０５２はレギュラー状態の設定であるため、タスク管理テーブル８０９とチェックポイントテーブル８１３に直接設定される。
【０１３９】
図２８には、タスク管理テーブル８０９の更新結果が示される。
【０１４０】
Ｔ−ＩＤ＝２のＴ２は実行不可であるためＴＡ−Ｐｒを０に設定し、Ｔ−ＩＤ＝４、５，６のタスク群はＴＡ−Ｐｒを論理値‘１’に設定する。タスクバジェット（Ｔ−Ｂｕ）は、タスク優先度テーブル８０８に従い、９０００μｓｅｃ（＝９ｍｓｅｃ）に設定される。バスパラメータ（Ｐａｒｍ）は、プロセッサエレメントが関連する（Ｔ−ＩＤ，ＳＴ−ＩＤ）＝（４，１）（４，３）（５，１）（６，１）のそれぞれに対して、タスク優先度テーブル８０８に従い１３０ＭＨｚに設定され、サブタスクの評価結果Ｔ−Ｅｖの値を計算する。この計算結果、並列性を考慮すると、Ｔ−ＩＤ＝４とＴ−ＩＤ＝６の値を加算した結果７６００がレイテンシとなり、この値に対して、予算９０００は１８％（９０００を７６００で割って計算）の余裕があり、十分な余裕と判断される。
【０１４１】
図２９は、テーブルチェックポイントテーブル８１３の更新結果が示される。チェックポイントは変更せず、チェックポイントでチェックするための予算値のみが見直されている。例えば、Ｔ−ＩＤ＝４のチェックポイント１の上限予算が、図２８の結果から（Ｔ−ＩＤ，ＳＴ−ＩＤ）＝（４，１）と（４，２）のＴ−Ｅｖの加算である１８００に少し余裕を持たせて設定する。図２９は、図２８の計算での余裕度１８％を考慮して、２１００と設定されている。
【０１４２】
以上から、タスク管理テーブル８０９とチェックポイントテーブル８１３とを設定でき、それはタスク優先度テーブル８０８の結果と矛盾しない。この点を目視でチェックし、問題なければ、イレギュラー状態８０１への遷移のための第２処理９０６により、タスク管理テーブル８０９の結果から旧タスクの削除と新タスクの登録を行う。この例では、タスクＴ２を休止し、タスクＴ２ｉ１−１〜Ｔ２ｉ３が実行状態にされる。
【０１４３】
上記の例によれば、以下の作用効果を得ることができる。
【０１４４】
（１）タスクマネージャ２１０は、各種テーブル群８０６に基づいてタスクリスケジューリングを行う。ここで上記各種テーブル群８０６には、ＲＳ８００は、タスクの終了や後述するチェックポイントの時点で、タスクマネージャ（ＴｓｋＭ）２１０に、現在のタスクの実行状態が通知される。通知を受けたタスクマネージャ２１０は、最初に定めたリアルタイム制約に基づく実行計画通りにアプリケーションソフトウェアが動作しているか否かをタスクチェックのためのチェックポイントテーブル（ＴＡ−ＣＨＣ）８１３に基づいてチェックし、それが良好なら何もしない。これに対して、実行計画の時間をオーバして動作中であれば、イレギュラー状態８０１への遷移を検討する。このとき、ＩＲＳ８０１のタスク選択にタスク優先度テーブル（ＴＡ−Ｐｒ−Ｔ）８０８が参照される。選択するタスクで実行計画の修正が可能か否かは、タスクの評価結果や予算、ハードウェアパラメータからなるタスク管理テーブル８０９が参照される。このとき、動作周波数などのハードウェアパラメータの見直しが、ハードウェア動作モデル（Ｈ−Ｍｏｄｌ）８１４を用いて行われる。計画修正を行った後、ＩＲＳ８０１のタスク実行を指示する（８０２）。ハードウェアパラメータの見直し指示も行われる。このようにタスクマネージャ２１０によって、アプリケーションソフトウェア実行時の動的なスケジューリングが行われる。
【０１４５】
（２）上記（１）の作用効果により、システム機器出荷後においてアプリケーションソフトウェアの要求が変更された場合や、アプリケーションソフトウェア要求が動的な要因で当初の予算通りに満たされなくなった場合でも、アプリケーションソフトウェア要求に柔軟に対応することができる。
【０１４６】
以上本発明者によってなされた発明を具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【０１４７】
以上の説明では主として本発明者によってなされた発明をその背景となった利用分野であるヘテロジニアスマルチプロセッサをカーナビゲーションシステムに適用した場合について説明したが、各種マルチプロセッサ及びその応用システムに広く適用することができる。
【０１４８】
本発明は、少なくとも、複数のプロセッサエレメントによってアプリケーションソフトウェアを実行することを条件に適用することができる。
【図面の簡単な説明】
【０１４９】
【図１】本発明に係る半導体集積回路の一例とされるヘテロジニアスマルチプロセッサを搭載して成るカーナビゲーションシステム機器における主要部の構成例ブロック図である。
【図２】上記ヘテロジニアスマルチプロセッサにおけるアプリケーションソフトウェア実行時の動的なスケジューリングの概要説明図である。
【図３】アプリケーションソフトウェアの一例とされるＭＰＥＧデコーダにおけるデータの流れの説明図である。
【図４】図３に示されるＭＰＥＧデコーダをヘテロジニアスマルチプロセッサで実現する場合の説明図である。
【図５】図４に示される構成のタスク制御のタイミング図である。
【図６】図４に示される構成のタスク制御のタイミング図である。
【図７】上記ＭＰＥＧデコーダにおける実行計画の説明図である。
【図８】上記ＭＰＥＧデコーダにおいてリアルタイム予算を超えたときの実行予想の説明図である。
【図９】上記ＭＰＥＧデコーダにおいて、ディオデコーダがリアルタイム予算を超えたときに、動的に定められる新たな実行計画の説明図である。
【図１０】上記ＭＰＥＧデコーダにおけるオーディオデコーダの内部処理の説明図である。
【図１１】図１０の処理を並列に実行するためのタスクのヘテロジニアスマルチプロセッサ上への割当の説明図である。
【図１２】上記ＭＰＥＧデコーダにおけるオーディオデコーダを並列に実行するときのタスク制御のタイミング図である。
【図１３】上記タスクマネージャにおける処理の説明図である。
【図１４】上記タスクマネージャにおける処理のフローチャートである。
【図１５】上記タスクを制御するための制御レジスタの構成例説明図である。
【図１６】上記タスクの状態を示す状態レジスタの構成例説明図である。
【図１７】上記タスクの定義とＩＤについての説明図である。
【図１８】上記タスクが利用するハードモデルの説明図である。
【図１９】上記ヘテロジニアスマルチプロセッサにおけるバスの性能限界の説明図である。
【図２０】上記ヘテロジニアスマルチプロセッサに含まれるタスク管理テーブルの説明図である。
【図２１】上記ヘテロジニアスマルチプロセッサにおけるイレギュラー状態用の新たなタスク管理テーブルの説明図である。
【図２２】上記ヘテロジニアスマルチプロセッサにおけるＯＳ用タスク管理テーブルの説明図である。
【図２３】上記ヘテロジニアスマルチプロセッサにおけるタスクのチェックポイントの説明図である。
【図２４】上記タスク管理テーブルを生成するコンパイラと、その他のテーブルやプログラムの作成手順のフローチャートである。
【図２５】上記ヘテロジニアスマルチプロセッサにおけるタスク優先度テーブルの説明図である。
【図２６】上記タスク優先度テーブルの変更に伴い、上記タスク管理テーブルなどを変更する処理のフローチャートである。
【図２７】上記ヘテロジニアスマルチプロセッサにおいて変更されたタスク優先度テーブルの説明図である。
【図２８】上記ヘテロジニアスマルチプロセッサにおいて変更されたタスク管理テーブルの説明図である。
【図２９】タスクチェックに用いられる情報の説明図である。
【符号の説明】
【０１５０】
１００  カーナビゲーションシステム機器
１０６  ヘテロジニアスマルチプロセッサ
１０３  ＣＰＵ
１０４  ＤＳＰ
１０５  ダイナミックリコンフィギュラブルプロセッサ
１０２  共有メモリ
１０１  共有バス
８０８  タスク優先度テーブル
８０９  タスク管理テーブル
２１０  タスクマネージャ
８００  レギュラー状態
８０１  イレギュラー状態
２２３  システム制御部
２２４  オーディオデコーダ
２２５  ビデオデコーダ
２０９  基本ソフトウェア
２１５  ＣＰＵの制御レジスタ
２１３  ＤＳＰの制御レジスタ
２１４  ＤＲＰの制御レジスタ
２０８  タスクの状態レジスタ
【図１】
2007133723.tif 000003
【図２】
2007133723.tif 000004
【図３】
2007133723.tif 000005
【図４】
2007133723.tif 000006
【図５】
2007133723.tif 000007
【図６】
2007133723.tif 000008
【図７】
2007133723.tif 000009
【図８】
2007133723.tif 000010
【図９】
2007133723.tif 000011
【図１０】
2007133723.tif 000012
【図１１】
2007133723.tif 000013
【図１２】
2007133723.tif 000014
【図１３】
2007133723.tif 000015
【図１４】
2007133723.tif 000016
【図１５】
2007133723.tif 000017
【図１６】
2007133723.tif 000018
【図１７】
2007133723.tif 000019
【図１８】
2007133723.tif 000020
【図１９】
2007133723.tif 000021
【図２０】
2007133723.tif 000022
【図２１】
2007133723.tif 000023
【図２２】
2007133723.tif 000024
【図２３】
2007133723.tif 000025
【図２４】
2007133723.tif 000026
【図２５】
2007133723.tif 000027
【図２６】
2007133723.tif 000028
【図２７】
2007133723.tif 000029
【図２８】
2007133723.tif 000030
【図２９】
2007133723.tif 000031