(57)【要約】  揮発性メモリ保守イベントをスケジューリングするためのシステム、方法、およびコンピュータプログラムを開示する。一実施形態は、メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対する保守イベントを実行するためにメモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、メモリコントローラが処理ユニットに割込み信号を提供するステップと、保守イベントの優先順位を決定するステップと、優先順位に従って保守イベントをスケジュールするステップとを含む方法である。
2018508884.tif 000002
【特許請求の範囲】
【請求項１】
揮発性メモリ保守イベントをスケジュールするための方法であって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するために前記メモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、
前記メモリコントローラが処理ユニットに割込み信号を提供するステップと、
前記保守イベントの優先順位を決定するステップと、
前記優先順位に従って前記保守イベントをスケジュールするステップと
を含む、方法。
【請求項２】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するステップ
をさらに含む、請求項1に記載の方法。
【請求項３】
前記保守イベントを実行することなく前記ToSウィンドウが終了したと決定するステップと、
前記処理ユニット上のトラフィックをストールするステップと、
前記揮発性メモリデバイスに対して前記保守イベントを実行するステップと
をさらに含む、請求項1に記載の方法。
【請求項４】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項1に記載の方法。
【請求項５】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項1に記載の方法。
【請求項６】
前記保守イベントの前記優先順位を前記決定するステップが、ルックアップテーブルにアクセスし、保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて前記優先順位を選択するステップを含む、請求項1に記載の方法。
【請求項７】
前記保守イベントを前記スケジュールするステップが、カーネルスケジューラに関連する入力キューにサービススレッドを追加するステップを含む、請求項1に記載の方法。
【請求項８】
揮発性メモリ保守イベントをスケジュールするためのシステムであって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するための手段と、
処理ユニットに割込み信号を提供するための手段と、
前記保守イベントの優先順位を決定するための手段と、
前記優先順位に従って前記保守イベントをスケジュールするための手段と
を含む、システム。
【請求項９】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するための手段
をさらに含む、請求項8に記載のシステム。
【請求項１０】
前記保守イベントを実行することなく前記ToSウィンドウが終了したと決定するための手段と、
前記処理ユニット上のトラフィックをストールするための手段と、
前記揮発性メモリデバイスに対して前記保守イベントを実行するための手段と
をさらに含む、請求項8に記載のシステム。
【請求項１１】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項8に記載のシステム。
【請求項１２】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項8に記載のシステム。
【請求項１３】
前記保守イベントの前記優先順位を決定するための前記手段が、
ルックアップテーブルにアクセスし、保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて前記優先順位を選択するための手段
を含む、請求項8に記載のシステム。
【請求項１４】
前記保守イベントをスケジュールするための前記手段が、
カーネルスケジューラに関連する入力キューにサービススレッドを追加するための手段
を含む、請求項8に記載のシステム。
【請求項１５】
メモリ内で具現化され、揮発性メモリ保守イベントをスケジュールするためにプロセッサによって実行可能である、コンピュータプログラムであって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定することと、
処理ユニットに割込み信号を提供することと、
前記保守イベントの優先順位を決定することと、
前記優先順位に従って前記保守イベントをスケジュールすることと
を行うように構成される論理手段を含む、コンピュータプログラム。
【請求項１６】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行する
ように構成される論理手段をさらに含む、請求項15に記載のコンピュータプログラム。
【請求項１７】
前記スケジュールされた保守イベントが前記ToSウィンドウの間に実行されていないと決定することと、
前記処理ユニット上のトラフィックをストールすることと、
前記揮発性メモリデバイスに対して前記保守イベントを実行することと
を行うように構成される論理手段をさらに含む、請求項15に記載のコンピュータプログラム。
【請求項１８】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項15に記載のコンピュータプログラム。
【請求項１９】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項15に記載のコンピュータプログラム。
【請求項２０】
前記保守イベントの前記優先順位を決定するように構成される前記論理手段が、ルックアップテーブルにアクセスし、保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて前記優先順位を選択するように構成される論理手段を含む、請求項15に記載のコンピュータプログラム。
【請求項２１】
前記保守イベントをスケジュールするように構成される前記論理手段が、カーネルスケジューラに関連する入力キューにサービススレッドを追加するように構成される論理手段を含む、請求項15に記載のコンピュータプログラム。
【請求項２２】
揮発性メモリ保守イベントをスケジュールするためのシステムであって、
ダイナミックランダムアクセスメモリ(DRAM)デバイスと、
処理デバイス、およびメモリデータインターフェースを介して前記DRAMデバイスに電気的に結合されるDRAMコントローラを含むシステムオンチップ(SoC)であって、前記DRAMコントローラが、前記DRAMデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するように構成されるスケジューラモジュールを含み、前記ToSウィンドウが、前記処理デバイスに提供される割込み信号、および前記保守を実行するためのデッドラインによって定義される、SoCと、
前記処理ユニットとを含み、前記処理ユニットが、
前記DRAMコントローラから前記割込み信号を受信し、
前記割込み信号に応答して、前記保守イベントの優先順位を決定し、
前記優先順位に従って前記保守イベントをスケジュールする
ように構成される、システム。
【請求項２３】
前記処理ユニットが、前記ToSウィンドウの間に前記DRAMデバイスに対して前記保守イベントの実行を開始するようにさらに構成される、請求項22に記載のシステム。
【請求項２４】
前記DRAMコントローラが、前記保守イベントが実行されることなく前記ToSウィンドウが終了したかどうかを決定するためのタイマを含む、請求項22に記載のシステム。
【請求項２５】
前記スケジュールされた保守イベントが前記処理デバイスによって実行されることなく前記ToSウィンドウが終了する場合、前記DRAMコントローラが、前記保守イベントを実行するために介入する、請求項22に記載のシステム。
【請求項２６】
前記DRAMコントローラが、前記処理デバイス上のトラフィックをストールすることによって前記保守イベントを実行する、請求項25に記載のシステム。
【請求項２７】
前記保守イベントが、前記DRAMデバイスを定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項22に記載のシステム。
【請求項２８】
前記処理デバイスが、ルックアップテーブルにアクセスし、保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記DRAMデバイスの現在の温度のうちの1つまたは複数に基づいて前記優先順位を選択することによって、前記保守イベントの前記優先順位を決定する、請求項22に記載のシステム。
【請求項２９】
前記保守イベントが、カーネルスケジューラに関連する入力キューにサービススレッドを追加することによってスケジュールされる、請求項22に記載のシステム。
【請求項３０】
前記DRAMデバイスおよび前記SoCが、ポータブルコンピューティングデバイスに設けられる、請求項22に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、マルチプロセッサシステムにおける揮発性メモリ保守イベントのスケジューリングに関する。
【背景技術】
【０００２】
ポータブルコンピューティングデバイス(たとえば、セルラー電話、スマートフォン、タブレットコンピュータ、携帯情報端末(PDA)、および携帯ゲーム機)および他のコンピューティングデバイスは、ますます拡大する数々の機能およびサービスを提供し続けており、ユーザには情報、リソース、および通信へのかつてないレベルのアクセスが提供されている。これらのサービス拡張とペースを合わせるために、そのようなデバイスは、より強力、かつより複雑になってきた。ここで、ポータブルコンピューティングデバイスには、一般に、単一の基板上に組み込まれた1つまたは複数のチップ構成要素(たとえば、1つまたは複数の中央処理ユニット(CPU)、グラフィックス処理ユニット(GPU)、デジタル信号プロセッサなど)を含む、システムオンチップ(SoC)が含まれる。SoCは、高性能データおよび制御インターフェースを介して、ダイナミックランダムアクセスメモリ(DRAM)などの、1つまたは複数の揮発性メモリデバイスに結合されてもよい。
【０００３】
高性能DRAMメモリは、一般に、様々なタイプのハードウェア保守イベントが実行されることを必要とする。たとえば、比較的高いクロック周波数(たとえば、GHzクロック周波数)においてインターフェースのエラーのない動作を提供するために、定期的な較正およびトレーニングが実行される場合がある。メモリデータの各ビットは、チップ上の小型キャパシタに電荷の有無として記憶されるので、メモリリフレッシュが、DRAMメモリの動作中に必要とされるバックグラウンド保守プロセスである。時間の経過とともに、メモリセル内の電荷は漏出し、したがってリフレッシュされることがなければ、記憶されたデータは最終的に失われることになる。これを防止するために、DRAMコントローラが、定期的に各セルを読み出し、これを再書き込みし、キャパシタ上の電荷をその元のレベルに戻す。
【０００４】
これらのハードウェア保守イベントは、CPUトラフィックを望ましくなく遮る場合がある。たとえば、既存のシステムでは、ハードウェア保守イベントは、メモリコントローラによって制御される独立したイベントであり、これらはアクティブCPUプロセスとこれらの定期的な独立したDRAMハードウェアイベントとの間でメモリアクセス衝突を生じる可能性がある。衝突が発生するとき、CPUプロセスは、DRAMハードウェアイベントがサービスされている(service)間、一時的にストールする場合がある。DRAMにサービスすることはまた、CPUプロセスが使用している、開いているページを、閉じるまたはリセットする場合もある。CPUプロセスをストールすることは望ましくなく、したがって、DRAMハードウェアイベントは、一般的には個々に行われる。SoCハードウェアは、DRAMハードウェアイベントを延期する能力を有する場合があるが、それは一般的には非常に短い時間期間(たとえば、ナノ秒レベル)の間だけである。その結果、アクティブCPUプロセスは、多数の個々のDRAMハードウェアイベントによって引き起こされる確率的ブロキングによる望ましくない非効率を招く場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、定期的な揮発性メモリ保守イベントによって引き起こされるメモリアクセス衝突を減少させ、CPUプロセスメモリ効率を向上させるためのシステムおよび方法を提供する必要がある。
【課題を解決するための手段】
【０００６】
揮発性メモリ保守イベントをスケジューリングするためのシステム、方法、およびコンピュータプログラムを開示する。一実施形態は、メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対する保守イベントを実行するためにメモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、メモリコントローラが処理ユニットに割込み信号を提供するステップと、保守イベントの優先順位を決定するステップと、優先順位に従って保守イベントをスケジュールするステップとを含む方法である。
【０００７】
別の実施形態は、ダイナミックランダムアクセスメモリ(DRAM)デバイスと、システムオンチップ(SoC)とを含むシステムである。SoCは、処理デバイスと、メモリデータインターフェースを介してDRAMデバイスに電気的に結合されるDRAMコントローラとを含む。DRAMコントローラは、DRAMデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するように構成されるスケジューラモジュールを含む。ToSウィンドウは、処理デバイスに提供される割込み信号、および保守を実行するためのデッドラインによって定義される。処理ユニットは、DRAMコントローラから割込み信号を受信する。割込み信号に応答して、処理ユニットは、保守イベントの優先順位を決定する。保守イベントは、優先順位に従ってスケジュールされる。
【０００８】
図の中では、別段に示されていない限り、様々な図の全体を通して、同様の参照番号は同様の部分を指す。"102A"または"102B"などの文字指定を伴う参照番号の場合、文字指定は、同じ図に存在している2つの同様の部分または要素を区別することができる。参照番号がすべての図において同じ参照番号を有するすべての部分を含むことが意図されるとき、参照番号に対する文字指定は省略される場合がある。
【図面の簡単な説明】
【０００９】
【図１】揮発性メモリ保守イベントをスケジュールするためのシステムの一実施形態のブロック図である。
【図２】図1のシステムの構成要素および動作を示すブロック/流れ図である。
【図３】図1および図2のシステム内でDRAM保守イベントをスケジュールするための方法の一実施形態を示すフローチャートである。
【図４】DRAM保守イベントをスケジュールするためのタイムオブサービス(ToS)ウィンドウを示すタイムラインである。
【図５】優先順位表に従って、CPUスレッドA、B、およびC、ならびにDRAM保守イベントをスケジュールするためのシステムの別の実施形態を示すブロック/流れ図である。
【図６】カーネルスケジューラを介してスケジュールせずに、図5のシステム内でDRAM保守イベントを定期的に実行するための方法の一実施形態を示すタイムラインである。
【図７】優先順位表に従ってDRAM保守イベントをスケジュールするための方法の一実施形態を示すタイムラインである。
【図８】優先順位表に従ってDRAM保守イベントをスケジュールするためのシステムの別の実施形態を示すブロック/流れ図である。
【図９】DRAM保守イベントをスケジュールするための優先順位表を生成するための方法の一実施形態を示すフローチャートである。
【図１０】DRAM保守イベントの優先順位を決定するための優先順位表の例示的な実施形態を示す図である。
【図１１】ToSウィンドウの間に実行されるDRAMリフレッシュイベントを示すタイムラインである。
【図１２】ToSウィンドウが終了した後にDRAMリフレッシュイベントを実行するためのハードウェア介入方法の一実施形態を示すタイムラインである。
【図１３】DRAM保守イベントをスケジュールするためのシステムおよび方法を組み込む場合があるポータブルコンピューティングデバイスの一実施形態のブロック図である。
【図１４】マルチプロセッサSoCに揮発性メモリ保守イベントをスケジュールするためのシステムの別の実施形態のブロック図である。
【図１５】図14のDRAMコントローラ内の決定モジュールの一実施形態を示す、組み合わされた流れ/ブロック図である。
【図１６】図14のマルチプロセッサSoC内でDRAM保守イベントをスケジュールするための方法の一実施形態を示すフローチャートである。
【図１７】図14のマルチプロセッサSoC内でDRAM保守イベントを独立してスケジュールおよび制御するための方法の一実施形態を示すタイムラインである。
【図１８】図15の決定優先順位表の一実施形態を示す表である。
【図１９】図14のプロセッサの各々によって独立して生成される通知の例示的な実装形態を示すデータ図である。
【発明を実施するための形態】
【００１０】
「例示的」という語は、本明細書では「例、事例、または例示としての役割を果たすこと」を意味するために使用される。「例示的」として本明細書において説明されるいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるべきでない。
【００１１】
本明細書では、「アプリケーション」または「イメージ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなどの、実行可能なコンテンツを有するファイルを含む場合もある。加えて、本明細書で参照される「アプリケーション」は、オープンされる必要があり得るドキュメントまたはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含む場合もある。
【００１２】
「コンテンツ」という用語は、オブジェクトコード、スクリプト、バイトコード、マークアップ言語ファイル、およびパッチなどの、実行可能コンテンツを有するファイルを含む場合もある。加えて、本明細書で参照される「コンテンツ」は、オープンされる必要があり得る文書またはアクセスされる必要がある他のデータファイルなどの、本質的に実行可能でないファイルを含む場合もある。
【００１３】
「構成要素」、「データベース」、「モジュール」、「システム」などの用語は、本明細書で使用されるとき、ハードウェア、ファームウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すものとする。たとえば、構成要素は、限定はしないが、プロセッサ上で実行されているプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行のスレッド、プログラム、および/またはコンピュータであってもよい。例として、コンピューティングデバイス上で実行されるアプリケーションとコンピューティングデバイスの両方が構成要素であってもよい。1つまたは複数の構成要素は、プロセスおよび/または実行のスレッド内に存在してもよく、構成要素は、1つのコンピュータ上に局在化されてもよく、および/または2つ以上のコンピュータ間に分散されてもよい。さらに、これらの構成要素は、様々なデータ構造を記憶した様々なコンピュータ可読媒体から実行されてもよい。構成要素は、1つまたは複数のデータパケット(たとえば、ローカルシステム、分散システム内の別の構成要素と、および/またはインターネットなどのネットワークにわたって他のシステムと信号により対話する、1つの構成要素からのデータ)を有する信号に従って、ローカルプロセスおよび/またはリモートプロセスによって通信してもよい。
【００１４】
この説明において、「通信デバイス」、「ワイヤレスデバイス」、「ワイヤレス電話」、「ワイヤレス通信デバイス」、および「ワイヤレスハンドセット」という用語は、互換的に使用される。第3世代("3G")ワイヤレス技術および第4世代("4G")が出現したことによって、利用可能な帯域幅が拡大されたので、より多様なワイヤレス能力を備えた、より持ち運びしやすいコンピューティングデバイスが可能になった。したがって、ポータブルコンピューティングデバイスには、セルラー電話、ページャ、PDA、スマートフォン、ナビゲーションデバイス、またはワイヤレス接続もしくはワイヤレスリンクを有するハンドヘルドコンピュータが含まれる場合がある。
【００１５】
図1は、メモリコントローラを介して揮発性メモリハードウェア保守イベントのカーネルスケジューリングを提供するためのシステム100の一実施形態を示す。システム100は、パーソナルコンピュータと、ワークステーションと、サーバと、セルラー電話、携帯情報端末(PDA)、ポータブルゲームコンソール、またはタブレットコンピュータなどのポータブルコンピューティングデバイス(PCD)とを含む、任意のコンピューティングデバイスに実装される場合がある。システム100は、1つまたは複数のメモリデバイスに電気的に結合されるシステムオンチップ(SoC)102を含む。メモリデバイスは、揮発性メモリ(たとえば、ダイナミックランダムアクセスメモリ(DRAM)104)と、不揮発性メモリ118とを含んでもよい。DRAM104は、高性能データバス107および制御バス105を介してSoC102に電気的に結合されてもよい。
【００１６】
SoC102は、様々なオンチップまたはオンダイ構成要素を含む。図1の実施形態では、SoC102は、SoCバス116を介して相互接続された、1つまたは複数の処理デバイス(たとえば、中央処理装置(CPU)106、グラフィックス処理装置(GPU)、デジタル信号プロセッサ(DSP)など)と、DRAMコントローラ108と、スタティックランダムアクセスメモリ(SRAM)110と、読取り専用メモリ(ROM)112と、ストレージコントローラ114とを含む。ストレージコントローラ114は、不揮発性メモリ118に結合され、関連するメモリトランザクションを制御する。不揮発性メモリ118は、たとえば、フラッシュメモリ、フラッシュドライブ、セキュアデジタル(SD)カード、ソリッドステートドライブ(SSD)、または他のタイプなど、任意の不揮発性メモリを含む場合があることを諒解されたい。CPU106は、現在のCPU処理負荷を決定するための1つまたは複数のセンサ126を含んでもよい。DRAM104は、DRAM104の温度を決定するための1つまたは複数の温度センサ128を含んでもよい。
【００１７】
DRAMコントローラ108は、様々なDRAMハードウェア保守イベントをスケジュール、制御、および実行するための様々なモジュール130を含む。下記でより詳細に説明するように、DRAMコントローラ108は、CPU106、およびオペレーティングシステム120によって提供される機能(たとえば、カーネルスケジューラ122、割込みハンドラ124など)とのシグナリングおよび通信により、DRAMハードウェア保守の様々な態様を実施してもよい。この点について、メモリハードウェア保守モジュール130は、たとえば、割込み要求(IRQ)バス117を介してCPU106への割込み信号を生成し、送信することによって、DRAM保守イベントのスケジューリングを開始するために、スケジューラモジュール132をさらに含んでもよい。スケジューラモジュール132は、スケジュールされた保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを定義するためにタイマ/制御モジュール134を組み込んでもよい。一実施形態では、DRAMハードウェア保守イベントは、当技術分野で知られているように、リフレッシュ動作と、較正動作と、トレーニング動作とを含んでもよい。リフレッシュモジュール136が、DRAM104の揮発性メモリをリフレッシュするための論理を含む。較正モジュール138が、電圧信号レベルを定期的に較正するための論理を含む。トレーニングモジュール140が、DRAM動作の間に使用されるタイミングパラメータを定期的に調整するための論理を含む。
【００１８】
図2は、DRAMハードウェア保守イベントをスケジュール、制御、および実行する際に使用される様々な構成要素間の対話の一実施形態を示す。(DRAMコントローラ108にある)スケジューラ132およびタイマ/制御モジュール134は、オペレーティングシステム120の割込みハンドラ124とインターフェースする。CPU106は、DRAMコントローラ108から、DRAMハードウェア保守イベントがカーネルスケジューラ122によってスケジュールされることを示す割込み信号を受信する。割込みを受信すると、CPU106上で動作している割込みハンドラ124は、受信した割込み信号に関連する特定のDRAMハードウェア保守イベントの優先順位を割り当てるために使用されてもよい優先順位表202とインターフェースする。割込みハンドラ124は、優先順位表202によって規定された優先順位に従ってDRAMハードウェア保守イベントをスケジュールするために、カーネルスケジューラ122とインターフェースする。異なるタイプの保守イベントのすべてにサービスするために、対応する割込みハンドラを用いた複数の割込みが使用される場合があることを諒解されたい。
【００１９】
図3は、DRAMハードウェア保守イベントのカーネルスケジューリングを提供するためのシステム100によって実施される方法300を示す。ブロック302において、DRAMコントローラ108は、カーネルスケジューラ122を介して1つまたは複数のDRAMハードウェア保守イベントをスケジュール、制御、および実行するためにタイムオブサービス(ToS)ウィンドウを決定する。図4は、例示的なToSウィンドウ408を示すメモリ保守イベントタイムライン400を示す。タイムライン400のy軸は、時間(x軸)によるメモリ保守イベントを表す。一実施形態では、ToSウィンドウ408は、DRAMハードウェア保守イベントが実行されてもよい、割込み信号402と所定のデッドラインとの間の継続時間として規定される。図4に示すように、割込み信号402は、基準線404によって示される時間t1に受信される場合がある。DRAMコントローラ108は、スケジュールされたDRAM保守イベントが、基準線406によって示されるデッドライン時間t2までに完了されたかどうかを決定するために、タイマおよび制御モジュール134によりToSウィンドウ408を監視してもよい。
【００２０】
再び図3を参照すると、ブロック304において、DRAMコントローラ108は、1つまたは複数のDRAMハードウェア保守イベントがToSウィンドウ408の間に実行されることを示す1つまたは複数の割込み信号402をCPU106に提供する。割込みハンドラ124は、割込み信号402を受信する。ブロック306において、割込み信号402に応答して、割込みハンドラ124は、ToSウィンドウ408の間にスケジュールされる1つまたは複数のDRAMハードウェア保守イベントの優先順位を決定してもよい。ToSウィンドウ408は、CPU106の負荷が少なく、重要な、高い優先順位のタスクを完了できるようにする、CPUアイドル時間の間に実行されるように、またはそのいずれも優先順位表202に具体化される場合がある他の優先順位方式に従って、1つまたは複数のDRAM保守イベントが、最適に延期される場合がある利用可能なサービスウィンドウを表すことを諒解されたい。DRAM保守イベントが、既存のシステムによって要求される独立した保守イベントとしてではなく保守イベントのバッチとして、たとえば、複数のリフレッシュコマンドを発行することによって、またはリフレッシュイベントとトレーニングイベントを組み合わせることによって、ToSウィンドウ408の間に実行されるようにスケジュールされてもよいことをさらに諒解されたい。このようにして、メモリアクセス衝突が解消される、または著しく減少する場合があり、CPUプロセスメモリ効率が向上する場合がある。
【００２１】
一実施形態では、優先順位は、たとえば、保守イベントのタイプ(たとえば、リフレッシュ、較正、トレーニングなど)、負荷センサ126によって決定される現在のCPU負荷、センサ128によって決定される現在のDRAM温度のうちの1つまたは複数に基づく優先順位表202に従って決定されてもよい。ブロック308において、1つまたは複数のDRAMハードウェア保守イベントは、割込みハンドラ124によって、ブロック306の間に決定された優先順位に従ってカーネルスケジューラ122の入力キューに新しいスレッドとして挿入される。カーネルスケジューラ122は、優先順位に基づいてそのキューにアクティビティのすべてを公平にディスパッチするために標準的な実行に従ってもよい。ブロック310において、1つまたは複数のDRAMハードウェア保守イベントは、優先順位に従ってカーネルスケジューラ122を介して実行されてもよい。上述のように、一実施形態では、DRAMハードウェア保守イベントは、ToSウィンドウ408内の有利な時間に単一のより長いDRAM保守動作を形成するために、合わせてグループ化されてもよい。スケジュールされたDRAMハードウェア保守イベントが実行される前にToSウィンドウ408が終了する(すなわち、デッドラインt2に達する)場合は、タイマおよび制御モジュール134は、カーネルスケジューリングを無効にし、CPU106上のトラフィックをストールすること、および所望の保守を実行することによってハードウェア介入を実行してもよい。介入が行われる場合、タイマおよび制御モジュール134は、CPU106によってアクセスされる場合がある過去の介入のログを保持してもよい。
【００２２】
図5は、3つの処理スレッド(スレッドA502、スレッドB504、およびスレッドC506)に関するDRAMリフレッシュ動作のスケジューリングを含むシステム100の別の例示的な実装形態を示す。図5に示すように、オペレーティングシステム120は、メモリ動作およびDRAMハードウェア保守イベントをスケジュールするための1つまたは複数の優先順位に基づく入力キューを含んでもよい。この例では、システムは、3つの優先順位レベルをサポートする。入力キュー508が、最も高い優先順位(優先順位0)に関連する動作をスケジュールするために使用される。入力キュー510が、次に最も高い優先順位(優先順位1)に関連する動作をスケジュールするために使用される。入力キュー512が、最も低い優先順位(優先順位2)に関連する動作をスケジュールするために使用される。任意の数の優先順位レベル、タイプ、および方式がサポートされてもよいことを諒解されたい。
【００２３】
上記で説明したように、DRAM104が、リフレッシュモジュール136、較正モジュール138、およびトレーニングモジュール140からの定期的なハードウェアサービスイベントを含んでもよい。一実施形態では、モジュール136、138、および140は、モジュール134によって提供されるタイマを使用して定期的なサービスインターバルを追跡するためのそれぞれのハードウェアを含んでもよい。各タイマは、対応するDRAMハードウェア保守イベントがその中で完了されるべきToSウィンドウ408を追跡してもよい。
【００２４】
各イベント手法のタイムオブサービスとして、スケジューラ132が、CPU106への割込み信号402を発行してもよい。割込み信号402が、オペレーティングシステム120の割込みハンドラ124に、優先順位表202に基づいて入力キュー508、510、および512のうちの1つに対応するイベントスレッドを追加させてもよいことを諒解されたい。図8は、割込みハンドラ124がリフレッシュ動作のための割込み信号402を受信する例を示す。割込みハンドラ124は、優先順位表202にアクセスし、リフレッシュ動作は、最も低い優先順位(すなわち、優先順位2動作のための入力キュー512)に割り当てられることを決定してもよい。優先順位は、負荷センサ126および/または温度センサ128からの入力に基づいて決定されてもよい。図8の例では、スレッドA502が、優先順位0動作として入力キュー508に追加され、スレッドB504が、優先順位1動作として入力キュー510に追加され、スレッドC506が、優先順位2動作として入力キュー512に追加される。割込みハンドラ124が、リフレッシュ動作は優先順位2動作を割り当てられると決定した後、リフレッシュスレッド802が、優先順位2動作に対応する入力キュー512に追加されてもよい。
【００２５】
カーネルスケジューリングアルゴリズムに従って、カーネルスケジューラ122は、スレッドA、B、およびC、ならびにリフレッシュスレッド802をディスパッチしてもよい。一実施形態では、カーネルスケジューリングアルゴリズムは、たとえば、当技術分野でよく知られている、静的優先順位方式、優先順位付けされたラウンドロビン方式、または優先順位付けされたピンポン方式に従ってもよい。リフレッシュスレッド802が実行されるとき、対応するリフレッシュドライバ514が、DRAMコントローラ108内のリフレッシュモジュール136にリフレッシュイベントを実行するよう命令するために使用されてもよいことを諒解されたい。さらなる較正およびトレーニングドライバ514が、較正モジュール138およびトレーニングモジュール140にそれぞれ対応するDRAM保守イベントを実行するように命令するために使用されてもよい。サービスする前に、各ドライバ514が、イベントが実行されるより前にToSウィンドウ408が終了することにより、ハードウェア介入がすでに行われているかどうかを決定するために、ハードウェアをチェックしてもよいことを諒解されたい。
【００２６】
上述のように、モジュール134内のタイマは、サービスイベントが完了されるべきデッドラインを追跡してもよい。たとえば、重いCPU負荷の下では、DRAM保守イベントスレッドおよび関連するドライバ514が、デッドラインの前に実行されない場合がある。これが発生する場合、DRAMコントローラ108は、タイマによって追跡されるデッドラインを認識し、ハードウェアが直ちに介入し、CPUトラフィックをストールし、必要とされるDRAMサービスを実行する。介入の後、ハードウェアは、前述のように続行されてもよい。
【００２７】
図6は、DRAMコントローラ108がカーネルスケジューラ122を介してスケジュールすることなく、図5の例においてDRAM104を定期的にリフレッシュするための従来の方法の一実施形態を示すメモリトラフィックタイムラインである。この例は、カーネルスケジューリング、優先順位などを顧慮せずに、独立したサービスイベントとして、リフレッシュ動作を定期的にスケジュールするための従来の手法を示すことを諒解されたい。図6に示すように、個々のリフレッシュ602が、カーネルスケジューラ122を介してDRAMコントローラ108によってスケジュールされるのではなく、一定の周期で行われる。したがって、スレッドA502、スレッドB504、およびスレッドC506を処理するとき、各リフレッシュ602は、リフレッシュ動作が実行されることを可能にするために、対応するスレッドがストールされることを必要とする。図7は、上記で説明したシステムおよび方法がリフレッシュ602のグループをスケジュールするために使用される図6の例を示す。図7は、アイドル時間の間に実行されるようにリフレッシュ602をスケジュールし、それによってCPUプロセスメモリ効率を向上させることによって、各メモリアクセス衝突が回避される場合があることを示す。
【００２８】
図9は、優先順位表202を生成するための優先順位較正方法900の一実施形態を示すフローチャートである。方法900に使用されるいくつかの値は、異なるプラットフォーム、メモリタイプ、ソフトウェアビルドなどに対応するように調整される場合があることは、当業者には認識されよう。値は、相手先商標製造会社(OEM)によって提供される場合があることをさらに諒解されたい。
【００２９】
ブロック902に示すように、優先順位較正は、様々な温度値にわたって実行されてもよい。ブロック904において、優先順位較正は、CPU負荷の様々な値(たとえば、パーセンテージ値、範囲など)にわたって実行されてもよい。値にわたるスイープの間、較正、トレーニング、およびリフレッシュハードウェアイベントのスレッド優先順位は、下げられてもよい。これは、整数値優先順位を0から、(スケジューリングがToSウィンドウ内で完了しないときの)ハードウェア介入の数がしきい値を超えるまで増やすことに対応することを諒解されたい。その時点において、優先順位は、その温度値(T)およびCPU負荷値(X)に対してログ記録されてもよく(ブロック912)、その後フローは、ブロック904に戻されてもよい。図9を参照すると、ブロック906は、システムがハードウェア介入をカウントするためにある固定時間期間の間実行されてもよいことを示す(ブロック908)。決定ブロック910では、ハードウェア介入の数がしきい値未満である場合、優先順位は、下げられてもよい。ハードウェア介入の数がしきい値を超える場合、ブロック912が実行される。
【００３０】
図10は、温度値(列1004)およびCPUパーセンテージ負荷(行1002)の組合せに対する優先順位値を含む例示的な優先順位表202を示す。たとえば、温度値85度およびCPU負荷80%に対する優先順位値は、CPU負荷が重くおよびDRAM温度が高いために最も高い優先順位レベル(優先順位=0)を割り当てられてもよい。
【００３１】
上述のように、DRAMコントローラ108は、スケジュールされたDRAM保守イベントが、対応するデッドラインまでに完了されたかどうかを決定するために、タイマおよび制御モジュール134によりToSウィンドウ408を監視してもよい。図11は、リフレッシュ602のグループがスレッド1101および1103の実行間のアイドル時間のToSウィンドウ1106の間に、正常にスケジュールされ、実行されることを示すタイムライン1100である。図12は、スレッド1101が実行されている間に、またリフレッシュ602のグループが実行される前に、ToSウィンドウ1106が終了するタイムライン1200を示す。この状況では、DRAMコントローラ108は、デッドラインを逸したことを検出し、上記で説明したようにハードウェア介入を開始する。各タイプの保守イベントに対する介入の実行履歴が、カウンタによってログ記録されてもよく、カウンタは、CPU106上で実行しているオペレーティングシステム120によって読み取られる、および/またはリスタートされることが可能である。オペレーティングシステム120は定期的に、この介入履歴を読み取り、クリアし、以前の読取りのログを不揮発性メモリ118に記憶してもよい。これは、オペレーティングシステム120が、たとえば、図9のブロック908と等しい継続時間の、固定連続時間期間にわたって行われた介入の数を測定することを可能にする。不揮発性メモリ118に記憶されたログは、システム100が許容できる較正にとどまっていること、および介入の発生が著しく悪化していないことを保証するために、オペレーティングシステム120によって使用されてもよい。たとえば、ログが、システム100が劣化し、図9のブロック910に記載する較正しきい値の値を超える介入に遭遇したことを示す場合、システムは、すべてのテーブルエントリ(すでに最高である優先順位0を含まない)の優先順位を直ちに上げて、それにより介入率を下げることによって、優先順位表202を意図的に調節してもよい。反対に、ログが、延長時間期間(たとえば、図9のブロック908の例示的な実施形態で使用される時間期間よりも例外的に長い、48時間)の間に、システム100がゼロまたはゼロに近い介入を経験することを報告する場合、これは、優先順位表202エントリが、必要以上に高く優先順位付けられたことを示す可能性があり、システム100は、各エントリの優先順位を下げ、したがって介入率が上がるようにするための機能を含んでもよい。
【００３２】
上述のように、システム100は、任意の望ましいコンピューティングシステムに組み込まれてもよい。図13は、SoC102を含む例示的なポータブルコンピューティングデバイス(PCD)1300を示す。この実施形態では、SoC102は、マルチコアCPU1302を含む。マルチコアCPU1302は、第0のコア1310、第1のコア1312、および第Nのコア1314を含んでもよい。コアのうちの1つは、たとえば、グラフィックス処理ユニット(GPU)を含み、他のコアのうちの1つまたは複数はCPUを含む場合がある。
【００３３】
ディスプレイコントローラ328およびタッチスクリーンコントローラ330は、CPU1302に結合されてもよい。一方、SoC102の外部にあるタッチスクリーンディスプレイ1306は、ディスプレイコントローラ328およびタッチスクリーンコントローラ330に結合されてもよい。
【００３４】
図13は、ビデオエンコーダ334、たとえば、位相反転線(PAL)エンコーダ、順次式カラーメモリ(SECAM)エンコーダ、または全米テレビジョン方式委員会(NTSC)エンコーダが、マルチコアCPU1302に結合されることをさらに示す。さらに、ビデオ増幅器336がビデオエンコーダ334とタッチスクリーンディスプレイ1306とに結合される。また、ビデオポート338がビデオ増幅器336に結合される。図13に示すように、ユニバーサルシリアルバス(USB)コントローラ340が、マルチコアCPU1302に結合される。同様に、USBポート342が、USBコントローラ340に結合される。DRAM104および加入者識別モジュール(SIM)カード346はまた、マルチコアCPU1302に結合されてもよい。
【００３５】
さらに、図13に示すように、デジタルカメラ348は、マルチコアCPU1302に結合される場合がある。例示的な態様において、デジタルカメラ348は、電荷結合デバイス(CCD)カメラまたは相補型金属酸化物半導体(CMOS)カメラである。
【００３６】
図13にさらに示すように、ステレオオーディオコーダ-デコーダ(コーデック)350が、マルチコアCPU1302に結合されてもよい。さらに、オーディオ増幅器352が、ステレオオーディオコーデック350に結合されてもよい。例示的な態様では、第1のステレオスピーカー354および第2のステレオスピーカー356が、オーディオ増幅器352に結合される。図13は、マイクロフォン増幅器358もステレオオーディオコーデック350に結合される場合があることを示している。さらに、マイクロフォン360が、マイクロフォン増幅器358に結合されてもよい。特定の態様では、周波数変調(FM)無線チューナ362が、ステレオオーディオコーデック350に結合されてもよい。また、FMアンテナ364が、FM無線チューナ362に結合される。さらに、ステレオヘッドフォン366は、ステレオオーディオコーデック350に結合されてもよい。
【００３７】
図13は、無線周波数(RF)トランシーバ368がマルチコアCPU1302に結合される場合があることをさらに示す。RFスイッチ370が、RFトランシーバ368とRFアンテナ372とに結合される場合がある。キーパッド204が、マルチコアCPU1302に結合される場合がある。また、マイクロフォンを備えたモノヘッドセット376が、マルチコアCPU1302に結合される場合がある。さらに、バイブレータデバイス378がマルチコアCPU1302に結合される場合がある。
【００３８】
図13はまた、電源380がSoC102およびSoC202に結合される場合があることを示す。特定の態様では、電源380は、電力を必要とするPCD1300の種々の構成要素に電力を供給する直流(DC)電源である。さらに、特定の態様では、電源は、充電式DCバッテリー、または交流(AC)電源に接続されたAC/DC変換器から得られるDC電源である。
【００３９】
図13はさらに、PCD1300がまた、データネットワーク、たとえば、ローカルエリアネットワーク、パーソナルエリアネットワーク、または任意の他のネットワークにアクセスするために使用される場合があるネットワークカード388を含んでもよいことを示す。ネットワークカード388は、Bluetooh(登録商標)ネットワークカード、WiFiネットワークカード、パーソナルエリアネットワーク(PAN)カード、パーソナルエリアネットワーク超低電力技術(PeANUT)ネットワークカード、テレビジョン/ケーブル/衛星チューナ、または当技術分野でよく知られている任意の他のネットワークカードである場合がある。さらに、ネットワークカード388は、チップに組み込まれる場合があり、すなわち、ネットワークカード388は、チップ内のフルソリューションである場合があり、別個のネットワークカード388でなくてもよい。
【００４０】
図13を参照すると、メモリ104、タッチスクリーンディスプレイ1306、ビデオポート338、USBポート342、カメラ348、第1のステレオスピーカー354、第2のステレオスピーカー356、マイクロフォン360、FMアンテナ364、ステレオヘッドフォン366、RFスイッチ370、RFアンテナ372、キーパッド204、モノヘッドセット376、バイブレータ378、および電源380は、オンチップシステム102の外部に存在する場合があることを諒解されたい。
【００４１】
揮発性メモリ保守イベントをスケジュールするための上記で説明したシステムおよび方法は、同じ揮発性メモリを共有する2つ以上の独立したメモリクライアントを含むマルチプロセッサSoCに組み込まれる場合があることを諒解されたい。図14は、図1のSoC102が3つのメモリクライアント、すなわち、CPU106、グラフィック処理ユニット(GPU)1402、およびモデム処理ユニット(MPU)1404を含む一実施形態を示す。各プロセッサは、自律的に、互いから独立して動作するが、SoCバス116を介して、互いと、ならびにROM112、SRAM110、DRAMコントローラ108、およびストレージコントローラ114に通信することができる。上記で説明し、図14に示すように、CPU106、GPU1402、およびMPU1404は、マルチクライアント決定モジュール1400によって含められ、IRQバス117を介してDRAMコントローラ108から割込み信号を受信するように登録してもよい。
【００４２】
任意の数のさらなるプロセッサおよび/またはプロセッサタイプが、SoC102に組み込まれてもよい。各プロセッサタイプは、それらのそれぞれのプロセッサタイプで動作しているカーネルおよびスケジューリング関数(たとえば、図1のカーネルスケジューラ122、割込みハンドラ124)のコマンドの下でスレッドを実行する、単数および/または複数の並列実行ユニットを含んでもよい。図14にさらに示すように、CPU106、GPU1402、およびMPU1404は、それぞれオペレーティングシステム120a、120b、および120cを、対応する負荷センサ126a、126b、および126cとともに備えてもよい。図1〜図13に関して上述したカーネルスケジューリングシステムおよび方法は、CPU106、GPU1402、およびMPU1404の各々に対して拡大されてもよい。
【００４３】
下記でより詳細に説明するように、DRAMコントローラ108は、SoCプロセッサの各々のカーネルスケジューリングを考慮に入れることによってDRAM保守イベントをいつスケジュールするかを決定するための論理を含むマルチクライアント決定モジュール1400をさらに含んでもよい。カーネルスケジューリングは、上記で説明した方法で実行されてもよい。ToS手法としての、図14のマルチプロセッサ環境では、タイマおよび制御モジュール134は、CPU106、GPU1402、およびMPU1404の各々に、1つまたは複数の割込みを発行してもよい。応答して、各オペレーティングシステム120a、120b、および120c内の割込みサービスルーチン(ISR)は、それらのそれぞれのスケジューラ入力キュー上に対応するイベントを発行してもよい。この点について、イベントは、各プロセッサタイプに対して、複製され、キューイングされてもよい。アクティブでないまたはスリープ状態であるプロセッサは、割込みに応答することから一時的に除外され、それらが再びアクティブになるまでマルチクライアント決定モジュール1400の処理から除外されてもよい。任意のプロセッサが、それ自体を任意の時間にマルチクライアント決定から除外してもよい。各プロセッサが、たとえば、プロセッサの割込みハンドラ124から保守イベント割込み117をマスクすることに加えて、このプロセッサはもはやマルチクライアント決定に含められるべきではないことを意味する、マルチクライアント決定モジュール1400への書込みを実行することによって、これを行ってもよい。
【００４４】
CPU106、GPU1402、およびMPU1404は、独立して動作し、DRAMコントローラ108への別個のスケジュール通知を生成し、提供することによってDRAM保守イベントをスケジュールする。一実施形態では、各プロセッサカーネルスケジューラが、それら自体の「保守に最良の時間」を決定し、次いで、各プロセッサからの受信したスケジュール通知に基づいて実際のスケジューリングを決定する最終的な権限を有するDRAMコントローラ108を用いて、通知を独立してスケジュールする。DRAMコントローラ108は、スケジュール通知を、任意の一貫性のあるパターンに従うのではなく順不同に受信してもよいことを諒解されタイマルチクライアント決定モジュール1400は、DRAM保守イベントをいつ実行するかを決定するために、記憶された特性付けデータならびにDRAMトラフィック利用データを活用してもよい。メモリトラフィック利用モジュール1406(図14)が、DRAM104上のトラフィックアクティビティの現在のレベルを決定し、報告してもよい。このようにして、各SoCプロセッサに対するカーネルスケジューラは、DRAM保守イベントを実行するのに最適な時間を個別に決定してもよいが、マルチクライアント決定モジュール1400は、それをいつ行うかの最終的な決定を行う。
【００４５】
図15は、マルチクライアント決定モジュール1400の一実施形態の一般的な動作およびデータ入力を示す。CPU106、GPU1402、およびMPU1404が独立して、通知1502を提供することによって、マルチクライアント決定モジュール1400に、DRAM保守イベントを実行するのに最適な時間を通知する。通知1502は、DRAMコントローラ108への書込み動作によって実施されてもよい。
【００４６】
図19は、クライアントID 1902、クライアント優先順位データ1904、クライアント負荷データ1906、および保守イベントID 1908を含む書込み動作1900の例示的な実装形態を示す。クライアントID 1902は、どのプロセッサが通知1502を送信しているかを識別するために使用されてもよい。クライアント優先順位データ1904は、プロセッサに割り当てられた優先順位を含んでもよい。一実施形態では、各プロセッサタイプ(たとえば、CPU、GPU、MPUなど)が、あらかじめ定義された優先順位方式に従って優先順位を割り当てられてもよい。プロセッサの優先順位は、DRAMアクセス待ち時間に対する感度(sensitivity)と逆である。言い換えれば、待ち時間に比較的より影響されやすい(sensitive)プロセッサは、より高い優先順位を割り当てられてもよい。図14の例では、MPU1404は、「最も高い優先順位」を、GPU1402は「最も低い優先順位」を、CPUは「中間の優先順位」を割り当てられてもよい。図15に示すように、優先順位データは、通知を用いて与えられなくてもよい。代替実施形態では、プロセッサ優先順位データ1502は、DRAMコントローラ108に記憶される、または場合によっては与えられてもよい。再び図19を参照すると、書込み動作1900によって与えられるクライアント負荷データ1906は、たとえば、プロセッサによってわかる平均負荷(すなわち、プロセッサ利用率)を含んでもよい。プロセッサ利用率は、負荷センサ126によって測定されてもよい。保守イベントID 1908は、スケジュールされているDRAM保守イベントのタイプを識別するイベントタイプ(たとえば、リフレッシュ、トレーニング、較正)を含んでもよい。一実施形態では、保守イベントID 1908はまた、プロセッサからマルチクライアント決定モジュール1400に設定およびステータス情報を送信するために使用されてもよい。たとえば、独立したクライアント負荷データ1906が、各プロセッサによって定期的に送信されてもよく、またはマルチクライアント決定から一時的に取り除かれるように、プロセッサから除外要求が送信されてもよい。
【００４７】
再び図15を参照すると、マルチクライアント決定モジュール1400は、1つまたは複数の決定ルールに従ってDRAM保守イベントをいつ実行するかを決定するように構成されてもよい。一実施形態では、決定ルールは、通知による通知ベースで適用される。言い換えれば、各通知1502が受信されるとき、決定ルールはその通知に適用される。マルチクライアント決定モジュール1400は、様々なタイプのデータを使用して決定ルールを適用してもよい。図15の実施形態では、入力データは、決定表1506、プロセッサ優先順位データ1504、およびメモリトラフィック利用データ1508を含む。例示的な決定表1506について、図18を参照して下記で説明する。メモリトラフィック利用データ1508は、モジュール1406(図14)によって提供されてもよい。
【００４８】
図16は、図14のマルチプロセッサSoC内でDRAM保守イベントをスケジュールするためのルールベースの方法1600の一実施形態を示すフローチャートである。ブロック1602において、DRAMコントローラ108は、DRAM保守イベントを実行するためにToSウィンドウを決定してもよい。ブロック1604において、DRAMコントローラ108は、SoC102上の複数のプロセッサの各々に割込み信号を提供する。ブロック1606において、各プロセッサが独立して、対応する通知1502を生成することによって、DRAM保守イベントをスケジュールする。ブロック1602、1604、および1606は、上記で説明したように動作してもよい。
【００４９】
各通知1502がDRAMコントローラ108によって受信されるとき(ブロック1608)、マルチクライアント決定モジュール1400は、DRAM保守イベントをいつ実行するかを決定するために、1つまたは複数の決定ルールを適用してもよい。マルチクライアント決定モジュール1400は、現在のToSウィンドウの間にどのプロセッサが通知を送信したかを追跡してもよい。決定ブロック1610において、マルチクライアント決定モジュール1400は、現在の通知の優先順位よりも高い優先順位を有する未処理の通知1502があるかどうかを決定してもよい。現在の通知よりも高い優先順位を有する未処理の通知がある場合、マルチクライアント決定モジュール1400は、次の通知1502の到着を待ってもよい(ブロック1608まで制御を戻す)。たとえば、現在の通知1502が、「最も低い優先順位」を有するGPU1402から受信されたと考える。通知がCPU106またはMPU1404(これらの両方がより高い優先順位を有する)からまだ受信されていない場合、DRAMコントローラ108は、次の通知を受信するのを待ってもよい。現在の通知よりも高い優先順位を有する未処理の通知がない場合、制御は、決定ブロック1612に移る。決定ブロック1612において、マルチクライアント決定モジュール1400は、「直ちに作動(go now)」し、DRAM保守イベントにサービスするか、1つまたは複数のプロセッサからさらなる通知を受信するのを待つかを決定する。最も高い優先順位のプロセッサが、最後に通知に応答する場合、これは、未処理の通知がないことを意味し、ルールベースの方法1600は、自動的にブロック1614に進んでもよい。
【００５０】
一実施形態では、決定ブロック1612は、決定表1506(図15)にアクセスすることによって実施されてもよい。図18は、CPU負荷(列1802)、GPU負荷(列1804)、およびMPU負荷(列1806)の様々な組合せに基づいて、"go now"または"wait"アクション(列1808)を指定する、例示的な決定表1506を示す。図18の例では、プロセッサ負荷は、"low"または"high"値によって指定されるが、数値範囲または他の値が実装されてもよい。書込み動作1900による次の値更新が、現在の値を上書きするまで、プロセッサ負荷値1802、1804、および1806は、保持されてもよい。DRAM保守イベントがない間でもマルチクライアント決定モジュール1400に正確な負荷情報を提供するために、プロセッサ負荷値更新が、定期的に送信されてもよい。
【００５１】
再び図16を参照すると、決定表1506が"wait"アクションを示す場合、制御はブロック1608に戻る。決定表1506が"go now"アクションを示す場合、DRAMコントローラ108は、DRAMトラフィック利用を監視することを始めてもよい(ブロック1614)。DRAMトラフィック利用が、所定の、またはプログラム可能なしきい値を下回るとき(決定ブロック1620)、DRAMコントローラ108は、DRAMイベントにサービスすることを始めてもよい(ブロック1622)。DRAMトラフィック利用を監視しながら、DRAMコントローラ108は、ToSウィンドウが終了したかどうかを追跡してもよい(決定ブロック1616)。DRAM保守イベントにサービスする前にToSウィンドウが終了する場合、DRAMコントローラは、上記で説明したようにハードウェア介入を実行してもよい(ブロック1618)。
【００５２】
図17は、ルールベースの方法1600の動作の2つの例を示すタイムラインである。タイムライン1700は、DRAMコントローラ108によって受信された通知1502の順番を示し、タイムライン1702は、DRAM保守イベントにサービスするための、結果として生じるタイミングを示す。タイムライン1700を参照すると、第1の通知1704aが、CPU106(「中間の優先順位」)から受信される。より高い優先順位プロセッサ(すなわち、GPU1402およびMPU1404)から通知はまだ受信されていないので、DRAMコントローラ108は、次の通知を待つ。第2の通知1706aが、GPU1402(「最も低い優先順位」)から受信される。最も高い優先順位プロセッサ(MPU1404)が未処理のままであるので、DRAMコントローラは、トラフィック利用モジュール1406をチェックし、ToSウィンドウ1711a内でDRAM保守イベントにサービスする前に、最後の通知(1708a)を受信するのを待つ。タイムライン1702は、最後の通知1708aが受信されるとき、信号1710aが生成されることを示す。
【００５３】
その後の時間に、第2のDRAM保守イベントがスケジュールされてもよい。このDRAM保守イベントの場合、通知は、異なる順番で受信される。第1の通知1708aは、「最も高い優先順位」を有するMPUから受信される。通知1708aを受信することに応答して、DRAMコントローラ108は、より高い優先順位を有する未処理の通知はないと決定してもよい。それに応じて、マルチクライアント決定モジュール1400は、DRAMにサービスすることを始める("go now"アクション)か、それとも次の通知まで待つ("wait"アクション)かを決定するために、決定表1506にアクセスしてもよい。この例では、MPU1404は、"high"負荷を有し(図18の2行目)、マルチクライアント決定モジュール1400は、対応するアクションは"wait"であると決定する。決定表1506に基づいて、DRAMコントローラ108は、CPU106(「中間の優先順位」)から次の通知1704bを受信するのを待つ。GPU1402に関連する未処理の通知は、より高い優先順位ではないので、マルチクライアント決定モジュール1400は、DRAMにサービスすることを始める(たとえば、"go now"アクション)か、それとも次の通知まで待つ(たとえば、"wait"アクション)かを決定するために、決定表1506にアクセスしてもよい。この例では、CPU106の書込み動作1900は、"high"負荷を示す。さらに、MPU1404は、その負荷を"high"から"low"値に更新した別個の書込み動作1900を行っており、マルチクライアント決定モジュール1400は、対応するアクション(たとえば、図18の3行目)は"go now"であると決定する。トラフィック利用モジュール1406は、図16のブロック1620で説明するように、しきい値を下回るメモリトラフィックをチェックされてもよく、次いでDRAMコントローラは、DRAM保守イベントにサービスすることを始める。タイムライン1702は、通知1704bが受信されるとき、また最も低い優先順位のプロセッサ(すなわち、GPU1402)から通知1706bを受信する前に、信号1710bが生成されることを示す。現在のToSウィンドウ1711bの間にDRAM保守はすでに完了しているので、GPU1402の通知1706bは、依然として行われる場合があるが、マルチクライアント決定モジュール1400によって無視されてもよい。たとえば、図17に示すように、信号1710bが発せられるとき、ToSウィンドウ1711bは閉じられてもよい。
【００５４】
本明細書で説明した方法ステップのうちの1つまたは複数は、上記のモジュールなどのコンピュータプログラム命令としてメモリに記憶される場合があることを諒解されたい。これらの命令は、本明細書で説明した方法を実行するために、対応するモジュールと組み合わせてまたは協働して、任意の適切なプロセッサによって実行される場合がある。
【００５５】
本発明が説明したように機能するために、本明細書で説明したプロセスまたはプロセスフローにおけるいくつかのステップが、他のステップに先行するのは当然である。しかしながら、そのような順序またはシーケンスが本発明の機能を変えない場合、本発明は、説明したステップの順序に限定されない。すなわち、本発明の範囲および趣旨から逸脱することなく、いくつかのステップは、他のステップの前に実行されるか、後に実行されるか、または他のステップと並行して(実質的に同時に)実行されてもよいことを認識されたい。場合によっては、本発明から逸脱することなく、いくつかのステップが省略されてもよく、または実行されなくてもよい。さらに、「その後」、「次いで」、「次に」などの語は、ステップの順番を限定することを意図していない。これらの言葉は単に、例示的な方法の説明に読者を導くために使用される。
【００５６】
さらに、プログラミングに関する当業者は、たとえば、本明細書におけるフローチャートおよび関連する説明に基づいて、難なく、開示した発明を実装するコンピュータコードを書くことができるか、または実装するのに適したハードウェアおよび/もしくは回路を識別することができる。
【００５７】
したがって、特定の1つのセットのプログラムコード命令または詳細なハードウェアデバイスの開示は、本発明の作製方法および使用方法を十分に理解するのに必要であるとは見なされない。特許請求されるコンピュータ実施プロセスの発明性のある機能は、上記の説明において、かつ様々なプロセスフローを示す場合がある図面とともに、より詳細に説明される。
【００５８】
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装されてもよい。ソフトウェアで実装される場合、機能は、1つもしくは複数の命令またはコードとして、コンピュータ可読媒体上に記憶される場合もあり、またはコンピュータ可読媒体上で送信される場合もある。コンピュータ可読媒体は、コンピュータ記憶媒体と、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む通信媒体の両方を含む。記憶媒体は、コンピュータによってアクセスされる場合がある任意の利用可能な媒体であってもよい。限定ではなく例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、NANDフラッシュ、NORフラッシュ、M-RAM、P-RAM、R-RAM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するために使用され、コンピュータによってアクセスされてもよい任意の他の媒体を備えてもよい。
【００５９】
また、いかなる接続も、厳密にはコンピュータ可読媒体と呼ばれる。たとえば、ソフトウェアが、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(「DSL」)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。
【００６０】
ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)("CD")、レーザーディスク(disc)(登録商標)、光ディスク(disc)、デジタル多用途ディスク(disc)("DVD")、フロッピーディスク(disk)、およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生する一方で、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲に含まれるべきである。
【００６１】
本発明の趣旨および範囲から逸脱することなく、本発明が関係する代替的な実施形態が、当業者には明らかになるであろう。したがって、選択された態様が図示され詳細に説明されてきたが、以下の特許請求の範囲によって定義されるように、本発明の趣旨および範囲から逸脱することなく、各態様において様々な置換および改変が行われてよいことが理解されよう。
【符号の説明】
【００６２】
100  システム
102  システムオンチップ(SoC)
104  ダイナミックランダムアクセスメモリ(DRAM)
105  制御バス
106  中央処理装置(CPU)
107  データバス
108  DRAMコントローラ
110  スタティックランダムアクセスメモリ(SRAM)
112  読取り専用メモリ(ROM)
114  ストレージコントローラ
116  SoCバス
117  割込み要求(IRQ)バス
118  不揮発性メモリ
120  オペレーティングシステム(OS)
122  カーネルスケジューラ
124  割込みハンドラ
126  負荷センサ
128  温度センサ
130  メモリハードウェア保守モジュール
132  スケジューラモジュール
134  タイマおよび制御モジュール
136  リフレッシュ
138  較正
140  トレーニング
202  優先順位表
204  キーパッド
328  ディスプレイコントローラ
330  タッチスクリーンコントローラ
334  ビデオエンコーダ
336  ビデオ増幅器
338  ビデオポート
340  ユニバーサルシリアルバス(USB)コントローラ
342  USBポート
346  加入者識別モジュール(SIM)カード
348  デジタルカメラ
350  ステレオオーディオコーダ-デコーダ
352  オーディオ増幅器
354  第1のステレオスピーカー
356  第2のステレオスピーカー
358  マイクロフォン増幅器
360  マイクロフォン
362  周波数変調(FM)無線チューナ
364  FMアンテナ
366  ステレオヘッドフォン
368  無線周波数(RF)トランシーバ
370  RFスイッチ
372  RFアンテナ
376  モノヘッドセット
378  バイブレータ
380  電源
388  ネットワークカード
602  CPU
802  マルチコアCPU
1300  ポータブルコンピューティングデバイス(PCD)
1302  マルチコアCPU
1306  タッチスクリーンディスプレイ
1310  第0のコア
1312  第1のコア
1314  第Nのコア
1400  マルチクライアント決定モジュール
1402  グラフィック処理ユニット(GPU)
1404  モデム処理ユニット(MPU)
1406  モジュール
1900  書込み動作
1902  クライアントID
1904  クライアント優先順位
1906  クライアント負荷データ
1908  保守イベントID
【図１】
2018508884.tif 000003
【図２】
2018508884.tif 000004
【図３】
2018508884.tif 000005
【図４】
2018508884.tif 000006
【図５】
2018508884.tif 000007
【図６】
2018508884.tif 000008
【図７】
2018508884.tif 000009
【図８】
2018508884.tif 000010
【図９】
2018508884.tif 000011
【図１０】
2018508884.tif 000012
【図１１】
2018508884.tif 000013
【図１２】
2018508884.tif 000014
【図１３】
2018508884.tif 000015
【図１４】
2018508884.tif 000016
【図１５】
2018508884.tif 000017
【図１６】
2018508884.tif 000018
【図１７】
2018508884.tif 000019
【図１８】
2018508884.tif 000020
【図１９】
2018508884.tif 000021
【手続補正書】
【提出日】平成29年8月15日(2017.8.15)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
揮発性メモリ保守イベントをスケジュールするための方法であって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するために前記メモリコントローラがタイムオブサービス(ToS)ウィンドウを決定するステップと、
処理ユニットと通信しているオペレーティングシステムの割込みハンドラに前記メモリコントローラが割込み信号を提供するステップと、
前記割込みハンドラを用いて、前記保守イベントの優先順位を決定するステップと、
前記優先順位に従って前記オペレーティングシステムのスケジューラの入力キューに前記保守イベントのための新しいスレッドを前記割込みハンドラを用いて挿入することによって、前記保守イベントをスケジュールするステップと
を含む、方法。
【請求項２】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するステップ
をさらに含む、請求項1に記載の方法。
【請求項３】
前記保守イベントを実行することなく前記ToSウィンドウが終了したと判定するステップと、
前記処理ユニット上のトラフィックをストールするステップと、
前記揮発性メモリデバイスに対して前記保守イベントを実行するステップと
をさらに含む、請求項1に記載の方法。
【請求項４】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項1に記載の方法。
【請求項５】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項1に記載の方法。
【請求項６】
前記保守イベントの前記優先順位を前記決定するステップが、前記オペレーティングシステムの前記割込みハンドラを用いてルックアップテーブルにアクセスし、かつ保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて、前記割込みハンドラを用いて前記優先順位を選択するステップを含む、請求項1に記載の方法。
【請求項７】
前記保守イベントを前記スケジュールするステップが、前記オペレーティングシステムのカーネルスケジューラの前記入力キューにサービススレッドを追加するステップを含む、請求項1に記載の方法。
【請求項８】
揮発性メモリ保守イベントをスケジュールするためのシステムであって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するための手段と、
処理ユニットと通信しているオペレーティングシステムの割込みハンドラに割込み信号を提供するための手段と、
前記割込みハンドラを用いて、前記保守イベントの優先順位を決定するための手段と、
前記優先順位に従って前記オペレーティングシステムのスケジューラの入力キューに前記保守イベントをスケジュールするための手段と
を含む、システム。
【請求項９】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行するための手段
をさらに含む、請求項8に記載のシステム。
【請求項１０】
前記保守イベントを実行することなく前記ToSウィンドウが終了したと判定するための手段と、
前記処理ユニット上のトラフィックをストールするための手段と、
前記揮発性メモリデバイスに対して前記保守イベントを実行するための手段と
をさらに含む、請求項8に記載のシステム。
【請求項１１】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項8に記載のシステム。
【請求項１２】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項8に記載のシステム。
【請求項１３】
前記保守イベントの前記優先順位を決定するための前記手段が、
前記オペレーティングシステムの前記割込みハンドラを用いてルックアップテーブルにアクセスし、かつ保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて前記優先順位を選択するための手段
を含む、請求項8に記載のシステム。
【請求項１４】
前記保守イベントをスケジュールするための前記手段が、
前記オペレーティングシステムのカーネルスケジューラの前記入力キューにサービススレッドを追加するための手段
を含む、請求項8に記載のシステム。
【請求項１５】
メモリ内で具現化され、かつ揮発性メモリ保守イベントをスケジュールするためにプロセッサによって実行可能であるコンピュータプログラムであって、
メモリデータインターフェースを介してメモリコントローラに結合される揮発性メモリデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定することと、
処理ユニットと通信しているオペレーティングシステムの割込みハンドラに割込み信号を提供することと、
前記割込みハンドラを用いて、前記保守イベントの優先順位を決定することと、
前記優先順位に従って前記オペレーティングシステムのスケジューラの入力キューに前記保守イベントのための新しいスレッドを前記割込みハンドラを用いて挿入することによって前記保守イベントをスケジュールすることと
を行うように構成される論理手段を含む、コンピュータプログラム。
【請求項１６】
前記ToSウィンドウの間に前記揮発性メモリデバイスに対して前記保守イベントを実行する
ように構成される論理手段をさらに含む、請求項15に記載のコンピュータプログラム。
【請求項１７】
前記スケジュールされた保守イベントが前記ToSウィンドウの間に実行されていないと決定することと、
前記処理ユニット上のトラフィックをストールすることと、
前記揮発性メモリデバイスに対して前記保守イベントを実行することと
を行うように構成される論理手段をさらに含む、請求項15に記載のコンピュータプログラム。
【請求項１８】
前記保守イベントが、前記揮発性メモリデバイスに定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項15に記載のコンピュータプログラム。
【請求項１９】
前記揮発性メモリデバイスが、ダイナミックランダムアクセスメモリ(DRAM)デバイスを含む、請求項15に記載のコンピュータプログラム。
【請求項２０】
前記保守イベントの前記優先順位を決定するように構成される前記論理手段が、前記オペレーティングシステムの前記割込みハンドラを用いてルックアップテーブルにアクセスし、かつ保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記揮発性メモリデバイスに関連する現在の温度のうちの1つまたは複数に基づいて、前記割込みハンドラを用いて前記優先順位を選択するように構成される論理手段を含む、請求項15に記載のコンピュータプログラム。
【請求項２１】
前記保守イベントをスケジュールするように構成される前記論理手段が、前記オペレーティングシステムのカーネルスケジューラの前記入力キューにサービススレッドを追加するように構成される論理手段を含む、請求項15に記載のコンピュータプログラム。
【請求項２２】
揮発性メモリ保守イベントをスケジュールするためのシステムであって、
ダイナミックランダムアクセスメモリ(DRAM)デバイスと、
処理デバイス、およびメモリデータインターフェースを介して前記DRAMデバイスに電気的に結合されるDRAMコントローラを含むシステムオンチップ(SoC)であって、前記DRAMコントローラが、前記DRAMデバイスに対して保守イベントを実行するためにタイムオブサービス(ToS)ウィンドウを決定するように構成されるスケジューラモジュールを含み、前記ToSウィンドウが、前記処理デバイスに提供される割込み信号、および前記保守を実行するためのデッドラインによって定義される、SoCと、
前記処理デバイスであって
前記処理デバイスと通信しているオペレーティングシステムの割込みハンドラを用いて前記DRAMコントローラから前記割込み信号を受信し、
前記割込み信号に応答して、前記割込みハンドラを用いて前記保守イベントの優先順位を決定し、
前記優先順位に従って前記オペレーティングシステムのスケジューラの入力キューに前記保守イベントのための新しいスレッドを前記割込みハンドラを用いて挿入することによって、前記保守イベントをスケジュールする
ように構成される、処理デバイスと
を含む、システム。
【請求項２３】
前記処理ユニットが、前記ToSウィンドウの間に前記DRAMデバイスに対して前記保守イベントの実行を開始するようにさらに構成される、請求項22に記載のシステム。
【請求項２４】
前記DRAMコントローラが、前記保守イベントが実行されることなく前記ToSウィンドウが終了したかどうかを決定するためのタイマを含む、請求項22に記載のシステム。
【請求項２５】
前記スケジュールされた保守イベントが前記処理デバイスによって実行されることなく前記ToSウィンドウが終了する場合、前記DRAMコントローラが、前記保守イベントを実行するために介入する、請求項22に記載のシステム。
【請求項２６】
前記DRAMコントローラが、前記処理デバイス上のトラフィックをストールすることによって前記保守イベントを実行する、請求項25に記載のシステム。
【請求項２７】
前記保守イベントが、前記DRAMデバイスを定期的にサービスするための、リフレッシュ動作、較正動作、およびトレーニング動作のうちの1つまたは複数を含む、請求項22に記載のシステム。
【請求項２８】
前記処理デバイスが、前記オペレーティングシステムの前記割込みハンドラを用いてルックアップテーブルにアクセスし、かつ保守イベントのタイプ、前記処理ユニットに関連する現在の負荷、前記DRAMデバイスの現在の温度のうちの1つまたは複数に基づいて、前記割込みハンドラを用いて前記優先順位を選択することによって、前記保守イベントの前記優先順位を決定する、請求項22に記載のシステム。
【請求項２９】
前記保守イベントが、前記オペレーティングシステムのカーネルスケジューラの前記入力キューにサービススレッドを追加することによってスケジュールされる、請求項22に記載のシステム。
【請求項３０】
前記DRAMデバイスおよび前記SoCが、ポータブルコンピューティングデバイスに設けられる、請求項22に記載のシステム。
【国際調査報告】
2018508884.tif 000022
2018508884.tif 000023