(57)【要約】  データ処理装置と、そのようなデータ処理装置の動作方法とが開示される。データ処理装置は、複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットと、メイン処理ユニットに代わって複数のそれらタスクを実行するためのデータ・エンジンとを含む。メイン処理ユニットによって少なくとも１つの共有リソースがデータ・エンジンに割り当てられ、データ・エンジンがメイン処理ユニットの代わりにデータ処理タスクを実行するときに使用するようになっている。データ・エンジンは、タスクを実行するためのデータ・エンジン・コアと、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するようにアレンジされたデータ・エンジン・サブシステムとを含む。データ・エンジン・コアは、データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞って、割当共有リソースの使用を管理するためのリソース・マネージャ・ユニットを含む。そのような方式がデータ処理装置内にデータ・エンジンの特に効率的な実現を提供することが明らかになった。これは、既存のコードをそのようなデータ処理装置上で実行できるように書き換える必要性を減らす。
2008541215.tif 000002
【特許請求の範囲】
【請求項１】
データ処理装置であって、
複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットと、
メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能なデータ・エンジンと、
前記複数のデータ処理タスクを実行するときにデータ・エンジンが使用するためにメイン処理ユニットによってデータ・エンジンに割り当てることができる少なくとも１つの共有リソースと、を含み
前記データ・エンジンは、前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コアと、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能なデータ・エンジン・サブシステムとを含み、
前記データ・エンジン・コアは、データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うように動作可能で、割当共有リソースの使用を管理するリソース・マネージャ・ユニットを含む、
データ処理装置。
【請求項２】
請求項１記載のデータ処理装置であって、データ・エンジンが実行すべき複数のデータ処理タスクは、データ・エンジン・コアによって実行可能で前記リソース・マネージャ・ユニットを前記マスタ・デバイスとして振る舞わせる命令セットのうちの少なくとも１つの命令を含む命令シーケンスを含み、前記少なくとも１つの命令が実行されると、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムに制御コマンドを発行し、それによって割当共有リソースの使用を管理するように動作可能である前記データ処理装置。
【請求項３】
請求項２記載のデータ処理装置であって、データ・エンジン・サブシステムは、リソース・マネージャ・ユニットから制御コマンドを受信し、その制御コマンドに依存して割当共有リソースの使用を制御するように動作可能な制御ロジックを含む前記データ処理装置。
【請求項４】
請求項２又は３記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの転送起動命令を含み、それが実行されると、リソース・マネージャ・ユニットが前記マスタ・デバイスとして振る舞うようにされる前記データ処理装置。
【請求項５】
請求項２から４のうちの任意の請求項記載のデータ処理装置であって、割当共有リソースとデータ・エンジン・コアとは、互いに同時に動作し、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの同期命令を含み、それが実行されると、割当共有リソースとデータ・エンジン・コアとの間に同期が形成される前記データ処理装置。
【請求項６】
請求項５記載のデータ処理装置であって、メイン処理ユニットがデータ・エンジン・サブシステムのための新しい構成を指示するときに、データ・エンジン・コアは、割当共有リソースとデータ・エンジンとが同期する同期ポイントに到達させるために前記同期命令の１つを実行するよう動作可能で、同期ポイントに到達したあとのデータ・エンジン・サブシステム内でのみ新しい構成が有効になる前記データ処理装置。
【請求項７】
請求項２から６のうちの任意の請求項記載のデータ処理装置であって、データ・エンジン・コアは、複数の機能ユニットを含むデータ・パス・ロジックを含み、前記機能ユニットの１つがリソース・マネージャ・ユニットであり、データ・エンジン・コアは、更にシーケンス中の各命令に対してその命令をどの機能ユニットが実行するかを制御するように動作可能なコントローラを含む前記データ処理装置。
【請求項８】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、更に、データ・エンジン・コアが実行する前記命令シーケンスをスケジューリングするように動作可能なデータ・エンジン・コンパイラを含み、データ・エンジン・コアが実行可能な命令セットは、拘束条件を指定する少なくとも１つの拘束命令を含み、コンパイラは、前記拘束命令の１つに出会うと、拘束条件を考慮しながらシーケンス中の後続命令の実行をスケジューリングするように動作可能である前記データ処理装置。
【請求項９】
先行する任意の請求項記載のデータ処理装置であって、リソース・マネージャ・ユニットは、データ・エンジンと同期したデータ転送コントローラとして動作可能な前記データ処理装置。
【請求項１０】
請求項９記載のデータ処理装置であって、割当共有リソースがＤＭＡロジックを含み、リソース・マネージャ・ユニットは、ＤＭＡマスタ・デバイスとして振る舞い、前記ＤＭＡロジックを使用してデータの転送を起動させるように動作可能である前記データ処理装置。
【請求項１１】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースが割込みコントローラを含み、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムを介して割込みコントローラに転送するように割込みを発行するように動作可能である前記データ処理装置。
【請求項１２】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースがメモリ領域を含み、リソース・マネージャ・ユニットは、前記メモリ領域の１又は複数部分の使用変更を起動するための制御信号を発行するように動作可能である前記データ処理装置。
【請求項１３】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、割当共有リソースがメモリ領域を含み、データ・エンジン・コアが実行可能な命令セットは、メモリ領域の動的実時間管理をイネーブルする少なくとも１つの管理命令を含む前記データ処理装置。
【請求項１４】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのスケジューリング命令を含み、それが実行されると、割当共有リソースが実行するためにタスクをスケジューリングさせる前記データ処理装置。
【請求項１５】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのレジスタ命令を含み、データ・エンジン・コアが第１のデータ処理タスクを実行する間にそれが実行されると、第２のデータ処理タスクが実行のために登録される前記データ処理装置。
【請求項１６】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのコールバック命令を含み、データ・エンジン・コアが第１のデータ処理タスクを実行中にそのタスクの遂行に関して少なくとも１つの条件が満たされていないと判断すると、データ・エンジン・コアは、コールバック命令を実行し、リソース・マネージャ・ユニットに、前記少なくとも１つの条件が満たされ次第第１のデータ処理タスクを再度呼び出すべきことをデータ・エンジン・サブシステムに向けて指示させ、それによって、前記少なくとも１つの条件が満たされるまでデータ・エンジン・コアが第１の処理タスクの実行を停止することを許容するように動作可能な前記データ処理装置。
【請求項１７】
先行する任意の請求項記載のデータ処理装置であって、データ・エンジンがスタブ・レイヤを含み、それは、データ処理タスクをデータ・エンジン・コアが実行すべきときに、データ・エンジン・コアがデータ処理タスクの実行を許容する前に、そのデータ処理タスクに必要な１又は複数の必要条件をチェックするように動作可能である前記データ処理装置。
【請求項１８】
請求項２に従属するときの請求項１７記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのリクエスト命令を含み、データ処理タスクに必要な少なくとも１つの必要条件が満たされていないとスタブ・レイヤが判断したとき、リクエスト命令が実行されて、リソース・マネージャ・ユニットにデータ・エンジン・サブシステムに向けてリクエスト・コマンドを出力させ、その少なくとも１つの必要条件が満たされるべきであることを要求する前記データ処理装置。
【請求項１９】
請求項２に従属するときの請求項１７又は１８記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのエラー処理命令を含み、データ処理タスクに必要な少なくとも１つの必要条件が満たされないとき、エラー処理命令が実行されて、リソース・マネージャ・ユニットに任意の必要なエラー状態を出力させ、データ処理タスクをエグジットさせる前記データ処理装置。
【請求項２０】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースは、データ・エンジンとデータ処理装置の処理ユニットとの間の通信を促進するデータ処理装置の１つの要素である前記データ処理装置。
【請求項２１】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットのうちの少なくとも１つの命令は、フラグを返させて、命令の実行が成功であったか否かを表示するようにアレンジされ、それによって、フラグが存在しない場合にデータ・エンジン・コアがストールし、電力節約モードに入る前記データ処理装置。
【請求項２２】
複数のデータ処理タスクを実行させるように動作可能なメイン処理ユニットと、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能なデータ・エンジンとを有するデータ処理装置を動作させる方法であって、
データ・エンジンに対して、前記複数のデータ処理タスクを実行するときにデータ・エンジンが使用する少なくとも１つの共有リソースを割り当てる工程と、
データ・エンジンのデータ・エンジン・コアを使用して前記複数のデータ処理タスクを実行する工程と、
データ・エンジンと割当共有リソースとの間の通信を管理するために使用されるデータ・エンジン・サブシステムを構成する工程と、
データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うリソース・マネージャ・ユニットをデータ・エンジン・コア内に採用して、割当共有リソースの使用を管理する工程と、
を含む方法。
【請求項２３】
複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットを有するデータ処理装置のためのデータ・エンジンであって、データ・エンジンは、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能であり、また前記複数のデータ処理タスクを実行するときに使用するためのデータ処理装置の少なくとも１つの共有リソースを割り当てられており、データ・エンジンは、
前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コアと、
メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能なデータ・エンジン・サブシステムと、
データ・エンジン・コア内にあってデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うように動作可能で、割当共有リソースの使用を管理するリソース・マネージャ・ユニットと、
を含むデータ・エンジン。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は、データ処理装置および方法に関するものであって、詳細には、そのようなデータ処理装置内でのデータ・エンジンの使用に関する。
【背景技術】
【０００２】
（発明の背景）
メイン処理ユニットを有するデータ処理装置では、しばしば疎結合コプロセッサ（それがメイン処理ユニットの外部にあって、データ・エンジンとメイン処理ユニットとの間の同期が１つのプロセス又はタスクのレベルで発生するという意味で疎結合）とも呼ばれるデータ・エンジンを備えることが知られており、それは、メイン処理ユニットに代わって特定のデータ処理タスクを取り扱うために用いることができる。このことは、タスクすべてがメイン処理ユニットで扱われるデータ処理装置に対して各種の改善をもたらし、それらの改善とは、例えば、実行速度の向上、与えられたタスク群について消費電力の削減又は必要とされる機能をサポートするために要する合計シリコン面積の縮小のうち１つ又は複数のものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
そのようなデータ・エンジンの一例は、デジタル信号プロセッサ（ＤＳＰ）であり、それは、特定の処理タスクを扱うように最適化された処理ユニットと考えることができ、更に典型的には、それ自身の専用リソース、例えば、それ自身の割込みコントローラ、それ自身のダイレクト・メモリ・アクセス（ＤＭＡ）ロジック等を有する。そのようなＤＳＰの使用は、データ処理装置の性能を向上させるのに非常に有効であるが、それらは、ＤＳＰがメイン処理ユニットに代わって要求される処理タスクを実行できるようにするために必要とされる専用リソースすべてをＤＳＰに提供する必要があるため、データ処理装置内部に設けるには、高価である。
【０００４】
そのようなＤＳＰに代わるものは、それに対する専用のローカル・リソースを持たないタイプのデータ・エンジンを提供するものであり、そのようなデータ・エンジンは、メイン処理ユニットに対して純粋にスレーブ・デバイスとして機能する。そのような例では、メイン処理ユニットは、特別なタスクをそのタスクを実行するためにデータ・エンジンが必要とするすべてのデータと一緒にそのデータ・エンジンにディスパッチし、そのあと、タスクが完了したときにデータ・エンジンから確認信号を受信する。そのような確認信号を受信すると、メイン処理ユニットからデータ・エンジンに別のタスクをディスパッチできる。そのようなデータ・エンジンは、データ・エンジンのためのローカル・リソースを設ける必要がないことから、先に述べたＤＳＰよりもかなり安く組み込むことができる一方で、個別タスクをデータ・エンジンに割り当てる処理およびデータ・エンジンに対してそれがタスクを実行するのに必要なすべてのデータを提供することを保証するためにメイン処理ユニットに代わって大きなオーバヘッドが課されることになり、それにより、データ・エンジンの活動をサポートするための巨大なグローバルなシステム活動が生ずることになる。これは、計算サイクルおよび電力消費に関して性能劣化につながるだけでなく、しばしばそのようなデータ・エンジンを含むデータ処理装置上でソフトウエアを走らせるようにするために既存のソフトウエアを大幅に書き換えることが必要となり、明らかに望ましくない。
【０００５】
ＤＳＰが必要とするすべてのリソースをＤＳＰにローカルに提供しＤＳＰ専用とする上述のＤＳＰ方式と、データ・エンジンがローカル／専用のリソースを持たないデータ・エンジン方式との中間の方式は、特定のリソースにアクセスできるが、それらのリソースがデータ処理装置の他の要素と共有されるデータ・エンジンを提供するものである。従って、それらのリソース又はそれらのリソースの一部は、特定のセッション（セッションは、典型的には、実行すべき一群のタスクを含む）に関してそのデータ・エンジン専用のものとなるが、それらのリソースは、後続のセッションでは、データ処理装置の他の要素に割り当て直すことができる。
【０００６】
特定の共有リソースに対するアクセスをデータ・エンジンに提供するとき、メイン処理ユニットとデータ・エンジンとの間に、データ・エンジンからメイン処理ユニットへの何らかのデカップリングを提供するサブシステム・レイヤを設けることができる。そうすることで、メイン処理ユニットが一群のタスクをデータ・エンジンに割り当て、次に、サブシステムが各々の個別タスクをデータ・エンジンにディスパッチして処理させるようにできる。サブシステムは、またデータ・エンジンが要求されるタスクを実行するのに必要な場合に、割当共有リソースへのアクセスができるようにする。そのような方式では、サブシステムがデータ・エンジンに対してマスタ役を果たし、データ・エンジンは、今回も純粋なスレーブとして振る舞う。そのような方式は、メイン処理ユニットが一群のタスクをサブシステムにディスパッチして、データ・エンジンに処理させることによって、メイン処理ユニットをタスク管理の複雑な作業のいくつかから解放できるが、それでもなお、ソフトウエアがデータ処理装置上で実行できるようにするために既存のソフトウエアを大幅に書き換えることが必要となる場合がしばしばある。特に、特別なタスクを実現するソフトウエアが書かれた場合、そのようなタスクは、なんらかのマスタ機能を示すことができ、従って、特定のイベントを開始させることができた処理ユニットによって実行されると考えることができよう。しかし上で述べたように、サブシステムによって１つのタスクがデータ・エンジンに割り当てられると、データ・エンジンそれ自身は、純粋なスレーブ・デバイスとして振る舞い、イベントを開始させることができない。
【０００７】
上で述べた方式の更に別の問題点は、それが、システム内部に３つの異なるプログラム上の視点を持ち込むことである。特に、メイン処理ユニットおよびデータ・エンジンをプログラムすることに加えて、サブシステムも何らかのプログラミングを必要とする。それは、サブシステムがそれ自体でローカル処理ユニットとして機能するからであり、それは、それがデータ・エンジンに対する個別タスクのディスパッチを管理し、データ・エンジンがそのようなタスクを実行するのに必要なすべてのデータを提供されることを保証するために、必要に応じて共有リソースへのアクセスを管理するように要求されるからである。更に、共有リソースを使用することがメイン処理ユニットとの間で頻繁な通信を必要とするので、それは、グローバルなシステム活動を縮小する手助けとならない。
【課題を解決するための手段】
【０００８】
従って、データ処理装置内で使用するための進歩したデータ・エンジンを提供することが望まれ、それは、ＤＳＰの使用に関して顕著なコスト削減を提供できるものであり、またそれがデータ・エンジンを含むシステム上で実行できるように大幅な書き換えをしなければならないリスクを低減できるものである。
【０００９】
（発明の概要）
第１の態様から眺めると、本発明は、複数のデータ処理タスクを実行するように動作可能なメイン処理ユニット、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能なデータ・エンジン、前記複数のデータ処理タスクを実行するときにデータ・エンジンが使用するためにデータ・エンジンに対してメイン処理ユニットによって割り当て可能な少なくとも１つの共有リソース、前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コアと、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能でメイン処理ユニットによって構成可能なデータ・エンジン・サブシステムとを含む前記データ・エンジンおよび割当共有リソースの使用を管理するためのデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うように動作可能なリソース・マネージャ・ユニットを含む前記データ・エンジン・コアを含むデータ処理装置を提供する。
【００１０】
本発明に従えば、データ・エンジンは、メイン処理ユニットに代わってタスクを実行するデータ・エンジン・コアと、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するようにアレンジされたデータ・エンジン・サブシステムとを有し、割当共有リソースは、タスクを実行するときに、データ・エンジンが使用するためにメイン処理ユニットによってデータ・エンジンに割り当てられるリソースである。
【００１１】
共有リソース全体が、何らかの期間、典型的には、１つのセッションの間、データ・エンジンに割り当てられるか、あるいは、その代わり、リソースの一部だけが他の部分と一緒にデータ処理装置の他の要素に割り当てられる。リソースの一部がデータ・エンジンに割り当てられる場合、その部分は、物理的部分、例えば、メモリの一領域、ＤＭＡコントローラの限られた数のチャネル等であるか、あるいは、共有リソースによってサポートされる機能の特別なサブセット、例えば、データ・エンジンに読出しアクセスを許容するが、書込みアクセスを許容しないものを指定する機能的部分である。このことから、１つの共有リソースは、一定の期間、データ・エンジンに専用のものとなるか、あるいは、その期間、データ・エンジンと他の要素（例えば、それもデータ・エンジンでよい）との間で共有できるが、後者の場合、データ・エンジンは、典型的には、他の要素に割り当てられた物理的又は機能的部分と競合しない物理的又は機能的部分へのアクセスのみが割り当てられる。
【００１２】
更に、本発明に従えば、データ・エンジン・コアは、割当共有リソースの使用を管理するためのデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うリソース・マネージャ・ユニットを有する。そのような方式によって、データ・エンジン・コアは、既存のソフトウエアがそのソフトウエアを実行する処理ユニットが実行能力を有することを期待する多様な異なるアクションを実行することができる。これは、既存のソフトウエアを書き直してそのようなデータ・エンジンを含むデータ処理装置上で実行できるようにする必要性を大幅に緩和することができる。更に、共有リソースへのアクセスがリソース・マネージャ・ユニットを介してデータ・エンジン中で緊密に統合されるので、それらのリソースは、それ自体で機能しなければならないリソースと比べて低コストですむ。
【００１３】
更に、データ・エンジン・コア内にデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うリソース・マネージャ・ユニットを備えることにより、データ・エンジン・サブシステムを別にプログラムする必要性を緩和することができ、従って、さもなければ存在したであろうプログラム上の視点の数を減らすことができ、それによって設計の複雑さを大幅に縮小できる。リソース・マネージャ・ユニットは、ハードウエア・ユニットとして構成することも、あるいは、ハードウエアとソフトウエアの２つの要素の混在する形で構成することも可能である。
【００１４】
共有リソースは、データ処理装置の任意のその他の要素、例えば、メイン処理ユニット、あるいは、データ処理装置内に設けられた任意のその他のデータ・エンジンと共有されよう。１つの実施の形態では、複数のデータ・エンジンが同じデータ・エンジン・サブシステムを使用し、その場合に、共有されるリソースが実際には、データ・エンジン・サブシステム内にある。典型的には、メイン処理ユニットは、セッションごとにデータ・エンジン・サブシステムを構成し、任意の必要な共有リソースをデータ・エンジンに割り当てるようにアレンジされており、各セッションは、典型的には、データ処理装置上で実行すべき複数のタスクを含む。従って、セッションの期間、データ・エンジン・サブシステムの構成は、変わらず、共有リソースの割り当ても変わらない。しかし、リソース・マネージャ・ユニットを使用して、割当共有リソースがセッションの間に使用されるやり方を管理することができる。
【００１５】
データ・エンジン内にデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うリソース・マネージャ・ユニットを設けることによって、メイン処理ユニットの介入／干渉なしで、セッションの間、データ・エンジンが共有リソースにアクセスすることが許容され、それによってグローバルなシステム活動が縮小され、そのことから性能向上およびエネルギー消費削減が達成される。例えば、グローバルなシステム活動の縮小は、メイン処理ユニットがより大きい比率の時間、低電力モードを採用する可能性を増大させることができる。
【００１６】
メイン処理ユニットは、多様な形を取ることができる。例えば、それは、中央処理ユニット（ＣＰＵ）、あるいは、データ処理装置内の何らかのその他の簡略化された制御要素、例えば、ブート・アップを制御し、そのあとその他のすべてのタスクを１又は複数のデータ・エンジンに委ねるだけの制御要素でよい。
【００１７】
リソース・マネージャ・ユニットが割当共有リソースの使用を管理するマスタ・デバイスとして振る舞うやり方は、複数存在する。１つの実施の形態では、データ・エンジンが実行すべき複数のデータ処理タスクが、命令シーケンスを含み、それには、データ・エンジン・コアが実行可能な命令セットのうちの少なくとも１つの命令であって、前記リソース・マネージャ・ユニットに前記マスタ・デバイスとして振る舞わせるようにするものが含まれ、前記少なくとも１つの命令が実行されると、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムに向けて制御コマンドを発行し、それによって割当共有リソースの使用を管理するように動作できる。従って、そのような実施の形態に従えば、データ・エンジン・サブシステムは、リソース・マネージャ・ユニットからデータ・エンジン・サブシステムへの制御コマンドの発行を通して、望ましい形で割当共有リソース使用を管理する。
【００１８】
１つの特別な実施の形態で、データ・エンジン・サブシステムは、リソース・マネージャ・ユニットから制御コマンドを受信し、その制御コマンドに依存して割当共有リソースの使用を制御するように動作する制御ロジックを含む。１つの実施の形態で、データ・エンジン・サブシステム内の制御ロジックは、３つのインタフェースを含み、第１のインタフェースは、それを通して制御ロジックの動作をメイン処理ユニットが構成できる構成インタフェースであり、第２のインタフェースは、それを通してデータ・エンジン・コアのリソース・マネージャ・ユニットとデータ・エンジン・サブシステムの制御ロジックとの通信が発生する制御インタフェースであり、そして第３のインタフェースは、制御ロジックと、データ・エンジン外部のデータ処理装置の部分との間のインタフェースで、それを通してリソース・マネージャ・ユニットの指図に従うように制御ロジックが割当共有リソースの管理を行う。
【００１９】
データ・エンジン・コアが実行可能な命令セット内に備えられる命令は、多様な形を取ることができる。１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの転送起動命令を含み、それが実行されると、リソース・マネージャ・ユニットが前記マスタ・デバイスとして振る舞うようにされる。従って、そのような実施の形態で、転送起動命令の実行は、データ・エンジン・サブシステムに向けて適当な制御コマンドを発行させ、何らかの操作、例えば、何らかのデータの転送、割込みコントローラへの割込み信号の発行、割り当てられたメモリ領域の再プログラミング等を起動させる。
【００２０】
１つの実施の形態で、割当共有リソースおよびデータ・エンジン・コアは、互いに同時に動作し、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの同期命令を含み、それが実行されると、割当共有リソースとデータ・エンジン・コアとの間に同期がもたらされる。割当共有リソースがデータ・エンジンに対して同時に動作することから、割当共有リソースとデータ・エンジンは、ともに任意の特定の時点で互いに独立して動作するが互いの状態を知ることがない。従って、同期命令を使用すれば、割当共有リソースとデータ・エンジンとを同期させる同期ポイントに到達させることができる。このことは、有益である。というのは、そのような同期が成立するまで次の命令が実行できないプログラム・コード内のポイントに達する場合が多いためである。
【００２１】
先に述べたように、メイン処理ユニットは、どこかの時点、典型的には、新しいセッションに切り替わるときに、データ・エンジン・サブシステムの構成を変更することができる。しかし、構成に関する任意のそのような変更は、現在の構成に依存して動作してきたデータ処理装置の各種パーツをリセットすることを意味する。典型的な実施の形態で、そのようなプロセスが注意深く処理されることを保証することが重要であり、特に、データ・エンジン・コアおよび割当共有リソースがそのような変更の発生に先立って同期化されることを保証することが重要である。従って、１つの実施の形態で、メイン処理ユニットがデータ・エンジン・サブシステムに関する新しい構成を指示するとき、データ・エンジン・コアは、割当共有リソースとデータ・エンジンとが同期する同期ポイントに達するように前記同期命令の１つを実行するように動作可能であり、新しい構成は、同期ポイントに達したあとで、データ・エンジン・サブシステム内でのみ有効になる。
【００２２】
データ・エンジン・コアは、多様な形にアレンジできる。しかし、１つの実施の形態で、データ・エンジン・コアは、複数の機能ユニットを含むデータ・パス・ロジックを含み、前記機能ユニットの１つは、リソース・マネージャ・ユニットであり、データ・エンジン・コアは、更にシーケンス中の各命令に対してどの機能ユニットがその命令を実行するかを制御するように動作可能なコントローラを含む。従って、そのような実施の形態に従えば、データ・エンジン・コア内に複数の機能ユニットを備えることができ、各機能ユニットは、特別なタイプの命令を実行してそれらの命令の高速かつ効率的な処理を提供するようになっており、命令シーケンスの個別命令が適当な機能ユニットによって実行されることを保証するためにコントローラが使用される。１つの実施の形態で、各命令は、コントローラによって実行され、適当な機能ユニットに転送すべき制御信号を生成し、他方、別の実施の形態では、コントローラが単に各命令を適当な機能ユニットに転送して、その機能ユニットに実行させる。
【００２３】
１つの実施の形態では、データ・エンジン・コアが実行すべき命令のシーケンスをスケジューリングするためにデータ・エンジン・コンパイラが備えられる。コンパイラの目的は、命令シーケンスが、データ・エンジン・コアの構造を考慮したうえで、可能な限り効率的に実行されることを保証することである。本発明の１つの実施の形態に従えば、データ・エンジン・コアが実行可能な命令セットは、拘束条件を指定する少なくとも１つの拘束命令を含み、コンパイラが前記拘束命令の１つに出会うと、拘束条件を考慮してシーケンス中の後続の命令の実行をスケジューリングするように動作可能である。一例として、拘束命令は、ＤＭＡプロシージャを受けさせるべきアドレス・グループを指定し、またコンパイラは、拘束命令の直後に命令が続く場合、それらのアドレス・グループへのアクセスを必要としない命令をスケジューリングするように動作可能である。
【００２４】
注意すべきことは、いくつかの実施の形態で、拘束命令によって指定される拘束条件を、データ・エンジン・コアによって効率的に処理されることを保証するために別の目的で使用することもできることである。例えば、１つの実施の形態で、拘束条件は、データ・エンジン・コアが拘束条件によって指定されたアドレス範囲内の任意のアドレスにアクセスすることを要求する場合にそれをストールさせるセマフォを設定するように、リソース・マネージャ・ユニットからデータ・エンジン・サブシステムの制御ロジックまで伝えることができる。拘束条件が最早必要でない場合、セマフォをクリアすることができ、それによってデータ・エンジン・コアは、それをストールさせたアクセスを継続することが許容される。
【００２５】
リソース・マネージャ・ユニットは、多様な形で使用することができる。１つの実施の形態に従えば、リソース・マネージャ・ユニットは、データ・エンジンと同期したデータ転送コントローラとして動作可能である。従って、例えば、マスタ・デバイスとして振る舞う場合、リソース・マネージャ・ユニットは、データ転送起動デバイスとして振る舞い、また、スレーブ・デバイスとして使用される場合は、リソース・マネージャ・ユニットは、データ・ゲート・デバイスとして振る舞うことができる。
【００２６】
１つの実施の形態で、割当共有リソースは、ＤＭＡロジックを含み、リソース・マネージャ・ユニットは、ＤＭＡマスタ・デバイスとして振る舞うことができ、前記ＤＭＡロジックを使用してデータ転送を起動する。従って、そのような実施の形態では、データ・エンジン・コアのリソース・マネージャ・ユニットは、メイン処理ユニットの代わりのデータ・エンジンによって実行されるタスクの結果としてそれが要求される場合、それ自身の意思でデータ転送を起動することができる。そのようなデータ転送には、データ・エンジン中へのデータの転送又はデータ・エンジンから外へのデータの転送が含まれる。
【００２７】
１つの実施の形態で、割当共有リソースは、割込みコントローラを含み、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムを経由して割込みコントローラに送るための割込みを発行するように動作可能である。従って、これは、データ・エンジン・コアによる直接的な割込みベース処理の実行をイネーブルし、そのことから、データ・エンジンが別のデバイスに信号を送る必要がある場合、リソース・マネージャ・ユニットは、適当な割込み信号を発行させることができる。
【００２８】
１つの実施の形態で、割当共有リソースは、メモリ領域を含み、リソース・マネージャ・ユニットは、そのメモリ領域の１又は複数部分の使用の変更を起動するための制御信号を発行するように動作可能である。従って、特別なセッションの間、これは、データ・エンジンが実行すべきタスクを考慮して割当メモリ・リソースの使用を最適化することをイネーブルする。
【００２９】
割当共有リソースがメモリ領域を含む実施の形態では、データ・エンジン・コアが実行可能な命令セットは、メモリ領域の動的実時間管理をイネーブルする少なくとも１つの管理命令を含む。従って、一例として、メモリ領域の一部を使用して、ヘッド・ポインタとテイル・ポインタとによって定義されるソフトウエア的ＦＩＦＯ構造を実現でき、その管理命令は、例えば、ヘッド・ポインタに問い合わせ、テイル・ポインタをセットし、ソフトウエア的ＦＩＦＯを構成する等によって、そのソフトウエア的ＦＩＦＯの動的実時間管理を実行する。
【００３０】
１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットは、実行されると割当共有リソースが実行するタスクをスケジューリングする少なくとも１つのスケジューリング命令を含む。これは、例えば、そのタスクを実行するために必要なリソースが直ちに利用できない場合に適しており、そのような場合には、リソースが利用可能になるまでそのタスクの実行を待たせることができる。
【００３１】
１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのレジスタ命令を含み、それは、データ・エンジン・コアが第１のデータ処理タスクを実行している間に実行されると、第２のデータ処理タスクを実行のために登録させる。そのような方式によって、１つの実施の形態のリソース・マネージャ・ユニットは、１つのタスクに後続のタスクを何らかのスケジューリング・ルーチン、例えば、オペレーティング・システムのスケジューラ部に登録することを許容するインタフェースを提供する。
【００３２】
１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのコールバック命令を含み、もし第１のデータ処理タスクを実行中にそのタスクの遂行に関して少なくとも１つの条件が満たされていないとデータ・エンジン・コアが判断すれば、データ・エンジン・コアは、コールバック命令を実行して、リソース・マネージャ・ユニットに働きかけて、前記少なくとも１つの条件が満たされ次第、第１のデータ処理タスクを再び呼び出すべきことをデータ・エンジン・サブシステムに指示させるように動作可能であり、それによってデータ・エンジン・コアは、前記少なくとも１つの条件が満たされるまで、第１の処理タスクの実行を停止させる。従って、そのような実施の形態を通して、データ・エンジン・コアは、特定の条件が満たされない場合、特別なタスクの実行を停止するように決定でき、その場合、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムに対してそれ以降のどこかの時点で条件が満たされたときに、そのタスクを再び呼び出すようにアドバイスする機構を提供する。従って、この方式は、データ・エンジン・コア自体にスケジューリングのための何ら複雑な機構を追加しなくても、タスクがどのようにデータ・エンジン・コアによって実行されるかについての柔軟性をサポートする。
【００３３】
１つの実施の形態で、データ・エンジンは、スタブ・レイヤを含み、それは、データ・エンジン・コアによってデータ処理タスクを実行すべきときに、そのデータ処理タスクをデータ・エンジン・コアが実行することを許容する前に、データ処理タスクに必要な１又は複数の必要条件をチェックするように動作可能である。そのような必要条件は、例えば、何らかのプログラム・データ、定数テーブル・データ、状態割り当て等の利用可能性である。そのようなスタブ・レイヤを使用することで、より汎用化されたタスク・モデルがデータ・エンジン上に実現でき、ここでは、単にタスクを実行する代わりに、まず何らかのチェック・プロシージャが呼び出される。
【００３４】
１つのそのような実施の形態で、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのリクエスト命令を含み、また、データ処理タスクによって必要とされる少なくとも１つの必要条件が満たされていないとスタブ・レイヤが判断すると、リクエスト命令が実行されて、リソース・マネージャ・ユニットに働きかけて、その少なくとも１つの必要条件が満たされるべきことを要求するリクエスト・コマンドをデータ・エンジン・サブシステムに向けて出力させる。そのような方式によって、データ・エンジン・コアによるタスクの実際の実行を、前記少なくとも１つの必要条件が満たされるまで保留することができる。
【００３５】
１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのエラー処理命令を含み、データ処理タスクによって必要とされる少なくとも１つの必要条件が満たされない場合、エラー処理命令が実行されて、リソース・マネージャ・ユニットに任意の必要なエラー状態を出力させ、またデータ処理タスクをエグジットさせる。先に述べたスタブ・レイヤを使用した実施の形態で、エラー処理命令の実行は、エグジット・ルーチンを実行させるためのエグジット・コマンドをリソース・マネージャ・ユニットからスタブ・レイヤに発行させるようにアレンジできる。
【００３６】
上の議論で、データ・エンジン・コアが実行可能な命令セットは、多様な異なるタイプの命令、特に、転送起動命令、同期命令、拘束命令、スケジューリング命令、レジスタ命令、コールバック命令、リクエスト命令およびエラー処理命令を含むものとして説明してきた。注意すべきことは、任意の特別な命令が、それらの命令タイプの２つ以上のものに属するということである。例えば、転送起動命令は、拘束命令を兼ねていてもよい。例えば、ＤＭＡ開始命令は、ＤＭＡ操作を受けさせるべきアドレス範囲を定義する。別の例として、転送起動命令は、その命令によって指定されるタスクを実施するために必要なリソースが現時点で利用可能でない状況では、スケジューリング命令になると考えることができる。
【００３７】
上の説明から明らかなように、割当共有リソースは、多様な形を取ることができる。１つの実施の形態で、割当共有リソースは、データ・エンジンとデータ処理装置の処理ユニットとの間の通信を促進するデータ処理装置の１つの要素である。割当共有リソースがそれを利用してデータ・エンジンとの通信を促進する処理ユニットは、多様な形を取り、例えば、メイン処理ユニット、あるいは、例えば、別のデータ・エンジンのようなデータ処理装置内の何らかの他の処理ユニットでよい。
【００３８】
データ・エンジン・コアが実行可能な命令セットの命令は、多様な形を取ることができる。しかし、１つの実施の形態で、データ・エンジン・コアが実行可能な命令セットの少なくとも１つの命令は、命令の実行が成功したか否かを表示するフラグのリターンを引き起こすようにアレンジされ、それによって、フラグが存在しない場合、データ・エンジン・コアは、ストールし、電力節約モードに入る。このことから、そのような実施の形態に従えば、データ・エンジン・コアの視点からは、命令が無条件に返されるように見え、そのため、データ・エンジン・コアは、リターン・フラグの不在のときストールする。返されるフラグが不在の場合に、データ・エンジンが自動的にストールし、電力節約モードに入ることをイネーブルすることにより、それは、データ・エンジン内に特別に電力効率的な実施を提供する。
【００３９】
１つの実施の形態で、いくつかの命令は、ブロッキング的であり、それらが終了するまでストールを発行し、それらは、フラグのリターンを引き起こす命令である。他の命令は、非ブロッキング的であり、そのような非ブロッキング命令は、一定のサイクル数で終了することが確実なアクション（例えば、ステータス情報をリクエストする場合）を実施するか、あるいは、データ・エンジン・コアが結果を知る必要のない、あるいは、結果が直ちに必要でないアクション（例えば、同期化を行うために第２のコマンドが使用される場合）を開始させるかのいずれかである。
【００４０】
第２の観点から眺めると、本発明は、複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットと、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能なデータ・エンジンとを有するデータ処理装置を動作させる方法を提供し、その方法は、前記複数のデータ処理タスクを実行するときに、データ・エンジンが使用する少なくとも１つの共有リソースをデータ・エンジンに割り当てる工程、データ・エンジンのデータ・エンジン・コアを使用して前記複数のデータ処理タスクを実行する工程、データ・エンジン・コアと割当共有リソースとの間の通信を管理するために使用されるデータ・エンジン・サブシステムを構成する工程およびデータ・エンジン・コア内に、データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞い、割当共有リソースの使用を管理するリソース・マネージャ・ユニットを採用する工程を含む。
【００４１】
第３の観点から眺めると、本発明は、複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットと、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能であり、前記複数のデータ処理タスクを実行するときに使用するために、データ処理装置の少なくとも１つの共有リソースを割り当てられるデータ・エンジンとを有するデータ処理装置用のデータ・エンジンを提供し、前記データ・エンジンは、前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コア、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能なデータ・エンジン・サブシステムと、データ・エンジン・コア内にあって、データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞い、割当共有リソースの使用を管理するように動作可能なリソース・マネージャ・ユニットとを含む。
【００４２】
本発明について、添付図面にほんの一例として示されたそれの実施の形態を参照しながら更に説明する。
【実施例】
【００４３】
（詳細な説明）
図１は、本発明の１つの実施の形態に従うデータ処理装置のブロック図である。データ処理装置１０は、ホスト・バス４０（実際には、分離したバスのネットワークを構成する）を介して、ホスト・バスに接続された多様な他の装置と通信することができるホスト・プロセッサ２０を有する。特に、ＳＤＲＡＭ３０のようなメモリ・デバイスがホスト・プロセッサによって必要とされるデータを記憶するために備えられる。同様に、ホスト・プロセッサ２０に代わって特定のタスクを実行するために、１又は複数のデータ・エンジン６０、７０が備えられる。更に、１又は複数の共有リソース５０が備えられ、それらは、ホスト・プロセッサ２０によってデータ・エンジン６０、７０の１つ又は両方に割り当てられて、ホスト・プロセッサ２０に代わってデータ・エンジンがタスクを実行するときに使用される。
【００４４】
共有リソース５０は、多様な形を取ることができ、１又は複数の分離したリソースを含むことができる。そのような共有リソースの例は、データ転送を管理するためのＤＭＡロジック・ユニット、割込みリクエストを処理するためのベクトル化された割込みコントローラ（ＶＩＣ）、メモリ領域、データ・エンジン６０、７０とデータ処理装置１０の何らかの他の要素、例えば、ホスト・プロセッサ２０や別のデータ・エンジン等との間の通信を促進する通信交換要素であるがそれらに限らない。
【００４５】
本発明の実施の形態に従えば、データ・エンジン６０、７０の少なくとも１つは、データ処理タスクを実行するためのデータ・エンジン・コアと、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するようにアレンジされたデータ・エンジン・サブシステムとを有するデータ・エンジンである。データ処理装置上で走るアプリケーションは、典型的には、複数の分離したセッションを含み、各々のセッションに対してホスト・プロセッサ２０は、データ・エンジン・サブシステムを構成し、そのセッションの間、データ・エンジンが使用する１又は複数の共有リソースを割り当てるようにアレンジされる。データ・エンジン・コアは、１つの実施の形態で、データ・エンジン・サブシステム内の制御ロジックを介して構成されるか、あるいは、データ・エンジン内に備えられたスタブ・レイヤを介して構成される。スタブ・レイヤについては、後に図９を参照しながら詳しく説明する。
【００４６】
もしデータ・エンジン６０、７０の両方が上で述べたタイプのデータ・エンジンであれば、各々のデータ・エンジンは、それ自身のデータ・エンジン・コアを有することになる。１つの実施の形態で、各データ・エンジンは、それ自身のデータ・エンジン・サブシステムを有するが、注意すべき点は、別の実施の形態では、データ・エンジン６０、７０が１つのデータ・エンジン・サブシステムを共有し得ることである。
【００４７】
図２は、本発明の１つの実施の形態に従う、データ・エンジン６０、７０の少なくとも１つのなかに備えられたロジックをより詳細に示すブロック図である。特に、１つの実施の形態では、少なくともデータ・エンジン６０が上で述べたタイプのものであって、従って、データ・エンジン・サブシステム１００とデータ・エンジン・コア１３０とを含むものと想定されている。データ・エンジン・コアは、データ・パス１５０を有し、それは、典型的には、データ・エンジンが処理すべきタスクを構成する命令に応答して動作する複数の機能ユニットを含む。データ・エンジン・コア１３０内のコントローラ１４０は、命令シーケンスの個々の命令がデータ・パス１５０内の適当な機能ユニットによって確実に実行されることに責任を持つ。
【００４８】
データ・エンジン・コア１３０は、外部環境、すなわちデータ・エンジン６０の外部にあり、従って、特に、データ・エンジン・サブシステム１００を介して共有リソース５０を含むデータ処理装置１０のパーツと通信する。既に述べたように、データ・エンジン・サブシステムは、セッションごとにメイン処理ユニットによって構成され、データ・エンジン・コアと割当共有リソースとの間の通信を管理するようにアレンジされる。特に、データ・エンジン・サブシステム１００は、ホスト・プロセッサ２０によって構成され、データ・エンジン・コア１３０と共有リソース５０を含む外部環境との間の適当な通信を許容するグルー・ロジック１２０を含む。
【００４９】
グルー・ロジック１２０に加えて、データ・エンジン・サブシステム１００は、１又は複数の非共有リソース１１０を含むことができ、それらは、データ・エンジン・サブシステム１００に接続されたデータ・エンジン・コアに専用となっている。そのような非共有リソースの一例は、特にデータ・エンジン６０専用とされるメモリ部分である。
【００５０】
図３は、本発明の１つの実施の形態に従う、データ・エンジン６０およびオプションとしてのデータ・エンジン７０内に備えられた要素をより詳細に示すブロック図である。図３の例に示されたように、データ・エンジン・サブシステム１００内には、密結合メモリ（ＴＣＭ）２３０の形の非共有リソースが備えられており、このＴＣＭ２３０は、データ・エンジン・コア１３０専用となっている。
【００５１】
グルー・ロジック１２０は、実際には、複数のコンポネントから構成される。特に、グルー・ロジック１２０は、構成ポート２０２に接続されたデコーダ２００を含み、それによって、デコーダは、ホスト・プロセッサ２０から構成設定情報を受信する。デコーダ２００は、この構成設定情報を解読して、データ・エンジン・サブシステムの必要な構成を実行させるために、データ・エンジン・サブシステム１００の他の要素に向けて適当な制御信号を送信させる。
【００５２】
グルー・ロジック１２０は、またデータ・エンジン・サブシステム１００内のその他各種のコンポネントに向けて、更に、データ・エンジン・サブシステムの通信ポート２０４を介して外部環境の要素にも向けて制御信号を発行できる制御ロジック２１０を含む。更に、本発明の１つの実施の形態に従えば、制御ロジック２１０は、データ・エンジン・コア１３０のデータ・パス１５０内に備えられたリソース・マネージャ・ユニット２７０に接続されており、このリソース・マネージャ・ユニットは、ここでシステム・コール機能ユニット（ＳＣＦＵ）とも呼ばれる。ＳＣＦＵ２７０は、データ・エンジン・サブシステム１００に対してマスタ・デバイスとして振る舞い、データ・エンジン・コア１３０が同期、制御トランザクションおよびデータ・エンジン・コア１３０と任意の割当共有リソース５０を含む外部環境との間のデータ転送を起動することを許容する。特に、命令セットが提供され、それらは、要求される機能を実現させるようにＳＣＦＵ２７０からデータ・エンジン・サブシステム１００内の制御ロジック２１０に向けて、対応する制御コマンドを発行させるようにＳＣＦＵ２７０によって実行できる。データ・パス１５０内に通信ポート２８２が設けられ、それを通してＳＣＦＵ２７０が制御ロジック２１０と通信できるようになっており、またそれによって制御ロジック２１０がＳＣＦＵ２７０と通信できるようになっている。ＳＣＦＵ２７０は、また入力／出力ポート２７４を有し、それを通してコントローラ１４０とＳＣＦＵ２７０との間の通信ができる。
【００５３】
このように、ＳＣＦＵ２７０は、データ・エンジン・コア１３０がデータ・エンジン・サブシステム１００に向けてメッセージを発行することを通して、それの意図を知らせることを許容するインタフェースと見ることができる。同様に、ホスト・プロセッサ２０もそれの意図（例えば、セッションを変更したい等）を知らせることができる。次に、サブシステム制御ロジック２１０は、この情報を組み合わせて、一例として図５から９のトランザクション図を参照しながら後により詳しく説明するように、適切なアクションを取る。
【００５４】
図３の例のデータ・エンジン・サブシステム１００は、またデータ・ポート２０８に接続されたＤＭＡインタフェース２２０を含み、それを通してデータ・エンジン・サブシステム１００と外部環境との間でＤＭＡトランザクションが実行できる。
【００５５】
図３に示されたように、ＴＣＭ２３０は、実際には、ＴＣＭ自身と、ＴＣＭに関連して設けられた付属の制御ロジックとを含み、例えば、ＴＣＭへのアクセスに関する多重リクエスト間の調整を行う。制御ロジック２１０は、ＴＣＭ制御ロジックに向けて制御信号を発行し、また必要に応じてＴＣＭ２３０を構成することができる。
【００５６】
ＳＣＦＵ２７０に加えて、データ・パス１５０は、また複数の機能ユニット２５０、２６０を含み、各々の機能ユニットは、それぞれ２つのインタフェース２５２、２５４および２６２、２６４を有すると考えることができる。これら両方のインタフェースは、データ・パス１５０から可視であるため、それらインタフェースのプロパティは、データ・パス１５０による処理のために命令をコンパイルするために使用されるデータ・エンジン・コンパイラ（図示されていない）によって知られる。これと対照的に、注意すべきように、ＳＣＦＵ２７０は、データ・パス１５０から可視である１つのインタフェース２７４を有し、従ってそれは、コンパイラに知られているが、それの他のインタフェースは、通信ポート２８２であって、それは、データ・エンジン・サブシステム１００から可視であり、従って、コンパイラには、見えない。ＳＣＦＵ２７０には、オプションとして外部環境への第３のインタフェース（図示されていない）を設けることができ、それを介してＳＣＦＵにあてがわれた機能を構成できるようになっていることに注意しなければならない。このオプションの第３インタフェースは、例えば、サービス・アクセス・プロトコル（ＳＡＰ）インタフェースである。
【００５７】
これも図３に示されているように、データ・パス１５０内に複数のデータ・ポート２８４、２８６を設けることができ、それらを介して機能ユニット２５０、２６０がデータ・エンジン・サブシステム１００を通ってデータ処理装置の他の要素とデータの送受信を行うことができる。１つの実施の形態で、それらデータ・インタフェース２８４、２８６の各々は、それぞれ機能ユニット２５０、２６０によって使用できる。図３に示された特別な例で、１つのデータ・ポート２８４は、ＴＣＭ２３０に接続されて、機能ユニット２５０、２６０とＴＣＭ２３０との間でデータ交換ができるようにしており、他方、もう１つのデータ・ポート２８６は、データ・エンジン・サブシステム１００を通してデータ・エンジン・サブシステムのデータ・ポート２０６に接続されて、データ・エンジン・コア１３０と外部環境にある共有リソースを形成するメモリとの間でデータ通信ができるようにしている。
【００５８】
ＳＣＦＵ２７０は、命令セットを通して作動させることができ、それらは、データ・エンジン・アーキテクチャの不可欠な部分（すなわち、データ・エンジン能力／命令セットの全体）である。１つの実施の形態で、それらのＳＣＦＵ固有の命令は、標準ＯＳＩ（オープン・システム・インターコネクション）レイヤ又は共通ＯＳ（オペレーティング・システム）コールとしてモデル化できるよう制約されたものとなっている。そのような方式によって、そのようなデータ・エンジンを含むデータ処理装置上で走るようにソフトウエアを適合させる場合のソフトウエア移植の労力は、大幅に低減される。
【００５９】
先に述べたように、データ・パス１５０内のＳＣＦＵ２７０は、データ・エンジン・サブシステム１００に対してマスタ・デバイスとして振る舞い、ホスト・プロセッサ２０によってデータ・エンジン６０に割り当てられた任意の割当共有リソース５０の使用を管理することができる。そのような使用の一例で、ＳＣＦＵ２７０は、データ・エンジン・コア１３０と同期したデータ転送コントローラとして振る舞うことができる。例えば、もし割当共有リソースにＤＭＡロジックが含まれていれば、ＳＣＦＵ２７０は、ＤＭＡマスタ・デバイスとして振る舞い、ＤＭＡロジックを使用したデータ転送を起動させることができる。特に、コントローラ１４０は、パス１４７を経由し、またポート２７４を介してＳＣＦＵ２７０に制御信号を発行するための命令を実行することができ、通信ポート２８２を通って制御ロジック２１０に向けて制御コマンドを発行させ、ＤＭＡ転送プロセスを実行させようとする。この結果、制御ロジック２１０は、適切な制御信号をＤＭＡインタフェース２２０に送り、ＤＭＡインタフェース２２０がデータ・ポート２０８を介して、データ・エンジン６０の外部に設けられたＤＭＡロジックに向けて転送リクエストを出力するようにする。これは、ＤＭＡロジックを介したＤＭＡデータ転送を起動することになる。１つの例で、データは、何らかの外部メモリからデータ・エンジン・サブシステム１００内のＴＣＭ２３０に転送されるため、それは、データ・エンジン・コア１３０のデータ・パス１５０によって迅速にアクセスできるようになる。この例で、データは、ＤＭＡロジックからポート２０８を経由してＤＭＡインタフェース２２０に送られ、そこからそのデータは、ＤＭＡインタフェース２２０からＴＣＭ２３０に送られてそこに記憶される。記憶されたデータは、データ・パス１５０をＴＣＭ２３０に接続するデータ・ポート２８４を通してデータ・パス１５０によって後でアクセスできる。
【００６０】
ＳＣＦＵ２７０を使用することによって実現される機能の別の例として、コントローラ１４０は、ＳＣＦＵ２７０に働きかけて制御ロジック２１０に向けて制御コマンドを発行させ、ベクトル化された割込みコントローラ（ＶＩＣ）の形の共有リソースに向けて通信ポート２０４を通して割込みリクエストを出力させることができる。従って、この機構は、データ・エンジン・コア１３０による割込み駆動処理の実施を許容するが、以前であればそのようなデータ・エンジン・コア１３０は、スレーブ型のデバイスとして振る舞うことができるのみで、従ってそれ自体として割込みを発行することは、できなかったであろう。
【００６１】
別の例で、共有リソースは、データ・エンジン・コア１３０とデータ処理装置の何らかのその他の要素との間で共有されるメモリ領域の形を取る。そのような例で、データ・エンジン６０に割り当てられる特別なメモリ領域は、セッション期間中、ホスト・プロセッサ２０によって固定されてしまうが、ＳＣＦＵ２７０は、問題のセッションの間にメモリ領域の使用方法を変更するように使用することもできる。特に、ＳＣＦＵ２７０に働きかけて制御信号を制御ロジック２１０および通信ポート２０４を通して問題になっているメモリ領域のメモリ・コントローラに転送させ、そのメモリ領域の使用に関する必要な変更を実施させる命令を実行することができる。
【００６２】
データ・エンジン・サブシステム１００が複数のデータ・エンジン・コア１３０間で共有され、従って、ＴＣＭ２３０それ自身が１つの共有リソースと考えられる実施の形態では、その中で、それが複数のデータ・エンジン・コア間で共有できることに注意しなければならない。そのような場合、同じ機構を用いて、ＴＣＭ２３０内の特別なメモリ領域の使用を変更することができ、その場合、関連する制御信号がＳＣＦＵ２７０から制御ロジック２１０を経由してＴＣＭ２３０内のメモリ制御ロジックに送られる。
【００６３】
１つの実施の形態で、割当共有リソースがメモリ領域を含む場合、データ・エンジン・コア１３０は、そのメモリ領域の動的実時間管理を実行する管理命令を実行するようにアレンジできる。例えば、１つの実施の形態で、メモリ領域内にソフトウエアで定義したＦＩＦＯが実現され、ＦＩＦＯの範囲は、ヘッド・ポインタとテイル・ポインタとによって定義される。ＳＣＦＵ２７０は、そのソフトウエアＦＩＦＯを構成するための命令を実行して、データをそのソフトウエアＦＩＦＯにロードさせ、データをそのソフトウエアＦＩＦＯからメモリに保存させ、ヘッド・ポインタに問い合わせを行い、テイル・ポインタを設定する等を行うようにアレンジされる。そのような機能は、ＳＣＦＵ２７０およびデータ・エンジン・サブシステム１００内の制御ロジック２１０を使用することを通して、メモリの動的実時間管理を効率的に行うことを可能にする。
【００６４】
１つの実施の形態で、割当共有リソースおよびデータ・エンジン・コア１３０は、互いに同時に動作して、それにより、互いの状態を知らなくてもそれぞれの操作を同時に実行できる。データ・エンジンによって実行される命令のシーケンスは、特別な時点で、その命令を実行する前に、割当共有リソースの活動がデータ・エンジン・コアの活動と同期していることを確認する必要があるようになっている。本発明の１つの実施の形態で、このことは、ＳＣＦＵ２７０が同期命令を実行して、割当共有リソースとデータ・エンジン・コアとの間で同期を発生させるようにＳＣＦＵ２７０をアレンジすることで実現できる。そのような同期命令は、明示的又は暗示的である。明示的同期命令の一例は、ＤＭＡエンジンの形の共有リソースに働きかけてＤＭＡ転送を起動させるＤＭＡ開始命令に続いて、ＤＭＡ済命令が実行される場合である。ＳＣＦＵ２７０によって実行される命令セット中の命令は、それぞれ命令の実行が成功したか否かを示すためにフラグを返させるようになっており、従って、それらの命令は、データ・エンジン・コアの視点からは、無条件でリターンするように見られる。ＤＭＡ済命令に対しては、要求されたＤＭＡ転送が完了したとデータ・エンジン・サブシステム１００内の制御ロジック２１０が判断したときに、フラグが返されるのみである。フラグが返されるそのときまで、データ・エンジン・コア１３０は、ストールし、それによって割当共有リソース（この例では、ＤＭＡロジック）とデータ・エンジン・コアとが同期する。それは、データ・エンジン・コア１３０が次の命令の実行に進むことができるのは、ＤＭＡ転送が完了したときだけであるためである。
【００６５】
そのような明示的同期命令の代わりに、同期命令は、暗示的なものでもよい。ここでもＤＭＡロジックの形の共有リソースによって実行されるＤＭＡ転送の例を考えると、ＤＭＡ転送を起動させるために実行されるＤＭＡ開始命令は、またそのＤＭＡ転送を受けさせるアドレス範囲のアレンジも指定する。このアドレス範囲は、１つの実施の形態で、データ・エンジン・サブシステム１００内の制御ロジック２１０にセマフォを設定させる拘束条件を指定するものと考えることができる。これは、もしそれがその範囲にあるデータ・アドレスの１つに対するアクセスを要求する命令を実行しようとすれば、データ・エンジン・コア１３０をストールさせる。ＤＭＡ転送が完了した場合にのみ、従って、セマフォがクリアされたときにのみ、データ・エンジン・コア１３０は、その命令の実行を継続することができ、それによって、強制的に同期を発生させる。
【００６６】
そのような同期命令は、またデータ・エンジン・サブシステム１００の特別な構成に依存するデータ処理装置の各種要素の活動が同期していることを、その構成変更の前に確認するためにも使用できる。先に述べたように、メイン処理ユニット２０は、セッション間でデータ・エンジン・サブシステムの構成を変更することができる。もしメイン処理ユニットがデータ・エンジン・サブシステムに対して新しい構成を指示すれば、１又は複数の割当共有リソースとデータ・エンジン６０とが同期する同期ポイントに到達させるように同期命令を実行することができ、それにより、その新しい構成は、同期ポイントに到達したあとで、データ・エンジン・サブシステム内でのみ有効となる。このことは、データ・エンジン・サブシステムが１つの構成から別のものへ移行するときのデータ処理装置の正しい動作を保証する。
【００６７】
セッション変更の間に、データ・エンジン・サブシステムで同時プロセス（ＯＳＩ階層の下層で走っている）がまだ稼動している場合、それらは、セッション変更の特殊な要求に依存して単にアボートされるか又はリセットされる。例えば、受け入れられた同期ポイントにおいて、コーデック関連のパラメータが変更され、それに対して出力ストリームをアボートする必要はなく、効果的に継続される。別の変更では、入力ファイルが切り替えられて、そのことが出力ストリームのアボートも要求する。従って要約すると、プロセスは、必要に応じてリセットされるだけである。
【００６８】
ＳＣＦＵ２７０によって実行される特別な命令によって指定される先に述べた拘束条件は、またデータ・エンジン・コア１３０によって実行する命令シーケンスをスケジューリングするデータ・エンジン・コンパイラによって、データ・エンジン・コア１３０がそれらの命令を実行する効率を向上させる目的で使用されることもできる。特に、コンパイラは、拘束条件を設定する命令に出会うと、その拘束条件を解析して、拘束条件を考慮してシーケンス中の後続命令の実行をスケジューリングするようにアレンジされる。例えば、もし拘束条件がその拘束条件を設定する命令によって指定される１又は複数の操作を受けさせるメモリ・アドレスの範囲を指定するものであれば、コンパイラは、拘束条件によって設定されたアドレスのいずれにもアクセスする必要のない複数の直後に続く命令を見出すために、直後に続く命令の順序を変えるようにアレンジできる。これにより、命令シーケンスを実行する場合にデータ・エンジン・コア１３０がストールしなければならない機会が減り、それに従って、データ・エンジン・コアの速度および効率が改善する。
【００６９】
データ・エンジン・コア１３０によって特別なタスクを実行しなければならないときに、そのタスクを実行するために必要な実際のリソースがまだ利用可能になっていない場合がある。そのような状況に対処するために、ＳＣＦＵ２７０は、制御ロジック２１０に制御信号を発行して、直ちにそのタスクを実行させるのでなく、タスクの実行をスケジューリングするようにアレンジできる。このことから、ＤＭＡ開始命令を例に取ると、それは、もし必要なリソースが利用可能であれば直ちに実行できるが、共有リソースがまだ利用可能でない場合には、ＤＭＡ開始命令に関連するタスクを制御ロジック２１０によって待ち行列に加えて、リソースが利用可能になったときに、要求されるタスクが開始されるようにする。
【００７０】
いくつかの実施の形態で、共有リソースの１つは、データ・エンジン６０と、別の処理デバイス、例えば、別のデータ・エンジン、ホスト・プロセッサ２０等とを接続する通信転送要素でよい。そのような実施の形態で、ＳＣＦＵ２７０は、関連するデータ・エンジン・コア１３０と前記その他の処理ユニットとの間で通信および処理を同期化するために使用できる。この機構は、従って例えば、データ・エンジン・コア１３０と前記その他の処理ユニットとの間の同期を達成するために使用することができ、従って例えば、オペレーティング・システムの関数として実行できるスレッド同期と類似したタイプのスレッド同期を実行するための機構を提供する。
【００７１】
図４は、セッションを初期化するときにデータ・エンジン６０に対して実行される工程を示すフロー図である。工程３００で、セッションは、ホスト・プロセッサ２０によって初期化され、そのあと工程３１０で、ホスト・プロセッサ２０は、データ・エンジン・サブシステム１００の構成ポート２０２に適切な構成データを発行することによってデータ・エンジン・サブシステム１００を構成するようにアレンジされる。この実施の形態で、データ・エンジン・コア１３０は、次にデータ・エンジン・サブシステムを通して明示的に構成される。一旦構成が行われると、データ・エンジン・コア１３０は、ホスト・プロセッサによってデータ・エンジン・コアに割り当てられたタスク・シーケンスの処理を開始させるために、工程３２０において開始させることができる。その後、工程３３０で、それら割り当てられたタスクがすべてデータ・エンジン・コアによって完了したと判断されると、次に、データ・エンジン・コアは、工程３４０で停止できる。１つの特別なセッション内で割り当てられたすべてのタスクがデータ・エンジン・コアによって実行されても、データ・エンジン・サブシステムの構成は変わらないことに注意しなければならない。
【００７２】
図５は、データ・エンジン・コアがＤＭＡ転送タスクを起動するときに、データ処理装置の各種要素間で発生するトランザクションを示すトランザクション図である。最初に、ホスト・プロセッサ２０上で実行されるホスト・プロセス４１０は、セッションをスタートさせ、その後、ホスト・プロセスは、ＤＭＡをデータ・エンジン６０が使用できるように構成するために、ＤＭＡロジック４００（図１の共有リソース５０の１つ）に向けてトランザクションを発行する。更に、ホスト・プロセスは、データ・エンジン・サブシステム１００に対するトランザクションを起動して、そこにあるＤＭＡインタフェース２２０を、データ・エンジン・コアがＤＭＡロジック４００と通信できるように適切に構成させる。図５で、このプロセスは、パラメータ化と呼ばれ、一般的にこのプロセスは、データ・エンジン・サブシステム１００を問題となっている特別なセッション用に構成することを含む。
【００７３】
一旦この構成が行われると、ホスト・プロセスは、データ・エンジン・コア１３０のコントローラ１４０にそれの構成ポート１４２を介してアクセスして、要求されているタスクに関連する命令シーケンスをプログラム・メモリ中にロードし、その後、ホスト・プロセス４１０は、コントローラ１４０との通信をそれに関連する制御ポート１４３を介して行うことによって、要求されているタスクを開始させることができる。これは、典型的には、関連するデータ・パス１５０によって複数の計算を実行させることになり、或る時点で、ＤＭＡ開始命令が実行されることになる。この命令が実行されると、コントローラ１４０は、ＳＣＦＵ２７０にコンタクトして、データ・エンジン・サブシステム内のＤＭＡインタフェース２２０に向けて制御ロジック２１０を介してＤＭＡ実行コマンドを転送させる。この時点でＳＣＦＵ２７０がコントローラ１４０にＤＭＡ開始リターン・フラグを返して、ＤＭＡ開始命令が起動されたことを示すことに注意すべきである。コントローラ１４０は、それがそれ以後の命令の実行を継続させて、その結果としてデータ・パス１５０内の適当な機能ユニットに向けて制御信号を転送することを可能にするために、このフラグのリターンを必要とする。
【００７４】
ＤＭＡ実行コマンドがＤＭＡインタフェース２２０に受信されると、それは、転送表示信号をＤＭＡロジック４００に発行して、それがＤＭＡに転送を希望するデータを供給していることを示す。この転送表示信号と一緒に、実際のデータがＤＭＡロジック４００に出力される。例えば、図３を参照すると、このデータは、ＴＣＭ２３０から外部環境にある何らかのメモリ・デバイスに転送されるデータである。ＤＭＡがこのデータ・ブロックを受け入れると、それは、ＤＭＡインタフェース２２０に転送応答信号を送り返し、この信号は、基本的に、データが受け入れられたことを応答するものであり、ＤＭＡが別のデータ・ブロックを受信する準備ができていることを示す。転送すべき各データ・ブロックは、転送表示信号及び関連する転送応答信号をＤＭＡインタフェース２２０とＤＭＡロジック４００との間で交換することを伴う。
【００７５】
図５の例で、この期間もコントローラ１４０は、命令シーケンスを通して実行を継続していると想定されており、またどこかの時点で、実行されることによってＳＣＦＵ２７０に制御ロジック２１０と通信させてＤＭＡプロセスが完了しているか否かを判断させるＤＭＡ済命令に到達すると想定されている。しかし、ＤＭＡプロセスの完了は、ＤＭＡインタフェース２２０が制御ロジック２１０およびＳＣＦＵ２７０にＤＭＡ完了信号を返すことによって表示されるだけである。従って、この期間に、コントローラ１４０にＤＭＡ済リターン・フラグを返すことは、不可能であり、従って、コントローラ１４０は、図５に示されたようにストールする。
【００７６】
ＤＭＡ転送が完了したときのみ、そして適当なＤＭＡ完了信号がＳＣＦＵ２７０に返されたときにのみ、ＳＣＦＵ２７０は、コントローラ１４０にＤＭＡ済リターン・フラグを発行することができ、その後、コントローラ１４０は、その操作を継続することができる。或る時点で、割り当てられたタスクがすべて完了すると、コントローラ１４０は、「タスク済」信号をホスト・プロセッサ４１０に発行する。
【００７７】
図６は、ＳＣＦＵ２７０を使用した本発明の実施の形態のデータ処理装置に基づいて実施されるプロセスの別の例を示すトランザクション図である。この例で、関連する共有リソースは、ＶＩＣ４３０である。図５に関連して先に説明したのと同じように、ホスト・プロセッサ４１０がセッションを開始するとき、それは、共有リソース、この場合、ＶＩＣ４３０を構成し、更に、データ・エンジン・サブシステム１００の構成も行う。この場合、関連コンポネントは、割込みインタフェース４２０であり、それは、制御ロジック２１０内にあると考えることができる。次に、データ・エンジン・コア１３０によって実行すべきタスクが開始されるとき、コントローラ１４０は、命令シーケンスの実行を開始し、また対応する制御信号をデータ・パス１５０の関連する機能ユニットにディスパッチする。割込みが必要な時点に到達すると、それは、割込み信号発生命令を実行して、対応する制御信号をＳＣＦＵ２７０に転送させる。次に、ＳＣＦＵ２７０は、コントローラ１４０にリターン・フラグを送って、コントローラ１４０が実行を継続することを許容し、更にデータ・エンジン・サブシステム１００内の割込みインタフェース４２０に割込み送信コマンドを発行する。これは、データ・エンジン・サブシステムからＶＩＣ４３０への割込み信号の出力をもたらし、その結果、割込み肯定応答信号がＶＩＣ４３０から割込みインタフェース４２０に返されて、ＶＩＣが割込みを受け付けたことを表示する。次に、割込み受信信号が制御ロジック２１０を介してＳＣＦＵ２７０に送られて、割込みが受け入れられたことを示す。
【００７８】
コントローラ１４０が実行を継続している間、そしてブロッキング割込みの生成を要求するどこか後の時点で、そのようなブロッキング割込みを同期型命令として用いて、そこにおいて、コントローラ１４０は、それがＶＩＣ４３０によって割込みが受け入れられたことを知るまで実行をストールする。特に、図示のように、ブロッキング割込み信号の受信に続いてＳＣＦＵ２７０からフラグが返されても、それは、単に別の命令（ＩＲＱ＿ｗａｉｔｆｏｒ＿ｂ（））を実行しているコントローラ１４０に、ＳＣＦＵ２７０に制御ロジック２１０と協議して割込みがＶＩＣ４３０によって肯定されたか否かをチェックさせるだけである。
【００７９】
その間、元々の割込み信号ブロッキング命令に関連する制御信号をＳＣＦＵ２７０が受信することによって、ＳＣＦＵは、割込み送信コマンドを割込みインタフェース４２０に転送させ、それが次に割込み表示をＶＩＣ４３０に転送させる。後にＶＩＣ４３０がその割込みの受信を肯定するとき、それは、肯定応答を割込みインタフェース４２０に返させて、それが次に割込み受信信号を制御ロジック２１０を介してＳＣＦＵ２７０に返させる。この受信信号を受け取ることによってのみ、ＳＣＦＵ２７０は、コントローラ１４０によって先に実行されたＩＲＱ＿ｗａｉｔｆｏｒ＿ｂ（）命令に応答したフラグを返すことができる。更に、このフラグがコントローラ１４０に返されたときにのみ、コントローラ１４０は、それのストール状態からエグジットして実行を継続できる。
【００８０】
１つの実施の形態で、図６において発行される各種の割込み信号に関連してＩＤが含まれ、それによって、任意の時点で処理されているプロセス中に２つ以上の割込みが存在するとき、個別信号をそれらの割込みの特別な１つに関連づけることができる。
【００８１】
図７は、ＳＣＦＵ２７０の使用を採用した１つの実施の形態のデータ処理装置１０上で実行できるタスクの別の例である。この場合、共有リソースは、ＤＭＡロジック４００と、メモリ・コントローラ４４０によって制御される何らかの共有メモリとの両方を含む。問題となっている特別な例で、複数のデータ・エンジン・コアが同じデータ・エンジン・サブシステムを共有し、そのことからデータ・エンジン・サブシステム内のＴＣＭ２３０のようなメモリ・リソースが複数のデータ・エンジン・コアによって共有されることが想定されている。従って、この例で、メモリ・コントローラ４４０は、図３のＴＣＭ２３０内に存在すると考えることができる。
【００８２】
セッションが開始されると、ＤＭＡロジック４００およびメモリ・コントローラ４４０は、図５および６に関連して先に説明したのと類似したように構成される。この例で、データは、外部環境からＤＭＡロジック４００を経由してＴＣＭメモリ２３０に転送されると想定され、特に、ＴＣＭ２３０内に維持されるソフトウエアＦＩＦＯ中に転送されると想定されている。従って、ＤＭＡ４００が始動し、その後、タスクがコントローラ１４０にディスパッチされる。これは、コントローラ１４０にＦＩＦＯ命令セットを実行させて、その結果として、ＳＣＦＵ２７０は、メモリ・コントローラ４４０に対して制御コマンドを発行して、メモリ内に構築すべきＦＩＦＯを定義するいくつかのパラメータを提供するようにされる。更にコントローラ１４０に対してセットＦＩＦＯリターン・フラグが返され、その後、スタートＦＩＦＯ命令が実行される。これにより、ＳＣＦＵ２７０からメモリ・コントローラ４４０にイネーブルＦＩＦＯコマンドが送信される。ここでも、コントローラ１４０にリターン・フラグが返される。
【００８３】
メモリ・コントローラ４４０は、周期的にステータス情報をＳＣＦＵ２７０に送って、ＦＩＦＯのステータス、例えば、それが空きを有するか、空きがないか、又は満杯であるかを表示する。更に、命令シーケンスの実行中の或る時点で、コントローラは、クエリＦＩＦＯ命令を実行させて、その結果としてクエリ信号をＳＣＦＵ２７０に転送させ、それとともにメモリ・コントローラ４４０からＳＣＦＵに次のステータス断片が供給されると、リターン・フラグがコントローラ１４０に返される。中間の期間、コントローラ１４０は、図７に示されたようにストールする。
【００８４】
図７に示されたように、一旦ＤＭＡロジック４００が始動されて、ＦＩＦＯがイネーブルされると、ＤＭＡロジック４００とＴＣＭ２３０との間でデータ・ブロックが転送され、それとともに関連する制御信号もＤＭＡロジック４００と関連するメモリ・コントローラ４４０との間で受け渡される。従って、ＤＭＡロジック４００からの転送リクエスト信号には、転送すべきデータが伴い、メモリ・コントローラ４４０は、そのデータを受信したとき、ＤＭＡロジック４００に転送確認信号を送り返す。
【００８５】
どこかの段階で、ＤＭＡロジック４００を介してＴＣＭ２３０内に設けられたＦＩＦＯ中にデータが転送され続ける結果として、ＦＩＦＯが満杯になり、メモリ・コントローラ４４０からＳＣＦＵ２７０にフルＦＩＦＯ信号を発行することによってそのことがＳＣＦＵ２７０に表示される。この時点で、ＤＭＡロジック４００が転送しようとするそれ以上のデータは、図７に示されたホールド・ループに示されるように、ＴＣＭによって受け付けられない。
【００８６】
その間、データ・エンジン・コア上で実行される命令は、ＦＩＦＯ中のデータを利用しているが、或る時点で、ＦＩＦＯ中のそのデータの或る部分が最早必要でなくなる。この時点で、コントローラ１４０は、ムーブ・テイルＦＩＦＯ命令を実行する。それは、ＳＣＦＵ２７０にメモリ・コントローラ４４０へ制御信号を発行させて、ＦＩＦＯが最早満杯でない（すなわち、データ・エンジン・コアがまだ必要とするデータで最早満杯でない）ことを示す。この時点で、メモリ・コントローラ４４０は、ＤＭＡロジック４００からの保留中の転送リクエストの対象であるデータを受け入れることができ、従って、要求される転送確認信号を返し、ＤＭＡロジック４００上で実行されているホールド・プロセスを終わらせる。
【００８７】
ＦＩＦＯが最早満杯でないことを示す制御信号がメモリ・コントローラ４４０からＳＣＦＵ２７０に発行されると、ムーブ・テイルＦＩＦＯリターン・フラグもまたコントローラ１４０に返されて、コントローラが実行継続することをイネーブルする。
【００８８】
どこかの時点で、データ・エンジン・コア１５０は、ＴＣＭ２３０内にソフトウエアＦＩＦＯのセット・アップを必要としなくなるため、コントローラ１４０は、リリースＦＩＦＯ命令を実行するようにアレンジでき、それによって、ＳＣＦＵ２７０からメモリ・コントローラ４４０にディセイブルＦＩＦＯ制御信号を転送させることができる。
【００８９】
図８は、ＳＣＦＵ２７０を使用した本発明の実施の形態のデータ処理装置上で実現されるプロセスの別の例を示すトランザクション図である。特に、この例に従えば、データ・エンジン・コア１３０内のコントローラ１４０は、先行関数／タスクを呼び出す現行関数／タスクを実行するとき、その先行関数の完了後に現行関数が自動的にコールバックされるようにアレンジできる。図８に示された構成マネージャ４５０は、典型的には、図３に示されたデータ・エンジン・サブシステム１００の制御ロジック２１０内にあり、セッションの状態を維持するために使用されるセッション・レイヤの場所にインタフェースを提供する。同様に、図８に示された協調的オペレーシング・システム（ＯＳ）ブロック４６０は、制御ロジック２１０内にあるものとみなすことができ、タスクのスケジューリングを制御するために使用される。
【００９０】
図８に示されたように、ホスト・プロセッサ２０上で実行されるホスト・プロセス４１０は、セッションを開始させ、その後、ホスト・プロセスは、構成マネージャを構成するために構成マネージャ４５０にトランザクションを発行する。更に、ホスト・プロセスは、データ・エンジン・サブシステム１００の協調的ＯＳブロックに向けてのトランザクションを起動させ、問題になっている特別なセッションに関してそのブロックを構成／パラメータ化する。
【００９１】
一旦この構成が行われると、ホスト・プロセス１４０は、協調的ＯＳブロック４６０に向けて実行コマンドを発行し、データ・エンジンが今や処理タスクを開始できることを示す。この時点で、協調的ＯＳブロック４６０は、データ・エンジン・コアによって実行すべき第１のタスクを決定し、そのタスクを指定するタスク開始コマンドをコントローラ１４０に出力する。図８に示された例で、このタスクは、出力タスクであり、例えば、データ・エンジン・コアに何らかの出力データを生成させるものである。この時点で、コントローラ１４０は、必要に応じてデータ・パス・ロジックと共同して、データ・エンジン・コア１３０が出力タスクを実行することをイネーブルするために必要な入力データをデータ・エンジン・コアが有するか否かを判断する。
【００９２】
図８に示された例では、要求される入力データが現時点で存在しないことが判断されて、コントローラ１４０は、セット・コールバック命令を実行し、ＳＣＦＵ２７０に向けてセット・コールバック信号を発行し、それ自身をコールバック命令のパラメータとして指定する。更に、セット・トークン命令が実行され、ＳＣＦＵ２７０にセット・トークン信号が発行されて、ここでもそれ自身がその命令のパラメータとして指定される。セット・コールバック制御信号は、ＳＣＦＵに制御コマンドをデータ・エンジン・サブシステムに向けて発行させ、出力タスクのために必要なデータが利用可能になったときにコントローラ１４０がコールバックされるべきことを指示し、またセット・トークン制御信号は、ＳＣＦＵに情報を発行させて、その特別なコントローラ１４０にどのようにコンタクトするか、例えば、どの通信チャネルを使用するか等を指示する。しかし、図８に示された例で、この情報は、ＳＣＦＵ２７０によって、コントローラ１４０による先行命令コールの実行結果として要求される他の情報とバンドルされる。コール先行命令を実行することによって、ＳＣＦＵは、先行タスク（すなわち、出力タスクに先行するもの）を決定し、次にデータ・エンジン・サブシステム１００内の協調的ＯＳブロック４１０に向けてその先行タスクを指定するレジスタ・タスク・コマンドを発行させる。コールバック・リクエストおよび関連するトークン情報の存在もまた、協調的ＯＳブロック４６０に返されるこのレジスタ・タスク・コマンドにバンドルされる。
【００９３】
レジスタ・タスク・コマンドが協調的ＯＳブロック４６０によって受信されることにより、先行タスクの完了時にコントローラ１４０に対してコールバック操作が必要であることの指示と一緒に、先行タスクを協調的ＯＳブロック４６０に登録させる。
【００９４】
図８に示されたように、コール先行命令がＳＣＦＵ２７０によって実行されると、それは、コール先行リターン・フラグをコントローラ１４０に返させ、それが受信されると、コントローラ１４０は、出力タスクをエグジットして、協調的ＯＳブロック４６０に向けてタスク済コマンドを返すことができる。
【００９５】
コントローラ１４０からのタスク済コマンドを受信すると、協調的ＯＳブロック４６０は、それが保持するタスク・リストから次のタスクを得ようとする。介入するタスクが登録されていないため、リストから得られる次のタスクは、先に述べたレジスタ・タスク・コマンドの結果として登録されるそのタスク、すなわち、出力タスクに先行するタスクとなる。協調的ＯＳブロック４６０は、次にタスクに関する情報を得る目的でゲット・タスク情報コマンドを構成マネージャ４５０に発行し、その結果、構成マネージャ４５０から協調的ＯＳブロック４６０に必要な情報を含む送信タスク情報コマンドが返される。
【００９６】
その後、協調的ＯＳブロック４６０は、この例では、入力タスクであるが、そのタスクを指定するタスク開始コマンドをコントローラ１４０に発行することができる。これにより、必要な入力データを得るために、関連するデータ・パスによって複数の計算が実行される。そのとき、実行中のこの現在のタスクが協調的ＯＳブロック４６０に登録されるので、コールバック・リクエストもそのタスクに関連付けられ、従ってそのタスクに要求される必要な計算が完了すると、コントローラ１４０は、コール・コールバック命令を実行して、コール・コールバック制御信号をＳＣＦＵに転送させ、パラメータとして、このコールバック操作の結果として割り当てられるタスクに関する受け手としてコントローラ１４０を指定するトークンを指定するようにアレンジされる。コール・コールバック制御信号は、ＳＣＦＵに協調的ＯＳブロック４６０に向けてレジスタ・タスク・コマンドを発行させ、関連トークンを指定する。これにより、協調的ＯＳブロック４６０は、その関連トークンにタスクを登録する。更に、レジスタ・タスク・コマンドを発行することにより、コール・コールバック・フラグがＳＣＦＵからコントローラ１４０に返され、その後、コントローラは、協調的ＯＳブロック４６０にタスク済コマンドを発行することができる。
【００９７】
タスク済コマンドを受信すると、協調的ＯＳブロック４６０は、次にリストから次のタスクを得る。これは、トークン情報によってコントローラ１４０を受け手として指定するタスクであり、従って、前と同じように、協調的ＯＳブロック４６０は、構成マネージャ４５０と通信してそのタスクの必要な詳細を得る。要求されるタスクは、入力タスクに続くタスクであり、それは、先に述べた出力タスクである。従って、その出力タスクがタスク開始コマンドを介してコントローラ１４０に送られ、先に述べたトークンがこのコマンドをこの特別なコントローラに送るべきであることを指示する。この時点で、コントローラが入力をチェックするが、今回は、入力が利用可能であるため、出力タスクによって要求される必要な計算を次に実行することができる。出力タスクが完了すると、それに従って対応するタスク済信号が協調的ＯＳブロック４６０に返され、もしそれが協調的ＯＳブロックに割り当てられたセッションの最後のタスクであれば、タスク済コマンドがホスト・プロセッサ４１０に返されることになる。
【００９８】
図８を参照しながら模式的に説明した方式によって、ＳＣＦＵ２７０は、データ・エンジン・コアを単一コンテキスト最小オーバヘッドプロセッサ（例えば、一瞬でも別のタスクを実行させるために割込みを掛けることができない）として実現することを許容する。これは、１つのタスクが他のタスクをオペレーティング・システムのスケジューラ部に登録することを許容するアプリケーション・プログラミング・インタフェース（ＡＰＩ）をＳＣＦＵが提供するためである。オペレーティング・システムのスケジューラ部（これは、１つの実施の形態では、データ・エンジン・サブシステム１００内にある）は、スケジュールされたシステム・リクエスト・タスクにつながるシステム・イベントにも応答するので、システム全体は、標準的なイベント駆動型のソフトウエアがそうであると期待されるのと同じように振る舞うが、データ・エンジン・コアは、「一時に単一機能、（ｓｉｎｇｌｅ−ｆｕｎｃｔｉｏｎ−ａｔ−ａ−ｔｉｍｅ）」のタスク・レベルにあるアクセラレータの単純さを維持する。データ・エンジン・コア上で実行されて、他のタスクをオペレーティング・システムのスケジューラ部に登録するこのＳＣＦＵによって提供される能力を、ここで「タスクチェイニング」と呼ぶことにする。
【００９９】
理解されるように、そのようなタスクチェイニング機能をサポートする実施の形態を採用するとき、システム・プログラミング・インタフェースは、系統的でオブジェクト指向的なものにアレンジでき、ここで、タスクチェインのシーケンスは、構成可能で、それは、その時点以降、動的で自律的なやり方で実行される。
【０１００】
図８に示されたような実施の形態を採用するときは、協調的ＯＳブロック４６０が使用されて、タスクをデータ・エンジン・コアによって実行するようにスケジューリングするので、先に述べた図４のフロー図を修正することになることを理解されよう。特に、図４の工程３３０は、データ・エンジン・コアに現時点で割り当てられているすべてのタスクが完了したか否かを判断する決定ブロックとなる。それらのタスクが完了すると、１つの実施の形態では、工程３３０と３４０との間に１つの工程が介入して、そこにおいて保留中の新しいタスクがあるか否かが判断される。これは、協調的ＯＳブロックで判断される。もし存在すれば、それらの新しいタスクがデータ・エンジン・コアに割り当てられ、プロセスは、工程３３０に戻る。しかし、もし保留中の新しいタスクが存在しないと判断されれば、プロセスは、工程３４０に進む。
【０１０１】
図９は、ＳＣＦＵ２７０の使用を採用する１つの実施の形態のデータ処理装置上で実行できるタスクの別の例を示す。そのような実施の形態では、データ・エンジン内にスタブ・レイヤ４７０が備えられる。１つの実施の形態で、このスタブ・レイヤ４７０は、データ・エンジン・コア１３０のデータ・パス１５０内で実行されるソフトウエアとして設けられ、他方、別の実施の形態では、スタブ・レイヤは、ハードウエアとソフトウエアの混在した方式で実現され、そこでは、データ・パス１３０上で実行される何らかのソフトウエアに加えて、スタブ・レイヤの機能のいくつかがデータ・エンジン・サブシステム１００の制御ロジック２１０内に備えられる。タスク開始コマンドがデータ・エンジン・コアのコントローラ１４０に発行される先に述べた例と対照的に、この実施の形態では、そのようなタスク開始コマンドは、スタブ・レイヤ４７０に向けて発行され、それは、次に、タスク開始コマンドをコントローラ１４０に伝播させるか否かを決定する前に、何らかの初期工程を実行する。
【０１０２】
特に、図９に示されたように、セッションが開始されたとき、ホスト・プロセッサ４１０は、構成マネージャ４５０を構成し、更に、スタブ・レイヤ４７０に向けてパラメータ化コマンドを発行してスタブ・レイヤをその特別なセッション用に構成する。その後、タスク開始起動コマンドがスタブ・レイヤ４７０に発行され、スタブ・レイヤは、そのコマンドの受信に応答して、そのタスクを実行するために必要な特定のリソースが利用可能であるか否かをチェックする。そのようなリソースは、ここで必要条件とも呼ばれる。こうして、例えば、スタブ・レイヤ４７０は、プログラム・データ、定数テーブル・データ、状態割り当て等のようなすべての必要なリソースが存在するか否かを検査する。従って、一般論として、スタブ・レイヤ４７０は、タスクの実行に必要なすべてのものが、そのタスクを実行しようとするデータ・エンジン・コアが利用可能であるか否かをチェックするようにアレンジされることが分かる。
【０１０３】
図９に示された例で、スタブ・レイヤは、プログラム・メモリが初期化されていないことを判断し、それに従ってＳＣＦＵ２７０にリクエスト信号を発行する。この特別な例で、そのリクエスト信号は、「プログラム・メモリ未初期化」信号である。このリクエスト信号は、ＳＣＦＵ２７０にダウンロード・プログラム指示を構成マネージャ４５０に向けて発行させ、構成マネージャが必要なプログラムを要求されたプログラム・メモリ中にダウンロードするように仕向け、その後で、ダウンロード・プログラム応答信号をＳＣＦＵ２７０に返させる。この結果、ＳＣＦＵ２７０からスタブ・レイヤ４７０にリターン・フラグが発行される。その間、スタブ・レイヤ４７０は、「待機」ループに入ってリターン・フラグの受信を待つ。リターン・フラグが受信されると、スタブ・レイヤ４７０は、そのタスクのために必要なすべてのリソースが利用可能となったことを知り、それに従って、タスク開始コマンドをコントローラ１４０に発行してタスクを実行させる。この結果、一連の計算が発生し、そのタスクが完了すると、コントローラ１４０からホスト・プロセッサ４１０にタスク済コマンドが送られる。
【０１０４】
タスク済コマンドを受信すると、ホスト・プロセッサ４１０は、スタブ・レイヤ４７０に別のタスク開始コマンドを発行できるようになる。図９に示された例で、スタブ・レイヤ４７０が次にリソースをチェックするとき、それは、すべてのリソースが利用可能であることを判断し、それに従ってタスク開始コマンドをコントローラ１４０に発行して、要求された計算が実行されるようにする。その計算の途中で、コントローラ１４０は、例えば、同期化工程を実行するためにブロッキング割込みを発行する。図６に関連して先に議論したように、コントローラ１４０は、ＩＲＱ＿ｗａｉｔｆｏｒ＿ｂ（）信号をＳＣＦＵ２７０に発行して、制御ロジック２１０と協議しながら先に発行されたブロッキング割込みがその割込みを処理する割込みコントローラによって肯定されているか否かをＳＣＦＵ２７０にチェックさせる。その確認を待っている間に、ＳＣＦＵ２７０は、その割込みの受信についての検査を継続し、コントローラ１４０は、ストールする。
【０１０５】
図９の例で、ブロッキング割込みに関するこの受信が待機状態となる間、何らかのイベントが発生して、ホスト・プロセッサ４１０からＳＣＦＵ２７０にタスク・アボート・コマンドを発行させる。この例で、タスク・アボート・コマンドは、ＳＣＦＵ２７０に直接送られる。それは、スタブ・レイヤ４７０を含むデータ・エンジン上で実行されるソフトウエアがブロッキング割込みからの応答を待ってストール状態にあるためである。タスク・アボート・コマンドがＳＣＦＵによって受信されると、ＳＣＦＵは、アボートおよびエグジット・コマンドをコントローラ１４０に向けて発行させるようにアレンジされており、それは、コントローラにそれの現在のプロセスをアボートおよびエグジットさせ、その効果に対する肯定をＳＣＦＵ２７０に送らせる。その肯定を受信すると、ＳＣＦＵ２７０は、次にスタブ・レイヤ４７０に向けてラン・エグジット・コマンドを発行する。後者は、その時点で最早ストールしてなくて、従って、エグジット・ルーチンを指定するタスク開始コマンドをコントローラ１４０に送ることによって、エグジット・プロシージャを起動することができる。コントローラ１４０は、次に、データ・パス１５０と一緒にエグジット・ルーチン用の望みの計算を実行し、それに続いてタスク済コマンドがホスト・プロセッサ４１０に返される。
【０１０６】
図９の議論から明らかなように、スタブ・レイヤ４７０は、一般化されたタスク・モデルをデータ・エンジン上で実現することを可能にする。特に、ホスト・プロセッサからデータ・エンジンに割り当てられるタスクは、現時点で最早単に実行部を含むのではない。その代わり、実行部は、今は、タスク中に含まれるいくつかのメソッドの単に１つであって、例えば、ｉｎｉｔｉａｔｅ（コンストラクタ）、ｅｘｉｔ（デストラクタ）、ｓａｖｅ＿ｓｔａｔｅ、ｒｅｓｔｏｒｅ＿ｓｔａｔｅ等である。スタブ・レイヤは、ソフトウエア・レイヤを形成し、それは、１つの実施の形態で、最小の常駐プログラムの形を取る。ＳＣＦＵは、次に、例えば図９の上部に関して先に議論したように、スタブ・レイヤ４７０が発行するコマンドに応答することができる。更に、スタブ・レイヤは、ＳＣＦＵ２７０にそうするように命令されたときは、例外およびエグジット状態を処理することができる。
【０１０７】
ＳＣＦＵ２７０は、データ・エンジン・コアが多くのリソース上でタスクを起動することを許容し、それらのタスクは、共有システム・リソースの利用可能性および応答に依存して場合によって同時に実行され、データ・エンジン・サイドでブロッキング命令としてモデル化される。これらの因子のために、ホスト・プロセッサ４１０によってトラップされるエラー状態は、例えば、図９の下半分に関して議論したケースのようにデータ・エンジン・コアのストールをもたらし、その間、ブロッキング関数のリターンを待機することになる。図９に示された実施の形態で、ＳＣＦＵ２７０がホスト・プロセッサ４１０からのソフト・リセット信号、例えば、図９に示されたタスク・アボート信号に応答するのは、この可能性による。その結果、データ・エンジン・コアは、（図９の下半分に関して上で議論したように）実行されているスタブのエグジット・ルーチンおよびそれのブロッキング命令をアボートすることになる。
【０１０８】
図１０は、１つの実施の形態で、データ・エンジンに割り当てられた共有リソースを形成するメモリ領域を示す模式図であり、特に、そのメモリ部に関して施される２つのタイプの変更を示している。特に、セッションが開始されたとき、ホスト・プロセッサ２０は、その共有メモリ内の特別なメモリ領域間に境界を定義し、それに従ってプログラム（Ｐ）メモリ、データ・メモリの２つの異なる部分（ＸおよびＹと呼ぶ）および何らかのレジスタ・メモリ（図１０の６００に示されたような）間に境界６０２、６０４および６０６を定義する。レジスタ・メモリは、ＤＭＡロジックによって使用され、特に、ＤＭＡロジックを使用するいくつかの異なるデバイスは、それらがＤＭＡロジックを使おうとするとき、メモリのＤＭＡレジスタ領域に特別なレジスタをセットする。そしてＤＭＡロジックは、ＤＭＡ転送を実行する必要のあるときを判断するためにレジスタをレビューする。
【０１０９】
図１０に示されたように、もしＭＰ３デコード機能を備えたければ、ＳＣＦＵ２７０は、制御ロジック２１０を経由してメモリ・マネージャに適当な制御信号を発行し、それによってメモリの異なる部分をＭＰ３デコード機能で使用するように割り当てさせることができる。特に、ＭＰ３デコード・プログラム命令は、プログラム・メモリの特別な部分に割り当てることができ、ＭＰ３係数やパルス符号変調（ＰＣＭ）データのような特定のデータは、Ｘデータ・メモリ内に領域を割り当てることができ、またＭＰ３状態データは、Ｙデータ・メモリ内に領域を割り当てることができる。
【０１１０】
どこかの時点で、もしＭＰ３の第２のインスタンス化が必要になれば、それは、更なるＰＣＭデータのためにＸデータ・メモリの一部を割り当て、更に第２のＭＰ３デコーダに関連するＭＰ３状態データに対してＹデータ・メモリの一部を割り当てることを要求する。しかし、Ｘデータ・メモリを定義する既存の境界６０２、６０４がそのようなＰＣＭデータのために割り当てるのに不十分なスペースしか残していないため、このことは、ホスト・プロセッサのセッション・マネージャに対してセッションの変更を要求することになり、その結果、図１０に６１０として示されたように新しい境界６１２、６１４および６１６ができる。この時点で、Ｘデータ・メモリ中の付加的ＰＣＭデータ領域およびＹデータ・メモリ中のＭＰ３状態領域が定義できる。
【０１１１】
この後に、もし更にミキサ機能がインスタンス化されれば、それは、プログラム・メモリの領域をミキサ・プログラム命令用に、またＹデータ・メモリの一部をミキサ状態用に割り当てることを要求する。典型的に、ＭＰ３デコーダからの出力は、更なる出力を生成する前に混ぜ合わされるため、Ｘデータ領域内に２つのＰＣＭ領域を持つことは、最早不要である。図１０に６２０として示されたように、６１０と６２０との間の使用の変更は、ＳＣＦＵ２７０に適切な管理命令を実行させてメモリの動的実時間管理をイネーブルさせ、特に、ミキサ領域をプログラム・メモリ中に、またミキサ状態領域をＹデータ・メモリ中に確立させ、それと同時にＸデータ・メモリ中の第２のＰＣＭ領域を解放させることによって実現できる。注意すべきことは、この場合、ホスト・プロセッサによって設定された境界６１２、６１４および６１６が変わらないということである。
【０１１２】
本発明の実施の形態に関する上の議論のなかで、メイン処理ユニットは、１又は複数のデータ・エンジンの１つのレイヤに接続されるように述べてきたが、複数のデータ・エンジンを階層状にアレンジすることも可能である。例えば、メイン処理ユニットは、階層のより上位にデータ・エンジンとしてそれ自身を提供することができる。そのようなシナリオで、それは、リソース・マネージャ・ユニット（ＳＣＦＵ）を有し、それをより上位レベルのメイン処理ユニットに接続するサブシステムと相互作用する。最上位レベルのメイン処理ユニットは、たいがい汎用ＣＰＵであるが、どの中間のメイン処理ユニットもデータ・エンジンでよい。データ・エンジンも汎用ＣＰＵ、あるいは、単にそれらＣＰＵのコアで構わない。これに関して、メイン処理ユニットとそれのデータ・エンジンとの区別は、メイン処理ユニットがスタート・アップで共有リソースを制御することである。データ・エンジンは、メイン処理ユニットによってそれらに割り当てられた共有リソースを単に使用できるだけである。
【０１１３】
本発明の実施の形態についての上の説明から明らかなように、データ・エンジンは、ＳＣＦＵを通して駆動されるアクションに対して次のような複数の方法のうちの１つによって同期することが分かる。
−それは、アクションが終わるまでストールする。
−それは、第１のアクションが終わるまでストールする別のコマンドを発行する。
−それは、先行コマンドの状態（開始、終了、エラー等）をリクエストするコマンドを発行する。
−それは、データ・エンジン・コアのコントローラがアクセス可能なステータス・レジスタ・ファイルの指定された場所に直接的にステータス・ビットを書き込んで、それらを直ちに実行するように条件付でジャンプする。
又は、
−それは、タスクが終わったとき、そのタスクに与えられたアクションが完了するまでストールする。
【０１１４】
本発明の実施の形態についての上の説明から明らかなように、本発明の実施の形態は、次のような特徴を示すようにアレンジできる。
−データ・エンジン・サブシステムは、セッション・レベルで管理でき、リソースは、セッション・レベルでＤＥＳＳに割り当てられる。
−リソースは、システム活動を最小化することを目標にして、セッションの間、ローカルに使用できる。これにより、性能が改善され、エネルギー消費が削減できる。
および
−システム・プログラミング・インタフェースは、系統的でオブジェクト指向型のものとすることができ、ここで、タスク／関数のシーケンスは、構成可能で、それは、その時点以降、動的で自律的なやり方で実行される。
【０１１５】
本発明の実施の形態についての上の説明から明らかなように、そのような実施の形態は、データ・エンジンの特に効率的な実施を提供し、それは、１又は複数の共有リソースの使用を通して特にコスト効率的であり、また割り当てられた１又は複数の共有リソースの使用を管理するためのデータ・エンジン・サブシステムに対してデータ・エンジン・コアがマスタ・デバイスとして振る舞うようにできるＳＣＦＵロジックを提供することを通して、そのようなデータ・エンジンを含むデータ処理装置上で実行するためにソフトウエアを書き換える必要性が小さくなる。
【０１１６】
ここに特別な実施の形態について説明してきたが、理解されるように、発明は、それらに限定されず、発明の範囲内でそれらに対して多くの修正および追加を行うことができる。例えば、本発明の範囲から外れることなく独立項の特徴を後続の従属項の特徴と多様に組み合わせることができる。
【図面の簡単な説明】
【０１１７】
【図１】本発明の１つの実施の形態に従うデータ処理装置のブロック図。
【図２】本発明の１つの実施の形態に従う、図１のデータ・エンジンの少なくとも１つ内に備えられた要素をより詳細に示すブロック図。
【図３】本発明の１つの実施の形態に従う、図１のデータ・エンジンの少なくとも１つ内に備えられたコンポネントをより詳細に示すブロック図。
【図４】特定のタスクを本発明の１つの実施の形態のデータ・エンジンで実行させるために、セッションを初期化するときにデータ処理装置によって実行される工程を示すフロー図。
【図５】本発明の特別な実施の形態のホスト・プロセッサ、データ・エンジンおよび共有リソースの間で発生する各種トランザクションを示すトランザクション図。
【図６】本発明の特別な実施の形態のホスト・プロセッサ、データ・エンジンおよび共有リソースの間で発生する各種トランザクションを示すトランザクション図。
【図７】本発明の特別な実施の形態のホスト・プロセッサ、データ・エンジンおよび共有リソースの間で発生する各種トランザクションを示すトランザクション図。
【図８】本発明の特別な実施の形態のホスト・プロセッサ、データ・エンジンおよび共有リソースの間で発生する各種トランザクションを示すトランザクション図。
【図９】本発明の特別な実施の形態のホスト・プロセッサ、データ・エンジンおよび共有リソースの間で発生する各種トランザクションを示すトランザクション図。
【図１０】本発明の１つの実施の形態に従う、データ・エンジンに割り当てられたメモリ領域で実施される変更を示す模式図。
【図１】
2008541215.tif 000003
【図２】
2008541215.tif 000004
【図３】
2008541215.tif 000005
【図４】
2008541215.tif 000006
【図５】
2008541215.tif 000007
【図６】
2008541215.tif 000008
【図７】
2008541215.tif 000009
【図８】
2008541215.tif 000010
【図９】
2008541215.tif 000011
【図１０】
2008541215.tif 000012
【手続補正書】
【提出日】平成19年8月7日(2007.8.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ処理装置であって、
複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットと、
メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能な疎結合のコプロセッサであるデータ・エンジンと、
前記複数のデータ処理タスクを実行するときにデータ・エンジンが使用するためにメイン処理ユニットによってデータ・エンジンに割り当てることができる少なくとも１つの共有リソースと、を含み
前記データ・エンジンは、前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コアと、メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能なデータ・エンジン・サブシステムとを含み、
前記データ・エンジン・コアは、データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うように動作可能で、割当共有リソースの使用を管理するリソース・マネージャ・ユニットを含む、
を含むデータ処理装置。
【請求項２】
請求項１記載のデータ処理装置であって、データ・エンジンが実行すべき複数のデータ処理タスクは、データ・エンジン・コアによって実行可能で前記リソース・マネージャ・ユニットを前記マスタ・デバイスとして振る舞わせる命令セットのうちの少なくとも１つの命令を含む命令シーケンスを含み、前記少なくとも１つの命令が実行されると、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムに制御コマンドを発行し、それによって割当共有リソースの使用を管理するように動作可能である前記データ処理装置。
【請求項３】
請求項２記載のデータ処理装置であって、データ・エンジン・サブシステムは、リソース・マネージャ・ユニットから制御コマンドを受信し、その制御コマンドに依存して割当共有リソースの使用を制御するように動作可能な制御ロジックを含む前記データ処理装置。
【請求項４】
請求項２又は３記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの転送起動命令を含み、それが実行されると、リソース・マネージャ・ユニットが前記マスタ・デバイスとして振る舞うようにされる前記データ処理装置。
【請求項５】
請求項２から４のうちの任意の請求項記載のデータ処理装置であって、割当共有リソースとデータ・エンジン・コアとは、互いに同時に動作し、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つの同期命令を含み、それが実行されると、割当共有リソースとデータ・エンジン・コアとの間に同期が形成される前記データ処理装置。
【請求項６】
請求項５記載のデータ処理装置であって、メイン処理ユニットがデータ・エンジン・サブシステムのための新しい構成を指示するときに、データ・エンジン・コアは、割当共有リソースとデータ・エンジンとが同期する同期ポイントに到達させるために前記同期命令の１つを実行するよう動作可能で、同期ポイントに到達したあとのデータ・エンジン・サブシステム内でのみ新しい構成が有効になる前記データ処理装置。
【請求項７】
請求項２から６のうちの任意の請求項記載のデータ処理装置であって、データ・エンジン・コアは、複数の機能ユニットを含むデータ・パス・ロジックを含み、前記機能ユニットの１つがリソース・マネージャ・ユニットであり、データ・エンジン・コアは、更にシーケンス中の各命令に対してその命令をどの機能ユニットが実行するかを制御するように動作可能なコントローラを含む前記データ処理装置。
【請求項８】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、更に、データ・エンジン・コアが実行する前記命令シーケンスをスケジューリングするように動作可能なデータ・エンジン・コンパイラを含み、データ・エンジン・コアが実行可能な命令セットは、拘束条件を指定する少なくとも１つの拘束命令を含み、コンパイラは、前記拘束命令の１つに出会うと、拘束条件を考慮しながらシーケンス中の後続命令の実行をスケジューリングするように動作可能である前記データ処理装置。
【請求項９】
先行する任意の請求項記載のデータ処理装置であって、リソース・マネージャ・ユニットは、データ・エンジンと同期したデータ転送コントローラとして動作可能な前記データ処理装置。
【請求項１０】
請求項９記載のデータ処理装置であって、割当共有リソースがＤＭＡロジックを含み、リソース・マネージャ・ユニットは、ＤＭＡマスタ・デバイスとして振る舞い、前記ＤＭＡロジックを使用してデータの転送を起動させるように動作可能である前記データ処理装置。
【請求項１１】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースが割込みコントローラを含み、リソース・マネージャ・ユニットは、データ・エンジン・サブシステムを介して割込みコントローラに転送するように割込みを発行するように動作可能である前記データ処理装置。
【請求項１２】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースがメモリ領域を含み、リソース・マネージャ・ユニットは、前記メモリ領域の１又は複数部分の使用変更を起動するための制御信号を発行するように動作可能である前記データ処理装置。
【請求項１３】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、割当共有リソースがメモリ領域を含み、データ・エンジン・コアが実行可能な命令セットは、メモリ領域の動的実時間管理をイネーブルする少なくとも１つの管理命令を含む前記データ処理装置。
【請求項１４】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのスケジューリング命令を含み、それが実行されると、割当共有リソースが実行するためにタスクをスケジューリングさせる前記データ処理装置。
【請求項１５】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのレジスタ命令を含み、データ・エンジン・コアが第１のデータ処理タスクを実行する間にそれが実行されると、第２のデータ処理タスクが実行のために登録される前記データ処理装置。
【請求項１６】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのコールバック命令を含み、データ・エンジン・コアが第１のデータ処理タスクを実行中にそのタスクの遂行に関して少なくとも１つの条件が満たされていないと判断すると、データ・エンジン・コアは、コールバック命令を実行し、リソース・マネージャ・ユニットに、前記少なくとも１つの条件が満たされ次第第１のデータ処理タスクを再度呼び出すべきことをデータ・エンジン・サブシステムに向けて指示させ、それによって、前記少なくとも１つの条件が満たされるまでデータ・エンジン・コアが第１の処理タスクの実行を停止することを許容するように動作可能な前記データ処理装置。
【請求項１７】
先行する任意の請求項記載のデータ処理装置であって、データ・エンジンがスタブ・レイヤを含み、それは、データ処理タスクをデータ・エンジン・コアが実行すべきときに、データ・エンジン・コアがデータ処理タスクの実行を許容する前に、そのデータ処理タスクに必要な１又は複数の必要条件をチェックするように動作可能である前記データ処理装置。
【請求項１８】
請求項２に従属するときの請求項１７記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのリクエスト命令を含み、データ処理タスクに必要な少なくとも１つの必要条件が満たされていないとスタブ・レイヤが判断したとき、リクエスト命令が実行されて、リソース・マネージャ・ユニットにデータ・エンジン・サブシステムに向けてリクエスト・コマンドを出力させ、その少なくとも１つの必要条件が満たされるべきであることを要求する前記データ処理装置。
【請求項１９】
請求項２に従属するときの請求項１７又は１８記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットは、少なくとも１つのエラー処理命令を含み、データ処理タスクに必要な少なくとも１つの必要条件が満たされないとき、エラー処理命令が実行されて、リソース・マネージャ・ユニットに任意の必要なエラー状態を出力させ、データ処理タスクをエグジットさせる前記データ処理装置。
【請求項２０】
先行する任意の請求項記載のデータ処理装置であって、割当共有リソースは、データ・エンジンとデータ処理装置の処理ユニットとの間の通信を促進するデータ処理装置の１つの要素である前記データ処理装置。
【請求項２１】
請求項２に従属するときの先行する任意の請求項記載のデータ処理装置であって、データ・エンジン・コアが実行可能な命令セットのうちの少なくとも１つの命令は、フラグを返させて、命令の実行が成功であったか否かを表示するようにアレンジされ、それによって、フラグが存在しない場合にデータ・エンジン・コアがストールし、電力節約モードに入る前記データ処理装置。
【請求項２２】
複数のデータ処理タスクを実行させるように動作可能なメイン処理ユニットと、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能な疎結合のコプロセッサであるデータ・エンジンとを有するデータ処理装置を動作させる方法であって、
データ・エンジンに対して、前記複数のデータ処理タスクを実行するときにデータ・エンジンが使用する少なくとも１つの共有リソースを割り当てる工程と、
データ・エンジンのデータ・エンジン・コアを使用して前記複数のデータ処理タスクを実行する工程と、
データ・エンジンと割当共有リソースとの間の通信を管理するために使用されるデータ・エンジン・サブシステムを構成する工程と、
データ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うリソース・マネージャ・ユニットをデータ・エンジン・コア内に採用して、割当共有リソースの使用を管理する工程と、
を含む方法。
【請求項２３】
複数のデータ処理タスクを実行するように動作可能なメイン処理ユニットを有するデータ処理装置のための疎結合のコプロセッサであるデータ・エンジンであって、データ・エンジンは、メイン処理ユニットに代わって複数の前記データ処理タスクを実行するように動作可能であり、また前記複数のデータ処理タスクを実行するときに使用するためのデータ処理装置の少なくとも１つの共有リソースを割り当てられており、データ・エンジンは、
前記複数のデータ処理タスクを実行するように動作可能なデータ・エンジン・コアと、
メイン処理ユニットによって構成可能で、データ・エンジン・コアと割当共有リソースとの間の通信を管理するように動作可能なデータ・エンジン・サブシステムと、
データ・エンジン・コア内にあってデータ・エンジン・サブシステムに対してマスタ・デバイスとして振る舞うように動作可能で、割当共有リソースの使用を管理するリソース・マネージャ・ユニットと、
を含むデータ・エンジン。
【国際調査報告】
2008541215.tif 000013
2008541215.tif 000014
2008541215.tif 000015