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

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (15)

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

Images