JP4847615B2 - バスアクセスを調停する制御装置およびその方法 - Google Patents

Description

本発明はバスアクセスを調停する制御装置およびその方法に関し、例えば、複数のバスマスタによるバスアクセスを調停する制御に関する。

バスマスタのバスアクセスを調停するアービタは、DRAMなどのメモリバスをアクセスする複数のバスマスタからのバス使用要求に対して、そのうちの一つのバスマスタに対してバス使用権を与えるバス使用権の管理制御（調停）を行う。各バスマスタに対するバス使用権の優先順位はハードウェア的に決められているので、複数のバスマスタから同時にバス使用要求があった場合、バスアービタは、予め決められている優先順位に従い、必ず、優先順位が高いバスマスタにバス使用権を与えるようにバス使用許可信号を出力する（例えば、特許文献1参照）。

従って、高い優先順位に位置付けされたバスマスタから頻繁にバス使用要求が出力されると、そのバスマスタのバス使用権の獲得割合が多くなり、低い優先順位に位置付けされたバスマスタがバス使用権を獲得するのが困難になるという問題点がある。

また、バス使用要求の受け付けを制限し、一度受け付けたバス使用要求のすべてに対してバス使用権を与えてから、次のバス使用要求を受け付けるようにすることができる。しかし、多数のバスマスタからバス使用要求が出る場合、たとえ高い優先順位に位置付けされたバスマスタでも、低い優先順位に位置付けされたバスマスタと同程度のアクセスしか実行できないという問題がある。

さらに、バースト転送がサポートされたバスや、DRAMなどのメモリバスにおいて、バス使用権を獲得したバスマスタが頻繁に入れ替わると、アドレス設定のためのオーバヘッドが増加し、バスの使用効率が低下するという問題点がある。

また、一つのアービタにバス使用権の調停を集中させると、バスマスタ数の増加に伴い調停処理が複雑化して回路の増大を招くだけでなく、バスの高速性も損われる欠点がある。

特開平09-062579号公報

本発明は、バス使用権を動的に管理して、バスの使用効率を向上することを目的とする。

また、バス使用権の調停を分散処理して、バスマスタ数の増加に伴う回路規模の増大を防ぎ、バスの高速性を維持することを他の目的とする。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

本発明にかかる制御装置は、バスに接続された複数のバスマスタと、前記複数のバスマスタのバスアクセスを調停するアービタと、前記複数のバスマスタそれぞれの、前記バスの連続アクセスの回数をカウントする計数手段とを有し、前記アービタは、前記連続アクセスの回数が所定回数に達したバスマスタを除くバスマスタのバスアクセスを調停することを特徴とする。

本発明にかかる制御方法は、バスに接続された複数のバスマスタのバスアクセスを調停する制御装置の制御方法であって、前記複数のバスマスタそれぞれの、前記バスの連続アクセスの回数をカウントし、前記連続アクセスの回数が所定回数に達したバスマスタを除くバスマスタのバスアクセスを調停することを特徴とする。

本発明によれば、バス使用権を動的に管理することで、バスの使用効率を向上することができる。

また、バス使用権の調停を分散処理することで、バスマスタ数の増加に伴う回路規模の増大を防ぎ、バスの高速性を維持することができる。

実施例1の画像処理装置の構成例を示すブロック図。 画像処理モジュールの詳細な構成例を説明するブロック図。 サブモジュール間のデータ転送を説明するタイミングチャート。 アービタ13のアルゴリズムを説明するフローチャート。 アービタ5のアルゴリズムを説明するフローチャート。 連続したバスアクセスをカウントするアルゴリズムを説明するフローチャート。 実施例2の画像処理モジュールの詳細な構成例を説明するブロック図。 実施例2のアービタ13のアルゴリズムを説明するフローチャートである。

以下、本発明にかかる実施例を図面を参照して詳細に説明する。勿論、以下の実施例は、本発明の技術分野における当業者による実施を容易にするための開示を提供するものであり、特許請求の範囲によって確定される本発明の技術的範囲に含まれるほんの一部の実施例に過ぎない。従って、本明細書に直接的に記載されていない実施例であっても、技術思想が共通する限り、本発明の技術的範囲に包含されることは、当業者にとって自明である。

また、便宜上、複数の実施例を記載するが、これらは個別に発明として成り立つだけではなく、勿論、複数の実施例を適宜組み合わせることでも発明が成り立つことは、当業者であれば容易に理解できる。

［装置の構成］
まず、各種画像処理を行った後、画像を出力する画像処理装置を例に説明する。図1は実施例1の画像処理装置の構成例を示すブロック図である。

図1において、CPU1は、ROM2に格納されたプログラムに従い、DRAM7をワークメモリとして、画像処理装置全体を制御する。また、CPU1は、CPUバス1aを介してROM2、バスブリッジ3およびI/Oポート9に接続する。

アービタ5は、バスブリッジ3を介したCPU1によるDRAM7のアクセス、および、n（n≧1、整数）個の画像処理モジュール4によるDRAM7のアクセスを調停する。また、DRAM7は、DRAMインタフェイス(I/F)6を有する。

また、画像処理モジュール1の一つ（図1ではモジュール4n）は、例えばインクジェットプリンタのプリントヘッドに接続するためのヘッドI/F8が備わる。

なお、図1には、DRAM7がCPU1および複数の画像処理モジュール4に共有される例を示したが、パフォーマンスの維持または向上のために、CPU1用のRAMをCPUバス1aに接続する構成としてもよい。

［処理動作］
CPU1は、ROM2に格納されたプログラムに従い、I/Oポート9より処理すべき画像データを受け取り、バスブリッジ3、アービタ5、DRAM I/F6を経て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に処理を開始させ、ヘッドI/F8を介してビットマップデータをプリンタエンジンに送り、プリントさせる。

●画像処理モジュールの構成
図2は画像処理モジュールの詳細な構成例を説明するブロック図で、リードバッファ10、m（m≧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’、PNUM=Rn、PADD=Rad）を発行する。

一方、ライトバッファ12のデータ蓄積数Wpが所定のワード数以上（Wp≧Wn）になると、アービタ13は、ライトアドレス発生器16のイネーブル信号Wenを検出し、ライトアドレスが有効（Wen=‘1’）であれば、アービタ5へライトリクエスト（PREQ=‘1’、PNRW=‘1’、PNUM=Wn、PADD=Wad）を発行する。

アービタ5は、画像処理モジュール4からリクエスト信号PREQを受け取ると、PNRWでリード/ライトを判別し、PNUMでワード数を、PADDでアドレスを検知する。CPU1および他の画像処理モジュール4からのリクエストがなければ、アービタ5は、DRAM I/F6を通じてDRAM7の該当データのアクセスを開始する。DRAM I/F6にリクエストが受け付けられると、アービタ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の処理に必要なデータが揃うと有効信号valid_0をセットし、サブモジュール11aの処理に必要なデータが揃っていなければ有効信号valid_0をリセットする。

そして、サブモジュール11aからの保持要求信号stall_0がセットされていない場合、リードバッファ10は、格納したデータをクロックに同期して出力する。もし、保持要求信号stall_0がセットされている場合は、データを更新しない。

サブモジュール11aは、有効信号valid_0がセットされているデータのみを受け取る。なお、データの受け取りが不可能な場合は、保持要求信号stall_0をセットし、リードバッファ10の出力をホールドする。なお、入力データの並べ替えが不要な場合、リードバッファ10はFIFO (First In First Out)メモリでよい。同様に、出力データの並べ替えが不要な場合、ライトバッファ12はFIFOメモリでよい。

画像処理モジュール4の内部は、画像処理を行う一つ以上のサブモジュール11によって構成され、各サブモジュール間では、上記と同様の動作（有効信号valid_xと保持要求信号stall_xによるハンドシェーク）によってデータdata_xの受け渡しを行う。

●サブモジュール間のデータ転送
図3はサブモジュール11間のデータ転送を説明するタイミングチャートである。

データ送信側のサブモジュール11は、データが出力可能であればクロックclkの立ち上がりに同期してデータ信号d1および有効信号validをセットする(T1)。次のクロックの立ち上がりで受信側から保持要求信号stallがセットされていなければデータ信号d1が受信されたとみなし、次のデータが出力可能であればデータ信号d2および有効信号validをセットする(T2)。もし、次のデータが出力不能であれば有効信号validをリセットする(T3)。また、次のクロックの立ち上がりで受信側から保持要求信号stallがセットされていた場合は、データ信号が受信されなかったとみなし、データ信号d5および有効信号validをホールドする(T7)。なお、受信側から保持要求信号stallがセットされていても有効信号validをセットしていなければ(T8)、無効データであるからデータ信号および有効信号validをホールドせずに、次の有効データとしてデータ信号d6を出力し、有効信号validをセットする(T9)。言い換えれば、有効信号validをセットしていない場合の保持要求信号stallは無視する。

データ受信側のサブモジュール11は、受信可能であれば有効信号validがセットされているデータ信号をクロックclkの立ち上がりに同期して受け取る(T1、T2、T4、T5)。また、受信不能であれば保持要求信号stallをセットし、送信側にデータ信号d5および有効信号validを保持させる(T6)。そして、受信可能になると保持要求信号stallをリセットし、データ出力d5を受信する(T7)。

また、ライトバッファ12は、バッファに空きがあれば、サブモジュール11からの有効信号valid_nがセットされたときのデータ信号data_nをバッファに格納する。もし、バッファに空きがなければ、保持要求信号stall_nをセットし、サブモジュール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、または、直前にリクエストキューに格納したリクエストがライトリクエスト（ID1=IDw）か否かを判定し(S201)、そうであればライトリクエストをリクエストキューに蓄積する(S205)。

上記の条件が成立しない場合は、リードリクエストRreq=‘1’で、リードバッファ10の空き容量の評価値Prと所定値Rthの関係がPr≧Rth、または、直前にリクエストキューに格納したリクエストがリードリクエスト（ID1=IDr）か否かを判定し(S202)、そうであればリードリクエストをリクエストキューに蓄積する(S206)。

上記の二つの条件が成立せず、リードリクエストRreq=‘1’の場合は(S203)、リードリクエストをリクエストキューに蓄積し(S206)、ライトリクエストWreq=‘1’の場合は(S204)、ライトリクエストをリクエストキューに蓄積する(S205)。

リクエストキューへのライトリクエストの蓄積(S205)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDwに更新する。同時に、ライトバッファ12の蓄積数の評価値Pwからライトデータ数Wnを減算して評価値Pwを更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

同様に、リクエストキューへのリードリクエストの蓄積(S206)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDrに更新する。同時に、リードバッファ10の空き容量の評価値Prからリードデータ数Rnを減算して評価値Prを更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

上記処理が終了すると、処理をステップS201に戻し、上記の処理を繰り返す。

なお、ここではバッファの容量、アービタ5のシーケンスなどによりリクエストキューに蓄積されるリクエスト数Ppの上限が決まるため、リクエスト数Ppを制限しないが、システムによって制限が必要な場合は、リクエスト数Ppが最大値となった時点で、Rreq=Wreq=0とすればよい。

●アービタ5のアルゴリズム
図5はアービタ5のアルゴリズムを説明するフローチャートである。なお、以下の説明では、三つの画像処理モジュールM1、M2、M3と、エンジン処理モジュールM4、バスブリッジB0が接続されているとする。エンジン処理モジュールM4には、リアルタイム制御のために、最高の優先順位を設定する。また、バスブリッジB0は、エンジン処理モジュールM4に次いで高い優先順位に設定する。三つの画像処理もジュールの優先順位は同じである。従って、各モジュールの優先順位は下記のようになる。
M4 ＞ B0 ＞ M1, M2, M3

アービタ5は、まず、優先順位の一番高いエンジン処理モジュールM4からバス使用権のリクエストreq4がある（つまりreq4=‘1’）か否かを判定する(S211)。req4=‘1’ならばリクエストreq4を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをエンジン処理モジュールM4のリクエスト識別コードID_4に更新し、エンジン処理モジュールM4に受領信号PACKを返し(S216)、処理をステップS211に戻す。

エンジン処理モジュールM4のリクエストがなければ、バスブリッジB0のリクエストreq0がある（つまりreq0=‘1’）か否かを判定する(S212)。req0=‘1’ならばリクエストreq0を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをバスブリッジB0のリクエスト識別コードID_0に更新し、バスブリッジB0に受領信号PACKを返し(S217)、処理をステップS211に戻す。

バスブリッジB0のリクエストもなければ、画像処理モジュールM1のリクエストreq1がある（つまりreq1=‘1’）か否かを判定する(S213)。req1=‘1’で、さらに、リクエストキューに蓄積されている画像処理モジュールM1のリクエスト数P1が三つの画像処理モジュールM1、M2、M3の中で一番多い（つまりP1=Pmax）、あるいは、直前に受け付けたリクエストが画像処理モジュールM1のリクエスト（つまりID1=ID_1）であれば、リクエストreq1を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDを画像処理モジュールM1のリクエスト識別コードID_1に更新し、画像処理モジュールM1に受領信号PACKを返し(S218)、処理をステップS211に戻す。

また、req1=‘0’あるいはP1≠PmaxかつID1≠ID_1ならば、他の画像処理モジュールM2、M3のリクエストreq2、req3がある（つまりreq2=‘1’、req3=‘1’）か否かを判定する(S214、S215)。リクエストがあり、さらに、リクエストキューに蓄積されている画像処理モジュールが三つの画像処理モジュールM1、M2、M3の中で一番多い（つまりP2=PmaxまたはP3=Pmax）、あるいは、直前に受け付けたリクエストが画像処理モジュールM2またはM3のリクエスト（つまりID1=ID_2またはID1=ID_3）であれば、リクエストreq2またはreq3を受け付け、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDを画像処理モジュールM2またはM3のリクエスト識別コードID_2またはID_3に更新し、画像処理モジュールM2またはM3に受領信号PACKを返し(S219またはS220)、処理をステップS211に戻す。

上記のアルゴリズムは、一部固定の優先順位を用いているので、高い優先順位に位置付けされているバスマスタ（エンジン処理モジュールM4やバスブリッジB0）から頻繁にバス使用権が要求されると、そのバスマスタにバスが占有されてしまう可能性がある。とくに、上記の例では、バスブリッジB0よりもエンジン処理モジュールM4の優先順位が高く設定されているため、タイミングによってCPU1のリクエストに対する応答性が悪化する。また、画像処理モジュールM1、M2、M3においても、直前に受け付けたリクエストを優先するため、特定の画像処理モジュールにバスを占有されてしまう可能性がある。そこで、特定のバスマスタがバスを占有しないように、連続アクセス数に制限を付ける。

図6は連続したバスアクセスをカウントするアルゴリズムを説明するフローチャートである。

まず、現在リクエストを出しているモジュール数Nrを検出し(S221)、現在のリクエスト識別コードIDと直前のリクエスト識別コードレジスタID1の値を比較し(S222)、Nr≦1またはID1≠IDであればカウンタCを零にリセットする(S223)。また、Nr＞1かつID1=IDであれば、ステップS224の判定により、対象モジュールに受領信号PACKを返す度にカウンタCをインクリメントする(S224)。

図6の処理を繰り返すことで、カウンタCには同一モジュールによる連続したバスアクセスの回数（以下「連続バスアクセス数」と呼ぶ）がカウントされる。そして、アービタ5は、カウンタCが所定値になる（C＜Cth）と(S226)、直前のリクエスト識別コードレジスタID1が示すモジュールのリクエストをマスクする(S227)。

このように、次には必ず異なるモジュールのリクエストが受け付けられるため、連続バスアクセス数は制限されることになる。なお、一度、異なるモジュールにバスの使用権が移れば、ステップS221〜S223によってカウンタCがリセットされるので、リクエストのマスクは解除される(S228)。

なお、図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’、PNUM=Rn、PADD=Rad）を発行する。同様に、リードバッファ10bのバッファの空き容量R1pおよびリードアドレス発生器14bのイネーブル信号R1enを検出し、リードアドレスが有効（R1en=‘1’）でリードバッファ10bにデータが格納可能（R1p≧R1n）であれば、アービタ5へリードリクエスト（PREQ=‘1’、PNRW=‘0’、PNUM=Rn、PADD=Rad）を発行する。

一方、ライトバッファ12aのデータ蓄積数W0pが所定のワード数以上（W0p≧W0n）になると、アービタ13は、ライトアドレス発生器16bのイネーブル信号W0enを検出し、ライトアドレスが有効（W0en=‘1’）であれば、アービタ5へライトリクエスト（PREQ=‘1’、PNRW=‘1’、PNUM=Wn、PADD=Wad）を発行する。同様に、ライトバッファ12bのデータ蓄積数W0pが所定のワード数以上（W1p≧W1n）になると、ライトアドレス発生器16bのイネーブル信号W1enを検出し、ライトアドレスが有効（W1en=‘1’）であれば、アービタ5へライトリクエスト（PREQ=‘1’、PNRW=‘1’、PNUM=Wn、PADD=Wad）を発行する。

図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のライトリクエスト（ID1=IDw0）か否かを判定し(S231)、そうであればライトバッファ12aのライトリクエストをリクエストキューに蓄積する(S239)。

上記の条件が成立しない場合は、ライトリクエストW1req=‘1’で、ライトバッファ12bのデータ蓄積数の評価値P1wと所定値W1thの関係がP1w≧W1th、または、直前にリクエストキューに格納したリクエストがライトバッファ12bのライトリクエスト（ID1=IDw1）か否かを判定し(S232)、そうであればライトバッファ12bのライトリクエストをリクエストキューに蓄積する(S240)。

上記の二つの条件が成立せず、リードリクエストR1req=‘1’で、リードバッファ10bの空き容量の評価値Pr1と所定値R1thの関係がPr1≧R1th、または、直前にリクエストキューに格納したリクエストがリードバッファ10bのリードリクエスト（ID1=IDr1）か否かを判定し(S233)、そうであればリードバッファ10bのリードリクエストをリクエストキューに蓄積する(S242)。

上記の三つの条件が成立せず、リードリクエストR0req=‘1’で、リードバッファ10aの空き容量の評価値Pr0と所定値R0thの関係がPr≧R0th、または、直前にリクエストキューに格納したリクエストがリードバッファ10aのリードリクエスト（ID1=IDr0）か否かを判定し(S234)、そうであればリードバッファ10aのリードリクエストをリクエストキューに蓄積する(S241)。

上記の四つの条件が成立せず、リードリクエストR0req=‘1’の場合は(S235)、リードバッファ10aのリードリクエストをリクエストキューに蓄積し(S241)、リードリクエストR1req=‘1’の場合は(S236)、リードバッファ10bのリードリクエストをリクエストキューに蓄積し(S242)、ライトリクエストW1req=‘1’の場合は(S237)、ライトバッファ12bのライトリクエストをリクエストキューに蓄積し(S240)、ライトリクエストW0req=‘1’の場合は(S238)、ライトバッファ12aのライトリクエストをリクエストキューに蓄積する(S239)。

リクエストキューへのライトバッファ12aのライトリクエストの蓄積(S239)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDw0に更新する。同時に、ライトバッファ12aの蓄積数の評価値Pw0からライトデータ数W0nを減算して評価値Pw0を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

同様に、リクエストキューへのライトバッファ12bのライトリクエストの蓄積(S240)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをライトリクエスト識別コードIDw1に更新する。同時に、ライトバッファ12bの蓄積数の評価値Pw1からライトデータ数W1nを減算して評価値Pw1を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

同様に、リクエストキューへのリードバッファ10aのリードリクエストの蓄積(S241)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDr0に更新する。同時に、リードバッファ10aの空き容量の評価値Pr0からリードデータ数R0nを減算して評価値Pr0を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

同様に、リクエストキューへのリードバッファ10bのリードリクエストの蓄積(S242)は、現在のリクエスト識別コードIDを直前のリクエスト識別コードレジスタID1に格納し、現在のリクエスト識別コードIDをリードリクエスト識別コードIDr1に更新する。同時に、リードバッファ10bの空き容量の評価値Pr1からリードデータ数R1nを減算して評価値Pr1を更新し、リクエストキューに蓄積されているリクエスト数Ppを一つ増やす。

上記処理が終了すると、処理をステップS231に戻し、上記の処理を繰り返す。

上記のモジュールにはデータパスが二つ存在する。例えば、誤差拡散回路の誤差バッファをDRAM7上に構成するようなモジュールは、画像データのデータパスと誤差バッファのデータバスが存在する。この場合、バスマスタの数は二個から四個に増加し、このままではメモリバスに接続することができない。このような場合、モジュール内で調停を実行して接続すれば、上層の回路を一切変更することなしに、モジュールとメモリバスを接続することが可能になる。

また、上述したように、アービタ5だけではなく各モジュール内で調停を実行する（調停の分散処理）ため、モジュールに最適な調停が可能である。例えば、上述したように、各バスマスタのリクエスト発生頻度が異なる場合は、発生頻度の低い順にポインタ評価と連続アクセス数の評価を行う。これは、発生頻度の低い方を優先することで、発生頻度の低い方のバス使用権の獲得確率を高め、処理の平準化を図るためである。ただし、発生頻度がほぼ同じ場合は、ライト側を優先する。これは、一般にライト処理の方がレイテンシ（待ち時間）が少なく、メモリバスが解放されるまでの時間が短いためである。

また、各モジュール内で、図6に示した連続アクセス数をカウントするカウンタを用いて、連続アクセス数を制限するようにしてもよい。この場合、上記の発生頻度を考慮しなくとも、処理の平準化を図ることができる。

さらに、上記評価値（Pw0、Pw1、Pr0、Pr1）との比較のための閾値（W0th、W1th、R0th、R1th）を複数設定し、より細やかな調停を行うことも可能である。この場合は、閾値の大きさ順に優先順位を設定し、最も大きな閾値との比較時に連続アクセス数を判定すればよい。このように、モジュール単位の最適化が可能になるので、容易にメモリバスの使用効率を向上させることができる。

以上では、メモリバスのアクセスを調停する例を実施例として説明したが、本発明は、メモリバスに限らず、様々なバスの使用権のアービトレーションに適用可能である。

［他の実施例］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

Claims (7)

1. バスに接続された複数のバスマスタと、
   前記複数のバスマスタのバスアクセスを調停するアービタと、
   前記複数のバスマスタごとに、前記バスの連続アクセスの回数をカウントする計数手段とを有し、
   前記アービタは、前記連続アクセスの回数が所定回数に達したバスマスタを除くバスマスタのバスアクセスを調停することを特徴とする制御装置。
2. 前記計数手段は、前記アービタにより前記バスをアクセスするバスマスタが切り替わるごとに、前記カウントの値をリセットすることを特徴とする請求項1に記載の制御装置。
3. 前記計数手段は、前記バスアクセスが競合しない場合は、前記カウントの値をリセットすることを特徴とする請求項1または請求項2に記載の制御装置。
4. さらに、前記計数手段が計数する連続アクセスの回数が所定回数に達したバスマスタからのバスアクセス要求をマスクするマスク手段を有することを特徴とする請求項1から請求項3の何れか一項に記載の制御装置。
5. 前記複数のバスマスタはそれぞれ、前記バスに接続されているメモリに対してリードアクセスを要求する第一のマスタ、前記メモリに対してライトアクセスを要求する第二のマスタ、前記第一および第二のマスタのバスアクセスを調停する内部アービタ、並びに、前記内部アービタが直前に調停して受け付けたバスアクセスの種類を記憶する記憶手段を備え、
   前記内部アービタは、前記内部アービタが属すバスマスタ内で複数のバスアクセスの要求が競合すると、前記記憶手段が記憶する前記バスアクセスの種類と同じ種類のバスアクセスの要求を優先して前記調停を行うことを特徴とする請求項1から請求項4の何れか一項に記載の制御装置。
6. 前記メモリはダイナミックランダムアクセスメモリであり、前記複数のバスマスタは、前記メモリに書き込む画像データ、または、前記メモリから読み出した画像データを処理する画像処理モジュールであることを特徴とする請求項5に記載の制御装置。
7. バスに接続された複数のバスマスタのバスアクセスを調停する制御装置の制御方法であって、
   前記複数のバスマスタごとに、前記バスの連続アクセスの回数をカウントし、
   前記連続アクセスの回数が所定回数に達したバスマスタを除くバスマスタのバスアクセスを調停することを特徴とする制御方法。

Images