JP6047747B2 - 制御タイプの実行モードとデータフロータイプの実行モードとの組み合わせによりタスクを並列に実行可能な複数の処理ユニットを有するシステム - Google Patents

Description

本発明は効率的及び効果的な方法でタスクを並列に実行可能な複数の処理ユニットを備えるシステムに関する。本発明は、例えば、埋め込みシステムに関連する効率及び消費電力の制約条件で集約的な計算を必要とする全ての分野で適用される。

半導体業界は、プロセッサのパフォーマンスを少なくとも個々のレベルでは大幅に高める確かな手段がもはやないという、当惑した状況に直面している。複数のプロセッサを使用しそれらを並列に動作させるシステムだけは、システムの計算能力を向上させるための手段としてまだ有望であるように思われる。実際、１９６０年代に実施された調査によれば、計算システムの効率に対する計算能力の比は、逐次システムに比べて並列システムの場合が潜在的にはるかに高くなるということである。ここで、特に最適化と効率を基本的に重要視する埋め込みシステムの分野において、並列システムがすぐに普及しなかった理由を把握するということが課題になる。一方で、技術的に、同じコンポーネント上に超並列構造体を統合するのは不可能であった（ただし、この種の並列性に合わせてアプリケーションを調整する際に簡単にプログラムできるＳＩＭＤ（「単一命令複数データ」）構造体の場合は例外）。他方、並列システムは一般的にはプログラミング及び開発するのがかなり難しい。このことは特に、同じ処理要素の複製に基づき、同一及び均一なアクセス及び通信インターフェイスを有する対称システム（均一システムとも称する）の場合に当てはまる。しかし、オペレーションを処理するための複数の専用プロセッサと特定のインターフェイスを使用する非対称システム（異種システムとも呼ばれる）の場合は、ほとんどそのことは当てはまらない。非対称システムは、例えば、ビデオ又はネットワークチップタイプの従来の周辺装置において、長い時間をかけて普及してきたが、それでも、並列に配置するプロセッサの数についてはまだ制限がある。非対称システムのこの普及は一般に、処理制御レベルがそれほど複雑でないアプリケーションの分野で起きているものであること、即ち、リソースの異種性によって、処理オペレーションのマッピングの複雑性だけでなく、処理オペレーションのマッピングの柔軟性も制限されていることに注意されたい。しかしながら、埋め込みシステムにも専用の多重処理システムが登場している。携帯電話通信の分野では、単一のチップ上に配置された「マルチコア」が登場している。このマルチコアは、信号処理用のＤＳＰ（「デジタルシグナルプロセッサ」）、通常の処理オペレーション用のＧＰＵ（「汎用処理装置」）、及びアナログ入力／出力ブロックを含み得る。携帯用ステレオ又はマルチメディアプレーヤーの分野では、汎用プロセッサに加えて、オーディオ（「ＭＰＥＧ Ａｕｄｉｏ Ｌａｙｅｒ」、「Ｄｏｌｂｙ Ｄ」、「ＤＴＳ」）又はビデオ（「ＭＰＥＧ」、「Ｈ２６４」）に専用の復号コアが登場している。一方、対称並列システムは、プログラミングの処理が難しいこと、及びプログラムの微調整が困難であることなどの理由であまり開発されていない。一般に、このようなプログラミング及び微調整に関する問題は、アプリケーションの高まる複雑化により深刻なものとなっている。埋め込みシステムでは、これらの問題が、これまで以上に多くの機能を統合したいという要望によって、及び処理の対象となるデータ量の継続的な増大によっても深刻化している。例えば、携帯電話では、通信機能がマルチメディア機能、位置決め機能、又はゲームと関連付けられている。携帯電話では、これまで以上に大きな容量のビデオセンサ及びこれまで以上に高いスループットのコンバータを使用している。更に、集約的計算タスクが、制御によって支配されタスクと一緒に実行され、アプリケーションのこのような種々の要素間で活発な対話が行われる。

本発明は更に、高い計算能力を提供する埋め込みシステムの分野に関する。マルチメディア、通信、又はリアルタイム処理システム等の分野での新しいアプリケーションは、消費される電力のレベル及び表面積の制御のためにこれまで以上の計算能力を求めている。前述したように、独立した方法で計算要素の処理能力を十分に高められない場合、ただ１つの現実的な解決策は計算要素を増やし、それらを並列に稼働させることである。このフレームワーク内では、新しい概念として並列システム・オン・チップが現在登場している。理論的に、並列システム・オン・チップでは、エッチング技術の進歩によって同じチップ上に統合可能になった追加のトランジスタを効率的に利用できる。埋め込みシステム用のプロセッサの極めて特殊なフレームワーク内でも、同じチップ上で実行コアの数を増やす傾向が非常に明確になっている。中期的に見れば、この傾向は、数十又は実際には数百の実行要素を備えたシステムの導入、さらに言えば当該システムの普及を表しているであろう。このようなシステムの中から、マルチプロセッサシステム・オン・チップを例にとる。このシステムは、通常、「マルチプロセッサ・システム・オン・チップ（Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）」を表す頭字語「ＭＰＳｏＣ」で指定される。ＭＰＳｏＣは、並列に動作可能な最小限の計算要素と完全な通信アーキテクチャとをチップ上に統合した完全なシステムである。現行のＭＰＳｏＣの通信アーキテクチャは、複数の巨視的要素から構成されるシステムに対応する接続システムアーキテクチャを再現する。このアーキテクチャは、通信バス、専用のチップ上ネットワーク（通常は「チップ上ネットワーク（Ｎｅｔｗｏｒｋ ｏｎ Ｃｈｉｐ）」を表す頭字語「ＮｏＣ」で示される）、専用の相互接続スイッチングシステム（通常は「クロスバー」という表現で示される）、入力／出力インターフェイス、ランダムアクセスメモリ（通常は頭字語「ＲＡＭ」によって示される）、ローカルメモリ、キャッシュメモリ、又は「スクラッチパッド」を備え得る。しかし、大体の場合、ＭＰＳｏＣの通信アーキテクチャは、この全てを組み合わせたものを有する。巨視的アーキテクチャに関してチップ上通信アーキテクチャの模倣における根本的な問題点は、巨視的アーキテクチャが非常に規則的な処理オペレーションに対して想定されるということである（それらが超並列計算処理オペレーション、ストリーム処理オペレーション、又はサーバータスクのいずれであろうとも）。埋め込みシステムのアプリケーションは、益々、それほど規則的でない処理オペレーション及び予想しがたい処理オペレーションの方へ向かう傾向にある。したがって、ＭＰＳｏＣの通信アーキテクチャは再考する必要がある。実際、ハイレベルなパフォーマンスを有し効率的なチップ上並列システム（ＭＰＳｏＣ等）を実現するには、数十又は実際には数百の計算コア又は処理要素を一斉に稼働させる必要がある。上記が当てはまらない場合、並列性の使用は最適でない。これは数十又は実際には数百の処理要素が正しく使用されないこと、即ち、処理要素の使用率がそんなに高くないことを示す。これ以降、処理要素は「処理要素（Ｐｒｏｃｅｓｓｉｎｇ Ｅｌｅｍｅｎｔ）」の頭字語「ＰＥ」で示す。しかし、最適な方法で並列性を利用するには、様々な問題が存在する。ソフトウェアレベルでの問題点は、アプリケーションの考えられる並列性の全体をコードで表現するための簡単且つアクセス可能なツールをプログラマに提供することである。ソフトウェアレベルでのもう一つの問題点は、このコードをコンパイルしたときに最大限の利益を得る能力である。しかし、このような非常に複雑なソフトウェアの問題は、本特許出願の主題ではない。

並列アーキテクチャを効率的に利用するには、不確定性のコントロール、通信のコントロール、及びチェックのコントロールという３つの側面で問題に対応する必要がある。実際に、潜在的な並列性をアプリケーションから抽出しプログラムで表現したら、この並列性を所与のハードウェアアーキテクチャ内で実際に実現できなければならない。例えば、ＭＰＳｏＣにおいて、プログラマによって行われるアプリケーション並列性の抽出から最大限の利益を得るには、多数の処理シーケンスをチップ上の全てのリソースに正常に配布する必要があり、これらのシーケンスはデータの依存関係又は実行制御の依存関係によって相互に関連し合っている。これ以降、このようなシーケンスは実行タスクと称することにする。したがって、実行タスクはＰＥでの処理オペレーションの実行に関係する。通常、ソフトウェアの専門家はそれを「スレッド」と称している。本特許出願の残りの部分では特に記述がない限り、「タスク」という用語は実行タスクを指すだけである。一方でＰＥを選択する方法について他方でＰＥを一緒に稼働させる方法について何ら考慮しない場合、プログラムで表現された並列性の全体をアーキテクチャで実際に実現できる可能性は極めて低い。ある意味では、アプリケーションの並列性の可能性をプログラムで表現するのと同じように、タスクの適切な制御を通してアーキテクチャの並列性の可能性を表現する手段を見つける必要がある。アーキテクチャの潜在的な並列性の有効利用に悪影響を及ぼす全ての状況を考慮に入れる必要がある。それにはまず、中央メモリ、ネットワーク、通信バス、又はタスクマネージャ等の必須の共有リソースへのアクセスによって制限されるリスクが挙げられる。更に、タスク間の相互依存関係を十分に正確な方法で管理できないリスク、又はそれらを管理するときにある特定のアプリケーションの動的特性に合わせて調整しなければならないリスクも含まれる。最後に並列実行の不確定性を制御できず、それによりプログラムを微調整するのが難しくなるリスクを含む。考慮の結果として、ＰＥを選択する方法及びＰＥを一緒に稼働させる方法を定義する実行モデルに至ることが必要である。同じチップ内で数十又は実際には数百のＰＥを一緒に効率的な方法で稼働させることは、現在、マイクロエレクトロニクス業界が対処しなければならない主要な課題の１つである。現在のところ、設計の観点から及びプログラムの微調整の観点からすれば、並列アプリケーションをプログラミングする技術は明らかに、シーケンシャルアプリケーションをプログラミングする技術より実現するのが難しい。プログラマがより利用し易くなるように並列プログラミングモデルを発展させるには、基礎をなす並列アーキテクチャの実行モデルをそれに合わせて適切に調整する必要がある。しかしながら、調整は、それによって現行のシリコン技術での実現効率を犠牲にすることがないように実施する必要がある。これは技術的な課題の１つであり、本発明でその対処方法を提案している。

歴史的な理由から、並列性の利用においてはアプリケーションタスクレベルでの並列性から利益を得られることを可能にする解決策を提案するよう努力してきた。実際には、命令レベルで高度な並列性を効率的に管理することができるアーキテクチャの定義に関する集約的な研究であっても、これらの研究方法はすぐにその限界を示した。同時に、埋め込みシステムの複雑さのため、単一の制御フローの形式で埋め込みシステムをモデル化するのは極めて困難又は非効率となる。したがって、ユーザ及びアーキテクチャの設計者は、タスクレベルで並列性を支持することについて意見が一致する。このため、埋め込みシステムの分野で現在観測されている根強い傾向として、複数のプロセッサコアを同じシリコン基板に統合し、同じ回路でのタスクの並列実行を可能にしている。同じシリコン基板上でそのようなアーキテクチャの並列性を利用するためにいくつかの解決策がすでに提案されている。最もよく知られているモデルは、同時マルチスレッディング（Ｓｉｍｕｌｔａｎｅｏｕｓ ＭｕｌｔｉＴｈｒｅａｄｉｎｇ）を表す頭字語による「ＳＭＴ」モデル、チップマルチプロセッシング（Ｃｈｉｐ ＭｕｌｔｉＰｒｏｃｅｓｓｉｎｇ）を表す頭字語による「ＣＭＰ」モデル、及びチップマルチスレッディング（Ｃｈｉｐ ＭｕｌｔｉＴｈｒｅａｄｉｎｇ）による「ＣＭＴ」モデルである。以降、命令の集合の実行を管理できる処理ユニットは、１つの命令しか実行できない計算ユニットと区別する。

しかし、ＳＭＴ、ＣＭＰ、及びＣＭＴモデルは、埋め込みシステムの問題に部分的にしか対処できない。このことは特に多くの問題点を示している。更に言えば、以下に詳述するように、これらのモデルはアプリケーション内で共存可能な種々の処理クラスについて何の区別も行わない。これらのシステムは、最適化されていない計算プリミティブ（基本形）に構築されているので、電力消費量、コスト／パフォーマンス比、及び動作信頼性についてアプリケーションの要件に適さないことがしばしばである。このようなことが主要な問題点である。

ＣＭＰタイプの解決策の場合、規則的な処理オペレーションと不規則な処理オペレーションとの区別が行われるようになる。これには、集約的な処理オペレーションに専用の計算ユニットを統合するアーキテクチャで実現される解決策が必要であり、不規則な処理オペレーションは汎用プロセッサのシステムソフトウェアで処理される。しかし、以下に詳述するように、システムバスを使用すると、アーキテクチャの反応性が低下すると共に、システムソフトウェアが計算ユニットの使用を最適化できなくなる。

このような問題点を最小限に抑えることを試みるために、米国特許出願公開２００５／０１４９９３７Ａ１号明細書『Ａｃｃｅｌｅｒａｔｏｒ ｆｏｒ ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ』では、計算ユニット間の同期のメカニズムを専用の構造によって処理することを提案している。しかし、これはタスク間のデータ転送の問題に対して何の解決策も提供していない。

一方、米国特許出願公開２００４／００８８５１９Ａ１『Ｈｙｐｅｒｐｒｏｃｅｓｓｏｒ』では、高いパフォーマンスを発揮するプロセッサとの関連でタスクの並列性に対する解決策を提案している。しかし、これは、特に不確定性及びコスト的な理由で埋め込みシステムには適用されない。

本発明の目的は、特に前述した問題点を軽減することである。数百の計算ユニットを個別に均一管理することは難しいので、本発明では２つのレベルでタスクの管理の階層化を提案する。計算ユニットは複数のユニットブロックに分類され、本発明ではブロックにおけるタスク管理のモードと各ブロック内におけるタスクの管理モードとを提案する。これ以降、計算ユニットのブロックは「クラスタ」と称する。所与のクラスタ内では、非常に動的な実行モデルにより計算ユニットの使用をローカルで最適化することができ、結果としてクラスタ内での同一のタスクセットの処理が実行ごとに変化し得る。クラスタ間では、より静的な実行モデルにより、コンパイル中及びリンク編集中に所与のクラスタへのタスクの割り当てが可能になり、結果として実行ごとに同一のクラスタによって同一のタスクセットが常に処理される。コンパイル中及びリンク編集中には情報の経路を保証する通信タスクも静的に管理される。本発明に係る２レベル実行モデルを適用することで、所与のクラスタに割り当てられたタスクがリモートクラスタによって生成されたデータを正式に使用する必要があるという状況が発生した場合、そのタスクの実行は同一のモデルで、あたかもローカルクラスタのデータしか使用していないかのように行われる。これは、「ダイレクトメモリアクセス」を意味する表現による「ＤＭＡ」タイプの通信タスクによって可能である。このタスクでは可用性又はクラスタ外の宛先との間の伝送を信号で知らせ、データ転送を処理する。

このため、本発明の主題は、タスクの並列実行を可能にする複数の処理ユニットと、通信ネットワークとを備えたシステムである。処理ユニットは複数のユニットクラスタに編成され、各クラスタはローカルメモリを備える。システムは各ユニットクラスタにタスクを静的に割り当てる手段を有し、この結果、アプリケーションの所与のタスクはアプリケーションの実行ごとに同じユニットクラスタで処理される。各ユニットクラスタは、処理ユニットのそれぞれにタスクを動的に割り当てるためのクラスタ管理手段と、ローカルメモリ内にタスクを実行するための空間を有する。その結果、アプリケーションの所与のタスクはアプリケーションの実行ごとに同じ処理ユニットで処理されなくてもよい。クラスタ管理手段は、タスクを管理するための手段と、処理ユニットを管理するための手段と、ローカルメモリを管理するための手段と、通信用処理ユニットを伴う通信を管理するための手段とを有し、このような管理手段は一斉に互いに連携して動作する。

有利には、各クラスタが備えるローカルメモリは、クラスタ専用とすることができる。

一実施形態では、処理ユニットのクラスタはチップ上に配置することができ、ユニットクラスタはチップ上のネットワークを介して互いに通信する。システムはまた、中央メモリを備えることもできる。

システムは、各ユニットクラスタにタスクを静的に割り当てるためのリンクをコンパイル及び編集するための手段を有することができる。

有利には、ユニットクラスタに割り当てられたタスクが別のユニットクラスタで生成されたデータを消費する必要がある場合、データが生成されるクラスタ内でデータ送信タスクを実行することができ、このデータ送信タスクは、データが消費されるクラスタ内で実行されるデータ受信タスクにデータを送信することができる。結果として、データを消費するタスクは、同じ動的なリソース割り当てモードで、ローカルで生成されたデータしか消費していないかのように実行され得る。送信タスクと受信タスクとの間の通信に専用のメモリ空間は、関係する２つのクラスタのうちのいずれかのクラスタのローカルメモリ内で予約することができる。有利には、送信タスクは、送信タスクと受信タスクとの通信に専用のメモリ空間を飽和させないように一時的に中断され得る。送信タスクのスループットもコンパイル中に決定することにより、受信タスク用の空間の飽和の可能性がないようローカルメモリ内に受信タスク用の十分な空間を割り当てることが可能である。

例えば、データ送信タスクとデータ受信タスクは、データが生成されるクラスタと、データが消費されるクラスタにそれぞれ静的に割り当てることが可能である。一実施形態で、送信タスクと受信タスクは、クラスタ内のローカルメモリとデータを直接やりとりする専用の実行手段によって実行され得る。

例えば、データが消費されるクラスタは、まだ使用できるメモリ空間に応じてデータを生成するクラスタにクレジットをディスパッチし、データを生成するクラスタは受信したクレジットに応じてデータ送信スループットを調整することができる。送信タスクと受信タスクとの間の通信に専用のメモリ空間が所与のクォータを超えて使用されると、受信タスクを管理するクラスタ用のクラスタ管理手段はまた、送信タスクを管理するクラスタ用のクラスタ管理手段に割り込み信号をディスパッチし、専用のメモリ空間がクォータ以内で使用されるようになると再開信号をディスパッチすることができる。

一実施形態では、ローカルメモリを管理するための手段は、ローカルメモリによって形成されるアドレス指定空間を断片化しないように、ローカルメモリ内の空間を一定の細分レベルで割り当てることができる。別の実施形態では、ローカルメモリを管理するための手段は、ローカルメモリ内の空間を可変の細分レベルで割り当てることができる。

一実施形態では、ローカルメモリを管理するための手段は、ローカルメモリ内の空間のデータを消費する必要があるかもしれないタスクの数を示すカウンタを使用して、ローカルメモリ内の空間を解放することができる。タスクがデータ項目へのアクセスの必要がなくなるとすぐに、カウンタの値が変更される。このため、カウンタの値により消費タスクがまだ残っているかどうかを明らかにすることができる。消費タスクがもう残っていない場合は、メモリ空間を解放することができる。

一実施形態では、ローカルメモリを管理するための手段は、ローカルメモリ内の空間のデータを消費する必要があるかもしれないタスクのリストを使用して、ローカルメモリ内の空間を解放することができる。ローカルメモリを管理するための手段は、関連付けられたメモリ空間を解放するために、リストのタスクがデータ項目をもはや必要していないことに準じた情報項目を待ち受ける。

例えば、タスクを管理するための手段は、実行の前提条件を満足する割り振り可能なタスクを判別するためにタスクを選択するためのモジュールと、処理ユニットに割り振り可能なタスクを割り当てるためのスケジューリングモジュールとを有する。有利には、タスクを選択するためのモジュールは、並列マルチタスクタイプの実行モードとデータフロータイプの実行モードにおいて同一時に実行の前提条件を満たす割り振り可能なタスクを判別することができる。実行の前提条件は、処理オペレーションの優先順位、及び／又はデータの可用性、及び／又は作成されたデータを格納するためのメモリ空間の可用性、及び／又はクラスタのローカルイベント又はクラスタの外部イベントを有し得る。

有利には、送信タスクはいくつかのユニットクラスタにデータを同時に送信することが可能であり、これによりいくつかの消費タスクに同じデータが同時に提供される。いくつかの送信タスクを同一のユニットクラスタで同時に実行し、いくつかの消費タスクに様々なデータを同時に提供することができる。

一実施形態では、システムはＤＭＡタイプの送信タスク及び受信タスクの管理に専用の手段を有することができる。システムはまた、少なくとも１つの入力／出力インターフェイスを有することもできる。

システムは、例えば、処理ユニット上で並列にタスクを実行することにより、モーフィングアプリケーションを実行することができる。システムはまた、処理ユニット上で並列にタスクを実行することにより、ハフ変換を実施するアプリケーションの実行を可能にする。システムは更に、パイプラインモードでタスクを実行することにより、ＭＰＥＧ復号アプリケーションの実行も可能にする。

例えば、ローカルメモリ内の空間は、これらの空間のデータを消費したタスク数のカウンタ、又はローカルメモリ内の空間のデータを消費したタスクのリストを使用することにより、解放することができる。

本発明の主な利点は、制御タイプとデータフロータイプの両方の実行モードの又は２つのモードを組み合わせた、複数のＰＥを備えるプラットフォームにおいてタスクの並列且つ同時実行を可能にすることである。したがって、本発明は埋め込みシステムのフレームワーク内で使用できる。

本発明の他の特徴及び利点は、添付の図面に関連して記載された以下の説明を読むことにより、明らかになる。

ＳＭＴアーキテクチャの一般的なモデルと動作例とを図表によって示す。 ＣＭＰアーキテクチャの一般的なモデルと動作例とを図表によって示す。 ＣＭＴアーキテクチャの一般的なモデルと動作例とを図表によって示す。 本発明に係るいくつかのクラスタを備えた例示的なアーキテクチャをブロック図によって示す。 本発明に係るクラスタの例示的なアーキテクチャとその動作原理とをブロック図によって示す。 本発明に従って「モーフィング」アプリケーションを実現するためのタスクを図表によって示す。 本発明に係る「モーフィング」アプリケーションでの予測及びブロック変換をブロック図によって示す。 本発明に係る「モーフィング」アプリケーション中にクラスタで実行されるタスクをタイムチャートによって示す。 本発明に係る「モーフィング」アプリケーション中の変換テーブルの更新時に発生するやりとりをタイムチャートによって示す。 本発明に係る「モーフィング」アプリケーション中のタスクの入力フローの中断時に発生するやりとりをタイムチャートによって示す。 本発明に係る「モーフィング」アプリケーション中の通信をタイムチャートによって示す。 本発明に係るＭＰＥＧ−２復号アプリケーションでのデータの流れを図表によって示す。 本発明に係るＭＰＥＧ−２復号アプリケーション中にマップされ転送されるタスクを図表によって示す。 本発明に係るＭＰＥＧ−２復号アプリケーション中の通信の管理をタイムチャートによって示す。

埋め込みシステムのレベルのアプリケーションでは、処理能力を拡大することが新たに必要となっている。これまで以上に、高度な意思決定は下位レベル及び中レベルの情報処理タスクに基づいて行われる必要がある。従来の例としては、車両の走行を支援する道路標識の検知が挙げられる。そのようなアプリケーションの場合、下位レベルの処理オペレーションにて、第一に画像の明るさとコントラストを正規化し、次にＳｏｂｅｌフィルタリング等を使用して輪郭を抽出する必要がある。この後、基本形状のハフ変換又は認識等の中位レベル処理が実行される。最後に、複雑な形状認識又は関連処理オペレーションと共に、メモリに格納されたデータベースが最上位レベルで適用される。これらの上位処理オペレーションは場合によっては視差修正等、下位中間相と結び付けることが可能である。逆に、計算上、集約的な下位レベルの処理オペレーションを、外部データ又は前の処理オペレーションから生じるデータによって直接管理することが可能である。これは特に最新世代のビデオ圧縮アルゴリズムの場合に行われる。前述したように、埋め込みシステムの分野では、同一のシリコン基板上に複数のＰＥを統合することにより、当該処理オペレーションのすべてを同一の回路上で並列に、特にＳＭＴ、ＣＭＰ、又はＣＭＴモデルによって実行できるようにする傾向が、現在、根強く観察される。

図１では、従来技術に係る一般的なＳＭＴモデルを略図で示すと共に、このモデルの動作例も示す。図の上部のブロック図は、システムソフトウェア１、又は「ＯＳ」（「オペレーティングシステム」を示す表現）を示すものであり、このシステムソフトウェア１は処理オペレーションを単一の制御リソース２（又は従来技術で知られている「タスクディスパッチャー」）に提供する。制御リソース２は処理オペレーションをｎ個の計算ユニットＦＵ１〜ＦＵｎに再配布する。「ＦＵ」は「機能ユニット」を表す頭字語であり、図１にはユニットＦＵ１、ＦＵ２、ＦＵ３、及びＦＵｎが示されているだけである。各サイクルで、制御リソース２は、ユニット同士で共有される中央メモリ３から送られてくるデータの可用性とオペレーションの発生し得るランダムな変化とに従って命令をユニットＦＵ１〜ＦＵｎに同時に割り当てる。図１の下部の略図において、各正方形は命令を表している。左右に延びる正方形の行は、ユニットによって時間順に実行される命令を示している。上下に延びる正方形の行は、ユニットＦＵ１、ＦＵ２、ＦＵ３、ＦＵｎによってそれぞれ実行される命令を示している。一タスクは、同じテクスチャの正方形によって表わされる一連の命令からなる。命令間の黒色のダッシュは、命令割り当て及び制御タスクを表す。クロスドアウトされた正方形は、データやリソース等の依存関係により、ユニットによって使用されない時間間隔に相当する。この第１の解決策は、例えば、最新世代の「Ｉｎｔｅｌ」（商標）、「ＩＢＭ」（商標）、又は「ＨＰ Ａｌｐｈａ」（商標）プロセッサで実現されている。この解決策は、複数のプログラムカウンタを使用することにあり、複数の命令フローから生じる命令を計算ユニットに入力する。このため、プロセッサのパフォーマンスの場合のように、制限されるタスク間の依存関係、プロセッサによって認識される命令レベルでの並列性、又は「命令レベル並列度」を表す命令の「ＩＬＰ」が増大する。これらの解決策は、命令の読み取り及び配布の段階が非常に複雑になるため、実施するのが難しい。したがって、これらのアーキテクチャは回路の大規模化を招き、電力消費がコンポーネントあたり１００ワットを超えるようになる。これでは埋め込みシステムの制約に対応できない。

図２では、従来技術に係る一般的なＣＭＰモデルを略図で示すと共に、このモデルの動作例も示す。この解決策は、実現するのが比較的に簡単であるため、一般的に埋め込みシステムに最適である。図上部のブロック図は、処理オペレーションを単一の制御リソース１１に提供するシステムソフトウェア１０を示す。制御リソース１１は処理オペレーションをｎ個の計算ユニットＦＵ１〜ＦＵｎへ再配布する。尚、図２にはユニットＦＵ１、ＦＵ２、ＦＵ３、及びＦＵｎが示されているだけである。タスクの実行準備が整ったかどうかの判断は、制御リソース１１に任される。ＦＵ１〜ＦＵｎの中のいずれかのユニットが解放されるとすぐに、中央メモリ１２からデータがロードされ次第処理されるタスクがそのユニットに割り当てられる。図２の下部の略図において、各正方形は命令を表している。左右に延びる正方形の行は、ユニットによって時間順に実行される命令を示している。上下に延びる正方形の行は、ユニットＦＵ１、ＦＵ２、ＦＵ３、ＦＵｎによってそれぞれ実行される命令を示している。一タスクは、同じテクスチャの正方形によって表わされる一連の命令からなる。命令間の黒色のダッシュは、命令割り当て及び制御タスクを表す。データのロードは、クロスドアウトされた領域で表わされる。この解決策の原理は、命令に従ってではなくユニットの可用性に応じてタスクをユニットに同時に配布するというものである。各ユニットは自身に割り当てられたタスクを次々に終了まで実行する。これらのアーキテクチャは、対称構造体と非対象構造体の２つのファミリに分割される。非対称構造体は、所与のアプリケーション分野向けに最適化された異種の計算ユニットＦＵ１〜ＦＵｎを統合するものであり、これらのリソースへのタスクの配布はコンパイル時に前もって識別される。コンパイル時にソフトウェアのパーティショニングが実行されるため、実行時におけるタスクの動的な配布のメカニズムを簡略化することができる。このような所謂「アプリケーションドリブン」型の解決策は、特に、「ＯＭＡＰ」（商標）、「ＶＩＰＥＲ」（商標）、「ＰＮＸ」（商標）、又は「Ｎｏｍａｄｉｋ」（商標）のプラットフォームに組み込まれている。一方、対称構造体は、同種の計算ユニットＦＵ１〜ＦＵｎの統合に基づいている。ユニットＦＵ１〜ＦＵｎはＩＢＭのＣｅｌｌｓプラットフォームや「ＡＲＭ」（商標）のＭＰＣｏｒｅプラットフォームのように汎用的なものとすることも、Ｃｒａｄｄｌｅ ＴｅｃｈｎｏｌｏｇｉｅｓのＣＴ３４００（ＭＰＥＧ４−ＡＶＣ符号化／復号化用に最適化）のように所与のアプリケーション向けに最適化することもできる。対称型の解決策の場合はかなり広範に及ぶ問題を対象とすることができる。一方、非対称型の解決策の場合は明確に識別されたアプリケーション分野向けに最適化される。

図３では、従来技術に係る一般的なＣＭＴモデルを略図で示すと共に、このモデルの動作例も示す。図の上部のブロック図は、処理オペレーションを単一の制御リソース２１に提供するシステムソフトウェア２０を示す。制御リソース２１は処理オペレーションをｎ個の計算ユニットＦＵ１〜ＦＵｎに再配布する。尚、図３にはユニットＦＵ１、ＦＵ２、ＦＵ３、及びＦＵｎが示されているだけである。タスクの実行準備が整ったかどうかの判断は、制御リソース２１に任される。ＦＵ１〜ＦＵｎの中のいずれかのユニットが解放されるとすぐに、データがロードされ次第処理されるタスクがそのユニットに割り当てられる。図３の下部の略図において、各正方形は命令を表している。左右に延びる正方形の行は、ユニットによって時間順に実行される命令を示している。上下に延びる正方形の行は、ユニットＦＵ１、ＦＵ２、ＦＵ３、ＦＵｎによってそれぞれ実行される命令を示している。一タスクは、同じテクスチャの正方形によって表わされる一連の命令からなる。命令間の黒色のダッシュは、命令割り当て及び制御タスクを表す。データのロードは、クロスドアウトされた領域で表わされる。各ユニットは複数のタスクを同時に管理することができる。キャッシュメモリの欠陥等が原因でタスクが無効になるとすぐに、ユニットはそのタスクを新しいタスクに置き換える。この場合、ユニット内でタスクの切り替えが発生してもコンテキストのロードに関するペナルティは発生しない。この解決策は、前述したＳＭＴモデルとＣＭＰモデルを結び付ける。これには、ＣＭＰの概念を拡大して、該当するユニット上で複数のタスクを実行可能にする必要がある。差し当たり、この解決策が想定されるのはサーバータイプの解決策のフレームワーク内に限られる。特に、「ＳＵＮ」（商標）の未来世代のサーバーではこの技術が利用される（まずはＵｌｔｒａＳｐａｒｃ ＩＶプロセッサを搭載、次にＮｉａｇａｒａプロセッサを搭載）。

前述したように、図１、２、及び３に示したＳＭＴ、ＣＭＴ、及びＣＭＴモデルは、埋め込みシステムの問題に部分的にしか対処していない。実際、これらのモデルでは、アプリケーション内に共存可能な種々の処理クラス間の区別は行われない。したがって、制御に大きく支配される処理オペレーションは、同等の方法で、即ち、同一のＰＥ上で、その実行時間の観点から規則正しく重要な意味を持つ処理オペレーションとして処理される。計算ユニットは規則正しい処理オペレーションと極めて不規則な処理オペレーションをサポートする必要があり、この結果、システムは最適化されない計算基本形で構築される。したがって、このような従来技術のモデルで構築されたシステムは、電力消費量、コスト／パフォーマンス比、及び処理信頼性に関してアプリケーションの要件を満たさないことがしばしばある。しかし、規則正しい処理オペレーションと不規則な処理オペレーションとを区別することにつながる、ＣＭＰタイプの既存のいくつかの解決策について述べる必要がある。これらの解決策には、集中的な処理オペレーションに専用の計算ユニットを統合するアーキテクチャで実現される解決策が含まれる。不規則な処理オペレーションは、汎用プロセッサ上のシステムソフトウェアで扱われる。集中処理オペレーション専用の計算ユニットを統合すると、最適化を行ってこれらのアーキテクチャのパフォーマンス又はエネルギー効率をかなり改良することが可能であるが、アーキテクチャの要素間の非高率な通信により、残念ながら最適化の利点が全て失われてしまう。実際、処理タスクは互いに交信する必要があり、更にシステムソフトウェア及び制御処理オペレーションと通信する必要がある。これらのシステムでは、システムバスによって通信が行われるため、遅延レベルと帯域レベルの両方で大きな代償を払うことになる。このため、これらのシステムは、制御情報の伝送における遅延、及びデータ転送の妨げとなるようなスループットによって悪影響を受ける。この結果、アーキテクチャの反応性が低下し、システムソフトウェアが計算ユニットの使用を最適化できなくなる。概して、従来技術が、埋め込みシステムの問題に対処する解決策を提供していないことは明らかである。特に、データへのアクセスが問題になる高密度の計算要素に関係する点、及び特に共有リソースへのアクセス時における実行の不確定性に関する点が挙げられる。

実際には、計算ユニットの密度が非常に高い場合にデータアクセスに関する問題が発生する。ユニットが多数存在する場合、潜在的な並列性が実際に実現されるようにそれらのユニット全てを提供するには大量のデータが必要になることを示している。しかし、ほとんどの場合は交換バスが１つしかないことにより、外部ＤＲＡＭへのアクセスが必然的に制限される。したがって、１つの交換バスでは１つの計算ユニットを適切に提供するのにもとても十分とは言えないことが多いので、このＤＲＡＭに基づいて全ての計算ユニットを提供することは不可能である。このことは、ダイナミックメモリと計算ユニットとの間のパフォーマンスの差に起因するものであり、これを受けて１９８０年代からプロセッサ用にキャッシュメモリを導入することとなった。このため、このような並列性の高いアーキテクチャにおいてチップ上にメモリを搭載しないのは考えられないことである。外部メモリへのアクセスは制限要因となるので、処理中にチップのメモリ上にすでに存在するデータを利用できるようにすることが必要である。これらのデータは外部メモリから送信される。したがって、それらは異なる処理によって事前に送還されているか、或いは新しい処理オペレーションに与えるために処理によりローカルに作成されている。このことは、対象となる全てのＰＥを提供するには通信インターフェイスに強い圧力がかかることを示している。別の言い方をすると、チップ上に中央メモリが存在する場合、ボトルネックはこの中央メモリへのアクセスのレベルに位置する。メモリが分散されている場合、ボトルネックは通信インターフェイスのレベルに位置する。したがって、計算ユニット間の通信に応じて高い接続性を維持できるインターフェイスが必要である。通信の接続性において、接続性が不十分な場合は並列性のボトルネックが生じる可能性があり、逆に通信インターフェイスが過度に大きくなるとシリコン効率とエネルギー効率が劇的に低下するという高いリスクが存在する。最後に、非常に多くのＰＥを制御する場合も問題が生じる。全てのユニットの制御が一元化されると、単一の制御モジュールで単一の同期ポイントが構成され、そのことは実行時に並列性を利用する際に制限要因となる可能性が非常に高いからである。他方、数十又は数百のＰＥをそれぞれ独立制御することには、少なくとも慎重を要する。実際には、タスクのスケジューリングについて適切な決定を下す必要がある場合は、上流の処理オペレーションの状態を把握する必要がある。これらの処理オペレーションは場合によっては離れたＰＥで実行され、その場合通信システムには更に追加の負荷が生じる。データストリームの処理等の静的なスケジュールによる極めて規則的な処理オペレーションを除き、実行制御なしのこのアーキテクチャは効率的でない。更に、そのようなアーキテクチャの場合は、不確定な動作によりプログラムの微調整が難しくなる。要約すると、完全な分散型のアーキテクチャでも高度に統一されたアーキテクチャでも、実行レベルで満足のいくパフォーマンス及び効率を取得することはできない。ただし、普通に並列又は厳密にデータフローになるアプリケーションについては例外である。アプリケーションが任意のレベルで制御を必要としたらすぐに、この２つの極端な手段の間で平衡中間体を見つけることを想定する必要がある。しかし、これはまた、静的制御と動的制御との間で平衡体を見つける必要がある。

更に、並列プログラミングの主な課題は、特にストレージや通信等の共通のリソースへのアクセスにおける不確定要素の制御である。実行に関するランダムで予測できない変化や遅延を考慮したときの考えられる多様な動作は、逐次プログラムを制御する動作よりもかなり複雑である。特に、そのようなシステムを微調整してプログラミングすることは場合によっては非常に困難、又は全く不可能である。アクセスの同時発生、相互ロックアップ、種々の矛盾といった様々なリスクがある。一般的な並列システムでは、システムの観測可能な状態を適切に定義し、それによって所与の時点で出力動作が観測された理由を把握することは実際には不可能である。同じデータを同じ順番及び類似の同期条件で再生しても、システムの種々のランダムで予測できない変化により、同じ出力動作が観測されるとは限らない。システム内で発生する全て事をそれぞれの時点で完全に制御することは、当然ながら、求められている対応ではない。これを行うと、例えば種々の要素間で特定の数の厳しい同期条件を課すことによって、システムのパフォーマンスが大幅に低下するというリスクを冒すことになるからである。現実に、追及しなければならない目標は、実行におけるランダムで予測できない変化とは合理的に独立した実行を獲得することである。これはまさに、実行の決定性について述べる際に意図するところである。不確定性を制御しないで実行することに関連するリスクは数多くあるからである。まず、通信に対する制御を欠くと、入力データの供給が乏しくなり、このことは並列性には不利益となる。通信に対する制御の欠如はまた、データ着信の制御にも悪影響を及ぼす。通信が確定的でなくなると、通信ネットワークに大きな負荷がかかる場合又は相互ロックアップが存在する場合に、特定のデータアイテムがその宛先に到達したかどうかを確認する手段はもはやなくなる。通信時間の確定性の欠如によりデータ場所が不足すると、システムのグローバルな状態を定義することは不可能である。ただし、純粋なデータフロータイプの単純化したアプリケーションの場合は例外である。更に、微調整及び実行の制御を行うことも不可能である。実行の制御が欠如すると、共有リソースへのアクセスの競合に起因する問題や処理オペレーションのつなぎ合わせについての考慮不足に起因する問題が発生する。実行の制御なくして、不良プログラムの動作を明らかにすることは不可能である。実行障害の検出が遅くなり過ぎると、並列実行チェーンに沿った伝播現象が発生し、これによって元々の原因を特定するのが益々難しくなる。最後に、実行が確定的であると、チップ上の所与のアプリケーションの実行において発生する事態を制御することが可能である。これにより、プログラムの微調整及びエラーの追跡のための手段を予想することが可能になる。これらの手段では、アプリケーションの設計からのエラーを浮かび上がらせることが可能である。そのような手段では、並列プログラミングのハードポイントにアクセスし易くする。これは本発明の目的の１つである。

図４は本発明に係る一般的なアーキテクチャの例を示す。この例では、Ｃｌ０〜Ｃｌ１５の１６のクラスタがチップ３０に配置されている。Ｃｌ０〜Ｃｌ１５の中の各クラスタは、特定の数の計算ユニットを含んでいる。これらのユニットは図４に示していない。図５にそれらのユニットの詳細を示す。クラスタＣｌ０〜Ｃｌ１５は、チップ３０に配置された通信構造体によって互いに交信することができる。例えば、通信構造体はチップ上ネットワーク３１（頭字語で表現すると「ＮｏＣ」）となり得る。しかし、バス、階層バス、又はポイントツーポイント構造体等の非常に多様な通信構造体を使用することができる。本特許出願では、これ以降、パフォーマンスと表現のし易さとだけから、ＮｏＣ ３１の使用を解決策として優先する。クラスタＣｌ０〜Ｃｌ１５はそれぞれ、インターフェイスとＮ０〜Ｎ１５で示されたＮｏＣを備える。更に、有用なトポロジープロパティを備えたアーキテクチャでは、タスクをマッピングするための経験則及び通信をルーティングするための経験則の効率を大幅に簡略化することができる。実際に、マッピング−ルーティングは、分散システムで非常に複雑な問題を引き起こす。それはＮＰ完全となり得る。幸いにも、近似解を提供する公知の経験則が存在する。しかしながら、様々な複雑さのうち、これらの経験則はサポートのトポロジーに非常に影響され易い。したがって、本例では円環状タイプのトポロジーが優先的に採用されている。しかし、本特許出願で説明されている発明を疑問視することなく、他のトポロジーが使用される場合もある。ネットワークの複雑さとマッピング−ルーティングの複雑さとの間で適切な妥協点を見つけることが重要である。例えば、コントローラ３２及び３３はＤＲＡＭタイプの外部中央メモリ３４へのアクセスを許可し、入力／出力コントローラ３５及び３６は、円環状の推測的な規則性を中断する。しかし、クラスタＣｌ０〜Ｃｌ１５が相互に同じである限り、メモリ及び入力／出力へのアクセスとは切り離してマッピング−ルーティングの問題を検討できる。このように、第１のステップでは処理オペレーションのマッピングと、クラスタ間の通信のルーティングとを許可し得る。第２のステップでは、円環状アーキテクチャの変換−不変プロパティを利用することにより、これらのアクセスを帰納的に最適化することが可能である。

図５はＣｌ０〜Ｃｌ１５の中のクラスタ（例えばクラスタＣｌ０）の例示的な内部アーキテクチャを示す。クラスタＣｌ０は、例えば４つのプログラム可能なＰＥ ４０、４１、４２、４３を備えている。例えば、ユニット４０、４１、４２、及び４３は、プロセッサ即ち「デジタル信号プロセッサ」（ＤＳＰ）、或いは再設定可能な要素になり得る。クラスタＣｌ０は、例えば、１６のメモリバンク４４、４５、４６、４７、４８、４９、５０、５１、５２、５３、５４、５５、５６、５７、５８、及び５９を備える。これらの一連のメモリバンクは本例ではクラスタのローカルメモリを構成しており、有利にはこのローカルメモリを物理的にクラスタ専用とすることができる。クラスタＣｌ０を管理するためのモジュール６０は、特に、クラスタＣｌ０内部で相互接続リソースを構成し、要件に応じてメモリバンク４４〜５９をユニット４０、４１、４２、４３と接続することができる。相互接続リソースは、図５に図示していない。以下、モジュール６０はクラスタマネージャと称する。例えば、プログラム可能なＤＭＡインターフェイス６１は、Ｎｏｃ３１のローカルノードとリンクされる。ＤＭＡインターフェイス６１は、クラスタＣｌ０のローカルなメモリと、Ｎｏｃ３１へのクラスタＣｌ０のインターフェイスＮ０との間でデータを有利に転送することができる。

クラスタモジュール６０自体は、同時に連携して動作する複数のサブモジュールで構成される。技術的及びコスト的な制約に従い、これらのサブモジュールの製作は、ハードウェアモジュールとソフトウェアモジュールとの関わりの度合いを変化させることができる。

例えば、クラスタモジュール６０は、タスク管理モジュール６２、即ちタスクマネージャを備える。実施形態は、ソーティング構造体や連想ストレージ構造体等の特定のハードウェアリソースに応じてプログラム可能又は再設定可能な解決策とすることが好ましい。これにより、パフォーマンスが使用分野に大きく左右されるスケジューラと同様の方法で、構造体をアプリケーションの制約に合わせて調整するための必要な柔軟性を保ちながらパフォーマンスを最適化することができる。

例えば、クラスタマネージャ６０はまた、メモリを管理するためのモジュール６３即ちメモリマネージャと、ユニットを管理するためのモジュール６４即ちＰＥマネージャと、ネットワーク及び通信を管理するためのモジュール６５即ちネットワーク／通信マネージャを備える。これらのマネージャは、パフォーマンスを最大限に高めるために主としてハードウェアベースとすることが好ましい。全ての場合で、モジュール６２、６３、６４、及び６５を同時に呼び出すことができる。しかし、ここで提示したクラスタマネージャ６０のサブモジュールへの分割が、これらのサブモジュールの機能をサポートするハードウェア又はソフトウェア構造体を予測するものではないことを明確に理解されたい。このため、管理が必要なリソースに機能が近づくように機能の階層化を行い、ボトルネックの発生を回避することができる。そのような例を、データフローモードの効率的な管理について、以下に詳しく説明する。

クラスタＣｌ０の初期化時又は強制リロード中に、タスクマネージャ６２とネットワーク／通信マネージャ６５は、動作する上で必要な情報が入った記述テーブルを受信する。この初期化プロシージャは、例えば、内部ネットワークを経由して初期化シーケンスを配布する外部マスターによって又はクラスタＣｌ０〜Ｃｌ１５のそれぞれを順番に初期化する内部プロシージャによって管理され得る。マネージャ６２と６５はこれらのテーブルに頻繁にアクセスするため、これらのテーブルは、クラスタＣｌ０のメモリバンク４４〜５９に格納されるのでなく特定の内部メモリ空間に格納されるのが極めて好ましい。

マネージャ６２、６３、６４、及び６５は、クラスタＣｌ０から発信された種々のイベントを受信でき、それにはユニット４０〜４３で実行されるタスクの一部でのデータの生成若しくは消費に関するイベント、又はタスク終了イベント等がある。メモリリソースを効率的に管理するために、これらのマネージャはまた、オーバーフローに関するイベント又は割り振られたメモリ空間がオーバーフローするリスクに関するイベントも受信できる。同様に、これらのマネージャはメモリ内にあるデータのディスパッチを要求できる。このイベントリストは限定的でなく、これらのマネージャはアプリケーションの要件に従ってアプリケーションの実行及び制御に関連する可能性があるどんなタイプのイベントも利用できる。

ソフトウェアタスクは、プログラマが、例えばデータ依存関係を考慮する等、純粋なソフトウェアの検討事項に基づいてアプリケーションを処理オペレーションに分割した結果として作り出されたものである。ソフトウェアタスクは、ハードウェアに関する検討に由来するものではない。一方、実行タスクはハードウェアアーキテクチャ及びマッピング−ルーティングの特定の機能、並びに処理オペレーションのスケジューリング又は処理オペレーションを中断する能力等の他の多くの要因に関係する。図５のクラスタＣｌ０では、ユニット４０、４１、４２、及び４３での実行タスクの実行の管理はタスクマネージャ６２に任される。例えば、タスクマネージャ６２自体は、タスクを選択するモジュールとスケジューラとから構成され得る。この２つの要素については図示していない。例えば、タスクの実行を開始するための最小限の前提条件は、システムの初期化時にタスクを選択するためのモジュールにテーブルにて提供され得る。この前提条件には、クラスタのローカルイベント又は外部イベントが必要となる場合がある。これらの前提条件は、タスク間の優先順位だけでなく、タスクを開始するのに必要な最低限のデータの可用性又は生成されたデータを格納するメモリ空間の可用性を含んでもよい。タスクの実行モードが並列マルチタスクタイプであろうとデータフロータイプであろうと、所与のタスクが待機状態にあって最低限の前提条件を満足すると、タスクは、タスクを選択するためのモジュールによって割り振り可能になると考えられる。次にスケジューラは、割り振り可能なタスクの中から、ＰＥ ４０、４１、４２、及び４３で実行されるように選出されるタスクを選択する。スケジューリングポリシーは、アプリケーションに大きく左右されることに留意されたい。例えば、当技術分野で公知のように、純粋なリアルタイムシステムのスケジューリングポリシーは、「ベストエフォート」システムのスケジューリングポリシーとは根本的に異なる。したがって、スケジューリングポリシーは目的とするアプリケーションのタイプに従ってプログラム可能又は再設定可能となる。

更に、最小限の前提条件が満足された場合、これはユニット４０、４１、４２、又は４３のいずれかにタスクを割り振り可能であること、即ち、タスクの実行を開始できることを意味する。しかし、このことは必ずしも全てのデータが利用可能であることを意味するものではない。したがって、データ又はメモリ空間の可用性に関係する可能性がある内部的な同期化フェーズなしに、タスクの実行が終了され得るかどうかは不明である。以下に詳述するように、タスク内部のこのような同期化は、ＰＥ ４０、４１、４２、又は４３によってローカルに管理される場合もあれば、タスクマネージャ６２を必要とする場合もある。

ユニット４０、４１、４２、又は４３のいずれかにタスクが割り当てられた場合、クラスタマネージャ６０は選択されたユニットにパラメータを転送する。このパラメータは選択されたユニットが自身を初期化するために必要であり、例えば、タスクが切り換えられている場合は現在のコンテキストが考えられ、又はローカルアドレス変換テーブルの入力も考えられる。これらのテーブル（操作方法については本特許出願で以下に詳しく説明する）によって、プログラミングにより生成されるデータとタスクの実行時にのみクラスタ上でローカルに利用可能な物理アドレスとの間にリンクを形成することができる。このテーブルにより、タスクは操作の必要なデータにアクセスすることができる。タスクは、タスクが実行されるユニットに対して及びそのアップグレード（存在する場合）に対して可能な限り最も透過的な方法で動作する。タスクは、データにおける処理オペレーションを、それが生成か消費かに関わらず、終了したことを示すためにクラスタマネージャ６０に信号をディスパッチし得る。関連付けられているメモリは解放されて別のタスクへ再割り当てされる、或いはそのメモリ内に格納されているデータが別のタスクへの入力として役に立つ場合がある。タスクにおいて、メモリアロケーションテーブルを介してタスクに提供されているメモリへのアクセスが無効になった場合、原因として次の２つの状況が考えられる。まず、該当するタスクで障害が発生しており、タスクを停止させなければならない場合が考えられる。或いは、入力のために必要な全てのデータ、又は出力のために必要な全てのメモリ空間がまだ準備できていないにも関わらず、タスクが開始された場合が考えられる。後者の状況はまた、データフロータイプの処理の場合とも一致する。データフロータイプの処理ではデータが継続的に供給される必要がある、しかし、データの効率的な供給は前の処理オペレーションによって提供された入力ストリームのテンポ（速度）に依存するのである。タスクに割り当てられているメモリ空間は無限ではないので、入力ストリームがまだ有効であるにも関わらず、生成されたデータを格納するのに必要な空き領域が不足するということも起こり得る。このような状況はエラーではない。しかし、これらの状況が発生すると、タスクマネージャ６２は、ユニット４０、４１、４２、又は４３のいずれかに割り当てられる別のタスクを保持している場合に処理の切り替えを行う場合がある。このような処理の切り替えは、処理オペレーションの数と選択されているスケジューリングポリシーに依存し得る。処理オペレーションを実行するのに必要なデータ又はメモリが有効になると、クラスタマネージャ６０はユニットのアドレス変換テーブルの更新版を伝送することもできるので、結果として該ユニットはタスクを引き続き進めることが可能である。メモリアクセス中のエラーの検出は、安全なオペレーションを実現するため及びアプリケーションの効率的な微調整を可能にするために最も重要である。読み取り時、該当するエラーは、生成されていないので決して利用できないデータ項目へのアクセスを意味する。書き込み時、該当するエラーは当タスクに割り当て可能なメモリ空間を超えるデータ項目へのアクセスを意味する。障害の場合と正常なオペレーションの場合との区別を行うには、無効なアクセスを解析する必要がある。正常なオペレーションの場合につながるアクセス範囲と、エラーの場合につながる第２の範囲がオフラインで定義される。技術的に公知である「ウォッチドッグ」を使用することも可能である。ウォッチドッグを使用すれば、スタンバイ状態でデータ又はメモリ空間を待機しているタスクを識別できる。ウォッチドッグの動作は、最悪な場合、時間的な振る舞いとの関連で異常となる。これらのタスクは誤りと見なされる。また、タスクがデータフローモードを利用すべきかどうかを識別することも可能である。特定のケースでは、エラーを迅速に検出することが可能であるが、非データフロータスクはスタンバイ状態でデータを待機することができない。

図４の例示的な実施形態では、クラスタＣｌ０〜Ｃｌ１５並びにコントローラ３２と３３は、有利には、少なくとも１つのＤＭＡエンジン等、通信タスクに専用の実行手段を備える。ＤＭＡエンジンは有利にはクラスのローカルメモリと直接的にデータのやりとりを行うことができる。これらのＤＭＡエンジンを有利に使用することにより、クラスタＣｌ０〜Ｃｌ１５の中でのデータのやりとりを可能にする通信タスクを実行することができる。このため、本特許出願の中ではこれ以降、通信タスクを「ＤＭＡタスク」と称する。例えば、送信タスクはデータが生成されるクラスタで実行することができ、受信タスクはデータが消費されるクラスタで実行することができる。有利には、この送信タスクと受信タスクは、他のタスクと同様にクラスタに静的に割り当て可能である。本発明においてＤＭＡエンジンは単に特定のＰＥとして見なされる。ＤＭＡタスクは処理タスクと同様の方法で管理されるが、ＤＭＡタスクでは、ＤＭＡタイプのリソースを使用してタスクを実行するために管理手段を制約する必要がある。通常のオペレーションで、データの受信を任されるＤＭＡエンジンは、受信時に提供されるデータ量に合わせてメモリ４４〜５９内の空間を利用できるようにする必要がある。もはや利用できるメモリがないのにデータが着信した場合、これによりクラスタマネージャ６０に信号で知らせなければならない重大なエラーに巻き込まれる。この問題を回避するために、メカニズムにおいては、図５の受信モードにあるクラスタＣｌ０は、飽和した通信リンクの問題を送信クラスタに信号で知らせることができる。図５の例では、メモリマネージャ６３が該当する通信リンクへの追加メモリの割り当てに成功しなかった場合、有利には、送信クラスタに割り込み信号をディスパッチすることができる。割り当てを実行するために十分なメモリが利用できるようになるとすぐに、第２の信号を送信クラスタにディスパッチすることができる。コンシューマによって送信ストリームがあるクラスタから別のクラスタへ転送される必要がある場合、このメカニズムでは確実に、可能な限り最も透過的に連携することができる。

データロードが終了した場合、アップ方向かダウン方向かに関係なく、対応するＤＭＡエンジンはクラスタマネージャ６０に信号をディスパッチしてその旨を通知する。このロードの終了は、タスクのローカル割り当てに関係する前提条件を満足するといった方法で行われ得る。このため、データ受信クラスタＣｌ０の観点からすると、クラスタ間通信メカニズムはユニット４０、４１、４２、又は４３のいずれかによるデータのローカル生成に相当する。クラスタＣｌ０の観点からすれば、この場合、ユニット４０、４１、４２、又は４３のいずれかによって実行されたデータ生成タスクの終了か、ＤＭＡエンジンによるデータ受信タスクの終了か、いずれかのタスク終了を待機することが必要である。これにより、ローカルデータを操作する処理オペレーションの実行モデルとリモートデータを使用する処理オペレーションの実行モデルの差別化を回避することができる。そのようなクラスタ内及びクラスタ間の実行モデルのユニットが実際に存在するかどうか示せることは非常に重要である。実際、このユニットは一元的であるので、コード生成の簡略化を将来的に実現可能にする。したがって、ＤＭＡタスクはタスクマネージャ６２による通常のタスクと同じ方法で管理される。しかしながら、ＤＭＡタスクは、チップのネットワーク中を流れる外部データによって制約されるに違いない。とりわけ、ＤＭＡタスクは、選択された通信チャンネル、割り当てられた帯域幅、及び処理されるデータの配置用に特に生成されたプログラムとする必要がある。アプリケーションの要件によれば、更にＤＭＡタスクのプログラムをパラメータ化することにより、通信に影響を及ぼす、オフラインで予測不可能な全ての情報を把握することができる。一例として、画像内の物体追跡の機能では、サイズと位置が低レベル処理の後でしか取得されない画像のサブパートの操作を必要とする。

メモリマネージャ６３は、メモリバンク４４、４５、４６、４７、４８、４９、５０、５１、５２、５３、５４、５５、５６、５７、５８、及び５９に格納されたデータをクラスタＣｌ０内の種々の実行タスクに割り当てる処理を担当する。メモリマネージャ６３は、タスクが実行されるユニット４０、４１、４２、及び４３と一緒に動作する必要がある。このため、メモリマネージャ６３は、種々のイベントを、タスクを実行するＰＥから直接的に受信するか、タスクマネージャ６２を経由して受信する。これにより、アクセス権限とタスクのメモリクォータの管理が可能になる。ユニット４０、４１、４２、及び４３で実行される各タスクへのメモリ空間の割り当てに加えて、メモリマネージャ６３はまた、クラスタ通信時に各通信チャネルに関連付けられたメモリ空間を管理することにより重要な役割を果たす。例えば、メモリマネージャ６３は、有利には、データ項目のタスクに割り当て可能なメモリサイズである、クォータを管理することができる。このクォータはデータフローに対する処理オペレーションに関連して直接利用されるが、その有効性はこれに限定されるものではない。実際には、クォータを超過するとタスクマネージャ６２に向けてイベントが生成され、タスクマネージャ６２は、データ項目が生成されるクラスタのタスクマネージャと適宜通信することにより、データの生成を中断することが可能になる。データ項目が再びクォータを下回ると消費プロセスによって第２のイベントが生成され、これによりプロデューサタスクの再開が可能になる。データ項目によって実際に占有される空間は用語「クォータ」によって早計に判断されない。これは、イベントの生成とプロデューサタスクの停止との間の遅延によりデータ項目がクォータを一瞬超過する場合があるからである。遅延を延ばしクォータを適宜計算するのは、オフラインのディメンショニングツールの役割である。これらのツールがエラーをコミットした場合、それを検出するのは簡単である。クラスタ上でのメモリの動的な割り当てによりクラスタ上で利用可能なメモリのオーバーフローが発生すると、重大な例外が生成される。或いは、メモリが十分に利用されていないのにタスクが不当に待機状態に置かれている場合、この状態は、当技術分野において公知である「プロファイリング」ツールによって明らかにされ得る。

クォータの概念を更に規定するために、全てのデータ依存関係、即ち、クラスタ内部の及びクラスタ間のデータ依存関係、又はクラスタと中央メモリ間のデータ依存関係、に対してこれらを適用することが重要である。

クォータの実施方法にはいくつか存在する。本例では、メモリの使用を最適化するために、プロデューサ及びコンシューマ用に別々のメモリを使用しないことが有利である。ただし、クラスタ間の通信の場合は例外である。これは、データの生成に関して、又は所与のタスクの消費に対して提供されたデータ量に関して、クォータを割り当てるには十分であることを意味している。両方の場合とも、最適な実行制御を行うには、クォータ超過データ項目のプロデューサとコンシューマのペアはどれかを把握することが必須である。特定のデータ項目についてはこのペアは必ずしも一意ではないので、可能性のある候補を識別できる必要がある。このように、タスクマネージャ又はプログラマ（開発の段階に応じて）が、ランダムな予測のつかない変化について原因を正確に検出することができることにより、ランダムな予測のつかない変化は限定され、他のタスクの通常のオペレーションはすぐに損なわれないよう保護される。ここでは以降、データの過小消費の観点から問題を見ることによってクォータ超過を識別する特定の実施形態を示す。データ生成におけるクォータの観点からこの識別を解決することは、数学的に双対問題となる。

このメカニズムは、最大限の実行制御を試みなくても、単にデータ項目ごとに潜在的なコンシューマの数を指定することにより簡単に実施できる。この場合は、残りの潜在的な消費の数を特定するには、潜在的な各アクセスでこの値を減少させれば十分である。しかしながら、この場合は、複数のコンシューマが存在していると、どのコンシューマがロックアップの原因となっているのか特定するのは不可能である。

通信時にストリームのサイズを制御する方法は当然ながら他にも存在するが、重要なことは、通信チャンネルの容量を超えたときにデータ損失を検出できるようにすることである。したがって、通信チャネルで利用可能なメモリ空間についてプロデューサに情報項目を提供することも可能である。有利には、この解決策はクレジットベースのメカニズムで実施され得る。しかしながら、クレジットベースのメカニズムは、データの流れがクラスタ内部で発生する場合とデータの流れがクラスタ外部で発生する場合との整合性の喪失という犠牲を払って行われる。受信クラスタは、この場合は、利用可能なメモリサイズに応じてプロデューサクレジットを含むクラスタにディスパッチする。プロデューサによるデータのディスパッチは、十分なクレジットの存在によって条件付けされる。

メモリマネージャ６３はいくつかの信号を受信する。例えば、タスクによるメモリブロック利用の終了を示す信号を受信することができる。これを受けて、メモリマネージャ６３はアロケーションテーブルを更新する。問題のブロックがＤＭＡタスクを含む実行タスクで使用されていない場合、メモリマネージャは再使用のためにブロックを解放する。メモリマネージャ６３はまた、タスクへのブロックの割り当てを示す信号も受信する。例えば、自身ではデータを消費しない実行タスクによってデータブロックが生成されると、そのブロックは種々の消費タスクに単純に割り当てられる。メモリマネージャ６３では、このデータ項目との関連で消費タスク向けのメモリクォータの違反が発生しないことを確認する必要がある。メモリクォータは、マッピング−ルーティングツールによって定数としてメモリマネージャ６３に提供される。クォータの超過が発生するたびに、タスクマネージャ６２に例外がレポートされる。タスクのレベルでクォータを超えた後、問題のタスクのレベルでクォータ超過が消えると、メモリマネージャ６３はまたタスクマネージャ６２に信号をディスパッチし、その後データ消費が発生する。

本特許出願で、ブロックはメモリマネージャ６３で管理される最小の要素を示す。メモリのサイズは、メモリバンク４４〜５９内の最小のアドレス指定可能な要素から完全なメモリバンクまでの範囲で変化し得る。粒度が粗くなるほど、プログラムするメモリマネージャ６３は簡単になる。しかし、粒度が粗いとメモリリソースの利用不足が深刻になり、システム全体でパフォーマンスに関して影響が出る。他方、粒度が過度に細かいと、メモリマネージャ６３が非常に複雑になり、システムのボトルネックが発生する恐れがある。このように、ブロックの粒度について適切な妥協点を探すのには理由がある。更に、本発明で提案する実行モデルでは、ブロックのサイズを可変にすることが可能である。しかしながら、優先的な実施形態では、確定性の観点から適切なプロパティを持つ同種のフレームワークを採用するよう、固定されたブロックサイズを使用し得る。更に、可変サイズのブロックの管理では、デフラグ機能を導入して連続的なアドレス指定空間を維持する必要がある。

物理的か仮想的かに関わらず、通信のルーティングをオフラインツールによって実行できるようにする必要がある。したがって、これは静的状態又はフェーズルーティングによる静的状態を伴う。最大限の通信遅延及びアプリケーションの確定的な実行を保証するために、オフラインで実行されるルーティングに対して遅延が保証されたルーティングメカニズムが必要である。いくつかのスキームでは、単純な帯域幅の予約からより複雑な変形例まで（当技術分野で公知の「時分割多重アクセス」又は「ＴＤＭＡ」等）まで、この成果を出せる。ある特定の通信ネットワークでは、マルチバスネットワーク又は専用の相互接続スイッチングシステム等、固定された明示ルーティングを受け入れることに注意されたい。クラスタＣｌ０にローカルなＮｏＣ ３１のノードは、クラスタＣｌ０のデータを入力又は出力する役割を担うＤＭＡタスクと関連付けられる。ＤＭＡインターフェイス６１と一緒に、ＮｏＣ ３１によって形成されるネットワークのプロトコルにＤＭＡタスクを適応させるインターフェイスである。他方、ネットワークのノード間でデータを伝播する方法は実行方法に影響を及ぼさない。この実行方法は、「回路スイッチ」タイプのネットワークの場合と同様に「パケットスイッチ」タイプのネットワークへも適合するよう試みる。尚、これらのタイプのネットワークは当技術分野で公知である。しかしながら、データによって横断されるパスの仕様を配布できなければならない。「パケットスイッチ」タイプのネットワークにおいて、これはデータパケットでの通信パスのパラメータ化を伴う。分散型の設定インターフェイスでは、通信で横断されるネットワークの各ノードを部分的に設定することが可能であり、既存のパスを妨害しないように通信パスが開かれる。ＮｏＣ３１がバスタイプの通信構造体と置き換えられた場合、この構造体はネットワークノードを備えていないので、結果として、バスへの適合及びアクセスのためのインターフェイスだけがＣｌ０〜Ｃｌ１５の各クラスタで実施されることに注意されたい。

ＤＭＡタスクの目的は、クラスタＣｌ０〜Ｃｌ１５の間でデータのやりとりを確実に行うことにある。このため、ＤＭＡタスクはデータの生成タスクと消費タスクが同じクラスタ上にない場合に稼働する。クラスタＣｌ０で実行する処理タスクは、クラスタＣｌ０内のメモリバンク４４〜５９に存在するデータのみを使用する。したがって、リモートクラスタで実行されたタスクがデータの相互依存関係を有する場合、クラスタＣｌ０〜Ｃｌ１５の間でデータの転送を行う必要がある。このため、送信タスクはデータを生成しないが、クラスタＣｌ０のローカルデータを読み取ってそれらを別のクラスタのメモリ空間に再度書き込む。ＤＭＡタスクは、自由裁量のハードウェアサポートに応じて多かれ少なかれ複雑になると考えられる。したがって、データアクセス機能は、当技術分野で公知の「バースト」モードでのデータアクセス等、極めて基本的なものとなり得る。この場合、生成タスクと消費タスクについては、そのデータを再編成して適切なパフォーマンスが得られるようにするために、調整が必要である。逆に、データアクセス機能（例えばＤＭＡタイプの）が複雑である場合、ＤＭＡタスクはデータの再編成を行い、処理タスクの簡略化に役立てることができる。例えば、クラスタＣｌ０からクラスタＣｌ１５までの通信を実行するには、いくつかの条件を満足する必要がある。まず、クラスタＣｌ１５又は中央メモリ３４へのデータのディスパッチを管理するＤＭＡタスクがクラスタＣｌ０でアクティブされる必要がある。即ち、その最小限の前提条件が全て満たされる（例えば、ディスパッチされる最初のデータセットの場合と同様にデータの受け側の準備ができていること）。送信タスクは、クラスタＣｌ０内のＤＭＡリソースに割り当てる必要がある。更に、クラスタＣｌ０から着信するデータの受領を管理するＤＭＡタスクを、クラスタＣｌ１５でアクティブにする必要がある。更に、データを受信するためのメモリ空間が利用できなければならない。最後に、物理的な通信パスを開く必要がある。即ち、データの伝送を可能にするようＮｏＣ３１のノードを設定する必要がある。通信が確実に行われるよう、特定数の同期を確実に実行する必要があることは明白である。特に、送信側と受信側が全く同時に存在するようにＤＭＡタスク間には依存関係が存在する。特定の並列通信の場合（例えば、クラスタＣｌ１５がいくつかのソースからデータを受信する場合）は、ＤＭＡ受信タスクを並列に実行するためにクラスタＣｌ１５に十分に利用可能なＤＭＡリソースが確保されていることが必要であるか、又はクラスタＣｌ１５内でＤＭＡ受信タスクが待機状態に置かれたとき、識別子を取り込んだ各通信が実行されるＤＭＡ受信タスクを見定めることができることが必要である。実際には、各チャネルは一対のＤＭＡタスク（一つは送信タスク、もう一つは受信タスク）で管理される。このため、受信側からは、着信チャネルにつき１つ、ＤＭＡタスクの重畳として、収束が見られる。これにより、着信フロー間のフェーズシフトを効率的に管理することができる。送信クラスタＣｌ０側ではまた、並列に管理されるいくつかの通信が存在し得る。したがって、これが該当する場合は、クラスタＣｌ０に利用可能な十分なＤＭＡリソースを確保する必要があるか、又はＤＭＡタスクを管理する調停機能を備える必要がある。例えば、タスクマネージャ６２は、この調停機能を実行することができる。しかしながら、ＮｏＣ ３１におけるパフォーマンス及び帯域幅管理の理由で、ＤＭＡ機能に可能な限り近づけられ、それによって反応が良くなった、ＤＭＡタスクに専用のマネージャに調停機能を統合するのが好ましいという結果になると考えられる。いくつかの受信側へ同時にディスパッチを行うことができる「マルチキャスト」モード及び／又は「ブロードキャスト」モードを統合する最適化の可能性についてここでは注目すべきである。しかし、このオプションはコスト高となるので、その収益性についてはプラットフォームのタイプごとに個別的に調査する必要がある。同様に、いくつかの受信ＤＭＡタスクが、タスクマネージャ６２によって、又はＤＭＡタスクに専用のマネージャによって管理可能である。しかし、そのようなＤＭＡタスクに専用のマネージャは、特にそれがユニット４０〜４３のうちの１つにおいてのみ実施される場合、管理可能なＤＭＡタスクの数に制限がある。よって、アプリケーションの全てのＤＭＡタスクがこの専用のマネージャで同時に管理され得る可能性は極めて低い。このため、タスクマネージャ６２とＤＭＡタスクに専用のマネージャとの間で共同アプローチが想定され得る。タスクマネージャ６２の場合は、例えば、ＤＭＡタスクに専用のマネージャによる管理が必要なＤＭＡタスクの選択と選択解除を担当する。有利には、各通信の受信で必要とされるバンク４４〜５９内の必要メモリ空間は、コンパイル時及びタスクの静的配布時に例えばリンクの編集によって保証され得る。通信パスの開放は、システムに統合されたネットワークの性質に密接に関連する一ステップである（即ち、本例示的実施形態のＮｏＣ ３１）。よって、ネットワークインターフェイスユニットは、ネットワークの利用を管理する（即ち、本例示的実施形態のＤＭＡインターフェイス６１）。例えば、インターフェイス６１は、パケット化と、「パケットスイッチ」タイプのネットワーク用のヘッダの書き込みを担当する。分散型「回路スイッチ」タイプのネットワークの場合、ネットワークの部分設定のためのポートを提供する必要がある。ネットワークが「回路スイッチ」タイプの非分散型構造体である場合は、一元化されたユニットをシステムに追加する必要があり、通信で必要とされる２つのＤＭＡタスクのうちの１つは、パスが存在しない場合にその作成について該ユニットに問い合わせる必要がある。バスタイプの構造の場合は、Ｃｌ０〜Ｃｌ１５の中の各クラスタに共有メカニズムが存在する必要がある。他方、通信要素の識別と同期化についてはバスのプロトコルが担当するので、ルーティングメカニズムは必要なくなる。

しかしながら、本発明は（並列ハードウェアアーキテクチャ及びこの並列性を利用可能な実行モデルに基づいているが）、データフロータイプの逐次処理オペレーションに好適である。図５の例では、いくつかの手段を使用してデータフロータイプの処理中にＰＥ間でデータの同期化し共有することが可能である。しかし、アーキテクチャのプログラミングを容易にするために、均一なクラスタ間及びクラスタ内解決策を維持することが重要である。例えば、クラスタＣｌ０で実行され所定のメモリクォータに到達するタスクは、クラスタ管理モジュール６０の関与なく自動的にアイドル状態になり得る。この場合はローカル同期化メカニズムを必要とする。このメカニズムは、データフロー処理に参加する４０、４１、４２、４３の中の各ユニット間で利用可能であるだけでなく、処理がクラスタ間で分散される場合にＣｌ０〜Ｃｌ１５の中の各クラスタ間でも利用できなければならない。一杯又は空である送信先メモリ空間の検出は、先に提示したクォータシステムによって実行可能である。好適な方法では、クラスタ管理モジュール６０を使用して種々のＰＥ間の同期化が管理される。この方法では同期化に起因するペナルティが増すが、割り当てられた種々のタスクの実行状態のより全体的な状況が提供される。このメカニズムでは、いくつかのアプリケーションの例を通して、より詳細な解析の対象を形成する。

採用される実施形態とは関係なく、各管理手段の機能仕様が提案可能である。

タスクを管理するための手段は、クラスタ上のタスクの状態を更新することが可能な全てのメカニズムを網羅する。最低限の実施形態では、待機状態と準備完了状態という所与のタスクについて考えられる少なくとも２つの状態を明らかにすべきである。待機状態の特徴は、タスクはその実行のために必要な少なくとも１つの要素が不足すると実行されないということにある。必要な要素のリストは、非常に変化に富んでいる。例として、ＰＥの可用性、処理されるメモリ又はデータの可用性が挙げられる。このリストもタスクの性質に左右される。したがって、通信タスクの要件のタイプは、必ずしも処理タスクの場合と同じではない。準備完了状態の特徴は、タスクがその実行のために必要なあらゆるリソースを採用可能であることにある。タスクを管理するための手段によって実行される割り当ては仮想的なものであり、その理由は、タスクと実行リソースとの間に物理的なリンクが設定されるわけではないからである。システムが実施される方法では、タスクの実行において特定の変化をより適切に考慮するために、更なる状態の追加をもたらし得る。一例として、所与のタスクはその実行が開始されると、処理中に取って替わられる場合がある。

ＰＥを管理するための手段は、タスクをＰＥに割り当てることが可能なあらゆるメカニズムを網羅する。このため、各ＰＥには解放状態と割当状態という少なくとも２つの状態を関連付け可能である。解放状態の特徴は、関連付けられたＰＥがタスクに割り当てられていないことにある。割当状態の特徴は、関連付けられたＰＥがタスクに割り当てられていることにある。仮想的な割り当てを行うタスク管理手段とは異なり、ＰＥを管理するための手段はリソースの物理的な割り当てを実行する。タスクの管理の場合と同様に、システムが実施される方法では、ＰＥの実行において特定の変化をより適切に考慮するために、更なる状態の追加をもたらし得る。一例として、ＰＥに対するアイドルモード又は低消費モードの実施が処理され得る。

メモリ管理手段では、メモリを割り当て可能なあらゆるメカニズムを網羅することにより、１つ又は複数の所与のタスクにメモリが関連付けられ、データ項目が潜在的に有用である限りメモリが維持される。メモリ空間の割り当ては、事前に空きと見なされているメモリ空間部分（即ち、ローカルで保持される必要があるデータをもはや含んでいないメモリ空間部分）を確保し、それをタスクと関連付けできるようにすることを目的とする。その後の関連付けにより、割り当てられたメモリ空間を、１つ又は複数のタスクで処理要件に応じて使用できる（例えば、生成又は消費されるデータの読み取り又は書き込み、もしくは中間処理オペレーション）。権利管理では、不安定なデータ項目（即ち、タスクによって書き込み又は修正されるデータ項目）が他のタスクの読み取りモードで利用できないように保証することができる。最後に、メモリ空間は明示的なコマンドの形式によって（即ち、メモリ空間に割り当てがもはや存在しないため）、又は２つのメカニズムの組み合わせによって解放することが可能である。

いくつかのクラスタが通信チャネルを経由してデータ又は情報のやり取りを行う必要がある場合は、通信構造の制御及び管理を可能にするあらゆるメカニズムを包含した通信管理手段をセットアップするのが有用である。これらの管理手段は、通信構造の性質に大きく依存している。したがって、バスが使用される場合、管理手段には優先順位とアドレス指定の管理を含めることができる。ＮｏＣの場合、管理手段にはルーティングの管理と各通信と関連付けられた帯域幅の管理を含めることができる。

クラスタを管理するための手段は少なくとも、タスクを管理するための手段、ＰＥを管理するための手段、及びメモリを管理するための手段といった管理手段を全て含んでいる。いくつかのクラスタが、互いの通信を必要とする処理オペレーションを備えている場合、通信を管理するための手段を備えることが有用である。これらの管理手段とプラットフォームの残りの部分との間の全対話、並びにそれらの同期化に役に立つメカニズムは、クラスタを管理するための手段の中に包含されている。

本発明のオペレーションの方法を、３つの非常に異なる実行例を通して以下に説明する。ビデオ復号アプリケーションの例ではデータフローの逐次処理を示す。モーフィングアプリケーションの例では、アクセスレベルでそれほど規則的でない処理を示す。最後に、イメージ処理アプリケーションでは大規模な並列処理を動的制御フローで示す。

図６〜図１１では、モーフィングアプリケーションの実行例を示す。モーフィングアプリケーションは、通常の画像処理専門用語の「マクロブロック」における通例の変換よりも繊細な効果を考慮に入れるために、特定の高度な画像圧縮及び圧縮解除アルゴリズムでの動き推定のために使用される。アクセスのレベルにおいて、「ブロックマッチング」タイプの従来の動き推定より規則性が低く、理論的にはビデオコーダーで得られる圧縮レートを高めることができる。データはよりコンパクトになるが、その代りデータによってますます指示される計算が複雑になる。インテリジェントなアルゴリズムであり、この点において、メモリアクセスと処理オペレーションについて要求が厳しい。アルゴリズムの原理は画像を変形することにあり、この画像の変形ではカメラのズーム又は回転を特にモデル化することが可能である。このアルゴリズムはまた、グラフィカル表現システムでテクスチャ計算にも使用される。基本的なモーフィングアルゴリズムは、次のようにＣ言語によるコード形式に変換することができる。
ｆｏｒ （ｘ＝０； ｘ< ＸＭ； ｘ＋＋）
ｆｏｒ （ｙ＝０； ｙ< ＹＭ； ｙ＋＋）
｛ｕ＝ Ｆ_ｘ（ｘ）；
ｖ＝ Ｆ_ｙ（ｙ）；
ｄｅｓｔ［ｘ］［ｙ］＝ ｓｒｃ［ｕ］［ｖ］；｝

定数ＸＭとＹＭはそれぞれ、該当する領域の幅と高さを表す。提示したアーキテクチャでのこのアルゴリズムの実施形態を過度に簡略化しないよう、いくつか重要なことを想定しておく。まず、関数Ｆ_ｘ及びＦ_ｙが微分可能であると想定する。この想定は、実際の変換システムには理にかなっている。更に、関数Ｆ_ｘ及びＦ_ｙの消費時間は、中央メモリとの通信の時間に対して十分に長いものと想定する。この想定は、そうしたプラットフォームで並列性を実現するのに必要である。この想定がないと、処理は全体的にメモリとの伝送によって管理され、並列性を利用することはできない。最後に、画像は高解像度（ＨＤ）である、又は少なくとも、チップに埋め込まれたクラスタのローカルメモリ内に画像を格納することはできず、このため、「ｓｒｃ」及び「ｄｅｓｔ」フィールドは中央メモリに格納されるものと想定する。この想定は、現行技術のフレームワークでは明らかである。また、中央メモリとのやりとりがどのように行われるかについても明確に示すことができる。

このコード部を基本的なアクティビティに分割する場合、このコード部分は４つのクラスタで動作しているものとする、及び推論の一般化が破られてはいけないものとする。しかし、処理オペレーションは、この４つのクラスタを占有するために十分な計算を行うことを意味している。変換を検索するフレームワーク内において、この想定は全く実現的なものである。したがって、各クラスタで、複数のＰＥにわたる処理オペレーションの分散は次の通りである。
● 消費Ｆ_ｘ及びＦ_ｙに対する４つの実行タスク。これらは最も高価な計算である。
● 適宜、中央メモリから及び隣接するクラスタからロードされるマクロブロックの制限値の評価を担当する処理。
● マクロブロックをロードするためのＤＭＡ処理。
● 計算／予測されたマクロブロックに基づいてロードされたブロックで、モーフィングを実行するループの主処理。
● クラスタのローカルメモリに現在ロードされているマクロブロックを隣接クラスタに信号で知らせるＤＭＡ処理。
● 中央メモリ内で返還されたデータを出力するＤＭＡ処理。

タスクのチャートにおいて、図６はこれらの処理オペレーションに応答可能なタスクＴ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６、及びＴ７を示す。この図ではＰＥで実行されるタスクが円で表示され、ＤＭＡで実行されるタスクが矩形で表示される。本特許出願を通して、この形式に従っている。このあと、タスクＴ１、Ｔ２、Ｔ３、Ｔ４、Ｔ５、Ｔ６、及びＴ７について詳しく説明する。

通信のルーティングは種々のクラスタ間で円形チェーンとして実行される。タスクのマッピングは、通信によって定義されるチェーンの順番でシーケンシャルに行われる。第１のクラスタは第１のマクロブロックの処理タスクを受信し、第２のクラスタは第２のマクロブロックの処理を受信するといった具合に第４のクラスタまで行われる。第１のクラスタは、５番目のマクロブロックにおいてチェーンでつながれるという具合である。画像ブロックの全ての処理オペレーションが、割り当てられた４つのクラスタにマップされる。

クラスタでの実行は、次のようにローカルに行われる。ＤＭＡアクセスは、予測されたマクロブロックに対して予約される。マクロブロックの予測の初期化は、高解像度（ＨＤ）ページの均一なグリッドとして行われ、このグリッドは高さ／幅に比例しており、クラスタのメモリ容量に合わせて調整される。例えば、クラスタのローカルメモリの７５％を超えて満たしてはいけない。進行中のローディングが予測されたマクロブロックラインを終了するとすぐに、ＤＭＡ処理はメモリとタスクを担当するマネージャに警告する。主処理はローディングで並列に開始される。それでも、この処理が実際には、現在のブロックの処理領域で、即ちＦｘ（ｘｍ）及びＦｙ（ｙｍ）に基づいて実行されるだけである。これは、処理を実行するＰＥのためにローカルにデータを用意するメカニズム（当技術分野では一般に「フェッチ」と称する）によって確実に行われる。

「フェッチ」メカニズムは、読み取り時にソースデータがまだ着信していない場合、タスクを無効にするだけであり、データが利用できるようになるまでそれは続く。４つのＰＥで並列に算出されるソース座標がまだ利用できない場合は、依存関係が解決されないためタスクマネージャによってタスクは停止される。当技術分野で公知の「ストールされた」状態である。算出されたソース座標が予測された拡大マイクロブロックを超過した場合、タスクマネージャは、割り当てられたメモリ領域のオーバーフローを理由にタスクマネージャに例外をアップロードする。この動作は、正規の変換にとって全く例外的である。したがって、この自動調節メカニズムでは、入力データの着信と並行して出力マクロブロックを生成する。エラーの場合もまた、必然的に管理される。

主処理は当技術分野で公知の「バッファ」モードで使用されるメモリ領域を経由してＤＭＡ出力処理を並列に提供する。主処理は、変換／モーフィング計算の４つの処理オペレーションと、計算／処理対象の一対のポイント（ｘ、ｙ）を提供し、それらの処理の結果（ｕ、ｖ）を待機する。主処理はまた、変換の現在の制限値を提供することで、次のメモリマクロブロックの予測処理を与える。次のマクロブロックの予測処理では、マクロブロック制限値の前のデータと現在のデータを使用して予測を行う。例えば、導関数を外挿、又は必要に応じて第２の導関数を外挿することにより予測を行うことができる。しかし、画像のサイズとマクロブロックのサイズとの差を考慮すると、２つの外挿アルゴリズムの差はほとんど気付かない程度となる可能性がある。

図７はブロック予測と変換アルゴリズムを示す。関数Ｆｘ及びＦｙによる（ｘ、ｙ）矩形ブロック８０の一般的な変換は、結果的にソースの（ｕ、ｖ）ドメイン８１になる。ボックス８２は同じ（ｘ、ｙ）ドメインの前の変換から生じるリニア又は二次外挿によって予測されるＸＹエンベロープ矩形である。このため、このエンベロープ矩形の速度は各変換で評価される。二次矩形の場合は、このエンベロープ矩形の加速度が評価される。変換のソースポイントがクラスタのローカルメモリ内にくることが、かなり確かとなるように、この予測矩形の周囲にマージン８３が取られる。これは強制的なものではないが、例外プロセスを回避できる。したがって、ロードされる最後の矩形の寸法は、データに依存する。しかし、Ｘ及びＹ寸法は実行される変換に応じて自由に変化し得るが、矩形の領域は、その部分定数のためにある。したがって、使用されるメモリは、クラスタ上で一定である。更に、考えられる最適化は、ロードされる追加データが破棄されず、隣接クラスタに転送されるようにすることにあり、これにより、中央メモリへの不要なアクセスが少なくなる。

タスクＴ１は、メモリブロックに対するＤＭＡローディングタスクであり、隣接するクラスタに既に存在するデータを考慮して配置される。このタスクの依存関係は、画像の同期化、及びＤＲＡＭとの通信用のチャネルの可用性に関連する。第１のクラスタの場合、アプリケーションが起動するとすぐにタスクＴ１がアクティブにされる。他のクラスタで実行されているタスクＴ１は、その後ブロックが消費されると、アクティブにされる。前のＧＯで算出されたパラメータが使用される。第１の画像を処理するとき、Ｔ１はデフォルトのダウンロードパラメータを使用する。タスクＴ２はメインループ、即ち、モーフィング計算の分散タスクである。Ｔ２の依存関係は、Ｔ１によって提供されるローディングブロックのデータの可用性に影響される。タスクＴ３、Ｔ４、Ｔ５、及びＴ６は、モーフィング関数計算タスクである。これらは、ライン処理ごとの極値ペア（ｕ、ｖ）、ｘの最小から得られる極値のタスクＴ３、及びｘの最大から得られる極値のタスクＴ６を提供することにより、ＸＹエンベロープ予測バッファを与える。タスクＴ７は、矩形予測計算タスクである。データに関する依存関係は、Ｔ３及びＴ６によって提供されるデータに影響される。次のパスでタスクＴ１に対する予測矩形が提供される。

図８はタイムチャートによって、クラスタの実行シナリオを示したものである。図８は簡略化されており、メモリからのパケットの単一転送を示すだけである。実際の実行の場合は、通信と実行との間に更にオーバーラップが生じる。

まず、タスク１は、想定される矩形のローディングをＤＲＡＭコントローラに要求し、ｔ_０の時点からｔ_１の時点まで待機する。

次に、ＤＲＡＭコントローラは、ｔ_１の時点からｔ_２の時点まで更にｔ_２の時点からｔ_３の時点まで、タスク１によって提供された情報を使用してＤＲＡＭにメモリブロックをダウンロードし、前後して種々のクラスタにブロックをディスパッチする。

その後ｔ_２の時点でデータがクラスタに転送されると、Ｔ１は制御権を得て、各データブロックのローディングを、依存関係の解決のためにタスクコントローラに、割り当てられたメモリブロックの更新のためにメモリマネージャにアナウンスする。これはｔ_３の時点でＴ１から開始される２つの矢印によって表わされる。

これ以降、タスクマネージャがＴ２の実行を設定する。タスクＴ２は、一対のポイント（ｕ、ｖ）の計算をタスクＴ３、Ｔ４、Ｔ５、及びＴ６に分散する。

次に、タスクマネージャは、タスクＴ３、Ｔ４、Ｔ５、及びＴ６をＰＥで実行すべきタスクとして設定する。４つのフリーなＰＥがタスクに割り当てられており、タスクマネージャは、各タスクのメモリマネージャに、コンパイルツールによって関連付けられている仮想メモリとの通信のルックアップテーブル（「仮想メモリのマッピング」）を送信する。このステップは、ＰＥがフリーである場合はずいぶん前に開始でき、ＰＥがフリーになる限り開始可能である。例えば、タスクマネージャにおいて、ＰＥ１上のＴ２からの細い矢印は、ＰＥ１上でスケジュールされたＴ６に戻る。

したがって、メモリマネージャはタスクごとに現存するデータを使用してローカル変換テーブルを構築し、タスクマネージャによって選択されたＰＥにそのテーブルを送信する。これは、メモリマネージャから始まる矢印によって示され、ｔ_３の時点の直後、メモリ１に進む。タスクＴ３／Ｔ４及びタスクＴ５／Ｔ６にそれぞれ対応するメモリ２及びメモリ３への全く同様の矢印は、図８の簡略化につき、図示していない。図８のタイムチャートにおいてメモリマネージャから出てメモリへ進む矢印は、メモリマネージャからメモリへの実際の信号と一致しないことに注意されたい。それらは、メモリマネージャのアロケーションテーブルの更新に対応するだけである。

同時にタスクマネージャは、選択された各ＰＥにタスクの開始順序を提供する。メモリマネージャによってコードの配置が提供されるとすぐに、クラスタのローカルメモリにコードの開始がロードされ、実行が開始される：ループの開始、タスクＴ３、Ｔ４、Ｔ５、Ｔ６によるＦｘ及びＦｙの計算の起動、その起動はｔ_３の時点の後、並列に行われる。

Ｔ２においてペア（ｕ、ｖ）の計算が終了すると、後続の実行はソース画像の座標にアクセスする。以下のケースが発生する。
● データ項目はクラスタのローカルメモリ内に存在する。操作されるには、データ項目が、その処理に割り当てられたＰＥによってアクセスされる必要がある。ＰＥ変換テーブルの状態に応じて２つのケースが発生し得る。
○ ＰＥのローカル変換テーブルがすでに更新されている：ＰＥはそのテーブルへのアクセス方法を把握しているので、データ項目を操作することにより、それに割り当てられた処理を実行することができる。
○ ＰＥのローカル変換テーブルが更新されていない：ＰＥはデータ項目へのアクセス方法を把握していないので、ＰＥのローカル変換テーブルの更新内容を返送するメモリマネージャに情報項目が送信される。図９は、ｔ_ｓ及びｔ_ｓ(の２つの時点の間でのＰＥ１の一時停止時間に相当する期間をタイムチャートによって表す。この時間はその変換テーブルを更新するのに必要である。
● データ項目がクラスタのローカルメモリ内に存在しない。ただし、最初に、ローカル変換テーブルが更新されていない場合に、これは前の場合と同じように発生する：ＰＥはメモリマネージャに要求を送信する。次いで、２つの予備の場合が区別され得る。
○ データ項目は、タスクマネージャによってタスクの構築に提供されるデータに従って、クラスタ上で予想されるデータの一部を形成する。ＰＥ上で実行するタスクが無効になり、スタンバイ状態でタスクＴ１からのデータを待機していることを示すデータ項目が、メモリマネージャによってタスクマネージャにディスパッチされる。図１０は、Ｔ３の実行の一時停止の最小時間に対応するｔ_ｓとｔ_ｓ’との間の期間をタイムチャートによって表す。
○ データ項目が、エンベロープ予測タスクＴ７によってクラスタで予想されるデータの一部を形成しない：無効なメモリアクセスの場合、メモリマネージャによってタスクマネージャに例外がアップロードされる。タスクマネージャはこのイベントでタスクＴ１’を起動し、欠測データ項目とその周辺をロードする。タスクＴ１’は図示していない。

その後、ソースポイントはタスクを生成するクラスタのローカルメモリに格納される。各ラインの最後で、タスクＴ２は（ｕ、ｖ）の現在のラインの極値を生成することで、タスクＴ７を与える。全てのライン又はいくつかのラインについて、タスクＴ２が極値の中間生成信号をディスパッチすることにより、Ｔ７は新たに生成されたデータでその実行を継続することができるようになる。

タスクＴ７は、Ｔ１とＴ２との間の場合と同じ原理に従って、Ｔ２の少なくとも１つのイベントを待機する。極値に加えて、前の画像の極値を使用して新たにロードする矩形を計算するが、実際には二次計算用に更に前の画像の極値を使用する。タスクマネージャに余地がある場合、即ちＰＥがフリーである場合、タスクは定期的にセットされ極値のペアの着信ごとに再実行される。ブロックごとに一度、タスクＴ６は、今後のローディング予測を作成し、ブロック処理イベントの最後をディスパッチする。

ＤＭＡタスクＴ８はＴ３、Ｔ４、Ｔ５、及びＴ６の生成バッファを、この４つのタスクの４つ１組のイベントの着信と合わせてマージする。このタスクは、宛先画像の更新内容をＤＲＡＭコントローラに送信する。このタスクは未使用のソース画像データをリスト内の後続のクラスタに送信する。それらのクラスタは、処理オペレーションのためにソース画像データを必要としているからである。

依存関係によれば、タスクの終了はＴ１から始まる必要があるが、タスクＴ１’は滅多に出現しないことが分かっている。次に、処理オペレーションの問題とローディングのランダムで予測できない変化とに依存する順番に従って次にタスクＴ３、Ｔ４、Ｔ５、及びＴ６を追従する。その後、ローカルデータのみに関する、処理が短いＴ２及びＴ７を追従する。最後に、ブロックの処理の最後を示すタスクＴ８（図示せず）をたどる。タスクマネージャは、Ｔ７の最後から新しいブロックでＴ１を再起動できる。

タスクマネージャは以下の中の様々な要素で構成されている。
● タスクごとに、タスクの起動に必要な最低限の依存関係のリストと、クォータのオーバーフロー又はデータを待機するスタンバイ状態等、実行を条件付けするイベントと、操作対象の仮想メモリ空間の記述子（オプション）とを含むタスクのリスト。
● 次のタスクを割り当てるためにタスクマネージャによって使用可能な仮想ＰＥのリスト。必ずしもＰＥを物理的に識別しなくてもＰＥの可用性との関連でＰＥの割り当ての物理的な識別がＰＥの管理手段によって管理されるので、このリストは仮想的なリストと呼ばれる。
● すべての前提条件を満足する、実行準備の整ったタスクのリスト。
● 実行準備の整ったタスクを、クラスタ上で利用可能な対応するＰＥと調和させるスケジューラ。最適なスケジューリングポリシーは、一般にはアプリケーションの分野によって決まる。例えば、クリティカルなタイムリアルスケジューリングは、有利には、最も期限が迫っているタスクを優先的にスケジュールするＥＤＦ（「最迫期限優先」）スケジューリングアルゴリズムに基づいたスケジューリングポリシーを使用する。制約が緩いマルチメディアシステムの場合は、コストのあまりかからないリニアタイムスケジューリングを調整するのが適切であると考えられる。このため、スケジューラはプログラム可能、再設定可能、又は少なくともパラメータ化可能であることが好ましい。

したがって、クラスタ上のタスクマネージャの主な役割は、ＰＥ及びタスク間の適合を管理することである。このタスクマネージャはまた、タスク間のチャーンも管理する必要があり、これには一般にデータの依存関係の様態と制御の様態という２つの様態が含まれる。大抵の場合、制御の様態は、正しく設定されたデータの依存関係によってシミュレーション可能であることに注意されたい。このように、タスクマネージャは、クラスタの中央要素の１つである。タスクマネージャは、ＤＭＡタスク等の種々のタスクから発信される、データの生成に関係する複数のイベントを受信する。ただし、タスクマネージャはまた、メモリマネージャから発信された、データを待機するスタンバイ状態にあるタスク又は使用可能なメモリ空間を示すイベントを受信する。更に例外的に、これらのイベントは割り当てられたメモリクォータを超えているタスクを示す。後者の場合、タスクマネージャの役割は、クォータ超過の原因となったタスクを可能ならば無効にすることにより、問題の制限を模索することである。次いで、第２の例示的なアプリケーションで、この様態をフロー制御と共に詳述する。

クラスタのローカルメモリ空間はメモリマネージャによって管理される。メモリマネージャは、ＰＥでのタスクの実行を可能な限り透過的に許可する必要がある。本例では、メモリマネージャはチップ上に収まらず、ましてやクラスタにも収まらない高解像度画像を透過的に使用できるようにする必要がある。このために、メモリマネージャは、仮想メモリとクラスタのローカルメモリ内のタスクとの間のやりとりをマッチさせる、データ生成と使用テーブルとを必要とする。メモリマネージャはまた、タスクの支援を必要とし、タスクはデータを生成又はクラスタのローカルメモリに格納されたデータの使用を終了するときに、クラスタマネージャに信号をディスパッチすることにより、その旨を知らせる必要がある。このために、例えば特殊な命令をタスクのコードにコンパイルツール又はプログラマによって挿入し得る。また、ＰＥのメモリ変換テーブルの提供及び更新を行う必要もある。前に示したモーフィングアプリケーションを実行するシナリオでは、メモリマネージャとクラスタの残りとの対話を以下のように合成することができる。
● まず、種々のタスクが起動される：要求されたデータをタスクＴ１がまだ受信していない場合は、クラスタのレベル及びタスクＴ２〜Ｔ６のレベルの変換テーブルに、予測ブロックのデータは与えられない。それでも予測ブロック内でメモリアクセスが発生しない場合、メモリマネージャはタスクによって要求されたデータがまだ利用できない旨をタスクマネージャに知らせるだけである。タスクマネージャは、存在するスケジューリングポリシー及びタスクに従って、タスクをスタンバイ状態に保持することを選択するか、タスクを交換して他より緊急なものに対応して切り替えることができる。
○ 要求されたアドレスが、タスクはアクセス可能であると推測される範囲の外にある場合、タスクマネージャに例外がアップロードされる。これがソース画像へのアクセスを伴う場合、例外手順ではローディング予測エラーを管理する必要がある。他のケースでは、実際にエラーを伴うと、そのように処理される。タスクマネージャレベルでこれを管理する方法は、そのプログラム可能であるレベルによって決まる。これはタスクマネージャの例外プログラムとしてプログラムされ得るか、単に例外ローディングタスクＴ１’を起動する信号として処理され得る。
● 時間Ｔ１でデータブロックが生成されるたびに、メモリマネージャにその旨が通知される。図１１において時点ｔ_３付近のタイムチャートによって詳細に示すように、メモリマネージャは以下の処理を行う。
○ 通信に応答してブロック１の割り当てを解除する。これについては図１１の時点ｔ_３で「メモリ１−ブロック１」の「Ｃｏｍ．Ｂｕｆ．」によって示す。
○ 通信に対して新しいブロック２を再度割り当てることで、通信チャネルに関する１つの損失を補償する。これについては図１１に「メモリ１−ブロック２」によって示す。
□ この再割り当てが失敗した場合、タスクマネージャに例外信号がアップロードされ、通信がエラー状態にあることを信号で伝える。
○ 消費タスクＴ２〜Ｔ６にブロックを割り当てながら、タスクごとにこのデータ項目のメモリクォータを超過していないことを確認する。このメモリクォータを超過している場合、ネットワーク伝送チャネルを無効にするためにタスクマネージャに信号がディスパッチされる。超過していない場合、メモリマネージャは実施形態を選択する際、以下のことが可能である。
□ タスクマネージャに系統的に警告を出して、タスクＴ２〜Ｔ６についてローカル変換テーブルを更新する。
□ タスクによって要求された全てのアドレスがアドレス変換テーブルに反映されるのを待って、対応するタスクの再起動が可能である旨をタスクマネージャに信号で伝える。この実施形態は最も効果的であり、これが可能な限り好ましい。
○ メモリマネージャはまた、タスクＴ７のためにＴ２の一部でデータ生成信号を受信し、Ｔ１によってロードされたデータのブロックに対して使用終了信号を受信する。したがって、タスクＴ２〜Ｔ６がすべて、所与のブロックについて使用終了信号をディスパッチした場合、この信号をディスパッチしたタスクのラベルと、これらのデータを使用するタスクのラベルのリストの内容との比較により、メモリマネージャは、他のデータによって再使用されるよう、対応するクラスタのローカルメモリ空間を部分的に解放することができる。
○ データがＴ１によって生成されるタスクＴ２〜Ｔ６の場合と同様に、変換されたブロックの極値の生成と並行してタスクＴ７をアクティブにすることができる。
● 目的の画像の生成と並行して、タスクＴ８はＮｏＣを介してＤＲＡＭにデータを転送し、これによって再使用可能になったローカル結果のブロックを解放する。
● オプションとして、データを早期にロードするためのメカニズムである当技術分野で公知の「プリフェッチ」フェーズにてロードされた余剰なデータは、後続のクラスタに転送することができ、これによって後続のクラスタは、必要とするデータの一部を取得するのにＤＲＡＭを通過しなくても済むようになる。

本発明に係る超並列アーキテクチャのデータによって高度に指示されるモーフィングアプリケーションを実行するためのメカニズムについて説明した。かかるコンテキストで潜在的な並列性を適切に使用することは非常に難しいが、それは積極的、且つ効率的な「プリフェッチ」メカニズムによって達成可能である。「プリフェッチ」予測エラーボックスは、実施するのが容易な例外プロシージャによっても考慮される。データへのアクセスは並列アーキテクチャの基本的なポイントであり、本発明によるアーキテクチャに対して実行モデルで特に発展される。

図１２、１３、及び１４は、ＭＰＥＧ−２復号化アプリケーションの例示的な実行を示す。今日、ＭＰＥＧ−２復号化は、難しいアプリケーションではなくなった。ＭＰＥＧ−２復号化には、特殊なプロセッサは必要ないが、当技術分野で公知の「Ｆｕｌｌ ＨＤ」画像を伴う場合、モノプロセッサフレームワークに扱いにくいアプリケーションが残ったままである。そのアプリケーションは代表的なデータフロー逐次処理オペレーションであるので、特に注目に値する。更に、そのアプリケーションは、増殖するビデオストリームを送信する、将来的に不可避なアプリケーションとなるであろう。したがって、ＭＰＥＧ−２復号化は、来るべき埋め込みシステムの重要な分野の例示的な産業向けアプリケーションである。

タスクチャートでは、図１２はＭＰＥＧ−２デコーディングの代表的なタスクの分割を示す。このチャートは重要なデータフローの側面を伴うモデルを実際に示し、このタイプの処理オペレーションに対する本発明によるアーキテクチャの実現の分析を可能にする。可変長のデコーディングタスク９０、マクロブロックのデータリシェーピングタスク９１、量子化タスク９２、逆離散コサイン変換タスク９３、飽和タスク９４、モーションベクタデコーディングタスク９５、輝度モーション補正タスク９６、赤色クロミナンスのモーション補正タスク９７、青色クロミナンスのモーション補正タスク９８、及びカラースペースの凝集と変換タスク９９を示す。本例では、クラスタが４つのＰＥからなると共に、タスクがＰＥに静的に割り当てられるものと想定する。この想定は、従来技術の専用のデコーディング又はエンコーディングシステムで行われているものと近い。提案するプラットフォームでのインテリジェントな実現ではない。図１２のタスク及びクラスタ１、２、３の間でデータを転送するためのＤＭＡタスク等の基本的なタスクは以下のように分散される。
● クラスタ１：
○ タスクＴＤＭＡＩ１Ｃ１：ＭＰＥＧ−２ストリームのクラスタ１へのＤＭＡインポート。
○ タスクＴ１Ｃ１：可変長のデコーダ。
○ タスクＴ２Ｃ１：マクロブロックのデータのリシェーピング。
○ タスクＴ３Ｃ１：量子化。
○ タスクＴ４Ｃ１：モーションベクタデコーダ。
○ タスクＴＤＭＡＯ１Ｃ１：クロミナンスモーションベクタのＤＭＡエクスポート。
○ タスクＴＤＭＡＯ２Ｃ１：輝度モーションベクタのＤＭＡエクスポート。
○ タスクＴＤＭＡＯ３Ｃ１：量子化されたマクロブロックのＤＭＡエクスポート。
● クラスタ２：
○ タスクＴＤＭＡＩ１Ｃ２：クロミナンスモーションベクタのＤＭＡインポート。
○ タスクＴＤＭＡＩ２Ｃ２：量子化されたマクロブロックのＤＭＡインポート。
○ タスクＴＤＭＡＩ３Ｃ２：リファレンスクロミナンスマクロブロックのＤＭＡインポート。
○ タスクＴ１Ｃ２：逆離散コサイン変換。
○ タスクＴ２Ｃ２：飽和。
○ タスクＴ３Ｃ２：モーション補正、赤色クロミナンス。
○ タスクＴ４Ｃ２：モーション補正、青色クロミナンス。
○ タスクＴＤＭＡＯ１Ｃ２：赤色クロミナンスのＤＭＡエクスポート。
○ タスクＴＤＭＡＯ２Ｃ２：青色クロミナンスのＤＭＡエクスポート。
● クラスタ３：
○ タスクＴＤＭＡＩ１Ｃ３：赤色クロミナンスのマクロブロックのＤＭＡインポート。
○ タスクＴＤＭＡＩ２Ｃ３：青色クロミナンスのマクロブロックのＤＭＡインポート。
○ タスクＴＤＭＡＩ３Ｃ３：輝度モーションベクタのＤＭＡインポート。
○ タスクＴＤＭＡＩ４Ｃ３：リファレンス輝度のマクロブロックのＤＭＡインポート。
○ タスクＴ１Ｃ３：赤色オーバーサンプリング。
○ タスクＴ２Ｃ３：青色オーバーサンプリング。
○ タスクＴ３Ｃ３：輝度モーション補正。
○ タスクＴ４Ｃ３：カラースペースの凝集及び変換。
○ タスクＴＤＭＡＯ１Ｃ３：デコード済みビデオストリームのＤＭＡエクスポート。

クラスタ内の通信フレームワークは、例えばクラスタ１のＴＤＭＡＯ２Ｃ１とクラスタ３のＴＤＭＡＩ１Ｃ３等のデータエクスポートタスクとデータインポートタスクの２つのタスクを常に伴うことに注意すべきである。このため、２つのクラスタ間の通信チャネルは、ソースメモリ空間、ＤＭＡエクスポートタスク、通信リンク、ＤＭＡインポートタスク、及びデスティネーションメモリ空間によって定義される。これは、これら５つの要素のいずれか１つが欠けた場合、当該２つのクラスタ間に通信リンクがなくなることを示唆する。このため、メモリとネットワークのディメンショニングが正しいことを保証することが、マッピング／ルーティングツールの責務となる。これら要素のいずれか１つが欠けたことに起因する通信エラーの場合、エラーが検出され、例外が生成される。現在の文書では、この例外を管理するためのメカニズムに関する追加要素は提供しない。このようなエラーは、実際、システムのアプリケーションの分野に応じ、異なる処理オペレーションが必要となる。こうした想定に伴い、ビデオストリームをデコードするには、３つのクラスタが必要となる。このため、各クラスタでは、ＰＥに４つのタスク、つまりＰＥごとにタスクが１つずつある。この構成はストリーム処理オペレーションにとっては一般に行われているもので、極力処理オペレーションが静的にマッピングされ、当該技術分野では周知である仮想「パイプライン」に沿ってプロダクション／コンサンプションの作用により負荷のバランスが取られる。尚、仮想「パイプライン」はストリームの処理を示す。以降に説明するように、このタイプの規制は本発明によるアーキテクチャの処理スキームで完全に可能である。更に、これはこれらのクラスタ及びその他のクラスタで並行して動作するその他のアプリケーションのまとまりについて考える可能性を排除し、更には大きな画像に対してクラスタのＰＥのパワーが不十分であると判明した場合にクラスタの複数のトリプルでの複数のデコーダについて考える可能性を排除するものではない。にもかかわらず、入力及び出力での処理オペレーションの順番を保証するためのタスクが必要である。

チャートの図１３に示すタスクの構成によって定義されるソフトウェア「パイプライン」に沿った実行は以下のように要約できる。
● ＴＤＭＡＩ１Ｃ１がストリームをその到着と並行してクラスタのローカルメモリにロードする。
● Ｔ１Ｃ１は事前パケットの数に関してクォータを有し、これにより、事前フレームの数が十分であると（おそらく通信レイテンシーに応じて３〜５フレーム）直ちに転送を停止できる。管理手段で可変サイズのブロックによる割当が許容されている場合、クォータを細かくディメンショニングできる。そうでない場合は、クォータは固定サイズのブロックの倍数である必要がある。
● 同様に、Ｔ２Ｃ１とＴ４Ｃ１はマクロブロックの数及び飽和前のデコードされていないベクタの数についてクォータを有する。この階層に達した場合、タスクマネージャはプロデューサタスク、即ちＴ１Ｃ１を無効にする。自動的にブロック解除されない状況の場合、既に無効になっているタスクＴ１Ｃ１はＴＤＭＡ１Ｃ１によって提供される入力データも消費しないため、通信は無効となる。クォータが正しく評価された時点から、クォータを制御するための前述のメカニズムにより、処理オペレーションの実現の重荷になることなく、暗黙的な方法でデータストリームの規制を実行できる。クォータが正しくディメンショニングされなかった場合、クォータの過負荷が原因で、メモリ割当又は通信の明示的なエラーを招く。この場合、パフォーマンスの低下のアンダーロードは容易に明らかである。コンパイル時にクォータを設定するだけで、通常の動作下でシステム自体が自身のロードバランシングを行うことは当然のことと思われる。
● これを当然のこととみなすと、アプリケーションの振る舞い自体は何ら問題を提起するものではない。タスクのデータの準備が整わない限り、そのタスクはスタンバイ状態に置かれるか、又はシステムに他のアプリケーションが含まれる場合及びスケジューリングポリシーで許容される場合は、スイッチングされる。１つ又は複数の消費タスクが遅過ぎて処理できない場合を除き、データが整うと同時に、処理オペレーションを実行し、出力データを生成できる。１つ又は複数の消費タスクが遅過ぎて処理できない場合、モーフィングアプリケーションで説明するように、消費タスクのメモリクォータの違反により、タスクマネージャによりプロデューサタスクは一時停止される。
● 到着時にいくらかのメモリが存在する限り、通信チャネルを定義するＤＭＡタスクに注目することで、クラスタ間のデータの受け渡しが行われることは明白である。このチャネルは処理オペレーション間の通信のルーティングに関連するもので、チップ上のアプリケーションの処理オペレーションのマッピング／ルーティングに起因する。このため、通信はオリジンクラスタのローカルメモリに格納されたソースデータを伴う。また、ＤＭＡ送信タスクも通信は伴う。更に、ルーティングによりその通信用に帯域幅が確保されているＮｏＣのチャネルも伴う。最後に、メモリマネージャによって動的に確保されているデスティネーションクラスタ上のＤＭＡ受信タスク及びそれに関係するメモリを伴う。これら４つの要素の結合により、静的にバインドされ、決定的である時間及びレイテンシーで通信を確立できる。このプロパティは、たとえＭＰＥＧ−２のデコーディングには当てはまらなくても、数多くのアプリケーションのケースにとって重要である。
● 所与のコンシューマに対するクォータ超過でデータプロデューサを無効にするための機能により、チェーンの途中でＮｏＣを経由するデータの転送があった場合等、タスク依存チェーンを選択的に、必要とする以内で無効にできる。再開も自動で行われ、あらゆることがコンパイルチェーンによるメモリクォータの制御に依存する。図１４のタイムチャートの例に示すように、このディメンショニングに不具合がある場合に問題を検出するための例外メカニズムが実現される。
○ Ｔ１Ｃ３による赤色クロミナンスのオーバーサンプリングが時点ｔ_ｑでクォータ超過であると仮定する。これはかなり長い操作であり、更に、特にビデオ処理チェーンの最後で、かなりの量のメモリを要求する可能性がある処理がこのクラスタにロードされる。メモリマネージャがタスクマネージャに通知し、タスクマネージャがＤＭＡ転送タスクＴＤＭＡＩ１Ｃ３を無効にするような状況を考案し得る。ＤＭＡ転送処理を伴うため、クラスタ２のタスクマネージャにメッセージがディスパッチされ、異常が通知される。対応するＮｏＣ通信を図１４に示し、これらは通信１００、１０１及び１０２である。
○ クラスタ２のタスクマネージャがＤＭＡ送信タスクＴＤＭＡＯ１Ｃ２を無効にする。
○ 無効が継続する場合、タスクＴＤＭＡＯ１Ｃ２は時点ｔ_ｑ’でクォータ超過に進む。この場合、メモリマネージャがタスクマネージャに通知し、タスクマネージャはプロデューサタスクＴ３Ｃ２を無効にする。このレベルでは、赤色クロミナンスを処理するためのローカルチェーンだけが影響を受け、その他は名目上動作を続行する。
○ 無効がまだ緩和しないとみなされた場合、Ｔ３Ｃ２は時点ｔ_ｑ"でクォータ超過に進むこともでき、これは２つの非排他的なシナリオを通して行われ得る：
□ モーションベクタのクォータ超過：メモリマネージャはクォータ超過の発生源をタスクマネージャに示し、タスクマネージャはＤＭＡ入力タスクＴＤＭＡＩ２Ｃ２を無効にする。クラスタ１のタスクマネージャにＴＤＭＡＯ１Ｃ１を無効にするためのメッセージが伝達され、これによってＴ４Ｃ１を無効にし得る。
□ 赤色クロミナンスに対するデコード済みブロックのクォータ超過：メモリマネージャはクォータ超過の発生をタスクマネージャに通知し、タスクマネージャはプロデューサタスクＴ２Ｃ２を無効にする。このため、最小依存チェーン、即ちサイクルが削除される逆依存グラフから推定された依存ツリーで構築されたチェーンを無効にするためのメカニズムが設計される。
○ タスクＴ１Ｃ３が時点ｔ_ｒでクォータ超過でなくなると直ちに、メモリマネージャはタスクマネージャに通知し、タスクマネージャはタスクＴＤＭＡＩ１Ｃ３を再度有効にする。タスクマネージャはクラスタ２のタスクマネージャにメッセージをディスパッチし、クラスタ２のタスクマネージャはＴＤＭＡＯ２Ｃ２を再度有効にする。クォータ超過の消滅と並行して、ローカルメモリマネージャはタスクマネージャに通知し、タスクマネージャは無効が発生したのと同じ状況下でタスクを再度有効にする。このため、「パイプライン」の平衡は、単純なルール及びメモリクォータの正しいディメンショニングの想定だけで、当然出現するプロパティである。
○ クォータが十分にディメンショニングされていない場合、メモリマネージャはこれを簡単に検出できる：欠陥のある状況が発生するまで、入力側で各データ項目に提供されている動的割当が名目上行われる。欠陥のある状況が発生すると、メモリマネージャは行われている要求に対してメモリの割当を試行するものの、どこか別の場所にあまりに多くのメモリが割り当てられているために、それを満たすことができない。このため、メモリマネージャはタスクマネージャに例外をアップロードしなければならなくなる。このタイプの例外の処理はアプリケーションの分野に大きく依存するため、本特許出願では指定しない。例えば、ディメンショニングプログラム等のプログラムの異常を検出するために使用できる。しかし、ノンクリティカルなアプリケーションに対して所与のメモリクォータを自動的にオンライン調節するためにも使用できる。
● アプリケーションの残りの実行では特別な問題を提起せず、２つの例示アプリケーションで既に説明した内容に基づき簡単に推定できるはずである。

本発明によるアーキテクチャの実行モデルはストリーム処理タイプのアプリケーションにも適していることは明白である。この特定のフレームワークでは、このタイプの処理における専門家にとっては当然である、データフローのバランスを動的に取るための単純なメカニズムを採用する。これは、モーフィングのフレームワーク内で見てきたように、このタイプの実行はより動的なタスクモデルと同じように管理できるため、本発明によるアーキテクチャ及びその実行について非常に優れた柔軟性が判明している。この実現で理解すべき重要なことは、提案するアーキテクチャとその実行モデルは同じアプリケーション内にネストされた２つのタイプのモデルを効率的に、即ち並列性を最適に活用して、実行できることである。これは特に、独自性を構築するものである。データフローモードのサポートがクラスタ内部だけでなく、クラスタ間でも行われることに注目することが重要である。データの欠如又はメモリの飽和を管理するメカニズムの描写がタスク及びメモリマネージャに対する重圧を前もって知らせる。但し、このようなモードの特定の管理を階層的に見ることができる。したがって、スタンバイ状態でデータを待機し、使用可能なメモリスペースを待機する等の、このような機能の一部分をＰＥにオフロードできる。この場合、タスクマネージャは２つのタイプのマネージャに分割される。第１のタイプは各ＰＥに対応するもので、データフローモードのサポートを保証する。タスクの割当とその考えられる割り込みを担当する第２のタイプは中央タスクマネージャと呼ばれる。中央タスクマネージャは、スタンバイ状態のタスクに割り込むか否かの決定を担う。その一方、中央タスクマネージャへのリソースを管理するポリシーを選択することも可能である。したがって、中央マネージャが関与しない、データフローモードで実際にオペレーションの処理を行うことができる。

もう１つの実行例、つまりハフ変換に基づく画像処理のアプリケーションの例を、並列化を多用する非常に動的な制御フローに与えることができる。ハフ変換の目的は、直線の線分、円、又は楕円等の単純な幾何学的図形の輪郭を画像の中から見つけることである。画像処理の分野におけるこうした従来のアプリケーションは並列化が困難である。この困難は、結果空間が必ずＰＥ間で共有されることに関係する。更に、このアプリケーションは多くのメモリ空間を必要とする。ハフ変換を行うには、輪郭の画像が完全にトラバースされ、トラバースの優先順はない。各輪郭点で、この点を通ることができる直線のセットを算出する必要がある。それぞれの直線は公式ｙ＝ａｘ＋ｂに従い、ａとｂの２つの値によってパラメータ化される。したがって、パラメータスペースは、それぞれの点が（ａ，ｂ）のペアを示す箇所で定義される。このため、画像の輪郭点を通過できる直線のセットはパラメータ空間の直線によって示される。パラメータ空間のこのような直線の集積で集合点が識別される。このような点それぞれが開始画像における線の存在を示す。こうした点によって、そこに関係付けられているパラメータをリカバリすることで、このような直線の位置を確かめることができる。輪郭画像の各ピクセルはパラメータ空間の直線に関係付けられているため、このアルゴリズムの並列化は問題が多い。入力画像を簡単に分散できれば、本質的に結果空間が共有される。画像のサブパートで各ＰＥを動作させ、これらサブ画像それぞれについてパラメータ空間を生成することは当然可能である。そのため、このような空間全てを集約して、１つだけにするための追加タスクが必要となる。このソリューションでは、Ｎ個のＰＥで並列化を行うには、最低Ｎ＋１個の画像を格納する必要があるため、必要となるメモリの量の問題が提起される。また一方、このような選択肢は、高度のシリコン効率が求められる組み込みシステムのコンテキストに沿うものではない。結論としては、このアルゴリズムは共有メモリを伴うアーキテクチャで実現できるものの、この並列化により多くのメモリ競合をもたらし、このためかなり弱い並列化に制限しなければならない。分散メモリを伴うアーキテクチャでは、メモリ空間をオーバーディメンショニングしなければならない。一般性における問題では、クラスタのメモリ容量がアプリケーションで必要とされるものを実際に下回るフレームワークの検討が要求される。このフレームワークは、従来の統合技術及びビデオ処理要件に沿うものである。以下で説明するように、本発明により、開始画像とパラメータ空間を様々なクラスタに同時分散させることにより、更に効率的にハフ変換を並列化できる。各クラスタは、画像の領域の読み取り、及びパラメータ空間の一部の書き込みを担う。例えば、矩形の形のメッシュを作成することで、この分割を行うことができる。アルゴリズムは機能上各クラスタで２つの部分に分割される。

アルゴリズムの第１の部分は、クラスタが担う画像の領域のピクセルの読み取りと輪郭点の検索である。検出された各輪郭点について、クラスタはこの点によって修正されるパラメータ空間の部分を算出する。直線の検索の場合、開始画像の点がハフ変換のフレームワーク内の直線になることが判明している。この直線のパラメータを使用することで、ハフ空間で修正される部分を確認できる。このため、クラスタは修正される領域を担当するクラスタを見つける必要がある。この識別が行われると、ＤＭＡタスクがアクティブとなり、パラメータ空間の領域を直線のパラメータで更新する旨の要求が該当するクラスタにディスパッチされる。潜在的には、各クラスタはその他の全てのクラスタにデータをディスパッチできるが、処理時に実際の受信者の算出が行われる。

アルゴリズムの第２の部分は、更新要求の受信に関するものであり、これは潜在的に全てのクラスタから生じ得る。それぞれの要求に対し、クラスタは更新を行う前に更新すべきパラメータ空間の部分を中央メモリにリカバリし、その後新しいパラメータ空間を中央メモリに再度書き込む必要がある。このレベルでは所与の数の最適化が可能であり、とりわけそれ以降の要求に役立つことができるパラメータ空間の一部をローカルメモリに保持できる。このアルゴリズムの部分は、ＤＲＡＭコントローラとのインターフェイスの機能により、２つの形を取ることができる。第１の実現方法によれば、対象の領域をリカバリでき、この場合、その領域の全てのピクセルが修正される。第２の実現方法によれば、より大きな領域（オプションで、クラスタが担当する領域全体）をリカバリでき、この場合、パラメータの直線に属するか否かでピクセルを更新できる。効率を考えると、第２の実現方法では、より大きな対象の領域のリカバリをマスクするには、所与の数の要求が蓄積されるのを待機する必要がある。要約すると、対象の細かい領域をリカバリすることにより、単純な更新処理と複雑な通信の結合をもたらすか、単純な通信とより複雑な処理を有するかのいずれかが可能である。

ハフアルゴリズムの並列化がシステムの通信機能と非常に結合することが明白である。クォータ管理又はタスク同期化等、２つの上記アプリケーションで既に示したメカニズムはハフ変換についても有効なままである。その一方、モーフィングとＭＰＥＧ−２デコーディングの２つの上記アプリケーションに関して、所与の数の差別化要素が存在する。第１の差別化要素は、所与の通信の受信者が処理中に計算されることである。通信の受信者を実行中に計算しなければならない場合、ＤＭＡプログラムはパラメータを取得し、その処理を調整できなければならない。既に前述したように、ＤＭＡはプログラムを実行し、ＤＭＡタスクはＰＥのタスクと同じメカニズムによって管理される。したがって、ＤＭＡタスクはパラメータよりも高い優先条件を有し、現在のケースではこれは受信者である。このため、パラメータが判明した時点で、ＤＭＡプログラムはこれをメモリに読み込み、通信を調整できる。このメカニズムは前述したデータフローモードもサポートする。したがって、実行中に受信者が変更になった場合、ＤＭＡプログラムはこれを次々にメモリに読み込む。これらのパラメータがまだ使用可能になっていない場合は、そのタスクはスタンバイ状態に置かれ、タスクコントローラによって管理される。また、受信処理を調整できるよう、データ項目をディスパッチするクラスタをコンシューマが識別する必要が生じ得る可能性があることも注意すべきである。これはＤＭＡブロック内で直接行うことも、又はリソースマネージャを経由して行うこともできる。

第２の差別化要素は、中央メモリに含まれるデータのリカバリを処理中に並列化できることである。これは、実際、予測された画像ブロックの「プリフェッチ」に対する「モーフィング」アプリケーションで説明したものと同じケースである。別のクラスタへのプログラム化された転送との大きな違いは、パラメータが一般化されることである。更に、中央メモリとのインターフェイスは様々な形をとることができ、可変的な機能を伴う。したがって、「中央メモリへのアクセスのクラスタ」を提案できる。その動作方式は、システムの残りの部分と類似の原理に基づき、特にクラスタの動作方式に基づく。又、マネージャとローカルメモリも使用する。これにより、中央メモリ内の対象の領域の要求では、まずクラスタによるパラメータのディスパッチから始めることができる。これらのパラメータが使用可能であると、ＤＭＡタスクがアクティブになり、中央メモリへの転送が行われる。更に踏み込み、中央メモリのクラスタにメモリ空間の部分の権利の管理を許容するユニットを提供し、これによって実行モデルのレベルで完全に均質なビューを有することさえ可能である。また一方、対象の領域によるこのタイプのアクセスが所与のアプリケーション分野で主流である場合、中央メモリのＤＭＡにこのモードを取り込む構造を特殊化することも可能である。

第３の差別化要素は、更新要求がデータによって指示されるため、輪郭点の存在の有無に関して、処理しなければならないデータの量をクラスタがわからないことである。何のメカニズムも考案しなかった場合、プロデューサがその作業を完了し、それ以上データを提供しなくなっていても、タスクがスタンバイ状態に置かれ、データを待機する可能性がある。このため、コンシューマがスタンバイ状態でロックしないように、プロデューサはタスクを完了したことをコンシューマに知らせることができるようにする必要がある。これは様々な方法で実施できる。一例として、特定のデータ項目の書き込み又はプロデューサからコンシューマへのイベントのディスパッチを考案できる。

このため、とりわけ実行中にダイナミックサポートを有する通信デバイスにより、本発明による実行モデルでハフ変換を効率的に並列化できる。作業負荷を適切に分散化させ、アプリケーションを最適化できるよう、処理オペレーションと通信との複雑さの妥協点を実現することが可能である。

本発明の基本的な利点は、本発明で提案するモデルが、高い実行決定論を維持しながら、タスクの並列化とデータフローモードの両方をサポートすることである。この実行パラダイムをサポートするために必要となる様々な機能の実現方法は様々な形を取ることができ、本特許出願では、その実現可能性を実証するいくつかの可能な経路についてのみが記載されている。とりわけ、ネットワークの性質及び処理又は通信要素の性質によって、本発明によるモデルが疑問視されることはなく、逆に多少なりとも妥当で効率的なものに変えられる。本発明のもう１つの利点は、クラスタ又は通信内の力学により、複雑なチェックを伴う集中的な計算アプリケーションを効率的に実現できることである。処理オペレーションと通信との間のオーバーラップで集中的な「プリフェッチ」ポリシーが許容され、通常データアクセスが形成するボトルネックを制限できる。

Claims (23)

1. タスクを並列に実行することによって所与のアプリケーションを実行するシステムであって、
   − 各々が１つ以上のメモリブロックを含むローカルメモリを備えた複数のクラスタに編成される処理ユニットと、
   − 前記アプリケーションのタスクのセットが該アプリケーションの実行ごとに同じクラスタで処理されるように、前記クラスタの１つに前記アプリケーションのタスクの１セットを静的に割り当てる手段と
   を具備し、
   前記各クラスタは、前記クラスタに割り当てられたタスクのセットが前記アプリケーションの実行ごとに異なる処理ユニットで処理されるように、前記クラスタの処理ユニットに前記クラスタに割り当てられたタスクのセットの各タスクを動的に割り当てるとともに該タスクに前記ローカルメモリのメモリブロックを動的に割り当てるクラスタマネージャをさらに備え、
   前記クラスタマネージャは、
   − 前記クラスタの前記処理ユニット上でタスクの実行を管理するタスクマネージャと、
   − 前記ローカルメモリの１つ以上のメモリブロックに含まれるデータの前記クラスタに割り当てられたタスクへの割り当てを管理するメモリマネージャと
   を具備し、
   前記タスクマネージャと前記メモリマネージャが同時に連携して動作し、
   クラスタに割り当てられたタスクが別のクラスタで生成されたデータを消費する必要がある場合、前記データが生成された前記クラスタ内でデータ送信タスクが実行され、前記データ送信タスクは、前記データが消費される前記クラスタ内で実行されるデータ受信タスクに前記データを送信し、
   前記データ送信タスクと前記データ受信タスクとの間の通信に専用のメモリ空間が、関係する前記２つのクラスタのうちのいずれかのクラスタの前記ローカルメモリ内で予約される
   ことを特徴とするシステム。
2. 各クラスタが備える前記ローカルメモリが、前記クラスタに専用となることを特徴とする請求項１に記載のシステム。
3. 前記処理ユニットのクラスタはチップに配置され、該クラスタがチップ上のネットワークを介して互いに通信することを特徴とする請求項１に記載のシステム。
4. 中央メモリを備えることを特徴とする請求項１に記載のシステム。
5. 各クラスタにタスクを静的に割り当てるためのリンクをコンパイル及び編集するための手段を有することを特徴とする請求項１に記載のシステム。
6. 前記データ送信タスクと前記データ受信タスクとの前記通信に専用の前記メモリ空間を飽和させないように前記送信タスクが一時的に中断されることを特徴とする請求項１に記載のシステム。
7. 前記データ送信タスクのスループットがコンパイル中に決定され、前記データ受信タスク用の空間を該空間の飽和の可能性がないよう前記ローカルメモリ内に割り当てることを特徴とする請求項１に記載のシステム。
8. 前記データ送信タスクが、前記データが生成される前記クラスタに静的に割り当てられ、前記データ受信タスクが、前記データが消費される前記クラスタに静的に割り当てられることを特徴とする請求項１に記載のシステム。
9. 前記データ送信タスクと前記データ受信タスクが、各クラスタ内の前記ローカルメモリとデータを直接やりとりする専用の実行手段によって実行されることを特徴とする請求項１に記載のシステム。
10. 前記データが消費される前記クラスタは、前記通信に専用の前記メモリ空間の使用可能な量に応じて前記データを生成する前記クラスタにクレジットを送出するように構成され、
    前記データを生成する前記クラスタは、前記データが消費される前記クラスタから受けた前記クレジットに応じて前記データ送信タスクのスループットを調整するように構成される
    ことを特徴とする請求項７に記載のシステム。
11. 前記データ受信タスクを実行する前記クラスタ用の前記クラスタマネージャは、前記データ送信タスクと前記データ受信タスクとの間の前記通信に専用の前記メモリ空間が所与の割り当て量を超えて使用されると、前記データ送信タスクを実行する前記クラスタ用の前記クラスタマネージャに割り込み信号を送出し、前記メモリ空間が割り当て量以内で使用されるようになると再開信号を送出するように構成されることを特徴とする請求項１に記載のシステム。
12. 前記ローカルメモリの割り当てられたメモリブロックは、固定サイズであることを特徴とする請求項１に記載のシステム。
13. 前記ローカルメモリの割り当てられたメモリブロックは、可変サイズであり、ローカルメモリによって形成されたアドレス空間の連続性の維持のためにデフラグメンテーション機能が用いられることを特徴とする請求項１に記載のシステム。
14. 前記タスクマネージャは、
    割り当て可能なタスクを提供する実行の前提条件を満足するタスクを前記タスクのセットから選択するためのモジュールと、
    スケジューリングポリシーに従って、前記割り当て可能なタスクを処理可能な処理ユニットに割り当てるためのスケジューリングモジュールと
    を有することを特徴とする請求項１に記載のシステム。
15. タスクを選択するための前記モジュールが、並列マルチタスクタイプの実行モードとデータフロータイプの実行モードにおいて同一時に実行の前提条件を満足する前記割り振り可能なタスクを判別することを特徴とする請求項１４に記載のシステム。
16. 前記実行の前提条件が、処理オペレーションの優先順位、又はデータの可用性、又は生成された前記データを格納するためのメモリ空間の可用性、又は前記クラスタのローカルイベント又はクラスタの外部イベントを含むことを特徴とする請求項１４に記載のシステム。
17. 前記データ送信タスクはいくつかのクラスタにデータを同時に送信することが可能であり、これによりいくつかの消費タスクに同じデータが同時に提供されることを特徴とする請求項１に記載のシステム。
18. 同一のクラスタ内でいくつかのデータ送信タスクが同時に実行可能であり、これによりいくつかの消費タスクに様々なデータが同時に提供されることを特徴とする請求項１に記載のシステム。
19. 前記タスクマネージャを過負荷にしないために、ＤＭＡタイプの送信タスク及び受信タスクを管理するマネージャをさらに具備することを特徴とする請求項１に記載のシステム。
20. 少なくとも１つの入力／出力インターフェイスを有することを特徴とする請求項１に記載のシステム。
21. 前記システムが、処理ユニット上で並列にタスクを実行することにより、モーフィングアプリケーションを実行可能であることを特徴とする請求項１に記載のシステム。
22. 前記システムが、処理ユニット上で並列にタスクを実行することにより、ハフ変換を実施するアプリケーションを実行可能であることを特徴とする請求項１に記載のシステム。
23. 前記システムが、パイプラインモードでタスクを実行することにより、ＭＰＥＧ復号アプリケーションを実行可能であることを特徴とする請求項１に記載のシステム。

Images