(57)【特許請求の範囲】
【請求項１】
複数のメモリセルを備える不揮発性のメモリと、
前記不揮発性のメモリを制御するコントローラとを具備し、
前記コントローラは、
ホスト・デバイスから、ブート動作のための情報を要求された際、アドレス、及びフラグ値を含む返信パケットを前記ホスト・デバイスに返信し、
前記ブート動作の際に、初期化が要求されると、前記初期化の終了まで前記初期化の要求に対する返信を返さず、初期化が終了したら前記初期化の要求に対する返信を行い、
前記ホスト・デバイスからの論理アドレスを割り当てられた書き込みデータを前記不揮発性のメモリに書き込む要求に対して前記書き込みデータの分割された部分である書き込みデータ部分をそのサイズを指定して送信することを前記ホスト・デバイスに要求し、
前記フラグ値は、初期化が終了したら前記初期化の要求に対する返信を行うことを示
す
メモリ・デバイス。
【請求項２】
前記フラグ値は、前記メモリ・デバイスが有する前記不揮発性のメモリの全てのアドレスに一括して送信される
請求項１に記載のメモリ・デバイス。
【請求項３】
前記メモリ・デバイスは、ＵＦＳ（Universal Flash Storage）に基づいたメモリ・デバイスである
請求項１または２に記載のメモリ・デバイス。
【請求項４】
メモリ・デバイスに、ブート動作のための情報を要求し、
前記メモリ・デバイスから前記ブート動作のための情報の要求に対する、アドレスと、初期化が終了したら前記初期化の要求に対する返信を行うことを示すフラグ値とを含む返信パケットを受信し、
前記フラグ値の有無を読み出すことで、ポーリング動作が不要であるか否かを判断し、
ポーリング動作が不要であると判断する場合、前記メモリ・デバイスに対して、前記メモリ・デバイスの初期化が終了したかどうかの問い合わせを行わず、
前記ブート動作の際に、前記メモリ・デバイスに要求したデバイス情報を読み出すことで、前記メモリ・デバイスの初期化を要求したとき、前記メモリ・デバイスからの前記初期化の要求に対する返信を受信した段階で、前記メモリ・デバイスの初期化が完了したと判断し、
論理アドレスを割り当てた書き込みデータを書き込むことを前記メモリ・デバイスへ要求し、前記書き込みデータの分割された部分である書き込みデータ部分をそのサイズを指定して送信することを前記メモリ・デバイスから要求させるホスト・デバイス。
【請求項５】
前記フラグ値は、前記メモリ・デバイスが有する不揮発性のメモリの全てのアドレスに一括して送信される
請求項４に記載のホスト・デバイス。
【請求項６】
前記メモリ・デバイスはＵＦＳ（Universal Flash Storage）に基づいたメモリ・デバイスである
請求項４または５に記載のホスト・デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
メモリ・デバイス、ホスト・デバイスに関するものである。
【背景技術】
【０００２】
データを保持するメディアとして種々のものが存在する。そのようなメディアとして、例えばクライアント・サーバ・モデルに基づいたメモリ・デバイスがある。クライアント・サーバ・モデルに基づいた、メモリ・デバイスおよびホスト・デバイスからなるメモリ・システムでは、別のメモリ・システムと異なる点がある。例えば、クライアント・サーバ・モデルに基づくメモリ・デバイスおよびホスト・デバイスの役割分担は、クライアント・サーバ・モデルに基づかないメモリ・デバイスおよびホスト・デバイスの役割分担と異なる。したがって、ホスト・デバイスとメモリ・デバイスとの間の通信内容も、クライアント・サーバ・モデルに基づくシステムと基づかないシステムとで異なる。
【０００３】
メモリ・システムは特定の規格に則っていることがある。例えば、クライアント・サーバ・モデルに基づくメモリ・システムとして、例えば、ＵＦＳ（Universal Flash Storage）メモリ・デバイスおよびホスト・デバイスが挙げられる。規格で定められている点については、メモリ・システムは仕様に則っていなければならない。しかしながら、規格で定められていない点も存在し、このような点については、メモリ・システムの設計者が定めることができる。このように自由度が存在する事項については、メモリ・システムの特性に適する形で好ましい性能が実現されるように、決定されるべきである。このような自由度を伴った事項に対して適切な決定を行なって、より高い性能を実現できるメモリ・デバイスを提供する要望がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】国際公開第２００７／１１６４７６号パンフレット
【非特許文献】
【０００５】
【非特許文献１】JEDEC SOLID STATE TECHNOLOGY ASSOCIATION、JEDEC STANDARD（JESD220）、２０１１年２月
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ポーリング中の負担を軽減できるメモリ・デバイス、ホスト・デバイスを提供する。
【課題を解決するための手段】
【０００７】
実施形態によれば、一態様に係るメモリ・デバイスは、複数のメモリセルを備える不揮発性のメモリと、前記不揮発性のメモリを制御するコントローラとを具備し、前記コントローラは、ブート動作の際に、デバイスの初期化が要求されると、前記初期化の終了まで前記初期化の要求に対する返信を返さず、初期化が終了したら前記初期化の要求に対する返信を行い、ホスト・デバイスからの論理アドレスを割り当てられた書き込みデータを前記不揮発性のメモリに書き込む要求に対して前記書き込みデータの分割された部分である書き込みデータ部分をそのサイズを指定して送信することを前記ホスト・デバイスに要求し、前記フラグ値は、初期化が終了したら前記初期化の要求に対する返信を行うことを示す。
【図面の簡単な説明】
【０００８】
【図１】参考例に係るBootシーケンス例を示すフロー図。
【図２】参考例のクライアント・サーバ・モデルに基づくメモリ・デバイスとホスト・デバイスとの間のデータ書き込みの際の通信の例を示すフロー図。
【図３】第１の実施形態に係るメモリ・デバイスのハードウェア上の構成を示すブロック図。
【図４】第１の実施形態に係るメモリ・デバイスが封止された形態の例を示す図。
【図５】第１の実施形態に係るメモリ・デバイス機能ブロックを示す図。
【図６】第１の実施形態に係るメモリ・デバイスのパケットの例を示す図。
【図７】第１の実施形態に係る論理アドレスと物理ブロックの変換テーブルの例を示す図。
【図８】第１の実施形態に係るＬＵをより詳細に示す機能ブロック図。
【図９】第１の実施形態に係るBootシーケンス例を示すフロー図。
【図１０】第２の実施形態に係るBootシーケンス例を示すフロー図。
【発明を実施するための形態】
【０００９】
［参考例］  
実施形態の説明に先立ち、図１および図２を用い、参考例について簡単に説明する。
【００１０】
図１は、Universal Flash Memory (UFS)におけるブート（Boot）シーケンス例を示すフロー図である。
【００１１】
図示するように、ホストおよびデバイスは、ステップＳｔ１〜Ｓｔ２．２において、デバイス初期化に必要な動作を行う。
【００１２】
続いて、ステップＳｔ３の際に、ホストは、デバイスに対してQuery Requestを発行し、初期化開始を指示する。この際、ホストは、UPIUを通じて、フラグ値としてbDeviceInit='1'を設定する。
【００１３】
続いて、ステップＳｔ３．１の際に、デバイスは、デバイス初期化を開始し、ホストに対して、Query Responseを返信する。
【００１４】
続いて、ステップＳｔ４の際に、ホストは、デバイスに対してQuery Request を発行し、UPIUを通じて、デバイスの初期化が終了したかどうかを問い合わせる。
【００１５】
これに対して、ステップＳｔ４．１の際に、デバイスは、ホストに対して、Query Responseを返信し、初期化終了したかどうかの状態を示す。
【００１６】
続いて、ステップＳｔ５の際に、同様に、ホストは、デバイスに対してQuery Request を発行し、UPIUを通じて、デバイスの初期化が終了したかどうかを問い合わせる。
【００１７】
これに対して、ステップＳｔ５．１の際に、同様に、デバイスは、ホストに対して、Query Responseを返信し、初期化終了したかどうかの状態を示す。
【００１８】
続いて、ステップＳｔ６の際に、同様に、ホストは、デバイスに対してQuery Request を発行し、UPIUを通じて、デバイスの初期化が終了したかどうかを問い合わせる。
【００１９】
これに対して、ステップＳｔ６．１の際に、同様に、デバイスは、ホストに対して、Query Responseを返信し、デバイス初期化終了したことを示す。この際、デバイスは、UPIUを通じて、フラグ値としてbDeviceInit='0'を設定する。
【００２０】
これを受けて、ホストは、デバイスの初期化が完了したことを検出し、Boot処理が終了する。
【００２１】
上記のように、参考例では、ホスト側は、デバイスの初期化が完了したかどうかをポーリングして待たなければならない（フラグ値としてのbDeviceInit='1'のポーリング）。より具体的には、この参考例では、ホスト側は、デバイスに対して初期化指示後、Query Requestによる初期化終了の確認を３回行い、３回目でホストが初期化終了を認識する。すなわち、このポーリングをしている間、ホスト側は、デバイス側の監視のためにリソースを割り当てる必要がある。
【００２２】
次に、図２を用い、クライアント・サーバ・モデルに基づくメモリ・デバイスとホスト・デバイスとの間のデータ書き込みの際の通信の例を説明する。
【００２３】
図２に示されているように、ホスト・デバイスは書き込みコマンドを発行することにより、書き込みを開始する。書き込みコマンドは、書き込みの位置を指定する論理アドレスおよび、この書き込みコマンドの対象の書き込みデータのサイズの情報を含んでいる。書き込みコマンドを受け取ると、メモリ・デバイスは、書き込みデータの転送要求の内容を決定する。転送要求には、書き込みデータのうちのメモリ・デバイスがホスト・デバイスからの転送を望む部分の大きさおよびオフセット・アドレスが含まれることになっている。オフセット・アドレスは、メモリ・デバイスが転送を望む部分の位置を特定するためのものである。ホスト・デバイスは、転送要求を受け取ると、要求されたデータ部分をメモリ・デバイスに転送する。メモリ・デバイスは、受け取ったデータ部分をメモリに書き込むことと、別のデータ部分の転送要求を送信することと、を実行する。この書き込みと転送要求は、書き込みデータ全体が書き込まれるまで継続する。書き込みデータ全体の書き込みの成功または失敗に応じて、メモリ・デバイスはホスト・デバイスに相応するレスポンスを送信する。
【００２４】
このように、図２の例では、メモリ・デバイスが書き込みデータ部分を決定し、転送要求を送信する。この書き込みにおいて、規格によって定められている事項と定められていない事項がある。例えば、メモリ・デバイスによる転送要求内のオフセット・アドレスがシーケンシャルであるかランダムであるかはホスト・デバイスにおいて任意に設定され、オフセット・アドレスの選択は、この設定に従わなければならない。一方、例えば、転送要求によって指定されるデータ部分の大きさは、仕様において定められていない場合がある。
【００２５】
なお、クライアント・サーバ・モデルに基づかないメモリ・デバイスとして、ＳＤＴＭカードおよびｅＭＭＣが一例としてある。
【００２６】
以下に、このような知見に基づいて構成された実施形態について図面を参照して説明する。なお、以下の説明において、略同一の機能及び構成を有する構成要素については、同一符号を付し、重複説明は必要な場合にのみ行う。また、以下に示す各実施形態は、この実施形態の技術的思想を具体化するための装置や方法を例示するものであって、実施形態の技術的思想は、構成部品の材質、形状、構造、配置等を下記のものに特定するものでない。実施形態の技術的思想は、特許請求の範囲において、種々の変更を加えることができる。
【００２７】
［第１の実施形態］  
次に、第１の実施形態について説明する。  
まず、図３は、第１の実施形態に係るメモリ・デバイスを概略的に示している。図３は、メモリ・デバイスのハードウェア上の構成を示している。
【００２８】
図示するように、メモリ・デバイス１は、ホスト・デバイス（以下、単にホストと称する場合がある）２と通信できるように構成されている。メモリ・デバイス１とホスト２は、少なくとも、ホスト２からの書き込み要求に対して、メモリ・デバイス１が書き込みデータの部分のサイズおよび位置を指定できる方式でホスト２と通信する。例えば、メモリ・デバイス１は、ホスト・デバイス２からの論理アドレスを割り当てられた書き込みデータをメモリに書き込む要求に対して、書き込みデータの分割された部分である書き込みデータ部分を、そのサイズを指定して送信することをホスト・デバイス２に要求すること等が可能である。より具体的には、メモリ・デバイス１とホスト２、クライアント・サーバ・モデルに基づいて通信する。メモリ・デバイス１は、ターゲットとして動作し、ホスト２はイニシエータとして動作する。さらに具体的な例として、メモリ・デバイス１はＵＦＳメモリ・デバイスであり、ホスト２はＵＦＳメモリ・デバイスをサポートするホストである。
【００２９】
メモリ・デバイス１は、少なくとも、不揮発性の半導体メモリ１１と、メモリ１１を制御するためのメモリ・コントローラ１２とを含んでいる。メモリ１１は、複数ビットからなる特定の書き込み単位でデータの書き込みおよび読み出しを行う。さらに、メモリ１１は、複数の書き込み単位からなる消去単位でデータを消去する。
【００３０】
例えば、メモリ１１は１つまたは複数のＮＡＮＤ型フラッシュ・メモリからなる。メモリ１１がＮＡＮＤ型フラッシュ・メモリである場合、メモリ１１は、ページ単位でデータの書き込みおよび読み出しを行う。ページは、複数の接続されたメモリセルの集合のメモリ空間からなり、固有の物理アドレスを割り当てられている。また、メモリ１１がＮＡＮＤ型フラッシュ・メモリである場合、メモリ１１は、ブロック単位でデータの消去を行う。各ブロックは、連続する物理アドレスを有する複数のページからなる。各メモリセルは、いわゆる積層ゲート構造のＭＯＳＦＥＴ（metal oxide semiconductor field effect transistor）からなる。各セルトランジスタは、浮遊ゲート電極に蓄えられる電子の数に応じて閾値電圧が変化し、この閾値電圧の違いに応じた情報を記憶する。メモリ１１がＮＡＮＤ型フラッシュ・メモリである場合、セルトランジスタが２つ以上の閾値電圧の異なる状態を取り得る、つまりメモリセルが多値（多ビット）を記憶できるように、メモリ１１が構成されていてもよい。以下の説明では、便宜上、書き込み単位をページとし、消去単位をブロックとする。しかしながら、メモリ１１は、必ずしもＮＡＮＤ型フラッシュ・メモリに限られない。
【００３１】
メモリ・デバイス１は、Ｉ／Ｏ２１、コア・ロジック部２２、Ｉ／Ｏ２３を含んでいる。Ｉ／Ｏ２１は、メモリ・デバイス１がホスト２と接続するためのハードウェア上の構成を含んでいる。メモリ・デバイス１がＵＦＳメモリ・デバイスである場合、メモリ・デバイス１とホスト２との間の信号には、ＲＥＳＥＴ、ＲＥＦ＿ＣＬＫ、ＤＯＵＴ、ＤＯＵＴ＿ｃ、ＤＩＮ、ＤＩＮ＿ｃ、ＶＣＣ、ＶＣＣＱ、ＶＣＣＱ２、ＶＤＤｉ、ＶＤＤｉ２、ＶＤＤｉ３が含まれる。ＲＥＳＥＴ、ＲＥＦ＿ＣＬＫ、ＤＯＵＴ、ＤＯＵＴ＿ｃ、ＤＩＮ、ＤＩＮ＿ｃは、ホスト２とＩ／Ｏ２１との間で通信される。ＲＥＳＥＴは、ハードウェア・リセット信号である。ＲＥＦ＿ＣＬＫは、参照クロックである。ＤＯＵＴとＤＯＵＴ＿ｃは差動信号対を形成し、ホスト２からメモリ・デバイス１へ送信される信号である。ＤＩＮとＤＩＮ＿ｃは差動信号対を形成し、メモリ・デバイス１からホスト２へ送信される信号である。ＶＣＣ、ＶＣＣＱ、ＶＣＣＱ２は、メモリ１１およびコア・ロジック部３１に供給される電源電圧である。ＶＤＤｉ、ＶＤＤｉ２、ＶＤＤｉ３は、コア・ロジック部３１に供給され、コア・ロジック部３１内に電圧レギュレータが設けられる際の入力端子である。
【００３２】
コア・ロジック部２２は、メモリ・コントローラ１２のうちのＩ／Ｏを除く主要部分である。Ｉ／Ｏ２３は、メモリ・コントローラ１２がメモリ１１と接続するためのハードウェア上の構成を含んでいる。コア・ロジック部２２は、ホスト・インターフェース３１、バッファ３２、データ・バス３３、メモリ・インターフェース３４、バッファ３５、ＥＣＣ回路３６、制御バス４１、ＣＰＵ（central processing unit）４２、ＲＯＭ（read only memory）４３、ワークＲＡＭ（random access memory）４５、レジスタ４６を含んでいる。
【００３３】
Ｉ／Ｏ２１は、ホスト・インターフェース３１と接続されている。ホスト・インターフェース３１は、メモリ・デバイス１とホスト２が通信するのに必要な処理を行なう。より具体的には、ホスト・インターフェース３１は、メモリ・デバイス１とホスト２がともに準拠している通信プロトコルに則ってメモリ・デバイス１とホスト２との間の通信を担う。メモリ・デバイス１がＵＦＳメモリ・デバイスである場合、例えば、ホスト・インターフェース３１は、ＵＦＳインターフェースである。ＵＦＳインターフェースは、物理層についてはＭ−ＰＨＹ規格に則っており、リンク層についてはＵｎｉＰｒｏ規格に則っている。
【００３４】
ホスト・インターフェース３１は、バッファ３２と接続されている。バッファ３２は、ホスト２からメモリ・デバイス１に送信されたデータをホスト・インターフェース３１を介して受け取り、これを一時的に保持する。また、バッファ３２は、メモリ・デバイス１からホスト・インターフェース３１を介してホスト２へ送信されるデータを一時的に保持する。バッファ３２はデータ・バス３３と接続されている。
【００３５】
Ｉ／Ｏ３１は、メモリ・インターフェース３４と接続されている。メモリ・インターフェース３４は、メモリ・コントローラ１２がメモリ１１と通信するのに必要な処理を行なう。より具体的には、メモリ・インターフェース３４は、コア・ロジック部２２からの指示をメモリ１１が認識可能な形態で送信する。メモリ１１がＮＡＮＤ型フラッシュ・メモリである場合、メモリ・インターフェース３４は、ＮＡＮＤフラッシュ・インターフェースである。
【００３６】
メモリ・インターフェース３４は、バッファ３５と接続されている。バッファ３５は、メモリ１１からコントローラ１２に送信されたデータをメモリ・インターフェース３４を介して受け取り、これを一時的に保持する。また、バッファ３５は、コントローラ１２からメモリ１１にメモリ・インターフェース３４を介して送信される予定のデータを一時的に保持する。バッファ３５はデータ・バス３３と接続されている。メモリ・インターフェース３４およびバッファ３５は、ＥＣＣ（error correcting code）回路３６と接続されている。ＥＣＣ回路３６はまた、データ・バッファ２４と接続されている。ＥＣＣ回路３６は、ホスト１からの書き込みデータをデータ・バス３３を介して受け取り、書き込みデータにエラー訂正符号を付加し、エラー訂正符号を付された書き込みデータをバッファ３５に供給する。また、ＥＣＣ回路３６は、メモリ１１から供給されたデータをバッファ３５を介して受け取り、このデータに対してエラー訂正符号を用いてエラー訂正を行い、エラー訂正されたデータをデータ・バス３３に供給する。
【００３７】
データ・バス３３は、制御バス４１と接続されている。制御バス４１には、ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４５、レジスタ４６が接続されている。ＣＰＵ４２、ＲＯＭ４３、ＲＡＭ４５、レジスタ４６は、制御バス４１を介して相互に通信する。ＣＰＵ４２は、メモリ・デバイス１の全体の動作を司る。ＣＰＵ４２は、ＲＯＭ４３に格納されている制御プログラム（命令）に従ってホスト２から受けたコマンドに従ってメモリ１１に対する所定の処理を実行する。ＣＰＵ４２は、制御プログラムに従ってホスト２から受けたコマンドに従ってメモリ１１に対する所定の処理を実行したりする。
【００３８】
ＲＯＭ４３は、ＣＰＵ４２により制御される制御プログラムなどを格納する。ＲＡＭ４５は、ＣＰＵ４２の作業エリアとして使用され、ＣＰＵ４２の作業に必要な変数等を一時的に記憶する。レジスタ４６は、メモリ・デバイス１の動作に必要な種々の値を保持する。また、レジスタ４６は、ホスト２が、メモリ・デバイス２を制御するのに必要な種々の値を保持する。
【００３９】
制御バス４１には、ホスト・インターフェース３１、バッファ３２、メモリ・インターフェース３４、バッファ３５が接続されている。ＣＰＵ４２は、制御プログラムやホスト２からの指示に基づいて、ホスト・インターフェース３１、バッファ３２、メモリ・インターフェース３４、バッファ３５を制御する。メモリ・コントローラ１２には、アナログ回路５１が設けられていてもよい。
【００４０】
＜メモリ・デバイスの封止された形態について＞  
メモリ・デバイス１は、例えば、プリント基板上に半田実装される埋め込み型でも良いし、ホスト２に設けられたカードスロットに対して脱着可能なリムーバブル型でも良い。
【００４１】
図４は、封止された形態のメモリ・デバイス１の例を示している。図４に示されているように、プリント基板２０１上にチップ状の複数のメモリ１１が積層されている。各メモリ１１は、プリント基板２０１上の配線パターン（図示せず）にワイヤ２０２により接続されている。チップ状のメモリ・コントローラ１２も、プリント基板２０１上に置かれ、ワイヤ２０２により配線パターンに接続されている。プリント基板２０１の裏面には、図示せぬ外部端子（例えば、ＢＧＡ（ball grid array））が設けられている。外部端子には、図３に示した信号（ＲＥＳＥＴ、ＲＥＦ＿ＣＬＫ、ＤＯＵＴ、ＤＯＵＴ＿ｃ、ＤＩＮ、ＤＩＮ＿ｃ、ＶＣＣ、ＶＣＣＱ、ＶＣＣＱ２、ＶＤＤｉ、ＶＤＤｉ２、ＶＤＤｉ３が含まれる。ＲＥＳＥＴ、ＲＥＦ＿ＣＬＫ、ＤＯＵＴ、ＤＯＵＴ＿ｃ、ＤＩＮ、ＤＩＮ＿ｃ）が割り当てられ、この外部端子を介してメモリ・デバイス１外部のホスト２との間で信号を通信する。ＢＧＡ（ball grid array）が設けられている。プリント基板２０１、メモリ１１、メモリ・コントローラ１２、ワイヤ２０２は、例えば樹脂製のパッケージ２０３により封止されている。
【００４２】
＜メモリ・デバイスの機能ブロックについて＞  
次に、図５に、メモリ・デバイス１の構成の別の視点を示す。より具体的には、図５は、メモリ・デバイス１の論理構成、すなわち機能ブロックを示している。各ブロックは、ハードウェア、コンピュータ・ソフトウェアのいずれかまたは両者を組み合わせたものとして実現されることが可能である。各機能ブロックが、ハードウェアとして実行されるか、またはソフトウェアとして実行されるかは、具体的な実施態様またはシステム全体に課される設計制約に依存する。当業者は、具体的な実施態様ごとに、種々の方法でこれらの機能を実現し得るが、いずれの実現の手法も実施形態の範疇に含まれる。また、各機能ブロックが、以下の具体例のように区別されていることは、必須ではない。例えば、一部の機能が以下の説明において例示されている機能ブロックとは別の機能ブロックによって実行されてもよい。さらに、例示のブロックがさらに細かい機能サブブロックに分割されていてもよい。どのブロックによって特定されるかによって実施形態が限定されるものではない。
【００４３】
図示するように、メモリ・デバイス１は、ターゲット・ポート６１、ルータ６２、デバイス・マネージャ６３、デスクリプタ６４、アトリビュート６５、フラグ６６、複数のロジカル・ユニット（ＬＵ：logical unit）６７を含んでいる。
【００４４】
ターゲット・ポート６１は、メモリ・デバイス１がホスト１と通信可能に接続されるためのポートであり、例えばホスト・インターフェース３１に対応する。ルータ６２は、ホスト２から受信された通信（タスク、コマンド、データ、クエリー等）を宛先のＬＵ６７にルーティングする。ホスト２は、コマンドの処理またはタスク管理機能を、１つのＬＵ６７を宛先とする要求を通じて要求する。
【００４５】
ＬＵ６７同士は、アドレス（例えばＬＵＮ（logial unit number））により相互に識別されることが可能である。ＬＵＮは、例えば、図６に示されているように、メモリ・デバイス１とホスト２との間の通信（パケット）に含められることが可能である。図６に示されているように、パケット１０１は、ＬＵＮ１０２と、実体部１０３とを含んでいる。ＬＵＮ１０２は、例えばパケット１０１のヘッダに含められることが可能である。実体部１０３は、パケットの機能に固有の内容、例えばコマンド、データ、各種のパラメータ等を含んでいる。各パケットの宛先のＬＵ６２は、ＬＵＮにより一意に特定される。ＵＦＳメモリ・デバイスでは、メモリ・デバイス１とホスト２との間のパケットはいずれもヘッダを含んでおり、ヘッダ内にＬＵＮが記述されている。
【００４６】
ルータ６２は、ホスト２から受信された通信（タスク、コマンド、データ、クエリー）を、この通信中のＬＵＮ１０３に基づいて、宛先のＬＵ６７にルーティングする。また、ルータ６２は、複数のＬＵ６７からホスト２宛ての通信を例えば時分割によって適当な順序でターゲット・ポート６１に送信する。ルータ６２は、例えばＣＰＵ４２、ＲＯＭ４３、レジスタ４６により実現される。すなわち、ＣＰＵ４２によって、ＲＯＭ４３中のプログラムが、レジスタ４６中の値を参照しながら実行されることを通じて実現される。
【００４７】
デバイス・レベル・マネージャ６３は、デバイス・レベルの動作およびコンフィギュレーションの管理を行なう。デバイス・レベルの管理には、例えば、メモリ・デバイス１の電力管理、スリープ等の制御等が含まれる。デバイス・レベルのコンフィギュレーションには、デスクリプタの組を保持すること等が含まれる。デバイス・レベル・マネージャ６３は、ホスト２からのメモリ・デバイス１のコンフィギュレーション情報の変更および出力要求であるクエリー要求のようなコマンドを処理する。デバイス・レベル・マネージャ６３は、例えばＣＰＵ４２、ＲＯＭ４３、レジスタ４６により実現される。すなわち、ＣＰＵ４２によって、ＲＯＭ４３中のプログラムが、レジスタ４６中の値を参照しながら実行されることを通じて実現される。
【００４８】
デスクリプタ６４、アトリビュート６５、フラグ６６は、例えばワークＲＡＭ４５中のデータとして実現される。デスクリプタ６４は、予め定義されたフォーマットのデータ構造を有し、メモリ・デバイス１についての何らかの特徴を記述するためのものである。デスクリプタ６４には、例えば、メモリ・デバイス１にアクセスするのに必要なデバイス・クラス、サブ・クラス、プロトコル等が含まれる。アトリビュート６５は、メモリ・デバイス１に与えられた設定を示す変更可能または読み出し専用のパラメータである。アトリビュート６５には、例えば、メモリ・デバイス１とホスト２との間で転送可能なデータの最大値等が含まれる。フラグ６６は、種々の項目についての択一的な論理値からなり、例えば「真」または「偽」、あるいは「０」または「１」等により表わされる。
【００４９】
各ＬＵ６７は、例えばメモリ１１、メモリ・インターフェース３４、バッファ３５、ＥＣＣ回路３６、ＣＰＵ４２、ＲＯＭ４３、レジスタ４６により実現される。各ＬＵ６７は、相互に独立して、ホスト２からの処理を実行する。したがって、各ＬＵはメモリ１１、インターフェース３１、バッファ３５、ＥＣＣ回路３６、ＣＰＵ４２、ＲＯＭ４３、レジスタ４６等の資源の一部を利用して実現される。各ＬＵは、上記のようにホスト２からは１つのＬＵを特定するＬＵＮによって相互に区別される。ホスト２からのコマンドは指定されたＬＵ６７によって実行される。
【００５０】
各ＬＵ６７は、デバイス・サーバ７１、タスク・マネージャ７２、メモリ領域７３を含んでいる。メモリ領域７３は、メモリ１１のメモリ領域のうちの一部から構成され、ホスト２からの書き込みデータを実際に格納する。デバイス・サーバ７１およびタスク・マネージャ７２は、例えばＣＰＵ４２、ＲＯＭ４３、レジスタ４６により実現される。すなわち、ＣＰＵ４２によって、ＲＯＭ４３中のプログラムが、レジスタ４６中の値を参照しながら実行されることを通じて実現される。デバイス・サーバ７１は、ホスト２から受信されたＬＵレベルの処理を要求するコマンドを解釈し、実行する。そのような処理には、例えば、データの書き込み、読み出し、消去等が含まれる。ＬＵ６７はメモリ領域７３を含んでいるので、デバイス・サーバ７１は、少なくともメモリ領域７３（メモリ１１）を制御する機能を有している。タスク・マネージャ７２は、複数のコマンド（タスク）の実行の順序を制御し、タスク管理機能を提供する。
【００５１】
上記のように、デバイス・サーバ７１は、メモリ１１の制御に関する処理を行なう。そのような処理には、論理アドレスと物理アドレスの変換が含まれる。論理アドレスは、ホスト２によって、ホスト２がメモリ・デバイス１に書き込むことを望むデータに割り当てられるアドレスである。物理アドレスは、上記のように、メモリ１１の書き込み領域（ページ）または消去領域（ブロック）を特定するためのアドレスである。デバイス・サーバ７１は、自身に対応するメモリ領域７３によるデータの記憶状態を管理する。記憶状態の管理とは、どの物理アドレスのページ（または物理ブロック）が、どの論理アドレスのデータを保持しているかの関係、およびどの物理アドレスのページ（または物理ブロック）が消去状態（何も書き込まれていない、または無効なデータを保持している状態）であるかを管理することを含んでいる。その管理のために、デバイス・サーバ７１は、例えば論理アドレス・物理アドレス変換テーブル（以下、単に変換テーブルと称する場合がある）を保持している。
【００５２】
変換の例として、例えば、図７に示されているように、割り当てをブロックとすることができる。各ブロック中の各ページに対して、固定の論理アドレス・オフセットが割り当てられている。図７は、メモリ１１の書き込み単位の大きさが１６ｋＢであり、論理アドレスが５１２Ｂサイズのデータごとに割り当てられている例を示している。
【００５３】
＜通信の時のロジカル・ユニットＬＵ６７について＞  
次に、図８を参照して、通信の際のＬＵ６７について説明する。図８は、第１実施形態に係る通信時のロジカル・ユニットＬＵの詳細を示す機能ブロック図である。複数のＬＵ６７のうち、少なくとも１つ、典型的には全てが以下に図８を参照して説明する構成を有している。
【００５４】
図示するように、デバイス・サーバ７１は、管理部８１と、コマンド解析部８２と、転送要求生成部８３と、メモリ制御部８４を含んでいる。
【００５５】
管理部８１は、デバイス・サーバ７１の全体を管理する。コマンド解析部８２は、ホスト２からルータ６２を介してコマンドを受信する。コマンド解析部８２は、受信されたコマンドを解析する。コマンド制御部８２は、書き込みコマンドを受信すると、転送要求生成部８３に、転送要求の決定（生成）を要求する。この転送要求生成部８３への要求は、コマンド解析部８２が直接行なってもよいし、管理部８１により行われてもよい。転送要求生成部８３は、要求を受けると、書き込みコマンドに含まれている書き込みデータのサイズおよびアドレスに基づいて転送要求を生成する。メモリ制御部８４は、管理部８１の指示に従って、メモリ１１に対するあらゆる指示の発行を担う。
【００５６】
＜ブート動作について＞  
次に、図９を参照して、第１の実施形態に係るBoot動作について説明する。
【００５７】
図示するように、まず、ステップＳｔ１の際に、ホスト２は、デバイスに対して、Query Request UPIUを発行し、デバイスから起動のための情報（Descriptor）を要求する。
【００５８】
続いて、ステップＳｔ１．１の際に、デバイス１は、情報（Descriptor）を読み出し（READ DESCRIPTOR）、読み出したDescriptorを、UPIUを通じて、ホスト２に送信する。この際、送信される情報（Descriptor）は、パケット１０１中のＬＵＮ１０２と共に実態部１０３に含められる。
【００５９】
続いて、ステップＳｔ２の際に、ホスト２は、デバイスに対して、ブートコード（boot code）の読み出しを要求する（SCSI READ (Boot LU)）。
【００６０】
続いて、ステップＳｔ２．１の際に、デバイス１は、ブートコード（boot code）を読み出し、ホストに対して、読み出したboot codeを送信する。この際においても、送信される情報boot codeは、パケット１０１中のＬＵＮ１０２と共に実態部１０３に含められる。
【００６１】
続いて、ステップＳｔ２．１の際に、デバイス１は、全てのboot code送信後、ホスト２に対して、status信号を送信する。同様に、送信されるstatus信号は、パケット１０１中のＬＵＮ１０２と共に実態部１０３に含められる。
【００６２】
このstatus信号を受けたホスト２は、ブートコードの読み出しを完了する。
【００６３】
続いて、ステップＳｔ３の際に、ホスト２は、デバイス１に対して、Query Requestを発行し、初期化開始を指示する。この際、ホストは、UPIUを通じて、フラグ値としてbDeviceInit='1'を設定する。
【００６４】
Query Requestを受信したデバイス１は、デバイス１の初期化を開始する。
【００６５】
続いて、ステップＳｔ３．１の際に、デバイスの初期化が完了すると、デバイス１は、ホスト２に対して、Query Responseを返信し、初期化が完了できる状態であることを示す。
【００６６】
このように、第１の実施形態では、デバイス１の初期化が完了したら、デバイス１がQuery Responseを返信し、ホスト２がデバイス１に対してQuery Request を発行してUPIUを通じてデバイス１の初期化が終了したかどうかを問い合わせることを行わない。そのため、参考例のように、ホストが、デバイスの初期化が完了したかどうかをポーリングして待つ（フラグ値としてのbDeviceInit='1'のポーリング）必要がない。そのため、このポーリングをしている間、ホスト２は、デバイス１の監視のためにリソースを割り当てる必要がない。
【００６７】
換言すると、第１の実施形態は、ホスト２の側は、デバイス１の初期化が完了するまで、ポーリングをするシステムである。しかしながら、ホスト２は、初期化が完了するまでデバイス１がQuery Responseを返信しないため、ホスト２がデバイス１に対して初期化終了を問い合わせることがない。そのため、ホスト２は、デバイス１が初期化完了後に発行するQuery Responseの返信まで、何度もポーリングをする必要がなく、１度の確認のみで済む点で、メリットがある。
【００６８】
また、Query Responseの返信があってから、ホスト２が１度目に問い合わせしたときには、すでに初期化完了が確定しているため、確実に１回の問い合わせで済む点で有利である。加えて、実装を知らない汎用ホストに対しても互換性を損なわない点でも有利である。
【００６９】
続いて、ステップＳｔ４の際に、ホスト２は、デバイス１に対してフラグ値（FLAG bDeviceInit='0'）を得るためのQuery Request を発行する。
【００７０】
これに対して、ステップＳｔ４．１の際に、デバイス１は、ホスト２に対して、Query Responseを返信し、フラグ値（bDeviceInit='0'）を返信する。この際においても、送信されるフラグ値（bDeviceInit='0'）は、パケット１０１中のＬＵＮ１０２と共に実態部１０３に含められる。この際、送信されるフラグ値（bDeviceInit='0'）は、デバイス１の全体の初期化のために全てのＬＵＮ１０２に一括して送信される。
【００７１】
Query Responseを受信したホスト２は、フラグ値（bDeviceInit='0'）により、デバイス１の初期化が完了したことを検出できる。
【００７２】
＜作用効果＞  
第１の実施形態によれば、少なくとも下記（１）の効果が得られる。
【００７３】
（１）ポーリング中の負担を軽減できる。  
このように、第１の実施形態では、デバイス１の初期化が完了するまでQuery Responseを返信せず、デバイス１の初期化が完了したらデバイス１がQuery Responseを返信する。そのため、ホスト２は、デバイス１がQuery Responseを返信するまで、デバイス１に対してQuery Request を発行してUPIUを通じてデバイス１の初期化が終了したかどうかを問い合わせることを行わない。
【００７４】
そのため、参考例のように、ホスト２が、デバイスの初期化が完了したかどうかをポーリングして待つ（フラグ値としてのbDeviceInit='1'のポーリング）必要がない。そのため、このポーリングをしている間、ホスト２は、デバイス１の監視のためにリソースを割り当てる必要がない。これにより、ホスト２は、自身の処理に専念することができ、起動時間の短縮につながる。また、ポーリングの機能を削除することができるので、そのための機能を削減（コード量減、消費電力源など）することができる。
【００７５】
より具体的には、第１の実施形態では、ホスト２は、初期化要求のQuery Requestを送信して、そのQuery Responseを受信したら、初期化完了終了確認のためのQuery Requestを１回発行するだけで、デバイス１の初期化が終了したかどうかを認識することができる。
【００７６】
よって、ホスト２は、ポーリングのためのQuery Requestを１回発行するだけで、デバイス１の初期化終了を知ることができる。これにより、デバイス１は、初期化中にホストからのコマンド処理をせずに済むため、初期化中にホスト２のコマンドを処理するための機能（例えば、コード量、消費電力源等）を削減することができる。
【００７７】
このように、第１の実施形態によれば、Boot動作において、メモリ・デバイス１およびホスト・デバイス２のいずれのポーリング中の負担を軽減することができる点で有利である。
【００７８】
また、Query Responseの返信があってから、ホスト２が１度目に問い合わせしたときには、すでに初期化完了が確定しているため、確実に１回の問い合わせで済む点で有利である。
【００７９】
加えて、実装を知らない汎用ホストに対しても互換性を損なわない点でも有利である。
【００８０】
［第２の実施形態］  
次に、第２の実施形態について、図１０を用いて説明する。第２の実施形態は、ホスト２が、デバイス１が初期化を完了した後に初めてQuery Responseを返すことを認識する場合に関するものである。この説明において、上記第１の実施形態と重複する部分の詳細な説明を省略する。
【００８１】
＜ブート動作について＞  
図１０を参照して、第２の実施形態に係るＢｏｏｔ動作について説明する。
【００８２】
図示するように、第２の実施形態では、まず、ステップＳｔ１の際に、ホスト２は、デバイスに対して、Query Request UPIUを発行し、デバイスから起動のための情報（Descriptor）を要求する。
【００８３】
続いて、ステップＳｔ１．１の際に、デバイス１は、情報（Descriptor）を読み出し（READ DESCRIPTOR）、読み出したDescriptorを、UPIUを通じて、ホスト２に送信する。この際、送信される情報（Descriptor）は、パケット１０１中のＬＵＮ１０２と共に実態部１０３に含められる。
【００８４】
続いて、ホスト２は、受信したデバイス１からのデバイス情報（Device Descriptor）中のフラグ有無を読み出すことで、ポーリング動作が不要であると判断する点で、上記第１の実施形態と相違する。そのため、第１の実施形態の上記ステップＳｔ４およびＳｔ４．１をさらに省略できる。
【００８５】
その他の構成、動作等に関しては、上記第１の実施形態と実質的に同様であるため、詳細な説明を省略する。
【００８６】
＜作用効果＞  
上記のように、第２の実施形態によれば、少なくとも上記（１）と同様の効果が得られる。
【００８７】
さらに、第２の実施形態では、ステップＳｔ１の際に要求した受信したデバイス１からの情報（Device Descriptor）中のフラグ有無を読み出すことで、ポーリング動作が不要であると判断する点で、上記第１の実施形態と相違する。
【００８８】
そのため、第１の実施形態の上記ステップＳｔ４およびＳｔ４．１をさらに省略でき、さらにブート動作におけるメモリ・デバイス１およびホスト・デバイス２の負担を低減できる点で有利である。
【００８９】
このように、必要に応じて、本例を適用することが可能である。
【００９０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９１】
１…メモリ・デバイス、２…ホスト・デバイス、１１…メモリ、１２…メモリ・コントローラ。
【図１】
0005694101.tif 000002
【図２】
0005694101.tif 000003
【図３】
0005694101.tif 000004
【図４】
0005694101.tif 000005
【図５】
0005694101.tif 000006
【図６】
0005694101.tif 000007
【図７】
0005694101.tif 000008
【図８】
0005694101.tif 000009
【図９】
0005694101.tif 000010
【図１０】
0005694101.tif 000011