バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してリードアクセスまたはライトアクセスの種類のバスアクセスを要求する複数のモジュールと、前記複数のモジュールの複数のバスアクセスの要求について、直前に調停して受け付けたバスアクセスの種類と同じ種類のバスアクセスを優先して調停するアービタとを有することを特徴とする制御装置。バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してバスアクセスを要求する複数のモジュールと、前記複数のモジュールの複数のバスアクセスの要求について、直前に調停して受け付けたバスアクセスの要求を発行したモジュールのバスアクセスを優先して調停するアービタとを有することを特徴とする制御装置。さらに、前記複数のモジュールごとに、前記バスに対する連続アクセスの回数をカウントする計数手段を有し、前記アービタは、前記連続アクセスの回数が所定回数に達したモジュールの前記バスアクセスの要求をマスクすることを特徴とする請求項1または請求項2に記載の制御装置。さらに、前記複数のモジュールのバスアクセスの要求をスタックするリクエストキューを有し、前記アービタは、前記リクエストキューにスタックした、前記複数のモジュールごとのバスアクセスの要求の数に応じて、前記複数のモジュールのバスアクセスを調停することを特徴とする請求項1から請求項3の何れか一項に記載の制御装置。前記アービタは、直前に調停して受け付けたバスアクセスとの連続性、前記リクエストキューにスタックした、前記複数のモジュールごとのバスアクセスの要求の数、の順に考慮して前記優先を制御することを特徴とする請求項4に記載の制御装置。前記アービタは、さらに、前記バスアクセスの要求の発生頻度が低いモジュールのバスアクセスを優先して前記調停を行うことを特徴とする請求項5に記載の制御装置。前記アービタは、さらに、レイテンシの短いモジュールのバスアクセスを優先して前記調停を行うことを特徴とする請求項5に記載の制御装置。バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してリードアクセスまたはライトアクセスの種類のバスアクセスを要求する複数のマスタ、および、前記複数のマスタのバスアクセスを調停する第一のアービタを有する複数のモジュールと、前記複数のモジュールのバスアクセスを調停する第二のアービタとを有することを特徴とする制御装置。前記第一のアービタは、直前に調停して受け付けたバスアクセスと同じ種類のバスアクセスを優先して前記調停を行うことを特徴とする請求項8に記載の制御装置。さらに、前記リードアクセスまたはライトアクセスの要求を種類ごとにスタックするキューを有し、前記第一のアービタは、前記バスアクセスの種類ごとに設定された数分、前記キューにバスアクセスの要求が蓄積された種類のバスアクセスを優先して前記調停を行うことを特徴とする請求項8に記載の制御装置。さらに、前記リードアクセスまたはライトアクセスの要求を種類ごとにスタックするキューを有し、前記第一のアービタは、直前に調停して受け付けたバスアクセスと同じ種類のバスアクセスを優先し、次に、前記バスアクセスの種類ごとに設定された数分、前記キューにバスアクセスの要求が蓄積された種類のバスアクセスを優先して前記調停を行うことを特徴とする請求項8に記載の制御装置。前記第一のアービタは、さらに、前記バスアクセスの要求の発生頻度が低いマスタのバスアクセスを優先して前記調停を行うことを特徴とする請求項11に記載の制御装置。前記第二のアービタは、同一のモジュールのバスアクセスが連続するように前記調停を行うことを特徴とする請求項8に記載の制御装置。前記第二のアービタは、同一のモジュールによる所定回数以上の連続したバスアクセスを制限することを特徴とする請求項13に記載の制御装置。さらに、前記複数のモジュールごとのバスアクセスの要求をスタックするキューを有し、前記第二のアービタは、前記キューにスタックされたバスアクセスの要求の数が多いモジュールのバスアクセスを優先して前記調停を行うことを特徴とする請求項8に記載の制御装置。さらに、前記複数のモジュールごとのバスアクセスの要求をスタックするキューを有し、前記第二のアービタは、同一のモジュールのバスアクセスが連続するように前記調停を行い、次に、前記複数のモジュールに関する所定の優先順位に基づいて前記調停を行い、さらに、前記キューにスタックされたバスアクセスの要求の数が多いモジュールを優先するように前記調停を行うことを特徴とする請求項8に記載の制御装置。本発明は、バス使用権を動的に管理して、バスの使用効率を向上することを目的とする。また、バス使用権の調停を分散処理して、バスマスタ数の増加に伴う回路規模の増大を防ぎ、バスの高速性を維持することを他の目的とする。本発明は、前記の目的を達成する一手段として、以下の構成を備える。本発明にかかる制御装置は、バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してリードアクセスまたはライトアクセスの種類のバスアクセスを要求する複数のモジュールと、前記複数のモジュールの複数のバスアクセスの要求について、直前に調停して受け付けたバスアクセスの種類と同じ種類のバスアクセスを優先して調停するアービタとを有することを特徴とする。また、バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してバスアクセスを要求する複数のモジュールと、前記複数のモジュールの複数のバスアクセスの要求について、直前に調停して受け付けたバスアクセスの要求を発行したモジュールのバスアクセスを優先して調停するアービタとを有することを特徴とする。また、バスアクセスを調停する制御装置であって、バスに接続されたメモリに対してリードアクセスまたはライトアクセスの種類のバスアクセスを要求する複数のマスタ、および、前記複数のマスタのバスアクセスを調停する第一のアービタを有する複数のモジュールと、前記複数のモジュールのバスアクセスを調停する第二のアービタとを有することを特徴とする。本発明によれば、バス使用権を動的に管理することで、バスの使用効率を向上することができる。また、バス使用権の調停を分散処理することで、バスマスタ数の増加に伴う回路規模の増大を防ぎ、バスの高速性を維持することができる。以下、本発明にかかる実施例を図面を参照して詳細に説明する。勿論、以下の実施例は、本発明の技術分野における当業者による実施を容易にするための開示を提供するものであり、特許請求の範囲によって確定される本発明の技術的範囲に含まれるほんの一部の実施例に過ぎない。従って、本明細書に直接的に記載されていない実施例であっても、技術思想が共通する限り、本発明の技術的範囲に包含されることは、当業者にとって自明である。また、便宜上、複数の実施例を記載するが、これらは個別に発明として成り立つだけではなく、勿論、複数の実施例を適宜組み合わせることでも発明が成り立つことは、当業者であれば容易に理解できる。[装置の構成]まず、各種画像処理を行った後、画像を出力する画像処理装置を例に説明する。図1は実施例1の画像処理装置の構成例を示すブロック図である。図1において、CPU1は、ROM2に格納されたプログラムに従い、DRAM7をワークメモリとして、画像処理装置全体を制御する。また、CPU1は、CPUバス1aを介してROM2、バスブリッジ3およびIOポート9に接続する。アービタ5は、バスブリッジ3を介したCPU1によるDRAM7のアクセス、および、nn≧1、整数個の画像処理モジュール4によるDRAM7のアクセスを調停する。また、DRAM7は、DRAMインタフェイス6を有する。また、画像処理モジュール1の一つ図1ではモジュール4nは、例えばインクジェットプリンタのプリントヘッドに接続するためのヘッドIF8が備わる。なお、図1には、DRAM7がCPU1および複数の画像処理モジュール4に共有される例を示したが、パフォーマンスの維持または向上のために、CPU1用のRAMをCPUバス1aに接続する構成としてもよい。[処理動作]CPU1は、ROM2に格納されたプログラムに従い、IOポート9より処理すべき画像データを受け取り、バスブリッジ3、アービタ5、DRAMIF6を経てDRAM7へ格納する。次に、CPU1は画像処理モジュール4aのコンフィグレーションレジスタを設定し、画像処理モジュール4aを動作させる。画像処理モジュール4aは、所定の処理を実行し、コンフィグレーションレジスタに設定された処理すべきデータの読出処理が終了するか、あるいは、コンフィグレーションレジスタに設定された処理データの書込処理が終了すると、割り込みを発生して、処理の終了をCPU1へ通知する。CPU1は、割り込みを受けると、その要因を解析し、画像処理モジュール4aの読出処理が終了した場合は、次に処理すべきデータの設定を行い、画像処理モジュール4aに処理を続行させる。また、画像処理モジュール4aの書込処理が終了した場合は、次の処理データの格納先を設定し、画像処理モジュール4aに処理を続行させるとともに、次の画像処理モジュール4bのコンフィグレーションレジスタを設定して、画像処理モジュール4bを動作させる。画像処理モジュール4bは、所定の処理を実行し、コンフィグレーションレジスタに設定された処理すべきデータの読出処理が終了するか、あるいは、コンフィグレーションレジスタに設定された処理データの書込処理が終了すると、割り込みを発生して、処理の終了をCPU1へ通知する。CPU1は、割り込みを受けると、その要因を解析し、画像処理モジュール4bの読出処理が終了した場合は、次に処理すべきデータの設定を行い、画像処理モジュール4bに処理を続行させる。また、画像処理モジュール4bの書込処理が終了した場合は、次の処理データの格納先を設定し、画像処理モジュール4bに処理を続行させるとともに、次の画像処理モジュール4cのコンフィグレーションレジスタを設定して、画像処理モジュール4cを動作させる。このように、前の処理が終わった直後に、次の画像処理モジュールを起動し、処理データを次々と画像処理モジュールに受け渡すことで、画像処理モジュール単位のパイプラインを構成することができる。そして、画像処理モジュール4mまでの処理が進み、所定量以上のビットマップデータを生成すると、CPU1は図示しないプリンタエンジンを起動し、プリンタエンジンの同期信号に合わせて画像処理モジュール4nに処理を開始させ、ヘッドIF8を介してビットマップデータをプリンタエンジンに送り、プリントさせる。●画像処理モジュールの構成図2は画像処理モジュールの詳細な構成例を説明するブロック図で、リードバッファ10、mm≧1、整数個のサブモジュール11、ライトバッファ12、アービタ13、リードアドレス発生器14、割込コントローラ15、ライトアドレス発生器16を備える。CPU1は、画像処理モジュール4のコンフィグレーションレジスタの設定により、リードアドレス発生器14にリードの開始および終了アドレスを設定し、リードイネーブル信号Renをセットする。また、ライトアドレス発生器16にライトの開始および終了アドレスを設定し、ライトイネーブル信号Wenをセットする。アービタ13はリードバッファ10の空き容量Rpおよびリードアドレス発生器14のイネーブル信号Renを検出し、リードアドレスが有効Ren‘1’で、リードバッファ10にデータが格納可能Rp≧Rnであれば、アービタ5へリードリクエストPREQ‘1’、PNRW‘0’、PNUMRn、PADDRadを発行する。一方、ライトバッファ12のデータ蓄積数Wpが所定のワード数以上Wp≧Wnになると、アービタ13は、ライトアドレス発生器16のイネーブル信号Wenを検出し、ライトアドレスが有効Wen‘1’であれば、アービタ5へライトリクエストPREQ‘1’、PNRW‘1’、PNUMWn、PADDWadを発行する。アービタ5は、画像処理モジュール4からリクエスト信号PREQを受け取ると、PNRWでリードライトを判別し、PNUMでワード数を、PADDでアドレスを検知する。CPU1および他の画像処理モジュール4からのリクエストがなければ、アービタ5は、DRAMIF6を通じてDRAM7の該当データのアクセスを開始する。DRAMIF6にリクエストが受け付けられると、アービタ5は、受領信号PACKを要求元の画像処理モジュール4に返す。一方、CPU1および他の画像処理モジュール4からリクエストがある場合は、優先順位に従って、リクエストを受け付ける。アービタ13は、受領信号PACKを受け取ると、リードリクエストの場合は受領信号Rackを要求元のリードアドレス発生器14に返し、ライトリクエストの場合は受領信号Wackを要求元のライトアドレス発生器16に返す。受領信号Rackを受け取ったリードアドレス発生器14は、次のアドレスを生成するが、リクエストしたアドレスがリード終了アドレスの場合は、リードイネーブル信号Renをリセットし、リード終了信号Rendを割込コントローラ15に出力する。また、受領信号Wackを受け取ったライトアドレス発生器16は、次のアドレスを生成すが、リクエストしたアドレスがライト終了アドレスの場合は、ライトイネーブル信号Wenをリセットし、ライト終了信号Wendを割込コントローラ15に出力する。割込コントローラ15は、コンフィグレーションレジスタによってリード終了割込マスクおよびライト終了割込マスクの設定が可能で、各割込マスクの設定が割込イネーブルとなっている場合は、リード終了信号Rendまたはライト終了信号Wendによって割込信号INTを生成してCPU1へ通知する。CPU1は、割り込みを受付けると、割込コントローラ15のステータスを読み取り、割り込みの要因がリード終了の場合は、リード終了割込マスクをリセットして割り込みを解除する。さらに処理を続行する場合は、リード開始および終了アドレスを再設定し、リードイネーブル信号Renのセットなどを行った後、リード終了割込マスクをセットする。同様に、割り込み要因がライト終了の場合は、ライト終了割込マスクをリセットして割り込みを解除する。さらに処理を続行する場合は、ライト開始および終了アドレスを再設定し、ライトイネーブル信号Wenのセットなどを行った後、ライト終了割込マスクをセットする。次に、DRAM7よりデータが読み出されるとアービタ5は、DRAMデータ有効信号PVALIDを要求元の画像処理モジュール4に返す。要求元の画像処理モジュール4のアービタ13は、リードバッファ10へデータ有効信号Rvalidを返す。リードバッファ10は、データ有効信号Rvalidがセットされている期間、DRAMデータ出力信号PDIN上のデータを格納する。この操作により、DRAM7のデータがリードバッファ10へ格納される。一方、DRAM7にデータを書込む場合は、DRAM7の書込タイミングに合わせて、アービタ5は、DRAMデータ有効信号PVALIDを要求元の画像処理モジュール4に返す。要求元の画像処理モジュール4のアービタ13は、ライトバッファ12へデータ有効信号Wvalidを返す。ライトバッファ12は、データ有効信号Wvalidがセットされている期間、DRAMデータ入力信号PDOUTとしてDRAM7に書き込むデータを出力する。この操作により、ライトバッファ12のデータがDRAM7へ格納される。リードバッファ10は、サブモジュール11aの処理に必要なデータが揃うと有効信号valid0をセットし、サブモジュール11aの処理に必要なデータが揃っていなければ有効信号valid0をリセットする。そして、サブモジュール11aからの保持要求信号stall0がセットされていない場合、リードバッファ10は、格納したデータをクロックに同期して出力する。もし、保持要求信号stall0がセットされている場合は、データを更新しない。サブモジュール11aは、有効信号valid0がセットされているデータのみを受け取る。なお、データの受け取りが不可能な場合は、保持要求信号stall0をセットし、リードバッファ10の出力をホールドする。なお、入力データの並べ替えが不要な場合、リードバッファ10はFIFOメモリでよい。同様に、出力データの並べ替えが不要な場合、ライトバッファ12はFIFOメモリでよい。画像処理モジュール4の内部は、画像処理を行う一つ以上のサブモジュール11によって構成され、各サブモジュール間では、上記と同様の動作有効信号validxと保持要求信号stallxによるハンドシェークによってデータdataxの受け渡しを行う。●サブモジュール間のデータ転送図3はサブモジュール11間のデータ転送を説明するタイミングチャートである。データ送信側のサブモジュール11は、データが出力可能であればクロックclkの立ち上がりに同期してデータ信号d1および有効信号validをセットする。次のクロックの立ち上がりで受信側から保持要求信号stallがセットされていなければデータ信号d1が受信されたとみなし、次のデータが出力可能であればデータ信号d2および有効信号validをセットする。もし、次のデータが出力不能であれば有効信号validをリセットする。また、次のクロックの立ち上がりで受信側から保持要求信号stallがセットされていた場合は、データ信号が受信されなかったとみなし、データ信号d5および有効信号validをホールドする。なお、受信側から保持要求信号stallがセットされていても有効信号validをセットしていなければ、無効データであるからデータ信号および有効信号validをホールドせずに、次の有効データとしてデータ信号d6を出力し、有効信号validをセットする。言い換えれば、有効信号validをセットしていない場合の保持要求信号stallは無視する。データ受信側のサブモジュール11は、受信可能であれば有効信号validがセットされているデータ信号をクロックclkの立ち上がりに同期して受け取る。また、受信不能であれば保持要求信号stallをセットし、送信側にデータ信号d5および有効信号validを保持させる。そして、受信可能になると保持要求信号stallをリセットし、データ出力d5を受信する。また、ライトバッファ12は、バッファに空きがあれば、サブモジュール11からの有効信号validnがセットされたときのデータ信号datanをバッファに格納する。もし、バッファに空きがなければ、保持要求信号stallnをセットし、サブモジュール11に出力をホールドさせる。●アービタ13のアルゴリズム図4はアービタ13のアルゴリズムを説明するフローチャートである。なお、以下の説明においては、リクエストキューに蓄積されたリクエストの数をPp、リクエストキューに蓄積されたリクエストが実行された場合のライトバッファ12のデータ蓄積数評価値をPw、リクエストキューに蓄積されたリクエストが実行された場合のリードバッファ10の空き容量評価値をPrとする。なお、リクエストキューに蓄積されたリクエストの数Ppはアービタ5がリクエストを受け付けるPACK‘1’と一つ減じられる。また、以下の説明では、リードリクエストの頻度>ライトリクエストの頻度と仮定し、バスアクセスのリクエスト発生頻度が低いモジュールの順に、後述するバッファの空き状態の検出を行う。ライトリクエストWreqは、ライトバッファ12の蓄積数の評価値Pwが所定のワード数以上Pw≧Wnになり、ライトアドレスが有効Wen‘1’であるならばWreq‘1’になり、リードリクエストRreqは、リードバッファ10の空き容量の評価値Prが所定のワード数以上Pr≧Rnになり、リードアドレスが有効Ren‘1’であるならばRreq‘1’になるものとする。まず、ライトリクエストWreq‘1’で、ライトバッファ12のデータ蓄積数の評価値Pwと所定値Wthの関係がPw≧Wth、または、直前にリクエストキューに格納したリクエストがライトリクエストID1IDwか否かを判定し、そうであればライトリクエストをリクエストキューに蓄積する。上記の条件が成立しない場合は、リードリクエストRreq‘1’で、リードバッファ10の空き容量の評価値Prと所定値Rthの関係がPr≧Rth、または、直前にリクエストキューに格納したリクエストがリードリクエストID1IDrか否かを判定し、そうであればリードリクエストをリクエストキューに蓄積する。上記の二つの条件が成立せず、リードリクエストRreq‘1’の場合は、リードリクエストをリクエストキューに蓄積し、ライトリクエストWreq‘1’の場合は、ライトリクエストをリクエストキューに蓄積する。リクエストキューへのライトリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDwに更新する。同時に、ライトバッファ12の蓄積数の評価値Pwからライトデータ数Wnを減算して評価値Pwを更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。同様に、リクエストキューへのリードリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDrに更新する。同時に、リードバッファ10の空き容量の評価値Prからリードデータ数Rnを減算して評価値Prを更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。上記処理が終了すると、処理をステップS201に戻し、上記の処理を繰り返す。なお、ここではバッファの容量、アービタ5のシーケンスなどによりリクエストキューに蓄積されるリクエスト数Ppの上限が決まるため、リクエスト数Ppを制限しないが、システムによって制限が必要な場合は、リクエスト数Ppが最大値となった時点で、RreqWreq0とすればよい。●アービタ5のアルゴリズム図5はアービタ5のアルゴリズムを説明するフローチャートである。なお、以下の説明では、三つの画像処理モジュールM1、M2、M3と、エンジン処理モジュールM4、バスブリッジB0が接続されているとする。エンジン処理モジュールM4には、リアルタイム制御のために、最高の優先順位を設定する。また、バスブリッジB0は、エンジン処理モジュールM4に次いで高い優先順位に設定する。三つの画像処理もジュールの優先順位は同じである。従って、各モジュールの優先順位は下記のようになる。M4>B0>M1M2M3アービタ5は、まず、優先順位の一番高いエンジン処理モジュールM4からバス使用権のリクエストreq4があるつまりreq4‘1’か否かを判定する。req4‘1’ならばリクエストreq4を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをエンジン処理モジュールM4のリクエスト識別コードID4に更新し、エンジン処理モジュールM4に受領信号PACKを返し、処理をステップS211に戻す。エンジン処理モジュールM4のリクエストがなければ、バスブリッジB0のリクエストreq0があるつまりreq0‘1’か否かを判定する。req0‘1’ならばリクエストreq0を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをバスブリッジB0のリクエスト識別コードID0に更新し、バスブリッジB0に受領信号PACKを返し、処理をステップS211に戻す。バスブリッジB0のリクエストもなければ、画像処理モジュールM1のリクエストreq1があるつまりreq1‘1’か否かを判定する。req1‘1’で、さらに、リクエストキューに蓄積されている画像処理モジュールM1のリクエスト数P1が三つの画像処理モジュールM1、M2、M3の中で一番多いつまりP1Pmax、あるいは、直前に受け付けたリクエストが画像処理モジュールM1のリクエストつまりID1ID1であれば、リクエストreq1を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDを画像処理モジュールM1のリクエスト識別コードID1に更新し、画像処理モジュールM1に受領信号PACKを返し、処理をステップS211に戻す。また、req1‘0’あるいはP1≠PmaxかつID1≠ID1ならば、他の画像処理モジュールM2、M3のリクエストreq2、req3があるつまりreq2‘1’、req3‘1’か否かを判定する。リクエストがあり、さらに、リクエストキューに蓄積されている画像処理モジュールが三つの画像処理モジュールM1、M2、M3の中で一番多いつまりP2PmaxまたはP3Pmax、あるいは、直前に受け付けたリクエストが画像処理モジュールM2またはM3のリクエストつまりID1ID2またはID1ID3であれば、リクエストreq2またはreq3を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDを画像処理モジュールM2またはM3のリクエスト識別コードID2またはID3に更新し、画像処理モジュールM2またはM3に受領信号PACKを返し、処理をステップS211に戻す。上記のアルゴリズムは、一部固定の優先順位を用いているので、高い優先順位に位置付けされているバスマスタエンジン処理モジュールM4やバスブリッジB0から頻繁にバス使用権が要求されると、そのバスマスタにバスが占有されてしまう可能性がある。とくに、上記の例では、バスブリッジB0よりもエンジン処理モジュールM4の優先順位が高く設定されているため、タイミングによってCPU1のリクエストに対する応答性が悪化する。また、画像処理モジュールM1、M2、M3においても、直前に受け付けたリクエストを優先するため、特定の画像処理モジュールにバスを占有されてしまう可能性がある。そこで、特定のバスマスタがバスを占有しないように、連続アクセス数に制限を付ける。図6は連続したバスアクセスをカウントするアルゴリズムを説明するフローチャートである。まず、現在リクエストを出しているモジュール数Nrを検出し、現在のリクエスト識別コードIDと直前のリクエスト識別コードレジスタID1の値を比較し、Nr≦1またはID1≠IDであればカウンタCを零にリセットする。また、Nr>1かつID1IDであれば、ステップS224の判定により、対象モジュールに受領信号PACKを返す度にカウンタCをインクリメントする。図6の処理を繰り返すことで、カウンタCには同一モジュールによる連続したバスアクセスの回数以下連続バスアクセス数と呼ぶがカウントされる。そして、アービタ5は、カウンタCが所定値になるC<Cthと、直前のリクエスト識別コードレジスタID1が示すモジュールのリクエストをマスクする。このように、次には必ず異なるモジュールのリクエストが受け付けられるため、連続バスアクセス数は制限されることになる。なお、一度、異なるモジュールにバスの使用権が移れば、ステップS221~S223によってカウンタCがリセットされるので、リクエストのマスクは解除される。なお、図6には、連続バスアクセス数をカウントするカウンタを全モジュールで共通に使用する例を説明したが、モジュールごとにカウンタを設けてもよい。この場合、モジュールごとに連続バスアクセス数を制限することができる。例えばバスブリッジB0の制限値をCPU1のキャッシュのラインサイズに合わせておけば、効率的にキャッシュを更新することができる。また、各モジュールがDRAM7のそれぞれ異なるバンクをアクセスする場合、バスアクセスの連続性を考慮する必要はない。従って、現在のリクエスト識別コードIDと直前のリクエスト識別コードレジスタID1の比較は不要になる。このように、バッファの空き状態、直前のアクセス、連続アクセス数に応じてバスアクセスの優先順位を動的に変更制御することで、バスアクセスの連続性を向上させつつ、バスマスタのバス使用頻度に合わせた調停が可能になる。また、アービタ5だけではなく各モジュール内で調停を実行する調停の分散処理ため、モジュールに最適な調停が可能である。例えば、上述したように、各バスマスタのリクエスト発生頻度が異なる場合は、発生頻度の低い順にポインタ評価と連続アクセス数の評価を行う。これは、発生頻度の低い方を優先することで、発生頻度の低い方のバス使用権の獲得確率を高め、処理の平準化を図るためである。ただし、発生頻度がほぼ同じ場合は、ライト側を優先する。これは、一般にライト処理の方がレイテンシ待ち時間が少なく、メモリバスが解放されるまでの時間が短いためである。以下、本発明にかかる実施例2の画像処理を説明する。なお、実施例2において、実施例1と略同様の構成については、同一符号を付して、その詳細説明を省略する。図7は実施例2の画像処理モジュールの詳細な構成例を説明するブロック図で、図2に示す画像処理モジュールとの違いは、リードバッファ10、ライトバッファ12、リードアドレス発生器14およびライトアドレス発生器16がそれぞれ二つずつあることである。アービタ13は、リードバッファ10aのバッファの空き容量R0pおよびリードアドレス発生器14aのイネーブル信号R0enを検出し、リードアドレスが有効R0en‘1’でリードバッファ10aにデータが格納可能R0p≧R0nであれば、アービタ5へリードリクエストPREQ‘1’、PNRW‘0’、PNUMRn、PADDRadを発行する。同様に、リードバッファ10bのバッファの空き容量R1pおよびリードアドレス発生器14bのイネーブル信号R1enを検出し、リードアドレスが有効R1en‘1’でリードバッファ10bにデータが格納可能R1p≧R1nであれば、アービタ5へリードリクエストPREQ‘1’、PNRW‘0’、PNUMRn、PADDRadを発行する。一方、ライトバッファ12aのデータ蓄積数W0pが所定のワード数以上W0p≧W0nになると、アービタ13は、ライトアドレス発生器16bのイネーブル信号W0enを検出し、ライトアドレスが有効W0en‘1’であれば、アービタ5へライトリクエストPREQ‘1’、PNRW‘1’、PNUMWn、PADDWadを発行する。同様に、ライトバッファ12bのデータ蓄積数W0pが所定のワード数以上W1p≧W1nになると、ライトアドレス発生器16bのイネーブル信号W1enを検出し、ライトアドレスが有効W1en‘1’であれば、アービタ5へライトリクエストPREQ‘1’、PNRW‘1’、PNUMWn、PADDWadを発行する。図8は実施例2のアービタ13のアルゴリズムを説明するフローチャートである。実施例1と同様に、リクエストキューに蓄積されているリクエストが実行された場合のライトバッファ12aのデータ蓄積数評価値をPw0、ライトバッファ12bのデータ蓄積数評価値をPw1、リクエストキューに蓄積されているリクエストが実行された場合のリードバッファ10aの空き容量評価値をPr0、リードバッファ10bの空き容量評価値をPr1とする。なお、リクエストキューに蓄積されているリクエスト数Ppは、アービタ5がリクエストを受け付けるPACK‘1’と一つ減じられる。以下の説明ではリードバッファ10aのリクエストの頻度>リードバッファ10bのリクエストの頻度ライトバッファ12bのリクエストの頻度>ライトバッファ12aリクエストの頻度であると仮定し、バスアクセスのリクエスト発生頻度が低いモジュールの順に、バッファの空き状態の検出を行う。ライトバッファ12aのリクエストW0reqは、ライトバッファ12aの蓄積数の評価値Pw0が所定のワード数以上Pw0≧W0nになり、ライトアドレスが有効W0en‘1’ならば、W0req‘1’になる。同様に、ライトバッファ12bのリクエストW1reqは、ライトバッファ12bの蓄積数の評価値Pw1が所定のワード数以上Pw1≧W1nになり、ライトアドレスが有効W1en‘1’ならば、W1req‘1’になる。また、リードバッファ10aのリクエストR0reqは、リードバッファ10aの空き容量の評価値Pr0が所定のワード数以上Pr0≧R0nになり、リードアドレスが有効R0en‘1’ならば、R0req‘1’になる。同様に、リードバッファ10bのリクエストR1reqは、リードバッファ10bの空き容量の評価値Pr1が所定のワード数以上Pr1≧R1nになり、リードアドレスが有効R1en‘1’ならば、R1re‘1’になる。まず、ライトリクエストW0req‘1’で、ライトバッファ12aのデータ蓄積数の評価値P0wと所定値W0thの関係がP0w≧W0th、または、直前にリクエストキューに格納したリクエストがライトバッファ12aのライトリクエストID1IDw0か否かを判定し、そうであればライトバッファ12aのライトリクエストをリクエストキューに蓄積する。上記の条件が成立しない場合は、ライトリクエストW1req‘1’で、ライトバッファ12bのデータ蓄積数の評価値P1wと所定値W1thの関係がP1w≧W1th、または、直前にリクエストキューに格納したリクエストがライトバッファ12bのライトリクエストID1IDw1か否かを判定し、そうであればライトバッファ12bのライトリクエストをリクエストキューに蓄積する。上記の二つの条件が成立せず、リードリクエストR1req‘1’で、リードバッファ10bの空き容量の評価値Pr1と所定値R1thの関係がPr1≧R1th、または、直前にリクエストキューに格納したリクエストがリードバッファ10bのリードリクエストID1IDr1か否かを判定し、そうであればリードバッファ10bのリードリクエストをリクエストキューに蓄積する。上記の三つの条件が成立せず、リードリクエストR0req‘1’で、リードバッファ10aの空き容量の評価値Pr0と所定値R0thの関係がPr≧R0th、または、直前にリクエストキューに格納したリクエストがリードバッファ10aのリードリクエストID1IDr0か否かを判定し、そうであればリードバッファ10aのリードリクエストをリクエストキューに蓄積する。上記の四つの条件が成立せず、リードリクエストR0req‘1’の場合は、リードバッファ10aのリードリクエストをリクエストキューに蓄積し、リードリクエストR1req‘1’の場合は、リードバッファ10bのリードリクエストをリクエストキューに蓄積し、ライトリクエストW1req‘1’の場合は、ライトバッファ12bのライトリクエストをリクエストキューに蓄積し、ライトリクエストW0req‘1’の場合は、ライトバッファ12aのライトリクエストをリクエストキューに蓄積する。リクエストキューへのライトバッファ12aのライトリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDw0に更新する。同時に、ライトバッファ12aの蓄積数の評価値Pw0からライトデータ数W0nを減算して評価値Pw0を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。同様に、リクエストキューへのライトバッファ12bのライトリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDw1に更新する。同時に、ライトバッファ12bの蓄積数の評価値Pw1からライトデータ数W1nを減算して評価値Pw1を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。同様に、リクエストキューへのリードバッファ10aのリードリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDr0に更新する。同時に、リードバッファ10aの空き容量の評価値Pr0からリードデータ数R0nを減算して評価値Pr0を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。同様に、リクエストキューへのリードバッファ10bのリードリクエストの蓄積は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDr1に更新する。同時に、リードバッファ10bの空き容量の評価値Pr1からリードデータ数R1nを減算して評価値Pr1を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。上記処理が終了すると、処理をステップS231に戻し、上記の処理を繰り返す。上記のモジュールにはデータパスが二つ存在する。例えば、誤差拡散回路の誤差バッファをDRAM7上に構成するようなモジュールは、画像データのデータパスと誤差バッファのデータバスが存在する。この場合、バスマスタの数は二個から四個に増加し、このままではメモリバスに接続することができない。このような場合、モジュール内で調停を実行して接続すれば、上層の回路を一切変更することなしに、モジュールとメモリバスを接続することが可能になる。また、上述したように、アービタ5だけではなく各モジュール内で調停を実行する調停の分散処理ため、モジュールに最適な調停が可能である。例えば、上述したように、各バスマスタのリクエスト発生頻度が異なる場合は、発生頻度の低い順にポインタ評価と連続アクセス数の評価を行う。これは、発生頻度の低い方を優先することで、発生頻度の低い方のバス使用権の獲得確率を高め、処理の平準化を図るためである。ただし、発生頻度がほぼ同じ場合は、ライト側を優先する。これは、一般にライト処理の方がレイテンシ待ち時間が少なく、メモリバスが解放されるまでの時間が短いためである。また、各モジュール内で、図6に示した連続アクセス数をカウントするカウンタを用いて、連続アクセス数を制限するようにしてもよい。この場合、上記の発生頻度を考慮しなくとも、処理の平準化を図ることができる。さらに、上記評価値Pw0、Pw1、Pr0、Pr1との比較のための閾値W0th、W1th、R0th、R1thを複数設定し、より細やかな調停を行うことも可能である。この場合は、閾値の大きさ順に優先順位を設定し、最も大きな閾値との比較時に連続アクセス数を判定すればよい。このように、モジュール単位の最適化が可能になるので、容易にメモリバスの使用効率を向上させることができる。以上では、メモリバスのアクセスを調停する例を実施例として説明したが、本発明は、メモリバスに限らず、様々なバスの使用権のアービトレーションに適用可能である。[他の実施例]なお、本発明は、複数の機器例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなどから構成されるシステムに適用しても、一つの機器からなる装置例えば、複写機、ファクシミリ装置などに適用してもよい。また、本発明の目的は、前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体または記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはCPUやMPUが記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステムなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。