(57)【要約】【課題】記憶装置の性能を向上する。【解決手段】実施形態の記憶装置は、データを記憶する不揮発性記憶媒体と、ホストから受信した複数のコマンドをキューイングして実行し、コマンドに応じて不揮発性記憶媒体への書き込み動作及び読み出し動作を制御するコントローラとを具備する。コントローラは、コマンドの実行に応じて第１の情報と第２の情報をホストに送信し、第１の情報は、送信を開始する前に、コマンドの実行に応じて送信予定数が決められている。そしてコントローラは、第１の情報の送信開始後かつ送信予定数分の送信を完了する前に、第２の情報をホストに送信可能である。【選択図】図１
2017162399.tif 000002
【特許請求の範囲】
【請求項１】
ホストと通信可能な記憶装置であって、
データを記憶する不揮発性記憶媒体と、
前記ホストから受信した複数のコマンドをキューイングして実行し
前記コマンドに応じて前記不揮発性記憶媒体への書き込み動作及び読み出し動作を制御するコントローラと、
を具備し、
前記コントローラは、
前記コマンドの実行に応じて第１の情報と第２の情報を前記ホストに送信し、
前記第１の情報は、送信を開始する前に前記コマンドの実行に応じて送信予定数が決められており、
前記第１の情報の送信開始後かつ前記送信予定数分の送信を完了する前に、前記第２の情報を前記ホストに送信可能である
記憶装置。
【請求項２】
前記第１の情報は前記不揮発性記憶媒体から読み出したデータであり、
前記第２の情報は前記記憶装置の内部状態を示すステータス情報である
請求項１に記載の記憶装置。
【請求項３】
前記ホストと前記不揮発性記憶媒体との間でデータを一時的に格納するバッファをさらに具備し、
前記第１の情報の前記送信予定数は、前記コマンドの実行に応じて前記バッファに格納したデータの数に応じて決められる
請求項２に記載の記憶装置。
【請求項４】
前記ステータス情報は前記複数のコマンドのうちの少なくとも１つのコマンドの実行が完了したことを前記ホストに報告する情報であり、
前記コントローラは、前記複数のコマンドのうちの少なくとも１つのコマンドの実行が完了したことに応じて
前記ステータス情報を前記ホストに送信する
請求項２に記載の記憶装置。
【請求項５】
前記ホストとの通信は全二重通信方式による通信である
請求項２に記載の記憶装置。
【請求項６】
前記ステータス情報は前記データの受信が可能であることを前記ホストに報告する情報であり、
前記コントローラは、前記データの受信が可能になったことに応じて
前記ステータス情報を前記ホストに送信する
請求項５に記載の記憶装置。
【請求項７】
前記コントローラは、
前記第１の情報の前記送信予定数と、
前記コマンドの実行に応じて既に前記ホストに送信した前記第１の情報の送信数との差分が所定の閾値以上のときにのみ
前記第１の情報の送信開始後かつ前記送信予定数分の送信を完了する前に、前記第２の情報を前記ホストに送信する
請求項１に記載の記憶装置。
【請求項８】
さらに複数のホストのいずれかと選択的に通信可能であり、
前記コントローラは、
前記第１の情報と前記第２の情報とが同一の前記ホストに送信されるべき情報であるときにのみ
前記第１の情報の送信開始後かつ前記送信予定数分の送信を完了する前に、前記第２の情報を前記ホストに送信する
請求項１に記載の記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、記憶装置に関する。
【背景技術】
【０００２】
ホストから受信したコマンドをキューイングして実行する記憶装置において、記憶装置の性能を向上させるためには、各コマンド実行に関する情報を適切な順序でホストに送信することが重要であることが知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許第８８６８８０９号明細書
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする課題は、記憶装置の性能を向上させることにある。
【課題を解決するための手段】
【０００５】
上記課題を達成するために、実施形態の記憶装置は、データを記憶する不揮発性記憶媒体と、ホストから受信した複数のコマンドをキューイングして実行し、コマンドに応じて不揮発性記憶媒体への書き込み動作及び読み出し動作を制御するコントローラとを具備する。コントローラは、コマンドの実行に応じて第１の情報と第２の情報をホストに送信し、第１の情報は、送信を開始する前に、コマンドの実行に応じて送信予定数が決められている。そしてコントローラは、第１の情報の送信開始後かつ送信予定数分の送信を完了する前に、第２の情報をホストに送信可能である。
【図面の簡単な説明】
【０００６】
【図１】第１の実施形態の記憶装置の構成を示すブロック図である。
【図２】第１の実施形態の記憶装置中の受信制御部、実行制御部、送信制御部の詳細な構成を示すブロック図である。
【図３】第１の実施形態の記憶装置中の実行管理テーブルの構成を示す図である。
【図４ａ】第１の実施形態の記憶装置が実行するリードコマンドのプロトコルを説明する図である。
【図４ｂ】第１の実施形態の記憶装置が実行するライトコマンドのプロトコルを説明する図である。
【図４ｃ】第１の実施形態の記憶装置が実行するノンデータコマンドのプロトコルを説明する図である。
【図５】第１の実施形態の記憶装置におけるコマンドのキューイング実行を説明する図である。
【図６】第１の実施形態の記憶装置がリードコマンドを実行するときのタイミングチャートである。
【図７】第１の実施形態の記憶装置がリードコマンドとノンデータコマンドをキューイング実行するときのタイミングチャートである。
【図８】第１の実施形態の記憶装置がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【図９】第１の実施形態の記憶装置がリードコマンドとノンデータコマンドをキューイング実行するときの動作を説明する図である。
【図１０】第２の実施形態の記憶装置における全二重通信方式の動作を説明する図である。
【図１１】第２の実施形態の記憶装置がライトコマンドを実行するときのタイミングチャートである。
【図１２】第２の実施形態の記憶装置がリードコマンドとライトコマンドをキューイング実行するときのタイミングチャートである。
【図１３】第２の実施形態の記憶装置がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【図１４】第２の実施形態の記憶装置がリードコマンドとライトコマンドをキューイング実行するときの動作を説明する図である。
【図１５ａ】第３の実施形態の記憶装置がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【図１５ｂ】第３の実施形態の記憶装置がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【図１６】第４の実施形態の記憶装置と複数のホストとの接続形態を説明するブロック図である。
【図１７】第４の実施形態の記憶装置中の実行制御部の詳細な構成を示すブロック図である。
【図１８】第４の実施形態の記憶装置中の実行管理テーブルの構成を示す図である。
【図１９】第４の実施形態の記憶装置がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【発明を実施するための形態】
【０００７】
以下、実施形態の記憶装置を、図面を参照して説明する。なお、以下の説明において、同一の機能及び構成を有する構成要素については、共通する参照符号を付す。
【０００８】
［第１の実施形態］
図１は、第１の実施形態の記憶装置１の構成を示すブロック図である。
【０００９】
記憶装置１は、記憶装置１全体を制御するコントローラ１０、データを記憶する不揮発性記憶媒体２０、ホスト２と不揮発性記憶媒体２０との間でデータを一時的に格納するバッファ３０などからなる。
【００１０】
本実施形態の説明では、ホスト２はＳＡＳ（Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  ＳＣＳＩ）規格のインターフェースをサポートするコンピュータであるが、その他の規格、例えばＳＡＴＡ（Ｓｅｒｉａｌ  ＡＴＡ）規格、ＮＶＭｅ（ＮＶＭ  Ｅｘｐｒｅｓｓ）規格のインターフェースをサポートするコンピュータであってもよい。
【００１１】
コントローラ１０は、例えばＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）として設計される半導体集積回路である。
【００１２】
不揮発性記憶媒体２０としては、例えばＮＡＮＤ型フラッシュメモリや磁気ディスクなどが用いられる。
【００１３】
本実施形態ではバッファ３０はＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）からなるメモリであるが、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）など他の種類のメモリを採用してもよい。また、バッファ３０は、コントローラ１０に内蔵されていてもよい。
【００１４】
コントローラ１０はホスト２との通信を行う通信インターフェース（ＩＦ）部４０、ＦＷ（Ｆｉｒｍｗａｒｅ）を実行し記憶装置１全体の制御を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）５０、ホスト２からの情報の受信を制御する受信制御部１００、ホスト２から受信したコマンドの実行を制御する実行制御部２００、ホスト２への情報の送信を制御する送信制御部３００などから成る。
【００１５】
なお、ＣＰＵ５０はコントローラ１０に内蔵せず、別個の半導体集積回路としてもよい。また、以下の説明においてＦＷにより実行されるとしてある機能の一部又は全部は専用のＨＷ（Ｈａｒｄｗａｒｅ）によっても実行可能であり、ＨＷにより実行されるとしてある機能の一部又は全部をＦＷによって実行することも可能である。
【００１６】
受信制御部１００はホスト２から受信したコマンド及びデータの振り分けを行う受信情報選択部１１０、受信したコマンドを保持しておくコマンドテーブル１２０などから成る。
【００１７】
実行制御部２００は、インターフェースに適合したプロトコルでコマンドの実行を行うプロトコルエンジン２１０などから成る。
【００１８】
送信制御部３００はホスト２へ送信するステータス情報及びデータの振り分けを行う送信情報選択部３１０などから成る。
【００１９】
図２は、第１の実施形態の記憶装置１中の受信制御部１００、実行制御部２００、送信制御部３００の詳細な構成を示すブロック図である。
【００２０】
受信制御部１００中の受信情報選択部１１０は、ホスト２よりフレームの形で受信した情報４００を、フレームヘッダー中のフレーム種別フィールドに基づいて格納先を選択して格納する。すなわち、コマンド情報であるＣＯＭＭＡＮＤフレーム４０１はコマンドテーブル１２０に、不揮発性記憶媒体２０に記憶されるデータであるＤＡＴＡフレーム４０２はバッファ３０に、それぞれ格納する。
【００２１】
コマンドテーブル１２０に格納されたＣＯＭＭＡＮＤフレーム４０１はＦＷにより取り出され、ＦＷはコマンドのタイプ（すなわちライトコマンド、リードコマンド、ノンデータコマンドの種別）、ＬＢＡ（Ｌｏｇｉｃａｌ  Ｂｌｏｃｋ  Ａｄｄｒｅｓｓ）、転送数などを解釈する。
【００２２】
また、受信制御部１００には受信カウンタ１３０があり、バッファ３０に格納されたＤＡＴＡフレーム４０２の長さ（データ数）をカウントし、受信カウンタ１３０の値は実行制御部２００に出力される。
【００２３】
送信制御部３００中の送信情報選択部３１０は、実行制御部２００の指示のもと、記憶装置１の内部状態を示すステータス情報５０１と、不揮発性記憶媒体２０から読み出されバッファ３０に格納されたデータであるＤＡＴＡフレーム５０２とを選択し、通信インターフェース部４０に出力する。
【００２４】
ステータス情報５０１には、コマンドの実行が完了したことを報告するＲＥＳＰＯＮＳＥフレームと、ライトデータの受信が可能であることを報告するＸＦＥＲ＿ＲＤＹ（Ｔｒａｎｓｆｅｒ  Ｒｅａｄｙ）フレームがある。
【００２５】
また、送信制御部３００には送信カウンタ３２０があり、バッファ３０から読み出されたＤＡＴＡフレーム５０２の長さ（データ数）をカウントし、送信カウンタ３２０の値は実行制御部２００に出力される。
【００２６】
実行制御部２００はプロトコルエンジン２１０のほか、実行管理テーブル２２０、受信完了判定部２３０及び送信完了判定部２４０を有する。
【００２７】
実行管理テーブル２２０は、コマンドをキューイングして実行を管理するためのテーブルであり、その構成の一例を図３に示す。実行管理テーブル２２０は例えば１エントリーが４ＤＷ（Ｄｏｕｂｌｅ  Ｗｏｒｄ、１ＤＷは３２ビット）で構成される。テーブルのエントリー数は同時にキューイングするコマンドの数に応じて決まり、例えば８コマンドをキューイングする必要がある場合には、４ＤＷから成るテーブルが８エントリー実装される。
【００２８】
実行管理テーブル２２０の各エントリーには、キューイングして実行する各コマンドを識別するためにフレームヘッダーに付加されるｔａｇ２２１、コマンドのタイプ２２２、コマンドで指定される論理アドレス（ＬＢＡ）２２３、コマンドで指定された全転送数２２４、現在送受信しているデータの送信／受信予定数２２５が設定される。
【００２９】
なお、送信／受信予定数２２５はリードコマンド実行時には送信予定数、ライトコマンド実行時には受信予定数として扱われる。また、送信／受信予定数２２５はコマンドで指定された全転送数２２４と一致してもよいが、送信予定数としてはバッファ３０への格納が済んだデータに応じた数、受信予定数としてはバッファ３０の空きスペースに応じた数、としてもよい。
【００３０】
図２に戻って説明を続ける。受信完了判定部２３０には、現在受信しているＤＡＴＡフレーム４０２のｔａｇ１４０及び受信カウンタ１３０の値が受信制御部１００から入力され、実行管理テーブル２２０の各エントリーからｔａｇ２２１及び受信予定数２２５が入力される。受信しているＤＡＴＡフレーム４０２のｔａｇ１４０と実行管理テーブル２２０に設定されたｔａｇ２２１が一致し、かつ、当該エントリーの受信予定数２２５の値と受信カウンタ１３０の値が一致すると、受信完了判定部２３０は実行管理テーブル２２０に対し、当該エントリーのライトデータ受信完了を通知する。
【００３１】
同様に、送信完了判定部２４０には、現在送信しているＤＡＴＡフレーム５０２のｔａｇ３３０及び送信カウンタ３２０の値が送信制御部３００から入力され、実行管理テーブル２２０の各エントリーからｔａｇ２２１及び送信予定数２２５が入力される。送信しているＤＡＴＡフレーム５０２のｔａｇ３３０と実行管理テーブル２２０に設定されたｔａｇ２２１が一致し、かつ、当該エントリーの送信予定数２２５の値と送信カウンタ３２０の値が一致すると、送信完了判定部２４０は実行管理テーブル２２０に対し、当該エントリーのリードデータ送信完了を通知する。
【００３２】
次に、図４ａ〜図４ｃを参照して、実行制御部２００が制御するコマンドのプロトコルを説明する。
【００３３】
図４ａはリードコマンドのプロトコルを示す。
【００３４】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１２０に格納される。ＦＷがＣＯＭＭＡＮＤフレームを取り出し、不揮発性記憶媒体２０から読み出したデータのバッファ３０への格納その他の必要な処理を行った後、実行管理テーブル２２０にｔａｇ２２１、コマンドのタイプ２２２としてリードコマンド、ＬＢＡ２２３、コマンドで指定された全転送数２２４、送信予定数２２５を設定する。すると、実行管理テーブル２２０がプロトコルエンジン２１０に対してＤＡＴＡフレームの生成を要求する。要求を受けたプロトコルエンジン２１０は、実行管理テーブル２２０からはｔａｇ２２１及び送信予定数２２５を、バッファ３０からはデータをそれぞれ取得し、ＤＡＴＡフレームを生成する。ＤＡＴＡフレームは送信制御部３００中の送信情報選択部３１０から通信インターフェース部４０を介してホスト２に送信される。
【００３５】
記憶装置１がホスト２へＤＡＴＡフレームを送信し、送信予定数２２５の値と送信カウンタ３２０の値が一致すると、送信完了判定部２４０は実行管理テーブル２２０に対してリードデータの送信完了を通知する。
【００３６】
リードデータの送信完了を通知された実行管理テーブル２２０は、コマンドで指定された全転送数分のＤＡＴＡフレームの送信が完了していない場合、ＦＷに割り込み（ｉｎｔｅｒｒｕｐｔ）をあげ、ＦＷは送信予定数２２５の設定等を再度行う。実行管理テーブル２２０はプロトコルエンジン２１０に対してＤＡＴＡフレームの生成を再度要求し、ＤＡＴＡフレームが再送信される。
【００３７】
一方で、コマンドで指定された全転送数のＤＡＴＡフレームの送信が完了した場合は、実行管理テーブル２２０はプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレームの生成を要求する。プロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２２１を取得し、ＲＥＳＰＯＮＳＥフレームを生成する。
【００３８】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から通信インターフェース部４０を介してホスト２に送信され、ホスト２はリードコマンドの完了を認識することができる。
【００３９】
図４ｂはライトコマンドのプロトコルを示す。
【００４０】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１２０に格納される。ＦＷがＣＯＭＭＡＮＤフレームを取り出し、バッファ３０の空きスペースの確保その他の必要な処理を行った後、実行管理テーブル２２０にｔａｇ２２１、コマンドのタイプ２２２としてライトコマンド、ＬＢＡ２２３、コマンドで指定された全転送数２２４、受信予定数２２５を設定する。すると、実行管理テーブル２２０がプロトコルエンジン２１０に対してＸＦＥＲ＿ＲＤＹフレームの生成を要求する。要求を受けたプロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２２１及び受信予定数２２５を取得し、ＸＦＥＲ＿ＲＤＹフレームを生成する。ＸＦＥＲ＿ＲＤＹフレームは送信制御部３００中の送信情報選択部３１０から通信インターフェース部４０を介してホスト２に送信される。
【００４１】
ＸＦＥＲ＿ＲＤＹフレームを受信したホスト２は、ＤＡＴＡフレームを送信する。記憶装置１がＤＡＴＡフレームを受信すると、受信制御部１００はＤＡＴＡフレームをバッファ３０に格納する。受信予定数２２５の値が受信カウンタ１３０の値と一致すると、受信完了判定部２３０は実行管理テーブル２２０に対してライトデータの受信完了を通知する。
【００４２】
ライトデータの受信完了を通知された実行管理テーブル２２０は、コマンドで指定された全転送数分のＤＡＴＡフレームの受信が完了していない場合、ＦＷに割り込みをあげ、ＦＷは受信予定数２２５の設定等を再度行う。実行管理テーブル２２０はプロトコルエンジン２１０に対してＸＦＥＲ＿ＲＤＹフレームの生成を再度要求し、ＸＦＥＲ＿ＲＤＹフレームが再送信される。
【００４３】
一方で、コマンドで指定された全転送数のＤＡＴＡフレームの受信が完了した場合は、実行管理テーブル２２０はプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレームの生成を要求する。プロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２２１を取得し、ＲＥＳＰＯＮＳＥフレームを生成する。
【００４４】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から通信インターフェース部４０を介してホスト２に送信され、ホスト２はライトコマンドの完了を認識することができる。
【００４５】
図４ｃはノンデータコマンドのプロトコルを示す。
【００４６】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１２０に格納される。ＦＷがＣＯＭＭＡＮＤフレームを取り出し必要な処理を行った後、実行管理テーブル２２０にｔａｇ２２１、コマンドのタイプ２２２としてノンデータコマンドを設定する。なお、ノンデータコマンドの場合、ＬＢＡ２２３、全転送数２２４、送信／受信予定数２２５は設定する必要がない。すると、実行管理テーブル２２０がプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレームの生成を要求する。要求を受けたプロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２２１を取得し、ＲＥＳＰＯＮＳＥフレームを生成する。
【００４７】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から通信インターフェース部４０を介してホスト２に送信され、ホスト２はノンデータコマンドの完了を認識することができる。
【００４８】
次に、図５を参照して、複数のコマンドをキューイングして実行するときのプロトコルの一例を説明する。
【００４９】
ホスト２はｔａｇ＝１のＣＯＭＭＡＮＤフレームでリードコマンドを、ｔａｇ＝２のＣＯＭＭＡＮＤフレームでライトコマンドを、ｔａｇ＝３のＣＯＭＭＡＮＤフレームでノンデータコマンドをそれぞれ送信している。
【００５０】
記憶装置１はｔａｇ＝１のリードコマンドに対するＤＡＴＡフレーム及びＲＥＳＰＯＮＳＥフレームを送信した後、ｔａｇ＝３のノンデータコマンドに対するＲＥＳＰＯＮＳＥフレーム、ｔａｇ＝２のライトコマンドに対するＸＦＥＲ＿ＲＤＹフレームを送信している。
【００５１】
ホスト２はｔａｇ＝２のライトコマンドに対するＤＡＴＡフレームを送信し、記憶装置１はｔａｇ＝２のライトコマンドに対するＲＥＳＰＯＮＳＥフレームを送信している。
【００５２】
図６は本実施形態の記憶装置１がリードコマンドを実行するときのタイミングチャートである。
【００５３】
実行管理テーブル２２０の送信予定数２２５に０ｘ１０００（バイト）が設定され、各０ｘ４００バイトのＤＡＴＡフレーム（ＤＡＴＡ０〜ＤＡＴＡ３）が送信される。ＤＡＴＡフレームの送信毎に送信カウンタ３２０が０ｘ４００ずつインクリメントされ、送信予定数２２５と送信カウンタ３２０の値が０ｘ１０００で一致すると、送信完了判定部２４０は実行管理テーブル２２０に対してリードデータの送信完了を通知する。そして、コマンドで指定された全転送数のＤＡＴＡフレームの送信が完了した場合、プロトコルエンジン２１０がＲＥＳＰＯＮＳＥフレームを生成し、ホスト２に送信する。
【００５４】
なお、本実施形態では送信カウンタ３２０はＤＡＴＡフレーム長ずつインクリメントされているが、もっと小さい単位（例えばバイト単位やＤＷ単位）でインクリメントするようにしてもよい。
【００５５】
図７は本実施形態の記憶装置１がリードコマンドとノンデータコマンドをキューイングして実行するときのタイミングチャートである。
【００５６】
ｔａｇ＝４のリードコマンドに対する送信予定数２２５として、実行管理テーブル２２０に０ｘ２０００（バイト）が設定され、各０ｘ４００バイトのＤＡＴＡフレームの送信を開始する（ＤＡＴＡ０〜ＤＡＴＡ２）。
【００５７】
一方でｔａｇ＝５のノンデータコマンドに対するＦＷの処理が完了し、実行管理テーブル２２０がプロトコルエンジン２１０にｔａｇ＝５のＲＥＳＰＯＮＳＥフレームの生成を要求する。プロトコルエンジン２１０はｔａｇ＝５のＲＥＳＰＯＮＳＥフレームを生成し、ｔａｇ＝４のリードコマンドに対する送信予定数分のＤＡＴＡフレームの送信完了前（ＤＡＴＡ２の送信完了後かつＤＡＴＡ３の送信開始前）に送信情報選択部３１０を一時的に切り替え、ｔａｇ＝５のＲＥＳＰＯＮＳＥフレームを送信する。ｔａｇ＝５のＲＥＳＰＯＮＳＥフレームの送信を完了すると、プロトコルエンジン２１０は再度送信情報選択部３１０を切り替え、ｔａｇ＝４のリードコマンドに対する残りのＤＡＴＡフレーム（ＤＡＴＡ３以降）を送信する。
【００５８】
なお、本実施形態ではＤＡＴＡフレームのフレーム境界で送信情報選択部３１０を切り替えたが、もっと小さい単位（例えばバイト単位）で切り替えてもよい。
【００５９】
図８は本実施形態の記憶装置１がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【００６０】
実行管理テーブル２２０に送信予定数２２５が設定された後（Ｓ８００）、ＤＡＴＡフレームの送信を行う（Ｓ８０１）。次に、送信予定数２２５の値と送信カウンタ３２０の値が一致しているか、すなわち、送信予定数分のＤＡＴＡフレームの送信が完了したかの判断を行う（Ｓ８０２）。送信予定数分のＤＡＴＡフレームの送信が完了していない場合、実行が完了したコマンドがあるか、すなわちＲＥＳＰＯＮＳＥフレームの生成要求があるかの判断を行う（Ｓ８０３）。ＲＥＳＰＯＮＳＥフレームの生成要求がない場合、Ｓ８０１に戻りＤＡＴＡフレームの送信を続行する。ＲＥＳＰＯＮＳＥフレームの生成要求がある場合、ＲＥＳＰＯＮＳＥフレームを生成及び送信（Ｓ８０４）してからＳ８０１に戻りＤＡＴＡフレームの送信を再開する。
【００６１】
図９は本実施形態の記憶装置１がリードコマンドとノンデータコマンドをキューイングして実行するときの動作を説明する図である。
【００６２】
ホスト２はｔａｇ＝４のＣＯＭＭＡＮＤフレームでリードコマンドを、ｔａｇ＝５のＣＯＭＭＡＮＤフレームでノンデータコマンドをそれぞれ送信している。
【００６３】
記憶装置１はｔａｇ＝４のリードコマンドに対する送信予定数分のＤＡＴＡフレームの送信を完了する前に、ｔａｇ＝５のノンデータコマンドに対するＲＥＳＰＯＮＳＥフレームを送信した後、ｔａｇ＝４のリードコマンドに対する残りのＤＡＴＡフレームを送信している。
【００６４】
なお、上記ではリードコマンドとノンデータコマンドをキューイングして実行する場合を説明したが、リードコマンドとライトコマンドをキューイングして実行する場合にも同様に、ＤＡＴＡフレームの送信を開始した後、その送信予定数分の完了前に、ライトコマンドに対するＲＥＳＰＯＮＳＥフレームを送信することができる。
【００６５】
以上説明した第１の実施形態の記憶装置によれば、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、ＲＥＳＰＯＮＳＥフレームを送信する必要が生じたときに、ＤＡＴＡフレームの送信を一時中断しＲＥＳＰＯＮＳＥフレームを優先して送信するので、キューイングして実行している各コマンドを適切な順序で実行することができ、記憶装置の性能を向上させることができる。
【００６６】
［第２の実施形態］
図１０は、全二重（Ｆｕｌｌ  Ｄｕｐｌｅｘ）通信方式を説明する図である。
【００６７】
図に示すように、全二重通信方式では、ホスト２がライトコマンドに対するＤＡＴＡフレームを記憶装置１に送信するのと同時に、記憶装置１がリードコマンドに対するＤＡＴＡフレームをホスト２に送信することができる。
【００６８】
図１１は、本実施形態の記憶装置１がライトコマンドを実行するときのタイミングチャートである。
【００６９】
実行管理テーブル２２０の受信予定数２２５に０ｘ１０００（バイト）が設定されると、プロトコルエンジン２１０がＸＦＥＲ＿ＲＤＹフレームを生成し、ホスト２に送信する。ＸＦＥＲ＿ＲＤＹフレームを受信したホスト２は、各０ｘ４００バイトのＤＡＴＡフレーム（ＤＡＴＡ０〜ＤＡＴＡ３）を送信する。ＤＡＴＡフレームの受信毎に受信カウンタ１３０が０ｘ４００ずつインクリメントされ、受信予定数２２５と受信カウンタ１３０の値が０ｘ１０００で一致すると、受信完了判定部２３０は実行管理テーブル２２０に対してライトデータの受信完了を通知する。そして、実行管理テーブル２２０は、コマンドで指定された全転送数分のＤＡＴＡフレームの受信が完了していない場合、ＦＷに割り込みをあげる。ＦＷは実行管理テーブル２２０の受信予定数２２５を再度設定し、ＸＦＥＲ＿ＲＤＹフレームがホスト２に再度送信される。
【００７０】
なお、本実施形態では受信カウンタ１３０はＤＡＴＡフレーム長ずつインクリメントされているが、もっと小さい単位（例えばバイト単位やＤＷ単位）でインクリメントするようにしてもよい。
【００７１】
図１２は本実施形態の記憶装置１がリードコマンドとライトコマンドをキューイングして実行するときのタイミングチャートである。
【００７２】
ｔａｇ＝６のリードコマンドに対する送信予定数２２５として、実行管理テーブル２２０に０ｘ２０００（バイト）が設定され、各０ｘ４００バイトのＤＡＴＡフレームの送信を開始する（ＤＡＴＡ＿Ｒ０〜ＤＡＴＡ＿Ｒ１）。
【００７３】
一方でｔａｇ＝７のライトデータコマンドについて、受信予定数０ｘ１０００（バイト）に対するＤＡＴＡフレーム（ＤＡＴＡ＿Ｗ２〜ＤＡＴＡ＿Ｗ３）の受信が完了後、ＦＷの処理が完了し、実行管理テーブル２２０がプロトコルエンジン２１０にｔａｇ＝７のＸＦＥＲ＿ＲＤＹフレームの生成を要求する。
【００７４】
プロトコルエンジン２１０はｔａｇ＝７のＸＦＥＲ＿ＲＤＹフレームを生成し、ｔａｇ＝６のリードコマンドに対する送信予定数分のＤＡＴＡフレームの送信完了前（ＤＡＴＡ＿Ｒ１の送信完了後かつＤＡＴＡ＿Ｒ２の送信開始前）に送信情報選択部３１０を一時的に切り替え、ｔａｇ＝７のＸＦＥＲ＿ＲＤＹフレームを送信する。ｔａｇ＝７のＸＦＥＲ＿ＲＤＹフレームの送信を完了すると、プロトコルエンジン２１０は再度送信情報選択部３１０を切り替え、ｔａｇ＝６のリードコマンドに対する残りのＤＡＴＡフレーム（ＤＡＴＡ＿Ｒ２以降）を送信する。
【００７５】
ｔａｇ＝７のＸＦＥＲ＿ＲＤＹフレームを受信したホスト２は、ｔａｇ＝７のライトコマンドに対する残りのＤＡＴＡフレーム（ＤＡＴＡ＿Ｗ４以降）を送信するとともに、ｔａｇ＝６のリードコマンドに対する残りのＤＡＴＡフレーム（ＤＡＴＡ＿Ｒ２以降）を受信することができる。
【００７６】
なお、本実施形態ではＤＡＴＡフレームのフレーム境界で送信情報選択部３１０を切り替えたが、もっと小さい単位（例えばバイト単位）で切り替えてもよい。
【００７７】
図１３は本実施形態の記憶装置１がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【００７８】
実行管理テーブル２２０に送信予定数２２５が設定された後（Ｓ１３００）、ＤＡＴＡフレームの送信を行う（Ｓ１３０１）。次に、送信予定数２２５の値と送信カウンタ３２０の値が一致しているか、すなわち、送信予定数分のＤＡＴＡフレームの送信が完了したかの判断を行う（Ｓ１３０２）。送信予定数分のＤＡＴＡフレームの送信が完了していない場合、ライトデータの受信が可能となったコマンドがあるか、すなわちＸＦＥＲ＿ＲＤＹフレームの生成要求があるかの判断を行う（Ｓ１３０３）。ＸＦＥＲ＿ＲＤＹフレームの生成要求がない場合、Ｓ１３０１に戻りＤＡＴＡフレームの送信を続行する。ＸＦＥＲ＿ＲＤＹフレームの生成要求がある場合、ＸＦＥＲ＿ＲＤＹフレームを生成及び送信して（Ｓ１３０４）からＳ１３０１に戻りＤＡＴＡフレームの送信を再開する。
【００７９】
図１４は本実施形態の記憶装置１がリードコマンドとライトデータコマンドをキューイングして実行するときの動作を説明する図である。
【００８０】
ホスト２はｔａｇ＝６のＣＯＭＭＡＮＤフレームでリードコマンドを、ｔａｇ＝７のＣＯＭＭＡＮＤフレームでライトコマンドをそれぞれ送信している。
【００８１】
記憶装置１はｔａｇ＝７のライトコマンドに対するＸＦＥＲ＿ＲＤＹフレームを送信し、ｔａｇ＝７のライトコマンドに対するＤＡＴＡフレームの受信と同時に、ｔａｇ＝６のリードコマンドに対するＤＡＴＡフレームの送信を開始する。
【００８２】
記憶装置１はｔａｇ＝６のリードコマンドに対する送信予定数分のＤＡＴＡフレームの送信を完了する前に、ｔａｇ＝７のライトコマンドに対するＸＦＥＲ＿ＲＤＹフレームを再度送信した後、ｔａｇ＝６のリードコマンドに対する残りのＤＡＴＡフレームを送信している。
【００８３】
以上説明した第２の実施形態の記憶装置によれば、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、ＸＦＥＲ＿ＲＤＹフレームを送信する必要が生じたときに、ＤＡＴＡフレームの送信を一時中断しＸＦＥＲ＿ＲＤＹフレームを優先して送信するので、キューイングして実行している各コマンドを適切な順序で実行することができ、記憶装置の性能を向上させることができる。また、全二重通信方式である場合は、ホスト２との通信路の使用効率を高めることができる。
【００８４】
［第３の実施形態］
第３の実施形態の記憶装置１は、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、ＤＡＴＡフレームの送信を一時中断し記憶装置１の内部状態を示すステータス情報５０１を送信するか否かを判定するための閾値を有している。なお、閾値は記憶装置１内の適切な場所、例えば実行制御部２００内に設けられるレジスタに設定されればよい。
【００８５】
図１５ａは本実施形態の記憶装置１がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【００８６】
実行管理テーブル２２０に送信予定数２２５が設定された後（Ｓ１５００ａ）、ＤＡＴＡフレームの送信を行う（Ｓ１５０１ａ）。次に、送信予定数２２５の値と送信カウンタ３２０の値が一致しているか、すなわち、送信予定数分のＤＡＴＡフレームの送信が完了したかの判断を行う（Ｓ１５０２ａ）。次に、送信予定数２２５の値と送信カウンタ３２０の値との差分が閾値以上であるか、すなわち、ＤＡＴＡフレームの送信残量が多いかどうかの判断を行う（Ｓ１５０３ａ）。
【００８７】
送信予定数２２５の値と送信カウンタ３２０の値との差分が閾値以上である場合、実行が完了したコマンドがあるか、すなわちＲＥＳＰＯＮＳＥフレームの生成要求があるかの判断を行う（Ｓ１５０４ａ）。ＲＥＳＰＯＮＳＥフレームの生成要求がない場合、Ｓ１５０１ａに戻りＤＡＴＡフレームの送信を続行する。ＲＥＳＰＯＮＳＥフレームの生成要求がある場合、ＲＥＳＰＯＮＳＥフレームを生成及び送信して（Ｓ１５０５ａ）からＳ１５０１ａに戻りＤＡＴＡフレームの送信を再開する。
【００８８】
なお、送信予定数２２５の値と送信カウンタ３２０の値との差分が閾値未満であるときに（Ｓ１５０３ａ：Ｎｏ）ＲＥＳＰＯＮＳＥフレームの生成要求があった場合は、送信予定数分のＤＡＴＡフレームの送信が完了してから（Ｓ１５０６ａ）、ＲＥＳＰＯＮＳＥフレームを生成及び送信する。
【００８９】
同様に、図１５ｂは本実施形態の記憶装置１がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【００９０】
図１５ｂは図１５ａとほぼ同じであるが、図１５ａのＲＥＳＰＯＮＳＥフレームにかかるステップ（Ｓ１５０４ａ〜Ｓ１５０５ａ）が、図１５ｂではＸＦＥＲ＿ＲＤＹフレームに置き換えられている（Ｓ１５０４ｂ〜Ｓ１５０５ｂ）。
【００９１】
以上説明した第３の実施形態の記憶装置によれば、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、記憶装置の内部状態を示すステータス情報を送信する必要が生じたときに、ＤＡＴＡフレームの送信残量が多いときのみステータス情報を優先して送信するので、ＤＡＴＡフレームの送信が細切れになることを防止しつつ、キューイングして実行している各コマンドを適切な順序で実行することができ、記憶装置の性能を向上させることができる。
【００９２】
［第４の実施形態］
ＳＡＳインターフェースにおいては、図１６に示すように、エキスパンダー３と呼ばれる中継器を介して記憶装置１と複数のホスト２とが通信することができる。記憶装置１及び各ホスト２は、それぞれが固有に持つＷＷＮ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｎａｍｅ）という識別子によって区別される。記憶装置１及び各ホスト２は、相手方にフレームを送信する前に論理的な接続を確立させ、送信完了後は速やかに論理的な接続を切断しなければならない。
【００９３】
図１７は、本実施形態の記憶装置１中の実行制御部２００の詳細な構成を示すブロック図である。
【００９４】
実行制御部２００はプロトコルエンジン２１０、実行管理テーブル２２０、受信完了判定部２３０、送信完了判定部２４０のほか、ホスト管理テーブル２５０を有する。
【００９５】
ホスト管理テーブル２５０は、通信相手となるホスト２のＷＷＮや、通信速度などを管理するテーブルで、ホスト２との論理的な接続が確立されるごとに更新される。また、そのエントリー数は同時に管理する必要があるホスト２の数に応じて決まる。例えば８つのホスト２を管理する必要がある場合は８エントリー実装される。
【００９６】
図１８は、本実施形態の記憶装置１中の実行管理テーブル２２０の構成を示す図である。図３との違いは、本実施形態の実行管理テーブル２２０には、ホスト管理テーブルのエントリー番号を示すホスト番号２２６があることである。
【００９７】
図１７に戻って説明を続ける。プロトコルエンジン２１０には、実行管理テーブル２２０からホスト番号２２６が入力されるとともに、ホスト管理テーブル２５０の情報が入力される。これにより、プロトコルエンジン２１０は、現在論理的な接続が確立されているホスト２のＷＷＮ等を把握することができる。
【００９８】
図１９は本実施形態の記憶装置１がＤＡＴＡフレームを送信するときの動作を説明するフローチャートである。
【００９９】
実行管理テーブル２２０に送信予定数２２５が設定された後（Ｓ１９００）、ＤＡＴＡフレームの送信を行う（Ｓ１９０１）。次に、送信予定数２２５の値と送信カウンタ３２０の値が一致しているか、すなわち、送信予定数分のＤＡＴＡフレームの送信が完了したかの判断を行う（Ｓ１９０２）。送信予定数分のＤＡＴＡフレームの送信が完了していない場合、現在ＤＡＴＡフレームを送信しているホスト２から受信したコマンドのうち、実行が完了したコマンドがあるか、すなわちＲＥＳＰＯＮＳＥフレームの生成要求があるかの判断を行う（Ｓ１９０３）。ＲＥＳＰＯＮＳＥフレームの生成要求がない場合、Ｓ１９０１に戻りＤＡＴＡフレームの送信を続行する。ＲＥＳＰＯＮＳＥフレームの生成要求がある場合、ＲＥＳＰＯＮＳＥフレームを生成及び送信して（Ｓ１９０４）からＳ１９０１に戻りＤＡＴＡフレームの送信を再開する。
【０１００】
以上説明した第４の実施形態の記憶装置によれば、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、同一ホスト向けにＲＥＳＰＯＮＳＥフレームを送信する必要が生じたときに、ＤＡＴＡフレームの送信を一時中断しＲＥＳＰＯＮＳＥフレームを優先して送信するので、ホストと記憶装置との間の論理的な接続の確立回数を必要以上に増大させることなく、キューイングして実行している各コマンドを適切な順序で実行することができ、記憶装置の性能を向上させることができる。
【０１０１】
以上説明した少なくとも１つの実施形態の記憶装置によれば、送信予定数の決まっているＤＡＴＡフレームの送信を開始した後、記憶装置の内部状態を示すステータス情報を送信する必要が生じたときに、ＤＡＴＡフレームの送信を一時中断しステータス情報を優先して送信するので、キューイングして実行している各コマンドを適切な順序で実行することができ、記憶装置の性能を向上させることができる。
【０１０２】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【０１０３】
１…記憶装置、２…ホスト、３…エキスパンダー、１０…コントローラ、２０…不揮発性記憶媒体、３０…バッファ、４０…通信インターフェース部、５０…ＣＰＵ、１００…受信制御部、１１０…受信情報選択部、１２０…コマンドテーブル、１３０…受信カウンタ、１４０…受信したフレームのｔａｇ、２００…実行制御部、２１０…プロトコルエンジン、２２０…実行管理テーブル、２２１…実行管理テーブルに設定されたｔａｇ、２２２…コマンドタイプ、２２３…ＬＢＡ、２２４…全転送数、２２５…送信／受信予定数、２２６…ホスト番号、２３０…受信完了判定部、２４０…送信完了判定部、２５０…ホスト管理テーブル、３００…送信制御部、３１０…送信情報選択部、３２０…送信カウンタ、３３０…送信するフレームのｔａｇ、４００…受信したフレーム、４０１…受信したＣＯＭＭＡＮＤフレーム、４０２…受信したＤＡＴＡフレーム、５００…送信するフレーム、５０１…送信するステータス情報、５０２…送信するＤＡＴＡフレーム
【図１】
2017162399.tif 000003
【図２】
2017162399.tif 000004
【図３】
2017162399.tif 000005
【図４ａ】
2017162399.tif 000006
【図４ｂ】
2017162399.tif 000007
【図４ｃ】
2017162399.tif 000008
【図５】
2017162399.tif 000009
【図６】
2017162399.tif 000010
【図７】
2017162399.tif 000011
【図８】
2017162399.tif 000012
【図９】
2017162399.tif 000013
【図１０】
2017162399.tif 000014
【図１１】
2017162399.tif 000015
【図１２】
2017162399.tif 000016
【図１３】
2017162399.tif 000017
【図１４】
2017162399.tif 000018
【図１５ａ】
2017162399.tif 000019
【図１５ｂ】
2017162399.tif 000020
【図１６】
2017162399.tif 000021
【図１７】
2017162399.tif 000022
【図１８】
2017162399.tif 000023
【図１９】
2017162399.tif 000024