JP2009025939A - タスク制御方法及び半導体集積回路 - Google Patents

Abstract

【課題】タスク制御の対象とされるアプリケーションソフトウェアの適用範囲の制約を軽減する。
【解決手段】プロセッサ（１００，１０１）によってアプリケーションソフトウェアタスクが実行される場合において、アプリケーションソフトウェアタスクには予めチェックポイントが埋め込まれる。上記アプリケーションソフトウェアタスクの実行中に、上記チェックポイントを用いて、上記アプリケーションソフトウェアタスクの経過ポイントを問い合わせる。問合せた結果の現在の経過ポイントと経過ポイントに対応する経過予算から上記タスクの進捗状況を判断し、その判断結果に基づいて、タスクが利用する共有リソースを制御するとともに、新たな経過予算を設定する。これにより、タスク制御の対象とされるアプリケーションソフトウェアの適用範囲の制約が軽減される。
【選択図】図１

Description

本発明は、プロセッサによってアプリケーションソフトウェアタスクが実行される際のタスク制御技術に関する。

半導体集積回路は、微細化に伴うクロック周波数向上の限界や、電力増大により、処理の高速化と低電力化は、ますます困難となってきている。そこで、これまで実行前に静的に決定したハードやタスクの実行方法のみならず、動的に決まる要因まで考慮したより繊細なタスクやハードリソースの制御が注目されている。

その代表例として、特許文献１は、同一プログラムを繰り返し実行するタスクに対して、タスクの進捗状況を、プログラムの実行回数で判断する。すなわち、プログラムは予算時間Ｔを持ち、全部でＮ回繰り返されるとすると、Ｔ×Ｍ時間でＭ回実行されるはずである。この時、実際には、Ｍ回以下なら遅れており、Ｍ回以上なら進んでいると判断できる。遅れが顕著な時には、クロック周波数を上げ、進んでいるときにはクロック周波数を下げることができる。

特許文献１は、低電力化のための制御であるため、クロック周波数を下げる場合を想定して執筆されているが、遅れている場合に周波数をあげる方法も、本質的な差異はない。このように、従来の方法は、所定のプログラムを繰り返し実行する回数により、進捗状況を判断し、その判断結果により、クロック周波数や電圧を制御することにより、性能や電力を改善する。

特開２００２−２０２８９３号公報

上記の従来技術は、ある特定のプログラムが何回実行されたかで、進捗状況を判断するため、アプリケーションソフトウェアの適用範囲に制約がある。例えば実行時間が異なる複数のプログラムの組合せでタスクが構成されているときに、各プログラムごとに周波数を変更するような要望には対応できない。

画像圧縮プログラムは、離散コサイン変換、可変長符号化、量子化などのサブプログラムから成り、各々のサブプログラムは異なる実行時間を持つため、画像圧縮プログラム全体がＮ回繰り返される場合において、より素早い制御を行うためには、プログラム単位に進捗を監視して制御することが望ましい。

また、従来技術は、マルチプロセッサ上でのタスクを扱っていないため、プロセッサの共有リソースに対する制御は開示されていない。

さらに、制御の効率化という観点では、シングルプロセッサ上で行うべき制御と、共有リソースに対する制御を区分した方が、プロセッサの通信量を減らすことができ、オーバヘッドを削減することができるが、マルチプロセッサを対象としない従来技術では、この方法も提示されていない。

本発明の目的は、タスク制御の対象とされるアプリケーションソフトウェアの適用範囲の制約を軽減するための技術を提供することにある。

本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち代表的なものについて簡単に説明すれば下記のとおりである。

すなわち、プロセッサによってアプリケーションソフトウェアタスクが実行される場合において、アプリケーションソフトウェアタスクには予めチェックポイントが埋め込まれる。上記アプリケーションソフトウェアタスクの実行中に、上記チェックポイントを用いて、上記アプリケーションソフトウェアタスクの経過ポイントを問い合わせる。そして問合せた結果の現在の経過ポイントと経過ポイントに対応する経過予算から上記タスクの進捗状況を判断し、その判断結果に基づいて、タスクが利用する共有リソースを制御するとともに、新たな経過予算を設定する。これにより、アプリケーションソフトウェアの適用範囲に制約がなくなる。

本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記の通りである。

すなわち、タスク制御の対象とされるアプリケーションソフトウェアの適用範囲の制約を軽減することができる。

１．代表的な実施の形態
先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。

〔１〕本発明の代表的な実施の形態に係るタスク制御方法は、プロセッサ（１００，１０１）によってアプリケーションソフトウェアタスクが実行される場合において、アプリケーションソフトウェアタスクには予めチェックポイントが埋め込まれる。そして、上記アプリケーションソフトウェアタスクの実行中に、上記チェックポイントを用いて、上記アプリケーションソフトウェアタスクの経過ポイントを問い合わせる。問合せた結果の現在の経過ポイントと経過ポイントに対応する経過予算から上記タスクの進捗状況を判断し、その判断結果に基づいて、タスクが利用する共有リソースを制御するとともに、新たな経過予算を設定する。

〔２〕このとき、上記アプリケーションソフトウェアタスクへの問合せは、あるチェックポイントの経過予定時間が過ぎた時に行われ、上記問合の結果通知される情報には、現在経過しているチェックポイントと当該チェックポイントを経過した時間が含まれる。

〔３〕遅れの度合いが大きいタスクを制御するとき、所定プロセッサのみで利用するパラメータを制御する部分と、複数のプロセッサで利用する共有リソースを制御する部分とに分け、前者に対しては上記所定のプロセッサでタスク制御を行い、後者に対しては上記複数のプロセッサとは独立したモジュールで制御する。

〔４〕進捗状況の判断は、タスクが終了するまでの経過時間の予算値（７１０４）、現在経過したチェックポイントの経過時間の予算値（７１０６）、現在経過したチェックポイントの実際の経過時間（７１０５）を利用する。

〔５〕上記〔３〕において、上記所定プロセッサで行われるタスク制御は、タスクが終了するまでの経過時間の予算値、現在経過したチェックポイントの経過時間の予算値、現在経過したチェックポイントの実際の経過時間を、プロセッサ識別子とローカルリソースを制御した結果の新たなリソース情報と共に、共有リソースを制御するモジュールに転送することができる。

〔６〕上記〔３〕において、共有リソースのタスクまたはタスクを搭載するプロセッサの優先度を変更し、当該優先度は遅れの挽回がより困難なタスクまたはプロセッサの優先度を高くすることができる。

〔７〕上記〔３〕において、タスクが終了するまでの経過時間の予算値をＡとし、現在経過したチェックポイントの経過時間の予算値をＢとし、現在経過したチェックポイントの実際の経過時間をＣとするとき、遅れの挽回がより困難なタスクまたはプロセッサの優先度を高くする手段として、ＢのＡに対する割合が高く、ＣのＢに対する割合が高いタスクまたは当該タスクを搭載するプロセッサの優先度を高くすることができる。

〔８〕上記タスク制御方法を実現するタスク制御プログラムが格納されたメモリ（１０６）と、このメモリに格納されているタスク制御プログラムを実行可能なＣＰＵ（１００，１０１）とを含んで半導体集積回路を構成することができる。

２．実施の形態の説明
次に、実施の形態について更に詳述する。

＜マルチプロセッサシステムの構成＞
図１には、本発明にかかる半導体集積回路の一例とされるマルチプロセッサシステムが示される。図１に示されるマルチプロセッサシステムは、特に制限されないが、公知の半導体集積回路製造技術により単結晶シリコン基板などの一つの半導体基板に形成される。図１において、四角はハードウェア要素を示し、角が丸い四角はＯＳ（オペレーティングシステム）やタスクなどのソフトウェアを示す。

上記マルチプロセッサシステムには、特に制限されないが、二つの汎用プロセッサ（ＣＰＵ）１００，１０１、クロック生成回路（ＣＫＧＥＮ）１０２、共有リソース管理モジュール（ＣＲＭ）１０３、バスとその調停を行うバス調停回路（ＢＵＳ＿ＡＲＢ）１０４、プロセッサ間の共有メモリ（ＣＭ）１０５、ブート時にプロセッサにロードする各種ソフトウェアを格納するフラッシュメモリ（ＦＬＳＨ）１０６、リアルタイムオペレーティングシステム（ＲＴＯＳ）１１１，１１６の各種サービスコールの実行に用いる割り込みコントローラ（ＩｎｔＣ）１０７とタイマ（Ｔｉｍｅｒ）１０８が含まれる。尚、ＦＬＳＨ１０６には、本例におけるタスク制御方法を実現するタスク制御プログラムも格納される。

ＣＰＵ１００は、ローカルメモリ（ＬＭ）１０９及び優先度レジスタ（ＰＲｅｇ）１１０を内蔵する。上記ＬＭ１０９は、ＣＰＵ１００での処理の中間結果の格納に用いられる。上記ＰＲｅｇ１１０は、ＢＵＳ＿ＡＲＢ１０４へのアクセスの優先順位の格納に用いられる。

ＣＰＵ１００に搭載するソフトウェアは、ＲＴＯＳ１１１、ＣＰＵ１００にのみ関連するクロック周波数などのパラメータを制御するＬＲＣＬ１１２、及びアプリケーションタスク（ＡＰＰＬ）１１３から構成する。同様にして、ＣＰＵ１０１に搭載するソフトウェアは、ＲＴＯＳ１１６、ＬＲＣＬ１１７、及びＡＰＰＬ１１８である。

ＣＫＧＥＮ１０２は、マルチプロセッサ共通の基本クロックを水晶発信器から生成する基本クロック生成回路（ＢＣＫＧＥＮ）１２０と、基本クロックを元にクロックを分周して、各ＣＰＵごとのクロックを生成する分周波回路（ＣＫＤＩＶ）１１９を含んで成る。ＢＣＫＧＥＮ１２０は、ＣＲＭ１０３によりＢＵＳ＿ＡＲＢ１０４を通して制御される。ＣＫＤＩＶ１１９は、ＣＰＵ１００とＣＰＵ１０２により、各ＣＰＵの制御信号とクロック分配信号である、１１４と１１５を通して、またはＣＲＭ１０３によりＢＵＳ＿ＡＲＢ１０４を通して制御され、クロックを分配する。

ＣＲＭ１０３は、共有リソースコントローラ専用のＣＰＵであるＳＣＰＵ１２１、ＳＣＰＵ１２１上に搭載するＲＴＯＳ１２２と共有リソースコントローラ（ＣＲＣＬ）１２３から構成される。ＢＵＳ＿ＡＲＢ１０４は、後で述べるバスを利用する優先順位の設定がＣＲＭ１０３を通して実施できる。

＜マルチプロセッサシステムにおける制御の流れ＞
次に、図２及び図３を参照しながら、上記マルチプロセッサシステムにおける制御の流れを説明する。

図２の一番上のＣＰＵ１００の欄には、ローカルリソースコントローラＬＲＣＬの流れが示され、上から三番目のＣＲＭ１０３の欄には、共有リソースコントローラＣＲＣＬ１２３の流れが示される。

まず、ＬＲＣＬ１１２は、ＡＰＰＬ１１３のあるチェックポイントの予定経過時間に、実行状況を問い合わせ（２００）、現在経過したチェックポイントの通知を受ける（２０１）。

チェックポイント（ＣＰ）は、ＡＰＰＬ１１３に予め埋め込んであり、図３の３０３に示されるように、各ＣＰに対して、事前に予算、すなわち予定経過時間が定められている。ここで、ＳはＳｔａｒｔ、ＥはＥｎｄを表し、ＣＰの特殊な形である。例えば、図３において、ＣＰ２の予定経過時間は、３０１からΔｔ１＋Δｔ２３であることがわかる。この時間に実行状況を問い合わせると（２００）、ＣＰ１しか経過していないことが判明する（２０１）。すなわち、３００が現在の経過状況となる。この結果を受取り、ＬＲＣＬ１１２は、遅れの深刻さや、終了までの残り時間と残った処理量との対比から進捗状況を把握する（２０２）。

次に、上記進捗状況を受けて遅れを挽回するため、ＣＰＵ１００専用のローカルリソースを制御する（２０３）。例えば２０３ではＣＰＵ１００用のクロックを変更する。具体的には、図１の信号１１４を介して、ＣＫＧＥＮ１０２内のＣＫＤＩＶ１１９の分周比を変更して、ＣＰＵ１００用のクロック周波数を変更する。

一方、共有リソースを制御するために、進捗状況をＣＲＭ１０３に通知する（２０４）。

ＣＰＵ１０１での動作もＣＰＵ１００と同様である。ＣＲＭ１０３のＣＲＣＬ１２３は、ＣＰＵ１００とＣＰＵ１０１から進捗状況の通知を受けて（２０４，２０５）、共有リソースの制御を行う。基本クロックを変更する必要があるなら、２０６により、ＣＫＧＥＮ１０２を制御する。また、ＣＰＵ１００とＣＰＵ１０１の進捗状況を比較して、２０７により、遅れがより顕著なプロセッサの共有リソースの優先度を上げる。図１のブロック図では、共有リソースとして、ＢＵＳ＿ＡＲＢ１０４が該当するため、１０４に対して優先度変更の制御を行う。

図３の３０２は、ＬＲＣＬ１１２とＣＲＣＬ１２３の結果、設定された新たな経過時間の予算である。事前予算３０３を改訂して保持する。

＜アプリケーションのチェックポイント＞
次に、図４、図５、及び図６を参照しながら、アプリケーションに内蔵するチェックポイントの例と、３０３を登録する予算時間の登録テーブル、及びチェックポイント経過時の経過登録処理について説明する。経過登録処理は、２００と２０１を実施するために、アプリケーション側で行っておく必要がある。

図４において４００に示されるように、ＣＰの経過登録処理がチェックポイントである。この例では、ＣＰ０からＣＰ４までの五つのチェックポイントを設定している。ＣＰ０はスタートＳ、ＣＰ４はエンドＥを示す。

これらのチェックポイントに対しては、図５に示されるように、事前に予定経過時間を予定経過時間登録テーブル（ＥｌａｐｓｅｄＴｉｍｅ−ＢＴ５００）に登録しておく。図５において領域５０１には、ＣＰの数-1のＮを登録し、５０３にＣＰ０からＣＰＮまでの予定経過時間を登録しておく。５０２は、ＬＲＣＬ１１２で、実際に経過したＣＰにマーキングしておく領域である。最初は全ビット０であるが、経過したビットにフラグ“１”を立てる。図５では、５０２１がｎビットだとすると、ＣＰｎまで経過したことが示される。

次に、ＣＰｎの経過登録処理について説明する。

図６（ａ）には、経過登録テーブル（ＥｌａｐｓｅｄＴｉｍｅ−ＲＴ６００）が示される。図６（ｂ）には、ＣＰｎの経過登録処理流れが示される。

図６（ａ）における各領域の意味は、図５に示されるのとほぼ同一であり、６０３に登録するデータが、実際にＣＰｎを経過した時間である点のみが異なる。６０１は５０１と同じ意味、６０２は５０２と同じ意味である。図６（ｂ）の経過登録処理では、６０５で、６０２のｎビットである６０２１のビットにフラグ”１”をたて、６０３の領域のｎ番目の領域である６０３１に、経過時間を登録する。尚、経過時間はＴｉｍｅｒ１０８から時間の初期地点で０リセットしたあと、得ることができる。通常、Ｔｉｍｅｒ用ＡＰＩがＲＴＯＳで定めらており、このＡＰＩを通して時間を得る。

＜ローカルリソースコントローラ（ＬＲＣＬ）＞
ここでは、図７と図８に従い、ＬＲＣＬ１１２における処理の流れについて説明する。

ＬＲＣＬ１１２は、ＣＰＵが動作中は常時動作するタスクである。図７のフローは、管理するアプリケーションタスクが一つしかない想定であり、アプリケーションが複数存在するときには、この処理が複数回繰り返される。

まず、ステップ７００で経過時間を管理するテーブルと経過時間を初期化する。テーブルとしては、ＥｌａｐｓｅｄＴｉｍｅ−ＢＴ５００、及びＥｌａｐｓｅｄＴｉｍｅ−ＲＴ６００があり、事前に登録してある初期の予算テーブルＥｌａｐｓｅｄＴｉｍｅ−ＩＢＴが、上記の二つのテーブルにコピーされる。

次に、ステップ７０１でＡＰＰＬ１１３が起動される。

ステップ７０２以降が主要処理である。

ステップ７０２はループカウンタの判定で、ステップ７０３から７０７までが、あるチェックポイントＣＰｎにおける処理である。ステップ７０７でｎを１進めて、次のチェックポイントにおける処理を行い、ｎ＝０からＮまで繰り返す。尚、このループは、処理の経過の進みを示すが、これを同一処理の繰り返し回数とすると、ほぼ同様にして従来技術も実現できる。

ステップ７０３と７０４は、実行状況を問い合わせる準備処理である。ステップ７０３で、ＥｌａｐｓｅｄＴｉｍｅ−ＢＴ５００から、現在のＣＰn-1からＣＰｎまでの予定経過時間を取得し、ステップ７０４でこの経過時間の間スリープする。

ステップ７０５では、予定経過時刻になったため、ＥｌａｐｓｅｄＴｉｍｅ−ＲＴ６００から、現在ＡＰＰＬが実際に経過しているチェックポイントを取得する。この処理は、図２の２００と２０１に相当する。本例では、ＡＰＰＬが事前にチェックポイントを登録しているため、２００の問合せは６００の読み込みに相当し、２０１の通知は、６００からのデータ、経過したチェックポイントの取得に相当する。もちろん、２００と２０１を、ＯＳのサービスコールを使い、タスク間のメッセージ通信で、そのままの言葉通りに実現することもできる。

ステップ２０２では、現在経過したチェックポイントの予算経過時間、全ての処理が終了する予算時間から、遅れの度合いを判定する。本例では、図８の実際の経過時間７１０４の当初の予算時間７１０６に対する割合を遅れの度合いを判定する指標とする。

ステップ７０６では、２０２で判定した遅れの度合いが、所定のしきい値を超えると、新たな予算を設定し、２０３で、この新たな予算を実現するために、必要なローカルリソースの制御を実施する。本例では、ローカルリソースとして、ＣＰＵごとに設定できるローカルクロックのみを挙げており、上記のように、ＣＫＤＩＶ１１９でクロックの分周比を変更する。

ＣＰＵ１００からＣＲＭ１０３に、進捗状況とローカルクロックを、Ｐｒｏｇｒｅｓｓｉｎｇ−ＳＴ（Ｓｉｔｕａｔｉｏｎ Ｔａｂｌｅ）７１０を通して通知する（２０４）。

ここで、Ｐｒｏｇｒｅｓｓｉｎｇ−ＳＴ７１０について詳述する。

図８（ａ）において、７１０１から７１０３はローカルクロックに関する情報である。ＣＰＵ−ｉｄ７１００の古い分周比Ｏ＿ＣＤＩＶ７１０１と新しい分周比Ｎ＿ＣＤＩＶ７１０２により、ローカルクロックの周波数を示す。基本クロックＢＣＫは、ＣＲＭ１０３が保持していることを前提にしているため、この二つのパラメータにより、以前の周波数と新たな周波数は計算できる。Ｉｎ Ｔｉｍｅ１７０３は、Ｎ＿ＣＤＩＶ７１０２に変更して、図８（ｂ）に示される新たな予算３０２により、タスク終了のデッドラインが達成できるか否かを示す。フラグ”１”は達成できる。フラグ”０”は達成不可を示す。達成不可の場合には、ＣＲＭ１０３は基本クロックの変更も検討する。７１０４から７１０６は、ＣＰＵ−ｉｄ上のタスクの進捗状況を判断するための情報である。それについて、図８（ｂ）を参照しながら説明する。

本例ではタスクは各ＣＰＵに一個しかない想定であるが、複数のタスクがあってもこの部分をタスクの数だけ準備すれば対応できる。Ｔｏｔａｌ Ｂｕｄｇｅｔ Ｔｉｍｅ７１０４は、図８（ｂ）に示されるように、タスクが終了する予定時間を示す。すなわち、経過時間のデッドラインである。Ｅｌａｐｓｅｄ Ｔｉｍｅ７１０５は、現在の状態３００によって示される、ＣＰ１の経過時間である。Ｉｎｔｉａｌ Ｂｕｄｇｅｔ Ｔｉｍｅ７１０６は、３００のチェックポイントが、ＣＰ１が当初経過するはずであった予算時間を示す。後述するように、７１０６を７１０４と比較することにより、処理量から見た進捗の程度が判定できる。

尚、進捗が判定できる情報としては、実時間ではなくサイクル数を使う方法もある。この方法は、コンパイラとの親和性が高いというメリットがある。しかしながら、ＯＳとの親和性が低く、複数のクロックを扱う場合には、統一クロックを準備するなど何らかの工夫が必要となる。

＜共有リソースコントローラ（ＣＲＣＬ）＞
次に、上記ＣＲＣＬ１２３の処理流れについて、図９を参照しながら説明する。

ＣＲＣＬ１２３には、二つの機能がある。一つは、ＬＲＣＬ１１２で行ったローカルリソースの制御だけでは、タスク予算の達成が困難であるとき、共有リソースを制御して、タスク予算の達成を実現することである。もう一つは、マルチプロセッサにおけるプロセッサ間の共有リソースに対して、異なるプロセッサに搭載されるタスクが同時にアクセスするとき、その優先順位を、タスクの進捗状況の度合いに基づき変更する。遅れの回避がより困難なタスク、またはそのタスクが搭載されるプロセッサの優先順位を上げる。前者の機能をステップ２０６で実現し、後者の機能をステップ２０７で実現する。ステップ２０６は、タスクがローカルクロックを変更しても予算達成が困難であるとき、すなわち、図８のＩｎＴｉｍｅ７１０３がオフのとき、本例における共有リソースである基本クロックの周波数を上げ、予算達成を可能とする。基本クロックの周波数の変更は、図１のＢＵＳ＿ＡＲＢ１０４を通してＢＣＫＧＥＮ１２０を制御することにより実施する。

基本クロックの周波数を上げるに伴い、他のＣＰＵに対するローカルクロックの周波数も上がるため、電力の不必要な消費を抑えるためには、他のＣＰＵのローカルクロックに対しては、分周比を上げて周波数を必要以上に上げない制御も行う。この制御は、図１のＣＫＤＩＶ１１９に対して、１０４を通して行う。

ステップ２０７は、複数のプロセッサから送付されてきたタスクの進捗状況から、共有リソースの優先度を変更する処理である。本例では、共有リソースとして、図１のＢＵＳ＿ＡＲＢ１０４の中のバスを取り上げている。

まず、ステップ２０７１で、遅れ回避がより困難と思われるタスク、またはタスクが搭載されるプロセッサに対して、バス優先度をより高くするという決定を行う。遅れの挽回が困難であるという判断を行う尺度として、二つの指標を取り上げる。（１）の条件で同等の優先度になれば、（２）を適用する。

（１）処理の進行比率が大きい。進行した処理量の全体に対する比率が大きければ大きいほど、遅れを挽回する機会が少なく、挽回が困難と考える。早く終わらせた方がスケジューリングの課題がより少なくなるという理由もある。

（２）遅れの程度が大きいタスク、またはそのタスクを保持するプロセッサの順に、優先度を決定する。遅れの程度が大きいタスクを放置しておくと挽回が困難になるという理由による。

上記（１）を実現するには、Ｐｒｏｇｒｅｓｓｉｎｇ−ＳＴ７１０の値を用いて、次の式（i）を利用する。このとき、「Progress Ratio」が大きければ大きいほど、処理の進行比率が大きいため、そのタスクまたはタスクの搭載するプロセッサの優先度を高める。

Progress Ratio = Initial Budget Time7106/Total Budget Time7104 ……(i)
上記（２）を実現するには、次の式(ii)を利用する。このとき、「Degree of Delay」が大きければ大きいほど、予算に対して遅れが顕著であるため、そのタスクまたはタスクの搭載するプロセッサの優先度を高める。

Degree of Delay = Elapsed Time7105/Initial Budget Time7106 ……(ii)
次に、決定された優先度を、ステップ２０７１で、ＢＵＳ＿ＡＲＢ１０４への信号として出力できるように、プロセッサの優先度設定用のレジスタに優先度の値をセットする。例えばＣＰＵ１００では、図１のＰＲｅｇ１１０が、優先度設定用のレジスタである。本レジスタの各ビットは、ＢＵＳ＿ＡＲＢ１０４の入力制御信号として利用される。

上記例によれば、以下の作用効果を得ることができる。

（１）アプリケーションタスクのプログラム中に、進捗度を判定する複数のチェックポイントを保持し、ある事象が起こった時に、アプリケーションタスクの経過ポイントと経過時間を問合せ、その結果から、制御タスクが進捗度を判定する。判定結果に従い、タスクの実行を制御する。プロセッサで動作するタスクの制御を行うときには、ある事象として、タスクの定められたチェックポイントの予定完了時間が経過したときとし、タスクの実際の経過ポイントを取得し、事前に設定したそのポイントの予定経過時間と比較することにより進捗状況を判断する。タスクの実行制御は、クロック周波数や電圧の変更を行う。マルチプロセッサ上でのタスクを制御する場合には、複数のプロセッサの共有リソースを制御する共有リソースコントローラモジュールを設け、各プロセッサからのタスクの進捗状況の通知を受け、より進捗度の遅れが大きいプロセッサの共有リソースの優先度を上げる制御を行う。

（２）上記（１）により、アプリケーションソフトウェアの適用範囲に制約がなくなる。どんなプログラムでも適用可能となるため、高性能化や低電力化の効果は大となる。従来技術で、適用対象としていた画像圧縮プログラムにおいても、より細かいサブプログラム単位で進捗状況の把握が可能となる。このため、実行経過の早い段階での制御が可能となり、手遅れとなる事態を回避でき、高性能、低電力化の実現可能性が増す。

次に、マルチプロセッサ上で動作するタスクのシミュレータへの適用例について述べる。

本シミュレータは、タスクの経過に応じてタスクが搭載されるプロセッサの時間を進めることにより、機能だけでなく時間も模擬するが、二つ以上のプロセッサ間に通信がおこったときにプロセッサ間の時間の違いが、リアルタイムにタスクの進行状況を正確にモニターできなくなり、タスクの動作に矛盾を起こすケースがある。このため、時間の違いを認識して、時間を一致させるためのタスク制御を行う。

＜シミュレータの主要構成＞
図１０には、シミュレータの構成例が示される。

本シミュレータは、ハードウェアシミュレータを利用することなく、事前に設定した実行に要する時間を参照して、この時間を利用して、機能だけでなく経過時間のシミュレーションも行う。

まず、全体の概観を述べる。シミュレータは、プラットフォームＯＳ１０００の上で稼動する。

１０１０，１０２０は各々、並列動作するプロセッサＣＰＵ１００、ＣＰＵ１０１の上で稼動するタスク群である。ＣＰＵ１００と１０１上で動作するタスク同士は並列に独立に動作する必要があるため、１０１０と１０２０は、少なくとも一個以上のプラットフォームＯＳ１０００のタスクで構成する。ＣＰＵ１００とＣＰＵ１０１の間の通信を行う媒体は、これらのタスクと並列に独立に動作する必要があるため、この媒体を模擬するタスクとしてＣＲＣ（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）Ｔｓｋ１００７を装備する。ＣＲＣＴｓｋ１００７は、実際のハードウェアとしては、ＢＵＳ＿ＡＲＢ１０４とこれに繋がるＣＭ１０５、ＩｎｔＣ１０７、Ｔｉｍｅｒ１０８などに相当する。ＣＲＣＴｓｋ１００７は、複数のプロセッサからの通信を受取るため、データが矛盾なく受け渡されるためにデータの受け取りの同期を取る機能も必要となる。

上記タスク群１０１０，１０２０は互いに同一構成とされるため、タスク群１０１０の内部構成についてのみ説明する。

１０１０におけるタスクは、ＲＴＯＳ１１１のエミュレータＲＴＯＳＥｍｕ１００１と、１００１上で動作する三種類のタスクからなる。三種類のタスクとは、アプリケーションタスＡＰＰＬ１１３、１０２０からのデータを１００７を経由して受信する専用タスクＣＯＭ１００２、及びシミュレータ用タスクコントローラＳｉｍＣＬ１００４である。ここで、Ｃｏｍ１００２は図１での実プロセッサ上にも搭載することはできるが、本シミュレータの実施では必須であるため、ここでは特に構成要素として設定している。

尚、ＲＴＯＳＥｍｕ１００１の上に、アプリケーションタスクＡＰＰＬ１１３やＣＯＭ１００２が搭載される構成になっているが、ＲＴＯＳＥｍｕのサービスコールを、プラットフォームＯＳ１０００のサービスコールに変換して実行するタイプのエミュレータでは、ＲＴＯＳＥｍｕ１００１は存在せず、ＡＰＰＬ１１３やＣＯＭ１００２の中に、変換テーブルを保持する構成となる。

＜プロセッサの時間管理とタスク制御＞
図１１において、ステップ１１００では、図６で説明したタスク経過登録処理４００が起ったか否かを、判定する。更新がなければ、この処理は繰り替えし行う。図６（ｂ）のフローチャートは、シミュレータでもそのままであるが、経過時間は、シミュレータ上で取得するため、前回のチェックポイントから、今回のチェックポイントまでの処理時間をあらかじめテーブルとして保持しておき、これを前回のチェックポイントの経過時間に加算して得る。少し注意を要する点は、図４でのタスク登録処理の埋め込み、すなわちチェックポイントの埋め込みは、処理２と処理３のように、分岐で処理が異なるときには、分岐ごとの処理の終了時点にも設定する。何故なら、経過時間は事前の処理の予算時間の加算で決めるため、処理が決まらないと、経過時間が決まらないためである。本例では、経過時間の取得は、別のテーブル参照としているが、アプリケーションの中に処理時間を埋め込み、その中で計算することも可能である。

ステップ１１０１では、更新を行ったタスクがＡＰＰＬ１１３かＣＯＭ１００２かを、更新されたテーブルにより判定する。ＡＰＰＬであれば、１１０２と１１０３でプロセッサの時間を進める。ＣＯＭであれば、１１０４へ進む。時間を進めるには、まず、１１０２で、現在経過したチェックポイントでの経過時間を、ＥｌａｐｓｅｄＴｉｍｅ-ＲＴ６００から取得する。この経過時間を、プロセッサの経過時間、すなわちシミュレータの時刻として、ＰＲ−ＥｌａｐｓｅｄＴｉｍｅ１１１０に登録する。このテーブルは、プロセッサの時間のみを登録するのみであり、詳細は割愛する。

次に、ＣＯＭが経過時間の更新を行った時には、異なるプロセッサ１０１の経過時間を受けて更新を行っている。ステップ１１０４で、当該プロセッサの経過時間をＰＲ_ＥｌａｐｓｅｄＴｉｍｅ１１１０から取得し、ＣＯＭの経過時間をＣＯＭ＿ＥｌａｐｓｅｄＴｉｍｅ１１１１から取得する。ＣＯＭ_ＥｌａｐｓｅｄＴｉｍｅも、プロセッサの時間のみを登録するのみであり、詳細は割愛する。ステップ１１０５では、両者の経過時間に差異があるため、この時間あわせをする必要があるため、タスクの実行を制御する。

＜タスク制御の詳細＞
図１２から図１４は、ＣＯＭ１００２がＣＰＵ１０１のプロセッサ経過時間をＣＯＭ＿ＥｌａｐｓｅｄＴｉｍｅ１１１１に登録したときに、ＣＰＵ１００とＣＰＵ１０１のプロセッサ経過時間の関係と、ＡＰＰＬ１１３の状態で区分して、ＡＰＰＬ１１３とＣＯＭ１００２に対して行う制御を示した図である。

まず、図１２から図１４に共通のシンタックスを述べておく。最上段は、現在のプロセッサＣＰＵ１００とＣＰＵ１０１の経過時間を示す。ｔ１はＣＰＵ１００の経過時間で、ｔ２はＣＰＵ１０１の経過時間である。上から２番目の段は、ＣＰＵ１００で動作するタスク、ＡＰＰＬ１１３とＣＯＭ１００２の現在の状態と、今後ＳＩＭＣＬ１００４が行う制御を矢印１２０１などで示す。点線１２００は、現在のタスクの状態を示している。例えば図１２で、ＡＰＰＬ１１３は、ＣＰＵ１００の経過時間ｔ１であり、ＣＯＭ１００２はＣＰＵ１０１の経過時間ｔ２である。最下段は、ＣＰＵ１０１のプロセッサのＣＯＭ１００３がデータ転送を行った状態示している。プロセッサ時刻ｔ２でｗａｉｔしている状態である。ＣＯＭ１００３からＣＯＭ１００２に、１２０２に従いデータをバス経由で転送する。バス経由の転送には、実際には時間を要するが、本特許の内容とは関連ないため、バス転送の時間は無視している。もちろん、バス転送の時間を考慮しても良い。

次に各ケースの区分とタスク制御を述べる。

図１２と図１３は、ＣＰＵ１００の経過時間ｔ１が、ＣＰＵ１０１の経過時間ｔ２より小さい、すなわち、ＣＰＵ１００は時刻として遅れている。図１２は、ＡＰＰＬ１１３が実行状態かＲｅａｄｙ状態にある。図１３は、ＡＰＰＬ１１３がＷａｉｔ（ウェイト）状態またはＳｌｅｅｐ（スリープ）状態で停止している。

図１４は、ｔ１がｔ２より以上、すなわちＣＰＵ１００は時刻として進んでいる状態にある。

以下で各ケースのタスク制御を詳細に述べる。

（１）ケース１：ｔ１＜ｔ２ かつ ＡＰＰＬ１１３がＲｅａｄｙか実行状態
このケースは、ＣＯＭをｓｌｅｅｐ状態に移行させ、１２０１に示すように、ｔ１がｔ２に等しくなるまでＡＰＰＬ１１３を実行させる。ＡＰＰＬ１１３がＲｅａｄｙ状態であるときには、ＣＯＭがｓｌｅｅｐ状態になることにより実行が開始される。ｔ１とｔ２が等しくなれば、ＣＯＭを元の状態に戻す。

（２）ケース２：ｔ１＜ｔ２ かつ ＡＰＰＬ１１３が停止状態
このケースは、時刻ｔ２になるまでの１３０１の期間、ＡＰＰＬ１１３は停止していることになるため、ＣＯＭをｓｌｅｅｐ状態に移行させ、ＣＰＵ１００の経過時間ＰＲ＿ＥｌａｐｓｅｄＴｉｍｅ１１１０をｔ２まで強制的に進める。本特許の内容と関連ないため、詳細は割愛するが、シミュレータの状態監視の機能のため、１３０１の期間、ＡＰＰＬ１１３が停止状態であることも、どこかに記録する。その後、ＣＯＭを元の状態に戻す。

（３）ケース３：ｔ１＞＝ｔ２
このケースは、ＣＯＭの受信データはｔ１になるまでＡＰＰＬ１１３は必要ないため、ＣＯＭの処理との関連は少ない。１４００に示すとおり、ＣＯＭはｔ２の時刻のままで、処理を進める。ＡＰＰＬ１１３もこれまで通り実行する。

時刻の一致が得られるのは、ＡＰＰＬ１１３がＣＰＵ１０１にデータを送信して、ｔ１とｔ２の時刻が一致を取れたケースで、このときに、ＣＯＭに時刻データを送信する。

以上本発明者によってなされた発明を具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

以上の説明では主として本発明者によってなされた発明をその背景となった利用分野であるマルチプロセッサシステムに適用した場合について説明したが、本発明はそれに限定されるものではなく、半導体集積回路に広く適用することができる。

本発明に係るタスク制御方法が実施されるマルチプロセッサの構成例ブロック図である。 上記マルチプロセッサでのタスクの進捗状況の把握とタスクの実行制御の動作シーケンスである。 上記マルチプロセッサでの実行予算とその更新の説明図である。 上記マルチプロセッサでのアプリケーション内へのチェックポイント設定例のフローチャートである。 上記マルチプロセッサにおけるＬＲＣＬが利用するチェックポイントの予算時間登録表の説明図である。 上記マルチプロセッサにおけるアプリケーション内のｎ番目のチェックポイントの経過登録結果の説明図である。 上記マルチプロセッサにおけるＬＲＣＬの動作フローチャートである。 上記マルチプロセッサにおけるＬＲＣＬがＣＲＭに通知する情報を示す表の説明図である。 上記マルチプロセッサにおけるＣＲＣＬの動作フローチャートである。 シミュレータの構成例ブロック図である。 上記シミュレータの動作フローチャートである。 二つのプロセッサの時刻が異なるときのタスク制御についての説明図である。 二つのプロセッサの時刻が異なるときの別のタスク制御についての説明図である。 二つのプロセッサの時刻が異なるときの別のタスク制御についての説明図である。

符号の説明

１００，１０１ ＣＰＵ
１０２ クロック生成モジュール（ＣＫＧＥＮ）
１０３ 共用リソースマネージャモジュール（ＣＲＭ）
１０９ ローカルメモリ（ＬＭ）
１１０ ＢＵＳ＿ＡＲＢ１０４へのアクセス優先度設定用のレジスタ（ＰＲｅｇ）
１１１ リアルタイムＯＳ（ＲＴＯＳ）
１１２ ローカルリソースコントローラタスク（ＬＲＣＬ）
１１３ アプリケーションタスク（ＡＰＰＬ）
３０１ ＣＰ２とその予定経過時間
３０２ タスクのチェックポイントの経過時間の新たな予算
３０３ タスクのチェックポイントの経過時間の事前の予算
５００ 経過時間の事前の予算を登録するテーブル（ｌａｐｓｅｄＴｉｍｅ−ＢＴ）
５０１ チェックポイントの数−１を登録する領域
５０２ 経過したチェックポイント（ＣＰ）を登録する領域
５０３ チェックポイントの経過時間の予算を登録する領域
６００ 実際の経過時間を登録するテーブル（ｌａｐｓｅｄＴｉｍｅ−ＲＴ）
６０３ チェックポイントの実際の経過時間を登録する領域
７１０ タスクの進捗状況を通知するためのテーブル（ｒｏｇｒｅｓｓｉｎｇ−ＳＴ）

Claims (8)

1. プロセッサによってアプリケーションソフトウェアタスクが実行される際のタスク制御方法であって、
   上記アプリケーションソフトウェアタスクには予めチェックポイントが埋め込まれ、
   上記アプリケーションソフトウェアタスクの実行中に、上記チェックポイントを用いて、上記アプリケーションソフトウェアタスクの経過ポイントを問い合わせ、問合せた結果の現在の経過ポイントと経過ポイントに対応する経過予算から上記タスクの進捗状況を判断し、その判断結果に基づいて、タスクが利用する共有リソースを制御するとともに、新たな経過予算を設定することを特徴とするタスク制御方法。
2. 上記アプリケーションソフトウェアタスクへの問合せは、あるチェックポイントの経過予定時間が過ぎた時に行われ、上記問合の結果通知される情報には、現在経過しているチェックポイントと当該チェックポイントを経過した時間が含まれる請求項１記載のタスク制御方法。
3. 遅れの度合いが大きいタスクを制御するとき、所定プロセッサのみで利用するパラメータを制御する部分と、複数のプロセッサで利用する共有リソースを制御する部分とに分け、前者に対しては上記所定のプロセッサでタスク制御を行い、後者に対しては上記複数のプロセッサとは独立したモジュールで制御する請求項１記載のタスク制御方法。
4. 進捗状況の判断は、タスクが終了するまでの経過時間の予算値、現在経過したチェックポイントの経過時間の予算値、現在経過したチェックポイントの実際の経過時間を利用する請求項１記載のタスク制御方法。
5. 上記所定プロセッサで行われるタスク制御は、タスクが終了するまでの経過時間の予算値、現在経過したチェックポイントの経過時間の予算値、現在経過したチェックポイントの実際の経過時間を、プロセッサ識別子とローカルリソースを制御した結果の新たなリソース情報と共に、共有リソースを制御するモジュールに転送する請求項３記載のタスク制御方法。
6. 共有リソースのタスクまたはタスクを搭載するプロセッサの優先度を変更し、当該優先度は遅れの挽回がより困難なタスクまたはプロセッサの優先度を高くする請求項３記載のタスク制御方法。
7. タスクが終了するまでの経過時間の予算値をＡとし、現在経過したチェックポイントの経過時間の予算値をＢとし、現在経過したチェックポイントの実際の経過時間をＣとするとき、遅れの挽回がより困難なタスクまたはプロセッサの優先度を高くする手段として、ＢのＡに対する割合が高く、ＣのＢに対する割合が高いタスクまたは当該タスクを搭載するプロセッサの優先度を高くする請求項３記載のタスク制御方法。
8. 請求項１乃至７の何れか１項記載のタスク制御方法を実現するタスク制御プログラムが格納されたメモリと、
   上記メモリに格納されているタスク制御プログラムを実行可能なＣＰＵと、を含んで成る半導体集積回路。

Images