JP2022084921A - 多重プロセッサシステムのためのリアルタイム分析及び制御 - Google Patents

Abstract

【課題】アプリケーションソフトウェアを動作速度で実行する多重プロセッサアレイ（ＭＰＡ）を含む試験中のデバイス（ＤＵＴ）を試験するためのシステム及び方法を提供する。【解決手段】アプリケーションソフトウェア内で生成されたデータは試験を目的として複製され、ＭＰＡ上のハードウェアリソースを構成するための試験用コードを生成する。アプリケーションソフトウェアは、第１のハードウェアリソース上で展開され、提供された入力データを用いてＤＵＴを刺激する。試験用コードを実行して、アプリケーションソフトウェアの実行には使用されないＭＰＡのハードウェアリソースを用いてＤＵＴを分析するために、第１のデータの少なくともサブセットがＭＰＡのエッジのピンに供給される。第１のデータは、入力データに基づいてアプリケーションソフトウェアが実行した送信命令文に応答して生成される。【選択図】図１１

Description

本発明の分野は一般に、コンピュータ、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ：ＤＳＰ）及びこれらの埋込み型の例といったデジタル電子システムのための、ソフトウェア開発、自動化された試験及び分析に関し、より具体的には、多重プロセッサシステムのためのリアルタイム分析及び制御に関する。

新規のデジタル電子製品の開発には、ハードウェア及びその中のソフトウェアを検証するために、数多くの試験、測定、特徴決定が必要である。複雑なデジタル電子製品に関して、上記検証のコストは、開発プロジェクトの総コストのうち最も大きな部分を占めることもある。試験及び検証コストを削減するために、いくつかの方法又は技術が存在する。

１つの方法はテスト容易化設計（ｄｅｓｉｇｎ ｆｏｒ ｔｅｓｔ：ＤＦＴ）であり、ここでは製品設計が、試験を簡略化する技術のための条件を含む。これは、製品及びその構成デバイスの内部状態の可制御性及び可観測性を上昇させる、試験点の条件を含む。試験点に関する潜在的な問題は、これら試験点の位置がシステム内へと固定されてしまい、最終製品において変更できなくなる場合があることである。別の問題としては、試験点からの生データのレートが、システムがデータを消費又は処理する性能を超えることがあり、従って試験を実施するための通常の速度より低速で製品を動作させなければならなくなる。

試験及び検証のコストを削減する別の方法は、自動化された試験である。というのは、試験を実施するにあたって人間である操作者が不要であれば、単位時間あたりに実施できる試験の数を大幅に増やすことができ、これによって故障を捕捉できる蓋然性が上昇するためである。しかしながら、アプリケーションソフトウェアの開発中及び自動化された試験中に、プログラマの設計の増大及び短いサイクルでの（インタラクティブな）試験をサポートできると有益である。

別のアプローチは、製品の通常の動作に対して無視できる程度の悪影響しか有さないように、製品の内部に試験機器を内蔵させることである。内蔵型試験機器（Ｂｕｉｌｔ－Ｉｎ Ｔｅｓｔ Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）は、高速で複雑な信号を投入及び回収する高性能プローブから、プローブ信号処理、統計及びグラフィカルディスプレイ等の分析能力まで、幅広いものであり得る。このアプローチの問題は、生データを最高速度で消費するための十分な処理リソースが欠乏していることである。

別の方法は、内蔵型自己試験（ｂｕｉｌｔ－ｉｎ ｓｅｌｆ－ｔｅｓｔ：ＢＩＳＴ）である。ＢＩＳＴは多数の自動内部試験を利用してよく、これら試験のそれぞれが二値パターン結果を生成し、これらを加算して累計を得る。全ての試験が終了すると、上記累計はシグニチャとなり、これを出力して、設計及びシミュレーション中に生成した既知の良好なシグニチャと比較してよい。ＢＩＳＴはより詳細な報告、例えば失敗した試験が存在する場合はいずれの試験が失敗したかの報告を生成することもできる。

ＢＩＳＴ及びＢＩＴＩの両方を製品の寿命中に使用して、メンテナンス性を向上させてよい。これらの技術は同一のデバイスに対して併用してよい。

上述の技術はそれぞれ、細部に対する相当な注意を必要とし、これらの細部を追跡するにはコンピュータが使用される。また各製品はその詳細において異なり、従って、各製品の確認の為に必要な試験、測定及び特性決定データを得られるように上記コンピュータをプログラムするには相当な努力が必要となり得る。

これらの技術を使用することによる利益は通常、これらの技術を実装するためのコストを上回るものであるが、改善は可能であり、当該技術分野で改善が進められている。

コストは様々な方法で削減でき、例えば各製品に合わせた試験システムを作成するために容易に組み合わせることができる、再使用可能なパラメータ化されたモジュールを、試験の設定及びプログラミングプロセスに利用できるようにすることによって、コストを削減できる。

利益は様々な方法で増大させることができ、例えば試験動作をより高速で実施して、単位時間あたりに実施できる試験を大幅に増やし、これに伴ってアプリケーションの状態空間の範囲を増大させ、適切な動作を確認する（又は製品を顧客に届ける前にバグを発見する）ことにより、利益を増大させることができる。

コンピュータ、デジタル信号プロセッサ（ＤＳＰ）、並びに無線電話；政府サービス無線（ｇｏｖｅｒｎｍｅｎｔ ｓｅｒｖｉｃｅ ｒａｄｉｏｓ）；携帯電話、スマートフォン及びタブレットコンピュータといった消費者無線機器；携帯電話基地局装置；ビデオ処理及び放送装置；物体認識装置；ハイパースペクトル画像データ処理等の包囲設備内に埋め込まれるこれらのシステム等のデジタル電子システムは、１つ又は複数の多重プロセッサアレイ（ｍｕｌｔｉ－ｐｒｏｃｅｓｓｏｒ ａｒｒａｙ：ＭＰＡ）をますます利用するようになっている。ＭＰＡは、複数の処理素子（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ：ＰＥ）、補助メモリ（ｓｕｐｐｏｒｔｉｎｇ ｍｅｍｏｒｙ：ＳＭ）、高帯域相互接続ネットワーク（ｉｎｔｅｒｃｏｎｎｅｃｔ ｎｅｔｗｏｒｋ：ＩＮ）としておおまかに定義できる。本明細書で使用される用語「処理素子（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）」は、プロセッサ若しくはＣＰＵ（中央演算処理装置）、マイクロプロセッサ又はプロセッサコアを指す。ＭＰＡの中の単語「アレイ（ａｒｒａｙ）」は、円形次元（ループ又はリング）を含む１、２、３又はそれ以上の次元で利用可能な接続を備えるネットワークによって相互接続された、複数の計算ユニット（これらはそれぞれ処理及びメモリリソースを含む）を意味するものとして、最も広い意味で使用される。なお、次元が高いＭＰＡをより低い次元の製造用媒体上にマッピングできる。例えば４次元（４Ｄ）超立方体の形状を有するＩＮ内のＭＰＡは、シリコン集積回路（ＩＣを）チップの積層体上に、又は単一の２Ｄチップ上に、又は計算ユニットの１Ｄの線上にさえ、マッピングできる。次元が低いＭＰＡをより高い次元の媒体にマッピングすることもできる。例えば計算ユニットの１Ｄの線を、ＩＣチップの２Ｄ平面上に曲がりくねった形状で展開でき、又はチップの３Ｄ積層体へと巻くことができる。ＭＰＡは複数の種類の計算ユニットと、プロセッサ及びメモリが散在する構成とを含んでよい。広い意味でのＭＰＡは、ＭＰＡの階層又は入れ子構成、特に相互接続されたＩＣチップからなるＭＰＡも含まれ、この場合ＩＣがチップが１つ又は複数のＭＰＡを含み、これらＭＰＡもまた更に深い階層構造を有する。

ＭＰＡは、ソフトウェア開発方法及びツールに対して新たな問題及び機会を提示する。ＭＰＡは数千ものＰＥにまで拡張できるため、アレイを操作するために大量のソフトウェアを管理する必要があり、またこれらソフトウェアを効率的に試験、デバッグ、再構成する必要がある。これには一般に、モジュール性、階層、適応性のあるモジュールの再使用、自動構築方法が必要となる。これらの着想は従来のソフトウェア開発システムにも見られるが、これらの着想は、性能要件に左右される異なる数のＰＥ及び他のリソースに対して、又はリソース利用可能性若しくはアプリケーション要件に左右され得る異なる形状若しくはトポロジ要件に対して、静的及び／又は動的に適合できる汎用モジュールをサポートするような様式で開発ツールに組み込まれることはなかった。

ソフトウェア開発プロジェクトは、開発チームによって与えられた要件に従って何らかの製品又はサービスを動作させるソフトウェアを生成するための、人間と機械の作業との組み合わせである。一般に、設計及び試験がより自動化されれば、生成されたソフトウェアに対してより多くの試験を行うことができ、より多くのバグを排除できるため、有益である。

組み込みシステム用の従来技術のソフトウェア開発環境を図１に図示する。人間であるソフトウェアエンジニア及びプログラマ以外に、この開発環境には３つの主要な部分が存在し、これらは最終製品及びテストベンチであり、上記テストベンチは図示したようにワークステーションを含んでよいが、いくつかの従来技術の開発システムではワークステーションはテストベンチから離れているものとして考えることができる。

最終製品の最低限の表現は、技術要件のリストである。テストベンチに関する最低限の要件は、試験中のデバイス（ｄｅｖｉｃｅ ｕｎｄｅｒ ｔｅｓｔ：ＤＵＴ）のためのテストパターン入力を生成するための手段と、ＤＵＴの出力を捕捉して既知の良好なパターンと比較するための方法である。ＤＵＴが最終製品に適合すればするほど、開発されるソフトウェアが最終製品において期待通りに動作する確信が高まる。

ワークステーションに関する最低限の要件は、マスストレージの細部と、設計データのデータベースと、プロジェクトデータベースに対して読み書きを行う設計ツールの組（又はスイート）とを管理するオペレーティングシステム（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ：ＯＳ）を備えるデスクトップ又はラップトップコンピュータである。２つ以上のプロジェクト並びに２つ以上のプロジェクトデータベース及びツールが存在してよく、これらの間でライブラリを共有することで、開発コストを下げることができる。

一般に、コンピュータ及びＤＳＰのためのメモリは、上部に高速なメモリを有し、低速であるが大容量のメモリを各段下部に有する階層として組織される。ＭＰＡでは、階層の上部の補助メモリが各ＰＥの近傍に位置する。各補助メモリは、最適な命令又は最適なデータを保持するよう特殊化できる。特定のＰＥのための補助メモリは、そのＰＥ専用のものであっても、又は他のＰＥと共用であってもよい。

メモリ階層を更に下がると、典型的には、各ＰＥに隣接する補助メモリの何倍も大きいビット容量を有する半導体同期ＳＤＲＡＭからなる、比較的大型の共有メモリが存在してもよい。メモリ階層を更に下がるとフラッシュメモリ、磁気ディスク、光学ディスクがある。

上述のように、多重プロセッサアレイ（ＭＰＡ）は、処理要素（ＰＥ）、補助メモリ（ＳＭ）、並びにＰＥ及び／若しくはメモリ間の高帯域幅データ通信を支援するための一次相互接続ネットワーク（ｐｒｉｍａｒｙ ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ ｎｅｔｗｏｒｋ：ＰＩＮ、若しくは単にＩＮ）を含む。図２、３には例示的なＭＰＡが図示されており、これらについて以下に説明する。一般にＰＥは、入力データ及び出力データをバッファリングするためのレジスタ、命令処理ユニット（ｉｎｓｔｒｕｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ：ＩＰＵ）、データに対して演算及び論理関数を実行するための手段、並びにシステムのその他の部分との通信のための多数のスイッチ及びポートを備える。ＩＰＵはメモリから命令をフェッチし、これら命令を復号化して、データをＰＥに及びＰＥから移動させるため並びにデータに対して演算及び論理関数を実行するために適切な制御信号を設定する。大型ＭＰＡに適したＰＥは一般に、１つの大型ＭＰＡを含む１つのＩＣチップに対してＰＥの数が多いという単純な理由で、汎用プロセッサ（ｇｅｎｅｒａｌ ｐｕｒｐｏｓｅ ｐｒｏｃｅｓｓｏｒｓ：ＧＰＰ）よりもエネルギ効率が一般に高いはずである。

本出願において使用される用語ＭＰＡは、複数のプロセッサの比較的均一なアレイと、いわゆる「プラットフォームＩＣ」チップ上に集積された汎用プロセッサ及び特殊化されたプロセッサの異種集団との両方を包含する。プラットフォームＩＣチップは数個から多数のプロセッサを含んでよく、これらは典型的には共有メモリと相互接続され、場合によってはオンチップネットワークと相互接続される。ＭＰＡと「プラットフォームＩＣ」チップとの間には違いがあってもなくてもよい。しかしながら「プラットフォームＩＣ」チップは、特定の垂直的市場における特定の技術要件に対処するために市販されているものであってよい。

例示的なＭＰＡアーキテクチャは、特許文献１に開示されているＨｙｐｅｒＸ（商標）アーキテクチャである。ＨｙｐｅｒＸ（商標）アーキテクチャの一実施形態では、広範なサイズの多重プロセッサアレイは単位セルベースのハードウェア組織（メッシュ）からなってよく、各セルはＨｙｐｅｒＳｌｉｃｅと呼ばれる。このハードウェア組織は、グリッド上に単位セルを配設し、隣接するセルを相互接続することによって形成できる。各ＨｙｐｅｒＳｌｉｃｅは、１つ又は複数のデータメモリ及びルータ（ＤＭＲ）、並びに１つ又は複数の処理要素（ＰＥ）を含んでよい。米国特許第７４１５５９４号では、ＤＭＲは動的設定可能通信（ｄｙｎａｍｉｃａｌｌｙ ｃｏｎｆｉｇｕｒａｂｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ：ＤＣＣ）要素と呼ばれることもあり、ＰＥは動的設定可能処理（ｄｙｎａｍｉｃａｌｌｙ ｃｏｎｆｉｇｕｒａｂｌｅ ｐｒｏｃｅｓｓｉｎｇ：ＤＣＰ）要素と呼ばれることもある。ＤＭＲは隣接するＰＥに補助メモリを提供でき、また相互接続ネットワーク（ＩＮ）にルータ及びリンクを提供できる。

ハードウェアファブリックは、ＨｙｐｅｒＳｌｉｃｅを隣接させることによって生成でき、これにはＨｙｐｅｒＳｌｉｃｅを位置合わせして、正確な電気的接続を形成することが必要となる。このような接続は、ＤＭＲへのリンク、電源グリッドへの接続を含む。ＨｙｐｅｒＳｌｉｃｅを複製し、これらを隣接させ、隣接によって接続する技術は、集積回路（ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ：ＩＣ）チップ、特に相補型金属酸化膜半導体（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｍｅｔａｌ ｏｘｉｄｅ ｓｅｍｉｃｏｎｄｕｃｔｏｒ：ＣＭＯＳ）回路技術を用いて製作されるＩＣの、よく知られている超大規模集積（ｖｅｒｙ ｌａｒｇｅ ｓｃａｌｅ ｉｎｔｅｇｒａｔｉｏｎ：ＶＬＳＩ）である。このハードウェアファブリックは、独立して、かつ処理要素に対して透明に動作する一次ＩＮ（ＰＩＮ）を有し、また任意の通信ネットワークトポロジをサポートするＨｙｐｅｒＳｌｉｃｅ間の、リアルタイムでプログラム可能かつ適合可能な通信経路（ルート又はパスと呼ばれる場合もある）を通してオンデマンド帯域幅を提供できる。ＨｙｐｅｒＳｌｉｃｅの調整グループは、ソフトウェア制御下で「オン・ザ・フライ」で形成及び再形成できる。関数を評価するために使用されるハードウェアの量を動的に変更できるこのような能力により、ハードウェアリソースの最適な応用が可能となり、これによって処理におけるボトルネックが緩和される。ハードウェアファブリックの縁部において、リンクは、メモリ階層の更に下にあるメモリのタイプに対して、又は集積回路（ＩＣ）チップの縁部のＩ／Ｏに対して特化された回路に接続される。

ＨｙｐｅｒＸハードウェアファブリックの相互接続されたＤＭＲは、チップ内を横断する、及びチップ間の、最も近接した、局所的な、及び全体的な通信を提供できる。これらの通信モードはそれぞれ、ＤＭＲリソースを物理的に用いて、データの局所性及びソフトウェアアルゴリズムの要件に応じてデータ／メッセージを様々に送信できる。「クイックポート（Ｑｕｉｃｋ Ｐｏｒｔ）」設備を設けることにより、プロセッサからいずれのネットワーク目的地への、データの１つ又は複数の語の低レイテンシ伝送をサポートできる。ブロック伝送に関して、メモリ及びルーティングファブリックを横断するデータの移動を管理するために、ＤＭＲ内でダイレクトメモリアクセス（ＤＭＡ）エンジンを利用可能としてよい。ＰＥ間の最近接通信に関して、共有メモリ及びレジスタの使用が、最も効率的なデータ移動方法となり得る。局所的及び全体的なデータ移動に関して、ルーティングファブリック（ＰＩＮ）の使用が最も効率的な方法となり得る。通信経路（又はルート）は動的でも静的でもよい。動的ルートは、データ伝送のために設定され、伝送が完了すると、他のルート及びデータ伝送のためにＰＩＮリソースを活用できるよう切断してよい。静的リソースは、プログラム実行を通して所定の位置にあり続けることができ、主に優先度が高く重要な通信に使用される。通信経路の物理的位置及びこれら経路を横断するデータ伝送のタイミングは、ソフトウェアプログラム制御下にあってよい。いずれのセンダといずれのレシーバとの間の同時データ伝送をサポートするために多重通信経路が存在してよい。

ＤＭＲのアーキテクチャにより、異なる相互交換可能なＰＥを、システムを特定の用途に対して最適化するために多重プロセッサファブリックにおいて使用できる。ＨｙｐｅｒＸ（商標）多重プロセッサシステムは、ＰＥ異種のＰＥによるアレイ又は同種のＰＥによるアレイを備えてよい。ＰＥは従来のプロセッサであってよく、又はＰＥはプロセッサの従来の定義に適合していなくてもよい。ＰＥは単に、特定の論理関数のための結線接続されたプロセッサとして機能する論理ゲートの集合であってよく、ここではより高い性能、より小さい面積及び／又はより低い電力のためにプログラム可能性が犠牲となっている。

図２は、従来技術による例示的なＨｙｐｅｒＸ（商標）システムの、処理要素（ＰＥ）及びデータメモリルータ（ＤＭＲ）のネットワークを示す。ＰＥは矩形のブロックとして図示され、ＤＭＲは円として図示されている。ＤＭＲ間のルーティングパスは点線で図示されている。中実の三角形はオフメッシュ通信を示し、実線はＤＭＲ間のアクティブなデータ通信を示す。計算タスクはその数値による識別子で示され、これを実行するＰＥ上に位置する。通信に使用されているデータ変数はその名称で示され、これを含むＤＭＲ上に位置する。図示した実施形態では、左上のＰＥはタスクＩＤ６２のタスクに割り当てられ、このＰＥに隣接する各ＤＭＲを介して他のＰＥ又はメモリと通信でき、上記各ＤＭＲは通信パス変数ｔ、ｗ、ｕで表されている。これもまた図示されているように、この実施形態では、アクティブな通信チャネルは、「ｘ」で標識されている隣接するＤＭＲを介して、７１（例えば別のタスクＩＤ）で表されているＰＥを、オフメッシュ通信パス又はポートに接続する。

図３は、従来技術による、１つのチップ上に実装された例示的な多重プロセッサシステムを示す。図示したように、このチップはオフチップデバイスとの通信のための複数のＩ／Ｏルータと、図２の例示的なシステムと同様の内部多重プロセッサファブリックとを含む。ＨｙｐｅｒＸ（商標）プロセッサアーキテクチャは、固有の多次元性を含んでよいが、物理的には平面実施形態に実装できる。このプロセッサアーキテクチャは高エネルギ効率特性を有してよく、また（大型のアレイに対して）基本的に対応可能であり、信頼性が高い。即ち低電力かつ信頼性の高い概念を提示する。プロセッサアーキテクチャが前例のない性能を達成できる態様は、最新式のプロセッサ、メモリネットワーク、柔軟なＩＯを含む。処理要素（ＰＥ）はフルフレッジドＤＳＰ／ＧＰＰであってよく、また、ハードウェアリソースの使用を同時に最大化しながらスループットを維持するために実行パイプラインを動的に拡張できる可変幅命令語命令セットアーキテクチャによって支持される、メモリ間（キャッシュレス）アーキテクチャに基づくものであってよい。

従来技術によるＤＭＲハードウェア構造の例を、図４により詳細に示し、ここでは中央データメモリ（ｄａｔａ ｍｅｍｏｒｙ：ＤＭ）はルータを表す八角形のリングで囲まれている。なお、図示した八角形形状は単なる記号表現であり、実際の形状は異なっていてよく、例えば矩形であってよい。図示したように、ＤＭＲを取り囲むのは、他のＤＭＲ及びＰＥへのデータパスを表す多数の双方向矢印である。これらの双方向データパスは、各端部における実際の双方向トランシーバを用いて実装でき、又は反対方向に配向された単方向パスのペアとして実装できる。

図４のルータとデータメモリとの間の単方向矢印は、メモリとルータとの間の単方向データパスを表す。これらの矢印の近傍の小さな正方形はＤＭＡエンジン、即ちＤＭからの読み出しをサポートするＤＭＡリーダ（ＤＭＡ ｒｅａｄｅｒ：ＤＭＡＲ）及び／又はＤＭへのデータ書き込みをサポートするＤＭＡライタ（ＤＭＡ ｗｒｉｔｅｒ：ＤＭＡＷ）を表す。ＤＭＡＲエンジンは、典型的には読み出しデータをリンクから別のＤＭＲに送信するためにバッファによって増大させるための、メモリのためのアドレス信号を生成する。同様にＤＭＡＷエンジンは、リンクから受信した書き込みデータをバッファによって増大させるための、メモリのためのアドレス信号を生成する。各ＤＭＡエンジンはＰＥより大幅に小さく、使用電力が少なく、従ってこれらＤＭＡエンジンは、メモリのブロックの読み出し及び書き込みへの使用に関して魅力的である。ＤＭＡエンジンは、ＤＭメモリスペース内の関連する構成レジスタへのＰＥによる書き込みによって構成できる。特定のアドレスへの書き込みによりＤＭＡがトリガされ、上記増大が開始される。ＤＭＡが複数のアドレスのブロックを通しての増大を終了すると、無制限にルーピングを継続するよう構成されていない限り、ＤＭＡは停止する。

ソフトウェアは、コンピュータ又は他のプログラム記憶式デバイスを動作させるために必要な命令（プログラムコードとも呼ばれる）の集合である。ソフトウェアはその使用目的に応じて分類される。エンドユーザ用のコンピュータを特定の使用目的（ワードプロセッシング、インターネットサーフィン、ビデオ又は携帯電話信号処理等）のために動作させるソフトウェアは、アプリケーションソフトウェアと呼ばれることがある。アプリケーションソフトウェアは、人間であるプログラマが書いたソースプログラム及びスクリプトを含み、様々な中間コンパイル形式、及びランタイムソフトウェアと呼ばれる最終的な形式を対象デバイス（ＰＥ、マイクロプロセッサ又はＣＰＵ）によって実行できる。ランタイムソフトウェアはエミュレータによって実行することもでき、このエミュレータとは、デバッグ（エラー排除）を目的として、対象デバイスの内部状態に関して実際の対象デバイスよりも高い可視性を提供するよう設計されたデバイスである。

開発ソフトウェア（ソフトウェア開発ツールのグループ又はスイート）は、アプリケーションソフトウェアを生成するために使用されるソフトウェアである。基本的な開発ツールとしては、従来技術によるＭＰＡベースのシステムのための例示的なソフトウェア設計及び開発フローを示す図５に示すように、コンパイラ、アセンブラ、リンカが挙げられる。ユーザがソースコードを例えばＣ又はＣ＋＋といった高級プログラム言語で書くためのエディタもまた、基本的な開発ツールとみなしてよい。人間であるエンジニア又はプログラマは典型的にはプログラムを設計し、これを、図５の「完全な設計」と記された文書で表される、高級プログラム言語のソースコードに翻訳する。このソースコードはプログラムエディタによって生成できる。「言語のコンパイル／アセンブリ」と記されたブロックでは、コンパイラを用いてソースコードをモジュール単位のアドレス再配置可能なオブジェクトコードに翻訳し、続いてアセンブラを用いて、モジュール単位の機械コードを生成し、最後にリンカを用いて、プログラム全体の実行可能なバイナリイメージを生成する。図示したように、これらのステージのいずれにおいて、及びこれらのステージの間に、最適化を実施してもよい。「設計を処理してチッププログラミングファイルを生成する」と記された最適化を含む、このようなコンパイル、アセンブリ、リンク（バイナリイメージ作成）プロセスは、「メイクファイル」内に記憶されたオペレーティングシステムへの命令によって自動化できる。プログラムを試験するために、一般にはバイナリイメージを対象デバイスのメモリにロードし（これは図５において、「チッププログラミング情報」を「プロセッサＩＣチップ」に対して準備して実装することとして表されている）、実行する（即ち「プログラムを実行する」）。他の一般的なソフトウェアツールとしては、（対象ＰＥにからバイナリイメージをロード、開始、休止、ダンプ、ディスアセンブルするための）デバッガ、サイクル精度シミュレータがある。サイクル精度シミュレータは、プロセッサの内部状態に関する完全な可視性を提供するものの、これらの速度は対象ハードウェアと比べてはるかに、例えば数桁も遅い。

多重プロセッサシステムに関して、単一プロセッサシステムと比べて重要な追加のステップが存在する。これは、特定の処理タスク又はモジュールを特定の物理リソースに割り振ることであり、上記物理リソースはＰＥ、補助メモリ、ＰＥとシステムＩ／Ｏポートとの間の通信リソースである。通信リソースは、ルータ、ルータ間のリンク、ルータとリンクとが交互に連なったパス、補助メモリ、補助メモリとルータ（又はリンク）との間に介在するＤＭＡエンジンを含んでよい。なお、共有ローカルメモリの割り振りは、ＰＥ及び通信リソースの割り振りに影響を及ぼし得、またその逆もあり得るため、リソースの割り振りはメモリリソースへのデータ変数の割り振りを含んでよい。図５では、この追加のステップを「リソース割り振り」（これを「物理的設計」と呼ぶ場合もある）と記したブロックで表す。フローのリソース割り振り部分は、配置及びルーティングツールを利用してよく、これらはタスクをアレイ内の特定のＰＥに割り当て、ＩＮ内の特定のポート及び通信経路（パス）を選択するために使用できる。なお、システム全体の物理的設計は全てを一度に実施する必要はなく、特にソフトウェア定義試験機器を、ソフトウェア開発後のいずれの時点（システムの実行中を含む）において後から追加してよい。しかしながらこのようにすると、試験機器を追加できるかどうかは、アプリケーションソフトウェア及び目標の信号へのアクセスによって使用されないチップ上の利用可能なリソースに左右されることになる。アプリケーションソフトウェアが密に配置されるとアクセスがブロックされる場合があり、又はチップのセキュリティ用特徴部分を使用することによりアクセスを故意にブロックできる。

設計の各部分は、ランタイムソフトウェアの通常の実行中に、制御下で動的に変更できるものであってよい。従来のマイクロプロセッサは、プログラム実行中のメモリ割り振り及び割り振り解除をサポートしている。ＩＮリソースに関して、通信経路を設定及び切断するための機械コード命令を比較的少ないデータ語に符号化してよく、このようにして、多数の経路のための命令を、ＰＲのための補助メモリ内に容易に記憶できる。従ってＰＥ上のランタイムプログラムタスクは、必要に応じて動的に通信できるように経路を設定及び切断でき、これには、通信リソースを使用しないインターバル中に、これらのリソースを他のＰＥが利用できるという副次的な便益がある。Ｉ／Ｏポートは、Ｉ／Ｏポートに動的に接続される通信経路に応じて動的に割り振ってよい。ＰＥに対するタスクの割り振りもまた、ＰＥの命令メモリを新規のタスクで上書きできるオーバレイ機構によって、ランタイム中に変更できる。

ＭＰＡリソース割り振りがランタイム中に変化している場合、性能が向上する可能性はあるが、性能の低下又はデッドロック状態を防止できるように上記変化を調整する必要もある。従ってシステムの最適化は、時間次元と、空間におけるリソース次元とを含み得る。更にシステムの最適化は、例えばランタイムレイテンシ、遅延、電力放散、データ処理依存性等のシステムの制約に影響され得る。よって上記システムの最適化は、多次元最適化であってよい。

図６は、従来技術による例示的なソフトウェア設計データフローを更に詳細に示す。図示したように、一般にサードパーティ製システム開発ツールを用いて、例えばＣ、Ｃ＋＋等の標準的な高級プログラム言語でプログラムを生成し、これをコンパイル、アセンブル、リンクして画像（実行可能なバイナリイメージ）を生成する。また図示したように、コンパイルの結果を更に利用して、対象ハードウェアに対してソフトウェアを最適化して良い。より具体的には、タスク抽出、多次元最適化（上述）、リソース割り当て／割り振りを、システムの制約及び例えば図示したようにＨｙｐｅｒＸ（商標）ハードウェア製品である対象ハードウェア製品に基づいて実施してよい。図示したように、このプロセスは本質的に反復可能である。ソフトウェア開発ツールのスイートは、ＨｙｐｅｒＸ（商標）アーキテクチャデバイス用に開発されており、ＨｙｐｅｒＸ（商標）統合ソフトウェア開発環境（Ｉｎｔｅｇｒａｔｅｄ Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｅｎｖｉｒｏｎｍｅｎｔ：ＩＳＤＥ）製品に含まれている。

少数のプロセスしか伴わない場合、物理的設計（物理的位置に対するアプリケーションソフトウェアタスクの割り当て及び通信経路の具体的なルーティング）は比較的単純であり、手動で実施可能である。それでもなお、各プロセッサの作業負荷は経時的に劇的に変動し得、従ってスループットを最大化するために、何らかの形態の動的割り振りが望ましくなり得る。しかしながら、多数のＰＥを有するＭＰＡに関して、物理的設計プロセスは、手動でこれを行うと面倒であり、またエラーが発生しやすい。これらの問題に対処するために、タスク（プログラムコードのブロック）及び通信要件（各経路のソース及び目的地）を定義してリソースを自動的にタスクに割り振る（配置及びルーティングする）ための、多重プロセッサシステム用のソフトウェア開発ツールが製造されている。設計が大型であり、又は多くの反復するタスクを含む場合、セルの階層として表現すると比較的扱いやすいものとなり得る。階層としての記述は、ランタイムにおいて必要となる全てのタスク及び全ての通信経路のリストへと平坦化しなければならない場合があり、ランタイムの後、配置及びルーティングツールを使用して物理的設計を完成できる。階層の更なる強化をサポートする代替設計フローは、増加する配置及びルーティングをサポートすることもできる。

階層構造の設定可能なセルという着想は、ハードウェア記述言語（Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ：ＨＤＬ）の領域で既に使用されている。階層設定可能性は、Ｖｅｒｉｌｏｇ及びＶＨＤＬといった一般に使用されているＨＤＬに組み込まれている。しかしながらこれらの方法は、論理ゲートに実装され、かつ通常は多重プロセッサアレイに利用されない設計の生成を対象としている。主要な差異は、各ドメインで使用される計算のモデルである。ＨＤＬモデルでは、全ての計算リソースは一般に、同時に実行されるよう初期設定されているが、順次実行されるように指定することもできる。対照的に、多重プロセッサモデルは限られた数の並列計算ストリームを想定しており、上記ストリームはそれぞれ順次実行モデルの結果として生じる。

これらのＨＤＬは、例えば固有若しくは共有メモリ空間、固有若しくは共有同期リソース、又はプロセッサ特定機械命令のセットといった、多重プロセッサアレイの固有の特性の表現を有さない。対照的に、多重プロセッサのためのソフトウェア言語はこれらの特徴の表現を含む。

ソフトウェア言語の分野では最近、機能設定可能性が利用されている。しかしながら従来技術のソフトウェアプログラム言語は、（固定セル及び再設定可能セル両方の）プログラミングの再使用可能性、並びに階層分解による設計の複雑性の管理をサポートしていない。例えばＣ＋＋において「テンプレート」として知られている構造体は、ある機能を特定の使用のために特化できる。しかしながら、パラメータ化の範囲は、その引数のデータタイプに限定され、計算の並列実装において変化させることができない。

図７は、従来技術による、デジタルデバイスを試験するための一般的な従来のテストベンチ及び試験設備を示す。図示したように、試験中のデバイス（ＤＵＴ）は開発ボードの中央に位置し、上記開発ボードは、電力と、左側のパターン生成器（ｐａｔｔｅｒｎ ｇｅｎｅｒａｔｏｒ：ＰＧ）からＤＵＴへ、そしてＤＵＴから右側の論理アナライザ（ｌｏｇｉｃ ａｎａｌｉｚｅｒ：ＬＡ）への高速で密な信号接続とを供給する。ＰＧはデジタルメモリを含み、このデジタルメモリはコンピュータからロードでき、別個のバーストで、又は無限に反復するパターンとして、ＤＵＴへの送信を実施できる。ＬＡは、ＤＵＴから受信したデータ語を記憶するためのメモリを含む。ＬＡは、データがデータ内に特定のパターン（トリガ信号）を有して提示されるまでデータを記憶しないようプログラムでき、従って、大半が目標のデータではない大量のデータを収集するのではなく、特定のイベント後に目標のデータを記憶する。ＰＣは、ＰＧ、ＬＡを制御して結果をマスストレージに収集するために使用される。

より密なＩＣ製作技術による、極めて大幅に複雑なＩＣデバイスの出現により、図８に示すように、より多くのメモリＩＣチップ及びより高速なコンピュータ接続を、マスメモリ及びマイクロプロセッサを含む開発ボードに設置する傾向が生まれている。これらの非ＤＵＴ ＩＣチップを使用して、開発ボードとＰＣとの間で、標準ＵＳＢ及びイーサネット（登録商標）接続を介して大量のデータを移動させることができる。

なお、図８のＤＵＴは、試験入力データを受け取るために割り振られたある程度のオンチップリソース（「試験入力用リソース（ｒｅｓｏｕｒｃｅｓ ｆｏｒ ｔｅｓｔ ｉｎｐｕｔｓ）」）、並びに出力データの収集及び処理を精査するためのある程度のリソース（「試験出力用リソース（ｒｅｓｏｕｒｃｅｓ ｆｏｒ ｔｅｓｔ ｏｕｔｐｕｔｓ）」）と共に示されている。ＤＵＴリソースの大半は、アプリケーションの機能に割り振られている（「アプリケーション用リソース（ｒｅｓｏｕｒｃｅｓ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎ）」）。全体的な試験制御、試験プログラミング、試験データ分析、試験結果表示及びマスストレージのために別個のコンピュータを使用する。コンピュータ及びマイクロプロセッサはますます高速化されているため、多くの場合、従来のパターン生成器及び論理アナライザは多くの条件下で除去できる。

プログラマ設定可能なＩＣチップの一部を、プローブとして又は同一のチップの別の部分を試験若しくは特性決定するための機器として使用するという着想が、文献に記載されている。例えば設定可能ＩＣチップの１つのカテゴリとして、フィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：ＦＰＧＡ）がある。ＦＰＧＡは典型的には開発ソフトウェアを使用して構成され、この開発ソフトウェアはＨＤＬのプログラマ入力を得て機能を定義し、これを構成「ビットストリーム」にコンパイルし、この構成ビットストリームは、ＦＰＧＡチップを構成するために特定のＦＰＧＡチップへの入力となる。構成を試験するために、デジタル試験信号を投入し、構成ビットストリームに組み込まれたプログラマ定義プローブによって収集してよい。

非特許文献１では、オンチップマルチプレクサを使用して、データを論理アナライザへストリーミングする目的で、ＦＰＧＡチップのアプリケーション構成における複数の異なる場所からデータを収集する。

「この文書は、動的ＦＰＧＡプローブの組み合わせを提示しており、これはＦＰＧＡ内の信号グループを、ＦＦＴベースベクタ信号分析ソフトウェアパッケージを有する少数の物理パッケージパッドによる測定のために論理アナライザへとルーティングできる。この組み合わせにより、ＦＰＧＡ内部のデジタル信号におけるタイムドメイン、周波数スペクトル、変調品質を同時に測定できる。またこの組み合わせにより、時間のかかるＦＰＧＡの再設計を行う必要なく、信号分析のための様々な内部ネットを迅速に選択できる。」

非特許文献２では、「合成機器（ｓｙｎｔｈｅｔｉｃ ｉｎｓｔｒｕｍｅｎｔ）」即ちＳＩをＦＰＧＡのために設計している。

「これにより、標的であるデジタル信号処理（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇ：ＤＳＰ）ベースの機器の複数のタスクを実行できる。この文書のテーマはベクタ信号分析であり、これにより、時間依存性振幅及び位相が入力時間信号から抽出される。…

…ベクタ信号アナライザは、変調プロセスの多数の品質測定を提示できる。これらは、変調器の歪み、位相ノイズ、クロックジッタ、Ｉ－Ｑ不均衡、シンボル間干渉等の望ましくない属性の推定を含む。この場合ＳＩは、ＤＳＰ無線レシーバの全てのタスクを実行し、観察された変調信号パラメータと、理想的な変調信号のパラメータとの間の小さな変動を報告する、ソフトウェア無線（ｓｏｆｔｗａｒｅ－ｄｅｆｉｎｅｄ ｒａｄｉｏ：ＳＤＲ）となることを求められる。様々な品質測定（例えばエラーのサイズ）は、通信システムの性能限界を定量化及び精査するにあたって価値を有する。」

これらは、プログラムタスク、プロセッサ、ＩＮ経路設定及びメッセージ受け渡しといったＭＰＡの特徴を指定するための構造体を一般に含まない論理ゲート指向性のハードウェア記述言語ＨＤＬでほとんどの場合設計されるＦＰＧＡの実装形態である。

多数の処理要素（ＰＥ）、補助メモリ（ＳＭ）、高帯域幅一次相互接続ネットワーク（ＰＩＮ）からなる多重プロセッサ（ＭＰＡ）コンピュータシステムに関して、試験、デバッグ及び性能特性決定を目的として、高帯域幅信号をＭＰシステムに、及びＭＰシステムから通信する必要がある。

ＭＰＡシステムのうちのある程度又は全ては、１つ又は複数のＶＬＳＩ ＩＣチップ上に配置してよく、これにより、試験／デバッグを目的とした外部信号の投入又は内部信号の収集の精査はより困難となる。これは内部状態の制御可能性及び可視性を低下させる。コンピュータシミュレーションにより、全ての内部状態及び信号を示すことができる。しかしながら、極めて低いエラーレートの条件下で動作するシステムに関して、統計的に有効な特性決定を得るためには、何百万ものダミー情報及びノイズの試験パケットをシステムに通過させる必要があり、従ってコンピュータシミュレーションには時間がかかり過ぎる。必要とされているのは、ハードウェア及びソフトウェアが、最終システム目標速度（リアルタイム）に近い速度で動作する、運用システムの試験及び特性決定である。

必要な最小テストベンチ能力は、アプリケーションハードウェア／ソフトウェアのクリティカルポイントに投入される信号及びノイズの生成、ハードウェア及びソフトウェアのクリティカルポイントからの信号及びノイズの収集、これらの信号と既知の良好な信号との比較、これらの信号の処理（特性決定のタイプに応じて、単純な処理又は複雑な方法での処理）、目的の内部信号を送出するためのソフト精査のサポート、並びにストリーム信号の投入である。

従って、多重プロセッサシステムのリアルタイム分析及び制御のための改良された技術及びツールが望まれている。

米国特許第７４１５５９４号

Ｆｅｒｇｕｓｏｎ，Ｓ．；"Ｖｅｃｔｏｒ ｓｉｇｎａｌ ａｎａｌｙｓｉｓ ｏｆ ｄｉｇｉｔａｌ ｂａｓｅｂａｎｄ ａｎｄ ＩＦ ｓｉｇｎａｌｓ ｗｉｔｈｉｎ ａｎ ＦＰＧＡ，"ＩＥＥＥ Ａｕｔｏｔｅｓｔｃｏｎ ２００５ Ｄｉｇｅｓｔ ｏｆ Ｐａｐｅｒｓ，ｐｐ．４０２－４０７，Ｏｒｌａｎｄｏ，ＦＬ，２６－２９Ｓｅｐｔ．２００５ Ｌｏｗｄｅｒｍｉｌｋ，Ｒ．Ｗ．；Ｈａｒｒｉｓ，Ｆ．Ｊ．；"Ｖｅｃｔｏｒ Ｓｉｇｎａｌ Ａｎａｌｙｚｅｒ Ｉｍｐｌｅｍｅｎｔｅｄ ａｓ ａ Ｓｙｎｔｈｅｔｉｃ Ｉｎｓｔｒｕｍｅｎｔ，"Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ ａｎｄ Ｍｅａｓｕｒｅｍｅｎｔ，ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ，ｖｏｌ．５８，ｎｏ．２，ｐｐ．２８１－２９０，Ｆｅｂ．２００９

試験中のデバイス（ＤＵＴ）を試験するためのシステム及び方法の様々な実施形態を提示する。ここでＤＵＴは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク（ＩＮ）とを含む多重プロセッサアレイ（ＭＰＡ）を含む。アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するＭＰＡは、試験中のデバイス（ＤＵＴ）であるか、又は試験中のデバイス（ＤＵＴ）に含まれる。

一実施形態では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むよう修正してよく、これにより修正されたアプリケーションソフトウェアが生成される。修正されたアプリケーションソフトウェア中の試験用コードは、少なくとも１つの副次的送信命令文を含んでよい。アプリケーションソフトウェアは、多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で実行されるよう、及び／又は上記第１のハードウェアリソースを使用するよう構成してよく、ここで試験用コードは、第１のハードウェアリソースのうちの少なくとも１つ上で実行されるように構成してよく、またＭＰＡの１つ又は複数の第２のハードウェアリソースを使用するよう構成され、ここで上記１つ又は複数の第２のハードウェアリソースは、第１のハードウェアリソースとは異なり、かつアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するＭＰＡは試験中のデバイス（ＤＵＴ）を備える。

ＭＰＡ上で実行される修正されたアプリケーションソフトウェアは、入力データを受信してＤＵＴを刺激し、入力データに基づいてＤＵＴ内で第１のデータを生成し、第１の送信命令文を実行して、上記修正されたアプリケーションソフトウェアが使用するために第１のデータを提供し、少なくとも１つの副次的送信命令文を実行することにより、第２のハードウェアリソースのうちの少なくとも１つを用いて、第１のデータの少なくともサブセットを、ＭＰＡのエッジのピンに供給してよい。

少なくとも１つの副次的送信命令文によって供給される第１のデータの上記少なくともサブセットを受信でき、この第１のデータの上記少なくともサブセットはＤＵＴの分析に使用できる。

いくつかの実施形態では、第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給するにあたって、少なくとも１つの副次的送信命令文は、第１のデータの上記少なくともサブセットをＭＰＡのエッジのピンに供給するように、ＭＰＡの第１のダイレクトメモリアクセス（ＤＭＡ）エンジンをプログラムしてよく、ここで第１のＤＭＡエンジンは、（アプリケーションソフトウェアの実行には使用されない）第２のハードウェアリソースのうちの１つである。アプリケーションソフトウェアは、ＭＰＡの第１のメモリに第１のデータを記憶するよう構成してよく、ここで第１のメモリは、アプリケーションソフトウェアが使用する第１のハードウェアリソースのうちの１つであり、第２のハードウェアリソースのうちの１つである第１のＤＭＡエンジンを含む複数のＤＭＡエンジンが第１のメモリに関連付けられている。一実施形態では、第２のＤＭＡエンジンは第１のメモリに関連付けられていてよく、ここで第２のＤＭＡエンジンは、第１のメモリに第１のデータを記憶するためにアプリケーションソフトウェアが使用する第１のハードウェアリソースのうちの１つである。いくつかの実施形態では、第１のデータの上記少なくともサブセットをＭＰＡのエッジのピンに供給するにあたって、少なくとも１つの副次的送信命令文は第１のデータをフィルタリングしてよく、これによって第１のデータの上記少なくともサブセットを生成する。

いくつかの実施形態では、第１の送信命令文は、第１のハードウェアリソースの第１のプロセッサ要素上で実行されるよう構成してよく、少なくとも１つの副次的送信命令文は、第１のハードウェアリソースの上記第１のプロセッサ要素上で実行されるよう構成してよい。ＤＵＴは、ＭＰＡ上でリアルタイムに最高動作速度で実行される、上記修正されたアプリケーションソフトウェアを備えてよい。いくつかの実施形態では、ＤＵＴは、ＤＵＴに連結された外部信号ソースからリアルタイムデータを受信して、ＤＵＴを刺激できる。

一実施形態では、アプリケーションソフトウェアの修正は、アプリケーションソフトウェア内に第１の送信命令文を配置するためにアプリケーションソフトウェアを分析すること、及びアプリケーションソフトウェア内の第１の送信命令文の近傍に少なくとも１つの副次的送信命令文を自動的に挿入することを含んでよい。また更なる実施形態では、アプリケーションソフトウェアの修正は、アプリケーションソフトウェア内に複数の送信命令文を配置するためにアプリケーションソフトウェアを分析すること、及びアプリケーションソフトウェア内の各上記送信命令文の近傍に、対応する１つ又は複数の副次的送信命令文を自動的に挿入することを含んでよい。あるいは又は更に、１つ又は複数の副次的送信命令文を、アプリケーションソフトウェア内の複数の送信命令文それぞれの近傍に、（ユーザが）手動で挿入してよい。

第１のデータは、ＭＰＡのＩＮを通る第１のデータパスを介して、修正されたアプリケーションソフトウェアが使用できるよう供給してよく、また第１のデータの上記少なくともサブセットは、ＭＰＡのＩＮを通る第２のデータパスを介して、ＭＰＡのエッジのピンに供給してよく、ここで第２のデータパスは第１のデータパスとは異なる。

いくつかの実施形態では、上述の技術を、ソフトウェア定義テストベンチによって実装又は実行してよく、上記ソフトウェア定義テストベンチは、ＤＵＴ性能に対する影響が無視できる程度である状態でＤＵＴを分析できるよう構成してよい。

別の実施形態では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むよう修正してよく、これにより修正されたアプリケーションソフトウェアが生成され、ここで、修正されたアプリケーションソフトウェア中の試験用コードは、少なくとも１つの副次的送信命令文を含み、ここで試験用コードは、ＭＰＡの１つ又は複数の第２の異なるリソースを使用するよう構成され、ここで上記１つ又は複数の第２の異なるリソースはアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するＭＰＡは試験中のデバイス（ＤＵＴ）を備える。

ＭＰＡ上で実行される修正されたアプリケーションソフトウェアは、入力データを受信してＤＵＴを刺激し、入力データに基づいてＤＵＴ内で第１のデータを生成し、第１の送信命令文を実行して、上記修正されたアプリケーションソフトウェアが使用するために第１のデータを提供し、副次的送信命令文を実行することにより、ＭＰＡの１つ又は複数の第２のリソースのうちの少なくとも１つを用いて、第１のデータをＭＰＡのエッジのピンに供給してよい。

副次的送信命令文によって供給される第１のデータを受信でき、この第１のデータはＤＵＴの分析に使用できる。

更なる実施形態では、アプリケーションソフトウェアを実行する多重プロセッサアレイ（ＭＰＡ）を備える試験中のデバイス（ＤＵＴ）を試験するための方法は、試験することが求められているアプリケーションソフトウェアを分析することを含んでよく、ここで上記アプリケーションソフトウェアは、多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で展開されるよう構成され、ＭＰＡは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク（ＩＮ）とを含む。本方法は更に、アプリケーションソフトウェアで生成されたデータを分析のために複製するためにＭＰＡ上にハードウェアリソースを構成するよう実行可能な試験プログラムコードを生成すること、及びアプリケーションソフトウェアをＭＰＡの第１のハードウェアリソース上で展開することを含んでよく、ここでアプリケーションソフトウェアを実行するＭＰＡは、試験中のデバイス（ＤＵＴ）を備える。入力データを供給してＤＵＴを刺激してよく、ここでＤＵＴは、アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するＭＰＡを備える。試験プログラムコードを実行することにより、アプリケーションソフトウェアの実行に使用されていないハードウェアリソースのうちの少なくとも１つを用いて、第１のデータの少なくともサブセットを、ＭＰＡのエッジのピンに供給してよく、ここで第１のデータは、アプリケーションソフトウェアが入力データに応答して実行する送信命令文に応答して生成される。試験プログラムコードを実行することによって得られた第１のデータの上記少なくともサブセットを受信でき、この第１のデータの上記少なくともサブセットはＤＵＴの分析に使用できる。

好ましい実施形態に関する以下の詳細な説明を、添付の図面と組み合わせて考慮すると、本発明の更なる理解を得ることができる。

図１は、従来技術による例示的な開発システムを示す。 図２は、従来技術による例示的な多重プロセッサアレイ（ＭＰＡ）システムを示す。 図３は、従来技術による例示的な多重プロセッサアレイ（ＭＰＡ）システムを示す。 図４は、従来技術による例示的な多重プロセッサアレイ（ＭＰＡ）システムを示す。 図５は、従来技術によるＭＰＡのためのソフトウェア開発フローを示すフローチャートである。 図６は、従来技術によるＭＰＡのためのソフトウェア開発フローを示すフローチャートである。 図７は、従来技術によるテストベンチ及び試験設備を示す。 図８は、従来技術によるテストベンチ及び試験設備を示す。 図９は、一実施形態による、アプリケーションソフトウェアを実行するＭＰＡを含むＤＵＴを試験するためのシステムを示す。 図１０は、一実施形態によるソフトウェア定義テストベンチを示す。 図１１は、一実施形態による、多重プロセッサシステムのためのソフトウェアを開発するための方法のフローチャートである。 図１２は、一実施形態による、アプリケーションソフトウェア内の副次的送信命令文を使用する、ＤＵＴを試験するための方法のフローチャートである。 図１３は、一実施形態による、アプリケーションソフトウェア外部の試験用コードを使用する、ＤＵＴを試験するための方法のフローチャートである。 図１４は、一実施形態による、プローブが使用できるようにデータストリームを分割するためのＤＭＡエンジンの使用を示す。 図１５は、一実施形態による、サンプリングのためのＦＩＦＯ制御を有するプローブが使用できるようにデータストリームを分割するためのＤＭＡエンジンの使用を示す。 図１６は、一実施形態による、ソフトウェアインストルメンテーションのために使用されるリソースを有する多重プロセッサアレイを示す。 図１７は、一実施形態による、ＭＰＡのデータメモリ及びルータ（ＤＭＲ）要素を示す。 図１８は、ソフトウェア無線のある実施形態のハイレベルブロック図である。 図１９は、ソフトウェア無線の別の実施形態のハイレベルブロック図である。 図２０は、印加された加法性ホワイトガウスノイズ（ａｄｄｉｔｉｖｅ ｗｈｉｔｅ Ｇａｕｓｓｉａｎ ｎｏｉｓｅ：ＡＷＧＮ）を特定及び／又は指示するための、例示的なＡＷＧＮユーザインタフェースを示す。 図２１は、一実施形態による例示的な信号空間ダイヤグラムを示す。 図２２は、一実施形態による、様々なパラメータ又は属性を構成及び／又は表示できるビデオソースビュー（ＧＵＩ）を示す。

本発明は様々な修正及び代替形態を許容するものであるが、その具体的な実施形態を例として図面に示し、また本明細書で詳細に説明する。しかしながら、上記具体的実施形態の図及び詳細な説明は、本明細書に開示する特定の形態に本発明を限定することを意図したものではなく、反対に、添付の請求項によって定義されるような本発明の精神及び範囲内にある全ての修正例、均等物及び代替例を包含することを意図したものであることを理解されたい。

参照による援用
以下の特許は、その全体を参照することにより、本明細書においてその全体が完全に論述されているかのように、本明細書に援用されるものとする：
米国仮特許出願第６１／７２４４９３号（２０１２年９月９日出願、発明の名称「Ｒｅａｌ Ｔｉｍｅ Ａｎａｌｙｓｉｓ ａｎｄ Ｃｏｎｔｒｏｌ ｆｏｒ ａ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ」）；
米国特許第７４１５５９４号（２００３年６月２４日出願、発明の名称「Ｐｒｏｃｅｓｓｉｎｇ Ｓｙｓｔｅｍ Ｗｉｔｈ Ｉｎｔｅｒｓｐｅｒｓｅｄ Ｓｔａｌｌ Ｐｒｏｐａｇａｔｉｎｇ Ｐｒｏｃｅｓｓｏｒｓ Ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｅｌｅｍｅｎｔｓ」、発明者Ｍｉｃｈａｅｌ Ｂ．Ｄｏｅｒｒ、Ｗｉｌｌｉａｍ Ｈ．Ｈａｌｌｉｄｙ、Ｄａｖｉｄ Ａ．Ｇｉｂｓｏｎ、Ｃｒａｉｇ Ｍ．Ｃｈａｓｅ）；
米国特許出願第１３／２７４１３８号（２０１１年１０月１４日出願、発明の名称「Ｄｉｓａｂｌｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎ ａ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ」、発明者Ｍｉｃｈａｅｌ Ｂ．Ｄｏｅｒｒ、Ｃａｒｌ Ｓ．Ｄｏｂｂｓ、Ｍｉｃｈａｅｌ Ｂ．Ｓｏｌｋａ、Ｍｉｃｈａｅｌ Ｒ Ｔｒｏｃｉｎｏ、Ｄａｖｉｄ Ａ．Ｇｉｂｓｏｎ）。

用語
以下は、本出願で使用する用語の解説である。

メモリ媒体：いずれの様々な種類のメモリデバイス又はストレージデバイス。用語「メモリ媒体」は、インストール媒体（例えばＣＤ－ＲＯＭ、フロッピー（登録商標）ディスク１０４若しくはテープデバイス）；コンピュータシステムメモリ若しくはＤＲＡＭ、ＤＤＲ ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、ラムバスＲＡＭ等のランダムアクセスメモリ；又は磁気メディア（例えばハードドライブ）、光学ストレージ若しくはＲＯＭ、ＥＰＲＯＭ、ＦＬＡＳＨ等の不揮発性メモリ等を含むことを意図している。メモリ媒体はその他のタイプのメモリ又はその組み合わせも同様に含んでよい。更に、メモリ媒体は、プログラムを実行する第１のコンピュータ内に配置してよく、及び／又はインターネット等のネットワークを介して第１のコンピュータに接続された第２の異なるコンピュータ内に配置してよい。後者の場合、第２のコンピュータは第１のコンピュータに、実行のためのプログラム命令を提供してよい。用語「メモリ媒体」は、異なる位置、例えばネットワークを介して接続された異なるコンピュータ内にあってよい２つ以上のメモリ媒体を含んでよい。

キャリヤ媒体：上述のようなメモリ媒体、バスやネットワークといった物理的な伝送媒体、及び／又は電気信号若しくは光信号等の信号を搬送するその他の物理的な伝送媒体。

プログラマブルハードウェア要素：これは、プログラム可能な又は結線接続された相互接続を介して接続された複数のプログラマブル機能ブロックを備える、様々なハードウェアデバイスを含む。例としては、ＦＰＧＡ（フィールド プログラマブルゲートアレイ）、ＰＬＤ（プログラマブルロジックデバイス）、ＦＰＯＡ（フィールドプログラマブルオブジェクトアレイ）及びＣＰＬＤ（複合ＰＬＤ）が挙げられる。プログラマブル機能ブロックは、細粒度（例えば組み合わせ論理又はルックアップテーブル）から粗粒度（演算処理装置又はプロセッサコア）に及ぶ範囲のものであってよい。プログラマブルハードウェア要素は「再設定可能論理」と呼んでもよい。

特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）：この用語は、その通常使用される意味全てを有することが意図されている。用語「ＡＳＩＣ」は、汎用プログラマブルデバイスではなく、特定の用途に対してカスタマイズされた集積回路を含むことを意図したものであるが、ＡＳＩＣは基本単位としてプログラム可能なプロセッサコアを含んでよい。携帯電話のセル、ＭＰ３プレイヤーのチップ、その他多数の単一機能ＩＣがＡＳＩＣの例である。ＡＳＩＣは通常、Ｖｅｒｉｌｏｇ又はＶＨＤＬといったハードウェア記述言語で記述される。

プログラム：用語「プログラム」は、その通常の意味全体を含むことを意図したものである。用語「プログラム」は：１）メモリに記憶させることができ、プロセッサが実行可能なソフトウェアプログラム；又は２）プログラマブルハードウェア要素を構成するために使用可能なハードウェア構成プログラムを含む。

ソフトウェアプログラム：用語「ソフトウェアプログラム」は、その通常の意味全体を含むことを意図したものであり、いずれのタイプのプログラム命令、コード、スクリプト及び／若しくはデータ又はこれらの組み合わせを含み、これらはメモリ媒体に記憶でき、プロセッサによって実行できる。例示的なソフトウェアプログラムは：例えばＣ、Ｃ＋＋、ＰＡＳＣＡＬ、ＦＯＲＴＲＡＮ、ＣＯＢＯＬ、ＪＡＶＡ（登録商標）、アセンブリ言語等の命令型又は手続き型言語であるテキストベースプログラム言語で書かれたプログラム；グラフィカルプログラム（グラフィカルプログラム言語で書かれたプログラム）；アセンブリ言語プログラム；機械言語にコンパイルされたプログラム；及びその他のタイプの実行可能なプログラムを含む。ソフトウェアプログラムは、何らかの方法で連携した２つ以上のソフトウェアプログラムを含んでよい。

ハードウェア構成プログラム：プログラマブルハードウェア要素又はＡＳＩＣをプログラム又は構成するために使用できるプログラム（例えばネットリスト又はビットファイル）。

コンピュータシステム：パーソナルコンピュータシステム（ＰＣ）、メインフレームコンピュータシステム、ワークステーション、ネットワーク家電、インターネット家電、パーソナルデジタルアシスタント（ＰＤＡ）、グリッドコンピューティングシステム若しくはその他のデバイス又はデバイスの組み合わせを含む、様々なタイプの計算又は処理システムのいずれか。一般に、用語「コンピュータシステム」は、メモリ媒体からの命令を実行する少なくとも１つのプロセッサを有するいずれのデバイス（又は複数のデバイスの組み合わせ）を包含するものとして広く定義できる。

自動的に（ａｕｔｏｍａｔｉｃａｌｌｙ）：その動作又は操作を直接指定又は実施するユーザ入力を必要とせずに、コンピュータシステムが実施する動作又は操作（例えばコンピュータシステムが実行するソフトウェア）について用いる。従って用語「自動的に」は、ユーザが手動で実施又は指定する操作（ここでユーザが操作を直接実施するために入力を提供する）と対照的なものである。自動処理は、ユーザが提供する入力によって開始される場合があるが、これに続く「自動的に」実施される動作は、ユーザが指定するものではなく、即ち「手動で」実施される（ユーザが各動作の実施を指定する）ものではない。例えばユーザが、各フィールドを選択し、（例えば情報をタイピングすることによって、チェックボックスを選択することによって、無線選択によって等で）情報を指定する入力を提供することによって、電子フォームを埋める場合、仮にコンピュータシステムがユーザの動作に応答して上記フォームを更新しなければならないとしても、これは上記フォームを手動で埋めたことになる。このようなフォームはコンピュータシステムによって自動で埋めることができ、この場合コンピュータシステム（例えばコンピュータシステム上で実行されるソフトウェア）は、フォームのフィールドを分析して、フィールドへの回答を指定するいずれのユーザ入力を必要とせずにフォームを埋める。上述のように、ユーザはフォームを自動で埋める動作を発動する場合はあるが、実際にフォームを埋める動作には関わらない（例えばユーザはフィールドへの回答を手動で指定せず、回答は自動的に完了する）。本明細書は、ユーザが行う動作に応答して自動的に実施される操作の様々な例を提供する。

開発プロセス：ある方法論に基づく開発のためのライフサイクルを指す。広義には、設計、実装、確認、展開、保守を通してユーザの要件及び制約に対処する方法を指す。

概説
これより、試験インストルメンテーションがデータ処理デバイス（特に多重処理デバイス）及びこれらに関連するソフトウェア開発システム内に構築される、リアルタイム分析及び制御（ｒｅａｌ ｔｉｍｅ ａｎａｌｙｓｉｓ ａｎｄ ｃｏｎｔｒｏｌ：ＲＴＡＣ）のためのシステムの様々な実施形態について説明する。ＲＴＡＣは、データ処理デバイスが製品アプリケーションを最高速度で実行している間に、保護されていないデバイスのいずれの内部状態にアクセス（読み出し又は書き込み）し、データ処理デバイスが製品アプリケーションを実行している間に、デバイス内の保護されていないいずれの場所にデジタル信号ストリームを接続し、デジタル信号ストリームを様々な標準的方法（間引き、補間、フィルタリング、ノイズ付加、パターン又は閾値に対するトリガ、フーリエ変換等）で処理し、試験信号を生成して比較を行って信号を処理し、自律的に高速で動作し、ソフトウェア部品（「ビュー（ｖｉｅｗ）」と呼ばれる）を用いて比較的容易に設定できるように構成できる。

ここで開示するＲＴＡＣアプローチは、再使用可能かつカスタム設定可能なモジュールを備える開発ソフトウェアを含み、自律的に動作でき、従ってソフトウェア開発コストを削減でき、また適合可能な処理デバイスを使用する製品におけるアプリケーションソフトウェアの品質を改善できる。

なお、ここで開示する技術は、特定のアレイサイズのＭＰＡに関して特に有益であり得る。例えば例示的な一実施形態では、ＭＰＡは３つ以上のＰＥを含んでよい。他の例示的実施形態では、ＭＰＡのサイズ（アレイ内のＰＥ、補助メモリ、関連する通信リソースの数）は何らかの所定の数以上であってよく、様々な異なる実施形態において、この数は例えば４、８、１６、２４、３２、６４等の所望の値を有してよい。より一般には、特定の用途又は使用法に応じて、ＭＰＡ内のＰＥの数はある特定の下限を有してよく、この下限は必要に応じていずれの複数の値となるよう指定できる。

リアルタイム制御
いくつかの実施形態では、リアルタイム制御（Ｒｅａｌ－Ｔｉｍｅ Ｃｏｎｔｒｏｌ：ＲＴＣ）の基本的な考え方は、リンカが、ランタイムソフトウェアが使用する変数及びパラメータの、ＳＭ内での絶対位置を含むテーブルを生成するというものである。このリンカテーブルは、アプリケーションソフトウェアの動作中に特定のアドレスに対して個々の値を「ピーク（ｐｅｅｋ）」及び「ポーク（ｐｏｋｅ）」するために、例えばシリアルバスである二次相互接続ネットワークと共に使用してよく、これ以外の点で二次相互接続ネットワークに干渉することはない。ＭＰＡがそのハードウェア内に、一次相互接続ネットワーク（ＰＩＮ）とは独立したシリアルバス等の二次相互接続ネットワーク（ＳＩＮ）を有する場合、無干渉とすることもできる。ＳＩＮは典型的には、高帯域幅ＰＩＮよりも大幅に低い帯域幅を有し、従ってＳＩＮはアプリケーションソフトウェアによって使用されない。

例示的なＳＩＮは、米国特許出願第１３／２７４１３８号（発明の名称「Ｄｉｓａｂｌｉｎｇ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎ ａ Ｍｕｌｔｉｐｒｏｃｅｓｓｏｒ Ｓｙｓｔｅｍ」）に開示されており、この特許出願は既に参照により本出願に援用されている。

一実施形態では、対話式ソフトウェア開発環境は、リンカテーブルを維持する様々なツールを提供してよく、ＲＴＣツール（これはＲＴＡＣツールの一部であってよい）は、「書き込み（値、アドレス）」を複数のＳＩＮコマンドの組に自動的に翻訳し、これらコマンドをＰＣから開発システムボードへ、続いてＤＵＴへと通信し、ここでこれらＳＩＮコマンドの実行は、特定のアドレスの変数／パラメータに特定の値を書き込む。

同様に、変数又はパラメータの値を読み出すために、リンカテーブルを使用してその位置及びアドレス情報を得てよい。ＲＴＣツールを呼び出して、又は使用して、「読み出し（アドレス）」をＳＩＮコマンドに翻訳し、このＳＩＮコマンドを続いてＤＵＴへと通信してよい。実行時、内部の値を読み出し、ＰＣと通信してこれを戻して表示してよい。スクリプトを用いて多数の変数／パラメータを変更してよいが、アレイを扱うために汎用スクリプトを開発してよい。

リアルタイム分析
いくつかの実施形態では、リアルタイム分析（ｒｅａｌ‐ｔｉｍｅ ａｎａｌｙｓｉｓ：ＲＴＡ）ツール（これはＲＴＡＣツールの一部であってよい）を提供してよく、これは、ワークステーション、即ち例えばＰＣ／ラップトップコンピュータ又は他のいずれのタイプの所望のコンピュータであるホストコンピュータ上で実行される全体制御プログラムを含み、これは、試験中のデバイス（ＤＵＴ）及び最終的な用途に適切であるクロック速度でＭＰＡ上で動作するそのプリケーションソフトウェアを動作させるソフトウェア定義テストベンチ（ＳＤＴＢ）を管理する（及びいくつかの実施形態ではその一部と考えることもできる）。

図９ ＤＵＴを試験するための例示的なシステム
図９は、一実施形態による、アプリケーションソフトウェアを実行するＭＰＡを含むＤＵＴを試験するためのシステムを示す。図示したように、この例示的実施形態では、このシステムは、ホストコンピュータ、開発システムとＤＵＴを試験するために構成されたテストベンチとを試験設備と共に含む開発ボード、そしてこの特定の場合においてはプロセッサＩＣ（集積回路）、並びに例えば論理アナライザ又はオシロスコープ及び外部信号ソース（例えばビデオカメラ）といった機器を含む。いくつかの実施形態では、ホストコンピュータ、開発ボード及び上記機器は、本記述の実施形態を実装できるソフトウェア定義テストベンチを構成できる。

ソフトウェア定義テストベンチ（ＳＤＴＢ）は、ＤＵＴを刺激してそこからデータを収集するために、例えば１つ若しくは複数の試験ベクタ及び／又は信号ストリームといった（少なくともいくつかの）入力データを提供するよう構成してよいが、いくつかの実施形態では、入力データは、図９に示すように、場合によっては開発ボードを介してＤＵＴに連結された外部信号ソースからのリアルタイム信号（例えばデータ）を含んでよい。ＳＤＴＢは、ＤＵＴと同等の速さとなるよう、またＤＵＴの性能に無視できる程度の影響しか及ぼさないよう設計してよい。ＳＤＴＢは、ＤＵＴに刺激及び応答試験ベクタを供給するよう構成してよく、その動作に関するデータを収集する。ＳＤＴＢは、精査された信号をサブサンプリングしてＰＣのデータ処理要件を低減するよう構成してよく、いくつかの実施形態では、合成機器及び模擬的ＲＦアナログチャネル障害を含むように拡張できる。

図１０は、一実施形態による、アプリケーションソフトウェアを実行するＭＰＡを含むＤＵＴを試験するための例示的システムのハイレベル図である。図示したように、このシステムは少なくとも、ホストコンピュータがここで開示する新規の技術の少なくとも一部分を実装している点で図７の従来技術のシステムとは異なる。より具体的には、ホストコンピュータは、ここで開示する新規の方法の実施形態を実施するために実行できるプログラム命令と共に構成され、例えば、アプリケーションソフトウェア及び／又は外部試験用コードを、実行中にアプリケーションソフトウェアが生成したデータの少なくともサブセットを複製する（及び場合によってはフィルタリング又はその他の処理を行う）ように構成し、例えば通常使用中に、即ち試験／デバッグ環境又はコンテキストの外で、アプリケーションソフトウェアによって使用されないＭＰＡのハードウェアリソースをプログラミングすることによるデバッグ又は分析のために、データ（の少なくともサブセット）をＭＰＡの境界に搬送する。この複製及び／又はフィルタリング若しくはその他の処理を施されたデータをここでは「副次的データ（ａｕｘｉｌｉａｒｙ ｄａｔａ）」又は「副次的ストリームデータ（ａｕｘｉｌｉａｒｙ ｓｔｒｅａｍ ｄａｔａ）」と呼んでよい。なお、様々な実施形態では、フィルタリングはデータのサンプリングを含んでよく、従って副次的データの量はオリジナルデータよりも少なくすることができる。別の例示的実施形態では、フィルタリングは、例えばデータを平均してオリジナルデータに対応するより低解像度のデータを生成することによる、データの削減を含んでよい。他のいずれの種類のフィルタリング（処理）を必要に応じて使用してよい。

例示的な革新的特徴
上述のＲＴＡシステムのコンセプトの１つの有用な特徴は、アプリケーションの性能に対して影響を無視できる程度にしか、又は全く及ぼすことなく、ＤＴＵ内の高帯域幅データフローを精査できる点である。これは、ソフトウェア開発ツールのために開発されたソフトウェアプローブが、ＤＵＴに対してコード及び実行サイクルをごくわずかにしか（典型的には１％未満しか）追加しないことによって可能となる。アプリケーションソフトウェアは典型的には、全ての利用可能なＭＰＡリソースを消費するわけではなく、またデータのブロックを処理するために割り振られた時間全てを消費するわけではないため、サイクル、電力放散及び／又はメモリの使用が１％増大してもほとんど感知できない。

ソフトウェアプローブは少なくとも２つの作業を実施してよい。即ち、ストリームからのデータのブロックの少なくとも一部分の読み出し（及び場合によってはフィルタリング又はその他の処理）を複製し、そのデータをＭＰＡ上の、他の目的で使用されないバッファに書き込む。いくつかの実施形態ではＰＥがこれを行ってよいが、ハードウェアＤＭＡエンジンがはるかに効率的であり（電力の放散が小さく）、従って他の実施形態では、可能な全ての場合においてＤＭＡエンジンを使用してよい。

高帯域幅データストリームにアクセスすることによる主要な問題は、タップにより生成された全てのデータをどのように処理するかである。いくつかの実施形態では、これらのデータを可能な限り迅速にフィルタリング及びサブサンプリングしてよい。従って一実施形態では、副次的ストリームデータバッファ又はプローブストリームへのアクセスを有するＭＰＡ上の他の目的で使用されないＰＥを、データをフィルタリング及びダウンサンプリングして、得られたデータを並列ポートへ、そして更にホストコンピュータへ送信するようにプログラミングしてよい。場合によっては、データストリームをタップするＤＭＡエンジンによってサブサンプリングを完全に達成してよい。

同一の又は別の、他の目的で使用されないＰＥによって、ＲＴＡシステムをサポートするためにオンチップで必要な他の試験制御機能を提供してよい。これらは、試験刺激として又はチャネル障害のために使用するための、合成信号及びノイズの生成を含んでよい。

いくつかの実施形態では、ホストコンピュータは、例えば直交振幅変調（ｑｕａｄｒａｔｕｒｅ ａｍｐｌｉｔｕｄｅ ｍｏｄｕｌａｔｉｏｎ：ＱＡＭ）である異なる変調に関する信号空間ダイヤグラムをサポートするソフトウェアを含んでよく、入力される刺激は制御されるため、ソフトウェアはビットエラーレート、パケットエラーレート等を蓄積できる。いくつかの実施形態では、ソフトウェアは、ベクタ信号分析のために、特定の理想的な信号を実際の信号と比較するよう構成してよい。

いくつかの実施形態では、ホストコンピュータは、実験の進行中にその実験を適合させるか又はその他の方法で修正して、実験をより効率的なものとすることができる。例えば高い信号対ノイズ比（ｓｉｇｎａｌ‐ｔｏ‐ｎｏｉｓｅ ｒａｔｉｏ：ＳＮＲ）から低いＳＮＲへのＳＮＲのスイープは、高いＳＮＲに関して低いパケットカウントで始まり、より低いＳＮＲに関してパケットカウントがより高く変化し、信頼度要件を維持できる。

なお、システムは完全にソフトウェア内で動作するため、刺激を印加でき、その結果を、ＤＵＴがＭＰＡチップ上で動作するのと同等に迅速に蓄積できる。ＭＰＡが製品設計値より早いクロックを供給されている場合、上記結果は設計目標の「リアルタイム」よりも早く蓄積できる。

例示的実施形態及び実装形態
これより、ここで開示する技術の様々な例示的実施形態及び実装形態について説明する。しかしながら、説明される特定の実施形態及び技術は、本発明をいずれの特定の形態、機能又は外観に限定するものではないことに留意されたい。例えばこれらの実施形態のうちのいくつかについては、具体的な用語、構文又は要素を用いて説明するが、記載される用語、構文又は特定の要素は例示のみを目的としたものであり、考察されている実施形態をいずれの特定の名称、構文、形態、構造又は外観のセットに限定することを意図したものではない。

図１１ ソフトウェア開発のための方法のフローチャート
図１１は、一実施形態による、多重プロセッサシステム用のソフトウェアを開発するための例示的な方法のフローチャートである。より具体的には、図９は、フローにおいてプローブを挿入できる例示的な場所を示す。上述のように、ここで開示する技術はツールによって実装でき、このツール自体は多数のツール又はモジュールを含んでよい。いくつかの実施形態では、このツールはＩＳＤＥから又はＩＳＤＥ内で発動してよく、他の実施形態ではこのツールはスタンドアロン型ツールとして動作してよい。いくつかの実施形態では、このツールは呼び出し可能な機能及び／若しくは定義された構造のツールキットとして、又はソフトウェアスイートとして実装してよい。

図１１に示すように、本方法は図５のフローチャートと同様に、（例えば高級プログラム言語での）ソフトウェアアプリケーションの完全な設計、及び「言語のコンパイル／アセンブリ」の受容を含んでよく、ここではコンパイラを用いてソースコードをモジュール単位のアドレス再配置可能なオブジェクトコードに翻訳し、続いてアセンブラを用いて、モジュール単位の機械コードを生成し、最後にリンカを用いて、プログラム全体の実行可能なバイナリイメージを生成する。これらのステージのいずれにおいて、及びこれらのステージの間に、最適化を実施してもよい。上述のように、「設計を処理してチッププログラミングファイルを生成する」と記された最適化を含む、このようなコンパイル、アセンブリ、リンク（バイナリイメージ作成）プロセスは、「メイクファイル」内に記憶されたオペレーティングシステムへの命令によって自動化してよい。プログラムを試験するには、アプリケーションプログラムを対象ハードウェア上で実行する又は動作させるために、一般にはバイナリイメージを対象デバイスのメモリにロードする（これは図１１において、「チッププログラミング情報」を準備して実装することとして表されている）。上で示したように、プログラムは対象ハードウェア上で実行され、本方法はワークステーション（ホストコンピュータ）との通信を含む。また図示したように、本方法はテストハーネスとの通信、結果として得られたデータの処理、ワークステーション（ホストコンピュータ）上での又はワークステーション（ホストコンピュータ）における結果の表示を含んでよいが、いくつかの実施形態ではこれに加えて又はこれの代わりに、結果を後で閲覧するために、例えばローカルに又はネットワークを介してストレージデバイスに記憶してよい。

図１１に更に示すように、１つ又は複数のプローブを本方法の様々なポイントのいずれに挿入してよい。例えば様々な実施形態では、１つ又は複数のプローブを、特にリソース割り振りの前、リンキングの後及び／又は実行中に挿入してよい。様々な実施形態ではプローブを自動的に挿入してよく、又は以下で議論するように、例えばユーザ（例えば開発者若しくは試験者）によって手動で挿入してよいことに留意されたい。

いくつかの実施形態では、ツールはソフトウェア定義テストベンチを制御するよう構成された制御プログラムを含んでよい。ソフトウェア定義テストベンチは、試験中のデバイス（ＤＵＴ）及びＤＵＴ上で実行されるアプリケーションソフトウェアをリアルタイムに試験するよう構成してよく、ここでＤＵＴは、複数の処理要素と、補助メモリと、上記複数の処理要素と上記補助メモリとを通信可能に連結する高帯域幅相互接続ネットワーク（ＩＮ）とを含む多重プロセッサアレイ（ＭＰＡ）を含む。ソフトウェア定義テストベンチはまた、例えば試験ベクタ及び／又は信号ストリームである入力データを供給して、ＤＵＴを刺激し、ＤＵＴの刺激によって得られたデータを受信するよう構成してよい。更に又はあるいは、ＤＵＴは、ＤＵＴに連結された外部信号又はデータソースから、入力データ、即ち例えばビデオカメラからのリアルタイム信号を受信するよう構成してよい。

更にソフトウェア定義テストベンチは、ＤＵＴがアプリケーションソフトウェアを実行している間に、ＤＵＴ及びアプリケーションソフトウェアをリアルタイムに最高動作速度で分析（例えば試験）するよう構成してよい。いくつかの実施形態では、ソフトウェア定義テストベンチは、ＤＵＴ及びアプリケーションソフトウェアの性能に全く影響を及ぼすことなく、ＤＵＴ及びアプリケーションソフトウェアを分析するよう構成してよく、他の実施形態では、ＤＵＴ及びアプリケーションソフトウェアの性能に対する影響はゼロではないものの無視できる程度であってよく、即ちユーザが検出できないほど小さいか、アプリケーションの動作に測定可能な影響がないほど小さいか、又は以下でより詳細に議論するように何らかの特定された許容誤差内であってよい。一実施形態では、ＭＰＡは、ＭＰＡの第１の部分を用いてソフトウェアアプリケーション（又はアプリケーションソフトウェア）を実行するよう構成してよく、またツールは、ＭＰＡの第２の部分に対する１つ又は複数のソフトウェアプローブを自動的に構成するよう構成してよい。ＤＵＴがアプリケーションソフトウェアを実行している間に、ＤＵＴ及びアプリケーションソフトウェアを最高動作速度で分析するために、１つ又は複数のソフトウェアプローブは、分析又は制御のために、実行中にソフトウェアアプリケーションに対してデータの読み書きを行うよう構成してよい。更なる詳細を以下で提供する。

リアルタイムデバッグ
いくつかの実施形態では、リアルタイムデバッグは、アプリケーションランタイムソフトウェアを実行しているハードウェアＤＵＴに「デバッグプローブ」を挿入することによって実装してよく、これにより内部信号を監視する。理想的には、デバッグプローブは完全に非侵襲性であり、即ちユーザのアプリケーションソフトウェアの動作に対して一切の影響を及ぼさない。いくつかの状況ではこれが成立し得るが、ほとんどの状況では、上記影響は無視できる程度のものとなり、いくつかの状況では、プローブの挿入に十分なリソースが存在しない場合があるか、又はプローブの挿入に対するセキュリティ障壁が存在する場合がある。なお、用語「無視できる程度の影響（ｎｅｇｌｉｇｉｂｌｅ ｅｆｆｅｃｔｓ）」、「リアルタイム（ｒｅａｌ ｔｉｍｅ）」は、特定の応用分野又は考慮される使用法に応じて異なる許容誤差レベルを示してよい。例えばいくつかの実施形態では、これらの用語は、試験がＤＵＴ及び／又はアプリケーションの性能に１％未満の影響を及ぼす状態で実施されることを意味してよい。同様に他の様々な例示的実施形態では、許容誤差は、例えば指定された要件に対して０．１％未満、０．５％未満、１％未満、２％未満、３％未満、４％未満、５％未満等であってよい。より一般には、様々な異なる実施形態において、許容誤差（即ち「無視できる程度の（ｎｅｇｌｉｇｉｂｌｅ）及び「リアルタイムに最高動作速度で（ｒｅａｌ ｔｉｍｅ ａｔ ｆｕｌｌ ｏｐｅｒａｔｉｏｎａｌ ｓｐｅｅｄ）」の意味）は、いずれの所望の値となるように適宜指定してよい。

例示的な一実施形態では、プローブは、例えばＰＥ、アプリケーションソフトウェアが使用しない通信リソースといったＭＰＡハードウェアファブリック上で実行されるタスクとして実装してよい。プローブは所望のデータを、開発ボード及びソフトウェア開発ツールのためのホストマシンとして機能する接続されたＰＣへ、又は論理アナライザ等のデバイスへ、チップ外に送出してよい。ホストマシン上では、データをファイル内に配置し、グラフィック表示し、及び／又はスピーカ若しくはビデオモニタ等の取り付けられたデバイスに送出してよい。またホストマシンはＤＵＴに試験信号入力データを高速で供給してよく、これが直接行われない場合は、ＤＵＴに隣接するか又はＤＵＴ近傍のＳＤＲＡＭに入力データファイルを転送することによって行われる。いくつかの試験に関して、入力データはＤＵＴ上で生成されるが、他の場合においては外部信号生成器を使用してよい。

デジタル信号に関するプローブは、多数の異なる方法で実装してよい。いくつかの実施形態では、プローブはサンプリング部分、データ処理部分、チップ出力部分を含んでよい。いくつかの実施形態では、ＭＰＡはデータをホストマシンに送信するために、データをパケットとして形成又はフォーマットしてよく、他の実施形態では、ＭＰＡはこの目的のためにデータを別のチップに送信してよい。

副次的送信
プローブのサンプリング部分を実装するための１つの例示的な方法は、ＰＥタスク内において、対象の信号に関する第１の「送信」命令文を探し、第１の送信の後に第２の（副次的）送信命令文を挿入することであり、この第２の（副次的）送信命令文は同一の信号に対するものであるが、関連する通信経路がＤＭＲを異なる方向から出るようにし、この経路を自由経路に沿ってチップＩ／Ｏポートへと配向するものである。これら送信命令文を両方とも含むタスクを再コンパイルし、アプリケーションソフトウェアの残りの部分とリンクさせて、試験及び分析のための単一のタップを有するバイナリイメージを生成してよい。続いて、送信タスクが対象の信号のデータのブロックを送信するたびに、これは同一のデータのブロックをプローブにも送信する。これは、プローブが非侵襲性であるという要件に完全には適合しない。というのは、送信タスクは第２の送信を実行しなければならず、これはタスクを実行するためのサイクルを追加するからである。しかしながら、第２の送信が、アプリケーションソフトウェアが使用していないハードウェアリソースを利用する場合、上述のコストを緩和できる。例えば第２の（副次的）送信命令文がＤＭＡエンジンを使用する場合、ＰＥはＤＭＡ制御レジスタの書き込みに対して数ＰＥクロックサイクル分しか遅延しないものとなり得、そしてＰＥはアプリケーションタスクと共に継続できる。通常これらの追加のサイクルは、タスクに割り振られた時間に比べて無視できる程度のものである。別の例として、いくつかの実施形態では、第２の又は副次的送信命令文は、オンチップネットワークを利用して、プローブデータをＭＰＡのエッジに供給してよい。

図１２は、例示的な一実施形態による、副次的送信命令文を用いて試験中のデバイス（ＤＵＴ）を試験するための方法のハイレベルフローチャートである。ＤＵＴは多重プロセッサアレイ（ＭＰＡ）を含んでおり、ＭＰＡの様々な実施形態は上述した通りである。図１２に示す方法は、特にこれまでに図示したコンピュータシステム又はデバイスのいずれと組み合わせて使用してよい。図示した例示的実施形態では、本方法は、その一部をソフトウェア定義テストベンチによって、またその一部をＭＰＡ上で実行される（修正された）アプリケーションソフトウェアによって実行され、これは図１２において「ソフトウェア定義テストベンチ１００」及び「修正されたアプリケーションソフトウェア２００」で示した通りである。

様々な実施形態では、図示した方法要素のいくつかは、同時に若しくは図示したものと異なる順序で実施してよく、又は省略してよい。また必要に応じて追加の方法要素を実施してもよい。図示したように、この方法は以下のように動作できる。

まず１２０２では、試験することが求められているアプリケーションソフトウェアを、例えばメモリ媒体に記憶してよい。アプリケーションソフトウェアは、ＭＰＡの第１のハードウェアリソース上で実行されるよう展開可能となり得る。ＭＰＡは上述のように、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する相互接続ネットワーク（ＩＮ）とを含んでよい。

１２０４では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むように修正して、修正されたアプリケーションソフトウェアを生成してよい。修正されたアプリケーションソフトウェア内の試験用コードは、少なくとも１つの副次的送信命令文を含んでよい。

いくつかの実施形態では、試験用コードはアプリケーションソフトウェア内に自動的に含まれてよく、即ち例えばソフトウェア定義テストベンチによってアプリケーションソフトウェア内に含める操作を発動又は実施する直接的なユーザ入力なしに、含まれてよい。例えばアプリケーションソフトウェア内に第１の送信を配置するためにアプリケーションソフトウェアを分析してよく、アプリケーションソフトウェア内の第１の送信命令文の近傍に副次的送信命令文を自動的に挿入してよい。更にいくつかの実施形態では、アプリケーションソフトウェア内に複数の送信命令文を配置するためにアプリケーションソフトウェアを分析してよく、プリケーションソフトウェア内の上記複数の送信命令文それぞれの近傍に、対応する１つ又は複数の副次的送信命令文を自動的に挿入してよい。よって試験用コードは、複数の副次的送信命令文を含んでよい。なおいくつかの実施形態では、アプリケーションソフトウェア内のどの送信命令文が目標の送信命令文であるかをユーザが選択又は指示してよく、これに従って副次的送信を自動的に挿入してよい。換言すると、ユーザは、どの送信命令文（又は目標の信号／データ）を精査すべきかを指定してよく、本方法又はツールは、選択又は指示された送信命令文それぞれの近傍に、それぞれ１つ又は複数の副次的送信を自動的に挿入してよい。

他の実施形態では、試験用コードはユーザによって手動でアプリケーション内に含めてよく、例えばユーザは試験用コードをアプリケーションソフトウェアに、例えばエディタを介して、又はソフトウェア定義テストベンチ以外のプロセスによって、挿入してよい。更なる実施形態では、自動技術と手動技術との様々な組み合わせを利用してよい。例えばツールは送信命令文を自動的に発見又は配置してよく、ユーザは目標の送信命令文を指示又は選択して、これに従って副次的送信命令文を手動で挿入してよい。他の実施形態では、ユーザは送信命令文の配置を手動で決定してよく、またどの送信命令文が目標のものであるかを決定してよく、副次的送信を手動又は自動で挿入してよい。

１２０６では、修正されたアプリケーションソフトウェアをＭＰＡのハードウェアリソース上で展開してよい。この展開は、ＭＰＡの第１のハードウェアリソースを使用するためにアプリケーションソフトウェアを展開すること、及び試験コードを、第１のハードウェアリソースのうちの少なくとも１つにおいて実行され、かつＭＰＡの１つ又は複数の第２のハードウェアリソースを使用するよう構成されるようにするために展開することを含んでよく、ここで第２のハードウェアリソースは第１のハードウェアリソースとは異なり、またアプリケーションソフトウェアによって使用されることはない。修正されたアプリケーションソフトウェアをリアルタイムに最高動作速度で実行するＭＰＡは、試験中のデバイス（ＤＵＴ）を備えてよく、即ちＤＵＴを含むか、ＤＵＴであるか、又はＤＵＴに含まれていてよい。

いくつかの実施形態では、修正されたアプリケーションソフトウェアをＭＰＡの第１のハードウェアリソース上で、例えばソフトウェア定義テストベンチによって自動的に展開してよい。他の実施形態では、修正されたアプリケーションソフトウェアをＭＰＡの第１のハードウェアリソース上で、何らかの他の作因によって、例えばユーザが手動で、又はソフトウェア定義テストベンチ以外のプロセスによって、展開してよい。

１２０８では、修正されたアプリケーションソフトウェアが入力データを受信して、ＤＵＴを刺激してよい。いくつかの実施形態では、入力データのうちの少なくともいくつかは、ソフトウェア定義テストベンチによって、例えばホストコンピュータによって供給されて、ＤＵＴを刺激してよい。例えばソフトウェア定義テストベンチは、ＤＵＴ／アプリケーションソフトウェアのための入力データのセットを含む試験ベクタを供給してよく、またいずれの所望のタイプ及び数のデータ又は信号を含んでよい。

更に又はあるいは、いくつかの実施形態では、ＤＵＴは、例えば開発ボードを介してＤＵＴに連結された外部信号（データ）ソースから入力データを受信してよい。一実施形態では、外部信号ソースは、ＤＵＴを刺激するためのリアルタイム及び／又は実環境データを供給してよい。換言すると、ＤＵＴは、ＤＵＴに連結された外部信号ソースからリアルタイムデータを受信して、ＤＵＴを刺激してよい。外部信号ソースの例としては特に：ビデオカメラ；ルータ、モデム、ハブ等のネットワークデバイス；センサ；その他のシステムが挙げられるがこれらに限定されない。なお様々な実施形態では、必要に応じていずれのタイプの外部信号ソースを使用してよい。

ＭＰＡは修正されたアプリケーションソフトウェアをリアルタイムに最高動作速度で実行してよい。換言すると、ＤＵＴ／ＭＰＡ及びアプリケーションソフトウェアは試験中であるものの、修正されたアプリケーションソフトウェアを通常動作中と同等の速度（又は事実上同等の速度）で実行してよい。上述のように、修正されたアプリケーションソフトウェアを「リアルタイムに最高動作速度で」実行するとは、修正されたアプリケーションソフトウェアを実行する際のシステムの性能が、通常動作中（例えば試験又はデバッグ中でない場合）のシステムの性能の何らかの特定の許容誤差内、例えば所望又は必要に応じて０．１％未満、０．５％未満、１％未満、２％未満、４％未満、５％未満等であることを意味する。より一般には、これもまた上述のように、許容誤差は、いずれの所望の値となるように適宜指定してよく、これによっていずれの特定のアプリケーションに対して「リアルタイムに最高動作速度で」を定義する。従ってここで開示する技術を使用して、アプリケーションソフトウェアを実行するＤＵＴの性能を含むシステム性能に対して無視できる程度の影響しかない状態で、ＤＵＴを分析できる。

１２１０では、第１のデータを、入力データに基づいて、修正されたアプリケーションソフトウェアによってＤＵＴ内で生成してよい。換言すると、入力データに応答して、ＭＰＡ上で実行される修正されたアプリケーションソフトウェアは第１のデータ（いくつかの実施形態では信号と見做される場合もある）を生成してよい。いくつかの実施形態では、生成された第１のデータを、第１のデータを計算するＭＰＡの処理要素内の、又は上記処理要素に隣接したローカルメモリ、例えば隣接するＤＭＲのレジスタ又はメモリに記憶させてよい。

第１のＤＭＡエンジンを利用して第１のデータの少なくともサブセットを供給するいくつかの実施形態では、上記生成は、ＭＰＡの第２のメモリに第１のデータを記憶させることを含み、ここで第１のメモリはアプリケーションソフトウェアが使用する第１のハードウェアリソースのうちの１つであり、また１つ又は複数の第２のハードウェアリソースのうちの１つである第１のＤＭＡエンジンを含む複数のＤＭＡエンジンが第１のメモリに関連付けられている。更に一実施形態では、第２のＤＭＡエンジンもまた第１のメモリに関連付けられてよく、ここで第２のＤＭＡエンジンは、アプリケーションソフトウェアが使用する第１のハードウェアリソースのうちの１つである。

１２１２では、修正されたアプリケーションソフトウェアは第１の送信命令文を実行してよく、ここで第１の送信命令文は、修正されたアプリケーションソフトウェアが使用するための第１のデータを提供する。換言すると、修正されたアプリケーションソフトウェアは第１の送信命令文を実行して、修正されたアプリケーションソフトウェアの何らかの他の部分又は機能に対して第１のデータを供給してよい。第１の送信命令文は、ＭＰＡの第１のハードウェアリソースのうちの１つにおいて実行してよい。

１２１４では、修正されたアプリケーションソフトウェアは第１のハードウェアリソースのうちの１つにおいて副次的送信命令文を実行し、第２のハードウェアリソースのうちの少なくとも１つを用いて、第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給してよい。例えば一実施形態では、（第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給するための）副次的送信命令文の実行は、第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給するようにＭＰＡの第１のダイレクトメモリアクセス（ＤＭＡ）エンジンをプログラムしてよく、ここで第１のＤＭＡエンジンは、アプリケーションソフトウェアが使用しないＭＰＡの１つ又は複数の第２のハードウェアリソースのうちの１つである。（第１のハードウェアリソースから）第１のＤＭＡエンジンへの第１のデータのデータ伝送のこのようなオフロードは、データ伝送性能によって、実行される（修正された）アプリケーションソフトウェアの動作性能が（上述のような特定の許容誤差を超えて）劣化するのを防止できる。従って副次的送信命令文は、第２のハードウェアリソースのうちの１つ、例えば第１のＤＭＡエンジンによってアプリケーションソフトウェアをそっと「タップ」し、これによって分析を目的として第１のデータのコピーを生成するよう動作してよい。

一実施形態では、第１のデータは、ＭＰＡのＩＮを通る第１のデータパスを介して、修正されたアプリケーションソフトウェアが使用できるよう供給してよく、また第１のデータは、ＭＰＡのＩＮを通る第２のデータパスを介して、ＭＰＡのエッジのピンに供給してよく、ここで第２のデータパスは第１のデータパスとは異なる。

１２１６では、副次的送信命令文が提供した第１のデータを、例えばソフトウェア定義テストベンチ（例えばホストコンピュータ）が、例えばＭＰＡのエッジのピンを介して受信してよい。受信された第１のデータは、ＤＵＴの動作を分析するために、例えばアプリケーションソフトウェアを試験及びデバッグするために使用できる。

上述のように、いくつかの実施形態では、上述の方法の様々な要素をソフトウェア定義テストベンチによって実施してよい。例えば例示的な一実施形態では、上述の修正及び受信をソフトウェア定義テストベンチが実施してよく、ここでソフトウェア定義テストベンチは、ＤＵＴの性能に対する影響が無視できる程度である状態で、ＤＵＴを試験する。

上述の方法の重要な側面を若干異なる方法で説明すると、いくつかの実施形態では、メモリ媒体は、多重プロセッサアレイ（ＭＰＡ）の第１のリソース上で展開されるよう、及び／又は上記第１のリソースを使用するよう構成されたアプリケーションソフトウェアを記憶してよく、ここでＭＰＡは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク（ＩＮ）とを含む。メモリ媒体は、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むように修正して、修正されたアプリケーションソフトウェアを生成するためにプロセッサが実行できる、プログラム命令を更に含んでよく、ここで修正されたアプリケーションソフトウェア内の試験用コードは、少なくとも１つの副次的送信命令文を含む。上述のように、試験用コードは、ＭＰＡの１つ又は複数の第２の異なるリソースを使用するよう構成してよく、ここで上記１つ又は複数の第２の異なるリソースはアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するＭＰＡは試験中のデバイス（ＤＵＴ）を備える。

ＭＰＡ上で実行される修正されたアプリケーションソフトウェアは：入力データを受信してＤＵＴを刺激し；入力データに基づいてＤＵＴ内で第１のデータを生成し；第１の送信命令文を実行して、修正されたアプリケーションソフトウェアが使用するための第１のデータを提供し；副次的送信命令文を実行して、第１のデータをＭＰＡのエッジのピンに供給するようにＭＰＡのダイレクトメモリアクセス（ＤＭＡ）エンジンをプログラムするように構成してよく、ここでＤＭＡエンジンは、ＭＰＡの１つ又は複数の第２のリソースのうちの１つである。プログラム命令は更に、ＤＭＡエンジンから得られる第１のデータを受信するために実行可能であってよく、ここで第１のデータはＤＵＴを試験するために使用できる。

上述の技術をアプリケーションソフトウェアの観点から考えると、メモリ媒体は、多重プロセッサアレイ（ＭＰＡ）で実行可能なプログラム命令を記憶してよく、このプログラム命令はアプリケーションソフトウェアと、アプリケーションソフトウェアに挿入された試験用コードを含む。プログラム命令は：入力データを受信し；入力データに基づいて第１のデータを生成し；アプリケーションソフトウェアにおいて第１の送信命令文を実行して、アプリケーションソフトウェアが使用するための第１のデータを提供し；アプリケーションソフトウェアに挿入された試験用コードからの少なくとも１つの副次的送信命令文を実行して、第１のデータをＭＰＡのエッジのピンに供給するようにＭＰＡのダイレクトメモリアクセス（ＤＭＡ）エンジンをプログラムするように、実行可能であってよい。これもまた上述のように、第１のＤＭＡエンジンは、アプリケーションソフトウェアが使用しないＭＰＡのハードウェアリソースであってよい。第１のデータはＤＵＴを分析するために使用できる。

上述の方法の実施形態は、アプリケーションソフトウェアに挿入された副次的送信命令文を利用して、ＭＰＡ上の、他の目的で使用されない又はアイドル状態のＤＭＡエンジンをプログラムし、実行されているアプリケーションソフトウェアから目標のデータ（又は信号）を抽出し、これを、システムの性能に有意な影響を与えることなく、ＭＰＡのエッジに供給する。このようなデータ又は信号を複製及び抽出するための他の技術も考えられ、これらを以下に説明する。

外部試験用コード
図１３は、例えば図１２の副次的送信命令文の使用とは対照的に、ＭＰＡから目標のデータ又は信号を複製及び抽出するために、アプリケーションソフトウェアの外部の試験用コード（試験プログラムコードとも呼ばれる）を使用する、ＤＵＴを試験するための例示的な一実施形態による方法のハイレベルフローチャートである。図１２の方法と同様に、ＤＵＴは多重プロセッサアレイ（ＭＰＡ）を含んでおり、ＭＰＡの様々な実施形態は上述した通りである。図１２に示す方法は、特にこれまでに図示したコンピュータシステム又はデバイスのいずれと組み合わせて使用してよい。様々な実施形態では、図示した方法要素は、同時に若しくは図示したものと異なる順序で実施してよく、又は省略してよい。また必要に応じて追加の方法要素を実施してもよい。図示したように、この方法は以下のように動作できる。

まず１３０２では、試験することが求められているアプリケーションソフトウェアを分析してよい。アプリケーションソフトウェアは、多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で展開されるよう構成してよい。図１２の方法と同様に、ＭＰＡは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク（ＩＮ）とを含む。例えば一実施形態では、ソフトウェア定義テストベンチはアプリケーションソフトウェアを自動的に分析して、目標のデータ又は信号が生成される場所及び／又は時点を決定してよい。

１３０４では、試験プログラムコードを生成してよく、これは、分析（例えば試験）を目的としてアプリケーションソフトウェア内に生成されたデータの少なくともサブセットを複製するようＭＰＡ上のハードウェアリソースを構成するために実行可能である。いくつかの実施形態では、試験プログラムコードの生成は自動であってよく、例えばコードを指定する直接的なユーザ入力なしに、ソフトウェア定義テストベンチによって実施してよい。他の実施形態では、ユーザは、例えばソフトウェア定義テストベンチのエディタ又はプログラム開発環境を介して、試験プログラムコードの少なくとも一部分を生成してよい。

１３０６では、アプリケーションソフトウェアをＭＰＡの第１のハードウェアリソース上で展開してよく、ここでアプリケーションソフトウェアを実行するＭＰＡは試験中のデバイス（ＤＵＴ）を備える。

１３０８では、入力データを供給してＤＵＴを刺激してよい。ＤＵＴは上述のように、アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するＭＰＡを備えてよい。上述の方法と同様に、いくつかの実施形態では、ＤＵＴは、ＤＵＴに連結された外部信号ソースからリアルタイムデータを例えば入力データとして受信して、ＤＵＴを刺激してよい。

１３１０では、試験プログラムコードを実行して、アプリケーションソフトウェアの実行に使用されていないハードウェアを用いてＭＰＡのエッジのピンに第１のデータの少なくともサブセットを供給してよい。第１のデータは、試験ベクタに応答してアプリケーションソフトウェアが実行した送信命令文に応答して生成してよい（又は生成されたものである）。いくつかの実施形態では、（第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給するための）試験プログラムコードの実行は、第１のデータの少なくともサブセットをＭＰＡのエッジのピンに供給するようにＭＰＡの第１のダイレクトメモリアクセス（ＤＭＡ）エンジンをプログラムしてよく、第１のＤＭＡエンジンは、アプリケーションソフトウェアの実行に使用されていないＭＰＡのハードウェアリソースであってよい。換言すると、実行中、アプリケーションソフトウェアは、入力データに応答して第１のデータを生成する送信命令文を実行してよく、その後試験プログラムを実行してよく、これは、第１のデータの少なくともサブセットのコピーをＭＰＡのエッジのピンに伝送するように、ＤＵＴのＤＭＡエンジンをプログラムする。

上述のように様々な実施形態では、本方法は第１のデータのフィルタリング又はそれ以外の処理を含んでよい。例えば試験プログラムコード又は上記試験プログラムコードによってプログラム若しくは制御される（第２のハードウェアリソースの）ハードウェアリソースは、第１のデータ又はそのサブセットをフィルタリングしてよい。このフィルタリングはデータのサンプリングを含んでよく、従って副次的データの量はオリジナル（第１の）データよりも少なくすることができる。別の例示的実施形態では、フィルタリングは、例えばデータを平均してオリジナルデータに対応するより低解像度のデータを生成することによる、データの削減を含んでよい。平滑化、異常値の除去等を含む他のいずれの種類のフィルタリング（処理）を必要に応じて使用してよい。

１３１２では、試験プログラムコードの実行によって得られた第１のデータの上記少なくともサブセットを、例えばソフトウェア定義テストベンチが受信してよい。第１のデータの上記少なくともサブセットは、ＤＵＴを分析するために使用できる。ＭＰＡ及びＤＵＴの様々な実施形態は、既に詳細に説明した通りである。

いくつかの実施形態では、試験プログラムコードは、アプリケーションソフトウェアの実行に使用されないＭＰＡの処理要素、例えば第１のデータが記憶されているメモリの近隣の処理要素上で実行してよい。他の実施形態では、試験プログラムコードは、ＭＰＡから分離した別個のコンピュータシステム、即ち外部コンピュータシステム上で実行してよい。上述のようにいくつかの実施形態では、試験プログラムコードは更に、データをフィルタリングするか、又は例えばサンプリング、削減といった他の処理を必要に応じて行うよう動作してよい。

一実施形態では、試験プログラムコードは、第１のデータの上記少なくともサブセットを提供するために、ＭＰＡ内のシリアルバス（又はその他の二次相互接続ネットワーク（ＳＩＮ））を介してコマンドを提供してよい。例えば、上述のように第１のＤＭＡを利用する実施形態では、第１のＤＭＡエンジンは、ＭＰＡのシリアルバス（又はその他の二次相互接続ネットワーク（ＳＩＮ））を介して、外部試験プログラムコード（又は試験用コード）によってプログラムしてよい。

送信命令文によって生成された第１のデータは、ＭＰＡのＩＮを通る第１のデータパスを介して、アプリケーションソフトウェアが使用できるよう供給してよく、また第１のデータの上記少なくともサブセットは、ＭＰＡのＩＮを通る第２のデータパスを介して、例えばＤＭＡエンジンによって、ＭＰＡのエッジのピンに供給してよく、ここで第２のデータパスは第１のデータパスとは異なる。

いくつかの実施形態では、１３０２の分析及び１３１２の受信はソフトウェア定義テストベンチによって実施してよく、ここでソフトウェア定義テストベンチは、ＤＵＴの性能に対する影響が無視できる程度である状態でＤＵＴを試験する。

よって様々な実施形態では、ソフトウェア定義テストベンチ及びアプリケーションソフトウェアは連動して動作して、ＤＵＴがアプリケーションソフトウェアをリアルタイムに最高動作速度で実行している間に、（アプリケーションソフトウェアを含む）ＤＵＴを分析してよい。

副次的（若しくは第２の）送信コマンド又は外部試験用コードがＤＭＡエンジンを用いてデータ伝送を実行する場合、ＳＭ内のバッファからＩＮを介してチップＩ／Ｏポートにデータのブロックを移動させるよう構成できる経路を設定してよい。データ伝送の初めのいくつかの語は、経路を設定するためのヘッダ情報であってよい。図１４は例示的なシステムを示し、このシステムは、「ＤＭＡエンジン１」と記された第１のＤＭＡエンジンにデータを送出し、第１のＤＭＡエンジンはこのデータをメモリに伝送し、その後ＤＭＡエンジン２が（オリジナル）データを指定された標的に送出し、ＤＭＡエンジン３がこのデータのコピー、即ちここでは「プローブデータ」と呼ばれる副次的データを、例えば分析のために送出する。

更にいくつかの実施形態では、データは、自由なＤＭＲにおいてバッファリングすることにより、チップＩ／Ｏポートへの途上で処理してよく、ここで用語「自由な（ｆｒｅｅ）」は、「アプリケーションソフトウェアを実行する必要がない」ことを意味する。自由なＤＭＲの近傍の自由なＰＥは、このデータを処理（間引き又は圧縮等）するようプログラムしてよい。別の通信経路を設定して、データをチップＩ／Ｏポートへ、そしてホストマシンへ案内してよい。

レジスタのポーリング
目標のデータ又は信号を複製／抽出するための、より侵襲性が低いがより複雑である別の方法は、近隣のＰＥを利用して、特定のＤＭＡ伝送と関連する複数のレジスタのセットをポーリングする。上記近隣のＰＥが伝送の開始を検出すると、上記ＰＥは同一のデータを読み出してこれをチップから送出できる。これは非侵襲性の方法で実施できる。というのは、上記近隣のＰＥが最低の優先度を有し、従って上記アプリケーションソフトウェアの動作に一切干渉しないように、ＤＭＡレジスタ上に優先度を設定できるためである。従って、データを送信している間に、ＤＭＡエンジンの背後でプローブはゆっくりと継続されてよく、また時折、上記エンジンによって、又は同一のＤＭＲにアクセスしているアプリケーション内の他の近隣のＰＥによって機能停止し得る。これにより、ＤＭＡエンジンが終了しアプリケーションの送信ＰＥに通知を行ってから数サイクル後に、上記近隣のＰＥによるデータの読み出しを終了させる。その短いタイムウィンドウの間に、送信ＰＥはデータの修正を始めることができる。しかしながら、ＤＭＡ伝送のバースト間に比較的長いインターバルを有するのがより一般的であり、従って有効でないデータを読み出してしまう蓋然性は小さい。

ＤＭＡ‐ＦＩＦＯの使用
更に非侵襲性のプローブを、いくつかのＭＰＡが提供するオンボードＤＭＡ‐ＦＩＦＯ機能、例えばｈｘ３１００Ｂ ＨｙｐｅｒＸ［ＭＰＡ］プロセッサチップのＤＭＡ‐ＦＩＦＯ能力を用いて実装してよい。このアプローチでは、図１５に示すように、３つのＤＭＡエンジンを先入れ先出し（ｆｉｒｓｔ‐ｉｎ ｆｉｒｓｔ‐ｏｕｔ：ＦＩＦＯ）制御ブロックに連結し、データのストリームを一次又はオリジナルデータストリームと、精査された又は副次的データストリームとに分割してよい。

図示したように、この例示的実施形態では、データはＤＭＡエンジン１を介してメモリへと送出され、ＤＭＡエンジン２はこのデータをメモリから指定された標的へと送出し、ＤＭＡ３エンジンはプローブデータ、即ち副次的データを、例えば分析のために送出する。しかしながら、図１４のアプローチとは対照的にこの実施形態では、ＦＩＦＯ制御要素又は構成部品は３つのＤＭＡエンジン全ての間に介在し、これによってＤＭＡエンジンの動作を調整して、データの損失又はデータの複製を防止できることに留意されたい。データフロー制御は期間中ずっと継続させてよく、従ってこれにより「ダブルバッファリング」という公知の技術が必要なくなる。

プローブがアプリケーションと同時にＭＰＡリソース（物理的設計）に割り振られた場合、これはアプリケーションの物理的レイアウトを混乱させ得、これによって異なる挙動がもたらされる場合があることに留意されたい。この異なる挙動は、２つの異なる様式で発生し得る。

プローブが第１のタイプのものである場合（即ち挿入されたデバッグ送信を監視する場合）、追加のルーティングリソースにより、アプリケーション設計が、設計の性能を変化させ得る、そして最悪の場合には異なる挙動を引き起こし得る、異なるルートのセットを有してしまうことがある。第２に、プローブがＤＭＡレジスタにアクセスすることによってＤＭＡ伝送を直接監視している場合、適切なＤＭＡに物理的に隣接する必要があり得る。これはアプリケーション設計のレイアウトを混乱させ得る。最良の場合、プローブが使用するプロセッサは、アプリケーション設計に元々占有されていなかったものである。しかしながらこの場合でさえ、プローブは、他のＤＭＲメモリのいずれかにアクセスした場合にアプリケーション設計を変化させてしまう場合があり、異なるパターンのローカルメモリ競合が引き起こされる。これは、これらＤＭＲに対する優先度を変化させて、プローブが常に最低の優先度を有するようにすることによって対処できる。しかしながらこのように対処した場合でさえ、プローブはそのデータをチップから送信することを必要とし、従ってルーティングリソースを使用する必要があり、この場合もアプリケーション設計を潜在的に混乱させる。

しかしながら以下で議論するように、プローブをオリジナル設計開発の後に挿入した場合には、設計の混乱に関するこれらの問題は全て回避できることに留意されたい。

上述のルーティングの影響を回避するための１つの方法は、プローブを追加する前にアプリケーションルーティングをロックし（「フリーズさせ」）、プローブのルーティングに、未使用のルーティング区間を通過させるだけである。アプリケーション設計後にＭＰＡに残るリソースに応じて、これは可能であったり不可能であったりする。

ＭＰＡの例示的なＤＭＲ
図１７は、一実施形態によるＭＰＡのＤＭＲの例示的実施形態を示す。上述のように、ＭＰＡ内のＤＭＲは、ＭＰＡの隣接する処理要素のためのローカルメモリ及びルーティングリソースを提供し、また実行中のアプリケーションソフトウェアへのデータ書き込み、上記アプリケーションソフトウェアからのデータ読み出し、上記アプリケーションソフトウェア内でのデータ読み出し及び書き込みのためのＤＭＡエンジンを実装してよい。例えば図１７の例示的なＤＭＲは４ペアのＤＭＲエンジンを含み、各ペアは、ＤＭＲの中央に示したデータメモリからデータを読み出すためのＤＭＡ読み出しエンジンと、上記データメモリにデータを書き込むためのＤＭＡ書き込みエンジンとを含み、各ＤＭＡエンジンは、「ＤＭＡＷ Ｅｎｇｉｎｅ」（ＤＭＡ書き込みエンジン）、「ＤＭＡＲ Ｅｎｇｉｎｅ」（ＤＭＡ 読み出しエンジン）と記されているＤＭＲ内の最も右側の２つの正方形が示すように、図面ではそれぞれ正方形で表されており、ここでＤＭＡ書き込みエンジンはデータ（図におけるＷＤａｔａ）をデータメモリに書き込むよう動作し、ＤＭＡ読み出しエンジンはデータ（図におけるＲＤａｔａ）をデータメモリから読み出すよう動作する。

上述のように、これらＤＭＡエンジンのうちのいくつかを、実行中のアプリケーションソフトウェアが例えば上述の「第１のリソース」の一部として利用して、アプリケーションソフトウェアが使用できるようにデータの読み書きを行ってよく、その一方で他のＤＭＡエンジンを、試験又はデバッグ用の試験用プログラムコードが例えば上述の「第２のリソース」の一部として使用してよい。

図１７に示すように、この例示的実施形態では、ＤＭＲの最も左のＤＭＡ読み出しエンジンは、本技術の実施形態に従ってプログラムされる。より具体的には、このＤＭＡ読み出しエンジンは、オリジナル（修正されていない）アプリケーションソフトウェアとは分離した別個の試験用コード、例えば副次的送信命令文又は外部試験用コードによってプログラムされる。従ってＤＭＡ読み出しエンジンは、データを複製して場合によってはフィルタリングし、（上述のように）（場合によってはフィルタリングされた）複製データをＭＰＡのエッジのピンに送信するよう動作し、このリソースはＭＰＡの「第２のリソース」のうちの１つであるため、その動作はシステム性能を犠牲にしない（何らかの特定の許容誤差範囲内である）。

アプリケーション設計ポストリンクデバッグ精査
試験中のアプリケーションからソフトウェア通信プローブを連結解除すると有益であり得る。これを行う１つの動機は、アプリケーションのソースコードが利用可能ではなく、従って含まれている通信プローブによって再リンク（再構築）できないことである。しかしながらはるかに重要なことは、修正が、それがどれほど小さなものであろうと（即ちプローブ）アプリケーションに導入されることがないように、試験中のアプリケーションの完全な整合性を維持することである。これはまた、含まれているプローブを用いてアプリケーションを再構築（再リンク）する必要を省く（防ぐ）。

ＨｙｐｅｒＸ（商標）デバイスにより、ＰＥとＤＭＲとの完全に独立した制御が可能となる。このような柔軟性により、ユーザは、ロードされた追加のＰＥが既に動作しているアプリケーションのＰＥ及び関連するＤＭＲメモリ空間を上書きしない限りにおいて、既にＨｙｐｅｒＸデバイス上で動作していてよいアプリケーションを中断させることなく、実行コードを用いて追加のＰＥをプログラム及び実行できる。これにより本質的に、複数のバイナリイメージを、これらのリソース利用が相互排他的である（即ちＰＥ、ＤＭＲメモリ、ルーティングファブリック）限りにおいて、同時に（並列に）実行できる。異なるバイナリ（アプリケーション）のロード及び実行は、異なる時点で行うことができる。これらはＳＩＮを介してロードしてよく、ＳＩＮは、１つ又は複数のアプリケーションが使用するＰＩＮルーティングファブリックとは完全に独立である。

異なるバイナリイメージを異なる時点でロード及び実行でき、そしてこれらを同時に実行できるという柔軟性は、試験中のアプリケーションをプローブのバイナリイメージから連結解除して、試験中のアプリケーションからデータを抽出するのに役立つ。通信経路に接続されるプローブを生成するために、試験ＰＥを、ソースＤＭＲへのアクセスを有するよう、センダＰＥの隣に割り振ってよい。例えば図１６に示す例示的実施形態では、アプリケーションソフトウェアは、ＭＰＡの中央のフリーハンドのループ内に包含されるリソースを使用し、これはループ内に、第１のＰＥの上のタスク７１から第２のＰＥ上のタスク７２への経路を有する。Ｘと記されたＤＭＲは、非アプリケーションＰＥ上のタスク８１からアクセス可能である。この試験ＰＥは、ＤＭＲ Ｘから出力ポートへ、又は処理用の別のＰＥへの経路を設定できる。

この試験ＰＥは、（試験中のアプリからの）オリジナルデータ送信伝送のＤＭＡ（状態）レジスタを連続的にポーリングするようプログラムしてよい。ＰＥの試験／ポーリングによってＤＭＡの状態が非アクティブ状態からアクティブ状態へと変化したことが検出される場合は常に、試験ＰＥはオリジナルＤＭＡレジスタ値（即ちＴＯＴＡＬ、ＷＡＩＴ、ＳＴＲＩＤＥ）を複製して、同一のＤＭＡレジスタ値で（同一のＤＭＲの）別のＤＭＡをプログラムしてよい。これは、プローブとして使用されることになる副次的ＤＭＡ送信伝送を生成できる。試験中のアプリケーションは、プローブＤＭＡ伝送の確立によって停止、修正する必要はなく、また何ら影響を受けることはない。

トリガ
論理アナライザ（ＬＡ）等の試験機器は、多数のバイナリデジタル信号をサンプリングしてこれらを高速メモリに記憶させることにより、デジタル信号をキャプチャする。その後、メモリのコンテンツを、バイナリ信号のセットとして、又は何らかの等価の数値としてスクリーン上に表示してよい。論理アナライザ（ＬＡ）のタイムベースは、トリがイベントにおいてストレージアドレスの一括処理を開始する。トリがイベントは、一次信号のサブセット内のバイナリ信号の、及び試験中のデバイス又はＤＵＴに信号を供給するデジタルパターン生成器からの他のバイナリ信号の、特定のパターンであってよい。

デバッグ用プローブの挿入
デバッグ用プローブを用いて、ユーザ設計の内部である信号を監視する（既に詳細に説明されている）。Ｔｈｅ ＭａｔｈＷｏｒｋｓ，Ｉｎｃ．が提供するＳｉｍｕｌｉｎｋ（商標）は、デバッグ目的で使用される多数のブロックを提供する。特に内部信号のサンプリングのために複数のブロックが存在する。いくつかの実施形態では、これらの内蔵型Ｓｉｍｕｌｉｎｋブロックを、ＨｙｐｅｒＸハードウェア上で実現されることになる設計にデバッグ用プローブを挿入するために使用してよい。このようなブロックは、例えばＣ－コードを用いて翻訳でき、これによってデータのキャプチャ及びチップ外への送信を実装できる。トランスレータはまた、信号をホストマシンへルーティングしてこのデータを適切な様式で表示するために必要なインフラストラクチャを設定できる。

デバッグ用プローブの多重化
デバッグに必要なプローブの数は、ＭＰＡ上で利用可能なデータポートの数より多くなる場合が多い。これらの場合、データプローブは（帯域幅要件を低減するために必要である場合は）サブサンプリングしてよく、続いて複数のプローブからのデータパケットを統合して１つのデータストリームを形成してよく、このデータストリームはチップ上の単一のＩ／Ｏポートを使用できる。

なお、信号を多重化する際、データの識別をホストマシンに通信してよい。これは多数の方法のいずれによって達成してよい。例えば、第１のパケットが第１のプローブに対応し、第２のパケットが第２のプローブに対応し、第３のパケットが第１のプローブに対応し、第４のパケットが第２のプローブに対応し…のようになるように、プローブデータパケットを、厳密に反復される順序で送信してよい。

別のアプローチでは、プローブデータパケットを識別番号でタグ付けしてよく、これにより、ホストはパケットＩＤを読み出し、そのデータがどのプローブからのものであるかを知ることができる。

通信経路設定（ＣＯＭＭ）
これより、通信経路の設定及び切断のための例示的なプログラミングについて説明する。しかしながら、ここで説明する特定の実装形態は単なる例であり、考えられる実装形態をいずれの特定の形態、機能、名称又は外観に限定することを意図したものではないことに留意されたい。一般に１つ又は複数のＰＥは、ＤＭＡを用いてメモリから経路を通してデータを実際にポンピングする間に、上述の設定及び切断機能を実施してよい。またいくつかの実施形態では、メモリをバイパスする「クイックポート」を用いて、ＰＥがデータを経路に直接ポンピングしてよい。

通信パスの設定は一般に、ソフトウェアタスクをセンダＰＥ命令メモリにロードしてそのタスクの実行を開始することを伴う。経路はセンダＰＥタスクのみによって設定できるが、目的地ＤＭＲにおいて受信機構が必要となり、そうでなければハードウェアはデータの前進移動を機能停止させる。適切な受信機構は、ＤＭＲの近傍のＰＥ上の別のタスク、又はパスの到着ポートにおける準備されたＤＭＡエンジンである。

タスクは、例えばＣである高級プログラム言語でプログラムしてよいが、いくつかの実施形態では、プログラミングの労力を軽減するために、例えば例えばＭＰＸ＿構造体である様々な構造体を提供してよい。例えばＭＰＸ＿Ｓｅｎｄ、ＭＰＸ＿Ｒｅｃｖは、送信及び受信機能を提供できる。データ伝送オプションパラメータは、伝送のタイプ及び実装形態のばらつきを制御できる。このようなＭＰＸ機能は、３つの一般的な通信方法：
・汎用：システムが最適な通信（ｍｅｍｃｐｙ、ＤＭＡ伝送を用いたメッセージ受け渡し、又はクイックポート伝送）を選択する；
・ＤＭＡ伝送：メッセージ受け渡し；及び
・クイックポート：ＰＥがＤＭＲクイックポートレジスタに書き込みを行う、単一語のメッセージ受け渡し（ＤＭＲ内のデータメモリを使用せず、ＤＭＡを設定する必要がない）
をサポートしてよい。

これらの一般的な通信方法の中で、実装形態の変形は、設計者に多くのオプションを提供する。以下は例示的実施形態である：
・ブロッキング：データがバッファから完全に送信されるまで送信ＰＥの実行を停止； ・非ブロッキング：送信ＰＥの実行を即座に継続；
・ＩｎｉｔＲｏｕｔｅ：ＤＭＡルートを設定；
・ＥｎｄＲｏｕｔｅ：ＤＭＡルートを切断（なお、非ブロッキング機能はルートを切断しない）；
・Ｅｘｐｒｅｓｓ（送信）：ルートの設定又は切断を行わず、既に設定された明らかなルートに対して多数の高速のコールを可能とする；
・促進された機能：不変値レジスタを一度プリセットできるため、使用するコードが少ない；
・単一の二地点間通信；及び
・一対多（ファンアウト）及び多対一（ファンイン）通信。

ある機能は、動作の完了までに回復しなければブロックされる。従って、送信機能に関して、完了（ｃｏｍｐｌｅｔｅ）とは、データがバッファから完全に送信されることを意味し、データはＤＭＲを離れている。完了は必ずしも、受信用タスクによってデータが完全に受信されたことを意味しない。受信機能がブロックされると、データをＤＭＲ位置のメモリに書き込む必要があり得る。動作が完了した場合のみ、コール内で指定されたリソースを再使用でき、受信用ＰＥが実行を継続できる。

ある機能は、動作が完了するまでに回復した場合は非ブロック状態となる。データ伝送動作は必ずしも完了していないため、まだ送信されていないデータは、センダタスクによって誤って修正され得る。センダタスクは、完了信号を明確に待つこと、又はデータ伝送動作の状態を明確にポーリングすることによって、データのエラーを回避できる。

通信経路は、例えば＃ｄｅｆｉｎｅ ＣＯＭＭＩＤ ９９といった定数である特定のｃｏｍｍＩＤ値によって宣言してよい。

続いて構造体ＭＰＸ＿Ｓｅｎｄを使用してデータ伝送を実行できる。

ＭＰＸ＿Ｓｅｎｄ
ＭＰＸ＿Ｓｅｎｄは、特定の数の要素（メモリ語の値）を別のタスクに伝送できる。通信手段は、１つ又は複数の伝送オプションのパラメータ、例えばＭＰＸ＿ＣｏｍｍＯｐｔｉｏｎｓ＿ｔによって与えることができる。以下は、関数及び引数の種類を示す例示的な関数プロトタイプである。
ｉｎｔ１６＿ｔ ＭＰＸ＿Ｓｅｎｄ （ｖｏｉｄ ＊ｂｕｆ，
ｕｉｎｔ１６＿ｔ ｎｕｍＥｌｔｓ，
ＭＰＸ＿Ｄａｔａｔｙｐｅ＿ｔ ｄａｔａｔｙｐｅ，
ＭＰＸ＿Ｃｏｍｍ＿ｔ ｃｏｍｍＩＤ，
ＭＰＸ＿ＣｏｍｍＯｐｔｉｏｎｓ＿ｔ ｔｒａｎｓｆｅｒＯｐｔ）

以下は、この構造の様々な機能を特定する例示的なパラメータの表である。

受信関数
ＭＰＸ「送信及び受信機能」の説明において、汎用、ＤＭＡ及びクイックポート伝送に関する上の説明を参照されたい。なお受信関数はルートを設定又は切断することはできない。

制約
制約は、リソースの割り振りをガイドするために物理的設計段階中に使用できる形式である。制約を用いて例えばＩＮ内の１つ又は複数の通信経路及び他の通信パラメータの形成をガイドする。制約を用いて特に、経路の重複を防止でき、経路に特定のリソースを使用させることができ、また立入禁止領域を確立できる。プローブの制約は、以下に定義する特定のタイプの制約である：
／／デザインビューにおいてデータ精査の制約を生成する。
ｃｏｎｓｔｒａｉｎｔ ｃｒｅａｔｅ －ｔｙｐｅ ｐｒｏｂｅ［－ｒａｗ］
－ｎａｍｅ ｃｏｎｓｔｒａｉｎｔｎａｍｅ
－ｃｏｍｍ ｃｏｍｍ＿ｉｄ
－ｐｏｒｔ｛ＰＡＲＡＬＬＥＬＰＯＲＴ｜ＰＣＩＥ｝
［－ｓａｍｐｌｅ‘｛’ｏｆｆｓｅｔ ｓｔｒｉｄｅ ｃｏｕｎｔ‘｝’］
｛ｖｉｅｗｎａｍｅ｜ｖｉｅｗｐａｔｈ｝

データプローブの例及びビュー
データプローブは、アプリケーションからＩＳＤＥ内のリアルタイム分析（ＲＴＡ）ビューへのデータの抽出を促進できる。

プローブは通信データをサンプリングして、分析のためにサンプルをチップ外に伝送してよい。ある設計からのデータは、サンプリングポイントを挿入するためにその設計を変化させることなく、サンプリングできる。データをオンチップでフィルタリングして、通信オーバヘッドを最小化してよい。

サンプリングは設計の機能に影響を与えることはなく、タイミングに対する影響も最小であってよい。

いくつかの実施形態では、リアルタイム分析（ＲＴＡ）ツールは、サンプリングしたデータの分析に使用されるＨｙｐｅｒＸ ＩＳＤＥ内のビューのセットとして実装してよい。

プローブの生成
プローブは、構成プロセスのリソースマッピング段階中に生成してよい。例えば「Ｃ」コードであるソースコードに対する変更はない。

プローブｃｏｍｍは、プローブのサンプリングしたデータを伝送するための、非ブロッキングｃｏｍｍ設定であってよい。ＲＴＡに送信される各パケットに必要なヘッダは、全てのプローブｃｏｍｍに自動的に追加できる。

プローブｃｏｍｍは、タイプ「プローブ」の制約を生成することによって生成してよい。この制約は、精査の頻度を制御するためのサンプリング基準を含んでよい。

上で参照したプローブｃｏｍｍに対して、暗黙のｎｏｎ＿ｏｖｅｒｌａｐｐｉｎｇ＿ｃｏｍｍ制約をシステムが提供してよい。非オーバラップ制約は、ある経路に割り当てられたリンク及びルータのいずれを別の経路と共有しようとするのを抑制するよう、リソース割り当てツールに指示する。

実施例１
ｃｏｎｓｔｒａｉｎｔ ｃｒｅａｔｅ －ｔｙｐｅ ｐｒｏｂｅ－ｎａｍｅ ｐｒｏｂｅ９９＼
－ｃｏｍｍ ９９－ｐｏｒｔ ＰＡＲＡＬＬＥＬＰＯＲＴ／ｗｏｒｋ／ｔｏｐ／ｔｏｐｖ

この例は、ｐｒｏｂｅ９９という名称のプローブｃｏｍｍを生成し、このｃｏｍｍ９９は、データが精査された基準ｃｏｍｍである。

実施例２
ｃｏｎｓｔｒａｉｎｔ ｃｒｅａｔｅ －ｔｙｐｅ ｐｒｏｂｅ－ｎａｍｅ ｐｒｏｂｅ９９＼
－ｃｏｍｍ ９９－ｐｏｒｔ ＰＡＲＡＬＬＥＬＰＯＲＴ＼
－ｓａｍｐｌｅ｛２ ３ ４｝／ｗｏｒｋ／ｔｏｐ／ｔｏｐｖ

これは、－ｓａｍｐｌｅのオプションが、オフセット（２）、ストライド（３）、カウント（４）を指定することによって収集されるサンプルデータの量を制御していることを除いて、上述の実施例と同一である。例えば、ｃｏｍｍ９９上で伝送される値を１，９，２５，４９，８１，１２１，１６９，２２５，２８９…とすると、第１のプローブデータは２５，１２１，２８９，５２９となる。第１の要素は２５であるが、これはオフセットゼロが最初の要素であり、オフセット２における要素が２５であるためである。ストライドが３であるため、次の要素は１２１である。最後にカウントが４であるため、更に２つの要素が収集され、このサンプルデータのセットが完成される。

プローブｃｏｍｍは、データをチップ外に伝送できるようにＩＯｐｏｒｔが配置されることを必要としてよい。

実施例３
ｐｌａｃｅ ｉｏｐｏｒｔ －ｌｏｃａｔｉｏｎ｛１１ ９｝／ｗｏｒｋ／ｔｏｐ／ｔｏｐｖ／ｐｒｏｂｅ９９

チップ間Ｃｏｍｍのためのプローブの生成
多重チップ設計では、プローブはグルーピングの前又は後に確立できる。設計のグルーピングは、設計の部品をグループに割り当て、得られたグループを特定のチップ上に配置されるように割り当てるプロセスである。プローブをグルーピングの後に確立する場合、「センダ側（ｓｅｎｄｅｒ ｓｉｄｅ）」グループ名を使用してよい。

実施例４
ｇｒｏｕｐ ｃｒｅａｔｅ －ｎａｍｅ ｇｒｐＯ－ｔａｓｋ／ｗｏｒｋ／ｒｏｏｔ／ｒｏｏｔ／０
ｇｒｏｕｐ ｂｉｎｄ－ｃｈｉｐ／ｃｌｘｌｉｂ／ＸＨｘ／ｖ／Ｕｌ ｇｒｐ０
ｃｏｎｓｔｒａｉｎｔ ｃｒｅａｔｅ－ｔｙｐｅ ｐｒｏｂｅ＼
－ｎａｍｅ ｐｒｏｂｅ２７３－ｐｏｒｔ ＰＡＲＡＬＬＥＬＰＯＲＴ＼
－ｃｏｍｍ／ｗｏｒｋ／ｒｏｏｔ／ｒｏｏｔ／２７３ ／ｗｏｒｋ／ｒｏｏｔ／ｒｏｏｔ／ｇｒｐ０

この例は、ｐｒｏｂｅ２７３という名称のプローブを生成する。これは、基準ｃｏｍｍ２７３からのデータを精査し、上記ｃｏｍｍはグループ「ｇｒｐ０」の一部である。

リアルタイム分析－ビュー
リアルタイム分析（ＲＴＡ）を使用して、製品アプリケーションの挙動及び性能を、ＨｙｐｅｒＸ（商標）ハードウェア上での動作中にリアルタイムに制御及び監視してよい。

いくつかの実施形態では、ＲＴＡツールを、ハードウェアデバッガを動作させるＩＳＤＥ内のテストハーネスの一部として使用してよい。サンプルコードを、例えばインストール例ディレクトリ内に提供してよく、これにより、試験構成要素がアプリケーション及びＩＳＤＥビューとどのようにインタフェース接続されるかを示す。

以下の例示的実装形態は、無線用途の分析に焦点を当てたものである。

３種類のビュー
例示的な一実施形態では、ＨｙｐｅｒＸ（商標）ハードウェア用のリアルタイム分析（ＲＴＡ）ツールは、例えばＨｙｐｅｒＸ（商標）リアルタイム分析パースペクティブにおいて６つのビューを含み、これらは３ペアのビューとして動作する。

ＲＴＡビューを、ＨｙｐｅｒＸ（商標）リアルタイム分析パースペクティブにおいて使用してよい。

ソフトウェア無線の例
図１８に示すようにソフトウェア無線の例から始めるが、ここではパケットは、レシーバに連結されたトランスミッタへの入力として受信され、レシーバはパケットを出力し、トランスミッタ及びレシーバはそれぞれ１つ又は複数のＰＥを利用する。トランスミッタは固定サイズのパケットを受け取り、伝送のためにこれらを符号化し、これらをレシーバに送信し、これらはレシーバにおいて復号化される。実環境での応用では、トランスミッタからのデータはＲＦ（無線周波数）トランスミッタ回路に送信され、レシーバに供給されるデータはＲＦレシーバ回路から来るものとなる。

システムを試験するために、図１９に示すようにテストハーネス構成要素をシステムに追加してよく、これらはそれぞれＨｙｐｅｒＸ（商標）ハードウェア上で動作する。この例示的実施形態では、「パケット生成器」と記された試験データ生成器が追加されており、これは公知のコンテンツを有する試験パケットを生成し、これら入力パケットをトランスミッタに送信する。これもまた図示したように、チャネルの障害のためのＡＷＧＮ（加法性ホワイトガウスノイズ）構成要素をトランスミッタとレシーバとの間に介在させる。この構成要素は、信号にノイズを付加することによって放送電波を介した伝送をエミュレートし、得られたノイズを含む信号をレシーバに送信する。最後に、「パケット比較器」と記されたパケット比較器がレシーバに連結されている。レシーバはノイズを含む信号を復号化し、復号化された信号をパケット比較器に送信して、パケット及びビットエラーレートを計数する。

ＡＷＧＮ及び信号空間
いくつかの実施形態では、ＡＷＧＮビューはＨｙｐｅｒＸ（商標）加法性ホワイトガウスノイズ（ＡＷＧＮ）生成器構成要素を制御してよい。ＡＷＧＮ構成要素はエグザンプルコートを供給されてよく、また調整可能な量のノイズをトランスミッタの出力に付加するために使用してよい。

一実施形態では、信号空間ダイヤグラムは、直交振幅変調（ＱＡＭ）信号を復号化することの効果を示してよい。ＩＱデータは、様々な表示形態の中でも特に信号空間プロット（散布図としても知られる）として、又は２Ｄ若しくは３Ｄヒートマップとして示してよい。

図２０は、一実施形態による、印加されるＡＷＧＮを特定及び／又は指示するための例示的なＡＷＧＮユーザインタフェースビューを示す。ＡＷＧＮユーザインタフェースビューは、ＡＷＧＮ生成器構成要素にＡＷＧＮ制御メッセージ（パケット）を送信してよい。パケットは、要求されるＳＮＲと、推定された平均信号電力とを含んでよい。ＡＷＧＮ構成要素はトランスミッタの出力を、所定の平均電力を有するものとして処理してよい。ＡＷＧＮ構成要素は要求されるＳＮＲを使用して、トランスミッタの出力に付加されることになるノイズの振幅を計算してよい。

ＡＷＧＮユーザインタフェースビューは、ＨｙｐｅｒＸ（商標）ハードウェアにパケットを周期的に送信して、ＡＷＧＮノイズ設定を調整してよい。一実施形態では、ＡＷＧＮは２つのモード、即ち固定（Ｆｉｘｅｄ）モード及びスイープ（Ｓｗｅｅｐ）モードで動作してよい。

固定モードでは、１つのＡＷＧＮ制御パケットを送信してよく、これは固定フィールドからのＳＮＲ値と、平均電力フィールドの値とを含む。

スイープモードでは、ＡＷＧＮ制御パケットを周期的に送信してよい。図示したＳｅｃｓ／Ｉｎｃｒスピナ制御は、アップデートとアップデートとの間の秒数を調整してよい。ＳＮＲは開始値から停止値までスイープしてよく、毎回増分値だけ増加してよい。第１のパケットはスイープフィールドにおいてＳＮＲ値を使用してよい。停止値を有するパケットを送信すると、スイープを開始値で再び始めることができる。

なお、図示した実施形態では、底部の小さなグラフは、スイープの進行の指示を提供する。

ＡＷＧＮ構成要素は、新規のデータブロックの到着だけでなく、制御パケットの到着にも応答してよいことに更に留意されたい。これは、到着ポートをラウンドロビン様式でポーリングすることによって達成できる。しかしながらポーリングはＰＥを連続的に動作させるため、電気的エネルギを放散させてしまう。一時停止するとＰＥの電力放散は動作中に比べて大幅に、何倍も低くなるため、ＰＥを一時停止させて電気的エネルギを節約するための様々な方法が従来技術に存在する。ＰＥの一時停止（待機状態又は単に「待機（ｗａｉｔｉｎｇ）」とも呼ぶ）は、ＰＥの内部又は外部の特定のイベントに対して調整してよい。ＰＥの一時停止は、ＰＥのバイナリ命令の実行において待機するよう、ソフトウェアによって開始してよい。待機命令からの解除は、１つ又は複数のウェイクアップ信号に左右され得る。ＤＭＲは１つ又は複数のウェイクアップ信号を、近隣のＰＥのうちの１つ又は複数に送信してよく、そしてＰＥは全ての近隣のＰＥからウェイクアップ信号を受信してよい。ウェイクアップ信号は、ＤＭＲ－ＰＥインタフェースの一部であるもののＰＩＮ又はＳＩＮからは独立している物理的回路によって、ＤＭＲからＰＥへと通信してよい。ＤＭＲはマスクレジスタと呼ばれるレジスタを有し、これは、データトリガイベントの到着時にウェイクアップ信号を生成できるリンクポートを選択するよう構成してよい。追加のレジスタは、利用可能なポートのうちのいずれか１つがトリガされた場合に特定のＰＥに対するウェイクアップ信号が生成されるか、又は利用可能なポート全てがトリガされるまで上記ウェイクアップ信号が生成されないかを決定するよう構成してよい。これらのハードウェア機能の動作の例は、ｈｘ３１００Ａ集積回路製品のためのＨｙｐｅｒＸ（商標）ユーザマニュアルに詳述されている。

ＡＷＧＮ構成要素のための例示的なソースコードを、その動作の説明を付して以下に示す。これは、待機及びウェイクアップ信号送信のためのＲＴＡコンテキストを提供する。なお、このＡＷＧＮコードは単なる例であり、性能、命令メモリサイズ、バッファサイズ、信号サンプル値のタイプ等を調整するために数多くの変形例があり得る。

ｍｐｘ＿ｖｉｅｗ ａｗｇｎＶｉｅｗ（）｛
ＭＰＸ＿ＳｅｔｕｐＷａｋｅ（ｃｏｎｔｒｏｌＩｎ）；／／ｃｏｍｍＩＤ＝ｃｏｎｔｒｏｌＩｎに対するウェイクアップ信号を有効とする
ＭＰＸ＿ＳｅｔｕｐＷａｋｅ（ｄａｔａＩｎ）；／／ｃｏｍｍＩＤ＝ｄａｔａＩｎに対するウェイクアップ信号を有効とする
ＭＰＸ＿Ｒｅｃｖ（＆ｃｏｎｔｒｏｌ，ｓｉｚｅｏｆ（ｃｏｎｔｒｏｌ），ΜΡΧ＿ＩΝΤ，ｃｏｎｔｒｏｌＩｎ，ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ）；／／制御パケットの受信を開始、ここでは完了を待たない
ＭＰＸ＿Ｒｅｃｖ（＆ｄａｔａ，２，ＭＰＸ＿ＩＮＴ，ｄａｔａＩｎ，ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ）；／／データブロック（目標の信号）の受信を開始、ここでは完了を待たない
ｗｈｉｌｅ（１）｛／／無制限にループ
ＭＰＸ＿Ｗａｉｔ（）；／／いずれの利用可能なポートにおけるいずれの到着に対するウェイクアップ信号を待機
ｉｆ（ＭＰＸ＿Ｒｔｅｓｔ（ｃｏｎｔｒｏｌＩｎ）＝＝ＤＭＡ＿ＤＯＮＥ）｛／／データブロックの受信の完了に対する試験
ｓｎｒ＝ｃｏｎｔｒｏｌ．ｓｎｒ；／／パケットから現在のＳ／Ｎ比値を抽出 ａｖｅｒａｇｅ＿ｎｏｉｓｅ＝ｃｏｍｐｕｔｅＡｖｅｒａｇｅＮｏｉｓｅＦｒｏｍＳｉｇｎａｌＰｏｗｅｒ（ｃｏｎｔｒｏｌ．ａｖｅｒａｇｅＳｉｇｎａｌＰｏｗｅｒ）；
ＭＰＸ＿Ｒｅｃｖ（＆ｃｏｎｔｒｏｌ，ｓｉｚｅｏｆ（ｃｏｎｔｒｏｌ），ＭＰＸ＿ＩＮＴ，ｃｏｎｔｒｏｌＩｎ，ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ）；／／別の制御パケットの受信を開始、ここでは完了を待たない
｝
ｉｆ（ＭＰＸ＿Ｒｔｅｓｔ（ｄａｔａＩｎ）＝＝ＤＭＡ＿ＤＯＮＥ）｛／／コントロールパケットの受信の完了に対する試験
ａｄｄＮｏｉｓｅ（ｄａｔａ，２）；／／データブロックに対するノイズ付加のための機能の呼び出し
ＭＰＸ＿Ｓｅｎｄ（ｄａｔａ，２，ＭＰＸ＿ＩＮＴ，ｄａｔａＯｕｔ，ＭＰＸ＿ＤＭＡ）；／／データブロックをレシーバに送信
ＭＰＸ＿Ｒｅｃｖ（ｄａｔａ，２，ＭＰＸ＿ＩＮＴ，ｄａｔａＩｎ，ＭＰＸ＿ＮＯＮＢＬＯＣＫＩＮＧ）；／／別のデータブロックの受信を開始
｝
｝
｝

この例示的実施形態では、関数ａｗｇｎＶｉｅｗ（）は、ｃｏｍｍＩＤ「ｃｏｎｔｒｏｌＩｎ」及び「ｄａｔａＩｎ」に関連するＤＭＲポートからのウェイクアップ信号ソースを利用可能とすることから始まる。続いてこれは、「ｃｏｎｔｏｌ」という名称のメモリ内のバッファに制御パケットを受信するよう開始され、ここでＭＰＸ＿Ｒｅｃｖ関数に対する引数は、バッファアドレス、パケットサイズ、パケット要素に関するデータタイプ（ここではＭＰＸ＿ＩＮＴは整数を指定）、ｃｏｍｍＩＤ、非ブロッキングモードを指定する。非ブロッキングモードとは、プログラム制御が、バッファがいっぱいになるまで待機することなく、次の命令文に即座に進むことを意味する。上記次の命令文は、「ｄａｔａ」という名称のバッファ内にデータブロックを受信するよう開始され、これはｃｏｍｍ ＩＤ ｄａｔａＩｎからの、タイプを表す整数の２つの要素のみを含み、また非ブロッキングモードである。

次の命令文はｗｈｉｌｅループであり、これは、それぞれ試験によってゲート処理された２つの部分を包含するプログラムブロックに亘って無期限に動作する。第１の部分に関する試験（ＭＰＸ＿Ｒｔｅｓｔ（ｃｏｎｔｒｏｌＩｎ）＝＝ ＤＭＡ＿ＤＯＮＥ）は、ｃｏｎｔｒｏｌＩｎのためにウェイクアップ信号が受信されたことを確認するために実施される。ｃｏｍｍＩＤ ｃｏｎｔｏｌＩｎからのウェイクアップ信号が存在した場合、ＭＰＸ＿Ｒｔｅｓｔ（ｃｏｎｔｒｏｌＩｎ）はＤＭＡ＿ＤＯＮＥ値に戻る。ウェイクアップ信号を受信すると、プログラムは平均ノイズの計算処理を行い、次に別の制御パケットの読み出しを開始する。そうでない場合、プログラム制御は第２の部分に関する試験（ＭＰＸ＿Ｒｔｅｓｔ（ｄａｔａＩｎ）＝＝ＤＭＡ＿ＤＯＮＥ）へと移動する。この試験は、ｄａｔａＩｎのためのウェイクアップ信号が受信されている場合に真となり、その場合、プログラム制御は進行し、関数ａｄｄＮｏｉｓｅ（ｄａｔａ，２）を呼び出してデータバッファ内の値にノイズを付加する。続いて、ＤＵＴ上で実行されるレシーバアプリケーションへの経路であるｃｏｍｍＩＤ ｄａｔａＯｕｔを通した、ＤＭＲからノイズを付加したデータのＭＰＸ＿Ｓｅｎｄが実行される。この送信は、最後の命令文に進む前に確実に完了するようにブロッキングモードであり、上記最後の命令文は、ｃｏｍｍＩＤ ｄａｔａＩｎから別のデータブロックの受信を開始するための非ブロッキングモードでの受信である。そしてプログラム制御はｗｈｉｌｅ命令文、そして新規の制御パケット又は新規のデータブロックの到着までＰＥが待機するＷａｉｔ命令文までループして戻る。

信号空間
図２１は、一実施形態による例示的な信号空間ダイヤグラムである。信号空間ダイヤグラムは、直交振幅変調（ＱＡＭ）信号を復号化することの効果を図式的に示してよい。ＩＱデータは、信号空間プロット（散布図としても知られる）として、又は２Ｄ若しくは３Ｄヒートマップとして示してよい。図示したように、グラフのタイプの選択は、コンステレーションビューの底部のタブのセットによって実施できる。

ビデオによる実施例
これより、ビデオソースが画像フレームをチップに送信する単純な例について説明する。図２２は、例えばファイルの数（「ファイル」）、メッセージの数（「メッセージ」）、データレート（「バイトレート」）、フレームレート（「フレームレート」）といった様々なパラメータ又は属性を構成及び／又は表示できるビデオソースビュー（ＧＵＩ）を示す。これもまた図２２に示すように、画像のオーバレイを特定するためのフィールド、具体的にはこの例では「Ｏｖｅｒｌａｙ」である画像オーバレイテキストも提供される。

この例示的実施形態では、各フレームはＪＰＥＧ画像としてフォーマットされている。ＪＰＥＧデータは：
１．ファイルからの読み出し；
２．画像への復号化；
３．ファイルに画像オーバレイテキストを書き込み；
４．画像をＪＰＥＧに再符号化；
５．画像をチップに送信
である。

この実施形態では、１０２４語の固定サイズメッセージを用いて画像を送信する。従って最終的なＪＰＥＧ画像は複数のメッセージに分割され得る。

更なる実施形態では、特に更に複雑で密なＭＰＡに関して、比較的複雑な機器を上述の技術によってプログラムして挿入してよい。このようなソフトウェアベースの機器は一般に「合成機器（ＳＩ）」と呼ばれ、特にスペクトラムアナライザ又はベクタ信号アナライザといった機器機能を実装してよい。

例示的な便益
以下は、ここで開示した技術の可能な便益のリストであるが、ここに列挙した便益は単なる例であり、ここで開示した技術の実際の便益をいずれの特定の便益のセットに制限することを意図したものではないことに留意されたい：
ユーザが試験点を選択した場合の、プローブ及びオフチップ通信経路の自動的な設定； メモリ位置及び信号の自動的な精査；
変化する信号対ノイズ比に対して適合するための、ランタイムのインテリジェントな変動；
信号測定の帯域幅の上昇；
測定を行う速度の上昇；
測定データがチップを離れる前の、測定データのより良好な圧縮；
試験完了速度の上昇；
アプリケーションソフトウェアのより完全な試験及び特性決定；
必要な試験設備の数及びタイプの可能な限りの削減；並びに
オリジナル設計の動作、機能又は性能を観察が妨害しないこと。

以上の実施形態についてはかなり詳細に説明してきたが、以上の開示を完全に理解すれば、当業者には多数の変形例及び修正例が明らかとなるであろう。以下の請求項は、このような変形例及び修正例の全てを包含するものとして理解されることを意図したものである。

Claims (15)

1. アプリケーションソフトウェアを分析するステップと、
   前記アプリケーションソフトウェアを分析するステップの結果に少なくとも部分的に基づいて、テストソフトウェアを展開するステップと、
   前記アプリケーションソフトウェアを、多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で展開するステップであって、前記ＭＰＡは、複数の処理要素と、複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第１のハードウェアリソースは、前記複数の処理要素の少なくとも第１のサブセットを含むステップと、
   前記テストソフトウェアを、前記ＭＰＡの第２のハードウェアリソース上で展開するステップであって、前記第２のハードウェアリソースは、前記複数の処理要素の前記第１のサブセットとは異なる前記複数の処理要素の少なくとも第２のサブセットを含むステップと、
   前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行するステップと、
   前記テストソフトウェアを前記第２のハードウェアリソース上で実行するステップであって、前記テストソフトウェアを実行するステップは、
   前記第２のハードウェアリソースに含まれている第１の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第１のハードウェアリソース内でのダイレクトメモリアクセス（ＤＭＡ）転送に関連する一つ以上のレジスタをポーリングすることと、
   前記第１の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
   とを含むステップと、
   を含む方法。
2. 前記第１の処理要素のポーリングの優先度は、前記第１のハードウェアリソース内で前記ＤＭＡを実行することに関連する優先度よりも小さい、請求項１に記載の方法。
3. 前記アプリケーションソフトウェアを、少なくとも一つのプローブコマンドを含むように修正するステップをさらに含み、前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行するステップは、前記少なくとも一つのプローブコマンドを実行することに応答してプローブデータを生成することを含む、請求項１に記載の方法。
4. 前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行するステップは、
   複数のＤＭＡエンジンの第１のＤＭＡエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
   前記複数のＤＭＡエンジンの第２のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
   を含む、請求項３に記載の方法。
5. 前記テストソフトウェアを前記第２のハードウェアリソース上で実行するステップは、前記複数のＤＭＡエンジンの第３のＤＭＡエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項４に記載の方法。
6. 多重プロセッサシステムによる実行に応答して、前記多重プロセッサシステムに、
   アプリケーションソフトウェアを分析することと、
   前記アプリケーションソフトウェアを分析することの結果に少なくとも部分的に基づいて、テストソフトウェアを展開することと、
   多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で前記アプリケーションソフトウェアを展開することであって、前記ＭＰＡは、複数の処理要素と、複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第１のハードウェアリソースは、前記複数の処理要素の少なくとも第１のサブセットを含むことと、
   前記テストソフトウェアを、前記ＭＰＡの第２のハードウェアリソース上で展開することであって、前記第２のハードウェアリソースは、前記複数の処理要素の前記第１のサブセットとは異なる前記複数の処理要素の少なくとも第２のサブセットを含むことと、
   前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行することと、
   前記テストソフトウェアを前記第２のハードウェアリソース上で実行することであって、前記テストソフトウェアを実行するステップは、
   前記第２のハードウェアリソースに含まれている第１の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第１のハードウェアリソース内でのダイレクトメモリアクセス（ＤＭＡ）転送に関連する一つ以上のレジスタをポーリングすることと、
   前記第１の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
   とを含むことと、
   を含む動作を実行させるプログラム命令を中に格納した、非一時的なコンピュータ可読メモリ媒体。
7. 前記動作は、少なくとも一つのプローブコマンドを含むように前記アプリケーションソフトウェアを修正することをさらに含み、前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行するステップは、前記少なくとも一つのプローブコマンドを実行することに応答して、プローブデータを生成することを含む、請求項６に記載の非一時的なコンピュータ可読メモリ媒体。
8. 前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行するステップは、
   複数のＤＭＡエンジンの第１のＤＭＡエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
   前記複数のＤＭＡエンジンの第２のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
   を含む、請求項７に記載の非一時的なコンピュータ可読メモリ媒体。
9. 前記テストソフトウェアを前記第２のハードウェアリソース上で実行するステップは、前記複数のＤＭＡエンジンの第３のＤＭＡエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項８に記載の非一時的なコンピュータ可読メモリ媒体。
10. 前記動作は、
    前記第１のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義されたルートのセットに含まれる第１の一つ以上のルートを介してストリーミングすることと、
    前記第２のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットに含まれる第２の一つ以上のルートを介してストリーミングすることと、
    前記第３のＤＭＡエンジンによって、前記プローブデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットから除外される第３の一つ以上のルートを介してストリーミングすることと、
    をさらに含む、請求項９に記載の非一時的なコンピュータ可読メモリ媒体。
11. 命令を格納するように構成された一つ以上のメモリと、
    前記一つ以上のメモリから命令を受け取り、およびシステムに、
    アプリケーションソフトウェアを分析させるように、
    前記アプリケーションソフトウェアを分析することの結果に少なくとも部分的に基づいて、テストソフトウェアを展開させるように、
    前記アプリケーションソフトウェアを、多重プロセッサアレイ（ＭＰＡ）の第１のハードウェアリソース上で展開させるように、この場合、前記ＭＰＡは、複数の処理要素と、命令および／またはデータを格納する複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第１のハードウェアリソースは、前記複数の処理要素の少なくとも第１のサブセットを含み、
    前記テストソフトウェアを、前記ＭＰＡの第２のハードウェアリソース上で展開させるように、この場合、前記第２のハードウェアリソースは、前記複数の処理要素の前記第１のサブセットとは異なる、前記複数の処理要素の少なくとも第２のサブセットを含み、 前記アプリケーションソフトウェアを前記第１のハードウェアリソース上で実行させるように、および
    前記テストソフトウェアを前記第２のハードウェアリソース上で実行させるように、この場合、前記テストソフトウェアの実行は、
    前記第２のハードウェアリソースに含まれている第１の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第１のハードウェアリソース内でのダイレクトメモリアクセス（ＤＭＡ）転送に関連する一つ以上のレジスタをポーリングすることと、
    前記第１の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
    とを含むように、
    前記命令を実行させるように構成された、一つ以上のプロセッサと、
    を備えるシステム。
12. 前記命令の実行はさらに、前記システムに、少なくとも一つのプローブコマンドを含むように前記アプリケーションソフトウェアを修正させ、前記第１のハードウェアリソース上での前記アプリケーションソフトウェアの実行は、前記少なくとも一つのプローブコマンドを実行することに応答したプローブデータの生成を含む、請求項１１に記載のシステム。
13. 前記第１のハードウェアリソース上での前記アプリケーションソフトウェアの実行は、 複数のＤＭＡエンジンの第１のＤＭＡエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
    前記複数のＤＭＡエンジンの第２のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
    を含む、請求項１２に記載のシステム。
14. 前記第２のハードウェアリソース上での前記テストソフトウェアの実行は、前記複数のＤＭＡエンジンの第３のＤＭＡエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項１３に記載のシステム。
15. 前記命令の実行はさらに、前記システムに、
    前記第１のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義されたルートのセットに含まれる第１の一つ以上のルートを介してストリーミングさせ、
    前記第２のＤＭＡエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットに含まれる第２の一つ以上のルートを介してストリーミングさせ、
    前記第３のＤＭＡエンジンによって、前記プローブデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットから除外される第３の一つ以上のルートを介してストリーミングさせる、
    請求項１４に記載のシステム。

Images