JP4258469B2 - 表示コントローラ - Google Patents

Description

本発明は、表示コントローラに関する。

動画、静止画、音データなどのマルチメディア情報に対する符号化方式として、ＭＰＥＧ−４（Moving Picture Experts Group Phase 4）が規格化されている。近年の携帯電話機などの携帯型電子機器は、このＭＰＥＧ−４の規格に準拠したエンコード、デコード機能を有している。このような機能を持つことで、カメラ（ＣＣＤ）で撮った動画データをエンコードして他の携帯電話（サーバー）に送信したり、アンテナを介して他の携帯電話（サーバー）から受信した動画データをデコードして表示（ＬＣＤ）パネルに表示したりすることが可能になる。

さて、ＭＰＥＧ−４のエンコード、デコードなどのマルチメディア処理を行う場合、一連の処理の全てをハードウェア処理回路（ＡＳＩＣ）により実現する第１の手法が考えられる。

しかしながらこの第１の手法では、ハードウェア処理回路が大規模化し、携帯型電子機器の小型化、低消費電力化の要請に応えることができない。

一方、携帯電話機などの携帯型電子機器では、機器全体を制御したりベースバンドエンジン（通信処理）を実現するためのホストＣＰＵ（Central Processing Unit）が組み込
まれている。従って、このホストＣＰＵを用いたソフトウェア処理によりＭＰＥＧ−４などのマルチメディア処理を実現する第２の手法も考えられる。

しかしながら、この第２の手法では、ホストＣＰＵの処理負荷が増加してしまい、ホストＣＰＵが他の処理に費やす時間に制約が生じ、ホストＣＰＵが組み込まれた電子機器のパフォーマンスを低下させてしまう。またホストＣＰＵの処理時間の増加を招き、消費電力が大きくなり、バッテリの消耗抑制のための低消費電力化への要請に応えることができない。

また、ホストＣＰＵとＤＳＰ（Digital Signal Processor）によりマルチメディア処理を実現する第３の手法も考えられる。具体的には、ＤＳＰの内蔵メモリ（フラッシュＲＯＭなどの不揮発性メモリ）に、動画（ＭＰＥＧ）、静止画（ＪＰＥＧ）、音（オーディオ、音声）データのエンコード、デコードを実行するための全てのマルチメディア処理用プログラム群を記憶しておく。そしてホストＣＰＵが、起動コマンドを送信することで、起動が指示されたマルチメディア処理用プログラムをＤＳＰが実行する。

しかしながら、この第３の手法では、複雑な一連のマルチメディア処理の全てをＤＳＰが実行する必要がある。従って、コーデックの種類が増えたり、ストリームデータの多重化・分離化などの付加的な処理が増えて行くにつれて、ＤＳＰにマルチメディア処理を特化させて実行させるというアーキテクチャの意味合いが薄れ、結果的に、ＤＳＰやシステムのパフォーマンスが低下する。また、年々複雑化するマルチメディア処理に対応するために、ＤＳＰのクロック周波数を上昇させる必要が生じ、消費電力の増加や発熱の問題を招く。また、この第３の手法では、一連のマルチメディア処理用プログラム群の全てをＤＳＰの内蔵メモリ（フラッシュＲＯＭ）に記憶する必要があり、メモリの容量が増加し、消費電力の増加、製品の高コスト化の問題を招く。
MPEG-4 Visual Part(勧告書ISO/IEC 14496-2:1999(E) Annex L)

本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、マルチメディア処理を効率良く実行できる表示コントローラを提供することにある。

本発明は、動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うための表示コントローラであって、ホストプロセッサとのインターフェース処理を行うホストインターフェースと、ホストメモリに記憶されるマルチメディア処理用のプログラム群の中から、前記ホストプロセッサがマルチメディア処理用プログラムをリードして送信してきた場合に、送信された前記マルチメディア処理用プログラムがロードされるメモリと、ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含む表示コントローラに関係する。

本発明によれば、ホストメモリに記憶されるマルチメディア処理用プログラム群の中から選択されたマルチメディア処理用プログラムが、表示コントローラのメモリにロードされる。そして、内蔵プロセッサが、このロードされたマルチメディア処理用プログラムに基づいてマルチメディア処理のソフトウェア処理部分を実行し、第１のハードウェアアクセラレータが、マルチメディア処理のハードウェア処理部分を実行する。このようにすれば、マルチメディア処理を効率良く実行できる。また、全てのマルチメディア処理用プログラムを表示コントローラのメモリにロードしなくても済むようになり、メモリの記憶容量を節約できる。また、マルチメディア処理が複雑化した場合にも、これに柔軟に対応できるようになる。

また本発明では、前記内蔵プロセッサは、前記ホストプロセッサからリセット解除を指示された場合に、リセット状態が解除され、前記リセット状態の解除後に前記マルチメディア処理用プログラムを実行するようにしてもよい。

このようにすれば、必要な時にだけ内蔵プロセッサのリセット状態を解除してマルチメディア処理用プログラムを実行させることが可能となり、低消費電力化を実現できる。

また本発明では、前記内蔵プロセッサは、前記リセット状態の解除後に、前記ホストプロセッサからのコマンドの受信をウェイトするコマンドウェイト状態に移行し、前記コマンドウェイト状態において前記マルチメディア処理用プログラムの実行開始を前記ホストプロセッサから指示された場合に、前記マルチメディア処理用プログラムを実行するようにしてもよい。

このようにすれば、ホストプロセッサの制御の元で、一連のマルチメディア処理を効率良く実行できる。

また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、前記内蔵プロセッサは、ソフトウェア処理部分である可変長符号への符号化処理を行うようにしてもよい。

このようにすれば、処理負荷が重く、変更の可能性が低い離散コサイン変換、量子化等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルチメディア処理のエンコード処理を更に効率良く実行できる。

また本発明では、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合にはスキャニング処理を行い、前記内蔵プロセッサは、フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うようにしてもよい。

このようにすれば、符号化の種類に応じた最適な役割分担でマルチメディア処理のエンコード処理を実行できる。

また本発明では、前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、前記第１のハードウェアアクセラレータは、前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記内蔵プロセッサは、前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むようにしてもよい。

このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のエンコード処理をスムーズに効率良く実行できる。

また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、前記第１のハードウェアアクセラレータは、ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うようにしてもよい。

このようにすれば、処理負荷が重く、変更の可能性が低い逆量子化、逆離散コサイン変換等のハードウェア処理部分については、第１のハードウェアアクセラレータにより実行される。一方、処理負荷が比較的低く、フレキシブルなプログラミングが要求されるソフトウェア処理部分については、内蔵プロセッサにより実行される。このように役割分担することで、マルチメディア処理のデコード処理を更に効率良く実行できる。

また本発明では、前記内蔵プロセッサは、フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、前記第１のハードウェアアクセラレータは、フレーム間符号化の場合には逆スキャニング処理を行うようにしてもよい。

このようにすれば、符号化の種類に応じた最適な役割分担でマルチメディア処理のデコード処理を実行できる。

また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、前記第１のハードウェアアクセラレータは、前記ホストプロセッサからデコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むようにしてもよい。

このようにＦＩＦＯバッファを利用すれば、ホストプロセッサの制御の元で、マルチメディア処理のデコード処理をスムーズに効率良く実行できる。

また本発明では、前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、前記内蔵プロセッサは、デコード処理にエラーが発生した場合には、エラーの発生を前記ホストプロセッサに通知し、デコード処理のソフトウェア処理部分を前記ホストプロセッサに実行させるようにしてもよい。

このようにすれば、デコードエラーが発生した場合にも、そのエラーを回復して、その後のハードウェア処理部分を適正に実行することが可能になる。

また本発明では、前記内蔵プロセッサに制御され、前記マルチメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むようにしてもよい。

以下、本発明の実施形態について詳細に説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが本発明の解決手段として必須であるとは限らない。

１．構成
図１に、本実施形態の表示コントローラを含むマルチメディア処理システムと、このマルチメディア処理システムを含む電子機器の構成例を示す。なおマルチメディア処理システム、電子機器、表示コントローラの構成は図１に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。

図１は、マルチメディア処理システム２０を含む電子機器が携帯電話機である場合の例である。図１の携帯電話機（広義には電子機器）は、アンテナ１０、変復調器１２、操作部１４、表示ドライバ１６、表示パネル１７、カメラ１８、マルチメディア処理システム２０を含む。マルチメディア処理システム２０は、ホストＣＰＵ３０（広義にはホストプロセッサ）、ホストメモリ４０、表示コントローラ５０を含む。

アンテナ１０を介して他の機器（携帯電話機、サーバー）から受信したデータ（動画データ、ＭＰＥＧストリーム）は、変復調器１２で復調されてホストＣＰＵ３０に供給される。一方、ホストＣＰＵ３０からのデータは、変復調器１２で変調されて、アンテナ１０を介して他の機器に送信される。

ユーザからの操作情報は、操作部１４（操作ボタン）を介して入力される。この操作情報に基づいて、ホストＣＰＵ３０の制御の元で、データの通信処理、データのエンコード・デコード処理、表示パネル１７への画像の表示処理、カメラ１８（カメラモジュール）の撮像処理などが行われる。

表示パネル１７は表示ドライバ１６によって駆動される。表示パネル１７は、複数の走査線、複数のデータ線、複数の画素を含む。表示ドライバ１７は、走査線を駆動（選択）する走査ドライバの機能と、画像データ（表示データ）に対応した電圧をデータ線に供給するデータドライバの機能を有する。表示コントローラ５０は表示ドライバ１６に接続され、表示ドライバ１６に画像データを供給する。なお表示パネル１７としては液晶表示パネル（ＬＣＤ）を採用できるが、これに限定されず、エレクトロルミネッセンス表示パネルやプラズマ表示パネルなどであってもよい。

カメラ１８はＣＣＤ（Charge-Coupled Device）を含む。そしてＣＣＤで撮像した画像のデータを、ＹＵＶフォーマットで表示コントローラ５０に供給する。

ホストＣＰＵ３０は、ホストメモリ４０にアクセスしてホスト処理を行う。具体的には、表示コントローラ５０を制御する処理や、機器全体を制御する処理や、ベースバンドエンジン（通信処理エンジン）としての処理などを行う。ホストメモリ４０には種々のプログラムが記憶される。ホストＣＰＵ３０は、ホストメモリ４０に記憶されたプログラムにより動作してソフトウェア処理を実現する。このホストメモリ４０は、フラッシュＲＯＭなどの不揮発性メモリやＲＡＭなどにより実現できる。

表示コントローラ５０は、表示ドライバ１６を制御する。この表示コントローラ５０は、ホストインターフェース６０、内蔵ＣＰＵ７０（広義には内蔵プロセッサ）、ハードウェアアクセラレータ８０、メモリ９０を含む。なお本明細書中及び図面では、「インターフェース」、「ハードウェア」、「ソフトウェア」を、適宜、「Ｉ／Ｆ」、「Ｈ／Ｗ」、「Ｓ／Ｗ」と略称する。

表示コントローラ５０（画像コントローラ）は、カメラ１８からの画像データ（動画、静止画データ）をエンコードし、エンコード後の画像データをホストＣＰＵ３０に送信する。ホストＣＰＵ３０は、エンコード後の画像データをファイルとして保存したり、変復調器１２、アンテナ１０を介して他の機器に送信する。

また表示コントローラ５０は、ホストＣＰＵ３０から受信した画像データ（符号化データ、圧縮データ）をデコードし、デコード後の画像データを表示ドライバ１６に供給して表示パネル１７に表示させる。また表示コントローラ５０は、カメラ１８により撮像された画像データを受け、表示ドライバ１６に供給して表示パネル１７に表示させることもできる。

ホストメモリ４０はマルチメディア処理用プログラム群を記憶する。ここでマルチメディア処理は、動画データ、静止画データ又は音（オーディオ、音声）データについてのエンコード（圧縮）又はデコード（伸長）処理である。またマルチメディア処理用プログラムは、動画（狭義にはＭＰＥＧ）エンコード用プログラム、動画デコード用プログラム、静止画（狭義にはＪＰＥＧ）エンコード用プログラム、静止画デコード用プログラム、音エンコード用プログラム、或いは音デコード用プログラムなどである。なお、エンコードプログラムとデコードプログラムを１つのセットにしたコーデック用プログラムをマルチメディア処理用プログラムとしてホストメモリ４０に記憶してもよい。

本実施形態ではホストＣＰＵ３０（広義にはホストプロセッサ、ホスト）が、ホストメモリ４０に記憶されるマルチメディア処理用のプログラム群の中から選択したマルチメディア処理用プログラムをリードして、表示コントローラ５０に送信する。そして送信されたマルチメディア処理用プログラムは、表示コントローラ５０のメモリ９０にロードされる。

具体的にはホストＣＰＵ３０は、動画のエンコードが必要である場合には、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばカメラ１８で撮影された動画データ（元データ）を、ファイルとして保存したり、アンテナ１０を介して他の機器に送信する場合には、動画（ＭＰＥＧ）のエンコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。そしてエンコード対象となる動画データは、例えばカメラ１８から表示コントローラ５０に入力される。

またホストＣＰＵ３０は、動画のデコードが必要である場合には、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。例えばアンテナ１０を介して他の機器から受信した動画データ（符号化データ、圧縮データ）や、ファイルとして保存した動画データ（符号化データ、圧縮データ）を、表示パネル１７に表示する場合には、ホストＣＰＵ３０は、動画（ＭＰＥＧ）のデコード処理用プログラムをホストメモリ４０からリードして、表示コントローラ５０に送信する。またホストＣＰＵ３０は、デコード対象となる動画データ（元データ）を表示コントローラ５０に送信する。

このように本実施形態では、マルチメディア処理用プログラム群の中から、必要なマルチメディア処理用プログラムがホストＣＰＵ３０により選択されて、表示コントローラ５０のメモリ９０にロードされる。従って、メモリ９０（ＲＡＭ）の使用記憶容量を節約できるため、メモリ９０を小規模化でき、表示コントローラ５０の低コスト化を図れる。また、１度にロードするデータ量を少なくできるため、起動時や、ハングアップした場合の再起動時に、長時間を要してしまうという問題を防止できる。

表示コントローラ５０が含むホストＩ／Ｆ６０は、ホストＣＰＵ３０とのインターフェース処理を行う。具体的にはホストＩ／Ｆ６０は、ホストＣＰＵ３０との間でコマンド、データ、ステータスの送信や受信処理（ハンドシェーク処理）を行う。また表示コントローラ５０からホストＣＰＵ３０に対する割り込み信号の生成などを行う。なお、ホストＩ／Ｆ６０にデータのＤＭＡ（Direct Memory Access）転送機能を持たせてもよい。

表示コントローラ５０が含む内蔵ＣＰＵ７０（広義には内蔵プロセッサ）は、表示コントローラ５０の全体制御や各部の制御を行う。そして本実施形態では内蔵ＣＰＵ７０（ＲＩＳＣプロセッサ）が、メモリ９０にロードされたマルチメディア処理用プログラムに基づいて、マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する。このソフトウェア処理部分は、マルチメディア処理用プログラムを読み込んだ内蔵ＣＰＵ７０によりその処理が実行される部分である。

より具体的には、ホストＣＰＵ３０は、内蔵ＣＰＵ７０にリセットを指示することで（リセットコマンドを送信することで）、内蔵ＣＰＵ７０をリセット状態に設定する。そしてホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後に、リセット解除を指示して（リセット解除コマンドを送信して）、内蔵ＣＰＵ７０のリセット状態を解除する。そしてホストＣＰＵ３０は、内蔵ＣＰＵ７０のリセット状態の解除後に、マルチメディア処理用プログラムの実行開始を内蔵ＣＰＵ７０に指示する（実行開始コマンドを送信する）。内蔵ＣＰＵ７０は、ホストＣＰＵ３０からリセット解除を指示されると、そのリセット状態が解除される。そしてリセット状態の解除後に、メモリ９０にロードされたマルチメディア処理用プログラムを実行する。

なお、内蔵ＣＰＵ７０は、リセット状態の解除後に、ホストＣＰＵ３０からのコマンド（マルチメディア処理開始コマンド）の受信をウェイトするコマンドウェイト状態に移行する。そして、このコマンドウェイト状態において、マルチメディア処理用プログラムの実行開始をホストＣＰＵ３０から指示された場合に（マルチメディア処理開始コマンドを受信した場合に）、内蔵ＣＰＵ７０はマルチメディア処理用プログラムを実行する。

またホストＣＰＵ３０は、マルチメディア処理用プログラムを送信してメモリ９０にロードした後、内蔵ＣＰＵ７０のリセット状態が解除される前に、マルチメディア処理用プログラムのロード領域（図２の９１）のプロテクト（ライトプロテクト）処理を行う。

更にホストＣＰＵ３０は、階層構造を有しマルチメディア処理の対象となるストリームデータ（ＭＰＥＧストリーム）についての多重化処理（ビデオ、オーディオの多重化、ビデオ、オーディオのパケット分割）、分離化処理（ビデオ、オーディオの分離）、上位レイヤーのヘッダ解析処理(ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）の少なくとも１つを含む前処理（pre processing）を行う。そして、前処理により得られた情報（データ、パラメータ）を情報領域（図２の９９）に設定して、内蔵ＣＰＵ７０に知らせる。一方、内蔵ＣＰＵ７０は、ストリームデータ（ＭＰＥＧストリーム）の下位レイヤーのヘッダ解析処理（ＶＯＰヘッダの解析）を行う。また情報領域に設定された情報（データ、パラメータ）に基づいて、マルチメディア処理のソフトウェア処理部分を実行する。

表示コントローラ５０が含むＨ／Ｗアクセラレータ８０（第１のＨ／Ｗアクセラレータ）は、マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する回路（ハードウェア処理回路）である。このハードウェア処理部分は、プロセッサではない専用の回路によりその処理が実行される部分である。

表示コントローラ５０が含むメモリ９０は、プログラムのロード領域やデータバッファ領域や内蔵ＣＰＵ７０のワーク領域として機能する。具体的には、ホストＣＰＵ３０によりホストメモリ４０からリードされたマルチメディア処理用プログラムが、メモリ９０のプログラムロード領域にロードされる。また、エンコードデータやデコードデータが、メモリ９０のバッファ領域（ＦＩＦＯ領域）によりバッファリングされる。また内蔵ＣＰＵ７０は、メモリ９０のワーク領域にテーブル等を展開して処理を行う。このメモリ９０はＲＡＭ（ＳＲＡＭ、ＤＲＡＭ）などにより実現できる。

図２に表示コントローラの詳細な構成例を示す。なお表示コントローラの構成は図２に限定されず、同図の構成要素の一部を省略したり他の構成要素を加えてもよい。

図２に示すようにメモリ９０には、プログラムロード領域９１、ＦＩＦＯバッファ９２（ＭＰＥＧ４ＦＩＦＯ）、デコードデータバッファ９３（ＭＰＥＧ４デコードバッファ）、エンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）、表示バッファ９５、ホスト用バッファ９６（ハフマンＦＩＦＯ）、ワーク領域９７、テーブルアシスト用領域９８、情報領域９９が確保（マッピング）されている。なお、これらの領域やバッファは、物理的に同一のメモリで実現してもよいし、物理的に異なるメモリで実現してもよい。

メモリコントローラ１００は、メモリ９０のアクセス（リード、ライトアクセス）制御を行う。即ちメモリコントローラ１００は、ホストＩ／Ｆ６０、内蔵ＣＰＵ７０、Ｈ／Ｗアクセラレータ８０、ドライバＩ／Ｆ１１０、カメラＩ／Ｆ１２０からのアクセスを調停する。そしてメモリ９０のリードアドレスやライトアドレスを発生して、ライトポインタやリードポインタを制御し、メモリ９０からデータやプログラムをリードしたり、メモリ９０にデータやプログラムをライトする。例えばプログラムロード領域９１へのマルチメディア処理用プログラムのロードは、このメモリコントローラ１００により実現できる。

ドライバＩ／Ｆ１１０は、表示ドライバ１６とのインターフェース処理を行う。具体的には、表示ドライバ１６に画像データ（動画、静止画データ）を送信する処理や、表示ドライバ１６の各種制御信号を生成する処理などを行う。

カメラＩ／Ｆ１２０は、カメラ１８との間のインターフェース処理を行う。例えばカメラ１８は、撮像により得られた画像データを例えばＹＵＣフォーマットで出力すると共に、１フレームの区切りを指定する同期信号（ＶＳＹＮＣ等）を出力する。カメラＩ／Ｆ１２０は、この同期信号に基づいて、カメラ１８からの画像データを取り込む。

なお図２では、内蔵ＣＰＵ７０に対してＨ／Ｗアクセラレータ７２（第２のアクセラレータ）が接続されている。このＨ／Ｗアクセラレータ７２は、内蔵ＣＰＵ７０に制御され、マルチメディア処理のソフトウェア処理部分の一部をアシストする回路（ハードウェア処理回路）である。具体的にはＨ／Ｗアクセラレータ７２は、可変長符号（ＶＬＣ：Variable Length Code）への符号化処理や可変長符号の復号化処理の一部について内蔵ＣＰＵ７０をアシストする。例えばＨ／Ｗアクセラレータ７２は、可変長符号処理に必要なテーブルのインデックス番号の生成処理などを、内蔵ＣＰＵ７０に代わって実行する。この場合にＨ／Ｗアクセラレータ７２は、メモリ９０のテーブルアシスト用領域９８をワーク領域として使用する。

２．エンコード、デコード処理
次に本実施形態のＭＰＥＧ−４のエンコード、デコード処理を図３、図４を用いて説明する。

図３に示すエンコード処理では、入力された１ＶＯＰ（Video Object Plane）分の画像データ（１フレーム分の画像データ）が、マクロブロック（基本処理単位）に分割される。１つのマクロブロックは６つのブロックから構成される。そして各ブロックに対して離散コサイン変換（ＤＣＴ：Discrete Cosine Transform）の処理が実行される（ステップＳ１）。離散コサイン変換は、８画素×８画素の１ブロック単位で行われ、１ブロック毎にＤＣＴ係数を求めるものである。離散コサイン変換後のＤＣＴ係数は、１ブロック内の画像の濃淡変化を、全体の明るさ（ＤＣ成分）と空間周波数（ＡＣ成分）とで表わしたものになる。図５（Ａ）に、８画素×８画素の１ブロック内のＤＣＴ係数の一例を示す。図５（Ａ）の左上隅のＤＣＴ係数がＤＣ成分を示し、それ以外のＤＣＴ係数がＡＣ成分を示す。なお、ＡＣ成分のうち、高周波成分を省略しても画像認識への影響が少ない。

次に、ＤＣＴ係数の量子化の処理が行われる（ステップＳ２）。量子化は、１ブロック内の各ＤＣＴ係数を、量子化テーブル中の対応する位置の量子化ステップ値で除算して、情報量を少なくするために実施される。例えば、図５（Ａ）のＤＣＴ係数を図５（Ｂ）の量子化テーブルを用いて量子化した場合の１ブロック内のＤＣＴ係数を図５（Ｃ）に示す。図５（Ｃ）に示すように、高周波成分のＤＣＴ係数を量子化ステップ値で除算し、その小数点以下を四捨五入すると、ほとんどがゼロデータとなり、情報量が大幅に減少する。

図３に示すように、フレーム内符号化（Ｉピクチャ）の場合には、ＤＣ（直流）予測、スキャニング、可変長符号化（ＶＬＣ：Variable Length Code）の処理が行われる（ステップＳ８、Ｓ９、Ｓ１０）。ＤＣ予測（ステップＳ８）は、ブロックのＤＣ成分に対する予測値を決定する処理である。スキャニング（ステップＳ９）は、ブロック内を周波数が低い側から高い側に向けてスキャン（ジグザグスキャン）する処理である。可変長符号化（ステップＳ１０）は、エントロピー符号化とも称され、符号化原理として、出現頻度の多いものは少ない符号で表すように符号化する処理である。なおフレーム間符号化（Ｐピクチャ）の場合には、ＤＣ予測は不要であるため、スキャニング（ステップＳ７）だけが行われ、スキャニング後のデータに対して可変長符号化（ステップＳ１０）が行われる。

エンコード処理では、現在のフレームと次のフレームとの間で動き検出（ＭＥ：Motion Estimation）を実施するために、帰還ルートが必要となる。この帰還ルート（ローカルデコード処理）では、図３に示すように、逆量子化、逆ＤＣＴ及び動き補償（ＭＣ：Motion Compensation）の処理が実行される（ステップＳ３、Ｓ４、Ｓ５）。次に、得られた再構築フレーム（参照ＶＯＰ）に基づいて動き検出（ＭＥ）が実行されて、動きベクトルが検出される。そして、検出された動きベクトルに基づいて、予測フレーム（予測マクロブロック）が求められる。そして符号化対象となるフレームと予測フレームとの差分に対してＤＣＴ、量子化の処理が行われる（ステップＳ１、Ｓ２）。

図４のデコード処理は、図３のエンコード処理を、逆順で且つ逆処理することで実現される。即ち、まず、可変長符号（ＶＬＣ）の復号化処理が行われる（ステップＳ２１）。そしてフレーム内符号化（Ｉピクチャ）の場合には、逆スキャニング、逆ＤＣ／ＡＣ予測の処理が行われる（ステップＳ２２、Ｓ２３）。一方、フレーム間符号化（Ｐピクチャ）の場合には、逆ＤＣ／ＡＣ予測は行われず、逆スキャニングの処理だけが行われる（ステップＳ２４）。

次に、逆量子化、逆ＤＣＴの処理が行われる（ステップＳ２５、Ｓ２６）。そして過去のフレームのデータとＶＬＣ復号化後のデータとに基づき動き補償処理が行われ（ステップＳ２７）、逆ＤＣＴ後のデータとの加算処理が行われる。

図３に示すように本実施形態では、メモリ９０にロードされるマルチメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、Ｈ／Ｗアクセラレータ８０は、ハードウェア処理部分であるＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出の処理（ステップＳ１〜Ｓ６）を行う。また内蔵ＣＰＵ７０は、エンコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣへの符号化処理（ステップＳ１０）を行う。更に具体的には、Ｈ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合にはスキャニング処理（ステップＳ７）を行う。また内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合にはＤＣ予測（ＤＣ／ＡＣ予測）、スキャニングの処理を行う（ステップＳ８、Ｓ９）。

また図４に示すように本実施形態では、メモリ９０にロードされるマルチメディア処理用プログラムが動画のデコード処理用プログラムである場合には、内蔵ＣＰＵ７０は、デコード処理用プログラムに基づいて、ソフトウェア処理部分であるＶＬＣの復号化処理（ステップＳ２１）を行う。またＨ／Ｗアクセラレータ８０は、ハードウェア処理部分である逆量子化、逆ＤＣＴ、動き補償の処理（ステップＳ２５、Ｓ２６、Ｓ２７）を行う。更に具体的には、内蔵ＣＰＵ７０は、フレーム内符号化（Ｉピクチャ）の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理（ステップＳ２２、Ｓ２３）を行う。またＨ／Ｗアクセラレータ８０は、フレーム間符号化（Ｐピクチャ）の場合には逆スキャニング処理を行う（ステップＳ２４）。

なお本実施形態では、内蔵ＣＰＵ７０のデコード処理にデコードエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分（ステップＳ２１〜Ｓ２３）を実行する。

本実施形態において、図３、図４に示すような役割分担でソフトウェア処理部分とハードウェア処理部分を実現している理由は、以下の通りである。

即ち、図３のステップＳ２の量子化後であれば、図５（Ｃ）に示すように各ブロック内にはゼロデータが圧倒的に多く、図５（Ａ）の量子化前のデータに比べてデータの情報量の種類が圧倒的に少ない。しかも、ステップＳ８〜Ｓ１０の処理は、演算自体の負荷も少ない。従って、これらのステップＳ８〜Ｓ１０の処理については、演算処理能力がそれほど高くない内蔵ＣＰＵ７０を用いたソフトウェア処理で実現しても問題ない。また内蔵ＣＰＵ７０を用いたソフトウェア処理は低速であるが、フレキシブルなプログラミング可能である。従って、マルチメディア処理に付随する処理部分であり、負荷は軽いがフレキシブルなプログラミングが要求される処理部分を補うのに適している。

一方、図３のステップＳ１〜Ｓ６のＤＣＴ、量子化、逆量子化、逆ＤＣＴ、動き補償、動き検出は、情報量が多く、処理負荷が大きいと共に、処理の高速性が要求されるため、ソフトウェア処理にはあまり適していない。更に、ステップＳ１〜Ｓ６の処理は、負荷は重いが、その処理内容が規格である程度決まっているため、将来的な変更の必要性も乏しい。従って、ステップＳ１〜１６の処理は、専用のハードウェア回路（Ｈ／Ｗアクセラレータ８０）を用いたハードウェア処理に向いている。またステップＳ１〜Ｓ６の処理は、繰り返し処理が多いため、この意味においてもハードウェア処理に向いている。またステップＳ２の量子化後のデータ量は少ないため、Ｈ／Ｗアクセラレータ８０（ハードウェア処理部）から内蔵ＣＰＵ７０（ソフトウェア処理部）に伝送されるデータの量も少なくなり、データ転送制御の負担も軽くなる。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２１〜Ｓ２３を、内蔵ＣＰＵ７０を用いたソフトウェア処理で実現し、ステップＳ２４〜Ｓ２７を、Ｈ／Ｗアクセラレータ８０を用いたハードウェア処理で実現している。

また本実施形態では図３に示すように、フレーム内符号化（Ｉピクチャ）についてのスキャニング処理はソフトウェア処理で実現し、フレーム間符号化（Ｐピクチャ）についてのスキャニング処理はハードウェア処理で実現している。その理由は以下の通りである。

即ちフレーム内符号化の場合は、ステップＳ８のＤＣ予測をソフトウェア処理で行うため、ＤＣ予測に続くステップＳ９のスキャニング処理についてもソフトウェア処理で実現するのが効率的である。これに対して、フレーム間符号化の場合には、ＤＣ予測は不要であり、ステップＳ７のスキャニング処理をソフトウェア処理ではなくハードウェア処理で行っても問題はない。またステップＳ７のスキャニング処理は、比較的単純な処理であるため、ハードウェア処理に向いている。このような理由で本実施形態ではステップＳ７のスキャニング処理についてはハードウェア処理で実現し、ステップＳ９のスキャニング処理についてはソフトウェア処理で実現している。同様の理由で、本実施形態では図４のデコード処理においても、ステップＳ２２の逆スキャニング処理についてはソフトウェア処理で実現し、ステップＳ２４のスキャニング処理についてはハードウェア処理で実現している。

以上のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０によりバランス良く作業を分担することにより、クロック周波数をそれほど増加させることなく、低消費電力なシステムでマルチメディア処理を実現することに成功している。

３．ＦＩＦＯバッファ
本実施形態では、図２のＦＩＦＯ（First In First Out）バッファ９２、デコードデータバッファ９３、エンコードデータバッファ９４、ホスト用バッファ９６を、図６（Ａ）（Ｂ）のように利用して、エンコード処理、デコード処理を実現している。

例えばメモリ９０にロードされたマルチメディア処理用プログラムが動画のエンコード処理用プログラムである場合には、図６（Ａ）に示すように、カメラ１８で撮像された動画データ（１ＶＯＰ分の動画データ）はエンコードデータバッファ９４（ＭＰＥＧ４エンコードバッファ）に書き込まれる。そしてＨ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からエンコード処理の実行開始を指示された場合に、エンコードデータバッファ９４に書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗエンコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。

次に、内蔵ＣＰＵ７０は、ホストＣＰＵ３０から、メモリ９０にロードされたエンコード処理用プログラムの実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗエンコード後の動画データ）をホスト用バッファ９６（ハフマンＦＩＦＯ）に書き込む。

またメモリ９０にロードされたマルチメディア処理用プログラムが動画のデコード処理用プログラムである場合には、図６（Ｂ）に示すように、ホストＣＰＵ３０が、ホスト用バッファ９６に、デコード対象となる動画データ（１ＶＯＰ分の動画データ）を書き込む。そして内蔵ＣＰＵ７０は、ホストＣＰＵ３０からデコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファ９６に書き込まれた動画データに対して、デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行する。そして実行後の動画データ（Ｓ／Ｗデコード後の動画データ）をＦＩＦＯバッファ９２に書き込む。

次に、Ｈ／Ｗアクセラレータ８０は、ホストＣＰＵ３０からデコード処理の実行開始を指示された場合に、ＦＩＦＯバッファ９２に書き込まれた動画データ（１ＶＯＰ分の動画データ）に対して、デコード処理のハードウェア処理部分を実行する。そして実行後の動画データ（Ｈ／Ｗデコード後の動画データ）をデコードデータバッファ９３に書き込む。そしてデコードデータバッファ９３に書き込まれた動画データは、表示ドライバ１６に転送され、表示パネル１７の動画表示が行われる。

図６（Ａ）（Ｂ）のように本実施形態では、内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０の間にＦＩＦＯバッファ９２を介在させている。このようにすることで、ホストＣＰＵ３０の制御の元で、ソフトウェア処理部分とハードウェア処理部分を内蔵ＣＰＵ７０とＨ／Ｗアクセラレータ８０で効率良く分担して実行することが可能になる。

例えば図６（Ａ）のエンコード処理において、エンコード後の符号量が多い場合には、ビットレートを遵守するためのレートコントロールが必要になる。この場合に本実施形態では、ホストＣＰＵ３０がスキップフレームを作成することで、レートコントロールを実現する。具体的には、レートコントロールのために、例えば第Ｋのフレーム（第ＫのＶＯＰ）をスキップする場合には、ホストＣＰＵ３０は、この第Ｋのフレームの動画データについてのＨ／Ｗエンコード処理の開始指示（Ｈ／Ｗアクセラレータ８０に対する指示）を行わないようにする。これにより、Ｈ／Ｗエンコード処理後の第Ｋのフレームの動画データはＦＩＦＯバッファ９２には書き込まれないようになり、内蔵ＣＰＵ７０も、この第Ｋのフレームの動画データに対するＳ／Ｗエンコード処理を行わないようになる。

そしてホストＣＰＵ３０は、例えば次の第Ｋ＋１のフレーム（第Ｋ＋１のＶＯＰ）については、Ｈ／Ｗエンコード処理の開始指示をＨ／Ｗアクセラレータ８０に対して行う。これにより、Ｈ／Ｗエンコード処理後の第Ｋ＋１のフレームの動画データがＦＩＦＯバッファ９２に書き込まれ、内蔵ＣＰＵ７０は、この第Ｋ＋１のフレームの動画データに対するＳ／Ｗエンコード処理を行うことができる。この場合、ＦＩＦＯバッファ９２には、スキップされた第Ｋのフレームの動画データは書き込まれていない。従って、この第Ｋのフレームの動画データを廃棄したり無視したりする処理が不要になり、スムーズな処理を実現できる。

また図６（Ｂ）のデコード処理において、内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合に、本実施形態では、内蔵ＣＰＵ７０が、そのエラーの発生をホストＣＰＵ３０にレジスタ等を用いて通知する。そして、このように内蔵ＣＰＵ７０によるデコード処理にエラーが発生した場合には、ホストＣＰＵ３０が、内蔵ＣＰＵ７０に代わってデコード処理のソフトウェア処理部分を実行する。そしてホストＣＰＵ３０は、Ｓ／Ｗデコード処理後の動画データをＦＩＦＯバッファ９２に書き込む。これにより、Ｈ／Ｗアクセラレータ８０は、書き込まれた動画データに対してＨ／Ｗデコード処理を実行できるようになる。

デコード処理にエラーが発生した場合には、動画データ（ＶＯＰ）の解析を行う必要がある。しかしながら、ホストＣＰＵ３０からの動画データは、ＦＩＦＯであるホスト用バッファ９６に格納されているため、内蔵ＣＰＵ７０は、任意のアドレスにアクセスして動画データのエラー解析を行うことができない。一方、この動画データは、ホストＣＰＵ３０が送信したものであり、ホストＣＰＵ３０は、自身のメモリ内に記憶された動画データの任意のアドレスにアクセスしてエラー解析を行うことができる。これにより、内蔵ＣＰＵ７０のデコード処理にエラーが発生した場合にも、そのエラーを回復して、デコード処理を完結させることが可能になる。

４．スタートアップ時の動作
次に、本実施形態のスタートアップ（立ち上げ）時の動作について図７のシーケンス図を用いて説明する。

まずホストＣＰＵ３０が、内蔵ＣＰＵ７０によるアシスト処理の初期化設定を行う。そしてマルチメディア処理用プログラムをメモリ９０のプログラムロード領域９１にロードする。即ちホストメモリ４０に記憶されたマルチメディア処理用プログラム群の中から所望のマルチメディア処理用プログラム（デコード用プログラム、エンコード用プログラム）を選択して、メモリ９０にロードする。

次にホストＣＰＵ３０は、メモリ９０のプログラムロード領域９１のプロテクト処理を行う。このようにすることで、プログラムロード領域９１にロードされたマルチメディア処理用プログラムを保護することが可能になる。即ち、このようなプロテクト処理を行わないと、ホストＣＰＵ３０や内蔵ＣＰＵ７０が、データ等を間違ってプログラムロード領域９１に書き込んでしまう事態が生じ得る。このような事態が生じると、ロードされたプログラムが破壊され、システムがハングアップするなどの問題を招く。プログラムロード領域９１のプロテクト処理を行うことで、このような問題の発生を未然に防止できる。

次にホストＣＰＵ３０は、アシスト機能のイネーブルコマンド、クロックのイネーブルコマンド、リセット解除コマンドを送信し、スタートアップ完了ステータスの受信ウェイト状態に移行する。

内蔵ＣＰＵ７０は、リセット解除コマンドを受信すると、そのリセット状態を解除し、ブート処理などの初期化設定を行う。またメモリ９０のワーク領域９７の初期化（０クリア）を行う。そして内蔵ＣＰＵ７０は、スタートアップが完了すると、スタートアップ完了ステータスをホストＣＰＵ３０に送信し、ＡＣＫの受信ウェイト状態に移行する。するとホストＣＰＵ３０は、ＡＣＫを送信し、内蔵ＣＰＵ７０は、ＡＣＫを受信すると、デコード、エンコード開始コマンドのウェイト状態に移行する。

図７に示すように本実施形態では、ホストＣＰＵ３０からリセット解除コマンドを受信するまで、内蔵ＣＰＵ７０はリセット状態に設定される。そしてリセット解除コマンドを受信すると、内蔵ＣＰＵ７０のリセット状態が解除されて、マルチメディア処理用プログラムが実行される。そしてその後にホストＣＰＵ３０からリセットコマンドを受信すると、内蔵ＣＰＵ７０は再度リセット状態に設定される。このように本実施形態では、マルチメディア処理用プログラムを実行する時に、その都度、内蔵ＣＰＵ７０のリセット状態が解除され、それ以外の期間では、内蔵ＣＰＵ７０をリセット状態に設定できる。従って、動作する必要が無い期間において内蔵ＣＰＵ７０の動作を停止でき、省電力化を実現できる。なお図７では、ホストＣＰＵ３０によるリセット解除指示によりマルチメディア処理用プログラムが実行される方式を採用しているが、ホストＣＰＵ３０からの割り込みによりマルチメディア処理用プログラムが実行される方式を採用してもよい。

５．エンコード処理時の動作
次に、本実施形態のエンコード処理時の動作について図８のフローチャート及び図９のシーケンス図を用いて説明する。図８は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。

図８に示すように、ホストＣＰＵ３０は、エンコードデータバッファ９４へのデータ（カメラ１８からの動画データ）のライトが完了したか否かを判断する（ステップＳ３１）。そしてデータのライトが完了すると、データのライト完了フラグをクリアし（ステップＳ３２）、動き検出（ＭＥ）処理の開始を指示する（ステップＳ３３）。そして動き検出が完了したと判断すると、動き検出完了フラグをクリアする（ステップＳ３４、Ｓ３５）。

次に、ホストＣＰＵ３０は、レートコントロール処理を行う（ステップＳ３６）。即ち符号化データサイズに基づいて、量子化処理（図３のステップＳ２）の量子化ステップを変化させる。例えば符号化データサイズが大きい場合には、量子化ステップを大きくする。これにより量子化後のＤＣＴ係数（図５（Ｃ））のゼロデータの数が増える。一方、符号化データサイズが小さい場合には、量子化ステップを小さくする。これにより量子化後のＤＣＴ係数のゼロデータの数が減る。

次に、ホストＣＰＵ３０は、ＱＰ値（量子化パラメータ）を設定して、Ｈ／Ｗエンコード処理の開始を指示する（ステップＳ３７）。これにより、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理が実行される。そしてＨ／Ｗエンコード処理が終了したと判断すると、内蔵ＣＰＵ７０によるＳ／Ｗエンコード処理の開始を指示する（ステップＳ３８、Ｓ３９）。そして、エンコードストップか否かを判断し、エンコードストップではない場合にはステップＳ３１に戻り、エンコードストップの場合（所定フレーム数のエンコードが完了した場合）には処理を終了する（ステップＳ４０）。

次に、図９のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＱＰ値を設定して、Ｈ／Ｗアクセラレータ８０によるＨ／Ｗエンコード処理の開始を指示し、エンコードの完了をウェイトする。そしてＨ／Ｗエンコード処理が完了すると、必要があればＧＯＶ（Group Of VOP）ヘッダを作成する。またＶＯＰ（Video Object Plane）ヘッダを作成して、メモリ９０の情報領域９９に、エンコードに必要な種々の情報を設定する。

図１０（Ａ）に、エンコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０等は、図１０（Ａ）に示す情報をホストＣＰＵ３０から知らされることで、適切なエンコード処理を実現できる。

次に、ホストＣＰＵ３０は、Ｓ／Ｗエンコード処理の開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。そして内蔵ＣＰＵ７０がＡＣＫを送信すると、ホストＣＰＵ３０がそのＡＣＫを受信する。そして内蔵ＣＰＵ７０は、Ｓ／Ｗエンコード処理を開始し、処理後のデータ（動画データ）をホスト用バッファ９６（ＦＩＦＯ）にライトする。そして１ＶＯＰ分（広義には１フレーム分）のエンコード処理が終了したら、ｌａｓｔｅｎｃ＝１に設定する。

ホストＣＰＵ３０は、ホスト用バッファ９６（ＦＩＦＯ）をリードする。即ちｌａｓｔｅｎｃ＝１になるまでホスト用バッファ９６からデータ（ハフマンデータ）をリードする。そして、バイトアライメントのためのＶＯＰのスタッフィングを行う。なおレートコントロールによるスキップフレーム（ＶＯＰ）の作成はホストＣＰＵ３０が行う。

６．デコード処理時の動作
次に、本実施形態のデコード処理時の動作について図１１のフローチャート及び図１２のシーケンス図を用いて説明する。図１１は主にホストＣＰＵ３０の動作・処理を説明するフローチャートである。

図１１に示すように、ホストＣＰＵ３０は、ＶＯＳ（Video Object Sequence）ヘッダ、ＶＯ（Video Object）ヘッダ、ＶＯＬ（Video Object Layer）ヘッダの解析を行う（ステップＳ５１、Ｓ５２、Ｓ５３）。またスタートコードの検出を行い（ステップＳ５４）、ＧＯＶヘッダがある場合にはＧＯＶヘッダの解析を行う（ステップＳ５５、Ｓ５６）。

次に、ホストＣＰＵ３０は、Ｓ／Ｗデコード処理の開始を指示する（ステップＳ５７）。これにより、内蔵ＣＰＵ７０によるＶＯＰヘッダ解析とＶＣＬ復号化、逆スキャニング、逆ＤＣ／ＡＣ予測が行われるようになる。

次に、全てのフレーム（ＶＯＰ）のデコード処理が完了したか否かを判断し（ステップＳ５８）、完了した場合には処理を終了する。一方、全てのフレームのデコード処理が完了していない場合には、１フレーム分のデコード処理が完了したか否かを判断し（ステップＳ５９）、完了した場合にはデコード完了フラグをクリアする（ステップＳ６０）。

次にインターバル値を取得し、インターバル値分の時間（フレームレートに応じた時間）が経過したか否かを判断する（ステップＳ６１、Ｓ６２）。そして経過した場合には、表示エリア（ダブルバッファ構造のデコードデータバッファ９３の第１、第２のバッファのいずれか）の選択を行い（ステップＳ６３）、選択された表示エリアの表示データ（画像データ）を表示ドライバ１６に転送する（ステップＳ６４）。

図１１のステップＳ５１〜Ｓ５６に示すように、本実施形態では、ＭＰＥＧストリーム（広義にはストリームデータ）の上位レイヤーのヘッダ解析（ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶヘッダの解析）はホストＣＰＵ３０が行う。一方、ＭＰＥＧストリームの下位レイヤーのヘッダ解析（ＶＯＰヘッダの解析）は内蔵ＣＰＵ７０が行う。このように役割分担すれば、ホストＣＰＵ３０の制御の元で、ＭＰＥＧのデコード処理を効率化良く実施できるようになる。

次に、図１２のシーケンス図を説明する。まず、ホストＣＰＵ３０は、ＶＯＳ、ＶＯ、ＶＯＬ、ＧＯＶのヘッダを解析し、情報領域９９に情報（データ、パラメータ）を設定する。そしてホスト用バッファ９６（ＦＩＦＯ）の初期化処理を行う。

次にホストＣＰＵ３０はデコードリセットコマンドを送信し、ＡＣＫの受信ウェイト態に移行する。一方、内蔵ＣＰＵ７０は、アシストテーブルの展開後、ホストＣＰＵ３０からデコードリセットコマンドを受信すると、動作モードをデコードモードに設定する。またＨ／Ｗアクセラレータの初期化処理を行い、ＡＣＫを送信する。

ホストＣＰＵ３０は、ＡＣＫを受信すると、データ（ハフマンデータ）をホスト用バッファ９６にライトする。即ち１ＶＯＰ分のデータをホスト用バッファ９６にライトする。

次にホストＣＰＵ３０は、Ｓ／Ｗデコード開始コマンドを送信し、ＡＣＫの受信ウェイト状態に移行する。一方、内蔵ＣＰＵ７０は、デコード開始コマンドを受信すると、情報領域９９の情報を取得し、ＡＣＫを送信し、ホストＣＰＵ３０がそのＡＣＫを受信する。

図１０（Ｂ）に、デコード処理時に情報領域９９に設定される情報の例を示す。内蔵ＣＰＵ７０は、図１０（Ｂ）に示す情報をホストＣＰＵ３０から知らされることで、適切なデコード処理を実現できる。

次に内蔵ＣＰＵ７０は、Ｓ／Ｗデコード処理を開始する。そして処理後のデータをＦＩＦＯバッファ９２にライトする。そして１ＶＯＰ分のデータのデコード処理が終了したら、ｌａｓｔｄｅｃ＝１に設定する。また、ハフマンデータの解析中にエラーを検出したら、ｄｅｃｅｒｒ＝１に設定する。

ホストＣＰＵ３０は、ｌａｓｔｄｅｃ＝１になるのをウェイトする。そして、ｌａｓｔｄｅｃ＝１になった場合には、ｄｅｃｅｒｒを確認する。そして、ｄｅｃｅｒｒ＝１の場合には、ＦＩＦＯバッファ９２をクリアし、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。

次にホストＣＰＵ３０は、Ｈ／Ｗデコード処理の開始を指示する。そして開始の指示後、ホスト用バッファ９６の初期化処理に戻る。

図１２に示すように本実施形態では、Ｓ／Ｗデコード処理にエラーが発生した場合には、内蔵ＣＰＵ７０に代わってホストＣＰＵ３０がＳ／Ｗデコード処理を実行する。このようにすることで、エラーが発生した場合にも、そのエラーを回復してＨ／Ｗデコード処理に移行し、デコード処理を完結できるようになる。

７．ハンドシェーク通信
本実施形態では、ホストＣＰＵ３０、内蔵ＣＰＵ７０間でのコマンド、ステータスの転送を、レジスタ（出力レジスタ、入力レジスタ）を用いたハンドシェーク通信により実現している。これらのレジスタは、ホストＩ／Ｆ６０内に設けることができる。

図１３、図１４のフローチャートを用いて本実施形態のハンドシェーク通信を説明する。なお、図１５には、ハンドシェーク通信により転送されるコマンドやステータスの例を示す。

図１３は、ホストＣＰＵ３０から内蔵ＣＰＵ７０にデータ（コマンド、ステータス）を送信（出力）する場合のフローチャートである。まず、ホストＣＰＵ３０が、出力レジスタ（ビット７〜０）にデータをライトする（ステップＳ７１）。このライトにより出力ステータス（ビット８）＝１に自動設定される。

次にホストＣＰＵ３０は、タイマをスタートし（ステップＳ７２）、出力ステータス＝０になるのをウェイトする（ステップＳ７３）。そして出力ステータス＝０になった場合には処理を終了する。一方、出力ステータス＝０にならない場合には、ステップＳ７２でスタートしたタイマがタイムオーバーになったか否かを判断する（ステップＳ７４）。そしてタイムオーバーになっていない場合にはステップＳ７３に戻り、タイムオーバーになった場合には処理を終了する。

一方、内蔵ＣＰＵ７０は、出力レジスタ（ビット１５〜０）をリードする（ステップＳ７５）。このリードにより出力ステータス（ビット８）＝０に自動設定される。

次に、ステップＳ７５のリード時に出力ステータス＝１になっていたか否かを判断する（ステップＳ７６）。そして出力ステータス＝１になっていなかった場合にはステップＳ７５に戻り、出力レジスタ（ビット１５〜０）を再度リードする。一方、ホストＣＰＵ３０がステップＳ７１で出力レジスタ（ビット７〜０）にデータをライトし、出力ステータス＝１になると、ホストＣＰＵ３０は出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ７７）。

図１４は、ホストＣＰＵ３０が内蔵ＣＰＵ７０からデータ（コマンド、ステータス）を受信（入力）する場合のフローチャートである。まず内蔵ＣＰＵ７０が入力レジスタ（ビット２３〜１６）にデータをライトする（ステップＳ８１）。このライトにより入力ステータス（ビット２４）＝１に自動設定される。次に内蔵ＣＰＵ７０は出力レジスタ（ビット１５〜０）をリードする（ステップＳ８２）。そして出力ステータス＝１か否かを判断し（ステップＳ８３）、出力ステータス＝１の場合には出力レジスタのデータ（ビット７〜０）を取得する（ステップＳ８４）。次に、内蔵ＣＰＵ７０は入力ステータス＝０か否かを判断し（ステップＳ８５）、入力ステータス＝０ではない場合にはステップＳ８２に戻り、入力ステータス＝０の場合には処理を終了する。

ホストＣＰＵ３０は、入力レジスタ（ビット３１〜１６）をリードする（ステップＳ８６）。このリードにより入力ステータス（ビット２４）＝０に自動設定される。次に、ホストＣＰＵ３０は、入力ステータス＝１か否かを判断する（ステップＳ８７）。そして入力ステータス＝１ではない場合にはステップＳ８６に戻り、入力レジスタを再度リードする。一方、ステップＳ８１で内蔵ＣＰＵ７０により入力レジスタにデータがライトされ、入力ステータス＝１になった場合には、ホストＣＰＵ３０は、入力レジスタのデータ（ビット２３〜１６）を取得する（ステップＳ８８）。

なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。例えば、明細書又は図面中の記載において広義や同義な用語（ホストプロセッサ、内蔵プロセッサ、フレーム、電子機器等）として引用された用語（ホストＣＰＵ、内蔵ＣＰＵ、ＶＯＰ、携帯電話機等）は、明細書又は図面中の他の記載においても広義や同義な用語に置き換えることができる。

また本発明の電子機器、マルチメディア処理システム、表示コントローラの構成は、図１、図２等で説明した構成に限定されず、種々の変形実施が可能である。例えばこれらの図の構成要素の一部を省略したり、その接続関係を変更してもよい。また本発明で実現されるエンコード処理、デコード処理も図３、図４に限定されず、ＭＰＥＧ等の規格に応じた種々の変形実施が可能である。

本実施形態の電子機器、マルチメディア処理システムの構成例。 本実施形態の表示コントローラの構成例。 エンコード処理の説明図。 デコード処理の説明図。 図５（Ａ）〜図５（Ｃ）はＤＣＴ、量子化の説明図。 図６（Ａ）、図６（Ｂ）はＦＩＦＯバッファを用いる手法の説明図。 スタートアップ時のシーケンス図。 エンコード処理のフローチャート。 エンコード処理のシーケンス図。 図１０（Ａ）、図１０（Ｂ）は情報領域の説明図。 デコード処理のフローチャート。 デコード処理のシーケンス図。 レジスタを用いたハンドシェーク通信の説明図。 レジスタを用いたハンドシェーク通信の説明図。 ハンドシェーク通信により転送されるコマンド、ステータスの例。

符号の説明

１０ アンテナ、１２ 変復調器、１４ 操作部、１６ 表示ドライバ、
１７ 表示パネル、１８ カメラ、２０ マルチメディア処理システム、
３０ ホストＣＰＵ、４０ ホストメモリ、５０ 表示コントローラ、
６０ ホストＩ／Ｆ、７０ 内蔵ＣＰＵ、７２ 第１のＨ／Ｗアクセラレータ、
８０ 第２のＨ／Ｗアクセラレータ、９０ メモリ、９１ プログラムロード領域９１、９２ ＦＩＦＯバッファ、９３ デコードデータバッファ、
９４ エンコードデータバッファ、９５ 表示バッファ、９６ ホスト用バッファ、
９７ ワーク領域、９８ テーブルアシスト用領域、９９ 情報領域、
１００ メモリコントローラ、１１０ ドライバＩ／Ｆ、１２０ カメラＩ／Ｆ

Claims (10)

1. 動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うための表示コントローラであって、
   ホストプロセッサとのインターフェース処理を行うホストインターフェースと、
   ホストメモリに記憶されるマルチメディア処理用のプログラム群の中から、前記ホストプロセッサがマルチメディア処理用プログラムをリードして送信してきた場合に、送信された前記マルチメディア処理用プログラムがロードされるメモリと、
   ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、
   前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含み、
   前記マルチメディア処理用プログラムは、動画データのエンコード処理のソフトウェア処理部分を実行するためのエンコード処理用プログラムであり、
   前記第１のハードウェアアクセラレータは、
   前記ホストプロセッサからエンコード処理の実行開始を指示された場合に、エンコードデータバッファに書き込まれた動画データに対して、エンコード処理のハードウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
   前記内蔵プロセッサは、
   前記ホストプロセッサから前記エンコード処理用プログラムの実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、前記エンコード処理用プログラムに基づきエンコード処理のソフトウェア処理部分を実行し、実行後の動画データをホスト用バッファに書き込むことを特徴とする表示コントローラ。
2. 請求項１において、
   前記内蔵プロセッサは、
   前記ホストプロセッサからリセット解除を指示された場合に、リセット状態が解除され、前記リセット状態の解除後に前記マルチメディア処理用プログラムを実行することを特徴とする表示コントローラ。
3. 請求項２において、
   前記内蔵プロセッサは、
   前記リセット状態の解除後に、前記ホストプロセッサからのコマンドの受信をウェイトするコマンドウェイト状態に移行し、前記コマンドウェイト状態において前記マルチメディア処理用プログラムの実行開始を前記ホストプロセッサから指示された場合に、前記マルチメディア処理用プログラムを実行することを特徴とする表示コントローラ。
4. 請求項１乃至３のいずれかにおいて、
   前記第１のハードウェアアクセラレータは、
   ハードウェア処理部分である離散コサイン変換、量子化、逆量子化、逆離散コサイン変換、動き補償、動き検出の処理を行い、
   前記内蔵プロセッサは、
   ソフトウェア処理部分である可変長符号への符号化処理を行うことを特徴とする表示コントローラ。
5. 請求項４において、
   前記第１のハードウェアアクセラレータは、
   フレーム間符号化の場合にはスキャニング処理を行い、
   前記内蔵プロセッサは、
   フレーム内符号化の場合にはＤＣ予測、スキャニングの処理を行うことを特徴とする表示コントローラ。
6. 動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うための表示コントローラであって、
   ホストプロセッサとのインターフェース処理を行うホストインターフェースと、
   ホストメモリに記憶されるマルチメディア処理用のプログラム群の中から、前記ホストプロセッサがマルチメディア処理用プログラムをリードして送信してきた場合に、送信された前記マルチメディア処理用プログラムがロードされるメモリと、
   ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、
   前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含み、
   前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
   前記内蔵プロセッサは、
   前記ホストプロセッサから前記デコード処理用プログラムの実行開始を指示された場合に、ホスト用バッファに書き込まれた動画データに対して、前記デコード処理用プログラムに基づきデコード処理のソフトウェア処理部分を実行し、実行後の動画データをＦＩＦＯバッファに書き込み、
   前記第１のハードウェアアクセラレータは、
   前記ホストプロセッサからデコード処理の実行開始を指示された場合に、前記ＦＩＦＯバッファに書き込まれた動画データに対して、デコード処理のハードウェア処理部分を実行し、実行後の動画データをデコードデータバッファに書き込むことを特徴とする表示コントローラ。
7. 動画データ、静止画データ又は音データについてのエンコード又はデコード処理であるマルチメディア処理を行うための表示コントローラであって、
   ホストプロセッサとのインターフェース処理を行うホストインターフェースと、
   ホストメモリに記憶されるマルチメディア処理用のプログラム群の中から、前記ホストプロセッサがマルチメディア処理用プログラムをリードして送信してきた場合に、送信された前記マルチメディア処理用プログラムがロードされるメモリと、
   ロードされた前記マルチメディア処理用プログラムに基づいて、前記マルチメディア処理のうちソフトウェア処理に割り当てられたソフトウェア処理部分を実行する内蔵プロセッサと、
   前記マルチメディア処理のうちハードウェア処理に割り当てられたハードウェア処理部分を実行する第１のハードウェアアクセラレータとを含み、
   前記マルチメディア処理用プログラムは、動画データのデコード処理のソフトウェア処理部分を実行するためのデコード処理用プログラムであり、
   前記内蔵プロセッサは、
   デコード処理にエラーが発生した場合には、エラーの発生を前記ホストプロセッサに通知し、デコード処理のソフトウェア処理部分を前記ホストプロセッサに実行させることを特徴とする表示コントローラ。
8. 請求項６又は７において、
   前記内蔵プロセッサは、
   前記デコード処理用プログラムに基づいて、ソフトウェア処理部分である可変長符号の復号化処理を行い、
   前記第１のハードウェアアクセラレータは、
   ハードウェア処理部分である逆量子化、逆離散コサイン変換、動き補償の処理を行うことを特徴とする表示コントローラ。
9. 請求項８において、
   前記内蔵プロセッサは、
   フレーム内符号化の場合には逆スキャニング、逆ＤＣ／ＡＣ予測の処理を行い、
   前記第１のハードウェアアクセラレータは、
   フレーム間符号化の場合には逆スキャニング処理を行うことを特徴とする表示コントローラ。
10. 請求項１乃至９のいずれかにおいて、
    前記内蔵プロセッサに制御され、前記マルチメディア処理のソフトウェア処理部分の一部をアシストする第２のハードウェアアクセラレータを含むことを特徴とする表示コントローラ。

Images