JP2009266152A - コントローラ、ハードディスクドライブおよびコントロール方法 - Google Patents

Abstract

【課題】メモリ周辺だけでなくドライブ全体としての状況変化にリアルタイムに対応して、共有資源の利用効率を向上する。
【解決手段】このデータ転送システムは、ホスト９に接続されたハードディスクドライブ２を有する。ハードディスクドライブ２は、ＨＤＣ３とディスクユニット８を有する。ＨＤＣ３は、ホスト９およびディスクユニット８からアクセスされるＤＲＡＭ７０と、ＤＲＡＭ７０にアクセスするためのリクエストを出力するとともに、リクエストがあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予値を出力する複数のリクエスト発生ユニット１１，２１，３５と、これらのリクエスト発生ユニット１１，２１，３５から入力された猶予値どうしを比較して、猶予が少ないリクエストにアクセス権を与えるリクエストアービター４０とを備える。
【選択図】図１

Description

本発明は、例えばハードディスクドライブ、画像処理装置、ＤＶＤプレーヤなどの電子機器に用いるコントローラ、ハードディスクドライブおよびコントロール方法に関する。

一般に、ハードディスクドライブは、データをハードディスクに書き込んだり読み出す前に内蔵された一時格納用のメモリなどの共有資源にデータを一時的に蓄積し、この共有資源が接続されたバスを優先的に使用する権利（バス優先権）を獲得するためのリクエストを調停するバス制御機能を有している。

従来のバス制御技術としては、例えば一時的にデータを格納する格納メモリのデータ量と、複数の要求元が必要とするデータ転送速度とに応じてバス優先権を切り換える技術が公開されている（例えば特許文献１参照）。

ところで、ハードディスクドライブの場合、ドライブが接続されたホストコンピュータがポーズ状態になることや、駆動するディスク上のサーボセクタの位置にヘッドが達したときにデータ転送が中断することがある。
特開２００６−９９４７３号公報

しかしながら、上記従来の技術では、一時格納用のメモリのデータ量とデータ転送速度に起因したパラメータでバス優先権を決めているため、例えばホストコンピュータからデータ転送のポーズがかかるといった外部要因やディスクのサーボの影響などの内部要因でデータ転送が中断してもバス優先権が他に移らず、他のリクエストが待たされ続けることになり、その間、一時格納用のメモリなどの共有資源の利用効率が低下するという問題があった。

本発明はこのような課題を解決するためになされたもので、共有資源の利用効率を向上することのできるコントローラ、ハードディスクドライブおよびコントロール方法を提供することを目的とする。

上記の課題を解決するために、本発明のコントローラは、一つ以上の機器からアクセスされる共有資源と、前記共有資源に前記機器がアクセスするためのリクエストを生成するとともに、前記リクエストがあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予値を出力する複数のリクエスト発生ユニットと、前記複数のリクエスト発生ユニットからの複数のリクエストおよび猶予値が入力されたとき、前記猶予値どうしを比較して、猶予が少ないリクエストに前記共有資源へのアクセス権を与える調停ユニットとを具備する。

本発明のハードディスクドライブは、請求項１記載のコントローラにより駆動されるハードディスクユニットを具備する。
本発明のコントロール方法は、一つ以上の機器から共有資源にアクセスするためのリクエストと、前記リクエストがあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予値とを発生し、前記複数のリクエストおよび猶予値が発生したときに、前記猶予値どうしを比較して、猶予が少ないリクエストに前記共有資源へのアクセス権を与えることを特徴とする。

本発明によれば、メモリ周辺だけでなくドライブ全体としての状況変化に迅速に対応して、共有資源の利用効率を向上することができる。

以下、本発明の実施の形態について図面を参照しながら説明する。図１は本発明の一実施形態に係るデータ転送システムの構成を示すブロック図である。

図１に示すように、このデータ転送システム１は、ハードディスクドライブ２とこのハードディスクドライブ２が接続されたホストコンピュータ９（以下「ホスト９」と称す）とを有している。

なお、図中において、太線はデータの流れを示し、白地が入った線は制御信号（コントロールコマンド、リクエストなど）または情報（ステータス）等を示す。

ホスト９は、この例においては、ハードディスクドライブ２に対してデータ転送要求をかける要求元となる。

ハードディスクドライブ２は、コントローラの一つとしてのハードディスクコントローラ３（以下「ＨＤＣ３」と称す）と、ハードディスクユニット８（以下「ディスクユニット８」と称す）とを有している。

ハードディスクドライブ２は、ホスト９からのデータ転送要求に対してディスクユニット８に記憶されたデータを読み出してホスト９へ送る。

ＨＤＣ３は、ＦＩＦＯバッファメモリ１２（以下「ＦＩＦＯ１２」と称す）を介してデータを要求元の機器（ディスクユニット８など）へ供給する第１回路群１０と、ＦＩＦＯバッファメモリ２２（以下「ＦＩＦＯ２２」と称す）を介してデータを要求元の機器（ホスト９など）へ供給する第２回路群２０と、セントラル・プロセッシング・ユニット３０（以下「ＣＰＵ３０」と称す）と、プログラムデータを先読みするためのキャッシュであるＳＲＡＭ３１と、リクエスト調停ユニットとしてのリクエストアービター４０と、共有資源の一つであるダイナミック・ランダム・アクセス・メモリ７０（以下「ＤＲＡＭ７０」と称す）と、ホスト９とシリアルＡＴＡケーブル（ＳＡＴＡケーブル）及びＳＡＴＡインターフェースボードなどのインターフェースで接続されるインターフェースコントローラ６１を含むデータ処理用の回路群（図示せず）と、ディスクユニット８とインターフェースバス（内部バス）を介して接続されたインターフェースコントローラ５１を含むデータ処理用の回路群（図示せず）とを有している。

ディスクユニット８は、ヘッド８１、ランプ８２、ボイスコイルモータ８３、ディスク８４、スピンドルモータ８５、ヘッドアンプ８６、モータ駆動部（モータドライバー）８７などを有している。ディスクユニット８は、ＨＤＣ３により駆動制御される。

インターフェースコントローラ５１，６１は、それぞれのインターフェースからのデータを処理する回路群の中の一つであり、この他の回路群としては、例えばリードチャネル回路、誤り訂正回路、デコード回路…などがある。

インターフェースコントローラ５１は、内部バスを通じて行われるディスクユニット８との通信でディスクユニット８の動作状況（ヘッド８１がデータライト中かデータリード中かサーボセクタに入ったかといったディスクユニット８の状態）を検出し、検出された状態に応じた係数（動作状況係数Ａ）を第１回路群１０へ通知（伝達）する。このインターフェースコントローラ５１は、ディスクユニット８とのインターフェースも兼ねる。

第１回路群１０は、リクエスト発生ユニット１１と、ＦＩＦＯ１２とを有している。この例では、説明をわかりやすくするために第１回路群１０は、ディスクユニット８に対してデータリードの処理を行うものとする。リードされたデータは、いったんＤＲＡＭ７０に格納される。したがってリクエスト発生ユニット１１は、ＤＲＡＭ７０に対するデータライトのリクエストを発生する。

ＦＩＦＯ１２へデータを供給する供給元（この場合、ディスクユニット８）からの、その時点における最速のスループット：α Byte/s、ＦＩＦＯ１２の残りバイト数：ａおよびライトデータが供給されるデータ供給元とのインターフェースにおける動作状況係数：Ａとすると、リクエスト発生ユニット１１は、ａ／α×Ａという計算式で猶予度を求め、計算結果の猶予度の値をリクエストアービター４０へ常に出力する。上記した猶予度を求める計算式は一例であり、他にも猶予度の求め方はさまざま考えられる。

ＦＩＦＯ１２は、入力されたデータを順に格納し、その順で出力する先入れ先出しのバッファメモリである。つまりＦＩＦＯ１２は、ディスクユニット８などの機器から供給されるデータを順次バッファリングしてその順に出力するバッファである。

インターフェースコントローラ６１は、ＳＡＴＡインターフェースを通じて行われるホスト９との通信でホスト９の通信状況（ビジー状態かポーズ状態（ウェイト状態）か転送終了状態かなどといったホスト９の状態）を検出し、検出された状態に応じた係数（動作状況係数Ｂ）を生成して第２回路群２０へ通知（伝達）する。ビジー状態とは実際にデータを転送している状態を示す。

一例としては、例えばビジー状態ならば動作状況係数Ｂ＝「１」、ポーズ状態ならば動作状況係数Ｂ＝「３」、転送終了ならば動作状況係数Ｂ＝「５」などとった値をインターフェースコントローラ６１に予め設定しておくものとする。

第２回路群２０は、リクエスト発生ユニット２１と、ＦＩＦＯ２２とを有している。この例では、説明をわかりやすくするために第２回路群２０は、ホスト９からの要求によりディスクユニット８に対してデータリードのリクエストを発生するものとする。リクエスト発生ユニット２１は、ディスクに対するデータリードのリクエストを発生する。

ＦＩＦＯ２２からデータを持って行く送信先（この場合、ホスト９）の、その時点における最速のスループット：β Byte/s、ＦＩＦＯ２２に現在存在している有効バイト数：ｂ、およびリードデータが提供されるデータ提供先の機器（ホスト９）とのインターフェースにおける動作状況係数Ｂとすると、リクエスト発生ユニット２１は、ｂ／β×Ｂという計算式で猶予度を求め、計算結果の猶予度の値をリクエストアービター４０へ常に出力する。

ＦＩＦＯ２２は、入力されたデータを順に格納し、その順で出力する先入れ先出しのバッファメモリである。つまりＦＩＦＯ２２は、ホスト９などの機器へ供給するデータを順次バッファリングしてその順に出力するバッファである。

ＣＰＵ３０は、リミット値記憶部３２と、カウンタ３３と、タイミングコントローラ３４と、リクエスト発生ユニット３５とを有している。

リミット値記憶部３２には、ＤＲＡＭ７０をリフレッシュする限界の時間値（リミット値）が記憶されている。この例では、ＤＲＡＭ７０のリフレッシュタイミングが例えば１０μｓｅｃであるものとすると、リミット値はそれよりも少ない値、例えば９μｓｅｃであり、この値がリミット値記憶部３２に記憶されている。カウンタ３３は、０〜９μｓｅｃを繰り返しカウントする。

タイミングコントローラ３４は、リクエストを発生させるタイミング信号をリクエスト発生ユニット３５に与える。例えば９μｓｅｃ毎にタイミング信号を出力する。

リクエスト発生ユニット３５は、リミット値記憶部３２からリミット値を読み出して、カウンタ３３によりカウントされた値を引き算して猶予度（given Time）を求め、猶予度の値を常にリクエストアービター４０へ出力する。

また、リクエスト発生ユニット３５は、タイミングコントローラ３４からタイミング信号が与えられたときに、リクエスト（例えばリフレッシュサイクルなどといったコマンド）をリクエストアービター４０へ出力する。

ＣＰＵ３０は、ディスクユニット８を制御してデータ転送などを行う。またＣＰＵ３０は、ＤＲＡＭ７０に対して例えば１０μｓｅｃ毎にリフレッシュコマンドを発行し、ＤＲＡＭ７０をリフレッシュする。このリフレッシュ動作はシステムにとって重要であり、リフレッシュタイミングを逃した場合、システムの動作に影響が最も及ぶため、リクエスト発生ユニット３５から受け取った猶予度の値が小さい場合は最も優先すべきリクエストとなる。

リクエストアービター４０は、一つ以上のリクエスト発生ユニット１１，２１，３５からリクエストとその猶予度が入力されたとき、猶予度の数値（猶予値）どうしを比較して、猶予が少ないリクエストを選定し、そのリクエストの発行元にＤＲＡＭ７０へのアクセス権を与えるため、アクセス許可信号（グラント：Gnt）を、選定したリクエストの発生元へ返信する。

このデータ転送システムの場合、リクエストの発生元のタイプを大別すると３つに分けられる。

（タイプＩ）第１回路群１０
リクエストが、ＤＲＡＭ７０へのライトリクエストであり、リクエストの発生元がデータの送信用のＦＩＦＯ１２を持っているタイプである。この場合、第１回路群１０のリクエスト発生ユニット１１は、ＦＩＦＯ１２の残りバイト数ａを、ディスクユニット８からＦＩＦＯ１２へのそのときの最速のスループットαの値で割り算し、その値に動作状況係数Ａを掛け算することで猶予度を算出し、その猶予度の値をリクエストアービター４０に送る。

（タイプII）第２回路群２０
リクエストが、ＤＲＡＭ７０へのリードリクエストであり、リクエストの発生元がデータ受信用のＦＩＦＯ２２を持っているタイプである。この場合、第１回路群２０のリクエスト発生ユニット２１は、ＦＩＦＯ２２に現在存在している有効バイト数ｂを、ＦＩＦＯ２２からホスト９へのそのときの最速のスループットβで割り算し、その値に動作状況係数Ｂを掛け算することにより猶予度を算出し、その猶予度の値をリクエストアービター４０に送る。

なお、上記タイプＩとタイプIIは、いずれもＦＩＦＯを用いるタイプであり、各回路群のリクエスト発生ユニットとしては一つのハードウェアとしてまとめて実現することも可能である。

（タイプIII）ＣＰＵ３０
ＦＩＦＯなどは存在しないが、リクエストアービター４０へ送ったリクエストが、一定時間以内に受け付けられることを期待するリクエストである。この場合に、ＣＰＵ３０のリクエスト発生ユニット３５は、リクエストが受け付けられるべき時間から現在時刻を引き算して猶予値を算出し、その値をリクエストアービター４０に送る。つまり猶予値は、リクエストが受け付けられるべき時間−現在時刻で求めることができる。

すなわち、ＣＰＵ３０の場合、ある時間以内にリクエストがリクエストアービター４０に受け付けられない場合に、システム（ハードディスクドライブ２全体）に影響を与える恐れのあるリクエストを発行する。

タイプIIIにおいて、ＤＲＡＭリフレッシュの例以外の例としては、例えばＳＲＡＭ３１などにデータをキャッシュする機構や、ＣＰＵ３０のコードキャッシュなどもあげられる。ＣＰＵ３０のコードキャッシュでは、ＣＰＵ３０のリードアドレスポインタと、キャッシュされている最後のアドレスまでの差が、ＦＩＦＯ有効バイト数とみなすことができ、この場合は、タイプIIと同様と考えられる。

以下、図２〜図４を参照してこのデータ転送システムの動作を説明する。まず、機器の状況計数を得る一つの例として、ディスクユニット８のデータリード動作の例について説明する。

図２に示すように、例えばディスク８４には、サーボセクタ９２とディスクリード対象（ターゲット）のセクタ９３が設けられている。この例では、ターゲットのリードセクタ９３は、１〜３，６〜１０とし、ヘッド８１がこの外周位置のセクタ９２，９３を読み取るものとする。

図３に示すタイミングチャートにおいて、（Ａ）はサーボゲートの開閉に伴う信号の変化を示す。（Ｂ）はリードゲートの開閉に伴う信号の変化を示す。（Ｃ）はディスクインターフェースバス（内部バス）上のデータを示す。（Ｄ）は状況計数の変化を示す。状況計数は例えばデータリード中が「１」、データリード中断中が「３」、データリード終了後が「５」などとする。（Ｅ）はＦＩＦＯ出力データバスのデータを示す。

ディスク８４の回転でサーボセクタ９２上にヘッド８１がくると、ＣＰＵ３０は、サーボゲートを開き（タイミングチャート（Ａ）の信号がＨＩになる）、サーボセクタ９２上に記録されている位置情報を読み取る。このときの動作状況をインターフェースコントローラ５１が監視している。

ＣＰＵ３０は、読み取った位置情報を基に、ヘッド８１の位置を感知し、ターゲットのリードセクタ９３がある位置にあわせてリードゲートを開く（（Ｂ）の信号がＨＩになる）。

インターフェースコントローラ５１は、この動作に合わせて、リードゲートが開くべきタイミングの少し手前の位置で状況係数を変化させる。

具体的には、図３のタイミングチャートの、例えば符号９５のタイミングでリードゲートが開き、ディスク８４からデータが読み取られるが、このタイミングの少し手前の符号９６の位置で状況係数“３”を“１”に変化させる。

なお、処理を迅速化するためには、リクエスト発生ユニット１１，２１において、スループットに応じた猶予度を都度計算するのではなく、猶予度を予め正規化しておき、動作状況計数Ａ，Ｂをかけ算するだけ、つまり割り算（除算）を行わなくても良いようにしておくことで、さらに処理を高速化できる。

複数のリクエスト発行元のうち、１つ目のものの最速のスループットが30MB/s、２つ目のものの最速のスループットが60MB/s、３つ目のものの最速のスループットが120MB/sといったスループットがそれぞれあったものとすると、ＦＩＦＯ段数×｛4, 2, 1｝がそれぞれのリクエスト発行元の猶予度となる。

動作状況係数Ａ，Ｂは、ＦＩＦＯのインターフェースでなく、データ送受信の大元（ホスト９やディスクユニット８）のインターフェースの動作状態に応じて、猶予度に対し演算を加えるための係数である。

動作状況係数Ａ，Ｂは、例えばディスクユニット８において、ヘッド８１の位置がターゲットセクタに到達してはじめてディスクユニット８へのデータ転送が行われる。また、１セクタ転送中であったとしても、例えばサーボ領域ではデータ転送が行われない。

また、ディスクユニット８では、あるセクタから別のセクタまでリード動作をスキップさせることもある。このように、ＤＲＡＭ７０へリードデータ転送中であっても、ディスクユニット８とのインターフェースではデータ転送を頻繁に、かつ比較的長時間中断していることも多い。

また、ディスクユニット８に対するデータのリード動作が完了した場合、それらはＥＣＣ訂正など処理を終えた後にＤＲＡＭ７０へと転送される。そのレイテンシは非常に大きいが、このような場合、ディスクユニット８からのデータのリード動作が完了していれば、以後のデータの読み出しは行わないので、ＤＲＡＭ７０への転送リクエストを少し余裕をもって処理してもシステムの動作に影響を与えることがない。

このように、インターフェースにおいて実際のデータ転送が中断もしくは完了している場合、ある演算（例えば通常は１倍、ディスクへのデータ転送中の断中は３倍、ディスクへのデータの転送完了後は５倍など）を行う。

これにより、より全体を見渡した大局的な最適化が可能となる。この動作状況係数Ａ，Ｂは、実際のデータの転送状態をそのままリアルタイムに示してもよいが、実際にデータの転送を開始してから、あわててＤＲＡＭ７０へデータ転送を開始したのでは遅い。

そこで、より好適には、データ転送が実際に行われることが予測される時点において少し先んじて係数を変化させるほうがよい。

例えば、ディスク８４からデータをリードしホスト９へ転送する場合、ＨＤＣ１のＣＰＵ３０は、ディスク８４の読み出しセクタ番号であるリードセクタを管理するとともに、現在のヘッド８１がどのセクタ位置にあるかも管理している。

このような場合、インターフェースコントローラ５１は、ディスクのリードを開始する前、あるいはディスクのリードを中断中に、実際に転送を開始する１セクタ程度前に「転送中」であることを示す動作状況計数Ｂをリクエスト発生ユニット１２へ通知する。

リクエストアービター４０において複数のリクエストの中から優先度の高いリクエストの選定を行う処理はさまざまな形態を適用できる。

一例として、もっともシンプルな処理は、それぞれのリクエスト送信元から送られてくる猶予度どうしを比較して、猶予の少ない、つまり猶予度の数値の小さいリクエストにアクセス権を渡すようにする。この場合、リクエストアービター４０は、アクセス権を渡す相手にアクセス許可信号（グラント：Gnt）を返すことでアクセス権を渡し、ＤＲＡＭ７０へのアクセスを許可する。

ここで、図４（Ａ）〜図４（Ｃ）のタイミングチャートを参照してこのデータ転送システムのリクエスト調停動作について説明する。

図４（Ａ）は第１回路群１０（リクエスト発生ユニット１１）からのリクエストに関する信号を示す図であり、図４（Ｂ）は第２回路群２０（リクエスト発生ユニット２１）からのリクエストに関する信号を示す図であり、図４（Ｃ）はＣＰＵ３０（リクエスト発生ユニット３５）からのリクエストに関する信号を示す図である。

図４（Ａ）において、Status_Aはインターフェースコントローラ５１がリクエストアービター４０へ通知したディスクユニット８の状況計数である。Req_Aはリクエスト発生ユニット１１から発行されるリクエストである。FifoCNT_AはＦＩＦＯ１２の残りバイト数ａである。Time_Aはリクエストアービター４０に通知された猶予度である。Gnt_Aはリクエストアービター４０からリクエスト発生ユニット１１へ返信されるアクセス許可信号である。Data_AはＤＲＡＭ７０に転送されるデータである。

図４（Ｂ）において、Status_Bはインターフェースコントローラ６１がリクエストアービター４０へ通知したホスト９の状況計数である。Req_Bはリクエスト発生ユニット２１から発行されるリクエストである。FifoCNT_BはＦＩＦＯ２１の有効バイト数ｂである。Time_Bはリクエストアービター４０に通知された猶予度である。Gnt_Bはリクエストアービター４０からリクエスト発生ユニット２１へ返信されるアクセス許可信号である。Data_BはＤＲＡＭ７０から転送されるデータである。

図４（Ｃ）において、Limit_Cはリミット値記憶部３２から読み出されるリミット値である。ここでは時間ではなく、クロック数として数値（100）を表している。Count_Cはカウンタ３３によりカウントされるカウント値である。この値は0から99まで変化することが可能である。Time_Cはリクエストアービター４０に通知された猶予度である。ここでは単純にリミット値（100）からそのときのカウント値を引き算した値とされる。Req_Cはリクエスト発生ユニット３５から発行されるＤＲＡＭリフレッシュのためのリクエストである。リクエストが受け付けられると、Count_Cは０にリセットされ、再度カウントを始める。Data_CはＤＲＡＭ７０に送られるリフレッシュコマンドである。

リクエスト発生ユニット１１，２１，３５は、ＤＲＡＭ７０へアクセス後、次のアクセスが可能となるタイミング、例えば図中の矢印位置のタイミングＴ１〜Ｔ８でリクエストを発行している。

リクエストアービター４０は、各タイミングＴ１〜Ｔ８で、猶予度どうしを比較し、猶予度が最小の値のものに対してグラント信号（Gnt_A, Gnt_B, Gnt_Cのいずれか,）を発行し、そのリクエストのアクセスを許可する。

これにより、リクエストアービター４０からグラント信号を受けたリクエスト発行元は、実際にＤＲＡＭ７０にアクセスしデータ転送を行う。

この例の場合、タイミングＴ１では、Req_AとReq_B が発行されており、Time_Aが「９」、Time_Bが「３５」のため、リクエストアービター４０は、Gnt_Aを出力する。これにより、Data_AがＤＲＡＭ７０に転送される。

タイミングＴ２では、Req_BとReq_Cが発行されており、Time_Bが「３」、Time_Cが「１９」のため、リクエストアービター４０は、アクセス権を移すようGnt_Bを出力する。これにより、Data_BがＤＲＡＭ７０から転送される。

タイミングＴ３では、Req_AとReq_BとReq_Cが発行されており、Time_Aが「３０」、Time_Bが「１０」、Time_Cが「１６」のため、リクエストアービター４０は、Gnt_Bを出力し、アクセス権を変えない。これにより、Data_Bの転送が継続される。

タイミングＴ４では、Req_AとReq_BとReq_Cが発行されており、Time_Aが「３０」、Time_Bが「１０」、Time_Cが「１２」である。ここでは、タイミングＴ３からタイミングＴ４の間で、Req_AのStatus_Aの値が「１」から「３」に変っており、他よりもTime_Aの値が高く、換言すれば、Req_Aの優先度が低下しているため、リクエストアービター４０は、Gnt_Bを出力し、アクセス権を変えない。これにより、Data_Bの転送が継続される。つまり、Req_Aは、Status_Aの値が「１」に変わり、他のリクエストよりもTime_Aの値が低くなるまでは、アクセスが待たされることになる。

タイミングＴ５では、Req_AとReq_Cが発行されており、Time_Aが「９」、Time_Cが「１０」のため、リクエストアービター４０は、アクセス権を移すようGnt_Aを出力する。これにより、Data_AがＤＲＡＭ７０に転送される。

タイミングＴ６では、Req_BとReq_Cが発行されており、Time_Bが「１０」、Time_Cが動作性能に影響が生じる直前の「８」まで低下しているため、リクエストアービター４０は、アクセス権を即時にReq_Bに移すようGnt_Cを出力する。これにより、Data_CがＤＲＡＭ７０に転送され、リフレッシュが間に合う。

なお、タイミングＴ６以降にReq_Bを発行した後、ＦＩＦＯ２２の有効バイト数であるFifoCNT_Bが「0」、つまり空になっているが、このときホスト９がポーズ状態にあるため、ホスト９へのデータ転送は局所的にはＦＩＦＯエンプティという好ましくない事態が発生しているが、大局的にはハードディスクの性能面ではまったく影響が生じない。

このようにこの実施形態のデータ転送システムによれば、ハードディスクドライブ２の内部の限られた共有資源であるＤＲＡＭ７０へのアクセス許可を得るために、リクエスト発生ユニット１１，１２は、ＦＩＦＯ１１の有効バイト数ｂやＦＩＦＯ１２の残りバイト数ａと各スループットβだけでなく、ホスト９やディスクユニット８の通信状況（動作状況係数Ａ，Ｂ）を加味して要求元それぞれの猶予度を算出してリクエストアービター４０へ送り、またリクエスト発生ユニット３５は、リクエストがリクエストアービター４０によってあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予度（数値）を生成してリクエストアービター４０へ送る。

これにより、リクエストアービター４０は、入力されたリクエストの中から、システムへの悪影響が極力生じないように猶予の少なくなった順にリクエストを選定し、要求元へアクセス許可信号（グラント：Gnt）を返すので、猶予の少なくなった順にＤＲＡＭ７０へアクセスすることができるようになる。また猶予度は数値であり、単純な比較処理で判定できるので、ＤＲＡＭ７０へのアクセス要求のリクエストを効率よく調停することができる。

例えばホスト９がポーズになると、リクエスト発生ユニット１１は、ホスト転送へのリクエストの優先度を相対的に下げる。またディスクユニット８におけるデータ転送が外周側で高速になると、リクエスト発生ユニット１２は、ディスク転送のリクエストの優先度を相対的に上げる一方、サーボセクタ９２の読み取りなどでディスク転送に余裕が生じると、そのときだけはディスクユニット８へのデータ転送の優先度を相対的に下げる。つまり、刻一刻と変化する周囲の状況に迅速に対応し、ＤＲＡＭ７０などの共有資源を効率よく利用することができる。

すなわち、共有資源であるＤＲＡＭ７０やアクセスバス７１、ＦＩＦＯメモリ１２，２２などの周辺だけでなく、ディスクユニット８におけるデータの読み取り状況やホスト９がビジー状態かポーズ状態かなどの動作状況を考慮したドライブ全体またはシステム全体としての状況変化に対応してアクセス権を移すので、共有資源の利用効率を向上することができる。

なお、本願発明は、上記実施形態のみに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形してもよい。また、上記実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の発明を構成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

上記実施形態で説明した猶予度は一例であり、計算がしやすい形で桁数などを変形してもよく、猶予度ではなく、緊急度を示す数値で表現してもよい。また各リクエストに本質的な優先順位がある場合（例えばハードディスクドライブ２においては、ホスト転送よりもディスク転送のほうが優先順位が高い等）、係数を乗算したり猶予度の上限や下限を設けたりすることで優先順位に上下関係を付けてもよい。

また、実施形態以外の既存の調停回路（バスアービター）とリクエスト発生ユニット１１，２１，３５とを組み合わせて使用してもよい。

また、より高度な調停ユニットを実現するために、１回のアクセスバイト数の違いなどで各リクエストの転送時間が異なる場合には、例えば猶予度が下から２番目であるがアクセス時間が短いものを先にアクセスさせてから、猶予度が一番下のものをアクセスさせたほうがよい、という場合があり得る。

このようなアクセスであれば、どちらも破綻しないが、逆に猶予度が１番下のものをアクセスさせると、このアクセス時間が長いために猶予度が下から２番目のものが破綻してしまう、というケースが起こり得る。

このようなケースも考慮し、調停ユニットを構成する場合、調停ユニットは、一旦、猶予度が一番下のリクエスト発行元に仮のアクセス権を与え、そのリクエスト発行元がデータ転送を完了する時刻まで猶予がないリクエストが他に存在すれば、今度はそちらにアクセス権を与えるように構成する。

また、複数のリクエスト発行元のうち、どのリクエスト発行元にアクセス権を与えてもどこかで破綻が生じるような場合には、予め定められた各リクエストに固有の優先度に応じてアクセス権を与えるようにする。

実際に調停ユニットを構成する実装形態としては、各リクエストに対して、それぞれのアクセス時間から、その次のリクエスト受付時間をそれぞれ求め、その時間までに破綻するリクエストが他にあるかどうかをそれぞれのリクエストに対して計算しておき、一番下のリクエストから順に、他に誰も破綻しないというリクエストが存在するまでサーチする。どれも破綻する場合は予め決めておいた優先度で処理してもよいし、そのときの猶予度の数値が一番下のものを処理するようにしてもよい。

なお、上記実施形態では、タイプＩ、タイプII、タイプIIIのリクエスト発生ユニットを一つずつ有する例について説明したが、タイプＩとタイプIII、タイプIIとタイプIII、同じタイプどうし（タイプＩどうし、タイプIIどうし、タイプIIIどうし）を組み合わせて構成する等、さまざまな形態にしてもよい。

また上記実施形態では、ハードディスクドライブの一例について説明したが、共有資源を有するコントローラに、インターフェースを介して要求元の機器を接続したものであれば、例えばカラープリンタなどの画像処理装置、ＤＶＤレコーダ、ＤＶＤプレーヤ、液晶表示装置、テレビジョンチューナなどの家庭用電子機器、コンピュータ、ゲーム機などの情報処理装置にも適用できる。

本発明の一実施形態のデータ転送システムの構成を示す図である。 リード動作時のディスクを示す図である。 （Ａ）はディスクリード動作におけるサーボゲートの開閉信号を示す図である。（Ｂ）はリードゲートの開閉信号を示す図である。（Ｃ）はディスクインターフェースバス（内部バス）上のデータを示す図である。（Ｄ）は状況計数の変化を示す。（Ｅ）はＦＩＦＯ出力データバスのデータを示す図である。 （Ａ）は第１回路群における信号を示す図である。（Ｂ）は第２回路群における信号を示す図である。（Ｃ）はＣＰＵにおける信号を示す図である。

符号の説明

１…データ転送システム、２…ハードディスクドライブ、３…ハードディスクコントローラ（ＨＤＣ）、８…ハードディスクユニット（ディスクユニット）、９…ホストコンピュータ（ホスト）、９…ホスト、１０…第１回路群、１１，２１，３５…リクエスト発生ユニット、１２，２２…ＦＩＦＯバッファメモリ（ＦＩＦＯ）、３０…セントラル・プロセッシング・ユニット（ＣＰＵ）、３２…リミット値記憶部、３３…カウンタ、３４…タイミングコントローラ、４０…リクエストアービター、５１，６１…インターフェースコントローラ、７０…ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ）、７１…アクセスバス、８１…ヘッド、８２…ランプ、８３…ボイスコイルモータ、８４…ディスク、８５…スピンドルモータ、８６…ヘッドアンプ。

Claims (9)

1. 一つ以上の機器からアクセスされる共有資源と、
   前記共有資源に前記機器がアクセスするためのリクエストを生成するとともに、前記リクエストがあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予値を出力する複数のリクエスト発生ユニットと、
   前記複数のリクエスト発生ユニットからの複数のリクエストおよび猶予値が入力されたとき、前記猶予値どうしを比較して、猶予が少ないリクエストに前記共有資源へのアクセス権を与える調停ユニットと
   を具備することを特徴とするコントローラ。
2. 前記機器から供給されるデータを順次バッファリングしてその順に出力するバッファと、
   前記機器と通信し、通信中に、前記機器の動作状態の変化を検出し、検出された動作状態に応じて予め設定された動作状態計数を生成するインターフェースコントローラとを備え、
   前記複数のリクエスト発生ユニットのうちの少なくとも一つは、
   前記共有資源に前記機器がアクセスするためのリクエストを生成するとともに、前記機器から前記バッファへのデータ転送速度と、前記バッファに存在するデータ量または前記バッファの残り容量と、前記インターフェースコントローラにより生成された前記動作状態計数とから猶予値を生成することを特徴とする請求項１記載のコントローラ。
3. 前記複数のリクエスト発生ユニットのうちの少なくとも一つは、
   前記リクエストが、前記共有資源へのライトリクエストの場合、前記バッファの残りバイト数を、前記機器から前記バッファへのその時点の最速のスループットの値で割り算した値に、前記動作状態計数を掛け算することにより猶予値を算出することを特徴とする請求項２記載のコントローラ。
4. 前記複数のリクエスト発生ユニットのうちの少なくとも一つは、
   前記リクエストが、前記共有資源へのリードリクエストの場合、前記バッファからデータの有効バイト数を、前記バッファから前記機器へのその時点の最速のスループットの値で割り算した値に、前記動作状態計数を掛け算することにより猶予値を算出することを特徴とする請求項２記載のコントローラ。
5. 前記複数のリクエスト発生ユニットのうちの少なくとも一つは、
   前記リクエストが、一定時間以内に前記リクエストが受け付けられることを期待するリクエストである場合に、前記リクエストが受け付けられるべき時間から現在時刻を引き算して猶予値を算出することを特徴とする請求項１記載のコントローラ。
6. 前記調停ユニットは、
   前記猶予値が最も低いリクエストに仮のアクセス権を与え、そのリクエストのデータ転送が完了する時刻までに猶予がないリクエストが存在したときに、前記猶予がないリクエストに前記アクセス権を移すことを特徴とする請求項１記載のコントローラ。
7. 前記調停ユニットは、
   どのリクエストにアクセス権を与えたとしてもどこかで破綻が生じる場合に、各リクエスト毎に予め設定された優先順位に従ってアクセス権を与えることを特徴とする請求項１記載のコントローラ。
8. 請求項１記載のコントローラにより駆動されるハードディスクユニットを具備することを特徴とするハードディスクドライブ。
9. 一つ以上の機器から共有資源にアクセスするためのリクエストと、前記リクエストがあとどれくらい受け付けられないとこの装置の動作に影響を与えるかを示す猶予値とを発生し、
   複数のリクエストおよび猶予値が発生したときに、前記猶予値どうしを比較して、猶予が少ないリクエストに前記共有資源へのアクセス権を与える
   ことを特徴とするコントロール方法。

Images