(57)【要約】  本発明の一態様に応じた通信システムは、１つ又は複数の集積回路を備えている。前記１つ又は複数の集積回路は、ローカル集積回路及びリモート集積回路のうちの少なくとも１つを備える。前記ローカル集積回路内に配置された少なくとも１つの送信アプリケーションハードウエアモジュールは、前記送信アプリケーションハードウエアモジュールからのメッセージの送信を制御する送信ロジックを有する。少なくとも１つの受信アプリケーションハードウエアモジュールは、前記ローカル集積回路又はリモート集積回路のうちの少なくとも１つに配置される。送信アプリケーションハードウエアモジュールは、前記受信アプリケーションハードウエアモジュールのアドレス又はそれへのパスの演繹的知識が送信ロジックに構築されることなく、メッセージを受信アプリケーションハードウエアモジュールに送信する。前記ローカル集積回路に配置されたディスパッチロジックは少なくとも１つ又は複数のルーティングを行う。
2010517172.tif 000002
【特許請求の範囲】
【請求項１】
通信システムであって、
ローカル集積回路又は前記ローカル集積回路に対するリモート集積回路のうちの少なくとも１つを備える１つ又は複数の集積回路と、
前記ローカル集積回路に配置され、送信アプリケーションハードウエアモジュールからのメッセージの送信を制御する送信ロジックを有する少なくとも１つの送信アプリケーションハードウエアモジュールと、
前記ローカル集積回路又は前記リモート集積回路のうちの少なくとも１つに配置された少なくとも１つの受信アプリケーションハードウエアモジュールであって、送信アプリケーションハードウエアモジュールは、前記受信アプリケーションハードウエアモジュールのアドレス又はそれへのパスの演繹的知識が送信アプリケーションハードウエアモジュールの送信ロジックに構築されることなく、メッセージを受信アプリケーションハードウエアモジュールに送信する受信アプリケーションハードウエアモジュールと、
前記ローカル集積回路に配置され、
Ａ）前記送信アプリケーションハードウエアモジュールから、前記ローカル集積回路上の１つ又は複数の受信アプリケーションハードウエアモジュールに送信されたメッセージ、又は
Ｂ）前記送信アプリケーションハードウエアモジュールから、リモート集積回路に配置された１つ又は複数の受信アプリケーションハードウエアモジュールへの転送のために送信されたメッセージ
のうちの少なくとも１つ又は複数のルーティングを行うディスパッチロジックと
を備えることを特徴とする通信システム。
【請求項２】
請求項１に記載の通信システムにおいて、１つ又は複数の受信アプリケーションソフトウエアプログラムを実行する前記ローカル集積回路に対してリモートな１つ又は複数のプロセッサを更に含み、前記ローカル集積回路内の送信アプリケーションハードウエアモジュールは、前記受信アプリケーションソフトウエアプログラムのアドレス又はそれへのパスの演繹的知識が送信アプリケーションハードウエアモジュールの送信ロジックに構築されることなく、メッセージをリモートプロセッサで実行される受信アプリケーションソフトウエアプログラムに送信し、前記ディスパッチロジックは伝送のために前記送信アプリケーションハードウエアモジュールから前記受信アプリケーションソフトウエアプログラムに送信されたメッセージのうちの少なくとも１つ又は複数のルーティングを行うことを特徴とする通信システム。
【請求項３】
通信システムであって、
１つ又は複数の集積回路と、
１つ又は複数のアプリケーションソフトウエアプログラムを実行する前記１つ又は複数の集積回路に対してリモートな１つ又は複数のプロセッサと、
送信アプリケーションハードウエアモジュールからのメッセージの送信を制御する送信ロジックを有する集積回路内の少なくとも１つの送信アプリケーションハードウエアモジュールであって、前記送信アプリケーションハードウエアモジュールは、前記受信アプリケーションソフトウエアプログラムのアドレス又はそれへのパスの演繹的知識が前記送信アプリケーションハードウエアモジュールの送信ロジックに構築されることなく、メッセージをリモートプロセッサで実行される受信アプリケーションソフトウエアに送信する、少なくとも１つの送信アプリケーションハードウエアモジュールと
前記集積回路に配置され、前記受信アプリケーションソフトウエアプログラムへの伝送のために前記送信アプリケーションハードウエアモジュールから送信されたメッセージの少なくとも１つ又は複数のルーティングを行うディスパッチロジックと
を備えることを特徴とする通信システム。
【請求項４】
請求項３に記載の通信システムにおいて、前記ディスパッチロジックは、
Ａ）同一の集積回路上の１つ又は複数の受信アプリケーションハードウエアモジュールに、前記送信アプリケーションハードウエアモジュールから送信されたメッセージ、又は
Ｂ）リモート集積回路に配置された１つ又は複数の受信アプリケーションハードウエアモジュールへの伝送のために、前記送信アプリケーションハードウエアモジュールから送信されたメッセージ
のうちの少なくとも１つ又は複数のルーティングを行うことを特徴とする通信システム。
【請求項５】
複数のミドルウエア使用可能なアプリケーションブロックを備える集積回路であって、
各ミドルウエア使用可能なアプリケーションブロックは、
メッセージを処理する１つ又は複数のアプリケーション特有のインターフェースインディケータを用いる１つ又は複数のアプリケーションオブジェクトを含む１つ又は複数のアプリケーションモジュールと、
１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを送信する送信オペレーションアダプタと、
着信オペレーションネーム及びオブジェクトインディケータを受信する受信オペレーションアダプタと
を備え、
ミドルウエア使用可能なアプリケーションブロックの各受信オペレーションアダプタは、前記オブジェクトインディケータによって特定される対応するアプリケーションモジュールのアプリケーションオブジェクトによる使用のために、着信オブジェクトインディケータに基づいた少なくとも１つの着信オペレーションネームを、対応するアプリケーション特有のオペレーションインディケータに変換し、ミドルウエア使用可能なアプリケーションブロックの各送信オペレーションアダプタは、アプリケーションモジュールのアプリケーションオブジェクトによって特定される少なくとも１つのアプリケーション特有のオペレーションインディケータを、対応する発信オペレーションネームに変換し、１つのアプリケーションブロックにおける送信オペレーションアダプタからのオペレーションネームは、前記送信オペレーションアダプタからのオブジェクトインディケータに基づいて別のアプリケーションブロックの受信オペレーションアダプタに搬送されることを特徴とする集積回路。
【請求項６】
請求項５に記載の通信システムにおいて、前記複数のミドルウエア使用可能なアプリケーションブロックから任意のオペレーションネーム、任意のオブジェクトインディケータ、及び他のデータを各々含む１つ又は複数のメッセージを搬送し、前記複数のミドルウエア使用可能なアプリケーションブロックに１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを移動させるメッセージルータを更に含むことを特徴とする集積回路。
【請求項７】
請求項６に記載の通信システムにおいて、定義されたプロトコルに応じて前記集積回路外部の通信伝送手段を介してオブジェクトサービスリクエスト及びリプライメッセージを仲介するメッセージルータに連結されたディスパッチモジュールを更に含み、前記オブジェクトサービスリクエストメッセージは、１つ又は複数の着信オペレーションネーム及びオブジェクトインディケータを含む着信データメッセージと、１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを含む発信データメッセージとを備え、前記オブジェクトサービスリプライメッセージは、オブジェクトサービスリクエストコンテキスト情報を含む着信データメッセージと、オブジェクトサービスリクエストコンテキスト情報を含む発信データメッセージとを備えることを特徴とする集積回路。
【請求項８】
請求項６に記載の集積回路において、前記定義されたプロトコルは、ＯＲＢプロトコルを備えることを特徴とする集積回路。
【請求項９】
請求項５に記載の集積回路において、各受信オペレーションアダプタは、１つ又は複数の着信オペレーションネームを１つ又は複数のアプリケーション特有のインターフェース値にマッピングするルックアップテーブルを備えることを特徴とする集積回路。
【請求項１０】
請求項５に記載の集積回路において、各送信オペレーションアダプタは、１つ又は複数のアプリケーション特有のインターフェース値を１つ又は複数の発信オペレーションネームにマッピングするルックアップテーブルを備えることを特徴とする集積回路。
【請求項１１】
請求項５に記載の集積回路において、前記複数のアプリケーションブロックは、集積回路技術に応じて回路に集積化され、ＦＰＧＡ、ＰＬＤ、又はＡＳＩＣのうちの少なくとも１つを備えることを特徴とする集積回路。
【請求項１２】
請求項７に記載の集積回路において、着信データパケットは、着信オペレーションネームをサービスのためのリクエストと関連付けることを特徴とする集積回路。
【請求項１３】
請求項７に記載の集積回路において、発信データパケットは、発信オペレーションネームをサービスのためのリクエスト又はサービスのためのリクエストへのリプライと関連付けることを特徴とする集積回路。
【請求項１４】
請求項６に記載の集積回路において、前記メッセージルータは、スイッチ又はバスのうちの少なくとも１つを備えることを特徴とする集積回路。
【請求項１５】
請求項１４に記載の集積回路において、前記スイッチは、部分的に接続したクロスバースイッチ、完全に接続したクロスバースイッチ、バニヤンスイッチ、又はメモリスイッチのうちの少なくとも１つを備えることを特徴とする集積回路。
【請求項１６】
請求項６に記載の集積回路において、前記メッセージルータは、複数のアプリケーションモジュールを直列に互いに連結することを特徴とする集積回路。
【請求項１７】
請求項１６に記載の集積回路において、前記ルータパイプライン着信及び発信リクエストは、複数の直列連結のアプリケーションモジュールを介して前記複数のオペレーションアダプタにパイプライン伝送されることを特徴とする集積回路。
【請求項１８】
請求項８に記載の集積回路において、前記ＯＲＢプロトコルは、一般ＯＲＢ間プロトコル（ＧＩＯＰ）を備えることを特徴とする集積回路。
【請求項１９】
再構成可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）であって、
各々が１つ又は複数のアプリケーション特有のインターフェースインディケータを使用する１つ又は複数のアプリケーションオブジェクトを備える複数のミドルウエア使用可能なアプリケーションブロックであって、前記１つ又は複数のアプリケーション特有のインターフェースインディケータはＦＰＧＡ上の各アプリケーションブロックを実現するハードウエア定義言語によって説明され、１つのアプリケーションブロックと関連したアプリケーション特有のインディケータは任意の他のアプリケーションブロックを実現するハードウエア定義言語のいかなる説明も変更することなく動的に変更される、複数のミドルウエア使用可能なアプリケーションブロックを備えることを特徴とする再構成可能なＦＰＧＡ。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願）
本出願は２００８年１月２５日に出願された米国特許出願（割り当てられるべき、出願番号）及び（２００７年１月２６日に出願された）米国仮出願Ｎｏ．６０／８９７，４９７の優先権を主張し、それらの全ての内容が参照により本明細書に組み入れられる。
本発明は通信ネットワーク内にディジタル集積回路装置を実装することに一般的に関し、特にディジタル集積回路装置にＯＲＢ（Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ：オブジェクトリクエストブローカー）モジュールを実装して分散システム内で他のコンピューティング装置との通信を可能にすることに関する。
【背景技術】
【０００２】
分散コンピューティングは並列処理の１種である。その並列処理においては、アプリケーションの異なるコンポーネント、すなわちソフトウエアプログラム又はハードウエアモジュール処理ロジックが、ネットワークで互いに通信する２以上のコンピューティング装置上で同時に動作する。アプリケーションコンポーネントは異なるコンピューティング装置上で動作する別のコンポーネントとの呼び出し、通信又はコールをなし、実行されるべき特定の機能又は戻されるべき特定のデータを要求することができる。これらのアプリケーションコンポーネントは異なるコンピューティング環境、例えば、異なるハードウエアプラットフォーム、オペレーティングシステム、及びプログラミング言語で動作することができる。例えば、分散アプリケーション内の２つのソフトウエアプログラムを、異なるプログラミング言語で書き、異なるプロセッサ上で動作する異なるオペレーティングシステムで実行することができる。２つのコンポーネントが異なりかつ非コンパティブルなコンピューティング環境で設計され、動作されるならば、そのような１つのコンポーネントから別のコンポーネントへ直接コールを実現することは開発者には度々難しいことである。従って、これらのアプリケーションコンポーネントが互いに相互運用及び相互作用を行うことを可能にする共通の通信媒体が存在しなければならない。
【０００３】
分散アプリケーションソフトウエアを処理する従来の分散システムにおいて、ＯＢＲ（Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ）と称されるミドルウエアコンポーネントは、異なるコンピューティング環境内で動作するソフトウエアプログラムがネットワーク上で互いに通信できるようにするために用いられる。ＯＲＢはデータ構造を１つのコンピューティングプラットフォームから、ネットワーク上で送信され別のコンピューティングプラットフォームによって受信することができるバイト列に変換する。受信コンピューティングプラットフォームでは、ＯＲＢは、このバイト列を受信コンピューティングプラットフォームによって理解されるデータ構造に変換する。また、ＯＲＢは、分散システム内で動作するプログラムに透過性を与え、それによりＯＲＢ内のコンピューティングプラットフォーム上のプログラムは、プログラムの位置、プログラムが実行されるプラットフォームのタイプ、又はプログラムを実行するオペレーティングシステムを知る必要なしに、リモートコンピューティングプラットフォーム上の別のプログラムと通信することができる。
【０００４】
ＯＲＢは、ＧＩＯＰ（Ｇｅｎｅｒａｌ  Ｉｎｔｅｒ−ＯＲＢ  Ｐｒｏｔｏｃｏｌ）と称される抽象トプロトコルを介して互いに通信する。ＧＩＯＰは、ネットワークを介して伝送されるデータのフォーマット及びメッセージのシンタックスを定義する。ＧＩＯＰと関連した標準規格はＯＭＧ（Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｇｒｏｕｐ）によって保持される。ＯＭＧはまた、ＣＯＲＢＡ（Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｒｅｑｕｅｓｔ  Ｂｒｏｋｅｒ  Ａｒｃｈｉｔｅｃｔｕｒａｌ）と称される分散システムのアーキテクチャモデルも定義する。分散システム内のアプリケーションコンポーネント毎に、ＣＯＲＢＡはロジック内側の能力及びそれの呼び出し方についての情報を含むバンドルを作成する。ＣＯＲＢＡはＩＤＬ（Ｉｎｔｅｒｆａｃｅ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ）を使用してオブジェクトがその外部世界に提示するインターフェースを記述する。ＩＤＬは言語的に中立な形式でインターフェースを記述し、それにより共通のプログラミング言語又は編集プラットフォームを共有しないソフトウエアコンポーネントが互いに通信することができる。また、ＣＯＲＢＡは、ＩＤＬと通信するためにＡｄａ、Ｃ、Ｃ＋＋、又はＪａｖａ（登録商標）等の異なるプログラミング言語のためのマッピングを定義する。
【０００５】
ＣＯＲＢＡシステムの単純化モデルは図１を参照して説明される。この図において、ネットワーク１１０はクライアントコンピュータ１２０からサーバコンピュータ１３０にリクエストを供給する。ＯＢＲ収納部（図示せず）は、ネットワーク１１０上の全てのコンピュータで実行可能なオブジェクトＸ等の全てのオブジェクトのリストを記憶する。クライアントＯＲＢ１１０はＯＢＲ収納部にアクセスし、ＯＲＢを介して実行可能なオブジェクトＸ等の全てのオブジェクトについての情報をクライアントコンピュータ１２０に与えることができる。この例において、オブジェクトＸはメソッド「ｆｉｒｅ」を含む。オブジェクトＸはサーバコンピュータ１３０に記憶され、サーバコンピュータ１３０によって実行されるが、そのコードはクライアントコンピュータ１２０上のプログラム１２２に完全に透過的である。プログラム１２２は、サーバコンピュータ１３０で動作するプログラム１３２又はオペレーティングシステムによって用いられるプログラミング言語を知る必要がない。従って、プログラム１２２の透視から、任意のローカルオブジェクトを呼ぶことと同じにようにオブジェクトＸに対してコールをなす。
【０００６】
プログラム１２２はオブジェクトＸを呼び出してこのリクエストをクライアントＯＲＢ１２４に送ることによりメソッド「ｆｉｒｅ」を実行することができる。クライアントＯＲＢ１２４は、コンピュータ１２０にオブジェクトＸ用のインターフェースを与える。クライアントＯＲＢ１２４は、ＩＤＬスタブ１２６を用いる。ＩＤＬスタブ１２６は、ＩＤＬで予めコンパイルされ、クライアントコンピュータ１２０がどのようにサーバコンピュータ１３０上のオブジェクトＸを呼び出すかを定義する。クライアントコンピュータ１２０がネットワーク１１０上の別のコンピュータで使用するインターフェース毎にＩＤＬスタブが存在する。クライアントＯＲＢ１２４は、マーシャリングを行うためのコードを含み、それはオペレーション及びそのパラメータを、ネットワーク１１０を介してサーバコンピュータ１３０に送信することができるフラットなＧＩＯＰメッセージフォーマットに符号化することを意味する。
【０００７】
サーバコンピュータ１３０では、ＩＤＬスケルトン１３４がこのサーバによってエクスポートされる各サービスに静的インターフェースを与える。これらのスケルトンは、クライアントコンピュータ１２０のスタブのようにＩＤＬコンパイラを用いて作成される。これらのスケルトンを用いて、サーバＯＲＢ１３４は、フラットなＧＩＯＰメッセージをサーバコンピュータ１３０内のオブジェクトＸによって理解されるオペレーション及びパラメータに変換する。その後、オブジェクトＸは、所望のオペレーションを実行し、必要ならば、リクエストしたデータをＯＲＢを介してクライアントコンピュータ１２０に戻す。
【０００８】
従来のＯＲＢモデルは何年もの間、分散ソフトウエアシステムにおいて使用されている。近年、ＯＲＢソフトウエアは、マイクロコントローラ又はディジタルシグナルプロセッサ（ＤＳＰ）で動作できるように開発されている。しかしながら、アプリケーションは、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ、アプリケーションの特定の目的のためにカスタマイズされた集積回路）のようなハードウエアコンポーネントとして直接開発されている。或いは、固定した機能を実装せず代わりに所望の機能を行うために構成することができる多数のロジックゲート及び接続リソースから成るプログラム可能なロジックデバイス内にアプリケーションを実装することができる。
【０００９】
今日、使用されている一般的なプログラム可能な半導体デバイスはＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）である。ＦＰＧＡは、プログラム可能なロジックコンポーネント及びプログラム可能なインターコネクトを含むデバイスである。ＦＰＧＡのロジック及びインターコネクトコンポーネントを、所望の機能を行うためにロジック設計者によってプログラムすることができる。ＦＰＧＡはそのＡＳＩＣカウンターパートより遅く、より電力を消費し、非常に複雑なアプリケーションには適さない可能性がある。しかしながら、ＦＰＧＡは、ＡＳＩＣを越えるある利点を備え、その利点は、任意に再プログラムする能力、市場へのより短い時間、バグを修正する能力、及び低いＮＲＥ（非反復エンジニアリング）コストを含む。
【００１０】
ＡＳＩＣ、ＰＬＤ及びＦＰＧＡ等のハードウエアコンポーネントが分散システムに有効に組み入れられるためには、それらにソフトウエアリクエストをハードウエアコンポーネントによって理解される信号に変換することができるＯＲＢインターフェースが備えられる必要がある。更に、ハードウエアは、ソフトウエアコンポーネントによって理解されるリクエストを発生することができなければならない。ハードウエアデバイスを分散システムに接続する従来方法は、ハードウエアデバイスとソフトウエア実装ＯＲＢとの間のインターフェースを提供するＧＰＰ（Ｇｅｎｅｒａｌ  Ｐｕｒｐｏｓｅ  Ｐｒｏｃｅｓｓｏｒ）又はＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）上で動作するカスタムプロキシを介する。このアプローチは、ＧＰＰプロキシにおいてパフォーマンス障害を引き起こす重大な不利益を有する。
【００１１】
或いは、ハードウエア設計者は、ハードウエアデバイス内にカスタムアプリケーション特有のＯＲＢモジュールを組み入れることができる。しかしながら、この方法は、ハードウエア設計者にオブジェクト指向プログラミングと共にＣＯＲＢＡを理解することを要求する。それは多くのハードウエア設計者が精通していない領域である。また、特定のアプリケーションブロックのためにカスタムデザインされたＯＲＢモジュールは、コードマッピングが特定のアプリケーション用のモジュール内に組み込まれなければならないので、容易に再利用することができない可能性がある。
【００１２】
特許文献１は、再構成可能な通信アーキテクチャ（Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ：ＲＣＡ）無線システム内におけるＦＰＧＡにＯＲＢを実装することを記載している。しかしながら、この公報はどのようにＯＲＢが実装されるのか開示していない。
【００１３】
プリズムテック社（ＰｒｉｓｍＴｅｃｈ  Ｌｔｄ．）によって開発された集積回路ＯＲＢ（ＩＣＯ）は、ＦＰＧＡ上でマッピング可能なポータブルＶＨＤＬに書き込まれた組み込みＯＲＢを提供する。ＩＣＯはＩＣＯエンジン、ＩＤＬ−ＶＨＤＬジェネレータ、スペクトラモデリングツール（Ｓｐｅｃｔｒａ  Ｍｏｄｅｌｉｎｇ  Ｔｏｏｌ）、及びＳＣＡ（Ｓｏｆｔｗａｒｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）コンポーネントから成る。ＳＣＡはハードウエア及びソフトウエアエレメントがどのようにソフトウエア無線（ＳＤＲ）内で通信するのか定義するアーキテクチャフレームワークである。ＩＣＯエンジンは、ＣＯＲＢＡによって用いられる転送構文（ｔｒａｎｓｆｅｒ  ｓｙｎｔａｘ）を実行することに関与する。このエンジンは、入ってくるＧＩＯＰメッセージを分解してこのメッセージからヘッダとデータフィールドとを抽出する。入ってくるメッセージのために、このエンジンはオペレーションネーム多重分離を行って、ＧＩＯＰメッセージ内のデータがどのオブジェクトに転送されるか判定する。メッセージデータは次いで、このエンジンによって抽出され、適切なＦＰＧＡロジックブロックに転送される。リプライが要求された場合、エンジンはオブジェクトに対する読み込み動作を行ってリプライのための必要データを得る。また、それはヘッダフィールドを投入し、ＧＩＯＰ標準規格に従ってリプライメッセージをビルドする。
【００１４】
ＩＣＯは、ＦＰＧＡアプリケーションがＯＲＢを介して通信することを可能にするが、ハードウエア実装アプリケーションが更に着実な方法で互いに通信することを可能にするより良い機構を備える必要がある。
【００１５】
更に、ＩＣＯはＦＰＧＡ開発者のために利点を提供する。ＩＣＯにおいて、メッセージから適切なヘッダを抽出し、適切なオブジェクトに対してオペレーションネーム多重分離及びデータルーティングを行うために、ＩＣＯエンジンは各アプリケーションモジュールの位置及び機能について知る必要がある。ＩＣＯ  ＩＤＬ−ＶＨＤＬコードジェネレータは、ＩＣＯエンジンによって必要とされる構成パラメータを生成する。また、このコードジェネレータは、これらのパラメータを、ＩＣＯインターフェース及び内部記憶エレメントの物理的態様を構成するＶＨＤＬパッケージファイルに加える。従って、ＩＣＯのＯＲＢコア用のＶＨＤＬコードの一部は、コードジェネレータによってコンパイル時に生成される。結果として、ＦＰＧＡの設計者がＦＰＧＡ内でアプリケーションブロックの機能性を再構成することを望む場合、ＯＲＢモジュール全体を再構成及び再生成しなければならない。これは、ＯＲＢ及び他のＦＰＧＡモジュールの動作に影響することなく、ＦＰＧＡを部分的に再構成する能力を排除するという点において多数のＦＰＧＡ設計者に問題となる可能性がある。
【先行技術文献】
【特許文献】
【００１６】
【特許文献１】米国特許出願第２００５／０１０８３８２号明細書
【発明の概要】
【課題を解決するための手段】
【００１７】
簡潔には、本発明の一態様に応じた通信システムは、１つ又は複数の集積回路を備えている。この１つ又は複数の集積回路路は、ローカル集積回路及びリモート集積回路のうちの少なくとも１つを備えている。ローカル集積回路に配置された少なくとも１つの送信アプリケーションハードウエアモジュールは、この送信アプリケーションハードウエアモジュールからのメッセージの送信を制御する送信ロジックを有する。少なくとも１つの受信アプリケーションハードウエアモジュールは、ローカル集積回路及びリモート集積回路のうちの少なくとも１つに配置される。送信アプリケーションハードウエアモジュールは、上述の受信アプリケーションハードウエアモジュールのアドレス又はそれへのパスの演繹的知識が送信ロジックに構築されることなく、メッセージを受信アプリケーションハードウエアモジュールに送信する。ディスパッチロジックは、Ａ）及びＢ）の少なくとも１つ又は複数のメッセージをルーティングするローカル集積回路に配置される。
【００１８】
Ａ）送信アプリケーションハードウエアモジュールからローカル集積回路上の１つ又は複数の受信アプリケーションハードウエアモジュールに送信されたメッセージ、又は
【００１９】
Ｂ）送信アプリケーションハードウエアモジュールから、リモート集積回路に配置された１つ又は複数の受信アプリケーションハードウエアモジュールへの転送のために送信されたメッセージ。
【００２０】
本発明のこの態様の更なる詳細な特徴のいくつかによれば、通信システムは、１つ又は複数の受信アプリケーションソフトウエアプログラムが動作するローカル集積回路に対してリモート状態となる１つ又は複数のプロセッサを更に含んでいる。ローカル集積回路の送信アプリケーションハードウエアモジュールは、上述の受信アプリケーションソフトウエアプログラムのアドレス又はそれへのパスの演繹的知識が送信ロジックに構築されることなく、リモートプロセッサで実行される受信アプリケーションソフトウエアプログラムにメッセージを送信する。ディスパッチロジックは、転送のために送信アプリケーションハードウエアモジュールから受信アプリケーションソフトウエアプログラムに送信された少なくとも１つ又は複数のメッセージをルーティングする。
【００２１】
本発明の他の態様によれば、集積回路は、複数のミドルウエア使用可能なアプリケーションブロックを備えている。各ミドルウエア使用可能なアプリケーションブロックは、１つ又は複数のアプリケーションオブジェクトを有し、メッセージを処理するために１つ又は複数のアプリケーション特定インターフェースインディケータを使用する、１つ又は複数のアプリケーションモジュールを備えている。各ミドルウエアアプリケーションブロックと関連した送信オペレーションアダプタは、１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを送信し、各ミドルウエアアプリケーションブロックと関連した受信オペレーションアダプタは、着信オペレーションネーム及びオブジェクトインディケータを受信する。ミドルウエア使用可能なアプリケーションブロックの各受信オペレーションアダプタは、着信オブジェクトインディケータによって特定される対応するアプリケーションモジュールのアプリケーションオブジェクトによる使用のために、着信オブジェクトインディケートに基づいて少なくとも１つの着信オペレーションネームを、対応するアプリケーション特定オペレーションインディケータに変換する。ミドルウエア使用可能なアプリケーションブロックの各送信オペレーションアダプタは、対応するアプリケーションモジュールのアプリケーションオブジェクトによって特定される少なくとも１つのアプリケーション特定オペレーションインディケータを、対応する発信オペレーションネームに変換する。１つのアプリケーションブロックにおける送信オペレーションアダプタからのオペレーションネームは、上述の送信オペレーションアダプタからのオブジェクトインディケータに基づいて別のアプリケーションブロックの受信オペレーションアダプタに伝えられる。本発明のかかる態様は、任意の他のアプリケーションブロックをはめ込む（ｉｍｐａｃｔｉｏｎ）ことなく、各アプリケーションブロックを再構成することができるように、アプリケーションブロックを実装するＦＰＧＡの部分的な再構成を可能にする。
【００２２】
本発明のこの態様の更なる詳細な特徴のいくつかによれば、メッセージルータは、複数のミドルウエア使用可能なアプリケーションブロックから任意のオペレーションネーム、任意のオブジェクトインディケータ、及び他のデータを各々含む１つ又は複数のメッセージを搬送し、複数のミドルウエア使用可能なアプリケーションブロックに１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを指定する。ディスパッチモジュールは、メッセージルータにつながれ、メッセージルータは定義されたプロトコルに応じて集積回路外部の通信伝送手段を介してオブジェクトサービスリクエスト及びリプライメッセージを仲介する。オブジェクトサービスリクエストメッセージは、１つ又は複数の着信オペレーションネーム及びオブジェクトインディケータを含む着信データメッセージと、１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを含む発信データメッセージとを備えている。オブジェクトサービスリプライメッセージは、オブジェクトサービスリクエストコンテキスト情報を含む着信データメッセージと、オブジェクトサービスリクエストコンテキスト情報を含む発信データメッセージとを備えている。ルータは、伝送手段を介した通信のためにアプリケーションモジュールから指定された発信オペレーションネームを、プロトコルに応じて伝送されるべきディスパッチモジュールに適用する。
【００２３】
本発明の更に別の態様によれば、再構成可能なＦＰＧＡは、複数のミドルウエア使用可能なアプリケーションブロックを備えている。各ミドルウエア使用可能なアプリケーションブロックは、メッセージを処理するための１つ又は複数のアプリケーション特定インターフェースインディケータを用いる１つ又は複数のアプリケーションオブジェクトを含む１つ又は複数のアプリケーションモジュールを備えている。別のアプリケーションブロックの別のアプリケーションモジュールと関連した１つ又は複数のアプリケーション特定インターフェースインディケータを維持する間に、１つのアプリケーションブロックのアプリケーションモジュールと関連した１つ又は複数のアプリケーション特定インターフェースインディケータが再構成される。
【図面の簡単な説明】
【００２４】
【図１】ネットワーク内でクライアントコンピュータをサーバコンピュータに接続する従来のＯＲＢモジュールを図示する。
【図２（ａ）】ハードウエア実装アプリケーションモジュールから送信されたメッセージの透過的な通信のためのブロック図である。
【図２（ｂ）】クロスバースイッチを用いる本発明の実施形態を図示する。
【図３】内部バスを用いる本発明の実施形態を図示する。
【図４】ダイレクトルーティングを用いる本発明の実施形態を図示する。
【図５】ＯＲＢ及び受信オペレーションアダプタを介して処理される着信リクエストメッセージの例示的なフォーマットを図示する。
【図６】送信オペレーションアダプタ及びＯＲＢを介して処理される発信リクエストメッセージの例示的なフォーマットを図示する。
【図７】送信オペレーションアダプタ及びＯＲＢを介して処理されるリプライメッセージの例示的なフォーマットを図示する。
【図８（ａ）】図６及び図７に示されたＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬ及びＲＥＰＬＹ＿ＣＯＮＴＲＯＬの例示的なフォーマットを図示する。
【図８（ｂ）】図６及び図７に示されたＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬ及びＲＥＰＬＹ＿ＣＯＮＴＲＯＬの例示的なフォーマットを図示する。
【図９】本願の実施形態に応じてＯＲＢを有するＦＰＧＡを実装する方法のフローチャートを図示する。
【図１０】本発明の実施形態に応じてＯＲＢを有するＦＰＧＡの例を図示する。
【発明を実施するための形態】
【００２５】
本発明の実施形態は図面と関連して開示される。本発明の実施形態はＦＰＧＡについて図示され、説明されるが、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）等の任意の集積回路、又は半導体以外の技術に基づいたコンピューティングプラットフォーム（例えば、オプティカルコンピューティング）において本発明を利用できることは、理解されなければならない。また、本発明の実施形態は、ＣＯＲＢＡ標準規格を実現するＯＲＢシステムとしてディスパッチャを説明しているが、他の標準規格を実現する通信ミドルウエアシステム及びディスパッチャを本発明の方法及びシステムで使用できることも、理解されなければならない。
【００２６】
本発明の１つの態様は、メッセージを送信、さもなければ伝送する１つ又は複数のハードウエア実装アプリケーションモジュールと、その送信、さもなければ伝送されたメッセージを受信する１つ又は複数のハードウエア実装ハードウエアモジュール又はソフトウエア実装アプリケーションプログラムとの間でメッセージを透過的に伝送する通信システムに関している。
【００２７】
図２（ａ）は、本発明のかかる態様に応じて、ローカル集積回路上の送信アプリケーションハードウエアモジュールと、受信アプリケーションハードウエアモジュール又は受信アプリケーションソフトウエアプログラムとの間でのメッセージングを提供するシステムを示している。メッセージングの透過性は、受信アプリケーションハードウエアモジュール又は受信アプリケーションソフトウエアプログラムにメッセージを送信する送信アプリケーションハードウエアモジュールによって与えられ、受信アプリケーションハードウエアモジュール又はアプリケーションソフトウエアプログラムのアドレス又はそれへのパスの演繹的知識がそのようなハードウエアモジュールの送信ロジックに構築されることなく与えられる。言い換えると、送信ロジックは、受信アプリケーションハードウエアモジュール又はアプリケーションソフトウエアプログラムのアドレス又はそれへのパスのいかなる知識もなしに構築される。それにより、初期的に構築されるとき、受信アプリケーションハードウエアモジュール又はアプリケーションソフトウエアプログラムのアドレス又はそれへのパスは送信ロジックには組み込まれていない。
【００２８】
一実施形態においては、通信システムは、インターチップ、すなわち、集積回路内の１つのアプリケーションハードウエアモジュールと別のアプリケーションハードウエアモジュールとの間の通信透過性を提供する。この実施形態の元では、通信透過性は、両方が同じローカル集積回路に配置された送信アプリケーションハードウエアモジュールと受信アプリケーションハードウエアモジュールとの間にある。また、本発明のシステムは、ローカル集積回路内の送信アプリケーションハードウエアモジュールと、リモート集積回路内の受信アプリケーションハードウエアモジュールとの間のイントラチップ通信透過性も提供する。更に別の実施形態においては、本発明のシステムは、ローカル集積回路上の送信アプリケーションハードウエアモジュールと、１つ又は複数のリモートプロセッサ、例えば、クライアントステーション又は通信ノード上で実行される受信アプリケーションソフトウエアプログラムとの間のメッセージング透過性を提供する。それにも係わらず、ローカル集積回路上の送信アプリケーションハードウエアモジュールの送信ロジックは、受信アプリケーションハードウエアモジュール又は受信アプリケーションソフトウエアプログラムのアドレス又はそれへのパスの演繹的知識を有しておらず、メッセージを透過的に伝える。
【００２９】
本発明の通信システムにおいて、ＯＲＢプロトコルに準拠したハードウエア実装ミドルウエア等のハードウエア実装ディスパッチモジュールは、メッセージの通信を仲介する。ディスパッチロジックは、ローカル集積回路上の送信アプリケーションハードウエアモジュールから、その同じローカル集積回路上の１つ又は複数の受信アプリケーションハードウエアモジュールに送信又は伝送されたメッセージの少なくとも１つ又は複数をルーティングする集積回路に配置される。或いは、ディスパッチロジックは、転送のためにローカル集積回路上の送信アプリケーションハードウエアモジュールから、リモート集積回路に配置された受信アプリケーションハードウエアモジュール、又はリモートプロセッサによって実行されるアプリケーションソフトウエアプログラムのいずれかに伝送されたメッセージをルーティングする。
【００３０】
図２（ｂ）を参照すると、本発明によるＦＰＧＡシステムの実施形態が示されている。ＦＰＧＡは、各々が対応するアプリケーションモジュールを有する、複数のアプリケーションブロック２４０ａ，２４０ｂ等を備えている。各アプリケーションモジュールは、対応するインターフェース及びオペレーションインディケータを用いて特定の機能をなす１つ又は複数のアプリケーションオブジェクトを備えている。オペレーションインディケータは、メッセージに含まれる数値又は文字列であってよい。図示されるように、例えば、アプリケーションブロック２４０ａは、アプリケーションモジュール２４２、受信オペレーションアダプタ（ＲＯＡ）２５０、及び送信オペレーションアダプタ（ＴＯＡ）２５２を含む。ＲＯＡ２５０及びＴＯＡ２５２は、アプリケーションモジュール２４２とのインターフェースをなし、アプリケーションモジュール２４２と、着信及び発信メッセージのルーティングを行ったメッセージルータとの間のブリッジとして作用する。図２（ｂ）の例示的なＦＰＧＡにおいては、メッセージルータは、アプリケーションブロック２４０ａ、２４０ｂ等の間で、ＦＰＧＡ内でメッセージをローカルに搬送する、クロスバースイッチ２３０を備えている。また、ＦＰＧＡは、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２を備えるＯＲＢを介する伝送手段でＦＰＧＡ外部のリモート宛先にメッセージを搬送する。ＯＲＢ受信部２２０及びＯＲＢ送信部２２２は、それぞれ、受信トランスポートアダプタ（ＲＴＡ）２１０及び送信トランスポートアダプタ（ＴＴＡ）２１２を介して外部ネットワークに接続されている。受信トランスポートアダプタ（ＲＴＡ）２１０及び送信トランスポートアダプタ（ＴＴＡ）２１２は、ＰＣＩポート、ＵＳＢポート、イーサネット（登録商標）ポート、シリアルポート等のＯＲＢの内外でデータを伝送することができる任意のタイプの通信ポートを含むことができる。着信メッセージはＲＴＡ２１０によって受信され、ＯＲＢ受信部２２０に渡される。発信メッセージはＯＲＢ送信部２２２からＴＴＡ２１２を介して外部世界に送信される。複数の外部通信ポートがＦＰＧＡで利用できるならば、複数の相互動作可能なＯＲＢをそれらに関連したＲＴＡ及びＴＴＡモジュールと共にインスタンス化することができる。
【００３１】
ＦＰＧＡ２００におけるＯＲＢ受信部２２０及びＯＲＢ送信部２２２の実装はよく知られており、ＦＰＧＡ２００内の設計者が望むどこにでも配置することができる。ＲＴＡ２１０及びＴＴＡ２１２は、アプリケーションブロック２４０ａ，２４０ｂ等の要件に応じてＦＰＧＡ設計者によって典型的にはカスタム設計される。しかしながら、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２はＲＴＡ２１０及びＴＴＡ２１２から独立し分離しているので、ＲＴＡ２１０及びＴＴＡ２１２のために用いられるポート設計の種類は、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２モジュールに影響を与えない。
【００３２】
ＯＲＢ送信部２２２は、前に図１を参照して説明したクライアントＯＲＢ１２４及びＩＤＬスタブ１２６と同様の機能で機能する。同様に、ＯＲＢ受信部２２０はサーバＯＲＢ１３４及びＩＤＬスケルトン１３６と同様の機能で機能する。ＦＰＧＡ２００内のアプリケーションモジュールによってリクエスト又はリプライが生成されたとき、ＯＲＢ送信部２２２は、ＴＴＡ２１２を介してリモート宛先ＯＲＢ、例えば、図１のリモート集積回路内のディスパッチャに送信されるＧＩＯＰメッセージを作成する。
【００３３】
外部又はその他のリモートＯＲＢからリクエスト、例えば、図１のリモート集積回路内のディスパッチャからのリクエストがＦＰＧＡ２００に送信されたとき、ＯＲＢ受信部２２０は、ＧＩＯＰパケットを、ＦＰＧＡ内で容易に処理することが可能なコンパクトな内部表現に変換する。以下で更に説明されるように、ＦＰＧＡ内の全てアプリケーションブロック２４０ａ，２４０ｂ等はメッセージを処理する。その処理は、メッセージがＦＰＧＡ内の他のアプリケーションブロックからローカル的に発生したか、又はＦＰＧＡの外部からリモート的に発生したかに係わらず同じ方法で行われる。コンパクトな内部表現は、文字列をベースにした「オペレーションネーム」を含み、それはＦＰＧＡ２００上のアプリケーションモジュール２４２が実行するために必要なパラメータと共に要求されるオペレーションである。
【００３４】
また、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２に加えて、ＯＲＢ機能は、クロスバースイッチ２３０を含むことができる。或いは、設計者は所有のクロスバースイッチ２３０を実装することを選択することができる。クロスバースイッチ２３０は、ＯＢＲ受信部２２０及びＯＢＲ送信部２２２を、ＯＲＢが通信する必要がある全てのアプリケーションブロック２４０ａ，２４０ｂ等に接続することができる限り、ＦＰＧＡ２００の任意の部分に配置することができる。図２の例示的な実施形態は、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２を複数のアプリケーションブロック２４０ａ，２４０ｂ，２４０ｃに接続した４ポートクロスバースイッチ２３０を示している。しかしながら、部分接続のクロスバー、全接続のクロスバー、バニヤンスイッチ、メモリスイッチ等の様々な他のスイッチを用いることができる。また、ＦＰＧＡ上のアプリケーションブロックの数に応じてスイッチ２３０にポートをいくつでも含むことができる。更に、１つより多いＯＲＢをＦＰＧＡに含むことができ、その場合には、各ＯＲＢは、スイッチ２３０に１ポートを指定されることとなる。図２において、ＯＲＢ受信部２２０及びＯＲＢ送信部２２２をポート「００」に接続し、アプリケーションブロック２４０ａをポート「０１」に接続し、アプリケーションブロック２４０ｂをポート「１０」に接続し、アプリケーションブロック２４０ｃをポート「１１」等に接続することができる。
【００３５】
上記したように、アプリケーションブロック２４０ａ、受信オペレーションアダプタ（ＲＯＡ）２５０、送信オペレーションアダプタ（ＴＯＡ）２５２等の各ミドルウエア使用可能なアプリケーションブロックは、アプリケーションモジュール２４２とクロスバースイッチ２３０との間のブリッジとして作用する。各ミドルウエアアプリケーションブロックと関連する送信オペレーションアダプタは、１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを送信する。各ミドルウエアアプリケーションブロックと関連する受信オペレーションアダプタは、着信オペレーションネーム及びオブジェクトインディケータを受信する。ミドルウエア使用可能なアプリケーションブロックの各受信オペレーションアダプタは、そのオブジェクトインディケータによって特定される対応するアプリケーションモジュールのアプリケーションオブジェクトによる使用のために、その着信オブジェクトインディケータに基づいた少なくとも１つの着信オペレーションネームを、対応するアプリケーション特定オペレーションインディケータに変換する。ミドルウエア使用可能なアプリケーションブロックの各送信オペレーションアダプタは、対応するアプリケーションモジュールのアプリケーションオブジェクトによって特定される少なくとも１つのアプリケーション特定オペレーションインディケータを、対応する発信オペレーションネームに変換する。１つのアプリケーションブロックにおける送信オペレーションアダプタからのオペレーションネームは、上述の送信オペレーションアダプタからのオブジェクトインディケータに基づいて別のアプリケーションブロックの受信オペレーションアダプタに搬送される。
【００３６】
図２（ｂ）の例示的な実施形態においては、ＲＯＡ２５０は、オペレーションネームと対応して列挙オペレーションインディケータ値とを有するルックアップテーブルを含む。オペレーションネームは文字列であり、アプリケーションモジュール２４２等のアプリケーションモジュールが実行することができる命令として外部世界で知られていることの構成要素となる。例えば、オペレーションネームは「ｆｉｒｅ」、「ｒｅｌｏａｄ」又は「ｓｈｕｔ  ｄｏｗｎ」であってよい。アプリケーションモジュール２４２は、機能として、オペレーションネームと関連して列挙オペレーションインディケータ値を認識するように構成される。例えば、「ｆｉｒｅ」に対する列挙オペレーションインディケータ値は０であり、「ｒｅｌｏａｄ」に対する列挙オペレーションインディケータ値は１であり、「ｓｈｕｔ  ｄｏｗｎ」に対する列挙オペレーションインディケータ値は２であってよい。列挙オペレーションインディケータ値は、特定のアプリケーションモジュール及びそれの中に含まれるアプリケーションオブジェクトに特有である。従って、０はアプリケーションブロック２４０ａ内の「ｆｉｒｅ」と関連する一方で、アプリケーションブロック２４０ｂ内の「ｍｅａｓｕｒｅ  ｔｅｍｐｅｒａｔｕｒｅ」等の別のオペレーションと関連する。ルックアップテーブルはＲＯＡ２５０に含まれ、アプリケーションモジュール２４２と直接関連付けられるので、システムの停止に重なることなく、また追加的な外部構成行動を要求することなく、アプリケーションを動的に再構成することができる。
【００３７】
ＴＯＡ２５２は、オペレーションネーム用の列挙オペレーションインディケータ値及びオブジェクトキー用の列挙オブジェクトインディケータ値を、それぞれ、十分に拡張したオペレーションネーム及びオクテットシーケンスに変換するために用いられるテーブルセットを含む。前と同じように、このデータはＴＯＡ２５２に含まれ、アプリケーションモジュール２４２と直接関連付けられるので、システムの停止に重なることなくアプリケーションを動的に再構成することができる。
【００３８】
ＦＰＧＡ２００の実行中には、ＲＯＡ２５０及びＴＯＡ２５２は、ＩＤＬ−ＶＨＤＬコンパイラを用いてＩＤＬモデルから生成される。ＩＤＬモデルは、ＲＯＡ２５０及びＴＯＡ２５２のコンテンツを記述する。ＩＤＬモデル内ではアプリケーションモジュール２４２のアプリケーションオブジェクトによってサポートされるオペレーション毎にエントリがあり、それはオペレーション毎に列挙オペレーションインディケータ値、オペレーションネーム、及びパラメータのリストを含む。アプリケーションブロック２４０用のＩＤＬモデルを構成及び作成するために、システム設計者は、オペレーション毎にオペレーションネーム及びパラメータを変更することだけを必要とする。従って、ＩＤＬモデルを作成することは、設計者にＩＤＬプログラミングを完全に理解することを要求しない。従って、本発明による再構成可能なＦＰＧＡは、値又は文字列等の１つ又は複数のアプリケーション特定インターフェースインディケータを用いる１つ又は複数のアプリケーションオブジェクトを有する複数のミドルウエア使用可能なアプリケーションブロックを有する。アプリケーション特定インターフェースインディケータは、ＦＰＧＡ上の各アプリケーションブロックを実行する、ハードウエア定義言語、例えば、ＶＨＤＬによって記述される。本発明のかかる態様によれば、任意の他のアプリケーションブロックを実行するハードウエア定義言語の任意の他の記述を変更することなく、１つのアプリケーションブロックに関連するアプリケーション特定インディケータを動的に変更、更新又は再構成することができる。
【００３９】
ＲＯＡ２５０及びＴＯＡ２５２用のＶＨＤＬコードを生成することに加えて、ＩＤＬコンパイラは、ＧＩＯＰメッセージペイロード内に全てのオペレーションデータエレメントのフォーマット及び位置を詳細に説明した文書を生成する。これは、ＦＰＧＡ設計者がＧＩＯＰメッセージフォーマット及びＣＤＲ（Ｃｏｍｍｏｎ  Ｄａｔａ  Ｒｅｐｒｅｓｅｎｔａｉｏｎ）マーシャリング／デマーシャリング規則に精通する必要性を減少又は除去させる。
【００４０】
ＩＤＬ−ＶＨＤＬコンパイラは、ＩＤＬモデルをＶＨＤＬコードにコンパイルする。ＶＨＤＬコードは、アプリケーションブロック２４０ａ，２４０ｂ，２４０ｃ毎にＲＯＡ２５０及びＴＯＡ２５２を同期させるために用いられる。ＲＯＡ２５０及びＴＯＡ２５２は前に説明した全ての他のＯＲＢから独立して生成されるので、ＦＰＧＡ設計者は、他のＯＲＢモジュールの再プログラミング及び再構成を行うことなくＦＰＧＡ２００の任意のアプリケーションブロック２４０ａ、２４０ｂ又は２４０ｃを再構成することができる。従って、例えば、アプリケーションブロック２４０ａ内のアプリケーションモジュール２４２が更新又は変更される必要があるならば、システム設計者は、アプリケーションブロック２４０用の新しいＲＯＡ２５０及びＴＯＡ２５２を作成するために、新しいアプリケーションモジュール２４２用の新しいＩＤＬモデルを作成し、ＩＤＬ−ＶＨＤＬコンパイラを動作させることだけが必要である。しかしながら、ＯＲＢ受信部２２０、ＯＲＢ送信部２２２、ＲＴＡ２１０、ＴＴＡ２１２及びクロスバースイッチ２３０を変更する必要はない。
【００４１】
ＦＰＧＡの動作中において、ＧＩＯＰリクエストパケットがＲＴＡ２１０によって受信されるとき、このパケットはＯＲＢ受信部２２０に渡される。ＯＲＢ受信部２２０はメッセージヘッダを処理し再フォーマットして、ストリーム処理のために最適化されるコンパクトな内部表現を作成する。最適化ヘッダは、他の情報の中で、文字列の形式でオペレーションネーム、所望のオペレーションのためのパラメータを含むメッセージデータ、及びパケットの宛先アドレスを指定するオブジェクトキーを含んでいる。宛先アドレスは、パケットが送信されるところのアプリケーションブロックに対応する。このデータパケットは次いで、クロスバースイッチ２３０に送信される。
【００４２】
スイッチ２３０は、ＯＲＢ受信部２２０から前もって定められたアプリケーションブロック２４０ａへ受信するパケットのルーティングを行う。着信パケットは、アプリケーションモジュール２４２に送られる前にＲＯＡ２５０によって処理される。オブジェクトキーのオブジェクトインディケータビット［５：０］は、アプリケーションモジュール内のアプリケーション毎の適切なインターフェースを示している。前述したように、ＲＯＡ２５０は、ターゲットオブジェクトインターフェースに対して適切な文字列オペレーションネームを、列挙オペレーションインディケータ値に変換するためのルックアップテーブルを含んでいる。ＲＯＡ２５０で受信されたメッセージがＯＲＢ受信部２５０から発せられた場合、このメッセージは、文字列の形式でオペレーションネームを含んでいる。その場合には、ＲＯＡ２５０はオペレーションネームを検索し、それを対応する列挙値に変換する。次いで、ＲＯＡ２５０はパケットをアプリケーションブロック２４０に渡す。しかしながら、パケットが別のアプリケーションブロック２４０ｂからアプリケーションブロック２４０ａにルーティングされた場合、そのパケットは既に列挙値を含んでいる。この場合には、ＲＯＡ２５０は、パケットを変更なしでアプリケーションモジュール２４２に渡す。この動作は、メッセージの内部又は外部発生についての知識からＦＰＧＡアプリケーションを分離し、位置透過性を与える。
【００４３】
オペレーションがリプライを要求する場合、アプリケーションモジュール２４２は、リプライメッセージを生成し、それをＴＯＡ２５２を介してクロスバースイッチ２３０に送る。次いで、このメッセージはクロスバースイッチ２３０から、完全なＧＩＯＰメッセージを生成するＯＲＢ送信モジュール２２２に送られる。ＧＩＯＰメッセージは次いで、ＴＴＡ２１２を介して送出される。いずれのアプリケーションブロック２４０によって発せられたリクエストは同様に転送される。
【００４４】
本発明の別の実施形態において、ＴＯＡ２５２のタスクは、ブート時にＯＲＢ受信部２２０及びＯＲＢ送信部２２２に情報を送信することに限定される。この実施形態においては、ブート時にＴＯＡ２５２によってＯＲＢ送信部２２２に送られるデータは、列挙オペレーションインディケータ値を文字列オペレーションネームに変換して戻す方法についての情報を含む。従って、この実施形態において、ＯＲＢ送信部は、各アプリケーションブロック２４０ａによって引き起こされる各オペレーションに関連した列挙オペレーションインディケータ値を記憶する記憶手段を含まなければならない。オペレーション時に、アプリケーションモジュール２４２がリクエストメッセージを開始し又はＯＲＢ送信部２２２にリプライメッセージを送るとき毎に、ＴＯＡ２２２は、いかなる変更もなしにメッセージを送信する。従って、ＯＲＢ送信部２２２によって受信されたメッセージは、オペレーションネームに代わって列挙オペレーションインディケータ値を含む。ＯＲＢ送信部２２２は次いで、ＧＩＯＰメッセージを作成する前に列挙タイプをオペレーションネームに訳す。
【００４５】
図３はスイッチに代えてバス３３０の形式でルーティングを行う本発明の代替的実施形態を示している。この実施形態において、ＯＲＢ受信部２２０は、メッセージをバス３３０に送る。バス３３０はメッセージヘッダにおけるアドレス情報を用いて、宛先アプリケーションブロック２４０ａにメッセージを供給する。
【００４６】
図４は本発明の更に別の実施形態を示しており、全てのアプリケーションブロック４４０間のメッセージは連続的にルーティングされる。この実施形態において、ＯＲＢ受信部２１０は一連のアプリケーションブロックを介してメッセージを、そのメッセージでアドレス指定された所望のアプリケーションブロックがメッセージを受信して処理するまで、送信する。その後、このアプリケーションブロックはリプライを発し、それはＯＲＢ送信部２２２によって受信される前に一連の他のアプリケーションブロックを介して再度実行することができる。処理量を増加させるために、全ての接続部をパイプ４３０を用いてパイプライン伝送することができる。従って、ＯＲＢ受信部２１０は、新しいリクエストを発する前に戻りのためにリプライを待つことに代えて、クロックサイクル毎に発信アプリケーションブロックに異なるリクエストを発することができる。或いは、一連のアプリケーションブロック４４０を、パイプラインなしに接続することができる。
【００４７】
図５は、ＯＲＢ及びＲＯＡを介して処理された着信リクエストメッセージの例示的なフォーマットを示している。転送リクエストメッセージ５２０は、ＧＩＯＰ標準規格によって要求されたフィールドを有するＧＩＯＰメッセージである。大部分のこれらのフィールドは内部ＦＰＧＡアプリケーションのオペレーションのためには必要ないので、ＯＲＢはメッセージ５２０をＯＲＢ後のリクエストメッセージ５３０に減少させる。メッセージ５３０はオペレーションネームを文字列として含み、文字列は前述した例において、「ｆｉｒｅ」、「ｒｅｌｏａｄ」、「ｓｈｕｔ＿ｄｏｗｎ」、又は「ｍｅｓｓａｇｅ＿ｔｅｍｐｅｒａｔｕｒｅ」であってよい。また、メッセージ５３０は、ｒｅｑｕｅｓｔ＿ｉｄ、ｄａｔａ＿ｐａｙｌｏａｄ＿ｓｉｚｅ、メッセージデータと共に、後で図８ａを参照して説明されるＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬを含む。メッセージデータは、特定のオペレーションを実行するためにアプリケーションに送信されるパラメータを含む。
【００４８】
図６は操作可能な送信アダプタ及びＯＲＢを介して処理された発信リクエストメッセージの例示的なフォーマットを示している。アプリケーションリクエストメッセージ６１０は、操作可能な送信アダプタによって受信され、操作可能な送信アダプタは所望オペレーション列挙値のためのオペレーションネーム（文字列）を検索し、メッセージ６２０にこのオペレーションネームを加える。メッセージ６２０は次いで、ＯＲＢによってポートＯＲＢへの（転送のための）のリクエストメッセージ６３０に変換され、リクエストメッセージ６３０はＧＩＯＰ標準規格に従っている。
【００４９】
図７は操作可能な送信アダプタ及びＯＲＢを介して処理されたリプライメッセージの例示的なフォーマットを示している。アプリケーションリプライメッセージ７１０は、ＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬの代わりにＲＥＰＬＹ＿ＣＯＮＴＲＯＬを含むことを除いて、図６に示したアプリケーションリクエストメッセージ６１０と類似である。同様に、オペレーション後のアダプタリプライメッセージ７２０は、ＲＥＰＬＹ＿ＣＯＮＴＲＯＬを含むことを除いて、オペレーション後のアダプタリクエストメッセージ６２０と類似である。
【００５０】
図８（ａ）及び図８（ｂ）は、図６及び図７に示した共に３２ビットフィールドのＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬ及びＲＥＰＬＹ＿ＣＯＮＴＲＯＬの例示的なフォーマットを示している。ＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬ及びＲＥＰＬＹ＿ＣＯＮＴＲＯＬのフィールド説明は次の通りである。
ＲＥＱＵＥＳＴ＿ＣＯＮＴＲＯＬフィールド説明
宛先オブジェクトアドレス
【００５１】
ビット［１０：６］はメッセージについての内部物理的宛先を示している。発信リクエストメッセージについて、これらのビットは、送信ＯＲＢアダプタにセットされる（全てゼロ）。着信及びローカルリクエストメッセージについて、これらのビットはターゲットオペレーションアダプタにセットされる。
【００５２】
ビット［５：０］は、メッセージについての物理的宛先内の内部論理宛先を示している。着信、ローカル又は発信リクエストメッセージについて、これらのビットは、呼び出されたクライアントサーバントに対してオブジェクトＩＤを示すために適切な値にセットされる。
ソースオブジェクトアドレス
【００５３】
ビット［１０：６］はメッセージの内部物理的ソースを示している。着信リクエストメッセージについて、これらのビットは、受信ＯＲＢアダプタにセットされる（全てゼロ）。発信及びローカルリクエストメッセージについて、これらのビットは、ソースオペレーションアダプタにセットされる。
【００５４】
ビット［５：０］はメッセージの物理的ソース内の内部論理ソースを示している。着信、ローカル又は発信リクエストメッセージについて、これらのビットは、呼び出しのサーバントに対してオブジェクトＩＤを示すことに適切な値にセットされる。
バイト順番−着信メッセージについてバイト順を示すＣＯＲＢＡ定義ブーリアン値。
【００５５】
１＝リトルエンディアン，０＝ビッグエンディアン
メッセージタイプ（ＭＴ）−メッセージタイプフィールドインディケータブーリアン値。
０＝リクエスト，１＝リプライ
レスポンスイクスペクテッド（ＲＥ）−レスポンスがこのリクエストに対して期待されるかどうかを示すＣＯＲＢＡ定義ブーリアン値。
０＝レスポンス期待なし，１＝レスポンス期待あり
列挙オペレーション
【００５６】
オペレーションアダプタはこれを列挙オペレーションインディケータとして解釈する。
ＲＥＰＬＹ＿ＣＯＮＴＲＯＬフィールド説明
宛先オブジェクトアドレス
【００５７】
ビット［１０：６］はメッセージについての内部物理的宛先を示している。発信リプライメッセージについて、これらのビットは、送信ＯＲＢアダプタにセットされる（全てゼロ）。着信及びローカルリプライメッセージについて、これらのビットは、ターゲットオペレーションアダプタにセットされる。
【００５８】
ビット［５：０］はメッセージについての物理的宛先内の内部論理宛先を示している。着信、ローカル又は発信リプライメッセージについて、これらのビットは、呼び出しているクライアントサーバントに対してオブジェクトＩＤを示すために適切な値にセットされる。
ソースオブジェクトアドレス
【００５９】
ビット［１０：６］はメッセージの内部物理的ソースを示している。着信リプライメッセージについて、これらのビットは、受信ＯＲＢアダプタにセットされる（全てゼロ）。発信及びローカルリプライメッセージについて、これらのビットはソースオペレーションアダプタにセットされる。
【００６０】
ビット［５：０］はメッセージの物理的ソース内の内部論理ソースを示している。着信、ローカル又は発信リプライメッセージについて、これらのビットは、呼び出されるサーバントに対してオブジェクトＩＤを示すために適切な値にセットされる。
バイト順番−着信メッセージについてのＣＯＲＢＡ定義バイト順。
１＝リトルエンディアン，０＝ビッグエンディアン
メッセージタイプ（ＭＴ）−メッセージタイプフィールドインディケータブーリアン値。
０＝リクエスト，１＝リプライ  リプライ（ｂ”１”）であるに違いない。
リプライステータス（ＲＳ）−ＣＯＲＢＡ定義。典型的にはＮＯ＿ＥＸＣＥＰＴＩＯＮ（ｂ”０００”）であるべき。
【００６１】
図９は本願の実施形態に応じてＯＲＢ又は複数のＯＲＢを有するＦＰＧＡを実現する方法のフローチャートを示している。ＩＤＬインターフェース９１０及びＩＤＬメタデータ９１２は、ＩＤＬ−ＶＨＤＬコンパイラに供給される（ブロック９１４）。ＩＤＬ−ＶＨＤＬコンパイラはこのデータを用いてＶＨＤＬにて各アプリケーション毎に必要なオペレーションインターフェースを生成する（ブロック９２０）。その後、このオペレーションインターフェースは、ユーザアプリケーションとマージされ、ＶＨＤＬ又はＶｅｒｉｌｏｇにてアプリケーションブロックを生成する（ブロック９２２）。次いで、アプリケーションブロックは、ＥＤＩＦネットリストフォーマットのＦＰＧＡ  ＯＲＢ９３２と、ＶＨＤＬ、ＥＤＩＦ、又はソフトウエアフォーマットである転送アダプタモデル９３４と結合され、ＦＰＧＡのＶＨＤＬモデルにする（ブロック９３０）。このＶＨＤＬモデルは次いで、ＶＨＤＬに備えられたシミュレーション環境９４２を用いてシミュレーションされる（ブロック９４０）。良好なシミュレーション後、ＦＰＧＡのＶＨＤＬモデルは合成され（ブロック９５０）、ＥＤＩＦネットリストを生成する（ブロック９５２）。次いでＥＤＩＦネットリストを配置して、ＦＰＧＡを介してルーティングすることができる（ブロック９５４）。最終的に、ビットファイルが作成され（ブロック９５６）、それはＦＰＧＡをプログラムするために用いられる（ブロック９６０）。
【００６２】
図１０は本発明の実施形態に応じて実現されたＳＤＲ（ソフトウエア無線）の例示的ブロック図を示している。ＳＤＲはスプレッダブロック、デスプレッダブロック、エンコーダブロック及びＤＡＣ／ＡＤＣブロック等の複数のミドルウエア可能アプリケーションブロックと共に、ＦＰＧＡ等の集積回路上に実現される。各ミドルウエア使用可能なアプリケーションブロックは、信号スプレッディング、デスプレッディング、エンコーディング、及びＡ／Ｄ，Ｄ／Ａ変換機能等を含む、必要なＳＤＲ機能をなす１つ又は複数のアプリケーションオブジェクトを含む、１つ又は複数のアプリケーションモジュールを備えている。これらのアプリケーションオブジェクトは、上記したように、集積回路内でローカル的に、また集積回路の外部で伝送手段を介してリモート的にメッセージを透過的に処理する対応するアプリケーション特定インターフェースインディケータを用いる。
【００６３】
図のように、送信オペレーションアダプタ及び受信オペレーションアダプタは、上述したように、着信及び発信メッセージを伝え、オペレーションネーム及びオブジェクトインディケータを処理／変換する各ミドルウエアアプリケーションブロックと関連付けされる。ミドルウエア使用可能なアプリケーションブロックの各受信オペレーションアダプタは、着信オブジェクトインディケータに基づいた少なくとも１つの着信オペレーションネームを、対応するアプリケーション特有のオペレーションインディケータに変換する。これはオブジェクトインディケータによって特定される対応するアプリケーションモジュールのアプリケーションオブジェクトによる使用のためである。ミドルウエア使用可能なアプリケーションブロックの各送信オペレーションアダプタは、対応するアプリケーションモジュールのアプリケーションオブジェクトによって特定される少なくとも１つのアプリケーション特有のオペレーションインディケータを、対応する発信オペレーションネームに変換する。クロスバースイッチ形式のメッセージルータは、集積回路内のメッセージをアプリケーションブロック間でローカル的に搬送する。ＯＲＢ受信及びＯＲＢ送信ブロックを備えるディスパッチモジュールは、メッセージルータにつながれて、メッセージルータはＣＯＲＢＡ等の定義されたプロトコルに応じて集積回路外部の通信伝送手段を介してオブジェクトサービスリクエスト及びリプライメッセージを仲介する。オブジェクトサービスリクエストメッセージは、１つ又は複数の着信オペレーションネーム及びオブジェクトインディケータを含む着信データメッセージと、１つ又は複数の発信オペレーションネーム及びオブジェクトインディケータを含む発信データメッセージとを備えている。オブジェクトサービスリプライメッセージは、オブジェクトサービスリクエストコンテキスト情報を含む着信データメッセージと、オブジェクトサービスリクエストコンテキスト情報を含む発信データメッセージとを備えている。メッセージルータは、伝送手段を介した通信のためにアプリケーションモジュールから指定された発信オペレーションネームを、プロトコルに応じて伝送されるべきディスパッチモジュールに適用する。
【００６４】
上記したように、本発明は、他のアプリケーションブロックをはめ込むことなく、各アプリケーションブロックを再構成することができるように、ＳＤＲアプリケーションブロックを実装するＦＰＧＡの部分的及び動的な再構成可能性について考慮する。例えば、スプレッダブロックインターフェースを、任意の他のＳＤＲ機能ブロックを再構成することなく更新又は変更することができる。従って、ＳＤＲを実現するＦＰＧＡは、複数のミドルウエア使用可能なアプリケーションブロック、すなわちスプレッダ、デスプレッダ、エンコーダ、ＤＡＣ／ＡＤＣブロック等を備える再構成可能なＦＰＧＡである。各ミドルウエア使用可能なアプリケーションブロックはＳＤＲに関連した機能をなす１つ又は複数のアプリケーションオブジェクトを有する。それらはメッセージを処理するために１つ又は複数のアプリケーション特有のインターフェースインディケータを使用する。１つのアプリケーションブロックと関連したこの１つ又は複数のアプリケーション特有のインターフェースインディケータを、別のアプリケーションブロックと関連した１つ又は複数のアプリケーション特有のインターフェースインディケータを変更することなく、動的に再構成又は変更することができる。
【図１】
2010517172.tif 000003
【図２（ａ）】
2010517172.tif 000004
【図２（ｂ）】
2010517172.tif 000005
【図３】
2010517172.tif 000006
【図４】
2010517172.tif 000007
【図５】
2010517172.tif 000008
【図６】
2010517172.tif 000009
【図７】
2010517172.tif 000010
【図８（ａ）】
2010517172.tif 000011
【図８（ｂ）】
2010517172.tif 000012
【図９】
2010517172.tif 000013
【図１０】
2010517172.tif 000014
【国際調査報告】
2010517172.tif 000015