(57)【要約】      （修正有）【課題】マルチメディア画像を生成するため、同時またはほぼ同時にビデオデータを解凍し、処理することが可能な処理アーキテクチャを提供する。【解決手段】メディア処理システムは、該メディア処理システムによって処理されるデジタルデータを格納する複数個の格納位置を含むＤＲＡＭと、該デジタルデータが、標準化されたフォーマットに圧縮されるビデオを含むことと、圧縮ビデオ画像と画像データを生成するために、該標準化フォーマットの圧縮ビデオデータを含む該デジタルデータを処理するシステムと、フルモーションビデオピクセルデータを生成するために、該標準化フォーマットの圧縮ビデオデータを復号化するシステムと、該処理手段と該複合化手段との間で該ＤＲＡＭを共有するシステムとを含んで提供される。メディア処理は、並列にたがいに接続される複数個の処理要素と、該処理要素のそれぞれを制御し、それぞれに分配するシステムを有してもよい。【選択図】図２
2008017493.tif 000002
【特許請求の範囲】
【請求項１】
種々のタイプのデジタルデータを受信して処理し得る、ユーザ設定可能な汎用メディア処理システムであって、
同メディア処理システムによって処理されるべき、ビデオデジタルデータおよびオーディオデジタルデータを含むデジタルデータを格納するメモリユニットと、
前記デジタルデータの分配処理を可能にすべく配置された複数の分配設定可能メディア処理要素（ＭＰＥ）であって、各デジタルデータはメモリユニットに接続され、それによって、メディア処理要素の間で、デジタルデータの選択された部分を共有して処理でき、複数の設定可能ＭＰＥのうちの少なくとも１つは、ＭＰＥの幾つかあるいはすべての間でデジタルデータの分配を制御すべく適切に配置された制御処理要素として、少なくとも部分的に、動的に動作すべく設定され、ＭＰＥの課題をスケジューリングし、分配されたＭＰＥはそれぞれ、他の複数のＭＰＥと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げ、さらに、ＭＰＥのうちの選択されたものに制御信号を送り、選択されたデジタルデータテイプを処理するために、同制御信号によって、選択されたＭＰＥが再設定される、分配設定可能メディア処理要素（ＭＰＥ）と、
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために適切に配置された複数の通信バスであって、それによって、通信バスのそれぞれによって、制御信号／コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、通信バスと、
からなるシステム。
【請求項２】
更に、選択された複数のＭＰＥによって適切に処理されるべく、デジタルデータを複数のサブデータ・ストリームに構文解析するための、メモリユニットに接続されたデータストリームパーサからなる請求項１に記載のシステム。
【請求項３】
複数のＭＰＥはそれぞれが、他の複数のＭＰＥを独立に動作させ得る、単一の命令ストリームで複数のデータストリーム（ＳＩＭＤ）の汎用超長語（ＶＬＩＷ）ＲＩＳＣプロセッサである請求項１に記載のシステム。
【請求項４】
プロセッサ制御要素によって供給される信号に基づいて、複数のＭＰＥのうちの選択された幾つかは協同で特定の課題を行なう請求項１に記載のシステム。
【請求項５】
前記特定の課題は、グラフィック処理、データベースの検索、数値処理、およびビデオ処理を含む群から選択される請求項４に記載のシステム。
【請求項６】
デジタルデータが、特定の外部メディアと整合するフォーマット外部メディア上に格納されている請求項５に記載のシステム。
【請求項７】
前記外部メディアはコンパクトディスク（ＣＤ），レーザディスク（ＬＤ），デジタル多目的ディスク（ＤＶＤ）を含み、それぞれのフォーマットは、圧縮オーディオフォーマット、第１のタイプの圧縮ビデオと第１のタイプの圧縮オーディオのフォーマット、および第２のタイプの圧縮ビデオと第２のタイプの圧縮オーディオのフォーマットを含み、それによって、汎用メディアプロセッサは特定のフォーマットを識別して、対応するデジタルデータの処理を実行するために複数のＭＰＥのうちの選択された幾つかを再設定する、請求項５に記載のシステム。
【請求項８】
前記特定の課題がＭＰＥＧ−２ビデオストリームの処理のときは、処理要素コントローラは選択された複数のＭＰＥに、ＭＰＥＧ−２データを復号すべく命令し、他の複数の選択
されたＭＰＥに、該復号されたＭＰＥＧ−２データを基にフルモーションカラー画像を生成することと、他の複数のＭＰＥに、オーディオストリームデータを生成すること、を指示する請求項６に記載のシステム。
【請求項９】
前記メモリ装置は主システムメモリを含み、複数のバスは、
主システムメモリに接続された主システムバスと、
線形のデータ転送が可能な主システムメモリと通信すべく配置された、該主システムバスから分離された付属バスと、
ＭＰＥのうちの選択された幾つかの間でデータパケットの転送や、複数のＭＰＥと複数の周辺装置との間の連結のために使用される通信バスと、からなる請求項１に記載のシステム。
【請求項１０】
メディア処理システムによってデジタルデータを処理する方法であって、
デジタルデータを受信する工程と、
受信したデジタルデータと関係するデジタルデータフォーマットを決定する工程と、
適切なフォーマットでデジタルデータを処理するために、複数の設定可能メディア処理ユニット（ＭＰＥ）のうちの選択された複数を設定する工程と、  
設定可能ＭＰＥのうちの少なくとも１つが、少なくとも部分的に、動作すべく動的に設定され、ＭＰＥのうちの幾つかまたはすべての間でデジタルデータを分配すべく制御し、ＭＰＥの課題をスケジューリングし、分配されたＭＰＥはそれぞれ、他の複数のＭＰＥと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げる工程と、
からなる方法。
【請求項１１】
更に、受信されたデジタル信号を複数のＭＰＥのそれぞれに接続されたメモリ装置中に格納する工程を含む請求項１０に記載の方法。
【請求項１２】
更に、複数のＭＰＥのうちの選択された幾つかに制御信号を送り、同制御信号によって、選択された幾つかのＭＰＥが、決定されたフォーマットでデジタルデータを処理するために再設定される請求項１０に記載の方法。
【請求項１３】
デジタルデータを構文解析する工程と、
同構文解析されたデジタルデータの処理に基づいて複数のＭＰＥの課題をスケジューリングする工程であって、各分配された複数のＭＰＥは他の複数のＭＰＥと協同して構文解析されたデジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体の速度と効率を増大させる、前記スケジューリング工程とを、更に含む請求項１２に記載の方法。
【請求項１４】
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために複数の通信バスを適切に配置する工程であって、
それによって、分離されたそれぞれの通信バスによって、制御信号／コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、請求項１３に記載の方法。
【請求項１５】
デジタルビデオデータが第１の標準化フォーマットで圧縮されており、
第１の標準化フォーマットで圧縮されたビデオデータを含むデジタルデータを処理して、圧縮されたビデオ画像とビデオデータを生成する工程と、
選択された複数のＭＰＥによって、第１の標準化フォーマットで圧縮されたビデオ画像を復号して、フルモーションのビデオピクセルデータを生成する工程と、
複数のＭＰＥ間でＤＲＡＭを共用する工程と、
フルモーションのビデオピクセルデータからフルモーションのビデオ信号を生成して、第１の標準化フォーマットで圧縮されたビデオ画像を復号するために使用される複数の選択されたＭＰＥは、第２の標準化フォーマットで圧縮されるデータを含むデジタルデータを復号すべく再設定するために適合される工程と、からなる請求項１０に記載の方法。
【請求項１６】
メディア処理システムによってデジタルデータを処理するためのコンピュータプログラムであって、
デジタルデータを受信するためのコンピュータコードと、
受信したデジタルデータと関係するデジタルデータフォーマットを決定するためのコンピュータコードと、
適切なフォーマットでデジタルデータを処理するために、複数の設定可能メディア処理ユニット（ＭＰＥ）のうちの選択された複数を設定するためのコンピュータコードと、  設定可能ＭＰＥのうちの少なくとも１つが、少なくとも部分的に、動作すべく動的に設定され、ＭＰＥのうちの幾つかまたはすべての間でデジタルデータを分配すべく制御し、ＭＰＥの課題をスケジューリングし、分配されたＭＰＥはそれぞれ、他の複数のＭＰＥと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げるためのコンピュータコードと、
処理されたデジタルデータを出力するためのコンピュータコードと、
コンピュータコードを格納するためのコンピュータ読み取り可能メディアと、  からなるコンピュータプログラム。
【請求項１７】
受信されたデジタルデータを各ＭＰＥに接続されたメモリ装置中に格納することを更に含む請求項１６に記載のコンピュータプログラム。
【請求項１８】
制御信号を複数の選択されたＭＰＥに送信するためのコンピュータコードであって、該制御信号によって、選択された複数のＭＰＥが、決定されたフォーマット中のデジタルデータ処理するために再設定される、請求項１６に記載のコンピュータプログラム。
【請求項１９】
更に、デジタルデータを構文解析するためのコンピュータコードと、
同構文解析されたデジタルデータの処理に基づいて複数のＭＰＥの課題をスケジューリングする工程であって、各分配された複数のＭＰＥは他の複数のＭＰＥと協同して構文解析されたデジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体の速度と効率を増大させる、前記スケジューリングするためのコンピュータコードと、を更に含む請求項１８に記載のコンピュータプログラム。
【請求項２０】
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために適切に配置された複数の通信バスであって、
それによって、分離されたそれぞれの通信バスによって、制御信号／コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、請求項１９に記載のコンピュータプログラム。
【請求項２１】
デジタルビデオデータが第１の標準化フォーマットで圧縮されているときに、
第１の標準化フォーマットで圧縮されたビデオデータを含むデジタルデータを処理して、圧縮されたビデオ画像とビデオデータを生成するためのコンピュータコードと、
選択された複数のＭＰＥによって、第１の標準化フォーマットで圧縮されたビデオ画像を復号して、フルモーションのビデオピクセルデータを生成するためのコンピュータコードと、
複数のＭＰＥ間でＤＲＡＭを共用するためのコンピュータコードと、
フルモーションのビデオピクセルデータからフルモーションのビデオ信号を生成して、第１の標準化フォーマットで圧縮されたビデオ画像を復号するために使用される複数の選
択されたＭＰＥは、第２の標準化フォーマットで圧縮されるデータを含むデジタルデータを復号すべく再設定するために適合されるためのコンピュータコードと、
からなる請求項２０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアアプリケーションにおいて使用するための新規な処理アーキテクチャに関する。詳細には、圧縮されたデジタルビデオおよび音声データを解凍し、デジタルビデオおよび音声データを他のデジタルデータとともに処理し、コンピュータシステムまたはその他の適切なマルチメディア提示システム上において提示するための高解像度カラーマルチメディアデータを生成するのに適合された処理アーキテクチャおよび関連する方法に関する。
【背景技術】
【０００２】
ＤＶＤ、ＣＤまたはコンピュータメモリなどの比較的狭い波長帯の媒体上でのデジタルビデオ画像の格納を容易にするためのフルモーションデジタル画像の圧縮は周知である。コンピュータ画面用の典型的な単一の全画面ビデオフレームは３００，０００ピクセルを超えるピクセルから成り、各ピクセルは、２４ビットカラーシステムの１６７０万色のうちの１色により定義される。該単一のフルカラー画像フレームは、約１００万バイト（１Ｍｂ）のメモリに格納され得る。ビデオゲームなどのアプリケーションで動画を実現するためには、ビデオシステムは毎秒約３０のカラーフレームを生成、表示しなければならない。よって、１分間のフルモーションカラービデオのためには、システムは、好ましくは２ギガバイト（２Ｇｂ）の画像データを格納できなければならない。同様に、３００ドット／インチで走査されるフルカラーの静止フレーム画像は、２５メガバイトを超えるメモリを必要とする。これらのメモリ要件は、非常に大きく、かかる大量のデータを格納できる格納装置は高価である。
【０００３】
さらに、フルモーションカラー画像を生成するため、格納装置からフルカラー画像データが検索される速度は、ほとんどの現行の格納装置の有効データ転送速度を上回る。例えば、典型的な格納装置が毎秒約２５０ＫＢの速度でデータを転送できると想定すると、毎秒３０ＭＢの所要速度でのフルモーションカラービデオ画像の検索（毎秒３０個の１ＭＢフレーム）は達成できない。この仮説の格納装置は１２０倍低速すぎる。
【０００４】
したがって、フルカラー画像を表すために必要なデータ量を減少でき、同時に、十分な高品質画像を維持する画像圧縮手法が開発された。かかる手法のほとんどにおいて、情報を除去し得る（すなわち人間の目がそれほど敏感ではない）場所を特定化することで、大幅に画質を劣化させることなく、画像データ量が低減される。例えば、人間の目は、カラーの詳細よりも白黒の詳細により敏感である。かくして、多くの既知の手法は、画質における大幅な認識可能な低下を生じることなく、画像において各ピクセルに関する色情報の量を低減する。
【０００５】
かかる既知の圧縮手法としては、差分パルスコード変調、動画エキスパートグループ（ＭＰＥＧ）圧縮、およびＭＰＥＧ−２圧縮がある。ＭＰＥＧフォーマットは、コンピュータシステムで使用されるデジタルフルモーションビデオおよび音声データの圧縮と解凍の基準となるよう意図された。ＭＰＥＧ−２フォーマットは、柔軟なデジタル・スケーラブルビデオ伝送を支援する、ＭＰＥＧフォーマットの拡張版である。ＭＰＥＧおよびＭＰＥＧ−２フォーマットは、フルモーションビデオ信号の圧縮および解凍の標準的な手法となってきている。
【０００６】
かかる手法を用いて画像が圧縮されると、次に、画像を表示するために、圧縮画像データは一般に解凍され、場合によっては処理される。圧縮された画像データの解凍および処理は、大量の処理能力を必要とし、大量のメモリも必要とする。圧縮されたデジタルビデ
オ画像の復号化・解凍の従来のシステムは、圧縮されたデジタルビデオ画像と、圧縮されていないデジタルビデオ画像の両方を保持するメモリと、画像を解凍し、メモリ内に画像を格納するデコーダとを備える。既知の解凍システムは、ＰＣ、ＤＶＤプレーヤー、デジタル衛星テレビシステム、ケーブルテレビシステムで使用され得る。かかる既知のシステムは、圧縮された画像を復号化するためにメモリ集約的な演算を使用し、典型的に２ＭＢの格納空間を必要とする。当業者なら理解するように、かかるシステムは、解凍に必要とされる大量のメモリにより高価になる傾向がある。さらに、かかるシステムは、画像のみを解凍し、複合画像を生成するために、他のソースからのデジタルデータは処理しない。最終的に、データを解凍し、同時にビデオデータを処理するためには、追加のメモリおよび処理能力が必要とされ、それらは一般に従来のビデオ解凍システムでは利用可能ではない。
【０００７】
さらに、従来の処理システムは、ビデオ画像を生成するのに十分な処理能力を有するものが存在するが、かかるシステムのいずれも、フルモーションカラー画像を高速で効率よく解凍、処理するために最適化されていない。一般に、かかる処理システムは、処理システムに付加された別個の解凍システムも必要とする。
【０００８】
最後に、フルモーションカラービデオゲーム、バーチャルリアリティシステム、ケーブルテレビ受像機などの用途のために十分高速でメディアデータを解凍、処理するようなこれら従来のシステムは存在しない。かかるシステムのいずれも、統合されたフルモーション画像データ解凍および処理システムのいずれも含まないため、かかるシステムのいずれも、廉価で完全に機能的なメディア処理システムを提供しない。
【特許文献１】米国特許出願第０９／４７６，９４６号
【特許文献２】米国特許出願第０９／４７６，６９８号
【発明の開示】
【発明が解決しようとする課題】
【０００９】
したがって、公知の装置のこれらの不都合およびその他の不都合を回避するメディア処理システムおよび方法が必要とされている。
【課題を解決するための手段】
【００１０】
本発明は、衛星デジタルテレビシステム、ビデオゲームシステム、ケーブルテレビシステムなどで使用され得るフルモーションカラー画像を生成するために、ビデオデータの解凍および処理を同時に行うメディア処理システムを提供する。該メディア処理システムは、システムの全体的なコスト削減のため、解凍システムと処理システムとの間で共有されるメモリも有し得る。
【００１１】
本発明によると、メディア処理システムは、標準化されたフォーマットで圧縮されたビデオデータを含むデジタルデータを格納するためのダイナミックランダムアクセスメモリ（ＤＲＡＭ）またはその他の適切な格納装置を備え得る。該ＤＲＡＭは処理システムと復号化システムとによって共有される。前記デジタルデータは処理されて、圧縮されたビデオ画像および画像データを生成する。次に、圧縮されたビデオ画像は復号化されて、フルモーションビデオピクセルデータを生成する。
【００１２】
次に、表示され得るフルモーションビデオ信号を生成するために、フルモーションビデオピクセルデータが使用される。前記ＤＲＡＭは圧縮された音声データを備えてもよく、該圧縮された音声データは復号化され、次に、マルチメディアデータを生成するために、フルモーションビデオ信号と組み合わされ得る。メディア処理システムは、単一の処理サイクル内で２個のピクセルを乗算するか、または組み合わせてもよい。メディア処理システムは、単一の半導体チップ上に形成されてもよい。
【００１３】
本発明のより完全な理解は、好ましい実施例の詳細な説明と特許請求の範囲を、図面と関連して考慮することにより得られる。図面において、同一の参照番号は同様の部分を示す。
【発明を実施するための最良の形態】
【００１４】
本発明は新規な処理アーキテクチャに関し、より詳細には、マルチメディア画像を生成するため、同時またはほぼ同時にビデオデータを解凍し、処理することが可能な処理アーキテクチャに関する。本発明が説明されるのはこの状況においてである。ただし、本発明によるシステムおよび方法がより広い効用を有することは言うまでもない。
【００１５】
図１は、本発明にしたがってマルチメディアデータを生成するために、デジタルデータを解凍し、処理するように構成されたシステム２０の全体ブロック図である。該システムは、圧縮されたデジタルメディアストリームを生成または提供し得るハードディスクドライブ、ケーブルテレビシステム、衛星受像機またはＣＤまたはＤＶＤプレーヤーなどの圧縮画像発生器２５を備えることが好ましい。システム２０は、解凍されたフルモーション画像を表示するディスプレイシステム２６も備える。音声および視覚データを含み得る圧縮されたメディアストリームは、該圧縮されたメディアストリームを解凍するように構成されたメディア処理システム３０に入る。さらに、メディア処理システム３０は、圧縮されたメディアストリームを解凍すると同時に、圧縮されたデータストリームまたは別の格納装置またはデジタルデータソースに含まれるデジタルデータを処理し得、かくして、解凍されたメディアストリームと共に使用され得る他の種類のメディアデータを生成する。例えば、対話型のカラー、フルモーションビデオゲームが生成され得る。すべてのデータが解凍され、処理されると、データは、見るために表示システム２６に出力される。ケーブルまたは衛星テレビシステム用には、メディア処理システム３０は、入力された圧縮デジタルデータを単に解凍し、本発明の一実施例によるとテレビ画面であり得るディスプレイ２６上に画像を出力し得る。
【００１６】
図２は、本発明の一実施例によるメディア処理システムのアーキテクチャのブロック図である。メディア処理システム３０は、圧縮ビデオデータの解凍、フルモーションカラー画像を生成するための解凍されたビデオデータおよび／または他のデジタルデータを含むデジタルデータの処理、およびメディア処理システム３０内での他の演算の制御などの複数の演算を実行可能なメディアプロセッサ３２を備える。メディアプロセッサ３２は、単一の半導体チップ上に形成され得、これに代わって、メディアプロセッサ３２の複数のコンポーネントが複数の半導体チップまたはデバイスに区切られてもよい。
【００１７】
メディア処理システム３０は、ビデオまたは視覚データ、音声データおよび／または圧縮データなどの種々のデジタルデータを一時的に格納するためのＤＲＡＭ、ＳＤＲＡＭ、フラッシュメモリ、またはその他の適切な格納装置などの１つ以上の格納装置３４，４６を備えることも望ましい。ＤＲＡＭおよび／またはＳＤＲＡＭはそのより高速なアクセス時間により、より迅速にアクセス可能であるので、メディア処理システム３０によって処理または解凍されるいかなるデータも、メインメモリ（図示せず）からＤＲＡＭおよび／またはＳＤＲＡＭにロードされることが好ましい。メディア処理システムによって処理されたデータは、ディスプレイ上に表示される前またはメインメモリに戻される前のいずれかで、ＤＲＡＭおよび／またはＳＤＲＡＭに一時的に格納され得る。
【００１８】
マルチメディアデータを処理する際、メディアプロセッサ３２は、デジタル画像データストリームおよびデジタル音声データストリームを生成するように構成されている。ビデオエンコーダおよびデジタル−アナログコンバータ（ＤＡＣ）３６はメディアプロセッサ３２から出力されるデジタル画像データを、テレビまたはコンピュータモニタなどのディ
スプレイ装置上に表示できる複合ビデオ、ｓ−ビデオ、コンポーネントビデオなどのアナログ画像信号に変換する。音声デジタル・アナログコンバータ（ＤＡＣ）３８は、メディアプロセサッサ３２によって出力されたデジタル音声信号を、オーディオシステムなどによって放送可能なアナログ音声信号（好ましくは約２〜８個の別個の音声チャネル）に変換する。別の実施例によると、メディアプロセッサ３２は、ＩＥＣ−９５８ステレオ音声またはコード化音声データ信号３９も出力し得る。この信号は内部音声デコーダまたはデジタル・アナログコンバータ（ＤＡＣ）を有し得るシステムへの接続を意図された音声出力信号である。
【００１９】
メディアプロセッサ３２は、メディア処理システム３０用のベーシック・インプット／アウトプット・オペレーティング・システム（ＢＩＯＳ）と、音声データを解凍し、合成音声を生成するために使用され得る音声テーブルおよび／またはメディアプロセッサ３２およびメディア処理システム３０によって使用されるその他の適切なソフトウェアまたはデータを格納するために使用され得るリードオンリーメモリ（ＲＯＭ）などの第２格納装置４０も備える。さらに、メディアプロセッサ３２はシステムバス４１に接続される拡張バス４２を備えてもよく、それにより、１つ以上の拡張モジュール４３がメディアプロセッサ３２に接続され得る。拡張モジュール４３は、メディア処理システム３０の機能性を拡張するためのマイクロプロセッサ４４などの追加ハードウェアを備えてもよい。図２に示されるように、追加メモリ４６を、拡張バス４２およびシステムバス４１を介してプロセッサ３２に接続してもよい。
【００２０】
メディアプロセッサ３２は、メディアプロセッサ３２と、メディア処理システム３０の他の部分との間の通信のための複数の通信接続を備えることが好ましい。メディアデータ接続５０は、メディアプロセッサ３２と、圧縮画像発生器２５（図１）などのその他のシステムとの間のメディアデータの転送を可能にする。メディア制御接続５２は、メディアプロセッサ３２と、Ｉ２Ｃ互換性装置および／またはシステムバス４１に接続されたインターフェースハードウェアなどの他のシステムとの間で制御信号および／またはデータを転送する。ユーザインターフェース接続５４は、メディアプロセッサ３２と、ジョイスティック、ＩＲリモコン装置などのユーザインターフェース周辺機器との間でユーザインターフェースデータを転送する。最後に、入出力チャネル接続５６は、システムのさらなる拡張のための他のＩ／Ｏデバイスとの接続を可能にする。
【００２１】
メディア処理システム３０は、フルモーションカラービデオゲーム、ケーブルテレビ受信機および衛星テレビ受信機、高解像度テレビ受信機、コンピュータシステム、ＣＤおよびＤＶＤプレーヤーなどの種々の用途で使用される。例えば、ビデオゲームアプリケーションで、地形、登場人物およびゲームのその他の視覚的側面を表すデジタルデータは、メインメモリに格納され、周辺デジタルデータソースから入力される。本発明のこの態様によると、メディア処理システム３０、およびより詳細にはプロセッサ３２は、１乃至それ以上のデジタルデータソースからのデジタルデータを処理し、ビデオゲームディスプレイ上に表示されるインタラクティブなフルモーションカラー画像を生成する。メディア処理システム３０は、ビデオゲームの音楽および音響効果を追加する音声信号も生成し得る。
【００２２】
ケーブルテレビ受信機または衛星テレビ受信機に対し、メディア処理システム３０は、ケーブルヘッドエンドシステムか衛星送信機から受信した圧縮デジタルビデオ・音声信号を解凍し、解凍デジタルビデオ・音声信号を生成する。次に、解凍デジタルビデオ・音声信号は、テレビディスプレイへの出力であるアナログ信号に変換される。メディア処理システム３０はまた、任意の暗号化入力ケーブルテレビまたは衛星テレビ信号を解読するように構成されてもよい。
【００２３】
ＤＶＤプレーヤー用には、メディア処理システム３０は、ＤＶＤまたはＣＤから圧縮デ
ジタルデータを受信し、データを解凍することが好ましい。同時に、メディア処理システム３０はＲＯＭ、例えばＲＯＭ４０に格納されたデジタルデータまたは別のデジタルデータソースからの入力を受信し、解凍されたＤＶＤまたはＣＤカラー画像が、ＲＯＭまたはその他のデジタルデータソースから受信されたデータと共に表示されるビデオゲーム環境を生成し得る。かくして、インタラクティブなフルモーションカラーマルチメディアゲームが、メディア処理システム３０によって動作され得る。
【００２４】
次に図３を参照すると、その他の多数の処理アプリケーションと同様に、上記で概説したアプリケーションを実行するメディアプロセッサ３２の内部アーキテクチャを以下でさらに詳細に説明する。より詳細には、図３は、内部並列アーキテクチャを有するメディアプロセッサ３２のブロック図である。本発明の並列アーキテクチャは、デジタルデータを解凍、処理するために必要な処理能力および速度を提供し、フルモーションカラー画像を生成可能にする。並列アーキテクチャは、様々なアプリケーションで利用され得るが、並列アーキテクチャは特に、マルチメディア処理アプリケーションに適用可能である。
【００２５】
本発明の一実施例によると、メディアプロセッサ３２は、通信バス６０と、メインバス６２と、補助バス６４とから成り、これらのすべてが、プロセッサ３２の種々の処理要素とサブシステム装置を接続するために用いられる。より詳細には、プロセッサ３２は、第１処理要素（ＭＰＥ０）６６と、第２処理要素（ＭＰＥ１）６８と、第３処理要素（ＭＰＥ２）７０と、第４処理要素（ＭＰＥ３）７２と、復号支援装置７４と、音声映像Ｉ／Ｏシステムとからなることが好ましい。本発明の一実施例によると、音声映像Ｉ／Ｏシステムは、音声Ｉ／Ｏ装置７６と、ビデオＩ／Ｏ装置７８と、ビデオ時間ベース・表示発生器８０とからなる。
【００２６】
メインバス６２は、ＭＰＥメモリと外部ＳＤＲＡＭとの間か、または１個のＭＰＥから別のＭＰＥへのいずれかにおける、約２１６Ｍバイト／秒の最大データ転送速度を有する３２ビットバスである。該バスは、データのバーストの転送に使用でき、バイリニア・アドレッシングおよびＺバッファ比較を含むピクセル転送の広範なサポートを有する。これは、ビデオ・音声出力にも使用される。メディア処理システム３０は、このバスに接続される最低８ＭバイトのＳＤＲＡＭを有することが好ましい。
【００２７】
補助バス６４は、１６ビットバスであることが好ましく、より単純で低速なメインバスのようなものである。補助バス６４は、システムバスメモリと、システムバスに接続される他のデバイスとの通信用に使用され、線形データ伝送（ｌｉｎｅａｒ  ｄａｔａ  ｔｒａｎｓｆｅｒ）を、約１０８Ｍバイト／秒の最高速度で実行する。メディア処理システム３０は、該バスに接続される最低８ＭバイトのＤＲＡＭを有することが好ましい。
【００２８】
通信バス６０は、最大データ転送速度が約１７２Ｍバイト／秒の別の３２ビットバスであることが好ましく、ＭＰＥ間で１２８ビットパケットの伝送に使用されるか、ＭＰＥの周辺機器との通信を可能にするために使用される。通信バス６０は低レイテンシーバスであって、プロセッサ間の通信に適している。通信バス６０のより詳細な説明については、２０００年１月３日に出願され、「マルチプロセッサシステム用の通信バス（Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｂｕｓ  ｆｏｒａ  Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｏｒ  Ｓｙｓｔｅｍ）」と題された米国特許出願第０９／４７６，９４６号（代理人明細書番号第１９２２３−０００６００ＵＳ）を参照されたい。当該出願のすべては参照により本願に援用される。
【００２９】
データと命令が同じバスで伝送されなければならない、より標準的な単一バスアーキテクチャと比較すると、制御信号／コマンドおよびデータが別のバス上で通信されるために、該特定の並列バス構造は、メディア処理システム３０により処理されるデータ量の増加
を可能とする。処理要素とサブシステム装置との間で伝送されるコマンドおよびデータの数を増やすことにより、システムの総処理能力が増大される。
【００３０】
さらに図３で、処理要素およびサブシステム装置について以下により詳細に説明する。特に、プロセッサ３２は、処理要素（ＭＰＥ）６６   ，６８，７０，
７２を備えることが好ましい。該処理要素の１つは、好ましくはプロセッサ３２の処理全体を制御するために、少なくとも部分的に、制御処理要素として使用される。例えば、制御処理要素は、（１）各ＭＰＥと他のシステム装置の間における一部またはすべてのデータの移動を制御し、（２）ＭＰＥおよびシステム装置が実行するタスクのスケジュールを決定し、（３）他の適切な制御機能を実行し得る。このようにして、タスクが適切にスケジュール指定され、データが効率的に利用されると、メディアプロセッサ３２内のすべてのＭＰＥとサブシステム装置が常に、またはほとんど常にビジー状態に維持できる。メディアプロセッサ３２内のすべてまたはほとんどのＭＰＥおよびサブシステム装置をアクティブ状態に維持することで、より多くのデータおよびコマンドが処理され、かくして、システムの全体速度が増大する。
【００３１】
本発明はいかなる特定のアプリケーションまたはメディアシステムに限定されないが、プロセッサ３２の動作は、ＭＰＥＧビデオデータストリームの処理を例に取って説明する。ＭＰＥＧフォーマットは、ＭＰＥＧ−１規格とＭＰＥＧ−２規格とを有し、ＭＰＥＧ−２規格はその改良された画像圧縮能力により、この２つの内でより広く用いられ始めている。ＭＰＥＧフォーマットは、特定のピクセルの輝度に対応する輝度値で各ピクセルを表す。さらに、４個のピクセルの色を表す２個のクロミナンスを生成するため４個ずつピクセルがサンプル抽出される。かくして、４個のピクセルに関するデータを格納するため６バイトが使用される。該フォーマットは、４．２．０サブサンプリングフォーマットとして知られる。非圧縮の画像では、同じ４個のピクセルは、少なくとも１２バイトのメモリを要する。ＭＰＥＧデコーダは、ピクセルがディスプレイシステム上で表示され得るように、４．２．０サブサンプルされた圧縮フォーマット信号を、複数個の個々のピクセルを表す信号に変換し戻す。ＭＰＥＧおよびＭＰＥＧ−２の圧縮並びに解凍手法は当業で周知であり、本願では詳細には説明しない。
【００３２】
図３に示されるように、すべてのメディア処理要素（ＭＰＥ）６６〜７２は、バス６０〜６４のそれぞれに接続されることが好ましい。４個のＭＰＥが図示されるが、本発明は、いかなる特定数のＭＰＥに限定されるものではなく、最低１個のＭＰＥまたは多数のＭＰＥを有してもよい。ただし、本発明の一実施例によると、４個のＭＰＥを用いるのが好ましい。前記で簡単に説明したように、かかる４個のＭＰＥは、単一の半導体チップ上か、または多数のチップ上に形成され得る。
【００３３】
本発明の一実施例によると、各ＭＰＥ６６〜７２は、他のすべてのＭＰＥから独立して動作可能な単一命令多重データストリーム（ＳＩＭＤ）汎用ベリー・ロング・インストラクション・ワード（ＶＬＩＷ）ＲＩＳＣである。したがって、図３に図示される実施例によると、最高４個の個別の複雑な処理タスクが同時またはほぼ同時に実行される。さらに、大きなより複雑なタスクでは、制御プロセッサが同じタスク上で幾つかまたはすべてのＭＰＥを動作させる。例えば、３次元画像を生成する場合、１個のＭＰＥは、実像を生成する多角形を計算し、同時に別のＭＰＥは多角形を描画（表現）し得る。かくして、ＭＰＥは、タスクに応じて、並列に独立して、あるいはたがいに協動して動作できる。このフレキシビリティは、メディア処理システムが、グラフィック処理、データベース検索、数値処理などの様々な異なるタスクを処理することを可能にする。さらに、ＭＰＥ６６〜７２の各々は、同じ汎用命令セットを利用することが好ましい。
【００３４】
本発明の一実施例によると、ＭＰＥＧ−２ビデオデータストリームを処理するために、
ＭＰＥＧデータを復号化し、フルモーションカラー画像を生成するために必要なタスクは、複数のＭＰＥ間に分割されてもよい。したがって、例えば１個のＭＰＥが音声データを処理し、１個のＭＰＥが圧縮ビデオデータを生成し、１個のＭＰＥがデータストリームパーサーまたはマルチプレクサとして機能し、別のＭＰＥが制御機能を実行し得る。
【００３５】
さらに図３を参照すると、プロセッサ３２が、ＭＰＥＧ−２データ、サブピクチャデータ、オーバーレイデータ、および制御データなどを含むＤＶＤデータストリームを以下に処理するかの具体例を示している。本発明のこの特定例によると、ＤＶＤデータストリームを処理するために、ＭＰＥ１６８は、データストリームを受信し、データストリームを、圧縮ビデオデータコンポーネント、圧縮音声データコンポーネント、サブピクチャデータコンポーネント、ナビゲーション制御データコンポーネントなどの別々のコンポーネントに分割または分解するように構成されることが好ましい。ＤＶＤデータストリームが独立したコンポーネントに分解されると、次にデータは、データバッファとして機能するメモリ内に置かれる。データが提示された時点またはそれに近い時点で、ＭＰＥ１６８がメモリからデータを引き出し、処理のために、データの独立したコンポーネントを異なるＭＰＥおよびサブシステム装置に送信することが好ましい。
【００３６】
この特定例によると、ＭＰＥ０６６はＭＰＥＧ−２データストリームの圧縮音声部分を復号化および／または解凍するように構成されることが好ましい。同様に、ＭＰＥ１６８、ＭＰＥ２７０およびデコーダ装置７４は、ＭＰＥＧ−２ビデオデータストリームの復号化または解凍を実行するように構成される。図３に図示されるように、デコーダ装置７４は、デコーダ装置７４とＭＰＥ６８，７０との間のデータの高速転送を容易にするために、ＭＰＥ１６８とＭＰＥ２７０の両方への直接的な接続を含む。さらに、デコーダ装置７４とメモリ、および他のＭＰＥとサブシステム装置の間でのデータ転送を容易にするために、デコーダ装置７４は、通信バス６０とメインバス６０に接続されることが好ましい。
【００３７】
ＭＰＥ１６８は、別のコンポーネントにＭＰＥＧ−２およびＤＶＤデータを解析し、次に、残りの復号化機能のために、ビデオデータストリームをＭＰＥ２７０とデコーダ装置７４に送信する。例えば、ＭＰＥ２７０は、ストリーム解析と動作ベクトル復号化機能を実行するように構成され、一方デコーダ装置７４は、逆離散余弦変換（ＩＤＣＴ）、逆定量化（ｄｅｑｕａｎｔｉｚａｔｉｏｎ）、および動作予測機能などのＭＰＥＧ復号の下層部を実行するように構成される。図３に図示されるように、ＭＰＥ２７０とデコーダ装置との直接的な接続は、該装置間のデータの高速転送を可能にし、かくしてビデオデータストリームの高速復号を容易にする。
【００３８】
ＭＰＥＧビデオストリームは復号された後、テレビまたはコンピュータモニタなどの表示装置に提供されるまで格納されるメモリに送信されることが好ましい。ＭＰＥ３７２は、サブピクチャ、メニュー、ナビゲーションおよびその他のビデオおよび音声制御機能を処理するように構成されることが好ましい。
【００３９】
すべての音声、ビデオおよびＤＶＤ情報が復号化され、メモリ内に置かれた後に、表示発生器８０は、ビデオ、サブピクチャおよび制御情報をメモリから検索し、幾つかの処理を実行する。例えば、本発明の一実施例によると、ビデオ情報は４：２：０ＭＰＥＧフォーマットでメモリに格納される。表示発生器８０は、４：２：０フォーマットをＣＣＩＲ６５６標準ビデオフォーマットに合致した４：２：２フォーマットに変換することが好ましい。さらに、表示発生器８０は、ビデオ情報をメニューなどのオーバーレイ情報およびサブピクチャチャネル情報と組み合わせて、出力として情報の全パケットを提示することが好ましい。最後に、表示発生器８０は、好ましくはビデオタイミングとリフレッシュ機能を実行するように構成されて、サブピクチャ復号化動作の幾つかを実行し得る。表示発生器８０が、サブピクチャ復号を実行するためにどのように１乃至それ以上のＭＰＥと相
互作用するかについてのより詳細な説明は、２０００年１月３日に出願され、「サブピクチャ復号方法と装置（Ｓｕｂｐｉｃｔｕｒｅ  Ｄｅｃｏｄｉｎｇ  Ｍｅｔｈｏｄｓ  ａｎｄ  Ａｐｐａｒａｔｕｓ）」と題された米国特許出願第０９／４７６，６９８号（代理人明細書第１９２２３−０００７００ＵＳ号）に記載され、当該出願のすべては参照により本願に援用される。
【００４０】
前述の例は、ＤＶＤデバイスからのＭＰＥＧ−２ビデオストリームとその他の情報の復号化として本願で記載されたが、当業者であれば、プロセッサ３２が、処理機能、またはデジタル静止カメラ、デジタルビデオカメラ、ケーブルまたは衛星テレビシステム、ＲＯＭまたはハードドライブ、あるいはその他の適切なデータソースなどのいかなるソースからのメディアデータストリームを実行できることは十分理解するであろう。さらに、プロセッサ３２は、メディアデータのみならず、いかなるタイプのデータも処理するように構成され得る。最後に、前述の例は、特定の機能について説明しており、ＭＰＥ６６〜７２と、デコーダ装置７４および表示発生器８０などの他のサブシステム装置により実行されるが、当業者であれば、本発明がこれらの特定の機能分類に限定されないことは十分理解するであろう。ＭＰＥとサブシステム装置は、いかなる数の異なる機能を実行するようにも構成され得る。したがって、本発明は、本願に説明されるか、図３に図示される例に限定されない。
【００４１】
プロセッサ３２は、メディア処理システム３０の通信バス６０、補助バス６４およびシステムバス４１（図２）に電気的に接続されるシステムバスインターフェース８２も備えてよい。システムバスインターフェース８２は、プロセッサ３２と、メモリと、システムバス４１および／または拡張バス４２に接続される他の周辺機器間に通信パスを提供する。例えば、図２に図示されるように、プロセッサ３２は、システムインターフェース８２とシステムバス４１とを介して、ＤＲＡＭ４６および拡張モジュール４３に接続される。システムバスインターフェース８２を利用することで、プロセッサ３２は、メモリ、外部プロセッサ、周辺機器などを含む複数の異なるデバイスに接続され得る。
【００４２】
さらにメディアプロセッサ３２は、メインバス・オービトレーション・メモリアクセス装置８４を含む。装置８４のメインバスオービトレーション部は、メインバス６２上のバストラヒックを制御し、オービトレーションを行なうことが好ましい。装置８４は、メモリ、例えば図２に図示されるメモリ３４にインターフェースも提供することが好ましい。メモリ３４にアクセスするために、装置８４は、メモリオービトレーションシステム（図示せず）と、直接メモリアクセス装置（図示せず）および／またはＤＲＡＭインターフェース（図示せず）を備えるか、またはそれらと通信し得る。
【００４３】
前述のように、通信バス６０は、一般的に、プロセッサ３２内の種々のシステム間、ならびにプロセッサ３２外部の種々のシステムおよびシステムインターフェースとの制御信号およびデータの通信に使用される。例えば、ＲＯＭインターフェース８８は、ＲＯＭ、例えば図２のＲＯＭ４０へのデータ転送および同ＲＯＭからのデータの転送のために、補助バス６４と通信バス６０に接続される。前記で簡単に説明したように、該ＲＯＭは、メディアプロセッサ３２に固有のプログラムコードおよびその他のデータを格納できる。また、一般入出力（Ｉ／Ｏ）インターフェース９０が通信バス６０に接続されて、メディアプロセッサ３２と、例えばユーザインターフェースまたはメディア制御システム（例えばキーボード、ジョイスティック、マウス、およびその他の適切なユーザインターフェース）との間に通信パスを提供し得る。
【００４４】
通信バス６０には、コード化データインターフェース９２と、通信バスオービトレーション装置９４も接続される。コード化データインターフェース９２は、ＤＶＤプレーヤー、ケーブルまたは衛星ビデオフィードなどのソースから、ＭＰＥＧビデオデータなどのコ
ード化されたデータを受信し、１乃至それ以上のＭＰＥ６６〜７２、デコーダ装置７４および／またはメモリに通信バス６０を介してデータを通信することが好ましい。さらに、通信バスオービトレーション装置９４は、通信バス６０を介したデータ通信の使用および制御のオービトレーションを行うように構成されることが好ましい。
【００４５】
最後に、前記で簡単に説明したように、プロセッサ３２は音声Ｉ／Ｏ装置７６およびビデオ入力装置７８を備え得る。音声Ｉ／Ｏ装置７６は、通信バス７６とメインバス６２に接続され、マイク、ステレオシステムなどの外部音源から音声デジタルビットストリーム入力を受信するように構成されることが好ましい。音声Ｉ／Ｏ装置７６からの出力は、プロセッサ３２の音声出力であり、Ｉ２Ｓ、ＩＥＣ９５８、ＳＰ−ＤＩＦ、ＡＣ＿３、ＭＰＥＧ音声、ＭＰ３、ＤＴＳまたはその他の公知の音声フォーマットなどの種々のデジタル音声出力フォーマットを含む。ビデオ入力装置７８は、通信バスに接続され、例えばビデオカメラ、ＮＴＳＣおよびＰＡＬデコーダなどからデジタルビデオ入力（例えばＣＣＩＲ６５６デジタルビデオフォーマット）を受信するように構成されていることが好ましい。
【００４６】
要約すると、ＭＰＥ６６〜７２は汎用処理要素であるが、ＭＰＥは、好ましくは、メディア処理アプリケーションを最適化するために使用できる特定の命令を命令セット内に含む。かかる命令を以下により詳細に説明する。また、各ＭＰＥは、３次元画像を生成するためのメディア処理規格およびアルゴリズムが変化し、向上する場合に、命令が新しいアルゴリズムを実行するために簡単に変更されるために、ＭＰＥは最新の基準とアルゴリズムに順応できるという点で十分に一般的である。このＭＰＥのフレキシビリティは、本発明によるメディア処理システム３０が拡張し、ユーザの需要と将来的な革新に順応することを可能にする。例えば、より優れた圧縮技術が開発されると、メディア処理システム３０に簡単に組み込まれる。さらに、ＭＰＥのいずれも特に単一機能を実行するように構築されていないために、処理機能のいずれか（例えば音声処理システム）で障害が生じた場合、障害を軽減するために、音声データを処理するのに別のＭＰＥが使用され得る。
【００４７】
前記でより詳細に説明されるように、各ＭＰＥ６６〜７２は単一命令多重データストリーム（ＳＩＭＤ）内部ハードウェアアーキテクチャとベリー・ロング・インストラクション・ワード（ＶＬＩＷ）アーキテクチャとからなることが好ましい。ＶＬＩＷアーキテクチャは、論理演算装置、乗算器などの複数個の並列処理装置を備えるため、各処理装置がそれ自体のデータに関するそれ自体の命令を実行できる。かくして、前述のように、メディアプロセッサ３２は並列アーキテクチャから成り、メディアプロセッサ３２内の各ＭＰＥ６６〜７２も並列アーキテクチャからなることが好ましく、よって、メディアプロセッサ３２およびメディア処理システム３０の全体的な処理能力がさらに向上する。
【００４８】
次に図４で、本発明の一実施例によるメディア処理要素（ＭＰＥ）６６，６８，７０，７２の内部並列アーキテクチャ１００を図示するブロック図を示す。メディアプロセッサ３２の並列バスアーキテクチャと同様に、各ＭＰＥ６６〜７２は、命令バス１０２とデータバス１０４を有する並列バスアーキテクチャも含むことが好ましい。命令バス１０２は好ましくはＭＰＥの全体にわたって命令を送信し、データバス１０４はＭＰＥ内の種々の装置へまた同装置からデータを送信する。前述のように、命令およびデータが同じバスを通って伝送されないので、並列な命令およびデータのバスアーキテクチャによりＭＰＥ速度が増大される。
【００４９】
ＭＰＥのアーキテクチャ１００は、実行制御装置（ＥＣＵ）１０６と、メモリ処理装置（ＭＥＭ）１０８と、レジスタ制御装置（ＲＣＵ）１１０と、論理演算装置（ＡＬＵ）１１２と、乗算処理装置（ＭＵＬ）１１４と、レジスタファイル１１６などの複数個のサブユニットを有し得る。ＥＣＭ１０６と、ＭＥＭ１０８と、ＲＣＵ１１０と、ＡＬＵ１１２と、ＭＵＬ１１４はすべてレジスタファイル１１６を介して並列にともに接続されること
が好ましい。命令解凍およびルーティング装置１１８は命令バス１０２を介して命令メモリ１２０に接続され、好ましくは命令を復号し、ＭＰＥ内の種々の処理装置へルートする。命令メモリ１２０は、ＭＰＥ内の種々の処理装置を制御する複数個の命令を格納する。格納される命令は、好ましくはベリー・ロング・インストラクション・ワード（ＶＬＩＷ）の形式であり、格納するために必要なメモリ量を低減するために圧縮されている。ＶＬＩＷ圧縮のより詳細な説明を以下に説明する。
【００５０】
レジスタファイル１１６は、ＭＰＥの処理装置１０６〜１１４のいずれかによって処理されるデータを一時的に格納するために使用される。例えば、２つの数を加算する際、各数はレジスタファイル１１６内のレジスタにロードされ、次に、該レジスタが加算され、結果がレジスタに格納される。以下に説明するように、レジスタファイル１１６は、ピクセルなどのビデオ処理に固有のデータタイプを含む種々のデータを格納するよう再構成され得る。
【００５１】
ＭＥＭ装置１０８は、データバス１０４によってＭＥＭ装置１０８に接続されるデータメモリ１２２などのＭＰＥ内のいずれかの格納要素へのアクセスを制御するように構成される。ＭＥＭ装置１０８は、別のＭＰＥまたは別のシステムからＭＰＥ内の適切なメモリまたはレジスタに伝送されるようにデータのルートを決定し得る。例えば、ＭＰＥは、データインターフェース１３０〜１３８を介して、メモリから、または別のＭＰＥもしくは処理装置から直接データを受信できる。メインバス６２に接続されるＳＤＲＡＭからのデータは、メインバスＤＭＡインターフェース１３４を介して、ＭＰＥに伝送される。同様に、通信バス６０と補助バス６４からのデータは、それぞれ通信バスインターフェース１３８と補助バスＤＭＡインターフェース１３６を介して、ＭＰＥにより受信される。データは、コプロセッサＤＭＡインターフェース１３２を介して、あるＭＰＥメモリ１２２と、別のＭＰＥメモリ１２２またはシステム装置（例えばデコーダ支援装置７４）の間で伝送され得る。同様に、ＭＰＥは、コプロセッサインターフェース１３０を介して、別のＭＰＥまたはシステム装置（例えばデコーダ支援装置７４）のレジスタまたはレジスタファイル内のデータにアクセスできる。図３に図示される実施例によると、デコーダ支援装置７４は、コプロセッサＤＭＡインターフェース１３２を介して、ＭＰＥ１６８のデータメモリ１２２からデータから引き出すことが可能である。同様に、ＭＰＥ７０は、コプロセッサインターフェース１３０を介して、データ支援装置７４のレジスタにアクセスできる（逆もまた同様である）。最後に、図４に図示されるように、アーキテクチャ１００は、ＭＥＭ装置１０８からレジスタファイル１１６へデータを書き戻すことを可能にする。
【００５２】
ＲＣＵ１１０は、対立がないように、専用レジスタのグループ（図示せず）への処理装置の割当を制御する。ＡＬＵ１１２は、レジスタファイル１１６に典型的に格納されるデータに対して演算および論理処理を実行し、また、以下にさらに詳細に説明されるように、ピクセル演算のために最適化され得る。ＭＵＬ１１４はレジスタライフ１１６に典型的に格納される２個のデータの乗算を実行し、また、以下に説明されるように、ピクセル演算のために最適化され得る。図４に示されるように、ＡＬＵ装置１１２およびＭＵＬ装置１１４は、両方とも、リターンレジスタファイルポート１２６，１２８をそれぞれ介して、レジスタファイル１１６にデータを返信でき、よって生じたデータはレジスタファイルレジスタのいずれかに格納され得る。
【００５３】
図示される並列パイプラインＶＬＩＷアーキテクチャ１００のために、処理装置１０６〜１１４のそれぞれが単一の独立命令を処理できるので、各ＭＰＥは、各クロックサイクルで最高５個の独立命令を処理できる。３次元環境で多角形を生成する、あるいは画像に陰影をつける命令のグループなどの、繰り返し実行される複雑なループ命令を有するグラフィックアプリケーションの場合、ループ内のＶＬＩＷ命令のそれぞれが、各動作がＭＰＥ内の処理装置のそれぞれに対して１個ずつで、最高５個の演算を含む。かくして、ＭＰ
Ｅの内部並列アーキテクチャは、メディアプロセッサ３２とメディア処理システム３０の処理能力、特にグラフィック処理能力をさらに増大させる。
【００５４】
ＭＰＥの並列アーキテクチャから実現可能な最適化の１例として、陰影をつけた物体上の平滑表面を生成するために使用できるプログラムコードの最適化について以下に説明する。本例では、三角形が、グーロー陰影法（Ｇｏｕｒａｕｄ  ｓｈａｄｉｎｇ）として知られる手法で陰影を付けられる。グーロー陰影法では、表面が三角形などの複数個の多角形から構築される滑らかな表面陰影のモデル化の試行において、隣接するピクセル強度は、頂点間で線形補完される。この例を目的とし、増分値の設定は無視することにする。関数により使用される任意の三角形の変数は以下のとおり。
【００５５】
【表１】
2008017493.tif 000003
【００５６】
グールー陰影法を実行するために使用されるマイクロコードは以下のようであってよい。 
【００５７】
【表２】
2008017493.tif 000004
【００５８】
ここで同じマイクロコードが図示される。中括弧｛  ｝がマイクロコードの部分の周囲に置かれ、必要に応じて再配置され、前述のＭＰＥの並列アーキテクチャ１００によって１回のクロックサイクルで実行される。
【００５９】
【表３】
2008017493.tif 000005
【００６０】
図示されるように、「ｈｌｏｏｐ」内のすべての命令は、１個のクロックサイクル内で実行され得、よって、三角形からなる画像上にグーロー陰影法を実行するために必要な時間を短縮する。
【００６１】
図５は、本発明によるベリー・ロング・インストラクション・ワード（ＶＬＩＷ）１４０の例の図である。ＶＬＩＷ命令は可変長で、各クロックサイクルで、各処理装置が個別の命令を実行できるように、処理装置のいずれかまたはすべての命令を含む。例えば、ＶＬＩＷ１４０は、ＥＣＵ装置１０６を制御するためのＥＣＵ＿ＣＴＲＬ命令１４２と、ＭＵＬ装置１１４を制御するためのＭＵＬ＿ＣＴＲＬ命令１４４と、ＡＬＵ装置１１２を制御するためのＡＬＵ＿ＣＴＲＬ命令１４６と、ＲＣＵ装置１１０を制御するためのＲＣＵ＿ＣＴＲＬ命令１４８と、ＭＥＭ装置１０８を制御するためのＭＥＭ＿ＣＴＲＬ命令１５０とを含む。ＥＣＵ＿ＣＴＲＬ、ＭＵＬ＿ＣＴＲＬ、およびＡＬＵ＿ＣＴＲＬ命令は可変長で、ここでは例示を目的として、それぞれ長さ３２ビットとして示される。ＲＣＵ＿ＣＴＲＬおよびＭＥＭ＿ＣＴＲＬ命令も可変長で、ここでは例示を目的として、それぞれ長さ１６ビットとして示される。かかる各命令の長さは、典型的に、処理装置によって異なる。本例で、完全なＶＬＩＷ１４０の長さは１２８ビットである。いずれのＶＬＩＷの長さも、使用される処理装置の数と、ＶＬＩＷが何らかの方法にて圧縮されたか否かに依存する。
【００６２】
次に図６を参照すると、メディアプロセッサ３２および各ＭＰＥ６６〜７２によってサポートされる種々のデータタイプを図示する図が示されている。最も単純なデータタイプは、３２ビットスカラ値であることが好ましいスカラタイプ１６０である。スカラタイプ１６０は、すべての他のデータタイプがそれに基づく、基本的なデータタイプを形成する
。例えば、ベクトルデータタイプ１６２は４個の３２ビットスカラデータタイプ１６４，１６６，１６８，１７０から成り、ベクトルの全長は１２８ビットである。同様にスモールベクトル１７２も特定のタイプの命令に定義され、４個の３２ビットスカラデータタイプ１７４，１７６，１７８，１８０からなるという点でベクトルと似ている。しかし、スモールベクトルのデータ部は６４ビットでしかなく、したがって、陰影領域で示されるように、各スカラレジスタ１７４〜１８０の下半分が０に設定される。同様に、ピクセルデータタイプ１８２も４個のレジスタ１８４，１８６，１８８，１９０からなる。ピクセルは、各一次色（例えば、赤緑青）に対して１６ビット値として一般に定義される。１ピクセルに対し、スカラレジスタ１８４，１８６，１８８は０に設定される。さらに、３個の１６ビット値のみが典型的に必要であるために、最後のスカラレジスタ１９０のすべてのビットが０に設定されるか、またはピクセルのＺ（深度）などの他の値を保持するために使用される。ピクセル全体を１個のデータタイプに格納にでき、１個のクロックサイクルで操作または処理できるので、ピクセルデータタイプ１８２の使用により、好ましくは、グラフィックアプリケーションのためのプロセッサ３２、特にＭＰＥの処理速度が増大される。最後のデータタイプはハーフベクトル１９２で、２個の３２ビットスカラデータタイプ１９４，１９６から成り、全長を６４ビットにすることが好ましい。
【００６３】
すべてのデータタイプ１６０，１６２，１７２，１８２は、単一のレジスタとして、あるいはグループレジスタの組み合わせとしてレジスタファイル１１６内に格納され得る。レジスタファイル１１６内のレジスタの様々な使用が、以下の表１に記載される。
【００６４】
【表４】
2008017493.tif 000006
【００６５】
表１に示されるように、各メディア処理要素（ＭＰＥ）６６〜７２（図３）は、スカラデータタイプを格納することが好ましい３２個の３２ビット物理レジスタからなるレジスタファイル１１６を含むことが好ましい。前述のその他のデータタイプのいずれかを格納
するために、３２ビット長さのレジスタを論理的に組み合わせる。かくして、３２個の物理レジスタしかないが、かかる３２個の物理レジスタが複数個のデータタイプを表すために用いられる。例えば、Ｒ０〜Ｒ３は、第１ピクセルを格納するために組み合わされ、Ｒ４〜Ｒ７は第２ピクセルを格納し、Ｒ８はスカラを格納し、Ｒ１２〜Ｒ１５は特定のクロックサイクル用にベクトルを格納する。次に、次のクロックサイクルで、かかる割当は変更され得る。この物理レジスタのエイリアシングまたは論理的結合は、様々なデータデータタイプをサポートする能力を保持するとともに、レジスタファイルの全体サイズを減少する。例えば、１２８ビットを要するベクトル値を格納するために、４個の３２ビット物理レジスタが論理的に組み合わされる。かくして、第１定義論理ベクトルレジスタＶ０は物理レジスタＲ０〜Ｒ３に格納される。各ベクトルデータは４個の物理レジスタを必要とするために、１度に合計８個のベクトルレジスタが利用できる。同様に、前述のように、スモールベクトルとピクセルデータタイプも４個の物理レジスタに格納される。
【００６６】
ＭＰＥ内の処理装置による処理のためにデータを一時的に格納するデータレジスタに加え、幾つかのアドレスおよびシステムレジスタも存在する。例えば、ＲＸ、ＲＹ、ＲＵおよびＲＶレジスタは、以下により詳細に説明するように、バイリニア・アドレッシングに利用されることが好ましい。レジスタＲＣ０とＲＣ１は、処理装置１０６〜１１４（図４）のいずれかにより使用される汎用ダウンカウンタである。ＳＰレジスタはスタックポインタで、メモリ内のシステムプログラムスタックの先頭へのポインティングに使用される。ＲＺレジスタは、プログラム内の制御が、サブルーチンリターン制御後に、レジスタＲＺ内に保存されたアドレスに戻されるように、呼び出しサブルーチン命令後のプログラム実行中にアドレスを格納するために使用される。ＰＣレジスタは、プログラム実行を制御し、追跡するために使用されるプログラムカウンタである。当業では周知であるように、複数個の条件コードを格納するために使用されるＣＣレジスタもある。
【００６７】
バイリニア・アドレッシングスキームは、例えば、ピクセル操作命令の速度を増大するためにピクセルをロードし、格納するために用いられる。例えば、ピクセルロード命令は以下のバイリニア・アドレッシング形式、すなわちｌｄ＿ｐ（ｘｙ），Ｐｉを有し得る。この特定の命令は、ＲＸとＲＹレジスタを一緒に使用するが、命令中で（ｕｖ）と称されるＲＵおよびＲＶレジスタも使用できる。各レジスタ対ＲＸ，ＲＹおよびＲＵ，ＲＶは、レジスタによって参照されるデータ構造を定義する入出力レジスタの関連セットを有してもよい。例えば、６４ピクセルマップ内のいずれかのピクセルを、単一のバイリニア・アドレッシング命令を用いてロードまたは格納できるように、以下に説明されるようなピクセルマップデータタイプを入出力レジスタによって定義できる。かくして、単一命令が任意のピクセルをロードできるので、ピクセルの格納およびロード速度は低減される。
【００６８】
各メディア処理要素（ＭＰＥ）からメインＤＲＡＭへのピクセルデータタイプ転送のフレキシビリティと速度をさらに増加するためには、複数の異なるピクセルデータタイプがある。各ＭＰＥ内部のピクセルデータタイプの幾つかは、メディア処理システム３０のＤＲＡＭ内に格納されたデータタイプを変換することで生成される。かかる変換は、以下に説明されるように、ＭＰＥが内部フォーマットでピクセルデータをより高速で処理できるために、実行される。外部ＤＲＡＭピクセルデータフォーマットの幾つかは、ＭＰＥＧフォーマットなどの工業規格フォーマットであり、ＭＰＥがかかるフォーマットを操作することは困難である。外部ＤＲＡＭピクセルデータタイプから内部ＭＰＥピクセルデータタイプへの変換と、その反対の変換は、例えば図３の装置８２、装置８４または装置８６などのＤＭＡシステムによって実行される。
【００６９】
変換と、内部通常およびピクセルデータタイプを理解しやすくするために、表２にピクセルデータタイプを示す。
【００７０】
【表５】
2008017493.tif 000007
【００７１】
示されるように、ピクセルマップタイプ０は、１ピクセル当たり１６ビットである。ＭＰＥＧピクセルは、輝度の線形解像度の半分で彩度（ｃｈｒｏｍａ）がサンプル抽出され、したがってこの種のＭＰＥメモリ表象は、１２８ビットメモリ内に８個の８ビットの輝度（Ｙ）値と４個の８ビット彩度（ＣＲ、ＣＢ）対（すなわち８ピクセル）を格納する。
【００７２】
示されるように、ピクセルマップタイプ１は、１ピクセル当たり４ビットである。４ビットの値は、任意のカラー参照テーブル（ＣＬＵＴ）への索引を表すので、その値はピクセルの物理的外見と物理的関係を有さない。かかる４ビットピクセルマップは、前述のように、カラー参照テーブル内での索引付け後、ベクトルレジスタ内にロードされる。
【００７３】
ピクセルマップタイプ２は、１ピクセル当たり１６ビットで、ビットの値は、いずれも５ビットである第１クロミナンス要素Ｃｂと、第２クロミナンス要素Ｃｒと、６ビットである輝度要素Ｙとしてピクセルの色を表す。示されるように、タイプ２ピクセルマップは１６ビットで、ＤＲＡＭに格納され、画面上に表示され、かつ／またはＭＰＥレジスタ内
にロードされるが、このフォーマットでＭＰＥによって、レジスタからメモリ内に格納はできない。ＤＭＡシステムは、メモリからロードする際に、ピクセルマップタイプ４からピクセルマップタイプ２に変換する。同様に、ＤＭＡシステムは、メモリ内に格納し戻す前に、ピクセルマップタイプ２をピクセルマップタイプ４に変換できる。
【００７４】
示されるように、ピクセルマップタイプ３は、１ピクセルあたり８ビットである。８ビットの値は任意のカラー参照テーブル（ＣＬＵＴ）への索引を表しているので、その値はピクセルの物理的外見と物理的関係を有さない。かかる８ビットピクセルマップは、前述のように、カラー参照テーブル内での索引付けの後、ベクトルレジスタ内にロードされる。
【００７５】
ピクセルマップタイプ４は、１ピクセル当たり３２ビットである。該ピクセルマップの２４ビットは、ピクセルの実際の色を表す。示されるように、これらのタイプのピクセルマップは、ＤＲＡＭからのピクセルのロード、ＤＲＡＭまたはＭＰＥメモリ内へのピクセルの格納に使用される。この種のピクセルマップはベクトルレジスタ内に格納される。タイプ４ピクセルマップは、色も表す１ピクセル当たり３２ビットを有する。かかる３２ビットは、いずれも８ビットである第１クロミナンス要素Ｃｂと、第２クロミナンス要素Ｃｒと、８ビットである輝度要素Ｙに分割される。最後の８ビットは予備ビットで、他のピクセル属性に用いられる。
【００７６】
タイプ５ピクセルマップは、１ピクセル当たり１６ビットで、１６ビット制御値を有する。１６ビット制御値は、Ｚバッファ深度に用いられる。１ピクセル当たりの１６ビットは、ピクセルマップタイプ４の場合と同じ様態でＣｂと、Ｃｒと、Ｙとに割り当てられる。
【００７７】
タイプ６ピクセルマップは、１ピクセル当たり３２ビットで、関連３２ビット制御ワードを有する。制御ワードは、Ｚバッファ深さに用いられる。１ピクセル当たりの１６ビットは、タイプ４ピクセルマップと同じ様に配される。
【００７８】
ここで、各ＭＰＥ６６〜７２内の処理装置１０６〜１１４の詳細なアーキテクチャを、より詳細に説明する。
図７は、本発明による論理演算装置（ＡＬＵ）１１２の一実施例の詳細図であり、ピクセルデータに最適化されることが好ましい。以下に述べるように、ＡＬＵ１１２の入出力は種々の異なるソースとやり取りされるために、図示されるようにＡＬＵ１１２はフレキシブルである。さらに、図８を参照して以下に説明するように、ＡＬＵ１１２は、追加加算器・減算器を備えるので、ＡＬＵ１１２は、単一のクロックサイクルでピクセル全体に演算および論理処理を実行できる。
【００７９】
ＡＬＵ１１２は、ＡＬＵ１１２の複数のソース入力の１つからデータを選択するように構成された、マルチプレクサなどの複数個のスイッチ２１０，２１２，２１４を含むことが好ましい。例えば、スイッチ２１０は、本発明によると、レジスタのいずれかの１個に格納される３２ビットデータタイプであるＳｒｃＡから、あるいはＡＬＵ命令に格納される即値データ（ＩｍｍＢ）からデータを選択できる。同様に、第２スイッチ２１２は、ＳｒｃＡから、またはＡＬＵ命令に格納される即値（ＩｍｍＡ）からデータを選択できる。ＩｍｍＡ即値データは、スイッチに入る前に符号拡張器２１６によって符号拡張され得る。ＩｍｍＡデータ、ＳｒｃＢデータ、ＳｒｃＤデータ、またはＳｒｃＢデータの最上位ビットは第３スイッチ２１４によって選択され得る。ＳｒｃＢデータの最上位ビットは、最上位ビット（ＭＳＢ）装置２１７によって決定され得る。
【００８０】
第１スイッチ２１０および第２スイッチ２１２の出力は、シフタ２１８によっていずれ
の方向にも変更または回転され得る。次に、シフタの出力が算術演算装置（ＡＯＵ）２２０に送られる。ＡＯＵ２２０の他の入力は、第３スイッチの出力である。かくして、ＡＯＵ２２０に入力するデータは、複数個の異なるソースから選択され、複数の異なる動作が、ＡＯＵに入力する前に、データに実行される。このフレキシビリティにより、ＡＬＵ１１２は種々の異なるデータタイプを処理可能となる。ＡＯＵ２２０は、加算、減算、論理積、論理和、および排他的論理和を実行し得る。ＡＯＵ２２０の出力は、複数個の宛先に送られる３２ビット値である。ＡＬＵ１１２は、単一のクロックサイクルで単一のピクセルを処理するためにも用いられ、図８を参照して以下に説明する。
【００８１】
図８を参照すると、本発明にしたがって、ピクセルを処理するように構成されたＡＬＵ１１２の図が示されている。図示されるように、ＡＬＵ１１２はＡＯＵ２２０と、付加的な加算器／減算器装置２２２を含む。付加的な加算器／減算器２２２は、ＡＯＵ２２０と同じ演算を実行する。該演算において、要素Ｐ１，Ｐ２，Ｐ３，Ｐ４を備えた第１ピクセルと、要素Ｓ１，Ｓ２，Ｓ３，Ｓ４を備えた第２ピクセルが例えば加算される。要素Ｐ１は要素Ｓ１に加算されることが好ましく、要素Ｐ２は、３２ビット値を加算するＡＯＵ２２０によって要素Ｓ２に加算されることが好ましい。かかる１６ビットピクセル要素を加算するために、ＡＯＵ２２０の前進チェーンをビット１５とビット１６との間で切断する。各ピクセル追加要素Ｐ３，Ｐ４，Ｓ３，Ｓ４を、他の要素が加算されると同時に、付加的な加算器／減算器２２２によって加算する。かくして、本発明によると、ＡＬＵ１１２は、３次元画像処理などのピクセル集中アプリケーションの速度を増加するために、１回のクロックサイクルで１個のピクセルを別のピクセルに演算的、論理的に組み合わせることができる。
【００８２】
図９は、本発明の一実施例によるＭＵＬ装置１１４のアーキテクチャを示す図である。ＭＵＬ装置１１４は、以下に説明するように、クロックサイクルごとにピクセルを高速処理するように構成される。図示されるように、ＭＵＬ１１４装置は、２個の３２ビット数を乗算して６４ビットの結果を生成する３２ビット×３２ビットマルチプライヤ２４０からなり得る。さらに、ＭＵＬ装置１１４は、レジスタに書き戻すために、積のいずれかの３２ビットの部分を選択するシフタ２４２からなる。ＭＵＬ装置１１４は、本発明によると、変数の高指数を迅速かつ容易に計算し得る。例えば、ｘ３を計算する場合、ｘをｘで乗算してｘ２に等しい出力を生成する。次に、ｘ２にふたたびｘを乗算してｘ３に等しい出力を生成するために、ｘ２出力はＭＵＬ入力に戻される。ＭＵＬ装置１１４は、図１０を参照して説明されるように、ピクセルデータタイプも迅速に処理され得る。
【００８３】
図１０は、本発明に従って、ＭＵＬ装置２１４がどのようにピクセルまたはスモールベクトルデータタイプを処理するかを示す図である。３２ビット×３２ビットＭＵＬ２１４は、ＭＵＬ装置１１４が４個の１６ビット×１６ビット乗算器２４６，２４８，２５０，２５２に分解され得るように構成される。さらに、かかる１６ビット×１６ビット乗算器は個々にアドレス指定可能である。したがって、要素Ｐ１，Ｐ２，Ｐ３，Ｐ４を備えた第１ピクセルまたはスモールベクトルを、要素Ｓ１，Ｓ２，Ｓ３，Ｓ４を備えた第２ピクセルまたはスモールベクトルで乗算するために、要素Ｐ１とＳ１は、第１乗算器２４６によって乗算されることが好ましい。同時に、要素Ｐ２とＳ２は、第２乗算器２４８によって乗算され、要素Ｐ３とＳ３は、第３乗算器２５０によって乗算され、要素Ｐ４とＳ４は、第４乗算器２５２によって乗算される。かくして、ピクセルまたはスモールベクトルの全体が、第２ピクセルまたはスモールベクトルの全体により、ＭＵＬ装置１１４を用いて１回のクロックサイクル内で乗算され、したがって、ピクセルを使用するグラフィックアプリケーション用のメディア処理システムの処理速度を増加する。さらに、ＭＵＬ装置１１４は、２個の３２ビット値を乗算するように構成されるとともに、２個のピクセルまたはスモールベクトルを一緒に乗算するように構成され得る。
【００８４】
さらに、本メディア処理システムは、ピクセルが処理される速度をさらに増加するために幾つかの専用ピクセル命令も有することができる。例えば、ピクセルデータタイプを使用できるロードピクセル、格納ピクセル、乗算ピクセル、加算ピクセル命令がある。さらに、前述のように、バイリニア・アドレッシングスキームも、複数個のピクセルから構成される画像が処理される速度を増加できる。
【００８５】
要するに、本メディア処理システムのアーキテクチャは、画像などのピクセルベースデータを高速で処理できるようにするために、ピクセル処理の大幅な強化を提供する。しかし、本メディア処理システムおよびＭＰＥは汎用であるために、該メディア処理システムは、多くの他の速度および処理能力に集約的な演算にも使用され得る。
【００８６】
以上は、本発明の特定の実施例を参照してきたが、当業者であれば、本発明の原則と精神から逸脱することなく、本実施態様への変更が行なわれ得ることは十分理解され、本発明の範囲は特許請求の範囲に定義される。
【図面の簡単な説明】
【００８７】
【図１】メディア処理システムのブロック図。
【図２】本発明によるメディアプロセッサを含むメディア処理システムを示すブロック図。
【図３】図２のメディアプロセッサのブロック図。
【図４】図３に図示される処理要素の１つのより詳細なブロック図。
【図５】処理要素の一部である種々の処理装置を制御できるベリー・ロング・インストラクション・ワードの図。
【図６】本発明によるメディアプロセッサにより利用される種々のデータタイプの図。
【図７】本発明による論理演算装置（ＡＬＵ）のより詳細なブロック図。
【図８】本発明により組み合わされる第１ピクセルと第２ピクセルの図。
【図９】本発明による乗算器（ＭＵＬ）のより詳細なブロック図。
【図１０】本発明によりたがいに乗算される２個のピクセルのブロック図。
【図１】
2008017493.tif 000008
【図２】
2008017493.tif 000009
【図３】
2008017493.tif 000010
【図４】
2008017493.tif 000011
【図５】
2008017493.tif 000012
【図６】
2008017493.tif 000013
【図７】
2008017493.tif 000014
【図８】
2008017493.tif 000015
【図９】
2008017493.tif 000016
【図１０】
2008017493.tif 000017