JP6595868B2 - 情報処理システム、デバイス、インタフェース制御方法 - Google Patents

Description

本発明は、情報処理システム、デバイス、インタフェース制御方法の技術に関し、特にシリアルバスインタフェース制御の技術に関する。

近年の情報処理装置（情報処理システムとも呼ばれる）では、大規模ＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）が採用され初期設定レジスタの増大、設定手順の複雑化など初期化に対する高速化の必要性が高まっている。また、複数デバイス間での処理の複雑化などデバイス間の通信処理時間の改善は急務である。また、デバイスの外部ピン数の制限により、限られた信号本数で通信を行うケースも多く、信号を増やすことなく通信時間を削減する技術の開発が重要である。

信号本数の少ないシリアルインタフェースによる通信に係る、様々な関連技術が知られている。

例えば、特許文献１は、データ伝送速度変換装置の一例を開示する。特許文献１のデータ伝送速度変換装置は、調歩同期式のＲＳ−２３２Ｃ回線におけるデータ伝送速度を変換する装置である。そのデータ伝送速度変換装置は、伝送速度不明のデータを受信し、スタートビットを検出する。次に、そのデータ伝送速度変換装置は、１９２００ＢＰＳ（Ｂｉｔｓ Ｐｅｒ Ｓｅｃｏｎｄ）のクロックでそのデータをサンプリングする。次に、そのデータ伝送速度変換装置は、所定の伝送速度毎の、クロック数に対応するサンプリングアドレスのストップビットの位置をチェックする。次に、そのデータ伝送速度変換装置は、ストップビットのサンプリングアドレス位置から伝送速度を判定する。次に、そのデータ伝送速度変換装置は、上述のようにして伝送速度を判定したデータを、１９．２キロボーの固定伝送速度に変換して送信する。

しかしながら、上述のような調歩同期式のＲＳ−２３２Ｃ回線では、情報処理装置に搭載されるデバイス間の通信においては望ましくない、以下に示すような問題点があった。第１に、マスタデバイス側とスレーブデバイス側とのそれぞれにおいてクロック生成部を備える必要がある。第２にスタートビット、ストップビットがオーバヘッドとなり、通信性能が低下する。第３に、非同期データをサンプリングするためのクロックが必要である。

このような問題点を解決する技術が特許文献２に記載されている。特許文献２は、シリアル通信回路の一例を開示する。特許文献２のシリアル通信回路は、同期式のＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）バスにおいて、マスタデバイスがスレーブ選択信号を備えていても或いは備えていなくても、対応可能なシリアル通信回路である。そのシリアル通信回路は、コマンドとそのコマンドとは異なる同期識別コードとを１セットの入力データとしてシリアルに受け取る。次に、そのシリアル通信回路は、その同期識別コードが所定の値と一致する場合に、そのコマンドに基づく応答処理の実行開始を指示する。

ＳＰＩバスは、コンピュータ内部のＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）チップやＬＳＩ、装置などのデバイス間を接続するためのデータ伝送路の規格のひとつである。ＳＰＩバスは、３線式を取ることが可能なシリアルバスインタフェースであるため、それらのデバイス間を接続する際に少ないピン数で接続することができる。ＳＰＩバスで接続されたマスタデバイス（以降マスタ）とスレーブデバイス（以降スレーブ）とが通信を行う場合、マスタが基準となる周波数のクロックを生成し、マスタ及びスレーブの双方がそのクロック信号に同期させてデータ転送を行う。デバイスどうしがＳＰＩバスを用いて接続された情報処理装置において、マスタはリクエスト（リクエストトランザクション）をスレーブに発行する。そして、スレーブはそのリクエストを受信し、そのリクエストに対するリプライ（リプライデータ）をマスタに返却する。

特開平５−３７５７２号公報 特開２０１４−８６８７６号公報

しかしながら、上述した特許文献２に記載された技術においては、リクエストに対するリプライを待つ時間が、必要以上に長い場合があるという問題点がある。

その理由は、以下のとおりである。

ＳＰＩバスを使った通信を行う情報処理装置において、例えば、１つのトランザクションでリクエストからリプライまでを連続して処理する。このような場合、通常、マスタがリードリクエストを発行し、スレーブはそのリードリクエストを受信し終わったクロックサイクルの、次のクロックサイクルのタイミングでリプライデータの返却を開始しなければならない。

ここで、スレーブがメモリアクセスを行うような、レイテンシが大きくすぐにリプライデータを返却できないような場合、マスタはＳＰＩクロックを停止し、スレーブにおいてリプライデータの準備が整うのを待つ必要がある。即ち、マスタは、スレーブがリプライデータを同期して返却できるように、クロックを生成しなければならない。しかし、マスタにはスレーブの状態が不明なため、マスタは、何時からリプライデータを受信するためのＳＰＩクロックを生成してよいのかを判断できない。

このような場合、例えば、マスタとスレーブとの間で、予めスレーブ側の処理に必要な時間が決めておかれる。そして、マスタは、スレーブ側のリプライデータ返却開始が可能なタイミングまで待ってからＳＰＩクロックを生成する。これでは、スレーブ側のトランザクション毎の処理時間に差がある場合、スレーブ側の処理時間が短いケースであっても、ＳＰＩクロックを生成するまでの待ち時間をスレーブ側の最長処理時間に合わさなければならない。ここで、処理時間に差がある場合とは、例えば同じメモリアクセスでもキャッシュヒットしたケースとメモリまでアクセスしなければならないケースなどの場合である。即ち、リクエストに対するリプライを待つ時間が、必要以上に長い場合があるという問題点がある。換言すると、この問題点は、全てのトランザクションを最長の処理時間で処理しなければならないという問題点であり、トランザクションの性能を著しく悪化させる要因となる。

以上説明したとおり、本発明が解決しようとする課題は、同期式のシリアル通信において、リクエストに対するリプライ待ち時間を短縮することである。

本発明の目的は、同期式のシリアル通信において、リクエストに対するリプライの待ち時間が、不適切に長い場合があるという問題点を解決し、その待ち時間を短縮することができる情報処理システム、デバイス、インタフェース制御方法を提供することにある。

本発明の一様態における情報処理システムは、リプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するリプライ受信手段を含むマスタデバイスと、前記マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信するリプライ送信手段を含むスレーブデバイスと、を含む。

本発明の一様態におけるマスタデバイスは、スレーブデバイスからリプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するリプライ受信手段を含み、前記スレーブデバイスは、マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信するリプライ送信手段を含むスレーブデバイスである。

本発明の一様態におけるスレーブデバイスは、マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、リプライ送信開始を通知するリプライ開始コード及び前記リプライ開始コードに連続するリプライデータと、のいずれかを送信するリプライ送信手段とを含み、前記マスタデバイスは、前記リプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するマスタデバイスである。

本発明の一様態におけるインタフェース制御方法は、マスタデバイスが、リプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信し、スレーブデバイスが、前記マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信する。

本発明は、同期式のシリアル通信において、リクエストに対するリプライ待ち時間を短縮することが可能になるという効果がある。

本発明の第１の実施形態に係る情報処理システムの構成を示すブロック図である。 第１の実施形態におけるリプライ受信回路の回路構成を示すブロック図である。 第１の実施形態における情報処理システムの動作を示すフローチャートである。 関連技術における動作を示すフローチャートである。 本発明の第２の実施形態に係る情報処理システムの構成を示すブロック図である。 第２の実施形態におけるリプライタイムアウト検出回路の回路構成を示すブロック図である。 本発明の第３の実施形態に係る情報処理システムの構成を示すブロック図である。 第３の実施形態における情報処理システムの動作を示すフローチャートである。 本発明の第４の実施形態に係る情報処理システムの構成を示すブロック図である。 第４の実施形態における情報処理システムの動作を示すフローチャートである。 第４の実施形態の第１の変形例の構成を示すブロック図である。 第４の実施形態の第２の変形例の構成を示すブロック図である。

本発明を実施するための形態について図面を参照して詳細に説明する。尚、各図面及び明細書記載の各実施形態において、同様の構成要素には同一の符号を付与し、説明を適宜省略する。また、図面中の矢印の方向は、一例を示すものであり、ブロック間の信号の向きを限定するものではない。

＜＜＜第１の実施形態＞＞＞
図１は、本発明の第１の実施形態に係る情報処理システム１０の構成を示すブロック図である。図１に示すように、本実施形態に係る情報処理システム１０は、マスタ（マスタデバイスとも呼ばれる）１１とスレーブ（スレーブデバイスとも呼ばれる）１２とを含む。マスタ１１とスレーブ１２とは、ＳＰＩバス８００を介して接続される。マスタ１１は、ＳＰＩクロック生成回路（基準クロック生成手段とも呼ばれる）１１１、リクエスト送信回路１１２及びリプライ受信回路１１３を含む。スレーブ１２は、リクエスト受信回路１１６及びリプライ送信回路１１７含む。尚、図１に示す例に係わらず、マスタ１１及びスレーブ１２は、ＳＰＩバス８００以外の同期式シリアルインタフェースを介して接続されてよい。

図１に示す各構成要素のそれぞれは、回路によって実現されてよい。その回路は、ハードウェア単位の回路でも、マイクロチップに含まれるモジュールであってもよい。例えば、その回路は、ＬＳＩやＰＧＡ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）であってもよく、そのＬＳＩやそのＰＧＡは、シングルチップで構成されても、マルチチップで構成されてもよい。

＝＝＝ＳＰＩクロック生成回路１１１＝＝＝
ＳＰＩクロック生成回路１１１は、ＳＰＩクロック（基準クロックとも呼ばれる）を生成し、リクエスト送信回路１１２とリプライ受信回路１１３とに、及びＳＰＩバス８００を介してリクエスト受信回路１１６とリプライ送信回路１１７とに、供給する。リクエスト送信回路１１２、リプライ受信回路１１３、リクエスト受信回路１１６及びリプライ送信回路１１７は、各動作をこのＳＰＩクロックに同期して実行する。

＝＝＝リクエスト送信回路１１２＝＝＝
リクエスト送信回路１１２は、マスタ１１の実行するリクエストトランザクションにおけるリクエストを、パラレルデータからシリアルデータに変換し、ＳＰＩバス８００を介してスレーブ１２へ発行する。

＝＝＝リプライ受信回路１１３＝＝＝
リプライ受信回路１１３は、スレーブ１２から送信されるシリアルデータを受信する。そして、リプライ受信回路１１３は、そのシリアルデータから、リプライ開始コードを検出し、リプライデータを受信する。次に、リプライ受信回路１１３は、受信したリプライデータをシリアルデータからパラレルデータに変換して出力する。尚、リプライ開始コードは、例えば、マスタ１１とスレーブ１２との間で初期設定動作により、予め決定される。具体的には、最初の通信開始時において、リプライ開始コードを利用しないで通信を行い、マスタ１１とスレーブ１２との双方がリプライ開始コードをサポートしている場合にリプライ開始コードを決定する。尚、情報処理システム１０内の全てのマスタ１１及びスレーブ１２がリプライ開始コードをサポートしている場合、任意のリプライ開始コードが事前に割り当てられていてもよい。

＝＝＝リクエスト受信回路１１６＝＝＝
リクエスト受信回路１１６は、マスタ１１から送信されるシリアルデータ及びＳＰＩクロックを受信する。そして、リクエスト受信回路１１６は、そのシリアルデータからリクエストを受信し、パラレルデータに変換する。次に、リクエスト受信回路１１６は、そのリクエストを処理し、リプライデータを生成する。

＝＝＝リプライ送信回路１１７＝＝＝
リプライ送信回路１１７は、リクエスト受信回路１１６によりリクエストの処理が実行されると、リプライ開始コードを発行し、そのリプライ開始コードをパラレルデータからシリアルデータに変換し、マスタに送信する。次に、リプライ送信回路１１７は、リクエスト受信回路１１６が生成したリプライデータを発行し、そのリプライデータをパラレルデータからシリアルデータに変換し、マスタに送信する。

次に、リプライ受信回路１１３について、より具体的な回路構成の一例を説明する。図２は、リプライ受信回路１１３の回路構成を示すブロック図である。

マスタ１１のＳＰＩクロック生成回路１１１は、リクエストトランザクションの処理期間中、ＳＰＩクロックを送信し続けている。従って、リプライ受信回路１１３は、リクエストトランザクション処理中は常に、スレーブ１２のリプライ送信回路１１７からのリプライ開始コード及びリプライデータを受信可能である。

リプライ受信回路１１３は、シリアル→パラレルデータ変換を行うシフトレジスタ３０１へ、ＳＰＩバス８００を介して受信するシリアルデータを格納する。シフトレジスタ３０１は、格納したシリアルデータをＳＰＩクロック毎に１ビットシフトすることでパラレルデータに変換する。

このとき、シフトレジスタ３０１は、リプライ開始コードのビット数分のパラレルデータを、常に、リプライ開始コード判定回路３１１の比較回路３０３に入力する。

比較回路３０３は、そのパラレルデータをリプライ開始コード定数３０２と比較する。比較回路３０３の比較結果（一致した場合「１」、一致しない場合「０」）、即ち比較回路３０３の出力は、セレクタ３０８の図２における最下段に入力される。

ここで、セレクタ３０８は、以下の優先順位で入力された値をリプライ開始フラグレジスタ３０４へ出力する。最高優先順位で出力される値は、最上段の図２における右側からの入力が「１」の場合の、最上段へ入力される値である。次に高い優先順位で出力される値は、最上段の図２における右側からの入力が「０」で、中段の図２における右側からの入力が「１」の場合の、中段へ入力される値である。最低優先順位で出力される値は、最上段の図２における右側からの入力が「０」で、中段の図２における右側からの入力が「０」の場合の、最下段へ入力される値である。

この比較回路３０３が一致を検出した場合、リプライ開始フラグレジスタ３０４は「１」を格納する。更に、この場合、リプライ開始フラグレジスタ３０４は、１を出力し、セレクタ３０８の中段の図２における右側からの入力が「１」となる。それによりリプライ開始フラグレジスタ３０４の出力、即ちセレクタ３０８の中段への入力がセルフホールドされ、それ以降、リプライ開始フラグレジスタ３０４は、比較回路３０３の出力を取り込まない。換言すると、この比較回路３０３が一致を検出した場合、リプライ開始コード判定回路３１１は、リプライ開始コードを検出する。

また、リクエスト送信完了時及びリプライデータ受信完了時（リプライデータバリッド検出時）、セレクタ３０８の最上段の図２における右側からの入力が「１」となり、セレクタ３０８は最上段へ入力される「０」を選択する。これによりリプライ開始フラグレジスタ３０４は、「０」を格納する。換言すると、リクエスト送信完了時及びリプライデータ受信完了時、リプライ開始コード判定回路３１１は、リプライ開始コードの検出をリセットする。

スレーブ１２は、リプライ開始コードに続けてリプライデータを転送する。そこで、マスタ１１は、受信するシリアルデータを連続してシフトレジスタ３０１に格納する。尚、シフトレジスタ３０１は、リプライデータのビット数分のビットを、少なくとも含む。

リプライ受信カウンタ３０５は、リプライ開始フラグ点灯（リプライ開始フラグレジスタ３０４の出力が「１」）している場合、カウント動作を実行する。具体的には、リプライ開始フラグレジスタ３０４の出力が「１」の期間中、ＳＰＩクロック毎に、アダー３１２によりリプライ受信カウンタレジスタ３０７の出力に「１」加算した値がセレクタ３０９の中段に入力される。そして、その中段に入力された値が、リプライ受信カウンタレジスタ３０７に格納される。リプライ開始フラグレジスタ３０４の出力が「０」の期間中は、セレクタ３０９の最下段に入力されているリプライ受信カウンタレジスタ３０７の値が、リプライ受信カウンタレジスタ３０７にそのまま格納される。

ここで、リプライ受信カウンタ３０５のセレクタ３０９の出力の優先順位は、優先順位を決定する入力が図２における左側からである点を除いて、リプライ開始コード判定回路３１１におけるセレクタ３０８と同様である。

リプライ受信回路１１３は、リプライデータを順次受信していく過程で、リプライ受信カウンタレジスタ３０７が出力する値と定数３１０とを比較回路３０６で比較する。ここで、定数３１０は、「リプライ有効ビット数−１」である。これにより、比較回路３０６は、リプライデータのビット数分を受信したところで一致を検出する。換言すると、比較回路３０６は、リプライデータ受信が完了を検出し、比較結果の信号としてリプライデータバリッドを示す「１」を出力する。

シフトレジスタ３０１に格納されたデータはパラレル化されたデータであるため、マスタ１１は、そのデータをそのままリプライデータとして使用することができる。

セレクタ３０９は、比較回路３０６がリプライデータバリッドを出力することにより、最上段の図２における左側からの入力が「１」となり、最上段へ入力される「０」を選択する。これによりリプライ受信カウンタレジスタ３０７は、「０」を格納する。換言すると、リプライ受信カウンタレジスタ３０７は、リプライデータバリット時、リプライデータのカウント値をリセットする。

次に本実施形態の動作について、図面を参照して詳細に説明する。

図３は、本実施形態の動作を示すフローチャートである。また、処理のステップ名については、Ｓ２０１のように、記号で記載する。

マスタ１１はリクエストを発行する（ステップＳ２０１）。

次に、リクエスト送信回路１１２は、ＳＰＩクロック生成回路１１１が生成するＳＰＩクロックに同期して、そのリクエストのデータをパラレルデータからシリアルデータへ変換し、そのシリアルデータをスレーブ１２に対して送信する（ステップＳ２０２）。尚、この時、ＳＰＩクロック生成回路１１１は、その生成したＳＰＩクロックを、そのリクエストのシリアルデータとともにスレーブ１２に対して送信する。尚、マスタ１１のＳＰＩクロック生成回路１１１は、リクエストの発行開始からリプライデータの受信完了までＳＰＩクロックを生成し続ける。

次に、スレーブ１２は、リクエストであるシリアルデータを受信する（ステップＳ２０３）。

次に、リクエスト受信回路１１６は、そのシリアルデータをパラレルデータへ変換し、リクエストを受信する（ステップＳ２０４）。

次に、リクエスト受信回路１１６は、リクエスト内容を解析し、リクエストに対応した処理を実行する（ステップＳ２０５）。この時、リクエスト受信回路１１６は、リクエストに対するリプライデータがある場合は、リプライデータを準備する。以下、リプライデータが準備される場合について説明する。
次に、スレーブ１２のリプライ送信回路１１７は、リプライ開始コードを発行する（ステップＳ２０６）。即ち、マスタ１１からはＳＰＩクロックが出し続けられているので、スレーブ１２は、任意の時点でリプライを開始できる。そこで、リプライ送信回路１１７は、リプライ開始の際に予め定められたリプライ開始コードを発行する。
次に、リプライ送信回路１１７は、そのリプライ開始コードをパラレルデータからシリアルデータへ変換し、そのシリアルデータをマスタ１１へ送信する（ステップＳ２０７）。

連続して、リプライ送信回路１１７は、リプライデータを発行する（ステップＳ２０８）。

更に連続して、リプライ送信回路１１７は、そのリプライデータをパラレルデータからシリアルデータへ変換し、マスタ１１へ送信する（ステップＳ２０９）。

一方、マスタ１１のリプライ受信回路１１３は、ステップＳ２０７で送信されたシリアルデータを受信し、シリアルデータからパラレルデータへ変換する（ステップＳ２１０）。

次に、リプライ受信回路１１３は、変換したそのパラレルデータがリプライ開始コードか否かを判定する（ステップＳ２１１）。否の場合（ステップＳ２１１でＮＯ）、処理は、ステップＳ２１０へ戻る。

リプライ開始コードである場合（ステップＳ２１１でＹＥＳ）、リプライ受信回路１１３は、ステップＳ２０７で送信されたシリアルデータを受信し、シリアルデータからパラレルデータへ変換する（ステップＳ２１２）。

次に、リプライ受信回路１１３は、リプライデータのビット数分の、変換したそのパラレルデータをリプライデータとして受信する（ステップＳ２１３）。

尚、スレーブ１２のリプライ送信回路１１７は、リクエスト受信からリプライ開始コードの送信を開始するまで、リプライ開始コード以外の所定の値（例えば、連続する「０」）を、シリアルデータとしてＳＰＩクロックに同期して、送信する。

次に、本実施形態と関連技術値との差異を明確にするために、関連技術におけるマスタとスレーブとの動作を説明する。

図４は、関連技術におけるマスタ（以後、マスタＭと呼ぶ）とスレーブ（以後、スレーブＳと呼ぶ）との動作を示すフローチャートである。

マスタＭはリクエストを発行する（ステップＳ１０１）。

次に、マスタＭは、リクエストをパラレルデータからシリアルデータへ変換し、ＳＰＩクロックとともにそのシリアルデータをスレーブＳに対して送信する（ステップＳ１０２）。

次に、マスタＭは，ＳＰＩクロックを停止する（ステップＳ１０３）。

次に、マスタＭは、最長処理時間を待つ（ステップＳ１０４）。

一方、スレーブＳは、ステップＳ１０２で送信されたシリアルデータを受信し、シリアルデータからパラレルデータへ変換する（ステップＳ１０５）。

次に、スレーブＳは、その変換したパラレルデータをリクエストとして受信する（ステップＳ１０６）。

次に、スレーブＳは、リクエスト内容を解析し、リクエストに対応した処理を行う（ステップＳ１０７）。

次に、スレーブＳは、リクエストに対するリプライデータがある場合、そのリプライデータを発行する（ステップＳ１０８）。

次に、マスタＭは、最長処理時間を待った後、スレーブＳがステップＳ１０８においてリプライデータの発行が完了したタイミングでＳＰＩクロックの生成を再開する（ステップＳ１０９）。

次に、スレーブＳは、ステップＳ１０９で再開されたＳＰＩクロックを受信すると、リプライデータをパラレルデータからシリアルデータへ変換し、マスタＭへ送信する（ステップＳ１１０）。

次に、マスタＭは、スレーブＳから送信されたシリアルデータを受信し、そのシリアルデータをパラレルデータへ変換する（ステップＳ１１１）
次に、マスタＭは、変換したそのパラレルデータをリプライデータとして受信する（ステップＳ１１２）。

こうして、トランザクション処理は完了する。

上述の説明から明らかなように、関連技術においては、マスタＭがリクエストを発行後にリプライデータの受信を開始するまでに、必ず最長処理時間が経過する。一方、本実施形態の情報処理システム１０においては、マスタ１１がリクエストを発行後にスレーブ１２においてリプライデータが準備でき次第、マスタ１１はリプライデータの受信を開始することができる。

上述した本実施形態における効果は、同期式のシリアル通信において、リクエストに対するリプライ待ち時間を短縮することが可能になる点である。換言すると、スレーブ１２の処理時間の長短によらず最適な通信時間でトランザクションを処理することが可能になる点である。このため、通信処理時間が短縮され、ひいてはソフトウェア処理性能を大幅に向上させることができる。

その理由は、以下のような構成を含むからである。即ち、第１にマスタ１１のＳＰＩクロック生成回路１１１がＳＰＩクロックを生成し、スレーブ１２へ送信する。第２にマスタ１１のリクエスト送信回路１１２がリクエストをスレーブ１２へ送信する、第３にマスタ１１のリプライ受信回路１１３が、リプライ開始コードを受信した場合に、そのリプライ開始コードに続けて受信するデータをリプライデータとして受信する。第４にスレーブ１２のリクエスト受信回路１１６がそのリクエストを受信し、リプライデータを発行する。第５に、スレーブ１２のリプライ送信回路１１７が、そのＳＰＩクロックに対して、リプライデータが準備できていない場合、リプライ開始コード以外の信号を送信する。第６にリプライ送信回路１１７が、そのＳＰＩクロックに対して、リプライデータが準備できている場合、リプライ開始コード及びそのリプライ開始コードに連続するリプライデータを送信する。

＜＜＜第２の実施形態＞＞＞
次に、本発明の第２の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

図５は、本発明の第２の実施形態に係る情報処理システム２０の構成を示すブロック図である。

図５に示すように、本実施形態における情報処理システム２０は、第１の実施形態の情報処理システム１０と比べて、マスタ１１に替えて、リプライタイムアウト検出回路１２４を更に含む、マスタ２１を含む点が異なる。

図４に示すフローチャートで説明した関連技術のマスタＭとスレーブＳとの関係では、マスタＭが能動的に適切なタイミングで、スレーブＳにＳＰＩクロックを送信することでリクエストの送出、リプライデータの受信を実行する。もし何らかの事象でスレーブＳがリプライ開始タイミングまでにリプライデータを用意できなかった場合、マスタＭは、ＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）やパリティチェックなどのＲＡＳ（Ｒｅｌｉａｂｉｌｉｔｙ Ａｖａｉｌａｂｉｌｉｔｙ ａｎｄ Ｓｅｒｖｉｃｅａｂｉｌｉｔｙ）機能によりエラーを検出する。こうして、マスタＭは、リクエストが失敗したと判断することができる。

一方、図３に示すフローチャートで説明した第１の実施形態のマスタ１１とスレーブ１２との関係では、リプライデータを能動的に送出するのはスレーブ１２でありマスタ１１は受動的な立場となる。このため、何らかの事象によりスレーブ１２がリプライデータを用意できない状態となった場合、マスタ１１は永遠にリプライ開始コードを待ち続ける状態になる。このような状態に陥ることを避けるため、本実施形態ではマスタ２１がリプライタイムアウト検出回路１２４を含む。

リプライタイムアウト検出回路１２４は、リクエストの送信が完了した時点から所定時間以内に、リプライ開始コードを受信しなかった場合、リプライタイムアウトを検出し、そのリプライタイムアウトを検出したことを出力する。ここで、その所定時間は、予め定められたリプライタイムアウト設定時間である。

図６は、リプライタイムアウト検出回路１２４の回路構成の一例を示す図である。

まず、セレクタ４０４の出力の優先順位は、図２に示すリプライ受信カウンタ３０５のセレクタ３０９と同様である。

リクエスト送信完了時、セレクタ４０４の最上段の図６における左側からの入力が「１」となり、セレクタ４０４は最上段へ入力される「０」を選択する。これによりリプライタイムアウト検出カウンタレジスタ４０５は、「０」を格納する。換言すると、リクエスト送信完了時、リプライタイムアウト検出回路１２４は、リプライタイムアウト検出カウンタ４０１をリセットする。

アダー４０６は、ＳＰＩクロック毎に、リプライタイムアウト検出カウンタレジスタ４０５の出力に「１」加算した値をセレクタ４０４の最下段に入力する。換言すると、リプライタイムアウト検出回路１２４は、リクエスト送信完了時にリプライタイムアウト検出カウンタレジスタ４０５をリセットした後、アダー４０６によりリプライタイムアウト検出カウンタ４０１をカウントアップする。

リプライ開始フラグ点灯時、セレクタ４０４の中段の図６における左側からの入力が「１」となる。それにより、リプライタイムアウト検出カウンタレジスタ４０５の出力、即ちセレクタ４０４の中段への入力がセルフホールドされ、それ以降、リプライタイムアウト検出カウンタレジスタ４０５は、アダー４０６の出力を取り込まない。換言すると、リプライタイムアウト検出回路１２４は、リプライ開始フラグ点灯により、リプライタイムアウト検出カウンタ４０１のカウントアップを停止する。

一方、リプライ開始フラグが点灯しない場合、アダー４０６によるカウントアップは継続される。その結果、リプライタイムアウト検出カウンタレジスタ４０５の出力と、予め設定したリプライタイムアウト設定時間４０２値とが一致し、比較回路４０３は、リプライタイムアウトを検出する。

マスタ２１は、そのリプライタイムアウトに基づいて、スレーブ１２が何らかの事象でリプライデータを用意できなかったと判断し、障害処理へ移行する。

上述した本実施形態における効果は、第１の実施形態の効果に加えて、マスタ２１が永遠にリプライ開始コードを待ち続ける状態になることを、防止することが可能になる点である。

その理由は、リプライタイムアウト検出回路１２４が、リクエスト送信完了時点からリプライタイムアウト設定時間４０２以内にリプライ開始フラグレジスタ３０４が点灯しなかった場合に、リプライタイムアウトを検出するからである。

＜＜＜第３の実施形態＞＞＞
次に、本発明の第３の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

図７は、本発明の第２の実施形態に係る情報処理システム３０の構成を示すブロック図である。

図７に示すように、本実施形態における情報処理システム３０は、第１の実施形態の情報処理システム１０と比べて、ＳＰＩクロック生成回路１１１を含むマスタ１１に替えて、ＳＰＩクロック生成回路１３１を含むマスタ３１を含む点が異なる。

ＳＰＩクロック生成回路１３１は、リクエスト送信回路１１２からリクエストの送信が完了したことを通知された場合、ＳＰＩクロックの生成を停止する。ＳＰＩクロック生成回路１３１は、リクエストの送信が完了したことを通知されたことによりＳＰＩクロックの生成を停止した後、特定の時間の経過後に、ＳＰＩクロックの生成を再開する。

また、ＳＰＩクロック生成回路１３１は、ＳＰＩクロックの生成を再開した後、リプライ受信回路１１３からリプライ開始コードを未受信であることを通知された場合、ＳＰＩクロックの生成を停止する。ＳＰＩクロック生成回路１３１は、リプライ開始コードを未受信であることを通知されたことによりＳＰＩクロックの生成を停止した後、特定の時間の経過後に、ＳＰＩクロックの生成を再開する。

尚、その特定の時間は、予め定められた、任意の適切な固定時間であってよい。また、その特定の時間は、ＳＰＩクロックの生成停止の回数のそれぞれに対応する、任意の適切な時間（例えば、その回数の増加に従って、相対的に短くなる時間）であってよい。

図１に示すマスタ１１のＳＰＩクロック生成回路１１１は、ＳＰＩクロックをリクエスト送出開始時からリプライデータの受信完了時まで、ＳＰＩクロックを生成し出力する。

本実施形態のマスタ３１のＳＰＩクロック生成回路１３１は、以下に示すように動作することで、電力消費を削減する。

図８は、本実施形態における情報処理システム３０の動作を示すフローチャートである。以下では、図３に示す情報処理システム１０の動作を示すフローチャートとの差分について説明する。

ＳＰＩクロック生成回路１３１は、ステップＳ２０２のシリアルデータ送信（リクエストの送信）後、ＳＰＩクロックの生成を停止する（ステップＳ３０１）。

次に、ＳＰＩクロック生成回路１３１は、特定の時間を待つ（ステップＳ３０２）。

次に、ＳＰＩクロック生成回路１３１は、ＳＰＩクロックの生成を再開する（ステップＳ３０３）。

また、ステップＳ２１１において、否の場合（ステップＳ２１１でＮＯ）、処理は、ステップＳ３０１へ戻る。

上述の動作以外の、ステップＳ２０１乃至ステップＳ２１３の動作は、図３に示す情報処理システム１０の動作と同様である。

図８に示す動作における、マスタ３１とスレーブ１２との関係を説明する。

マスタ３１がステップＳ３０１においてＳＰＩクロックを停止することにより、スレーブ１２は、シリアルデータの送信ができなくなる。

次に、マスタ３１におけるステップＳ３０２の特定の時間待ちの後、マスタ３１がステップＳ３０３においてＳＰＩクロックを再開することにより、スレーブ１２はシリアルデータを送信可能となる。

シリアルデータを送信することが可能になった場合に、スレーブ１２は、リクエスト処理中につきリプライデータをまだ用意できていないとき、リプライ開始コードではないシリアルデータを送信する。例えば、前述したように、スレーブ１２はリクエスト受信完了の直後からリプライ開始コード返却開始の直前まで、リプライ開始コード以外の所定の値（例えば、連続する「０」）を送信する。

シリアルデータを送信することが可能になった場合に、スレーブ１２は、リプライデータが用意できたとき、リプライ開始コードをシリアルデータとして送信する。

ステップＳ２１１において、リプライ開始コードではないときには、マスタ３１の処理は、ステップＳ３０１へ戻り、ＳＰＩクロックを停止する。

ステップＳ２１１において、リプライ開始コードであったときには、リプライ開始コード判定回路３１１は、ＳＰＩクロックの生成を継続し、スレーブ１２よりリプライデータを受信する。

上述した本実施形態における効果は、ＳＰＩクロックの無駄な生成及びその出力を削減することができ、電力消費量を削減することが可能になる点である。

その理由は、ＳＰＩクロック生成回路１３１が、リクエストの送信が完了した後、リプライ開始コードの受信が開始されるまでの期間、ＳＰＩクロックの生成を間欠的に（特定の時間）停止するからである。

＜＜＜第４の実施形態＞＞＞
次に、本発明の第４の実施形態について図面を参照して詳細に説明する。以下、本実施形態の説明が不明確にならない範囲で、前述の説明と重複する内容については説明を省略する。

本実施形態は、最小の構成要素を示す実施形態である。図９は、本発明の第４の実施形態に係る情報処理システム４０の構成を示すブロック図である。

図９に示すように、本実施形態における情報処理システム４０は、リプライ受信回路１４３を含むマスタ４１と、リプライ送信回路１４７を含むスレーブ４２とを含む。

マスタ４１のリプライ受信回路１４３は、スレーブ４２からリプライ送信開始を通知するリプライ開始コードを受信した場合に、そのリプライ開始コードに続けて受信するデータをリプライデータとして受信する。

スレーブ４２のリプライ送信回路１４７は、マスタ４１から基準クロック（例えば、ＳＰＩクロック）を受信し、受信したその基準クロックに対して、以下のいずれかを送信する。その第１は、マスタ４１から受信したリクエストに対するリプライ準備中であることを示す信号である。その第２は、そのリプライ開始コード及びそのリプライ開始コードに連続するそのリプライデータである。

次に、本実施形態の動作について、図面を参照して詳細に説明する。

図１０は、本実施形態の情報処理システム４０の動作を示すフローチャートである。

スレーブ４２は、マスタ４１からリクエストを受信したことを契機に、図１０に示すフローチャートの動作を開始する。

リプライ送信回路１４７は、基準クロックを待つ（ステップＳ６０１）。基準クロックを受信しない場合（ステップＳ６０１でＮＯ）、処理は、ステップＳ６０１に戻る。

基準クロックを受信した場合（ステップＳ６０１でＹＥＳ）、リプライ送信回路１４７は、リプライの準備が完了しているか否かを判定する（ステップＳ６０２）。

その準備が完了していない場合（ステップＳ６０２でＮＯ）、リプライ送信回路１４７は、リプライ準備中信号を送信する（ステップＳ６０３）。次に、処理は、ステップＳ６０１へ戻る。ここで、リプライ準備中信号は、前述したように、リクエスト受信からリプライ開始コードの送信を開始するまで、リプライ開始コード以外の所定の値（例えば、連続する「０」）がシリアルデータとして基準クロックに同期して、送信される信号である。

その準備が完了している場合（ステップＳ６０２でＹＥＳ）、リプライ送信回路１４７は、リプライ開始コードを発行する（ステップＳ６０４）。

次に、リプライ送信回路１４７は、基準クロックに同期して、リプライ開始コードをパラレルデータからシリアルデータへ変換し、そのシリアルデータを送信する（ステップＳ６０５）。

連続して、リプライ送信回路１４７は、リプライデータを発行する（ステップＳ６０６）。

更に連続して、リプライ送信回路１４７は、基準クロックに同期して、リプライデータをパラレルデータからシリアルデータへ変換し、そのシリアルデータを送信する（ステップＳ６０７）。

一方、マスタ４１のリプライ受信回路１４３は、ステップＳ６０３またはステップＳ６０５で送信されたシリアルデータを受信する（ステップＳ６１１）。

次に、リプライ受信回路１４３は、ステップＳ６１１で受信したシリアルデータがリプライ開始コードであるか否かを判定する（ステップＳ６１２）。リプライ開始コードでない場合（ステップＳ６１２でＮＯ）、処理はステップＳ６１１へ戻る。

リプライ開始コードである場合（ステップＳ６１２）、リプライ受信回路１４３は、ステップＳ６０７で送信されたシリアルデータを受信する（ステップＳ６１３）。

次にリプライ受信回路１４３は、そのシリアルデータをパラレルデータに変換し、リプライデータとして受信する（ステップＳ６１４）。

上述した本実施形態における効果は、同期式のシリアル通信において、リクエストに対するリプライ待ち時間を短縮することが可能になる点である。

その理由は、以下のような構成を含むからである。

即ち、第１にリプライ受信回路１４３が、スレーブ４２からリプライ開始コードを受信した場合に、そのリプライ開始コードに続けて受信するデータをリプライデータとして受信する。換言すると、マスタ４１のリプライ受信回路１４３は、そのリプライ開始コードを受信した場合に、必要以上の待ちを行うことなく、直ちにそのリプライデータを受信する。

第２に、リプライ送信回路１４７が、マスタ４１から基準クロックを受信し、受信したその基準クロックに対して、以下のいずれかを送信する。その第１は、マスタ４１から受信したリクエストに対するリプライ準備中であることを示す信号である。その第２は、そのリプライ開始コード及びそのリプライ開始コードに連続するそのリプライデータである。換言すると、スレーブ４２のリプライ送信回路１４７は、その基準クロックに同期し、マスタ４１に対して、リプライ準備中であることを示すか、リプライ開始コード及びリプライデータを送信するかのいずれかを実行する。

＜＜＜第４の実施形態の第１の変形例＞＞＞
図１１は、第４の実施形態の第１の変形例の構成を示すブロック図である。図１１に示すように、本変形例は、リプライ受信回路１４３を含むマスタ４１を含む。第４の実施形態において説明したように、本変形例のマスタ４１は、図９に示すスレーブ４２と接続され、第４の実施形態と同様の効果を得ることができる。

＜＜＜第４の実施形態の第２の変形例＞＞＞
図１２は、第４の実施形態の第２の変形例の構成を示すブロック図である。図１２に示すように、本変形例は、リプライ送信回路１４７を含むスレーブ４２を含む。第４の実施形態において説明したように、本変形例のスレーブ４２は、図９に示すマスタ４１と接続され、第４の実施形態と同様の効果を得ることができる。

以上の各実施形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はない。例えば、複数個の任意のその構成要素が１個のモジュールとして実現されてよい。また、その構成要素の内の任意のひとつが複数のモジュールで実現されてもよい。また、その構成要素の内の任意のひとつがその構成要素の内の任意の他のひとつであってよい。また、その構成要素の内の任意のひとつの一部と、その構成要素の内の任意の他のひとつの一部とが重複してもよい。

また、以上説明した各実施形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の順番は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で、変更することができる。

更に、以上説明した各実施形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。例えば、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で、ある動作の実行中に他の動作が発生してよい。また、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で、ある動作と他の動作との実行タイミングが部分的に乃至全部において重複してもよい。

更に、以上説明した各実施形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作との関係を限定するものではない。このため、各実施形態を実施するときには、その複数の動作の関係は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で、変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、各実施形態を実施する上で機能的、性能的、その他の特性に対して支障を来さない範囲内で変更されてよい。

以上、各実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本発明の構成や詳細には、本発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

１０ 情報処理システム
１１ マスタ
１２ スレーブ
２０ 情報処理システム
２１ マスタ
３０ 情報処理システム
３１ マスタ
４０ 情報処理システム
４１ マスタ
４２ スレーブ
１１１ ＳＰＩクロック生成回路
１１２ リクエスト送信回路
１１３ リプライ受信回路
１１６ リクエスト受信回路
１１７ リプライ送信回路
１２４ リプライタイムアウト検出回路
１３１ ＳＰＩクロック生成回路
１４３ リプライ受信回路
１４７ リプライ送信回路
３０１ シフトレジスタ
３０２ リプライ開始コード定数
３０３ 比較回路
３０４ リプライ開始フラグレジスタ
３０５ リプライ受信カウンタ
３０６ 比較回路
３０７ リプライ受信カウンタレジスタ
３０８ セレクタ
３０９ セレクタ
３１０ 定数
３１１ リプライ開始コード判定回路
３１２ アダー
４０１ リプライタイムアウト検出カウンタ
４０２ リプライタイムアウト設定時間
４０３ 比較回路
４０４ セレクタ
４０５ リプライタイムアウト検出カウンタレジスタ
４０６ アダー
８００ ＳＰＩバス

Claims (10)

1. リプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するリプライ受信手段を含むマスタデバイスと、
   前記マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信するリプライ送信手段を含むスレーブデバイスと、を含む
   情報処理システム。
2. 前記マスタデバイスは、
   前記リクエストの送信が完了したことを通知された場合、前記基準クロックの生成を停止し、
   前記リクエストの送信が完了したことを通知されたことにより、前記基準クロックの生成を停止した後、特定の時間の経過後に、前記基準クロックの生成を再開し、
   前記基準クロックの生成を再開した後、前記リプライ受信手段から前記リプライ開始コードを未受信であることを通知された場合、前記基準クロックの生成を停止し、
   前記リプライ開始コードを未受信であることを通知されたことにより、前記基準クロックの生成を停止した後、特定の時間の経過後に、前記基準クロックの生成を再開する、
   基準クロック生成手段を更に含む
   請求項１記載の情報処理システム。
3. 前記基準クロック生成手段は、前記基準クロックの生成停止の回数のそれぞれに対応する、前記特定の時間の経過後に、前記基準クロックの生成を再開する
   請求項２記載の情報処理システム。
4. 前記マスタデバイスは、前記リクエストの送信が完了した時点から所定時間以内に前記リプライ開始コードを受信しなかった場合に、リプライタイムアウトを検出し、前記リプライタイムアウトを検出したことを出力するリプライタイムアウト検出手段を含む
   請求項１乃至３のいずれか１項に記載の情報処理システム。
5. 前記マスタデバイスと前記スレーブデバイスとのインタフェースは、前記マスタデバイスから前記スレーブデバイスへ前記基準クロックを送信するクロック信号線、前記マスタデバイスから前記スレーブデバイスへ前記リクエストを送信する第１のシリアルデータ信号線、及び前記スレーブデバイスから前記マスタデバイスへ前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータを送信する第２のシリアルデータ信号線を、少なくとも含む
   請求項１乃至４のいずれか１項に記載の情報処理システム。
   
6. スレーブデバイスからリプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するリプライ受信手段を含み、
   前記スレーブデバイスは、マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信するリプライ送信手段を含むスレーブデバイスである、
   マスタデバイス。
7. 前記マスタデバイスは、
   前記リクエストの送信が完了したことを通知された場合、前記基準クロックの生成を停止し、
   前記基準クロックの生成を再開した後、前記リプライ受信手段から前記リプライ開始コードを未受信であることを通知された場合、前記基準クロックの生成を停止し、
   前記基準クロックの生成を停止した後、特定の時間の経過後に、前記基準クロックの生成を再開する
   基準クロック生成手段を更に含む
   請求項６記載のマスタデバイス。
8. マスタデバイスから基準クロックを受信し、受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、リプライ送信開始を通知するリプライ開始コード及び前記リプライ開始コードに連続するリプライデータと、のいずれかを送信するリプライ送信手段とを含み、
   前記マスタデバイスは、前記リプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信するマスタデバイスである、
   スレーブデバイス。
9. 前記マスタデバイスは、前記リクエストの送信が完了した場合、前記基準クロックの生成を停止し、前記基準クロックの生成を再開した後、前記リプライ開始コードを未受信であることを検出し場合、前記基準クロックの生成を停止し、前記基準クロックの生成を停止した後、特定の時間の経過後に、前記基準クロックの生成を再開する
   基準クロック生成手段を更に含む前記マスタデバイスである
   請求項８記載のスレーブデバイス。
10. マスタデバイスが、
    リプライ送信開始を通知するリプライ開始コードを受信した場合に、前記リプライ開始コードに続けて受信するデータをリプライデータとして受信し、
    スレーブデバイスが、
    前記マスタデバイスから基準クロックを受信し、
    受信した前記基準クロックに対して、前記マスタデバイスから受信したリクエストに対するリプライ準備中であることを示す信号と、前記リプライ開始コード及び前記リプライ開始コードに連続する前記リプライデータと、のいずれかを送信する、
    インタフェース制御方法。

Images