(57)【特許請求の範囲】
【請求項１】
データを記憶する不揮発性記憶媒体と、
ホストから受信したコマンドに応じて前記不揮発性記憶媒体へのライト動作及びリード動
作を制御するコントローラと、
を具備し、
前記コントローラは、
前記ホストから受信した複数のコマンドをキューイング実行し、
前記複数のコマンドのうちの第１の属性を有する第１のコマンドの実行に伴い発生した第
１のエラー事象を検出し、
前記第１の属性は、前記第１の属性を有するコマンドの実行に伴い発生したエラー事象を
前記ホストへ報告することにより、エラー処理コンディションを生成することを要求する
ものであり、
前記コントローラは、
前記第１のエラー事象が発生した時に保持していたコマンドのうち実行仕掛り中であった
第２のコマンドについては、
所定の実行ステップまで実行を完了させた後で
前記ホストへ前記第１のエラー事象を報告し、前記エラー処理コンディションを生成する
記憶装置。
【請求項２】
前記コントローラは、
前記ホストから新たなコマンドを受信しない第１のコマンド受信制限モードで前記第１の
エラー事象の報告を行う
請求項１に記載の記憶装置。
【請求項３】
前記コントローラは、
前記エラー処理コンディション中には、
コマンドを保持していない時にのみ前記ホストから新たなコマンドを受信する第２のコマ
ンド受信制限モードで動作する
請求項１に記載の記憶装置。
【請求項４】
前記コントローラは、
さらに複数のホストのいずれかと選択的に通信可能であり、
前記ホストが前記第１のエラー事象を報告したホストである場合にのみ、前記第２のコマ
ンド受信制限モードで動作する
請求項３に記載の記憶装置。
【請求項５】
前記コントローラは、
前記第２のコマンドのうちの前記第１の属性を有しないコマンドの、前記実行ステップま
での実行に伴い発生した第２のエラー事象を検出し、
前記第２のエラー事象については、前記エラー処理コンディションを生成し解除した後で
前記ホストへ報告する
請求項１に記載の記憶装置。
【請求項６】
前記コントローラは、
前記第２のコマンドのうちの前記第１の属性を有するコマンドの、前記実行ステップまで
の実行に伴い発生した第２のエラー事象を検出し、
前記第２のエラー事象については、前記エラー処理コンディションを生成し解除した後で
前記ホストへ報告する
請求項１に記載の記憶装置。
【請求項７】
前記第２のコマンドが、前記ホストへリードデータを送信するリードコマンドである場合
に、
前記実行ステップは、前記コントローラが前記リードコマンドで指定された前記リードデ
ータのすべてを前記ホストへ送信することである
請求項１に記載の記憶装置。
【請求項８】
前記実行ステップは、前記コントローラが、前記リードデータのすべてを前記ホストへ送
信したことを報告するステータスを前記ホストへ送信することをさらに含む
請求項７に記載の記憶装置。
【請求項９】
さらに前記不揮発性記憶媒体と前記ホストとの間でデータを一時的に格納するバッファを
具備する
請求項１に記載の記憶装置。
【請求項１０】
前記第２のコマンドが、前記ホストへリードデータを送信するリードコマンドであり、
前記第１のエラー事象が発生した時に前記リードデータのうちの少なくとも一部が前記バ
ッファに格納済みである場合に、
前記実行ステップは、前記コントローラが、前記第１のエラー事象が発生した時に前記バ
ッファから読み出し済みであった前記リードデータのすべてを前記ホストへ送信すること
である
請求項９に記載の記憶装置。
【請求項１１】
前記実行ステップは、
前記バッファに格納済みの前記リードデータの少なくとも一部を破棄することをさらに含
む
請求項１０に記載の記憶装置。
【請求項１２】
前記第２のコマンドが、前記ホストへリードデータを送信するリードコマンドであり、
前記第１のエラー事象が発生した時に前記リードデータのうちの少なくとも一部が前記バ
ッファに格納済みである場合に、
前記実行ステップは、前記コントローラが、前記第１のエラー事象が発生した時に前記バ
ッファに格納済みの前記リードデータの少なくとも一部を前記ホストへ送信することであ
る
請求項９に記載の記憶装置。
【請求項１３】
前記実行ステップは、前記コントローラが、前記第１のエラー事象が発生した時に前記バ
ッファに格納済みでなかった前記リードデータの一部を前記ホストへ送信することをさら
に含む
請求項１２に記載の記憶装置。
【請求項１４】
前記第２のコマンドが、前記ホストからライトデータを受信するライトコマンドである場
合に、
前記実行ステップは、前記コントローラが、前記ライトコマンドで指定された前記ライト
データのすべてを前記ホストから受信することである
請求項１に記載の記憶装置。
【請求項１５】
前記実行ステップは、前記コントローラが、前記ライトデータのすべてを前記ホストから
受信したことを報告するステータスを前記ホストへ送信することをさらに含む
請求項１４に記載の記憶装置。
【請求項１６】
前記第２のコマンドが、前記ホストからライトデータを受信するライトコマンドである場
合に、
前記実行ステップは、前記コントローラが、前記第１のエラー事象が発生した時に前記ホ
ストへ要求済みであった前記ライトデータのすべてを前記ホストから受信することである
請求項１に記載の記憶装置。
【請求項１７】
前記コントローラは、
前記第２のコマンドについて前記実行ステップまで実行を完了させ、
さらに前記第２のコマンドについての実行再開条件を保持した後で、
前記ホストへ前記第１のエラー事象を報告する
請求項１０又は請求項１２又は請求項１６に記載の記憶装置。
【請求項１８】
データを記憶する不揮発性記憶媒体と、
ホストから受信したコマンドに応じて前記不揮発性記憶媒体へのライト動作及びリード動
作を制御するコントローラと、
を具備し、
前記コントローラは、
前記ホストから受信した複数のコマンドをキューイング実行し、
エラー処理コンディション中に発生した解除事象及びエラー事象を検出し、
前記解除事象が発生した後は、
前記ホストから新たなコマンドを受信しない第１のコマンド受信制限モードで前記エラー
事象の報告を行ってから
前記解除事象を前記ホストに報告し、前記エラー処理コンディションを解除する
記憶装置。
【請求項１９】
前記コントローラは、
前記第１のコマンド受信制限モードで前記解除事象の報告を行う
請求項１８に記載の記憶装置。
【請求項２０】
前記第１のコマンド受信制限モードは、
前記コントローラが前記ホストからの接続要求を拒否するモードである
請求項２又は請求項１８又は請求項１９に記載の記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、記憶装置に関する。
【背景技術】
【０００２】
記憶装置のエラー処理手順は、複雑になりがちであることが知られている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２０１１／０１７９２１４号明細書
【特許文献２】米国特許第６２８６０５６号明細書
【特許文献３】米国特許第８９４３２２６号明細書
【非特許文献】
【０００４】
【非特許文献１】SCSI Architecture Model - 6、<http://www.t10.org/drafts.htm#SCSI3_ARCH>
【非特許文献２】SAS Protocol Layer - 4、<http://www.t10.org/drafts.htm#SCSI3_SAS>
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明が解決しようとする課題は、エラー処理手順を簡素化した記憶装置を提供するこ
とである。
【課題を解決するための手段】
【０００６】
上記課題を達成するために、実施形態の記憶装置は、データを記憶する不揮発性記憶媒
体と、ホストから受信したコマンドに応じて不揮発性記憶媒体へのライト動作及びリード
動作を制御するコントローラとを具備する。コントローラは、ホストから受信した複数の
コマンドをキューイング実行し、複数のコマンドのうちの第１の属性を有する第１のコマ
ンドで第１のエラー事象が発生したことを検出する。第１の属性は、第１の属性を有する
コマンドの実行に伴い発生したエラー事象を前記ホストへ報告することにより、エラー処
理コンディションを生成することを要求するものである。コントローラは、第１のエラー
事象が発生した時に保持していたコマンドのうち、実行仕掛り中であった第２のコマンド
については、所定の実行ステップまで実行を完了させた後でホストへ第１のエラー事象を
報告し、エラー処理コンディションを生成する。
【図面の簡単な説明】
【０００７】
【図１】第１の実施形態の記憶装置の構成を示すブロック図である。
【図２】第１の実施形態の記憶装置における受信制御部、実行制御部、送信制御部の詳細な構成を示すブロック図である。
【図３】第１の実施形態の記憶装置における実行管理テーブルの構成を示す図である。
【図４ａ】第１の実施形態の記憶装置が実行するリードコマンドのプロトコルを説明する図である。
【図４ｂ】第１の実施形態の記憶装置が実行するライトコマンドのプロトコルを説明する図である。
【図４ｃ】第１の実施形態の記憶装置が実行するノンデータコマンドのプロトコルを説明する図である。
【図５】第１の実施形態の記憶装置におけるコマンドのキューイング実行を説明する図である。
【図６】第１の実施形態の記憶装置におけるコマンドキューの構成を示す図である。
【図７】第１の実施形態の記憶装置におけるレスポンスキューの構成を示す図である。
【図８】第１の実施形態の記憶装置におけるＱ０モードの動作を説明する図である。
【図９】ＳＣＳＩ規格で規定されているＡＣＡコンディションの動作を説明する図である。
【図１０ａ】第１の実施形態の記憶装置がＡＣＡコンディションを生成し、解除するまでの動作を説明する図である。
【図１０ｂ】第１の実施形態の記憶装置がＡＣＡコンディションを生成し、解除するまでの動作を説明する図である。
【図１１】第１の実施形態の記憶装置がＡＣＡコンディションを生成する時の動作を説明する図である。
【図１２】第１の実施形態の記憶装置がＡＣＡコンディションを生成する時の動作を説明するフローチャートである。
【図１３】第１の実施形態の記憶装置において、実行仕掛り中コマンドでエラーが発生した場合の動作を説明する図である。
【図１４】第１の実施形態の記憶装置において、実行仕掛り中コマンドでエラーが発生した場合の別の動作を説明する図である。
【図１５】第１の実施形態の記憶装置がエラー事象を処理する際の、コマンドキュー及びレスポンスキューの第１の動作を説明する図である。
【図１６】第１の実施形態の記憶装置がエラー事象を処理する際の、第１の動作を説明するフローチャートである。
【図１７】第１の実施形態の記憶装置がエラー事象を処理する際の、コマンドキュー及びレスポンスキューの第２の動作を説明する図である。
【図１８】第１の実施形態の記憶装置がエラー事象を処理する際の、第２の動作を説明するフローチャートである。
【図１９ａ】ＳＣＳＩ規格で規定されているＡＣＡコンディション中の動作を説明するための図である。
【図１９ｂ】ＳＣＳＩ規格で規定されているＡＣＡコンディション中の動作を説明するための図である。
【図２０ａ】第１の実施形態の記憶装置におけるＱ１モードの動作を説明する図である。
【図２０ｂ】第１の実施形態の記憶装置におけるＱ１モードの動作を説明する図である。
【図２０ｃ】第１の実施形態の記憶装置におけるＱ１モードの動作を説明する図である。
【図２１】第１の実施形態の記憶装置がＡＣＡコンディションを生成した後の動作を説明するフローチャートである。
【図２２】ＳＣＳＩ規格で規定されているＡＣＡコンディションの解除時の動作を説明する図である。
【図２３】第１の実施形態の記憶装置が、ＡＣＡコンディションの解除事象が発生した後にＲＥＳＰＯＮＳＥフレームを送信する時の動作を説明する図である。
【図２４】第１の実施形態の記憶装置が、ＡＣＡコンディションを解除する時の動作を説明する図である。
【図２５】第１の実施形態の記憶装置がＡＣＡコンディションを解除する時の動作を説明するフローチャートである。
【図２６】第２の実施形態の記憶装置において、実行仕掛り中であったリードコマンドのリードデータの状況を示す図である。
【図２７】第２の実施形態の記憶装置がエラー事象を処理する際の、コマンドキュー及びレスポンスキューの動作を説明する図である。
【図２８】第２の実施形態の記憶装置がエラー事象を処理する際の動作を説明するフローチャートである。
【図２９】第３の実施形態の記憶装置において、実行仕掛り中であったライトコマンドのライトデータの状況を示す図である。
【図３０】第３の実施形態の記憶装置がエラー事象を処理する際の動作を説明するフローチャートである。
【図３１】第４の実施形態の記憶装置における実行ステップの変更条件を示す図である。
【発明を実施するための形態】
【０００８】
以下、実施形態の記憶装置を、図面を参照して説明する。なお、以下の説明において、
同一の機能及び構成を有する構成要素については、共通する参照符号を付す。
【０００９】
［第１の実施形態］
図１は、第１の実施形態の記憶装置の構成を示すブロック図である。
【００１０】
記憶装置１は、記憶装置１全体を制御するコントローラ１０、データを記憶する不揮発
性記憶媒体２０、ホスト２と不揮発性記憶媒体２０との間でデータを一時格納するバッフ
ァ３０などからなる。
【００１１】
本実施形態の説明では、ホスト２はＳＡＳ（Ｓｅｒｉａｌ  Ａｔｔａｃｈｅｄ  ＳＣＳ
Ｉ）規格のインターフェースをサポートするコンピュータであるが、その他の規格、例え
ばＵｌｔｒａ  ＳＣＳＩ規格、ＦＣ（Ｆｉｂｒｅ  Ｃｈａｎｎｅｌ）規格、ＳＡＴＡ（Ｓ
ｅｒｉａｌ  ＡＴＡ）規格、ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉ
ｎｔｅｒｃｏｎｎｅｃｔ  Ｅｘｐｒｅｓｓ）規格、ＮＶＭｅ（ＮＶＭ  Ｅｘｐｒｅｓｓ）
規格のインターフェースをサポートするコンピュータであってもよい。
【００１２】
コントローラ１０は、例えばＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ａ  Ｃｈｉｐ）として設計
される半導体集積回路である。
【００１３】
不揮発性記憶媒体２０としては、例えばＮＡＮＤ型フラッシュメモリや磁気ディスクな
どが用いられる。
【００１４】
本実施形態ではバッファ３０はＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ
Ｍｅｍｏｒｙ）からなるメモリであるが、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  
Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）など他の種類のメモリを採用してもよい。また、バッファ
３０は、コントローラ１０に内蔵されていてもよい。
【００１５】
コントローラ１０はホスト２との通信を行う通信インターフェース部４０、ＦＷ（Ｆｉ
ｒｍｗａｒｅ）を実行し記憶装置１全体の制御を行うＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃ
ｅｓｓｉｎｇ  Ｕｎｉｔ）５０、ホスト２とのコネクションの管理やプリミティブの送受
信などのＬｉｎｋ層の制御を行うＬｉｎｋ制御部６０、ホスト２からの情報の受信を制御
する受信制御部１００、ホスト２から受信したコマンドの実行を制御する実行制御部２０
０、ホスト２への情報の送信を制御する送信制御部３００などから成る。なお、ＣＰＵ５
０は必ずしもコントローラ１０に内蔵されていなくともよい。
【００１６】
受信制御部１００はホスト２から受信したコマンド及びデータの振り分けを行う受信情
報選択部１２０、受信したコマンドを保持しておくコマンドテーブル１３０などから成る
。
【００１７】
実行制御部２００は、インターフェースに適合したプロトコルでコマンドの実行を行う
プロトコルエンジン２１０などから成る。
【００１８】
送信制御部３００はホスト２へ送信するステータス情報及びデータの振り分けを行う送
信情報選択部３１０などから成る。
【００１９】
なお、記憶装置１はエキスパンダーと呼ばれる中継器を介して、複数のホスト２のいず
れかと選択的に通信を行うこともできる。
【００２０】
また、以下の説明においてＦＷにより実行されるとしてある機能の一部又は全部は専用
のＨＷ（Ｈａｒｄｗａｒｅ）によっても実行可能であり、ＨＷにより実行されるとしてあ
る機能の一部又は全部をＦＷによって実行することも可能である。
【００２１】
図２は、第１の実施形態の記憶装置１中の受信制御部１００、実行制御部２００、送信
制御部３００の詳細な構成を示すブロック図である。
【００２２】
受信制御部１００中の受信フレームＦＩＦＯ１１０は、ホスト２よりフレームの形で受
信した情報４００を一時格納するためのＦＩＦＯである。本実施形態では３フレーム分の
大きさを有する。受信情報選択部１２０は、受信フレームＦＩＦＯ１１０から取り出され
た情報４００を、フレームヘッダー中のフレーム種別フィールドに基づいて格納先を選択
して格納する。すなわち、コマンド情報であるＣＯＭＭＡＮＤフレーム４０１はコマンド
テーブル１３０に、不揮発性記憶媒体２０に記憶されるデータであるＤＡＴＡフレーム４
０２はバッファ３０に、それぞれ格納する。
【００２３】
コマンドテーブル１３０に格納されたＣＯＭＭＡＮＤフレーム４０１はＦＷにより取り
出され、ＦＷはコマンドのタイプ（すなわちライトコマンド、リードコマンド、ノンデー
タコマンドの種別）、ＬＢＡ（Ｌｏｇｉｃａｌ  Ｂｌｏｃｋ  Ａｄｄｒｅｓｓ）、転送数
などを解釈する。
【００２４】
また、受信制御部１００には受信カウンタ１４０があり、バッファ３０に格納されたＤ
ＡＴＡフレーム４０２の長さ（データ数）をカウントする。受信カウンタ１４０の値は実
行制御部２００に出力される。
【００２５】
送信制御部３００中の送信情報選択部３１０は、実行制御部２００の指示のもと、記憶
装置１の内部状態を示すステータス情報５０１と、不揮発性記憶媒体２０から読み出され
バッファ３０に格納されたデータであるＤＡＴＡフレーム５０２とを選択し、送信フレー
ムＦＩＦＯ３４０を介し、通信インターフェース部４０に出力する。なお、送信フレーム
ＦＩＦＯ３４０は本実施形態では３フレーム分の大きさを有する。
【００２６】
ステータス情報５０１には、コマンドの実行が完了したことを通知するＲＥＳＰＯＮＳ
Ｅフレームと、ライトデータの受信が可能であることを通知するＸＦＥＲ＿ＲＤＹ（Ｔｒ
ａｎｓｆｅｒ  Ｒｅａｄｙ）フレームがある。
【００２７】
また、送信制御部３００には送信カウンタ３２０があり、バッファ３０から読み出され
たＤＡＴＡフレーム５０２の長さ（データ数）をカウントする。送信カウンタ３２０の値
は実行制御部２００に出力される。
【００２８】
実行制御部２００はプロトコルエンジン２１０のほか、実行管理テーブル２２０、受信
完了判定部２３０及び送信完了判定部２４０を有する。
【００２９】
実行管理テーブル２２０は、コマンドのキューイング実行を管理するためのテーブルで
あり、その構成の一例を図３に示す。実行管理テーブル２２０は例えば１エントリーが４
ＤＷ（Ｄｏｕｂｌｅ  Ｗｏｒｄ、１ＤＷは３２ビット）で構成される。テーブルのエント
リー数は同時にキューイング実行するコマンドの数に応じて決まり、例えば８コマンドを
同時にキューイング実行する必要がある場合には、４ＤＷから成るテーブルが８エントリ
ー実装される。
【００３０】
実行管理テーブル２２０の各エントリーには、キューイング実行する各コマンドを識別
するためにフレームヘッダーに付加されるｔａｇ２２１、コマンドのタイプ２２２、ＬＢ
Ａ２２３、コマンドで指定された全転送数２２４、現在送受信しているデータの送信／受
信予定数２２５が設定される。なお、送信／受信予定数２２５はリードコマンド実行時に
は送信予定数、ライトコマンド実行時には受信予定数として扱われる。また、送信／受信
予定数２２５はコマンドで指定された全転送数２２４と一致してもよいが、送信予定数と
してはバッファ３０への格納が済んだデータに応じた数、受信予定数としてはバッファ３
０の空きスペースに応じた数、としてもよい。
【００３１】
図２に戻って説明を続ける。受信完了判定部２３０には、現在受信しているＤＡＴＡフ
レーム４０２のｔａｇ１５０及び受信カウンタ１４０の値が受信制御部１００から入力さ
れ、実行管理テーブル２２０の各エントリーからｔａｇ２２１及び受信予定数２２５が入
力される。受信しているＤＡＴＡフレーム４０２のｔａｇ１５０と実行管理テーブル２２
０に設定されたｔａｇ２２１が一致し、かつ、当該エントリーの受信予定数２２５の値と
受信カウンタ１４０の値が一致すると、受信完了判定部２３０は実行管理テーブル２２０
に対し、当該エントリーのライトデータ受信完了を通知する。
【００３２】
同様に、送信完了判定部２４０には、現在送信しているＤＡＴＡフレーム５０２のｔａ
ｇ３３０及び送信カウンタ３２０の値が送信制御部３００から入力され、実行管理テーブ
ル２２０の各エントリーからｔａｇ２２１及び送信予定数２２５が入力される。送信して
いるＤＡＴＡフレーム５０２のｔａｇ３３０と実行管理テーブル２２０に設定されたｔａ
ｇ２２１が一致し、かつ、当該エントリーの送信予定数２２５の値と送信カウンタ３２０
の値が一致すると、送信完了判定部２４０は実行管理テーブル２２０に対し、当該エント
リーのリードデータ送信完了を通知する。
【００３３】
次に、図４ａ〜図４ｃを参照して、実行制御部２００が制御するコマンドのプロトコル
を説明する。図４ａ〜図４ｃでは説明を簡略化するため、Ｌｉｎｋ制御部６０が行うＬｉ
ｎｋ層の制御は省略してある。
【００３４】
図４ａはリードコマンドのプロトコルを示す。
【００３５】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１３０に格納される。
ＦＷがＣＯＭＭＡＮＤフレームを取り出し、不揮発性記憶媒体２０から読み出したデータ
のバッファ３０への格納その他の必要な処理を行った後、実行管理テーブル２２０にｔａ
ｇ２２１、コマンドのタイプ２２２としてリードコマンド、ＬＢＡ２２３、コマンドで指
定された全転送数２２４、送信予定数２２５を設定する。すると、実行管理テーブル２２
０がプロトコルエンジン２１０に対してＤＡＴＡフレームの生成を要求する。要求を受け
たプロトコルエンジン２１０は、実行管理テーブル２２０からはｔａｇ２２１及び送信予
定数２２５を、バッファ３０からはデータをそれぞれ取得し、ＤＡＴＡフレームを生成す
る。ＤＡＴＡフレームは送信制御部３００中の送信情報選択部３１０から送信フレームＦ
ＩＦＯ３４０及び通信インターフェース部４０を介してホスト２に送信される。
【００３６】
記憶装置１がホスト２へＤＡＴＡフレームを送信し、送信予定数２２５の値と送信カウ
ンタ３２０の値が一致すると、送信完了判定部２４０は実行管理テーブル２２０に対して
リードデータの送信完了を通知する。
【００３７】
リードデータの送信完了を通知された実行管理テーブル２２０は、コマンドで指定され
た全転送数分のＤＡＴＡフレームの送信が完了していない場合、ＦＷに割り込み（ｉｎｔ
ｅｒｒｕｐｔ）をあげ、ＦＷは送信予定数２２５の設定等を再度行う。実行管理テーブル
２２０はプロトコルエンジン２１０に対してＤＡＴＡフレームの生成を再度要求し、ＤＡ
ＴＡフレームが再送信される。
【００３８】
一方で、コマンドで指定された全転送数のＤＡＴＡフレームの送信が完了した場合は、
実行管理テーブル２２０はプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレーム
の生成を要求する。プロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２
２１を取得し、ＲＥＳＰＯＮＳＥフレームを生成する。
【００３９】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から送信フレ
ームＦＩＦＯ３４０及び通信インターフェース部４０を介してホスト２に送信され、ホス
ト２はリードコマンドの完了を認識することができる。
【００４０】
図４ｂはライトコマンドのプロトコルを示す。
【００４１】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１３０に格納される。
ＦＷがＣＯＭＭＡＮＤフレームを取り出し、バッファ３０の空きスペースの確保その他の
必要な処理を行った後、実行管理テーブル２２０にｔａｇ２２１、コマンドのタイプ２２
２としてライトコマンド、ＬＢＡ２２３、コマンドで指定された全転送数２２４、受信予
定数２２５を設定する。すると、実行管理テーブル２２０がプロトコルエンジン２１０に
対してＸＦＥＲ＿ＲＤＹフレームの生成を要求する。要求を受けたプロトコルエンジン２
１０は、実行管理テーブル２２０からｔａｇ２２１及び受信予定数２２５を取得し、ＸＦ
ＥＲ＿ＲＤＹフレームを生成する。ＸＦＥＲ＿ＲＤＹフレームは送信制御部３００中の送
信情報選択部３１０から送信フレームＦＩＦＯ３４０及び通信インターフェース部４０を
介してホスト２に送信される。
【００４２】
ＸＦＥＲ＿ＲＤＹフレームを受信したホスト２は、ＤＡＴＡフレームを送信する。記憶
装置１がＤＡＴＡフレームを受信すると、受信制御部１００はＤＡＴＡフレームをバッフ
ァ３０に格納する。受信予定数２２５の値が受信カウンタ１４０の値と一致すると、受信
完了判定部２３０は実行管理テーブル２２０に対してライトデータの受信完了を通知する
。
【００４３】
ライトデータの受信完了を通知された実行管理テーブル２２０は、コマンドで指定され
た全転送数分のＤＡＴＡフレームの受信が完了していない場合、ＦＷに割り込みをあげ、
ＦＷは受信予定数２２５の設定等を再度行う。実行管理テーブル２２０はプロトコルエン
ジン２１０に対してＸＦＥＲ＿ＲＤＹフレームの生成を再度要求し、ＸＦＥＲ＿ＲＤＹフ
レームが再送信される。
【００４４】
一方で、コマンドで指定された全転送数のＤＡＴＡフレームの受信が完了した場合は、
実行管理テーブル２２０はプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレーム
の生成を要求する。プロトコルエンジン２１０は、実行管理テーブル２２０からｔａｇ２
２１を取得し、ＲＥＳＰＯＮＳＥフレームを生成する。
【００４５】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から送信フレ
ームＦＩＦＯ３４０及び通信インターフェース部４０を介してホスト２に送信され、ホス
ト２はライトコマンドの完了を認識することができる。
【００４６】
なお、コマンドで指定された全転送数のＤＡＴＡフレームの送信又は受信が完了しても
、実行管理テーブル２２０がプロトコルエンジン２１０にＲＥＳＰＯＮＳＥフレームの生
成を要求しないように設定しておくことも可能である。この場合は、ＤＡＴＡフレームの
送信又は受信の完了後、後述するノンデータコマンドと同様の手順でＲＥＳＰＯＮＳＥフ
レームを送信すればよい。
【００４７】
図４ｃはノンデータコマンドのプロトコルを示す。
【００４８】
ホスト２が送信したＣＯＭＭＡＮＤフレームはコマンドテーブル１３０に格納される。
ＦＷがＣＯＭＭＡＮＤフレームを取り出し必要な処理を行った後、実行管理テーブル２２
０にｔａｇ２２１、コマンドのタイプ２２２としてノンデータコマンドを設定する。なお
、ノンデータコマンドの場合、ＬＢＡ２２３、全転送数２２４、送信／受信予定数２２５
は設定する必要がない。すると、実行管理テーブル２２０がプロトコルエンジン２１０に
対してＲＥＳＰＯＮＳＥフレームの生成を要求する。要求を受けたプロトコルエンジン２
１０は、実行管理テーブル２２０からｔａｇ２２１を取得し、ＲＥＳＰＯＮＳＥフレーム
を生成する。
【００４９】
ＲＥＳＰＯＮＳＥフレームは送信制御部３００中の送信情報選択部３１０から送信フレ
ームＦＩＦＯ３４０及び通信インターフェース部４０を介してホスト２に送信され、ホス
ト２はノンデータコマンドの完了を認識することができる。
【００５０】
次に、図５を参照して、複数のコマンドをキューイング実行する時のプロトコルの一例
を説明する。
【００５１】
ホスト２は５つのＣＯＭＭＡＮＤフレームを送信し、ｔａｇ＝１のリードコマンド、ｔ
ａｇ＝２のライトコマンド、ｔａｇ＝３のノンデータコマンド、ｔａｇ＝４のリードコマ
ンド、ｔａｇ＝５のライトコマンド、をそれぞれ発行する。
【００５２】
記憶装置１はバッファ３０の空きスペースの確保等を行い、ｔａｇ＝２のＸＦＥＲ＿Ｒ
ＤＹフレーム、ｔａｇ＝５のＸＦＥＲ＿ＲＤＹフレームをそれぞれ送信する。
【００５３】
また、記憶装置１は不揮発性記憶媒体２０からデータを読み出し、ｔａｇ＝１のＤＡＴ
Ａフレーム、ｔａｇ＝４のＤＡＴＡフレームをそれぞれ送信する。この時、不揮発性記憶
媒体２０からのデータの読み出し状況によって、図示するように複数のｔａｇのＤＡＴＡ
フレームが交互に送信されてもよい。
【００５４】
一方、ホスト２はｔａｇ＝２のＤＡＴＡフレーム、ｔａｇ＝５のＤＡＴＡフレームをそ
れぞれ送信する。この時も、ホスト２のデータ送信の状況によって、図示するように複数
のｔａｇのＤＡＴＡフレームが交互に送信されてもよい。
【００５５】
記憶装置１はリードデータの送信が完了したｔａｇ＝１、ｔａｇ＝４、コマンドで要求
された処理が完了したｔａｇ＝３、ライトデータの受信が完了したｔａｇ＝２、ｔａｇ＝
５について、それぞれＲＥＳＰＯＮＳＥフレームを送信する。
【００５６】
なお、リードデータの送信又はライトデータの受信中にｔａｇが切り替わるタイミング
（図中に“ｔａｇ切り替わり”と示してあるタイミング）では、送信カウンタ３２０又は
受信カウンタ１４０の値が、対応するｔａｇが設定されている実行管理テーブル２２０の
送信／受信予定数２２５に、転送の途中経過としてコピーされるようにしてもよい。
【００５７】
図６ａ及び図６ｂは、本実施形態の記憶装置１における、ＦＷが管理するコマンドキュ
ー６００の構成を示す図である。
【００５８】
ＦＷはコマンドテーブル１３０からＣＯＭＭＡＮＤフレームを取り出した後、ｔａｇ６
０１、コマンドのタイプ６０２、その他必要なコマンド制御情報６０３を、ＣＰＵ５０内
の図示しないＲＡＭに保存する。そして、これらの情報に基づいて実行管理テーブル２２
０を設定し、コマンドの実行を行う。
【００５９】
図７ａ及び図７ｂは、本実施形態の記憶装置１における、ＦＷが管理するレスポンスキ
ュー７００の構成を示す図である。
【００６０】
ＦＷはＲＥＳＰＯＮＳＥフレームを送信すべき状態になったコマンドのｔａｇ７０１、
その他必要なレスポンス制御情報７０２を、ＣＰＵ５０内の図示しないＲＡＭに保存する
。そして、これらの情報に基づいて実行管理テーブル２２０を設定し、ＲＥＳＰＯＮＳＥ
フレームを送信する。
【００６１】
なお、リードコマンド及びライトコマンドにおいて、データ転送が正常終了し、実行管
理テーブル２２０がプロトコルエンジン２１０に対してＲＥＳＰＯＮＳＥフレームの生成
を要求する場合は、レスポンスキュー７００は使用されない。
【００６２】
上記の説明では、コマンドキュー６００及びレスポンスキュー７００はＣＰＵ５０内の
ＲＡＭに保存するとしたが、バッファ３０の一部領域に保存するとしてもよい。
【００６３】
図８は、本実施形態の記憶装置１のコマンド受信制限モードの１つであるＱ０モードの
動作を説明する図である。なお、図４ａ〜図４ｃでは省略してあったＬｉｎｋ制御部６０
が行うＬｉｎｋ層の制御についても一部記載してある。
【００６４】
ＳＡＳインターフェースにおいては、フレームを送信する前に、ホスト２と記憶装置１
との間でコネクションを確立させる必要がある。この時、コネクションの確立を要求する
側がＯＰＥＮアドレスフレームを送信する。一方、ＯＰＥＮアドレスフレームを受信した
側は、要求を許容するのであればＯＰＥＮ＿ＡＣＣＥＰＴプリミティブで応答し、要求を
拒否するのであればＯＰＥＮ＿ＲＥＪＥＣＴ（ＲＥＴＲＹ）プリミティブで応答する。ま
た、ＯＰＥＮ＿ＡＣＣＥＰＴプリミティブで応答した場合は、応答から１ｍｓ以内に、受
信可能なフレーム数（少なくとも１つ）をＲＲＤＹ（Ｒｅｃｅｉｖｅｒ  ｒｅａｄｙ）プ
リミティブによって相手側に通知しなければならない。なお、ＯＰＥＮアドレスフレーム
を送信した側は、ＲＲＤＹプリミティブを送信する義務はない。
【００６５】
さて、本実施形態におけるＬｉｎｋ制御部６０がＱ０モードに設定されると、図に示す
ようにホスト２からのＯＰＥＮアドレスフレームに対しては、ＯＰＥＮ＿ＲＥＪＥＣＴ（
ＲＥＴＲＹ）プリミティブで応答する。また、ＯＰＥＮ＿ＡＣＣＥＰＴプリミティブを受
信した場合は、ＲＲＤＹプリミティブの送信は行わず、そのコネクションにおいてはフレ
ームを受信しない旨をホストに通知するために、ＣＲＥＤＩＴ＿ＢＬＯＣＫＥＤプリミテ
ィブの送信を行う。
【００６６】
なお、図示しないが、コネクションがすでに確立されている時にＱ０モードに設定され
た場合は、Ｌｉｎｋ制御部６０はただちにＣＲＥＤＩＴ＿ＢＬＯＣＫＥＤプリミティブを
送信し、その後、コネクションの切断シーケンスを実行する。
【００６７】
＜ＡＣＡコンディション生成時の動作＞
記憶装置１が、コマンドの実行に伴い発生したエラー事象を検出し、当該エラー事象を
ホスト２に報告すると、記憶装置１とホスト２はエラー処理コンディションとなる。エラ
ー処理コンディションにおいては、ホスト２は当該コマンドのアボートや、記憶装置１の
診断などを行う。
【００６８】
エラー事象としては、ホスト２と記憶装置１との間の伝送路でのデータ化けや、不揮発
性記憶媒体２０からのデータ読み出し時の訂正不能なエラーなどがある。
【００６９】
以下では、エラー処理コンディションとして、ＳＡＳ規格を含むＳＣＳＩ規格で規定さ
れているＡＣＡ（Ａｕｔｏ  ｃｏｎｔｉｎｇｅｎｔ  ａｌｌｅｇｉａｎｃｅ）コンディシ
ョンを例にして説明をする。なお、他の規格において同等のエラー処理コンディションが
規定されている場合にも、規格の規定に違反しない限りにおいて適用可能である。
【００７０】
図９はＳＣＳＩ規格で規定されているＡＣＡコンディションを生成する時の動作を説明
する図である。
【００７１】
ホスト２がコマンド発行時に、コマンド内のＮＡＣＡ属性を１にして発行する。そして
、当該コマンドの実行中にエラー事象が発生した場合、記憶装置１はホスト２にエラー事
象を報告するため、“ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ”を報告する。このように、ＮＡ
ＣＡ＝１のコマンドに対する“ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ”の報告により、ＡＣＡ
コンディションが生成され、以降、ホスト２によるエラー処理のために種々の制約が課せ
られる。詳細については後述する。
【００７２】
なお、どのコマンドでエラー事象が発生するかを事前に予測することは困難であるため
、ホスト２がエラー処理にＡＣＡコンディションを使用したい場合には、すべてのリード
コマンド及びライトコマンドをＮＡＣＡ＝１で発行するのが通常である。また、ＡＣＡコ
ンディションの生成前に受信し、実行開始しないまま保持していたコマンドについては、
ＡＣＡコンディションを生成し、解除した後で実行開始しなければならない。
【００７３】
図１０ａ及び図１０ｂは本実施形態の記憶装置１がＡＣＡコンディションを生成し、解
除するまでの動作の一例を説明する図である。
【００７４】
図１０ａで、ホスト２は３つのＣＯＭＭＡＮＤフレームを送信し、ｔａｇ＝１、２、３
のリードコマンドを、いずれもＮＡＣＡ＝１で発行する。なお、各リードコマンドが指定
する全転送量は、いずれも４ＤＡＴＡフレーム分であるとする。
【００７５】
記憶装置１は不揮発性記憶媒体２０からデータを読み出し、ｔａｇ＝１、２のＤＡＴＡ
フレームを送信するが、ｔａｇ＝２の２ＤＡＴＡフレーム目において伝送路でデータ化け
が発生し、ホスト２がＮＡＫ（Ｎｅｇａｔｉｖｅ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）プ
リミティブでエラーを通知する。ここで記憶装置１は、ｔａｇ＝２のＲＥＳＰＯＮＳＥ（
ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ）フレームの送信、すなわちＡＣＡコンディションの生
成前に、すでに２ＤＡＴＡフレーム分のデータ送信を行っていたｔａｇ＝１のコマンドに
ついて、コマンドで指定された全転送量（４ＤＡＴＡフレーム）のデータ送信を完了し、
正常完了を示すＲＥＳＰＯＮＳＥ（ＮＯＲＭＡＬ）フレームを送信する。
【００７６】
一方で、ホスト２がＮＡＫプリミティブを送信する前にまったくＤＡＴＡフレームの送
信を行っていなかったｔａｇ＝３のコマンドについては、ＡＣＡコンディションが生成さ
れ、解除された後にＤＡＴＡフレームの送信を開始する。ＡＣＡコンディションの解除条
件については後述する。
【００７７】
図１０ｂは、ｔａｇ＝１のコマンドがライトコマンドの場合である。
【００７８】
ｔａｇ＝２の２ＤＡＴＡフレーム目に対してホスト２がＮＡＫプリミティブを送信した
時に、ｔａｇ＝１のコマンドについて、すでにＸＦＥＲ＿ＲＤＹフレームを送信しＤＡＴ
Ａフレームの受信が始まっている。この場合、記憶装置１はコマンドで指定された全転送
量のデータ受信を完了しＲＥＳＰＯＮＳＥ（ＮＯＲＭＡＬ）フレームを送信した後でＡＣ
Ａコンディションを生成する。
【００７９】
なお、コマンドで指定された全転送量のデータの送信又は受信のみをＡＣＡコンディシ
ョン生成前に完了させ、ＲＥＳＰＯＮＳＥ（ＮＯＲＭＡＬ）フレームの送信はＡＣＡコン
ディションの解除後に行ってもよい。
【００８０】
ここまで説明したように、本実施形態の記憶装置１は、ＡＣＡコンディションの生成条
件となるエラー事象が発生した場合、それまでに受信して保持していたコマンドのうち、
実行仕掛り中であったコマンドについては、コマンドで指定された全転送量のデータの送
信又は受信までを完了させてから、ＡＣＡコンディションを生成する。
【００８１】
ここで、あるコマンドを保持しているとは、ホスト２よりＣＯＭＭＡＮＤフレームを受
信してから、ホスト２へＲＥＳＰＯＮＳＥフレームを送信するまでの状態、又は、当該コ
マンドの実行をアボートするまでの状態を意味する。また、実行仕掛り中とは、リードコ
マンドにおいてはホスト２に少なくとも１つのＤＡＴＡフレームを送信していたことを意
味し、ライトコマンドにおいてはホスト２に少なくとも１つのＸＦＥＲ＿ＲＤＹフレーム
を送信していたことを意味する。
【００８２】
これにより、ＡＣＡコンディションの生成前後においてコマンド実行が予期せぬ実行ス
テップで分断されることがなく、エラー処理手順を簡素化することができる。
【００８３】
図１１は本実施形態の記憶装置１が、ＡＣＡコンディションを生成するためのＲＥＳＰ
ＯＮＳＥ（ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ）フレームを送信する時の動作の一例を説明
する図である。
【００８４】
図ではｔａｇ＝１、ＮＡＣＡ＝１のリードコマンドで、１ＤＡＴＡフレーム目に対して
ホスト２がＮＡＫプリミティブを送信したことで、ＡＣＡコンディションの生成条件とな
るエラー事象が発生している。
【００８５】
ここでＦＷは、Ｌｉｎｋ制御部６０をＱ０モードに設定してから、実行管理テーブル２
２０を設定し、ｔａｇ＝１のＲＥＳＰＯＮＳＥ（ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ）フレ
ームを送信する。このため、ＡＣＡコンディションの生成のためのＲＥＳＰＯＮＳＥ（Ｃ
ＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ）フレームを送信する時に、別なＣＯＭＭＡＮＤフレーム
を受信することがなくなる。
【００８６】
これにより、コマンドテーブル１３０に格納されているＣＯＭＭＡＮＤフレームが、Ａ
ＣＡコンディションの生成前に受信したものなのか、ＡＣＡコンディションの生成後に受
信したものなのかを容易に判別することができ、エラー処理手順を簡素化することができ
る。
【００８７】
なお、Ｑ０モードを使用しなくても、例えばタイムスタンプによって、コマンドテーブ
ル１３０に格納されているＣＯＭＭＡＮＤフレームが、ＡＣＡコンディションの生成前後
のいずれで受信したものなのかを判別することも可能である。
【００８８】
図１２は本実施形態の記憶装置１が、ＡＣＡコンディションを生成する時のＦＷの動作
を説明するフローチャートである。
【００８９】
ＮＡＣＡ＝１のコマンドでエラー事象が発生（Ｓ１００）すると、ＦＷはコマンドキュ
ー６００からの新たなデキューを禁止する（Ｓ１０１）。これにより実行開始していなか
ったコマンドについては、デキューの禁止が解除されるまで実行開始しないことになる。
【００９０】
次にＦＷはそれまでに実行仕掛り中となっているコマンドの有無を確認する（Ｓ１０２
）。これは例えばコマンドキュー６００内にコマンド制御情報６０３として保存しておい
た送信／受信予定数と、実行管理テーブル２２０に格納されている現在の送信／受信予定
数（すなわち転送の途中経過）を比較することによって判定される。
【００９１】
実行仕掛り中となっているコマンドがある場合（Ｓ１０２：Ｙｅｓ）、ＦＷは当該コマ
ンドについて、全転送数の転送が完了するのを待つ（Ｓ１０３）。
【００９２】
実行仕掛り中となっていたすべてのコマンドについて全転送数の転送が完了すると（Ｓ
１０３：Ｙｅｓ）、ＦＷはレスポンスキュー７００に、レスポンス制御情報７０２として
ＮＡＣＡ＝１、ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ（Ｃ．Ｃ．）を有するレスポンスを登録
する（Ｓ１０４）。
【００９３】
そして、必要に応じてＬｉｎｋ制御部６０をＱ０モードに設定してから（Ｓ１０５〜Ｓ
１０６）、実行管理テーブル２２０を設定する（Ｓ１０７）。これにより、ＲＥＳＰＯＮ
ＳＥ（ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ）フレームが送信され、ＡＣＡコンディションが
生成される。
【００９４】
＜ＡＣＡコンディション生成条件発生後に別なエラー事象が発生した場合の動作＞
図１３は本実施形態の記憶装置１が、前述した実行仕掛り中のコマンドについて全転送
数の転送完了待ちをする間に、当該実行仕掛り中コマンドでエラーが発生した場合の動作
の一例を説明する図である。なお、ｔａｇ＝２の２ＤＡＴＡフレーム目に対してホスト２
がＮＡＫプリミティブでエラーを通知するところまでは図１０ａと同じである。
【００９５】
前述のとおり記憶装置１は、すでに２ＤＡＴＡフレーム分のデータ送信を行っていたｔ
ａｇ＝１のコマンドについては、コマンドで指定された全転送量（４ＤＡＴＡフレーム）
のデータ送信をＡＣＡコンディションの生成前に完了させようとするが、ｔａｇ＝１の４
ＤＡＴＡフレーム目に対してもホスト２がＮＡＫプリミティブでエラーを通知する。
【００９６】
ここで、ｔａｇ＝２に対するＮＡＫプリミティブ、ｔａｇ＝１に対するＮＡＫプリミテ
ィブと、ＡＣＡコンディションの生成条件となるエラー事象が２つ発生したことになる。
記憶装置１はこのような場合、後から発生したエラー事象（ｔａｇ＝１に対するＮＡＫプ
リミティブ）についてはホスト２への報告を保留する。
【００９７】
そして、先に発生したエラー事象（ｔａｇ＝２に対するＮＡＫプリミティブ）をホスト
２へ報告し、ＡＣＡコンディション（１）を生成し、解除した後で、後から発生したエラ
ー事象（ｔａｇ＝１に対するＮＡＫプリミティブ）をホスト２へ報告し、ＡＣＡコンディ
ション（２）を生成する。また、ｔａｇ＝３のコマンドについては、ＡＣＡコンディショ
ン（２）を生成し、解除した後で実行を開始する。
【００９８】
このように、ＡＣＡコンディションの生成条件となるエラー事象が複数発生した場合に
、その発生順にホスト２にエラー事象を報告することで、エラー処理手順を簡素化するこ
とができる。
【００９９】
図１４は本実施形態の記憶装置１が、前述した実行仕掛り中のコマンドについて全転送
数の転送完了待ちをする間に、当該実行仕掛り中コマンドでエラーが発生した場合の動作
の別の一例を説明する図である。図１３との違いは、ｔａｇ＝１のコマンドがＮＡＣＡ＝
０で発行されていることである。
【０１００】
このような場合、先に発生したエラー事象（ｔａｇ＝２に対するＮＡＫプリミティブ）
をホスト２へ報告する前に、後から発生したエラー事象（ｔａｇ＝１に対するＮＡＫプリ
ミティブ）をホスト２へ報告する。なぜなら、ｔａｇ＝１のコマンドはＮＡＣＡ＝０なの
で、エラー事象が発生してもＡＣＡコンディションの生成条件ではなく、エラー処理手順
の複雑化の問題は生じ難いからである。
【０１０１】
なお、この場合も、ＡＣＡコンディションを生成し解除した後に、後から発生したエラ
ー事象（ｔａｇ＝１に対するＮＡＫプリミティブ）をホスト２に報告するようにして、Ｆ
Ｗによる処理手順を統一させてもよい。
【０１０２】
図１５ａ〜図１５ｃは、本実施形態のＦＷがエラー事象を処理する際の、コマンドキュ
ー６００及びレスポンスキュー７００の第１の動作の一例を説明する図である。
【０１０３】
図１５ａでは、ホスト２より受信した４つのコマンド（ｔａｇ＝１〜４、いずれもＮＡ
ＣＡ＝１のリードコマンド）がコマンドキュー６００に格納されている一方で、レスポン
スキュー７００は空である。
【０１０４】
図１５ａから図１５ｂに至るまでの間に、ｔａｇ＝１、２のコマンドの実行が開始され
、そのうちのｔａｇ＝１でエラー事象が発生したので、ＦＷはｔａｇ＝１について、レス
ポンス制御情報７０２をＮＡＣＡ＝１、ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ（Ｃ．Ｃ．）と
してレスポンスキュー７００に登録する。また、コマンドキュー６００をデキュー禁止と
し、実行開始前のｔａｇ＝３、４をデキューしないようにする。この時、ｔａｇ＝２のコ
マンドについては実行仕掛り中である。
【０１０５】
その後、図１５ｂから図１５ｃに至るまでの間に、全転送数の転送完了を待っていたｔ
ａｇ＝２のコマンドについてもエラー事象が発生したので、ＦＷはコマンドキュー６００
の先頭にｔａｇ＝２のコマンドを戻す。この時、コマンド制御情報６０３をエラーとする
。
【０１０６】
これにより、コマンドキュー６００のデキュー禁止が解除され、ｔａｇ＝２のコマンド
をデキューした時に、ｔａｇ＝２のコマンドはデータ転送を行うことなくエラー報告をす
べきことをＦＷが認識することができる。
【０１０７】
図１６は本実施形態の記憶装置１が、全転送数の転送完了を待っている間に別なエラー
事象が発生した時に、図１５ａ〜図１５ｃに示した制御を行うためのＦＷの動作を説明す
るフローチャートである。なお、本フローチャートの処理は図１２のＳ１０３で行う処理
に相当する。
【０１０８】
全転送数の転送完了の転送完了待ち（Ｓ２００）の間に新たなエラー事象が発生してい
た場合（Ｓ２０１：Ｙｅｓ）、当該コマンドのコマンド制御情報６０３をエラーとしてコ
マンドキュー６００の先頭に登録する（Ｓ２０２）。
【０１０９】
図１７ａ〜図１７ｃは、本実施形態のＦＷがエラー事象を処理する際の、コマンドキュ
ー６００及びレスポンスキュー７００の第２の動作の一例を説明する図である。図１７ａ
は図１５ａに、図１７ｂは図１５ｂにそれぞれ等しく、図１７ｃのみが図１５ｃと異なる
。
【０１１０】
図１７ｂから図１７ｃに至るまでの間に、全転送数の転送完了を待っていたｔａｇ＝２
のコマンドについてもエラー事象が発生したので、ＦＷはレスポンスキュー７００にｔａ
ｇ＝２のレスポンスを登録する。この時、レスポンス制御情報７０２をＮＡＣＡ＝１、Ｃ
ＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ（Ｃ．Ｃ．）とし、レスポンスキュー７００からのｔａｇ
＝２のレスポンスをデキュー禁止とする。
【０１１１】
これにより、ｔａｇ＝２のレスポンスのデキュー禁止が解除され、ｔａｇ＝２のレスポ
ンスをデキューした時に、ｔａｇ＝２のレスポンスでエラー報告をすべきことをＦＷが認
識することができる。
【０１１２】
図１８は本実施形態の記憶装置１が、全転送数の転送完了を待っている間に別なエラー
事象が発生した時に、図１７ａ〜図１７ｃに示した制御を行うためのＦＷの動作を説明す
るフローチャートである。なお、本フローチャートの処理についても図１２のＳ１０３で
行う処理に相当する。
【０１１３】
全転送数の転送完了待ち（Ｓ３００）の間に新たなエラー事象が発生していた場合（Ｓ
３０１：Ｙｅｓ）、当該コマンドに対するレスポンスをデキュー禁止かつレスポンス制御
情報７０２をＣＨＥＣＫ  ＣＯＮＤＩＴＩＯＮ（Ｃ．Ｃ．）としてレスポンスキューに登
録する（Ｓ３０２）。
【０１１４】
＜ＡＣＡコンディション中の動作＞
図１９ａ〜図１９ｂは、ＳＣＳＩ規格で規定されているＡＣＡコンディション中の動作
を説明するための図である。
【０１１５】
ホスト２は、ＡＣＡコンディション中に実行させたいコマンドについては、コマンド内
のＡＣＡ  ｔａｓｋ  ａｔｔｒｉｂｕｔｅ属性を１にして送信する。また、発行済みコマ
ンドに対する終了報告を受信するまでは、ホスト２は次のコマンドを発行してはならない
。すなわちＡＣＡコンディション中にキューイング実行可能なコマンド数は１である。こ
れにより、ホスト２が記憶装置１に対し適切にエラー処理コマンドを発行することが可能
となる。
【０１１６】
そして、図１９ａに示すように、ホスト２が、発行済みコマンド（ｔａｇ＝１）に対す
る終了報告の受信前に、別なコマンド（ｔａｇ＝２、３）を発行した場合、当該コマンド
に対しては、記憶装置１は“ＡＣＡ  ＡＣＴＩＶＥ”と称するエラー報告を行う。
【０１１７】
また、図１９ｂに示すように、キューイング実行可能なコマンドの数が１という制限が
守られている場合でも、ＡＣＡコンディション中にＡＣＡ  ｔａｓｋ  ａｔｔｒｉｂｕｔ
ｅ属性が０で発行されたコマンド（ｔａｇ＝１）に対しては、記憶装置１は“ＡＣＡ  Ａ
ＣＴＩＶＥ”と称するエラー報告を行う。
【０１１８】
なお、Ｃｏｎｔｒｏｌ  ｍｏｄｅ  ｐａｇｅ中のＴＭＦ＿ＯＮＬＹビットがセットされ
ている時は、ＡＣＡコンディション中に受信したいかなるコマンドに対しても記憶装置１
は“ＡＣＡ  ＡＣＴＩＶＥ”のエラー報告を行うことになっている。
【０１１９】
また、エキスパンダーを介し記憶装置１と複数のホスト２が通信可能に接続されている
場合、ＡＣＡコンディションを生成したホスト２以外のホスト２（以下では“他ホスト”
と呼ぶ）から受信したコマンドを記憶装置１が実行するか否かは、Ｃｏｎｔｒｏｌ  ｍｏ
ｄｅ  ｐａｇｅ中のＴＳＴフィールドの設定によって異なる。
【０１２０】
すなわち、ＴＳＴ＝０００ｂの時は、他ホストから受信したコマンドは、ＡＣＡ  ｔａ
ｓｋ  ａｔｔｒｉｂｕｔｅ属性に関わらず、特殊コマンド（ＰＥＲＳＩＳＴＥＮＴ  ＲＥ
ＳＥＲＶＥ  ＯＵＴ）のみ実行し、他のコマンドに対しては記憶装置１は“ＡＣＡ  ＡＣ
ＴＩＶＥ”又は“ＢＵＳＹ”のエラー報告を行う。
【０１２１】
一方、ＴＳＴ＝００１ｂの時は、他ホストから受信したＡＣＡ  ｔａｓｋ  ａｔｔｒｉ
ｂｕｔｅ属性が１のコマンドに対しては、記憶装置１は“ＣＨＥＣＫ  ＣＯＮＤＩＴＩＯ
Ｎ”のエラー報告を行うが、ＡＣＡ  ｔａｓｋ  ａｔｔｒｉｂｕｔｅ属性が０のコマンド
については通常通りに実行する。
【０１２２】
なお、これらの“ＡＣＡ  ＡＣＴＩＶＥ”（又は“ＢＵＳＹ”）の報告は、ＡＣＡコン
ディションの解除前にすべて完了させなくてはならない。ＡＣＡコンディションの解除条
件については後述する。
【０１２３】
図２０ａ〜図２０ｃは、本実施形態の記憶装置１のコマンド受信制限モードの１つであ
るＱ１モードの動作を説明する図である。なお、図４ａ〜図４ｃでは省略してあったＬｉ
ｎｋ制御部６０が行うＬｉｎｋ層の制御についても一部記載してある。
【０１２４】
図２０ａに示す動作は、コマンド受信は特に制限されていない通常モードの動作である
。前述したようにＳＡＳインターフェースにおいては、ＯＰＥＮアドレスフレームを受信
した側は、コネクション要求を許容するのであればＯＰＥＮ＿ＡＣＣＥＰＴプリミティブ
で応答し、応答から１ｍｓ以内に、受信可能なフレーム数（少なくとも１つ）をＲＲＤＹ
（Ｒｅｃｅｉｖｅｒ  ｒｅａｄｙ）プリミティブによって相手側に通知しなければならな
い。
【０１２５】
この時に送信可能なＲＲＤＹプリミティブの数は、本実施形態では受信フレームＦＩＦ
Ｏ１１０の大きさに応じて決まり、本実施形態では最大３つのＲＲＤＹプリミティブを送
信することが可能である。そして、ホスト２よりフレームを受信後、当該フレームが受信
フレームＦＩＦＯ１１０から抜き出されると、ＲＲＤＹプリミティブを追加で１つ送信し
、さらに１フレームの受信が可能になったことをホスト２に通知することができる。
【０１２６】
図２０ｂ及び図２０ｃはＬｉｎｋ制御部６０がＱ１モードに設定されている場合の動作
を示す。
【０１２７】
Ｑ１モードでは、ＯＰＥＮ＿ＡＣＣＥＰＴプリミティブで応答した後は、まずＲＲＤＹ
を１つだけ送信する。そして、受信フレームＦＩＦＯ１１０から抜き出したフレームがＣ
ＯＭＭＡＮＤフレームであった場合は、図２０ｂに示すようにＲＲＤＹプリミティブでは
なく、ＣＲＥＤＩＴ＿ＢＬＯＣＫＥＤプリミティブを送信し、そのコネクションにおいて
はこれ以上フレームを受信しない旨をホスト２に通知する。一方で受信フレームＦＩＦＯ
１１０から抜き出したフレームがＣＯＭＭＡＮＤフレームではなかった場合は、図２０ｃ
に示すようにＲＲＤＹプリミティブを１つ送信する。
【０１２８】
さて、前述したようにＡＣＡコンディション中にキューイング実行可能なコマンドの数
は１である。キューイング実行させるコマンドの数は、本来はホスト２が管理するもので
あるが、本実施形態の記憶装置１は、ＡＣＡコンディションの生成後、Ｌｉｎｋ制御部６
０をＱ１モードに設定することにより、キューイング実行可能なコマンドの数を１に制限
することができる。これにより、図１９ａに示すような、複数コマンドの受信による“Ａ
ＣＡ  ＡＣＴＩＶＥ”条件の発生を抑止することができる。
【０１２９】
なお、現在コネクションを確立している相手がＡＣＡコンディションを生成したホスト
２である場合のみＱ１モードとし、他ホストである場合には（特にＴＳＴ＝００１ｂの場
合には）、コマンド受信を特に制限しない通常モードとなるように設定してもよい。この
場合、Ｑ１モードに設定すべきホスト２を識別する識別子を、ＦＷがＬｉｎｋ制御部６０
にあらかじめ設定しておくことにより、Ｌｉｎｋ制御部６０がコネクションの確立時に通
常モード／Ｑ１モードを判断することができる。
【０１３０】
図２１は本実施形態の記憶装置１が、ＡＣＡコンディションを生成した後のＦＷの動作
を説明するフローチャートである。なお、本フローチャートの開始ステップ（Ｓ４００）
は図１２のＳ１０７に相当する。
【０１３１】
ＡＣＡコンディションの生成後（Ｓ４００）、必要に応じてＬｉｎｋ制御部６０をＱ１
モードに設定する（Ｓ４０１〜Ｓ４０２）。そして、Ｃｏｎｔｒｏｌ  ｍｏｄｅ  ｐａｇ
ｅ中のＴＳＴフィールドの設定が００１ｂの時は（Ｓ４０３：Ｙｅｓ）、他ホストから受
信したコマンド及び他ホストへ送信するレスポンスについて、それぞれコマンドキュー６
００及びレスポンスキュー７００からのデキュー禁止を解除し（Ｓ４０４）、ＡＣＡコン
ディション中でもコマンド実行を可能にする。その後、Ｑ０モードを解除する（Ｓ４０５
）。
【０１３２】
＜ＡＣＡコンディション解除時の動作＞
図２２はＳＣＳＩ規格で規定されているＡＣＡコンディションの解除時の動作を説明す
る図である。
【０１３３】
ホスト２は、エラー処理を完了しＡＣＡコンディションの解除を決断すると、ＣＬＥＡ
Ｒ  ＡＣＡ属性を１にしたタスクを発行する。そして、記憶装置１がホストに当該タスク
の正常終了を報告することにより、ＡＣＡコンディションは解除される。
【０１３４】
なお、この他の解除条件としては、特殊コマンド（ＰＥＲＳＩＳＴＥＮＴ  ＲＥＳＥＲ
ＶＥ  ＯＵＴ）の正常終了、ＡＣＡ  ｔａｓｋ  ａｔｔｒｉｂｕｔｅ属性コマンドのエラ
ー終了などがある。
【０１３５】
図２３は本実施形態の記憶装置１が、ＡＣＡコンディションの解除事象が発生した後に
ＲＥＳＰＯＮＳＥ（ＡＣＡ  ＡＣＴＩＶＥ）フレームを送信する時の動作の一例を説明す
る図である。
【０１３６】
図では“ＡＣＡ  ＡＣＴＩＶＥ”の報告条件であるＡＣＡ  ｔａｓｋ  ａｔｔｒｉｂｕ
ｔｅ＝０のＣＯＭＭＡＮＤフレームがｔａｇ＝１で発行された後、前述したようなＡＣＡ
コンディションの解除事象が発生している。
【０１３７】
この場合、ＦＷはＬｉｎｋ制御部６０をＱ０モードに設定してから、実行管理テーブル
２２０を設定し、ｔａｇ＝１のＲＥＳＰＯＮＳＥ（ＡＣＡ  ＡＣＴＩＶＥ）フレームを送
信する。
【０１３８】
前述したようにＲＥＳＰＯＮＳＥ（ＡＣＡ  ＡＣＴＩＶＥ）フレームはＡＣＡコンディ
ションの解除前にすべて送信しなければならない。Ｌｉｎｋ制御部６０をＱ０モードに設
定することで、これ以上のＣＯＭＭＡＮＤフレームの受信（ひいてはこれ以上の“ＡＣＡ
ＡＣＴＩＶＥ”報告条件の発生）を防止しつつ、ＲＥＳＰＯＮＳＥ（ＡＣＡ  ＡＣＴＩ
ＶＥ）フレームを送信することが可能になる。
【０１３９】
図２４は本実施形態の記憶装置１が、ＡＣＡコンディションを解除する時の動作を説明
する図である。
【０１４０】
図ではホスト２よりｔａｇ＝１のＴＡＳＫ（ＣＬＥＡＲ  ＡＣＡ）フレームが発行され
ている。これに対する応答をするために、ＦＷは、Ｌｉｎｋ制御部６０をＱ０モードに設
定してから、実行管理テーブル２２０を設定し、ＲＥＳＰＯＮＳＥ（ＮＯＲＭＡＬ）フレ
ームを送信する。
【０１４１】
これにより、これ以上のＣＯＭＭＡＮＤフレームの受信（ひいては“ＡＣＡ  ＡＣＴＩ
ＶＥ”報告条件の発生）を防止しつつ、ＡＣＡコンディションを解除するためのＲＥＳＰ
ＯＮＳＥ（ＮＯＲＭＡＬ）フレームを送信することが可能になる。
【０１４２】
図２５は本実施形態の記憶装置１が、ＡＣＡコンディションを解除する時の、ＦＷの動
作を説明するフローチャートである。
【０１４３】
ＡＣＡコンディションの解除事象が発生（Ｓ５００）すると、ＦＷはレスポンスキュー
７００の中に“ＡＣＡ  ＡＣＴＩＶＥ”属性のレスポンスがあるか否かを判定する（Ｓ５
０１）。“ＡＣＡ  ＡＣＴＩＶＥ”属性のレスポンスがある場合（Ｓ５０１：Ｙｅｓ）、
必要に応じてＬｉｎｋ制御部６０をＱ０モードに設定してから（Ｓ５０２〜Ｓ５０３）、
実行管理テーブル２２０を設定する（Ｓ５０４）。これによりＲＥＳＰＯＮＳＥ（ＡＣＡ
ＡＣＴＩＶＥ）フレームが送信される。次にＦＷはＱ０モードを解除する（Ｓ５０５）
。なお、Ｓ５０５は次のＳ５０６でＱ０モードに設定する場合は省略してもよい。
【０１４４】
“ＡＣＡ  ＡＣＴＩＶＥ”を報告するレスポンスがない場合（Ｓ５０１：Ｎｏ）及び“
ＡＣＡ  ＡＣＴＩＶＥ”の報告が完了した後は、必要に応じてＬｉｎｋ制御部６０をＱ０
モードに設定してから（Ｓ５０６〜Ｓ５０７）実行管理テーブル２２０を設定する（Ｓ５
０８）。これによりＲＥＳＰＯＮＳＥ（ＮＯＲＭＡＬ）フレームが送信され、ＡＣＡコン
ディションが解除される。ＡＣＡコンディションの解除後、コマンドキュー６００及びレ
スポンスキュー７００のデキュー禁止を解除し（Ｓ５０９）、Ｑ０モードを解除する（Ｓ
５１０）。
【０１４５】
以上説明した第１の実施形態の記憶装置によれば、ＡＣＡコンディションの生成時や解
除時においてコマンド実行やコマンド受信を制限したので、エラー処理手順を簡素化する
ことができる。
【０１４６】
［第２の実施形態］
第１の実施形態の記憶装置１では、ＡＣＡコンディションの生成条件となるエラー事象
が発生した場合、それまでに実行仕掛り中であったリードコマンドについては、コマンド
で指定された全転送量分のＤＡＴＡフレームの送信、又はＲＥＳＰＯＮＳＥ（ＮＯＲＭＡ
Ｌ）フレームの送信まで実行を完了させてから、ＡＣＡコンディションを生成する。
【０１４７】
これに対し本実施形態の記憶装置１では、ＡＣＡコンディションの生成条件となるエラ
ー事象が発生した時に、記憶装置１内部のどこにリードデータがあったかによって、ＡＣ
Ａコンディションを生成するまでに完了させる実行ステップを変更する。
【０１４８】
図２６は、ＡＣＡコンディションの生成条件となるエラー事象が発生した時に、実行仕
掛り中であったリードコマンドのリードデータの状況の一例を示す図である。
【０１４９】
ここで、当該リードコマンドの実行でホスト２に送信すべきデータは、ＤＡＴＡ１〜Ｄ
ＡＴＡ１５の１５フレーム分が残っているとする。また、ＤＡＴＡ１〜ＤＡＴＡ３の３フ
レームはバッファ３０から読み出し済みであり、ＤＡＴＡ４〜ＤＡＴＡ９の６フレームは
バッファ３０に格納済みであり、ＤＡＴＡ１０〜ＤＡＴＡ１５の６フレームは、まだ不揮
発性記憶媒体２０から読み出されていない。
【０１５０】
この時、ＡＣＡコンディションを生成するまでに完了させる実行ステップとして、以下
の３通りを選択することが可能である。
【０１５１】
（Ｒ１）・・・バッファ３０から読み出し済みであったリードデータを送信完了する。
【０１５２】
（Ｒ２）・・・バッファ３０に格納済みのリードデータの一部又は全部、及び/又は不
揮発性記憶媒体２０から新たに読み出すリードデータの一部を送信完了する。
【０１５３】
（Ｒ３）・・・リードコマンドで指定されたリードデータのすべてを送信完了する。
【０１５４】
（Ｒ１）を選択する場合、ＤＡＴＡ１〜ＤＡＴＡ３の３フレームを、ホスト２に送信し
た後でＡＣＡコンディションを生成する。これによりエラー事象の発生からＡＣＡコンデ
ィション生成までの時間を短縮することができる。
【０１５５】
また、この時、バッファ３０に格納されているＤＡＴＡ４〜ＤＡＴＡ９の一部又は全部
を破棄してもよい。これによりバッファの使用効率を高めることができる。
【０１５６】
（Ｒ２）を選択する場合、ＤＡＴＡ１〜ＤＡＴＡ９の一部又は全部を、ホスト２に送信
した後でＡＣＡコンディションを生成する。これによりエラー事象の発生からＡＣＡコン
ディション生成までの時間を短縮しつつ、バッファ３０の使用効率を高めることができる
。
【０１５７】
一方で、ＤＡＴＡ１〜ＤＡＴＡ９の一部又は全部をホスト２に送信した後で、ＤＡＴＡ
１０〜ＤＡＴＡ１５の一部又は全部をバッファ３０に格納してからＡＣＡコンディション
を生成してもよい。さらには、ＤＡＴＡ１０〜ＤＡＴＡ１５の一部をホスト２に送信した
後でＡＣＡコンディションを生成してもよい。これらによりＡＣＡコンディションの解除
後、当該コマンドの実行を再開する時の時間を短縮することができる。
【０１５８】
（Ｒ３）を選択する場合、ＤＡＴＡ１〜ＤＡＴＡ１５の１５フレームを、ホスト２に送
信した後でＡＣＡコンディションを生成する。この動作は第１の実施形態と同等である。
【０１５９】
図２７ａ〜図２７ｃは、上記（Ｒ１）又は（Ｒ２）の処理を行う際の、コマンドキュー
６００及びレスポンスキュー７００の動作の一例を説明する図である。図２７ａは図１５
ａに、図２７ｂは図１５ｂにそれぞれ等しく、図２７ｃのみが図１５ｃと異なる。
【０１６０】
図２７ｂから図２７ｃに至るまでの間に、バッファ３０から読み出し済みであったリー
ドデータ（（Ｒ１）の場合）又は、バッファ３０に格納済みのリードデータの一部又は全
部（（Ｒ２）の場合）の、ホスト２への送信が完了する。
【０１６１】
ＦＷはコマンドキュー６００の先頭にｔａｇ＝２のコマンドを戻すが、この時、コマン
ド制御情報６０３に、それぞれの場合に応じた実行再開条件（ＬＢＡ及び残り転送数）を
設定する。すなわち、ホスト２へのリードデータの送信が完了したＬＢＡに１を加えたア
ドレスを実行再開後の開始ＬＢＡとし、コマンドで指定された全転送数からホスト２への
送信が完了している転送数を引いた転送数を、実行再開後の転送数と設定する。
【０１６２】
これにより、コマンドキュー６００のデキュー禁止が解除された後、ｔａｇ＝２のコマ
ンドを適切に再開することができる。
【０１６３】
図２８ａ及び図２８ｂは、上記（Ｒ１）又は（Ｒ２）の処理を行う際の、ＦＷの動作を
説明するフローチャートであり、図２８ａが（Ｒ１）に、図２８ｂが（Ｒ２）にそれぞれ
対応する。なお、第１の実施形態の図１２のフローチャートにおけるＳ１０３の処理が、
本実施形態では図２８ａ又は図２８ｂのフローチャートの処理で置き換えられる。
【０１６４】
実行仕掛り中のリードコマンドについて、バッファ３０から読み出し済みであったリー
ドデータ又は、バッファ３０に格納済みのリードデータの一部又は全部を、ホスト２へ送
信完了するのを待つ（Ｓ６０１ａ、Ｓ６０１ｂ）。
【０１６５】
ホスト２へのリードデータの送信が完了すると、当該コマンドをコマンドキュー６００
の先頭に登録する。この時、実行再開条件を設定する（Ｓ６０２ａ、Ｓ６０２ｂ）。その
後、必要に応じバッファ３０に格納済みのリードデータの破棄又はバッファ３０に新たな
リードデータの格納を行う（Ｓ６０３ａ〜Ｓ６０４ａ、Ｓ６０３ｂ〜Ｓ６０４ｂ）。さら
に（Ｒ２）の場合は、バッファ３０に新たに格納したリードデータをホスト２へ送信して
もよい（Ｓ６０５ｂ）。
【０１６６】
以上説明した第２の実施形態の記憶装置によれば、リードデータの格納状況に応じてＡ
ＣＡコンディションの生成までに完了させる実行ステップを変更するので、ＡＣＡコンデ
ィションの生成が過度に遅れることを防止しつつ、エラー処理手順を簡素化することがで
きる。
【０１６７】
［第３の実施形態］
第１の実施形態の記憶装置１では、ＡＣＡコンディションの生成条件となるエラー事象
が発生した場合、それまでに実行仕掛り中であったライトコマンドについては、コマンド
で指定された全転送量分のＤＡＴＡフレームの受信、又はＲＥＳＰＯＮＳＥ（ＮＯＲＭＡ
Ｌ）フレームの送信まで実行を完了させてから、ＡＣＡコンディションを生成する。
【０１６８】
これに対し本実施形態の記憶装置１では、ＡＣＡコンディションの生成条件となるエラ
ー事象が発生した時のライトデータの受信状況、及び、記憶装置１内部のどこにライトデ
ータがあったかによって、ＡＣＡコンディションを生成するまでに完了させる実行ステッ
プを変更する。
【０１６９】
図２９は、ＡＣＡコンディションの生成条件となるエラー事象が発生した時に、実行仕
掛り中であったライトコマンドのライトデータの状況の一例を示す図である。
【０１７０】
ここで、当該ライトコマンドの実行でホスト２から受信すべきデータは、ＤＡＴＡ１〜
ＤＡＴＡ２１の２２フレーム分であり、１回目に送信したＸＦＥＲ＿ＲＤＹフレームで、
ホスト２にＤＡＴＡ１〜ＤＡＴＡ１５の１５フレーム分のライトデータは要求済みである
が、ＤＡＴＡ１６〜ＤＡＴＡ２１の６フレームは、まだ要求していない。
【０１７１】
また、ＤＡＴＡ１〜ＤＡＴＡ３の３フレームは不揮発性記憶媒体２０に記憶済みであり
、ＤＡＴＡ４〜ＤＡＴＡ９の６フレームはバッファ３０に格納済みであり、ＤＡＴＡ１０
〜ＤＡＴＡ１２の３フレームは受信フレームＦＩＦＯ１１０に格納済みであり、ＤＡＴＡ
１３〜ＤＡＴＡ１５の３フレームはまだホスト２から受信していない。
【０１７２】
この時、ＡＣＡコンディションを生成するまでに完了させる実行ステップとして、以下
の４通りを選択することが可能である。
【０１７３】
（Ｗ１）・・・ＸＦＥＲ＿ＲＤＹフレームで要求済みのライトデータを少なくともバッ
ファ３０に格納する。
【０１７４】
（Ｗ２）・・・ＸＦＥＲ＿ＲＤＹフレームで要求済みのライトデータを不揮発性記憶媒
体２０に記憶させる。
【０１７５】
（Ｗ３）・・・ライトコマンドで指定されたライトデータのすべてを少なくともバッフ
ァ３０に格納する。
【０１７６】
（Ｗ４）・・・ライトコマンドで指定されたライトデータのすべてを不揮発性記憶媒体
２０に記憶させる。
【０１７７】
（Ｗ１）を選択する場合、ＤＡＴＡ１０〜ＤＡＴＡ１５の６フレームをバッファ３０に
格納した後でＡＣＡコンディションを生成する。これにより、エラー事象の発生からＡＣ
Ａコンディション生成までの時間を短縮することができる。
【０１７８】
なお、ＤＡＴＡ４〜ＤＡＴＡ９の６フレーム及びＤＡＴＡ１０〜ＤＡＴＡ１５の６フレ
ームの一部又は全部については、バッファ３０の空きスペースが不足する場合は不揮発性
記憶媒体２０に記憶させてもよい。
【０１７９】
（Ｗ２）を選択する場合、ＤＡＴＡ４〜ＤＡＴＡ１５の１２フレームを不揮発性記憶媒
体２０に記憶させた後でＡＣＡコンディションを生成する。これにより、エラー事象の発
生からＡＣＡコンディション生成までの時間を短縮しつつ、バッファ３０の使用効率を高
めることができる。
【０１８０】
（Ｗ３）を選択する場合、ＤＡＴＡ１３〜ＤＡＴＡ１５の３フレームをホスト２より受
信した後、ＸＦＥＲ＿ＲＤＹフレームを送信し、ＤＡＴＡ１６〜ＤＡＴＡ２１の６フレー
ムをバッファ３０に格納した後でＡＣＡコンディションを生成する。
【０１８１】
この場合も（Ｗ１）の場合と同様、ＤＡＴＡ４〜ＤＡＴＡ１５の１２フレーム及びＤＡ
ＴＡ１６〜ＤＡＴＡ２１の６フレームの一部又は全部については、バッファ３０の空きス
ペースが不足する場合は不揮発性記憶媒体２０に記憶させてもよい。
【０１８２】
（Ｗ４）を選択する場合、ＤＡＴＡ１３〜ＤＡＴＡ１５の３フレームをホスト２より受
信した後、ＸＦＥＲ＿ＲＤＹフレームを送信し、ＤＡＴＡ１６〜ＤＡＴＡ２１の６フレー
ムを不揮発性記憶媒体２０に記憶させた後でＡＣＡコンディションを生成する。
【０１８３】
なお、上記（Ｗ１）又は（Ｗ２）の処理を行う際の、コマンドキュー６００及びレスポ
ンスキュー７００の動作については、第２の実施形態において説明した図２７ａ〜図２７
ｃと同様であるため、ここでは説明を省略する。
【０１８４】
図３０は、上記（Ｗ１）〜（Ｗ４）の処理を行う際の、ＦＷの動作を説明するフローチ
ャートである。なお、第１の実施形態の図１２のフローチャートにおけるＳ１０３の処理
が、本実施形態では図３０のフローチャートの処理で置き換えられる。
【０１８５】
実行仕掛り中のライトコマンドについて、最後に送信したＸＦＥＲ＿ＲＤＹフレームで
ホスト２に要求したライトデータが、少なくともバッファ３０にまで格納されるのを待つ
（Ｓ７０１）。
【０１８６】
次に、ライトコマンドで指定された全ライトデータの受信を待つ場合（Ｓ７０２：Ｙｅ
ｓ、すなわち（Ｗ３）及び（Ｗ４）の場合）、ライトコマンドで指定された全ライトデー
タをホスト２に要求する（Ｓ７０３〜Ｓ７０４）。
【０１８７】
所定のライトデータのバッファ３０への格納が完了後、当該ライトデータを不揮発性記
憶媒体２０に記憶させる場合（Ｓ７０５：Ｙｅｓ、すなわち（Ｗ２）及び（Ｗ４）の場合
）、ライトデータを不揮発性記憶媒体２０に記憶させる（Ｓ７０６）。
【０１８８】
そして、ライトコマンドで指定された全ライトデータの受信が済んでいない場合（Ｓ７
０７：Ｎｏ、すなわち（Ｗ１）及び（Ｗ２）の場合）は、当該コマンドをコマンドキュー
６００の先頭に登録する。この時、実行再開条件を設定する（Ｓ７０８）。
【０１８９】
以上説明した第３の実施形態の記憶装置によれば、ライトデータの受信状況に応じてＡ
ＣＡコンディションの生成までに完了させる実行ステップを変更するので、ＡＣＡコンデ
ィションの生成が過度に遅れることを防止しつつ、エラー処理手順を簡素化することがで
きる。
【０１９０】
［第４の実施形態］
本実施形態の記憶装置１では、第２の実施形態で説明した（Ｒ１）〜（Ｒ３）及び、第
３の実施形態で説明した（Ｗ１）〜（Ｗ４）を、残りの転送数に応じて選択する。
【０１９１】
すなわち、図３１ａに例示するように、リードコマンドで指定された全転送量のうち、
これからホスト２に送信すべきリードデータの残り転送数に対する閾値を２つ（第１閾値
＞第２閾値とする）持ち、残り転送数≧第１閾値である場合は（Ｒ１）を選択する。第１
閾値＞残り転送数≧第２閾値である場合は（Ｒ２）を選択し、残り転送数＜第２閾値であ
る場合は（Ｒ３）を選択する。
【０１９２】
また、図３１ｂに例示するように、ライトコマンドで指定された全転送量のうち、これ
からホスト２より受信すべきライトデータの残り転送数に対する閾値を持ち、残り転送数
≧第３閾値である場合は（Ｗ１）又は（Ｗ２）を選択し、第３閾値＞残り転送数である場
合は（Ｗ３）又は（Ｗ４）を選択する。
【０１９３】
なお、ＡＣＡコンディションを生成するまでの制限時間が決められている場合は、実行
仕掛り中のコマンドの、所定の実行ステップまでの実行時間によって上記第１閾値〜第３
閾値を決定し、また、（Ｒ１）〜（Ｒ３）及び（Ｗ１）〜（Ｗ４）を選択してもよい。
【０１９４】
さらには、（Ｒ１）〜（Ｒ３）及び（Ｗ１）〜（Ｗ４）の選択の条件に、バッファ３０
の空きスペースを関連させてもよい。この場合、バッファ３０の空きスペースが小さい時
は（Ｒ２）、（Ｗ２）、（Ｗ４）を選択することになる。
【０１９５】
以上説明した第４の実施形態の記憶装置によれば、リードデータの格納状況及びライト
データの受信状況に応じてＡＣＡコンディションを生成までに完了させる実行ステップを
変更するので、ＡＣＡコンディションの生成が過度に遅れることを防止しつつ、エラー処
理手順を簡素化することができる。
【０１９６】
以上説明した少なくとも１つの実施形態の記憶装置によれば、ＡＣＡコンディションの
生成時や解除時においてコマンド実行やコマンド受信を制限したので、エラー処理手順を
簡素化することができる。
【０１９７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したも
のであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その
他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の
省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や
要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる
。
【符号の説明】
【０１９８】
１…記憶装置、２…ホスト、１０…コントローラ、２０…不揮発性記憶媒体、３０…バ
ッファ、４０…通信インターフェース部、５０…ＣＰＵ、６０…Ｌｉｎｋ制御部、１００
…受信制御部、１１０…受信フレームＦＩＦＯ、１２０…受信情報選択部、１３０…コマ
ンドテーブル、１４０…受信カウンタ、１５０…受信したフレームのｔａｇ、２００…実
行制御部、２１０…プロトコルエンジン、２２０…実行管理テーブル、２２１…実行管理
テーブルに設定されたｔａｇ、２２２…コマンドタイプ、２２３…ＬＢＡ、２２４…全転
送数、２２５…送信／受信予定数、２２６…ホスト番号、２３０…受信完了判定部、２４
０…送信完了判定部、２５０…ホスト管理テーブル、３００…送信制御部、３１０…送信
情報選択部、３２０…送信カウンタ、３３０…送信するフレームのｔａｇ、３４０…送信
フレームＦＩＦＯ、４００…受信したフレーム、４０１…受信したＣＯＭＭＡＮＤフレー
ム、４０２…受信したＤＡＴＡフレーム、５００…送信するフレーム、５０１…送信する
ステータス情報、５０２…送信するＤＡＴＡフレーム、６００…コマンドキュー、６０１
…コマンドキュー中のｔａｇ、６０２…コマンドキュー中のコマンドタイプ、６０３…コ
マンドキュー中のコマンド制御情報、７００…レスポンスキュー、７０１…レスポンスキ
ュー中のｔａｇ、７０２…レスポンスキュー中のレスポンス制御情報
【図１】
0006502879.tif 000002
【図２】
0006502879.tif 000003
【図３】
0006502879.tif 000004
【図４ａ】
0006502879.tif 000005
【図４ｂ】
0006502879.tif 000006
【図４ｃ】
0006502879.tif 000007
【図５】
0006502879.tif 000008
【図６】
0006502879.tif 000009
【図７】
0006502879.tif 000010
【図８】
0006502879.tif 000011
【図９】
0006502879.tif 000012
【図１０ａ】
0006502879.tif 000013
【図１０ｂ】
0006502879.tif 000014
【図１１】
0006502879.tif 000015
【図１２】
0006502879.tif 000016
【図１３】
0006502879.tif 000017
【図１４】
0006502879.tif 000018
【図１５】
0006502879.tif 000019
【図１６】
0006502879.tif 000020
【図１７】
0006502879.tif 000021
【図１８】
0006502879.tif 000022
【図１９ａ】
0006502879.tif 000023
【図１９ｂ】
0006502879.tif 000024
【図２０ａ】
0006502879.tif 000025
【図２０ｂ】
0006502879.tif 000026
【図２０ｃ】
0006502879.tif 000027
【図２１】
0006502879.tif 000028
【図２２】
0006502879.tif 000029
【図２３】
0006502879.tif 000030
【図２４】
0006502879.tif 000031
【図２５】
0006502879.tif 000032
【図２６】
0006502879.tif 000033
【図２７】
0006502879.tif 000034
【図２８】
0006502879.tif 000035
【図２９】
0006502879.tif 000036
【図３０】
0006502879.tif 000037
【図３１】
0006502879.tif 000038