トップ :: H 電気 :: H04 電気通信技術




【発明の名称】 メディア処理システムおよび方法
【発明者】 【氏名】リチャード ジー.ミラー

【氏名】ルイス エイ.カルディッロ

【氏名】ジョン ジー.マシソン

【氏名】エリック アール.スミス

【要約】 【課題】マルチメディア画像を生成するため、同時またはほぼ同時にビデオデータを解凍し、処理することが可能な処理アーキテクチャを提供する。

【構成】メディア処理システムは、該メディア処理システムによって処理されるデジタルデータを格納する複数個の格納位置を含むDRAMと、該デジタルデータが、標準化されたフォーマットに圧縮されるビデオを含むことと、圧縮ビデオ画像と画像データを生成するために、該標準化フォーマットの圧縮ビデオデータを含む該デジタルデータを処理するシステムと、フルモーションビデオピクセルデータを生成するために、該標準化フォーマットの圧縮ビデオデータを復号化するシステムと、該処理手段と該複合化手段との間で該DRAMを共有するシステムとを含んで提供される。メディア処理は、並列にたがいに接続される複数個の処理要素と、該処理要素のそれぞれを制御し、それぞれに分配するシステムを有してもよい。
【特許請求の範囲】
【請求項1】
種々のタイプのデジタルデータを受信して処理し得る、ユーザ設定可能な汎用メディア処理システムであって、
同メディア処理システムによって処理されるべき、ビデオデジタルデータおよびオーディオデジタルデータを含むデジタルデータを格納するメモリユニットと、
前記デジタルデータの分配処理を可能にすべく配置された複数の分配設定可能メディア処理要素(MPE)であって、各デジタルデータはメモリユニットに接続され、それによって、メディア処理要素の間で、デジタルデータの選択された部分を共有して処理でき、複数の設定可能MPEのうちの少なくとも1つは、MPEの幾つかあるいはすべての間でデジタルデータの分配を制御すべく適切に配置された制御処理要素として、少なくとも部分的に、動的に動作すべく設定され、MPEの課題をスケジューリングし、分配されたMPEはそれぞれ、他の複数のMPEと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げ、さらに、MPEのうちの選択されたものに制御信号を送り、選択されたデジタルデータテイプを処理するために、同制御信号によって、選択されたMPEが再設定される、分配設定可能メディア処理要素(MPE)と、
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために適切に配置された複数の通信バスであって、それによって、通信バスのそれぞれによって、制御信号/コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、通信バスと、
からなるシステム。
【請求項2】
更に、選択された複数のMPEによって適切に処理されるべく、デジタルデータを複数のサブデータ・ストリームに構文解析するための、メモリユニットに接続されたデータストリームパーサからなる請求項1に記載のシステム。
【請求項3】
複数のMPEはそれぞれが、他の複数のMPEを独立に動作させ得る、単一の命令ストリームで複数のデータストリーム(SIMD)の汎用超長語(VLIW)RISCプロセッサである請求項1に記載のシステム。
【請求項4】
プロセッサ制御要素によって供給される信号に基づいて、複数のMPEのうちの選択された幾つかは協同で特定の課題を行なう請求項1に記載のシステム。
【請求項5】
前記特定の課題は、グラフィック処理、データベースの検索、数値処理、およびビデオ処理を含む群から選択される請求項4に記載のシステム。
【請求項6】
デジタルデータが、特定の外部メディアと整合するフォーマット外部メディア上に格納されている請求項5に記載のシステム。
【請求項7】
前記外部メディアはコンパクトディスク(CD),レーザディスク(LD),デジタル多目的ディスク(DVD)を含み、それぞれのフォーマットは、圧縮オーディオフォーマット、第1のタイプの圧縮ビデオと第1のタイプの圧縮オーディオのフォーマット、および第2のタイプの圧縮ビデオと第2のタイプの圧縮オーディオのフォーマットを含み、それによって、汎用メディアプロセッサは特定のフォーマットを識別して、対応するデジタルデータの処理を実行するために複数のMPEのうちの選択された幾つかを再設定する、請求項5に記載のシステム。
【請求項8】
前記特定の課題がMPEG−2ビデオストリームの処理のときは、処理要素コントローラは選択された複数のMPEに、MPEG−2データを復号すべく命令し、他の複数の選択
されたMPEに、該復号されたMPEG−2データを基にフルモーションカラー画像を生成することと、他の複数のMPEに、オーディオストリームデータを生成すること、を指示する請求項6に記載のシステム。
【請求項9】
前記メモリ装置は主システムメモリを含み、複数のバスは、
主システムメモリに接続された主システムバスと、
線形のデータ転送が可能な主システムメモリと通信すべく配置された、該主システムバスから分離された付属バスと、
MPEのうちの選択された幾つかの間でデータパケットの転送や、複数のMPEと複数の周辺装置との間の連結のために使用される通信バスと、からなる請求項1に記載のシステム。
【請求項10】
メディア処理システムによってデジタルデータを処理する方法であって、
デジタルデータを受信する工程と、
受信したデジタルデータと関係するデジタルデータフォーマットを決定する工程と、
適切なフォーマットでデジタルデータを処理するために、複数の設定可能メディア処理ユニット(MPE)のうちの選択された複数を設定する工程と、
設定可能MPEのうちの少なくとも1つが、少なくとも部分的に、動作すべく動的に設定され、MPEのうちの幾つかまたはすべての間でデジタルデータを分配すべく制御し、MPEの課題をスケジューリングし、分配されたMPEはそれぞれ、他の複数のMPEと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げる工程と、
からなる方法。
【請求項11】
更に、受信されたデジタル信号を複数のMPEのそれぞれに接続されたメモリ装置中に格納する工程を含む請求項10に記載の方法。
【請求項12】
更に、複数のMPEのうちの選択された幾つかに制御信号を送り、同制御信号によって、選択された幾つかのMPEが、決定されたフォーマットでデジタルデータを処理するために再設定される請求項10に記載の方法。
【請求項13】
デジタルデータを構文解析する工程と、
同構文解析されたデジタルデータの処理に基づいて複数のMPEの課題をスケジューリングする工程であって、各分配された複数のMPEは他の複数のMPEと協同して構文解析されたデジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体の速度と効率を増大させる、前記スケジューリング工程とを、更に含む請求項12に記載の方法。
【請求項14】
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために複数の通信バスを適切に配置する工程であって、
それによって、分離されたそれぞれの通信バスによって、制御信号/コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、請求項13に記載の方法。
【請求項15】
デジタルビデオデータが第1の標準化フォーマットで圧縮されており、
第1の標準化フォーマットで圧縮されたビデオデータを含むデジタルデータを処理して、圧縮されたビデオ画像とビデオデータを生成する工程と、
選択された複数のMPEによって、第1の標準化フォーマットで圧縮されたビデオ画像を復号して、フルモーションのビデオピクセルデータを生成する工程と、
複数のMPE間でDRAMを共用する工程と、
フルモーションのビデオピクセルデータからフルモーションのビデオ信号を生成して、第1の標準化フォーマットで圧縮されたビデオ画像を復号するために使用される複数の選択されたMPEは、第2の標準化フォーマットで圧縮されるデータを含むデジタルデータを復号すべく再設定するために適合される工程と、からなる請求項10に記載の方法。
【請求項16】
メディア処理システムによってデジタルデータを処理するためのコンピュータプログラムであって、
デジタルデータを受信するためのコンピュータコードと、
受信したデジタルデータと関係するデジタルデータフォーマットを決定するためのコンピュータコードと、
適切なフォーマットでデジタルデータを処理するために、複数の設定可能メディア処理ユニット(MPE)のうちの選択された複数を設定するためのコンピュータコードと、 設定可能MPEのうちの少なくとも1つが、少なくとも部分的に、動作すべく動的に設定され、MPEのうちの幾つかまたはすべての間でデジタルデータを分配すべく制御し、MPEの課題をスケジューリングし、分配されたMPEはそれぞれ、他の複数のMPEと協力して、デジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体的速度と効率を上げるためのコンピュータコードと、
処理されたデジタルデータを出力するためのコンピュータコードと、
コンピュータコードを格納するためのコンピュータ読み取り可能メディアと、 からなるコンピュータプログラム。
【請求項17】
受信されたデジタルデータを各MPEに接続されたメモリ装置中に格納することを更に含む請求項16に記載のコンピュータプログラム。
【請求項18】
制御信号を複数の選択されたMPEに送信するためのコンピュータコードであって、該制御信号によって、選択された複数のMPEが、決定されたフォーマット中のデジタルデータ処理するために再設定される、請求項16に記載のコンピュータプログラム。
【請求項19】
更に、デジタルデータを構文解析するためのコンピュータコードと、
同構文解析されたデジタルデータの処理に基づいて複数のMPEの課題をスケジューリングする工程であって、各分配された複数のMPEは他の複数のMPEと協同して構文解析されたデジタルデータの選択された部分を処理し、それによって、メディア処理システムの全体の速度と効率を増大させる、前記スケジューリングするためのコンピュータコードと、を更に含む請求項18に記載のコンピュータプログラム。
【請求項20】
メモリユニット、複数のメディア処理要素、および制御処理要素を相互接続するために適切に配置された複数の通信バスであって、
それによって、分離されたそれぞれの通信バスによって、制御信号/コマンドやデータがメディア処理システム全体に転送され、それによって、メディア処理システムの全体的な処理能力を増大させる、請求項19に記載のコンピュータプログラム。
【請求項21】
デジタルビデオデータが第1の標準化フォーマットで圧縮されているときに、
第1の標準化フォーマットで圧縮されたビデオデータを含むデジタルデータを処理して、圧縮されたビデオ画像とビデオデータを生成するためのコンピュータコードと、
選択された複数のMPEによって、第1の標準化フォーマットで圧縮されたビデオ画像を復号して、フルモーションのビデオピクセルデータを生成するためのコンピュータコードと、
複数のMPE間でDRAMを共用するためのコンピュータコードと、
フルモーションのビデオピクセルデータからフルモーションのビデオ信号を生成して、第1の標準化フォーマットで圧縮されたビデオ画像を復号するために使用される複数の選
択されたMPEは、第2の標準化フォーマットで圧縮されるデータを含むデジタルデータを復号すべく再設定するために適合されるためのコンピュータコードと、
からなる請求項20に記載の方法。
【発明の詳細な説明】【技術分野】
【0001】
本発明は、マルチメディアアプリケーションにおいて使用するための新規な処理アーキテクチャに関する。詳細には、圧縮されたデジタルビデオおよび音声データを解凍し、デジタルビデオおよび音声データを他のデジタルデータとともに処理し、コンピュータシステムまたはその他の適切なマルチメディア提示システム上において提示するための高解像度カラーマルチメディアデータを生成するのに適合された処理アーキテクチャおよび関連する方法に関する。
【背景技術】
【0002】
DVD、CDまたはコンピュータメモリなどの比較的狭い波長帯の媒体上でのデジタルビデオ画像の格納を容易にするためのフルモーションデジタル画像の圧縮は周知である。コンピュータ画面用の典型的な単一の全画面ビデオフレームは300,000ピクセルを超えるピクセルから成り、各ピクセルは、24ビットカラーシステムの1670万色のうちの1色により定義される。該単一のフルカラー画像フレームは、約100万バイト(1Mb)のメモリに格納され得る。ビデオゲームなどのアプリケーションで動画を実現するためには、ビデオシステムは毎秒約30のカラーフレームを生成、表示しなければならない。よって、1分間のフルモーションカラービデオのためには、システムは、好ましくは2ギガバイト(2Gb)の画像データを格納できなければならない。同様に、300ドット/インチで走査されるフルカラーの静止フレーム画像は、25メガバイトを超えるメモリを必要とする。これらのメモリ要件は、非常に大きく、かかる大量のデータを格納できる格納装置は高価である。
【0003】
さらに、フルモーションカラー画像を生成するため、格納装置からフルカラー画像データが検索される速度は、ほとんどの現行の格納装置の有効データ転送速度を上回る。例えば、典型的な格納装置が毎秒約250KBの速度でデータを転送できると想定すると、毎秒30MBの所要速度でのフルモーションカラービデオ画像の検索(毎秒30個の1MBフレーム)は達成できない。この仮説の格納装置は120倍低速すぎる。
【0004】
したがって、フルカラー画像を表すために必要なデータ量を減少でき、同時に、十分な高品質画像を維持する画像圧縮手法が開発された。かかる手法のほとんどにおいて、情報を除去し得る(すなわち人間の目がそれほど敏感ではない)場所を特定化することで、大幅に画質を劣化させることなく、画像データ量が低減される。例えば、人間の目は、カラーの詳細よりも白黒の詳細により敏感である。かくして、多くの既知の手法は、画質における大幅な認識可能な低下を生じることなく、画像において各ピクセルに関する色情報の量を低減する。
【0005】
かかる既知の圧縮手法としては、差分パルスコード変調、動画エキスパートグループ(MPEG)圧縮、およびMPEG−2圧縮がある。MPEGフォーマットは、コンピュータシステムで使用されるデジタルフルモーションビデオおよび音声データの圧縮と解凍の基準となるよう意図された。MPEG−2フォーマットは、柔軟なデジタル・スケーラブルビデオ伝送を支援する、MPEGフォーマットの拡張版である。MPEGおよびMPEG−2フォーマットは、フルモーションビデオ信号の圧縮および解凍の標準的な手法となってきている。
【0006】
かかる手法を用いて画像が圧縮されると、次に、画像を表示するために、圧縮画像データは一般に解凍され、場合によっては処理される。圧縮された画像データの解凍および処理は、大量の処理能力を必要とし、大量のメモリも必要とする。圧縮されたデジタルビデ
オ画像の復号化・解凍の従来のシステムは、圧縮されたデジタルビデオ画像と、圧縮されていないデジタルビデオ画像の両方を保持するメモリと、画像を解凍し、メモリ内に画像を格納するデコーダとを備える。既知の解凍システムは、PC、DVDプレーヤー、デジタル衛星テレビシステム、ケーブルテレビシステムで使用され得る。かかる既知のシステムは、圧縮された画像を復号化するためにメモリ集約的な演算を使用し、典型的に2MBの格納空間を必要とする。当業者なら理解するように、かかるシステムは、解凍に必要とされる大量のメモリにより高価になる傾向がある。さらに、かかるシステムは、画像のみを解凍し、複合画像を生成するために、他のソースからのデジタルデータは処理しない。最終的に、データを解凍し、同時にビデオデータを処理するためには、追加のメモリおよび処理能力が必要とされ、それらは一般に従来のビデオ解凍システムでは利用可能ではない。
【0007】
さらに、従来の処理システムは、ビデオ画像を生成するのに十分な処理能力を有するものが存在するが、かかるシステムのいずれも、フルモーションカラー画像を高速で効率よく解凍、処理するために最適化されていない。一般に、かかる処理システムは、処理システムに付加された別個の解凍システムも必要とする。
【0008】
最後に、フルモーションカラービデオゲーム、バーチャルリアリティシステム、ケーブルテレビ受像機などの用途のために十分高速でメディアデータを解凍、処理するようなこれら従来のシステムは存在しない。かかるシステムのいずれも、統合されたフルモーション画像データ解凍および処理システムのいずれも含まないため、かかるシステムのいずれも、廉価で完全に機能的なメディア処理システムを提供しない。
【特許文献1】米国特許出願第09/476,946号
【特許文献2】米国特許出願第09/476,698号
【発明の開示】
【発明が解決しようとする課題】
【0009】
したがって、公知の装置のこれらの不都合およびその他の不都合を回避するメディア処理システムおよび方法が必要とされている。
【課題を解決するための手段】
【0010】
本発明は、衛星デジタルテレビシステム、ビデオゲームシステム、ケーブルテレビシステムなどで使用され得るフルモーションカラー画像を生成するために、ビデオデータの解凍および処理を同時に行うメディア処理システムを提供する。該メディア処理システムは、システムの全体的なコスト削減のため、解凍システムと処理システムとの間で共有されるメモリも有し得る。
【0011】
本発明によると、メディア処理システムは、標準化されたフォーマットで圧縮されたビデオデータを含むデジタルデータを格納するためのダイナミックランダムアクセスメモリ(DRAM)またはその他の適切な格納装置を備え得る。該DRAMは処理システムと復号化システムとによって共有される。前記デジタルデータは処理されて、圧縮されたビデオ画像および画像データを生成する。次に、圧縮されたビデオ画像は復号化されて、フルモーションビデオピクセルデータを生成する。
【0012】
次に、表示され得るフルモーションビデオ信号を生成するために、フルモーションビデオピクセルデータが使用される。前記DRAMは圧縮された音声データを備えてもよく、該圧縮された音声データは復号化され、次に、マルチメディアデータを生成するために、フルモーションビデオ信号と組み合わされ得る。メディア処理システムは、単一の処理サイクル内で2個のピクセルを乗算するか、または組み合わせてもよい。メディア処理システムは、単一の半導体チップ上に形成されてもよい。
【0013】
本発明のより完全な理解は、好ましい実施例の詳細な説明と特許請求の範囲を、図面と関連して考慮することにより得られる。図面において、同一の参照番号は同様の部分を示す。
【発明を実施するための最良の形態】
【0014】
本発明は新規な処理アーキテクチャに関し、より詳細には、マルチメディア画像を生成するため、同時またはほぼ同時にビデオデータを解凍し、処理することが可能な処理アーキテクチャに関する。本発明が説明されるのはこの状況においてである。ただし、本発明によるシステムおよび方法がより広い効用を有することは言うまでもない。
【0015】
図1は、本発明にしたがってマルチメディアデータを生成するために、デジタルデータを解凍し、処理するように構成されたシステム20の全体ブロック図である。該システムは、圧縮されたデジタルメディアストリームを生成または提供し得るハードディスクドライブ、ケーブルテレビシステム、衛星受像機またはCDまたはDVDプレーヤーなどの圧縮画像発生器25を備えることが好ましい。システム20は、解凍されたフルモーション画像を表示するディスプレイシステム26も備える。音声および視覚データを含み得る圧縮されたメディアストリームは、該圧縮されたメディアストリームを解凍するように構成されたメディア処理システム30に入る。さらに、メディア処理システム30は、圧縮されたメディアストリームを解凍すると同時に、圧縮されたデータストリームまたは別の格納装置またはデジタルデータソースに含まれるデジタルデータを処理し得、かくして、解凍されたメディアストリームと共に使用され得る他の種類のメディアデータを生成する。例えば、対話型のカラー、フルモーションビデオゲームが生成され得る。すべてのデータが解凍され、処理されると、データは、見るために表示システム26に出力される。ケーブルまたは衛星テレビシステム用には、メディア処理システム30は、入力された圧縮デジタルデータを単に解凍し、本発明の一実施例によるとテレビ画面であり得るディスプレイ26上に画像を出力し得る。
【0016】
図2は、本発明の一実施例によるメディア処理システムのアーキテクチャのブロック図である。メディア処理システム30は、圧縮ビデオデータの解凍、フルモーションカラー画像を生成するための解凍されたビデオデータおよび/または他のデジタルデータを含むデジタルデータの処理、およびメディア処理システム30内での他の演算の制御などの複数の演算を実行可能なメディアプロセッサ32を備える。メディアプロセッサ32は、単一の半導体チップ上に形成され得、これに代わって、メディアプロセッサ32の複数のコンポーネントが複数の半導体チップまたはデバイスに区切られてもよい。
【0017】
メディア処理システム30は、ビデオまたは視覚データ、音声データおよび/または圧縮データなどの種々のデジタルデータを一時的に格納するためのDRAM、SDRAM、フラッシュメモリ、またはその他の適切な格納装置などの1つ以上の格納装置34,46を備えることも望ましい。DRAMおよび/またはSDRAMはそのより高速なアクセス時間により、より迅速にアクセス可能であるので、メディア処理システム30によって処理または解凍されるいかなるデータも、メインメモリ(図示せず)からDRAMおよび/またはSDRAMにロードされることが好ましい。メディア処理システムによって処理されたデータは、ディスプレイ上に表示される前またはメインメモリに戻される前のいずれかで、DRAMおよび/またはSDRAMに一時的に格納され得る。
【0018】
マルチメディアデータを処理する際、メディアプロセッサ32は、デジタル画像データストリームおよびデジタル音声データストリームを生成するように構成されている。ビデオエンコーダおよびデジタル−アナログコンバータ(DAC)36はメディアプロセッサ32から出力されるデジタル画像データを、テレビまたはコンピュータモニタなどのディ
スプレイ装置上に表示できる複合ビデオ、s−ビデオ、コンポーネントビデオなどのアナログ画像信号に変換する。音声デジタル・アナログコンバータ(DAC)38は、メディアプロセサッサ32によって出力されたデジタル音声信号を、オーディオシステムなどによって放送可能なアナログ音声信号(好ましくは約2〜8個の別個の音声チャネル)に変換する。別の実施例によると、メディアプロセッサ32は、IEC−958ステレオ音声またはコード化音声データ信号39も出力し得る。この信号は内部音声デコーダまたはデジタル・アナログコンバータ(DAC)を有し得るシステムへの接続を意図された音声出力信号である。
【0019】
メディアプロセッサ32は、メディア処理システム30用のベーシック・インプット/アウトプット・オペレーティング・システム(BIOS)と、音声データを解凍し、合成音声を生成するために使用され得る音声テーブルおよび/またはメディアプロセッサ32およびメディア処理システム30によって使用されるその他の適切なソフトウェアまたはデータを格納するために使用され得るリードオンリーメモリ(ROM)などの第2格納装置40も備える。さらに、メディアプロセッサ32はシステムバス41に接続される拡張バス42を備えてもよく、それにより、1つ以上の拡張モジュール43がメディアプロセッサ32に接続され得る。拡張モジュール43は、メディア処理システム30の機能性を拡張するためのマイクロプロセッサ44などの追加ハードウェアを備えてもよい。図2に示されるように、追加メモリ46を、拡張バス42およびシステムバス41を介してプロセッサ32に接続してもよい。
【0020】
メディアプロセッサ32は、メディアプロセッサ32と、メディア処理システム30の他の部分との間の通信のための複数の通信接続を備えることが好ましい。メディアデータ接続50は、メディアプロセッサ32と、圧縮画像発生器25(図1)などのその他のシステムとの間のメディアデータの転送を可能にする。メディア制御接続52は、メディアプロセッサ32と、IC互換性装置および/またはシステムバス41に接続されたインターフェースハードウェアなどの他のシステムとの間で制御信号および/またはデータを転送する。ユーザインターフェース接続54は、メディアプロセッサ32と、ジョイスティック、IRリモコン装置などのユーザインターフェース周辺機器との間でユーザインターフェースデータを転送する。最後に、入出力チャネル接続56は、システムのさらなる拡張のための他のI/Oデバイスとの接続を可能にする。
【0021】
メディア処理システム30は、フルモーションカラービデオゲーム、ケーブルテレビ受信機および衛星テレビ受信機、高解像度テレビ受信機、コンピュータシステム、CDおよびDVDプレーヤーなどの種々の用途で使用される。例えば、ビデオゲームアプリケーションで、地形、登場人物およびゲームのその他の視覚的側面を表すデジタルデータは、メインメモリに格納され、周辺デジタルデータソースから入力される。本発明のこの態様によると、メディア処理システム30、およびより詳細にはプロセッサ32は、1乃至それ以上のデジタルデータソースからのデジタルデータを処理し、ビデオゲームディスプレイ上に表示されるインタラクティブなフルモーションカラー画像を生成する。メディア処理システム30は、ビデオゲームの音楽および音響効果を追加する音声信号も生成し得る。
【0022】
ケーブルテレビ受信機または衛星テレビ受信機に対し、メディア処理システム30は、ケーブルヘッドエンドシステムか衛星送信機から受信した圧縮デジタルビデオ・音声信号を解凍し、解凍デジタルビデオ・音声信号を生成する。次に、解凍デジタルビデオ・音声信号は、テレビディスプレイへの出力であるアナログ信号に変換される。メディア処理システム30はまた、任意の暗号化入力ケーブルテレビまたは衛星テレビ信号を解読するように構成されてもよい。
【0023】
DVDプレーヤー用には、メディア処理システム30は、DVDまたはCDから圧縮デ
ジタルデータを受信し、データを解凍することが好ましい。同時に、メディア処理システム30はROM、例えばROM40に格納されたデジタルデータまたは別のデジタルデータソースからの入力を受信し、解凍されたDVDまたはCDカラー画像が、ROMまたはその他のデジタルデータソースから受信されたデータと共に表示されるビデオゲーム環境を生成し得る。かくして、インタラクティブなフルモーションカラーマルチメディアゲームが、メディア処理システム30によって動作され得る。
【0024】
次に図3を参照すると、その他の多数の処理アプリケーションと同様に、上記で概説したアプリケーションを実行するメディアプロセッサ32の内部アーキテクチャを以下でさらに詳細に説明する。より詳細には、図3は、内部並列アーキテクチャを有するメディアプロセッサ32のブロック図である。本発明の並列アーキテクチャは、デジタルデータを解凍、処理するために必要な処理能力および速度を提供し、フルモーションカラー画像を生成可能にする。並列アーキテクチャは、様々なアプリケーションで利用され得るが、並列アーキテクチャは特に、マルチメディア処理アプリケーションに適用可能である。
【0025】
本発明の一実施例によると、メディアプロセッサ32は、通信バス60と、メインバス62と、補助バス64とから成り、これらのすべてが、プロセッサ32の種々の処理要素とサブシステム装置を接続するために用いられる。より詳細には、プロセッサ32は、第1処理要素(MPE0)66と、第2処理要素(MPE1)68と、第3処理要素(MPE2)70と、第4処理要素(MPE3)72と、復号支援装置74と、音声映像I/Oシステムとからなることが好ましい。本発明の一実施例によると、音声映像I/Oシステムは、音声I/O装置76と、ビデオI/O装置78と、ビデオ時間ベース・表示発生器80とからなる。
【0026】
メインバス62は、MPEメモリと外部SDRAMとの間か、または1個のMPEから別のMPEへのいずれかにおける、約216Mバイト/秒の最大データ転送速度を有する32ビットバスである。該バスは、データのバーストの転送に使用でき、バイリニア・アドレッシングおよびZバッファ比較を含むピクセル転送の広範なサポートを有する。これは、ビデオ・音声出力にも使用される。メディア処理システム30は、このバスに接続される最低8MバイトのSDRAMを有することが好ましい。
【0027】
補助バス64は、16ビットバスであることが好ましく、より単純で低速なメインバスのようなものである。補助バス64は、システムバスメモリと、システムバスに接続される他のデバイスとの通信用に使用され、線形データ伝送(linear data transfer)を、約108Mバイト/秒の最高速度で実行する。メディア処理システム30は、該バスに接続される最低8MバイトのDRAMを有することが好ましい。
【0028】
通信バス60は、最大データ転送速度が約172Mバイト/秒の別の32ビットバスであることが好ましく、MPE間で128ビットパケットの伝送に使用されるか、MPEの周辺機器との通信を可能にするために使用される。通信バス60は低レイテンシーバスであって、プロセッサ間の通信に適している。通信バス60のより詳細な説明については、2000年1月3日に出願され、「マルチプロセッサシステム用の通信バス(Communication Bus fora Multi−Processor System)」と題された米国特許出願第09/476,946号(代理人明細書番号第19223−000600US)を参照されたい。当該出願のすべては参照により本願に援用される。
【0029】
データと命令が同じバスで伝送されなければならない、より標準的な単一バスアーキテクチャと比較すると、制御信号/コマンドおよびデータが別のバス上で通信されるために、該特定の並列バス構造は、メディア処理システム30により処理されるデータ量の増加
を可能とする。処理要素とサブシステム装置との間で伝送されるコマンドおよびデータの数を増やすことにより、システムの総処理能力が増大される。
【0030】
さらに図3で、処理要素およびサブシステム装置について以下により詳細に説明する。特に、プロセッサ32は、処理要素(MPE)66 ,68,70,
72を備えることが好ましい。該処理要素の1つは、好ましくはプロセッサ32の処理全体を制御するために、少なくとも部分的に、制御処理要素として使用される。例えば、制御処理要素は、(1)各MPEと他のシステム装置の間における一部またはすべてのデータの移動を制御し、(2)MPEおよびシステム装置が実行するタスクのスケジュールを決定し、(3)他の適切な制御機能を実行し得る。このようにして、タスクが適切にスケジュール指定され、データが効率的に利用されると、メディアプロセッサ32内のすべてのMPEとサブシステム装置が常に、またはほとんど常にビジー状態に維持できる。メディアプロセッサ32内のすべてまたはほとんどのMPEおよびサブシステム装置をアクティブ状態に維持することで、より多くのデータおよびコマンドが処理され、かくして、システムの全体速度が増大する。
【0031】
本発明はいかなる特定のアプリケーションまたはメディアシステムに限定されないが、プロセッサ32の動作は、MPEGビデオデータストリームの処理を例に取って説明する。MPEGフォーマットは、MPEG−1規格とMPEG−2規格とを有し、MPEG−2規格はその改良された画像圧縮能力により、この2つの内でより広く用いられ始めている。MPEGフォーマットは、特定のピクセルの輝度に対応する輝度値で各ピクセルを表す。さらに、4個のピクセルの色を表す2個のクロミナンスを生成するため4個ずつピクセルがサンプル抽出される。かくして、4個のピクセルに関するデータを格納するため6バイトが使用される。該フォーマットは、4.2.0サブサンプリングフォーマットとして知られる。非圧縮の画像では、同じ4個のピクセルは、少なくとも12バイトのメモリを要する。MPEGデコーダは、ピクセルがディスプレイシステム上で表示され得るように、4.2.0サブサンプルされた圧縮フォーマット信号を、複数個の個々のピクセルを表す信号に変換し戻す。MPEGおよびMPEG−2の圧縮並びに解凍手法は当業で周知であり、本願では詳細には説明しない。
【0032】
図3に示されるように、すべてのメディア処理要素(MPE)66〜72は、バス60〜64のそれぞれに接続されることが好ましい。4個のMPEが図示されるが、本発明は、いかなる特定数のMPEに限定されるものではなく、最低1個のMPEまたは多数のMPEを有してもよい。ただし、本発明の一実施例によると、4個のMPEを用いるのが好ましい。前記で簡単に説明したように、かかる4個のMPEは、単一の半導体チップ上か、または多数のチップ上に形成され得る。
【0033】
本発明の一実施例によると、各MPE66〜72は、他のすべてのMPEから独立して動作可能な単一命令多重データストリーム(SIMD)汎用ベリー・ロング・インストラクション・ワード(VLIW)RISCである。したがって、図3に図示される実施例によると、最高4個の個別の複雑な処理タスクが同時またはほぼ同時に実行される。さらに、大きなより複雑なタスクでは、制御プロセッサが同じタスク上で幾つかまたはすべてのMPEを動作させる。例えば、3次元画像を生成する場合、1個のMPEは、実像を生成する多角形を計算し、同時に別のMPEは多角形を描画(表現)し得る。かくして、MPEは、タスクに応じて、並列に独立して、あるいはたがいに協動して動作できる。このフレキシビリティは、メディア処理システムが、グラフィック処理、データベース検索、数値処理などの様々な異なるタスクを処理することを可能にする。さらに、MPE66〜72の各々は、同じ汎用命令セットを利用することが好ましい。
【0034】
本発明の一実施例によると、MPEG−2ビデオデータストリームを処理するために、
MPEGデータを復号化し、フルモーションカラー画像を生成するために必要なタスクは、複数のMPE間に分割されてもよい。したがって、例えば1個のMPEが音声データを処理し、1個のMPEが圧縮ビデオデータを生成し、1個のMPEがデータストリームパーサーまたはマルチプレクサとして機能し、別のMPEが制御機能を実行し得る。
【0035】
さらに図3を参照すると、プロセッサ32が、MPEG−2データ、サブピクチャデータ、オーバーレイデータ、および制御データなどを含むDVDデータストリームを以下に処理するかの具体例を示している。本発明のこの特定例によると、DVDデータストリームを処理するために、MPE168は、データストリームを受信し、データストリームを、圧縮ビデオデータコンポーネント、圧縮音声データコンポーネント、サブピクチャデータコンポーネント、ナビゲーション制御データコンポーネントなどの別々のコンポーネントに分割または分解するように構成されることが好ましい。DVDデータストリームが独立したコンポーネントに分解されると、次にデータは、データバッファとして機能するメモリ内に置かれる。データが提示された時点またはそれに近い時点で、MPE168がメモリからデータを引き出し、処理のために、データの独立したコンポーネントを異なるMPEおよびサブシステム装置に送信することが好ましい。
【0036】
この特定例によると、MPE066はMPEG−2データストリームの圧縮音声部分を復号化および/または解凍するように構成されることが好ましい。同様に、MPE168、MPE270およびデコーダ装置74は、MPEG−2ビデオデータストリームの復号化または解凍を実行するように構成される。図3に図示されるように、デコーダ装置74は、デコーダ装置74とMPE68,70との間のデータの高速転送を容易にするために、MPE168とMPE270の両方への直接的な接続を含む。さらに、デコーダ装置74とメモリ、および他のMPEとサブシステム装置の間でのデータ転送を容易にするために、デコーダ装置74は、通信バス60とメインバス60に接続されることが好ましい。
【0037】
MPE168は、別のコンポーネントにMPEG−2およびDVDデータを解析し、次に、残りの復号化機能のために、ビデオデータストリームをMPE270とデコーダ装置74に送信する。例えば、MPE270は、ストリーム解析と動作ベクトル復号化機能を実行するように構成され、一方デコーダ装置74は、逆離散余弦変換(IDCT)、逆定量化(dequantization)、および動作予測機能などのMPEG復号の下層部を実行するように構成される。図3に図示されるように、MPE270とデコーダ装置との直接的な接続は、該装置間のデータの高速転送を可能にし、かくしてビデオデータストリームの高速復号を容易にする。
【0038】
MPEGビデオストリームは復号された後、テレビまたはコンピュータモニタなどの表示装置に提供されるまで格納されるメモリに送信されることが好ましい。MPE372は、サブピクチャ、メニュー、ナビゲーションおよびその他のビデオおよび音声制御機能を処理するように構成されることが好ましい。
【0039】
すべての音声、ビデオおよびDVD情報が復号化され、メモリ内に置かれた後に、表示発生器80は、ビデオ、サブピクチャおよび制御情報をメモリから検索し、幾つかの処理を実行する。例えば、本発明の一実施例によると、ビデオ情報は4:2:0MPEGフォーマットでメモリに格納される。表示発生器80は、4:2:0フォーマットをCCIR656標準ビデオフォーマットに合致した4:2:2フォーマットに変換することが好ましい。さらに、表示発生器80は、ビデオ情報をメニューなどのオーバーレイ情報およびサブピクチャチャネル情報と組み合わせて、出力として情報の全パケットを提示することが好ましい。最後に、表示発生器80は、好ましくはビデオタイミングとリフレッシュ機能を実行するように構成されて、サブピクチャ復号化動作の幾つかを実行し得る。表示発生器80が、サブピクチャ復号を実行するためにどのように1乃至それ以上のMPEと相
互作用するかについてのより詳細な説明は、2000年1月3日に出願され、「サブピクチャ復号方法と装置(Subpicture Decoding Methods and Apparatus)」と題された米国特許出願第09/476,698号(代理人明細書第19223−000700US号)に記載され、当該出願のすべては参照により本願に援用される。
【0040】
前述の例は、DVDデバイスからのMPEG−2ビデオストリームとその他の情報の復号化として本願で記載されたが、当業者であれば、プロセッサ32が、処理機能、またはデジタル静止カメラ、デジタルビデオカメラ、ケーブルまたは衛星テレビシステム、ROMまたはハードドライブ、あるいはその他の適切なデータソースなどのいかなるソースからのメディアデータストリームを実行できることは十分理解するであろう。さらに、プロセッサ32は、メディアデータのみならず、いかなるタイプのデータも処理するように構成され得る。最後に、前述の例は、特定の機能について説明しており、MPE66〜72と、デコーダ装置74および表示発生器80などの他のサブシステム装置により実行されるが、当業者であれば、本発明がこれらの特定の機能分類に限定されないことは十分理解するであろう。MPEとサブシステム装置は、いかなる数の異なる機能を実行するようにも構成され得る。したがって、本発明は、本願に説明されるか、図3に図示される例に限定されない。
【0041】
プロセッサ32は、メディア処理システム30の通信バス60、補助バス64およびシステムバス41(図2)に電気的に接続されるシステムバスインターフェース82も備えてよい。システムバスインターフェース82は、プロセッサ32と、メモリと、システムバス41および/または拡張バス42に接続される他の周辺機器間に通信パスを提供する。例えば、図2に図示されるように、プロセッサ32は、システムインターフェース82とシステムバス41とを介して、DRAM46および拡張モジュール43に接続される。システムバスインターフェース82を利用することで、プロセッサ32は、メモリ、外部プロセッサ、周辺機器などを含む複数の異なるデバイスに接続され得る。
【0042】
さらにメディアプロセッサ32は、メインバス・オービトレーション・メモリアクセス装置84を含む。装置84のメインバスオービトレーション部は、メインバス62上のバストラヒックを制御し、オービトレーションを行なうことが好ましい。装置84は、メモリ、例えば図2に図示されるメモリ34にインターフェースも提供することが好ましい。メモリ34にアクセスするために、装置84は、メモリオービトレーションシステム(図示せず)と、直接メモリアクセス装置(図示せず)および/またはDRAMインターフェース(図示せず)を備えるか、またはそれらと通信し得る。
【0043】
前述のように、通信バス60は、一般的に、プロセッサ32内の種々のシステム間、ならびにプロセッサ32外部の種々のシステムおよびシステムインターフェースとの制御信号およびデータの通信に使用される。例えば、ROMインターフェース88は、ROM、例えば図2のROM40へのデータ転送および同ROMからのデータの転送のために、補助バス64と通信バス60に接続される。前記で簡単に説明したように、該ROMは、メディアプロセッサ32に固有のプログラムコードおよびその他のデータを格納できる。また、一般入出力(I/O)インターフェース90が通信バス60に接続されて、メディアプロセッサ32と、例えばユーザインターフェースまたはメディア制御システム(例えばキーボード、ジョイスティック、マウス、およびその他の適切なユーザインターフェース)との間に通信パスを提供し得る。
【0044】
通信バス60には、コード化データインターフェース92と、通信バスオービトレーション装置94も接続される。コード化データインターフェース92は、DVDプレーヤー、ケーブルまたは衛星ビデオフィードなどのソースから、MPEGビデオデータなどのコ
ード化されたデータを受信し、1乃至それ以上のMPE66〜72、デコーダ装置74および/またはメモリに通信バス60を介してデータを通信することが好ましい。さらに、通信バスオービトレーション装置94は、通信バス60を介したデータ通信の使用および制御のオービトレーションを行うように構成されることが好ましい。
【0045】
最後に、前記で簡単に説明したように、プロセッサ32は音声I/O装置76およびビデオ入力装置78を備え得る。音声I/O装置76は、通信バス76とメインバス62に接続され、マイク、ステレオシステムなどの外部音源から音声デジタルビットストリーム入力を受信するように構成されることが好ましい。音声I/O装置76からの出力は、プロセッサ32の音声出力であり、IS、IEC958、SP−DIF、AC_3、MPEG音声、MP3、DTSまたはその他の公知の音声フォーマットなどの種々のデジタル音声出力フォーマットを含む。ビデオ入力装置78は、通信バスに接続され、例えばビデオカメラ、NTSCおよびPALデコーダなどからデジタルビデオ入力(例えばCCIR656デジタルビデオフォーマット)を受信するように構成されていることが好ましい。
【0046】
要約すると、MPE66〜72は汎用処理要素であるが、MPEは、好ましくは、メディア処理アプリケーションを最適化するために使用できる特定の命令を命令セット内に含む。かかる命令を以下により詳細に説明する。また、各MPEは、3次元画像を生成するためのメディア処理規格およびアルゴリズムが変化し、向上する場合に、命令が新しいアルゴリズムを実行するために簡単に変更されるために、MPEは最新の基準とアルゴリズムに順応できるという点で十分に一般的である。このMPEのフレキシビリティは、本発明によるメディア処理システム30が拡張し、ユーザの需要と将来的な革新に順応することを可能にする。例えば、より優れた圧縮技術が開発されると、メディア処理システム30に簡単に組み込まれる。さらに、MPEのいずれも特に単一機能を実行するように構築されていないために、処理機能のいずれか(例えば音声処理システム)で障害が生じた場合、障害を軽減するために、音声データを処理するのに別のMPEが使用され得る。
【0047】
前記でより詳細に説明されるように、各MPE66〜72は単一命令多重データストリーム(SIMD)内部ハードウェアアーキテクチャとベリー・ロング・インストラクション・ワード(VLIW)アーキテクチャとからなることが好ましい。VLIWアーキテクチャは、論理演算装置、乗算器などの複数個の並列処理装置を備えるため、各処理装置がそれ自体のデータに関するそれ自体の命令を実行できる。かくして、前述のように、メディアプロセッサ32は並列アーキテクチャから成り、メディアプロセッサ32内の各MPE66〜72も並列アーキテクチャからなることが好ましく、よって、メディアプロセッサ32およびメディア処理システム30の全体的な処理能力がさらに向上する。
【0048】
次に図4で、本発明の一実施例によるメディア処理要素(MPE)66,68,70,72の内部並列アーキテクチャ100を図示するブロック図を示す。メディアプロセッサ32の並列バスアーキテクチャと同様に、各MPE66〜72は、命令バス102とデータバス104を有する並列バスアーキテクチャも含むことが好ましい。命令バス102は好ましくはMPEの全体にわたって命令を送信し、データバス104はMPE内の種々の装置へまた同装置からデータを送信する。前述のように、命令およびデータが同じバスを通って伝送されないので、並列な命令およびデータのバスアーキテクチャによりMPE速度が増大される。
【0049】
MPEのアーキテクチャ100は、実行制御装置(ECU)106と、メモリ処理装置(MEM)108と、レジスタ制御装置(RCU)110と、論理演算装置(ALU)112と、乗算処理装置(MUL)114と、レジスタファイル116などの複数個のサブユニットを有し得る。ECM106と、MEM108と、RCU110と、ALU112と、MUL114はすべてレジスタファイル116を介して並列にともに接続されること
が好ましい。命令解凍およびルーティング装置118は命令バス102を介して命令メモリ120に接続され、好ましくは命令を復号し、MPE内の種々の処理装置へルートする。命令メモリ120は、MPE内の種々の処理装置を制御する複数個の命令を格納する。格納される命令は、好ましくはベリー・ロング・インストラクション・ワード(VLIW)の形式であり、格納するために必要なメモリ量を低減するために圧縮されている。VLIW圧縮のより詳細な説明を以下に説明する。
【0050】
レジスタファイル116は、MPEの処理装置106〜114のいずれかによって処理されるデータを一時的に格納するために使用される。例えば、2つの数を加算する際、各数はレジスタファイル116内のレジスタにロードされ、次に、該レジスタが加算され、結果がレジスタに格納される。以下に説明するように、レジスタファイル116は、ピクセルなどのビデオ処理に固有のデータタイプを含む種々のデータを格納するよう再構成され得る。
【0051】
MEM装置108は、データバス104によってMEM装置108に接続されるデータメモリ122などのMPE内のいずれかの格納要素へのアクセスを制御するように構成される。MEM装置108は、別のMPEまたは別のシステムからMPE内の適切なメモリまたはレジスタに伝送されるようにデータのルートを決定し得る。例えば、MPEは、データインターフェース130〜138を介して、メモリから、または別のMPEもしくは処理装置から直接データを受信できる。メインバス62に接続されるSDRAMからのデータは、メインバスDMAインターフェース134を介して、MPEに伝送される。同様に、通信バス60と補助バス64からのデータは、それぞれ通信バスインターフェース138と補助バスDMAインターフェース136を介して、MPEにより受信される。データは、コプロセッサDMAインターフェース132を介して、あるMPEメモリ122と、別のMPEメモリ122またはシステム装置(例えばデコーダ支援装置74)の間で伝送され得る。同様に、MPEは、コプロセッサインターフェース130を介して、別のMPEまたはシステム装置(例えばデコーダ支援装置74)のレジスタまたはレジスタファイル内のデータにアクセスできる。図3に図示される実施例によると、デコーダ支援装置74は、コプロセッサDMAインターフェース132を介して、MPE168のデータメモリ122からデータから引き出すことが可能である。同様に、MPE70は、コプロセッサインターフェース130を介して、データ支援装置74のレジスタにアクセスできる(逆もまた同様である)。最後に、図4に図示されるように、アーキテクチャ100は、MEM装置108からレジスタファイル116へデータを書き戻すことを可能にする。
【0052】
RCU110は、対立がないように、専用レジスタのグループ(図示せず)への処理装置の割当を制御する。ALU112は、レジスタファイル116に典型的に格納されるデータに対して演算および論理処理を実行し、また、以下にさらに詳細に説明されるように、ピクセル演算のために最適化され得る。MUL114はレジスタライフ116に典型的に格納される2個のデータの乗算を実行し、また、以下に説明されるように、ピクセル演算のために最適化され得る。図4に示されるように、ALU装置112およびMUL装置114は、両方とも、リターンレジスタファイルポート126,128をそれぞれ介して、レジスタファイル116にデータを返信でき、よって生じたデータはレジスタファイルレジスタのいずれかに格納され得る。
【0053】
図示される並列パイプラインVLIWアーキテクチャ100のために、処理装置106〜114のそれぞれが単一の独立命令を処理できるので、各MPEは、各クロックサイクルで最高5個の独立命令を処理できる。3次元環境で多角形を生成する、あるいは画像に陰影をつける命令のグループなどの、繰り返し実行される複雑なループ命令を有するグラフィックアプリケーションの場合、ループ内のVLIW命令のそれぞれが、各動作がMPE内の処理装置のそれぞれに対して1個ずつで、最高5個の演算を含む。かくして、MP
Eの内部並列アーキテクチャは、メディアプロセッサ32とメディア処理システム30の処理能力、特にグラフィック処理能力をさらに増大させる。
【0054】
MPEの並列アーキテクチャから実現可能な最適化の1例として、陰影をつけた物体上の平滑表面を生成するために使用できるプログラムコードの最適化について以下に説明する。本例では、三角形が、グーロー陰影法(Gouraud shading)として知られる手法で陰影を付けられる。グーロー陰影法では、表面が三角形などの複数個の多角形から構築される滑らかな表面陰影のモデル化の試行において、隣接するピクセル強度は、頂点間で線形補完される。この例を目的とし、増分値の設定は無視することにする。関数により使用される任意の三角形の変数は以下のとおり。
【0055】
【表1】


【0056】
グールー陰影法を実行するために使用されるマイクロコードは以下のようであってよい。
【0057】
【表2】


【0058】
ここで同じマイクロコードが図示される。中括弧{ }がマイクロコードの部分の周囲に置かれ、必要に応じて再配置され、前述のMPEの並列アーキテクチャ100によって1回のクロックサイクルで実行される。
【0059】
【表3】


【0060】
図示されるように、「hloop」内のすべての命令は、1個のクロックサイクル内で実行され得、よって、三角形からなる画像上にグーロー陰影法を実行するために必要な時間を短縮する。
【0061】
図5は、本発明によるベリー・ロング・インストラクション・ワード(VLIW)140の例の図である。VLIW命令は可変長で、各クロックサイクルで、各処理装置が個別の命令を実行できるように、処理装置のいずれかまたはすべての命令を含む。例えば、VLIW140は、ECU装置106を制御するためのECU_CTRL命令142と、MUL装置114を制御するためのMUL_CTRL命令144と、ALU装置112を制御するためのALU_CTRL命令146と、RCU装置110を制御するためのRCU_CTRL命令148と、MEM装置108を制御するためのMEM_CTRL命令150とを含む。ECU_CTRL、MUL_CTRL、およびALU_CTRL命令は可変長で、ここでは例示を目的として、それぞれ長さ32ビットとして示される。RCU_CTRLおよびMEM_CTRL命令も可変長で、ここでは例示を目的として、それぞれ長さ16ビットとして示される。かかる各命令の長さは、典型的に、処理装置によって異なる。本例で、完全なVLIW140の長さは128ビットである。いずれのVLIWの長さも、使用される処理装置の数と、VLIWが何らかの方法にて圧縮されたか否かに依存する。
【0062】
次に図6を参照すると、メディアプロセッサ32および各MPE66〜72によってサポートされる種々のデータタイプを図示する図が示されている。最も単純なデータタイプは、32ビットスカラ値であることが好ましいスカラタイプ160である。スカラタイプ160は、すべての他のデータタイプがそれに基づく、基本的なデータタイプを形成する
。例えば、ベクトルデータタイプ162は4個の32ビットスカラデータタイプ164,166,168,170から成り、ベクトルの全長は128ビットである。同様にスモールベクトル172も特定のタイプの命令に定義され、4個の32ビットスカラデータタイプ174,176,178,180からなるという点でベクトルと似ている。しかし、スモールベクトルのデータ部は64ビットでしかなく、したがって、陰影領域で示されるように、各スカラレジスタ174〜180の下半分が0に設定される。同様に、ピクセルデータタイプ182も4個のレジスタ184,186,188,190からなる。ピクセルは、各一次色(例えば、赤緑青)に対して16ビット値として一般に定義される。1ピクセルに対し、スカラレジスタ184,186,188は0に設定される。さらに、3個の16ビット値のみが典型的に必要であるために、最後のスカラレジスタ190のすべてのビットが0に設定されるか、またはピクセルのZ(深度)などの他の値を保持するために使用される。ピクセル全体を1個のデータタイプに格納にでき、1個のクロックサイクルで操作または処理できるので、ピクセルデータタイプ182の使用により、好ましくは、グラフィックアプリケーションのためのプロセッサ32、特にMPEの処理速度が増大される。最後のデータタイプはハーフベクトル192で、2個の32ビットスカラデータタイプ194,196から成り、全長を64ビットにすることが好ましい。
【0063】
すべてのデータタイプ160,162,172,182は、単一のレジスタとして、あるいはグループレジスタの組み合わせとしてレジスタファイル116内に格納され得る。レジスタファイル116内のレジスタの様々な使用が、以下の表1に記載される。
【0064】
【表4】


【0065】
表1に示されるように、各メディア処理要素(MPE)66〜72(図3)は、スカラデータタイプを格納することが好ましい32個の32ビット物理レジスタからなるレジスタファイル116を含むことが好ましい。前述のその他のデータタイプのいずれかを格納
するために、32ビット長さのレジスタを論理的に組み合わせる。かくして、32個の物理レジスタしかないが、かかる32個の物理レジスタが複数個のデータタイプを表すために用いられる。例えば、R0〜R3は、第1ピクセルを格納するために組み合わされ、R4〜R7は第2ピクセルを格納し、R8はスカラを格納し、R12〜R15は特定のクロックサイクル用にベクトルを格納する。次に、次のクロックサイクルで、かかる割当は変更され得る。この物理レジスタのエイリアシングまたは論理的結合は、様々なデータデータタイプをサポートする能力を保持するとともに、レジスタファイルの全体サイズを減少する。例えば、128ビットを要するベクトル値を格納するために、4個の32ビット物理レジスタが論理的に組み合わされる。かくして、第1定義論理ベクトルレジスタV0は物理レジスタR0〜R3に格納される。各ベクトルデータは4個の物理レジスタを必要とするために、1度に合計8個のベクトルレジスタが利用できる。同様に、前述のように、スモールベクトルとピクセルデータタイプも4個の物理レジスタに格納される。
【0066】
MPE内の処理装置による処理のためにデータを一時的に格納するデータレジスタに加え、幾つかのアドレスおよびシステムレジスタも存在する。例えば、RX、RY、RUおよびRVレジスタは、以下により詳細に説明するように、バイリニア・アドレッシングに利用されることが好ましい。レジスタRC0とRC1は、処理装置106〜114(図4)のいずれかにより使用される汎用ダウンカウンタである。SPレジスタはスタックポインタで、メモリ内のシステムプログラムスタックの先頭へのポインティングに使用される。RZレジスタは、プログラム内の制御が、サブルーチンリターン制御後に、レジスタRZ内に保存されたアドレスに戻されるように、呼び出しサブルーチン命令後のプログラム実行中にアドレスを格納するために使用される。PCレジスタは、プログラム実行を制御し、追跡するために使用されるプログラムカウンタである。当業では周知であるように、複数個の条件コードを格納するために使用されるCCレジスタもある。
【0067】
バイリニア・アドレッシングスキームは、例えば、ピクセル操作命令の速度を増大するためにピクセルをロードし、格納するために用いられる。例えば、ピクセルロード命令は以下のバイリニア・アドレッシング形式、すなわちld_p(xy),Pを有し得る。この特定の命令は、RXとRYレジスタを一緒に使用するが、命令中で(uv)と称されるRUおよびRVレジスタも使用できる。各レジスタ対RX,RYおよびRU,RVは、レジスタによって参照されるデータ構造を定義する入出力レジスタの関連セットを有してもよい。例えば、64ピクセルマップ内のいずれかのピクセルを、単一のバイリニア・アドレッシング命令を用いてロードまたは格納できるように、以下に説明されるようなピクセルマップデータタイプを入出力レジスタによって定義できる。かくして、単一命令が任意のピクセルをロードできるので、ピクセルの格納およびロード速度は低減される。
【0068】
各メディア処理要素(MPE)からメインDRAMへのピクセルデータタイプ転送のフレキシビリティと速度をさらに増加するためには、複数の異なるピクセルデータタイプがある。各MPE内部のピクセルデータタイプの幾つかは、メディア処理システム30のDRAM内に格納されたデータタイプを変換することで生成される。かかる変換は、以下に説明されるように、MPEが内部フォーマットでピクセルデータをより高速で処理できるために、実行される。外部DRAMピクセルデータフォーマットの幾つかは、MPEGフォーマットなどの工業規格フォーマットであり、MPEがかかるフォーマットを操作することは困難である。外部DRAMピクセルデータタイプから内部MPEピクセルデータタイプへの変換と、その反対の変換は、例えば図3の装置82、装置84または装置86などのDMAシステムによって実行される。
【0069】
変換と、内部通常およびピクセルデータタイプを理解しやすくするために、表2にピクセルデータタイプを示す。
【0070】
【表5】


【0071】
示されるように、ピクセルマップタイプ0は、1ピクセル当たり16ビットである。MPEGピクセルは、輝度の線形解像度の半分で彩度(chroma)がサンプル抽出され、したがってこの種のMPEメモリ表象は、128ビットメモリ内に8個の8ビットの輝度(Y)値と4個の8ビット彩度(CR、CB)対(すなわち8ピクセル)を格納する。
【0072】
示されるように、ピクセルマップタイプ1は、1ピクセル当たり4ビットである。4ビットの値は、任意のカラー参照テーブル(CLUT)への索引を表すので、その値はピクセルの物理的外見と物理的関係を有さない。かかる4ビットピクセルマップは、前述のように、カラー参照テーブル内での索引付け後、ベクトルレジスタ内にロードされる。
【0073】
ピクセルマップタイプ2は、1ピクセル当たり16ビットで、ビットの値は、いずれも5ビットである第1クロミナンス要素Cbと、第2クロミナンス要素Crと、6ビットである輝度要素Yとしてピクセルの色を表す。示されるように、タイプ2ピクセルマップは16ビットで、DRAMに格納され、画面上に表示され、かつ/またはMPEレジスタ内
にロードされるが、このフォーマットでMPEによって、レジスタからメモリ内に格納はできない。DMAシステムは、メモリからロードする際に、ピクセルマップタイプ4からピクセルマップタイプ2に変換する。同様に、DMAシステムは、メモリ内に格納し戻す前に、ピクセルマップタイプ2をピクセルマップタイプ4に変換できる。
【0074】
示されるように、ピクセルマップタイプ3は、1ピクセルあたり8ビットである。8ビットの値は任意のカラー参照テーブル(CLUT)への索引を表しているので、その値はピクセルの物理的外見と物理的関係を有さない。かかる8ビットピクセルマップは、前述のように、カラー参照テーブル内での索引付けの後、ベクトルレジスタ内にロードされる。
【0075】
ピクセルマップタイプ4は、1ピクセル当たり32ビットである。該ピクセルマップの24ビットは、ピクセルの実際の色を表す。示されるように、これらのタイプのピクセルマップは、DRAMからのピクセルのロード、DRAMまたはMPEメモリ内へのピクセルの格納に使用される。この種のピクセルマップはベクトルレジスタ内に格納される。タイプ4ピクセルマップは、色も表す1ピクセル当たり32ビットを有する。かかる32ビットは、いずれも8ビットである第1クロミナンス要素Cbと、第2クロミナンス要素Crと、8ビットである輝度要素Yに分割される。最後の8ビットは予備ビットで、他のピクセル属性に用いられる。
【0076】
タイプ5ピクセルマップは、1ピクセル当たり16ビットで、16ビット制御値を有する。16ビット制御値は、Zバッファ深度に用いられる。1ピクセル当たりの16ビットは、ピクセルマップタイプ4の場合と同じ様態でCbと、Crと、Yとに割り当てられる。
【0077】
タイプ6ピクセルマップは、1ピクセル当たり32ビットで、関連32ビット制御ワードを有する。制御ワードは、Zバッファ深さに用いられる。1ピクセル当たりの16ビットは、タイプ4ピクセルマップと同じ様に配される。
【0078】
ここで、各MPE66〜72内の処理装置106〜114の詳細なアーキテクチャを、より詳細に説明する。
図7は、本発明による論理演算装置(ALU)112の一実施例の詳細図であり、ピクセルデータに最適化されることが好ましい。以下に述べるように、ALU112の入出力は種々の異なるソースとやり取りされるために、図示されるようにALU112はフレキシブルである。さらに、図8を参照して以下に説明するように、ALU112は、追加加算器・減算器を備えるので、ALU112は、単一のクロックサイクルでピクセル全体に演算および論理処理を実行できる。
【0079】
ALU112は、ALU112の複数のソース入力の1つからデータを選択するように構成された、マルチプレクサなどの複数個のスイッチ210,212,214を含むことが好ましい。例えば、スイッチ210は、本発明によると、レジスタのいずれかの1個に格納される32ビットデータタイプであるSrcAから、あるいはALU命令に格納される即値データ(ImmB)からデータを選択できる。同様に、第2スイッチ212は、SrcAから、またはALU命令に格納される即値(ImmA)からデータを選択できる。ImmA即値データは、スイッチに入る前に符号拡張器216によって符号拡張され得る。ImmAデータ、SrcBデータ、SrcDデータ、またはSrcBデータの最上位ビットは第3スイッチ214によって選択され得る。SrcBデータの最上位ビットは、最上位ビット(MSB)装置217によって決定され得る。
【0080】
第1スイッチ210および第2スイッチ212の出力は、シフタ218によっていずれ
の方向にも変更または回転され得る。次に、シフタの出力が算術演算装置(AOU)220に送られる。AOU220の他の入力は、第3スイッチの出力である。かくして、AOU220に入力するデータは、複数個の異なるソースから選択され、複数の異なる動作が、AOUに入力する前に、データに実行される。このフレキシビリティにより、ALU112は種々の異なるデータタイプを処理可能となる。AOU220は、加算、減算、論理積、論理和、および排他的論理和を実行し得る。AOU220の出力は、複数個の宛先に送られる32ビット値である。ALU112は、単一のクロックサイクルで単一のピクセルを処理するためにも用いられ、図8を参照して以下に説明する。
【0081】
図8を参照すると、本発明にしたがって、ピクセルを処理するように構成されたALU112の図が示されている。図示されるように、ALU112はAOU220と、付加的な加算器/減算器装置222を含む。付加的な加算器/減算器222は、AOU220と同じ演算を実行する。該演算において、要素P,P,P,Pを備えた第1ピクセルと、要素S,S,S,Sを備えた第2ピクセルが例えば加算される。要素Pは要素Sに加算されることが好ましく、要素Pは、32ビット値を加算するAOU220によって要素Sに加算されることが好ましい。かかる16ビットピクセル要素を加算するために、AOU220の前進チェーンをビット15とビット16との間で切断する。各ピクセル追加要素P,P,S,Sを、他の要素が加算されると同時に、付加的な加算器/減算器222によって加算する。かくして、本発明によると、ALU112は、3次元画像処理などのピクセル集中アプリケーションの速度を増加するために、1回のクロックサイクルで1個のピクセルを別のピクセルに演算的、論理的に組み合わせることができる。
【0082】
図9は、本発明の一実施例によるMUL装置114のアーキテクチャを示す図である。MUL装置114は、以下に説明するように、クロックサイクルごとにピクセルを高速処理するように構成される。図示されるように、MUL114装置は、2個の32ビット数を乗算して64ビットの結果を生成する32ビット×32ビットマルチプライヤ240からなり得る。さらに、MUL装置114は、レジスタに書き戻すために、積のいずれかの32ビットの部分を選択するシフタ242からなる。MUL装置114は、本発明によると、変数の高指数を迅速かつ容易に計算し得る。例えば、xを計算する場合、xをxで乗算してxに等しい出力を生成する。次に、xにふたたびxを乗算してxに等しい出力を生成するために、x出力はMUL入力に戻される。MUL装置114は、図10を参照して説明されるように、ピクセルデータタイプも迅速に処理され得る。
【0083】
図10は、本発明に従って、MUL装置214がどのようにピクセルまたはスモールベクトルデータタイプを処理するかを示す図である。32ビット×32ビットMUL214は、MUL装置114が4個の16ビット×16ビット乗算器246,248,250,252に分解され得るように構成される。さらに、かかる16ビット×16ビット乗算器は個々にアドレス指定可能である。したがって、要素P,P,P,Pを備えた第1ピクセルまたはスモールベクトルを、要素S,S,S,Sを備えた第2ピクセルまたはスモールベクトルで乗算するために、要素PとSは、第1乗算器246によって乗算されることが好ましい。同時に、要素PとSは、第2乗算器248によって乗算され、要素PとSは、第3乗算器250によって乗算され、要素PとSは、第4乗算器252によって乗算される。かくして、ピクセルまたはスモールベクトルの全体が、第2ピクセルまたはスモールベクトルの全体により、MUL装置114を用いて1回のクロックサイクル内で乗算され、したがって、ピクセルを使用するグラフィックアプリケーション用のメディア処理システムの処理速度を増加する。さらに、MUL装置114は、2個の32ビット値を乗算するように構成されるとともに、2個のピクセルまたはスモールベクトルを一緒に乗算するように構成され得る。
【0084】
さらに、本メディア処理システムは、ピクセルが処理される速度をさらに増加するために幾つかの専用ピクセル命令も有することができる。例えば、ピクセルデータタイプを使用できるロードピクセル、格納ピクセル、乗算ピクセル、加算ピクセル命令がある。さらに、前述のように、バイリニア・アドレッシングスキームも、複数個のピクセルから構成される画像が処理される速度を増加できる。
【0085】
要するに、本メディア処理システムのアーキテクチャは、画像などのピクセルベースデータを高速で処理できるようにするために、ピクセル処理の大幅な強化を提供する。しかし、本メディア処理システムおよびMPEは汎用であるために、該メディア処理システムは、多くの他の速度および処理能力に集約的な演算にも使用され得る。
【0086】
以上は、本発明の特定の実施例を参照してきたが、当業者であれば、本発明の原則と精神から逸脱することなく、本実施態様への変更が行なわれ得ることは十分理解され、本発明の範囲は特許請求の範囲に定義される。
【図面の簡単な説明】
【0087】
【図1】メディア処理システムのブロック図。
【図2】本発明によるメディアプロセッサを含むメディア処理システムを示すブロック図。
【図3】図2のメディアプロセッサのブロック図。
【図4】図3に図示される処理要素の1つのより詳細なブロック図。
【図5】処理要素の一部である種々の処理装置を制御できるベリー・ロング・インストラクション・ワードの図。
【図6】本発明によるメディアプロセッサにより利用される種々のデータタイプの図。
【図7】本発明による論理演算装置(ALU)のより詳細なブロック図。
【図8】本発明により組み合わされる第1ピクセルと第2ピクセルの図。
【図9】本発明による乗算器(MUL)のより詳細なブロック図。
【図10】本発明によりたがいに乗算される2個のピクセルのブロック図。
【出願人】 【識別番号】502281013
【氏名又は名称】ジェネシス マイクロチップ コーポレイション
【氏名又は名称原語表記】GENESIS MICROCHIP CORPORATION
【出願日】 平成19年7月9日(2007.7.9)
【代理人】 【識別番号】100068755
【弁理士】
【氏名又は名称】恩田 博宣

【識別番号】100105957
【弁理士】
【氏名又は名称】恩田 誠


【公開番号】 特開2008−17493(P2008−17493A)
【公開日】 平成20年1月24日(2008.1.24)
【出願番号】 特願2007−179901(P2007−179901)