(57)【特許請求の範囲】
【請求項１】
データ転送の種類を示す複数の属性情報を含むヘッダー部と、データを含むデータ部とを有するパケットを用いてデータ転送を行うデータ転送装置であって、
第１バスで用いるデータ転送の種類を示す属性情報の組合せと識別子と対応付けて、複数のパケットにおいて出現頻度が高い属性情報の組合せを優先的に予め保持する保持手段と、
属性情報を含むパケットを前記第１バスから受信する受信手段と、
前記受信手段により受信されるパケットに含まれている複数の属性情報の組合せが前記保持手段の保持している属性情報の組合せであると、当該属性情報の組合せに対応する識別子を前記複数の属性情報の組合せの代わりにパケットに含めて送信する送信手段とを有し、
前記属性情報の組合せは、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とするデータ転送装置。
【請求項２】
前記送信手段は、第１バスから取得したパケットに含まれる複数の属性情報の組合せが前記保持手段の保持する組合せに一致する場合には、一致した組合せの属性情報を送信せず、一致したことを示す識別子をパケットに含めて送信することを特徴とする請求項１に記載のデータ転送装置。
【請求項３】
前記送信手段は、第１バスから取得したパケットに含まれる複数の属性情報の組合せが前記保持手段に保持されている組合せに一致しない場合には、一致しないことを示すパケット識別子と前記第１バスから受信した属性情報とを前記パケットに含めて送信することを特徴とする請求項１又は２に記載のデータ転送装置。
【請求項４】
転送の種類を示す複数の属性情報を含むヘッダー部と、データを含むデータ部とを有するパケットを用いてデータ転送を行うデータ転送装置であって、
データ転送の種類を示す属性情報の組合せと識別子とを対応づけて、複数のパケットにおいて出現頻度が高い属性情報の組合せを優先的に予め保持する保持手段と、
識別子を含むパケットを受信する受信手段と、
前記受信手段により受信されたパケットの識別子が前記保持手段を参照するように示していると、前記保持手段に保持されている属性情報の組合せの中でパケットに含まれる識別子に対応する組合せの属性情報と前記受信手段の受信したデータとをパケットとして送信する送信手段とを有し、
前記属性情報の組合せは、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とするデータ転送装置。
【請求項５】
前記送信手段は、前記受信手段の受信したパケットの識別子が前記保持手段を参照しないように示していると、前記受信手段により受信されたパケットに含まれる属性情報を、受信手段の受信したデータに付加して送信することを特徴とする請求項４に記載のデータ転送装置。
【請求項６】
前記保持手段は、前記識別子に対して属性情報の組合せに加えて、変動のないアドレスの一部分を対応付けて保持し、前記送信手段は前記受信手段により受信される複数の属性情報が前記保持手段に保持されている属性情報の組合せであれば、前記属性情報の組合せに対応する識別子と、前記複数の属性情報および前記受信手段により受信されたアドレスの一部分の代わりとして、残りのアドレスと前記データと前記識別子とを組み合わせたパケットを送信することを特徴とする請求項１乃至３のいずれか１項に記載のデータ転送装置。
【請求項７】
第１バスに接続される第１集積回路と、第２バスに接続される第２集積回路と、前記第１集積回路と第２集積回路を接続する第３バスとを有するチップ間通信システムであって、
前記第１集積回路は、前記第１バスを介して属性情報とデータとアドレスとを含むデータ転送要求を受信する第１受信手段と、受信した属性情報の組合せが第１集積回路に予め保持されている属性情報の組合せであると、前記属性情報の組合せに対応する識別子を当該属性情報の組合せの代わりに前記アドレスに付加して前記データと一緒にパケットとして前記第３バスを介して前記第２集積回路へ送信する第１送信手段とを備え、
前記第２集積回路は、前記第３バスを介して前記第１集積回路から転送されるパケットを受信する第２受信手段と、受信したパケットの識別子が前記第２集積回路に保持されている属性情報の組合せを参照することを示していると当該識別子に対応する属性情報の組合せを前記パケットに含まれるデータと組み合わせて前記第２バスへ送信する第２送信手段とを備え、
前記属性情報の組合せは、複数のパケットにおいて出現頻度が高い属性情報の組合せであり、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とするチップ間通信システム。
【請求項８】
第１バスで用いるデータ転送の種類を示す属性情報の組合せと識別子と対応付けて複数のパケットにおいて出現頻度が高い属性情報の組合せを優先的に予め保持する保持手段を備え、データ転送の種類を示す複数の属性情報を含むヘッダー部とデータを含むデータ部とを有するパケットを用いてデータ転送を行うデータ転送装置によるデータ転送方法であって、
前記属性情報を含むパケットを前記第１バスから受信する受信工程と、
前記受信工程で受信したパケットに含まれている複数の属性情報の組合せが前記保持手段により保持されている属性情報の組合せであると、当該属性情報の組合せに対応する識別子を前記複数の属性情報の組合せの代わりにパケットに含めて送信する送信工程とを有し、
前記属性情報の組合せは、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とするデータ転送方法。
【請求項９】
第１バスで用いるデータ転送の種類を示す属性情報の組合せと識別子と対応付けて複数のパケットにおいて出現頻度が高い属性情報の組合せを優先的に予め保持する保持手段を有し、複数の属性情報を含むヘッダー部と、データを含むデータ部とを有するパケットを用いてデータ転送を行うデータ転送装置によるデータ転送方法であって、
属性情報を含むパケットを前記第１バスから受信する受信工程と、
前記受信工程で受信するパケットに含まれている複数の属性情報の組合せが前記保持手段の保持している属性情報の組合せであると、当該属性情報の組合せに対応する識別子を前記複数の属性情報の組合せの代わりにパケットに含めて送信する送信工程とを有し、
前記属性情報の組合せは、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とするデータ転送方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、集積回路内におけるデータ転送および集積回路間のデータ転送の高速化技術に関する。
【背景技術】
【０００２】
近年、集積回路のデータ処理量が増加している。そこで、集積回路内の各ブロック間や集積回路間のデータ転送をより効率良く行わせる技術が求められている。一方で、データ転送機能自体を高機能化するために、転送する対象となるアドレスやデータ以外にも様々な属性情報が付加されて転送が行われるようになってきている。【０００３】
転送効率を向上させるために、特許文献１では、バスで転送されるデータを数ビット単位で圧縮することが開示されており、特許文献２では、アドレスを圧縮する方法が開示されている。特許文献３はアドレスを含むヘッダーを単純に圧縮する方法が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−２４６６９４号公報
【特許文献２】特開２００８−２０５９４２号公報
【特許文献３】特開２００９−１３５９７４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１〜３の方法では、冗長性を利用して圧縮しているので、転送データや転送アドレスの値のランダム性が高くなると、アドレスやヘッダーをそのまま圧縮しても圧縮効率が良くない。
【課題を解決するための手段】
【０００６】
本発明のデータ転送装置は、データ転送の種類を示す複数の属性情報を含むヘッダー部と、データを含むデータ部とを有するパケットを用いてデータ転送を行うデータ転送装置であって、データ転送の種類を示す属性情報の組合せと識別子とを対応づけて、複数のパケットにおいて出現頻度が高い属性情報の組合せを優先的に予め保持する保持手段と、属性情報を含むパケットを受信する受信手段と、前記受信手段の受信したパケットに含まれている複数の属性情報の組合せが前記保持手段の保持している属性情報の組合せであると、当該属性情報の組合せに対応する識別子を前記複数の属性情報の組合せの代わりにパケットに含めて送信する送信手段と、を有し、
前記属性情報の組合せは、リクエストタイプ、キャッシュ情報、セキュリティ情報、データ幅情報、排他アクセス情報の少なくとも２つの組合せであることを特徴とする。
【発明の効果】
【０００７】
本発明によれば、データ転送効率を向上させることができる。
【図面の簡単な説明】
【０００８】
【図１】データ転送装置の概略構成を示す図である。
【図２】ＡＸＩバスプロトコルを示す図である。
【図３】ＯＣＰバスプロトコルを示す図である。
【図４】属性情報テーブルの例を示す図である。
【図５】パケット識別子の例を示す図である。
【図６】パケット送信処理を説明する図である。
【図７】パケット受信処理を説明する図である。
【図８Ａ】属性情報保持部の値に一致しなかった場合のパケットフォーマットの例
【図８Ｂ】属性情報保持部の値に一致した場合のパケットフォーマットの例を示す図である。
【図９】チップ間通信システムの構成を示す概略図である。
【発明を実施するための形態】
【０００９】
（実施形態１）
以下、図面を参照しながら本発明の実施形態１について詳細に説明する。図９は、本発明の実施形態１のデータ転送装置を備えるチップ間通信システムの構成例を示す。ＣＰＵ９０１、ＲＯＭ９０２、ＲＡＭ９０３は第１バス９０９に接続され、ＰＣＩ９０６、ＵＳＢ９０７、ＩＤＥ９０８は第２バス９１０に接続されている。そして第１バス９０９と第２バス９１０はブリッジ９０４とブリッジ９０５を介して接続されている。この構成は汎用のコンピュータにおける２チップセットの構成で代表的な構成であり、ブリッジ９０４を備えるチップとブリッジ９０５を備えるチップとを備える。
【００１０】
ＣＰＵ９０１はＲＯＭ９０２のプログラムをＲＡＭ９０３に展開し、ＲＡＭからプログラムを読み込んで実行する。第２バスに接続されているＰＣＩ９０６、ＵＳＢ９０７、ＩＤＥ９０８は各種周辺機器（不図示）との接続を制御する制御部である。
【００１１】
ブリッジ９０４はＣＰＵ又はＤＭＡＣ（不図示）によって第１バス９０９のプロトコルに従って送信されるデータ転送要求（リードリクエスト、ライトリクエスト等）を、チップ間接続によってブリッジ９０５へ転送する。なお、ライトリクエストの際はＲＡＭ９０３のデータや不図示のレジスタの値などを包含している。ブリッジ９０５はブリッジ９０４から取得したデータを第２バス９１０のプロトコルに従って、各種周辺回路に転送する。また、データ転送要求は転送対象のデータの転送に用いるデータ伝達方式の種類（バースト長、排他属性、セキュリティ情報、キャッシュ利用の有無）を示す属性情報を含む。例えば、ＣＰＵ又はＤＭＡＣ（不図示）からＰＣＩ９０６、ＵＳＢ９０７、ＩＤＥ９０８へのリードアクセスで読み出すデータ（リスポンス時）やライトアクセスで書込むデータをこの属性情報の示すデータ転送の種類で転送する。
【００１２】
ここで、リクエストに対するリスポンス（リードデータ、リクエスト完了通知等）は、リクエストの送り先からリクエスト送信元へ伝達される。その場合はブリッジ９０５とブリッジ９０４を通過し、リクエストの場合と逆のプロトコル変換をなされるので説明は省略する。
【００１３】
なお、実施形態１のデータ転送装置を備えるチップ間通信システムの構成は図９の構成に限らず、集積回路から送受するパケットについて広く適用できる。
【００１４】
図１は、データ転送装置（ブリッジ９０４、ブリッジ９０５）の構成をより詳細に示す図である。図１に示す第１バス１００から第２バス２００へデータ転送を行うに際して、データ送信装置１０１とデータ受信装置２０１とはパケット転送を行う。まず、図１を用いてデータ転送装置の概略構成を説明する。なお、転送に用いられるパケットは、図８Ａ、８Ｂに示すように、パケット識別子（０〜４ｂｉｔ）、転送の属性情報（５〜１５ｂｉｔ）およびアドレスを含むヘッダー部と転送対象のデータを含むデータ部で構成され、それぞれ所定長の転送単位（キャラクター）に区切られている。
【００１５】
図９のブリッジ９０４に相当する第１集積回路としてのデータ送信装置１０１は、第１バス１００と第３バス３００、３０１に接続されている。データ送信装置１０１は内部にリクエスト処理に関わる、第１バスリクエスト受信部１０１０（第１受信部）、第１バス・第３バスリクエストパケット変換部１０１１、送信リクエスト属性情報保持部１０１６（第１保持部）、リクエストパケット送信部１０１２（第１送信部）を有する。
【００１６】
第１バス１００から送られるリクエストは、転送先アドレス（ＡＤＤＲＥＳＳ）、ライト転送かリード転送かを示すフラグ、書き込みデータ（ＷＤＡＴＡ）、ストローブ（ＷＳＴＲＢ）及び、このリクエスト又はレスポンス（又はパケット）の転送の種類を示す属性情報を有している。
【００１７】
第１バスリクエスト受信部１０１０は、リクエストのタイミングを制御する信号に従い、上述のリクエストからアドレス・データ・ストローブ・属性情報を抽出し、リクエストパケット変換部１０１１に渡す。なお、リクエストのタイミングを制御する信号とは第１バスリクエスト受信部１０１０が第１バス１００から入力される有効信号（Ｒｅｑｕｅｓｔ信号）や有効信号（Ｖａｌｉｄ信号）およびこれらに応じて第１バスリクエスト受信部１０１０が出力するレディ信号（Ｒｅａｄｙ信号）や受領信号（Ａｃｃｅｐｔ信号）である。第１バスリクエスト受信部１０１０はこれらの信号によってリクエスト送信元とハンドシェークを行った上でパケットの受信手続きを行う。
【００１８】
属性情報組合せ保持部１０１６は、転送リクエストにまつわる属性情報の組合せ又は定数値を保持するレジスタやメモリを有している。リクエストパケット変換部１０１１は、第１バスのリクエストを第３バスで用いるパケットに変換する。その際に、属性情報組合せ保持部１０１６にアクセスしてその内容を参照し、属性情報を圧縮できそうであれば圧縮する。詳細は後述する。
【００１９】
リクエストパケット送信部１０１２は、第３バス３００に接続されており、リクエストパケット変換部１０１１から受け取ったパケットを第３バス３００に送出する。
【００２０】
データ送信装置１０１は、さらにレスポンスパケット受信部１０１３、レスポンスパケット変換部１０１４、属性情報組合せ保持部１０１７、第１バスレスポンス送信部１０１５を有する。これらの構成により第３バスから受信するパケットを第１バスの形式に変換して出力されるが、データ送信装置１０１が第１バスから受信したパケットを第３バスの形式に変換する構成と同様であるので詳細な説明は省略する。
【００２１】
図９のブリッジ９０５に相当する第２集積回路としてのデータ受信装置２０１は、第２バス２００と第３バス３００、３０１に接続される。そして、データ受信装置２０１はリクエストパケット受信部２０１０（第２受信部）、リクエストパケット変換部２０１１、属性情報組合せ保持部２０１６（第２保持部）、第２バスリクエスト送信部２０１２（第２送信部）を有する。
【００２２】
リクエストパケット受信部２０１０は、第３バス３００と接続され、データ送信装置１０１から受信したパケットをリクエストパケット変換部２０１１に渡す。属性情報組合せ保持部２０１６は、転送リクエストにまつわる属性情報の組合せ又は定数値を保持するレジスタやメモリを有している。
【００２３】
データ送信装置２０１が第２バス２００へリクエストとして出力するパケットは、転送先アドレス（ＡＤＤＲＥＳＳ）、ライト転送かリード転送かを示すフラグ、書き込みデータ（ＷＤＡＴＡ）、ストローブ（ＷＳＴＲＢ）及び、データ転送の種類を示す属性情報を有する。リクエストパケット変換部２０１１は、第３バスからのパケットを第２バスのリクエストに変換する。その際にリクエストパケット変換部２０１１は属性情報組合せ保持部２０１６にアクセスする。
【００２４】
第２バスリクエスト送信部２０１２は、リクエストパケット変換部２０１１から受け取ったリクエスト情報をリクエストのタイミングを制御する信号に従い、第２バス２００に送出する。なお、リクエストのタイミングを制御する信号とは第２バスリクエスト送信部２０１２から出力するＲｅｑｕｅｓｔ信号やＶａｌｉｄ  信号に応じてリクエスト送信先が出力するＲｅａｄｙ信号やＡｃｃｅｐｔ信号である。第２バスリクエスト送信部２０１２はこれらの信号によってリクエスト送信先とハンドシェークを行った上でリクエストの転送を開始する。
【００２５】
データ受信装置２０１はさらにレスポンスに関わる、第２バスレスポンス受信部２０１３、レスポンスパケット変換部２０１４、属性情報組合せ保持部２０１７、レスポンスパケット送信部２０１５を有している。これらの構成により第２バスから受信するパケットを第３バスの形式に変換して出力するが、データ受信装置２０１が第１バスから受信したパケットを第３バスの形式に変換する構成と同様であるので詳細な説明は省略する。
【００２６】
次に、図１における第１バス１００、第２バス２００、または図９におけるバス９０９とバス９１０に用いる標準的なプロトコルの例としてＡＸＩ、ＯＣＰプロトコルについて簡単に説明する。これらのバスプロトコルでは、「属性情報」「アドレス」「データ」を所定のフォーマットに従って、並列的に通信することを規定している。
【００２７】
図２は集積回路内で用いられるバスのプロトコルであるＡＸＩ（Ａｄｖａｎｃｅｄ  ｅＸｔｅｎｓｉｂｌｅ  Ｉｎｔｅｒｆａｃｅ）バスの制御信号および、アドレス／データ／属性情報を示す。
【００２８】
ＡＸＩバスプロトコルは、５つのチャネルと呼ばれる転送路を有する。各チャネルは、リードのアドレスを運ぶリードアドレスチャネル、ライトのアドレスを運ぶライトアドレスチャネル、リードの応答・データを運ぶリードデータチャネル、ライトのデータを運ぶライトデータチャネル、ライトのレスポンスを運ぶライト応答チャネルである。それぞれのチャネルは転送のやり取り・タイミングを司るＶａｌｉｄ，Ｒｅａｄｙ信号によってハンドシェークを行い、一連の転送の手続きを行う。また、それぞれのチャネルには、データ転送の基本情報となるアドレスやデータ以外に、転送の属性情報として、転送タイプを示すｘＢＵＲＳＴ，転送長を示すｘＬＥＮ、アトミック転送を示すｘＬＯＣ、キャッシュの制御情報を示すｘＣＡＣＨＥ、転送のセキュリティ情報を示すｘＰＯＲＴ、転送のデータ幅のサイズｘＳＩＺＥ、転送の優先度を示すｘＱＯＳ、転送領域区間を示すｘＢＵＲＳＴ、ユーザの任意の情報を運ぶｘＵＳＥＲ信号が規定されている。
【００２９】
図３は集積回路内で用いられるバスのプロトコルであるＯＣＰ（Ｏｐｅｎ  Ｃｏｒｅ  Ｐｒｏｔｏｃｏｌ）バスの制御信号および、アドレス／データ／属性情報を示す。
【００３０】
ＯＣＰバスプロトコルは、４つの転送路を持ち、リクエスト情報とアドレスを運ぶリクエスト転送路、ライトレスポンスやリードデータ・レスポンスを運ぶレスポンス転送路、ライトデータを運ぶデータハンドシェーク転送路、その他の転送路で構成される。それぞれの転送路において、Ｍｃｍｄ／ＳＣｍｄＡｃｃｅｐｔ，ＳＲｅｓｐ／ＭＲｅｓｐＡｃｃｅｐｔ，ＭｄａｔａＶａｌｉｄ／ＳＤａｔａＡｃｃｅｐｔの信号の組みでハンドシェークを行い、一連の転送の手続きを行う。それぞれの転送路には、データ転送の基本情報となるアドレスやデータ以外に、転送の属性情報として、転送のタイプを示す、ＭＢｕｒｓｔＳｅｑ、転送の長さを示す  ＭＢｕｒｓｔＬｅｎｇｔｈ、転送の正確性を示す  ＭＢｕｒｓｔＰｒｅｃｉｓｅ、アトミック転送を示す  ＭＡｔｏｍｉｃＬｅｎｇｔｈ、２次元転送の情報を運ぶ  ＭＢｌｏｃｋＨｉｇｈｔ／ＭＢｌｏｃｋＳｔｒｉｄｅ、セキュリティ情報を運ぶ  Ｍｓｅｃｕｒｅ  などから構成される。
【００３１】
なお、以降の説明では第１バス１００と第２バス２００はＡＸＩに従った通信を行うものとして説明する。
【００３２】
図４は属性情報組合せ保持部が保持する属性情報テーブルを示す。属性情報テーブルは複数の属性情報の組合せと置換する識別子とを対応付けて保持している。第１バス（ＡＸＩ）、第２バス（ＡＸＩ）の属性情報は、排他制御属性（ＬＯＣＫ）、キャッシュの属性（ＣＡＣＨＥ）、セキュリティ属性（ＰＯＲＴ）、データサイズ（ＳＩＺＥ）、リクエストタイプ（ＢＵＲＳＴ）、送信元（ＩＤ）等を有する。
【００３３】
排他制御属性（ＬＯＣＫ）は、受信装置側でシステムバスを独占的に使用する手続きを行った上で転送を行うか否かを示す。排他制御属性（ＬＯＣＫ）信号として、バスロックを行う転送を行うかどうかを示す“Ｌｏｃｋ”ビットと、システム性能の向上を図るための排他転送を行うかどうかを示す“Ｅｘｃｌｕｓｉｖｅ”ビットと、について各々１ビットで表現している。
【００３４】
キャッシュ（ＣＡＣＨＥ）の属性は、受信装置がデータの転送先までの経路において転送内容のバッファリングを許可するか否かを示す。キャッシュ（ＣＡＣＨＥ）属性には４ビット割り当てられ、キャッシュ可能かどうかを示すビット、バッファリングが可能かどうかを示すビット、キャッシュミスした際にＷｒｉｔｅＴｈｒｏｕｇｈ  やＷｒｉｔｅＢａｃｋ  などといったキャッシュシステム自身に指示を出すフィールド（２ビット）がある。
【００３５】
セキュリティ属性は、セキュリティレベルの高いスレーブにデータが受信されるように手続きを行った上で転送を行うか否かを示す。
【００３６】
リクエストタイプ（ＢＵＲＳＴ）は転送のタイプを示し、ＩＮＣＲ（連続アドレス転送）／ＦＩＸＥＤ（アドレス固定）／ＷＲＡＰ（キャッシュミスの際のアドレッシング）の３つを２ビットにエンコードして表現している。
【００３７】
データサイズはデータサイズの示す単位でデータ転送を行うことを示す。例えば、物理的なデータ幅が１２８ビットだとしても、８ｂｉｔ／１６ｂｉｔ／．．／１２８ｂｉｔの様に、どのデータ幅分を転送に使用しているかを示す。
【００３８】
各々の属性情報は直交性があり、使用する値の組合せの出現頻度には偏りがある。
【００３９】
なお通常のデータ転送では「排他属性、キャッシュ属性、セキュリティ属性情報」を保持するフィールドが無効を示す値を保持するパケットの方が、各属性情報が有効を示す値を保持するパケットよりも多いものと考えられる。また、送信元情報や、データサイズ情報は、特定の転送についてデータ転送開始してから断続的に同様の内容が集中することが多い。従って、所定の転送が始まる前に、属性情報組合せ保持部における属性情報テーブルを所定の転送に対応した属性情報テーブルに書き換えることで、様々な属性情報を持つ転送を効率よく転送することも可能となる。
【００４０】
図４のテーブルは属性情報組合せ保持部１０１６、２０１７等が保持するテーブルを示す。図４に例示するテーブルは、特定の属性情報をもつ組合せを４組、これらの４組に該当しない場合をデフォルトとして５組の属性値の組合せと、其々の組合せに対応する識別子を保持している。
【００４１】
パケット識別子のＴｙｐｅ［４］（第２識別子），［１：０］（第１識別子）は、パケット変換部１０１１、２０１１、１０１４、２０１４が変換するパケットに付与する識別子を示している。なお、Ｔｙｐｅ［４］はＴｙｐｅフィールドの４ｂｉｔ目を示し、Ｔｙｐｅ［１：０］はＴｙｐｅフィールドの０〜１ｂｉｔ目を示している。
【００４２】
パケット識別子のＴｙｐｅ［４］は、変換部の受信したパケットに含まれる属性情報の組合せが属性情報組合せ保持部１０１６、２０１７の保持しているテーブルに格納されている組合せの何れかに一致しているか否かを示す。（この例では“１”で何れかに一致、“０”で何れとも一致せず。）パケット識別子のＴｙｐｅ［１：０］はどの組合せに一致しているかを示す。テーブルに登録する組合せ数を増やそうとすると、この箇所のビット数を増やす必要がある。なお、テーブルは頻度の多い組合せを登録しているほど圧縮効率が良いが、登録する組合せを増やし過ぎると圧縮効率は下がってしまう。なお、属性情報より小さいビット数の識別子で属性情報を置換することが好ましい。
【００４３】
図５は属性情報組合せ保持部１０１６、２０１７のテーブルを用いて変換したパケットに含まれるパケット識別子Ｔｙｐｅ［４：０］を示す。なお、Ｔｙｐｅ［４］とＴｙｐｅ［１：０］については図４で説明したとおりなので説明を省略する。
【００４４】
ただし、Ｔｙｐｅ［４］が不一致（“０”）を示す場合は、Ｔｙｐｅ［１：０］には便宜上“００”を格納させる。パケット識別子のＴｙｐｅ［３］は転送がリード転送であるかライト転送であるかを示す（“０”でリード転送、“１”でライト転送）。パケット識別子のＴｙｐｅ［２］はパケットの転送方向がリクエスト方向であるかレスポンス方向であるかを示す（“０”でリクエスト方向、“１”でレスポンス方向）。
【００４５】
パケットの属性情報の種類はリクエストのパスとレスポンスのパスでそれぞれ異なっていてもよい。
【００４６】
属性情報組合せ保持部２０１６は、属性情報組合せ保持部１０１６のテーブルに対応するテーブルを有しており、属性情報組合せ保持部１０１７は属性情報組合せ保持部２０１７のテーブルと対応するテーブルを有している。ここで、対応するテーブルとは、上流で属性情報が圧縮されたパケットを属性情報付きのパケットに復号できるテーブルを示す。但し復号する際に必ずしも圧縮前と同一のプロトコルに復号する必要はない。
【００４７】
図５では、Ｔｙｐｅ［１：０］のＸＸが送信リクエスト属性情報保持部１０１６と受信リクエスト属性情報保持部２０１６における属性情報の組合せの番号を示す。同様に、Ｔｙｐｅ［１：０］のＹＹが送信レスポンス属性情報保持部１０１７と受信レスポンス属性情報保持部２０１７における属性情報の組合せを示す。図４に対応しているために其々、２ｂｉｔで表現しているが、テーブルの保持する組合せの数に応じたビット数であればよい。
【００４８】
次に図１のデータ転送装置１０１が、図６の処理フローに従って行うデータ転送処理について説明する。なお、事前に出現頻度が高いことが分かっている属性情報の組合せをテーブル化し、属性情報組合せ保持部１０１６に設定しておくことが好ましいが、学習する機構を設けてもよいし、モードに応じたテーブルを切り替えてもよい。
【００４９】
まず、第１バスを介して送信されるリクエストを第１バスリクエスト受信部１０１０が受信し（ステップＳ６００）、リクエストパケット変換部１０１１にて、リクエストの属性情報をチェックする（ステップＳ６０１）。
【００５０】
リクエストパケット変換部１０１１は第１バスからのリクエストに含まれる属性情報と属性情報組合せ保持部１０１６に存在する属性情報とを比較するために、属性情報組合せ保持部１０１６に問い合わせを行う（ステップＳ６０２）。
【００５１】
リクエストパケット変換部１０１１は第１バスリクエスト受信部１０１０から受信したパケットと属性情報保持部１０１６から取得した属性情報の値を比較し、その比較結果に応じたパケット識別子を、ヘッダーに付加する。なお、属性情報組合せ保持部のテーブルに登録されている属性情報の組合せを有するパケットについてはパケット識別子を付加する代わりに変換するパケットには属性情報を埋め込まない（ステップＳ６０４に処理を進める）。
【００５２】
リクエストパケット変換部１０１１の受信するパケットの属性情報の組合せが属性情報組合せ保持部に存在するテーブルに格納されている属性情報の組合せのいずれとも一致しない場合には所定のパケット識別子（図５によると“０００００”又は“０１０００”）を付加し、パケットに含まれている属性情報を図８Ａに示すフォーマットに埋め込んで転送する（ステップＳ６０３、およびステップＳ６０４）。
【００５３】
リクエストパケット変換部１０１１で生成されたパケットを、リクエストパケット送信部１０１２が第３バスに送出する（ステップＳ６０５）。
【００５４】
図８Ａは、パケット変換部の受信したパケットの属性情報の組合せが属性情報組合せ保持部内のテーブルに登録されている属性情報の組合せに一致しなかった場合にパケット変換部が出力するパケットのフォーマットを示す。一方で、図８Ｂは、パケット変換部の受信したパケットの属性情報の組合せが属性情報組合せ保持部内のテーブルに登録されている属性情報の組合せに一致した場合にパケット変換部が出力するパケットのフォーマットを示す。
【００５５】
図８Ｂを参照すると、パケット変換部の受信したパケットの属性情報の組合せが属性情報組合せ保持部内のテーブルに登録されている属性情報の組合せに一致した場合には、第３バスにて転送されるデータの総量が圧縮されることが分かる。例えば、現状のＡＸＩに関しては、プロトコル上１６バースト長（ＡＸＩ３）、２５６バースト長（ＡＸＩ４）の転送が可能ではあるが、実際は長い転送長を許容するほど他の転送に影響を与えるおそれが高くなるため、便宜的に４又は８バースト長を最大とすることが多い。そのため、属性情報を圧縮しない場合は、４又は８バースト毎に属性情報が出現することが多く、属性情報の圧縮の必要性が高い。
【００５６】
次に、図１のデータ受信装置２０１が、図７の処理フローに従って行うデータ転送処理について説明する。なお、事前に頻度の高い属性情報の組合せをテーブル化し、属性情報組合せ保持部２０１６に設定しておく。
【００５７】
まず、リクエストパケット受信部２０１０は第３バスを介して送信されるパケットを受信し（ステップＳ７００）、リクエストパケット変換部２０１１はリクエストパケット受信部２０１０の受信したパケットの識別子を解析する（ステップＳ７０１）。
【００５８】
解析によって、受信したパケットがテーブルに登録されている組合せの属性情報を含むパケットとしてリクエストパケット変換部１０１１によって変換されたことを示す場合は、属性情報組合せ保持部２０１６のテーブルに登録されている属性情報の値を参照して、圧縮前の属性情報に対応する第２バスの属性情報を生成する（ステップＳ７０２）。
【００５９】
ここで、パケットの識別子がリクエストパケット変換部１０１１によって属性情報が置換されていることを示していることは、パケットの識別子がリクエストパケット変換部２０１１に対して属性情報組合せ保持部２０１６を参照するように示していることに相当する。
【００６０】
一方で、受信したパケットが属性情報保持値に登録されている組合せの属性情報を含まないパケットとしてリクエストパケット変換部１０１１によって変換されたことを示す場合は、受信したパケットに埋め込まれている属性情報を利用する（ステップＳ７０３）。この場合は、リクエストパケット変換部１０１１は属性情報組合せ保持部２０１６の属性情報を参照しなくてもよい。
【００６１】
リクエストパケット変換部２０１１が受信したパケットから第２バスのリクエストを生成（ステップＳ７０４）した後に、第２バスリクエスト送信部２０１２が第２バスへリクエストを発行する（ステップＳ７０５）。
【００６２】
以上のように、本実施形態によれば、転送するパケットの属性情報を適宜圧縮してデータ転送を行うことができる。そして、第３バス３００、３０１におけるデータ転送を効率的に実行することができる。
【００６３】
また、上述の実施形態では、第３バスはパケット型の転送形態（パケットの幅でパラレル転送を行う形態：  Ｎｅｔｗｏｒｋ  Ｏｎ  Ｃｈｉｐなど）について説明したが、シリアルバスや無線通信などの様々な物理的な転送形態を用いても本発明は適用できる。すなわち、論理層でデータをパケット化するデータ転送について高い効果を発揮し、物理層の形態にはとらわれない。
【００６４】
また、上述の実施形態では、集積回路間（チップ間、モジュール間）におけるデータ転送について説明したが、本発明は同一集積回路（同一チップ、同一モジュール）内におけるデータ転送にも適用することもできる。
【００６５】
ただし、チップ間の転送は、チップ内の転送に比べて、データを転送する能力が低く、システムのボトルネックとなる可能性が高い。チップ内の転送では、「属性情報」「アドレス」「データ」についてそれぞれに物理的に信号線が存在し、同時・並列的に転送することができる。一方、チップ間の転送では、製品のコストを下げようとすると共通の信号線を利用してすることになり（チップのＩＯピンはコスト上昇を招くため）、時系列に転送するので、上述の実施形態による転送効率の向上はチップ内転送に比べて顕著である。
【００６６】
また、上述の実施形態では、属性情報組合せ保持部はデータ転送前に属性情報テーブルを設定できるとしたが、設計開発時（又は製造時）に静的に属性情報を設定してもよい。
【００６７】
さらに、アドレスの上位又は下位について変動しないことが予め分かっている部分があることが予め分かっている場合は属性情報テーブルに上位（又は下位）アドレス情報を含ませて、属性情報と変動のないアドレスの一部分（上位又は下位数ビット分）を一緒に圧縮するように構成してもよい。例えば、ソフトウェアのアドレスマップの特性やバスの規格を考慮すると、あるモジュールにアクセスする場合には常に上位４ビットは固定の”００００”となることが考えられる。その場合は、テーブルに上位アドレス比較値を入れておけば変動のないアドレスビット数分さらにデータ転送効率がよくなる（下位アドレスについても同様）。この場合、変動のないアドレス部分を識別子で置換する場合には、属性情報の組合せが一致することだけを確かめて置換するようにしてもよい。
【００６８】
また、上述の実施形態では属性情報の組合せが保持しているものと一致しない場合は、一致していないことを示す識別子を付加するだけであるが、属性情報の組合せが一致しなくても変動しないアドレス部分を置換するように構成してもよい。その場合には復号側は常に変動しないアドレス部分を付加する構成を必要とする。
【００６９】
また、上述の実施形態では図１における第１バス１００、第２バス２００、または図９におけるバス９０９とバス９１０に用いるプロトコルとしてＡＸＩを挙げて説明したが、本発明はデータ、アドレス、属性情報を組み合わせて転送するプロトコルであれば広く効果を発揮することができる。なお、複数の転送内容を１つの属性情報として複数のビット数で表現している場合でも本発明は適用できる。
【００７０】
なお、属性情報の組合せは、データ転送を行うＣＰＵ／ＤＭＡなどの送信元の使用形態で組合せ出現率に偏りがある、従って属性情報組合せ保持部は、送信元毎にテーブルを保持するようにしてもよい。また、ＣＰＵ９０１が所定のタイミング毎に属性情報の出現頻度の順列に変更があれば、属性情報組合せ保持部のテーブルを更新するようにしてもよい。その際は、出現頻度の高い組合せを優先的に保持させるようにする。
【００７１】
本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために以下の請求項を添付する。
【図１】
0006053692.tif 000002
【図２】
0006053692.tif 000003
【図３】
0006053692.tif 000004
【図４】
0006053692.tif 000005
【図５】
0006053692.tif 000006
【図６】
0006053692.tif 000007
【図７】
0006053692.tif 000008
【図８Ａ】
0006053692.tif 000009
【図８Ｂ】
0006053692.tif 000010
【図９】
0006053692.tif 000011