JP2004508617A - ソフトウェアが設計されたインターネット再構成可能ハードウェアのシステム、方法、及び製造物 - Google Patents

Abstract

プログラマブルロジックデバイスをネットワーク・ベースで構成するシステム、方法、及び製造物が提供される。デフォルトのアプリケーションがプログラマブルロジックデバイス上でイニシエートされる。構成データのファイル要求が、ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ送られる。構成データは、ネットワーク・サーバから受け取られる。構成データは、ロジックデバイスを構成して第２のアプリケーションを走らせるために使用される。第２のアプリケーションはロジックデバイス上で走る。
【選択図】図１

Description

【０００１】
【発明の分野】
本発明は、再構成可能なロジックデバイスに関しており、更に具体的には、ロジックデバイスをネットワーク・ベースで構成することに関する。
【０００２】
【発明の背景】
ソフトウェア制御のマシンは、適切なソフトウェアを使用することによって多くの異なった所望の目的に適合化される点で大きな柔軟性を提供することがよく知られている。ソフトウェア制御のプロセッサは、周知の汎用コンピュータで使用されるだけでなく、現在では、多くの製品、例えば、自動車、電話、及び他の家庭製品で使用される。その場合、そのようなプロセッサは組み込みシステムとして知られている。
【０００３】
しかし、所与の機能については、ソフトウェア制御プロセッサは、通常、その機能に専用のハードウェアよりも遅い。この問題を克服する１つの方法は、特別のソフトウェア制御プロセッサ、例えば、ＲＩＳＣプロセッサを使用することである。ＲＩＳＣプロセッサは、そのパラメータ（例えば、サイズ、命令セットなど）を所望の機能へ調整することによって、限定された目的へ、より早く機能するように作ることができる。
【０００４】
しかし、ハードウェアが使用される場合、それは操作のスピードを増大させても柔軟性を欠いている。例えば、ハードウェアは、それが設計されたタスクには適しているかも知れないが、後でそのタスクの修正バージョンが所望されたときには適していないかも知れない。現在では、再構成可能なロジック回路、例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）上で、ハードウェアを形成することができる。ＦＰＧＡは、異なった様式で反復的に再構成されることのできるロジック回路である。従って、再構成可能ロジック回路は、専用ハードウェアのスピードの利点を提供し、また後の更新又は多数の機能に適した或る程度の柔軟性を提供する。
【０００５】
しかし、一般的に、設計者はスピードと汎用性を正しくバランスさせる問題に直面することが分かるであろう。設計者は、ソフトウェアで制御されて多くの異なった機能を比較的遅く実行する汎用チップを製作するか、タスクの限定されたセットのみを早く実行するアプリケーション専用チップを案出することができる。
【０００６】
これらの問題の妥協的解決法は、専用ハードウェアとソフトウェアを結合するシステムで見出すことができる。ハードウェアは、特定の機能、例えば、スピードを要求する機能で専用に使用され、ソフトウェアは残りの機能を実行することができる。そのようなシステムの設計は、ハードウェア・ソフトウェアの共設計（ｃｏｄｅｓｉｇｎ）として知られる。
【０００７】
設計プロセスにおいて、設計者は、所望の機能を有する目標システムのために、どの機能をハードウェアで実行させ、どの機能をソフトウェアで実行させるかを決定しなければならない。これは設計の区分化として知られる。そのようなシステムは高度に効率的であるが、設計者はソフトウェア設計及びハードウェア設計の双方に精通していなければならない。もしソフトウェアだけに精通し、構成可能なロジック・リソースの柔軟性を利用できる人々が、そのようなシステムを設計できるならば有利であろう。更に、構成データを選択及び転送するための直観的で人間工学的なインタフェースを、そのようなシステムの中へ実現することは有利であろう。
【０００８】
【発明の概要】
プログラマブルロジックデバイスをネットワーク・ベースで構成するシステム、方法、及び製造物が提供される。デフォルトのアプリケーションがプログラマブルロジックデバイス上でイニシエートされる。構成データのファイル要求が、ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ送られる。構成データは、ネットワーク・サーバから受け取られ、ビットファイルの形式であることができる。構成データは、ロジックデバイスを構成して第２のアプリケーションを走らせるために使用される。第２のアプリケーションはロジックデバイス上で走る。
【０００９】
本発明の１つの実施形態によると、ロジックデバイスは１つ又は複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。好ましくは、第１のＦＰＧＡは、構成データを受け取り、第２のＦＰＧＡを構成するためにそのデータを使用する。第１及び第２のＦＰＧＡは、異なったスピードで刻時されることができる。
【００１０】
本発明の他の実施形態によると、デフォルトのアプリケーション及び第２のアプリケーションの双方が、ロジックデバイス上で同時に走ることができる。ロジックデバイスは、更に、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、不揮発性メモリ、及び／又は他のハードウェア・コンポーネントを含むことができる。
【００１１】
本発明は、方法を実行するプログラム・コード手段を含むコンピュータ・プログラムへ拡張される。
【００１２】
本発明は、実施形態の以下の詳細な説明が考察されるとき、より良好に理解されるであろう。そのような説明は、添付の図面を参照する。
【００１３】
【好適な実施形態の詳細な説明】
本発明によるシステムの好適な実施形態は、好ましくは、パーソナル・コンピュータ、例えば、ＩＢＭ互換パーソナル・コンピュータ、アップル・マッキントッシュ・コンピュータ、又はＵＮＩＸベース・ワークステーションの環境で実施される。代表的ハードウェア環境は、図１に示される。図１は好適な実施形態によるワークステーションの典型的なハードウェア構成を示し、中央処理装置１１０、例えば、マイクロプロセッサ、及びシステム・バス１１２を介して接続された多数の他の装置を有する。図１に示されるワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１１４、読み出し専用メモリ（ＲＯＭ）１１６、周辺装置、例えばディスク記憶装置１２０をバス１１２へ接続するＩ／Ｏアダプタ１１８、キーボード１２４、マウス１２６、スピーカ１２８、マイクロフォン１３２、及び／又は他のユーザ・インタフェース装置、例えばタッチスクリーン（図示されていない）をバス１１２へ接続するユーザ・インタフェース・アダプタ１２２、ワークステーションを通信ネットワーク（例えば、データ処理ネットワーク）へ接続する通信アダプタ１３４、及びバス１１２をディスプレイ装置１３８へ接続するディスプレイ・アダプタ１３６を含む。ワークステーションは、更に、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）１４０、及びその上の完全又は部分的オペレーティング・システム、例えば、Ｍｉｃｒｏｓｏｆｔ　Ｗｉｎｄｏｗｓ　ＮＴ又はＷｉｎｄｏｗｓ／９８オペレーティング・システム（ＯＳ）、ＩＢＭ　ＯＳ／２オペレーティング・システム、ＭＡＣ　ＯＳ、又はＵＮＩＸオペレーティング・システムを含む。当業者は、本発明が前記のプラットフォーム及びオペレーティング・システムとは異なったもので実施されてよいことを理解するであろう。
【００１４】
好適な実施形態は、ＪＡＶＡ、Ｃ、及びＣ＋＋言語を使用して書かれ、オブジェクト指向プログラミング方法を利用する。オブジェクト指向プログラミング（ＯＯＰ）は、複雑なアプリケーションを開発するために使用されることが多くなってきた。ＯＯＰがソフトウェア設計及び開発の主流となるにつれて、様々なソフトウェア解決法は、ＯＯＰの利点を利用するための適合化を必要とする。ＯＯＰのこの原理を電子メッセージング・システムのメッセージング・インタフェースへ適用して、メッセージング・インタフェースのための一組のＯＯＰクラス及びオブジェクトを提供できるようにする必要がある。
【００１５】
ＯＯＰは、オブジェクトを使用してコンピュータ・ソフトウェアを開発するプロセスであり、問題を分析し、システムを設計し、プログラムを構造化するステップを含む。オブジェクトとは、データ及び関連の構造及び手順の集合を含むソフトウェア・パッケージである。オブジェクトは、データ及び構造並びに手順の集合を含むので、その特別のタスクを実行するために他の追加の構造、手順、又はデータを必要としない自給自足のコンポーネントとして考えることができる。従って、ＯＯＰは、コンピュータ・プログラムを、オブジェクトと呼ばれる非常に自立的なコンポーネントの集合として考える。オブジェクトの各々は特定のタスクに責任を有する。このように、データ、構造、及び手順を１つのコンポーネント又はモジュールへ一緒にパッケージする概念は、カプセル化と呼ばれる。
【００１６】
一般的に、ＯＯＰコンポーネントは、再使用可能なソフトウェア・モジュールである。このモジュールは、オブジェクト・モデルに合致したインタフェースを与え、コンポーネント統合アーキテクチャによって実行時にアクセスされる。コンポーネント統合アーキテクチャは、異なった処理空間にあるソフトウェア・モジュールが相互の能力又は機能を利用できるようにする一組のアーキテクチャ・メカニズムである。これは、一般的に、アーキテクチャを構築する共通のコンポーネント・オブジェクト・モデルを想定することによって行なわれる。この時点で、オブジェクトと、オブジェクトのクラスとを区別しておくことが必要である。オブジェクトとは、オブジェクトのクラスの１つのインスタンスである。オブジェクトのクラスは、多くの場合、単にクラスと呼ばれる。オブジェクトのクラスは、青写真と考えることができる。１つの青写真から多くのオブジェクトを形成することができる。
【００１７】
ＯＯＰは、プログラマが他のオブジェクトの一部分であるオブジェクトを作り出すことを可能にする。例えば、ピストンエンジンを表すオブジェクトは、ピストンを表すオブジェクトと組成関係を有すると言われる。現実には、ピストンエンジンはピストン、バルブ、及び他の多くのコンポーネントを含む。ピストンがピストンエンジンの１つの要素である事実は、２つのオブジェクトによって、ＯＯＰの中で論理的及び意味的に表されることができる。
【００１８】
ＯＯＰは、更に、他のオブジェクト「から垂れ下がる（ｄｅｐｅｎｄｓ ｆｒｏｍ）」オブジェクトの作成を可能にする。２つのオブジェクトが存在し、１つのオブジェクトはピストンエンジンを表し、他のオブジェクトはピストンがセラミックから作られたピストンエンジンを表す場合、２つのオブジェクトの関係は組成の関係ではない。セラミック・ピストンエンジンは、ピストンエンジンを作り上げていない。むしろ、それは単に、ピストンエンジンよりも１つだけ多い限定、即ち、そのピストンはセラミックから作られているという限定を有する一種のピストンエンジンである。この場合、セラミック・ピストンエンジンを表すオブジェクトは、導出オブジェクトと呼ばれる。それはピストンエンジンを表すオブジェクトの様相の全てを継承し、更なる限定又はディテールをそれに加えている。セラミック・ピストンエンジンを表すオブジェクトは、ピストンエンジンを表すオブジェクト「から垂れ下がって」いる。これらのオブジェクトの関係は継承と呼ばれる。
【００１９】
セラミック・ピストンエンジンを表すオブジェクト又はクラスが、ピストンエンジンを表すオブジェクトの様相の全てを継承するとき、それはピストンエンジン・クラスの中で定義された標準ピストンの熱特性を継承する。しかし、セラミック・ピストンエンジンのオブジェクトは、金属ピストンに関連した熱特性とは典型的に異なっているセラミック特殊熱特性をオーバーライドする。それはオリジナルを飛び越えて、セラミック・ピストンに関連した新しい機能を使用する。異なった種類のピストンエンジンは、異なった特性を有するが、それに関連した同じ根本的機能（例えば、エンジンの中のピストンの数、点火シーケンス、注油など）を有するかも知れない。ピストンエンジン・オブジェクトにおけるこれらの機能の各々にアクセスするため、プログラマは、同じ機能を同じ名前で呼ぶが、ピストンエンジンの各々のタイプは、同じ名前の背後にある機能の異種／オーバーライド実現形態を有するかも知れない。機能の異なった実現形態を同じ名前の背後に隠す能力はポリモーフィズムと呼ばれ、オブジェクトの間の通信を非常に簡単にする。
【００２０】
組成関係、カプセル化、継承、及びポリモーフィズムの概念を使用すると、オブジェクトは、現実世界の事物を正確に表現することができる。実際に、人の論理的現実認識は、オブジェクト指向ソフトウェアのオブジェクトとなることができる事物の種類を決定する場合の唯一の制約である。幾つかの典型的なカテゴリーは、次の通りである：
・オブジェクトは物理オブジェクト、例えば、交通量シミュレーションにおける自動車、回路設計プログラムにおける電気コンポーネント、経済モデルにおける国、又は航空管制システムにおける飛行機を表すことができる；
・オブジェクトは、コンピュータ・ユーザ環境の要素、例えば、ウィンドウ、メニュー、又はグラフィックス・オブジェクトを表すことができる；
・オブジェクトは、インベントリ、例えば、個人ファイル、又は都市の経度と緯度の表を表すことができる；
・オブジェクトは、ユーザ定義のデータ・タイプ、例えば、時間、角度、及び複素数、又は平面上の点を表すことができる。
【００２１】
論理的に区分できる事物を正確に表現できるオブジェクトの巨大な能力を使用して、ＯＯＰは、現実が物理的実体、プロセス、システム、又は事物の組成であっても、ソフトウェアの開発者が、事物の或る様相のモデルであるコンピュータ・プログラムを設計及び実現することができるようにする。オブジェクトは任意の事物を表すことができるから、ソフトウェアの開発者は、将来大きなソフトウェア・プロジェクトのコンポーネントとして使用されることができるオブジェクトを作り出すことができる。
【００２２】
新しいＯＯＰソフトウェア・プログラムの９０％が、既存の再使用可能なオブジェクトから作られた証明済みの既存のコンポーネントから構成された場合、新しいソフトウェア・プロジェクトの残りの１０％のみが、スクラッチから書かれてテストされる必要がある。９０％は、広範囲にテストされた再使用可能なオブジェクトの在庫から既に来ているので、誤りが生じる可能性がある領域は、プログラムの１０％である。その結果、ＯＯＰは、ソフトウェアの開発者が、前に構築された他のオブジェクトからオブジェクトを構築することを可能にする。
【００２３】
このプロセスは、アセンブリ及びサブアセンブリから組み立てられる複雑な機械装置と非常に良く似ている。従って、ＯＯＰ技術は、オブジェクトとして開発者が利用可能な既存のコンポーネントからソフトウェアが構築される点で、ソフトウェア・エンジニアリングをハードウェア・エンジニアリングと似たものにする。これらの全ては、ソフトウェアの改善された品質及び開発速度に寄与する。
【００２４】
プログラミング言語は、ＯＯＰの原理、例えば、カプセル化、継承、ポリモーフィズム、及び組成関係を完全にサポートし始めている。Ｃ＋＋言語の出現によって、多くの商用ソフトウェア開発者がＯＯＰを採用した。Ｃ＋＋は、高速でマシンを実行できるコードを提供するＯＯＰ言語である。更に、Ｃ＋＋は、商用アプリケーション及びシステム・プログラミングのプロジェクトに適している。現在のところ、Ｃ＋＋は多くのＯＯＰプログラマの間で最も人気のある言語のように見えるが、多数の他のＯＯＰ言語、例えば、Ｓｍａｌｌｔａｌｋ、Ｃｏｍｍｏｎ　Ｌｉｓｐ　Ｏｂｊｅｃｔ　Ｓｙｓｔｅｍ（ＣＬＯＳ）、及びＥｉｆｆｅｌが存在する。更に、ＯＯＰ能力は、更に伝統的で人気のあるコンピュータ・プログラミング言語、例えば、Ｐａｓｃａｌへ付け加えられている。
【００２５】
オブジェクト・クラスの利点を要約すると、次のようになる：
・オブジェクト及びそれらの対応するクラスは、複雑なプログラミング問題を多くの小さな単純問題へ分解する；
・カプセル化は、相互に通信することのできる小さな独立オブジェクトへデータを組織することによって、データの抽象化を実効的にする。カプセル化は、オブジェクト内のデータを不測の損害から保護するが、オブジェクトのメンバー関数及び構造を呼び出すことによって、他のオブジェクトがそのデータと交信することを可能にする；
・サブクラス化と継承は、システムで利用可能な標準のクラスから新しい種類のオブジェクトを導出することによって、オブジェクトの拡張及び修正を可能にする。従って、スクラッチから出発することなく、新しい能力が作り出される；
・ポリモーフィズム及び多重継承は、異なったプログラマが、多くの異なったクラスの特性を混合及び調和させ、予測可能な様式で関連オブジェクトと一緒に働くことのできる専門オブジェクトを作り出すことを可能にする；
・クラス階層及びコンテナ階層は、現実世界のオブジェクト、及びそれらの間の関係をモデル化する柔軟なメカニズムを提供する；
・再使用可能なクラスのライブラリを多くの場合に使用できるが、それらは或る制約を有する。例えば：
・複雑性：複雑なシステムでは、関連クラスのためのクラス階層は、何十何百というクラスによって、極端な混乱を起こす可能性がある；
・制御のフロー：クラスライブラリの助けを借りて書かれたプログラムは、依然として制御のフローに責任を有する（即ち、それは、特定のライブラリから作り出された全てのオブジェクトの間の交信を制御しなければならない）。プログラマは、どのような種類のオブジェクトのために、いつ、どのような関数を呼び出すかを決定しなければならない；
・労力の重複：クラスライブラリは、プログラマが多くの小さなコード部分を使用及び再使用することを可能にするが、各々のプログラマは、それらのコード部分を異なった様式で組み合わせる。２人の異なったプログラマは、クラスライブラリの同じセットを使用して、全く同じことを行なう２つのプログラムを書くことができる。しかし、それらのプログラムの内部構造（即ち、設計）は、各々のプログラマが途中で行なう何百という小さな決定に依存して、全く違ってもよい。必然的に、類似のコード部分は、少しだけ異なった様式で類似のことを行なう結果となるが、共に機能する場合とは異なって機能する。
【００２６】
クラスライブラリは非常に柔軟性に富む。プログラムが益々複雑になるにつれて、益々多くのプログラマが、基本問題の基本的解決法を何度も繰り返して再発明するように強制される。クラスライブラリ概念の比較的新しい拡張は、クラスライブラリのフレームワークを有することである。このフレームワークは、より複雑であり、小型のパターン及び大きなメカニズムの双方を捕獲する協働クラスのかなりの集合から構成される。小型パターン及び大きなメカニズムは、特定のアプリケーション領域で共通の要件及び設計を実現する。それらは、最初、メニュー、ウィンドウ、ダイアログボックス、及びパーソナル・コンピュータの他の標準ユーザ・インタフェース要素の表示に関連する雑用からアプリケーション・プログラマを解放するために開発された。
【００２７】
フレームワークは、更に、プログラマが書いたコードと、他のプログラマが書いたコードとの交信に関するプログラマの考え方の変化を表す。手続き的プログラミングの早期において、プログラマはオペレーティング・システムによって提供されたライブラリを呼び出して或るタスクを実行したが、基本的には、プログラムはページを最初から最後まで実行し、プログラマは、制御のフローに単独で責任を有した。これは、ただ１つの方法で実行されるプログラムを使用して給料の小切手を印刷し、数表を計算し、又は他の問題を解決するのに適切であった。
【００２８】
グラフィカル・ユーザ・インタフェースの開発は、この手続き的プログラミング配列を裏返しにし始めた。これらのインタフェースは、プログラム・ロジックではなくユーザが、プログラムを駆動して、或るアクションをいつ実行すべきかを決定することを可能にする。今日では、パーソナル・コンピュータの大部分のソフトウェアが、イベント・ループによってこれを達成する。イベント・ループは、マウス、キーボード、及び外部イベントの他のソースを監視し、ユーザが実行するアクションに従ってプログラマのコードの適切な部分を呼び出す。プログラマは、もはや、イベントが起こる順序を決定しない。その代わりに、プログラムは別々の部分へ分割され、この別々の部分が、予測不可能な時間に予測不可能な順序で呼び出される。このようにして制御をユーザへ譲ることによって、開発者は使用するのに非常に容易なプログラムを作り出す。しかし、開発者によって書かれた個々のプログラム部分は、依然として、或るタスクを達成するためオペレーティング・システムによって提供されるライブラリを呼び出し、プログラマは、各々のプログラム部分がイベント・ループによって呼び出された後、依然として、各々のプログラム部分の中で制御のフローを決定しなければならない。アプリケーション・コードは、依然として、システムの「最上部に座っている」。
【００２９】
イベント・ループ・プログラムも、プログラマが大量のコードを書くことを要求するが、そのようなコードは全てのアプリケーションのために別々に書かれる必要はない。アプリケーション・フレームワークの概念は、イベント・ループの概念を更に推し進める。基本的メニュー、ウィンドウ、及びダイアログボックスを組み立てる基礎的処理を行い、次に、これらのものが全て一緒に働くようにする代わりに、アプリケーション・フレームワークを使用するプログラマは、アプリケーション・コード及び基本的ユーザ・インタフェース要素を働かせることからスタートする。次に、プログラマは、フレームワークの一般的能力の幾つかを、意図されたアプリケーションの特別の能力で置換することによって構築していく。
【００３０】
アプリケーション・フレームワークは、プログラマがスクラッチから書かなければならないコードの総量を減少させる。しかし、フレームワークは、実際には、ウィンドウを表示しコピー・アンド・ペーストをサポートするなどの一般的アプリケーションであるから、プログラマは、イベント・ループ・プログラムが許す以上に、大きく制御を譲ることができる。フレームワーク・コードは、殆ど全てのイベント処理及び制御のフローを取り扱い、プログラマのコードは、フレームワークがそれを必要とするときにのみ呼び出される（例えば、専有のデータ構造を作り出すか処理するため）。
【００３１】
フレームワーク・プログラムを書いているプログラマは、制御をユーザへ譲るだけでなく（イベント・ループ・プログラムの場合もそうであるように）、プログラム内部の詳細な制御フローをフレームワークへ譲る。このアプローチは、カスタム・コードを有する孤立したプログラムが、類似の問題に対して何度も繰り返して作成されることとは反対に、興味ある様式で働く更に複雑なシステムの作成を可能にする。
【００３２】
従って、前述したように、フレームワークは、基本的には、所与の問題領域のために再使用可能な設計解決法を作り上げる協力クラスの集合である。それは、典型的には、デフォルトの行動を提供するオブジェクトを含み（例えば、メニュー及びウィンドウのために）、プログラマは、フレームワークが適切なときにアプリケーション・コードを呼び出すように、そのデフォルトの行動の幾つかを継承し、他の行動をオーバーライドすることによって、それを使用する。
【００３３】
フレームワークとクラスライブラリとの間には、３つの主な差異がある：
・行動に対するプロトコル。
クラスライブラリは、本質的に、プログラムの中で個々の行動を希望するとき呼び出すことのできる行動の集合である。他方、フレームワークは、行動を提供するだけでなく、行動を組み合わせることのできる方法を支配するプロトコル又は規則の集合をも提供する。規則の集合は、フレームワークが何を提供するかに対抗して、プログラマが何を提供するかの規則を含む；
・呼び出しに対するオーバーライド。
クラスライブラリ、即ち、コードを使用する場合、プログラマはオブジェクトを具体化し、それらのメンバー関数を呼び出す。フレームワークを使用して、同じようにオブジェクトを具体化して呼び出すことができるが（即ち、クラスライブラリのようにフレームワークを処理する）、フレームワークの再使用設計を十分に利用するため、プログラマは、典型的には、オーバーライドしてフレームワークによって呼び出されるコードを書く。フレームワークは、そのオブジェクトの間で制御フローを管理する。プログラムを書くことは、フレームワークによって呼び出されるソフトウェアの様々な部分の間で責任を分割することを含み、異なった部分がどのように働くかを指定することを含まない；
・実現形態に対する設計。
クラスライブラリを使用する場合、プログラマは、実現形態のみを再使用するが、フレームワークを使用する場合、プログラマは設計を再使用する。フレームワークは、関連プログラムのファミリー又はソフトウェアの部分が働く方法を具体化する。それは、所与の領域における多様な特別問題へ適合化されることができる一般的な設計解決法を表す。例えば、１つのフレームワークは、ユーザ・インタフェースが働く方法を具体化することができる。もっとも、同じフレームワークで作り出された２つの異なったユーザ・インタフェースは、全く異なったインタフェース問題を解決してもよい。
【００３４】
従って、多様な問題及びプログラミング・タスクを解決するフレームワークを開発することによって、ソフトウェアの設計及び開発努力をかなり減らすことができる。本発明の好適な実施形態は、インターネット上でドキュメントを実現するハイパーテキスト・マークアップ言語（ＨＴＭＬ）、及びクライアントとニューコ（Ｎｅｗｃｏ）との間のトランスポート媒体として汎用安全通信プロトコルを利用する。ＨＴＴＰ又は他のプロトコルは、不当な実験なしに容易にＨＴＭＬと置換されることができる。これらの製品に関する情報は、Ｔ．　Ｂｅｒｎｅｒｓ−Ｌｅｅ，　Ｄ．　Ｃｏｎｎｏｌｙ，　“ＲＦＣ　１８６６：Ｈｙｐｅｒｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ−２．０”（Ｎｏｖ．１９９５）、及びＲ．　Ｆｉｅｌｄｉｎｇ，　Ｈ，　Ｆｒｙｓｔｙｋ，　Ｔ．　Ｂｅｒｎｅｒｓ−Ｌｅｅ，　Ｊ．　Ｇｅｔｔｙｓ　ａｎｄ　Ｊ．　Ｃ．　Ｍｏｇｕｌ，　“Ｈｙｐｅｒｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ−ＨＴＴＰ／ｌ．ｌ；　ＨＴＴＰ　Ｗｏｒｋｉｎｇ　Ｇｒｏｕｐ　Ｉｎｔｅｒｎｅｔ　Ｄｒａｆｔ”（Ｍａｙ　２，　１９９６）から得られる。
【００３５】
ＨＴＭＬは、１つのプラットフォームから他のプラットフォームへ持ち運び可能なハイパーテキスト・ドキュメントを作り出すために使用される簡単なデータ・フォーマットである。ＨＴＭＬドキュメントは、広範囲なドメインからの情報を表すのに適した一般的意味を有するＳＧＭＬドキュメントである。ＨＴＭＬは、１９９０年からワールド・ワイド・ウェブ世界情報イニシアチヴによって使用される。ＨＴＭＬは、ＩＳＯ標準８８７９；１９８６情報処理テキスト及びオフィス・システム；標準汎用マークアップ言語（ＳＧＭＬ）のアプリケーションである。
【００３６】
今日まで、ウェブ開発ツールは、ダイナミックなウェブ・アプリケーションを作り出す能力において制限されてきた。このようなアプリケーションは、クライアントからサーバまでを包含し、既存のコンピューティング・リソースと相互に運用される。最近まで、ＨＴＭＬは、ウェブ・ベースの解決法を開発ときに使用される支配的な技術であった。しかし、ＨＴＭＬは、次の分野で適切でないことが証明された：
・貧弱なパフォーマンス；
・制限されたユーザ・インタフェース能力；
・静的ウェブ・ベージの生成に限られた能力；
・既存のアプリケーション及びデータとの相互運用性の欠乏；
・スケーリング能力の欠乏。
【００３７】
サン・マクロシステムズのＪａｖａ言語は、次のようにしてクライアント側の問題の多くを解決する：
・クライアント側のパフォーマンスを改善することによって；
・ダイナミックでリアルタイムのウェブ・アプリケーションの作成を可能にすることによって；
・多様なユーザ・インタフェース・コンポーネントの作成能力を提供することによって。
【００３８】
Ｊａｖａを使用すると、開発者は、ロバストなユーザ・インタフェース（ＵＩ）コンポーネントを作成することができる。カスタム「ウィジェット」（例えば、リアルタイム株式相場表示器、アニメ化アイコンなど）を作成することができ、クライアント側のパフォーマンスが改善される。ＨＴＭＬとは異なり、Ｊａｖａはクライアント側における妥当性検証の概念をサポートし、適切な処理をクライアントへアンロードしてパフォーマンスを改善する。ダイナミックでリアルタイムのウェブ・ページを作成することができる。前述したカスタムＵＩコンポーネントを使用して、ダイナミックなウェブ・ページを作成することができる。
【００３９】
サンのＪａｖａ言語は、「インターネットをプログラミングする」企業認識言語として現れた。サンは、Ｊａｖａを「簡単、オブジェクト指向、分散性、解釈的、ロバスト、安全、アーキテクチャ中立、ポータブル、高パフォーマンス、マルチスレッド、ダイナミック、専門語に従順な汎用プログラミング言語」として定義する。「Ｊａｖａは、プラットフォーム独立Ｊａｖａアプレットの形式で、インターネットのプログラミングをサポートする。」Ｊａｖａアプレットは、サンのＪａｖａアプリケーション・プログラミング・インタフェース（ＡＰＩ）と合致する小さな専門アプリケーションであり、開発者は「インタラクティブ・コンテンツ」をウェブ・ドキュメントへ追加することができる（例えば、簡単なアニメーション、ページ飾り、基本ゲームなど）。アプレットは、サーバからクライアントへコードをコピーすることによって、Ｊａｖａ互換ブラウザ（例えば、ネットスケープ・ナビゲータ）の中で実行する。言語の観点からは、Ｊａｖａの中心的関数セットは、Ｃ＋＋に基づいている。サンのＪａｖａ説明書は、Ｊａｖａが、基本的に、「よりダイナミックな方法の解決法を目的としたオブジェクティブ・シーからの拡張を有するＣ＋＋である」と述べている。
【００４０】
ＪＡＶＡと類似の機能を提供する他の技術は、マイクロソフトのＡｃｔｉｖｅＸ技術によって提供される。この技術は、インターネット及びパーソナル・コンピュータのためにダイナミックなコンテンツを構築する必要手段を開発者及びウェブ設計者に与える。ＡｃｔｉｖｅＸは、アニメーション、３Ｄ仮想現実、ビデオ、及び他のマルチメディア・コンテンツを開発するツールを含む。ツールは、インターネット標準を使用し、多数のプラットフォーム上で働き、１００を超える会社によってサポートされる。グループのビルディング・ブロックは、ＡｃｔｉｖｅＸコントロールと呼ばれ、開発者がソフトウェアの部分をハイパーテキスト・マークアップ言語（ＨＴＭＬ）ページの中に埋め込むことを可能にする小さくて高速のコンポーネントである。ＡｃｔｉｖｅＸコントロールは、多様なプログラミング言語と一緒に働く。そのようなプログラミング言語は、マイクロソフトのＶｉｓｕａｌ　Ｃ＋＋、ボーランドのＤｅｌｐｈｉ、マイクロソフトのＶｉｓｕａｌ　Ｂａｓｉｃプログラミング・システム、及び将来には、マイクロソフトのＪａｖａ開発ツールであるコード名「Ｊａｋａｒｔａ」を含む。ＡｃｔｉｖｅＸ技術は、更に、ＡｃｔｉｖｅＸサーバ・フレームワークを含む。これは、開発者がサーバ・アプリケーションを作成することを可能にする。本発明を実施するため、不当な実験をすることなくＪＡＶＡをＡｃｔｉｖｅＸで置換できることは、当業者によって容易に理解される。
【００４１】
好適な実施形態は、ヘンデルによって開発されたプログラミング言語であるＨａｎｄｅｌ−Ｃを使用して書かれる。Ｈａｎｄｅｌは、カスタム同期ハードウェアへコンパイルするために設計されたプログラミング言語であった。この言語は、「“Ｃｏｍｐｉｌｉｎｇ　ｏｃｃａｍ　ｉｎｔｏ　ＦＰＧＡｓ”，　Ｉａｎ　Ｐａｇｅ　ａｎｄ　Ｗａｙｎｅ　Ｌｕｋ　ｉｎ　“ＦＰＧＡｓ”　Ｅｄｓ．　Ｗｉｌｌ　Ｍｏｏｒｅ　ａｎｄ　Ｗａｙｎｅ　Ｌｕｋ，　ｐｐ２７１−２８３，　Ａｂｉｎｇｄｏｎ　ＥＥ　＆　ＣＳ　Ｂｏｏｋｓ，　１９９１」で始めて説明された。この文献は、参照してここに組み込まれる。Ｈａｎｄｅｌは、Ｈａｎｄｅｌ−Ｃの多様なバージョンを作成するため、後にＣ類似のシンタックスを与えられた（「“Ａｄｖａｎｃｅｄ　Ｓｉｌｉｃｏｎ　Ｐｒｏｔｏｔｙｐｉｎｇ　ｉｎ　ａ　Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ　Ｅｎｖｉｒｏｎｍｅｎｔ”，　Ｍ．　Ａｕｂｕｒｙ，　Ｉ．　Ｐａｇｅ，　Ｄ．　Ｐｌｕｎｋｅｔｔ，　Ｍ．　Ｓａｕｅｒ　ａｎｄ　Ｊ．　Ｓａｕｌ，　Ｐｒｏｃｅｅｄｉｎｇｓ　ｏｆ　ＷｏＴＵＧ　９８，　１９９８」に説明される。この文献も、参照してここに組み込まれる）。
【００４２】
Ｈａｎｄｅｌ−Ｃは、Ｃｅｌｏｘｉｃａ社（Ｃｅｌｏｘｉｃａ　Ｌｉｍｉｔｅｄ，　７−８　Ｍｉｌｔｏｎ　Ｐａｒｋ，　Ａｂｉｎｇｄｏｎ，　Ｏｘｆｏｒｄｓｈｉｒｅ，　ＯＸ１４　４ＲＴ，　Ｕｎｉｔｅｄ　Ｋｉｎｇｄｏｍ）によって販売されたプログラミング言語である。それは、ソフトウェア又はハードウェア・エンジニアが、ハードウェア記述言語に頼ることなく、古典的なマイクロプロセッサ・クロスコンパイラ開発ツールと同じ方法でＦＰＧＡ（フィールドプログラマブルゲートアレイ）を直接標的にすることを可能にし、従って、設計者は、ＦＰＧＡの生のリアルタイム・コンピューティング能力を直接実現することができる。
【００４３】
Ｈａｎｄｅｌ−Ｃは、同期ハードウェアへプログラムをコンパイルできるように設計される。それは、高レベルのアルゴリズムをゲート・レベルのハードウェアへ直接コンパイルすることを目的とする。
【００４４】
Ｈａｎｄｅｌ−Ｃのシンタックスは、通常のＣのシンタックスに基礎を置いている。従って、通常のＣに慣れたプログラマは、Ｈａｎｄｅｌ−Ｃ言語の殆ど全ての構文を理解するであろう。この技術分野に知識を有しない業者のために、Ｈａｎｄｅｌ−Ｃのプログラミングに関する詳細情報は、「Ｈａｎｄｅｌ−Ｃ　Ｕｓｅｒ　ｍａｎｕａｌ」、「Ｈａｎｄｅｌ−Ｃ　Ｌａｎｇｕａｇｅ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ：ｖｅｒｓｉｏｎ　３」、「Ｈａｎｄｅｌ−Ｃ　Ｉｎｔｅｒｆａｃｉｎｇ　ｔｏ　ｏｔｈｅｒ　ｌａｎｇｕａｇｅ　ｃｏｄｅ　ｂｌｏｃｋｓ」、及び「Ｈａｎｄｅｌ−Ｃ　Ｐｒｅｐｒｏｃｅｓｓｏｒ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ」と題する文献で提供される。これらの各々は、Ｃｅｌｏｘｉｃａ社（Ｃｅｌｏｘｉｃａ　Ｌｉｍｉｔｅｄ，　７−８　Ｍｉｌｔｏｎ　Ｐａｒｋ，　Ａｂｉｎｇｄｏｎ，　Ｏｘｆｏｒｄｓｈｉｒｅ，　ＯＸ１４　４ＲＴ，　Ｕｎｉｔｅｄ　Ｋｉｎｇｄｏｍ）から入手可能である。これらの文献は、全ての目的のために、参照してその全体をここに組み込まれる。
【００４５】
シーケンシャル・プログラムは、通常のＣのようにＨａｎｄｅｌ−Ｃで書かれることができるが、目標のハードウェアから最良のパフォーマンスを得るためには、その固有のパラレリズムを利用しなければならない。
【００４６】
Ｈａｎｄｅｌ−Ｃは、プログラマが、この利点をアプリケーションで利用する手段を提供する並行構文を含む。コンパイラは、Ｈａｎｄｅｌ−Ｃソース・コードを、シミュレーションに適したファイルへ、又は配置されて現実のＦＰＧＡへ回送されることのできるネットリストへ、コンパイル及び最適化する。
【００４７】
注意すべきは、他のプログラミング及びハードウェア記述言語、例えばＶＨＤＬも利用できることである。
【００４８】
ネットワーク構成可能ハードウェア
このセクションでは、ネットワーク接続を介して再構成されることができ、シリコンの中に直接構築されたソフトウェア・アプリケーションを走らせるハードウェアを使用して、本発明の例示的実施形態に従った柔軟なマルチメディア・デバイスの開発を詳細に説明する。
【００４９】
この目的のために開発された例示的プラットフォームは、マルチメディア端末（ＭＭＴ）と呼ばれる。その特徴は、専用の蓄積プログラム及び中央処理装置（ＣＰＵ）を有しないことである。その代わりに、プログラムはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）の中に実現される。ＦＰＧＡは、周辺装置を制御してデータを処理するために使用され、再構成可能なロジック及びソフトウェア設計方法のみを使用してＣＰＵ類似の柔軟性を作り出す。
【００５０】
ＦＰＧＡは、マイクロプロセッサ及びオペレーティング・システムに関連するオーバーヘッドなしにアプリケーションを走らせるソフトなハードウェアを作り出すために使用されることができる。そのようなハードウェアは、ネットワーク接続を介して全面的に再構成可能であり、改良、修理、又は完全に新しいアプリケーションを提供する。再構成可能であることは、ハードウェアが設計されたとき想像することのできなかった標準及びアプリケーションの発展を柔軟にサポートすることによって、廃棄を無用にする。これは、更に、製造業者が、インターネット再構成可能ロジックを使用して、装置がどこに存在していても、任意の時点でハードウェア設計を遠隔からアクセスして変更することを可能にする。
【００５１】
本発明の１つの例示的実施形態に従ったＭＭＴは、２つの独立した百万ゲートＸｉｌｉｎｘ　ＸＣＶ１０００　Ｖｉｒｔｅｘ　ＦＰＧＡを使用することによって、柔軟な再構成可能性を達成する。ＦＰＧＡの１つは、デバイスがスイッチオンにされたとき、ネットワーク機能を静的に構成されたままに残される。他のＦＰＧＡは、マスターによって提供されたデータで再構成される。２つのＦＰＧＡは、共通の譲受人へ譲渡された「ＳＹＳＴＥＭ，　ＭＥＴＨＯＤ，　ＡＮＤ　ＡＲＴＩＣＬＥ　ＯＦ　ＭＡＮＵＦＡＣＴＵＲＥ　ＦＯＲ　ＤＡＴＡ　ＴＲＡＮＳＦＥＲ　ＡＣＲＯＳＳ　ＣＬＯＣＫ　ＤＯＭＡＩＮ」と題する米国特許出願で説明されるように、４ビットがハンドシェーキングに予約された３６ビット・バス、及び２つの１６ビット単方向チャネルを介して直接通信する。この米国特許出願は、全ての目的のために、参照してここに組み込まれる。２つのＦＰＧＡが異なったスピードで刻時されるときでも、プロトコルは信頼性のある通信の使用を保証する。
【００５２】
ＭＭＴの他のコンポーネントは、ＬＣＤタッチスクリーン、オーディオ・チップ、１０Ｍｂｐｓイーサネット、パラレルポート、シリアルポート、３つのＲＡＭバンク、及び１つの不揮発性フラッシュ・メモリ・チップである。
【００５３】
ＦＰＧＡの再構成は、２つの方法の１つを使用して実行されることができる。第１の方法は、静的ＦＰＧＡ上でＸｉｌｉｎｘセレクトマップ・プログラミング・プロトコルを実現する。この静的ＦＰＧＡは他のＦＰＧＡをプログラムすることができる。第２の方法は、ネットワーク・インタフェース又はフラッシュ・メモリからＭＭＴ上に再構成データを供給する。フラッシュ・メモリからの再構成は、アプリケーションが終了したとき、又はネットワークを介する構成が失敗したとき、パワーアップ時にインターネット・プロトコル経由音声（ＶｏＩＰ）電話のＧＵＩをスレーブＦＰＧＡへロードするためにだけ使用される。ネットワーク・ベースの再構成は、サーバへのＴＣＰ接続を介するハイパーテキスト転送プロトコル（ＨＴＴＰ）を使用する。ファイル要求を含むテキスト・ストリングが、ＭＭＴによってサーバへ送られ、次に、サーバは、再構成データ（ビットファイル）を送り返す。
【００５４】
以上のように、選択されたアプリケーションをＦＰＧＡの中で走らせることのできる柔軟なアーキテクチャが呈示された。これから、それら全てのアプリケーションを書く方法、及びそれを合理的な時間内で行なう方法を説明する。ハードウェア記述言語（ＨＤＬ）は、インタフェース・ロジックを作成し、低レベルの時間問題を有するハードウェア設計を定義するためには適している。しかし、ＨＤＬは、ネットワーキング、ＶｏＩＰ、ＭＰ３、及びビデオゲームには適していないであろう。
【００５５】
前述したシステムのチャレンジに応じるため、Ｈａｎｄｅｌ−Ｃを使用してＭＭＴ設計を行うことができる。それは、ＡＮＳＩ−Ｃに基づいており、Ｃソフトウェア開発を行なった人によって早く習得される。パラレリズム、任意の幅の変数、及びハードウェア設計でよく知られた他の特徴をサポートする拡張が行なわれたが、それはソフトウェア設計の方法論にかなり目標を置いている。ＣをＨＤＬへ変換する従来技術のＣベース解決法とは異なり、Ｈａｎｄｅｌ−ＣコンパイラはＥＤＩＦネットリストを直接合成する。このネットリストは、即時に配置、回送、及びＦＰＧＡへ組み込まれることができる。
【００５６】
パワーアップ時にＭＭＴの例示的実施形態上で走るデフォルトのアプリケーションは、ＧＵＩを完備したインターネット・プロトコル経由音声（ＶｏＩＰ）電話である。インターネット・プロトコル経由音声は、呼び出し状態マシン、呼び出し交渉メカニズム、及びサウンド処理リアルタイム・プロトコル（ＲＴＰ）モジュールを含む。ＧＵＩからのメッセージと呼び出し交渉装置の組み合わせは、状態マシンを駆動するために使用される。
【００５７】
呼び出し交渉装置によって実現されたプロトコルは、Ｈ．３２３Ｆａｓｔｓｔａｒｔのサブセットである（Ｈ２２５及びＱ９３１を含む）。このプロトコルは、２つのＩＰ電話の間でストリーム・ベースの接続を確立するためＴＣＰを使用する。ＲＴＰモジュールは、入サウンド・パケットを処理し、ＵＤＰを介して送られる出パケットを生成することに責任を有する。
【００５８】
プロトコル、例えば、ＲＴＰ、ＴＣＰ、ＩＰ、及びＵＤＰのためのアルゴリズムは、既存のパブリック・ドメインのＣソースから引き出されることができる。ソース・コードは、Ｈａｎｄｅｌ−Ｃで利用可能な特徴、例えば、パラレリズムを使用するため最適化されることができる。一般的に、パケット・ヘッダ内のフィールドが連続的に読み込まれることを必要とし、通常、ステージが並行に走っているパイプラインによって実行されることのできるネットワーク・プロトコルにとって、パラレリズムは有用である。各々のステージは、１つのＨａｎｄｅｌ−Ｃ環境の中でテスト及びシミュレートされ、ＥＤＩＦネットリストを生成することによって直接組み込まれることができる。更なる最適化及び同調は、単に、ネットワークを介して最新のバージョンをＭＭＴへダウンロードすることによって迅速に実行されることができる。
【００５９】
アーキテクチャに柔軟性があるため、及びインターネット再構成可能性を利用するため、アプリケーションの混合バッグを開発することができる。アプリケーションの全ては、ＭＭＴ上のハードウェアの中で走る。アプリケーションの中には、ＧＵＩを有する完全機能ＭＰ３プレーヤ、幾つかのビデオゲーム、及び幾つかの印象的グラフィックス・デモンストレーションが存在する。これらは全てＨａｎｄｅｌ−Ｃを使用して開発された。これらのアプリケーションは、サーバ上でビットファイルとしてホストされる。サーバは、ネットワーク接続を介して、これらのファイル、ＭＭＴのユーザからの要求に応じて供給する。
【００６０】
インタフェース
本発明によると、構成ファイルを定義して、コンピュータから再構成可能ロジックデバイスへ転送する直観的インタフェースが提供される。図２は、再構成可能ロジックデバイス、例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックデバイス（ＰＬＤ）、又はコンプレックスプログラマブルロジックデバイス（ＣＰＬＤ）へ構成データを転送するインタフェースを提供するプロセス２００の流れ図である。操作２０２において、再構成可能ロジックデバイスへ接続されたディスプレイ上に画像が呈示される。操作２０４において、ユーザは、１つ又は複数の画像を選択することによって、再構成可能ロジックデバイスを構成するコマンドを入力することができる。操作２０６で、構成データは、コンピュータから再構成可能ロジックデバイスへ転送される。構成データは、操作２０８で再構成可能ロジックデバイスを再構成するために使用される。
【００６１】
他の実施形態は、タッチ敏感液晶（ＬＣＤ）、ユーザをガイドするビットマップ画像として呈示されるボタンを含む。ボタンは、ユーザがデバイス及びそのコンポーネントをインタラクティブに構成するようにガイドし、インターネット及びワイヤレス・ネットワークを介してダウンロードを提供する。
【００６２】
好適な実施形態において、再構成可能ロジックデバイスは、後の使用のために構成データを保存することができる。他の実施形態において、再構成可能ロジックデバイスの操作を制御するコマンドを入力するため、ディスプレイを操作することができる。
【００６３】
例１
図３は、本発明の１つの実施形態に従ったディスプレイ３００を示す。ディスプレイは、再構成可能ロジックデバイス、例えば、図９〜図１５を参照して後で説明されるデバイスへ接続される。オプションとして、ディスプレイはデバイスと一体化されてよい。
【００６４】
デバイスをイニシエートする例示的手順４００が図４に示される。操作４０２でデバイスはネットワークへ接続され、操作４０４で電源へ接続される。ディスプレイは、操作４０６で較正される。操作４０８で、電源を接続されたデバイスはデフォルトのプログラミングでブートする。この例において、デバイスはＩＰ電話としてブートし、呼び出しを受け入れ／受信する準備を整える。
【００６５】
再び図３を参照すると、ディスプレイは幾つかのビットマップ・ボタンを含む。ユーザは、ビットマップ・ボタンを使用して、インターネット電話のセッションで使用されるコマンドを入力することができる。キーパッド・ボタン３０２は、電話を入れるＩＰアドレスを入力するために使用される。ステータス・ウィンドウ３０４は、デバイスの状態を表示する。
【００６６】
本発明によると、ハードウェア・ベースの再構成可能インターネット電話システムを提供することができる。システムは、ネットワーキング機能を使用して構成される第１のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。ユーザ・インタフェースは、ユーザへ情報を与えユーザからコマンドを受け取るために、第１のＦＰＧＡと通信する。第１のＦＰＧＡと通信するマイクロフォンは、ユーザから音声データを受け取る。通信ポートは、第１のＦＰＧＡ及びインターネットと通信する。第１のＦＰＧＡは、呼び出し状態マシン、呼び出し交渉メカニズム、及びサウンドを処理するリアルタイム・プロトコル（ＲＴＰ）モジュールを提供するために構成される。呼び出しを入れる方法の更なる詳細は、図５〜図７に関連する説明を参照されたい。
【００６７】
本発明の１つの実施形態によると、システムと他のインターネット電話システムとの間に、ストリーム・ベースの接続が生成される。本発明の他の実施形態において、第２のアプリケーションを走らせるため第２のＦＰＧＡが構成される。そのような実施形態において、第１のＦＰＧＡは、好ましくは、第２のＦＰＧＡを構成することができる。
【００６８】
本発明の実施形態において、ＲＴＰモジュールは、入サウンド・パケットを処理し、出サウンド・パケットを生成する。好適な実施形態において、ユーザ・インタフェースはタッチスクリーンを含む。
【００６９】
図５は、デバイスを使用して電話を入れるプロセス５００を示す。（プロセス・フローは、上から下へ進む。）ナンバー・キーが押され、次に、呼び出されるＩＰアドレスが入力される。ナンバーが押されるにつれて、それらのナンバーはステータス・ウィンドウに現れる。一度、ナンバーが入力されると、接続を行なうため受け入れボタン３０６が押される。「呼び出し中」の語句がステータス・ウィンドウに現れて、接続が係属中であることを示す。接続が行なわれると、「接続済み」がステータス・ウィンドウに現れる。呼び出しを終了するには、終了ボタン３０８が押される。
【００７０】
図６は、呼び出しに応答するプロセス６００を示す。ステータス・ウィンドウは「着信」を表示し、デバイスはトーンを出してよい。ユーザは、呼び出しに応答するため受け入れボタンを選択する。終了ボタンの選択は呼び出しを終了させる。
【００７１】
図７は、電話機能の様々なパラメータを設定する構成スクリーン７００を示す。プラス及びマイナス符号を有するボタン７０２及び７０４は、スピーカの音量、マイクロフォンの音量などを増加及び減少させるために使用される。ミュート・ボタン７０６及びディスプレイ輝度ボタン７０８が設けられる。
【００７２】
当業者は、デバイスが従来の電話のように動作し、従って、デバイスは、そのような電話で見出される特徴の多くを含むことを理解するであろう。
【００７３】
図３に示されるスクリーンは、前述したボタンのほかに幾つかのボタンを含む。ｍｐ３ボタン３１０を選択すると、ダウンロード・シーケンスがイニシエートされる。このダウンロード・シーケンスは、デバイスを再構成してｍｐ３フォーマットでオーディオを再生するための構成情報を要求するように、デバイスに命令する。一度、構成情報が受け取られると、デバイスはそれ自身を再構成してｍｐ３オーディオを再生する。
【００７４】
再構成するとき、ディスプレイは、図８Ａに示されるスクリーン８００を呈示する。表示される様々なボタンは、再生ボタン８０２、停止ボタン８０４、逆方向追跡及び順方向追跡ボタン８０６及び８０８、休止ボタン８１０、ミュート・ボタン８１２、音量アップ及び音量ダウン・ボタン８１４及び８１６、及びデフォルトのプログラム、この場合はＩＰ電話プログラムへ戻る出口ボタン８１８を含む。
【００７５】
保存ボタン８２０を選択すると、もしデバイスが十分な情報記憶装置へのアクセスを有するならば、ダウンロードを必要としないでデバイスを再構成するための構成情報が記憶される。
【００７６】
再び図３を参照すると、ゲーム・ボタン３１２の選択は、ダウンロード・シーケンスをイニシエートする。このシーケンスは、デバイスを再構成してゲームをプレーさせる構成情報の要求をデバイスに命令する。
【００７７】
マルチメディア・デバイス
図８Ｂは、ハードウェア・ベースの再構成可能マルチメディア・デバイスを提供するプロセス８５０を示す。操作８５２において、デフォルトのマルチメディア・アプリケーションが、再構成可能マルチメディアロジックデバイス上でイニシエートされる。マルチメディアロジックデバイスは、図９から図１５に関して説明されるデバイスと類似のデバイスであってよい。操作８５４で、第２のマルチメディア・アプリケーションに対する要求がユーザから受け取られる。構成データは、操作８５６でデータ・ソースから検索され、操作８５８でロジックデバイスを構成して第２のマルチメディア・アプリケーションを走らせるために使用される。操作８６０で、第２のマルチメディア・アプリケーションがロジックデバイス上で走る。
【００７８】
本発明によると、マルチメディア・アプリケーションは、オーディオ・アプリケーション、ビデオ・アプリケーション、音声ベース・アプリケーション、ビデオゲーム・アプリケーション、及び／又は他の任意タイプのマルチメディア・アプリケーションを含むことができる。
【００７９】
本発明の１つの実施形態において、構成データは、ネットワーク、例えば、インターネットを利用して、ロジックデバイスから遠隔に置かれたサーバから検索される。
【００８０】
本発明の他の実施形態において、ロジックデバイスは１つ又は複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。理想的には、第１のＦＰＧＡは、構成データを受け取り、第２のＦＰＧＡを構成するために構成データを使用する。本発明の他の実施形態は、異なったスピードで刻時される第１及び第２のＦＰＧＡを含む。好適な実施形態において、デフォルトのマルチメディア・アプリケーション及び第２のマルチメディア・アプリケーションの双方は、ＦＰＧＡの数に関係なくロジックデバイス上で同時に走ることができる。
【００８１】
例示的再構成可能ロジックデバイス
本発明の好適な実施形態に従った再構成可能ロジックデバイスは、２つのＦＰＧＡが相互に話すことを可能にする双方向１６ビット通信ドライバを含む。１つのＦＰＧＡから他のＦＰＧＡへの全てのメッセージは、１６ビットＩＤを前に置かれる。１６ビットＩＤの８つの高ビットはメッセージのタイプ（オーディオ、フラッシュ、再構成など）を識別し、低ビットはそのハードウェアに対する特定の要求（フラッシュ読み出しなど）を識別する。ＩＤコードはヘッダ・ファイルｆｐ０ｓｅｒｖｅｒ．ｈで処理され、メッセージの各々のタイプに対して適切なマクロ手順が呼び出される（例えば、オーディオに対してはＡｕｄｉｏＲｅｑｕｅｓｔが呼び出される）。次に、マクロ手順は通信のメイン・ボディーを受け取って処理する。
【００８２】
好ましくは、ＦＰＧＡは外部メモリにアクセス可能にされる。更に好ましくは、ＦＰＧＡが同じリソースにアクセスするときＦＰＧＡの間の衝突を避けるため、アービトレーションが備えられる。更に、１つのＦＰＧＡから他のＦＰＧＡへパスするとき、ドライバ及びハードウェアを停止及び再イニシエートする必要性が除かれる。
【００８３】
オプションとして、通信が進行している間、共用リソースを他のプロセスからロックすることができる。この通信は、ＦＰＧＡ相互間の通信、及び／又はＦＰＧＡとリソースとの間の通信を含むことができる。
【００８４】
本発明の１つの実施形態において、ＦＰＧＡの１つの上のアプリケーションは、ＦＰＧＡの他の１つへコマンドを送るようにされる。本発明の他の実施形態において、１つ又は複数のＦＰＧＡが、リソースにアクセスできるように再構成される。
【００８５】
使用されるとき、サーバ・プロセスは、多数のパラメータが渡されることを必要とする。次のようなパラメータがある：
・ＰＩＤ：通信の進行中に、他のプロセスから共用リソース（例えば、フラッシュ）をロックするために使用される；
・ｕｓｅｎｄＣｏｍｍａｎｄ、ｕＳｅｎｄＬｏｃｋ：ＦＰ０上のアプリケーションがＦＰ１上のアプリケーションへコマンドを送るようにするチャネル、及びデータがサーバ送信データとインタリーブしないことを確実にする１ビット・ロック変数；
・ｕＳｏｕｎｄＯｕｔ、ｕＳｏｕｎｄＩｎ：オーディオ・ドライバの機能をミラーリングする２つのチャネル。ｕＳｏｕｎｄＯｕｔへ送られたデータは、ＭＭＴ２０００スピーカから再生され（正しいコードがＦＰ１にあるものと仮定する）、ｕＳｏｕｎｄＩｎから読み出されたデータはＭＭＴ２０００マイクロフォンへの入力となる。チャネルは、サウンド・ドライバがブロックしたとき、ＦＰＧＡ間の通信チャネルが停止しないように実現される；
・ＭＰ３Ｒｕｎ：ＭＰ３　ＧＵＩを制御する１ビット変数。サーバは、ＦＰ１からコマンドを受け取ったとき、ＭＰ３　ＧＵＩを活性化又は非活性化する；
・ＣｏｎｆｉｇＡｄｄｒ：再構成プロセスを制御する２３ビット・チャネル。有効なＦＰＧＡビットファイルのフラッシュ・アドレスがこのチャネルへ送られたとき、サーバは、指定されたビットマップでＦＰ１を再構成する。
【００８６】
異なったクロック・レートで走っているＦＰＧＡの間で通信するため、双方の方向における２つのＦＰＧＡの間のデータ転送レートは、好ましくは、約１６ビット／５クロック・サイクルである（最も遅いＦＰＧＡのクロック領域で）。
【００８７】
本発明の様々な実現形態で使用するため生成される幾つかのＨａｎｄｅｌ−Ｃマクロは、表１に記載される。前記の参照によって組み込まれた文献「Ｈａｎｄｅｌ−Ｃ　Ｌａｎｇｕａｇｅ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ：ｖｅｒｓｉｏｎ　３」は、Ｈａｎｄｅｌ−Ｃでマクロを生成するときの詳細情報を提供する。
【表１】

【００８８】
例示的デバイス開発プラットフォーム＼
図９は、本発明の例示的実施形態に従ったリソース管理デバイスのボード９００を示す略図である。注意すべきは、以下の説明が本発明の例示的実施形態を説明するためのものであり、本発明の様々な実施形態は、この説明によって限定されないことである。図示されるように、ボードは、２つのＸｉｌｉｎｘ　Ｖｉｒｔｅｘ（商標）２０００ｅ　ＦＰＧＡ　９０２及び９０４、Ｉｎｔｅｌ　ＳｔｒｏｎｇＡＲＭ　ＳＡ１１１０　プロセッサ９０３、大容量メモリ９０８及び９１０、並びに多数のＩ／Ｏポート９１２を含むことができる。その主な特徴が、次にリストされる：
２つのＸＣＶ　２０００ｅ　ＦＰＧＡ。その各々は次のデバイスへの単独アクセスを有する：
ＳＲＡＭ（２５６Ｋｘ３２ビット幅）の２つのバンク（各々は１ＭＢ）；
パラレルポート；
シリアルポート；
ＡＴＡポート；
ＦＰＧＡは次のデバイスを共用する：
ＶＧＡモニタポート；
８つのＬＥＤ；
共用ＳＲＡＭ（更に、ＣＰＵと共用される）の２つのバンク；
ＵＳＢインタフェース（更に、ＣＰＵと共用される）。
【００８９】
ＦＰＧＡは、汎用Ｉ／Ｏ（ＧＰＩＯ）バス、３２ビット選択リンク・バス、及び外部装置がＦＰＧＡへ接続されることを可能にするコネクタを有する３２ビット拡張バスを介して、相互に接続される。ＦＰＧＡは、可変待ち時間Ｉ／Ｏ装置として、ＳｔｒｏｎｇＡＲＭプロセッサのメモリへマップされる：
Ｉｎｔｅｌ　ＳｔｒｏｎｇＡＲＭ　ＳＡ１１１０プロセッサは、次のものへのアクセスを有する：
６４ＭバイトのＳＤＲＡＭ；
１６Ｍバイトのフラッシュ・メモリ；
ＬＣＤポート；
ＩＲＤＡポート；
シリアルポート；
それは、ＵＳＢポート及び共用ＳＲＡＭをＦＰＧＡと共用する。
【００９０】
更に、ボードはＸｉｌｉｎｘ　ＸＣ９５２８８ＸＬ　ＣＰＬＤを有する。このＣＰＬＤは、多数のグルー（ｇｌｕｅ）論理関数を実現し、共用ＲＡＭアービタ、可変レート・クロック・ジェネレータ、及びＦＰＧＡ構成のためのＪＴＡＧ並びにＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭＡＰサポートとして働く。
【００９１】
ＡＲＭプロセッサとＦＰＧＡとの間で、多数の通信メカニズムが可能である。ＦＰＧＡはＡＲＭメモリの中へマップされる。これは、ＦＰＧＡが、ＲＡＭデバイスであるかのようにＡＲＭからアクセスされるようにする。ＦＰＧＡは、更に、ＳＲＡＭの２つの１ＭＢバンクをプロセッサと共用する。これは、ＤＭＡ転送が実行されることを可能にする。更に、ＦＰＧＡとＡＲＭとの間には、ＡＲＭの汎用Ｉ／Ｏ（ＧＰＩＯ）レジスタを介する多数の直接接続が存在する。
【００９２】
ボードは、４つのクロック及び２つの固定周波数の、２つのＰＬＬを組み込まれる。ＰＬＬはＡＲＭプロセッサによってプログラム可能である。
【００９３】
ＡＲＭは、パワーアップのとき、ＡＲＭオンボード・デバッギング・モニタであるエンゼル（Ａｎｇｅｌ）へブートされる。このモニタは、シリアルリンクを介してホストＰＣ上のＡＲＭデバッガへ接続されることができる。これによって、アプリケーションは、ホスト上で容易に開発され、ボード上で走ることができる。
【００９４】
ＦＰＧＡを構成する方法は多様である。それらの方法は、次の通りである：
・ＪＴＡＧ又はＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭＡＰを使用する外部ホストによって；
・フラッシュＲＡＭのいずれかに記憶されたデータ、又はシリアルポート（ＵＳＢ、ＩＲＤＡ、又はＲＳ２３２）の１つを介して獲得されたデータを使用するＡＲＭプロセッサによって；
・ＦＰＧＡフラッシュＲＡＭの特定のロケーションに記憶されたデータを使用してパワーアップするＣＰＬＤによって；
・他のＦＰＧＡの１つによって。
【００９５】
ＳｔｒｏｎｇＡＲＭ
ボードは、Ｉｎｔｅｌ　ＳＡ１１１０　ＳｔｒｏｎｇＡＲＭプロセッサを組み込まれる。このプロセッサは、ローカルに接続された６４ＭバイトのＳＤＲＡＭ、及び１６ＭバイトのＩｎｔｅｌ　ＳｔｒａｔａＦＬＡＳＨ（商標）を有する。プロセッサはＩｎｔｅｌ　ＳｔｒａｔａＦＬＡＳＨ（商標）からブートしてよい。プロセッサはＦＰＧＡへの直接接続を有する。ＦＰＧＡは、ＳＲＡＭ類似の可変待ち時間Ｉ／Ｏ装置として、そのメモリ・マップへマップされ、ＵＳＢ、ＩＲＤＡ、ＬＣＤスクリーン・コネクタ、及びシリアルポートを含む様々なＩ／Ｏ装置へアクセスする。それは、更に、プロセッサとＦＰＧＡとの間で共用される２ＭＢのＳＲＡＭへのアクセスを有する。
【００９６】
メモリ・マップ
表２で示されるように、様々なデバイスがＳｔｒｏｎｇＡＲＭメモリ・ロケーションへマップされた。
【表２】

【００９７】
ＳｔｒｏｎｇＡＲＭの内部メモリ構成レジスタのために提案される設定は、表３に示される。
【表３】

ここで、頭字語は次のように定義される：
ＭＤＣＮＦＧ　−ＤＲＡＭ構成レジスタ；
ＭＳＣ０，１，２　−バンク０、１、２のための静的メモリ制御レジスタ；
ＭＤＲＥＦ　−ＤＲＡＭのリフレッシュ制御レジスタ；
ＭＤＣＡＳ　−ＤＲＡＭバンクのためのＣＡＳ回転制御レジスタ；
【００９８】
ＣＰＵクロックは、１９１．７ＭＨｚ（ＣＣＦ＝９）に設定されなければならない。これらのレジスタにアクセスする方法の詳細は、インテル社から入手可能なＳｔｒｏｎｇＡＲＭ　Ｄｅｖｅｌｏｐｅｒｓ　Ｍａｎｕａｌ　を参照されたい。
【００９９】
フラッシュ・メモリ
フラッシュＲＡＭは、ＳＲＡＭ又はＳＤＲＡＭと比較して非常に遅い。それは、ブートにだけ使用されるべきである。コードは、フラッシュＲＡＭから実行のためにＳＤＲＡＭへコピーされることが推奨される。もしフラッシュＲＡＭの内容を更新するためにＳｔｒｏｎｇＡＲＭが使用されるならば、フラッシュからコードを走らせてはならない。そうでないと、フラッシュの中のプログラミング命令が破壊されるであろう。
【０１００】
ＳＤＲＡＭ
標準の６４ＭＢ　ＳＤＲＡＭ　ＳＯＤＩＭＭがボードに組み込まれる。これはＳｔｒｏｎｇＡＲＭのために大容量メモリを提供する。組み込まれたモジュールに依存して、ＳＤＲＡＭはメモリ内で連続して現れないかも知れない。
【０１０１】
共用ＲＡＭバンク
これらのＲＡＭバンクは、双方のＦＰＧＡと共用される。このリソースは、ＣＰＬＤによってアービトレーションされ、ＣＰＬＤがＡＲＭ許可を与えたときだけアクセスされてよい。ＲＡＭをアクセスする許可の要求及び受信は、ＣＰＬＤレジスタ０ｘ１０を介して実行される。ＡＲＭプロセッサからＣＰＬＤ及びその内部レジスタへのアクセスについては、本明細書のＣＰＬＤのセクションを参照されたい。
【０１０２】
ＦＰＧＡアクセス
ＦＰＧＡはＡＲＭのメモリへマップされ、ＳｔｒｏｎｇＡＲＭは、指定されたロケーションを使用してＦＰＧＡへ直接アクセスすることができる。これらのロケーションは可変長アクセスをサポートし、従って、ＦＰＧＡがデータの受信又は送信の準備を完了するまで、ＦＰＧＡはＡＲＭがアクセスを完了するのを防止することができる。ＳｔｒｏｎｇＡＲＭにとって、ＦＰＧＡは静的メモリ・デバイスとして現れる。ＦＰＧＡは、ＲＡＭのデータ、アドレス、及びチップ制御信号へのアクセスを有するであろう。
【０１０３】
ＦＰＧＡは、更に、ＳＡＩＯバスを介してプロセッサのＧＰＩＯブロックへ接続される。ＳＡＩＯバスへのＧＰＩＯピン・マップは、表４に示される。
【表４】

これらの中で、ＳＡＩＯ［０：１０］はＦＰＧＡへ接続し、ＳＡＩＯ［０：１４］はボード上のコネクタＣＮ２５へ接続する。ＦＰＧＡ及びＡＲＭは、更に、共用メモリの２ＭＢへアクセスすることができる。これは、ＤＭＡ転送がデバイスの間で実行されることを可能にする。
【０１０４】
Ｉ／Ｏ装置
次のコネクタが提供される：
・バックライト・コネクタを有するＬＣＤインタフェース・コネクタ；
・ＩＲＤＡコネクタ（５Ｖ許容ではない）；
・ＧＰＩＯピン（５Ｖ許容ではない）；
・シリアルポート；
・ＳｔｒｏｎｇＡＲＭを再ブートするリセット・ボタン。
【０１０５】
これらとＡＲＭプロセッサとの間の接続は、次の表５〜表８で定義される。
【表５】

【表６】

【表７】

【表８】

シリアルポートは、もしハンドシェーキングが必要でなければ、１つの特別のリード線で２つのポートを利用できるように配線される。
【０１０６】
エンゼル
エンゼルは、ＡＲＭプロセッサのためのオンボード・デバッグ・モニタである。それは、シリアルポート（ヌル・モデム・シリアルケーブルが必要となる）を介してホストＰＣと通信する。ＡＲＭは、スタートアップ時にエンゼルへ自動的にブートするようにセットアップされる。これが必要でない場合には、ＡＲＭのフラッシュＲＡＭの中のスタートアップ・コードを変更する必要がある。
【０１０７】
エンゼルが使用されるとき、ＳＤＲＡＭの３２ＭＢがメモリの中で０Ｘ００００００００へマップされ、キャッシュ可能及びバッファ可能としてマークされる（トップの１ＭＢを除いて）。フラッシュ・メモリは０Ｘ４０００００００へ再マップされ、読み出し専用及びキャッシュ可能である。メモリの残りは、１対１にマップされ、キャッシュ可能又はバッファ可能ではない。
【０１０８】
エンゼルのもとでは、ＦＰＧＡプログラマ・ソフトウェアを走らせることが可能である。このソフトウェアは、ホスト・マシンからビットファイルを取り、それを使用してＦＰＧＡをプログラムする。ビットファイルは１ＭＢを超えるサイズであり、シリアルリンクがデータ転送に使用されるから、これはＦＰＧＡを構成する方法としては非常に遅い方法である。
【０１０９】
Ｖｉｒｔｅｘ　ＦＰＧＡ
更に、２つのＶｉｒｔｅｘ　２０００ｅ　ＦＰＧＡがボードに組み込まれる。それらは、パワーアップ時のフラッシュ・メモリを含めて、多様なソースからプログラムされてよい。双方のデバイスは同じコンポーネントを含むが、異なったピンの定義を有する。２つのＦＰＧＡのために、Ｈａｎｄｅｌ−Ｃヘッダ・ファイルが提供される。
【０１１０】
デバイスの１つは「マスター」として割り当てられ、他の１つは「スレーブ」として割り当てられる。これは、基本的にＦＰＧＡを識別する手段であり、共用メモリへの要求がＣＰＬＤによって処理されるとき、マスターはスレーブよりも優先権を有する。
【０１１１】
ＦＰＧＡの各々の上の１つのピンは、マスター／スレーブ定義ピンとして定義される。このピンは、マスターＦＰＧＡ上ではＧＮＤへプルされ、スレーブ上では高に保持される。ピンは次の通りである：
マスターＦＰＧＡ：Ｃ９；
スレーブＦＰＧＡ：Ｄ３３。
【０１１２】
これらのチップのためにＨａｎｄｅｌ−Ｃをコンパイルするとき、次のｐａｒｔ及びｆａｍｉｌｙパラメータを使用しなければならない：
ｓｅｔ　ｆａｍｉｌｙ　＝　Ｘｉｌｉｎｘ４０００Ｅ；
ｓｅｔ　ｐａｒｔ　＝　“ＸＶ２０００ｅ−６−ｆｇ６８０”。
【０１１３】
クロック
２つのソケット・クロック発振器モジュールが、ボードへ組み込まれてよい。ＣＬＫＡは応急的に５０ＭＨｚ発振器を組み込まれ、ＣＬＫＢソケットは、他の倍数周波数が必要であるときユーザによって組み込まれるように残される。＋５Ｖ発振器モジュールが、ＣＬＫＢのために使用されるべきである。
【０１１４】
２つのオンボードＰＬＬ、ＶＣＬＫ、及びＭＣＬＫが、８ＭＨｚから１００ＭＨｚ（１２５ＭＨｚも可能である）までのクロック源を提供する。これらはＡＲＭプロセッサによってプログラム可能である。ＶＬＣＫは、ＡＲＭによってシングルステップにされてよい。
【０１１５】
このクロック源の多様性は、ＦＰＧＡが異なったレートで刻時されることを可能にするか、１つのＦＰＧＡが多数のクロック領域を有することを可能にする。
【０１１６】
表９及び付録Ａ及び付録Ｂに示されるように、クロックはＦＰＧＡへ接続される。
【表９】

【０１１７】
ＦＰＧＡのプログラミング
ＦＰＧＡは多様なソースからプログラムされてよい：
・パラレルＩＩＩケーブルＪＴＡＧ；
・ＭｕｌｔｉＬｉｎｘ　ＪＴＡＧ；
・ＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭＡＰ；
・ＡＲＭプロセッサ；
・他のＦＰＧＡから；
・パワーアップ時のフラッシュ・メモリから（ＦＰＧＡフラッシュ・メモリのセクション）。
【０１１８】
ＪＴＡＧ方法でＦＰＧＡをプログラムするとき、Ｂｉｔｇｅｎコマンドが確実にオプション“−ｇ　ｓｔａｒｔｕｐｃｌｋ：ｊｔａｇｃｌｋ”を渡されるようにしなければならない。更に、ＣＰＬＤのために．ｊｅｄファイル又は．ｂｓｄファイルを必要とするであろう。．ｂｓｄファイルは、”Ｘｉｌｉｎｘ＼ｘｃ９５００ｘｌ＼ｄａｔａ＼ｘｃ９５２８８ＸＬ＿ｔｑ１４４．ｂｓｄ”で見出される。更に、ＳｔｒｏｎｇＡＲＭは．ｂｓｄファイルを必要とする。この．ｂｓｄファイルは、Ｉｎｔｅｌウェブサイトｈｔｔｐ：／／ｄｅｖｅｌｏｐｅｒ．ｉｎｔｅｌ．ｃｏｍ／ｄｅｓｉｇｎ／ｓｔｒｏｎｇ／ｂｓｄｌ／ｓａ１１１０　ｂ１．ｂｓｄで見出される。ダウンロードされたとき、このファイルは、ＨＴＭＬヘッダ及びフッタを含む。これらは最初に除去される必要がある。代替的に、必要な．ｂｓｄファイルのコピーは、供給されるディスク上に含まれる。
【０１１９】
ボードのためのＪＴＡＧチェーン１０００は、図１０に示される。
【０１２０】
ＸｉｌｉｎｘパラレルＩＩＩケーブル及び「ＪＴＡＧプログラマ」を使用するときの接続は、表１０に示される。
【表１０】

Ｘｉｌｉｎｘケーブルを使用する場合、浮動端をＸｉｌｉｎｘポッドへ差し込むことが容易であり、多数のケーブルが一度にボードへ接続されるであろう。
【０１２１】
ＭｕｌｔｉＬｉｎｘ　ＪＴＡＧ
ボードは、ＭｕｌｔｉＬｉｎｘを使用してプログラムするときのサポートを有する。ＣＮ３は、ＭｕｌｔｉＬｉｎｘを使用するＪＴＡＧプログラミングに必要な唯一のコネクタであり、表１１に示されるように配線される。（注意すべきは、使用されない信号は、もし必要であれば、ＭｕｌｔｉＬｉｎｘへ接続されてよいことである。）
【表１１】

【０１２２】
ＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭＡＰ
ＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭＡＰを使用してＦＰＧＡを再構成するとき、ＪＰ３を調整しなければならない。このリンクは、バスの競合を防止するため、ＣＰＬＤがＦＰＧＡデータ・バスにアクセスしないように防止する。更に、これは、ＡＲＭがＦＰＧＡフラッシュ・メモリにアクセスすることを防止し、パワーアップからＦＰＧＡプログラミングを試みることを防止する。コネクタＣＮ３及びＣＮ４はマスターＦＰＧＡのプログラミングに使用すべきであり、ＣＮ１０及びＣＮ１１はスレーブＦＰＧＡのプログラミングに使用すべきである。表１２及び表１３を参照されたい。
【表１２】

【表１３】

【０１２３】
実際には、ＭｕｌｔｉＬｉｎｘ　ＳｅｌｅｃｔＭａｐは、多数の浮動リード線が含まれるためＦＰＧＡをプログラムするには非常に退屈な方法であることが分かった。マルチＦＰＧＡシステムに対するサポートが存在しないことは、ＦＰＧＡの各々を構成するためリード線を異なったコネクタへ接続しなければならないことを意味する。
【０１２４】
ＡＲＭプロセッサ
ＡＲＭは、ＣＰＬＤを介して各々のＦＰＧＡをプログラムすることができる。ＦＰＧＡは、ＳｅｌｅｃｔＭａｐモードで構成されるようにセットアップされる。ＦＰＧＡのプログラミング・ピンにアクセスする方法、及び実際の構成プロセスに関しては、本明細書のＣＰＬＤのセクション及びＶｉｒｔｅｘ構成に関するＸｉｌｉｎｘデータシートを参照されたい。エンゼルのもとでホストＰＣからの．ｂｉｔファイルを使用してＦＰＧＡを構成するＡＲＭプログラムが提供される。しかし、これは非常に遅いプロセスである。なぜなら、ファイルがシリアルリンクを介して転送されるからである。更に、データは、ＵＳＢ、ＩＲＤＡ、又はオンボード・フラッシュＲＡＭを含む多様な他のソースから獲得されることができる。これは、ＦＰＧＡを０．５秒内で構成できなければならない。
【０１２５】
１つのＦＰＧＡの他のＦＰＧＡからの構成
ＡＲＭがＦＰＧＡを構成する場合と同じようにして、１つのＦＰＧＡが、ＣＰＬＤを介して他のＦＰＧＡを構成することができる。詳細については、再び、本明細書のＣＰＬＤのセクション及びＸｉｌｉｎｘデータシートを参照されたい。
【０１２６】
パワーアップ時のフラッシュ・メモリからの構成
ボードは、パワーアップ時に、このメモリに記憶された構成データを使用してＦＰＧＡをブートするように設定されることができる。もしフラッシュＲＡＭからボードをブートする必要があれば、次のジャンパを設定しなければならない：
・マスターＦＰＧＡがパワーアップからプログラムされた場合、ＪＰ１を調整する必要がある；
・スレーブＦＰＧＡがパワーアップからプログラムされた場合、ＪＰ２を調整する必要がある。
【０１２７】
これらのジャンパが使用された場合、フラッシュＲＡＭは、表１４のように組織される必要がある。
【表１４】

【０１２８】
構成データは、．ｂｉｔファイルの全体ではなく、構成ビット・スリームだけでなければならない。．ｂｉｔファイルはヘッダ情報を含む。ヘッダ情報は、最初に除去される必要があり、．ｂｉｔファイルの中に記憶された構成ストリームのバイトは、ミラーリングされる必要がある。即ち、ビット・ファイルの中で００１１０００１として記憶された構成バイトは、１０００１１００としてＦＰＧＡ構成データ・ピンへ適用される必要がある。
【０１２９】
Ｘｉｌｉｎｘ　ＦＰＧＡの構成及び．ｂｉｔフォーマットに関する詳細情報については、適切なＸｉｌｉｎｘデータシートを参照されたい。
【０１３０】
ＦＰＧＡ　フラッシュ・メモリ
Ｉｎｔｅｌ　ＳｔｒａｔａＦＬＡＳＨ（商標）フラッシュ・メモリの１６ＭＢをＦＰＧＡに使用することができる。これは、２つのＦＰＧＡ及びＬＣＰＤの間で共用され、それらへ直接接続される。フラッシュＲＡＭは、ボード上のＳＲＡＭよりも非常に遅く、１２０ｎｓの読み出しサイクル及び約８０ｎｓの書き込みサイクルを有する。
【０１３１】
ＦＰＧＡは、メモリに対して読み出し及び書き込みを直接行なうことができる。しかし、ＡＲＭプロセッサは、ＣＰＬＤを介してメモリへアクセスする。簡単なコマンドをフラッシュＲＡＭの内部状態マシンから読み出し及び書き込むマクロ（例えば、ＲＡＭのためにＩＤ及びステータス情報を検索する）が、ｋｌｉｂ．ｈマクロライブラリの中に提供されるが、これらを改良して、より複雑な手順、例えば、ブロック・プログラミング及びロッキングを実現することは開発者に任されている。提供されたマクロは、フラッシュＲＡＭにアクセスする基本的メカニズムを例示することが意図されている。
【０１３２】
ＦＰＧＡがフラッシュＲＡＭにアクセスする必要があるとき、フラッシュ・バス・マスター信号を低に設定することによってＣＬＰＤへ通知する必要がある。これによって、ＣＰＬＤは、そのフラッシュＲＡＭピンをトライステートにし、バスの競合を避けることができる。同様に、双方のＦＰＧＡは共用バスを介してフラッシュＲＡＭへのアクセスを有するので、それらが同時にメモリへのアクセスを試みないように注意する必要がある（２つのＦＰＧＡが相互に対して駆動された場合、その１つ又は双方が損傷を受けるかも知れない）。このＲＡＭの共用が双方のＦＰＧＡ間で必要な場合には、適切なアービトレーション・システムを実現することは開発者に任されている。
【０１３３】
このＲＡＭとＦＰＧＡとの間の接続は、表１５に示される。
【表１５】

【０１３４】
ローカルＳＲＡＭ
各々のＦＰＧＡは、ローカルＳＲＡＭの２つのバンクを有する。これらのバンクは２５６Ｋワードｘ３２ビットとして配列される。それらは１５ｎｓのアクセスタイムを有する。
【０１３５】
これらのＲＡＭへ単一サイクルでアクセスできるように、外部クロック・レートは、Ｈａｎｄｅｌ−Ｃクロック・レートのために２又は３によって分割されることが推奨される。即ち、次の行をコードの中に含ませる：
ｓｅｔ　ｃｌｏｃｋ＝ｅｘｔｅｒｎａｌ＿ｄｉｖｉｄｅ“Ａ２０”２；／／又は、それより高い。
【０１３６】
ｅｘｔｅｒｎａｌ＿ｄｉｖｉｄｅ　２　クロック・レートのために、ＲＡＭは次のように定義される必要がある：
【数１】

クロックが２を超える数によって分割された場合、ｗｅｇａｔｅパラメータを次の行で置換する。
ｗｅｓｔａｒｔ＝２，
ｗｅｌｅｎｇｔｈ＝１．
【０１３７】
これらのＲＡＭへの接続は、次の通りである。
【表１６】

【０１３８】
【０１３９】
共用ＳＲＡＭ
各々のＦＰＧＡは、共用ＳＲＡＭの２つのバンクへのアクセスを有する。これらのバンクは、再び２５６Ｋワードｘ３２ビットとして配列される。これらのバンクは１６ｎｓのアクセスタイムを有する。これらのＲＡＭをＦＰＧＡの間で切り替えるため、一連のクイック・スイッチが使用される。これらのスイッチは、アービタとして働くＣＰＬＤによって制御される。特定のＳＲＡＭバンクへのアクセスを要求するためには、要求ピンを低へプルする必要がある。そうすれば、コードは、応答するＣＰＬＤによって許可信号が低くプルされるまで待つ。
【０１４０】
これを実現するＨａｎｄｅｌ−Ｃコードは、以下に示される：
【数２】

ＲＡＭは、ローカルＲＡＭと同じような方法で定義されなければならない（前述）。
【０１４１】
共用ＲＡＭへの接続は表１７に示される。
【表１７】

【０１４２】
ＳｔｒｏｎｇＡＲＭプロセッサへの接続
ＦＰＧＡは、可変待ち時間Ｉ／Ｏ装置としてＳｔｒｏｎｇＡＲＭメモリへマップされ、１０２４エントリーｘ３２ビットＲＡＭデバイスのように、ＡＲＭによって取り扱われる。これらのＲＡＭに関連したアドレス、データ、及び制御信号は、ＦＰＧＡへ直接アタッチされる。ＦＰＧＡが、これらの信号を使用してＡＲＭと交信する方法は、開発者に任されている。
【０１４３】
接続は、表１８に示される通りである。
【表１８】

【０１４４】
更に、ＡＲＭの汎用Ｉ／Ｏピンの幾つかがＦＰＧＡへ接続される。これらはボード上でコネクタＣＮ２５を通り、外部装置がそれらに接続されることを可能にする（ＡＲＭのセクションを参照）。表１９を参照されたい。
【表１９】

【０１４５】
ＣＰＬＤインタフェース
表２０には、フラッシュ・バス・マスター信号及びＦＰ＿ＣＯＭを設定するために使用されるピンがリストされる。その詳細は、ＣＰＬＤのセクションを参照されたい。
【表２０】

【０１４６】
各々のＦＰＧＡへ利用可能なローカルＩ／Ｏ装置
ＡＴＡポート
３３本のＦＰＧＡ　Ｉ／Ｏピンは、ＡＴＡポートへ直接接続する。これらのピンは、１００Ω直列成端抵抗器を有する。これらの抵抗器はポートを５Ｖ　Ｉ／Ｏ許容にする。もしＡＴＡポートが必要とされなければ、これらのピンはＩ／Ｏとしても使用されてよい。表２１を参照されたい。
【表２１】

【０１４７】
パラレルポート
このポートにアクセスするため、通常の２５ピンＤ型コネクタ及び２６ウエイ・ボックス・ヘッダが提供される。Ｉ／Ｏピンは１００Ω直列成端抵抗器を有する。この抵抗器もポートを５Ｖ　Ｉ／Ｏ許容にする。もしパラレルポートが必要とされなければ、これらのピンもＩ／Ｏとして使用されてよい。表２２を参照されたい。
【表２２】

【０１４８】
シリアルポート
ＲＳ２３２レベル・シフタを有する標準９ピンＤ型コネクタが提供される。このポートは、ヌル・モデム・ケーブルでＰＣへ直接接続されてよい。５Ｖ許容Ｉ／Ｏを有するボックス・ヘッダも提供される。これらの信号は、外部レベル・シフタを有しない標準ＲＳ２３２インタフェースへ接続されてはならない。なぜなら、ＦＰＧＡが損傷を受けるかも知れないからである。表２３を参照されたい。
【表２３】

【０１４９】
シリアルヘッダ
各々のＦＰＧＡも１０ピン・ヘッダへ接続する（ＣＮ９／ＣＮ１６）。接続は表２４に示される。
【表２４】

【０１５０】
共用Ｉ／Ｏ装置
これらの装置は、２つのＦＰＧＡの間で直接共用される。どのＦＰＧＡが、所与の時点で、どのデバイスにアクセスするかに関して、十分に注意しなければならない。
【０１５１】
ＶＧＡモニタ
各々のカラー（赤、緑、青）のためにオンボード４ビットＤＡＣを有する標準１５ピン高密度コネクタが提供される。これは、表２５に示されるように、ＦＰＧＡへ接続される。
【表２５】

【０１５２】
ＬＥＤ
ボード上の１２のＬＥＤの中の８つは、ＦＰＧＡへ直接接続される。表２６を参照されたい。
【表２６】

【０１５３】
ＧＰＩＯコネクタ
５Ｖ許容Ｉ／Ｏを有する５０ウエイ・ボックス・ヘッダが提供される。３２のデータ・ビット（「Ｅ」バス）及び２つのクロック信号が利用可能である。コネクタは、ＳｅｌｅｃｔＬｉｎｋを他のＦＰＧＡへ実現するために使用されてよい。＋３Ｖ３及び＋５Ｖ電源がヒューズを介して提供される。表２７を参照されたい。
【表２７】

【０１５４】
ＳｅｌｅｃｔＬｉｎｋインタフェース
２つのＦＰＧＡを接続する他の３２ビット汎用バスが存在する。このバスは、ＳｅｌｅｃｔＬｉｎｋインタフェースを実現して、２つのデバイスの間で、より大きな帯域幅を提供するために使用されてよい。接続は表２８に示される。
【表２８】

【０１５５】
ＵＳＢ
ＦＰＧＡは、ボード上のＵＳＢチップへ共用アクセスを有する。フラッシュＲＡＭの場合と同じように、ＦＰＧＡは、チップにアクセスする前に、ＵＳＢマスターピンを低に設定することによって、ＵＳＢチップの制御を取ったことをＣＰＬＤへ通知することが必要である。ＵＳＢチップの詳細については、本明細書のＵＳＢのセクションを参照されたい。
【表２９】

【０１５６】
ＣＰＬＤ
ボードは、Ｘｉｌｉｎｘ　ＸＣ９５２８８ＸＬ　ＣＰＬＤを組み込まれる。このＣＰＬＤは、共用ＲＡＭアービトレーション、ＡＲＭとＦＰＧＡとの間のインタフェース、及びＦＰＧＡの構成のために、多数のグルー論理関数を提供する。ＣＰＬＤは、パワーアップからＦＰＧＡを構成するか、１つのＦＰＧＡが他のＦＰＧＡを再構成するとき使用されることができる（「ＦＰＧＡのプログラミング」のセクションを参照）。
【０１５７】
共用ＳＲＡＭバンク・コントローラ
ＣＰＬＤは、共用ＲＡＭバンクを管理するコントローラを実現する。各々のＳＲＡＭバンクが３つのデバイスの１つによってアクセスされるようにするため、要求許可システムが実現された。もし複数のデバイスが同時にＳＲＡＭバンクを要求するのであれば、優先順位システムが使用される：
最高優先順位：ＡＲＭ；
マスターＦＰＧＡ；
最低優先順位：スレーブＦＰＧＡ。
【０１５８】
ＦＰＧＡは、対応する要求信号を低へプルし、それに応答するＣＰＬＤが許可信号を低へプルするのを待つことによって、共用ＳＲＡＭへのアクセスを要求する。制御は、要求信号を再び高に設定することによって譲渡される。ＡＲＭプロセッサは、ＣＰＬＤ内の幾つかのレジスタを介して共用ＳＲＡＭバンクへのアクセスを要求することができる。次のセクションを参照されたい。
【０１５９】
ＡＲＭのためのＣＰＬＤレジスタ
ＡＲＭは、表３０で示されるように、ＣＰＬＤ内の多数のレジスタにアクセスすることができる。
【表３０】

【０１６０】
ＦＰＧＡのためのＣＰＬＤレジスタ
ＦＰＧＡは、ＦＰＣＯＭピン上にコマンドを設定することによって、ＣＰＬＤにアクセスすることができる。データはＦＰＧＡ（フラッシュＲＡＭ）データバス上を転送される。表３１を参照されたい。
【表３１】

これらのコマンドは、主として、１つのＦＰＧＡが他のＦＰＧＡを再構成するとき使用される。詳細については、ＦＰＧＡ構成のセクション及び適切なＸｉｌｉｎｘデータシートを参照されたい。
【０１６１】
ＣＰＬＤ　ＬＥＤ
４つのＬＥＤが、ＣＰＬＤへ直接接続される。これらのＬＥＤは、次のことを示すために使用される：
Ｄ０　プログラミングの間のマスターＦＰＧＡフラッシュのための終了ＬＥＤ；
Ｄ１　プログラミングの間のスレーブＦＰＧＡフラッシュのための終了ＬＥＤ；
Ｄ２　使用されない；
Ｄ３　ＦＰＧＡがプログラムされるまでのフラッシュ。
【０１６２】
他のデバイス
ＵＳＢ
ボードは、フルスピード１２Ｍビット／秒で伝送することのできるＳＣＡＮロジックＳＬ１１Ｈ　ＵＳＢインタフェース・チップを有する。チップは、ＦＰＧＡへ直接接続され、ＡＲＭプロセッサによって、ＣＬＰＤを介してアクセスされることができる（詳細な情報は、本明細書のＣＰＬＤのセクションを参照されたい）。
【０１６３】
このチップのデータシートは、ｈｔｔｐ：／／ｗｗｗ．ｓｃａｎｌｏｇｉｃ．ｃｏｍ／ｐｄｆ／ｓｌｌｌｈ／ｓｌｌｌｈｓｐｅｃ．ｐｄｆから入手可能である。
【０１６４】
ＰＳＵ
このボードは、２．１ｍｍＤＣジャックを介して、外部１２Ｖ　ＤＣ電源から給電されてよい。電源は、少なくとも２．４Ａを供給できなければならない。
【０１６５】
Ｈａｎｄｅｌ−Ｃのライブラリ
前書き
このセクションは、ボードのために書かれたＨａｎｄｅｌ−Ｃライブラリを説明する。ｋｌｉｂ．ｈライブラリは、ボード上の様々なデバイスへ容易にアクセスさせる多数のマクロ手順を提供する。前記のデバイスは、共用メモリ、フラッシュＲＡＭ、ＣＰＬＤ、及びＬＥＤを含む。２つの他のライブラリ、即ち、ｐａｒａｌｌｅｌ＿ｐｏｒｔ．ｈ及びｓｅｒｉａｌ＿ｐｏｒｔ．ｈも提供される。これらは、パラレル及びシリアルポートへアクセスし、これらを介して外部装置、例えば、ホストＣＰと通信するための一般的Ｈａｎｄｅｌ−Ｃライブラリである。
【０１６６】
更に、例示的プログラムが説明される。このプログラムは、これらの様々なライブラリを使用して、パラレル及びシリアルポートのためにエコー・サーバを実現する。
【０１６７】
更に、ここでは、ＥＳＬパラレルポート・データ転送プロトコルのホスト側実現形態が説明される。このプロトコルは、ｐａｒａｌｌｅｌ＿ｐｏｒｔ．ｈ内のデータ転送マクロと一緒に使用される。
【０１６８】
ｋｌｉｂ．ｈライブラリ
共用ＲＡＭアービトレーション
２つのＦＰＧＡとＡＲＭプロセッサとの間で共用ＲＡＭをアービトレーションするため、要求・許可メカニズムが実現される。個々のＲＡＭバンクの要求及び解放の処理を容易にするため、４つのマクロが提供される：
ＫＲｅｑｕｅｓｔＭｅｍｏｒｙＢａｎｋ０（）；
ＫＲｅｑｕｅｓｔＭｅｍｏｒｙＢａｎｋ１（）；
ＫＲｅｌｅａｓｅＭｅｍｏｒｙＢａｎｋ０（）；
ＫＲｅｌｅａｓｅＭｅｍｏｒｙＢａｎｋ１（）；
引き数：
なし；
返却値：
なし；
実行時間：
ＫＲｅｑｕｅｓｔＭｅｍｏｒｙＢａｎｋ＃（）は、少なくとも１つのクロック・サイクルを必要とする；
ＫＲｅｌｅａｓｅＭｅｍｏｒｙＢａｎｋ＃（）は、１つのクロック・サイクルを必要とする；
説明：
これらのマクロ手順は、それぞれのメモリ・バンクのオーナーシップを要求及び譲渡する。メモリ・バンクの要求が行なわれたとき、手順は、要求されたバンクへのアクセスが許可されるまで、スレッドをブロックする；
注意：異なったバンクに対する要求及び解放関数は、同じサイクルで双方のバンクへのアクセスを獲得するか解放するため、相互に並行して呼び出されてよい。
【０１６９】
フラッシュＲＡＭマクロ
これらのマクロは、フラッシュＲＡＭへのインタフェースを実行するベースとして提供される。マクロは、どのように読み出し／書き込みサイクルが働くべきかを示すため、ＲＡＭからモデル及びステータス情報を検索する。実際のデータをフラッシュＲＡＭへ書き込むことは、より複雑であり、この実現は開発者に任されている。
ＫＳｅｔＦＰＧＡＦＢＭ（）；
ＫＲｅｌｅａｓｅＦＰＧＡＦＢＭ（）；
引き数：
なし；
返却値：
なし；
実行時間：
双方のマクロは１クロック・サイクルを必要とする；
説明：
フラッシュＲＡＭとの通信が実行される前に、ＦＰＧＡは、フラッシュＲＡＭの制御を取りつつあることを、ＣＰＬＤへ知らせる必要がある。これによって、ＣＰＬＤは、フラッシュ・バス・ピンをトライステートにし、リソースの競合を避ける。ＫＳｅｔＦＰＧＡＦＢＭ（）はフラッシュ・バス・マスター（ＦＢＭ）信号をセットし、ＫＲｅｌｅａｓｅＦＰＧＡＦＢＭ（）はそれを解放する。このマクロは、一般的に、より高いレベルのマクロ、例えば、ＫＲｅａｄＦｌａｓｈ（）又はＫＷｒｉｔｅＦｌａｓｈ（）によって呼び出される；
注意：これらの２つの手順は、同じ信号にアクセスし、相互に並行して呼び出されてはならない。
【０１７０】
ＫＥｎａｂｌｅＦｌａｓｈ（）；
ＫＤｉｓａｂｌｅＦｌａｓｈ（）；
引き数：
なし；
返却値：
なし；
実行時間：
双方のマクロは１クロック・サイクルを必要とする；
説明：
これらのマクロは、フラッシュＲＡＭのチップ選択信号を上昇及び下降させ、ＦＰＧＡフラッシュＲＡＭライン（データ・バス、アドレス・バス、及び制御信号）をトライステートにする。これは、もしフラッシュＲＡＭが２つのＦＰＧＡの間で共用されるならば必要である。なぜなら、１つのチップだけが、所与の時点でフラッシュを制御できるからである。フラッシュＲＡＭへ同時にアクセスを試みている双方のＦＰＧＡは、ＦＰＧＡを「ラッチアップ」するか、ＦＰＧＡ又はフラッシュＲＡＭチップに重大な損傷を与える原因となる。このマクロは、一般的に、より高いレベルのマクロ、例えば、ＫＲｅａｄＦｌａｓｈ（）又はＫＷｒｉｔｅＦｌａｓｈ（）によって呼び出される；
注意：これらのマクロは、同じ信号にアクセスし、相互に並行して呼び出されてはならない。
【０１７１】
ＫＷｒｉｔｅＦｌａｓｈ（ａｄｄｒｅｓｓ，　ｄａｔａ）；
ＫＲｅａｄＦｌａｓｈ（ａｄｄｒｅｓｓ，　ｄａｔａ）；
引き数：
書き込むか読み出される２４ビット・アドレス；
８ビット・データ・バイト；
返却値：
ＫＲｅａｄＦｌａｓｈ（）は、ａｄｄｒｅｓｓによって指定されたロケーションの値を、ｄａｔａパラメータの中に返す；
実行時間：
双方の手順は４サイクルを取る；
手順は、フラッシュＲＡＭデバイスのタイミング特性によって制限される。読み出しサイクルは少なくとも１２０ｎｓを取り、書き込みサイクルは１００ｎｓを取る。手順は２５ＭＨｚのＨａｎｄｅｌ−Ｃクロックのためにセットアップされた；
説明：
マクロは、アドレス・パラメータの中に指定されたアドレス・ロケーションからデータを読み出し、そこへデータを書き込む；
注意：これらのマクロは、同じ信号にアクセスし、相互に並行して呼び出されてはならない。
【０１７２】
ＫＳｅｔＦｌａｓｈＡｄｄｒｅｓｓ（ａｄｄｒｅｓｓ）；
引き数：
２４ビット・アドレス値；
返却値：
なし；
実行時間：
このマクロは１クロック・サイクルを必要とする；
説明：
マクロは、フラッシュ・アドレス・バスを、アドレス・パラメータで渡された値へ設定する。このマクロは、１つのＦＰＧＡが、フラッシュＲＡＭからのデータを使用して他のＦＰＧＡを構成しているときのように、指定されたロケーションにおけるデータの返却値が必要でないときに使用される。なぜなら、ＦＰＧＡの構成ピンは、フラッシュＲＡＭの下位８データ・ラインへ直接接続されるからある。
【０１７３】
ＫＲｅａｄＦｌａｓｈＩＤ（ｆｌａｓｈ＿ｃｏｍｐｏｎｅｎｔ＿ＩＤ，ｍａｎｕｆａｃｔｕｒｅｒ＿ＩＤ）；
ＫＲｅａｄＦｌａｓｈＳｔａｔｕｓ（ｓｔａｔｕｓ）；
引き数：
製造者、コンポーネント、及びステータス情報を保持する８ビット・パラメータ；
返却値：
マクロは、要求された値を、渡されたパラメータの中に返す；
実行時間：
ＫＲｅａｄＦｌａｓｈＳｔａｔｕｓ（）は１０サイクルを必要とする；
ＫＲｅａｄＦｌａｓｈＩＤ（）は１４サイクルを必要とする；
説明：
マクロは、フラッシュＲＡＭからコンポーネント及びステータス情報を検索する。これは、内部フラッシュＲＡＭ状態マシンへ一連の書き込み及び読み出しを実行することによって行なわれる；
再び、これらのマクロは、フラッシュＲＡＭのアクセスタイムによって制限され、必要なサイクル数は、設計時のクロック・レートに依存する。これらのマクロは、２５ＭＨｚ以下のＨａｎｄｅｌ−Ｃクロック・レートで使用されるように設計される；
システムは、フラッシュＲＡＭが使用されていることをＣＰＬＤへ示すように設定されるが（ＫＳｅｔＦＰＧＡＦＢＭ（）及びＫＲｅｌｅａｓｅＦＰＧＡＦＢＭ（）マクロを使用することによって）、２つのＦＰＧＡの間でアービトレーションの方法を案出することは開発者に任されている。全てのフラッシュＲＡＭラインはＦＰＧＡの間で共用され、共用ＲＡＭの場合のような切り替えメカニズムは存在しないから、もし双方のＦＰＧＡがフラッシュＲＡＭへの同時アクセスを試みるならば、問題が起こるであろう；
注意：これらのマクロは、同じ信号にアクセスし、相互に並行して呼び出されてはならない。更に、注意すべきことは、これらのマクロは、フラッシュＲＡＭとの通信の基本的インタフェースを提供することである。詳細な情報は、フラッシュＲＡＭデータシートを参照されたい。
【０１７４】
ＣＰＬＤインタフェース
次のマクロは、ＣＰＬＤステータス及び制御レジスタを読み出し、及び書き込むマクロである：
ＫＲｅａｄＣＰＬＤＳｔａｔｕｓ（ｓｔａｔｕｓ）；
ＫＷｒｉｔｅＣＰＬＤＣｏｎｔｒｏｌ（ｃｏｎｔｒｏｌ）；
引き数：
８ビット・ワード；
返却値：
ＫＲｅａｄＳｔａｔｕｓ（）は、ＣＰＬＤステータス・レジスタのビットを含む８ビット・ワードを返す。（詳細な情報は、ＣＰＬＤのセクションを参照されたい）；
実行時間：
双方のマクロは、２５ＭＨｚ以下のＨａｎｄｅｌ−Ｃクロック・レートで、６クロック・サイクルを必要とする；
説明：
これらのマクロは、ＣＰＬＤのステータス・レジスタを読み出して制御レジスタへ書き込む。
【０１７５】
ＫＳｅｔＦＰＣＯＭ（ｆｐ＿ｃｏｍｍａｎｄ）；
引き数：
３ビット・ワード；
返却値：
なし；
実行時間：
このマクロは、２５ＭＨｚ以下のＨａｎｄｅｌ−Ｃクロック・レートで、３クロック・サイクルを必要とする；
説明：
このマクロは、ＦＰ＿ＣＯＭＭＡＮＤをＣＰＬＤへ容易に送るために提供される。ＦＰ＿ＣＯＭＭＡＮＤは、１つのＦＰＧＡを他のＦＰＧＡから再構成したいときに使用される（詳細な情報は、ＣＰＬＤのセクションを参照されたい）；
異なった可能なｆｐ＿ｃｏｍｍａｎｄが、表３２に示される：
【表３２】

注意：これらのマクロは、同じ信号にアクセスし、相互に並行して呼び出されてはならない。
【０１７６】
ＬＥＤ
ＫＳｅｔＬＥＤｓ（ｍａｓｋＢｙｔｅ）；
引き数：
８ビット・ワード；
返却値：
なし；
実行時間：
１クロック・サイクル；
説明：
このマクロ手順は、ボード上のＬＥＤを制御するために提供された。ｍａｓｋＢｙｔｅパラメータはボード上のＬＥＤへ適用され、１はライトをオンにすることを示し、０はライトをオフにすることを示す。ｍａｓｋＢｙｔｅのＭＳＢはボード上でＤ１２に対応し、ＬＳＢはＤ５に対応する；
注意：ＦＰＧＡの１つだけが、この機能にアクセスしてよい。双方がアクセスを試みた場合、ＦＰＧＡは相互に駆動して「ラッチアップ」し、損傷を与える可能性がある。
【０１７７】
パラレルポートの使用
前書き
ライブラリのｐａｒａｌｌｅｌ＿ｐｏｒｔ．ｈは、パラレルポートにアクセスするルーチンを含む。これは、パラレルポート・コントローラを独立プロセスとして実現する。このプロセスは、ＩＢＭ　ＰＣに見出されるパラレルポート・インタフェースを忠実なモデルにしている。コントローラによって、パラレル・インタフェースの制御、ステータス、及びデータ・ポート（ＩＢＭ　ＰＣ上で定義される）へ同時にアクセスすることができる。これらのポートは、コントローラ・プロセスへのチャネルを読み出し、又は書き込むことによってアクセスされる。これらのチャネルの読み出し及び書き込みは、直観的ＡＰＩを提供するため、他のマクロ手順の中にカプセル化される。
【０１７８】
図１１は、本発明の実施形態に従ったパラレルポート・データ伝送システム１１００の構造を示す。ＥＳＬのパラレル・データ転送プロトコルの実現形態も提供された。このプロトコルは、ホスト・コンピュータ１１０２との間で、パラレルポートを介するデータ転送を可能にする。これは、パラレルポート・コントローラ層を利用してプロトコルを実現する別個のプロセスとして実現される。データは、このプロセスのためにチャネルへ書き込み及び読み出しを行なうことによって、ホストの間で転送されることができる。ＡＰＩを更に直観的にするため、再び、マクロ手順の抽象化が提供される。
【０１７９】
Ｗｉｎｄｏｗｓ９５／９８及びＮＴにおけるデータ転送のホスト側アプリケーションが提供される。約１００Ｋバイト／秒のデータ転送スピードが、このインタフェース上で達成されるが、パラレルポートのスピードによって制限される。
【０１８０】
パラレルポートへの直接アクセス
ポートで使用される１７のピンは、ＩＢＭ　ＰＣパラレルポート仕様で定義されるようにデータ、制御、及びステータス・ポートへ分割された。表３３を参照されたい。
【表３３】

パラレルポート・コントローラ・プロセスは、パラレルポートのアクセスを望むプログラム部分と並行して走る必要がある。これは、ｍａｉｎ（）手順の中でｐａｒ｛｝を使用して行なわれることが推奨される。
【０１８１】
コントローラ手順は：
ｐａｒａｌｌｅｌ＿−ｐｏｒｔ（ｐｐ＿ｄａｔａ＿ｓｅｎｄ＿ｃｈａｎｎｅｌ，
ｐｐ＿ｄａｔａ＿ｒｅａｄ＿ｃｈａｎｎｅｌ，
ｐｐ＿ｃｏｎｔｒｏｌ＿ｐｏｒｔ＿ｒｅａｄ，
ｐｐ＿ｓｔａｔｕｓ＿ｐｏｒｔ＿ｒｅａｄ，
ｐｐ＿ｓｔａｔｕｓ＿ｐｏｒｔ＿ｗｒｉｔｅ）；
ここで、パラメータは、全て、様々なポートがアクセスされることのできるチャネルである。
【０１８２】
パラレルポート・マクロ
チャネルへ直接書き込むよりも、次のマクロを使用して、パラレルポートへアクセスすることが推奨される。
ＰｐＷｒｉｔｅＤａｔａ（ｂｙｔｅ）；
ＰｐＲｅａｄＤａｔａ（ｂｙｔｅ）；
引き数：
符号なしの８ビット・ワード；
返却値：
ＰｐＲｅａｄＤａｔａ（）は、引き数バイトの中にデータ・ピンの値を返す；
実行時間：
双方のマクロは１クロック・サイクルを必要とする；
説明：
これらは、ポートのデータ・ピンを制御しているレジスタへ引き数バイトを書き込むか、引き数バイトの中にデータ・ポートの値を返す。引き数のＭＳＢはデータ［７］に対応する。値が実際にデータ・ピン上に置かれるかどうかは、ステータス・レジスタのビット６によって制御されるデータ・ピンの方向設定に依存する。
【０１８３】
ＰｐＲｅａｄＣｏｎｔｒｏｌ（ｃｏｎｔｒｏｌ＿ｐｏｒｔ）；
引き数：
符号なしの４ビット・ワード；
返却値：
ＰｐＲｅａｄＣｏｎｔｒｏｌ（）は、引き数バイトの中に制御ポート・ピンの値を返す；
実行時間：
このマクロは１クロック・サイクルを必要とする；
説明：
この手順は、制御ポートの値を返す。４ビット・ニブルは［ｎＳｅｌｅｃｔ＿ｉｎ＠Ｉｎｉｔ＠ｎＡｕｔｏｆｅｅｄ＠ｎＳｔｒｏｂｅ］から構成される。ここで、ｎＳｅｌｅｃｔ＿ｉｎはＭＳＢである。
ＰｐＲｅａｄＳｔａｔｕｓ（ｓｔａｔｕｓ＿ｐｏｒｔ）；
ＰｐＳｅｔＳｔａｔｕｓ（ｓｔａｔｕｓ＿ｐｏｒｔ）；
引き数：
符号なしの６ビット・ワードである；
返却値：
ＰｐＲｅａｄＳｔａｔｕｓ（）は、ステータス・ポート・レジスタの値を引き数バイトの中に返す；
実行時間：
このマクロは１クロック・サイクルを必要とする；
説明：
これらは、ステータス・ポートの読み出し及び書き込みを行なう。マクロへ渡される６ビット・ワードは、［ｐｐ＿ｄｉｒｅｃｔｉｏｎ＠ｂｕｓｙ＠ｎＡｃｋ＠ＰＥ＠Ｓｅｌｅｃｔ＠ｎＥｒｒｏｒ］から構成される。ここで、ｐｐ＿ｄｉｒｅｃｔｉｏｎは、データ・ピンの方向（即ち、それらが送信［１］モードであるか、受信［０］モードであるか）を示す。ＰｐＷｒｉｔｅＤａｔａ（）又はＰｐＲｅａｄＤａｔａ（）を使用してポートへデータを書き込むか読み出そうとする前に、このビットを正しく設定することが重要である；
注意：ポートの全てが同時にアクセスされてよいが、所与の時点では、各々のポート上で、ただ１つの操作が実行されてよい。特定のポートを処理する呼び出しは、相互に並行して行なわれてはならない。
【０１８４】
ホストＰＣとの間のデータ転送
ライブラリｐａｒａｌｌｅｌ＿ｐｏｒｔ．ｈも、ＥＳＬのデータ転送プロトコルを使用してホストＰＣとの間でデータを転送するルーチンを含む。転送プロトコルを実現するデータ転送プロセスｐｐ＿ｃｏｍｓ（）は、再び、好ましくは、ｍａｉｎ　ｐａｒ｛｝ステートメントの中で、パラレルポート・コントローラ・プロセスと並行して走る必要がある。プロトコルのホスト側実現形態ｋｓｅｎｄ．ｅｘｅも提供される：
ｐｐ＿ｃｏｍｓ（ｐｐ＿ｓｅｎｄ＿ｃｈａｎ，　−送信のときデータを書き込むチャネル
ｐｐ＿ｒｅｃｖ＿ｃｈａｎ，　−受信のときデータを読み出すチャネル
ｐｐ＿ｃｏｍｍａｎｄ，　　　−コマンドを書き込むチャネル
ｐｐ＿ｅｒｒｏｒ）　　　　　−エラー・メッセージを受け取るチャネル。
【０１８５】
次のマクロは、データ転送プロセスへインタフェースを提供する：
ＯｐｅｎＰＰ（ｅｒｒｏｒ）　−データ転送のためにパラレルポートを開く；
ＣｌｏｓｅＰＰ（ｅｒｒｏｒ）　−ポートを閉じる；
注意：ホスト側のアプリケーションｋｓｅｎｄ．ｅｘｅが走っていることを確認する。マクロは、試行してホストとハンドシェーキングを行ない、応答が受け取られるまでブロック（又はタイムアウト）するであろう。更に、注意すべきは、後続のマクロの全てが、同じプロセスにアクセスすることであり、相互に並行して呼び出されてはならないことである；
引き数：
符号なしの２ビット・ワード；
返却値：
引き数は、コマンドの成功又は失敗を示すエラー・コードを返却するであろう；
実行時間：
このマクロは１クロック・サイクルを必要とする；
説明：
これらの２つのマクロは、データを受信又は送信するためポートを開いて閉じる。それらは、ホスト・コンピュータと通信を開始するためハンドシェーキング手順をイニシエートする。
【０１８６】
ＳｅｔＳｅｎｄＭｏｄｅ（ｅｒｒｏｒ）　−ポートを送信モードに設定する；
ＳｅｔＲｅｃｖＭｏｄｅ（ｅｒｒｏｒ）　−ポートを受信モードに設定する；
引き数：
符号なしの２ビット・ワード；
返却値：
引き数は、コマンドの成功又は失敗を示すエラー・コードを返却するであろう；
実行時間：
このマクロは１クロック・サイクルを必要とする；
説明：
これらはデータ転送の方向を設定する。ポートを介するデータの送信又は受信を試みる前に、適切なモードを設定すべきである。
【０１８７】
ＳｅｎｄＰＰ（ｂｙｔｅ，　ｅｒｒｏｒ）　−ポートを介してバイトを送る；
ＲｅａｄＰＰ（ｂｙｔｅ，　ｅｒｒｏｒ）　−ポートからバイトを読み出す；
引き数：
符号なしの８ビット・ワード及び符号なしの２ビット・ワード；
返却値：
ＲｅａｄＰＰ（）は、ホストから読み出された８ビット・データ値をｂｙｔｅパラメータの中へ返す。双方のマクロは、コマンドの成功又は失敗を示すエラー・コードを返すであろう；
実行時間：
これらのマクロが、どれほど早く実行されるかは、ホストに依存する。各々のバイトに対するハンドシェーキング動作の全体のシーケンスは、次のバイトを読み出すか書き込む前に完了される必要がある；
説明：
一度、パラレルポートが初期化されて正しいモードに置かれると、これらの２つのマクロは、パラレルポートを介してバイトを送信及び受信するであろう；
手順は、操作の結果を示す２ビットのエラー・コードを返す。これらのコードは、次のように定義される：
＃ｄｅｆｉｎｅＰＰ＿ＮＯ＿ＥＲＲＯＲ　　　　　　　　　　　　　　　　０；
＃ｄｅｆｉｎｅＰＰ＿ＨＯＳＴ＿ＢＵＦＦＥＲ＿ＮＯＴ＿ＦＩＮＩＳＨＥＤ　１；
＃ｄｅｆｉｎｅＰＰ＿ＯＰＥＮ＿ＴＩＭＥＯＵＴ　　　　　　　　　　　　２；
注意：ＳｅｎｄＰＰ及びＲｅａｄＰＰは、バイトが送信されるかタイムアウト値に達するまで、スレッドをブロックするであろう。もし通信を待っている間に何らかの処理を行なう必要があれば、「ｐｒｉａｌｔ」ステートメントを使用して、グローバルのｐｐ＿ｒｅｃｖ＿ｃｈａｎチャネルから読み出すかｐｐ＿ｓｅｎｄ＿ｃｈａｎチャネルへ書き込む。
【０１８８】
読み出し／書き込みの間の典型的なマクロ手順呼び出し
図１２は、データを受信するときの、典型的な一連の手順呼び出し１２００を示すフローチャートである。図１３は、データを送信するときの、典型的な一連の手順呼び出し１３００を示すフローチャートである。
【０１８９】
Ｋｓｅｎｄアプリケーション
Ｋｓｅｎｄ．ｅｘｅアプリケーションは、パラレルポートを介してボードＦＰＧＡとの間でデータを転送するように設計される。それはＥＳＬデータ転送プロトコルを実現する。それは、ＦＰＧＡ上で走っているｐｐ＿ｃｏｍｓ（）プロセスと通信するように設計される。このアプリケーションは、なお開発段階にあり、その中に多数のバグを有するかも知れない。
【０１９０】
プログラムの２つのバージョンが存在する。１つはＷｉｎｄｏｗｓ９５／９８用であり、他の１つはＷｉｎｄｏｗｓＮＴ用である。ＮＴバージョンは、ＧｅｎＰｏｒｔドライバがインストールされることを必要とする。その方法の詳細については、ＧｅｎＰｏｒｔの文献を参照されたい。
【０１９１】
現在のところ、ｋｓｅｎｄアプリケーションは、主として、ｅｓｌ＿ｂｏａｒｄｔｅｓｔプログラムのようにデータをボードへ送ることを意図されている。しかし、それはボードから出力を受け取ることもできる。再び、詳細は、アプリケーション・ノート又はｋｓｅｎｄのヘルプ（パラメータなしでｋｓｅｎｄを呼び出すことによって起動する）を参照されたい。
【０１９２】
シリアルポート
前書き
各々のＦＰＧＡはＲＳ２３２ポートへのアクセスを有する。これはＲＳ２３２ポートをホストＰＣへ接続することを可能にする。シリアルポートを介してＦＰＧＡとの間でデータを転送するドライバは、ファイルｓｅｒｉａｌ＿ｐｏｒｔ．ｈに含まれる。
【０１９３】
ＲＳ２３２Ａインタフェース
ホスト及びデバイスの能力、及び使用されるケーブルに依存して、ＲＳ２３２インタフェースを実現する多くの方法が存在する。このインタフェースは、ハードウェア・ハンドシェーキングを必要としないクロスワイヤ・ヌル・モデム・ケーブルのために実現される。ソフトウェア・フロー制御のオプションが提供されるが、ＦＰＧＡはホストＰＣよりも非常に早いレートでデータを処理できるので、前記のオプションは多分不必要であろう。ソフトウェア・フロー制御が使用されるとき、ホストは、ＸＯＮ及びＸＯＦＦトークンを送ることによってＦＰＧＡのデータ送信をストップ及びスタートできる。これが必要になるのは、満杯になるバッファを処理しているとき、及び、いずれかの側が通知を必要とするときだけである。
【０１９４】
シリアルポート・マクロ
シリアルポート通信は、データの送信／受信を望むプロセスと並行して走る別個のプロセスとして実現された。図１４は、並行に走っている幾つかのプロセス１４０２及び１４０４を示す流れ図である。
【０１９５】
シリアルポート・コントローラ・プロセスは、次の通りである：
ｓｅｒｉａｌ＿ｐｏｒｔ（ｓｐ＿ｉｎｐｕｔ，　ｓｐ＿ｏｕｔｐｕｔ）；
ここで、ｓｐ＿ｉｎｐｕｔ及びｓｐ＿ｏｕｔｐｕｔは、ポートからデータを読み出すか書き込むことのできるｎビット・チャネルである。これらの読み出し及び書き込みは、より直観的なＡＰＩをユーザに提供するため、再び、別個のマクロ手順の中にカプセル化される。
ＳｐＲｅａｄＤａｔａ（ｂｙｔｅ）　　−ポートからデータ・バイトを読み出す；
ＳｐＷｒｉｔｅＤａｔａ（ｂｙｔｅ）　−ポートへバイトを書き込む；
引き数：
ｎビット・ワード。ここで、ｎは指定されたデータ・ビットの数である；
返却値：
ＳｐＲｅａｄＤａｔａ（）は、送信されたバイトに対応するｎビット値を引き数の中に返す；
実行時間：
実行時間は、プロトコル及び使用されるボーレートに依存する；
説明：
これらの手順は、ＲＳ２３２を使用して、シリアルポートを介してデータを送信及び受信する。ｓｅｒｉａｌ＿ｐｏｒｔ．ｈライブラリを含める前に、一連の＃ｄｅｆｉｎｅを使用して、正しい通信プロトコルをセットアップしなければならない。ヌル・モデム・ケーブル上で１１５２００ボーの８データ・ビット、１スタート・ビット、及び１ストップ・ビット・プロトコルを、フロー制御なしで使用する場合、設定は次のようになるであろう：
＃ｄｅｆｉｎｅ　ＢＡＵＤ＿ＲＡＴＥ　　　　　１１５２００；
＃ｄｅｆｉｎｅ　ＳＴＡＲＴ＿ＢＩＴ　　　　　（（符号なしの１）０）；
＃ｄｅｆｉｎｅ　ＳＴＯＰ＿ＢＩＴ　　　　　　（（符号なしの１）１）；
＃ｄｅｆｉｎｅ　ＮＵＭ＿ＤＡＴＡ＿ＢＩＴ　　８；
他のオプションは、次の通りである：
ソフトフロー制御の場合：
＃ｄｅｆｉｎｅ　ＳＯＦＴＦＬＯＷ；
＃ｄｅｆｉｎｅ　ＸＯＮ　　　　　　　　＜ＡＳＣＩＩ文字コード＞；
＃ｄｅｆｉｎｅ　ＸＯＦＦ　　　　　　　＜ＡＳＣＩＩ文字コード＞；
ＲＴＳ／ＣＴＳフロー制御の場合：
＃ｄｅｆｉｎｅ　ＨＡＲＤＦＬＯＷ；
デフォルトの設定は次の通りである：
ボーレート　　　　　　　９６００；
スタート・ビット　　　　０；
ストップ・ビット　　　　１；
データ・ビットの数　　　８；
ＸＯＮ　　　　　　　　　１７；
ＸＯＦＦ　　　　　　　　１９；
フロー制御　　　　　　　オフ；
Ｈａｎｄｅｌ−Ｃクロック・レートが、ボーレートよりも少なくとも８倍高ければ、任意の標準ボーレートの設定が働く。更に、マクロＣＬＯＣＫ＿ＲＡＴＥが定義されていることを確認する。これは、一般的に、各々のＦＰＧＡのピン定義ヘッダの中に発見される；
例えば、
＃ｄｅｆｉｎｅ　ＣＬＯＣＫ＿ＲＡＴＥ　２５００００００　／／クロック・レートを定義する。
【０１９６】
例示的プログラム
以下に示すものは、例示的なＨａｎｄｅｌ−Ｃプログラムである。このプログラムは、ｓｅｒｉａｌ＿ｐｏｒｔ．ｈ及びｐａｒａｌｌｅｌ＿ｐｏｒｔ．ｈライブラリで見出されるパラレルポート及びシリアルポート・ルーチンの使用方法を例示する。プログラムは、シリアルポート及びパラレルポート上で簡単なエコー・サーバを実現する。シリアルポートを介して受け取られたＡＳＣＩＩ値をＬＥＤ上にバイナリーで表示するため、ｋｌｉｂ．ｈライブラリからのＳｅｔＬＥＤｓ（）関数が使用される：
【数３】

コードは、ＭＡＳＴＥＲマクロを単純に定義するか、定義しないことによって、いずれのＦＰＧＡのためにもコンパイルすることができる（行１から５）。
【０１９７】
更なる情報
本明細書の主題に関する有用な情報は、次の文献から得ることができる。Ｔｈｅ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｌｏｇｉｃ　Ｄａｔａ　Ｂｏｏｋ，　Ｘｉｌｉｎｘ　１９９６；　Ｈａｎｄｅｌ−Ｃ　Ｐｒｅｐｒｏｃｅｓｓｏｒ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ，　Ｈａｎｄｅｌ−Ｃ　Ｃｏｍｐｉｌｅｒ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ，　及びＨａｎｄｅｌ−Ｃ　Ｌａｎｇｕａｇｅ　Ｒｅｆｅｒｅｎｃｅ　Ｍａｎｕａｌ，　Ｅｍｂｅｄｄｅｄ　Ｓｏｌｕｔｉｏｎｓ　Ｌｉｍｉｔｅｄ　１９９８；　及びＸｉｌｉｎｘ　Ｄａｔａｓｈｅｅｔｓ　ａｎｄ　Ａｐｐｌｉｃａｔｉｏｎ　ｎｏｔｅｓ。これらは、Ｘｉｌｉｎｘウェブサイトｈｔｔｐ：／／ｗｗｗ．ｘｉｌｉｎｘ．ｃｏｍから入手可能であり、参照してここに組み込まれる。
【０１９８】
例示的実施形態
本発明の実施形態によると、デバイスはＦＰＧＡデバイスの中にＣｒｅａｔｉｖｅ　ＭＰ３エンコーダ・エンジンをカプセル化する。図１５は、本発明の例示的実施形態に従ったＦＰＧＡデバイス１５００のブロック図である。デバイスの目的は、ＣＤ１５０２又はＣＤＲＷからＦＰＧＡの中へオーディオ・データを直接ストリームし、データを圧縮し、データをＵＳＢホスト１５０４へプッシュすることである。ＵＳＢホスト１５０４は、それをＯＡＳＩＳ（Ｎｏｍａｄ２）デコーダへ引き渡す。このデバイスの動作の全てはＰＣから独立している。
【０１９９】
ＦＰＧＡの設計は、前述したように、Ｅｍｂｅｄｄｅｄ　Ｓｏｌｕｔｉｏｎｓ　Ｌｉｍｉｔｅｄ（ＥＳＬ）社からの「Ｈａｎｄｅｌ−Ｃ」コンパイラを使用する。ＥＳＬによって提供されるＥＤＡツールは、シリコンを再開発する必要なしに、ＦＰＧＡを使用してソフトウェア・アルゴリズムを迅速に展開及び修正することを意図している。従って、ＥＳＬツールは、シリコン開発の代替として利用されることができ、より広い範囲の製品で使用されることができる。
【０２００】
特徴の概観
ＦＰＧＡは、好ましくは、次のものに必要なロジックを含む：
−ＭＰ３エンコーダ１５０６
−ユーザ・コマンド・ルックアップ・テーブル
−再生；
−休止；
−イジェクト；
−停止；
−スキップソング（順方向／逆方向）；
−スキャンソング（順方向／逆方向）；
−記録（ＭＰ３へのリップ）−＞ＯＡＳＩＳ装置；
−ＡＴＡＰＩ
−コマンド及び制御；
−コマンドＦＩＦＯ；
−データ・バス；
−コマンド・バス；
−（２）６４サンプルＦＩＦＯ（１６ビット＊４４．１００ｋＨｚ）
−シリアルポート（１６５５０ＵＡＲＴ）、オプションとしてＥＥＰＲＯＭインタフェース（Ｉ２Ｃ＆Ｉ２Ｓ）
−ホスト・コントローラへのＵＳＢインタフェース
−ＳＤＲＡＭコントローラ
−３２ビットＡＲＭ又はＲＩＳＣプロセッサ。
【０２０１】
ＦＰＧＡに加えて、好ましくは、次のものが提供される：
−ＵＳＢホスト／ハブ・コントローラ（２ＵＳＢポート）
−４ＭＢ　ＳＤＲＡＭ
−１２８Ｋ　ＥＥＰＲＯＭ
−９ピン・シリアルポート
−６つの制御ボタン
−ＣＤ又はＣＤＲＷのための４０ピンＩＤＥインタフェース。
【０２０２】
インタフェース
ＡＴＡＰＩ（ＩＤＥ）インタフェース；
ユーザ・インタフェース；
ＵＳＢインタフェース。
【０２０３】
ネットワーク・ベース構成
図１６は、プログラマブルロジックデバイスをネットワーク・ベースで構成するプロセス１６００を示す。操作１６０２では、デフォルトのアプリケーションがプログラマブルロジックデバイス上でイニシエートされる。操作１６０４では、構成データのファイル要求が、ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ送られる。操作１６０６で、構成データがネットワーク・サーバから受け取られる。構成データは、例えば、ビットファイル形式であってよい。操作１６０８で、構成データは、ロジックデバイスを構成して第２のアプリケーションを走らせるために使用される。操作１６１０で、第２のアプリケーションがロジックデバイス上で走る。
【０２０４】
本発明の１つの実施形態によると、ロジックデバイスは、１つ又は複数のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。好ましくは、第１のＦＰＧＡは、構成データを受け取り、そのデータを使用して第２のＦＰＧＡを構成する。第１及び第２のＦＰＧＡは、異なったスピードで刻時されることができる。
【０２０５】
本発明の他の実施形態によると、デフォルトのアプリケーション及び第２のアプリケーションの双方が、ロジックデバイス上で同時に走ることができる。ロジックデバイスは、更に、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、不揮発性メモリ、及び／又は他のハードウェア・コンポーネントを含むことができる。
【０２０６】
図１７は、ハードウェア・デバイスの構成を遠隔から変更するプロセス１７００を示す。操作１７０２で、ハードウェア・デバイスが、ネットワーク、例えば、インターネットを利用してアクセスされる。ここで、ハードウェア・デバイスは再構成可能ロジックで構成されている。１７０４では、ハードウェア・デバイスの現在の構成が、再構成情報を選択する前に検出される。操作１７０６で再構成情報が選択され、操作１７０８でハードウェア・デバイスへ送られる。操作１７１０では、ハードウェア・デバイスの再構成ロジックを再プログラムしてハードウェア・デバイスの構成を変更するため、再構成情報が使用される。
【０２０７】
ハードウェア・デバイスの再構成は、ハードウェア・デバイスから受け取られた要求に応答して実行されることができる。本発明の実施形態において、ハードウェア・デバイスは、ハードウェア・デバイスの製造者、ハードウェア・デバイスのベンダー、及び／又はハードウェア・デバイスのアドミニストレータのシステムによってアクセスされる。
【０２０８】
本発明の他の実施形態において、ロジックデバイスは、少なくとも１つのフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。好ましくは、第１のＦＰＧＡは、再構成情報を受け取り、第２のＦＰＧＡを構成するため再構成情報を使用する。
【０２０９】
例示的実施形態
図１８は、データを処理し、周辺ハードウェアを制御するプロセス１８００を示す。操作１８０２では、再構成可能ロジックデバイスの第１のフィールドプログラマブルゲートアレイ（ＦＰＧＡ）がイニシエートされる。第１のＦＰＧＡは、再構成データに従って、ロジックデバイスの第２のＦＰＧＡをプログラムするプログラミング機能で構成される。第２のＦＰＧＡを構成する再構成データは、操作１８０４で検索される。操作１８０６では、第１のＦＰＧＡが、第２のＦＰＧＡをプログラムしてアプリケーションを走らせるため、再構成データを利用するように命令される。操作１８０８では、第１のＦＰＧＡが、第２のＦＰＧＡをプログラムし、アプリケーションの実行に付随して周辺ハードウェアを制御するため、構成データを使用するように命令される。
【０２１０】
本発明の１つの実施形態において、不揮発性メモリに記憶されたデータは、第１のＦＰＧＡがイニシエートされたとき、プログラミング機能で第１のＦＰＧＡを構成するために利用される。本発明の他の実施形態において、構成データは、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバから検索される。構成データは、ビットファイルの形式で受け取られることができる。
【０２１１】
第１及び第２のＦＰＧＡは、異なったスピードで刻時されることができる。好ましくは、ロジックデバイスは、更に、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、及び／又は不揮発性メモリを含む。
【０２１２】
更なる実施形態及び同等物
これまで、様々な実施形態が説明されたが、理解すべきは、それらの実施形態が、単に例として呈示され、限定として呈示されていないことである。従って、好適な実施形態の広さ及び範囲は、前述した例示的実施形態によって限定されるのではなく、以下のクレイム及び同等物に従ってのみ定義されるべきである。
【図面の簡単な説明】
【図１】
本発明の１つの実施形態をハードウェアで実現した略図である。
【図２】
構成データを再構成可能ロジックデバイスへ転送するインタフェースを提供するプロセスのフローチャートである。
【図３】
本発明の例示的実施形態に従ったディスプレイを示す図である。
【図４】
図３の例示的実施形態に従って再構成可能ロジックデバイスをイニシエートする例示的手順を示す図である。
【図５】
図３の例示的実施形態に従ってインターネットを介して電話を入れるため、再構成可能ロジックデバイスを使用するプロセスを示す図である。
【図６】
インターネットを介する呼び出しに答えるプロセスを示す図である。
【図７】
図３の例示的実施形態に従って電話機能の様々なパラメータを設定する構成スクリーンを示す図である。
【図８Ａ】
図３の例示的実施形態に従って再構成可能ロジックデバイスを再構成したときに表示される例示的スクリーンを示す図である。
【図８Ｂ】
ハードウェア・ベースの再構成可能マルチメディア・デバイスを提供するプロセスを示す図である。
【図９】
本発明の例示的実施形態に従ったリソース管理デバイスのボードを示す略図である。
【図１０】
図９のボードのＪＴＡＧチェーンを示す図である。
【図１１】
本発明の実施形態に従ったパラレルポート・データ伝送システムの構造を示す図である。
【図１２】
データを受け取るときの、典型的な一連の手順呼び出しを示すフローチャートである。
【図１３】
データを送るときの、典型的な一連の手順呼び出しを示すフローチャートである。
【図１４】
並行して走っている幾つかのプロセスを示す流れ図である。
【図１５】
本発明の例示的実施形態に従ったＦＰＧＡデバイスのブロック図である。
【図１６】
プログラマブルロジックデバイスをネットワーク・ベースで構成するプロセスのフローチャートである。
【図１７】
ハードウェア・デバイスの構成を遠隔から変更するプロセスを示す図である。
【図１８】
データを処理し、周辺ハードウェアを制御するプロセスを示す図である。
【符号の説明】
１１０　中央処理装置
１１２　システム・バス
１１４　ランダム・アクセス・メモリ（ＲＡＭ）
１１６　読み出し専用メモリ（ＲＯＭ）
１１８　Ｉ／Ｏアダプタ
１２０　ディスク記憶装置
１２２　ユーザ・インタフェース・アダプタ
１２４　キーボード
１２６　マウス
１２８　スピーカ
１３２　マイクロフォン
１３４　通信アダプタ
１３６　ディスプレイ・アダプタ
１３８　ディスプレイ装置
１４０　フィールドプログラマブルゲートアレイ（ＦＰＧＡ）
３００　ディスプレイ
３０２　キーパッド・ボタン
３０４　ステータス・ウィンドウ
３０６　受け入れボタン
３０８　終了ボタン
３１０　ｍｐ３ボタン
３１２　ゲーム・ボタン
７００　構成スクリーン
７０２、７０４　ボタン
７０６　ミュート・ボタン
７０８　ディスプレイ輝度ボタン
８００　スクリーン
８０２　再生ボタン
８０４　停止ボタン
８０６　逆方向追跡ボタン
８０８　順方向追跡ボタン
８１０　休止ボタン
８１２　ミュート・ボタン
８１４　音量アップ・ボタン
８１６　音量ダウン・ボタン
８１８　出口ボタン
８２０　保存ボタン
９００　ボード
９０２、９０４　Ｘｉｌｉｎｘ　Ｖｉｒｔｅｘ（商標）２０００ｅ　ＦＰＧＡ
９０６　Ｉｎｔｅｌ　ＳｔｒｏｎｇＡＲＭ　ＳＡ１１１０プロセッサ
９０８、９１０　大容量メモリ
９１２　Ｉ／Ｏポート
１０００　ＪＴＡＧチェーン
１１００　パラレルポート・データ伝送システム
１１０２　ホスト・コンピュータ
１５００　ＦＰＧＡデバイス
１５０２　ＣＤ又はＣＤＲＷ
１５０４　ＵＳＢホスト
１５０６　ＭＰ３エンコーダ

Claims (21)

1. プログラマブルロジックデバイスをネットワーク・ベースで構成する方法であって、前記方法は、
   （ａ）プログラマブルロジックデバイス上でデフォルトのアプリケーションをイニシエートするステップと、
   （ｂ）ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ、構成データのファイル要求を送るステップと、
   （ｃ）ネットワーク・サーバから構成データを受け取るステップと、
   （ｄ）ロジックデバイスが構成されるよう構成データを利用して、第２のアプリケーションを走らせるステップと、
   （ｅ）ロジックデバイス上で第２のアプリケーションを走らせるステップと、を備える方法。
2. 構成データがビットファイル形式で受け取られる、請求項１に記載の方法。
3. ロジックデバイスが少なくとも１つのフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項１または２に記載の方法。
4. 第１のＦＰＧＡが構成データを受け取り、前記第１のＦＰＧＡが、構成データを利用して第２のＦＰＧＡを構成する、請求項３に記載の方法。
5. ロジックデバイスが、異なったスピードで刻時される第１及び第２のＦＰＧＡを含む、請求項３または４に記載の方法。
6. デフォルトのアプリケーション及び第２のアプリケーションの双方が、ロジックデバイス上で同時に走ることができる、請求項１、２、３、４または５に記載の方法。
7. ロジックデバイスが、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、及び不揮発性メモリのうちの少なくとも１つを更に含む、請求項１、２、３、４、５または６に記載の方法。
8. プログラマブルロジックデバイスをネットワーク・ベースで構成するコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品は、
   （ａ）プログラマブルロジックデバイス上でデフォルトのアプリケーションをイニシエートするコンピュータ・コードと、
   （ｂ）ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ、構成データのファイル要求を送るコンピュータ・コードと、
   （ｃ）ネットワーク・サーバから構成データを受け取るコンピュータ・コードと、
   （ｄ）ロジックデバイスが構成されるよう構成データを利用して、第２のアプリケーションを走らせるコンピュータ・コードと、
   （ｅ）ロジックデバイス上で第２のアプリケーションを走らせるコンピュータ・コードと、
   を備える、コンピュータ・プログラム製品。
9. 構成データがビットファイル形式で受け取られる、請求項８に記載のコンピュータ・プログラム製品。
10. ロジックデバイスが少なくとも１つのフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項８又は９に記載のコンピュータ・プログラム製品。
11. 第１のＦＰＧＡが構成データを受け取り、前記第１のＦＰＧＡが、構成データを利用して第２のＦＰＧＡを構成する、請求項１０に記載のコンピュータ・プログラム製品。
12. ロジックデバイスが、異なったスピードで刻時される第１及び第２のＦＰＧＡを含む、請求項１０又は１１に記載のコンピュータ・プログラム製品。
13. デフォルトのアプリケーション及び第２のアプリケーションの双方が、ロジックデバイス上で同時に走ることができる、請求項８、９、１０、１１または１２に記載のコンピュータ・プログラム製品。
14. ロジックデバイスが、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、及び不揮発性メモリのうちの少なくとも１つを更に含む、請求項８、９、１０、１１、１２または１３に記載のコンピュータ・プログラム製品。
15. プログラマブルロジックデバイスをネットワーク・ベースで構成するシステムであって、前記システムは、
    （ａ）プログラマブルロジックデバイス上でデフォルトのアプリケーションをイニシエートするロジックと、
    （ｂ）ロジックデバイスから、ネットワークを利用して、ロジックデバイスから遠隔に置かれたサーバへ、構成データのファイル要求を送るロジックと、
    （ｃ）ネットワーク・サーバから構成データを受け取るロジックと、
    （ｄ）ロジックデバイスが構成されるよう構成データを利用して、第２のアプリケーションを走らせるロジックと、
    （ｅ）ロジックデバイス上で第２のアプリケーションを走らせるロジックと、
    を備えるシステム。
16. 構成データがビットファイル形式で受け取られる、請求項１５に記載のシステム。
17. ロジックデバイスが少なくとも１つのフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項１５又は１６に記載のシステム。
18. 第１のＦＰＧＡが構成データを受け取り、前記第１のＦＰＧＡが構成データを利用して第２のＦＰＧＡを構成する、請求項１７に記載のシステム。
19. ロジックデバイスが、異なったスピードで刻時される第１及び第２のＦＰＧＡを含む、請求項１７又は１８に記載のシステム。
20. デフォルトのアプリケーション及び第２のアプリケーションの双方が、ロジックデバイス上で同時に走ることができる、請求項１５、１６、１７、１８または１９に記載のシステム。
21. ロジックデバイスが、ディスプレイスクリーン、タッチスクリーン、オーディオ・チップ、イーサネット・デバイス、パラレルポート、シリアルポート、ＲＡＭバンク、及び不揮発性メモリのうちの少なくとも１つを更に含む、請求項１５、１６、１７、１８、１９または２０に記載のシステム。

Images