JP2010003035A - データ処理装置 - Google Patents

Abstract

【課題】アクセラレータシステム構成を採るデータ処理装置において、ハードウェアリソースは増加させずに、データ処理性能の低下を抑制しつつ、外部メモリの使用量を削減する。
【解決手段】再構成されたステージごとに、非蓄積型ストリームや蓄積型のストリームと、ローカルメモリの使用可能な容量に基づいて、ローカルメモリが容量オーバーとならないように、圧縮すべきストリームを特定し、特定したストリームに関して、圧縮処理や伸長処理の適用の有無を制御する。たとえば、ステージごとに圧縮閾値THを計算し（Ｓ1010）、ステージ内に圧縮器・伸長器を挿入可能であれば挿入する（Ｓ1022）。圧縮処理を適用した画像処理中に容量オーバーとなる場合は一次フォールバック処理を適用する（Ｓ1042）。一次フォールバック処理を適用してもなお容量オーバーとなる場合は二次フォールバック処理を適用する（Ｓ1046）。
【選択図】図３

Description

本発明は、データ処理装置に関する。特に、データ処理部や制御部とは別に、外部メモリを備えた構成において、処理を高速に行なう仕組みに関する。

画像処理などのデータ処理を実行する際、高速処理を実現するために、制御部（ＣＰＵ）やメインメモリとは別に、アクセラレータと外部メモリを用意し、データ処理をアクセラレータに任せるアクセラレータシステムの仕組みが提案されている（たとえば、特許文献１〜３を参照）。

特開平１１−１２０３４０号公報 特開２００５−１５７７８３号公報 特開２００６−２３９９６８号公報

たとえば、特許文献１に記載の仕組みは、画像データに第１の処理を施す第１の処理手段と、第１の処理と並行して画像データに第２の処理を施す第２の処理手段と、第１の処理に用いる第１のメモリ手段と、第２の処理に用いる第２のメモリ手段とを備えることで、異なる複数の画像処理を高速で行なうようにしている。

特許文献２に記載の仕組みは、アクセラレータと接続し該アクセラレータに起動要求の予約を発行するＣＰＵと、ＣＰＵが発行した要求数をカウントする要求数カウンタおよび終了した処理数をカウントする終了数カウンタを有するアクセラレータとを備え、アクセラレータは、要求数カウンタのカウンタ値が終了数カウンタのカウンタ値より大きいとき、自身を起動可能とすることで、画像処理を高速に行なうようにしている。

特許文献３に記載の仕組みは、スキャナ機能、プリンタ機能、コピー機能を制御する第１の制御手段と、プリンタ機能を異なる動作条件で第１の制御手段によるプリンタ機能を分散処理可能な第２の制御手段と、第１の制御手段または第２の制御手段の処理能力を認識する認識手段と、認識手段により認識される第１の制御手段がプリンタ部に設定されるプリンタ機能が実現可能かどうかを判断する判断手段と、判断手段による実現可能でないと判断した場合に、第１の制御手段によるプリンタ機能を分散処理すべき第２の制御手段に対する最適な動作条件を設定する設定手段とを備えることで、画像形成装置全体の消費電力を節減するようにしている。

一方、アクセラレータシステム構成を採る場合、アクセラレータと外部メモリとの間でストリーム転送（データ転送）を行ないながらデータ処理を実行する。このとき、メモリ容量オーバーとなると処理の継続ができなくなる。このため、ストリーム（データ）を圧縮して外部メモリに記憶することが考えられている。このとき、アクセラレータから外部メモリへストリームを格納するために出力ストリームごとに圧縮器を持ち、逆に、外部メモリからアクセラレータへ圧縮されたストリームを取り込むために入力ストリームごとに伸長器を持つようにする仕組みも考えられている。

本発明は、アクセラレータと外部メモリを備えたアクセラレータシステム構成を採る場合において、ハードウェアリソースは増加させずに、データ処理性能の低下を抑制しつつ、外部メモリの使用量を削減する仕組みを提供することを目的とする。

請求項１に記載の発明は、装置全体の動作を制御する中央制御部および前記中央制御部の管理の下でデータを記憶する主記憶部を具備したホスト部と、データを処理する機能部であってデータ処理のステージごとに回路構成を動的に再構成可能なデータ処理部、前記データ処理部の回路構成を動的に制御する再構成制御部、および、前記データ処理部が取り扱うデータを記憶する副記憶部を具備したアクセラレータ部と、を備え、前記再構成制御部は、再構成されたステージごとに、当該ステージで使用されるデータである非蓄積型のストリームや当該ステージにおいては使用されないが後のステージ用に前記副記憶部に保持すべきデータである蓄積型のストリームと、前記副記憶部の使用可能な容量に基づいて、前記副記憶部が所定の基準値よりも容量オーバーとならないように、圧縮すべきストリームを特定し、この特定したストリームに関して、圧縮処理や当該圧縮処理に対応する伸長処理の適用の有無を制御するデータ処理装置である。

請求項２に記載の発明は、請求項１に記載の発明においてさらに、前記再構成制御部は、前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、当該ステージの前記データ処理部に挿入可能か否かを判定し、挿入不可能であって、かつ、前記特定したストリームが前記非蓄積型のストリームであれば、当該非蓄積型のストリームに関して、圧縮せずに分割転送を行なうように前記データ処理部を制御する。

請求項３に記載の発明は、請求項１に記載の発明においてさらに、前記再構成制御部は、前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、前記データ処理部に挿入可能か否かを判定し、挿入可能であれば、前記圧縮処理や前記伸長処理を実行する機能部を前記データ処理部に挿入するように制御する。

請求項４に記載の発明は、請求項３に記載の発明においてさらに、前記再構成制御部は、前記圧縮処理がなされた前記非蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、容量オーバーとなると判断したときには、前記非蓄積型のストリームを前記ホスト部側へ転送するように制御する。

請求項５に記載の発明は、請求項３に記載の発明においてさらに、前記再構成制御部は、前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、当該ステージの前記データ処理部に挿入可能か否かを判定し、挿入不可能であって、かつ、前記特定したストリームが前記蓄積型のストリームであれば、当該蓄積型のストリームに関して、圧縮処理や伸長処理を実行する機能部用のステージを新たに追加する。

請求項６に記載の発明は、請求項３に記載の発明においてさらに、前記再構成制御部は、前記圧縮処理がなされた前記蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、容量オーバーとなると判断したときには、前記蓄積型のストリームに対して、より良好な圧縮率で再圧縮するように制御する。

請求項７に記載の発明は、請求項６に記載の発明においてさらに、前記再構成制御部は、前記再圧縮がなされた前記蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、容量オーバーとなると判断したときには、前記蓄積型のストリームを前記ホスト部側へ転送するように制御する。

請求項８に記載の発明は、請求項３に記載の発明においてさらに、前記再構成制御部は、前記副記憶部が所定の基準値よりも容量オーバーとなるときには、前記圧縮処理や前記伸長処理とデータ処理の組合せで、前記容量オーバーとならないように、時分割で処理を実行するように制御する。

請求項９に記載の発明は、請求項８に記載の発明においてさらに、前記再構成制御部は、複数の出力ストリームを圧縮する必要がある場合において、前記圧縮処理を実行する機能部を、当該ステージの前記データ処理部に挿入できない場合は、前記データ処理とその後の前記圧縮処理の組合せで、前記時分割で処理を実行するように制御する。

請求項１０に記載の発明は、請求項８に記載の発明においてさらに、前記再構成制御部は、圧縮済みの入力ストリームを伸長する必要がある場合において、当該入力ストリームを一括して前記伸長処理を実行すると前記副記憶部が所定の基準値よりも容量オーバーとなる場合は、前記伸長処理とその後の前記データ処理の組合せで、前記時分割で処理を実行するように制御する。

請求項１１に記載の発明は、請求項１に記載の発明においてさらに、前記再構成制御部は、前記圧縮処理や前記伸長処理をモジュール分割し、前記データ処理部の空きエリアとの関係で許容される範囲で、前記モジュール分割した前記圧縮処理や前記伸長処理を選択して、当該処理を実行する機能部を前記データ処理部に挿入してハードウェア処理で対処するように制御するとともに、前記データ処理部に挿入できなかったモジュールについては、前記圧縮処理や前記伸長処理をソフトウェア処理で対処するように制御する。

請求項１２に記載の発明は、請求項１１に記載の発明においてさらに、前記再構成制御部は、前記ハードウェア処理での対処が可能な範囲で、前記モジュール分割した前記圧縮処理や前記伸長処理の内、前記ソフトウェア処理が重たいものから前記ハードウェア処理を適用するように制御する。

請求項１３に記載の発明は、請求項１１に記載の発明においてさらに、前記再構成制御部は、前記蓄積型のストリームに対して前記圧縮処理や前記伸長処理を適用する場合には、同一の前記蓄積型のストリームについて、モジュール分割による前記ハードウェア処理と前記ソフトウェア処理を別のステージで実行するように制御する。

請求項１４に記載の発明は、請求項１１に記載の発明においてさらに、前記再構成制御部は、前記非蓄積型のストリームに対して前記圧縮処理や前記伸長処理を適用する場合には、同一の前記蓄積型のストリームについて、モジュール分割による前記ソフトウェア処理を実行中には、モジュール分割による前記ハードウェア処理を待機させる。

請求項１５に記載の発明は、請求項１に記載の発明においてさらに、前記再構成制御部は、圧縮処理や伸長処理が適用されるストリームが複数ある場合、ストリーム量、前記データ処理部の空きエリア、圧縮処理や伸長処理のタイミング、および、圧縮処理や伸長処理の性能に基づき、圧縮処理や伸長処理を適用するストリームを選択して、圧縮処理や伸長処理を実行する機能部を、同一ステージ中の前記データ処理部に挿入するように制御する。

請求項１６に記載の発明は、請求項１５に記載の発明においてさらに、前記再構成制御部は、回路規模や処理性能の異なる複数の前記機能部を前記データ処理部に挿入するように制御する。

請求項１７に記載の発明は、請求項１５に記載の発明においてさらに、前記再構成制御部は、選択したストリームに関して複数の前記機能部を前記データ処理部に挿入可能な場合、その中で圧縮性能の最も劣る機能部を前記データ処理部に挿入するように制御する。

請求項１８に記載の発明は、請求項１５に記載の発明においてさらに、前記再構成制御部は、圧縮処理を適用済みのストリームに関して、前記データ処理部に挿入可能な範囲で、前記圧縮処理を実行する機能部をより圧縮性能の高いものに変更するように制御する。

請求項１９に記載の発明は、請求項１に記載の発明においてさらに、前記再構成制御部は、前記圧縮処理がなされた前記ストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部の使用率を監視し、前記使用率が一定以上になった場合には、前記ストリームに対してより良好な圧縮率で圧縮処理を実行するステージを新たに設けるように制御する。

請求項２０に記載の発明は、請求項１９に記載の発明においてさらに、前記再構成制御部は、前記より良好な圧縮率での圧縮処理を実行するステージを新たに設けたことに合わせて、対応する伸長処理を実行する機能部を設定するように制御する。

請求項２１に記載の発明は、請求項２０に記載の発明においてさらに、前記再構成制御部は、前記より良好な圧縮率での圧縮処理が適用されるストリームについて現在設定されている伸長処理を実行する機能部が挿入されている前記データ処理部に挿入可能な範囲で、現在設定されている伸長処理を実行する機能部を、前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部に変更するように制御する。

請求項２２に記載の発明は、請求項２０に記載の発明においてさらに、前記再構成制御部は、前記より良好な圧縮率での圧縮処理が適用されるストリームについて現在設定されている伸長処理を実行する機能部が挿入されている前記データ処理部について、現在設定されている伸長処理を実行する機能部を前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部に変更できない場合は、前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部用のステージを新たに設けるように制御する。

請求項２３に記載の発明は、請求項１に記載の発明においてさらに、前記アクセラレータ部を複数備え、各アクセラレータ部の前記再構成制御部は、各副記憶部の空きエリアを、相互に利用するように、協調して前記制御を行なう。

請求項２４に記載の発明は、請求項２３に記載の発明においてさらに、各アクセラレータ部の前記再構成制御部の内の何れか１つをマスターとし、そのマスターの再構成制御部が、各副記憶部の空きエリアの情報を集約して管理する。

請求項１に記載の発明によれば、全ての入出力ストリームに対して圧縮や伸長を適用するのではなく、容量オーバーとならないように圧縮すべきストリームを特定して圧縮や伸長の適用の有無を制御するので、ハードウェアリソースは増加させずに、処理速度の低下を抑制しつつ、外部メモリの使用量を削減できる。

請求項２に記載の発明によれば、非蓄積型のストリームを主体的に取り扱う場合に、当該ステージ中に圧縮処理の挿入ができないときには分割転送を適用することで、処理を継続させることができる。

請求項３に記載の発明によれば、当該ステージ中もしくは当該ステージ中とは別のステージ中に圧縮処理や伸長処理を挿入することで、外部メモリの使用量を削減できる。

請求項４に記載の発明によれば、非蓄積型のストリームを主体的に取り扱う場合において、圧縮処理を適用したデータ処理中に容量オーバーとなる場合に、非蓄積型のストリームをホスト部側へ転送することで、処理を継続させることができる。

請求項５に記載の発明によれば、蓄積型のストリームを主体的に取り扱う場合において、圧縮処理や伸長処理を当該ステージ中に挿入できない場合には、別のステージ挿入することで、処理速度の低下を抑制しつつ、外部メモリの使用量を削減できる。

請求項６に記載の発明によれば、蓄積型のストリームを主体的に取り扱う場合において、圧縮処理を適用したデータ処理中に容量オーバーとなる場合に、より良好な圧縮率で再圧縮することで、処理を継続させることができる。ホスト部側へのストリーム転送の発生を抑制することができるので、処理の時間ロスが殆ど発生しない。

請求項７に記載の発明によれば、蓄積型のストリームを主体的に取り扱う場合において、再圧縮を適用したデータ処理中に容量オーバーとなる場合に、蓄積型のストリームをホスト部側へ転送することで、処理を継続させることができる。

請求項８に記載の発明によれば、時分割処理を適用することでメモリ使用量を削減できる。その結果、メモリ容量オーバーとなるときに時分割処理を適用することで、ハードウェアリソースは増加させずに、処理速度の低下を抑制しつつ、メモリ容量オーバーを回避できる。

請求項９に記載の発明によれば、複数の出力ストリームを圧縮する必要がある場合に時分割処理を適用することで、メモリ容量オーバーを回避しつつ、データ処理と圧縮処理を実行できる。

請求項１０に記載の発明によれば、圧縮済みの入力ストリームを伸長する必要がある場合において、入力ストリームを一括して伸長処理を実行するとメモリ容量オーバーとなる場合に時分割処理を適用することで、メモリ容量オーバーを回避しつつ、伸長処理とデータ処理を実行できる。

請求項１１に記載の発明によれば、圧縮処理や伸長処理を実行する機能部を一括してデータ処理部に挿入できない場合でも、モジュール分割して、エリアの許す範囲でモジュールの一部をハードウェア処理で対処できる。その結果、データ処理エリアを確保しつつ、処理速度低下を抑制するように、圧縮器や伸長器を挿入できる。

請求項１２に記載の発明によれば、ソフトウェア処理が重たいものからハードウェア処理を適用するように制御するので、処理速度低下を最低限に抑えることができる。

請求項１３に記載の発明によれば、蓄積型ストリームに対してモジュール分割によるソフトウェア処理を適用する場合、同一ストリームについては、ハードウェア処理とソフトウェア処理が別ステージで段階的に実行されるが、他のストリームとの関係においてはハードウェア処理とソフトウェア処理が同一ステージで並行して実行される。このため、実質的には、ソフトウェア処理による対処が処理速度面に影響を与えることがない。

請求項１４に記載の発明によれば、非蓄積型ストリームを取り扱う場合には、モジュール分割によるソフトウェア処理の分のオーバーヘッドが必要で、処理速度面に影響があるが、データ処理エリアを確保しつつ、処理速度低下を極力抑制するように、圧縮器や伸長器を挿入できる。

請求項１５に記載の発明によれば、空き回路スペース・メモリ容量に合わせた効率的な圧縮・伸長を行なうことができる。ホスト部側へのストリーム転送の発生を抑制することができるので、処理の時間ロスが殆ど発生しない。

請求項１６に記載の発明によれば、空き回路スペースを利用して、回路規模や性能の異なる複数の機能部を配置するので、空き回路スペース・メモリ容量に合わせた効率的な圧縮・伸長を行なうことができる。空き回路スペースを利用して圧縮・伸長を行なうので、処理の時間ロスが殆ど発生しない。

請求項１７に記載の発明によれば、圧縮性能の最も劣る機能部をデータ処理部に挿入することで、データ処理部により広い空きスペースを確保でき、その空きスペースにさらに他のストリームに関して圧縮・伸長を実行する機能部を挿入できる。

請求項１８に記載の発明によれば、スペース面から許容される範囲で圧縮性能の高いものに変更することで、メモリ使用量をより削減できるようになる。

請求項１９に記載の発明によれば、使用率が一定以上になった場合により良好な圧縮率で再圧縮するステージを新たに設けることで、処理を継続させることができる。ホスト部側へのストリーム転送の発生を抑制することができるので、処理の時間ロスが殆ど発生しない。

請求項２０に記載の発明によれば、圧縮率の変更に合わせて、対応する伸長処理を実行するので、データ処理を不都合なく実行できる。

請求項２１に記載の発明によれば、圧縮率の変更に対応する伸長処理を実行する機能部を、変更前の圧縮率が適用される伸長処理を実行する機能部と置き換えるので、新たなステージの追加をしなくても、圧縮率の変更に対応する伸長処理を実行できる。このため、伸長処理に関して処理速度面の性能低下が起きない。

請求項２２に記載の発明によれば、圧縮率の変更に対応する伸長処理を実行する機能部を、変更前の圧縮率が適用される伸長処理を実行する機能部と置き換えることができない場合でも、ステージの追加により対処するので、データ処理を不都合なく実行できる。

請求項２３に記載の発明によれば、マルチチップ構成を採る場合に、各副記憶部の空きエリアを共有化できる。ある再構成制御部が属するアクセラレータ部の副記憶部が容量オーバーとなると、他のアクセラレータ部と協調して、空いている副記憶部の領域を使用することができるので、各副記憶部の容量を最小限にすることができる。

請求項２４に記載の発明によれば、マスターの再構成制御部により、各副記憶部の空きエリアを集中管理できる。

以下、図面を参照して本発明の実施形態について詳細に説明する。

＜＜第１実施形態＞＞
図１および図１Ａは、本実施形態（第１実施形態に限らず後述する他の実施形態も）のデータ処理装置１（たとえば印刷装置や複写装置や複合機などの画像処理装置）の構成例を説明する図である。ここで、図１は、データ処理装置１の基本構成例を示す図である。図１Ａは、本実施形態のデータ処理装置１の仕様を説明する図である。

本実施形態のデータ処理装置１は、内部処理構成をプログラマブル可能なデバイスとしてＤＲＰ（Dynamically Reconfigurable Processor）を利用した構成を採っている。なお、内部処理構成を動的にプログラマブル可能なデバイスであれば良く、ＤＲＰに限らず、ＦＰＧＡ（Field Programmable Gate Array）でもよい。

具体的には、本実施形態のデータ処理装置１は、当該データ処理装置１の主要をなすＤＲＰ１０と、ＤＲＰ１０が直接的に使用するローカルメモリ３０（副記憶部、外部メモリ）と、当該データ処理装置１の全体を制御するコントローラメインＣＰＵ５０（ＣＰＵ：Central Processing Unit ：中央制御部）と、コントローラメインＣＰＵ５０が直接的に使用するメインメモリ７０（主記憶部）とを備えている。ＤＲＰ１０とコントローラメインＣＰＵ５０は外部バス９０で接続されている。ＤＲＰ１０とローカルメモリ３０によりアクセラレータ部３が構成される。コントローラメインＣＰＵ５０とメインメモリ７０によりホスト部５が構成される。

ローカルメモリ３０としては、たとえばＤＤＲ仕様のＳＤＲＡＭ（Double Data Rate Synchronous Dynamic Random Access Memory ）を使用する。外部バス９０としては、たとえば、ＰＣＩエクスプレス（PCI Express ：ＰＣＩ-e）規格のものを使用する。

ＤＲＰ１０は、再構成可能なデータ処理モジュール（再構成可能なデータ処理部）の一例である画像処理リコンフィグ部１２と、内部バス１４と、ローカルメモリ３０との間のインタフェース（インタフェース）をなすメモリＩＦ部１６と、外部バス９０を介してコントローラメインＣＰＵ５０とのインタフェースをなす外部バスＩＦ部１８を有する。また、本実施形態のＤＲＰ１０は、画像処理リコンフィグ部１２の再構成を制御する（スケジューリングする）リコンフィグ制御部２０（再構成制御部）を有する。

画像処理リコンフィグ部１２では、パイプラインステージを再構成（リコンフィグ）しながら、複数の画像処理を実行する。たとえば、データ処理装置１を画像処理システムとして利用したとき、ＤＲＰ１０におけるコストにおいて、ローカルメモリ３０の占める割合が大きくなることを避けるべく（たとえば全体の５０％以上となることを回避する）、プログラマブル・デバイス（ＦＰＧＡやＤＲＰ：本例ではＤＲＰ１０）の画像処理構成を制御するスケジューラとしてリコンフィグ制御部２０を導入して、性能の低下を抑制しながらメモリ使用量を削減する仕組みを採る。

メモリ使用量を削減するための基本的な仕組みとしては、圧縮・伸長方式を採用する。たとえば、印刷機能や複写機能あるいはＦＡＸ機能などの複数機能を実行可能な画像形成装置の一例である複合機を想定した場合、当該装置が取り扱う画像データは、たとえば、Ａ４サイズ、解像度６００ｄｐｉ、Ｙ（イエロ），Ｍ（マゼンタ），Ｃ（シアン），Ｋ（ブラック）の４色成分では、１ページ分で１３５ＭＢｙｔｅになる。仮に４つのデータ処理モジュールの入力データ、出力データ、合計８枚の画像をローカルメモリ３０に記憶するものとすると、１３５ＭＢｙｔｅ×８＝約１ＧＢｙｔｅのメモリ容量が必要になる。データ処理（たとえば画像処理）の入出力データをそのままローカルメモリ３０に読み書きするので、巨大なメモリ容量が必要となる。

この対策としては、ハードウェアリソースとして圧縮器や伸長器を各画像処理時に入れることが考えられる。ところが、このような対処方法では、回路規模大となり、画像処理装置のコストが大になる。また、ソフトウェアで圧縮処理や伸長処理を実行する場合は、リソースを圧縮処理や伸長処理にとられるため、画像処理が完了する時間が遅くなる。

よって、ハードウェアリソースは増加させずに、画像処理スピードの低下を抑制し、かつ、メモリ量を削減する仕組みが要求される。換言すると、図１Ａに示すように、ハードウェアリソースを増やさないで、画像処理速度性能低下を抑制し、画像処理に必要なストリーム使用量合計MSUM１以下のメモリ容量（メモリサイズ）でも、正常に画像処理を実現することが仕様要求となる。

この対策として、本実施形態では、回路構成を動的に再構成可能なデバイスの画像処理部（本例ではＤＲＰ１０の画像処理リコンフィグ部１２）にて画像データを取り扱う際のデータ容量削減の観点から、圧縮符号化によってデータ容量を削減する方法を採る。つまり、ローカルメモリ３０に記憶するデータは、圧縮符号化によってメモリ容量を削減するのである。このため、画像処理リコンフィグ部１２には、図示しないが（詳細は後述する）、内部バス１４にデータを入出力する前に、データを符号化・復号化する圧縮伸長部を有する。圧縮伸長部は、データを符号化して圧縮する符号化部（いわゆるエンコーダ）および符号化されたデータを伸長して復号する復号化部（いわゆるデコーダ）を有する。

ここで、本実施形態の仕組みでは、回路構成を動的に再構成可能なデバイスであるＤＲＰ１０を使用し、再構成されたステージごとに、非蓄積型ストリームや蓄積型ストリームとメモリ使用量に関する所定の規定値に基づいて、ローカルメモリ３０が容量オーバーとならないように圧縮すべきストリームを特定し、この特定したストリームに関して圧縮処理や伸長処理の適用を制御する。たとえば、画像処理の最中に保持しているストリームを圧縮処理し、リコンフィグ制御部２０にて画像処理部（画像処理リコンフィグ部１２）の外部メモリ量（ローカルメモリ３０のメモリ使用可能量）をオーバーしないように制御（スケジューリング）することで、ハードウェアリソースは増加させずに、データ処理（画像処理）速度の低下を抑制し、かつメモリ量を削減するようにする。

このため、リコンフィグ制御部２０にて、各機能部（リコンフィグパイプラインのファンクション（Func）やパイプラインステージと称する）ごとに圧縮閾値THを算出し、圧縮閾値THを超えるサイズのストリームはデータ処理（画像処理）の前後に圧縮器や伸長器を挿入するようにスケジューリングする。また、圧縮器や伸長器の挿入ができないときには、それに応じた対処を行なう。

さらに、全てのストリームに対して圧縮・伸長を適用するのではなく、画像処理リコンフィグ部１２内で再構成された各機能部（ファンクション（Func）やパイプラインステージと称する）の処理内容（たとえば取り扱うデータ量など）に応じて、圧縮・伸長を適用するか否かをリコンフィグ制御部２０にて制御する。たとえば、あるデータ量の基本単位を１ユニットとしたとき、図１では、Func_Aが８ユニットのSD_A（SD：Stream Data ）を取り扱い、Func_Bが１ユニットのSD_Bを取り扱い、Func_Cが１ユニットのSD_Cを取り扱う場合、データ量の多いSD_Aに関して８／３にデータ圧縮することでメモリサイズを削減する。

汎用ＣＰＵにおける画像処理をコストパフォーマンスよく高速化するために、たとえば、特開平１１−１２０３４０号公報、特開２００５−１５７７８３号公報、特開２００６−２３９９６８号公報などには、ＣＰＵやメインメモリ７０とは別に外部メモリを具備するアクセラレータを備えたアクセラレータシステムが提案されている。本実施形態のデータ処理装置１においても、基本的には、これらと同様に、図１に示すような画像処理アクセラレータ（ＦＰＧＡやＤＲＰなどのプログラマブル・デバイス）を利用した構成を採る。この場合、アクセラレータである「内部処理構成をプログラマブル可能なデバイス」（図ではＤＲＰ１０）そのもののコストより、ローカルメモリ３０のコストの方が大きくなる可能性がある。また、画像処理アクセラレータ単体でのケースでも同様なことが言える。

ローカルメモリ３０のメモリコストを削減する手法として、圧縮・伸長の適用が考えられる。このとき、注意すべきことは、可逆符号化方式の圧縮・伸長であることが望ましい。この理由は、画像処理途中でローカルメモリ３０にデータ出力する中間ストリームで非可逆圧縮（非可逆符号化）してしまうと、最終画質が予測不可能となるし、画像処理によっては、中間ストリームが「座標」など、画像ではない非可逆が許されない情報の場合もあるからである。ところが、可逆方式では圧縮率が１００％を超える場合など、一定の圧縮率を保証することができない。なお、圧縮率（％）は、“圧縮後のデータサイズ÷圧縮前のデータサイズ”であり、値の低い方が圧縮性能が良好であることを示す。

そこで、本実施形態では、ローカルメモリ３０へのデータ書込み・読出しに当たり可逆圧縮・伸長方式を採用する場合に、圧縮率が１００％を超える場合でも、アクセラレータシステムの性能の低下を抑えることのできる仕組みを採る。その基本は、前述の通り、プログラマブル・デバイスのデータ処理（本例では画像処理）構成を制御するスケジューラ機能を具備したリコンフィグ制御部２０により、画像処理リコンフィグ部１２内の再構成される各機能部（パイプラインステージ、ファンクション）の処理内容（たとえばストリーム系統数やストリーム合計量）に応じて、圧縮・伸長を適用するか否かを制御することで、データ処理性能の低下を抑制しながらメモリ使用量を削減する。

＜第１実施形態の比較例＞
図２および図２Ａは、第１実施形態のデータ処理装置１における基本動作例に対する比較例を説明する図である。ここで、図２は、パイプラインステージのスケジューリングの側面から示した図であり、図２Ａは、ＤＲＰ１０（詳しくは画像処理リコンフィグ部１２）の内部回路の構成面から示した図である。

ここでは、平均圧縮率が１／２（５０％）、メモリサイズは４ユニット、メモリサイズ・リミット（メモリサイズの限界）は３ユニットとして、図２（１）に示すような非蓄積型ストリームを想定パイプラインとする。ここで、メモリサイズ・リミットを設けたのは、可逆圧縮を採用するので、圧縮率が１００％を超えることで破綻を来たすことがないように、メモリサイズ（本例では４ユニット）に対してマージンを設けるためである。「非蓄積型ストリーム」とは、直近のパイプラインステージ（ファンクション：Func）で直ぐ使うストリームデータであり、それに対しての「蓄積型ストリーム」とは、直近のパイプラインステージでは使わないストリームデータである。

なお、後に「蓄積型ストリーム」となるストリームであっても、当該ファンクション（パイプラインステージ）の処理時点で出力されるストリームは、そのパイプラインステージ（ファンクション：Func）で直ぐ使うストリームデータであるから「非蓄積型ストリーム」である。また、以前は「蓄積型ストリーム」であったストリームであっても、当該ファンクション（パイプラインステージ）の処理時点で入力されるストリームは、そのパイプラインステージ（ファンクション：Func）で直ぐ使うストリームデータであるから「非蓄積型ストリーム」である。

図２（１）に示す想定パイプライン（イニシャル・パイプライン）においては、１ユニットのStream１がFunc１に入力され、Func１での処理により３ユニットのStream２が出力され、このStream２がFunc２に入力され、Func２での処理により０．８ユニットのStream３が出力されている。なお、実際には、ある段のFuncで処理されたStreamが次段のFuncに直ちに入力されるのではなく、画像処理リコンフィグ部１２は、ローカルメモリ３０からStreamをFuncに取り込み、Funcでの処理によりStreamを出力してローカルメモリ３０に記憶するという処理を、後段のパイプラインステージに順次引き継ぐことになる。これは、画像処理リコンフィグ部１２は、メモリ（本例ではローカルメモリ３０）との間でデータの読み書きを行ないながらデータ処理を行なうからである。

ここで、Func１の入出力間に着目したとき、ストリーム使用量の合計は４ユニットであり、画像処理リコンフィグ部１２は、この分をローカルメモリ３０との間で入出力することになるので、ストリーム使用量の合計がメモリサイズ・リミット（本例では３ユニット）以下となるようにする必要がある。圧縮率を計算すると、３（メモリサイズ・リミット）÷４（ストリーム使用量合計MSUM１）＝７５％となる。

この対応として、最も単純な方法は、図２（２）に示すモディファイド・パイプラインのように、全ストリームを７５％圧縮することである。圧縮するときには圧縮器Cm（圧縮符号化部）が必要であるし、データ処理のために元のサイズに戻す（復号する）には伸長器Ex（伸長復号部）が必要になる。なお、ここでは圧縮器Cmや伸長器Exを同一パイプラインステージ中に配しているが、そのパイプラインステージ中に圧縮器Cmや伸長器Exを収めるだけの余裕がない場合、あるいはストリーム種に応じて、そのパイプラインステージ外に（つまりリコンフィグして）、これらを別のパイプラインステージに配してもよい。

たとえば、Func１に入力する１ユニットのStream１に対しては圧縮器Cmで０．７５ユニットのStream１にしてからFunc１に入力する。Func１ではこれを伸長器Exにより元のサイズに戻し、処理後の３ユニットのStream２に対しては圧縮器Cmで２．２５ユニットのStream２にしてからFunc２に入力する。Func２ではこれを伸長器Exにより元のサイズに戻し、処理後の０．８ユニットのStream３に対しては圧縮器Cmで０．６ユニットのStream３として出力する。この場合は、圧縮器Cmの平均圧縮率は１／２なので、Func１の入出力間のストリーム使用量の合計は、当然に“０．７５＋２．２５＝３．０”であり、必要メモリサイズは、４から３に削減され、破綻を来たすことはない。ただし、平均圧縮率は予測値であり、１／２を超え、たとえば“１＝１００％”に近くなる、あるいは、“１＝１００％”を超えることもあり、これらの場合、破綻を来たすことがある（詳細は図２（３）や第１例で示す）。

このように、メモリ量を削減し、かつ画像処理スピードを低下させないために全ストリームを圧縮すると、それに対応した伸長も必ず必要になり、ＤＲＰ１０（詳しくは画像処理リコンフィグ部１２）の内部回路は、図２Ａに示すように、画像処理の入力ストリームごとに伸長器Exを、出力ストリームごとに圧縮器Cmを実装する構成となる。つまり、圧縮や伸長をするべき入力ストリームや出力ストリームが複数ある場合に、ハードウェアで圧縮器Cmや伸長器Exを入れると、入力ストリームごとに伸長器Exをまた出力ストリームごとに圧縮器Cmを実装する構成となるので回路規模が大きくなり、データ処理装置１（画像処理装置）のコストが掛る。

ここで、図２（２）や図２Ａから理解されるように、圧縮器Cmや伸長器Exをパイプラインステージ中に配する場合、全てのパイプラインステージ（本例ではFunc１，Func２）に圧縮器Cmと伸長器Exを挿入するだけの余裕がないとならない。また、複数ストリームの入出力では、複数の圧縮器Cmと伸長器Exを挿入する必要があり、付加的なハードウェアリソースが必要になる、圧縮処理および伸長処理のための付加的な処理時間が必要で、性能低下インパクトがあり、実際には、実装が困難となる。圧縮器Cmや伸長器Exの挿入を優先すると、その分の回路規模大のため、画像処理エリアが十分に確保されないと言うことも起こり得る。

また、画像処理途中でローカルメモリ３０にデータ出力する中間ストリームで非可逆圧縮することによる不都合を避けるべく（前述の通り）、可逆圧縮の適用が望まれる（実際にはほぼ必須となる）。可逆圧縮では、実際には、データ量を削減できる保証がないので、図２（３）に示すように、実際の圧縮率（圧縮後ストリームサイズ／圧縮前ストリームサイズ）が１（１００％）を越える場合がある。図２（３）に示す例では、Stream１は１２０％（＝１．２／１），Stream２は１０６％（＝３．２／３），Stream３は１２５％（＝１．０／０．８）となっている。この場合は、Func１の入出力間のストリーム使用量の合計は、“１．２＋３．２＝４．４”であり、メモリサイズ・リミット＝３をオーバーしているので、破綻を来たすことになる。

＜スケジューリング：第１実施形態＞
図３は、第１実施形態のデータ処理装置１における基本動作であるスケジューリングの処理手順を説明するフローチャートである。なお、各ステップに対応する具体的な処理例は、後述の各実施例（第１実施形態のもの）で説明する。また、ストリーム種別（蓄積型と非蓄積型）ごとのスタティック・スケジューリングとダイナミック・スケジューリングについては、具体的な処理手順を別途説明する。

図２（３）に示した問題点の対策として、第１実施形態では、スケジューラ機能を具備するリコンフィグ制御部２０は、圧縮・伸長頻度を低下させる圧縮閾値THを計算しておき（Ｓ1010）、スタティック・スケジューリングでの圧縮器Cmや伸長器Exの追加を適用できるケースでは（Ｓ1012-Y）、規定メモリサイズ（１種類とは限らない）に基づいて処理データであるストリームを選択的に圧縮・伸長することで、圧縮処理と伸長処理の頻度を低下させ、圧縮処理や伸長処理によるハードウェアリソースやソフトウェアなら性能低下のインパクトを最小限とする。一方、スタティック・スケジューリングでの圧縮器Cmや伸長器Exの追加を適用できないケースでは（Ｓ1012-N）、分割転送処理（バンディング処理とも称する：詳細は第２例で説明する）で対処する（Ｓ1014）。

特に、ＦＰＧＡや図１に示したＤＲＰ１０などのプログラマブル・デバイスにて画像処理パイプライン中間Streamを可逆圧縮するリコンフィグ制御部２０を導入し、可逆圧縮に特有の圧縮率が悪い（つまり圧縮率が高い）場合にそのままではＤＲＰ１０とローカルメモリ３０とのデータ転送に破綻を来たすことになる対策として、スタティック・スケジューリングによる圧縮・伸長の追加もしくは分割転送処理（バンディング処理とも称する）や、一次フォールバック処理やホスト部５であるコントローラメインＣＰＵ５０（それが管理するメインメモリ７０）を利用した二次フォールバック処理を行なう。

ストリームを選択的に圧縮する際には、図４に示すように、先ず、処理を開始する前に、パイプライン情報（特に第１の規定メモリサイズMS_1）に基づいてストリームを圧縮するか否かを切り分けて（圧縮対象のストリームを切り分けて）圧縮器Cmと伸長器Exを挿入する静的な対処方法（スタティック・スケジューリング（Static Scheduling ）と称する）がある（Ｓ1010〜Ｓ1022）。また、処理過程でメモリ容量（第２の規定メモリサイズMS_2）をオーバーするか否かを監視し、第２の規定メモリサイズMS_2を越える状況になったときに蓄積型ストリームに対して圧縮器Cmと伸長器Exを挿入する一次フォールバック処理（Ｓ1040〜Ｓ1042）や、メモリ容量（第３の規定メモリサイズMS_3）をオーバーする状況のときに非蓄積型ストリームや蓄積型ストリームに対してメインメモリ７０を利用する二次フォールバック処理（Ｓ1044〜Ｓ1048）を行なう動的な対処方法（ダイナミック・スケジューリング（Dynamic Scheduling）と称する）がある。スタティック・スケジューリング処理やダイナミック・スケジューリング処理をそれぞれ個別に適用してもよいし、スタティック・スケジューリング処理とダイナミック・スケジューリング処理を組み合わせた処理を行なうようにしてもよい。

一次フォールバック処理は、データ処理実行過程（ストリーム圧縮後）に行なうもので、ストリーム使用量合計MSUM１が第２の規定メモリサイズMS_2を超える（溢れる）ようになると（Ｓ1040-Y）、圧縮閾値TH未満の蓄積型ストリームについて、メモリ容量を可能な限り削減するためにより圧縮率が小さくなるように可逆圧縮する処理である（Ｓ1042）。具体的には、蓄積型ストリームで、圧縮閾値THに達しないストリーム（ＲＡＷデータのストリーム）を圧縮する。

二次フォールバック処理は、データ処理実行過程（ストリーム圧縮後）に行なうもので、コントローラメインＣＰＵ５０を介したメインメモリ７０へのデータ転送（外部転送と称する）を行なう処理である。二次フォールバック処理は、外部バス９０、コントローラメインＣＰＵ５０を介したデータ転送になり、ＤＲＰ１０とローカルメモリ３０との間のデータ転送に比べると低速になるので、蓄積型ストリームに関しては、一次フォールバック処理でも対処不足のとき、つまり一次フォールバック処理を行なってもストリーム使用量合計MSUM１が第２の規定メモリサイズMS_2を超えメモリサイズを溢れるようになるときに、ストリーム使用量合計MSUM１が第３の規定メモリサイズMS_3を超える（溢れる）と二次フォールバック処理を行なうようにする（Ｓ1044-Y，Ｓ1048）。なお、蓄積型ストリームに関しての第３の規定メモリサイズMS_3は一次フォールバック処理で参照する第２の規定メモリサイズMS_2と同じであってもよい（好ましくは同じにする）。

たとえば、リコンフィグ制御部２０は、スタティック・スケジューリングのために、圧縮・伸長の頻度を低下させる閾値（スレッショルド）の考え方を導入する。このため、圧縮閾値THを、たとえば、メモリサイズ・リミット／ストリーム数（ローカルメモリ３０を利用する入出力ストリームの総本数：以下同様）や、領域サイズ（その時点で使用が許可されるメモリ量）／ストリーム数に従って計算する（Ｓ1010）。“圧縮閾値TH１＝メモリサイズ・リミット／ストリーム数”を第１定義式と称し、“圧縮閾値TH２＝領域サイズ／ストリーム数”を第２定義式と称する。たとえば、リコンフィグ制御部２０は、スタティック・スケジューリングのために、圧縮・伸長の頻度を低下させる閾値（スレッショルド）の考え方を導入する。このため、圧縮閾値THを、たとえば、メモリサイズ・リミット／ストリーム数（ローカルメモリ３０を利用するストリームの種類数：以下同様）や、領域サイズ（その時点で使用が許可されるメモリ量）／ストリーム数に従って計算する。

また、リコンフィグ制御部２０は、処理過程のデータである中間ストリームを、直近のパイプラインステージで直ぐ使う非蓄積型ストリームと、直近のパイプラインステージでは使わない蓄積型ストリームに分類し、圧縮時間や伸長時間の制約を導入し、圧縮や伸長を行なわなくても不都合がなければ圧縮処理や伸長処理を行なわないようにすることで、同一タイミングで圧縮や伸長を行なうストリーム本数を減らす。

そして、データ処理（本例では画像処理）を実行する前に、算出した各パイプラインステージの圧縮閾値THに基づいて、各パイプラインステージでのストリーム使用量合計MSUM１が第１の規定メモリサイズMS_1を越えないように圧縮対象のストリームをピックアップ（選定）し、そのストリームに対して圧縮（や、それに対応する伸長）を示唆（指示）するスタティック・スケジューリングを行なう（Ｓ1022）。たとえば、対象のパイプラインステージで取り扱うストリーム（入出力のストリーム）のデータ量（ストリーム量：本例ではユニット数）が圧縮閾値THを超えるストリームを圧縮の対象とする。

なお、ここでは、圧縮閾値THを判断指標にする例で説明したが、基本的な考え方は、各パイプラインステージでの処理時点において、ローカルメモリ３０を使用するストリーム量の合計がメモリ容量を超えないようにすることにあり、このような観点での判断指標である限り、その他の指標値を使用してよい。

このスタティック・スケジューリング指示を受けた画像処理リコンフィグ部１２は、圧縮対象としてピックアップされたストリームに対して、圧縮器Cmや伸長器Exを挿入する（Ｓ1022）。ここで、圧縮器Cmと伸長器Exの挿入箇所は、非蓄積型ストリームであるのか蓄積型ストリームであるのかに応じて使い分ける。詳細には後述するが、たとえば、非蓄積型ストリームの場合には同一のパイプラインステージ中に配置し、蓄積型ストリームの場合には別のパイプラインステージに配置する。

画像処理リコンフィグ部１２は、所要の箇所への圧縮器Cmや伸長器Exの挿入が完了すると、各パイプラインステージでは、ストリームをローカルメモリ３０から取り込んで、データ処理（本例の場合は画像処理）を開始する（Ｓ1030）。このとき、圧縮対象のストリームであれば、そのストリームを圧縮器Cmで圧縮する（Ｓ1032-Y，Ｓ1034）。

この画像処理過程では、並行して、リコンフィグ制御部２０は画像処理リコンフィグ部１２によるストリーム使用量合計MSUM１を監視している。そして、処理対象ストリームが蓄積型ストリームである場合に（Ｓ1036-Y）、ストリーム使用量合計MSUM１が第２の規定メモリサイズMS_2を溢れるようになると（Ｓ1040-Y）、圧縮率が不足（未圧縮のものも含む）の蓄積型ストリームについてメモリ容量を可能な限り削減するためにより圧縮率が小さくなるように可逆圧縮する一次フォールバック処理を画像処理リコンフィグ部１２に指示する。この一次フォールバック処理指示を受けた画像処理リコンフィグ部１２は、圧縮閾値TH未満の蓄積型ストリームを圧縮する（Ｓ1042）。この説明から理解されるように、本実施形態の場合、一次フォールバック処理は蓄積型ストリームについてのみ適用される。

リコンフィグ制御部２０は、その圧縮による実際の圧縮率に基づき、たとえば、ストリーム量やストリーム使用量合計MSUM１を計算し、ストリーム量やストリーム使用量合計MSUM１が第３の規定メモリサイズMS_3を溢れる状態であると（Ｓ1044-Y）、二次フォールバック処理を画像処理リコンフィグ部１２に指示する。この二次フォールバック処理指示を受けた画像処理リコンフィグ部１２は、蓄積型ストリームに関してはステップＳ1042による圧縮済みのストリームをホスト部５側であるコントローラメインＣＰＵ５０を介してメインメモリ７０に一時的に退避させる（Ｓ1048）。なお、ここでのストリーム量やストリーム使用量合計MSUM１を判断対象とする例は一例であり、その他の指標値を判断対象としてもよい。第３の規定メモリサイズMS_3は、その指標値が何れであるのかに応じて適正なものを使用する。

また、処理対象ストリームが非蓄積型ストリームである場合には（Ｓ1036-N）、たとえば、ステップＳ1034で圧縮処理した結果のストリーム量やストリーム使用量合計MSUM１が第３の規定メモリサイズMS_3を越えているときには、ステップＳ1034による圧縮済みのストリームをホスト部５側であるコントローラメインＣＰＵ５０を介してメインメモリ７０に一時的に退避させる（Ｓ1046-Y，Ｓ1048）。なお、ここでのストリーム量やストリーム使用量合計MSUM１を判断対象とするのは一例であり、その他の指標値を判断対象としてもよい。第３の規定メモリサイズMS_3は、その指標値が何れであるのかに応じて適正なものを使用する。

因みに、ＤＲＰ１０を使用して複数のコンフィギグレーションを切り替える本実施形態のデータ処理装置１では、その入出力の各ストリームを全て保持しなくてはならないので、典型的には、入出力の全てのストリーム使用量合計MSUM１がメモリ容量を超えないことが基本的な判断基準となると考えてよい。

次に、画像処理リコンフィグ部１２は、画像処理を実行する。このとき、必要に応じて圧縮・伸長を行ないながら（Ｓ1032-Y）、ローカルメモリ３０に空き容量があるときには（Ｓ1040-N，Ｓ1044-N，Ｓ1046-N）、ローカルメモリ３０との間でデータの読み書き（データ転送）を行ない、画像処理を実行する。ローカルメモリ３０に空き容量が無く、メインメモリ７０にストリームを退避させたときには（Ｓ1044-Y，Ｓ1046-Y，Ｓ1048）、画像処理リコンフィグ部１２は、必要に応じて圧縮・伸長を行ないながら（Ｓ1032-Y，Ｓ1042-Y）、コントローラメインＣＰＵ５０を介してメインメモリ７０との間でデータの読み書き（データ転送）を行ない、画像処理を実行する。

画像処理リコンフィグ部１２は、あるパイプラインステージでの画像処理が完了すると、ステップＳ1030に戻り、次段のパイプラインステージに移行し、前記と同様の処理を行なう。

＜動作例：第１実施形態の基本＞
図４〜図５Ａは、第１実施形態のデータ処理装置１における基本動作例を説明する図である。ここで、図４は、ストリームデータの種類とメモリ容量との関係を説明する図である。図５および図５Ａは、圧縮・伸長をパイプライン処理に組み込む場合の定義モデルを説明する図であり、図５は非蓄積型ストリームが主体の場合、図５Ａは蓄積型ストリームが主体の場合を示す。

たとえば、図４には、蓄積型ストリームが多い長いパイプラインの場合を例に、非蓄積型ストリーム（ハッチングなし）と蓄積型ストリーム（ハッチングあり）のそれぞれについて、メモリ容量との関係が示されている。

蓄積型ストリームは、直ぐには使用しないので、ローカルメモリ３０にはストリームが加算されていく。このため、図４に示すように、ストリームの総和（Σ）でメモリ使用量を圧迫することになる。たとえば、図４に示す想定パイプライン（イニシャル・パイプライン）においては、画像処理リコンフィグ部１２は、７段のパイプラインステージFunc１〜Func７を有している。前半の４段分のパイプラインステージFunc１〜Func４は、それ以前（直前とは限らない）のパイプラインステージで処理済みの非蓄積型ストリームを取り込んで処理を行なって非蓄積型ストリームと蓄積型ストリームを出力するようになっている。一方、後半の３段分のパイプラインステージFunc５〜Func７は、それ以前（直前とは限らない）のパイプラインステージで処理済みの非蓄積型ストリームと未処理の蓄積型ストリームを取り込んで処理を行なって非蓄積型ストリームを出力するようになっている。

具体的には、画像処理リコンフィグ部１２は、ローカルメモリ３０から１ユニットのStream１をFunc１に取り込み、Func１での処理により１ユニットの非蓄積型のStream２を出力してローカルメモリ３０に記憶するとともに、３ユニットの蓄積型のStream３を出力してローカルメモリ３０に記憶する。次に、画像処理リコンフィグ部１２は、ローカルメモリ３０から１ユニットのStream２をFunc２に取り込み、Func２での処理により１ユニットの非蓄積型のStream４を出力してローカルメモリ３０に記憶するとともに、４ユニットの蓄積型のStream５を出力してローカルメモリ３０に記憶する。

さらに、画像処理リコンフィグ部１２は、ローカルメモリ３０から１ユニットのStream４をFunc３に取り込み、Func３での処理により１ユニットの非蓄積型のStream６を出力してローカルメモリ３０に記憶するとともに、５ユニットの蓄積型のStream７を出力してローカルメモリ３０に記憶する。さらに、画像処理リコンフィグ部１２は、ローカルメモリ３０から１ユニットのStream６をFunc４に取り込み、Func４での処理により１ユニットの非蓄積型のStream８を出力してローカルメモリ３０に記憶するとともに、６ユニットの蓄積型のStream９を出力してローカルメモリ３０に記憶する。

さらに、画像処理リコンフィグ部１２は、１ユニットの非蓄積型のStream１０と３ユニットの蓄積型のStream３をローカルメモリ３０からFunc５に取り込み、Func５での処理により１ユニットの非蓄積型のStream１１を出力してローカルメモリ３０に記憶する。さらに、画像処理リコンフィグ部１２は、１ユニットの非蓄積型のStream１１と４ユニットの蓄積型のStream５をローカルメモリ３０からFunc６に取り込み、Func６での処理により１ユニットの非蓄積型のStream１２を出力してローカルメモリ３０に記憶する。最後に、１ユニットの非蓄積型のStream１２と５ユニットの蓄積型のStream７をローカルメモリ３０からFunc７に取り込み、Func７での処理により１ユニットの非蓄積型のStream１３を出力してローカルメモリ３０に記憶する。６ユニットの蓄積型のStream９は、別の処理プロセスで使用するようになっている。

この場合、４段目のパイプラインステージの時点（図中のＡ点）では、ローカルメモリ３０には、Func４の入出力で取り扱う蓄積型のStream６およびStream８用の２ユニット分と、非蓄積型のStream３，Stream５，Stream７，Stream９の各ストリーム量を加算した１８ユニット分がストリーム使用量合計MSUM１となり、その内の９０％（＝１８／２０）は蓄積型ストリームが占めることになる。本来、Func４が取り扱うストリーム量は、非蓄積型の入出力分（Stream６とStream８の各１ユニット分を加算した２ユニット分）と、蓄積型の出力分（Stream９の６ユニット分）の合計の８ユニット分に対して、使用量合計が２０ユニット分であるから、Func４が取り扱うストリーム量に対してストリーム使用量合計MSUM１は２．５倍になってしまう。これから分るように、ローカルメモリ３０の使用量に関しては、蓄積型ストリームのデータ量（蓄積ストリームサイズ）が問題となる。

ここで、蓄積型ストリームを可逆圧縮（圧縮率１／３を仮定）すると、ストリーム使用量合計MSUM１は、２＋１８／３＝８ユニット分となり、圧縮前の２０ユニット分との比較では８／２０＝４／１０となり、１００％−４０％＝６０％の削減となる。蓄積型ストリームサイズが１／４になると、ストリーム使用量合計MSUM１（メモリサイズ）は、４６％に削減される。

このように、ストリームを、蓄積型ストリームと非蓄積型ストリームで分けて管理することが、メモリ容量削減にとっては効果的である。非蓄積型ストリームは直ぐには使用しないので、圧縮処理や伸長処理の時間制約が緩やかに与えられる。これは、そのときに圧縮できなくても、後で圧縮してもメモリ削減効果があるからである。

＜定義モデル＞
たとえば、図５には、非蓄積型ストリームが主体の場合に、圧縮・伸長をパイプライン処理に組み込む場合の定義モデルが示されている。入出力ストリームは直近のパイプラインステージ（Func_@：データ処理）で使用され再利用されないので、このパイプラインステージでのデータ処理後にストリームを圧縮したのではメモリ削減の効果がでない。たとえば、図５（１）に示すように、３ユニットのStream１がFunc１に入力され、Func１でのデータ処理後に２ユニットのStream２が出力される場合を考える。この場合、Func１の入出力間における合計ストリームサイズが５ユニットであるので、これを削減したい場合は、別のパイプラインステージで圧縮・伸長しても効果がない。たとえば、図５（１）に示すように、Func１の後段で圧縮を行なっても、Func１にとっては、必要メモリサイズは５ユニットであることに変わりがないからである。

この対策としては、たとえば、同一ファンクション（パイプラインステージ）で圧縮・伸長することが（唯一の）メモリ削減対策となる。なお、「（唯一の）」と称したが、実際には、必須ではなく、圧縮器Cmや伸長器Exを同一のパイプラインステージ内に配するか否かを問わず、処理パスとして、圧縮されたストリームの供給を受ける→データ処理前に伸長→パイプラインステージでデータ処理→処理済みストリームを圧縮→…の順にすることが考えられる。たとえば、圧縮器Cmの平均圧縮率を１／２と仮定すると、必要メモリサイズは１／２となる。ただし、圧縮器Cmや伸長器Exを物理的に同一のパイプラインステージ（本例ではFunc１）内に配する構成を採用すると、図５（２）に示すように、その同一パイプラインステージの入力側に伸長器Exを、出力側に圧縮器Cmを配置しなければならず、パイプラインステージとして、より多くのハードウェアリソースが必要となる。

一方、図５Ａには、蓄積型ストリームが主体の場合に、圧縮・伸長をパイプライン処理に組み込む場合の定義モデルが示されている。入出力ストリームは直近のパイプラインステージ（Func_@：データ処理）で使用された後、後続（直後は非蓄積型ストリームを供給すればよいので除く）のパイプラインステージで再利用される。このため、必要となる段階までローカルメモリ３０などに待機させておくことになり、これが重畳されると、メモリサイズが飛躍的に増加する。図４に示したことから理解されるように、蓄積型ストリームを圧縮すると、メモリ削減効果が出る。

たとえば、図５Ａ（１）に示す例では、ローカルメモリ３０から１ユニットのStream１をFunc１に取り込み、Func１での処理により１ユニットの非蓄積型のStream２を出力してローカルメモリ３０に記憶するとともに、３ユニットの蓄積型のStream３を出力してローカルメモリ３０に記憶する。次に、画像処理リコンフィグ部１２は、ローカルメモリ３０から１ユニットのStream２をFunc２に取り込み、Func２での処理により１ユニットの非蓄積型のStream４を出力してローカルメモリ３０に記憶するとともに、４ユニットの蓄積型のStream５を出力してローカルメモリ３０に記憶する。再び直ぐには使用されない蓄積型ストリームを加算すると、１０ユニットであり、２／３を占める。長いパイプラインの場合は、ストリーム使用量合計MSUM１は蓄積型ストリームが支配的となる。

この対策としては、後続のパイプラインステージに圧縮器Cmを挿入し、蓄積型ストリームを削減してローカルメモリ３０に記憶すればよい。たとえば、図５Ａ（２）に示す例では、Func２の後段のFunc３に圧縮器Cmを配置すればよい。Func３では、Func２から出力された４ユニットのStream５を取り込み、１／２に圧縮して２ユニットのStream７にしてローカルメモリ３０に記憶する。

Func２の入出力に着目したとき、図５Ａ（１）に示す非圧縮時には、非蓄積型ストリームのストリーム使用量はStream２，Stream４の各１ユニットを算した２ユニット、蓄積型ストリームのストリーム使用量はStream３の３ユニットとStream５の４ユニットを加算した７ユニットであり、ストリーム使用量合計MSUM１は９ユニットとなる。一方、図５Ａ（２）に示す圧縮時には、非蓄積型ストリームのストリーム使用量はStream２，Stream４の各１ユニットを加算した２ユニット、蓄積型ストリームのストリーム使用量はStream３の３ユニットとFunc３による圧縮済のStream７の２ユニットを加算した５ユニットであり、ストリーム使用量合計MSUM１は７ユニットとなる。よって、必要メモリサイズは、９ユニットから７ユニットに削減される。

＜第１例：第１実施形態＞
図６は、第１実施形態のデータ処理装置１における第１例を説明する図である。第１例は、処理対象ストリームが非蓄積型ストリームのみである場合の一例であり、スタティック・スケジューリングによる圧縮器Cmおよび伸長器Exの追加と、実際に圧縮したときに圧縮率が不足した際の二次フォールバック処理の適用例である。第１実施形態では、圧縮閾値THの定義式として、第１定義式を適用する（図ではTHで記す）。

ここでは、平均圧縮率が１／２（５０％）、図６（１）に示すメモリ・マッピングのようにメモリサイズは４ユニット、メモリサイズ・リミット（メモリサイズの限界）は３ユニットでこの分を非蓄積型ストリーム領域として確保し、残りの１ユニット分はバッファ領域として確保し、図６（２）に示すような非蓄積型ストリームを取り扱う想定パイプライン（イニシャル・パイプライン）とする。非蓄積型ストリーム領域が３ユニットであるので、各パイプラインステージで取り扱う非蓄積型ストリームの最大ストリーム量は３ユニットと仮定する。

ここで、メモリサイズとメモリサイズ・リミットを設けたのは、比較例（図２）での説明のように、可逆圧縮を採用するためである。第１例では、スタティック・スケジューリングではメモリサイズ・リミットを第１の規定メモリサイズMS_1とし、ダイナミック・スケジューリング（特に二次フォールバック処理）ではメモリサイズを第３の規定メモリサイズMS_3として参照する。また、圧縮挿入までの時間制約（Time Constraint ）は１Functionとする。各パイプラインステージ（本例ではFunc１，Func２）は、何れも、圧縮器Cmおよび伸長器Exを挿入し得るものとする。

リコンフィグ制御部２０は、スタティック・スケジューリングのため、先ず、パイプラインステージごとに、メモリサイズ・リミット／ストリーム数に従って、圧縮閾値TH１を計算する（Ｓ1010）。ここで、このような計算式（第１定義式）を使用するのは、圧縮対象のストリームを判断するためである。

本例の場合、Func１はStream１（３ユニットが最大），Stream２（３ユニットが最大）を入出力とするのでストリーム数は２であり、圧縮閾値TH１_1＝メモリサイズ・リミット／ストリーム数＝３／２＝１．５となる。Func２はStream２，Stream３（０．８ユニットが最大）を入出力とするのでストリーム数は２であり、圧縮閾値TH１_2＝メモリサイズ・リミット／ストリーム数＝３／２＝１．５となる。

リコンフィグ制御部２０は、パイプラインステージごとに、計算した圧縮閾値TH１_1，TH１_2と、各Stream１（３ユニットが最大），Stream２（３ユニットが最大），Stream３（０．８ユニットが最大）を比較し、そのストリーム量（ユニット数）が圧縮閾値TH１_1，TH１_2を超えるストリームを圧縮・伸長の対象とする。本例の場合、リコンフィグ制御部２０は、Stream１，Stream２（Stream３以外）を圧縮の対象とする。スタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加が適用し得るケースであれば（Ｓ1012-Y）、リコンフィグ制御部２０は画像処理リコンフィグ部１２に指示する。

このスタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加指示を受けた画像処理リコンフィグ部１２は、図６（３）に示すように、Stream１，Stream２を入出力ストリームにするパイプラインステージであるFunc１について、入力側に伸長器Exを挿入し、出力側に圧縮器Cmを挿入する。また、Stream２を入力ストリームにするパイプラインステージであるFunc２について、入力側に伸長器Exを挿入する。画像処理リコンフィグ部１２は、ローカルメモリ３０との間でStream１のデータ転送を行ないながらFunc１で圧縮済のStream１を伸長器Exで伸長してデータ処理（画像処理）を行ない処理済みのStream２を圧縮器Cmで圧縮して出力する。また、画像処理リコンフィグ部１２は、ローカルメモリ３０との間でStream２のデータ転送を行ないながらFunc２で圧縮済のStream２を伸長器Exで伸長してデータ処理（画像処理）を行ない処理済みのStream３を出力する。

なお、Stream１の圧縮は、ホスト処理で行なう。ここで、ホスト処理とは、コントローラメインＣＰＵ５０でStream１を圧縮して、ＤＲＰ１０のローカルメモリ３０に転送することである。

この場合は、圧縮器Cmの平均圧縮率は１／２なので、Func１の入出力間のストリーム使用量の合計は、当然に“１．５＋１．５＝３．０”であり、必要メモリサイズは、６から３に削減され、破綻を来たすことはない。ただし、平均圧縮率は予測値であり、１／２を超えることもあり、場合によっては、破綻を来たすことがある。たとえば、Stream１の実際の圧縮率が５０％、Stream２の実際の圧縮率が９５％になるケースでは、ストリーム使用量合計MSUM１は、１＋２．８５＝３．８５＜４（メモリサイズ）であり、このように、実際の圧縮率が１／２を超える場合でも、ストリーム使用量合計MSUM１がメモリサイズを超えなければ、ローカルメモリ３０との間でのデータ転送で対処できる。

一方、図６（４）に示すように、Stream１の実際の圧縮率が１／３、Stream２の実際の圧縮率が１１３％になるケースでは、ストリーム使用量合計MSUM１は、１＋３．４＝４．４＞４（メモリサイズ）となり、ローカルメモリ３０との間でのデータ転送では対処できなくなる。その対策として、第１例では、リコンフィグ制御部２０は、非蓄積型ストリーム（ここではStream２）に対して二次フォールバック処理を適用するように、画像処理リコンフィグ部１２に指示する。

因みに、このケースでは、圧縮率が１００％までなら、二次フォールバックは発生しない。つまり、圧縮した結果、メモリサイズを越えているため、ホスト部５側であるコントローラメインＣＰＵ５０を介したメインメモリ７０との間でのデータ転送が発生する。一次フォールバック処理は蓄積型ストリームでのみ発生する。非蓄積型ストリームはその場で消えるため、一次フォールバック対象が「ない」ためである。つまり、一次フォールバックを経由せずに、いきなり二次フォールバックが発生する。

Stream２について二次フォールバック処理の指示を受けた画像処理リコンフィグ部１２は、図６（４）に示すように、二次フォールバック処理により、外部バス９０およびコントローラメインＣＰＵ５０を介してメインメモリ７０との間で圧縮済のStream２のデータ転送を行ないながらFunc２で圧縮済のStream２を伸長器Exで伸長してデータ処理（画像処理）を行ない、処理済みのStream３を出力する。つまり、メモリサイズを越える場合、圧縮済部分をメインメモリ７０側に送信する。

なお、バンド圧縮を適用してもよい。バンド圧縮とは、メモリサイズを超えた場合、その段階で一旦、圧縮を完了させ、メインメモリに転送後、残りのデータを圧縮する処理である。すなわち、１つのストリームを複数の圧縮データに分割することである。

＜第２例：第１実施形態＞
図７は、第１実施形態のデータ処理装置１における第２例を説明する図である。第２例は、処理対象ストリームが非蓄積型ストリームのみである場合の一例であり、スタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加ができないケースでの適用例である。因みに、後述のように、第２例ではダイナミック・スケジューリングの適用はない。

ここでは、平均圧縮率が１／２（５０％）、図７（１）に示すメモリ・マッピングのようにメモリサイズは６ユニット、メモリサイズ・リミット（メモリサイズの限界）は５ユニットで残りの１ユニットはバッファ領域とし、メモリサイズ・リミットの内、３ユニット分は非蓄積型ストリームを格納する非蓄積型ストリーム領域に割り当て、２ユニット分は非蓄積型ストリームの一部についてバンディング処理用に処理を待機させるための非蓄積型ストリームを蓄積型ストリームとして格納する蓄積型ストリーム領域に割り当てる。非蓄積型ストリーム領域が３ユニットであるので、各パイプラインステージで取り扱う非蓄積型ストリームの最大ストリーム量は３ユニットと仮定する。また、図７（２）に示すような非蓄積型ストリームを取り扱う想定パイプライン（イニシャル・パイプライン）とする。また、スタティック・スケジューリングでは、第１例と同様に、メモリサイズ・リミットを第１の規定メモリサイズMS_1とする。また、圧縮挿入までの時間制約（Time Constraint ）は１Functionとする。さらに、各パイプラインステージ（図ではFunc１，Func２）では、「圧縮器Cmおよび伸長器Exの追加ができない」とは言っても、何れか一方（圧縮器Cm or 伸長器Ex）を挿入し得るものとする。

リコンフィグ制御部２０は、スタティック・スケジューリングのため、先ず、パイプラインステージごとに圧縮閾値THを計算する（Ｓ1010）。本例の場合、Func１はStream１（３ユニットが最大），Stream２（３ユニットが最大）を入出力とするのでストリーム数は２であり、圧縮閾値TH１_1＝メモリサイズ・リミット／ストリーム数＝５／２＝２．５となる。Func２はStream２，Stream３（０．８ユニットが最大）を入出力とするのでストリーム数は２であり、圧縮閾値TH１_2＝メモリサイズ・リミット／ストリーム数＝５／２＝２．５となる。

リコンフィグ制御部２０は、パイプラインステージごとに、計算した圧縮閾値TH１_1，TH１_2と、各Stream１（３ユニットが最大），Stream２（３ユニットが最大），Stream３（０．８ユニットが最大）を比較し、そのストリーム量（ユニット数）が圧縮閾値TH１_1，TH１_2を超えるストリームを圧縮・伸長の対象とする。本例の場合、リコンフィグ制御部２０は、Stream１，Stream２（Stream３以外）を圧縮の対象とする。スタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加が適用し得るケースであれば（Ｓ1012-Y）、リコンフィグ制御部２０は画像処理リコンフィグ部１２に指示するのであるが、本例ではそれができないので、リコンフィグ制御部２０は、バンディング処理の適用を画像処理リコンフィグ部１２に指示する（Ｓ1012-N）。

このスタティック・スケジューリングによバンディング処理指示を受けた画像処理リコンフィグ部１２は、図７（３）に示すように、先ず、Stream１の圧縮は、ホスト処理で行なう。

また、リコンフィグ制御部２０は、画像処理リコンフィグ部１２に対して、Stream１（Func１の入力ストリーム），Stream２（Func１の出力ストリーム、Func２の入力ストリーム）のローカルメモリ３０との間のデータ転送を、所定サイズに分けて行なうように指示する。所定サイズに分けてローカルメモリ３０との間でデータ転送を行なうには、非蓄積型ストリームであるStream１，Stream２の一部（分けた部分で直ちには使用されない部分）についてバンディング処理用に処理を待機させる必要があるため、その部分を蓄積型ストリームとして内部的には取り扱い、ローカルメモリ３０の蓄積型ストリーム領域に格納しておく。

たとえば、バンディング処理の適用に当たっては、以下のような手順を踏む。先ず、リコンフィグ制御部２０は、ストリームサイズ（ストリーム使用量合計MSUM１）／メモリサイズを算出し、算出結果に最も近く、大きな整数を分割数Ｄとする。本例の場合、ストリーム使用量合計MSUM１＝６で、メモリサイズ（非蓄積型ストリーム領域）＝３であり、前記の計算値は２となるので、分割数Ｄは２とする。

次に、画像処理リコンフィグ部１２は、Stream１を求めた分割数Ｄで分けて、ローカルメモリ３０との間でデータ転送を行ないながらデータ処理（画像処理）を行なう。このとき、非蓄積型ストリーム（Stream１）において、パイプラインステージ（Func１，Func２）に圧縮が入らない場合、圧縮ファンクション挿入による強制圧縮は意味を持たない。これは、一旦、ＲＡＷデータをローカルメモリ３０に出力してしまうことになるからである。よって、パイプラインステージ（ファンクション：Func）には圧縮が入らず、図７（３）のように、Stream１，Stream２を入出力ストリームにするパイプラインステージであるFunc１について、入力側に伸長を配置する。以降は、分割したストリーム量ずつ（本例ではStream１について１．５ユニットずつ）、ＲＡＷデータによるバンディング処理となる。つまり、圧縮しないので（詳しくは、バンディング処理によりメモリオーバーフローを起さないように対処するので）、フォールバックは発生しない。

画像処理リコンフィグ部１２は、１回目の処理では、圧縮された１．５ユニットのStream１の内の半分しか伸長を行なわず、ローカルメモリ３０の非蓄積型ストリーム領域との間でデータ転送をしつつ、Func１でデータ処理（画像処理）を行ない処理済みのStream２（１．５ユニットが最大）を出力する。１．５ユニットのStream１はローカルメモリ３０の蓄積型ストリーム領域に格納しておく。蓄積型ストリームのストリーム使用量合計MSUM１は１．５であり蓄積型ストリーム領域のサイズ（＝２）を超えない。また、画像処理リコンフィグ部１２は、ローカルメモリ３０の非蓄積型ストリーム領域との間でStream２（１．５ユニットが最大）のデータ転送を行ないながらFunc２でデータ処理（画像処理）を行ない処理済みのStream３（０．４ユニットが最大）を出力する。これで、１回目の処理が完了する。この１回目のFunc１での処理過程では、非蓄積型ストリームのストリーム使用量合計MSUM１は３．０（＝１．５＋１．５）であり非蓄積型ストリーム領域のサイズ（＝３）を超えないので、ローカルメモリ３０との間でのデータ転送には破綻を来たさない。

続く２回目の処理では、先ず、処理済みの０．４ユニットのStream３を蓄積型ストリームとして扱い、ローカルメモリ３０の蓄積型ストリーム領域に格納しておく。この格納時点では、蓄積型ストリームのストリーム使用量合計MSUM１は１．９（＝１．５＋０．４）であり蓄積型ストリーム領域のサイズ（＝２）を超えないので破綻を来たすことはない。次に、一時的にローカルメモリ３０の蓄積型ストリーム領域に格納しておいた１．５ユニットのStream１の内の残りの半分を処理対象として、前述と同様の処理を行なう。すなわち、画像処理リコンフィグ部１２は、圧縮された１．５ユニットのStream１の内の残りの半分についてローカルメモリ３０の非蓄積型ストリーム領域との間でデータ転送をしつつ、Func１でデータ処理（画像処理）を行ない処理済みのStream２（１．０ユニットが最大）を出力する。また、画像処理リコンフィグ部１２は、ローカルメモリ３０の非蓄積型ストリーム領域との間でStream２（１．０ユニットが最大）のデータ転送を行ないながらFunc２でデータ処理（画像処理）を行ない処理済みのStream３（０．４ユニットが最大）を出力する。これで、２回目の処理が完了する。この２回目のFunc１での処理過程では、非蓄積型ストリームのストリーム使用量合計MSUM１は２．５（＝１．５＋１．０）であり非蓄積型ストリーム領域のサイズ（＝３）を超えないので、ローカルメモリ３０との間でのデータ転送には破綻を来たさない。

なお、分割数Ｄに従って処理対象データであるストリームを分割して処理を行なうバンディング処理を適用した場合、ローカルメモリ３０との間でのデータ転送回数が増えるので、処理時間が増加することが懸念される。その対策として、バンディング処理を適用せずに、二次フォールバック処理を適用することが考えられる。しかしながら、二次フォールバック処理におけるメインメモリ７０との間でのデータ転送は、外部バス９０やコントローラメインＣＰＵ５０を介したデータ転送となり、そもそものデータ転送効率はローカルメモリ３０を利用するデータ転送（事実上の内部的なデータ転送）に比べると遙かに悪い。ローカルメモリ３０を利用したときのデータ転送速度E_30とメインメモリ７０を利用したときのデータ転送速度E_70との比ER（＝E_30／E_70）は、たとえば１０倍以上になる。よって、分割数Ｄがあまり大きくない限りは、バンディング処理を適用した方が、全体の処理効率がよい。もちろん、分割数Ｄと転送速度比ERを比較したときに、分割数Ｄ＞転送速度比ERとなるときには、バンディング処理ではなく、二次フォールバック処理を適用してもよい。

＜第３例：第１実施形態＞
図８は、第１実施形態のデータ処理装置１における第３例を説明する図である。第３例は、圧縮対象となるストリームが蓄積型ストリームである場合の一例である。第３例では、圧縮閾値THの定義式として、第２定義式を適用する（図ではTHで記す）。

ここでは、平均圧縮率が１／２（５０％）、図８（１）に示すメモリ・マッピングのようにメモリサイズは７ユニット、メモリサイズ・リミット（メモリサイズの限界）は５ユニットで残りの１ユニットはバッファ領域とし、メモリサイズ・リミットの内、２ユニット分は非蓄積型ストリームを格納する非蓄積型ストリーム領域に割り当て、４．５ユニット分は蓄積型ストリームを格納する蓄積型ストリーム領域に割り当てる。本例では、圧縮対象となるストリームが蓄積型ストリームであるとする例であり、非蓄積型ストリーム領域が２ユニットであるので、各パイプラインステージで取り扱う非蓄積型ストリームの最大ストリーム量は、２ユニットを入出力で等分して１ユニットと仮定する。

また、図８（２）に示すような非蓄積型ストリームと蓄積型ストリームを取り扱う想定パイプライン（イニシャル・パイプライン）とする。また、スタティック・スケジューリングでは、第１例と同様に、メモリサイズ・リミットを第１の規定メモリサイズMS_1とする。また、圧縮挿入までの時間制約（Time Constraint ）は１Functionとする。さらに、各パイプラインステージ（図ではFunc１，Func２，Func３）では、圧縮器Cmおよび伸長器Ex（圧縮器Cm or 伸長器Ex）を挿入し得るものとする。また、蓄積型メモリサイズＴＨは９０％とする。蓄積型メモリサイズＴＨとは、蓄積型ストリーム領域のメモリオーバーを防ぐための閾値である。

リコンフィグ制御部２０は、スタティック・スケジューリングのため、先ず、パイプラインステージごとに領域サイズ／ストリーム数に従って圧縮閾値TH２を計算する（Ｓ1010）。領域サイズは、その時点で使用が許可されるメモリ量であるが、本例では、第１ステージ（Func１）の領域サイズは５ユニット（＝メモリサイズ・リミット）であり、第２ステージ（Func２）の領域サイズはメモリサイズ・リミット＝５ユニットから蓄積型のStream３のストリーム量分（＝１）を差し引いた４ユニットになる。

よって、本例の場合、Func１はStream１（１ユニットが最大），Stream２（１ユニットが最大），Stream３（１ユニットが最大）を入出力とするのでストリーム数は３であり、圧縮閾値TH２_1＝領域サイズ／ストリーム数＝５／３＝１．６（近似値）となる。圧縮閾値TH２_1を超えるストリームは存在しないので、リコンフィグ制御部２０は、圧縮対象が無いと判断する。

Func２はStream２，Stream４（１ユニットが最大），Stream５（３ユニットが最大）を入出力とするが既にローカルメモリ３０にはStream３が記憶されているので、Func２での処理時点ではローカルメモリ３０との関係における取り扱うストリーム数が４となり、圧縮閾値TH２_2＝領域サイズ／ストリーム数＝４／４＝１．０となる。Stream５（３ユニットが最大）は圧縮閾値TH２_2を超えるので、リコンフィグ制御部２０は、Stream５を圧縮対象と判断する。

スタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加が適用し得るケースであれば（Ｓ1012-Y）、リコンフィグ制御部２０は画像処理リコンフィグ部１２に指示する。このスタティック・スケジューリングによる圧縮器Cmおよび伸長器Ex（圧縮器Cm＆伸長器Ex）の追加指示を受けた画像処理リコンフィグ部１２は、図８（３）に示すように、Func２とFunc３との間に、Stream５に対しての圧縮器Cmを挿入する。

画像処理リコンフィグ部１２は、ローカルメモリ３０との間でStream１のデータ転送を行ないながらFunc１でデータ処理（画像処理）を行ない処理済みのStream２，Stream３を出力する。また、画像処理リコンフィグ部１２は、ローカルメモリ３０との間でStream２のデータ転送を行ないながらFunc２でデータ処理（画像処理）を行ない処理済みのStream４，Stream５を出力する。さらに、画像処理リコンフィグ部１２は、ローカルメモリ３０との間でStream５のデータ転送およびFunc３での圧縮を行ない（その間はStream４に対する処理を待機（Wait）する）ローカルメモリ３０の蓄積型ストリーム領域に格納し、圧縮が完了すると、Func３でデータ処理（画像処理）を行ない処理済みのStream６を出力する。

この場合は、圧縮器Cmの平均圧縮率は１／２なので、Stream５に対しての圧縮後のストリーム量は１．５ユニットになる。

ただし、平均圧縮率は予測値であり、１／２を超えることもあり、場合によっては、破綻を来たすことがある。たとえば、Stream３の実際の圧縮率が５０％、Stream５の実際の圧縮率が１００％になるケースでは、ローカルメモリ３０との間でのデータ転送では対処できなくなる。その対策として、第３例では、図８（４）に示すように、リコンフィグ制御部２０は、非蓄積型ストリーム（ここではStream５）に対して二次フォールバック処理を適用するように、画像処理リコンフィグ部１２に指示する。つまり、Stream５に圧縮を適用したとしても実際の圧縮率が十分でなく、蓄積型メモリサイズＴＨを越えたままであるため、ダイナミック・スケジューリングでホスト部５側のメインメモリ７０へのデータ転送が行なわれる。なお、この後の画像処理で蓄積型ストリーム領域がオーバーフローする場合、ホスト部５へのデータ転送が行なわれるが、それまでに圧縮された部分はそのまま利用されるので、再圧縮は行なう必要がない。

＜蓄積型ストリームのスタティック・スケジューリング＞
図９は、第１実施形態のデータ処理装置１における、蓄積型ストリームのスタティック・スケジューリング処理の詳細を説明するフローチャートである。

先ず、リコンフィグ制御部２０は、オペレータＮを“１”に設定することで、１段目のファンクション（Func１）を割り当てる（Ｓ1100）。そして、リコンフィグ制御部２０は、圧縮閾値THを計算した後（Ｓ1112）、Ｎ＝１に関してのイニシャルStreamの処理を行なう。具体的には、リコンフィグ制御部２０は、「入力Streamが圧縮閾値THを越えているか？」を判断し（Ｓ1114）、イエスであればホスト部５（コントローラメインＣＰＵ５０）で圧縮してデータ転送をするように指示し（Ｓ1114-Y，Ｓ1116）、ノーであればホスト部５（コントローラメインＣＰＵ５０）から圧縮なしでデータ転送するように指示する（Ｓ1114-N，Ｓ1118）。

次に、リコンフィグ制御部２０は、パイプライン管理テーブルTB10を参照して、「伸長器挿入待ちの入力Streamはあるか？」を確認する（Ｓ1120）。

次に、リコンフィグ制御部２０は、「ファンクションＮ（FuncＮ）に伸長器Exが挿入可能か？」を判断し（Ｓ1124）、イエスであればファンクションＮに伸長器Exを挿入し（Ｓ1124-Y，Ｓ1126）、ノーであれば「該Streamの伸長器挿入器時間制約範囲内か？」を判断する（Ｓ1130）。なお、伸長器挿入の時間制約は、使う時点から遡る最大時間長で定義される。リコンフィグ制御部２０は、ノーであれば伸長ファンクションの強制挿入を画像処理リコンフィグ部１２に指示し（Ｓ1130-N，Ｓ1132）、イエスであれば伸長器挿入待ちStreamとしてStream管理テーブルTB11に（再）登録する（Ｓ1130-Y，Ｓ1134）。ステップＳ1120でノーのときを含めてこれら一連の処理が完了するまで（Ｓ1120〜Ｓ1134）が、伸長器挿入処理である。

伸長器挿入処理が完了すると、次にリコンフィグ制御部２０は、「圧縮器挿入待ちの入力Streamはあるか？」を判断し（Ｓ1140）、イエスであれば「ファンクションＮに圧縮器Cmが挿入可能か？」を判断し（Ｓ1140-Y，Ｓ1142）、イエスであればファンクションＮへの圧縮器Cmの挿入を画像処理リコンフィグ部１２に指示する（Ｓ1142-Y，Ｓ1144）。ステップＳ1142でノーであれば、リコンフィグ制御部２０は、該Streamの圧縮器挿入時間制約範囲内か？」を判断する（Ｓ1150）。なお、圧縮器挿入の時間制約は、該Stream生成時点から経過した最大時間長で定義される。リコンフィグ制御部２０は、ノーであれば圧縮ファンクションの強制挿入を画像処理リコンフィグ部１２に指示し（Ｓ1150-N，Ｓ1152）、イエスであれば圧縮器挿入待ちStreamとしてStream管理テーブルTB12に登録する（Ｓ1150-Y，Ｓ1154）。ステップＳ1140でノーのときを含めてこれら一連の処理が完了するまで（Ｓ1140〜Ｓ1154）が、圧縮器挿入処理である。

圧縮器挿入処理が完了すると、リコンフィグ制御部２０は、オペレータＮに“１”を加算して次段のファンクションを割り当て（Ｓ1160）、ステップＳ1120に戻り、前記と同様の処理を繰り返す。

＜蓄積型ストリームのダイナミック・スケジューリング＞
図１０は、第１実施形態のデータ処理装置１における、蓄積型ストリームのダイナミック・スケジューリング処理の詳細を説明するフローチャートである。

先ず、リコンフィグ制御部２０は、オペレータＮを“１”に設定することで、１段目のファンクション（Func１）を割り当てる（Ｓ1200）。そして、リコンフィグ制御部２０と画像処理リコンフィグ部１２は、図９に示したスタティック・スケジューリング処理と同様の伸長器挿入処理を実行し（Ｓ1210）、さらに、図９に示したスタティック・スケジューリング処理と同様の圧縮器挿入処理を実行する（Ｓ1230）。この後、画像処理リコンフィグ部１２は、ファンクションＮの画像処理を実行する（Ｓ1250）。

次に、リコンフィグ制御部２０は、「ファンクションＮまでの蓄積型入出力Streamサイズ合計値＞蓄積型Stream領域サイズ」を満たすか否かを判断する（Ｓ1260）。「出力Stream圧縮率が圧縮率平均値を上回った（悪い）か？既に領域サイズ・リミットに達した。」である。なお、圧縮率は「圧縮後Streamサイズ／圧縮前Streamサイズ」である。

ステップＳ1260での判断がノーであれば、リコンフィグ制御部２０は、「蓄積型Streamサイズ＞圧縮ＴＨ」を満たすか否かを判断し（Ｓ1270）、イエスであればStream管理テーブルTB13へ該Streamを登録（圧縮・伸長待ち）する（Ｓ1272）。

ステップＳ1260での判断がイエスであれば、リコンフィグ制御部２０は、画像処理リコンフィグ部１２に対して二次フォールバック処理を指示する（Ｓ1280）。具体的には、リコンフィグ制御部２０は、ホスト部５（コントローラメインＣＰＵ５０、メインメモリ７０）へ該Streamをデータ転送するよう画像処理リコンフィグ部１２に指示する（Ｓ1282）。この指示を受けた画像処理リコンフィグ部１２は、今までローカルメモリ３０に出力した分を含め、コントローラメインＣＰＵ５０側にデータ転送する。

次に、画像処理リコンフィグ部１２は、圧縮ファンクションを強制挿入して圧縮処理（を実行する（Ｓ1284）。「圧縮ファンクションの強制挿入」とは、そのファンクション（パイプラインステージ）に圧縮器を強制的に挿入すると言う意味である。画像処理リコンフィグ部１２は、Stream管理情報テーブルTB14を参照して、該当Streamを知り、圧縮閾値TH未満の蓄積型Streamを、挿入した圧縮器を使用して圧縮する。

なお、伸長器挿入処理は、Stream管理テーブルTB15を参照して行なう（該Streamが伸長必要なことを知る）。

前記の一連の処理が完了すると、リコンフィグ制御部２０は、オペレータＮに“１”を加算して次段のファンクションを割り当て（Ｓ1290）、ステップＳ1210に戻り、前記と同様の処理を繰り返す。

＜非蓄積型ストリームのスタティック・スケジューリング＞
図１１は、第１実施形態のデータ処理装置１における、非蓄積型ストリームのスタティック・スケジューリング処理の詳細を説明するフローチャートである。

リコンフィグ制御部２０は、オペレータＮを“１”に設定することで、１段目のファンクション（Func１）を割り当てる（Ｓ1300）。

リコンフィグ制御部２０は、圧縮閾値THを計算した後（Ｓ1312）、Ｎ＝１に関してのイニシャルStreamの処理を行なう。具体的には、リコンフィグ制御部２０は、「入力Streamが圧縮閾値THを越えているか？」を判断し（Ｓ1314）、イエスであればホスト部５（コントローラメインＣＰＵ５０）で圧縮してデータ転送をするように指示し（Ｓ1314-Y，Ｓ1316）、ノーであればホスト部５（コントローラメインＣＰＵ５０）から圧縮なしでデータ転送するように指示する（Ｓ1314-N，Ｓ1318）。

リコンフィグ制御部２０は、パイプライン管理テーブルTB16を参照して、「入力Streamが圧縮されているか？」を確認する（Ｓ1320）。

次に、リコンフィグ制御部２０は、ステップＳ1320でイエスであれば、「ファンクションＮ（FuncＮ）に伸長器Exが挿入可能か？」を判断し（Ｓ1324）、イエスであればファンクションＮに伸長器Exを挿入し（Ｓ1324-Y，Ｓ1326）、ノーであれば「伸長ファンクションを強制挿入」する（Ｓ1330）。次に、リコンフィグ制御部２０は、バンディング処理用の分割数を計算し、画像処理リコンフィグ部１２に対して、ストリームのローカルメモリ３０との間のデータ転送に当たり、ＲＡＷデータを所定サイズに分けて行なうバンディング処理を指示する（Ｓ1332）。ステップＳ1320でノーのときを含めてこれら一連の処理が完了するまで（Ｓ1320〜Ｓ1332）が、伸長器挿入処理である。

次に、リコンフィグ制御部２０は、「出力Streamサイズが圧縮ＴＨを越えている？」を確認し（Ｓ1340）、イエスであれば「ファンクションＮ（FuncＮ）に圧縮器Cmが挿入可能か？」を判断し（Ｓ1344）、イエスであればファンクションＮに圧縮器Cmを挿入し（Ｓ1344-Y，Ｓ1346）、ノーであればバンディング処理用の分割数を計算し、画像処理リコンフィグ部１２に対して、ストリームのローカルメモリ３０との間のデータ転送に当たり、ＲＡＷデータを所定サイズに分けて行なうバンディング処理を指示する（Ｓ1352）。ステップＳ1340でノーのときを含めてこれら一連の処理が完了するまで（Ｓ1340〜Ｓ1352）が、圧縮器挿入処理である。

圧縮器挿入処理が完了すると、リコンフィグ制御部２０は、オペレータＮに“１”を加算して次段のファンクションを割り当て（Ｓ1360）、ステップＳ1320に戻り、前記と同様の処理を繰り返す。

＜非蓄積型ストリームのダイナミック・スケジューリング＞
図１２は、第１実施形態のデータ処理装置１における、非蓄積型ストリームのダイナミック・スケジューリング処理の詳細を説明するフローチャートである。非蓄積型ストリームでは、実際の圧縮率が平均圧縮率を上回った（悪い）場合に、該ストリームをホスト部５（コントローラメインＣＰＵ５０やメインメモリ７０）へデータ転送（二次フォールバック処理）を行なうスケジューリングのみが追加される。つまり、非蓄積型ストリームではメモリ量削減のために圧縮ファンクションを挿入することは意味をもたない。

リコンフィグ制御部２０は、オペレータＮを“１”に設定することで、１段目のファンクション（Func１）を割り当てる（Ｓ1400）。

リコンフィグ制御部２０は、圧縮閾値THを計算した後（Ｓ1412）、Ｎ＝１に関してのイニシャルStreamの処理を行なう。具体的には、リコンフィグ制御部２０は、「入力Streamが圧縮閾値THを越えているか？」を判断し（Ｓ1414）、イエスであればホスト部５（コントローラメインＣＰＵ５０）で圧縮してデータ転送をするように指示し（Ｓ1414-Y，Ｓ1416）、ノーであればホスト部５（コントローラメインＣＰＵ５０）から圧縮なしでデータ転送するように指示する（Ｓ1414-N，Ｓ1418）。

画像処理リコンフィグ部１２は、ホスト部５から送られてくるストリームに対してファンクションＮの画像処理を実行する（Ｓ1420）。リコンフィグ制御部２０は、ファンクションＮから出力される出力Streamサイズを監視し「出力Streamサイズが非蓄積型Streamメモリサイズを越えている？」かを確認する（Ｓ1422）。イエスであれば、リコンフィグ制御部２０は、Stream管理テーブルTB17に該Streamの保管場所、圧縮・非圧縮を登録し、ホスト部５（コントローラメインＣＰＵ５０、メインメモリ７０）へ該Streamをデータ転送するように、つまり、画像処理リコンフィグ部１２に対して二次フォールバック処理を指示する（Ｓ1424）。

ステップＳ1422でノーのときを含めてこれら一連の処理が完了すると、リコンフィグ制御部２０は、オペレータＮに“１”を加算して次段のファンクションを割り当て（Ｓ1430）、ステップＳ1420に戻り、前記と同様の処理を繰り返す。

＜比較例との対比：第１実施形態＞
図１３は、第１実施形態の仕組みと比較例との差を説明する図である。前述の通り、プログラマブル・デバイス（ＦＰＧＡやＤＲＰ）の画像処理を制御するスケジューラ機能を持つリコンフィグ制御部２０を導入した第１実施形態の仕組みを適用し、圧縮・伸長を選択的に配置することで、圧縮・伸長の頻度を抑えてデータ処理性能（主に速度面での性能）の低下を抑制しながら、メモリ使用量を削減する処理がなされる。一概には言えないが、メモリ削減効果としてはたとえば５０％程度は可能であり、与えられたメモリを最大限活用して画像処理を実行し得る。メモリ使用量の圧迫度合いは同時に処理するストリーム数が多い程強くなるので、第１実施形態の適用による効果は、同時に処理するストリーム数が多い方が高くなる。ただし、ストリーム数が少ない場合でも、第１実施形態の仕組みを適用することでメモリ使用量の削減効果やデータ処理性能（主に速度面での性能）向上効果は得られる。

たとえば、図１３は、各パイプラインステージでは、入力ストリームが１系統で出力ストリームも１系統である場合における、比較例と第１実施形態の対比を示している。イニシャル・パイプラインとしては、図１３（１）に示すように、１ユニットのStream１がFunc１に入力され、Func１でのデータ処理により３ユニットのStream２が出力され、これがFunc２に入力され、Func２でのデータ処理により０．８ユニットのStream３が出力されている。この場合、メモリサイズ・リミットを３ユニットとすると、Func１でのデータ処理時にはローカルメモリ３０との間のデータ転送に破綻を来たす。

この対策としては、圧縮率を求め（圧縮率＝３（メモリサイズ・リミット）÷４（ストリーム使用量合計MSUM１）＝７５％）、図１３（２）に示す比較例のモディファイド・パイプラインのように、求めた圧縮率を適用する圧縮器および対応する伸長器を配置することが考えられる。この場合、各ファンクションには、入力側に伸長器Exが挿入され、出力側に圧縮器Cmが挿入されるので、ファンクション数（パイプラインステージ数）が増えるほど圧縮器Cmと伸長器Exが数多く入ることになる。このことは、レイテンシーがある場合は、大きな性能低下インパクトとなる。本来であれば不要な圧縮処理や伸長処理のための時間がオーバーヘッドになるからである。また、圧縮率が予想圧縮率よりも悪い場合は、メモリ不足でスタックすることにもなる。

これに対して、第１実施形態の仕組みでは、圧縮・伸長の頻度を低下させる圧縮閾値THを導入し、圧縮閾値THに基づきストリームを選択的に圧縮・伸長することで、圧縮・伸長の頻度を低下させるように、パイプラインステージをスケジューリングする。本例の場合、圧縮閾値TH＝３（メモリサイズ・リミット）÷ ２（ストリーム数合計）＝１．５となるので、図１３（３）に示すように、Stream２についてのみ圧縮・伸長を適用するように、Func１の出力側に圧縮器Cmを挿入し、Func２の入力側に伸長器Exを挿入したモディファイド・パイプラインを構築する。このように、第１実施形態の仕組みでは、選択的に圧縮・伸長が入るので、レイテンシーの影響が最小限に抑えられる。また、この図では示さないが、前述のように、圧縮率が悪く目盛りオーバーとなるケースでは、ダイナミック・スケジューリングによるフォールバック機能が働くので、システムは動き続ける。

因みに、特開平５−２６３９号公報には、圧縮画像データの伸長処理を実際に編集処理に必要な時間までに自動的に行なえる画像処理システムが提案されている。しかしながら、この仕組みでは、非可逆圧縮を対象としており、可逆圧縮で圧縮率が悪い場合を考慮していない。したがって、特開平５−２６３９号公報に記載の仕組みは、第１実施形態のスタティック・スケジューリング相当の処理のみで、ダイナミック・スケジューリングという概念がない。加えて、特開平５−２６３９号公報に記載の仕組みは、編集要求が重なれば膨大なメモリ空間を使用してしまう。これに対して、第１実施形態の仕組みでは、組込み用途でメモリ制約を考慮しているため、メモリ制限内でスケジューリングする。さらに、特開平５−２６３９号公報に記載の仕組みは、圧縮・伸長が専用のコンピュータ・リソースで常駐している必要があるが、第１実施形態の仕組みでは、必要なときに出現させている相違もある。

＜＜第２実施形態＞＞
図１４は、第２実施形態のデータ処理装置１の仕組みを説明する図である。第２実施形態では、第１実施形態と同様の観点から、「内部処理構成をプログラマブル可能なデバイス」を使用して、その再構成のスケジューリングを適正化する。こうすることで、ハードウェアリソースを増やさないで、画像処理速度性能低下を抑制し、画像処理に必要なストリーム使用量合計MSUM以下のメモリ容量（メモリサイズ）でも、正常に画像処理を実現する仕組みにする。ＤＲＰ１０の画像処理リコンフィグ部１２（リコンフィグパイプライン）のステージごとに圧縮閾値THを算出し、圧縮閾値THを超えるストリーム量（データサイズ）のストリームは画像処理と並行に圧縮器や伸長器を挿入する点では第１実施形態と同様の仕組みを採る。同一画素データについては伸長後に画像処理を行ない、また画像処理後の画素データを圧縮するが、他の画素データとの関係では画像処理と並行に圧縮処理や伸長処理がなされるので、圧縮処理や伸長処理のための時間ロスは抑えられる。メモリ使用量の増加もない。

ただし、第１実施形態との相違点としては、圧縮閾値THの定義式としては、第３定義式として、“圧縮閾値TH３＝（本ステージで使用できるメモリサイズ入力ストリームサイズ合計）÷（出力ストリームの総本数）”を使用する。なお、本ステージで使用できるメモリサイズとは、メモリサイズから本ステージには関係ない、蓄積ストリームの合計サイズを差し引いたサイズのことである。

第１実施形態との相違点としては、複数の出力ストリームを圧縮する必要がある場合において圧縮器が同一ファンクション（当該ステージの画像処理リコンフィグ部１２）に規模的に入らない場合や、入力ストリーム（単一・複数の何れでもよい）を伸長する必要がある場合において一度に伸長するとメモリ容量オーバーとなる場合の対処の仕組みである。何れの場合も、時分割処理で対処する点に特徴がある。

圧縮に関する時分割処理の仕組みのポイントは、ローカルメモリ３０に空きスペースが存在しないとき、それら複数のストリームを分けて順番に同じデータ処理（画像処理）を実行し、このとき、必要に応じてストリームに対しては圧縮を加える。なお、リコンフィグ制御部２０は、複数の出力ストリームを時分割でデータ処理するようにスケジューリングを行なう点に特徴がある。つまり、リコンフィグ制御部２０は、データ処理とその後の圧縮処理の組合せで時分割で処理を実行するようにスケジューリングする。「必要に応じて」とは、何れか１つの出力ストリームに関しての処理時にはローカルメモリ３０に空きスペースが存在するときには圧縮せず、空きスペースが存在しなければ圧縮することを意味する。圧縮するかしないかは、当該処理で出力される出力ストリームサイズとも関係し、一方の出力ストリームに関しての処理時には圧縮せず他方の処理時には圧縮するようなケースも存在する。

伸長に関する時分割処理の仕組みのポイントは、圧縮している入力ストリームを伸長してデータ処理（画像処理）を行なう場合に、入力ストリームを一括して伸長処理を実行すると（たとえば一度にページ分伸長すると）ローカルメモリ３０のメモリ容量をオーバーする場合、メモリ容量が許容する分だけ、「伸長＋データ処理」を行ない、次にその続きから「伸長＋データ処理」を行なうなど、リコンフィグ制御部２０は、入力ストリームを複数バンドに分割して時分割でデータ処理するようにスケジューリングを行なう。つまり、リコンフィグ制御部２０は、伸長処理とその後のデータ処理の組合せで、時分割で処理を実行するようにスケジューリングする。

なお、圧縮・伸長の何れの場合も、リコンフィグ制御部２０は、圧縮器Cmや伸長器Exが画像処理のコンフィグ（ファンクション）と同一コンフィグに挿入できず、メモリ容量をオーバーすると判断した場合には、圧縮・伸長のコンフィグを、画像処理パイプラインの途中に挿入するように調整する。

このように、第２実施形態の対処手法は、時分割でデータ処理するようにスケジューリングを行なうことで、メモリサイズオーバーを回避する。たとえば、図１４（２）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、３ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が７ユニットとなり、メモリサイズを超えてしまう。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合でも、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、２つの出力ストリームは何れも圧縮閾値TH３（改良版）をオーバーしている。

一方、図１４（３）に示すように、第２実施形態を適用すると、たとえば、時分割処理における第１の処理では第１出力ストリーム OUT１を出力し、次の第２の処理では第２出力ストリーム OUT２を出力するものとする。圧縮適用時には１／３の圧縮を行なうものとする。この場合、第１の処理時点では、第１出力ストリーム量は３×１／３＝１ユニットとなるので、ストリーム使用量合計MSUM１＝３＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２＝２であり圧縮閾値TH３（改良版）＝（５−２）／１＝３となり、第１出力ストリーム量（＝１ユニット）以上となるから、問題なく処理される。次の第２の処理時点では、ストリーム使用量合計MSUM１＝４＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２は第１の処理時点よりも第１出力ストリーム OUT１分の１ユニットが加算され３ユニットになり、圧縮閾値TH３（改良版）＝（５−２−１）／１＝２となり、問題なく処理される。

次に、具体的なケースを示して、第２実施形態の仕組みについて説明する。なお、以下に述べる第２実施形態の各例においては、最終的には、実際には第２実施形態の特徴点である時分割処理の仕組みが適用されないケースがあるが、時分割処理を適用する前に、時分割処理を適用する必要があるか否かを判定する手順が必要であるので、様々なケースについて説明する。因みに、各例において、圧縮適用時には１／３の圧縮を行なうものとする。

＜第１例：第２実施形態＞
図１５は、第２実施形態の第１例を説明する図である。第１例は、第３定義式の圧縮閾値TH３（改良版）に基づいて圧縮処理や時分割処理を適用する必要があるか否かを判定した結果、実際には、時分割処理の仕組みを適用しないと判断するケースである。

図１５に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、１ユニットの第１出力ストリーム OUT１と１ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が４ユニットとなり、メモリサイズを超えない。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合でも、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、２つの出力ストリームは何れも圧縮閾値TH３（改良版）をオーバーしない（圧縮閾値TH３以下である）。よって、リコンフィグ制御部２０は、圧縮を適用することなく、そのまま画像処理を行ないそのまま出力すると判断する。

＜第２例：第２実施形態＞
図１６は、第２実施形態の第２例を説明する図である。第２例は、第３定義式の圧縮閾値TH３（改良版）に基づいて圧縮処理や時分割処理を適用する必要があるか否かを判定した結果、一方の出力ストリームに関しての処理時には圧縮せず他方の処理時には圧縮すると判断するケースである。

図１６（１）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、１ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が５ユニットとなり、メモリサイズを超えない。しかしながら、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、第１出力ストリーム OUT１は圧縮閾値TH３（改良版）をオーバーしない（圧縮閾値TH３以下である）が、第２出力ストリーム OUT２は圧縮閾値TH３（改良版）をオーバーする（圧縮閾値TH３以上である）。

よって、リコンフィグ制御部２０は、先ず、第２出力ストリーム OUT２についての処理時には画像処理を行ない圧縮を適用して出力すると判断する。そのときの第２出力ストリーム OUT２は２／３＝０．６となり、再度計算すると、圧縮閾値TH３（改良版）＝（５−２−０．６）／２＝２．４となる。よって、次に第１出力ストリーム OUT１を出力するときは圧縮を行なわないと判断する。

＜第３例：第２実施形態＞
図１７は、第２実施形態の第３例を説明する図である。第３例は、第３定義式の圧縮閾値TH３（改良版）に基づいて圧縮処理や時分割処理を適用する必要があるか否かを判定した結果、各出力ストリームに関しての処理時には圧縮すると判断するケースである。特に、後述する第４例との対比においては、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入し得る場合の事例である。

図１７（１）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、２ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が６ユニットとなり、メモリサイズを超えてしまう。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、第１出力ストリーム OUT１および第２出力ストリーム OUT２は何れも圧縮閾値TH３（改良版）をオーバーする（圧縮閾値TH３以上である）。

よって、リコンフィグ制御部２０は、先ず、少なくても第１出力ストリーム OUT１および第２出力ストリーム OUT２の何れか一方についての処理時には画像処理を行ない圧縮を適用して出力する必要があると判断する。さらに、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入し得るか否かを判断する。その結果、個別の圧縮器Cmを同一ファンクション内に挿入し得るケースであり、時分割処理の適用については適用不要と判断し、第１出力ストリーム OUT１および第２出力ストリーム OUT２の双方についての処理時には並行的に画像処理を行ないかつ個別に圧縮を適用して出力すると判断する。

この場合、図１７（２）に示すように、第１出力ストリーム量および第２出力ストリーム量はそれぞれ２×１／３≒０．６ユニットとなるので、ストリーム使用量合計MSUM＝３．２＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２＝２であり圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、圧縮後の第１出力ストリーム量および第２出力ストリーム量（＝０．６ユニット）以上となるから、時分割処理を適用しなくても、問題なく処理される。

＜第４例：第２実施形態＞
図１８は、第２実施形態の第４例を説明する図である。第４例は、第３定義式の圧縮閾値TH３（改良版）に基づいて圧縮処理や時分割処理を適用する必要があるか否かを判定した結果、各出力ストリームに関しての処理時には圧縮すると判断するケースである。特に、前述の第３例との対比においては、画像処理の規模が大きく、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入できない場合の事例である。また、後述する第５例との対比においては、２回目の処理時の出力ストリームには圧縮を適用しない事例である。

図１８（１）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、２ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が６ユニットとなり、メモリサイズを超えてしまう。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、第１出力ストリーム OUT１および第２出力ストリーム OUT２は何れも圧縮閾値TH３（改良版）をオーバーする（圧縮閾値TH３以上である）。

よって、リコンフィグ制御部２０は、先ず、少なくても第１出力ストリーム OUT１および第２出力ストリーム OUT２の何れか一方についての処理時には画像処理を行ない圧縮を適用して出力する必要があると判断する。さらに、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入し得るか否かを判断する。その結果、画像処理の規模が大きく、個別の圧縮器Cmを同一ファンクション内に挿入できないケースであり、時分割処理の適用については適用必須と判断し、第１出力ストリーム OUT１および第２出力ストリーム OUT２の処理時には時分割処理で画像処理を行ない、かつ、少なくとも一方の処理時には圧縮を適用して出力すると判断する。そして、２回目の処理時にも、圧縮閾値TH３（改良版）を計算し、その結果、２回目の処理時には圧縮処理は適用不要と判断する。ここでは、時分割処理の適用においては、たとえば、第１出力ストリーム OUT１の処理を先に実行し、第２出力ストリーム OUT２の処理を後に実行するものとする。

この場合、図１８（２）に示すように、第１の処理時点では、第１出力ストリーム量は２×１／３≒０．６ユニットとなるので、ストリーム使用量合計MSUM＝２．６＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２＝２であり圧縮閾値TH３（改良版）＝（５−２）／１＝３となり、第１出力ストリーム量（＝０．６ユニット）以上となるから、問題なく処理される。次の第２の処理時点では、ストリーム使用量合計MSUM＝４．６＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２は第１の処理時点よりも第２出力ストリーム OUT２分の０．６ユニットが加算され２．６ユニットになり、圧縮閾値TH３（改良版）＝（５−２−０．６）／１＝２．４となるから、２本目の第２出力ストリーム OUT２（＝２ユニット）に対して圧縮を適用しなくても問題なく処理される。

なお、この第４例では、画像処理リコンフィグ部１２内に圧縮器Cmを１つ挿入して、複数の出力ストリームが各別に時分割で使用する例で示しているが、各出力ストリームに各別に圧縮器Cmを配置しつつ、各出力ストリームのデータ量の半分ずつを時分割で処理するようにスケジューリングしてもよい。

＜第５例：第２実施形態＞
図１９は、第２実施形態の第５例を説明する図である。第５例は、第３定義式の圧縮閾値TH３（改良版）に基づいて圧縮処理や時分割処理を適用する必要があるか否かを判定した結果、各出力ストリームに関しての処理時には圧縮すると判断するケースである。特に、前述の第４例との対比においては、画像処理の規模が大きく、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入できない場合において、各出力ストリームの処理時に圧縮を適用する事例である。

図１９（１）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１と１ユニットの第２入力ストリームIN２とがFunc１に入力され、当該Func１における画像処理後に、３ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が７ユニットとなり、メモリサイズを超えてしまう。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−２）／２＝１．５となり、第１出力ストリーム OUT１および第２出力ストリーム OUT２は何れも圧縮閾値TH３（改良版）をオーバーする（圧縮閾値TH３以上である）。

よって、リコンフィグ制御部２０は、先ず、少なくても第１出力ストリーム OUT１および第２出力ストリーム OUT２の何れか一方についての処理時には画像処理を行ない圧縮を適用して出力する必要があると判断する。さらに、各出力ストリーム用に個別の圧縮器Cmを同一ファンクション内に挿入し得るか否かを判断する。その結果、画像処理の規模が大きく、個別の圧縮器Cmを同一ファンクション内に挿入できないケースであり、時分割処理の適用については適用必須と判断し、第１出力ストリーム OUT１および第２出力ストリーム OUT２の処理時には時分割処理で画像処理を行ない、かつ、少なくとも一方の処理時には圧縮を適用して出力すると判断する。そして、２回目の処理時にも、圧縮閾値TH３（改良版）を計算し、その結果、２回目の処理時にも、圧縮処理の適用が必要と判断する。ここでは、時分割処理の適用においては、たとえば、第１出力ストリーム OUT１の処理を先に実行し、第２出力ストリーム OUT２の処理を後に実行するものとする。結果的には、同じ画像処理を２回実行し、出力ストリームを交互に圧縮することになる。

この場合、図１９（２）に示すように、第１の処理時点では、第１出力ストリーム量は３×１／３＝１ユニットとなるので、ストリーム使用量合計MSUM＝３＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２＝２であり圧縮閾値TH３（改良版）＝（５−２）／１＝３となり、第１出力ストリーム量（＝３ユニット）以上となるから、問題なく処理される。次の第２の処理時点では、圧縮閾値TH３（改良版）＝（５−２−１）／１＝２となり、第２出力ストリーム OUT２も圧縮が必要とすると判断する。

＜第６例：第２実施形態＞
図２０は、第２実施形態の第６例を説明する図である。第６例は、入力ストリームが圧縮データである場合に、第３定義式の圧縮閾値TH３（改良版）に基づいて伸長処理や時分割処理を適用する必要があるか否かを判定した結果、各出力ストリーム用に個別の伸長器Exを同一ファンクション内に挿入し得るケースで、かつ、各出力ストリームに関しての処理時には入力ストリームに対して時分割で伸長することは不要と判断する事例である。

図２０（１）に示すように、メモリサイズが５ユニットのときに、１ユニットの第１入力ストリームIN１が１／３に圧縮されて、また１ユニットの第２入力ストリームIN２が１／３に圧縮されて、それぞれFunc１に入力され、当該Func１における画像処理後に、２ユニットの第１出力ストリーム OUT１と２ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が４．６ユニットとなり、メモリサイズを超えない。また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−０．３−０．３）／２＝２．２となり、第１出力ストリーム OUT１および第２出力ストリーム OUT２は何れも圧縮閾値TH３（改良版）を超えない（圧縮閾値TH３以下である）。

よって、リコンフィグ制御部２０は、基本的には、第１出力ストリーム OUT１および第２出力ストリーム OUT２の双方についての処理時には伸長を適用して画像処理を行ない出力すればよいと判断する。「基本的には」と称したのは、同一ファンクション内で、伸長処理が個別に適用し得るか否かに左右されるからである。そこで、リコンフィグ制御部２０は、次に、各出力ストリーム用に個別の伸長器Exを同一ファンクション内に挿入し得るか否かを判断する。その結果、個別の伸長器Exを同一ファンクション内に挿入し得るケースであると判断する。つまり、リコンフィグ制御部２０は、個別の伸長器Exを同一ファンクション内に挿入し得るケースであり、時分割処理の適用については適用不要と判断し、第１出力ストリーム OUT１および第２出力ストリーム OUT２の双方についての処理時には個別に伸長を適用して、かつ伸長後に並行的に画像処理を行なって出力すると判断する。

この場合、図２０（２）に示すように、第１入力ストリーム量および第２入力ストリーム量はそれぞれ１×１／３≒０．３ユニットであるので、ストリーム使用量合計MSUM＝２．６＜メモリサイズ＝５となり、また、ストリーム使用量合計MSUM２＝２であり圧縮閾値TH３（改良版）＝（５−０．６）／２＝２．２で図２０（１）と変化なく、各入力ストリームおよび各出力ストリームの何れも、圧縮閾値TH３以下であることには変わりがなく、時分割処理を適用しなくても、問題なく処理される。

＜第７例：第２実施形態＞
図２１は、第２実施形態の第７例を説明する図である。第７例は、入力ストリームが圧縮データである場合に、第３定義式の圧縮閾値TH３（改良版）に基づいて伸長処理や時分割処理を適用する必要があるか否かを判定した結果、各出力ストリーム用に個別の伸長器Exを同一ファンクション内に挿入し得るケースで、かつ、各出力ストリームに関しての処理時には入力ストリームに対して時分割で伸長することが必要と判断する事例である。

図２１（１）に示すように、メモリサイズが５ユニットのときに、２ユニットの第１入力ストリームIN１が１／３に圧縮されて、また２ユニットの第２入力ストリームIN２が１／３に圧縮されて、それぞれFunc１に入力され、当該Func１における画像処理後に、３ユニットの第１出力ストリーム OUT１と３ユニットの第２出力ストリーム OUT２とが出力される場合を想定する。この場合、Func１での画像処理時にはストリーム使用量合計MSUM１が７．２ユニットとなり、メモリサイズを超えてしまう。

また、第２実施形態で適用する第３定義式による圧縮閾値TH３で判断した場合には、メモリサイズ＝領域サイズ＝５であり、２つの出力ストリームを一括で出力するケースであるので出力ストリームの総本数＝２であるから、圧縮閾値TH３（改良版）＝（５−０．６−０．６）／２＝１．９となり、第１出力ストリーム OUT１および第２出力ストリーム OUT２は何れも圧縮閾値TH３（改良版）を超えてしまう（圧縮閾値TH３以上である）。圧縮している入力ストリームを伸長してデータ処理（画像処理）を行なう場合に、一度にページ分伸長するとローカルメモリ３０のメモリ容量をオーバーするケースとなる。

よって、リコンフィグ制御部２０は、少なくとも、第１出力ストリーム OUT１および第２出力ストリーム OUT２の双方についての処理時には時分割処理を適用して伸長を行なってから画像処理を行ない出力する必要があると判断する。同一ファンクション内で、双方の出力ストリームの処理時に同時並行的に伸長処理が適用し得るか否かは、個別に伸長処理を適用し得るか否かに左右される。そこで、リコンフィグ制御部２０は、次に、各出力ストリーム用に個別の伸長器Exを同一ファンクション内に挿入し得るか否かを判断する。その結果、個別の伸長器Exを同一ファンクション内に挿入し得るケースであると判断する。

つまり、リコンフィグ制御部２０は、個別の伸長器Exを同一ファンクション内に挿入し得るケースであり、かつ、時分割処理の適用については必要と判断し、第１出力ストリーム OUT１および第２出力ストリーム OUT２の双方についての処理時には個別に伸長を適用して、かつ時分割での伸長後に並行的に画像処理を行なって出力すると判断する。つまり、伸長するとメモリオーバーする場合、分割伸長し、最初に前半の処理を行ない、次に後半の処理を行なうのである。出力ストリーム数が２であるが、基本的な考え方は、第１実施形態における第２例で適用したバンディング処理と同様である。

なお、バンディング処理の適用に当たっては、以下のような手順を踏む。先ず、リコンフィグ制御部２０は、一度にページ分伸長するとローカルメモリ３０のメモリ容量をオーバーする場合、次の後段の画像処理の出力サイズ量を含めて、メモリサイズをオーバーしないように分割数を特定する。最初に中間ストリーム合計サイズと中間ストリーム許容サイズを算出し、中間ストリーム合計サイズから中間ストリーム許容サイズを割った値がバンド分割数である。

この場合、図２１（２）に示すように、出力ストリームOUT１，OUT２を中間ストリームとする。中間ストリーム合計サイズは出力ストリームOUT１，OUT２（各３ユニット）の合計であり、６ユニットとなる。次に、中間ストリーム許容サイズはメモリサイズ（＝５）から圧縮された入力ストリームIN１，IN２（各０．６ユニット）と後段の画像処理出力ストリームOUT3（＝３ユニット）を引いた値であり、０．８ユニットとなる。中間ストリーム合計サイズから中間ストリーム許容サイズを割った値がバンド分割数であるので、６ユニット÷０．８ユニットで７．５となる。算出結果に最も近く、大きな整数を分割数とするので、バンド分割数は８である。

画像処理リコンフィグ部１２は、１回目の処理では、圧縮された入力ストリームIN１，IN２（各０．６ユニット）の８分割した１バンド目しか伸長を行なわず、ローカルメモリ３０との間でデータ転送をしつつ、Func１でデータ処理（画像処理）を行ない処理済みの出力ストリーム OUT１， OUT２（各０．４ユニット）を出力する。各０．６ユニットの入力ストリームIN１，IN２の内の伸長しない半分はローカルメモリ３０に格納しておく。次に１バンド目の後段の画像処理を実行し、出力ストリームOUT3はローカルメモリ３０に格納しておく。

続く２回目の処理では、圧縮された入力ストリームIN１，IN２（各０．６ユニット）の２バンド目に相当する部分を伸長し、ローカルメモリ３０との間でデータ転送をしつつ、Func１でデータ処理（画像処理）を行ない、２バンド目の出力ストリーム OUT１， OUT２（各０．４ユニット）を出力する。各０．６ユニットの入力ストリームIN１，IN２の内の伸長しない半分はローカルメモリ３０に格納しておく。次に２バンド目の後段の画像処理を実行し、出力ストリーム OUT３はローカルメモリ３０に格納しておく。この動作を繰り返し、最後のバンドの処理過程では、ストリーム使用量合計MSUMは、圧縮された入力ストリームIN１，IN２（各０．６ユニット）と最後のバンドの処理済みの出力ストリーム OUT１， OUT２（各０．４ユニット）と、後段の画像処理の出力ストリーム OUT３の合計（＝３ストリーム）で、５ユニットとなり、メモリサイズ（＝５）内に抑えることができる。

＜処理手順１：第２実施形態＞
図２２は、第２実施形態のデータ処理装置１における基本動作例の処理手順（メインフロー）を説明するフローチャートである。このフローチャートでは、前述の第１例、第２例、および第３例の処理手順が示される。

リコンフィグ制御部２０は、先ず、後述するリコンフィグパイプライン管理テーブルTB20から現ステージの圧縮閾値THを算出する（Ｓ2100）。次に、リコンフィグ制御部２０は、算出した圧縮閾値THに基づいて、現ステージで圧縮すべきストリーム、伸長すべきストリームをピックアップする（Ｓ2110）。そして、リコンフィグ制御部２０は、現ステージの画像処理コンフィグデータに、対象ストリームの圧縮器Ｃｍ（あるいは伸長器Ex）が全て挿入可能かを判断する（Ｓ2120）。イエスであれば、リコンフィグ制御部２０は、画像処理コンフィグデータに圧縮器Cm（あるいは伸長器Ex）を挿入する（Ｓ2120-Y，S2130）。

さらに、リコンフィグ制御部２０は、圧縮器処理後（ここでは１／３圧縮を想定する）のストリームサイズで圧縮閾値THを算出する（Ｓ2140）。そして、リコンフィグ制御部２０は、圧縮閾値THをオーバーするストリームがないかを判断する（Ｓ2150）。イエスであれば、リコンフィグ制御部２０は、リコンフィグパイプライン管理テーブルを更新し、ステップＳ2100に戻り、次のステージの処理に移行する（Ｓ2160）。

一方、ステップＳ2120にてノーであれば、リコンフィグ制御部２０は、伸長器Exが必要かや圧縮器Cmが必要かを判断する（Ｓ2120-N，Ｓ2170）。伸長器Exのみが必要である場合は、あるいは伸長器Exおよび圧縮器Cmの双方が必要である場合には、後述する伸長処理実行スケジューリングへ移行し（Ｓ2170-A，Ｓ2180）、また、圧縮器Cmのみが必要である場合は後述する圧縮処理実行スケジューリングへ移行し（Ｓ2170-B，Ｓ2190）、これら伸長処理実行スケジューリングや圧縮処理実行スケジューリングの処理が完了するとステップＳ2160へ移行する。また、リコンフィグ制御部２０は、ステップＳ2150にてノーであれば、リコンフィグ制御部２０は、後述する圧縮処理実行スケジューリングへ移行し（Ｓ2150-N，Ｓ2190）、この圧縮処理実行スケジューリングの処理が完了するとステップＳ2160へ移行する。

＜処理手順２：第２実施形態＞
図２３は、伸長処理実行スケジューリング（Ｓ2180）の詳細を説明するフローチャートである。このフローチャートでは、前述の第６例の処理手順が示される。先ず、画像処理リコンフィグ部１２は入力ストリームを伸長し、リコンフィグ制御部２０は画像処理した場合の圧縮閾値THを算出する（Ｓ2200）。次に、リコンフィグ制御部２０は、伸長実行THをオーバーするストリームがないかを判断する（Ｓ2210）。イエスであれば、リコンフィグ制御部２０は、本来の画像処理コンフィグの前に、入力ストリームを伸長するコンフィグを追加してメインフローのステップＳ2160に移行する（Ｓ2210-Y，Ｓ2220）。

一方、ステップＳ2210にてノーであれば、リコンフィグ制御部２０は、伸長の実行を画像処理リコンフィグ部１２に指示する（Ｓ2210-N）。この指示を受けた画像処理リコンフィグ部１２は、バンド分割数を計算し（Ｓ2231）、バンドサイズ分の伸長を実行し、バンドサイズ分画像処理を実行する。引き続き、後段の次の画像処理もバンドサイズ分実行する（Ｓ2232）。全てのバンド分の処理が終了したら、メインフローのステップＳ2160（Ｃ）に移行する。

＜処理手順３：第２実施形態＞
図２４は、圧縮処理実行スケジューリング（Ｓ2190）の詳細を説明するフローチャートである。このフローチャートでは、前述の第４例および第５例の処理手順が示される。先ず、リコンフィグ制御部２０は、最もサイズの大きい、出力ストリームの圧縮処理後（ここでは１／３圧縮を想定する）のサイズで圧縮閾値THを算出する（Ｓ2310）。そして、リコンフィグ制御部２０は、圧縮閾値THをオーバーするストリームがないかを判断する（Ｓ2320）。イエスであれば、リコンフィグ制御部２０は、画像処理コンフィグデータに圧縮器Cmを挿入してメインフローのステップＳ2160（Ｃ）に移行する（Ｓ2320-Y，Ｓ2330）。

また、ステップＳ2320にてノーであれば、画像処理リコンフィグ部１２は、画像処理コンフィグデータに圧縮器Cmを挿入し、圧縮できず、かつ圧縮閾値THをオーバーするストリームは出力しない（Ｓ2320-N，Ｓ2350）。さらに、リコンフィグ制御部２０は、画像処理コンフィグデータに圧縮器Cmを挿入し、画像処理リコンフィグ部１２は、前で出力しなかった出力ストリームを圧縮し、また、既に出力したストリームは今回は出力しない（Ｓ2360）。画像処理リコンフィグ部１２は、出力ストリームを全て出力したかを判断する（Ｓ2370）。ノーであればステップＳ2360に戻り、イエスであればメインフローのステップＳ2160（Ｃ）に移行する。

＜管理テーブル：第２実施形態＞
図２５および図２５Ａは、リコンフィグパイプライン管理テーブルTB20の一例を示す図である。ここで、図２５は最初の状態を示し、図２５Ａは、更新後の状態を示す。前提条件としては、画像処理部＝１００、圧縮器Ｃｍ＝２０、伸長器Ex＝２０で、先の通り、圧縮率１／３、メモリサイズ５とする。図２５において、トータルメモリサイズの欄において＊＊で示した部分（ステージ３，４，５）がメモリオーバーとなる部分であり、圧縮処理による対処が必要となる部分である。図２５Ａにおいて、網点ハッチングで示した部分が更新内容である。

第２実施形態のリコンフィグパイプライン管理テーブルTB20は、パイプラインステージ（リコンフィグ）順に、画像処理部の情報、入力ストリームの情報、出力ストリームの情報、メモリサイズ管理情報、メモなどの情報が管理されるようになっている。画像処理部の情報としては、名前（Name），規模，圧縮器Cmや伸長器Exの挿入の有無がある。入力ストリームの情報としては、名前（Name），サイズ，形態（ＲＡＷ，圧縮の別）がある。出力ストリームの情報としては、名前（Name），サイズ，形態（ＲＡＷ，圧縮の別）がある。メモリサイズ管理情報としては、圧縮閾値THやトータルメモリサイズがある。メモ欄には、本実施形態の各事例との対応関係を付している。

＜＜第２実施形態の比較例＞＞
＜第１比較例：第２実施形態＞
図２６は、第２実施形態のデータ処理装置１に対する第１比較例を説明する図である。第１比較例は、特開２００５−３０１６０７号公報に記載の仕組みに該当する。この仕組みは、プロセッサ９１０とは別に、サブローカルメモリ９１４と処理回路９１６を含むサブプロセッサ９１２を各ストリームに対応するように複数備えてデータ処理部が構成されている。サブプロセッサ９１２においては、サブローカルメモリ９１４と処理回路９１６との間に圧縮器Cmと伸長器Exを実装することで、データ転送によるボトルネックを回避するものである。メモリ量を削減し、かつ画像処理スピードを低下させないために、画像処理の各入力ストリームに伸長器Ex、各出力ストリームに圧縮器Cmを実装する。各サブプロセッサ９１２での処理が重なる場合は圧縮器Cmと伸長器Exを使用するようにスケジューリングし、圧縮した結果が悪い場合は圧縮せずに生（ＲＡＷ）データをサブローカルメモリ９１２を介してメモリ９１８に保持するようにしている。

第１比較例の仕組みの場合、圧縮器Cmと伸長器Exをハードウェアで持つ場合は、各ストリーム（換言すると各サブプロセッサ９１２）分必要なので、回路規模が大きくなる。全てのストリームに圧縮器Cmと伸長器Exを実装するために、画像処理エリアが十分に確保できないことも起こる。この場合、画像処理部分を分割するべく、サブプロセッサ９１２を増やすことも考えられるが、画像処理回数が増加し、画像処理スピードが低下する。また、プロセッサ９１０でソフトウェア的に圧縮器Cmと伸長器Exを実現する場合は、ハードウェア処理に比べると処理速度が低下するため、画像処理の速度性能に影響する（処理速度低下が起きる）。

これに対して、第２実施形態の仕組みは、ＤＲＰ１０などの「内部処理構成をプログラマブル可能なデバイス」を使用してスケジューリングを行なう仕組みを採っているので、各ストリーム数が多くなってもハードウェアリソースは増加しない。また、圧縮器Cmや伸長器Exが入った場合でも、ソフトウェア的に対処するものではなく、ハードウェア処理にて圧縮器Cmや伸長器Exが実現されるので、画像処理の速度性能低下は抑制される。

＜第２比較例：第２実施形態＞
図２６Ａは、第２実施形態のデータ処理装置１に対する第２比較例を説明する図である。第２比較例は、特開平０６−０７０１７１号公報に記載の仕組みに該当する。この仕組みは、メモリ容量を削減するために、入力データを圧縮し、保持し、画像処理する前に伸長し、画像処理後に圧縮し、メモリに保持するようにデータ処理部が構成されている。たとえば、入力データは誤差拡散部９２０に入力され圧縮器Cmにより圧縮された後メモリ９２８に保持される。その後、メモリ９２８からデータが読み出され伸長器Exにより伸長されてから平滑化多値化部９２２にて処理された後に画像処理部９２４にて画像処理が施される。画像処理後のデータは誤差拡散部９２６にて処理され、さらに圧縮器Cmでランレングスで圧縮されてからメモリ９２８に保持される。この後、所定のタイミングでデータが読み出され伸長器Exで伸長されてからデータ処理部の外部に出力される。

第２比較例の仕組みの場合、メモリ量削減のため、ハードウェア的にデフォルトで圧縮器Cmや伸長器Exが入出力にそれぞれ必要であるので、第１比較例と同様に、回路規模が大きくなる。また、画像処理の前後で圧縮・伸長があるので、単純にソフトウェア的に対処するように変形すると、第１比較例と同様に、画像処理の速度性能に影響する（処理速度低下が起きる）。これに対して、第２実施形態の仕組みは、第１比較例で述べた通りであり、ハードウェアリソースは増加しないし、圧縮器Cmや伸長器Exが入った場合でも、画像処理の速度性能低下は抑制される。

＜第３比較例：第２実施形態＞
図２６Ｂは、第２実施形態のデータ処理装置１に対する第３比較例を説明する図である。第３比較例は、特開２０００−３５８１４４号公報に記載の仕組みに該当する（図２より引用して示す）。この仕組みは、入力データを圧縮し（Ｓ９３０）、入力データ量と圧縮データ量との比を求め（Ｓ９３２）、この比から圧縮率を求め、求めた圧縮率と閾値を比較する（Ｓ９３４）。圧縮率が閾値よりも大きい場合は圧縮データをメモリに格納し（Ｓ９３４-Y，Ｓ９３６）、圧縮率が閾値よりも小さい場合は、伸長による性能低下を考慮し、圧縮していないデータ（非圧縮データ）をメモリに格納する（Ｓ９３４-N，Ｓ９３８）。

第３比較例の仕組みの場合、必ず圧縮するため、圧縮処理による性能低下が必ず発生する。また、圧縮器のハードウェアリソースが必要である。これに対して、第２実施形態の仕組みは、第１比較例で述べた通りであり、ハードウェアリソースは増加しないし、圧縮器Cmや伸長器Exが入った場合でも、画像処理の速度性能低下は抑制される。

＜第４比較例：第２実施形態＞
図２６Ｃは、第２実施形態のデータ処理装置１に対する第４比較例を説明する図である。第４比較例は、特開２００４−２７４７７６号公報に記載の仕組みに該当する。この仕組みは、メモリ容量オーバーとなるケースの場合にメインメモリ７０を利用せずに対処する仕組みであり、メモリ量を最小化するために適応的に圧縮方法を変更する。メモリ量の不足が発生した場合、第一の圧縮手段を用いて圧縮データを生成し、その圧縮データを検査し、ある閾値を超えていなければ、次の圧縮手段を適用し、閾値を達成するまで圧縮と検査を繰り返す。

たとえば、処理速度や圧縮性能の異なる複数の圧縮モードを用意しておき、実際に圧縮を行なってメモリが不足しているか否かを確かめながら、前記複数の圧縮モードを切り替えるようにしている。一例として、メモリ容量の不足が発生すると、Ｍモード（ランレングス、高速、低圧縮）→ＬＺＷ（辞書式、中速、中圧縮）→有損失（非可逆、高圧縮）の順に、３つのモードが使用される。この場合、実際に圧縮を行なって、メモリに入るか確かめるため、最大３回の圧縮を行なうことになり、その分のタイムロスが避けられない。

これに対して、第２実施形態の仕組みは、画像処理リコンフィグ部１２における回路の空き領域を利用して、圧縮器Cmや伸長器Exの中でその空き領域に挿入可能なものを選択して適用するため、ハードウェアリソースは増加しないし、タイムロスが殆ど発生しない。他の画素データとの関係では画像処理と並行に圧縮処理や伸長処理がなされるので圧縮処理や伸長処理のための時間ロスが抑えられるからである。

＜第５比較例：第２実施形態＞
図２６Ｄは、第２実施形態のデータ処理装置１に対する第５比較例を説明する図である。第５比較例は、特開２００３−２４４４４６号公報に記載の仕組みに該当する（図２６より引用して示す）。この仕組みは、メモリ容量オーバーとなるケースの場合にメインメモリ７０を利用せずに対処する仕組みであり、メモリ容量を削減するため、リアルタイムで画像データをメモリの記憶容量以内にＪｐｅｇ圧縮する。データをブロック化し、離散コサイン変換をして、ハフマン（Huffman ）符号化を行なう。圧縮データが所定以上の場合は、ハフマンの復号化を行ない、より圧縮率の高いＱテーブルに変更して再圧縮をする。最終的に、所定のデータ量になるまで、Ｑテーブル（または量子化テーブル）をビットシフトして、圧縮を繰り返すようにしている。最終的に所定のデータ量になるまで、より圧縮率の高いＱテーブルに変更して再圧縮を繰り返す。この仕組みでは、圧縮処理と他の処理を並行に行なうことができないため、圧縮処理の分の時間ロスが発生する。これに対して、第２実施形態の仕組みは、第４比較例で述べた通りであり、ハードウェアリソースは増加しないし、画像処理と並行に圧縮処理や伸長処理がなされるので圧縮処理や伸長処理のためのタイムロスが殆ど発生しない。

＜比較例との対比：第２実施形態＞
図２７は、第２実施形態の仕組みと比較例との差を説明する図である。前述の通り、プログラマブル・デバイス（ＦＰＧＡやＤＲＰ）の画像処理を制御するスケジューラ機能を持つリコンフィグ制御部２０を導入した第１実施形態の仕組みを適用して圧縮・伸長を選択的に配置し、さらに第２実施形態では、出力ストリームが複数ある場合にメモリ容量オーバーとなるケースや入力ストリーム（単一・複数の何れでもよい）を伸長する必要がある場合において一度に伸長するとメモリ容量オーバーとなるケースでは時分割で対処するようにしている。これにより、入出力ストリーム数による圧縮器Cmや伸長器Exのハードウェアリソースの増加を招くことなく、圧縮・伸長の頻度を抑えてデータ処理性能（主に速度面での性能）の低下を抑制しながら、メモリ使用量を削減する処理がなされる。

たとえば、図２７（１）の（１−１）に示すように、比較例の場合は、入力ストリーム数分の伸長器Exが必要となるし、出力ストリーム数分の圧縮器Cmが必要となる。したがって、たとえば、仮に入力ストリーム３系統で、かつ、出力ストリームが３系統である場合には、計６個の圧縮器・伸長器が必要となる。

一方、図２７（１）の（１−２）に示すように、第２実施形態の場合は、メモリサイズをオーバーしないように画像処理リコンフィグ部１２の構成をスケジューリングしながら画像処理リコンフィグ部１２に圧縮器Cmや伸長器Exを選択的に挿入するので、ハードウェアの増加はない。図２７（１−１）との対比では、圧縮器Cmや伸長器Exは１つでもよい場合があり、圧縮器Cmや伸長器Exの必要数に最大で６倍の差が生じる。

また、第２実施形態では、画像処理を実行する前に、圧縮率を予測し、１回目で最大メモリサイズ以内に収まるようにスケジューリングして、画像処理リコンフィグ部１２内に圧縮器Cmや伸長器Exを選択的に挿入している。加えて、画像処理と並行して圧縮処理や伸長処理を適用し得るようにしている。このため、ハードウェアリソースは増加しないし、画像処理と並行に圧縮処理や伸長処理がなされるので圧縮処理や伸長処理のためのタイムロスが殆ど発生しない。

たとえば、第４比較例の場合、メモリ容量の不足が発生すると、１回目ではＭモード→１回目ではＬＺＷモード→３回目では有損失モードが適用されるので、最大３回の圧縮を行なうことになり、その分のタイムロスが避けられない。これとの対比では、第２実施形態の場合、画像処理を実行する前（つまり圧縮処理前）に画像処理リコンフィグ部１２のスケジューリングが完成するので、タイムロスの側面では４倍の効果がある。

＜第３実施形態の比較例＞
図２８は、第３実施形態のデータ処理装置１に対する比較例を説明する図である。ここでは、パイプラインステージのスケジューリングの側面から示している。なお、図２８は、ストリーム使用量合計MSUMがメモリ容量をオーバーするケースを示している。

第１実施形態においても述べたが、ＤＲＰ１０などの「内部処理構成をプログラマブル可能なデバイス」を使用する場合、ＤＲＰ１０におけるコストにおいて、ローカルメモリ３０の占める割合が大きくなる（たとえば全体の５０％以上となる）。そのため、本実施形態（第３実施形態に限らない）のデータ処理装置１においては、システムのメモリコストを低減するべく、プログラマブル・デバイス（ＦＰＧＡやＤＲＰ：本例ではＤＲＰ１０）の画像処理構成を制御するスケジューラとしてリコンフィグ制御部２０を導入して、性能の低下を抑制しながらメモリ使用量を削減する様々な仕組みを採っている（前述の第１・第２実施形態のように）。

図２８には、あるパイプラインステージにおけるメモリサイズの例が示されている。各ファンクション（画像処理）に入出力されるストリームについては、そのデータ量がユニット単位で示されている。パイプラインステージの記述手法は、第１実施形態と同様であり、上側において左から右側に非蓄積型ストリームが入出力されるように示し、その下側に、蓄積型ストリームが入出力されるように示している。さらに、その下側には、そのファンクションにおける非蓄積ストリーム（Stream）サイズ合計（現画像処理中のストリーム量合計）、蓄積ストリーム（Stream）サイズ合計と本数（後段で使用するストリームの保持）、蓄積許容値、圧縮閾値TH４を示している。なお、圧縮有無の判断基準としては、“蓄積ストリーム（Stream）許容値＝メモリ空間（メモリ容量）−現画像処理中のストリームサイズ合計”、“圧縮閾値TH４＝蓄積ストリーム許容値÷蓄積ストリームの本数（蓄積ストリーム数）”を使用する。

第１実施形態において説明したように、各ＤＲＰ１０のリコンフィグ制御部２０が行なうスケジューリングの考え方は、スタティック・スケジューリングにより、パイプライン情報に基づいて圧縮対象ストリームピックアップと圧縮器Cmや伸長器Exの挿入を行なう。さらに、画像処理システムにて画像処理を実際に実行する過程で、ダイナミック・スケジューリングにより、フォールバックを考慮した処理を行なう。何れも、メモリサイズは制約条件として与えられる。この条件の中で、画像処理システムのパフォーマンス低下が最小限となるスケジューリングを行なう。

たとえば、スタティック・スケジューリング（Static Scheduling ）においては、「平均ストリームサイズ」を越えるストリームを圧縮する。ダイナミック・スケジューリング（Dynamic Scheduling）においては、圧縮した結果、メモリ容量オーバーが解消されないときには一次フォールバック処理にて圧縮を入れるか、もしくは二次フォールバック処理によりホスト部５側へデータ転送する。

メモリ容量オーバーとなる現象においては、蓄積型ストリームサイズが大きく寄与するもので、ストリーム使用量合計MSUMにとっては、蓄積型ストリームサイズが問題となる。そこで、ここでは、メモリ容量オーバーとなるときには蓄積型ストリームに対して圧縮を加えるものとする。図示した例では、メモリ空間が１０ユニット分であり、１ユニットの非蓄積型のStream２が画像処理２に入力され、１ユニットの非蓄積型のStream４と４ユニットの蓄積型のStream６とが出力される。このとき、画像処理１における処理により５ユニットの蓄積型のStream３が存在する。このため、画像処理２の段階でのストリーム使用量合計MSUMは１１ユニットとなり、画像処理２の段階でメモリ容量オーバーとなる。このため、５ユニットの蓄積型のStream３と４ユニットの蓄積型のStream６の内の、たとえば、その双方や、あるいは４ユニットの蓄積型のStream６のみを圧縮が必要なストリームとする。後に、これら圧縮されたStream３やStream６を使用するパイプラインステージにおいては、伸長が必要となる。次段の画像処理３においても、メモリ容量オーバーとなるケースでは、３ユニットの蓄積型のStream７を圧縮が必要なストリームとしてもよい。後に、この圧縮されたStream６を使用するパイプラインステージにおいては、伸長が必要となる。

ここで、画像処理リコンフィグ部１２は、データ処理機能（画像処理機能）で大部分が埋められているので、画像処理リコンフィグ部１２におけるデータ処理内容によっては、その回路規模が大きくなり、圧縮器Cmや伸長器Exを同一パイプラインステージの画像処理リコンフィグ部１２に配置できないケースも起こり得る。このときの対策として、たとえば第１実施形態では、圧縮器Cmや伸長器Exの強制挿入を行なうようにしている。

別の対策手法として、圧縮器Cmや伸長器Exによる回路規模大のため画像処理エリアが十分に確保されない点を解決するべく、画像処理部分を分割して、圧縮器Cmや伸長器Exを同一パイプラインステージの画像処理リコンフィグ部１２に挿入することも考えられる。しかしこの場合、画像処理回数（コンフィグ面）が増加し、画像処理スピードが低下する。

そこで、第３実施形態では、画像処理回数の増加や画像処理速度の低下を回避し得る、これらとは異なる仕組みを提案する。画像処理エリアを確保しつつ、画像処理スピードの低下を抑制するように、圧縮器Cmや伸長器Exを挿入する仕組みを採る。

＜＜第３実施形態＞＞
次に、データ処理装置１の第３実施形態について説明する。なお、第３実施形態においては、図面中で、「伸長」を「伸張」と記すことがあるが、これらは同義である。また、図面中で、圧縮器Cmと伸長器Exを纏めて「圧縮／伸長器」と記すことがある。

図２９は、第３実施形態のデータ処理装置１の仕組みを説明する図である。ここで、図２９は、図２８の対策として圧縮器Cmや伸長器Exを挿入する側面から第３実施形態の仕組みの基本原理を示す図である。

第３実施形態の仕組みの基本は、ソフトウェア処理できるプロセッサが空いていることがあることに着目し、圧縮器Cmや伸長器Exの一部もしくは全部をソフトウェア処理で対処することにある。ソフトウェア処理は、プロセッサ部（リコンフィグ制御部２０やコントローラメインＣＰＵ５０）において実行する。

具体的には、圧縮器Cmや伸長器Exをモジュール分割し、それぞれモジュールの「回路規模」および「ソフトウェア（Ｓ／Ｗ）バジェット」に基づき、画像処理リコンフィグ部１２に挿入する圧縮器Cmや伸長器Exのモジュール、ソフトウェア処理にする圧縮器Cmや伸長器Exのモジュール（場合によっては全てのモジュールをソフトウェア処理にする）に振り分け、圧縮処理や伸長処理を実行する。ここで、圧縮器Cmや伸長器Exの「ソフトウェアバジェット」とは、ソフトウェアによる処理時間である。

ハードウェア処理とソフトウェア処理の振り分けに当たっては、画像処理リコンフィグ部１２の空きエリアに応じて、モジュールを選択し、適応的にハードウェアで圧縮器Cmや伸長器Exを挿入し（物理的に入る範囲で）、ハードウェアで入りきらない残りのモジュールはソフトウェア処理で対処する。このとき、ソフトウェアで重い処理からハードウェアへ挿入するようにする。

図２９に示した例では、圧縮器Cmおよび伸長器Exをそれぞれ２つのモジュールに分割している。第１圧縮器Cm１は回路規模が２５％でソフトウェアバジェットがパイプラインステージの３ステージ分、第２圧縮器Cm２は回路規模が５０％でソフトウェアバジェットが０．３０ステージ分である。これから、第１圧縮器Cm１は、ソフトウェア処理よりもハードウェア処理（回路）で対処するのが好ましく、第２圧縮器Cm２は、ハードウェア処理よりもソフトウェア処理で対処するのが好ましいことが分る。第２圧縮器Ex１は回路規模が５０％でソフトウェアバジェットが０．３０ステージ、第２伸長器Ex２は回路規模が２５％でソフトウェアバジェットが３ステージである。これから、第１伸長器Exは、ハードウェア処理よりもソフトウェア処理で対処するのが好ましく、第２圧縮器Cm２は、ソフトウェア処理よりもハードウェア処理（回路）で対処するのが好ましいことが分る。

ソフトウェア処理はハードウェア処理（回路）よりも処理が遅くなる難点があるが、蓄積型ストリームの場合、後段の処理でその蓄積型ストリームが必要となるまでに圧縮や伸長を完了させておけばよく、ソフトウェア処理の処理速度が遅い点は殆ど問題にならないと考えてよい。蓄積型ストリームに対して圧縮処理や伸長処理を適用する場合には、ハードウェア処理とソフトウェア処理を別のステージで実行するように制御すればよいからである。なお、この図２９は、蓄積ストリーム対応のケースであり、非蓄積型ストリームに対してのソフトウェア処理による圧縮や伸長の適用を示していないが、後述するように、その適用を排除するものではない。

因みに、ソフトウェア処理できるプロセッサが空いていることがあることに着目した場合、メモリ容量オーバーとなるパイプラインステージからソフトウェア処理での対処を実行するよりも、全ての蓄積型ストリームに関してソフトウェア処理を適用した第３実施形態の仕組みを適用するのがよい。図２９では、この状態を示しており、Stream３，Stream６，Stream７の全蓄積型ストリームについて、圧縮器Cmの一部もしくは全部をソフトウェア処理で対処し、また、このStream３，Stream６，Stream７の全蓄積型ストリームについて、伸長器Exの一部もしくは全部をソフトウェア処理で対処するように、リコンフィグ制御部２０はパイプラインステージのスケジューリングを行なっている。

このように、第３実施形態の仕組みにおいては、データ処理中に保持しているストリームを圧縮処理し、ＤＲＰ１０の外部メモリ量（ローカルメモリ３０のメモリ容量）をオーバーしないように、リコンフィグ制御部２０は、画像処理リコンフィグ部１２のパイプラインステージ構成をスケジューリングする（その考え方は第１実施形態と同じ）。このとき、第３実施形態では、圧縮器Cmや伸長器Exをモジュール分割し、画像処理リコンフィグ部１２の空きエリアに応じてモジュールを選択し適応的にハードウェア（回路）で挿入し、ハードウェアで入りきらない残りのモジュールはソフトウェア処理で対処するように、リコンフィグ制御部２０はパイプラインステージのスケジューリングを行なう。画像処理回数の側面では、その回数が増加しないため、画像処理のスピード低下が発生しない。

＜モジュール分割＞
図３０は、モジュール分割と処理手順やストリーム使用量合計MSUMなどとの関係を説明する図である。ここでは説明を簡単にするため、圧縮率２５％の圧縮器Cmを２つのモジュールに均等に分割する事例で説明する。

ここでは、「圧縮率（％）＝圧縮後のデータサイズ÷圧縮前のデータサイズ：値の低い方が圧縮性能が良好」、「内部処理構成をプログラマブル可能なデバイス」を使用して複数のコンフィグレーションを切り替える画像処理システムでは、その入出力の各ストリームを全て保持すること、蓄積型ストリームの場合はパイプラインステージ（コンフィグレーション）を跨って処理に必要なストリームを保持しておくこと、を前提として説明する。

圧縮処理や伸長処理におけるモジュール分割に当たっての基本的な考え方としては、入力ストリーム量を（均等に）分割し、各モジュールでは分割して入力されるストリームに対してそれぞれ同一の圧縮率を適用する第１の手法（図３０（１））と、圧縮率を（均等に）分割し、分割せずに入力されるストリームに対して分割された圧縮率を適用する第２の手法（図３０（２））とがある。

図３０において、入力ストリーム量＝４ユニット、圧縮率＝２５％の場合で、具体的に説明する。第１の手法の場合、図３０（１−１）に示すように、第１圧縮器Cm１は、４ユニットの入力ストリームの内の２ユニットが入力され、２５％圧縮を適用して０．５ユニットのストリームを出力する。また、第２圧縮器Cm２は、４ユニットの入力ストリームの内の２ユニットが入力され、２５％圧縮を適用して０．５ユニットのストリームを出力する。この場合、第１圧縮器Cm１と第２圧縮器Cm２は同時並行的な動作も可能であるので、各モジュールをハードウェアとソフトウェアに分担する場合、何れか一方を先のパイプラインステージで処理し、他方を後のパイプラインステージで処理する段階処理の手法（図３０（１−２））と、双方を同一のパイプラインステージで処理する同時並行処理の手法（図３０（１−３））の何れも採り得る。ただし、何れの手法を採るかで、パイプラインステージでのストリーム使用量合計MSUMが異なってくる。

段階処理の場合、図３０（１−２）に示すように、たとえば、ハードウェア（Ｈ／Ｗ）処理後にソフトウェア（Ｓ／Ｗ）処理を行なうものとすると（逆でもよい）、第１段階での処理において、一方の圧縮器Cmの入出力ストリームのストリーム合計は２．５（＝２＋０．５）ユニットとなる。このとき、４ユニットの入力ストリームの内の処理を待機させる２ユニットが蓄積型ストリームとして取り扱われるので、第１段階のパイプラインステージでのストリーム使用量合計MSUMは４．５（＝２．５＋２）ユニットとなる。次の第２段階での処理において、他方の圧縮器Cmの入出力ストリームのストリーム合計は２．５＝２＋０．５）ユニットとなる。このとき、第１段階で処理された圧縮済みの出力ストリーム（０．５ユニット）が積型ストリームとして取り扱われるので、第２段階のパイプラインステージでのストリーム使用量合計MSUMは３．０（＝２．５＋０．５）となる。

同時並行処理の場合、図３０（１−３）に示すように、一方の圧縮器Cmの入出力ストリームのストリーム合計は２．５ユニットとなり、他方の圧縮器Cmの入出力ストリームのストリーム合計は２．５ユニットとなり、当該パイプラインステージでのストリーム使用量合計MSUMは５．０（＝２．５＋２．５）となる。

第２の手法の場合、図３０（２−１）に示すように、必然的に、何れか一方を先のパイプラインステージで処理し、他方を後のパイプラインステージで処理する段階処理の手法となる。たとえば、ハードウェア（Ｈ／Ｗ）処理後にソフトウェア（Ｓ／Ｗ）処理を行なうものとすると（逆でもよい）、第１段階での処理において、一方の圧縮器Cmの入出力ストリームのストリーム合計は６（＝４＋２）ユニットとなり、これがそのまま、第１段階のパイプラインステージでのストリーム使用量合計MSUMとなる。次の第２段階での処理において、他方の圧縮器Cmの入出力ストリームのストリーム合計は３（＝２＋１）ユニットとなり、これがそのまま、第２段階のパイプラインステージでのストリーム使用量合計MSUMとなる。

第１・第２の手法の何れを採用するかは、たとえば、圧縮器Cmや伸長器Exのアルゴリズムの観点から決める。圧縮や伸長の対象データが複数に分割でき並列処理が可能である場合、図３０（１−２）に示すように圧縮器Cmや伸長器Exを分割する。圧縮や伸長が処理内容により段階的に分割が可能である場合、図３０（１−２）に示すように圧縮器Cmや伸長器Exを分割する。また、これらの分割はそれぞれ同時に実施することができる。

＜蓄積型のスケジューラモデル：第３実施形態＞
図３１〜図３１Ｂは、第３実施形態の仕組みのモデルケース（蓄積ストリーム対応のケース）を示す図である。ここで、図３１は、ハードウェアによる対処部分とソフトウェア処理による対処部分の関係の基本を説明する図である。図３１Ａは、図３１についてのタイムスケジュールを示している。図３１Ｂは、図３１の状態において、具体的な数値例（図２８の事例）を適用して、スケジュールの更新後を示している。

なお、ここでは、圧縮処理や伸長処理におけるモジュール分割に当たって、圧縮率を分割し、分割せずに入力されるストリームに対して分割された圧縮率を適用する第２の手法（図３０（２））を採用する。前述のように、第２の手法の場合、段階処理となるので、最終的な圧縮率は各モジュールに適用される圧縮率の合成（積）となる。

また、圧縮処理のモジュール分割に関しては、ハードウェア処理による圧縮処理を先ず実行し、ハードウェアによる圧縮処理済みのストリーム（「中間（圧縮）」と記す）に対して、別のパイプラインステージ（リコンフィグステージ）においてソフトウェア処理による圧縮処理を実行する。また、伸長処理のモジュール分割に関しては、ソフトウェア処理による伸長処理を先ず実行し、ソフトウェアによる圧縮処理済みのストリーム（「中間（圧縮）」と記す）に対して、別のパイプラインステージ（リコンフィグステージ）においてハードウェア処理による伸長処理を実行する。

また、ハードウェアによる圧縮処理の圧縮率は５０％とし、ソフトウェアによる圧縮処理の圧縮率は５０％とする。ソフトウェアによる伸長処理時には圧縮率５０％に対応する（逆数の）伸長処理を行ない、ハードウェアによる伸長処理時には圧縮率５０％に対応する（逆数の）伸長処理を行なう。最終的な圧縮率は２５％（＝５０％×５０％）となる。

圧縮器Cmや伸長器Exをパイプラインステージに挿入するに当たっては、その部分をソフトウェア処理で対処する場合、パイプライステージの１ステージ内に収まれば複数のモジュールを組み込み得る。

たとえば、図３１では、ハードウェア（Ｈ／Ｗ：画像処理リコンフィグ部１２）により、蓄積型のStream３，Stream６について所定の圧縮率で圧縮処理を実行し、この処理済みの中間ストリーム（中間（圧縮））に対して、別のパイプラインステージにおいて、ソフトウェア（Ｓ／Ｗ：リコンフィグ制御部２０やコントローラメインＣＰＵ５０）により所定の圧縮率で圧縮処理を実行する。そして、この処理済みのストリーム（圧縮）に対して、別のパイプラインステージにおいて、ソフトウェア（Ｓ／Ｗ：リコンフィグ制御部２０やコントローラメインＣＰＵ５０）により所定の圧縮率に対応する（逆数の）伸長処理を実行し、この処理済みの中間ストリーム（中間（圧縮））に対して、別のパイプラインステージにおいて、ハードウェア（Ｈ／Ｗ：画像処理リコンフィグ部１２）により所定の圧縮率に対応する（逆数の）伸長処理を実行する。

この過程において、先ず、ハードウェア処理部分では、図３１Ａに示すように、非蓄積型ストリームに対しての画像処理と、後に蓄積型ストリームとなるストリームに対しての圧縮処理や直前のパイプラインステージでは蓄積型ストリームであったストリームに対しての伸長処理を、並行的に実行する。

また、ソフトウェア処理部分では、図３１Ａに示すように、一方のストリームについての圧縮処理と他方（１つとは限らない）のストリームについての圧縮処理、一方のストリームについての圧縮処理と他方１つとは限らない）のストリームについての伸長処理、あるいは、一方のストリームについての伸長処理と他方（１つとは限らない）のストリームについての伸長処理、と言った任意の組合せで、圧縮処理や伸長処理のソフトウェアモジュール（以下、単にモジュールとも称する）を分割して、同一パイプライステージ内で複数のモジュールを順番に実行する。図３１や図３１Ａに示した例では、画像処理４のパイプラインステージ４のとき、Stream６中間（圧縮）に対する圧縮処理を実行し、次に、Stream３（圧縮）に対する伸長処理を実行している。また、画像処理５のパイプラインステージ５のとき、Stream６中間（圧縮）に対する圧縮処理を実行し、次に、Stream３（圧縮）に対する伸長処理を実行している。

実際に数値を適用した図３１Ｂを参照して、さらに詳細に説明する。メモリ空間や入出力ストリームのストリーム量は、図２８に示したものと同一である。画像処理２（パイプラインステージ２）のとき、ハードウェア処理ではStream２（１ユニット）に対して画像処理が実行され、Stream４（１ユニット）が出力される。このとき、並行して、画像処理１（パイプラインステージ１）から出力されたStream３（４ユニット）に対して５０％の圧縮率で圧縮処理を実行する。したがって、圧縮後の予測メモリ使用量は、１＋１＋４＋（２）＝８ユニットとなる。

画像処理３（パイプラインステージ３）のとき、ハードウェア処理ではStream４（１ユニット）に対して画像処理が実行され、Stream５（２ユニット）とStream６（２ユニット）が出力される。また、並行してソフトウェア処理では、パイプラインステージ２のハードウェア処理で圧縮されたStream３中間（圧縮）（２ユニット）に対して５０％の圧縮率で圧縮処理を実行する。したがって、圧縮後の予測メモリ使用量は、１＋２＋２＋（２）＋（１）＝８ユニットとなる。

画像処理４（パイプラインステージ４）のとき、ハードウェア処理ではStream５（２ユニット）に対して画像処理が実行され、Stream７（１ユニット）が出力される。このとき、並行して、画像処理３（パイプラインステージ３）から出力されたStream６（２ユニット）に対して５０％の圧縮率で圧縮処理を実行する。また、並行してソフトウェア処理では、パイプラインステージ３のソフトウェア処理で圧縮されたStream３（圧縮）（１ユニット）に対して５０％の圧縮率に対応した伸長処理を実行する。したがって、圧縮後の予測メモリ使用量は、２＋１＋２＋（１）＋（（１））＋（２）＝９ユニットとなる。

画像処理５（パイプラインステージ５）のとき、ハードウェア処理ではStream７（１ユニット）に対して画像処理が実行され、Stream８（１ユニット）が出力される。このとき、並行して、パイプラインステージ４のソフトウェア処理で伸長されたStream３中間（圧縮（２ユニット）に対して５０％の圧縮率に対応した伸長処理を実行する。また、並行してソフトウェア処理では、パイプラインステージ４のハードウェア処理で圧縮されたStream６中間（圧縮）（１ユニット）に対して５０％の圧縮率で圧縮処理を実行する。したがって、圧縮後の予測メモリ使用量は、１＋１＋４＋（２）＋（１）＋（（０．５））＝９．５ユニットとなる。

各パイプラインステージにおいて、圧縮後の予測メモリ使用量は、何れも、メモリ空間＝１０ユニットよりも少ないので、メモリ容量オーバーとなる事象は起きない。また、更新後の画像処理回数（コンフィグ面）は更新前（図２８）と同じであるから、画像処理回数が増加しないため、画像処理のスピード低下が発生しない。

＜非蓄積型のスケジューラモデル：第３実施形態＞
図３２は、第３実施形態の仕組みのモデルケース（非蓄積ストリーム対応のケース）を示す図である。ここで、図３２は、蓄積ストリーム対応の図３１Ａに対応するもので、タイムスケジュールを示している。

非蓄積型ストリームを処理対象として、圧縮・伸長の有無を選択的に切り替えるとともに、圧縮・伸長をモジュール分割してハードウェア処理とソフトウェア処理を組み合わせるときに、図３０（２）に示した第２の手法を適用する場合、ソフトウェア処理を行なっている間は、ハードウェア処理で必要なストリームが準備されていないので、ソフトウェア処理が完了するまでの間はハードウェア処理を待機（Wait）する。よって、この待機期間が、オーバーヘッドとして処理時間に加算される。

たとえば、図３２は、画像処理２の出力ストリームを、直後のパイプラインステージである画像処理３の入力ストリームとして使用する場合において、第３実施形態の仕組みを適用する場合を示している。この場合、画像処理リコンフィグ部１２は（ハードウェア処理においては）、画像処理２から出力されるストリームを、自パイプラインステージに組み込んだ圧縮器Cmに直ちに入力して、所定の圧縮率（たとえば５０％）で圧縮する。圧縮処理が完了するとハードウェア処理は一旦処理を停止させる。同一画素データについては画像処理後に圧縮処理を行なうが、他の画素データとの関係では画像処理と並行に圧縮処理がなされるので、圧縮処理のための時間ロスは抑えられる。メモリ使用量の増加もない。

ハードウェア処理にて圧縮されたストリームは、プロセッサ部へ渡される。プロセッサ部は、それを、ソフトウェア処理にて、所定の圧縮率（たとえば２５％）で圧縮する。そして、ソフトウェア処理にて圧縮されたストリームをローカルメモリ３０に格納する。パイプラインステージの切替え（リコンフィグ）時には、ソフトウェア処理により、ローカルメモリ３０からストリームを取り込み、所定の圧縮率（たとえば５０％）に対応する伸長処理を行ない、パイプラインステージの切替え（リコンフィグ）が完了している画像処理リコンフィグ部１２に渡す。

画像処理リコンフィグ部１２は（ハードウェア処理においては）、ソフトウェア処理側から取り込んだストリームに対して自パイプラインステージに組み込んだ圧縮器Cmにより所定の圧縮率（たとえば５０％）で圧縮する。圧縮処理が完了すると直ちに画像処理３に入力して画像処理を実行する。同一画素データについては圧縮処理後に画像処理を行なうが、他の画素データとの関係では圧縮処理と並行に画像処理がなされるので、圧縮処理のための時間ロスは抑えられる。メモリ使用量の増加もない。

このように、非蓄積ストリームの場合に、第３実施形態の仕組みを適用するには、ソフトウェアプロセス期間中、コンフィグを停止させることになる。その間は、ハードウェア処理は待機期間となるので、この待機期間が、オーバーヘッドとなる。

＜フロアプランレイアウト：第３実施形態＞
図３３は、第３実施形態の画像処理リコンフィグ部１２に対して適用されるフロアプランレイアウトの一例を示す図である。この図は、画像処理部を動的に再構成可能な画像処理リコンフィグ部１２に、圧縮器Cmや伸長器Exをハードウェアとして挿入する際のレイアウト態様を示す。

画像処理リコンフィグ部１２の再構成可能な回路部分は、予め、画像処理領域と、圧縮器Cmや伸長器Exの領域を分けておくのがよい。このことを、本実施形態では、フロアプランと称し、このフロアプランに基づく各部分の配置状態をフロアプランレイアウトと称する。エリア（セグメント）割りをより細かくすると、画像処理リコンフィグ部１２のリソースがより効率的に使用されるようになる。

図３３に示す例では、コンフィグ１面を４エリアに分割し、使用率に応じてどのエリアに物理的に配置しているかを示す。たとえば、基本エレメント総数を１００、使用エレメント数を２５（使用率２５％）としたとき、使用エリアは、１，２，３，４の何れかとなる。また、基本エレメント総数を１００、使用エレメント数を５０（使用率５０％）としたときには、１〜４の何れか２つの組合せとなり、この組合せを括弧書きで示すと、使用エリアは、（１，２），（１，３），（１，４），（２，３），（２，４），（３，４）となる。

画像処理リコンフィグ部１２は、コンフィグ（画像処理部や圧縮器Cmや伸長器Ex）の選択時には、この使用エリアが重ならないようにする。たとえば、画像処理３の使用率が５０％であるときに、圧縮器Cm１を挿入するときに、その使用率が２５％であるときには、たとえば、画像処理３をエリア（２，４）に割り当て、圧縮器Cm１をエリア１に割り当てる。

＜スケジューラ部の処理手順：第３実施形態＞
図３４は、第３実施形態のデータ処理装置１におけるリコンフィグ制御部２０によるスケジューリング機能の処理手順（メインフロー）を説明するフローチャートである。

リコンフィグ制御部２０は先ず、オリジナル（更新前）のリコンフィグパイプライン管理テーブルTB31から圧縮閾値THを算出する（Ｓ3100）。おして、パイプラインステージ（リコンフィグステージ）ごとに蓄積ストリームから圧縮すべきストリームや伸長すべきストリームをピックアップし（Ｓ3110）、ピックアップしたストリームの圧縮処理から伸長処理の期間（圧縮→伸長の期間）が、圧縮ソフトウェアバジェットと伸長バジェットの総和（圧縮ＳＷバジェット＋伸長バジェット）よりも少ないか否かを判断する（Ｓ3120）。

イエスであれば、リコンフィグ制御部２０は、圧縮器管理テーブルTB32や伸長器管理テーブルTB33とリコンフィグパイプライン管理テーブルTB31に記述のコンフィグデータの画像処理部の回路使用サイズに基づいて、挿入できる圧縮器Cmや伸長器Exを設定する（Ｓ3130）。その詳細は後述するが、圧縮器Cmや伸長器Exのどのモジュールが画像処理リコンフィグ部１２に挿入できるかを判断すると言うことである。

次に、リコンフィグ制御部２０は、画像処理コンフィグデータに圧縮器Cmや伸長器Exを挿入し、圧縮器管理テーブルTB32や伸長器管理テーブルTB33において、選択されなかったモジュールをソフトウェア処理としてセットし、次のステージの処理に移動する（Ｓ3140）。

一方、ステップＳ3120の判断においてノーであれば、リコンフィグ制御部２０は、圧縮器管理テーブルTB32や伸長器管理テーブルTB33において、圧縮器Cmや伸長器Exを全てソフトウェアプロセスにセットし、次のステージの処理に移動する（Ｓ3150）。

＜リコンフィグパイプライン管理テーブル：第３実施形態＞
図３５および図３５Ａは、リコンフィグパイプライン管理テーブルTB31の一例を示す図である。ここで、図３５は最初の状態（オリジナル）を示し、図３５Ａは、更新後の状態を示す。

第３実施形態のリコンフィグパイプライン管理テーブルTB31は、パイプラインステージ（リコンフィグ）順に、コンフィグデータ、入力ストリームの情報、出力ストリームの情報などの情報が管理されるようになっている。コンフィグデータとしては、名前（Name）と回路使用サイズ（％）がある。入力ストリームの情報としては、名前（Name），サイズがある。出力ストリームの情報としては、名前（Name），サイズ，「蓄積ストリームか」がある。「蓄積ストリームか」は、後に蓄積型ストリームとなるかを意味する。

リコンフィグ制御部２０は、このリコンフィグパイプライン管理テーブルTB31のコンフィグデータ情報とストリーム情報を用いて、スケジューリングを組む。ここで、コンフィグデータ情報とは、名前（Name）、回路使用サイズ（％）である。ストリーム情報とは、名前（Name）、サイズ、「蓄積ストリームか」である。

たとえば、図３５に示すオリジナルのリコンフィグパイプライン管理テーブルTB31では、画像処理１の回路使用サイズが１００％であり、空きエリアが０％であるから、圧縮器Cmや伸長器Exの挿入可能なエリアが存在しないことが分る。一方、画像処理２の回路使用サイズが２５％であり、空きエリアが７５％であるから、その７５％エリアに圧縮器Cmや伸長器Exが挿入可能であることが分る。同様に、画像処理３の回路使用サイズが５０％であり、空きエリアが５０％であるから、その５０％エリアに圧縮器Cmや伸長器Exが挿入可能であることが分る。画像処理４の回路使用サイズが７５％であり、空きエリアが２５％であるから、その２５％エリアに圧縮器Cmや伸長器Exが挿入可能であることが分る。

リコンフィグ制御部２０は、オリジナルのリコンフィグパイプライン管理テーブルTB31から、どのストリームを圧縮し、どのストリームを伸長するかを求め、求めた結果を圧縮・伸長管理の情報として、リコンフィグパイプライン管理テーブルTB31に追加することで、リコンフィグパイプライン管理テーブルTB31を更新する。

圧縮・伸長管理の情報としては、圧縮閾値TH（＝蓄積ストリーム許容値÷（蓄積ストリーム数＋出力ストリーム数））、圧縮が必要なストリーム、伸長が必要なストリームの情報が登録される。因みに、圧縮対象とされた蓄積型ストリーム（蓄積圧縮ストリーム）については、画像処理前に伸長処理が必要となるので、使用する前に伸長しておくことになる。

＜ハードウェア処理とソフトウェア処理の振り分け手法：第３実施形態＞
図３６は、ハードウェア処理とソフトウェア処理の振り分けの手順を説明する図である。リコンフィグ制御部２０は、画像処理とレイアウトが重ならないように圧縮器Cmや伸長器Exのモジュールを選択する。そして、ハードウェアとして選択されなかったモジュールはソフトウェアプロセスとしてセットし、圧縮器Cmや伸長器Exのパイプラインを決定する。

具体的には、図示を割愛するが、リコンフィグ制御部２０は先ず、分割した圧縮器Cmや伸長器Exのソフトウェア処理の適用において、モジュールを１つピックアップし（Ｓ3010）、ピックアップしたモジュールがその判断時点で判断対象の中で最も重たいソフトウェア処理であるか否かを判断する（Ｓ3012）。ノーであれば判断対象の中で次のモジュールをピックアップし（Ｓ3012-N、Ｓ3014）、同様に判断する（Ｓ3012）。イエスであればピックアップしたモジュールをハードウェアによる圧縮や伸長で適用できるか否か、つまり、画像処理リコンフィグ部１２に圧縮器Cmや伸長器Exを挿入できるか否かを判断する（Ｓ3012-Y，Ｓ3020）。

リコンフィグ制御部２０は、ハードウェアによる圧縮や伸長を適用できるときにはハードウェア処理で実行するようにスケジューリングし（Ｓ3020-Y，Ｓ3022）、ハードウェアによる圧縮や伸長を適用できないときにはソフトウェア処理で実行するようにスケジューリングする（Ｓ3020-N，Ｓ3024）。最も重たいソフトウェア処理のモジュールについて、ハードウェアでの実行かソフトウェアでの実行かを決定したら、そのモジュールは次の判断対象から除外するようにセットし（Ｓ3028）、ステップＳ3010に戻り、判断対象のモジュールが無くなるまで同様に繰り返す。つまり、ソフトウェア処理の重たい順から優先的にハードウェアを適用するようにする。なお、このとき、ハードウェアの圧縮や伸長の適用モジュールが他の適用モジュールと重ならないようにする。空きスペースが少なく、１つのモジュールもハードウェアで入らない場合は、全てをソフトウェアで対処する。

このように、先ず、スペースの許す限り、ソフトウェア処理の重たい順から優先的にハードウェアによる実装を行ない、ハードウェアで対処できない分をソフトウェア処理で対処するのは、それぞれの処理速度を勘案したものである。

たとえば、図３６に示すように、画像処理３のレイアウト群に対して圧縮器Cmのモジュール１（回路規模２５％とする）を適用する場合を考える。画像処理３の回路使用サイズは５０％であるので、４分割した２５％エリアの何れかにはモジュール１を挿入し得る。このときの振り分けの決定方法としては、一例として、論理アルゴリズムを利用する。たとえば、圧縮器Cmや画像処理として採り得る全ての配置の組合せについて、それぞれが配置されるフロアレイアウト部分を論理“１”に設定し、相互のフロアの論理積をとり、“１”が発生しない組み合わせを選択する。複数ある場合はその内の何れか選択すればよい。タスクが増加する場合にも、同様の手順を用いる。また、あるモジュールをハードウェアで追加した後に、さらに別のモジュール追加が可能であれば、さらにそのモジュールをハードウェアで追加する。

＜ハードウェア処理とソフトウェア処理の振り分けの手順：第３実施形態＞
図３７は、ハードウェア処理とソフトウェア処理の振り分けの手順の詳細を説明するフローチャートである。前述のように、リコンフィグ制御部２０は、画像処理と圧縮器Cmや伸長器Exのエリア（セグメント）が重ならないように、フロアプランレイアウトの中から何れかのエリア（セグメント）を選択し、画像処理リコンフィグ部１２の処理実行コンフィグや、リコンフィグ制御部２０（あるいはコントローラメインＣＰＵ５０）によるソフトウェアプロセスを設定する。

たとえば、リコンフィグ制御部２０は、スケジューラ処理をスタートさせると、先ず、現在のリコンフィグ順を確認する（Ｓ3200）。そして、画像処理の使用エリア数を「エリア数」にセットし（Ｓ3202）、全エリア数が「エリア数」以上であるか（全エリア数≧「エリア数」）を確認する（Ｓ3204）。ノーであれば、リコンフィグ制御部２０は、「ＳＷバジェット」が最大のモジュールをセットする（Ｓ3204-N，Ｓ3210）。そして、リコンフィグ制御部２０は、セットされた圧縮器Cmや伸長器Ex（圧縮／伸長器）のモジュールの使用エリア数を「エリア数」に加算し（Ｓ3212）、全エリア数が「エリア数」以上であるか（全エリア数≧「エリア数」）を確認する（Ｓ3214）。ノーであれば（Ｓ3214-N）、リコンフィグ制御部２０は、加算したエリア数を減算し（Ｓ3222）、モジュールを「ソフトウェア（Ｓ／Ｗ）プロセス」にセットする（Ｓ3224）。一方、イエスであれば（Ｓ3214-Y）、圧縮器管理テーブルTB32や伸長器管理テーブルTB33において、モジュールを「ロードモジュール」にセットする（Ｓ3226）。この後、リコンフィグ制御部２０は、全モジュールをチェックしたかを確認し（Ｓ3230）、ノーであれば、次の「ソフトウェアバジェット」のモジュールをセット（次プライオリティ参照用）する（Ｓ3232）。

一方、ステップＳ3204でイエスのときには、リコンフィグ制御部２０は、圧縮器管理テーブルTB32や伸長器管理テーブルTB33において、全モジュールを「Ｓ／Ｗプロセス」にセットする（Ｓ3240）。この後、あるいは、ステップＳ3230でイエスのときには、リコンフィグ制御部２０は、画像処理のレイアウト（エリア／セグメント：以下同様）を選択し（Ｓ3242）、「ロードモジュール」はセットされているかを確認する（Ｓ3250）。イエスであれば、リコンフィグ制御部２０は、セットされている「ロードモジュール」のレイアウトを選択する（Ｓ3250-Y，Ｓ3252）。そして、さらにフロアプランの論理積は“０”になるかを判断する（Ｓ3254）。ノーであればステップＳ3242に戻り、別の画像処理のレイアウトを選択する。図示を割愛するが、この繰返し処理で全ての組合せを確認し、見つからなければ諦める。

ステップＳ3250でノーのときやステップＳ3260でイエスのときには、圧縮器管理テーブルTB32や伸長器管理テーブルTB33において、選択されたレイアウトをセットしロード「Ｓ／Ｗプロセス」をリコンフィグ制御部２０やホスト部ＣＰＵ（コントローラメインＣＰＵ５０）にセットする（Ｓ3262）。そして、データ処理装置１は、画像処理リコンフィグ部１２によりリコンフィグレーションを、またローカルメモリ３０やコントローラメインＣＰＵ５０によりソフトウェア（Ｓ／Ｗ）を実行する（Ｓ3264）。

＜管理テーブルの具体例：第３実施形態＞
図３８〜図３８Ｄは、第３実施形態の仕組みにおいて適用される各種管理テーブルの具体例を示す図である。たとえば、図３８は、図２８〜図３１Ｂのパイプラインステージ１〜４において、リコンフィグパイプライン管理テーブルTB31aと圧縮器管理テーブルTB32との関係の具体例を示している。図３８Ａは、図２８〜図３１Ｂのパイプラインステージ５〜８において、リコンフィグパイプライン管理テーブルTB31ｂと伸長器管理テーブルTB33との関係の具体例を示している。図３８Ｂは、図３８と図３８Ａのリコンフィグパイプライン管理テーブルTB31ａ，TB31ｂを１つに纏めたものである。図３８Ｃは、更新後のリコンフィグパイプライン管理テーブルTB34を示し、図３８Ｄは、更新後のソフトウェアプロセス管理テーブルTB35を示す。

たとえば、図３８において、画像処理３に着目する。画像処理の回路使用サイズは５０％であり、圧縮が必要なストリーム５に対する圧縮器Cmとしては、圧縮器管理テーブルTB32に示すように、２つにモジュール分割したときのモジュール１はソフトウェアバジェットが３ステージで回路使用サイズが２５％、モジュール２はソフトウェアバジェットが０．３ステージで回路使用サイズが５０％である。

前述のように、ソフトウェアバジェットの大きいモジュールから優先的に処理されるので、モジュール１がハードウェアとして挿入可能か否かが先ず判断される。画像処理と圧縮器Cmの回路使用サイズの合計は、１００％以下なので、その範囲で、フロアの最適な組み合わせを選択する。このとき、画像処理と圧縮器Cmの各エリア（セグメント）がぶつからないように組み合わせる。本例では、ソフトウェアバジェットの大きいモジュール１が圧縮器管理テーブルTB32の「ロードモジュール」にセットされる。ここでの「ロードモジュール」とは、画像処理リコンフィグ部１２に圧縮器Cmを挿入し、画像処理と並列して圧縮処理するモジュールを意味する。モジュール１をロードモジュールにセットすると、残りのエリアは２５％であり、同一パイプラインステージ中では、モジュール２をハードウェアレイアウトに挿入できないため、圧縮器管理テーブルTB32の「Ｓ／Ｗプロセス」にセットされる。ここでの「Ｓ／Ｗプロセス」とは、ローカルメモリ３０やコントローラメインＣＰＵ５０にて、ソフトウェア（Ｓ／Ｗ）にて圧縮処理するモジュールを意味する。

また、図３８Ａにおいて、画像処理６に着目する。伸長が必要なストリーム４に対する伸長器Exとしては、伸長器管理テーブルTB33に示すように、２つにモジュール分割したときのモジュール１はソフトウェアバジェットが０．３ステージで回路使用サイズが５０％、モジュール２はソフトウェアバジェットが３ステージで回路使用サイズが２５％である。前述のように、ソフトウェアバジェットの大きいモジュールから優先的に処理されるので、モジュール２がハードウェアとして挿入可能か否かが先ず判断される。画像処理と伸長器Exの回路使用サイズの合計は、１００％以下なので、その範囲で、フロアの最適な組み合わせを選択する。このとき、画像処理と伸長器Exの各エリア（セグメント）がぶつからないように組み合わせる。

本例では、ソフトウェアバジェットの大きいモジュール２が伸長器管理テーブルTB33の「ロードモジュール」にセットされる。ここでの「ロードモジュール」とは、画像処理リコンフィグ部１２に伸長器Exを挿入し、画像処理と並列して伸長処理するモジュールを意味する。モジュール２をロードモジュールにセットすると、残りのエリアは２５％であり、同一パイプラインステージ中では、モジュール１をハードウェアレイアウトに挿入できないため、伸長器管理テーブルTB33の「Ｓ／Ｗプロセス」にセットされる。ここでの「Ｓ／Ｗプロセス」とは、ローカルメモリ３０やコントローラメインＣＰＵ５０にて、ソフトウェア（Ｓ／Ｗ）にて伸長処理するモジュールを意味する。

リコンフィグ制御部２０は、これらの情報を、リコンフィグパイプライン管理テーブルTB31やソフトウェアプロセス管理テーブルTB35に追加することで各管理テーブルを更新する。たとえば、リコンフィグパイプライン管理テーブルTB31に関しては、図３８Ｃに示すように、圧縮器Cmや伸長器Exに関して、２つに分割したモジュール１，２を、ハードウェア回路で対処するのかソフトウェアで対処するのかの情報を追記する。

また、ソフトウェアプロセス管理テーブルTB35に関しては、図３８Ｄに示すように、パイプラインステージ（リコンフィグ）順に、ソフトウェア（Ｓ／Ｗ）プロセス、入力ストリームの情報、出力ストリームの情報などの情報が管理されるようになっている。ソフトウェアプロセスとしては、圧縮器Cmや伸長器Exのモジュールの別を特定する名前（Name）とソフトウェアバジェットがある。入力ストリームの情報としては、名前（Name），サイズがある。出力ストリームの情報としては、名前（Name），サイズがある。

＜圧縮器管理テーブル：第３実施形態＞
図３９は、第３実施形態の仕組みにおいて適用される圧縮器管理テーブルTB32の具体例を説明する図である。ここでは、非可逆圧縮の一例であるＰＮＧ（Portable Network Graphics ）圧縮を適用する１つの圧縮器Cmを２つにモジュール分割する場合を例示する。ＰＮＧ圧縮の処理手法は、「ＬＺ７７＋固定ハフマンコードによる静的ハフマン」、もしくは、「ＬＺ７７＋動的ハフマンコードによる静的ハフマン」の何れかの方法で圧縮することになる。因みに、ＬＺ法は、Abraham LempelとJacob Ziv の二人によるもので、正式名称はZiv-Lempel coding であり、ＬＺ７７は、１９７７年に開発された手法である。

前述から分るように、ＰＮＧ圧縮はＬＺ７７とハフマン符号化の組合せで実現されるので、そのモジュール分割に当たっては、図３９（１）に示すように、モジュール１にＬＺ７７を割り当て、モジュール２にハフマン符号化を割り当てて処理する段階的手法を適用する。ＬＺ７７はソフトウェアバジェットが重たいが回路規模は小さく、一方、ハフマン符号化はソフトウェアバジェットが軽いが回路規模は大きいという特徴がある。一例として、図３９（２）に示すように、ＬＺ法が適用されるモジュール１は、ソフトウェアバジェットが０．３ステージで回路使用サイズが５０％、ハフマン符号化が適用されるモジュール２はソフトウェアバジェットが３ステージで回路使用サイズが２５％である。前例に則して言えば、ＬＺ７７が適用されるモジュール１の方を優先的にハードウェアで対処するように設定するのが好ましいことになる。

＜纏め：第３実施形態＞
図４０は、前述の図２８〜図３９に示した事例を纏めて、第３実施形態の仕組みの特徴を事例に則して示した図である。第３実施形態を適用しない比較例の場合は、図２８から分るように、画像処理リコンフィグ部１２で対処しようとすると、８コンフィグ（本来の画像処理）＋３コンフィグ（圧縮用）＋３コンフィグ（伸長用）が必要となる。パイプラインステージ（コンフィグ）の数が増えるいので、圧縮や伸長のためにパイプラインステージ（コンフィグ）の数が増えるので、処理時間が掛る。

これに対して、第３実施形態の仕組みでは、画像処理の最中に保持しているストリームを圧縮処理し、また圧縮処理したものについては画像処理前に伸長処理し、ＤＲＰ１０の外部メモリであるローカルメモリ３０のメモリ容量をオーバーしないように制御する。このとき、第３実施形態では、画像処理と並列動作するように、圧縮器Cmや伸長器Exをモジュール分割し画像処理リコンフィグ部１２の空きエリアから適応的に選択して挿入するハードウェア面からの対処を実行し、ハードウェアとして挿入されなかったモジュールはソフトウェア処理で対処するようにした。これによって、前述の事例では、８コンフィグ（本来の画像処理）で対処される。第３実施形態の仕組みでは、パイプラインステージ（コンフィグ）の数が増えないので、画像処理が８処理（コンフィグ）、３ストリームを圧縮／伸長する場合、第３実施形態を適用しない場合と比較して、高速化されることが分る。

＜＜第３実施形態の比較例＞＞
＜第１比較例：第３実施形態＞
図４１は、第３実施形態のデータ処理装置１に対する第１比較例を説明する図である。第１比較例は、特開平０６−０７０１７１号公報に記載の仕組みに該当する。この仕組みは、第一圧縮部で圧縮し、第一伸長部で伸長し画像処理を実施し、第二圧縮部で圧縮し、第二伸長部で伸長するものである。画像メモリに記憶される画像データは必ず圧縮されているため、画像メモリは少量される。しかしながら、全てのストリームに圧縮部や伸長部が挿入されているため、回路規模は大きくなる。

＜第２比較例：第３実施形態＞
図４１Ａは、第３実施形態のデータ処理装置１に対する第２比較例を説明する図である。第２比較例は、特開平０９−０８４００４号公報に記載の仕組みに該当する。この仕組みは、汎用マイクロプロセッサと専用回路が協調動作して効率よく画像データを伸長するものである。処理全体を専用回路と汎用プロセッサに分割するので、専用回路の個数が減少され、ハードウェア規模は抑制される。しかしながら、専用回路のため、決まったパイプラインしか組めないという難点がある。また、画像処理と圧縮処理や伸長処理が並列処理ができないため、回路規模が増加する。換言すると、圧縮処理や伸長処理のために、専用回路を付与しなければいけないことになる。

＜第３比較例：第３実施形態＞
図４１Ｂは、第３実施形態のデータ処理装置１に対する第３比較例を説明する図である。第３比較例は、特開２００１−０２７９８６号公報に記載の仕組みに該当する。この仕組みは、擬似データを用いてハードウェアの処理時間を取得し、その時間によってハードウェア処理とソフトウェア処理を振り分けるものである。この際には、テストデータの処理時間に応じて、ハードウェア（Ｈ／Ｗ）とソフトウェア（Ｓ／Ｗ）を振り分ける。しかしながら、画像処理と圧縮処理や伸長処理は、並列処理ができないため、回路規模が増加する。換言すると、圧縮処理や伸長処理のために、たとえば、コーデックと言った専用回路を付与しなければいけないことになる。加えて、どちらか一方しか使用しないため、リソース使用が非効率である。

これら比較例１〜３に対して、第３実施形態の仕組みは、前述のように、ＤＲＰ１０などの「内部処理構成をプログラマブル可能なデバイス」を使用してスケジューリングを行なう仕組みを採り、メモリ容量オーバーとなるケースでは、圧縮や伸長を挿入することで対処する。この際、第３実施形態では、図４０においても説明したように、圧縮器Cmや伸長器Exをモジュール分割し画像処理リコンフィグ部１２の空きエリアから適応的に選択して挿入するハードウェア面からの対処を実行し、ハードウェアとして挿入されなかったモジュールはソフトウェア処理で対処する。このため、パイプラインステージ（コンフィグ）の数が増えないので、処理速度には影響がなく、メモリ容量オーバーも起きない。

＜＜第４実施形態＞＞
次に、データ処理装置１の第４実施形態について説明する。なお、第４実施形態においては、説明文では「伸長」と記す。図面中で、「伸長」を「伸張」と記すことがあるが、これらは同義である。また、図面中で、圧縮器Cmと伸長器Exを纏めて「圧縮／伸長器」と記すことがある。

図４２および図４２Ａは、第４実施形態のデータ処理装置１の仕組みを説明する図である。ここで図４２（１）は、第４実施形態の仕組みを、圧縮器Cmや伸長器Exの種類とサイズの圧縮性能の関係から示した図である。図４２（２）は、第４実施形態の仕組みを、パイプラインステージの再構成（リコンフィグ）の側面から示した図である。図４２Ａは、図４２のより具体的な説明図である。

従前の仕組みでは、第１実施形態などで説明したように、圧縮や伸長をするべき入力ストリームや出力ストリームが複数ある場合に、ハードウェアで圧縮器Cmや伸長器Exを各パイプラインステージのデータ処理時（画像処理時）に入れるケースでは、入力ストリームごとに伸長器Exをまた出力ストリームごとに圧縮器Cmを実装する構成となるので回路規模が大きくなり、データ処理装置１（画像処理装置）のコストが掛る。また、第３実施形態とは異なる単純なソフトウェア処理で圧縮処理や伸長処理をする場合は、リソースを圧縮処理や伸長処理にとられるため、画像処理が完了する時間が遅くなる。

この対策として、第４実施形態においても、先ず、第１実施形態と同様に、ハードウェアリソースは増加させずに、データ処理（画像処理）速度の低下を抑制し、かつメモリ量を削減する。その第４実施形態の仕組みの基本は、それぞれ回路規模や処理性能の異なる複数の圧縮器Cmや伸長器Exを用意しておき、画像処理リコンフィグ部１２の空き回路規模・圧縮処理や伸長処理のタイミング・圧縮性能や伸長性能（たとえばアルゴリズムや予想圧縮率や処理速度など）に基づいて、複数の圧縮器Cmや伸長器Exの中から適正なものを選択し、画像処理（データ処理）と並行に、圧縮処理や伸長処理を実行することで、メモリ容量オーバーと時間ロスを抑え、ホスト部５側へのデータ転送である二次フォールバック処理の発生を最小限に抑える。

具体的には、図４２に示すように、画像処理リコンフィグ部１２の空きスペースを利用して、回路規模（回路サイズ）および圧縮性能や伸長性能の異なる複数の圧縮器Cmや伸長器Exを挿入する。たとえば、画像処理リコンフィグ部１２の再構成（リコンフィグ）時には、画像処理リコンフィグ部１２の空き回路スペースに入るか否と圧縮性能や伸長性能の両面から、最も適正（つまり最適）なものの複数を選択して、各パイプラインステージで使用する圧縮器Cmや伸長器Exとして設定する。「最も適正」の判断基準としては、少なくとも空き回路スペースに入ることが第１であり、次にたとえば、圧縮率あるいは処理速度を基準とする。圧縮率が良好な方を優先するか処理速度を優先するか、あるいは圧縮率が最適なものと処理速度が最速なものを組み合わせるなどは、パイプラインステージにおける処理に併せて（適応させて）選択するのがよい。

図４２Ａに示すように、画像処理リコンフィグ部１２の空き回路スペースを利用して、回路規模や処理性能（たとえば圧縮性能）の異なる複数の圧縮器Cmや伸長器Exを選択して挿入する。なお、図において、処理に使用されているストリーム（Stream）とは非蓄積型ストリームであり、処理にしようされていないストリームとは蓄積型ストリームである。

スタティック（Static）に、回路規模や圧縮性能の異なる複数の圧縮器Cmや伸長器Exの中から選択することで、空き回路スペースやメモリ容量に合わせた効率的な圧縮処理や伸長処理を実行する。その結果、二次フォールバック処理の発生が極力、抑制されるようになる。画像処理リコンフィグ部１２の空き回路スペースを利用して圧縮器Cmや伸長器Exを挿入して圧縮処理や伸長処理を実行するので所定の圧縮率が得られればメモリ使用量が削減されメモリ容量オーバーは回避されるし画像処理の時間ロスが殆ど発生しない。

＜複数の圧縮器＆伸長器の選択処理：第４実施形態＞
図４３および図４３Ａは、第４実施形態のデータ処理装置１における複数の圧縮器Cmや伸長器Exを選択して画像処理リコンフィグ部１２に挿入する基本動作例の処理手順（メインフロー）を説明するフローチャートである。因みに、図４３Ａは、図４３の続きである。当該処理は、第１実施形態におけるスタティック・スケジューリングの処理ステップ（Ｓ1010〜Ｓ1022）と比較対象となる処理である。

リコンフィグ制御部２０は、先ず、圧縮閾値THと各ストリームの情報を取得する（Ｓ4010）。その処理の具体例は後述する。ここで使用する圧縮閾値THは、たとえば第１実施形態の圧縮閾値TH１を使用する。

次に、リコンフィグ制御部２０は、パイプラインステージ（リコンフィグステージ）ごとのストリームから、圧縮すべきストリームや伸長すべきストリームを選択（ピックアップ）する（Ｓ4012）。その処理の具体例は後述する。

次に、リコンフィグ制御部２０は、複数の圧縮器Cmや伸長器Exを選択するメイン処理に移行する（Ｓ4020）。その処理の具体例は後述するが、基本的な処理手順は以下の通りである。リコンフィグ制御部２０は先ず、画像処理リコンフィグ部１２の空き回路規模から、圧縮タイミングや伸長タイミングで、ともに挿入が可能な圧縮器Cmや伸長器Exを選択（ピックアップ）する（Ｓ4022）。

次に、リコンフィグ制御部２０は、選択した圧縮器Cmや伸長器Exで圧縮閾値THをクリアできるものがあるか否かを判断する（Ｓ4030）。イエスであれば、圧縮閾値THをクリアする中で最も回路規模の小さな圧縮器Cmや伸長器Exを選択する（Ｓ4030-Y，Ｓ4032）。回路規模の小さなものを選択するのは、他のストリーム用にスペースを空けておくためである。一方、ノーであれば圧縮閾値THをクリアしない中で最も高圧縮な圧縮器Cmや伸長器Exを選択する（Ｓ4030-N，Ｓ4034）。高圧縮なものを選択するのは、ストリーム量を最大限に削減するためである。

この後、リコンフィグ制御部２０は、全ての圧縮あるいは伸長すべき蓄積ストリームで、圧縮器Cmや伸長器Exの選択が完了したかを確認し（Ｓ4040）、ノーであればステップＳ4012に戻り同様の処理を繰り返す（Ｓ4040-N）。

ステッップＳ4040の判断でイエスであれば、リコンフィグ制御部２０は、全ての圧縮あるいは伸長すべきストリームで圧縮閾値THをクリアするかを確認し（Ｓ4050）、イエスであれば当該処理を終了する。ノーであれば、リコンフィグ制御部２０は、非圧縮ストリームに対する圧縮処理や圧縮済みストリームに対する伸長処理を実行するようにスケジューリングする（Ｓ4052）。その処理の具体例は後述する。「非圧縮ストリーム」とは、「圧縮すべきストリーム」と対比するストリームであり、（本来であれば）圧縮が不要なストリーム、すなわち、圧縮閾値THをクリアしているストリームである。

この際には、圧縮閾値THをクリアしている非圧縮ストリームの中で回路規模に余裕があるものに対して圧縮処理を実行することで、あるいは圧縮閾値THをクリアしている圧縮済みストリームの中で回路規模に余裕があるものに対して伸長処理を実行することで、ローカルメモリ３０の空き容量を増やすようにスケジューリングする。

この後、リコンフィグ制御部２０は、全ての圧縮あるいは伸長すべきストリームで圧縮閾値THをクリアするかを確認し（Ｓ4060）、イエスであれば当該処理を終了する。ノーであれば、リコンフィグ制御部２０は、圧縮済みストリームの高圧縮化を実行するようにスケジューリングする（Ｓ4062）。その処理の具体例は後述する。この際には、圧縮閾値THをクリアしている圧縮済みストリームの中で回路規模に余裕がある場合より高圧縮の圧縮器Cmと伸長器Exに変更することで、ローカルメモリ３０の空き容量を増やすようにスケジューリングする。

この後、図示を割愛するが、各ストリームについて、より高圧縮の圧縮器Cmと伸長器Exの設定が完了したら処理を終了させる。また、空き容量を増やすことのできるものが見つからなければ、当該第４実施形態の仕組みの適用は困難であるとして、たとえば、ホスト部５側へのデータ転送（フォールバック処理：第１実施形態の二次フォールバック処理と同等の処理）を行なうように設定する。

＜圧縮閾値と各ストリームの情報の取得：第４実施形態＞
図４４は、圧縮閾値THと各ストリームの情報を取得する処理（Ｓ4010）の詳細を説明する図である。ここでは、説明を簡単にするため、特に断りのない限り、圧縮処理に関してのみ説明する。また、圧縮をすべきストリームとしては、当該パイプラインステージでの処理に使用されないストリーム、つまり、後の処理で使用するため蓄積しておかなければならないストリーム（蓄積型ストリーム）を対象とするものとする。これらは、後述する図４５〜図４８においても同様である。

当該処理（Ｓ4010）に当たっては、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB40をローカルメモリ３０に記憶する。当該処理（Ｓ4010）の圧縮器選択管理テーブルTB40は、パイプラインステージ（リコンフィグ）順に、圧縮可能ストリームや圧縮閾値THをクリアするか否の情報が管理されるようになっている。

リコンフィグ制御部２０は、パイプライン管理テーブルTB10を参照して、当該パイプラインステージでの処理に使用されないストリームをピックアップして圧縮可能ストリームの項目に登録する。さらに、ピックアップしたものを、圧縮閾値THをクリアできるものとできないものとに分別し、その分別情報を圧縮閾値THをクリアの項目に登録する。たとえば、クリアできるものには○を付し、クリアできないものは×を付す。そして、圧縮閾値THをクリアできないものは、圧縮すべきストリームとする。この例では、ストリーム１-2，１-1，３-2を圧縮すべきストリームとする。

＜圧縮・伸長すべきストリームの選択：第４実施形態＞
図４５は、パイプラインステージごとのストリームから、圧縮すべきストリームや伸長すべきストリームをピックアップする処理（Ｓ4012）の詳細を説明する図である。

当該処理（Ｓ4012）に当たっては、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB41をローカルメモリ３０に記憶する。当該処理（Ｓ4012）の圧縮器選択管理テーブルTB41は、圧縮器選択管理テーブルTB40の情報に加えてさらに、空き回路サイズ、圧縮タイミング、伸長タイミングの情報が管理されるようになっている。圧縮器選択管理テーブルTB40にこれらの情報を追加して圧縮器選択管理テーブルTB41とすればよい。

たとえば、リコンフィグ制御部２０は、パイプライン管理テーブルTB10を参照して、当該パイプラインステージの画像処理部の回路使用サイズに基づき画像処理リコンフィグ部１２の空き回路サイズを特定しその情報を「空き回路サイズ」の項目に追加する。また、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB40を参照して、圧縮すべきストリームに対して圧縮処理を適用し得る（圧縮器Cmを挿入し得る）パイプラインステージを特定しその情報を「圧縮タイミング」の項目に追加する。因みに、圧縮すべきストリームを圧縮した後で画像処理に使用するために伸長処理を適用し得る（伸長器Exを挿入し得る）パイプラインステージを特定しその情報を「伸長タイミング」の項目に追加する。

この例では、ストリーム１-2に対して画像処理２のステージで圧縮器Cmを挿入し画像処理４のステージで伸長器Exを挿入するように設定し、また、ストリーム１-1，３-2に対しては、画像処理３のステージで圧縮器Cmを挿入し、画像処理５のステージで伸長器Exを挿入するように設定する。

＜圧縮器・伸長器の選択：第４実施形態＞
図４６は、画像処理リコンフィグ部１２の空き回路規模から、圧縮タイミングや伸長タイミングで、ともに挿入が可能な圧縮器Cmや伸長器Exを選択する処理（Ｓ4022）の詳細を説明する図である。

当該処理（Ｓ4022）に当たっては、リコンフィグ制御部２０は、圧縮器Cmや伸長器Exごとに、回路サイズや予想圧縮性能を規定した圧縮器Cmや伸長器Exの性能表TB42をローカルメモリ３０に登録しておく。図示した例では、圧縮Ａ，伸長Ａは、圧縮器Cmは５０単位、伸長器Exは４０単位で、予想圧縮率が６／１０の低圧縮のものである。圧縮Ｂ，伸長Ｂは、圧縮器Cmは６０単位、伸長器Exは６０単位で、予想圧縮率が５／１０の低圧縮のものである。圧縮Ｃ，伸長Ｃは、圧縮器Cmが８０単位、伸長器Exが５０単位で、予想圧縮率が４／１０の中圧縮のものである。圧縮Ｄ，伸長Ｄは、圧縮器Cmが１００単位、伸長器Exが１００単位で、予想圧縮率が３／１０の中圧縮のものである。圧縮Ｅ，伸長Ｅは、圧縮器Cmが１５０単位、伸長器Exが１４０単位で、予想圧縮率が２／１０の高圧縮のものである。圧縮性能の劣る低圧縮なものほど回路サイズは小さく、圧縮性能の高い高圧縮なものほど回路サイズは大きくなっている。

また、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB43をローカルメモリ３０に記憶する。当該処理（Ｓ4022）の圧縮器選択管理テーブルTB43は、圧縮器選択管理テーブルTB41の情報に加えてさらに、１ストリーム当たりの回路サイズ、挿入可能な圧縮器Cmや伸長器Ex、圧縮閾値THをクリアする圧縮器Cmや伸長器Exの情報が管理されるようになっている。これらの追加情報を、圧縮器選択管理テーブルTB41と圧縮器Cmや伸長器Exの性能表TB42に基づいて特定し、圧縮器選択管理テーブルTB41にこれらの情報を追加して圧縮器選択管理テーブルTB43とすればよい。

たとえば、圧縮器選択管理テーブルTB41において、圧縮タイミングや伸長タイミングに記述のある部分について、空き回路サイズを処理対象のストリーム数で除算することで、１ストリーム当たりの回路サイズを特定し、その情報を「１ストリーム当たりの回路サイズ」の項目に追加する。そして、このようにして求めた１ストリーム当たりの回路サイズを圧縮器Cmや伸長器Exの性能表TB42に突き合わせることで、そのパイプラインステージに挿入可能な圧縮器Cmや伸長器Ex並びに圧縮閾値THをクリアするか否かを特定し、その情報を「挿入可能な圧縮／伸長器」や「圧縮閾値THをクリアする圧縮／伸長器」の項目に追加する。

たとえば、画像処理３のパイプラインステージについて着目したとき、圧縮Ｅは、１ストリーム当たりの回路サイズ（＝１５０）に対して、圧縮器Cmの回路サイズ（＝１５０）が大きく、伸長器Exの回路サイズ（＝１４０）が小さいので、圧縮器Cmは入るが伸長器Exが入らないため、挿入可能な圧縮／伸長器から除外する。

また、各圧縮すべきストリームについては、最終的には、圧縮閾値THをクリアするものの中で最低圧縮なものを選択する（Ｓ4032）。本例では、画像処理２のステージでは、圧縮すべきストリームはストリーム１-2のみであり、これについて挿入可能でかつ圧縮閾値THをクリアする圧縮ＢＣＤの中で最低圧縮な圧縮Ｂを選択する。また、画像処理３のステージでは、圧縮すべきストリームはストリーム１-1，３-2の２つがあり、ストリーム１-1については、挿入可能でかつ圧縮閾値THをクリアする圧縮ＣＤの中で最低圧縮な圧縮Ｃを選択し、ストリーム３-2については、挿入可能でかつ圧縮閾値THをクリアする圧縮は無いため、挿入可能で最も高圧縮な圧縮Ｄを選択する。圧縮すべきストリームが複数ある場合に、圧縮器Cmや伸長器Exを複数挿入する第４実施形態の仕組みが適用されていることが分る。

＜非圧縮ストリームの圧縮：第４実施形態＞
図４７は、非圧縮ストリーム（圧縮されていないストリーム）に対する圧縮処理のスケジューリング（Ｓ4052）の詳細を説明する図である。

リコンフィグ制御部２０は、圧縮器選択管理テーブルTB44をローカルメモリ３０に記憶する。当該処理（Ｓ4052）の圧縮器選択管理テーブルTB44は、圧縮器選択管理テーブルTB43の情報に加えてさらに、残り空き回路の情報が管理されるようになっている。残り空き回路の情報を特定し、圧縮器選択管理テーブルTB43に追加して圧縮器選択管理テーブルTB44とすればよい。

たとえば、リコンフィグ制御部２０は、非圧縮ストリームを圧縮タイミングや伸長タイミングに入れる。そして、１ストリーム当たりの回路サイズを再計算し、空き回路領域に余裕がある場合は、その非圧縮ストリームを圧縮する。たとえば、画像処理３のパイプラインステージについて着目したとき、圧縮閾値THをクリアしている非圧縮ストリームであるストリーム２-2を圧縮タイミングに追加する。次に、そのパイプラインステージ（画像処理３）の「空き回路サイズ」（＝３００）と「圧縮閾値THをクリアする圧縮／伸長器」（＝圧縮ＣＤあるいは圧縮Ｄ）に基づき、この時点での残りの空き回路サイズを計算する。この例では、圧縮ＣＤを入れたとき、圧縮器Cmや伸長器Exの性能表TB42からその回路サイズは“８０＋１００＝１８０”であるので、残りの空き回路サイズは“３００−１８０＝１２０”となる。リコンフィグ制御部２０は、この残りの空き回路サイズ内に、非圧縮ストリームであるストリーム２-2用の圧縮器Cmを挿入可能か否かを判断する。この例であれば、圧縮Ｅを除く圧縮ＡＢＣＤが挿入可能となる。また、最終的には、圧縮閾値THをクリアするものの中で最低圧縮なものを選択する（Ｓ4032）ので、ここでは圧縮Ａが選択される。

＜圧縮ストリームの高圧縮化：第４実施形態＞
図４８は、圧縮ストリームに対する高圧縮化のスケジューリング（Ｓ4062）の詳細を説明する図である。

リコンフィグ制御部２０は、圧縮器選択管理テーブルTB45をローカルメモリ３０に記憶する。当該処理（Ｓ4062）の圧縮器選択管理テーブルTB45は、表形式（データ項目）としては圧縮器選択管理テーブルTB44と同じであり、圧縮ストリームについて、さらに圧縮率の良好な圧縮処理を行なう場合は、その情報に書き換える点が異なるだけである。

たとえば、リコンフィグ制御部２０は、非圧縮ストリーム（圧縮されていないストリーム）に対して圧縮処理を適用した後、１ストリーム当たりの回路サイズを再計算する。そして、空き回路領域に余裕がある場合は、より性能のよい圧縮器Cmや伸長器Exに置き換えて挿入する。前例に則して説明すると、画像処理３のステージにおいて、ストリーム２-2用の圧縮器Cmとして圧縮Ａ（回路サイズ＝５０）を設定したときの残りの回路サイズを求める。本例の場合、“１２０−５０＝７０”となる。これによって、空き回路の有無や程度が分るので、次にリコンフィグ制御部２０は、空き回路領域に余裕がある場合は、圧縮ストリームで使用している圧縮器Cmをより高圧縮なもの（圧縮率の小さな圧縮性能の高いもの）に変更する。この際には、低圧縮なもの（圧縮率の大きな圧縮性能の低いもの）から適用するようにする。前例の場合、３つのストリーム１-1，３-2，２-2の内、最も低圧縮なものが設定されているのはストリーム２-2であるので、ストリーム２-2用の圧縮器Cmとして設定した圧縮Ａ（圧縮率＝６／１０、回路サイズ＝５０）を、たとえば圧縮Ｄ（圧縮率＝３／１０、回路サイズ＝１００）に変更する。圧縮Ｄへの変更を選択した理由は、より高圧縮な圧縮に変更することで使用メモリ量を減らすためである。

なお、図４７において、画像処理３のステージで、ストリーム３は、圧縮器Cmを挿入して圧縮閾値THを求めたとき圧縮閾値THをクリアできなかったものである。これについては、処理３のストリーム２-2の圧縮を圧縮Ａから圧縮Ｄに変更することで使用メモリ量を減らして圧縮閾値THの条件が緩和されたため、図４８に示すように、圧縮閾値THはクリアされている。

＜比較例との対比：第４実施形態＞
図４９は、第４実施形態の仕組みと比較例との差を説明する図である。第２実施形態の第４比較例でも説明したが、特開２００４−２７４７７６号公報に記載の仕組みの場合、圧縮には、処理速度の速い順で（圧縮性能の低い順で）、Ｍモード（ランレングス、高速、低圧縮）、ＬＺＷモード（辞書式、中速、中圧縮）、有損失モード（非可逆、高圧縮）の３つのモードが存在する。そして、メモリが不足している場合、実際に圧縮を行なって、メモリに入るかを確かめるため、Ｍモード→ＬＺＷモード→有損失モードの３つの圧縮が順に使用され、最大３回の圧縮を行なうことになり、その分のタイムロスが避けられない。これに対して、第４実施形態の仕組みでは、ＤＲＰ１０における画像処理リコンフィグ部１２の空き領域を利用し、その中で挿入可能な圧縮器Cmや伸長器Exを選択して圧縮や伸長を行なうため、タイムロスが殆ど発生しない。

また、第２実施形態の第５比較例でも説明したが、特開２００３−２４４４４６号公報に記載の仕組みの場合、メモリ容量を削減するため、画像データをＪｐｅｇ圧縮し、所定のデータ量になるまで、Ｑテーブルを（または量子化テーブルのビットシフトで）して、圧縮を繰り返すもので、圧縮処理と他の処理を並行に行なうことができないため、時間のロスが発生する。これに対して、第４実施形態の仕組みは、ハードウェアリソースは増加しないし、画像処理と並行に圧縮処理や伸長処理がなされるので圧縮処理や伸長処理のためのタイムロスが殆ど発生しない。

たとえば、各ストリームサイズを１ユニットと仮定して、第４実施形態を適用していない前述の図４４の場合（比較例）と、第４実施形態を適用した図４８の場合で比較する。また、図４４および図４８において、使用メモリが最も多い画像処理３に注目する。

第４実施形態を適用していない場合（図４４）、使用メモリ量（ストリーム使用量合計MSUM）は５ユニットになる。一方、第４実施形態を適用すると、使用メモリ量（ストリーム使用量合計MSUM）は、３．６＝１＋１＋（１＊４／１０）＋（１＊５／１０）＋（１＊４／１０）＋（１＊３／１０）となる。これから分るように、本事例では、ハードウェアリソースを増やさず、処理速度面での性能低下も殆ど発生せずに、使用メモリサイズが４０％削減される。

＜＜第５実施形態＞＞
次に、データ処理装置１の第５実施形態について説明する。なお、第５実施形態においては、説明文では「伸長」と記す。図面中で、「伸長」を「伸張」と記すことがあるが、これらは同義である。また、図面中で、圧縮器Cmと伸長器Exを纏めて「圧縮／伸長器」と記すことがある。

図５０は、第５実施形態のデータ処理装置１の仕組みを説明する図である。第１実施形態などでも述べたが、入力ストリームによって圧縮率は左右されるため、平均圧縮率通りに圧縮されるとは限らず、予測よりデータ量が増加した場合、ホスト部５側へのデータ転送であるフォールバック（第１実施形態の二次フォールバック処理に相当）の発生率が上昇する。

その対策として、第５実施形態では、予測よりデータ量が上回ったストリームを一旦伸長してＲＡＷデータに戻し、再圧縮を行なうリトライ圧縮を適用する。このとき、新たにパイプラインステージ（リコンフィグステージ）を設ける。つまり、ローカルメモリ３０のメモリ使用量が一定以上になった場合、動的に新たにパイプラインステージを設け、パイプラインステージにて圧縮処理を単独で行なって、ホスト部５側へのデータ転送であるフォールバックの発生を最小限に抑えるようにする。

具体的には、図５０（１）に示すように、予測が外れてストリームサイズが大きくなった場合には、図５０（２）に示すように、圧縮器Cmや伸長器Exのリトライファンクションを挿入する。新たにステージを設けて、圧縮ストリームを伸長し、再圧縮する。再圧縮時には、スタティック・スケジューリングで適用する平均圧縮率よりも高圧縮を適用するのは言うまでもない。

＜リトライ圧縮の基本：第５実施形態＞
図５１は、第５実施形態のデータ処理装置１におけるリトライ圧縮の基本的な処理手順（メインフロー）を説明するフローチャートである。因みに、当該リトライ圧縮処理は、第１実施形態における一次フォールバック処理の処理ステップ（Ｓ1040〜Ｓ1042）と比較対象となる処理である。

リトライ圧縮処理は、データ処理実行過程（ストリーム圧縮後）に行なうもので、実際の圧縮率が平均圧縮率よりも悪いため、メモリ容量オーバーとなる（あるいはその可能性がある）と、圧縮閾値TH未満のストリームについて、メモリ容量を可能な限り削減するためにより圧縮率が小さくなるように可逆圧縮する。具体的には、メモリ使用量（つまりストリーム使用量合計MSUM）が使用許容値（たとえばメモリサイズ・リミットやメモリサイズ）に対してＸ％以上になると（Ｓ5010-Y）、リトライ圧縮の適用に入る。

リトライ圧縮の適用に当たっては、圧縮ストリームの伸長と再圧縮を実行する（Ｓ5012）。この際には、新たにパイプラインステージを設けて、伸長器Exと圧縮器Cmを用意する。前述のように、再圧縮時には、スタティック・スケジューリングで適用する平均圧縮率よりも高圧縮の圧縮器Cmを採用する。

また、スタティック・スケジューリングで設定していた圧縮器Cmをより高圧縮のものに変更するので、それに応じて、伸長器Exの設定も変更することが必要になる（Ｓ5020）。その処理の具体例は後述するが、このため、リコンフィグ制御部２０は、「伸長のタイミングで伸長器Exの変更は可能か？」を判断する（Ｓ5022）。ノーであれば、リコンフィグ制御部２０は、再圧縮ストリームの伸長処理用として、伸長タイミングに合わせて新たにステージを設けて再圧縮に合わせた伸長器Exを用意する（Ｓ5022-N，Ｓ5024）。一方、イエスであれば、再圧縮ストリームの伸長処理用として、再圧縮に合わせた伸長器Exに変更する（Ｓ5022-Y，Ｓ5026）。

＜リトライ圧縮の判断基準：第５実施形態＞
図５２は、第５実施形態のデータ処理装置１におけるリトライ圧縮適用の判断基準（閾値：スレッシュ）を説明する図である。たとえば、図５２（１）に示すように、リトライ圧縮のスレッシュを９５％（＝Ｘ）とする場合、マージンは１０％（＝｛１００−Ｘ｝＊２）として圧縮閾値THを計算する。

詳細には、リトライ圧縮有無の判断基準（画像処理の段階でオーバーする場合）として、圧縮閾値TH＝（メモリ空間−現画像処理中の入力ストリームサイズ合計）÷（蓄積ストリーム数＋出力ストリーム数）とする。入力ストリームは圧縮できないので、許容メモリサイズから入力ストリームをマイナスする。そして、画像処理ストリームがメモリ容量オーバーしない場合は、蓄積ストリーム対応でスケジューリングする。実際にメモリ容量オーバーが発生すると、性能低下が大きいため、マージンを設けて、オーバーする直前までローカルメモリ３０を使用する場合に、リトライ圧縮を行なうようにする趣旨である。

＜圧縮データサイズとメモリ使用率：第５実施形態＞
図５３は、第５実施形態のデータ処理装置１における圧縮データサイズとメモリ使用率の取得処理を説明する図である。ここでは、メモリ使用率が９５％を超えるとリトライ圧縮対象にする例で説明する。

当該処理に当たっては、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB50をローカルメモリ３０に記憶する。当該処理の圧縮器選択管理テーブルTB50は、パイプラインステージ（リコンフィグ）順に、圧縮ストリーム、圧縮の種類、圧縮による予測ストリームサイズ、実際の圧縮サイズ、メモリ使用率の情報が管理されるようになっている。

たとえば、図５３に示すように、画像処理３のステージで、ストリーム２-2に対する圧縮Ｃでの圧縮処理時に、圧縮サイズが予測ストリームサイズ（＝０．４）にはならず０．７となり、メモリ使用率が９７％で、リトライ圧縮対象となっている。このストリーム２-2は、予測ストリームサイズからオーバーする分（０．７−０．４＝０．３）がある。

＜圧縮データサイズとメモリ使用率：第５実施形態＞
図５４は、第５実施形態のデータ処理装置１におけるリトライ圧縮の挿入処理を説明する図である。

当該処理に当たっては、リコンフィグ制御部２０は、圧縮器選択管理テーブルTB51をローカルメモリ３０に記憶する。当該処理の圧縮器選択管理テーブルTB51は、表形式（データ項目）としては圧縮器選択管理テーブルTB50と同じであり、実際の圧縮サイズが予測ストリームサイズからオーバーしリトライ圧縮のスレッシュを超えるために、そのストリームについてリトライ圧縮が適用される情報を追記する点が異なるだけである。

たとえば、図５３に示した前例であれば、ストリーム２-2について圧縮Ｃに対応した伸長Ｃを適用して元のＲＡＷデータに一旦戻し、圧縮器Cmや伸長器Exの性能表TB42を参照して、圧縮Ｃよりも高圧縮のもの、たとえば圧縮Ｅ（圧縮率２／１０）を設定する。こうすることで、圧縮率に相関関係があるとしたら、圧縮Ｅを適用した実際の圧縮サイズｘは、“４／１０：０．７＝２／１０：ｘ”であるから、ｘ＝０．３５となり、当初の予測ストリームサイズ＝０．４以下を満たすので、メモリ容量オーバーが回避される。

＜伸長器の再設定：第５実施形態＞
図５５は、第５実施形態のデータ処理装置１におけるリトライ圧縮の挿入処理に伴う伸長器Exの再設定処理（Ｓ5020）の詳細を説明する図である。

リトライ圧縮を行なった場合、図示のように、スタティック・スケジューリングで設定していた圧縮器Cmをより高圧縮のものに変更するので、それに応じて、伸長器Exの設定も変更することが必要になる。このため、リコンフィグ制御部２０は、「伸長のタイミングで伸長器Exの変更は可能か？」を判断する（Ｓ5022）のであるが、この際には、具体的には、パイプラインステージの追加をせずに、「リトライ圧縮したデータの変更する伸長器Exが現状の伸長器Exが設定されているパイプラインステージ内に入るか？」を判断する（Ｓ5032）。

入らなければ、リコンフィグ制御部２０は、再圧縮ストリームの伸長処理用として、伸長のために新たにステージを設けて再圧縮に合わせた伸長器Exを用意する（Ｓ5032-N，Ｓ5034）。この場合、伸長用に新たにステージが追加されるので、処理速度面において、性能低下が発生する。一方、パイプラインステージの追加をせずに、再圧縮ストリームの伸長処理用の伸長器Exが入る場合には、リコンフィグ制御部２０は、そのパイプラインステージ内で、再圧縮に合わせた伸長器Exに変更する（Ｓ5032-Y，Ｓ5036）。この場合、伸長用に新たにステージが追加されることはないので、処理速度面において、性能低下が発生することはない。

＜第６実施形態の比較例＞
図５６〜図５６Ｂは、第６実施形態のデータ処理装置１に対する比較例を説明する図である。ここで、図５６は、パイプラインステージのスケジューリングの側面から示した概略図であり、図５６Ａは、パイプラインステージのスケジューリングの側面から示した詳細図であり、図５６Ｂは、あるパイプラインステージにおけるメモリサイズの側面から示した図である。

第１実施形態においても述べたが、ＤＲＰ１０などの「内部処理構成をプログラマブル可能なデバイス」を使用する場合、ＤＲＰ１０におけるコストにおいて、ローカルメモリ３０の占める割合が大きくなる（たとえば全体の５０％以上となる）。そのため、本実施形態（第６実施形態に限らない）のデータ処理装置１においては、システムのメモリコストを低減するべく、プログラマブル・デバイス（ＦＰＧＡやＤＲＰ：本例ではＤＲＰ１０）の画像処理構成を制御するスケジューラとしてリコンフィグ制御部２０を導入して、性能の低下を抑制しながらメモリ使用量を削減する様々な仕組みを採っている（前述の第１〜第４実施形態のように）。

たとえば、図５６に示すように、複数のコンフィグレーションを切り替える比較例の画像処理システムでは、その入出力の各ストリームを全て保持しなくてはならない。さらに蓄積型ストリームの場合は、Stream１のようにコンフィグレーションを跨って、処理に必要なストリームを保持しておかなくてはならない。このため、たとえバンディング処理（バンド処理）を行なっても、ローカルメモリ３０のメモリ容量は小さくならない。各バンドのサイズを小さくし過ぎても逆にオーバーラップ（Overlap ）が大きくなり、メモリ容量は減らない。処理に破綻を来たさないようにするには、全ストリームが、ＲＡＷ（生データ）の状態で格納できるだけのメモリ空間を持たなければならない。あるいは、メモリ容量オーバーとなったらホスト部５側のメインメモリ７０へデータ転送すること（第１実施形態で説明した二次フォールバック処理と同様のデータ転送）が考えられる。

これらのことは、「内部処理構成をプログラマブル可能なデバイス」を複数使用するマルチチップ（Multi-Chip）構成とする場合でも同様である。全ストリームが、ＲＡＷデータの状態で格納できるだけのメモリ空間を「内部処理構成をプログラマブル可能なデバイス」は持つ。あるいは、メモリ容量オーバーとなったらホスト部５側のメインメモリ７０へデータ転送する。

図５６Ａは、マルチチップ構成を採用した比較例におけるパイプラインステージのスケジューリングを説明する図である。この比較例では、３個のＤＲＰ１０（Reconfig-1，Reconfig-2，Reconfig-3）と、ＤＲＰ１０ごとに設けられたＤＤＲ仕様のローカルメモリ３０を備えている。各ＤＲＰ１０は、リコンフィグ制御部２０（たとえばScheduler1，Scheduler2，Scheduler3）を有しており、第１〜第４実施形態の仕組みを適用して、自身が管理するローカルメモリ３０のメモリ容量をオーバーしないようにスケジューリングすることになる。この際には、第１実施形態で説明したように、圧縮・伸長を選択的に配置するために、スタティック・スケジューリングとダイナミック・スケジューリングを組み合わせる。基本的な検索順序は、スタティック・スケジューリングに基づくスタティックルールから決め、その後に、ダイナミック・スケジューリングに基づくダイナミックルールからデータサイズの対処を行なう。

図５６Ｂには、あるパイプラインステージにおけるメモリサイズの例が示されている。ここでは、各Funcが３個のＤＲＰ１０の何れに配置されるかは不問としている。各ファンクション（Func）に入出力されるストリームについては、そのデータ量がユニット単位で示されている。パイプラインステージの記述手法は、第１実施形態と同様であり、上側において左から右側に非蓄積型ストリームが入出力されるように示し、その下側に、蓄積型ストリームが入出力されるように示している。さらに、その下側には、蓄積型ストリームの分を除いた各ファンクションの入出力ストリームのみのストリームサイズ合計（つまり非蓄積型ストリームサイズ合計）と、蓄積型ストリームサイズを考慮したストリームサイズ合計（つまりストリーム使用量合計MSUM）を示している。

図示した例では、Func４とFunc５の部分が、最大メモリサイズ部（ストリーム使用量合計MSUMが最大の部分）となっている。この最大メモリサイズ部は、蓄積型ストリームサイズが大きく寄与するもので、ストリーム使用量合計MSUMにとっては、蓄積型ストリームサイズが問題となる。

＜＜第６実施形態＞＞
次に、データ処理装置１の第６実施形態について説明する。なお、第６実施形態においては、説明文では「伸長」と記す。図面中で、「伸長」を「伸張」と記すことがあるが、これらは同義である。

図５７および図５７Ａは、第６実施形態のデータ処理装置１の仕組みを説明する図である。ここで、図５７は、ストリーム使用量合計MSUMと各ローカルメモリ３０のメモリ容量の側面から第６実施形態の仕組みを示す図である。図５７Ａは、第６実施形態のデータ処理装置１のシステム構成の側面から第６実施形態の仕組みを示す図である。

図５６Ｂから理解されるように、あるファンクションにおけるストリーム使用量合計MSUMの削減にとっては、蓄積型ストリームサイズを低減することが肝要となる。第６実施形態の仕組みは、この点に着目したもので、マルチチップ構成を採る場合に、蓄積型ストリームの格納場所として、各ＤＲＰ１０が管理するローカルメモリ３０を共有する仕組みを採る。このため、各アクセラレータ部５のリコンフィグ制御部２０は、各ローカルメモリ３０の空きエリアを、相互に利用するように、協調して制御（スケジューリング）を行なう。各リコンフィグ制御部２０が協調して各「内部処理構成をプログラマブル可能なデバイス」のスケジューラ間を通信することで、ローカルメモリ３０を共有化するのである。具体的には、各ＤＲＰ１０のスケジューラ機能を持つリコンフィグ制御部２０が、自分が管理するローカルメモリ３０の容量サイズを超えるストリームになると、相互のリコンフィグ制御部２０（スケジューラ）をアクセスして、他のＤＲＰ１０が管理するローカルメモリ３０の空いている領域を使用（代用）する。

たとえば、図５７Ａにおいて、各ＤＲＰ１０のリコンフィグ制御部２０は、自身が管理するローカルメモリ３０の使用率を監視する。その情報は、たとえばストリーム管理テーブルTB60（使用率テーブル）に保存する。そして、たとえば、第１ＤＲＰ１０（Reconfig-1）にて、あるストリームの処理時にメモリ容量がオーバーする（あるいはオーバーしないがその危険性がある）ようになると、そのストリームを、空いている別の（たとえば、第２ＤＲＰ１０（Reconfig-2）のリコンフィグ制御部２０が管理するローカルメモリ３０ヘ格納する。図５７および図５７Ａでは、６ユニットのStream１３をＤＲＰ１０のローカルメモリ３０へ格納する例で示している。このＤＲＰ間のデータ転送時にストリームを圧縮するか否かは、リコンフィグ制御部２０（スケジューラ）が、圧縮器Cmを入れられるファンクションを見つけて行なう。見つからなければＲＡＷデータのままデータ転送を行なう。

このような仕組みとすることで、マルチチップ構成のデータ処理装置１において、各メモリ領域を最小限にし、ホスト部転送にすることがなく、転送のオーバーヘッド（Over Head ）を少なくすることで、メモリコストの低減と処理時間の高速化を図る。たとえば、マルチチップ構成時に、１つのＤＲＰ１０が管理するローカルメモリ３０のメモリ容量を最小限にする。

なお、自身が管理するローカルメモリ３０ではなく、他のメモリの空き領域を利用するという点では、メモリ容量オーバーとなったらホスト部５側のメインメモリ７０へデータ転送すること（第１実施形態で説明した二次フォールバック処理と同様のデータ転送）と似通っている。しかしながら、ホスト部５側へのデータ転送は、同種のＤＲＰ１０およびローカルメモリ３０との間のデータ転送に比べると低速になるので、転送速度の側面では、第６実施形態の仕組みの方が効果的である。

＜スケジューリング：第６実施形態＞
図５８は、第６実施形態におけるスケジューリングの方法を説明する図である。第６実施形態においても、各ＤＲＰ１０のリコンフィグ制御部２０が行なうスケジューリングの考え方は、基本的には、第１実施形態のリコンフィグ制御部２０が採っている手法と同じ手法を先ず適用する。その上で、第６実施形態に特有の仕組みを加える。

たとえば、リコンフィグ制御部２０は、スタティック・スケジューリングにより、パイプライン情報に基づいて圧縮対象ストリームピックアップと圧縮器Cmや伸長器Exの挿入を行なう（Ｓ5010）。さらに、画像処理システムにて画像処理を実際に実行する過程で、ダイナミック・スケジューリングにより、フォールバックを考慮した処理を行なう（Ｓ5020）。何れも、メモリサイズは制約条件として与えられる。この条件の中で、画像処理システムのパフォーマンス低下が最小限となるスケジューリングを行なう。

＜処理手順１：第６実施形態＞
図５９は、第６実施形態のデータ処理装置１に特有のローカルメモリ３０間のストリーム格納の処理手順を説明するフローチャートである。

ＤＲＰ１０ごとに、各リコンフィグ制御部２０は、メモリサイズオーバーの構成（Configuration ）となると、自身が管理するローカルメモリ３０のメモリ容量をオーバーしないように、圧縮・伸長対象のストリームを決定する（Ｓ6100）。次にリコンフィグ制御部２０は、該当のＤＲＰ１０（プロセッサ）内で圧縮器Cmや伸長器Ex（圧縮・伸長Config）の挿入箇所が検出できるか否かを判定する（Ｓ6110）。検出できれば、圧縮器Cmや伸長器Exの挿入を画像処理リコンフィグ部１２に指示し、画像処理リコンフィグ部１２にて圧縮器Cmや伸長器Exを挿入し、圧縮処理や伸長処理を実行する（Ｓ6110-Y，Ｓ6120）。一方、検出できなければ、他のＤＲＰ１０（近接プロセッサ）のリコンフィグ制御部２０にアクセス（kick）し（Ｓ6110-N，Ｓ6130）、その近接プロセッサのローカルメモリ３０の空き空間にメモリサイズオーバーとなるストリームを格納可能かを確認する（Ｓ6140）。このとき、どの近接プロセッサを選択するかの順番の決定（他プロセッサ選択）は、後述する所定の手順に従う（Ｓ6132）。

格納可能であれば、リコンフィグ制御部２０は、メモリサイズオーバーとなるストリームをその近接プロセッサに転送する（Ｓ6150）。データ転送を受けた側では、たとえば圧縮してローカルメモリ３０に格納する。このデータ転送＆メモリ格納の情報を管理するべく、双方のＤＲＰ１０のリコンフィグ制御部２０は（該プロセッサおよび近接プロセッサは）、各ストリーム管理テーブルTB60を更新（Update）する（Ｓ6152）。この後、他のＤＲＰ１０のローカルメモリ３０に格納しておいたストリームが必要になったときには（つまり伸長時には）、他方のＤＲＰ１０のローカルメモリ３０（近接プロセッサ側）から元のＤＲＰ１０側（該プロセッサ側）へデータ転送する（Ｓ6154）。

一方、他のＤＲＰ１０（近接プロセッサ）のローカルメモリ３０の空き空間にメモリサイズオーバーとなるストリームを格納できないときには、さらに別のＤＲＰ１０（たとえば２つ隣のプロセッサ）のローカルメモリ３０の空き空間にメモリサイズオーバーとなるストリームを格納可能かを確認する（Ｓ6160）。格納可能であれば、ステップＳ6150〜Ｓ6154と同様の処理を行なう（Ｓ6160-Y，Ｓ6170）。

さらに、他のＤＲＰ１０のローカルメモリ３０の空き空間にメモリサイズオーバーとなるストリームを格納できないときには、さらに別のＤＲＰ１０のローカルメモリ３０の空き空間にメモリサイズオーバーとなるストリームを格納可能かを確認することを繰り返す。そして、最終的に、メモリサイズオーバーとなるストリームを格納できる他のＤＲＰ１０側のローカルメモリ３０が見つからないないときには、当該ＤＲＰ１０において二次フォールバック処理を行なう（Ｓ6160-N，Ｓ6180）。

＜処理手順２：第６実施形態＞
図６０および図６０Ａは、第６実施形態のデータ処理装置１に特有の「他プロセッサ選択」（どの近接プロセッサを選択するか順番の決定：Ｓ6132）の処理手順を説明する図である。ここで、図６０は、他プロセッサ選択手順の一例を示すフローチャートである。図６０Ａは、「他プロセッサ選択」の処理で使用されるストリーム管理テーブルTB60（Stream Management Table ：使用率テーブルとも称する）の管理手法を説明する図である。

図６０に示すように、リコンフィグ制御部２０は先ず、スタティック・スケジューリングにおいて、各ローカルメモリ３０のストリーム管理テーブルTB60（使用率テーブル）を参照して最も使用率の低いＤＲＰ１０（プロセッサ）を選択する（Ｓ6134）。さらに、リコンフィグ制御部２０は、ダイナミック・スケジューリングにおいて、実際に処理する過程でスケジューリングする中で各ローカルメモリ３０のストリーム管理テーブルTB60（使用率テーブル）を参照して最も使用率の低いＤＲＰ１０を選択する（Ｓ6136）。

ここで、ストリーム管理テーブルTB60を管理するに当たっては、ＤＲＰ１０ごとに、リコンフィグ制御部２０にて、自身が管理するローカルメモリ３０の使用率の情報のみを管理する仕組みを採り、お互いに、他方のローカルメモリ３０の使用率の情報を交換し合う個別管理の仕組み（第１の使用率管理手法と称する）を採ってもよい。

あるいは、図６０Ａに示すように、複数のＤＲＰ１０の内の何れかの１つのＤＲＰ１０のリコンフィグ制御部２０（Scheduler1）をマスターとして、そのマスターのリコンフィグ制御部２０が、各ローカルメモリ３０の使用率（つまり空きエリア）の情報を集約して管理する集中管理（一元管理）の仕組み（第２の使用率管理手法と称する）を採ってもよい。

たとえば、図６０Ａでは、第１画像処理リコンフィグ部１２（Reconfig-1）および第１リコンフィグ制御部２０（Scheduler1）を有する第１ＤＲＰ１０をマスターとして、第２リコンフィグ制御部２０（Scheduler2）が管理する第２ローカルメモリ３０でオーバーフローを引き起こす場合に、メモリ空間に余裕のある第３リコンフィグ制御部２０（Scheduler3）が管理する第３ローカルメモリ３０にオーバーフローするストリームを退避させて格納する例を示している。

この場合、先ず、第２画像処理リコンフィグ部１２（Reconfig-2）の蓄積データ（第２ローカルメモリ３０に格納されているデータ）がオーバーフローを引き起こすようになると、第２リコンフィグ制御部２０（Scheduler2）はマスターである第１リコンフィグ制御部２０（Scheduler1）にその情報を通知する（Ｓ９６０）。この通知を受けたマスターである第１リコンフィグ制御部２０（Scheduler1）は、ストリーム管理テーブルTB60を参照し、何れのローカルメモリ３０のメモリ空間が空いているかを判断する（Ｓ９６２）。この例では、第３リコンフィグ制御部２０（Scheduler3）が管理する第３ローカルメモリ３０のメモリ空間に余裕があると判断する。

マスターである第１リコンフィグ制御部２０（Scheduler1）は、第２画像処理リコンフィグ部１２（Reconfig-2）から第３ＤＲＰ１０側の第３ローカルメモリ３０-2）からへのデータ転送指示を出す（Ｓ９６４）。この転送指示を受けた第２画像処理リコンフィグ部１２（Reconfig-2）は、オーバーフローを引き起こすストリームを第３ローカルメモリ３０に転送する（Ｓ９６６）。マスターである第１リコンフィグ制御部２０（Scheduler1）は、この情報（たとえばどこのプロセッサに転送したか）を残すべく、ストリーム管理テーブルTB60をアップデートする（Ｓ９６８）。

以上説明したように、第６実施形態の仕組みによれば、マルチチップ構成のデータ処理装置１とする場合に、あるＤＲＰ１０での画像処理リコンフィグ部１２のデータ処理において、自身が属するＤＲＰ１０のローカルメモリ３０のメモリサイズをストリーム使用量合計MSUMが超えるようになると、相互のリコンフィグ制御部２０（スケジューラ）をアクセスしてあるいはマスターのリコンフィグ制御部２０にアクセスして、空いているローカルメモリ３０を特定し、その空いているメモリ空間を使用するようにした。端的には、複数のＤＲＰ１０（画像処理リコンフィグ部１２）で、各ローカルメモリ３０を共有化するようにした。

これにより、マルチチップ構成のデータ処理装置１において、コンフィグレーションを跨って、処理に必要なストリームを保持しておく必要のある場合でも、メモリ容量が削減される。何れかのローカルメモリ３０でオーバーフローとなるケースでは、空き領域のある他のローカルメモリ３０を利用するので、メモリ領域を低減しても、ホスト部５側へのデータ転送を行なわずに対処し得るようになる。ホスト部５側にデータ転送することがなく、転送のオーバーヘッドが少なくなり、メモリコストの低減、処理時間のロス低減に寄与する。

＜ストリーム管理テーブル：第６実施形態＞
図６１は、ストリーム管理テーブルTB60の一例を示す図である。ストリーム管理テーブルTB60は、たとえば図６１に示すようなもので、マスター側のＤＲＰ１０が利用する第１ローカルメモリ３０に格納される。

図６１に示すように、第６実施形態のストリーム管理テーブルTB60は、パイプラインステージ（リコンフィグ）順に、コンフィグステイタス（Config Status）、ＲＡＷデータ換算での入力ストリームサイズ（Input Stream Size） 、ＲＡＷデータ換算での出力ストリームサイズ（Output Stream Size）、ＲＡＷデータ換算での蓄積ストリームサイズ、圧縮ステイタス（Status）、圧縮後のサイズ、転送先プロセッサ番号、ストリーム使用量合計MSUM（In/Out total Stream Size）などの情報が管理されるようになっている。コンフィグステイタスは、演算器（ＰＥ）ごとに、使用演算器数と残りの使用可能演算器数（PE_able ）があり、圧縮ステイタスは、圧縮なし（ＲＡＷ）には１、圧縮あり（Comp）には２を、出力ストリームごとに付して管理する。

本実施形態のデータ処理装置の基本構成例を示す図である。 本実施形態のデータ処理装置の仕様を説明する図である。 第１実施形態のデータ処理装置における基本動作例に対する比較例を説明する図であり、パイプラインステージのスケジューリングの側面から示した図である。 第１実施形態のデータ処理装置における基本動作例に対する比較例を説明する図であり、画像処理リコンフィグ部の内部回路の構成面から示した図である。 第１実施形態のデータ処理装置における基本動作であるスケジューリングの処理手順を説明するフローチャートである。 第１実施形態のデータ処理装置における基本動作例を説明する図であり、ストリームデータの種類とメモリ容量との関係を説明する図である。 圧縮・伸長をパイプライン処理に組み込む場合の定義モデルを説明する図（非蓄積型ストリームが主体の場合）である。 圧縮・伸長をパイプライン処理に組み込む場合の定義モデルを説明する図（蓄積型ストリームが主体の場合）である。 第１実施形態のデータ処理装置における第１例を説明する図である。 第１実施形態のデータ処理装置における第２例を説明する図である。 第１実施形態のデータ処理装置における第３例を説明する図である。 第１実施形態のデータ処理装置における、蓄積型ストリームのスタティック・スケジューリング処理の詳細を説明するフローチャートである。 第１実施形態のデータ処理装置における、蓄積型ストリームのダイナミック・スケジューリング処理の詳細を説明するフローチャートである。 第１実施形態のデータ処理装置における、非蓄積型ストリームのスタティック・スケジューリング処理の詳細を説明するフローチャートである。 第１実施形態のデータ処理装置における、非蓄積型ストリームのダイナミック・スケジューリング処理の詳細を説明するフローチャートである。 第１実施形態の仕組みと比較例との差を説明する図である。 第２実施形態のデータ処理装置の仕組みを説明する図である。 第２実施形態の第１例を説明する図である。 第２実施形態の第２例を説明する図である。 第２実施形態の第３例を説明する図である。 第２実施形態の第４例を説明する図である。 第２実施形態の第５例を説明する図である。 第２実施形態の第６例を説明する図である。 第２実施形態の第７例を説明する図である。 第２実施形態のデータ処理装置における基本動作例の処理手順（メインフロー）を説明するフローチャートである。 伸長処理実行スケジューリング（Ｓ2180）の詳細を説明するフローチャートである。 圧縮処理実行スケジューリング（Ｓ2190）の詳細を説明するフローチャートである。 第２実施形態で適用されるリコンフィグパイプライン管理テーブルの一例を示す図であり、最初の状態を示す。 第２実施形態で適用されるリコンフィグパイプライン管理テーブルの一例を示す図であり、更新後の状態を示す。 第２実施形態のデータ処理装置に対する第１比較例を説明する図である。 第２実施形態のデータ処理装置に対する第２比較例を説明する図である。 第２実施形態のデータ処理装置に対する第３比較例を説明する図である。 第２実施形態のデータ処理装置に対する第４比較例を説明する図である。 第２実施形態のデータ処理装置に対する第５比較例を説明する図である。 第２実施形態の仕組みと比較例との差を説明する図である。 第３実施形態のデータ処理装置に対する比較例を説明する図である。 第３実施形態のデータ処理装置の仕組みを説明する図である。 モジュール分割と処理手順やストリーム使用量合計などとの関係を説明する図である。 第３実施形態の仕組みのモデルケース（蓄積ストリーム対応のケース）を示す図であり、ハードウェアによる対処部分とソフトウェア処理による対処部分の関係の基本を説明する図である。 図３１についてのタイムスケジュールを示す図である。 図３１の状態において、具体的な数値例（図２８の事例）を適用して、スケジュールの更新後を示した図である。 第３実施形態の仕組みのモデルケース（非蓄積ストリーム対応のケース）を示す図である。 第３実施形態の画像処理リコンフィグ部に対して適用されるフロアプランレイアウトの一例を示す図である。 第３実施形態のデータ処理装置におけるリコンフィグ制御部によるスケジューリング機能の処理手順（メインフロー）を説明するフローチャートである。 リコンフィグパイプライン管理テーブルの一例を示す図であり、最初の状態（オリジナル）を示す。 リコンフィグパイプライン管理テーブルの一例を示す図であり、更新後の状態を示す。 ハードウェア処理とソフトウェア処理の振り分けの手順を説明する図である。 ハードウェア処理とソフトウェア処理の振り分けの手順の詳細を説明するフローチャートである。 第３実施形態の仕組みにおいて適用されるリコンフィグパイプライン管理テーブルと圧縮器管理テーブルとの関係の具体例を示す図である。 第３実施形態の仕組みにおいて適用されるリコンフィグパイプライン管理テーブルと伸長器管理テーブルとの関係の具体例を示す図である。 第３実施形態の仕組みにおいて適用されるリコンフィグパイプライン管理テーブル（図３８，図３８Ａ）を１つに纏めて示した図である。 第３実施形態の仕組みにおいて適用される更新後のリコンフィグパイプライン管理テーブルを示す図である。 第３実施形態の仕組みにおいて適用される更新後のソフトウェアプロセス管理テーブルを示す図である。 第３実施形態の仕組みにおいて適用される圧縮器管理テーブルの具体例を説明する図である。 図２８〜図３９に示した事例を纏めて、第３実施形態の仕組みの特徴を事例に則して示した図である。 第３実施形態のデータ処理装置に対する第１比較例を説明する図である。 第３実施形態のデータ処理装置に対する第２比較例を説明する図である。 第３実施形態のデータ処理装置に対する第３比較例を説明する図である。 第４実施形態のデータ処理装置の仕組みを説明する図（基本図）である。 第４実施形態のデータ処理装置の仕組みを説明する図（具体的な説明図）である。 第４実施形態のデータ処理装置における複数の圧縮器や伸長器を選択して画像処理リコンフィグ部に挿入する基本動作例の処理手順（メインフロー）を説明するフローチャートである。 第４実施形態のデータ処理装置における複数の圧縮器や伸長器を選択して画像処理リコンフィグ部に挿入する基本動作例の処理手順（メインフロー）を説明するフローチャートである（続き）。 圧縮閾値と各ストリームの情報を取得する処理（Ｓ4010）の詳細を説明する図である。 パイプラインステージごとのストリームから、圧縮すべきストリームや伸長すべきストリームをピックアップする処理（Ｓ4012）の詳細を説明する図である。 画像処理リコンフィグ部の空き回路規模から、圧縮タイミングや伸長タイミングで、ともに挿入が可能な圧縮器や伸長器を選択する処理（Ｓ4022）の詳細を説明する図である。 非圧縮ストリーム（圧縮されていないストリーム）に対する圧縮処理のスケジューリング（Ｓ4052）の詳細を説明する図である。 圧縮ストリームに対する高圧縮化のスケジューリング（Ｓ4062）の詳細を説明する図である。 第４実施形態の仕組みと比較例との差を説明する図である。 第５実施形態のデータ処理装置の仕組みを説明する図である。 第５実施形態のデータ処理装置におけるリトライ圧縮の基本的な処理手順（メインフロー）を説明するフローチャートである。 第５実施形態のデータ処理装置におけるリトライ圧縮適用の判断基準（スレッシュ）を説明する図である。 第５実施形態のデータ処理装置における圧縮データサイズとメモリ使用率の取得処理を説明する図である。 第５実施形態のデータ処理装置におけるリトライ圧縮の挿入処理を説明する図である。 第５実施形態のデータ処理装置におけるリトライ圧縮の挿入処理に伴う伸長器の再設定処理（Ｓ5020）の詳細を説明する図である。 第６実施形態のデータ処理装置に対する比較例を説明する図であり、パイプラインステージのスケジューリングの側面から示した概略図である。 第６実施形態のデータ処理装置に対する比較例を説明する図であり、パイプラインステージのスケジューリングの側面から示した詳細図である。 第６実施形態のデータ処理装置に対する比較例を説明する図であり、あるパイプラインステージにおけるメモリサイズの側面から示した図である。 第６実施形態のデータ処理装置の仕組みを説明する図であり、ストリーム使用量合計と各ローカルメモリのメモリ容量の側面から示す図である。 第６実施形態のデータ処理装置の仕組みを説明する図であり、システム構成の側面から示す図である。 第６実施形態におけるスケジューリングの方法を説明する図である。 第６実施形態のデータ処理装置に特有のローカルメモリ間のストリーム格納の処理手順を説明するフローチャートである。 第６実施形態のデータ処理装置に特有の「他プロセッサ選択」の処理手順の一例を示すフローチャートである図である。 第６実施形態のデータ処理装置に特有の「他プロセッサ選択」の処理で使用されるストリーム管理テーブルの管理手法を説明する図である。 ストリーム管理テーブルの一例を示す図である。

符号の説明

１…データ処理装置、１０…ＤＲＰ（内部処理構成をプログラマブル可能なデバイスの一例）、１２…画像処理リコンフィグ部（再構成可能なデータ処理部の一例）、１４…内部バス、１６…メモリＩＦ部、１８…外部バスＩＦ部、２０…リコンフィグ制御部、２０２…割込み検知部、２０４…スケジューラ部、２０６…コマンド発行部、２０８…レイアウトロード部、２４０…リコンフィグ順判断部、２４２…ソフトウェアバジェット判断部、２４４…レイアウト判断部、２４６…ソフトウェアプロセスセット部、２４８…レイアウト選択部、３…アクセラレータ部、３０…ローカルメモリ、５…ホスト部、５０…コントローラメインＣＰＵ、７０…メインメモリ、９０…外部バス

Claims (24)

1. 装置全体の動作を制御する中央制御部および前記中央制御部の管理の下でデータを記憶する主記憶部を具備したホスト部と、
   データを処理する機能部であってデータ処理のステージごとに回路構成を動的に再構成可能なデータ処理部、前記データ処理部の回路構成を動的に制御する再構成制御部、および、前記データ処理部が取り扱うデータを記憶する副記憶部を具備したアクセラレータ部と、
   を備え、
   前記再構成制御部は、
   再構成されたステージごとに、当該ステージで使用されるデータである非蓄積型のストリームや当該ステージにおいては使用されないが後のステージ用に前記副記憶部に保持すべきデータである蓄積型のストリームと、前記副記憶部の使用可能な容量に基づいて、前記副記憶部が所定の基準値よりも容量オーバーとならないように、圧縮すべきストリームを特定し、
   この特定したストリームに関して、圧縮処理や当該圧縮処理に対応する伸長処理の適用の有無を制御する
   ことを特徴とするデータ処理装置。
2. 前記再構成制御部は、
   前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、
   この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、当該ステージの前記データ処理部に挿入可能か否かを判定し、
   挿入不可能であって、かつ、前記特定したストリームが前記非蓄積型のストリームであれば、当該非蓄積型のストリームに関して、圧縮せずに分割転送を行なうように前記データ処理部を制御する
   ことを特徴とする請求項１に記載のデータ処理装置。
3. 前記再構成制御部は、
   前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、
   この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、前記データ処理部に挿入可能か否かを判定し、
   挿入可能であれば、前記圧縮処理や前記伸長処理を実行する機能部を前記データ処理部に挿入するように制御する
   ことを特徴とする請求項１に記載のデータ処理装置。
4. 前記再構成制御部は、
   前記圧縮処理がなされた前記非蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、
   容量オーバーとなると判断したときには、前記非蓄積型のストリームを前記ホスト部側へ転送するように制御する
   ことを特徴とする請求項３に記載のデータ処理装置。
5. 前記再構成制御部は、
   前記データ処理部がデータ処理を実行する前に、前記圧縮すべきストリームを特定し、
   この特定したストリームに関して、前記圧縮処理や前記伸長処理を実行する機能部を、当該ステージの前記データ処理部に挿入可能か否かを判定し、
   挿入不可能であって、かつ、前記特定したストリームが前記蓄積型のストリームであれば、当該蓄積型のストリームに関して、圧縮処理や伸長処理を実行する機能部用のステージを新たに追加する
   ことを特徴とする請求項３に記載のデータ処理装置。
6. 前記再構成制御部は、
   前記圧縮処理がなされた前記蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、
   容量オーバーとなると判断したときには、前記蓄積型のストリームに対して、より良好な圧縮率で再圧縮するように制御する
   ことを特徴とする請求項３に記載のデータ処理装置。
7. 前記再構成制御部は、前記再圧縮がなされた前記蓄積型のストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部が所定の基準値よりも容量オーバーとなるか否かを監視し、
   容量オーバーとなると判断したときには、前記蓄積型のストリームを前記ホスト部側へ転送するように制御する
   ことを特徴とする請求項６に記載のデータ処理装置。
8. 前記再構成制御部は、
   前記副記憶部が所定の基準値よりも容量オーバーとなるときには、前記圧縮処理や前記伸長処理とデータ処理の組合せで、前記容量オーバーとならないように、時分割で処理を実行するように制御する
   ことを特徴とする請求項１に記載のデータ処理装置。
9. 前記再構成制御部は、
   複数の出力ストリームを圧縮する必要がある場合において、前記圧縮処理を実行する機能部を、当該ステージの前記データ処理部に挿入できない場合は、前記データ処理とその後の前記圧縮処理の組合せで、前記時分割で処理を実行するように制御する
   ことを特徴とする請求項８に記載のデータ処理装置。
10. 前記再構成制御部は、
    圧縮済みの入力ストリームを伸長する必要がある場合において、当該入力ストリームを一括して前記伸長処理を実行すると前記副記憶部が所定の基準値よりも容量オーバーとなる場合は、前記伸長処理とその後の前記データ処理の組合せで、前記時分割で処理を実行するように制御する
    ことを特徴とする請求項８に記載のデータ処理装置。
11. 前記再構成制御部は、
    前記圧縮処理や前記伸長処理をモジュール分割し、
    前記データ処理部の空きエリアとの関係で許容される範囲で、前記モジュール分割した前記圧縮処理や前記伸長処理を選択して、当該処理を実行する機能部を前記データ処理部に挿入してハードウェア処理で対処するように制御するとともに、
    前記データ処理部に挿入できなかったモジュールについては、前記圧縮処理や前記伸長処理をソフトウェア処理で対処するように制御する
    ことを特徴とする請求項１に記載のデータ処理装置。
12. 前記再構成制御部は、前記ハードウェア処理での対処が可能な範囲で、前記モジュール分割した前記圧縮処理や前記伸長処理の内、前記ソフトウェア処理が重たいものから前記ハードウェア処理を適用するように制御する
    ことを特徴とする請求項１１に記載のデータ処理装置。
13. 前記再構成制御部は、
    前記蓄積型のストリームに対して前記圧縮処理や前記伸長処理を適用する場合には、同一の前記蓄積型のストリームについて、モジュール分割による前記ハードウェア処理と前記ソフトウェア処理を別のステージで実行するように制御する
    ことを特徴とする請求項１１に記載のデータ処理装置。
14. 前記再構成制御部は、
    前記非蓄積型のストリームに対して前記圧縮処理や前記伸長処理を適用する場合には、同一の前記蓄積型のストリームについて、モジュール分割による前記ソフトウェア処理を実行中には、モジュール分割による前記ハードウェア処理を待機させる
    ことを特徴とする請求項１１に記載のデータ処理装置。
15. 前記再構成制御部は、
    圧縮処理や伸長処理が適用されるストリームが複数ある場合、ストリーム量、前記データ処理部の空きエリア、圧縮処理や伸長処理のタイミング、および、圧縮処理や伸長処理の性能に基づき、圧縮処理や伸長処理を適用するストリームを選択して、圧縮処理や伸長処理を実行する機能部を、同一ステージ中の前記データ処理部に挿入するように制御する
    ことを特徴とする請求項１に記載のデータ処理装置。
16. 前記再構成制御部は、回路規模や処理性能の異なる複数の前記機能部を前記データ処理部に挿入するように制御する
    ことを特徴とする請求項１５に記載のデータ処理装置。
17. 前記再構成制御部は、選択したストリームに関して複数の前記機能部を前記データ処理部に挿入可能な場合、その中で圧縮性能の最も劣る機能部を前記データ処理部に挿入するように制御する
    ことを特徴とする請求項１５に記載のデータ処理装置。
18. 前記再構成制御部は、圧縮処理を適用済みのストリームに関して、前記データ処理部に挿入可能な範囲で、前記圧縮処理を実行する機能部をより圧縮性能の高いものに変更するように制御する
    ことを特徴とする請求項１５に記載のデータ処理装置。
19. 前記再構成制御部は、
    前記圧縮処理がなされた前記ストリームを取り込んで前記データ処理部がデータ処理を実行する過程で、前記副記憶部の使用率を監視し、
    前記使用率が一定以上になった場合には、前記ストリームに対してより良好な圧縮率で圧縮処理を実行するステージを新たに設けるように制御する
    ことを特徴とする請求項１に記載のデータ処理装置。
20. 前記再構成制御部は、
    前記より良好な圧縮率での圧縮処理を実行するステージを新たに設けたことに合わせて、対応する伸長処理を実行する機能部を設定するように制御する
    ことを特徴とする請求項１９に記載のデータ処理装置。
21. 前記再構成制御部は、前記より良好な圧縮率での圧縮処理が適用されるストリームについて現在設定されている伸長処理を実行する機能部が挿入されている前記データ処理部に挿入可能な範囲で、現在設定されている伸長処理を実行する機能部を、前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部に変更するように制御する
    ことを特徴とする請求項２０に記載のデータ処理装置。
22. 前記再構成制御部は、前記より良好な圧縮率での圧縮処理が適用されるストリームについて現在設定されている伸長処理を実行する機能部が挿入されている前記データ処理部について、現在設定されている伸長処理を実行する機能部を前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部に変更できない場合は、前記より良好な圧縮率での圧縮処理に対応する伸長処理を実行する機能部用のステージを新たに設けるように制御する
    ことを特徴とする請求項２０に記載のデータ処理装置。
23. 前記アクセラレータ部を複数備え、
    各アクセラレータ部の前記再構成制御部は、各副記憶部の空きエリアを、相互に利用するように、協調して前記制御を行なう
    ことを特徴とする請求項１に記載のデータ処理装置。
24. 各アクセラレータ部の前記再構成制御部の内の何れか１つをマスターとし、そのマスターの再構成制御部が、各副記憶部の空きエリアの情報を集約して管理する
    ことを特徴とする請求項２３に記載のデータ処理装置。

Images