(57)【特許請求の範囲】
【請求項１】
データと、当該データについてバイト単位で有効であるか否かを示す有効情報と、を含む信号を受信する受信手段と、
前記受信手段により受信したデータのうちの対応する第１のビット数分のデータが有効であるか否かを示す部分有効情報と、当該部分有効情報が有ることを示す識別子と、前記第１のビット数分のデータと、を対応付けて送信する送信手段と、を備えるデータ転送装置であって、
前記送信手段は前記データのうち、前記第１のビット数分のデータが有効である際には、当該第１のビット数分のデータに対応する部分有効情報の送信を省略することを特徴とするデータ転送装置。
【請求項２】
パケットを受信するパケット受信手段と、
前記パケットに含まれている第１の有効情報に基づいて第２の有効情報を生成する生成手段と、
前記生成手段で生成した第２の有効情報と前記パケットに含まれるデータとを送信する送信手段と、を備えるデータ転送装置であって、
前記生成手段は、前記受信手段の受信したパケットに含まれている識別子が対応する前記パケットに含まれている第１のビット数分のデータが有効であることを示す第１の有効情報が無い事を示していると、当該識別子に対応する第１のビット数分のデータが有効であることを示す第２の有効情報を生成することを特徴とするデータ転送装置。
【請求項３】
前記生成手段は、前記受信手段の受信したパケットに含まれている識別子が前記パケットに含まれている第１のビット数分のデータに対応する第１の有効情報が有る事を示していると、当該有効情報に基づいて第２の有効情報を生成することを特徴とする請求項２に記載のデータ転送装置。
【請求項４】
所定長の複数のキャラクタを有するパケットを用いてデータ転送を行うデータ転送装置であって、
データと、当該データについてバイト単位で有効であるか否かを示す有効情報と、を含む信号をバスから受信する受信手段と、
前記バスから取得した有効情報のうちの対応する第１のビット数分のデータが有効であるか否かを示す部分有効情報と、当該部分有効情報が有ることを示す識別子とを含むイネーブルキャラクタと、前記受信手段の受信したデータのうちの第１のビット数分のデータを含むデータキャラクタ、とを生成する生成手段と、
前記生成手段の生成したイネーブルキャラクタとデータキャラクタとをセットとして含むパケットを送信する送信手段と、を備え、
前記生成手段は前記バスから受信した有効情報が所定のパターンであると前記イネーブルキャラクタの生成を省略することを特徴とするデータ転送装置。
【請求項５】
データを受信する受信手段と、
前記データについて第１のビット数のデータが有効であるか否かを示す有効情報を生成する生成手段と、
前記生成手段で生成した有効情報と前記有効情報の有無を示す識別子と前記データとを送信する送信手段と、を備えるデータ転送装置であって、
前記生成手段は、前記データのうち第１のビット数分のデータが有効である際に、当該第１のビット数分のデータに対応する前記有効情報の生成を省略することを特徴とするデータ転送装置。
【請求項６】
前記生成手段は前記有効情報の有無を示す識別子を第２のビット数毎に生成することを特徴とする請求項４乃至５のいずれか１項に記載のデータ転送装置。
【請求項７】
所定長の複数のキャラクタを有するパケットを受信する受信手段と、
受信したパケットに含まれる複数のキャラクタそれぞれがデータキャラクタであるか、イネーブルキャラクタであるかを判別する判別手段と、
前記判別手段の判別したキャラクタがイネーブルキャラクタである場合、当該イネーブルキャラクタに対応するデータキャラクタが有効であるか否かを示す有効情報を抽出し、前記判別手段の判別したキャラクタがデータキャラクタであり且つ所定数連続している場合、当該所定数連続しているデータキャラクタに含まれるデータは有効であることを示す有効情報を生成する変換手段と、
前記変換手段による有効情報と前記パケットに含まれるデータとをバスに送信する送信手段とを有することを特徴とするデータ転送装置。
【請求項８】
前記送信手段は、前記判別手段がイネーブルキャラクタであると判別すると、当該イネーブルキャラクタに含まれる部分有効情報と、当該イネーブルキャラクタに後続して前記受信手段の受信する第１のビット数分のデータキャラクタとを関連付ける請求項７に記載のデータ転送装置。
【請求項９】
データと、当該データについて第２のビット数毎に有効であるか否かを示す有効情報と、を受信する受信手段と、
前記受信手段の受信したデータを、前記第２のビット数より大きい第１のビット数毎に送信する送信手段と、を備えるデータ転送装置であって、
前記送信手段は、当該送信手段が送信しようとする第１のビット数分のデータに無効なデータが含まれるたびに、対応する第１のビット数分のデータが有効であるか否かを示す有効情報と、当該有効情報が有ることを示す識別子と、を前記第１のビット数分のデータに対応づけて送信することを特徴とするデータ転送装置。
【請求項１０】
データと、当該データについてバイト単位で有効であるか否かを示す有効情報と、を含む信号を受信する受信工程と、
前記受信手段により受信したデータのうちの対応する第１のビット数分のデータが有効であるか否かを示す部分有効情報と、当該部分有効情報が有ることを示す識別子と、前記第１のビット数分のデータと、を対応付けて送信する送信工程と、を有するデータ転送方法であって、
前記送信工程において前記データのうち、前記第１のビット数分のデータが有効である際には、当該第１のビット数分のデータに対応する部分有効情報の送信を省略することを特徴とするデータ転送方法。
【請求項１１】
パケットを受信するパケット受信工程と、
前記パケットに含まれている第１の有効情報に基づいて第２の有効情報を生成する生成工程と、
前記生成工程で生成した第２の有効情報と前記パケットに含まれるデータとを送信する送信工程と、を有するデータ転送方法であって、
前記生成工程において、前記受信工程で受信したパケットに含まれている識別子が対応する前記パケットに含まれている第１のビット数分のデータが有効であることを示す第１の有効情報が無い事を示していると、当該識別子に対応する第１のビット数分のデータが有効であることを示す第２の有効情報を生成することを特徴とするデータ転送方法。
【請求項１２】
所定長の複数のキャラクタを有するパケットを用いてデータ転送を行うデータ転送方法であって、
データと、当該データについてバイト単位で有効であるか否かを示す有効情報と、を含む信号をバスから受信する受信工程と、
前記バスから取得した有効情報のうちの対応する第１のビット数分のデータが有効であるか否かを示す部分有効情報と、当該部分有効情報が有ることを示す識別子とを含むイネーブルキャラクタと、前記受信工程で受信したデータのうちの第１のビット数分のデータを含むデータキャラクタ、とを生成する生成工程と、
前記生成工程で生成したイネーブルキャラクタとデータキャラクタとをセットとして含むパケットを送信する送信工程と、を有し、
前記生成工程において前記バスから受信した有効情報が所定のパターンであると前記イネーブルキャラクタの生成を省略することを特徴とするデータ転送方法。
【請求項１３】
データを受信する受信工程と、
前記データについて第１のビット数のデータが有効であるか否かを示す有効情報を生成する生成工程と、
前記生成工程で生成した有効情報と前記有効情報の有無を示す識別子と前記データとを送信する送信工程と、を有するデータ転送方法であって、
前記生成工程は、前記データのうち第１のビット数分のデータが有効である際に、当該第１のビット数分のデータに対応する前記有効情報の生成を省略することを特徴とするデータ転送方法。
【請求項１４】
所定長の複数のキャラクタを有するパケットを受信する受信工程と、
受信したパケットに含まれる複数のキャラクタそれぞれがデータキャラクタであるか、イネーブルキャラクタであるかを判別する判別工程と、
前記判別工程の判別したキャラクタがイネーブルキャラクタである場合、当該イネーブルキャラクタに対応するデータキャラクタが有効であるか否かを示す有効情報を抽出し、前記判別手段の判別したキャラクタがデータキャラクタであり且つ所定数連続している場合、当該所定数連続しているデータキャラクタに含まれるデータは有効であることを示す有効情報を生成する変換工程と、
前記変換工程による有効情報と前記パケットに含まれるデータとをバスに送信する送信工程とを有することを特徴とするデータ転送方法。
【請求項１５】
データと、当該データについて第２のビット数毎に有効であるか否かを示す有効情報と、を受信する受信工程と、
前記受信工程の受信したデータを、前記第２のビット数より大きい第１のビット数毎に送信する送信工程と、を有するデータ転送方法であって、
前記送信工程は、当該送信手段が送信しようとする第１のビット数分のデータに無効なデータが含まれるたびに、対応する第１のビット数分のデータが有効であるか否かを示す有効情報と、当該有効情報が有ることを示す識別子と、を前記第１のビット数分のデータに対応づけて送信することを特徴とするデータ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケットを使用してデータ転送を行うデータ転送装置及びデータ転送方法に関する。
【背景技術】
【０００２】
パケットを使用してデータ転送を行う技術が様々な分野に適用されている。ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）はインターネット上のデータ転送をパケットベースで行う技術である。また、ＰＣＩ−Ｅｘｐｒｅｓｓ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ−Ｅｘｐｒｅｓｓ）は集積回路間のデータ転送をパケットベースで行う技術である。また、ＮｏＣ（Ｎｅｔｗｏｒｋ  Ｏｎ  Ｃｈｉｐ）は集積回路内のデータ転送をパケットベースで行う技術である。
パケットベースでデータ転送を行うメリットは、アドレスやデータ等の転送に必要な様々な情報を少ない信号線で転送できることにある。例えば、ＰＣＩ−Ｅｘｐｒｅｓｓでは、２対の差動線路のみで、データ転送を行うことができる。また、転送レートを上げやすいというメリットがある。しかし、パケットベースの転送方式にあっては、様々な情報を時間軸上に展開して送信するため、非パケットベースの転送方式に比べて転送に要するサイクル数が多いという問題点がある。そのため、パケット構造を工夫し、転送する情報量を削減することで、転送に要するサイクル数を減らし、転送効率を上げる技術が提案されている。
転送する情報を減らす工夫として、非特許文献１に開示されているＰＣＩ−Ｅｘｐｒｅｓｓでは、メモリリクエスト時のデータペイロード中の最終の４バイトデータ、及び、先頭の４バイトデータ以外は全て有効データとして取り扱うプロトコルにし、パケット構成の中でデータペイロード中の最終の４バイトデータ、及び、先頭の４バイトデータに対応したバイトイネーブル識別情報（Ｌａｓｔ  ＤＷ  ＢＥ、１ｓｔ  ＤＷ  ＢＥ）以外を割愛することで、パケット上の情報を減らす工夫をしている。
また、特許文献１では、シリアルバス上に転送すべきデータについてバイト単位で付加されているバイトイネーブルに基づいて有効なデータのみを転送することで、無効データの転送を抑制し、転送効率の向上を図っている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−１０２３４１号公報
【非特許文献】
【０００４】
【非特許文献１】“ＰＣＩ  Ｅｘｐｒｅｓｓ  Ｂａｓｅ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ  Ｒｅｖｉｓｉｏｎ  １．１”ＰＣＩ−ＳＩＧ，Ｍａｒｃｈ，２００５．
【発明の概要】
【発明が解決しようとする課題】
【０００５】
一方で、集積回路内のデータ転送には、非パケットベースのパラレルバスが主流である。集積回路内のパラレルバスのプロトコルは、一転送単位中（例えば、６４バイト＝６４ビットバス幅  ×  ８バースト転送）のどのデータが有効であるか否かを示すバイトイネーブル（例えば８ビット）を、データ単位（バス幅である６４ビット）毎に有していることが多い。同様に記憶装置として主流であるＤＲＡＭを対象としたデータ転送に関するプロトコルにおいてもバイトイネーブルを有している。集積回路内／間を含むシステム全体におけるマスタからスレーブ（例えば、ＤＲＡＭ）へのデータ転送は、パケットベースの転送や、非パケットベースでバイトイネーブルを用いた転送を相互に利用することで実現される。
ここで、集積回路内のパラレルバスから集積回路間のＰＣＩ−Ｅｘｐｒｅｓｓへの転送経路において、パラレスバスからの一転送単位のデータにおいて、先頭と末尾の４バイト以外に無効データがある場合について詳細を述べる。ＰＣＩ−Ｅｘｐｒｅｓｓのプロトコルは、データペイロード（一転送単位）中の最終と先頭以外のデータは有効な転送対象のデータとして扱うため、ＰＣＩ−Ｅｘｐｒｅｓｓへデータを転送する際には、少なくとも向こうデータがある箇所で転送を分割し、分割した分だけヘッダーを追加する必要がある。例えば、６４ビットのデータバス幅のパラレスバスからの一転送のデータが６４バイト（６４ビットバス幅  ×  ８バースト転送）で、かつ、８バイトおきに無効なデータが１バイト含まれるようなデータをＰＣＩ−Ｅｘｐｒｅｓｓへ転送する場合は、例えば、８バイト毎に分割し其々にヘッダーを追加する必要がある。従って、転送帯域を占有するので転送効率が損なわれてしまう。
一方で、特許文献１のように、バイトイネーブルをシリアルバス上に転送するデータについてバイト単位で付与するため、転送対象のデータについて有効なデータを含む割合が多い場合は、バイトイネーブル自体のデータ量で逆に転送効率が損なわれてしまう。
【課題を解決するための手段】
【０００６】
以上の課題を解決するために本発明に係るデータ転送装置は、データと、当該データについてバイト単位で有効であるか否かを示す有効情報と、を含む信号を受信する受信手段と、前記受信手段により受信したデータのうちの対応する第１のビット数分のデータが有効であるか否かを示す部分有効情報と、当該部分有効情報が有ることを示す識別子と、前記第１のビット数分のデータと、を対応付けて送信する送信手段と、を備えるデータ転送装置であって、前記送信手段は前記データのうち、前記第１のビット数分のデータが有効である際には、当該第１のビット数分のデータに対応する部分有効情報の送信を省略することを特徴とする。
【発明の効果】
【０００７】
有効データ情報を含むデータ転送にあたって、転送効率を上げることができる。
【図面の簡単な説明】
【０００８】
【図１】システムの構成図である。
【図２】本発明の実施形態の構成を示す図である。
【図３】本発明の実施形態のパケットのフォーマットを示す図である。
【図４】キャラクタ生成部１０３４の処理フローを説明する図である。
【図５】本発明の実施形態における転送データを示す図である。
【図６】本発明の実施形態におけるシリアルバス３００上のデータフォーマット例を示す図である。
【図７】キャラクタ判別部２０３３の処理フローを説明する図である。
【発明を実施するための形態】
【０００９】
（実施形態１）
図１は、本発明の実施形態に関わるシステムの構成例である。ＡＳＩＣ＿Ａ１００とＡＳＩＣ＿Ｂ２００がシリアルバス３００で接続されているシステムの構成を示す。（ＡＳＩＣはＡｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔの略称である。）
【００１０】
シリアルバス３００上では、パケットによるデータ転送が行われる。ＡＳＩＣ＿Ａ１００は第一バスマスタＡ１０１、第一バスマスタＢ１０２、第一バスとシリアルバス間のブリッジである第一ブリッジ１０３、ＤＲＡＭコントローラＡ１０４を有しており、各モジュールは、第一バス１０５によって接続されている。第一バス１０５は、アドレスやデータ等がそれぞれ専用線で接続されているパラレルバスである。第一バスマスタＡ１０１及び第一バスマスタＢ１０２は第一バス１０５を介して、第一ブリッジ１０３とＤＲＡＭコントローラＡ１０４との間でデータ転送を行う。ＤＲＡＭコントローラＡ１０４はＤＲＡＭ  Ｉ／Ｆ  Ａ１０７を介してＤＲＡＭ＿Ａ１０６との間でデータ転送を行う。第一ブリッジ１０３は第一バス１０５からの転送をシリアルバス３００の転送に変換して、接続先のＡＳＩＣ＿Ｂ２００内の第二ブリッジ２０３へ転送を行う。
【００１１】
一方、ＡＳＩＣ＿Ｂ２００は第二バスマスタＡ２０１、第二バスマスタＢ２０２、第二ブリッジ２０３、ＤＲＡＭコントローラＢ２０４を有しており、各モジュールは、第二バス２０５によって接続されている。第二バス２０５は、アドレスやデータ等がそれぞれ専用線で接続されているパラレルバスである。第二ブリッジ２０３はシリアルバス３００からの転送を第二バス２０５の転送に変換して、第二バス２０５を介してＤＲＡＭコントローラＢ２０４に転送する。第二バスマスタＡ２０１及び第二バスマスタＢ２０２は第二バス２０５を介して、ＤＲＡＭコントローラＢ２０４との間でデータ転送を行う。ＤＲＡＭコントローラＢ２０４はＤＲＡＭ  Ｉ／Ｆ  Ｂ２０７を介してＤＲＡＭ＿Ｂ２０６との間でデータ転送を行う。なお、本例では、第一バス、第二バスとも、データのバス幅は６４ビットとする。
【００１２】
図２は本実施形態の転送方式を実現するための第一ブリッジ１０３及び第二ブリッジ２０３の構成図である。以下にそれぞれの処理について説明する。
【００１３】
〔リクエスト送信処理〕
まず、リクエストの送信処理について説明する。第一バスリクエスト受信部１０３０は第一バス１０５を介して、第一バスマスタＡ１０１や第一バスマスタＢ１０２からのリクエストを受信する。各バスマスタは、転送先のアドレス（Ａｄｄｒｅｓｓ）、Ｗｒｉｔｅ転送かＲｅａｄ転送かを示すフラグ、転送データのサイズ、書き込みデータ（Ｗｄａｔａ）、ライトストローブ（Ｗｓｔｒｂ）、及び、転送にまつわる属性情報（ＲｅｑＡｔｒｂ）を含むリクエストを出力する。
第一バスリクエスト受信部１０３０は、リクエストのタイミングを制御する信号に従い、上述したリクエストからアドレス、Ｗｒｉｔｅ転送かＲｅａｄ転送かを示すフラグ、Ｗｒｉｔｅ転送の場合は書き込みデータ、ライトストローブを抽出し、リクエストパケット変換部１０３１に渡す。
リクエストパケット変換部１０３１は、受信したリクエストをパケットに変換する。リクエストパケット変換部１０３１には、データイネーブルパターン認識部１０３３、及び、キャラクタ生成部１０３４から構成される。
データイネーブルパターン認識部１０３３は、第一バスリクエスト受信部１０３０からのリクエストのうち、１ｂｙｔｅ毎に有効なデータの有無を示しているライトストローブ（Ｗｓｔｒｂ：有効情報）を受信する。そして、連続する所定数の単位毎（第１のビット数毎）にライトストローブ（Ｗｓｔｒｂ）が全て真であるかどうかを判定するブロックである。本実施形態では、６４ｂｉｔのデータ単位（８ｂｙｔｅ単位）でライトストローブ（Ｗｓｔｒｂ）が連続して真か否かを判定するものとする。キャラクタ生成部１０３４は、第一バスリクエスト受信部１０３０からのリクエスト、及び、データイネーブルパターン認識部１０３３の判定結果を受けて、後述する各キャラクタを生成する。
【００１４】
図３に、キャラクタ生成部１０３４が生成する複数のキャラクタを有するパケットの例を示す。パケットはヘッダーおよびデータ部を有する。本実施形態のパケットではヘッダーおよびデータ部共に一キャラクタあたり３３ｂｉｔとしているとしているが、その他のビット数でもよい。ただし、データ転送の利便性を高めるためにキャラクタは所定長であることが好ましい。ヘッダー及びデータ共に３２ｂｉｔ単位（第２のビット数毎）の要素に分割され、各要素について１ｂｉｔのデータイネーブルキャラクタであるかどうかを示す識別子としてのフラグを付与されて複数の３３ｂｉｔのキャラクタを有するパケットとなっている。なお、データイネーブルキャラクタは６４ｂｉｔのデータ（第１のビット数分のデータ）についてのバイトイネーブル（ここでは、部分有効情報とする）を有しているので、データイネーブルキャラクタであることを示すフラグは部分有効情報の有無を示していることに相当する。バイトイネーブルはバイト単位でデータが有効であるか否かを示している。
【００１５】
図３（ａ）は、ライトリクエストのパケットの例である。ヘッダーは、パケットの種類を示す識別子（Ｔｙｐｅ）や転送属性情報（ＲｅｑＡｔｒｂ：Ｒｅｑｕｅｓｔ  Ａｔｔｒｉｂｕｔｉｏｎ）を含むキャラクタと転送先のアドレス（Ａｄｄｒｅｓｓ）を含むキャラクタとを有する。また、データ部は書き込みデータ（Ｗｄａｔａ）やＷｒｉｔｅ転送時にのみ生成されるデータイネーブルキャラクタ（ライトストローブ用のキャラクタ）を有する。また、各キャラクタの先頭ｂｉｔは其々のキャラクタがデータイネーブルキャラクタであるかデータキャラクタであるかを示す識別子としてのデータイネーブルキャラクタフラグである。図３（ａ）に示す例では先頭から３番目及び６番目のキャラクタのフラグが“１”なのでデータイネーブルキャラクタであり、その他は“０”なのでデータキャラクタである。なお、転送データの全てのバイトが有効でない限り、データ部はデータイネーブルキャラクタとデータキャラクタのセットを少なくとも１つ以上有する。
【００１６】
以下、リクエストパケット変換部１０３１内のキャラクタ生成部１０３４によるキャラクタ生成処理について、図４で示すフローチャートを用いて詳細に説明する。
リクエストパケット変換部１０３１内のキャラクタ生成部１０３４は、第一バスリクエスト受信部１０３０から転送されるリクエストを受けて、処理を開始する（ステップＳ４００）。次に、このタイミングで受信したリクエストの成分がヘッダーを構成する成分であるか判断する（ステップＳ４０１）。受信したリクエストの成分がヘッダーを構成する成分である場合は、図３（ａ）に示すヘッダー部を生成する（ステップＳ４０２）。ステップＳ４０１において、受信したリクエストの成分がヘッダーを構成する成分でない場合、受信したリクエストの成分はデータを生成する成分であるとして、ステップＳ４０３に移行する。データイネーブルパターン認識部１０３３の結果を受けて、ライトストローブのキャラクタを生成するかどうかを判断する（ステップＳ４０３）。
【００１７】
図５は、本実施形態においてバスマスタからのリクエストについてデータイネーブルパターン認識部１０３３が生成した３２ｂｉｔ単位のライトデータ（Ｗｄａｔａ）とバイト毎のライトストローブ（Ｗｓｔｒｂ）の一例である。
【００１８】
まず、本実施形態のデータイネーブルキャラクタは後続する２キャラクタ分のデータキャラクタのライトストローブ信号を有している。
Ｗｄａｔａ０に対応するライトストローブ（Ｗｓｔｒｂ）は“０１１１“、Ｗｄａｔａ１に対応するライトストローブ（Ｗｓｔｒｂ）は“１１１１”であるので、Ｗｄａｔａ０〜１の範囲で６４ｂｉｔのデータ単位（８ｂｙｔｅ単位）でライトストローブ（Ｗｓｔｒｂ）が連続して“真”ではない。このライトストローブ情報をデータイネーブルパターン認識部１０３３から受け取り、ライトストローブ情報（Ｗｓｔｒｂ０）と予約領域（Ｒｅｓｅｒｖｅｄ）とを含むデータイネーブルキャラクタを生成する（ステップＳ４０４）。ここでは、Ｗｄａｔａ０〜１に対応して図３（ａ）に示す３番目のキャラクタを生成する（ステップＳ４０５）。次に、Ｗｄａｔａ０〜１データキャラクタを生成し（ステップＳ４０５）、図３（ａ）に示す４番目、５番目のキャラクタを生成する。なお、予約領域は次のキャラクタのアライメントをするための情報であり、予約領域のｂｉｔ数は、（１キャラクタのｂｉｔ数）−（キャラクタフラグのｂｉｔ数）−（ライトストローブのｂｉｔ数）で決定される。本実施形態であると、３３−８−１＝２４となり予約領域は２４ｂｉｔである。次の、Ｗｄａｔａ２、Ｗｄａｔａ３に関しても８ｂｙｔｅ単位でライトストローブが連続して“真”ではないので、Ｗｄａｔａ０、Ｗｄａｔａ１と同様の処理を繰り返す。
【００１９】
一方で、Ｗｄａｔａ４、５に対応するライトストローブ（Ｗｓｔｒｂ）はともに“１１１１”であるので、Ｗｄａｔａ２〜３の範囲で６４ｂｉｔのデータ単位（８ｂｙｔｅ単位）でライトストローブ（Ｗｓｔｒｂ）が連続して“真”になる。この情報をデータイネーブルパターン認識部１０３３から受け取り、データイネーブルキャラクタの生成を省き、ステップＳ４０５に移行し、図３（ａ）に示す９番目、１０番目のキャラクタを生成する。以上の処理を一連のリクエストが終わるまで繰り返し（ステップＳ４０６）、処理を終了する。
【００２０】
なお、リードリクエストの場合、書き込みデータ（Ｗｄａｔａ）、ライトストローブ（Ｗｓｔｒｂ）がなく、転送先のアドレス（Ａｄｄｒｅｓｓ）、Ｗｒｉｔｅ転送かＲｅａｄ転送かを示すフラグ、及び、転送にまつわる属性情報（ＲｅｑＡｔｒｂ）のみを処理することになる。ライトリクエストの処理と比較して、書き込みデータ（Ｗｄａｔａ）、ライトストローブ（Ｗｓｔｒｂ）の処理（図４のステップＳ４０３、４０４、４０５）がなくなるだけであるので、ここでは説明を省略する。
リクエストパケット変換部１０３１でパケット化された各キャラクタは、リクエストパケット送信部１０３２からクロックとともにシリアルバス３００を介して、受信側のＡＳＩＣ＿Ｂ２００に送信される。図６に、本実施形態においてシリアルバス３００上でクロックに同期して転送されるデータのフォーマットを示す。キャラクタ毎にキャラクタの先頭を示すスタートビットが付与されている構成で、データ転送がない場合は、ＮＯＰ（ノーオペレーション）を示すデータが転送される。
【００２１】
〔リクエスト受信処理〕
続いて、ＡＳＩＣ＿Ｂ２００によるリクエストの受信処理について説明する。
リクエストパケット受信部２０３０はシリアルバス３００を介してＡＳＩＣ＿Ａ１００から送信されたシリアルデータ内のスタートビットを検出し、スタートビットに続く３３ｂｉｔのシリアルデータから３３ｂｉｔのキャラクタを生成し、リクエストパケット逆変換部２０３１に転送する。
【００２２】
次に、リクエストパケット逆変換部２０３１内のキャラクタ判別部２０３３の動作を図７のフローチャートを用いて説明する。まず、最初に転送されるヘッダー部の２個のキャラクタから転送の種類を示す識別子（Ｔｙｐｅ）、転送属性情報（ＲｅｑＡｔｒｂ）、アドレスを抽出し、其々を第二バスリクエスト送信部２０３２に送信する（ステップＳ７００）。さらに、後続するデータ部のキャラクタがあるか否か判定し（ステップＳ７０１）、データ部のキャラクタがある場合は、転送属性情報（ＲｅｑＡｔｒｂ）内に含まれる転送サイズ情報から、データの数（データキャラクタの数に相当する）を記憶する（ステップＳ７０２）。データ部のキャラクタがない場合は、処理を完了し、次のキャラクタが転送された際は、再びステップＳ７００においてヘッダー処理を行う。
データ部のキャラクタがあると判定された場合、後続するキャラクタのデータイネーブルキャラクタフラグから、各キャラクタがデータイネーブルキャラクタとデータキャラクタのどちらであるかを判定する（ステップＳ７０３）。
データキャラクタである場合は、データ成分を第二バスリクエスト送信部２０３２へ転送するとともに、データイネーブル生成部２０３４に今回のキャラクタがデータキャラクタであったことを通知する（ステップＳ７０４）。次にステップＳ７０５において、処理したデータの数がステップＳ７０２において記憶したデータの数に満たない場合は、ステップＳ７０３に戻り、データの数と一致した場合は、処理を完了し、次のキャラクタが転送された際は、ステップＳ７００においてヘッダー処理を行う。
ステップＳ７０３において、データキャラクタでなくデータイネーブルキャラクタの場合、前記キャラクタ内のＷｓｔｒｂ成分（第１の有効情報）をデータイネーブル生成部２０３４にそのまま転送し（ステップＳ７０６）、ステップＳ７０３へ戻る。
データイネーブル生成部２０３４は、キャラクタ判定部２０３３から受信する情報から、ライトストローブ（第２の有効情報）を生成する。本実施形態では、２キャラクタ分のデータ、つまり、６４ビットのデータ毎にＷｓｔｒｂ成分を生成する。
【００２３】
以下に、Ｗｓｔｒｂ成分の生成方法を示す。
【００２４】
データイネーブル生成部２０３４は、キャラクタ判定部２０３３からＷｓｔｒｂ成分を受信した場合は、そのまま、第二バスリクエスト送信部２０３２に送信する。また、データイネーブル生成部２０３４はキャラクタ判定部２０３３からＷｓｔｒｂ成分の受信を受けずにキャラクタがデータであったことの通知を２回連続（所定数連続）で受けた場合に、２キャラクタ分のデータについて全て真のＷｓｔｒｂ成分を生成し、第二バスリクエスト送信部２０３２に送信する。
第二バスリクエスト送信部２０３２は、リクエストパケット逆変換部２０３１からの転送情報をもとに、第二バスへのリクエスト形式に変換し、前記リクエストパケット逆変換部２０３１により取得したライトストローブを含むリクエストをＤＲＡＭコントローラＢ２０４へ第二バス２０５を介して送信する。
【００２５】
〔レスポンス送信処理〕
続いて、バスマスタからのリクエストに対するＤＲＡＭからのレスポンスの送信処理について説明する。第二バスレスポンス受信部２０３５は第二バス２０５を介して、ＤＲＡＭコントローラＢ２０４からのレスポンスを受信する。レスポンスは、エラーか否かを示すステータス情報（ＲｅｓｐＳｔ）、読み出しデータ（Ｒｄａｔａ）、及び転送長や転送のプライオリティーを示す転送属性情報（ＲｅｓｐＡｔｒｂ）を有する。
レスポンスパケット変換部２０３６は、第二バスレスポンス受信部２０３５が受信したレスポンスをパケットに変換する。本実施形態においてリクエストを変換したパケットを図３（ｂ）に示す。パケットはヘッダー及びデータ部を有する。ヘッダー及びデータ共に３２ｂｉｔ単位の要素に分割され、各要素について１ｂｉｔのデータイネーブルキャラクタのフラグを付与されて複数の３３ｂｉｔのキャラクタを有するパケットとなっている。
ヘッダーは、転送の種類を示す識別子（Ｔｙｐｅ）やステータス（ＲｅｓｐＳｔ）を含むキャラクタを有する。また、データ部は読み出しデータ（Ｒｄａｔａ）を含むキャラクタを有する。レスポンスパケット変換部２０３６の動作は、リクエストパケット変換部１０３１と同様であり、異なる点は、図４のステップＳ４０１において第２バスレスポンス受信部２０３５からのレスポンスに応じて処理を開始する点、図４のステップＳ４０３、４０４がない点であるので、ここでは説明を省略する。
レスポンスパケット送信部２０３７は、パケットに変換されたレスポンスをパラレル−シリアル変換し、シリアルバス３００へ送信する。パラレル−シリアル変換の動作は、リクエストパケット送信部１０３２の動作と同様である。パラレル−シリアル変換されたキャラクタはクロックとともにシリアルバス３００を介して、受信側のＡＳＩＣ＿Ａ１００に送信される。
【００２６】
〔レスポンス受信処理〕
続いて、ＡＳＩＣ＿Ａ１００によるレスポンスの受信処理について説明する。レスポンスパケット受信部１０３５はシリアルバス３００を介してＡＳＩＣ＿Ｂ２００から送信されたシリアルデータ内のスタートビットを検出し、スタートビットに続く３３ｂｉｔのシリアルデータをキャラクタに変換し、レスポンスパケット逆変換部１０３６に転送する。
レスポンスパケット逆変換部１０３６は、キャラクタに応じてヘッダー処理、データ部の処理を行う。レスポンスパケット逆変換部１０３６の動作はリクエストパケット逆変換部２０３１の動作と同様であり、違いはＷｓｔｒｂの処理（図７のステップＳ７０３、７０６）がないだけであるので説明を省略する。
第一バスレスポンス送信部１０３７は、レスポンストパケット逆変換部１０３６からの転送情報をもとに、第一バスへのレスポンス形式に変換し、レスポンスに対応するリクエストを発行した第一バスマスタへ第一バス１０５を介して送信する。
【００２７】
以上説明したように本実施形態によると、有効データ情報（ライトストローブ）を含むデータを効率的に転送することができる。
【００２８】
また、上述の実施形態の説明のように集積回路（チップ）間の転送が好ましいが、同一集積回路内でのデータ転送にあっても本発明を適用できる。また、上述の実施形態においては、６４ｂｉｔのデータ単位でデータイネーブルキャラクタを生成するという規則したが、任意のビット数単位でデータイネーブルキャラクタを生成してもよ。ただし、第２のビット数としてのキャラクタのビット数は、部分有効情報に対応するデータの第１のビット数以下である必要がある。
また、上述の実施形態においては、レスポンス側には有効データ情報を含まない構成としたが、リクエスト側と同じように有効データ情報を含む構成でもよい。
また、上述の実施形態においては、転送情報としてアドレス等を含んでいるが、データと有効データ情報のみを含む構成でもよい。また、本発明は出力データをパケット化して出力する技術であれば広く適用できる。
また、上述の実施形態では詳細を省略しているが、データ転送装置が転送するデータはＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やＤＭＡＣ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌｌｅｒ）その他の周辺機器、外部デバイスなどから供給される。データ転送機能の起動はＣＰＵが所定のプログラムに従って行えばよい。ＣＰＵは図１のＡＳＩＣ＿Ａ／Ｂの中に組み込まれていてもよいし、ＡＳＩＣ外にあってもよい。
【図１】
0005800565.tif 000002
【図２】
0005800565.tif 000003
【図３】
0005800565.tif 000004
【図４】
0005800565.tif 000005
【図５】
0005800565.tif 000006
【図６】
0005800565.tif 000007
【図７】
0005800565.tif 000008