JP2007538331A - 集積回路及びバッファリング方法 - Google Patents

Abstract

インターコネクト手段(N)によって結合される、多数の処理モジュール(M,S)を具える集積回路を提供する。第１の処理モジュール(M)は、トランザクションに基づいて第２の処理モジュール(S)と通信を行う。第２の処理モジュール(S)に関連する第１のラッパー手段(WM1)は、前記インターコネクト手段を介して転送すべき第２の処理モジュール(S)からのデータを、第１の量のデータがバッファされるまでバッファしてから、第１の量のバッファされたデータを前記第１の処理モジュール(M)へと転送する。

Description

本発明は、多数の処理モジュール及びこれら多数の処理モジュールを結合するインターコネクト（相互接続）手段を有している集積回路、バッファリング方法及びデータ処理システムに関する。

システムオンシリコンは、新たな機構の実現と既存の機能を改善するための需要が増加の一途をたどっているために、複雑さが増し続けている。このことは、１つの集積回路上に集積化し得るコンポーネントの密度を高めることにより可能となる。同時に、回路を作動させるクロック速度も増加する傾向にある。コンポーネントの高密度化とあいまってクロック速度を高めるにつれて、同じクロックドメイン内で同期して作動させることのできる領域が縮小されている。これが、モジュラー手法の需要を創出した。このような手法によれば、処理システムは多数の、相対的に独立した複雑なモジュールを具える。従来の処理システムでは通常、システムのモジュールはバスを介して互いに通信する。しかしながら、このような通信方法は、モジュールの数が増加すると、もはや下記の理由により実用に供しなくなる。一方ではモジュールの数が多数になるとバスへの負荷が高くなり過ぎ、他方ではバスへデータを送信できるデバイスは１つだけであるため、バスが通信のボトルネックとなる。

通信ネットワークは、これらの不都合を解消するのに有効な策を成している。ネットワークオンチップ（Networks on chip（NoC））は近年、非常に複雑なチップにおけるインターコネクトの問題に対する解決手法として、高い注目を集めている。この理由は２つから成る。第１に、ＮｏＣはグローバル配線を構築し管理するため、新しいディープサブミクロン技術における電気的課題を解決する助けとなる。ＮｏＣは配線を共有すると同時に、それらの個数を削減し利用性を高める。ＮｏＣは、電力効率及び信頼性をよくすることもでき、かつバスに比べて拡張性がある。第２にＮｏＣは、莫大な数のトランジスタチップの設計を管理するのに必須である演算処理を通信から切り離す。ＮｏＣがこのような分離を実現できる理由は、これらのＮｏＣはもともとは、プロトコルスタックを用いて設計されるからであり、プロトコルスタックは、通信サービスの利用をサービスの実装から分離するインターフェースを明確に規定する。

しかしながら、システムオンチップ（ＳｏＣ）の設計時にオンチップ通信用のネットワークを用いると、考慮しなくてはならない多くの新しい問題を引き起こすことになる。これは、通信モジュールを直接接続する、既存のオンチップインターコネクト（例えば、バス、スイッチ、または二地点間配線など）とは対照的に、ＮｏＣでは、モジュールがネットワークノードを介して間接的に通信を行うからである。結果として、インターコネクトのアービトレーションが集中型から分散型に変わり、不調なトランザクション、高い待ち時間、及びエンド・ツー・エンドフロー制御といった問題を、インテレクチャル・プロパティ・ブロック（ＩＰ）か、またはネットワークによって処理しなければならなくなる。

これらの問題の大部分はすでに、ローカル及び広域ネットワーク（コンピュータ・ネットワーク）の分野における研究課題及び並列計算機のインターコネクトネットワーク用のインターコネクトとして存在していた。これらは共にネットワークオンチップに極めて関連しており、これらの分野での多くの実績は、チップにも適用することができる。しかしながら、ＮｏＣの前提はオフチップネットワークとは異なっているため、ネットワーク設計上の選択の大部分を再評価しなければならない。ネットワークオンチップは、設計上の選択を異にし、最終的にネットワークサービスに影響を及ぼす、種々の特性（例えば、強いリンク同期）や、制約（例えば、高いメモリコスト）を有する。

オンチップインターコネクトとしてネットワークを導入することは、バスまたはスイッチのような直接的なインターコネクトと比較すると、通信を根本的に変化させることになる。これは、通信モジュールを直接接続せずに、１つまたは１つ以上のネットワークノードによって分離させるネットワークのマルチホップ性によるものである。このことは、モジュールを直接接続する、一般的な既存のインターコネクト（例えば、バス）とは対照的である。

現代のオンチップ通信プロトコル（例えば、デバイス・トランザクション・レベルのＤＴＬ及びＡＸＩ-プロトコル）は、要求と応答から成るトランザクションで、スプリット及びパイプラインに基づいて動作し、バスは、マスタによって出された要求が対応するスレーブによって受け入れられた後に釈放されて、他に使用される。スプリット・パイプライン型の通信プロトコルは、特に、インターコネクトを効率的に利用できるようにするマルチホップ式のインターコネクト（例えば、ネットワークオンチップまたはブリッジを有するバス）において用いられる。スレーブにおける応答の生成に時間がかかる場合に、スプリットバスの効率を上げることができる。パイプラインプロトコルでは、マスタは複数の未処理の要求（すなわち、応答が保留中または期待されている要求）を有することができる。

上述したプロトコルは、システムまたはインターコネクトのレベルではなく、デバイスのレベルにて動作するように設計される。言い換えれば、前述のプロトコルは、インテレクチャル・プロパティ・ブロックＩＰ及びそれらの初期のインテグレーションを再利用可能にする実際のインターコネクトの実現（例えば、アービトレーション信号は不可視である）とは無関係に設計される。

特に、前述のオンチップ通信プロトコルは、４つの主要な信号グループ、即ちコマンド（またはアドレス）、書込みデータ、読取りデータ、及び書込み応答を包含する。コマンドグループは、コマンド、アドレス、及びバースト長やマスクのようなコマンドフラグから成る。コマンド及び書込みデータグループは、ターゲットへのイニシエータによって駆動される。読取りデータと書込み応答は、イニシエータからのコマンドに追従して、このイニシエータへとターゲットによって駆動される。４つのグループは全て、何らかの順序をそれらの間に成して互いに独立しており、例えば、コマンドの前に応答が発せられることはない。

これらのオンチップ通信プロトコルは、従来のチップ設計において周知の、データのバッファリングの概念も実現する。一般的にバッファリングは、１つのモジュールがデータを生成し、他のモジュールがデータを消費するように、異なるモジュールを分離するために用いられる。バッファリングを行わないと、消費モジュールが生成モジュールのデータを受け入れる準備が整うまで、生成モジュールは消費モジュールによって阻止されることになる。生成モジュールが阻止されないようにするためには、生成モジュールによって生成されたデータを格納するバッファを導入して、消費モジュールの準備が整っていなくても、生成モジュールがその実行を継続し得るようにする。消費モジュールが幾つか、または全てのバッファされたデータを受け入れる準備が整ったとき直ちに、バッファ内に格納されているデータが消費モジュールへと供給される。

他方では、現代のオンチップ通信プロトコルは、インターコネクトの利用性を改善するために、書込みコマンドまたは書込みデータのバッファリングも用いている。したがって、小さい書込みバーストは、これらがインターコネクトを介して送信される前に、バッファ内に格納または蓄積される。蓄積されたデータは短いバーストで転送する代りに、インターコネクトを介して長いバーストで転送されることになり、これは通常インターコネクトの利用性の改善につながる。このことは、第１の書込みデータＷ１をバッファリングし、このデータを、例えば第２の書込みデータＷ２がバッファに到達するまでは転送しない（すなわち、第１の書込みデータはインターコネクトを介して転送されない）ようにし、書込みデータがインターコネクトの利用性に関して最適な長さを有する１つのバーストとして転送されるようにして実施することができる。

したがって、多数の書込みからのデータをバッファして、１つのバーストに集約することができる。さらに、書込みコマンドにおけるデータの一部分は、別のバーストで送信することができる。

前述の、オンチップ通信プロトコルにて上述したようなバッファリング技法を実施する理由は、インターコネクトによって接続される、システムオンチップにおけるインテレクチャル・プロパティ・ブロックＩＰが、「固有に」通信できなくてはならない、すなわち、ワードの幅及びバーストサイズを、インターコネクトよりはむしろデバイスに適合するように構成しなくてはならないためである。例えば、インテレクチャル・プロパティ・ブロックＩＰがピクセルを処理する場合、これらのインテレクチャル・プロパティ・ブロックはピクセルを消費しかつ生成する一方で、それらがビデオフレームを処理している場合には、ビデオフレームを消費しかつ生成する。データをバッファリングすることによって、十分な量のデータを１つのバーストで一度に転送できるように集められるまで、インターコネクトを介して転送すべきデータを待機させる。

上述したオンチッププロトコルは、主に、待ち時間の短いバス用に設計されている。さらに、これらのプロトコルは、読取り操作は常に緊急を要するために、不必要なバッファリングを行うことなくできるだけ早く完了させなければならない、という前提に基づいて設計されている。しかしながら、システムの大型化と、ネットワークまたはブリッジを有するバスのようなマルチホップ式のインターコネクトによって、待ち時間も同様に長くなっている。こういった場合には、通信精度が粗くなり、待ち時間の要求の正確さが低下する。

さらにこれらのプロトコルは、無制限なデータのバッファリングが起因するデッドロックを回避するために最適なバースト長に到達していなくても、現在バッファされているデータの幾つかを転送させる手法を含んでいる。ＤＴＬ通信プロトコルは、現在のワードまでの全てのデータを、インターコネクトで転送させるフラッシュ信号を提供している。ＡＸＩプロトコルは、バッファされたデータを転送させる書込みコマンド用のアンバッファフラグを提供している。

したがって、本発明の目的は、インターコネクトの利用性を改善した集積回路、バッファリング方法、並びにデータ処理システムを提供することにある。

この目的は、請求項１に記載の集積回路、請求項１３に記載のバッファリング方法、及び、請求項１４に記載のデータ処理システムによって達成される。

したがって、本発明によれば、インターコネクト手段によって結合される多数の処理モジュールを具える集積回路が提供される。第１の処理モジュールは、トランザクションに基づいて第２の処理モジュールと通信する。前記第２の処理モジュールに関連する第１のラッパー手段は、第１の量のデータがバッファされるまで、前記インターコネクト手段によって転送すべき前記第２の処理モジュールからのデータをバッファリングし、その後、前記第１の量のバッファされたデータを、前記第１の処理モジュールへと転送する。

したがってデータは、単一のパッケージでインターコネクトを介して転送すべきデータの量が十分に多量になるまで、スレーブ側にてバッファされる。インターコネクトを介して送信するパケットの数を低減すれば、必要なパケットヘッダが減るため、通信のオーバーヘッドが軽減される。送信すべきデータは、十分な量のデータが集められるまでバッファする。

本発明の態様によれば、第２の量のデータがバッファされるまで、インターコネクト手段を介して前記第２の処理モジュールへ転送すべき前記第１の処理モジュールからのデータをバッファリングするために第２のラッパー手段を第１の処理モジュールに関連付けて、その後、前記第２のラッパー手段が、前記バッファされたデータを前記第２の処理モジュールへ転送し得るようにする。したがってデータは、インターコネクトを介して単一のパッケージで転送すべきデータの量が十分に多量になるまで、マスタ並びにスレーブ側にてバッファされる。

本発明のさらなる態様によれば、前記第１及び第２のラッパー手段を、それぞれ、第１及び第２のアンバッファ信号または信号のグループの特定の組合せに応じて、（前記第１及び第２のラッパー手段にバッファされたデータが、前記第１及び第２の量より少なくても）バッファされたデータを転送するように適合させる。アンバッファ信号を発することにより、データがバッファされるのを待機する処理によるデッドロックの発生を阻止することができる。

本発明のさらなる態様によれば、前記第１及び第２のラッパー手段を、それぞれ、第１及び第２のアンバッファフラグに従って、（前記第１及び第２のラッパー手段にバッファされたデータが、前記第１及び第２の量より少なくても）バッファされたデータを転送するように適合させる。したがって、バッファされたデータをフラッシュ（一括消去）するための代替方法が提供される。各トランザクションに対して与えられる信号とは対照的に、フラグは長めの時間に設定することができる。このようにして、バッファリングを実行させたり、停止させたりすることができる。フラグは、任意の方法、例えば、ＩＰからの信号とともにトランザクションの一部として、または別のコンフィグレーションのトランザクション（特殊なフラッシュトランザクション、またはメモリーマップ式の読取りまたは書込み）を介して設定／解除することができる。これらのトランザクションは、同一のＩＰからか、または別のコンフィグレーションモジュールから出すことができる。

本発明の好適な態様によれば、前記第１及び第２のラッパー手段の少なくとも１つが、前記第１と第２の処理モジュール間の前記通信の通信特性に従ってデータを転送する前に、前記第１または第２のラッパー手段にバッファすべきデータの最適な第１または第２の量を決定する決定ユニットＢＬＤＵを具えるようにする。したがって、インターコネクトを介して転送されるデータのパケットのサイズを、実際の通信の特性に応じて適合させることができるため、インターコネクトの利用性を改善することができる。

本発明は、インターコネクト手段に接続される多数の処理モジュールを有する集積回路内でデータをバッファリングする方法にも関し、第１の処理モジュールがトランザクションに基づいて第２の処理モジュールと通信する前記バッファリング方法が、第１の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第２の処理モジュールからのデータをバッファリングし、バッファされたデータは、前記第１の量のデータがバッファされたときに転送するステップを含むようにする。

本発明はさらに、インターコネクト手段によって結合される多数の処理モジュールを具える集積回路を含む、データ処理システムにも関する。第１の処理モジュールは、トランザクションに基づいて、第２の処理モジュールと通信を行う。前記第１の処理モジュールに関連する第２のラッパー手段は、第１の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第１の処理モジュールからのデータをバッファリングし、その後、前記第１の量のバッファされたデータを、前記第１の処理モジュールへと転送する。

したがって、上述のようなデータのバッファリングは、多数の集積回路を具えるシステムにも適用することができる。

本発明は、バッファされたデータがインターコネクトの手段を介してパケットで最適に転送されるように十分に大きくなるまでデータをバッファする、という考えに基づいて成したものである。パケットが大きくなるほど、パケットヘッダの量は少なくなり、オーバーヘッドが軽減され、インターコネクトがより効率よく利用される。データは、早く送信できても、最適なパケットサイズとなるのに十分なデータがバッファされたときにのみ転送される。データは、最適な転送の条件が満足されたときにのみ、バッファから転送される。

本発明のさらなる態様は、従属項に記載した通りのものである。

本発明のこれら及び他の態様は、これ以降に述べる実施例を参照して明らかにする。

以下の実施例は、システムオンチップに関し、すなわち、同一チップ上（例えば、パッケージ内のシステム、マルチダイ・モジュールなどを含む）または異なるチップ上の多数のモジュールが、ある種のインターコネクトを介して互いに通信するシステムオンチップに関する。インターコネクトは、ネットワークオンチップＮｏＣとして具体化される。ネットワークオンチップは、配線、バス、時分割多重化、スイッチ、及び／またはルータをネットワーク内に具えることができる。前記ネットワークのトランスポート層では、モジュール間の通信はコネクションによって行うことができる。コネクションとは、各々が第１のモジュールと、少なくとも１つの第２のモジュールとの間に一組のコネクション特性を有している一組のチャネルとみなすことができる。第１のモジュールと単一の第２のモジュールとの間のコネクションに対して、そのコネクションは２つのチャネル、すなわち、第１のモジュールから第２のモジュールへの第１チャネル、すなわち要求チャネルと、第２のモジュールから第１のモジュールへの第２チャネル、すなわち応答チャネルとを具えることができる。要求チャネルは、第１モジュールから第２モジュールへのデータ及びメッセージ用に確保され、応答チャネルは第２モジュールから第１モジュールへのデータ及びメッセージ用に確保される。しかしながら、コネクションが１個の第１のモジュールとＮ個の第２のモジュールに関連する場合には、２×Ｎ個のチャネルを用意する。コネクションの特性には、順序付け（データ転送の順序）、フロー制御（遠隔バッファをコネクション用に確保して、データ生成モジュールは、生成したデータ用に利用できるスペースが保証された場合にのみデータを送信することができるようにする）、スループット（スループットの下限値を保証する）、待ち時間（待ち時間の上限値を保証する）、損失（データの脱落）、送信の終了、トランザクションの完了、データの正確さ、優先度、またはデータの配信を含めることができる。

図１に、本発明によるネットワークオンチップの基本的な配置を示す。特に、各々がネットワークインターフェースＮＩに関連しているマスタモジュールＭとスレーブモジュールＳを示している。各モジュールＭとＳはそれぞれ、関連しているネットワークインターフェースＮＩを介してネットワークＮに接続されている。ネットワークインターフェースＮＩは、マスタモジュールＭ及びスレーブモジュールＳとネットワークＮとの間のインターフェースとして用いられる。ネットワークインターフェースＮＩは、各モジュールＭ、ＳとネットワークＮとの間の通信を管理するために設けられるため、各モジュールはネットワークまたは他のモジュールとの通信に対処する必要なく、それぞれの専用のオペレーションを実行することができる。ネットワークＮは、一方のネットワークインターフェースＮＩから他方のネットワークインターフェースへ、ネットワークを通してデータをルーティングするための多数のネットワークルータＲを具えることができる。

以下に説明するようなモジュールは、前記ネットワークインターフェースＮＩにてネットワークと情報をやり取りする、いわゆるインテレクチャル・プロパティ・ブロックＩＰ（計算素子、メモリ、または、内部にインターコネクトモジュールを包含することができるサブシステム）とすることができる。ネットワークインターフェースＮＩは、１個またはそれ以上のＩＰブロックに接続することができる。同様に、ＩＰブロックは１個以上のネットワークインターフェースＮＩに接続することができる。

マスタモジュールＭ及びスレーブモジュールＳに関連している各ネットワークインターフェースは、ラッパー（wrapper）手段ＷＭ２、ＷＭ１をそれぞれ具えている。ラッパー手段ＷＭ２、ＷＭ１は、ネットワークＮを介してマスタＭ及びスレーブＮから送信される任意のデータのバッファリングに関与する。特に、２個のラッパー手段ＷＭ１、ＷＭ２は、それぞれマスタＭまたはスレーブＳから到来するデータを、所定のデータ量がバッファされるまでバッファする。その後、バッファされたデータはネットワークＮ、すなわち、インターコネクトを介して、所定のバースト長内でパケットとして転送される。ラッパー手段ＷＭ２、ＷＭ１が、マスタＭ並びにスレーブＳに関連して、要求並びに応答データをそれぞれのバースト長にてバッファ及び送信可能にすることに留意すべきである。応答が要求と異なることがあるように、それらのバースト長が異なることもある。選択バースト長は、ネットワークの利用性を改善するために、ネットワークＮに適合するように選ばれなければならない。

図２は、第２実施例によるネットワークオンチップの概略図を示す。特にこの第２実施例は、第１実施例によるネットワークオンチップにほぼ相当するものである。したがって、第１のラッパー手段ＷＭ１は、スレーブＳに関連するネットワークインターフェースＮＩ内に配置され、第２のラッパー手段ＷＭ２は、マスタＭに関連するネットワークインターフェースＮＩの内部に配置されている。第１の実施例のように、ラッパー手段ＷＭ１、ＷＭ２は、最適な転送条件が満足されるまで、ネットワークＮを介して送信すべきデータをバッファする働きをする。第１のアンバッファフラグユニットＵＢＦ１及び第２のバッファフラグユニットＵＢＦ２が、スレーブＳ及びマスタＭにそれぞれ関連するネットワークインターフェースの内部に配置されている。第１及び第２のアンバッファフラグユニットＵＢＦ１、ＵＢＦ２は、第１及び第２のアンバッファフラグを格納する働きをする。第１及び第２ラッパー手段は、第１または第２のアンバッファフラグが、第１または第２のアンバッファフラグユニットＵＢＦ１、ＵＢＦ２内にそれぞれ設定されると、バッファされたデータを直ちに転送するように適合させる。こうしてバッファデータをフラッシュさせることにより、バッファされているデータがデッドロックされるのを防ぐことができる。このような場合、バッファされている全てのデータは、ネットワークＮに対する最適なバースト長に適するパケットサイズになることを待たずに、できるだけ早く転送される。

バッファされたデータのフラッシングは、第１または第２のラッパー手段ＷＭ１、ＷＭ２が受信する、第１または第２のアンバッファ信号によって達成することもできる。したがって、第１または第２のラッパー手段ＷＭ１、ＷＭ２がアンバッファ信号を受信した場合、現在バッファされているデータはできるだけ早く、すなわち、取得すべき最適なバースト長を待たずに転送される。その結果、マスタＭは要求のフラッシングを開始することができ、スレーブＳは応答のフラッシングを開始することができる。

各トランザクションに対して与えられるアンバッファ信号とは対照的に、アンバッファフラグはやや長めの時間用に設定することができる。このようにして、バファリングの実行または停止を切り替えることができる。フラグは任意の方法、例えば、トランザクションの一部としてＩＰからの信号で、または、別のコンフィグレーションのトランザクション（特殊なフラッシュトランザクションか、または、メモリーマップ式の読取り及び書込み）を介して、設定／解除することができる。これらのトランザクションは、同一のＩＰからか、または別のコンフィグレーションのモジュールから送出することができる。

さらに、第１及び第２の決定手段ＢＬＤＵ１、ＢＬＤＵ２が、スレーブＳ及びマスタＭに関連するネットワークインターフェースＮＩの内部にそれぞれ配置されている。第１及び第２の決定ユニットＢＬＤＵ１、ＢＬＤＵ２は、現在の通信またはコネクションのプロパティに従ってネットワークＮを介してデータを転送するための、最適なバースト長を決定する働きをする。最適なバースト長は、要求された処理の初期段階の期間中、または所定の時間間隔の期間中に、静的または動的に決定することができる。あるいは、最適なバースト長は、（１）ネットワークを介してデータを転送するためのコネクションを設定する度に、（２）トランザクション毎に、（３）ＩＰが他のコネクションに切り替わる度に、（４）パケット毎に、（５）ネットワークオンチップの状態が変化したとき（例えば、リコンフィギュレーション、ＮｏＣ負荷、バッファの充填など）に動的に決定することもできる。最適なバースト長の決定は、決定ユニットＢＤＬＵ１、２内に格納されている情報或いはネットワークＮまたはＩＰブロックから受信される情報に基づいて行うことができる。したがって、ネットワークＮは、要求された通信またはコネクションに対する通信若しくはコネクションのプロパティを決定すると共に、場合によっては格納するための、通信プロパティ手段ＣＰＭを具えることができる。ＣＰＭは、集中型または分散型（例えば、全てのＮＩの内部に）にすることができる。

最適なバースト長の決定に加えて、伝送瞬時も、第１及び第２の決定手段ＢＬＤＵ１、ＢＬＤＵ２によって同様の方法で決定することができる。保証されたスループットのＧＴコネクションの場合、データは、そのコネクション用に確保されたスロットの１つを待たなければならない。「フラッシュ」のような信号／フラグを用いることによって、前もってデータを送信させることができる。さらに、ベストエフォートＢＥ型のコネクションには、ネットワークインターフェースＮＩにおけるコネクション間のラウンドロビンアービトレーションを用いることができる。「フラッシュ」のような信号は、コネクションの優先度を一時的に高めにすることができる。

第１及び第２実施例では、データ、すなわちバッファされるデータを、パケット形式でネットワークを介して送信する。パケットは、各ネットワークインターフェースＮＩにおいて形成するのが好適であり、ネットワークＮに関しては最適な方法で転送するのに十分な大きさとしなければならない。全てのパケットはパケットヘッダを含むので、パケットが大きくなれば、必要とされるパケットヘッダの数が少なくなり、必然的にオーバーヘッドが低減され、ネットワークの利用性が改善される。データは、バッファされるデータがネットワークを介して転送できるような最適なパケットサイズに達するまでバッファされる。バッファされたデータ量が未だ最適なパケットサイズに達しない場合には、やや小さいサイズのパケットの転送が可能であったとしても、データはネットワークＮを介して転送されることはない。バーストサイズは、バスまたは通信観点でのＩＰに関連付けられる一方で、パケット長は、パケット化が行われる（バスには不要）ときにのみ適用される。これ以前の段落にて記載した、バーストサイズを決定するスキームの全ては、最適なパケットサイズの決定に適用することもできる。

第１及び第２実施例によれば、データはネットワークインターフェースＮＩ、すなわち、インターコネクトインターフェース内にバッファされて、インテレクチャル・プロパティ・ブロックを構成し得るマスタＭまたはスレーブＳがインターコネクトまたはネットワークを介して通信するための実際の通信または通信プロトコルには関与しないようにするのが好適である。

言い換えれば、バッファリングは、要求並びに応答に対して行うようにし、すなわち、要求並びに応答は、インターコネクトを介して転送する前に、マスタ及びスレーブ側のバッファにそれぞれ蓄積されるようにする。要求及び応答は、特定のインターコネクトにとって最適な長さのバーストで集められる。書込みのような要求があった場合には、トランザクションの応答部へのアンバッファフラグによってバッファリングを阻止することができる。したがって、保留中のもの及び現在のものを含む、全ての応答または要求は、インターコネクト用に最適なバースト長を形成するべくバッファされることなく、できるだけ早く転送される。

他の実施例によれば、マスタが、要求並びに応答のフラッシングを単独で、及び／または同時に開始し得るようにする。このような場合には、（ＡＸＩまたはＤＴＬ）コマンドグループは、異なる種類のフラッシュ（例えば、ＤＴＬにおける２ビットのフラッシュ信号）を指示できるように拡張させなければならない。応答フラッシングのこの指示は、この場合にそれ相応に動作するスレーブＮＩへと転送しなければならない。フラグを用いる場合にも同様なことが言える。

さらに他の実施例によれば、ネットワークオンチップの通信スキームが、メッセージ通過通信スキームに基づくようにする。ここで、メッセージのメッセージヘッダは、フラッシュ情報を含むことができ、これにより、同一のコネクションから前もって送信された全てのメッセージをフラッシュさせる。

さらに他の実施例によれば、ネットワークオンチップの通信スキームを、パケットに基づく通信スキームとし、すなわち、１つのメッセージは１つまたはそれ以上のパケットにて送信され、フラッシュ情報はパケットヘッダ内に含まれるようにする。

上述したスキームは、ＤＴＬやＡＸＩのような、トランザクションに基づくプロトコルにも適用することができる。特に、このスキームでは、ラッパーにインターコネクト用のバースト長を、要求だけでなく応答に対しても、トランザクション内で最適化することができるようにする。要求の例には（認知／非認知の）書込みコマンドとデータや、読取りコマンド、または、テスト兼設定、セマフォコマンド（Ｐ、Ｖ）のようなもっと複雑なコマンドがある。応答の例には、読取りデータ、書込み確認応答、及び、より複雑なコマンドからの応答がある。ラッパーまたはインターコネクトのインターフェースを介してインターコネクトに接続されるインテレクチュアル・プロパティ・モジュールは、インターコネクトに無関係に構築することができる。すなわち、インターコネクトの諸特性の知識はラッパー内にしかないので、これらＩＰモジュールの再利用性を増すことができる。しかしながら、要求に関しては、追加の待ち時間が導入されることになるが、システム全体の効率は向上する。

さらに、マスタ並びにスレーブに関連するネットワークインターフェースにラッパー手段を設けることによって、ネットワークインターフェースを対称的に設計することができるため、これらの再利用性も高まる。

上述したそれぞれの実施例は本発明を制限するものではなく、当業者には、添付の請求項の範囲を逸脱することなく、多くの代替の実施例を設計し得ることに留意されたい。幾つかの手段を列挙している装置についての請求項において、それらの手段の幾つかは同一アイテムのハードウェアによっても実現することができる。所定の手段を互いに異なる従属項にて単に列挙していることは、それらの手段の組合せを有利に用いることができないということを示すものではない。

第１の実施例によるネットワークオンチップの概略図である。 第２の実施例によるネットワークオンチップの概略図である。

Claims (14)

1. インターコネクト手段に接続されている多数の処理モジュールを有する集積回路であって、第１の処理モジュールがトランザクションを用いて第２の処理モジュールと通信する前記集積回路が、
   第１の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第２の処理モジュールからのデータをバッファリングするように前記第２の処理モジュールに関連付けた第１のラッパー手段を具え、バッファされたデータは、前記第１の量のデータがバッファされたときに転送されるようにした、
   ことを特徴とする集積回路。
2. 第２の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第１の処理モジュールからのデータをバッファリングするように前記第１の処理モジュールに関連付けた第２のラッパー手段をさらに具え、バッファされたデータは、前記第２の量のデータがバッファされたときに転送されるようにした、
   ことを特徴とする請求項１に記載の集積回路。
3. 前記第１及び第２のラッパー手段にバッファされたデータ量が前記第１及び第２の量より少なくても、それぞれ第１及び第２のアンバッファ信号または信号のグループの第１及び第２の組合せに応答して、バッファされたデータを転送するように前記第１及び第２のラッパー手段を適合させた、
   ことを特徴とする請求項１または２に記載の集積回路。
4. 前記第１及び第２のラッパー手段にバッファされたデータ量が前記第１及び第２のデータ量より少なくても、それぞれ第１及び第２のアンバッファフラグに従って、バッファされたデータを転送するように前記第１及び第２のラッパー手段を適合させた、
   ことを特徴とする請求項１または２に記載の集積回路。
5. 前記第１及び第２のラッパー手段の少なくとも１つが、前記第１と第２の処理モジュール間の通信の通信特性に従って、バッファすべきデータの最適な第１または第２の量を決定する決定ユニットを具える、
   ことを特徴とする請求項１または２に記載の集積回路。
6. 前記第１及び第２のラッパー手段の少なくとも１つが、前記第１と第２の処理モジュール間の通信の通信特性に従って、前記第１及び第２のラッパー手段のデータを送信する最適な瞬時を決定する決定ユニットを具える、
   ことを特徴とする請求項１または２に記載の集積回路。
7. 前記第１のアンバッファ信号を前記第２の処理モジュールによって起動させ、かつ、前記第２のアンバッファ信号を前記第１の処理モジュールによって起動させるようにした、
   ことを特徴とする請求項３に記載の集積回路。
8. 前記第１のアンバッファフラグの設定を前記第２の処理モジュールによって開始させ、かつ、前記第２の非バッファフラグの設定を前記第１の処理モジュールによって開始させるようにした、
   ことを特徴とする請求項４に記載の集積回路。
9. 前記第１及び／または前記第２のアンバッファ信号を起動させるように前記第１の処理モジュールを適合させた、
   ことを特徴とする請求項３または４に記載の集積回路。
10. 前記第１及び／または前記第２のアンバッファフラグの設定を開始するように前記第１の処理モジュールを適合させた、
    ことを特徴とする請求項４に記載の集積回路。
11. 前記第１及び第２の処理モジュールが、メッセージ伝達通信スキームを用いて互いに通信し、メッセージがメッセージヘッダを含み、
    前記第１及び第２のラッパー手段にバッファされたデータの量が、前記第１及び第２の量より少なくても、前記メッセージヘッダにおける情報に応答して、バッファされたデータを転送するように前記第１及び第２のラッパー手段をそれぞれ適合させた、
    ことを特徴とする請求項１または２に記載の集積回路。
12. 前記第１及び第２の処理モジュールが、パケットに基づく通信スキームを用いて互いに通信し、パケットがパケットヘッダを含み、
    前記第１及び第２のラッパー手段にバッファされたデータの量が、前記第１及び第２の量より少なくても、前記パケットヘッダにおける情報に応答して、バッファされたデータを転送するように前記第１及び第２のラッパー手段をそれぞれ適合させた、
    ことを特徴とする請求項１または２に記載の集積回路。
13. インターコネクト手段に接続される多数の処理モジュールを有する集積回路内でデータをバッファリングする方法であって、第１の処理モジュールがトランザクションを用いて第２の処理モジュールと通信する前記バッファリング方法が、
    第１の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第２の処理モジュールからのデータをバッファリングし、バッファされたデータは、前記第１の量のデータがバッファされたときに転送するステップを含む、
    ことを特徴とするバッファリング方法。
14. インターコネクト手段に接続される多数の処理モジュールを具えるデータ処理システムであって、第１の処理モジュールがトランザクションを用いて第２の処理モジュールと通信する前記データ処理システムが、
    第１の量のデータがバッファされるまで、インターコネクト手段を介して転送すべき前記第２の処理モジュールからのデータをバッファリングするように前記第２の処理モジュールに関連付けた第１のラッパー手段を具え、バッファされたデータは、前記第１の量のデータがバッファされたときに転送されるようにした、
    ことを特徴とするデータ処理システム。

Images