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

Description

本発明は、複数のクライアント（バスマスタ）からのデータ転送要求を調停し、メモリバスへのアクセスを許可するデータ処理装置に関する。

複数のクライアント間で１つのメモリバスを共有する際に、そのメモリバスに対する複数のクライアント（バスマスタ）からのアクセスを調停するための、データ処理装置としてのアービタに関する様々な技術が従来より提案されている。
たとえば、下記特許文献１では、複数のバスマスタからのデータ転送要求を調停する際に、バスマスタの数が増大しても、処理速度の低下を防止するために、ツリー構造型のラウンドロビンアービタに関する技術が開示されている。

通常、このようなツリー構造のアービタでは、そのツリーから導き出される割合にしたがって各バスマスタのバンド幅が保証される。
図７は、ラウンドロビンアービタのツリー構造の一例である。図では、たとえば、効率を考慮したバンド幅：１０に対して、バスマスタＡ〜Ｃの各バスマスタに対し、それぞれ、「２．５」、「２．５」、「５」のバンド幅が保証される。なお、図中の矢印は、トークンが渡される向きを示す。

しかし、昨今、システムモードの多様化によって、１つのバスマスタが複数のモードを有し、各モード毎にバンド幅が著しく変化する場合がある。たとえば、映像表示を行うクライアントの場合、ＨＤモード（高密度映像モード）とＳＤモード（標準映像モード）とでは、映像の解像度が異なるためにバンド幅が大きく異なるのが通常である。かかる場合には、１つのツリー構造に基づくバンド幅の保証のみでは対応することができない。
また、システムモードの多様化に応じた複数のツリー構造を設定することは、あるモードからその他のモードへの遷移状態をどのように扱うかという問題、モードが非常に多く存在する場合にどの程度ツリーを設定する必要があるかという問題、などがあり、現実的に困難である。

ところで、あるバスマスタが、ツリー構造から割り当てられるバンド幅以上に動作する場合であっても、全バスマスタの合計バンド幅が効率を考えた全バンド幅を超えない限り、比較的長い時間で見ると、当該バスマスタのバンド幅も保証される。これは、ツリー構造上恵まれたバスマスタ（データ転送要求（以下、単にリクエストと称する）以上にバンド幅が割り当てられたバスマスタ）がリクエストを行わないことで、ツリー構造の一時的変化が起こり、他のバスマスタに対して、本来割り当てられたバンド幅以上のバンド幅が与えられるためである。

その一方で、ツリー構造上恵まれたバスマスタがリクエストを行う際の間隔が均一でない場合には、その他のバスマスタが有するＦＩＦＯバッファが不利となる。
図８は、（ａ）リクエストを同じ間隔で行う場合と、（ｂ）リクエストを同じ間隔で行わない場合とで、ＦＩＦＯバッファに与える影響を説明するための図である。
図８において、時刻ｒｔ１〜ｒｔ５は、図７で示した各バスマスタＡ〜Ｃがリクエスト（ＲＥＱ＿Ａ，ＲＥＱ＿Ｂ，ＲＥＱ＿Ｃ）を行うタイミングであり、時刻ｇｔ１〜ｇｔ８は、アービタからグラントを受け取るタイミングである。そして、リクエストのタイミングと、そのリクエストに対して受け取るグラントのタイミングが、対応付けて線で結ばれている。
なお、ここで、バスマスタＢは、図示しないメモリからデータの読み込みを行うリード用バスマスタであり、一定レートで外部のクライアントからＦＩＦＯバッファ上のデータが引き抜かれる。

図８において、ステップ状に示される線図は、バスマスタＢのＦＩＦＯバッファに蓄積されるデータ量を示す。たとえば、（ａ）では、時刻ｇｔ３，ｇｔ４，ｇｔ５，ｇｔ８にグラントが与えられ、これらのタイミングで、図示しないメモリコントローラを介し、順次ＦＩＦＯバッファに蓄積される。
また、図における直線ｒａｔｅ＿Ｂは、バスマスタＢのクライアントが、バスマスタＢのＦＩＦＯバッファからデータを引き抜く際のレートを示す。直線ｒａｔｅ＿Ｂの傾きは、（ａ）および（ｂ）ともに一定である。

図８（ａ）では、バスマスタＣのリクエスト（ＲＥＱ＿Ｃ）は、割り当てられたバンド幅に応じた均一の間隔で行われている（時刻ｒｔ１，時刻ｒｔ４，…）。
なお、時刻ｒｔ２およびｒｔ３におけるバスマスタＢのリクエスト（ＲＥＱ＿Ｂ）に応じてグラントが与えられているのは、トークンの向きとしては逆（トークンが渡される順序としては最後）であるものの、他のバスマスタがリクエストを行っていないからである。

一方、図８（ｂ）では、バスマスタＣのリクエスト（ＲＥＱ＿Ｃ）は、一定の期間で見れば割り当てられたバンド幅に応じた平均的な間隔となっているものの、時刻ｒｔ１およびｒｔ２において局所的にリクエストが行われた場合を示している。この時、時刻ｒｔ２においてツリー構造上優先度の高い、すなわち、トークンが先に渡されるバスマスタＣが先に調停される結果、バスマスタＢは、（ａ）と異なり、時刻ｇｔ３でグラントが与えられない。
すなわち、バスマスタＢは、（ａ）の場合と異なり、最初の調停時刻が遅れる（時刻ｇｔ４になる）ことになるが、バスマスタＢのクライアントからのデータ引き抜きレートは、（ａ）の場合と（ｂ）の場合とで同一のため、たとえば時刻ｇｔ４の時点において、（ａ）の場合と比較して、図に示すＤＩＦＦの分だけ大きく引き抜かれることになり、ＦＩＦＯバッファにとって不利となる。

以上、図８を参照して説明したように、あるバスマスタが、ツリー構造から割り当てられるバンド幅以上に動作する場合にＦＩＦＯバッファによりデータ損失を防止するシステムにおいては、バンド幅が保証される時間がＦＩＦＯバッファで補うことができる時間であるか否かが重要なポイントとなり、それはデータ転送に対するリクエスト間隔にむらがあるか否かに依存するのである。
そこで、下記特許文献２では、データ転送のリクエスト間隔のむらを抑制するために、ツリー構造から割り当てられたバンド幅以下で動作するバスマスタに対してタイマを設け、そのタイマによりリクエストをマスクするアービタに関する技術が開示されている。
特開２００２−３０４３６７号公報 特開２００３−２５６３５８号公報

しかし、上記特許文献２に開示されているように、タイマにより一度グラントをうけてから次のリクエストをタイマ値のサイクル数だけマスクする方法によれば、バスマスタのリクエストは、タイマによりマスクされた後、さらに調停による待ち時間（調停により順番が回ってくる時間）の後に満たされる（グラントが与えられる）ことになる。
このことは、タイマによりリクエストの制限を与えようとするバスマスタに対して、求められるバンド幅に応じて単純に導き出されるタイマ値を設定すると、調停待ち時間の分だけバンド幅が削減されることを意味する。

したがって、あるバスマスタに対するタイマ値は、ワーストケースでの調停待ち時間を考慮して設定する必要があるが、その一方で、ワーストケースの調停待ち時間を考慮したタイマ値が設定された場合に、実際にはベストケースでの調停待ち時間をもってグラントが与えられると、ツリー構造以上のバンド幅をリクエストするその他のバスマスタが破綻する可能性がある。
すなわち、タイマにより単純に一度グラントをうけてから次のリクエストをタイマ値のサイクル数だけマスクするのでは、調停の待ち時間にむらがある場合に対応することができず、実際にワーストケースを見積もることが困難であるため、ＦＩＦＯバッファの容量に対して過度のマージンを設定する必要が生ずる。

本発明はかかる事情に鑑みてなされたものであり、その目的は、バスマスタのデータ転送要求の間隔をバンド幅に相当する間隔に抑制するデータ処理装置を提供することにある。

上述した目的を達成するための本発明は、それぞれバッファを含む複数のバスマスタと、データ転送要求を調停し、前記複数のバスマスタの中からデータ転送を許可したバスマスタに対して、メモリバスへのアクセスを許可するアービタと、を有し、前記複数のバスマスタのうち少なくとも一のバスマスタは、タイマによりデータ転送要求を行うタイミングが管理され、第１のデータ転送要求に対する前記アービタの調停が前記タイマの設定時間を経過する回数をカウントし、当該カウント値に応じて、前記第１のデータ転送要求に続く第２のデータ転送要求以後の複数のデータ転送要求を、前記タイマに関わらず直ちに行うデータ処理装置である。

好適には、前記一のバスマスタは、前記アービタからデータ転送要求に対する許可が与えられる毎に、前記カウント値を減ずる。

好適には、前記一のバスマスタは、データ転送要求を、所定量のデータに対応する複数のデータ転送要求に分割して行い、バッファが前記所定量のデータを格納可能な数を、前記カウント値の上限とする。

好適には、前記一のバスマスタは、すべてのデータ転送要求に対して前記アービタより許可が与えられると、前記カウント値をリセットし、または、前記カウント値が「１」以上である場合に「１」に固定する。

好適には、前記一のバスマスタは、バッファがオーバーフローまたはアンダーフローするためにデータ転送要求を行うことができない間は、前記カウント値が「１」以上である場合に「１」に固定する。

本発明のデータ処理装置の作用は、以下の通りである。
すなわち、前記複数のバスマスタのうち少なくとも一のバスマスタは、タイマによりデータ転送要求を行うタイミングが管理されており、通常、タイマによる遅れ時間をもって、データ転送要求を行う。
そして、第１のデータ転送要求に対する前記アービタの調停時間が、前記タイマの設定時間より長くなると、その第１のデータ転送要求の次になされる第２のデータ転送要求については、タイマによる遅れを伴わずに直ちに行う。
これにより、第１のデータ転送要求におけるアービタの調停の遅れ分が、後の第２のデータ転送要求で取り戻される結果、ある一定期間では、アービタの調停時間によらず、データ転送要求のタイミングを均一と見ることができる。

本発明によれば、バスマスタのデータ転送要求の間隔をバンド幅に相当する間隔に抑制するので、その他のバスマスタに対する影響を少なくすることができ、バスマスタ全体のデータ転送性能を向上させることができる。さらに、バスマスタに必要なＦＩＦＯバッファの容量を正確に見積もることができるので、過度のマージンを必要とせず、小型化および低コスト化に資する。

実施の形態
本実施形態に係るデータ処理装置は、ラウンドロビンアービタにおけるツリー構造によって割り当てられるバンド幅以上のバンド幅をリクエストするバスマスタのデータ転送を保証するために、ツリー構造の変化を見積もることを可能にするとともに、バスマスタのデータ転送要求（リクエスト）間隔をタイマにより制御して、そのリクエスト間隔を平均化するものである。

図１は、本発明の一実施形態であるデータ処理装置の一構成例である。
図１では、メモリ（ＭＥＭ）４に対するデータ転送を行う複数のクライアント（ＣＬＴ）１ａ〜１ｄに対して、ＦＩＦＯバッファを含むバスマスタ（ＢＭ）２ａ〜２ｄが接続され、各バスマスタからのリクエストをメモリコントローラ（ＭＥＭ＿Ｃ）３内のアービタ（ＡＲＢ）３１が調停する。
なお、クライアント１ａ，１ｂは、リード用クライアントであり、メモリ４からデータを読み出すクライアントである。クライアント１ｃ，１ｄは、ライト用クライアントであり、メモリ４に対してデータを書き込むクライアントである。
図１に示すように、各クライアントは、対応するバスマスタに対してデータ転送に係るコマンド（ＣＭＤ）を与え、各バスマスタはこのコマンドに応じて、データ転送に係るリクエストをアービタ３１に対して行う。

アービタ３１は、図１に図示した複数のバスマスタからのリクエストを調停した結果、１つのバスマスタに対して、メモリバスに対するアクセスを許可するためのグラント（ＧＮＴ）を与える。
アービタ３１の調停方式としては、たとえば、上述したツリー構造のラウンドロビンアービタを適用することができる。すなわち、複数のバスマスタ間にトークンを走らせ、あるバスマスタにリクエストがない場合には、次のバスマスタにトークンを渡していき、リクエストがあるバスマスタにトークンが回ってきた時に、そのバスマスタに対してグラント信号を与える。そして、この調停をツリー構造に構成された複数のサブアービタによって順次行う。

図２は、リード用クライアントに対応するバスマスタ２の構成を示す回路ブロック図の一例である。
図２において、ＦＩＦＯバッファ１０は、データ転送のむらや調停待ち時間のむらを吸収し、各バスマスタの処理を破綻させないためのデータバッファである。アービタ３１は、このＦＩＦＯバッファがオーバーフロ／アンダーフロを起こさないように各バスマスタからのリクエストを調停することが必要である。

クライアントからのデータ転送コマンド（ＣＭＤ）は、順次コマンドバッファ（ＣＭＤ＿ＢＵＦ）１３に蓄積され、パケット分割部１４により処理される。
パケット分割部１４では、コマンドバッファ１３に蓄積されたデータ転送コマンド（ＣＭＤ）を、メモリコントローラ３によって規定される所定のデータ転送単位（パケット）に分割するとともに、順次、パケット単位でリクエスト信号を生成するようにリクエスト生成部１５に指示する。このとき、ＦＩＦＯバッファの空き容量が１パケット分ない場合は、ＦＩＦＯバッファの制御として、リクエストを止めなければならない(すなわち、ＦＵＬＬでない場合のみリクエストを行う)。
また、メモリ４のアドレス等のメモリアクセスに関する情報は、パケット分割部１４からメモリコントローラ３に対して送出される。
パケットとしては、リード用パケットおよびライト用パケットの２種類が必ず存在するが、その他として、たとえばデータ量の違い、アドレッシングの違いでパケットを設定してもよい。また、リフレッシュ等をパケットに含めてもよい。

リクエスト生成部１５により生成されたリクエスト信号（ＲＥＱ）は、無条件にメモリコントローラ３内のアービタ３１に出力されるのではなく、図に示すように、リクエスト信号（ＲＥＱ）の出力有無は、図に示すリクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）により、ＡＮＤ回路１６を介して制御される。

リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）には、図示しないＣＰＵによりタイマ設定値（ＴＩＭ）が与えられる。
タイマ設定値は、バスマスタによって異なる値であり、リクエスト信号（ＲＥＱ）の出力をマスクするサイクル数として、各バスマスタに与えられる。すなわち、このタイマ設定値（ＴＩＭ）に応じたマスク期間では、リクエスト信号（ＲＥＱ）が停止される。したがって、タイマ設定値（ＴＩＭ）が小さく設定されているほど、リクエスト信号（ＲＥＱ）がマスクされる期間が短くなり、優先度が上がることになる。

これにより、タイマ設定値（ＴＩＭ）に応じたバンド幅を各バスマスタに与えることができることになるが、単にタイマ設定値（ＴＩＭ）に応じた制御だけでは、調停の待ち時間にむらがある場合には、その待ち時間の分だけバンド幅が削減されることと等価になってしまう。
したがって、本実施形態では、調停の待ち時間に依存せずに、バンド幅のみから導き出せるタイマ値を設定できるように、リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）を以下に説明するように構成している。

図３は、リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）を構成するタイマカウンタ（ＣＴＲ）１１およびリクエスト制御値生成部（ＲＣＶＧ）１２の回路ブロック図の一例である。
タイマカウンタ１１は、タイマ設定値（ＴＩＭ）を順次カウントし、カウントを終了する毎にリクエスト制御値生成部１２へ通知する。
すなわち、カウンタ１１１では、タイマ設定値（ＴＩＭ）のカウントが終了する毎に、判定回路１１２およびゲート回路１１６を介して、タイマ設定値（ＴＩＭ）がロードされて、またカウントが始められる。そして、タイマ設定値（ＴＩＭ）のカウントが終了する毎に、判定回路１１２よりリクエスト制御値生成部１２へ制御信号が送出される。
なお、タイマカウンタ１１１は、対応するバスマスタ２がリクエスト信号（ＲＥＱ）を出力した後の調停の待ち時間の間も、カウントを継続する。

リクエスト制御値生成部１２は、図に示すように、カウンタ１２２を含んで構成され、このカウンタ１２２のカウント値がリクエスト制御値（ＲＣＶ）となる。
カウンタ１２２は、カウンタ１１１によりタイマ設定値（ＴＩＭ）のカウントが終了する毎にゲート回路１２１に与えられる制御信号に応じて、カウントアップする。
また、カウンタ１２２は、アービタ３１よりグラント信号（ＧＮＴ）が与えられると、カウントダウンする。
その際、タイマ設定値（ＴＩＭ）のカウントが終了し、かつ、グラント信号（ＧＮＴ）がアービタ３１より与えられた場合には、カウントアップとカウントダウンが相殺されるので、ＡＮＤ回路１２３を介して、カウントアップおよびカウントダウンはともに行わない（＋／−０）。

また、リクエスト制御値生成部１２では、カウンタ１２２に対してカウントできる最大値を設定している。その最大値は、ＦＩＦＯバッファの容量に対応していることが望ましい。すなわち、ＦＩＦＯバッファ１０が、クライアントが一回のデータ転送で要するデータ量の何倍に相当するかによって最大値を決定する。
図３では、最大値判定回路（ＭＡＸ）１２４がリクエスト制御値（ＲＣＶ）をモニタし、リクエスト制御値（ＲＣＶ）が所定の最大値に達した場合には、出力レベルを反転させ、これにより、ゲート回路１２１は、カウンタ１２２がカウントアップしないように制御する。

以上、リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）の構成および動作について述べた。次に、再び図２に戻って、リクエスト制御値（ＲＣＶ）によるリクエスト信号（ＲＥＱ）の出力制御について説明する。

図２に示すように、バスマスタ２では、カウンタ１２２のカウント値であるリクエスト制御値（ＲＣＶ）が「０」でない場合（！＝０）には、リクエスト生成部１５が生成したリクエスト信号（ＲＥＱ）を直ちにアービタ３１に対して送出する。
逆に、リクエスト制御値（ＲＣＶ）が「０」である場合（＝０）には、タイマ設定値（ＴＩＭ）のカウントが終了し、カウンタ１２２がカウントアップされてリクエスト制御値（ＲＣＶ）が「０」でなくなった時点で、リクエスト信号（ＲＥＱ）をアービタ３１に対して送出する。

すなわち、リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）は、バンド幅に応じて割り当てられたタイマ設定値（ＴＩＭ）よりアービタ３１の調停待ち時間が長い場合には、次のリクエスト信号（ＲＥＱ）を抑制せずに直ちに送出する。そして、カウンタ１２２がカウントアップされ、リクエスト制御値（ＲＣＶ）が「０」でない（！＝０）間は、リクエスト信号（ＲＥＱ）を直ちに送出し続けることができる。
これにより、調停待ち時間が長い場合であっても、リクエスト信号（ＲＥＱ）の送出遅れ分を、その後に取り戻すことができることになる。

一方、アービタ３１の調停待ち時間が非常に長い場合であっても、リクエスト信号（ＲＥＱ）をいつまでも直ちに送出できるのではない。すなわち、グラント信号（ＧＮＴ）を受け取る毎にカウンタ１２２がカウントダウンし、リクエスト制御値（ＲＣＶ）が「０」に達すると、タイマ設定値（ＴＩＭ）に応じた遅延時間をもってリクエスト信号（ＲＥＱ）を送出する。
以上述べたように、カウンタ１２２のカウントアップおよびカウントダウンの動作により、アービタ３１の調停待ち時間によらず、割り当てられたバンド幅に応じたタイマ設定値（ＴＩＭ）をもって、リクエスト間隔を平均化させることができる。すなわち、一時的に調停待ち時間が長くなっても、ある一定の期間ではリクエスト間隔が一定であるとして見ることができる。

具体的には、ある時刻ｔにおいて、下記（Ｉ）式を満足する場合にはそのバスマスタがリクエストしていると判断でき、最終的にはツリー構造の一時的変化を判断できるようになるので、ツリー構造によって割り当てられるバンド幅以上のバンド幅をリクエストするバスマスタのデータ転送を保証することができるようになる。

（繰り下げ(t／ＴＩＭ＋１) − ΣＧＮＴ）！＝ ０ ・・・（Ｉ）

ここで、繰り下げ(t／ＴＩＭ＋１)は、ＴＩＭ間隔でリクエストする式である。式の中で＋１をしているのは、システム全体でのリクエストのもっとも集中するとき、すなわち各バスマスタのリクエスト周期の位相が合い一斉にリクエストする時刻をt=0としている。
また、リクエスト間隔を等間隔に制御することで、他のバスマスタへの影響を小さくすることができる。

次に、図３を参照して述べたリクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）において、カウンタ群（カウンタ１１１およびカウンタ１２２）のリセットについて説明する。
リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）の各カウンタは、以下の（１）および（２）の観点を考慮してリセット機能を有している。
（１）バスマスタが動作していない場合に、カウンタ１２２をカウントアップしてしまうと、その後に動作を開始する直後のリクエスト間隔を制御できなくなる。
（２）ＦＩＦＯバッファが一杯になった場合に、カウンタ１２２がカウントアップしてしまうと、その後のリクエスト間隔を制御できなくなる可能性がある。

本実施形態においては、リセット条件を以下に説明するように設定する。
なお、図３においてリセット信号をｔｉｍ＿１ｓｅｔと称している。そして、カウンタ群をリセットする際には、クライアントからコマンド（ＣＭＤ）が与えられた直後は直ちにリクエストができるようにするため、図３に示すように、リセット信号（ｔｉｍ＿１ｓｅｔ）に応じてカウンタ１２２を「１」にセットする。

第１のリセット条件として、先ず、バスマスタが「動作中（ＯＰＧ）でない」場合に、カウンタ群のリセットを行う。
すなわち、ＦＩＦＯバッファ内においてデータ転送コマンド（コマンド）に対する処理が完全に終了した時、具体的には、あるコマンドに対する処理が終了し、その次のコマンドがまだ与えられていない場合に、バスマスタが「動作中（ＯＰＧ）でない」と判断する。

上述したように、リセットに際し、カウンタ１２２を「１」にセットするが、前のコマンドの処理の後、短期間だけ「動作中でない」状態になり、カウンタ１２２が「１」にセットされると、その直後に次のコマンドが来た場合にすぐリクエストが出ることになり、コマンド間隔が保証できなくなる。
したがって、コマンドの処理が完全に終了した時にリクエスト制御値（ＲＣＶ）が「１」以上の場合には「１」に固定する。また、リクエスト制御値（ＲＣＶ）が「０」である場合には、「１」になるタイミングまで待ち、「１」に固定することが望ましい。
なお、図３では、ゲート回路１１３、判定回路１１４およびＡＮＤ回路１１５により上述した処理がなされる。

第２のリセット条件として、ＦＩＦＯバッファに空き容量がない場合（ＦＵＬＬ）に、カウンタ群のリセットを行う。
すなわち、ＦＩＦＯバッファの制御としてＦＩＦＯバッファに１パケット分の空き容量がない場合にリクエストを止めなければならないが、その間にカウンタ１２２をカウントアップすると、その後のリクエスト間隔がクライアントのデータ転送レートのむらに依存してしまうことになる。

図４は、リクエスト間隔がクライアントのデータ転送レートに依存する場合について説明するための図であり、（ａ）はカウンタ１２２のカウント動作を、（ｂ）はリクエスト信号（ＲＥＱ）のタイミングを、それぞれ示す。図４は、たとえば、ＦＩＦＯバッファが８パケット分ある場合に、クライアントからのコマンドが１６パケット分である時の処理を示している。

時刻ｔ１の時点で、ＦＩＦＯバッファが一杯となり、その後、クライアントがＦＩＦＯバッファのデータを引き抜かないため、時刻ｔ１からｔ２の間、バスマスタは、リクエスト信号（ＲＥＱ）を送出しない。また、その間は、カウンタ１２２のカウント動作が行われているので、リクエスト制御値（ＲＣＶ）が増加している。
そして、時刻ｔ２の時点から、クライアントがＦＩＦＯバッファのデータの引き抜きを開始すると、リクエスト制御値（ＲＣＶ）が大きな値となっているので、早い転送レートでリクエスト信号（ＲＥＱ）を送出し、タイマ設定値（ＴＩＭ）のカウント動作によってはリクエスト信号（ＲＥＱ）の送出を抑制することができない。
時刻ｔ３になり、ある程度のデータの引き抜きがなされると、リクエスト制御値（ＲＣＶ）が適切なレベルとなり、リクエスト信号（ＲＥＱ）の送出タイミングがタイマ設定値（ＴＩＭ）に応じたタイミングに抑制される。すなわち、タイマが効き始める。

以上、図４を一例として述べたように、ＦＩＦＯバッファの空き領域がなく、かつ、リクエスト制御値（ＲＣＶ）がある程度大きな値となっている場合には、その後にＦＩＦＯバッファからデータが一気に引き抜かれると、タイマが効かず、クライアントのデータ引き抜きレートに応じたリクエスト間隔となってしまうのである。

この不都合を防止するためには、ＦＩＦＯバッファの空き容量がない間は、リクエスト制御値（ＲＣＶ）を「１」以上に蓄積しなければよい。
すでに述べたように、本来的にカウンタ１２２をカウントアップする理由は、調停の待ち時間分に起因するリクエスト信号（ＲＥＱ）の送出の遅れを後で取り戻すためであって、クライアントがＦＩＦＯバッファからデータを引き抜かないためリクエスト間隔が長引いた場合に、カウントアップする必要はない。
また、カウントアップする必要がある場合であっても、リクエスト間隔にむらが出るということは、ツリー構造の変化を見積もることができなくなる可能性があり、システム全体のデータ処理能力に影響を与えるため、個別に、より大きなバンド幅に対応できるタイマを設定したり、ＦＩＦＯバッファを増やすことで対応すべきである。
したがって、ＦＩＦＯバッファの空き容量がない間にリクエスト制御値（ＲＣＶ）が「１」以上の場合には「１」に固定する。また、リクエスト制御値（ＲＣＶ）が「０」である場合には、「１」になるタイミングまで待ち、「１」に固定することが望ましい。
なお、図３では、ゲート回路１１３、判定回路１１４およびＡＮＤ回路１１５により上述した処理がなされる。

次に、バスマスタ２の動作について、添付図面を参照して説明する。
図５は、バスマスタ２の動作を示すタイミングチャートの一例であり、（ａ）はＦＩＦＯバッファ１０のデータ量（ＦＩＦＯ）を、（ｂ）はカウンタ１１１のカウント動作（ＣＴＲ）を、（ｃ）はリクエスト制御値（ＲＣＶ）を、（ｄ）はクライアントからのデータ転送コマンド（ＣＭＤ）を、（ｅ）はクライアントからのデータイネーブル（ＤＥＮ）を、（ｆ）はリクエスト信号（ＲＥＱ）を、（ｇ）はグラント信号（ＧＮＴ）を、それぞれ示す。

図５では、時刻ｔ０で、クライアントからデータ転送コマンドが送出され、バスマスタ２は、そのコマンドを複数のパケットに分割し、パケット毎にリクエスト信号（ＲＥＱ）を生成してアービタ３１に対して出力する。
時刻ｔ０から時刻ｔ１にかけて送出されたリクエスト信号（ＲＥＱ）が調停され、グラント信号（ＧＮＴ）が与えられると、（ａ）に示すように、徐々にＦＩＦＯバッファにデータが蓄積される。

ここで、上記前者リセットは、時刻t0までの間に機能し、ＲＣＶの値が「１」に固定される。これによりコマンド（ＣＭＤ）が来た直後にＲＥＱを出し、時刻ｔ０から時刻ｔ１にかけて、タイマにコントロールされて、ＲＥＱを出すことが分かる。

時刻ｔ１になると、ＦＩＦＯバッファに１パケット分の空き容量がなくなり、ＦＩＦＯバッファの制御の必要上リクエストを止める。時刻ｔ１から時刻ｔ３まで、ＦＩＦＯバッファに1パケット分の空き容量がなく、ＲＥＱは止まり続ける。

ここで、上記後者リセットが機能し、リクエスト制御値（ＲＣＶ）が「１」以上の値であれば、リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）のカウンタ群はともにリセットされる。これにより、データの引き抜きが行われる時刻ｔ２以降、仮にデータ転送レートにむらがあり、バンド幅以上の割合でデータの引き抜きが行われても、タイマにコントロールされてＲＥＱを出すことが保証される。
仮にカウンタ群がリセットされずにＲＣＶの値が大きくなると、ＦＩＦＯバッファに空きがあればＲＥＱが出せるようになり、クライアントがバンド幅以上の割合でデータの引き抜きを行うと、そのままそのレートでＲＥＱが出ることになり、タイマによる制御が利かなくなる。したがって、カウンタ群をリセットすることで、かかる不都合を回避している。

なお、図では、データ転送レートが一定の場合を示しており、時刻ｔ３以降、ＦＩＦＯバッファの空き容量がなくなるとき（ｆｕｌｌ）、リクエスト制御値（ＲＣＶ）は「０」となり、ＦＩＦＯバッファに空き容量が発生すると、リクエスト制御値（ＲＣＶ）は「１」以上となる。この結果、図中に円で示したように、ＦＩＦＯバッファのデータ量が一杯となるタイミングと、リクエスト制御値（ＲＣＶ）が「０」となるタイミングが一致する。

上述のように、データ転送レートが一定のクライアントの場合、一旦ＦＩＦＯバッファが一杯（ｆｕｌｌ）になると、クライアントのデータ転送レートに応じた動作となるので、本発明は、たとえば、リード用クライアントが初めてバスマスタに対してデータ転送コマンドを送出し、ＦＩＦＯバッファが空の状態からデータ蓄積を開始する時からＦＩＦＯバッファが一杯になるまでの間（図５で時刻ｔ０からｔ１まで）において、特に、リクエスト間隔をタイマ設定値（ＴＩＭ）に応じた値に平均化させる効果が高いということが言える。

一方、クライアントによっては、比較的短い期間でデータ転送レートが一定ではない場合がある。本発明は、かかる場合にリクエスト間隔を平均化させる効果が高い。
たとえば、メモリ上のデータに基づいて画像表示を行うクライアントは、水平方向、垂直方向にブランク期間があるため、データ転送レートが実際には一定ではない。すなわち、そのブランク期間は、ＦＩＦＯバッファからデータを引き抜かないので、そのブランク期間を含めると、データ転送レートは一定ではなく、メモリバスの上ではバンド幅にむらがあるように見えてしまう。
このような場合でも、バスマスタ２は、タイマによってリクエスト間隔を平均化するので、メモリバス上のバンド幅にむらがないものと見ることができる。

一部の複雑なクライアントのデータ転送レートのむらがそのままリクエストに影響してしまうと、上述したようにツリー構造の変化を見積もることが困難になるうえ、必要なＦＩＦＯバッファの容量が増大する。
したがって、データ転送レートのむらのあるクライアントのバスマスタは、個別にＦＩＦＯバッファの容量を増加させて対応することで、必要なＦＩＦＯバッファ容量を効率的に見積もることができる。図６は、この考え方を模式的に表した図である。
図６は、リードクライアントにおいて、時間に応じてＦＩＦＯバッファに蓄積されるデータとの関係を示し、（ａ）は、リクエストのタイミングにむらがある複雑なクライアントの場合、（ｂ）は、タイマによりリクエスト間隔を抑制されたクライアントの場合である。また、（ｃ）は、合計での必要なＦＩＦＯバッファ容量を示す。

図６において、システム全体では、（ｂ）に示すように、タイマによりリクエスト間隔が抑制され、タイマ設定値（ＴＩＭ）に応じたＴＩＭ＿ｒａｔｅの割合で、ＦＩＦＯバッファにデータが蓄積されるが、一部の複雑なクライアントのデータレートは、ＴＩＭ＿ｒａｔｅに応じたデータの蓄積がなされない。
かかる場合には、（ｃ）に示すように、２つのバッファ容量ｄｉｆｆ１およびｄｉｆｆ２の合計を必要なＦＩＦＯバッファ容量として見積もることができる。

なお、今までリードのクライアントを中心に述べてきたが、ライトのクライアントについても、本発明を適用することできる。
ライトのクライアントの場合には、始めの１パケット分のデータがＦＩＦＯバッファに書き込まれないと、リクエストをしない点だけがリードのクライアントの場合と異なる。このため、リードのクライアントと異なり、データ転送レートが一定であれば、タイマを持つ必要が無い。
しかし、データ転送レートにむらがある場合には、本発明が有効に機能する。また、理論上データ転送レートにむらがない場合でも、実際上何かの不具合で暴走し始めた場合の保険として本発明は有効に機能する。

以上述べたように、本実施形態に係るデータ処理装置によれば、調停の待ち時間の間もタイマ設定値（ＴＩＭ）をカウントし、調停待ち時間がタイマ設定値（ＴＩＭ）より長くなった場合には、その分リクエスト制御値（ＲＣＶ）をカウントアップし、グラント信号（ＧＮＴ）を受け取ると、カウントダウンし、リクエスト信号（ＲＥＱ）の値が「１」以上の場合には、タイマ設定値（ＴＩＭ）によらず直ちにリクエスト信号（ＲＥＱ）を送出する。これにより、調停待ち時間に依存せずに、バンド幅から割り当てられたタイマ設定値（ＴＩＭ）通りにアービタ３１に対してリクエスト信号（ＲＥＱ）を送出することができ、精度の高いバス保証を可能とする。
また、各バスマスタが持つべきＦＩＦＯバッファの容量をマージンを考慮せず見積もることができるので、回路規模の小型化および低コスト化を図ることができる。

本実施形態に係るデータ処理装置によれば、タイマ設定値（ＴＩＭ）に基づいて、リクエスト間隔をバンド幅相当の間隔に正確に抑制することができるので、アービタとしてツリー構造のラウンドロビンアービタを適用した場合に、ツリー構造上割り当てられる以上のバンド幅を要求するバスマスタを保証することができると同時に、ＦＩＦＯバッファ容量の正確な見積もりが可能となる。

本発明の一実施形態であるデータ処理装置の一構成例である。 実施形態に係るバスマスタの構成を示す回路ブロック図の一例である。 リクエスト出力制御部（ＲＥＱ＿ＣＴＲＬ）を構成するタイマカウンタ１１およびリクエスト制御値生成部１２の回路ブロック図の一例である。 リクエスト間隔がクライアントのデータ転送レートに依存する場合について説明するための図である。 実施形態に係るバスマスタの動作を示すタイミングチャートの一例である。 リードクライアントにおいて、時間に応じてＦＩＦＯバッファに蓄積されるデータとの関係である。 ラウンドロビンアービタのツリー構造の一例である。 リクエストを同じ間隔で行う場合と、リクエストを同じ間隔で行わない場合とで、ＦＩＦＯバッファに与える影響を説明するための図である。

符号の説明

１ａ，１ｂ，１ｃ，１ｄ…クライアント、２，２ａ，２ｂ，２ｃ，２ｄ…バスマスタ、３…メモリコントローラ、３１…アービタ、４…メモリ、１０…ＦＩＦＯバッファ、１１…タイマカウンタ、１２…リクエスト制御値生成部、１３…コマンドバッファ、１４…パケット分割部、１５…リクエスト生成部、１６…ＡＮＤ回路。

Claims (5)

1. それぞれバッファを含む複数のバスマスタと、
   データ転送要求を調停し、前記複数のバスマスタの中からデータ転送を許可したバスマスタに対して、メモリバスへのアクセスを許可するアービタと、
   を有し、
   前記複数のバスマスタのうち少なくとも一のバスマスタは、タイマによりデータ転送要求を行うタイミングが管理され、
   第１のデータ転送要求に対する前記アービタの調停が前記タイマの設定時間を経過する回数をカウントし、当該カウント値に応じて、前記第１のデータ転送要求に続く第２のデータ転送要求以後の複数のデータ転送要求を、前記タイマに関わらず直ちに行う
   データ処理装置。
2. 前記一のバスマスタは、
   前記アービタからデータ転送要求に対する許可が与えられる毎に、前記カウント値を減ずる
   請求項１記載のデータ処理装置。
3. 前記一のバスマスタは、データ転送要求を、所定量のデータに対応する複数のデータ転送要求に分割して行い、
   バッファが前記所定量のデータを格納可能な数を、前記カウント値の上限とする
   請求項１記載のデータ処理装置。
4. 前記一のバスマスタは、
   すべてのデータ転送要求に対して前記アービタより許可が与えられると、前記カウント値をリセットし、または、前記カウント値が「１」以上である場合に「１」に固定する
   請求項３記載のデータ処理装置。
5. 前記一のバスマスタは、
   バッファがオーバーフローまたはアンダーフローするためにデータ転送要求を行うことができない間は、
   前記カウント値が「１」以上である場合に「１」に固定する
   請求項４記載のデータ処理装置。

Images