JP2015061295A - 処理装置および処理方法 - Google Patents

Abstract

【課題】装置の消費電力を低減する。【解決手段】本発明の一態様としての処理装置において、第１の記憶部は、複数のアドレスを含むブロック単位でデータ読み書き可能であり、第１のプロセッサまたは第２のプロセッサの一方は、他方のプロセッサへ渡す第１〜第Ｎ（Ｎは２以上の整数）のデータを、第Ｘ（Ｘは１以上の整数）のデータの終了アドレスと第Ｘ＋１のデータの開始アドレスが連続したアドレスになるように前記第１の記憶部に書き込み、制御部は、前記一方のプロセッサが前記第１の記憶部への書き込みを行っている期間の少なくとも一部の間、前記他方のプロセッサを低消費電力モードに設定し、前記第１の記憶部への書き込みの完了後、前記他方のプロセッサを通常動作モードに設定して前記他方のプロセッサを前記第１の記憶部から前記第１〜第Ｎのデータを読み出し可能にする。【選択図】図１

Description

本発明の実施形態は、処理装置および処理方法に関する。

ノートパソコンやスマートフォンなどのモバイル端末が普及した背景には、常時ネットワーク接続可能である利便性向上がある。ネットワークの常時接続により、端末の消費電力が増加し、バッテリーの持ち時間の短さが問題となっている。このため、端末のネットワーク処理の省電力化が望まれる。

従来、装置の低消費電力化の方法として、無線アクセスネットワーク側(サーバサイド)で、当該装置へのデータの送信タイミングを調整したり、データをまとめて装置へ送信したりする方法が知られている。この手法は、大規模な装置を想定しており、大容量のメモリを装置が搭載する必要がある。

しかしながら、小型化したモバイル端末では、限られた容量のメモリしか搭載しておらず、上述の手法の適用は困難である。したがって、消費電力効率を高める別の工夫が必要である。

特表２０１２-５１７１２７号公報

本発明の実施形態は、装置の消費電力を低減することを目的とする。

本発明の一態様としての処理装置は、第１のプロセッサと、第２のプロセッサと、第１の記憶部と、制御部と、を備える。

前記第１の記憶部は、複数のアドレスを含むブロック単位でデータ読み書き可能である。

前記制御部は、前記第１のプロセッサおよび前記第２のプロセッサの少なくとも一方の電源供給を制御する。

前記第１のプロセッサまたは前記第２のプロセッサの一方は、他方のプロセッサへ渡す第１〜第Ｎ（Ｎは２以上の整数）のデータを、第Ｘ（Ｘは１以上の整数）のデータの終了アドレスと第Ｘ＋１のデータの開始アドレスが連続したアドレスになるように前記第１の記憶部に書き込み、
前記制御部は、前記一方のプロセッサが前記第１の記憶部への書き込みを行っている期間の少なくとも一部の間、前記他方のプロセッサを低消費電力モードに設定し、前記第１の記憶部への書き込みの完了後、前記他方のプロセッサを通常動作モードに設定して前記他方のプロセッサを前記第１の記憶部から前記第１〜第Ｎのデータを読み出し可能にする。

第１の実施形態に従った通信装置のブロック図である。 第１の実施形態の動作フローの一例を示す。 図２のステップＳ１０８の処理の詳細フローの一例を示す。 図１に示すデータ保持部の内容の一例を示す。 図１に示すデータ保持部の内容の別の例を示す。 第２の実施形態に従った通信装置のブロック図である。 第２の実施形態に従った送信処理を行う場合の通信装置の動作フローを示す。 第２の実施形態に従った受信処理を行う場合の通信装置の動作フローを示す。 第２の実施形態に係る通信装置の具体例に係る動作を示すシーケンス図である。 第３の実施形態に係るデータ保持部の内容を示す。 データ保持部にデータを格納した状態を示す図。

以下、図面を参照しながら、本発明の実施形態について説明する。

（第１の実施形態）
図１は、本発明の実施形態に従った処理装置を備える通信装置のブロック図である。

本通信装置は、通信ネットワーク１４を介してサーバ１５等の他の通信装置と通信可能である。通信装置は、たとえば、サーバ１５からウェブページファイルなどのデータをダウンロードしたり、データをサーバにアップロードしたりすることが可能である。本通信装置は、たとえばモバイル端末、デスクトップ型PC、ノート型PCなどの端末に実装される。

本通信装置は、処理部１、データ保持部１２、処理部２、電源制御部１１および通信部１３を備える。本実施形態の処理装置は、処理部１、データ保持部１２、処理部２、電源制御部１１を備えるものとして定義してもよいし、さらに通信部１３を備えたものでもよい。

電源制御部１１は、電源ドメイン単位で電源供給を制御する。本実施形態では、電源ドメインA〜Cが存在する。電源ドメインAは処理部１を有し、電源ドメインBはデータ保持部１２を有し、電源ドメインCは処理部２と通信部１３を有する。それぞれの電源ドメインは、電源制御部１１によって電源供給を個別に制御する。それぞれの電源ドメインは同一のチップ上もしくは基盤上にあってもよいし、別々のチップ上もしくは基盤上にあってもよい。

一例として、電源ドメインAがメインボード上に配置され、電源ドメインB,Cが、メインボードに接続されたネットワークインターフェースカード（NIC）上に配置されてもよい。一例として、処理部１が、OSまたはアプリケーション等を実行するCPU（第１のプロセッサ）で、処理部２がCPUの指示を受けて、指示された処理の実行を制御するマイコン（第２のプロセッサ）、通信部１３が、MAC層や物理層等の処理を行う通信インタフェース、データ保持部１２がメモリ装置でもよい。メモリ装置には、SRAMやDRAMやMRAMのようなバイト単位でのデータの読み書きが可能な揮発性メモリや、NAND型フラッシュメモリのような、バイトよりも大きなブロック単位でデータの読み書きを行うメモリ等、種々のものが存在するが、本実施形態では、データ保持部１２が、NAND型フラッシュメモリであることを想定する。なお、データ保持部はNAND型フラッシュメモリに限定されるものではなく、ブロック単位で読み書きを行う他のメモリでもよい。

処理部１は、ファイル等のデータの取得要求や送信要求等の任意の処理の指示を処理部２に行う。一例として処理部１は、URIを指定したウェブページ等の取得要求を処理部２に出力する。

処理部２は、処理部１から指示を受けて動作する。URIを指定した取得要求であれば、ネットワーク上のサーバからURIで特定されるデータを取得し、取得したデータ等をデータ保持部１２へ書き込む動作を行う。処理部２は、指示された処理を完了したら、処理の完了を処理部１に通知する。

データ保持部１２は、処理部２の処理の結果として得られる実行結果データ、処理部１が処理部２に指示する際に必要なデータを記憶する。指示する際に必要なデータとしては、取得指示の場合は、URI等を指定した取得指示コマンド、データ送信指示の場合は、送信指示コマンドや送信対象となる送信データ等があり得る。処理部１は、データ保持部１２を介在して指示を処理部２に渡す他、データ保持部１２を介さずに、直接に渡す形態も可能である。データ保持部１２へは処理部１および処理部２のいずれもがデータを読み書き可能である。

処理部１は、処理部２から処理の完了通知を受けた場合、データ保持部１２にアクセスして、実行結果データを読み出す。サーバからの取得要求であれば、データ保持部１２には、サーバから受信したデータ等が格納されている。処理部１は、読み出した実行結果データを、図示しないDRAM等の不揮発性メモリに書き込んでも良い。

通信部１３は、ネットワークに接続された他の通信装置との間で無線または有線の通信を行う。通信を行う相手装置は、たとえばウェブサーバ等のサーバでもよいし、ファイルサーバでもよいし、他の端末でもよい。ネットワークは、有線または無線の任意のネットワークであり、単一のネットワークの他、有線または無線の複数のネットワークの複合型でもよい。

図２に、本実施形態の動作フローの一例を示す。

処理部１が、処理部２に処理を指示する場合、まず電源制御部１１がデータ保持部１２の電源状態を確認し（Ｓ１０１）、オフ（OFF）であれば、データ保持部１２の電源をオン（ON）にする。

処理部１は、データ保持部１２の電源がON状態にあることの通知を電源制御部１１から受けると、必要に応じて、処理部２に対する指示、および処理部２に渡すデータをデータ保持部１２に書き込む。なお、指示は、処理部２に直接送る形態も可能である。処理部２の電源がOFFの場合は、以下のステップＳ１０５で処理部２がONにされた後、指示を送っても良い。データ保持部１２へ送信データ等を書き込む場合は、後述するように、本実施形態の特徴の１つとなる構造化したデータ（データ識別子、データ長、データ）を書き込むとともに、データ管理テーブルの書き込みを行う。

電源制御部１１は、処理部２の電源状態を確認し、OFFであれば、処理部２の電源をONにする（Ｓ１０５）。

処理部１は、処理部２に処理を実行するよう指示する（Ｓ１０６）。なお、指示は、データ保持部１２の事前に決められた領域を介して通知してもよいし、処理部２に直接通知する構成でもかまわない。

電源制御部１１は、処理部１から処理部２への通知を行ったとの報告を受け、これをトリガーに処理部１を通常動作モードから低消費電力モードに遷移させる（Ｓ１０７）。または、電源制御部１１は、処理部２から処理部１からの指示の通知を受けたとの報告を受けたことをトリガーとして、処理部１を通常動作モードから低消費電力モードに遷移させてもよい。

ここで、低消費電力モードは、処理部１の回路全体への電源供給を停止することで実現してもよいし、当該回路の一部への電源供給を停止することで実現してもよいし、動作周波数を低減することで実現してもよいし、特定の処理の実行を強制的に停止することで実現してもよい。なお、処理部１が、優先的に実行しなければならない処理があるなどの条件が満たされる場合は、低消費電力モードへ遷移しない構成も可能である。なお、上述した例では、データ保持部および処理部２は電源のON/OFFの二通りの制御を示したが、処理部１のようなON/OFF以外の低消費電力モードと通常動作モードを定義して制御を行ってもかまわない。なお、ON/OFF制御の場合、ON状態が通常動作モードに対応し、OFFが低消費電力モードに対応する。

処理部２は、処理部１が低消費電力モードにある間、処理部１より指示された処理を実行する（Ｓ１０８）。本ステップの詳細は後述する。なお、本フローの例では、処理部２が、指示された処理を行っている間のすべての期間、処理部１が低消費電力モードにあるが、当該期間の少なくとも一部の期間の間のみ、処理部１が低消費電力モードにあってもよい。

処理部２の処理の実行が完了すると、電源制御部１１は、処理部１の電源状態を確認し（Ｓ１１０）、処理部１が低消費電力モードにある場合は、通常動作モードに復帰させる（Ｓ１１１）。

処理部２は、電源制御部１１から処理部１が通常動作モードにあることを通知されると、処理部１に処理の完了通知を送る（Ｓ１１２）。

電源制御部１１は、処理部２から処理の完了通知を受けたとの報告を処理部１から受けると、処理部２の電源をOFFにする（Ｓ１１３）。なお、電源制御部１１は、処理部２から処理部１へ処理の完了通知を送ったとの報告を受けたことをトリガーとして、処理部２の電源をOFFにしてもよい。

処理部１は、処理部２からの処理の完了通知を受けると、データ保持部１２から実行結果データを読み出す（Ｓ１１４）。処理部２へ指示した内容がデータの取得要求であれば、サーバ等から取得されたデータ等を実行結果データとしてデータ保持部１２から読み出す。送信要求であれば、送信結果が成功か否か等の結果をデータ保持部１２から読み出す。なお、処理部２は、処理部１に、送信結果が成功したか否か等の結果を、処理部１に直接通知する構成も可能である。

この後、電源制御部１１は、データ保持部１２からの読み出し完了の通知を処理部１から受け、これをトリガーに、データ保持部１２の電源をOFFにする（Ｓ１１５）。

図３は、図２のステップＳ１０８の処理の詳細フローの一例を示す。処理部１は処理部２に対し、複数のファイルの受信、または複数のファイルの送信といった、同様の動作が繰り返される処理を指示する（Ｓ２０１）。ここでは、処理部１が処理部２に、ネットワーク上のサーバから複数のファイルの取得を指示する場合を示す。

処理部２は、処理部１からの要求に応じて、サーバから応答となるデータを逐次取得し（Ｓ２０２）、取得したデータ等をデータ保持部１２に書き込む（Ｓ２０３、Ｓ２０４、Ｓ２０５）。ステップＳ２０３では最初の書き込み（ループの１回目の処理）では、任意の方法で決定したブロックの先頭アドレスを書き込みの開始アドレスとして決定する。この応答となるデータは、ヘッダ等の情報を含んだ応答データそのものであり、取得要求したファイルも含む。処理部２、前記データ等取得中に取得データを解析してデータ長やデータ種別等を判断し、関連するデータも合わせて取得してもよい。データを書き込む際は、データを一意に識別するデータ識別子と、当該データの長さの情報（データ長）のいずれか、もしくは両方を含む管理情報を、当該データの先頭に追加した構造化したデータを書き込む。

図４Ａ（A）に、構造化したデータ（データ識別子＋データ長＋データ）の例を示す。たとえばデータ１を取得した場合は、データ１のデータ識別子１、データ長１、データ１の結合である構造化したデータ１を、データ保持部１２の連続したアドレスに書き込む。図１０（A）に構造化したデータ１をデータ保持部１２に格納した例を示す。実線で区切られた個々の矩形はブロックを概略的に示している。１つのブロックは複数のアドレスを含む。図面に沿って左から右への方向はアドレスの昇順方向であり、さらに下の行に進むほどアドレスが大きくなっている。構造化したデータ１は２行目の７ブロック目のブロック先頭から書き込まれ別のブロックの途中まで、連続したアドレスで書き込まれている。データ保持部１２の所定領域または処理部２の内部に、最初に書き込みを開始したブロックの開始アドレス（ここでは構造化したデータ１の先頭のアドレス）の情報を記憶しておいてもよい。読み出しの際、この情報を利用してもよい。

ここで、データ識別子は、URI等を指定した取得要求（コマンド）から一意に導出可能なユニークなIDでもよいし、コマンドあるいはURIそのものでもよい。IDの長さを短く設定すれば、記憶サイズを小さくできる利点がある。データ長はサーバから受信されるデータのヘッダ情報から取得しても良いし、データの長さを解析してデータ長を取得してもよい。取得要求がHTTP要求であれば、応答はHTTP応答であり、HTTP応答全体がデータとして、データ識別子およびデータ長とともに、構造化したデータとしてデータ保持部１２に格納される。

処理部２は、データ保持部１２へのデータ書き込みとともに、図４Ａ（B）に示すデータ管理テーブルへの書き込みを行う（Ｓ２０６〜Ｓ２０８）。データ管理テーブルもデータ保持部１２に格納されているとするが、処理部２が内部的に保持する構成も可能である。データ保持部１２におけるデータ管理テーブルの格納位置の情報をデータ保持部１２の所定領域に保持しておき、処理部１または処理部２が、後に所定領域にアクセスすることでデータ管理テーブルを取得可能にしてもよい。データ管理テーブルは、データ識別子、データの長さ、データの開始位置、データ種類などの属性情報をデータごとに保持する。処理部２は、取得したデータについて、データ識別子と、データ長と、当該データが書き込まれたデータ保持部のデータの書き込み開始位置（書き込み開始アドレス）、データの種別（テキスト型、画像型など）等の属性情報をデータ管理テーブルに書き込む。たとえば図４Ａ（B）の開始位置１は、図４Ａ（A）におけるデータ１の開始アドレスである。

データ保持部１２へ書き込むべきデータがまだ存在する場合は、このデータ管理テーブルにより、直前に書き込んだデータの開始位置とそのデータ長、さらにデータ識別子とデータ長の各固定長サイズの情報に基づき、データ保持部１２において次に書き込むデータの書き込み開始位置を算出する（Ｓ２０３、Ｓ２０４）。一方、次に書き込む構造化したデータの書き込み開始位置は、直前に書き込んだデータの終了位置（終了アドレス）と連続するアドレスになるようにする。直前に書き込んだデータの終了アドレスがブロックの途中のアドレスであれば、同じブロック内の当該アドレスの次のアドレスから次の構造化したデータの書き込みを行う。図４Ａ（A）および図１０（A）に示す例では、構造化したデータ１に続いて、構造化したデータ２および構造化したデータ３についても書き込みを行っており、構造化したデータ１の終了アドレスと構造化したデータ２の開始アドレスが連続するように（ブロック内で連続するように、またはブロックの終了アドレスと隣のブロックの開始アドレスに一致するように）書き込みを行う。同様に、構造化したデータ２の終了アドレスと構造化したデータ３の開始アドレスも連続するように（ブロック内で連続するように、またはブロックの終了アドレスと隣のブロックの開始アドレスに一致するように）書き込みを行う。また図４Ａ（B）に示すように、構造化したデータ２の終了アドレスと構造化したデータ３について、データ管理テーブルへのそれぞれの属性情報の書き込みも行っている。このように１つの構造化したデータのみならず、複数の構造化したデータ間についてもアドレスが連続するように書き込みを行う。

ただし、書き込みの途中で、別のアプリケーションのデータなどが格納されたブロックが存在する場合がある。この場合、そのブロックのデータを消去した上で書き込みを行うことが可能な場合はそのようにすればよいが、消去が許されない場合もあり得る。この場合、連続したアドレスのブロックに書き込みを行うことができないため、当該ブロックをスキップするなどして、別の離れた場所のブロックの先頭から続けて書き込みを開始すればよい。この様子を図４Ｂ（A）および図１０（B）に示す。図１０（Ｂ）の「×」が記載されたブロックが書き込みできないブロックを表す。

ブロックの連続性が途切れた場合は、途切れたブロックの終了アドレスと、新たに開始するブロックの開始アドレス情報をポインタとして保持しておけばよい。データ管理テーブルの“開始位置”も、終了位置（終了アドレス）、開始位置（開始アドレス）を追加して、“開始位置、終了位置、開始位置”のようにすることで、データの連続性を維持して読み出しを行うことが可能である。たとえば図４Ｂ（A）に示すように、データ１の書き込みの途中で連続するブロックへの書き込みが不可になった場合は、途切れたブロックの終了位置１−１と、書き込み再開されたブロックの開始位置１−２の情報を記憶すればよい。この情報は、構造化したデータの最初の書き込み開始位置と同様に、処理部１に通知してもよい。データ管理テーブルにも開始位置１（１−１）に加え、終了位置１−１、開始位置１−２を追加する（図４Ｂ(B)）。なお、データ識別子やデータ長を書き込みの途中で連続するアドレスへの書き込みができなくなった場合（ブロックが不連続になる場合）も同様に、終了位置と開始位置の情報を追加的に記憶すれば、問題なく読み出すことができる。ここで述べたブロックの連続性（アドレスの連続性）が切れた場合の処理の例は一例であり、離れたブロックの連続性を表現できる方法であればどのような方法を用いてもよい。

以上に述べたような書き込みをシーケンシャル書き込みと呼ぶ。シーケンシャル書き込みを行うことで、データ保持部からのデータ読み出しの際に読み出す際にブロックを連続して読み出せるため（シーケンシャルな読み出し）、動作速度の低下を抑制できるとともに、低消費電力化を図ることができる。また、データ保持部からの読み出しをDMA転送で行う場合にも、DMA転送では開始位置と読み出しサイズを指定することから、読み出し指示の回数を減らし、低消費電力化を図ることができる。また、個々のブロックに無駄なくデータが格納されるため、読み込みのブロック数または書き込みのブロック数も低減でき得るため、低消費電力化につながる。

個々のブロックに無駄なくデータが格納されることについてさらに説明する。１つの応答データは通常、パケットが収容可能なデータサイズ長の制約から、複数のパケットに分割して運ばれてくる場合もある。処理部２が十分な大きさのバッファを有している場合は、各パケットで運ばれてきたデータを結合して１つのデータとしてから、構造化したデータを書き込んでも良い。または、１つ１つのパケットのデータごとに書き込みを行う場合や、ある程度パケットのデータが蓄積されるごとに、蓄積された分をまとめて書き込みを行う場合もあり得る。後者２つのケースでは、複数回に分けデータが書き込まれることになるため、特別な処理を行わないと、個々のデータがまだら状にブロックへ書き込まれ、個々のブロック内に書き込みが行われない無駄な領域も発生する。ブロック単位での読み出しではこのような領域の読み出しは非効率である。そこで、本実施形態はできるだけ連続したアドレスに書き込むため、分割した書き込まれるデータも、同じブロック内で連続するようになり、効率的な書き込みおよび読み出しが可能となる。なお、個々の構造化したデータ同士についても、上述したように、できるだけ先に書き込む構造化したデータの終了アドレスと次に書き込む構造化したデータの開始アドレスが連続したアドレスになるようにし、１つのブロック内の途中で１つの構造化したデータの書き込みが完了しても、続く構造化したデータは同じブロック内の続きのアドレスから書き込みを行うようにする。

処理部１から要求されたデータをすべて書き込んだら本フローの処理を終了し、図２のステップＳ１１２で、処理部２は処理部１へ書き込み完了を通知する。

この後、図２のステップＳ１１４では、処理部１がデータ保持部１２からデータを読み出す。データ１、２、３をこの順で読み出す場合の動作の例を示す。処理部１はデータ保持部１２のデータ管理テーブルからデータ１の開始位置１を特定し、開始位置１からデータ長１の長さのデータを読み出すことで、データ１を取得する。なお、データ識別子の導出方法は処理部２と処理部１で事前に共有されているものとする。

ここではデータ管理テーブルを用いてデータを取得する場合を示したが、データ管理テーブルを用いず、構造化したデータから直接読み出してもよい。この場合、構造化したデータの先頭のアドレス（図示の例ではデータ識別子１のデータの先頭アドレス）を処理部１に通知する。通知は、データ保持部１２の所定領域を介して行っても良いし、処理部１に直接行っても良い。処理部１は構造化したデータの先頭から読み出しを行うことで、各データのデータ識別子およびデータ長に基づき、各データ１、２、３を特定し、取得できる。

上述した図２の説明では、複数のファイルをサーバから取得する例を示したが、複数のファイルを送信する場合も同様にして行うことができる。この場合は、データ保持部１２への書き込み主体が処理部１である点が異なる。処理部２はデータ保持部１２の構造化したデータに含まれるデータを読み出して送信する。

本実施形態では、構造化したデータをデータ保持部１２に書き込んだが、変形例として、データ保持部１２にはデータのみ格納し、データ管理テーブルを利用して、必要なデータをデータ保持部１２から特定して、読み出すようにすることも可能である。

以上、本実施形態によれば、NAND等の不揮発性ストレージを介してデータ等を受け渡しできるとともに、動作速度の低下を抑制し、省電力効率を高めることが可能となる。

たとえば、低消費電力のため処理部１をスリープさせて、処理部２がデータをサーバから取得してNAND等の記憶部に書き込み、処理部１を起動させて一括してデータを渡す場合を考える。このような場合に、NAND等の記憶部に書き込まれたデータがまだら状態であると、ブロックを不必要に多く読み出す動作が発生するため、速度が遅延するとともに、消費電力が大きくなる。これに対し、本実施形態ではサーバから受信した各データがそれぞれ連続したアドレスに書き込まれるため、処理部１が読み出しを行う際も、高速かつ低消費電力で読み出しを行うことができる。

（第２の実施形態）
図５は、第２の実施形態に従った通信装置のブロック図である。 本実施形態の通信装置は、処理部１、判定部２１、データ保持部１、実行部２３、通信部１、処理部２、データ保持部２、通信部２、電源制御部１１を備える。処理部１、判定部２１、および実行部２３の機能は、同じプロセッサで実行されるソフトウェアにより実現されてもよい。

本通信装置は、電源が互いに独立に制御可能な２つの電源ドメインA,Bを有する。それぞれの電源ドメインは同一のSOC上にあってもよいし、別々の基盤上に構成されても構わない。

電源ドメインAは、処理部１、判定部２１、データ保持部１、実行部２３および通信部１を有する。

電源ドメインBは、処理部２、データ保持部２および通信部２を有する。

処理部１および処理部２は図１と同様であり、データ保持部２は図１のデータ保持部１２と同様であり、一例としてNAND型フラッシュメモリである。電源制御部１１は、電源ドメインA,Bの電源供給を制御する。

データ保持部１は、データ保持部２に比べ、ランダムアクセス性に優れた保持部であり、高速なメモリ装置である。一例として、データ保持部１は、SRAMやDRAMやMRAMであってもよい。ランダムアクセアス性に優れたとは、ブロック単位といった比較的大きな単位での読み書きを行うデータ保持部２に比べ、バイト単位といった細かい粒度でデータの読み書きを行うことができる意味である。

通信部１、２は、図１の通信部１３と同様にMAC層や物理層の処理を行う通信インタフェースであり、ネットワークに接続された他の通信装置との間で、無線または有線の通信を行う。なお、ここでは２つの通信部を備えた構成を示したが、通信部を１つのみとし、処理部１、２とで共通に用いる構成でもよい。この場合、１つの通信部を独立した電源ドメインCに配置してもよいし、電源ドメインAまたはBに配置してもよい。

判定部２１は、処理部１が行う処理が、処理部２で代理処理することが適しているか判断する。判定部２１は、処理部１の要求内容や、当該処理を行うために使用する通信プロトコルの種類等から判断する。たとえばHTTPのGET要求等の場合は、プリフェッチが可能な要求であるため、処理部２が代理処理することが適していると判断し、HTTPのHEAD要求等の場合は、プリフェッチが不要な要求のため、処理部２で代理してもらう効果が低く、適していないと判断する。

ここでプリフェッチとは、最初に要求したHTMLファイルから参照されている埋め込みオブジェクト（画像ファイル、スクリプトファイル、スタイルシートなど）を事前に取得する機能を指す。例えばＨＴＴＰを用いてウェブページを要求する場合を考える。ウェブページはその構成と文字情報を提供するＨＴＭＬファイル、ページのデザインに関する情報を提供するスタイルシート、スクリプトファイル、画像ファイルなどで構成されている。これらのファイルをすべて取得しなければウェブページを正確に表示できない。通常、最初にＨＴＭＬファイルを取得し、その内容を解析して初めてスタイルシートやスクリプトファイル、画像ファイルが参照されていることを把握する。このため、多数の取得要求が順次生成され、通信効率が悪くなってしまう。そこで、処理部２が、ＨＴＭＬファイルを最初にサーバから受け取ると、同ファイルを解析し、参照されている他のファイルを特定し、順次それらのファイルをプリフェッチする。

図６は、第２の実施形態に従った送信処理を行う場合の通信装置の動作フローを示す。

処理部１が送信処理の実行を開始すると（Ｓ３０１）、処理部１は、送信データをデータ保持部１（DRAM等）に書き込む（Ｓ３０２）。判定部２１は、送信処理を処理部２で代理させるかを判断し、代理させない場合は、実行部２３がデータ保持部１から送信データを読み出して、通信部１を用いて、送信処理を実行する（Ｓ３０４）。処理が完了すると、実行部２３は処理部１に処理の完了として実行結果を通知する。なお、以上の処理では処理部２は使用されないため、電源制御部１１は、電源ドメインBをOFFまたは低消費電力モードにしておいてよい。

一方、判定部２１が、送信処理を処理部２に代理させると決定した場合は、電源ドメインBがOFFであれば電源制御部１１を用いてONにする。そして、実行部１が送信データをデータ保持部１から読み出して、データ保持部２に書き込む（Ｓ３０５）。書き込みは、第１の実施形態で述べたように構造化したデータおよびデータ管理テーブルの書き込みを行い、また構造化したデータはシーケンシャル書き込みを行う。書き込みが完了した後、電源ドメインAをOFFまたは低消費電力モードに移行してもよい。

処理部２は、データ保持部２からデータを読み出し、通信部２を用いて送信する。図４Ａ（A）のような構造化したデータが格納されている場合は、すべてのデータ１、２、３の送信が完了するまで、データ保持部２からデータを読み出して送信することを繰り返す（Ｓ３０６、Ｓ３０７）。データ保持部１にはシーケンシャル書き込みが行われているため、効率的なデータ読み出しが可能となる。

すべてのデータの送信が完了すると、必要に応じて電源ドメインAを、電源制御部１１を用いて通常動作モードに移行して、処理部２は処理の完了として実行結果を処理部１に通知する（Ｓ３０８）。

図７は、第２の実施形態に従った受信処理を行う場合の通信装置の動作フローを示す。

処理部１が受信処理の実行を開始すると（Ｓ４０１）、判定部２１は、処理部２に受信処理を代理させるかを判断し（Ｓ４０２）、代理させない場合は、実行部２３が通信部１を用いて、受信処理を実行する（Ｓ４０３）。実行部２３は、受信したデータをデータ保持部１に書き込む。処理が完了すると、実行部２３は、処理部１に処理の完了として実行結果を通知する（Ｓ４０４）。なお、以上の処理では、処理部２は使用されないため、電源制御部１１は、電源ドメインBをOFFまたは低消費電力モードにしておいてよい。

一方、判定部２１が、処理部２に受信処理を代理させると決定した場合は、電源ドメインBがOFFであれば電源制御部１１を用いてONにする。そして、実行部１は、処理部２に受信処理を指示し（Ｓ４０５）、処理部２は、通信部２を用いてサーバ等からデータ受信を行う（Ｓ４０６）。処理部２は、受信したデータを含む構造化したデータを、第１の実施形態で述べたシーケンシャル書き込みでデータ保持部２に書き込む（Ｓ４０７）。またデータ管理テーブルへの書き込みも行う。

プリフェッチすべきデータがあればそのデータもすべて取得する。プリフェッチした場合は、プリフェッチの要求（コマンド）等からデータ識別子を生成し、プリフェッチにより取得したデータを含む構造化したデータをデータ保持部２に書き込み、データ管理テーブルにも属性情報を書き込む。

指示されたデータをすべて受信した場合は（たとえば指定サイズがあった場合は、当該サイズ以上のデータを受信したなど）（Ｓ４０８のYES）、処理部２は、必要に応じて電源ドメインAを、電源制御部１１を用いて通常動作モードに移行して、処理の完了として実行結果を処理部１に通知する（Ｓ４０４）。

この後、実行部２３、処理部１または処理部２は、データ保持部２からデータ保持部１へ構造化したデータをコピーまたは移動する。このとき、構造化したデータを格納したデータ保持部１のアドレス（例えばDRAMのアドレス）を対応づけたリストを生成して、以降の読み出しに利用してもよい。また、データ管理テーブルのコピーまたは移動を行っても良い。データ保持部２へのシーケンシャル書き込みが行われているため、効率的な構造化したデータの読み出し（シーケンシャルな読み出し）が可能となる。なお、データ保持部１はDRAM等のランダムアクセス可能なメモリを想定しているため、データ保持部１へは任意の方法でデータを書き込めば良い。なお、データの受信は完了していないが、受信開始からの時間が指定時間以上経過した場合は（Ｓ４０９のYES）、タイムアウトとして、処理を終了し、必要に応じて電源ドメインAを、電源制御部１１を用いて通常動作モードに移行した上、その旨を処理部１に通知してもよい（Ｓ４０４）。指定時間はあらかじめ決められていても良いし、処理部１が処理部２に通知してもよい。

図８は、本実施形態に係る通信装置の具体例に係る動作を示すシーケンス図である。

図５に示した処理部１がブラウザ３１，判定部２１および実行部２３がプロキシ３２、処理部２がオフロード処理部３３および代理取得部３４、通信部２が通信部３５に対応する場合の動作を示す。

ユーザのボタン操作によりブラウザ３１からHTTPリクエストが発行され（Ｓ５０１）、プロキシ３２は、当該HTTPリクエストに対応するデータがデータ保持部１にないため、代理取得要求をオフロード処理部３３に行う（Ｓ５０２）。このとき、電源ドメイン２がOFFであれば電源制御部１１によりONにする。また、電源ドメインAを低消費電力モードに移行してもよい。

オフロード処理部３３は代理取得部３４に代理取得処理を指示し（Ｓ５０３）、代理取得部３４は、通信部３５を用いて外部サーバと通信し、データを取得する（Ｓ５０４、Ｓ５０５）。代理取得部３４は、取得したデータ（ファイル）に埋め込みオブジェクト等があるときは、上述したプリフェッチを行い、当該埋め込みオブジェクトも取得する。代理取得部３４は、取得したデータを含む構造化したデータを、第１の実施形態で述べたシーケンシャル書き込みにより、データ保持部２へ書き込みを行う（Ｓ５０６）。またデータ管理テーブルへの書き込も行う。

データの取得が完了すると、代理取得部３４は処理完了をオフロード処理部３３に通知する（Ｓ５０７）。このとき電源ドメイン１が低消費電力モードであれば、電源ドメイン１を通常動作モードに移行する。オフロード処理部３３はプロキシ３２に代理取得の完了通知を通知し、プロキシ３２は、オフロード処理部３３を介してデータ保持部２から、構造化したデータ、およびデータ管理テーブルの読み出しを行う（Ｓ５０８、Ｓ５０９、Ｓ５１０、Ｓ５１１）。プロキシ３２は、オフロード処理部３３を介さずにデータ保持部２から直接、読み出しを行うことも可能である。なお、データ管理テーブルはデータ保持部２から読み出してもよいし、オフロード処理部３３が内部バッファに保持しておき、これを渡しても良い。

プロキシ３２は、取得した構造化したデータとデータ管理テーブルをデータ保持部１に書き込む。このとき、電源ドメインBをOFFにしてもよい。そして、プロキシ２は、HTTPリクエストに対応するデータをデータ保持部１から読み出し、応答としてブラウザ３１に返す（Ｓ５１４）。

ブラウザ３１から再度HTTPリクエストを受けた場合（Ｓ５１５）、リクエストされたURIが、上記で取得した埋め込みファイルのURIである場合は、これはプリフェッチで取得済みでデータ保持部１に格納されているため、プロキシ３２はこのデータをデータ保持部１から読み出して（Ｓ５１６）、応答としてブラウザ（Ｓ５１７）に返す。

読み出しの際は、構造化したデータを先頭から探索してデータ識別子から目的のデータを特定してもよいし、データ管理テーブルを用いて特定してもよい。または、データ保持部１への書き込み時に構造化したデータを格納したデータ保持部１のアドレスのリストを生成しておき、このリストを利用してもよい。

（第３の実施形態）
本実施形態のブロック図は、第１の実施形態で用いた図１と同様であるため、以下、図１を用いて説明する。

処理部２は、処理部１よりデータの送信指示または受信指示(コマンド)を受け、処理を実行する。処理部２は、コマンドを実行するとともに、処理部１より受けた指示の内容を、図９（A）に示すように、データ保持部１２に書き込む。具体的には、コマンドの識別子と、コマンドの長さと、コマンド自体とを一組として、構造化したコマンドとして、書き込みを行う。書き込みは、第１の実施形態で述べた構造化したデータと同じように、シーケンシャル書き込みで行うことが望ましいが、これに限定されない。なお、コマンド識別子は処理部１が生成し、処理部２にコマンドとともに送る。構造化したコマンドの書き込み位置の情報を、データ保持部１２の領域を介してまたは直接、処理部２に通知してもよい。

また、処理部２は、図９（Ｃ）に示すように、第１の実施形態で述べたデータ識別子、データ長、データの開始位置に加え、コマンドの識別子、コマンドの長さ、コマンドの位置をデータ保持部１２に格納する。データ保持部に書き込まれるコマンドは、コマンドの全内容、またはコマンドの実行の結果得られたデータと一意に紐づけるためのURL、またはURLを短縮したものを含む。たとえばコマンドとして、HTTPリクエストもしくはそのヘッダを保持してもよい。コマンドからデータ識別子が導出され、この導出のアルゴリズムは処理部１と処理部２で共通に保有しているものとする。

なお、本実施形態でも、第１の実施形態と同様に、図９（B）に示す構造化したデータをデータ保持部１２に書き込む。プリフェッチにより複数のデータを取得したときは各プリフェッチのコマンドを含む構造化したコマンドを記憶し、プリフェッチしたデータを含む構造化したデータも同様に記憶する。データ管理テーブルもこれらに合わせて書き込む。

処理部１または処理部２は、データ保持部１２から読み出しを行う際は、例えばデータ管理テーブルからコマンド識別子とデータ識別子の組を特定し、それぞれに対応するコマンドおよびデータを、構造化したコマンドおよび構造化したデータから読み出せばよい。コマンドの内容から、そのコマンドの実行結果として得られたデータを特定できるため、処理部２は、自身で、実行指示したコマンドや、取得要求したファイル名等を管理しなくてよい。なお、第２の実施形態のように構造化したコマンドもDRAM等のデータ保持部１に読み出しても良い。構造化したコマンドも、構造化したデータと同様に、シーケンシャル書き込みを行っても良い。ここではデータ管理テーブルを用いてコマンドとその実行結果としてのデータを特定する例を示したが、構造化したコマンドおよび構造化したデータをそれぞれ先頭から読んで探索することで、これらを特定してもよい。

尚、各実施形態の処理装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現することが可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することができる。このとき、処理装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいは通信網を介して上記のプログラムを配布して、このプログラムをコンピュータ装置に配置することで実現出来る。また、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスク又はCD-R、CD-RW、DVD-RAM、DVD-R等の記憶媒体などを利用することが出来る。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (16)

1. 第１のプロセッサと、
   第２のプロセッサと、
   複数のアドレスを含むブロック単位でデータ読み書き可能な第１の記憶部と、
   前記第１のプロセッサおよび前記第２のプロセッサの少なくとも一方の動作を制御する制御部と、を備え、
   前記第１のプロセッサまたは前記第２のプロセッサの一方は、他方のプロセッサへ渡す第１〜第Ｎ（Ｎは２以上の整数）のデータを、第Ｘ（Ｘは１以上の整数）のデータの終了アドレスと第Ｘ＋１のデータの開始アドレスが連続したアドレスになるように前記第１の記憶部に書き込み、
   前記制御部は、前記一方のプロセッサが前記第１の記憶部への書き込みを行っている期間の少なくとも一部の間、前記他方のプロセッサを低消費電力モードに設定し、前記第１の記憶部への書き込みの完了後、前記他方のプロセッサを通常動作モードに設定して前記他方のプロセッサを前記第１の記憶部から前記第１〜第Ｎのデータを読み出し可能にする、処理装置。
2. 前記一方のプロセッサは、前記第１〜第Ｎのデータを前記第１の記憶部におけるそれぞれ連続したアドレスに書き込む
   請求項１に記載の処理装置。
3. 他の装置とネットワークを介して通信する通信部をさらに備え、
   前記第１のプロセッサは前記他方のプロセッサであり、前記第２のプロセッサは前記一方のプロセッサであり、
   前記第１のプロセッサは前記第２のプロセッサに前記他の装置からのデータ取得要求を行い、
   前記制御部は、前記第１のプロセッサがデータ取得要求を行った後、前記第１のプロセッサを低消費電力モードに設定し、
   前記第２のプロセッサは前記他の装置から取得した第１〜第Ｎのデータである前記第１〜第Ｎのデータを前記第１の記憶部に書き込み、
   前記制御部は、前記第１の記憶部への書き込みの完了後、前記第１のプロセッサを通常動作モードに設定する
   請求項１または２に記載の処理装置。
4. 前記ブロックよりも小さなサイズ単位でデータ読み書き可能な第２の記憶部をさらに備え、
   前記制御部は、前記第１のプロセッサがデータ取得要求を行った後、前記第１のプロセッサおよび前記第２の記憶部を低消費電力モードに設定し、前記第１の記憶部への前記第１〜第Ｎのデータの書き込みの完了後、前記第１のプロセッサおよび前記第２の記憶部を通常動作モードに設定し、
   前記第１のプロセッサまたは前記第２のプロセッサは、前記第２の記憶部が通常動作モードに設定された後、前記第１の記憶部に書き込まれた第１〜第Ｎのデータを読み出して前記第２の記憶部に書き込む
   請求項３に記載の処理装置。
5. 他の装置とネットワークを介して通信する通信部をさらに備え、
   前記第１のプロセッサは前記一方のプロセッサであり、前記第２のプロセッサは前記他方のプロセッサであり、
   前記第１のプロセッサは前記他の装置へ送信するデータである前記第１〜第Ｎのデータを前記第１の記憶部に書き込み、
   前記制御部は、前記第１の記憶部への前記第１〜第Ｎのデータの書き込み完了後、前記第２のプロセッサを通常動作モードに設定し、前記第１のプロセッサを低消費電力モードに設定し、
   前記第２のプロセッサは、前記第１の記憶部から前記第１〜第Ｎのデータを読み出して前記他の装置へ前記通信部を用いて送信する
   請求項１または２に記載の処理装置。
6. 前記一方のプロセッサは、前記第１〜第Ｎのデータのそれぞれを識別するデータ識別子と、前記データのそれぞれの長さ情報とを含む管理情報を前記第１〜第Ｎのデータのそれぞれの先頭に結合した第１〜第Ｎの構造化したデータを、前記第Ｘの構造化したデータの終了アドレスと第Ｘ＋１の構造化したデータの開始アドレスが連続するように前記第１の記憶部に書き込む
   請求項１ないし５のいずれか一項に記載の処理装置。
7. 前記一方のプロセッサは、前記第１〜第Ｎの構造化したデータ前記第１の記憶部におけるそれぞれ連続したアドレスに書き込む
   請求項６に記載の処理装置。
8. 前記他方のプロセッサは、前記第１の構造化したデータの開始アドレスから読み出しを開始し、前記データ識別子と前記長さ情報に基づいて、前記第１〜第Ｎのデータを特定して読み出す
   請求項６または７に記載の処理装置。
9. 前記一方のプロセッサは、前記第１〜第Ｎのデータのそれぞれについて、前記データ識別子と、前記データの開始アドレスと、前記データのそれぞれの長さ情報とを少なくとも含むデータ管理テーブルを生成し、前記データ管理テーブルを前記第１の記憶部に書き込む
   請求項６ないし８のいずれか一項に記載の処理装置。
10. 前記他方のプロセッサは、前記データ管理テーブルに基づき前記第１の記憶部から前記第１〜第Ｎのデータを読み出す
    請求項６ないし９のいずれか一項に記載の処理装置。
11. 前記第１のプロセッサは、前記第２のプロセッサにデータ受信またはデータ送信を指示するコマンドの実行要求を発行し、
    前記一方のプロセッサは、前記コマンドの識別子と、前記コマンドの長さ含む管理情報と、前記コマンドまたはその短縮形を結合して得られる構造化したコマンドを、前記第１の記憶部に書き込み、
    前記コマンドまたはその短縮形から、前記コマンドの実行により受信または送信されるデータのデータ識別子が算出される
    請求項６ないし１０のいずれか一項に記載の処理装置。
12. 前記一方のプロセッサは、前記データ識別子と、前記データの開始アドレスと、前記データのそれぞれの長さ情報と、前記コマンドの識別子と、前記コマンドの開始アドレスと、前記コマンドの長さ情報とを少なくとも含むデータ管理テーブルを生成し、前記データ管理テーブルを前記第１の記憶部に書き込む
    請求項６ないし１０のいずれか一項に記載の処理装置。
13. 前記第１の記憶部は、ＮAＮD型フラッシュメモリである
    請求項１ないし１２のいずれか一項に記載の処理装置。
14. 前記ブロックよりも小さなサイズ単位でデータ読み書き可能な第２の記憶部をさらに備え、
    前記第１のプロセッサは、前記第１〜第Ｎの構造化したデータまたは前記第１〜第Ｎのデータを前記第２の記憶部に書き込み、前記第２の記憶部へ前記第１〜第Ｎの構造化したデータまたは前記第１〜第Ｎのデータを書き込んだアドレスを含むリストを生成する
    請求項６ないし９のいずれか一項に記載の処理装置。
15. 前記第２の記憶部は、バイト単位での読み書きが可能なメモリである
    請求項４または１４に記載の処理装置。
16. 第１のプロセッサまたは第２のプロセッサの一方は、他方のプロセッサへ渡す第１〜第Ｎ（Ｎは２以上の整数）のデータを、ブロック単位でデータを読み書き可能な第１の記憶部に書き込むステップと、
    前記一方のプロセッサが前記第１の記憶部への書き込みを行っている期間の少なくとも一部の間、前記他方のプロセッサを低消費電力モードに設定し、前記第１の記憶部への書き込みの完了後、前記他方のプロセッサを前記通常動作モードに設定して前記第１の記憶部から前記第１〜第Ｎのデータを読み出し可能にするステップと、を備え、
    前記第１の記憶部に書き込むステップは、第Ｘ（Ｘは１以上の整数）のデータの終了アドレスと第Ｘ＋１のデータの開始アドレスが連続したアドレスになるように前記第１〜第Ｎのデータの書き込みを行う、処理方法。

Images