JP3559046B2 - データ処理マネージメントシステム - Google Patents

Description

発明の分野
本発明は、リアルタイムマルチメディア入力及び処理に使用できる形式のデータ処理マネージメントシステムに係る。
先行技術の説明
コンピュータのユーザインターフェイスは、テレタイプからキーボードへそしてキャラクタターミナルからGUI（グラフィックユーザインターフェイス）へと連続的に進化し、現在では、GUIが大部分のコンピュータユーザの標準的なインターフェイスとなっている。この進化は、サウンド及び3Dグラフィックスが次第に一般的となりそして3Dサウンド及びバーチャルリアリティが出現するというように続いている。その共通の脈絡は、ユーザに与えられるデータの形式が付随的に増加するために人間とコンピュータとのインターフェイスが益々複雑化することである。PC（パーソナルコンピュータ）アプリケーションは、この移行の利点を取り上げ、そしてそれらの完全な潜在能力を引き出すためにサウンド及び3Dグラフィックスを利用することに益々依存している。
その結果、チップ及びボード供給者は、２つ以上のデータ形式、例えば、2Dグラフィックス及びサウンド、又は2D及びMPEG（動画専門グループ）再生を取り扱うように設計された複合機能をもつ製品を提供するようになった。今日までのこれらの製品は、各データ形式ごとに個別の機能的ユニットを使用していることに注目するのが重要である。
最近、プログラマブルSIMD（単一命令多データ）アーキテクチャー（例えば、クロマティックMPACT）が出現している。これらアーキテクチャーは、同じ命令を実行する同一の処理要素を使用して、多数のデータブロックに対して同じ処理を並列して実行する。この解決策は、例えば、MPEGのようなデータ圧縮におけるブロック処理のような共通の機能を実行できるように容易に分割できるデータについては充分に機能するが、データ処理内で条件付きの流れ制御をしばしば必要とする完全な汎用アルゴリズムを実行するに充分な融通性がない。
又、DSP（デジタル信号プロセッサ）の売り主は、種々のデータ形式を処理するに必要な融通性を与えるMIMD（多命令多データ）デバイス（例えばテキサスインスツルーメント社のTI320C80）をこのマーケットに向けるように努めた。しかしながら、そのアーキテクチャーは、アプリケーションに必要とされるものよりも遙に大きな融通性を保持する汎用DSPコアの複製であるために、それにより形成されるチップは、一般的なPC及び消費者向けとしては非常にコストの高いデバイスとなってしまう。
汎用プログラム及びマルチメディア処理の両方について高速RISC CPUをプロモートするCPU（中央処理ユニット）の売り主は、数個以上のマルチメディア特有の命令をサポートするようにそれらのアーキテクチャーを妥協することができず（そしてそのように望まず）、それ故、妥当なコストで所要の性能レベルを得ることができない。又、CPUは、一般に、非リアルタイムのオペレーティングシステムを実行するのに使用されるので、待ち時間の短い処理を与えることもできない。
多数の処理ユニットを制御するVLIW（非常に長い命令ワード）命令を使用する専用のマルチメディアCPU（例えばフィリップス社のトリメディア）は、それらの処理能力を効率的に使用することができない。というのは、各命令が単一のタスク（及びデータ形式）に専用のものであり、それ故、使用できる全ての処理ユニットを最適に活用することができないからである。例えば、3Dグラフィックオペレーションに専用のVLIW命令は、MPEG運動推定に設計されたハードウェアの利点を取り入れることができない。又、処理ユニットの個数、ひいては、拡張性も、VLIWワードの長さにより制限される。
発明の要旨
本発明の好ましい実施形態は、システムコストを最小限にすると共に、マルチメディア及び関連工業規格の将来の進展に備えるように、全てのマルチメディアデータ形式を処理するデバイスの要求に向けられる。本発明の実態形態は、処理能力、リアルタイムI/Oサポート、及び実行できる同時アクティビティの数について拡張性のあるアーキテクチャーを提供する。
全てのマルチメディアデータ形式は、ベクトル処理解決策に適したデータの流れとしてみることができる。これら流れの幾つかは、リアルタイムであり（例えば、音声又は映像入力からの流れ）、従って、データロスを回避するために専用のバッファ又は低待ち時間処理を必要とする。又、各データ流は、それを処理するのに何らかのハードウェアリソースを必要とする。
本発明の好ましい実施形態は、データIO及びタスクスケジューリングのみを遂行する低待ち時間のリアルタイム処理を含む。これは、不要で且つコストのかかるバッファの必要性を回避する。又、必要なリソースが使用できるタスクのみが実行されるよう確保するための動的なリソースチェック方法も含む。
ホストの処理能力と、メモリのコストと、シリコンのコストとのバランスは、常時変化している。これは、ホストプロセッサとマルチメディア共通プロセッサとの間の最適な作業分担も、時間と共に変化することを意味する。このデバイスは、必要に応じて作業分担を変更できるようにプログラム可能である。
並列処理デバイスの拡張性は、ハードウェア設計及びサポートソフトウェアの両方にとって問題である。より多くの処理ユニットがデバイスに追加されたときには、処理ユニット間のタスクの振り分けが益々困難になり、利益の減少を招くか、又は機能ユニット間の相互接続数の指数関数的な増加を招く。又、このような変化は、一般に、サポートソフトウェアの大規模な変更を必要とするデバイスに対しプログラミングモデルの変更を招く。本発明の好ましい実施形態は、機能ユニット間の相互接続の急増を生じることなく且つデバイスへのソフトウェアインターフェイスに与えられるプログラミングモデルの変更を伴うことなく全ての要素を拡張できる一貫した拡張可能なアーキテクチャーによってこれらの問題に対処する。
図１は、デバイスの基本的なアーキテクチャーを示す。
デバイスは、マルチメディアデータを処理するのに必要な現在及び将来の全てのアルゴリズムに適合できる再構成可能なエンジンと考えられている。これによって行われる作業は、２つの分類に分けられる。リアルタイムスケジューリング及びIO処理の両方は、メディアコントロールコアにより実行され、一方、計算能力の高いデータ処理は、１つ以上の付加的なデータ処理ユニットにより実行される。
この作業分割は、アーキテクチャーの基本的特徴の１つである。
データ処理は、次のような多数のステップより成る。
パラメータフェッチ及び設定；
データフェッチ及び設定；及び
データ記憶。
高いデータ処理スループットを効率的に達成するために、プロセッサは、適度な大きさのデータセットに対して上記オペレーションを行うことが必要である。データセットがあまりに小さいと、プロセッサは、タスク間のコンテクスト切り換えと、それに伴うスレッド状態のセーブ及び再記憶の必要性とにその能力のほとんどの部分を費やすことになる。
メディアコントロールコアは、IOポートとメモリとの間にデータを移動する（データ処理を行えるようにするために）要求に応じるためにのみ必要とされるので、各クロックサイクルにコンテクスト切り換えすることができ、これは、次いで、リアルタイムIOをサポートするための大きなデータバッファの必要性を排除する。データ処理ユニットは、データに対してアルゴリズムの重要な部分を中断なしに実行することにより効率的にデータを処理することができる。
これらの処理要素は、アクティブなアルゴリズムを実行するのに必要なデータセットをキャッシュ処理することにより効率的なデータ移動及び処理をサポートする拡張可能なマルチバンクキャッシュによりサポートされる。
本発明は、その種々の特徴について、請求の範囲に詳細に規定される。
【図面の簡単な説明】
添付図面を参照し、本発明の好ましい実施形態を一例として詳細に説明する。
図１は、本発明の実施形態のブロック図である。
図２は、図１のメディアコントロールコアのブロック図である。
図３は、本発明の第２の実施形態のブロック図である。
図４は、メディアコントロールコアのコントロールユニット命令パイプラインを示すブロック図である。
図５は、図４のデータバンクの１つの内部アーキテクチャーを示すブロック図である。
図６は、メディアコントロールコアによりリソースチェック、ひいては、プロセス選択をいかに実行するか示すブロック図である。
図７は、図１のバンク型キャッシュメモリへいかにアクセスするかを示すブロック図である。
好ましい実施形態の詳細な説明
本発明の実施形態の基本的なアーキテクチャーが図１に示されている。システムの中心は、メディアコントロールコア（MCC）２である。これは、微細粒度のマルチスレッディングプロセッサである。これは、リアルタイムデータ入力及び出力デバイス４に接続できる複数の入力及び出力を有する。デバイス４は、例えば、ビデオソース、オーディオソース、ビデオ出力、オーディオ出力、データソース、記憶装置等である。簡単な例では、１つの入力及び１つの出力のみが与えられる。
又、メディアコントロールコア２には、複数のデータ処理ユニット６も接続される。これらの各々は、データパイプライン10を経てデータの処理を制御するデータ処理コア８を含む。コア８は、パイプライン10のマイクロ命令をデコードしそしてシーケンスする。
又、メディアコントロールコア２には、マルチバンク型キャッシュメモリ12も接続され、このメモリからメディアコントロールコア２及びデータ処理ユニット６によりデータが検索されると共に、メディアコントロールコア２及びデータ処理ユニット６によりこのメモリにデータが書き込まれる。
メディアコントロールコアは、入力からデータ処理コア又は記憶装置へデータを導くと共に出力へデータ供給する微細粒度のマルチスレッディング処理ユニットである。これは、各クロックサイクルにタスクを切り換えできるように構成される。これは、各クロックサイクルに、それが実行できる考えられるオペレーションのどれが、実行されるべきタスクに対して使用可能な全てのリソースを有するか、そしてその中でどれが最も高い優先順位を有するかをチェックすることにより達成される。充分な処理能力が与えられる場合には、各クロックサイクルに２つ以上のオペレーションを開始するように構成することができる。
このリソースチェックは、特定のタスクを実行するに必要な全てのものが存在するよう確保する。これは、データが入力ポートに得られるかどうか（EGビデオデータ）、或いはデータ記憶装置又は出力が使用できるかどうかといった外部リソースを含む。又、一時的な記憶のためのデータバンクや、特定の新たな処理動作に必要な他のデータ又は既に処理されたデータに現在作用していない使用可能な処理コアのような内部リソースも含む。メディアコントロールコアは、入力から適当なデータ処理ユニット６へデータを送って処理を実行し、そして必要なときに必要に応じてキャッシュを使用して出力へデータをルート指定するように動作する。１組の命令の実行が処理ユニットにおいて開始されると、MCCは、それが実行できる種々のスレッド及びそれに対して使用できるリソースを再び探すことができ、その間に、プログラムはデータ処理ユニットにおいて実行を続ける。
メディアコントロールコアのリソース及び優先順位チェックは、ビデオ入力のようなリアルタイムデータとして働くタスクを、現在のリアルタイム入力に通常必要とされる大きなメモリバッファを伴わずに実行できることを意味する。ビデオ入力のようなオペレーションでは、メディアコントロールコアは、IOポートにデータが得られるかどうかを調べ、もしそうであれば、そのデータを受け取って、マルチバンク型キャッシュの一部分又はデータ記憶レジスタへ送り、データ処理ユニット６の１つで処理するための準備をする。
全てのデータ処理ユニット６は、メディアコントロールコア２の制御及びスケジューリングのもとにある。図１に示す例では、これらのユニットは、その関連するデータ処理コア８の制御のもとで、乗算器、加算器、シフタ等の多数の処理要素で作り上げられる処理パイプライン（データパイプライン10）より成り、処理コア８は、一連の命令を実行してデータ処理アルゴリズムを実行する。これらデータ処理コアの各々は、特定のデータ処理を実行するための一連の命令を記憶するそれ自身のマイクロ命令ROM及び／又はRAMを有する。メディアコントロールコアは、データ処理ユニット６を呼び出し、例えばアドレスオフセットをそのマイクロ命令ROMに通して実行の開始を命令することによりその特定のオペレーションシーケンスを実行する。次いで、マルチバンク型キャッシュからのデータ、又は１つの入力からメディアコントロールコアへ通されたデータに対して特定のプロセスを完了まで実行し、その際に、処理が完了したことをメディアコントロールコアに通知する。
図１のマルチバンク型キャッシュ12は、メモリアクセスに対して使用され、これらは全てこのバンクを通してキャッシュ処理される。キャッシュは、複数のバンク14に分割され、その各々は、行われる１つのデータ処理タスクの要件に適合するようにプログラムすることができる。例えば、キャッシュバンクは、3Dグラフィックレンダリングに使用するためにメインメモリからのテクスチャマップをキャッシュ処理するのに専用としてもよい。キャッシュバンクのこのプログラム特性を使用すると、オンチップメモリを最大限に使用できると共に、動的なキャッシュ割り当てを実行することができ、これにより、特定の条件のもとで最良の性能を得ることができる。
更に、多数のキャッシュバンクの使用は、キャッシュを非ブロッキングにすることができる。即ち、キャッシュバンクの１つが、現在満足することのできない要求、例えば、データが現在得られないような読み取り命令を処理している場合には、個別のキャッシュバンクを使用する別の処理スレッドを動作することができる。
図１に示す全デバイスは、拡張可能であり、シリコンの単一断片上に集積チップとして構成することができる。メディアコントロールコア２は、図２を参照して以下に述べるように拡張できる。メディアコントロールコアのサイズが増加するにつれて、メディアコントロールのための同じプログラミングモデルを使用しながらも更に別のデータ処理ユニット６をサポートすることができる。又、更に多数のキャッシュバンクを追加して、更に別のデータ処理ユニットをサポートすることにより、メディアコントロールコア及びデータ処理ユニットに対するデータスループットの有効性を高めることができる。デバイスのプログラムモデルが変化しないので、これは、高度の下位互換性を得られるようにする。
メディアコントロールコアが図２に詳細に示されている。これは、コントロールユニット16と、１組の読み取り／書き込みユニット18と、１組のプログラムカウンタバンク20と、１組のアドレスバンク22と、１組のデータバンク24と、１組の入力／出力バンク26とで構成される。これらのバンクは、全て、メディアコントロールコア状態バス28、メディアコントロールコア制御バス29及びメディアコントロールコアデータ相互接続部30によって互いに接続される。メディアコントロールコアデータ相互接続部は、種々の異なるバンク間にデータを送信するのに使用され、そして状態バスは、入力／出力ポートの状態や、メディアコントロールコアが命令及びデータを送信できるところのデータ処理ユニットの状態のようなデータを供給する。
更に、ROM及びRAMにマイクロ命令を記憶するメモリブロック32は、コントロールユニット16及び上記のユニット18−26に接続される。
コントロールユニットを除いて全てのコア要素18−26は、それらからデータを読み取ったり、それらにデータを書き込んだり、それらに記憶されたデータ間でオペレーションを実行したりすることのできる同じ基本的インターフェイスモデルを有する。各バンクは、処理ユニット及び演算論理ユニット（ALU）と共に、密接接続のローカル記憶レジスタファイルで構成される。
コントロールユニット16は、メディアコントロールコアの実行を制御するのに使用される。これは、各クロックサイクルごとに、メディアコントロール状態バス28により供給される状態情報を使用して、全てのリソースの利用性（例えば入力／出力ポート状態、データ処理ユニットの状態等）を、その制御のもとで各プログラムを実行するのに必要なリソースに対してチェックする。次いで、全てのリソースが使用できる最も優先順位の高いプログラムスレッドに対して命令の実行を開始する。
プログラムカウンタバンクは、メディアコントロールコアによってサポートされる各処理スレッドごとにプログラムカウンタを記憶するのに使用される。これは、メディアコントロールコアがサポートできる各処理スレッドに対するレジスタと、プログラムの進行、ループ動作、分岐等のためにプログラムカウンタに対して全てのオペレーションを実行するAULとで構成される。データバンク24は、メディアコントロールコア内のプログラムの流れを制御するためにデータに対する汎用動作に使用される。それらは、MMCにおいて動作する処理スレッドにより必要に応じて使用できる一般的なリソースである。
アドレスバンク22は、命令及びデータの両方に対するアドレスを記憶しそして操作するのに使用されると共に、データバンク24と同様の一般的なMMCリソースでもある。
入力／出力バンク26は、MCCによりサポートされる入力／出力に対しメディアコントロールコアとリアルタイムデータ流との間のインターフェイスを形成する。それらの状態は、例えばビデオ入力のようなポートにおけるデータの入手性、又は出力のためのデータを取り出すポートの能力を指示する。それらは、オプションとして、データが取り込まれ又は取り出されるときにデータを変換する能力、例えば、データ流のビットスタフィングを含むことができる。
読み取り／書き込みバンク18は、メディアコントロールコアとメモリとの間のインターフェイスを形成する（マルチバンクキャッシュを経て）。一度に２つ以上の処理スレッドを動作できるときには、メモリ要求のブロッキングを回避するために２つ以上の読み取り／書き込みユニットが必要とされる。
メディアコントロールコアは、全ての重要な観点で拡張可能である。これは、記憶（レジスタファイル）及び処理（ALU）をローカライズするバンクから構成されるので、ルート及び相互接続を管理できないという問題を生じることなく付加的なバンクを追加することができる。サポートできる処理スレッドの数は、プログラムカウンタバンクにレジスタを追加しそしてそれに応じてコントロールユニットを変更することにより増加することができる。MCCによりサポートできる入力／出力流の数は、更に別のIOバンクを追加することにより増加することができる。
データスループットは、更に別の読み取り／書き込みユニット18を追加することにより増加できると共に、全MCC処理能力は、更に別のデータ及びアドレスバンク24、22を追加することにより増加できる。
図３は、データ処理マネージメントシステムの特定の実施形態を示すブロック図である。このシステムのMCCは、複数のリアルタイムデータ入力／出力ポートとして働き、そしてそこから受け取った及びそこに出力されるデータを処理するようにデータ処理ユニットを制御する。
図示されたように、ビデオ入力34及びオーディオ入力36が、関連する前プロセッサ38及び40を経てメディアコントロールコアに接続される。対応するビデオ出力42及びオーディオ出力44は、各後プロセッサ46及び48を経てメディアコントロールコア２に接続される。ビデオ及びオーディオ入力及び出力は、デジタル入力及び出力である。
図１の場合と同様に、メディアコントロールコア２は、この場合にメインキャッシュバンクと称するマルチバンク型キャッシュ12に接続される。二次コア８及びデータ（メディア）パイプライン10を含むデータ処理ユニット６は、メディアコントロールコアに直接接続され、そしてそれらに供給されるべきデータを処理するのに使用される。
又、メディアコア２には、処理ユニット50も接続され、これは、デジタル／アナログコンバータ供給コア（DAC供給コア）52と、DAC供給パイプライン54とを備え、このパイプラインは、デジタル／アナログコンバータ56にデータを供給する。その目的は、グラフィック出力を供給することである。このため、処理ユニット50は、フレームバッファインターフェイス58を経てデータをフェッチし、そしてホストコンピュータ映像グラフィックアダプタ（VGA62）用のシステムバス60は、互換性のためにのみ保持される。従って、リアルタイムデータは、ビデオ及びオーディオ入力に送られ、そしてビデオ及びオーディオ出力を経て送り出すことができるが、グラフィック出力は、DAC56により送信することができる。
グラフィック出力のためのデータは、図３ではフレームバッファインターフェイス58を経て接続が示されたグラフィックフレームバッファのようなソースからの非リアルタイムデータ、3Dデータ、又はリアルタイムビデオを処理することにより発生できる。
二次コア８及びメディアパイプライン10は、音声、3D、2D、映像スケーリング、映像デコード等の処理を行うことのできるデータ処理ユニットの一例である。これは、何らかの形式の汎用プロセッサで形成することができる。
DAC供給コア及びDAC供給パイプラインは、DACのためのRGBデータを発生するために多数のフレームバッファからのデータを専用に処理する。これは、ピクセルごとにソースバッファ間で切り換わることができ、従って、YUVを含む多数の映像フォーマットから得られたデータを変換し、そして多数のフレームバッファからのソースデータを混合によるか或いはカラー又はクロマキー動作により合成することができる。
各コアは、ROM及びRAMで形成された関連するマイクロコード記憶装置を有し、これは、明瞭化のためにここには示さないが、プロセッサにより実行されるべき命令を記憶する。キャッシュバンク12は、メディアコントロールコア及びデータ処理ユニット６、50にインターフェイスする。それらは、アドレス変換ユニット64を経てシステムバスにもインターフェイスする。又、それらは、１つ以上のフレームバッファにデータを書き込んだりそこからデータを読み取ったりするためにフレームバッファインターフェイス58にもリンクされる。
データバンク24が図５に示されている。これは、レジスタファイル72と、ALU74と、マルチプレクスユニット76とを含む。データバンクのオペレーションは、レジスタファイルへ入力されるWE、Ｗ、R1及びR2と示されたマイクロ命令の多数のビットにより制御される。ALUにより実行されるマイクロ命令の結果は、状態ビットＨ、Ｓ、Ｚとして得ることができ、これらは、分岐及び条件付き命令を実行するためにメディアコントロールコアのコントロールユニットにルート指定される。
レジスタファイルは、各クロックサイクルに、２つのオペランドを入力からフェッチしそして１つのオペランドを出力に書き込むことができるように構成される。データ入力ポート78及びデータ出力ポート80は、それらが接続されたメディアコントロールコアデータバス30を経て他のデータと通信することができる。従って、図５のデータ流は、図を通して垂直方向下降し、一方、制御情報の流れは、左から右へと進み、コントロールユニットからの制御ビットと、コントロールユニットへ返送されるデータバンクの状態を表す状態ビットとで形成される。
複数のこれらデータバンクが使用され、その各々は同じ形態であり、即ちその各々は、図５に示すようにALUに密接に接続されたそれ自身のレジスタファイルを有する。複数の密接に接続されたレジスタ及びALUを好ましくは１対１の関係で使用するこの構成体は、レジスタバンクと多数のALUとの間の複雑なマルチプレクスが必要とされた多数のALUの公知の構成体とは異なる。
一般に、これらのデータバンクは、MCC内のプログラムの流れを制御するようにデータに対して汎用のオペレーションを実行し、そしてMCCにおいて動作する処理スレッドにより使用することができる。
アドレスバンク22、プログラムカウンタバンク20、IOバンク26、及び読み取り／書き込みユニット18は、全て、同様に構成されて動作するが、それらの実施を最適化して、それらが使用される方法を反映するように、個別のユニットで設けられる。
アドレスバンクは、メモリ（図示せず）へデータアクセスするためのアドレスを記憶しそして操作する。それらは、非符号化アキュムレータを使用し、そして状態バスを経てコントロールユニット16に変更される条件コードを発生しないという点で、データバンクより若干簡単である。
プログラムカウンタバンクは、メディアコントロールコアによってサポートされるスレッドを各々処理するためのプログラムカウンタを記憶するのに使用される。従って、図５に示された形式のバンクにおけるレジスタの数は、MCCがサポートできる処理スレッドの数に等しい。アドレスバンクの場合と同様に、ALUは、プログラムカウンタ動作に使用され、そして非符号化される。これは、コントロールユニット２に返送される条件コードを発生しない。
IOバンクは、IOポートにインターフェイスするのに使用され、レジスタもALUも含まない。それらは、MCCによりサポートされるリアルタイムデータ流とインターフェイスする。状態信号は、ポートにおけるデータの入手性、又はデータを採取するポートの能力を指示する。それらは、データが転送されるときにデータを変換する能力を任意に含むことができる。
読み取り／書き込みユニットは、キャッシュバンク12にインターフェイスする。それらは、レジスタもALUも有していない。読み取りユニットは、アドレスを受け入れ、そしてデータが返送されないときに、データ有効状態ビットをセットする。書き込みユニットは、アドレス及びデータを受け入れる。多数の読み取り及び書き込みユニットを使用し、１つのキャッシュがブロックをアクセスする場合に、別のスレッドが別の読み取り／書き込みユニットを介して実行を継続できるよう確保する。
各データ処理スレッドごとにコントロールユニット（図示せず）をもつ命令バッファは、そのスレッドの次のマイクロ命令及び命令オペランドを記憶する。命令及びオペランドは、その命令を実行するのに必要なリソースを示すビットを含む。これらのリソース要求は、メディアコントロールコア２、外部IOポート20及びデータ処理ユニット６、50の現在状態を示す状態ビットと共にコントロールユニットのリソースチェックロジックへと供給される。ロジックゲートのアレーのような簡単な組合せロジックは、命令を実行できるかどうか決定し、そしてコントロールユニット16の固定優先順位セレクタは、最も優先順位の高い実行可能なスレッドをデータ経路制御パイプライン（図４に示す）へ送り出し、そのプログラムスレッドの実行をスタートする。スレッドタスクは、「受信ビデオデータ」、「プロセス記憶オーディオデータ」等である。
通常、命令は、それが実行されるときに、そのスレッドの次の命令をメモリから読み取ることを必要とする。命令は、命令opコード及びオペランドを含むメモリ（プログラムカウンタで指示された）から読み取られる。命令のopコードフィールドは、次の命令を検索するためにマイクロコードROMをインデックスするのに使用され、それにより得られるマイクロ命令は、命令オペランドフィールドと共にスレッドの命令バッファに記憶される。
リソースチェック及び優先順位が図６に完全に示されている。図示された３つのスレッドに対し、全体的な状態情報は、必要なデータバンク及び必要なアドレスバンクから受け取られ、ルートコントロールデータは、コントロールユニットから、コントロール状態情報は、コントロールユニット16から、そして実行依存性データは、特定のスレッドが依存する他のプロセスから受け取られる。この全ての情報は、リソースチェッカ80へ送られ、該チェッカは、それをIOポートからのデータ、種々のパイプラインデータバンク状態、及び種々のデータ処理ユニットの状態と合成する。これは、考えられる各スレッドに対して行われる。そのデータ処理スレッドを実行できる場合には、優先順位セレクタ82へ出力が発生される。これは、サポートされるデータ処理スレッドの各々の優先順位に関する情報を有し、その結果、最も優先順位の高いスレッドを実行のために選択することができる。例えば、映像のようなリアルタイムデータ入力には高い優先順位が与えられ、これは、バックグランド処理動作より高い優先度をとる。
スレッドの次の命令は既に命令バッファに与えられているので、その命令は、常にリソースチェック及び優先順位選択に使用できる。従って、各クロックサイクルの状態をチェックすることにより実行時間のロスがなくなる。
図４に示すデータ経路コントロールパイプラインは、マイクロ命令のフィールドを異なる深さでパイプラインに入れられるようにすることにより動作する。これは、マイクロ命令が多数のクロックにわたりパイプラインを通るデータの流れを制御できるようにし、ひいては、データのパイプライン処理を制御できるようにする。
図４の回路は、アンドゲート92の出力をそのイネーブル入力に受け取る１対４デコーダ90を備えている。アンドゲート92の入力は、マイクロコード命令からの制御ビットと、命令の条件付き実行に使用される条件コードである。出力選択であるマイクロコード命令からの一対のタイミングヒットがデコーダ90に入力される。デコーダ90の４つの出力は、オアゲート94を経て、シフトレジスタとして構成された４つのＤ型フリップ−フロップ96への入力を形成する。デコーダ90からの出力は、ゲート94において、レジスタの手前のフリップ−フロップ96の出力（第１フリップ−フロップ96からの出力）とオアされる。ビットは、マイクロコード命令の実行を開始する出力制御ビットとして出現するまで、クロック98によりレジスタに沿ってクロックされる。
従って、制御ビットは、必要なクロックサイクルで行先バンクに到達するようにそのスケジューリングパイプラインの正しい位置に挿入される。概念的には、このような命令ビットパイプラインは、全てのマイクロコード制御ビットに対して存在するが、コントロールパイプラインを実施するのに必要なロジックの量を制限するために、マイクロコードのあるフィールドを配することのできるクロックサイクルに限度が設けられる。
条件付き実行は、条件付きオペレーションを特定しそして条件ビットを発生することにより達成される。２つの形式の条件付きオペレーションがサポートされる。第１の形式は、同じ又は別のバンクからの条件コードでバンクへの書き込みイネーブルパルスを定質化することである。第２の形式は、ある条件コードが真である場合にマイクロ命令ワードが再び実行される（プログラムカウンタからの次の命令ではなく）ことを特定することである。条件コードに対する可能性の数を制限するために、これらの条件付きオペレーションにおいてデータバンク条件コードしか使用できない。
マイクロ命令フォーマットの例
このアーキテクチャーに対するマイクロ命令フォーマットの例を以下に示し、サイクルごとにマルチスレッド処理を達成するためにこれをいかに使用するかについて説明する。
図６には、多数のスレッドのマイクロ命令が示されている。その各々は、次のものを含む。
各バンクに対するコントロールフィールド、例えば、レジスタ選択ビット及びALU制御ビット；
各バンクに対する命令タイミングビット−これらは以下で説明する；
バンク間のデータのルートを制御するルートコントロールビット；
命令を条件付きで繰り返すべきか及びそれが即時データオペランドを含むかどうかを示すコアコントロールビット。
性能のために、命令は、多数のクロックサイクルにわたって実行することが許される。命令の一部分が実行される時間は、コントロールユニット命令パイプライン（図６）に制御ビットを入れる位置を制御するバンクコントロールフィールド内の遅延ビットによりセットされる。
制御ビットは、メディアコントロールコアの将来の状態を表す命令パイプラインに入れられるので、コントロールユニットロジックは、命令遅延がリソースチェック時に準備されそして命令がそれが実行されるいかなるクロックサイクルにも矛盾を生じないよう確保することができる。
実行依存性
ハードウェア設計の複雑さを低く保つために、命令は、多数のクロックサイクルにわたって実行することが許される。命令の一部分が実行される時間は、バンクコントロールフィールド内の遅延ビットにより制御される。
リソースチェックが行われるときにこの命令遅延が各クロックに対して準備され、そしてオペレーションが正しいサイクルで行われるように確保するために、遅延ビットに対応するopコードが、各サイクルにクロックされる１組のラッチへ供給される。これらのラッチの出力は、データパイプラインの将来の状態を表し、そしてリソースチェックロジックへ供給されて、命令がそれが実行されるいかなるクロックサイクルにおいても矛盾を生じないように確保する。
バンク型キャッシュ
マルチバンク型キャッシュは、多数のキャッシュバンクで形成され、図７に示すように処理ユニット及びメモリにインターフェイスする。任意に拡張できるデバイスをサポートするために、多数のキャッシュバンクが使用される。各バンクの使用は、読み取りユニット又は書き込みユニットのようなキャッシュユーザに関連したキャッシュアロケータ86により制御される。これらは、キャッシュバンクを異なる構成で使用するためにプログラム可能に制御される。例えば、コマンドデータに１つのバンクを使用し、3Dテクスチャマップに別のバンクを使用し、そして2Dパラメータに第３のバンクを使用する。キャッシュバンクを構成する機能は、良好なメモリ性能を達成する上で重要である。
キャッシュへアクセスを要求する読み取りユニット88又は書き込みユニット90のような各ポートは、アロケータモジュール86に接続される。これらのモジュールは、ポートによってなされるメモリ要求を検討し、そして適当なキャッシュバンクにその要求をルート指定する。ポートから送られるアドレスは、書き込みアロケータにおいてベースレンジレジスタ対と比較され、アドレスが所与の領域内に入るかどうか決定する。一致が生じた場合には、要求がキャッシュバンクに送られる。一致が生じない場合には、デフォールトキャッシュバンクが使用される。これは、メモリサブシステムへ要求を単に通すことより成る。
ポートに接続されたモジュールのメモリ要求に基づいて２組以上のベース及びレンジレジスタが使用される。
所与の各アロケータから全てのキャッシュバンクにアクセスできるようにする必要はない。ある部分は、他の部分より融通性がなければならない。これは、キャッシュバンクの数を容易に拡張（増加）できるようにする一方、アロケータとキャッシュバンクとの間に必要とされる相互接続の増加を制限する。従って、１組のキャッシュは、ビデオ入力要求並びにオーディオ入力及び出力を処理するように割り当てられる一方、他のキャッシュは、メインメモリからのデータフェッチを主として処理するように割り当てることができる。
各キャッシュバンクは、アービタ94を経て読み取り及び書き込みアロケータに接続される。アービタは、全てのアロケータからアクセスのための要求を受け取り、そしてどのアロケータがその特定のキャッシュバンクへのアクセスを得るべきかを決定することができる。これは、各ポートに優先順位を指定し、そして単純に保留中の最も優先順位の高い要求をアービタが処理するように構成することにより行われる。
システムは、MPEG及びビデオ会議のような他の形式の入力を使用するように拡張することができる。

Claims (31)

1. 独立命令スレッドを実行するためのデータ処理マネージメントシステムにおいて、複数のデータ入力と、複数のデータ出力と、各々が上記命令スレッドの少なくとも１つを構成する命令を実行するためのデータ処理動作を実行できる複数のデータ処理手段と、データ記憶手段と、コントロール手段とを備えており、
   上記コントロール手段は、
   １つ以上のプログラム可能なルート指定動作において、上記データ入力のうちの選択された１つと、上記データ出力のうちの選択された１つと、上記データ処理手段のうちの選択された１つと、データ記憶手段との間に、複数のルート指定動作の中から選択されたルート指定動作にて、データを選択的にルート指定するための手段と、
   データがルート指定された各データ処理手段が上記命令スレッドのうちの１つからの命令に基づいて多数の所定のデータ処理動作の１つを開始するようにさせる手段と、
   どのルート指定動作及びどのデータ処理動作を実行できるか繰り返し決定するための手段と、
   実行できると決定されたルート指定動作またはデータ処理動作のうちの少なくとも１つの実行を開始するための手段と、
   を備えたことを特徴とするデータ処理マネージメントシステム。
2. 実行できる各ルート指定動作及びデータ処理動作に優先順位を指定するための手段と、実行できるルート指定動作及びデータ処理動作のどれに最も高い優先順位が指定されたかを決定するための手段とを備え、実行を開始する上記手段は、最も高い優先順位が指定された動作の実行を開始するように制御される請求項１に記載のデータ処理マネージメントシステム。
3. 少なくとも１つのデータ入力はリアルタイム入力であり、そしてその入力にデータを受信する動作に最も高い優先順位が指定される請求項１又は２に記載のデータ処理マネージメントシステム。
4. データ入力はビデオデータ入力である請求項３に記載のデータ処理マネージメントシステム。
5. データ入力はオーディオ入力である請求項３に記載のデータ処理マネージメントシステム。
6. どのルート指定動作及びどのデータ処理動作を実行できるか繰り返し決定する上記手段、及びそのように決定された動作のどれに最も高い優先順位が指定されたかを決定する上記手段は、上記コントロール手段に関連したクロック手段の各クロックサイクルにこの決定を行う請求項２ないし５のいずれかに記載のデータ処理マネージメントシステム。
7. 上記のように決定されて最も高い優先順位が指定された動作の開始は、その後のクロックサイクルに行われる請求項６に記載のデータ処理マネージメントシステム。
8. どのルート指定動作及びデータ処理動作を実行できるか決定する上記手段は、状態バスを経て受け取られそして内部及び／又は外部リソースにより発生されたリソース状態ビットからこの決定を行う請求項１ないし７のいずれかに記載のデータ処理マネージメントシステム。
9. 上記データ処理手段は、その処理手段により実行されるべき処理動作に関連したマイクロコード命令の記憶を含む請求項１ないし８のいずれかに記載のデータ処理マネージメントシステム。
10. 実行を開始する上記手段は、動作を実行すべき上記データ処理手段のマイクロコード命令記憶にアドレスオフセットを与えることにより処理動作の実行を開始する請求項９に記載のデータ処理マネージメントシステム。
11. 上記データ記憶手段は、キャッシュメモリ手段を含む請求項１ないし10のいずれかに記載のデータ処理マネージメントシステム。
12. 上記キャッシュメモリ手段は、キャッシュメモリ記憶装置の複数のバンクを含む請求項11に記載のデータ処理マネージメントシステム。
13. 上記キャッシュメモリへのアクセスを有するシステムの各部分は、上記キャッシュメモリの異なるバンクへのアクセスを許すようにプログラムできるキャッシュメモリ割り当て手段に関連される請求項１に記載のデータ処理マネージメントシステム。
14. 上記コントロール手段は、そのコントロール手段内でデータに対して動作を実行するための１組のデータバンクを含む請求項１ないし13のいずれかに記載のデータ処理マネージメントシステム。
15. 上記コントロール手段は、システムにより実行されるべきデータ処理動作の各々に対して１つづつ、１組のアドレスバンクを含む請求項１ないし14のいずれかに記載のデータ処理マネージメントシステム。
16. 上記コントロール手段は、システムにより実行されるべきデータ処理動作の各々に対して現在プログラムアドレスを記憶するためのプログラムカウンタバンクを含む請求項１ないし15のいずれかに記載のデータ処理マネージメントシステム。
17. 上記コントロール手段は、上記入力及び出力手段とインターフェイスするための１組の入力／出力バンクを含む請求項１ないし16のいずれかに記載のデータ処理マネージメントシステム。
18. 上記コントロール手段は、上記データ記憶手段とインターフェイスするための読み取り／書き込みユニットを含む請求項１ないし17のいずれかに記載のデータ処理マネージメントシステム。
19. 各データバンクは、演算論理ユニット（ALU）と、そのALUのみに関連したレジスタファイルとを含む請求項12に記載のデータ処理マネージメントシステム。
20. 上記データバンク、アドレスバンク、プログラムカウンタバンク、入力／出力バンク、及び読み取り／書き込みバンクは、全て、共通の状態バス、共通のデータ相互接続部及び共通のコントロールバスに接続される請求項14ないし19のいずれかに記載のデータ処理マネージメントシステム。
21. 実行されるべきルート指定動作またはデータ処理動作の実行を開始する上記手段は、その動作が実行でき且つ最も高い優先順位を有すると決定された後、続くクロックサイクルにてその最も高い優先順位を有する実行できるそのルート指定動作またはデータ処理動作を開始させるように構成されている請求項６に記載のデータ処理マネージメントシステム。
22. データ処理マネージメントシステムにおいて、複数のデータ入力と、複数のデータ出力と、複数のデータ処理手段と、データ記憶手段と、コントロール手段とを備えており、
    上記コントロール手段は、
    複数のルート指定動作にて上記データ処理手段のうちの選択された１つを通して上記データ入力の各々から上記データ出力のうちの選択された１つへとデータをルート指定する手段と、
    データがルート指定される上記データ処理手段の各々がそのデータに対するデータ処理動作を実行するようにさせる手段と、
    複数のルート指定動作の中からどのルート指定動作が実行できるか及び複数のデータ処理動作の中からどのデータ処理動作が実行できるかを繰り返し決定する手段と、
    どの動作が実行できるかを決定する上記手段が実行できると決定したルート指定動作及びデータ処理動作の実行を開始する手段と、
    を備えることを特徴とするデータ処理マネージメントシステム。
23. 各ルート指定動作及びデータ処理動作に優先順位を指定するための手段と、実行できるルート指定動作及びデータ処理動作のどれに最も高い優先順位が指定されたかを決定するための手段とを備え、動作の実行を開始する上記手段は、最も高い優先順位が指定されたルート指定動作またはデータ処理動作の実行を開始するように構成されている請求項22に記載のデータ処理マネージメントシステム。
24. どの動作が実行できるかを繰り返し決定する上記手段及び実行できるどの動作が最も高い優先順位を有しているかを決定する上記手段は、どのルート指定動作及びデータ処理動作が実行できるか、且つそれらの動作のうちのどれが最も高い優先順位を有するかを、上記コントロール手段と一体的なクロック手段の各クロックサイクル中に決定するようにまとめて構成されている請求項23に記載のデータ処理マネージメントシステム。
25. 上記複数のデータ処理手段は、別々の命令スレッドの一部分を構成する別々の命令を実行するため、データに対するデータ処理動作を独立的且つ同時に実行するように構成されており、上記コントロール手段は、上記複数のデータ処理手段がデータ処理動作を実行している間に、上記コントロール手段がどのルート指定動作及びデータ処理動作が実行できるか且つ実行できる動作のうちのどの動作が最も高い優先順位を有するかを同時に決定するように構成されている請求項24に記載のデータ処理マネージメントシステム。
26. どの動作が実行できるかを繰り返し決定する上記手段は、上記コントロール手段と一体的なクロック手段の各クロックサイクル中に、どのルート指定動作及びデータ処理動作が実行できるかを決定するように構成されている請求項22に記載のデータ処理マネージメントシステム。
27. 別々の命令スレッドを独立的に実行する方法であって、各命令スレッドに基づいて処理されるべきデータは、複数のデータ入力のうちの１つから与えられ、上記命令スレッドの処理の結果として生成されるデータは、複数のデータ出力のうちの１つへと送られるような方法において、
    各命令スレッドについて、そのスレッドにて実行されるべき次の処理ステップのために、実行されるべき処理ステップを指示するオプコードと、該処理ステップが実行されるべきデータ及びその命令を実行するのに必要とされるリソースを記述または定義する少なくとも１つのオペランドとを含むスレッドマイクロ命令をアセンブルし、
    上記複数のスレッドマイクロ命令について、そのマイクロ命令が実行されるべき相対的優先順位を確立し、
    各スレッドマイクロ命令について、そのマイクロ命令が実行できるかの決定がなされるように、その必要とされるリソースを定義するマイクロ命令に対するデータ及びそれらリソースの使用可能性のチェックに基づいてリソースがそのマイクロ命令を実行するのに使用可能であるかを決定し、
    実行できるスレッドマイクロ命令について、どのスレッドマイクロ命令が最も高い優先順位を有するかを決定し、
    最も高い優先順位を有するスレッドマイクロ命令について、そのスレッドマイクロ命令のオプコードに基づいて、上記データ入力の選択された１つから処理されるべきデータを検索し、該データをデータ処理手段にて処理し、及び／又は上記データ入力の選択された１つへ該データを送る、
    という各段階を含むことを特徴とする方法。
28. 上記データ処理手段がマイクロ命令を実行している間、次のスレッドマイクロ命令を実行するためのリソースの使用可能性を決定する上記段階及びすべてのリソースが使用可能であるスレッドマイクロ命令について最も高い優先順位を有するスレッドマイクロ命令を決定する上記段階を同時に実行する請求項27に記載の方法。
29. 複数の別々のデータ処理手段が与えられ、最も高い優先順位を有するスレッドマイクロ命令を決定する上記段階の後、その最も高い優先順位を有するスレッドマイクロ命令が実行のため多数の上記データ処理手段のうちのどれかに送られ、上記個々のデータ処理手段が異なる命令スレッドのスレッドマイクロ命令を同時に実行する請求項28に記載の方法。
30. キャッシュメモリが与えられ、上記データ入力から上記キャッシュメモリへデータが書き込まれ、上記個々のデータ処理手段は、スレッドマイクロ命令の処理中に上記キャッシュメモリからデータを読み取り、また上記キャッシュメモリへデータを書き込み、データは、上記キャッシュメモリから上記データ出力へ読み出され、上記キャッシュメモリは、上記データ入力の複数のものがデータを書き込むことができ、上記データ処理手段の複数のものがデータを読み出したり書き込んだりすることができ、及び／又はデータが上記データ出力の複数のものへと読み出されうる複数のメモリ場所を有している請求項29に記載の方法。
31. 上記データ処理手段は、該データ処理手段によって実行されるマイクロ命令が記憶されるメモリを有しており、データ処理手段でデータを処理する上記段階が実行されるべき時、そのデータ処理手段のマイクロ命令メモリにおけるオフセットアドレスがそのデータ処理手段へ供給され、上記オフセットアドレスは、実行すべきスレッドマイクロ命令に基づいており、上記オフセットアドレスがデータ処理手段によって受け取られることにより、該データ処理手段が該オフセットアドレスによって特定されたデータ処理手段マイクロ命令に従ってそのデータを処理するようにさせられる請求項27に記載の方法。

Images