JP6165342B2 - エンベデッドメモリへのコマンドキューイングの提供 - Google Patents

Description

優先権の主張
本願は、参照によりその全体が本明細書に組み込まれている、2013年9月10日に出願した、“SYSTEMS AND METHODS FOR PROVIDING COMMAND QUEUING IN THE EMBEDDED MULTI-MEDIA CONTROLLER(eMMC) STANDARD”という名称の米国仮特許出願第61/875,721号の優先権を主張するものである。

本願は、参照によりその全体が本明細書に組み込まれている、2014年9月5日に出願した、“PROVIDING COMMAND QUEUING IN EMBEDDED MEMORIES”という名称の米国特許出願第14/478,032号の優先権も主張するものである。

本開示の技術は一般にエンベデッドメモリに関し、詳細には、エンベデッドメモリにコマンドキューイングを提供することに関する。

多くのモバイルデバイスは、モバイルデバイスが使用するデータおよび/またはソフトウェアを格納するために、フラッシュメモリを利用している。フラッシュメモリには、固定(エンベデッド)とリムーバブルの、2つの一般的な種類がある。リムーバブルフラッシュメモリは典型的に、リムーバブルメモリカードの形態をとり、デジタルカメラやオーディオデバイスなどのデバイスにおいて一般に使用されている。エンベデッドフラッシュメモリは一般に、モバイルデバイス内の回路基板または他の支持媒体に、はんだ付けされ、またはその他の方法で永久に固定される。

電子素子技術連合評議会(JEDEC)は、一種のエンベデッドフラッシュメモリと関連のあるエンベデッドマルチメディアカード(eMMC)標準規格の策定を担っている。eMMCとは、マルチメディアカードインターフェース、フラッシュメモリ、およびコントローラがすべて、小型のボールグリッドアレイ(BGA)パッケージに入った、エンベデッドストレージソリューションからなるアーキテクチャを表している。eMMCは現在同期プロトコルであり、ここで、ホストがデバイスから読み出すコマンドまたはデバイスに書き込むコマンドを送信する。デバイスが応答を送信し、次いで、データブロックの転送が行われる。データ転送の完了時に、ホストが別のコマンドを送信し、別の応答を受信して、別のデータ転送が行われる。この同期コマンドストラクチャは、eMMCメモリ内への、またそこから外へのデータ転送ごとに生じる。通常、コマンドおよび応答ごとに、ソフトウェアが関与する。そのようなソフトウェアは、典型的には、反応の遅いエンティティであり、コマンドおよび応答ごとにソフトウェアが関与すると、データ転送の実施遅延が増す。

eMMCの同期コマンドストラクチャとは対照的に、別のメモリ標準規格であるユニバーサルフラッシュストレージ(UFS)は、コマンドキューイング機能を用いて複数のコマンドをサポートし、マルチスレッドプログラミングパラダイムを可能にしている、よく知られた小型コンピュータシステムインターフェース(SCSI)アーキテクチャモデルおよびコマンドプロトコルを採用している。実際、コマンドキューイングにより、ホストが複数のタスクをデバイスに、デバイスによるそれらのタスクの実行に先だって送信することが可能になる。これらのタスクは、デバイス内のキューに格納される。次いで、デバイスは、デバイスが受信した複数のタスクから1つのタスクを選び、選んだタスクを実行し、その完了をホストに知らせる。

eMMC電気的標準規格5.0、2012年6月電子素子技術連合評議会(JEDEC)発行

コマンドキューイングにより、ホストのソフトウェアとデバイスのソフトウェアが、互いに待たなければならないのではなく同時に機能することができるので、データ転送が行われるバスのより効率的な使用が可能になる。eMMCは、コマンドキューイングおよびデータバスの使用効率の改善の恩恵を受けることになる。しかしながら、eMMCでは歴史的にコマンドキューイングが企図されてこなかったので、デバイスのキュー内のタスクのステータスをホストがいかにして知り得るかについて規定する必要がある。

発明の詳細な説明の中で開示する態様は、エンベデッドメモリにコマンドキューイングを提供することを含む。具体的には、本明細書に開示する態様は、キューのステータスがデバイスからホストに通信されるプロセスに関する。本開示の態様は、ホストが、進行中のデータ転送の既知の終わりに近接して、デバイス内のキューの状態を判定することができるように、エンベデッドマルチメディアカード(eMMC)標準規格のコマンドストラクチャを使用する。このようにして、ホストが、現在のデータ転送の完了後に開始すべきタスクを、現在のデータ転送がまだ進行している間に選択することができる。

この点に関して、一態様では、ホストが開示される。ホストは、eMMC標準規格に準拠したデバイスに信号を伝送し、そこから信号を受信するように構成される、トランシーバを備える。ホストは、トランシーバに動作可能に結合される、制御システムも備える。制御システムは、デバイスに、デバイス内のキューステータスレジスタ(QSR)の状態を判定するコマンドを発行するように構成される。制御システムは、デバイスから、デバイスのQSRについての情報を備える応答を受信するようにも構成される。

別の態様では、デバイスが開示される。デバイスは、eMMC標準規格に準拠したホストに信号を伝送し、そこから信号を受信するように構成される、トランシーバを備える。デバイスは、トランシーバに動作可能に結合される、制御システムも備える。制御システムは、ホストから、デバイス内のQSRの状態を判定するコマンドを受信するように構成される。制御システムはさらに、ホストに、デバイスのQSRについての情報を備える応答を伝送するようにも構成される。

別の態様では、eMMCホストを動作させる方法が開示される。本方法は、eMMCホストからデバイスに、デバイス内のQSRの状態を判定するコマンドを含む信号を伝送することを含む。本方法は、デバイスから、デバイスのQSRについての情報を備える応答を受信することも含む。

エンベデッドマルチメディアカード(eMMC)標準規格を用いた、ホストとデバイスとの間の例示的な接続のブロック図である。 割込みピンを用いた、ホストとデバイスとの間の信号のタイミング図である。 本開示の例示的な態様によるコマンドストラクチャを用いた、ホストとデバイスとの間の信号のタイミング図である。 本開示の例示的なプロセスのフローチャートである。 本開示の態様に従って動作する図1のホストおよびデバイスを含むことのできる、例示的なプロセッサベースのシステムのブロック図である。

ここで、図面を参照して、本開示のいくつかの例示的な態様について説明する。「例示的な」という用語は、本明細書では、「例(example)、例(instance)、または例(illustration)としての役割を果たすこと」を意味するために使用される。本明細書において「例示的な」として説明する任意の態様は、他の態様よりも好ましいまたは有利であると、必ずしも解釈すべきではない。

詳細な説明の中で開示する態様は、エンベデッドメモリにコマンドキューイングを提供することを含む。具体的には、本明細書に開示する態様は、キューのステータスがデバイスからホストに通信されるプロセスに関する。本開示の態様は、ホストが、進行中のデータ転送の既知の終わりに近接して、デバイス内のキューの状態を判定することができるように、エンベデッドマルチメディアカード(eMMC)標準規格のコマンドストラクチャを使用する。このようにして、ホストが、現在のデータ転送の完了後に開始すべきタスクを、現在のデータ転送がまだ進行している間に選択することができる。

ホストがタスクを生成するとき、ホストは、どれだけのデータが転送される予定であるかをアプリオリに知っている。ホストはデバイスに、データ転送をいつ開始するかについての指示も行うので、ホストは、特定のタスクに関連するデータ転送が間もなく終わろうとするときを判定することが可能である。したがって、ホストは、データ転送の完了より前のある時点で、ポーリング問合せをスケジューリングすることができる。例示的な一態様では、ポーリング問合せは、ホストからデバイスへのSEND_QUEUE_STATUSコマンド(CMD13)信号の形態をとる。デバイスが、キューステータス情報で応答する。次いで、ホストが、キュー内でどのタスクの実行の準備が整っているかに関する十分な情報を得る。現在のデータ転送の終わりに、ホストは、新たなタスクを実行するコマンドを発行することができる。この構成により、追加のピンの必要が回避される。余計なピンを回避することで、スペースおよびコストが節減する。同様に、この構成により、周期的ポーリングを利用するのではなくポーリングイベントをデータ転送の来たるべき終わりに固定することによって、ポーリング問合せの回数が減少する。すなわち、ポーリングが周期的に行われる場合、ホストは、1回のデータ転送中に、2回(またはそれ以上)ポーリングする可能性がある。対照的に、本開示では、1回のデータ転送中に(データ転送の終わりに近接して)1回のポーリングイベントしかない。余分なポーリングをなくすことにより、データバスのより効率的な使用が可能になる。

eMMCシステムにコマンドキューイングを追加することにより、デバイスが実行順序を最適化することが可能になる。そのような最適化は、電池寿命を延ばし、かつ/またはタスクの実行遅延をなくすことができる。コマンドキューイングにより、デバイスが現在のキューステータスをホストに通知することが容易になり、エラー処理が改善する。さらに、コマンドキューイングにより、コマンドのタイミング面が改善する。

この点に関して、図1は、ホスト10が導体14を介してデバイス12に結合されるブロック図である。ホスト10とデバイス12との間の通信は、2012年6月に電子素子技術連合評議会(JEDEC)によって発行された、eMMC電気的標準規格(electrical standard)5.0などのeMMC標準規格に準拠している。改訂版5.01が、2014年7月に発行されている。改訂版5.1を完成させるべく現在取組みがなされており、発行目標は2014年12月である。この標準規格のコピーが、3103 North 10th Street, Suite 240 South, Arlington VA 22201-2107に所在のJEDECから入手可能である。ホスト10は、適切な通信インターフェース18を備えるハードウェアベースのシステムである、ホストコントローラ16を含む。ホストコントローラ16は、ホストソフトウェア20と連携する。ホストコントローラ16とホストソフトウェア20とを合わせて、制御システムとなっている。

引き続き図1を参照すると、デバイス12は、適切な通信インターフェース24を備えるハードウェアベースのシステムである、コントローラ22を含む。デバイス12はさらに、メモリユニット26(たとえば、否定ANDまたはNOT AND(NAND)フラッシュストレージデバイス)も含む。デバイス12はさらに、タスクキュー28も含む。コントローラ22と、コントローラ22の動作に関連する任意のソフトウェアおよびファームウェアとを合わせて、制御システムとなっている。

JEDECに先んじて、Samsung、SanDisk、およびQualcommによる、QRDYピンを通じたコマンドキューイングを含めたいという共同提案がなされた。そのようなQRDYピンを使用すると、コマンドキューイングが可能になり得るものの、コストが増大し、かつ/またはスペースにおける不利益が課されるおそれがある。とはいえ、本開示の態様を対比する助けとなるように、QRDYピンの態様を図2に記載する。具体的には、図2は、QRDYピンの場合の対時間信号推移フロー30を示す。

この点に関して、図2は、タイミング図を示す。具体的には、ホスト10がコマンド32(C)を送信し、応答(R)34を受信する。コマンド32は、デバイス12のキュー内のタスクの実行を開始するように、デバイス12に指示するものである。応答34の後、データフロー36が開始する。データフロー36が進行している間、デバイス12が、タスクキュー28内のタスクの実行の準備を終了する。QRDYピン38が、ハイからローに遷移する(遷移40参照)。QRDYピン38のレベルが変化することにより、ホスト10がコマンド42をデバイス12に送信する。例示的な一態様では、コマンド42はCMD13である。デバイス12が、新たに準備の整ったタスクを含んだキュー状態(QS)を含むことのできる、応答44を返送する。データフロー36の終わりに、ホストが、タスクキュー28内の準備の整ったタスクのうちの1つの実行を開始するようにデバイス12に指示する、新たなコマンド46を送信する。QRDYピン38を使用すると、ホスト10が、タスクの実行の準備が整ったときを知ることが可能になる。ホスト10は、データフローの終わりを待ち、データフローの終わりにキューの状態を問い合わせ、次いで、問い合わせた後に、タスク実行コマンドを発行しなければならないのではなく、適切な実行コマンドを既存のデータフローの終わりに発行することができる。

QRDYピン38の追加により、コマンドキューイングと、それに見合った時間の節減およびデータバスの効率的な使用が容易になるものの、ピンの追加により、追加の導体を新たなピンまで配線しなければならないので、製造費が増し、設計における不利益が課される。さらに、ピンの追加により、そのピンのあるデバイスおよびホストの実装面積が、追加のピンのない同様のデバイス(およびホスト)に比べて増す。したがって、QRDYピン38の追加は一般に望ましくない。

本開示の態様は、ホスト10が有している、CMD13と結び付けられた現在アクティブなデータ転送に関する知識を利用して、デバイス12のキューのステータスに関する適時の更新を確実にすることによって、QRDYピン38の使用を回避する。本開示のプロセスを容易にする助けとなるように、ホストコントローラインターフェース(HCI)レジスタマップのベンダ固有の範囲内で、さらなるレジスタを追加することができる。追加のレジスタについて取り上げる前に、プロセスの概要を示す。

この点に関して、図3は、対時間信号推移フロー50を示す。信号は、ホスト10がコマンド52をデバイス12に送信し、応答54を受信することから開始する。コマンド52は、準備の整ったタスクを実行するように、デバイス12に指示するものである。デバイス12が準備の整ったタスクを実行し、データ転送56が開始する。ホスト10は、データ転送56の一部としてどれだけのデータが転送されるかをアプリオリに知っており、したがって、データ転送56の終わり58がいつ生じるかを知っている(または計算することができる)。したがって、ホスト10の制御システムが、データ転送56の終わり58がいつ生じるかを知ることができるので、ホスト10の制御システムは、終わり58より前の、ただしそれに近接した時間を選択することができる。ホスト10の制御システムが、この選択した時間に、デバイス12にCMD13(60)を送信する。CMD13(60)は、タスクキュー28の状態に関する問合せを含む。デバイス12が、実行の準備の整ったすべてのタスクについての情報を含んだタスクキュー28の状態についての情報を有する、QS信号62で応答する。次いで、ホスト10が、準備の整ったタスクに基づいて、タスクを実行するコマンド64を発行し、プロセスが反復する。

対時間信号推移フロー50の背景にある、プロセス98のより確かなフローチャートを、図4を参照して示す。プロセス98は、ホスト10が、デバイス12によって実行するための1つまたは複数のタスクを生成する(ブロック100)ことから開始する。ホスト10が、タスクをキューに入れ(ブロック102)、タスクをキューに入れるコマンドを用いて、1つまたは複数のタスクをデバイス12に渡す(ブロック104)。デバイス12が、タスクをキューに入れ、タスクの実行の準備を開始する(ブロック106)。ある時点で、デバイス12が、1つまたは複数のタスクの実行の準備を終了し(ブロック108)、デバイス12がタスクキュー28を更新する。

ホスト10が最初にCMD13をデバイス12に送信し、タスクの準備が整っていることを知る(ブロック110)。ホスト10がデバイス12に、準備の整ったタスクを実行するように指令する(ブロック112)。デバイス12がタスクを実行し、データ転送56が行われる。その間、デバイス12が引き続き、キュー内のタスクの実行の準備を整える(ブロック114)。このようにして、1つまたは複数のさらなるタスクの準備を整えることができる。

ホスト10が、データ転送56の終わり58がいつ生じるかについての、そのアプリオリの知識に基づいて、データ転送56の終わり58より前に、ただしそれに近接して、CMD13(60)を送信する(ブロック116)。デバイス12が、ホスト10に提供された最終の更新以降に実行の準備の整った任意のタスクを含む、キューステータスメッセージで応答する(ブロック118)。ブロック118において実行の準備の整ったタスクがない場合、システムはブロック108に戻り、タスクの準備が整うまで周期的ポーリングを実行する。しかしながら、実行の準備の整ったタスクがある場合、データ転送56が完了し(ブロック120)、ホスト10が、準備の整ったタスクを実行するコマンド(CMD46またはCMD47)64をデバイス12に送信する(ブロック122)。次いで、述べたように、デバイス12がタスクを実行して、プロセス98が反復する。

上述したように、いくつかのレジスタをコマンドキューイングHCI(Command Queueing HCI)として含めることができる。これらのレジスタについて、以下のTable 1(表1)に要約する。

これらについては、仮特許出願の中で詳細に説明してきたが、特に興味深いのは、Send Status Configuration 1レジスタのSend Status Command Idle Timerフィールドであり、これは、コマンドキューステータスを確認するSTATUSコマンドを用いてデバイス12にポーリングするための時間周期を、ホストコントローラ16が知ることができるようにするものである。周期的ポーリングは、デバイス12内でタスクがペンディングになっているが、データ転送が行われないときに使用される。さらに、本開示の範囲から逸脱することなく、実装の違いが、名称(たとえば“Command Queueing Send Status Configuration 1”)の違いにより異なるレジスタを指す場合があることに留意されたい。

やはり特に興味深いのは、Send Status Configuration 1レジスタのSend Status Command Block Counterフィールドであり、これは、コマンドキューステータスを確認するSTATUSコマンドをどのブロックにおいて送信するかを、ホストコントローラ16に通知するものである。ホスト10は、ステータスコマンドBLOCK_CNT-1ブロックを転送の終わりの前に送信する。

図示していないが、制御システムは、タスクを破棄するコマンドを含むことのできるキュー管理要求を発行することができる。

本明細書に開示した態様による、eMMC標準規格にコマンドキューイングを提供するためのシステムおよび方法は、任意のプロセッサベースのデバイスに提供することもでき、あるいはそれに統合することもできる。例として、それらに限定されないが、セットトップボックス、エンターテインメントユニット、ナビゲーションデバイス、通信デバイス、固定位置データユニット、モバイル位置データユニット、モバイル電話、セルラー電話、コンピュータ、ポータブルコンピュータ、デスクトップコンピュータ、携帯情報端末(PDA)、モニタ、コンピュータモニタ、テレビ、チューナ、ラジオ、衛星ラジオ、音楽プレーヤ、デジタル音楽プレーヤ、ポータブル音楽プレーヤ、デジタルビデオプレーヤ、ビデオプレーヤ、デジタルビデオディスク(DVD)プレーヤ、およびポータブルデジタルビデオプレーヤがある。

この点に関して、図5は、図1に示すホスト10およびデバイス12を用いることのできる、プロセッサベースのシステム140の一例を示す。この例では、プロセッサベースのシステム140は、1つまたは複数のプロセッサ144をそれぞれが含む、1つまたは複数の中央処理装置(CPU)142を含む。CPU142は、マスタデバイスとすることができ、ソフトウェア20を実行することができる。CPU142は、プロセッサ144に結合された、一時的に格納されたデータに高速にアクセスするためのキャッシュメモリ146を有することができる。CPU142は、システムバス148に結合され、プロセッサベースのシステム140内に含まれるデバイスを相互に結合することができる。よく知られているように、CPU142は、これらの他のデバイスと、システムバス148を通じてアドレス情報、制御情報、およびデータ情報をやり取りすることによって通信する。たとえば、CPU142は、バストランザクション要求を、デバイス12とすることのできるメモリシステム150に通信することができる。トランザクション要求は、ホストコントローラ16とすることのできるメモリコントローラ149を経由することができる。図5には示していないが、複数のシステムバス148を設けることができ、その場合、各システムバス148が、異なるファブリックを構成する。

システムバス148に他のデバイスを接続することができる。図5に示すように、これらのデバイスは、例として、メモリシステム150、1つまたは複数の入力デバイス152、1つまたは複数の出力デバイス154、1つまたは複数のネットワークインターフェースデバイス156、および1つまたは複数のディスプレイコントローラ158を含むことができる。入力デバイス152は、入力キー、スイッチ、音声プロセッサなどを含むがそれらに限定されない、任意のタイプの入力デバイスを含むことができる。出力デバイス154は、オーディオインジケータ、ビデオインジケータ、他の視覚的インジケータなどを含むがそれらに限定されない、任意のタイプの出力デバイスを含むことができる。ネットワークインターフェースデバイス156は、ネットワーク160への、またそこからの、データのやり取りを可能にするように構成される、任意のデバイスとすることができる。ネットワーク160は、有線ネットワークまたはワイヤレスネットワーク、プライベートネットワークまたは公衆ネットワーク、ローカルエリアネットワーク(LAN)、ワイドLAN、ワイヤレスLAN、およびインターネットを含むがそれらに限定されない、任意のタイプのネットワークとすることができる。ネットワークインターフェースデバイス156は、所望の任意のタイプの通信プロトコルをサポートするように構成することができる。

CPU142は、1つまたは複数のディスプレイ162に送信された情報を制御するために、システムバス148を通じてディスプレイコントローラ158にもアクセスするように構成することができる。ディスプレイコントローラ158は、表示すべき情報を処理してディスプレイ162に適した形式にする1つまたは複数のビデオプロセッサ164を介して、表示すべき情報をディスプレイ162に送信する。ディスプレイ162には、陰極線管(CRT)、発光ダイオードディスプレイ(LED)、液晶ディスプレイ(LCD)、プラズマディスプレイなどを含むがそれらに限定されない、任意のタイプのディスプレイを含むことができる。

本明細書に開示した態様に関連して説明した、様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムは、電子的ハードウェアとして実装することもでき、メモリまたは別のコンピュータ可読媒体に格納され、プロセッサまたは他の処理デバイスによって実行される命令として実装することもでき、あるいはその両方の組合せとして実装することもできることを、当業者ならさらに理解するであろう。本明細書において説明したホストおよびデバイスは、例として、任意の回路、ハードウェア構成要素、集積回路(IC)、またはICチップ内で用いることができる。本明細書に開示したメモリは、どんなタイプおよびサイズのメモリでもよく、所望の任意のタイプの情報を格納するように構成することができる。この交換可能性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップについては上記で、それらの機能の観点から一般的に説明してきた。そのような機能がどのように実装されるかは、特定の適用分野、設計上の選択、および/またはシステム全体に課せられる設計制約によって変わる。当業者なら、説明した機能を、特定の各適用分野について様々な形で実装することができるが、そのような実装形態の決定は、本開示の範囲からの逸脱を生じさせるものと解釈すべきではない。

本明細書に開示した態様に関連して説明した、様々な例示的な論理ブロック、モジュール、および回路は、プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、ディスクリートのゲート論理回路もしくはトランジスタ論理回路、ディスクリートのハードウェア構成要素、または本明細書において説明した機能を実施するように設計された、それらの任意の組合せを用いて実装してもよく、実施してもよい。プロセッサは、マイクロプロセッサとすることができるが、代替手段として、プロセッサは、どんな従来型のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンでもよい。プロセッサは、コンピューティングデバイス同士の組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、1つもしくは複数のマイクロプロセッサとDSPコアとの併用、または他の任意のそのような構成として、実装することもできる。

本明細書に開示した態様は、ハードウェアとして具現化することができ、またハードウェアに格納される命令として具現化することができ、命令は、たとえば、ランダムアクセスメモリ(RAM)、フラッシュメモリ、リードオンリーメモリ(ROM)、電気的プログラマブルROM(EPROM)、電気的消去可能プログラマブルROM(EEPROM)、レジスタ、ハードディスク、リムーバブルディスク、CD-ROM、または当技術分野で知られる、他の任意の形態のコンピュータ可読媒体内に存在してよい。例示的な記憶媒体がプロセッサに、プロセッサがその記憶媒体から情報を読み出し、またそこに情報を書き込むことができるように結合される。代替手段として、記憶媒体がプロセッサと一体をなしてもよい。プロセッサおよび記憶媒体は、ASIC内に存在してよい。ASICは、遠隔局内に存在してよい。代替手段として、プロセッサおよび記憶媒体が、ディスクリートの構成要素として遠隔局内、基地局内、またはサーバ内に存在してよい。

本明細書における例示的な態様のいずれかにおいて説明した動作ステップが、例および議論を提供するために説明されていることにも留意されよう。説明した動作は、示したシーケンス以外の多数の異なるシーケンスで実施されてよい。さらに、単一の動作ステップとして説明した動作は、実際には、いくつかの異なるステップとして実施されてよい。さらに、例示的な態様において論じた1つまたは複数の動作ステップが、組み合わされてもよい。当業者には容易に明らかとなるように、フローチャート図中に示した動作ステップに、多数の異なる修正が施されてもよいことを理解されたい。情報および信号を、様々な異なる技術および技法のいずれかを用いて表現できることも、当業者なら理解されよう。たとえば、上記の説明全体にわたって参照されることのあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップを、電圧、電流、電磁波、磁場もしくは磁性粒子、光学場もしくは光粒子、またはそれらの任意の組合せによって、表現することができる。

本開示についての先の説明は、いかなる当業者でも本開示を作製または使用できるようにするために提供されている。本開示に対する様々な修正形態が、当業者には容易に明らかとなり、本明細書において定める一般的な原理は、本開示の趣旨または範囲から逸脱することなく、他の変形形態に適用することができる。したがって、本開示は、本明細書において説明した例および設計に限定されるものではなく、本開示には、本明細書に開示した原理および新規な特徴に一致する最も広い範囲が与えられるべきである。

10 ホスト
12 デバイス
14 導体
16 ホストコントローラ
18 通信インターフェース
20 ホストソフトウェア
22 コントローラ
24 通信インターフェース
26 メモリユニット
28 タスクキュー
30 対時間信号推移フロー
32 コマンド
34 応答
36 データフロー
38 QRDYピン
40 遷移
42 コマンド
44 応答
46 コマンド
50 対時間信号推移フロー
52 コマンド
54 応答
56 データ転送
58 終わり
60 CMD13
62 QS信号
64 コマンド
98 プロセス
140 プロセッサベースのシステム
142 中央処理装置(CPU)
144 プロセッサ
146 キャッシュメモリ
148 システムバス
149 メモリコントローラ
150 メモリシステム
152 入力デバイス
154 出力デバイス
156 ネットワークインターフェースデバイス
158 ディスプレイコントローラ
160 ネットワーク
162 ディスプレイ
164 ビデオプロセッサ

Claims (23)

1. ホストであって、
   エンベデッドマルチメディアカード(eMMC)標準規格に準拠したデバイスに信号を伝送し、かつそこから信号を受信するように構成されるトランシーバと、
   前記トランシーバに動作可能に結合される制御システムであって、
   前記デバイスに、前記デバイス内のキューステータスレジスタ(QSR)の状態を判定するコマンドを発行し、
   前記デバイスからの現在のデータ転送の来たるべき終わりを判定し、
   前記来たるべき終わりより前に、前記デバイスから、前記デバイスの前記QSRについての情報を備える応答を受信する
   ように構成される、制御システムと
   を備える、ホスト。
2. 前記制御システムが、前記来たるべき終わりに時間的に近接して、かつそれより前に、前記コマンドを発行するようにさらに構成される、請求項1に記載のホスト。
3. 前記制御システムが、タスクをキューに入れるコマンドを発行するようにさらに構成される、請求項1に記載のホスト。
4. 前記制御システムが、キュー管理要求を発行するようにさらに構成される、請求項1に記載のホスト。
5. 前記キュー管理要求が、タスクを破棄するコマンドである、請求項4に記載のホスト。
6. 前記制御システムが、エグゼキュートリードタスクコマンドを発行するようにさらに構成される、請求項1に記載のホスト。
7. 前記制御システムが、エグゼキュートライトタスクコマンドを発行するようにさらに構成される、請求項1に記載のホスト。
8. セットトップボックス、エンターテインメントユニット、ナビゲーションデバイス、通信デバイス、固定位置データユニット、モバイル位置データユニット、モバイル電話、セルラー電話、コンピュータ、ポータブルコンピュータ、デスクトップコンピュータ、携帯情報端末(PDA)、モニタ、コンピュータモニタ、テレビ、チューナ、ラジオ、衛星ラジオ、音楽プレーヤ、デジタル音楽プレーヤ、ポータブル音楽プレーヤ、デジタルビデオプレーヤ、ビデオプレーヤ、デジタルビデオディスク(DVD)プレーヤ、およびポータブルデジタルビデオプレーヤからなるグループから選択されたデバイスに統合される、請求項1に記載のホスト。
9. デバイスであって、
   エンベデッドマルチメディアカード(eMMC)標準規格に準拠したホストに信号を伝送し、かつそこから信号を受信するように構成されるトランシーバと、
   前記トランシーバに動作可能に結合される制御システムであって、
   前記ホストから、前記デバイス内のキューステータスレジスタ(QSR)の状態を判定するコマンドを受信し、
   前記デバイスからの現在のデータ転送の来たるべき終わりより前に、前記デバイスの前記QSRについての情報を備える応答を前記ホストに伝送する
   ように構成される、制御システムと
   を備える、デバイス。
10. 前記制御システムが、前記応答を伝送する前に、前記デバイス内の前記QSRの前記状態を判定するようにさらに構成される、請求項9に記載のデバイス。
11. 前記制御システムが、タスクをキューに入れるコマンドを受信するようにさらに構成される、請求項9に記載のデバイス。
12. 前記制御システムが、キュー管理要求を受信するようにさらに構成される、請求項9に記載のデバイス。
13. 前記キュー管理要求が、タスクを破棄するコマンドである、請求項12に記載のデバイス。
14. 前記制御システムが、エグゼキュートリードタスクコマンドを受信するようにさらに構成される、請求項9に記載のデバイス。
15. 前記制御システムが、エグゼキュートライトタスクコマンドを受信するようにさらに構成される、請求項9に記載のデバイス。
16. エンベデッドマルチメディアカード(eMMC)ホストを動作させる方法であって、
    eMMCホストからデバイスに、前記デバイス内のキューステータスレジスタ(QSR)の状態を判定するコマンドを含む信号を伝送するステップと、
    前記デバイスからの現在のデータ転送の来たるべき終わりを判定するステップと、
    前記来たるべき終わりより前に、前記デバイスの前記QSRについての情報を備える応答を前記デバイスから受信するステップと
    を含む、方法。
17. 前記来たるべき終わりに時間的に近接して、かつそれより前に、前記コマンドを発行するステップをさらに含む、請求項16に記載の方法。
18. 前記来たるべき終わりの前に前記応答を受信するステップをさらに含む、請求項17に記載の方法。
19. タスクをキューに入れるコマンドを発行するステップをさらに含む、請求項16に記載の方法。
20. キュー管理要求を発行するステップをさらに含む、請求項16に記載の方法。
21. 前記キュー管理要求を発行するステップが、前記デバイスにタスクを破棄するように指令するステップを含む、請求項20に記載の方法。
22. エグゼキュートリードタスクコマンドを発行するステップをさらに含む、請求項16に記載の方法。
23. エグゼキュートライトタスクコマンドを発行するステップをさらに含む、請求項16に記載の方法。