IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ コーヒレント・ロジックス・インコーポレーテッドの特許一覧

特開2022-84921多重プロセッサシステムのためのリアルタイム分析及び制御
<>
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図1
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図2
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図3
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図4
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図5
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図6
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図7
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図8
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図9
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図10
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図11
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図12
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図13
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図14
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図15
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図16
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図17
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図18
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図19
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図20
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図21
  • 特開-多重プロセッサシステムのためのリアルタイム分析及び制御 図22
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022084921
(43)【公開日】2022-06-07
(54)【発明の名称】多重プロセッサシステムのためのリアルタイム分析及び制御
(51)【国際特許分類】
   G06F 11/36 20060101AFI20220531BHJP
【FI】
G06F11/36 188
G06F11/36 192
【審査請求】有
【請求項の数】1
【出願形態】OL
(21)【出願番号】P 2022058455
(22)【出願日】2022-03-31
(62)【分割の表示】P 2020009082の分割
【原出願日】2013-11-08
(31)【優先権主張番号】61/724,493
(32)【優先日】2012-11-09
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.VERILOG
(71)【出願人】
【識別番号】505000815
【氏名又は名称】コーヒレント・ロジックス・インコーポレーテッド
(74)【代理人】
【識別番号】100098394
【弁理士】
【氏名又は名称】山川 茂樹
(72)【発明者】
【氏名】エリス,ジェフリー・エヌ
(72)【発明者】
【氏名】ビアズリー,ジョン・マーク
(72)【発明者】
【氏名】ドーア,マイケル・ビイ
(72)【発明者】
【氏名】アグアヨ,アイヴァン
(72)【発明者】
【氏名】ダリオ,ブライアン・エイ
(57)【要約】
【課題】アプリケーションソフトウェアを動作速度で実行する多重プロセッサアレイ(MPA)を含む試験中のデバイス(DUT)を試験するためのシステム及び方法を提供する。
【解決手段】アプリケーションソフトウェア内で生成されたデータは試験を目的として複製され、MPA上のハードウェアリソースを構成するための試験用コードを生成する。アプリケーションソフトウェアは、第1のハードウェアリソース上で展開され、提供された入力データを用いてDUTを刺激する。試験用コードを実行して、アプリケーションソフトウェアの実行には使用されないMPAのハードウェアリソースを用いてDUTを分析するために、第1のデータの少なくともサブセットがMPAのエッジのピンに供給される。第1のデータは、入力データに基づいてアプリケーションソフトウェアが実行した送信命令文に応答して生成される。
【選択図】図11
【特許請求の範囲】
【請求項1】
アプリケーションソフトウェアを分析するステップと、
前記アプリケーションソフトウェアを分析するステップの結果に少なくとも部分的に基づいて、テストソフトウェアを展開するステップと、
前記アプリケーションソフトウェアを、多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で展開するステップであって、前記MPAは、複数の処理要素と、複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第1のハードウェアリソースは、前記複数の処理要素の少なくとも第1のサブセットを含むステップと、
前記テストソフトウェアを、前記MPAの第2のハードウェアリソース上で展開するステップであって、前記第2のハードウェアリソースは、前記複数の処理要素の前記第1のサブセットとは異なる前記複数の処理要素の少なくとも第2のサブセットを含むステップと、
前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行するステップと、
前記テストソフトウェアを前記第2のハードウェアリソース上で実行するステップであって、前記テストソフトウェアを実行するステップは、
前記第2のハードウェアリソースに含まれている第1の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第1のハードウェアリソース内でのダイレクトメモリアクセス(DMA)転送に関連する一つ以上のレジスタをポーリングすることと、
前記第1の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
とを含むステップと、
を含む方法。
【請求項2】
前記第1の処理要素のポーリングの優先度は、前記第1のハードウェアリソース内で前記DMAを実行することに関連する優先度よりも小さい、請求項1に記載の方法。
【請求項3】
前記アプリケーションソフトウェアを、少なくとも一つのプローブコマンドを含むように修正するステップをさらに含み、前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行するステップは、前記少なくとも一つのプローブコマンドを実行することに応答してプローブデータを生成することを含む、請求項1に記載の方法。
【請求項4】
前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行するステップは、
複数のDMAエンジンの第1のDMAエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
前記複数のDMAエンジンの第2のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
を含む、請求項3に記載の方法。
【請求項5】
前記テストソフトウェアを前記第2のハードウェアリソース上で実行するステップは、前記複数のDMAエンジンの第3のDMAエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項4に記載の方法。
【請求項6】
多重プロセッサシステムによる実行に応答して、前記多重プロセッサシステムに、
アプリケーションソフトウェアを分析することと、
前記アプリケーションソフトウェアを分析することの結果に少なくとも部分的に基づいて、テストソフトウェアを展開することと、
多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で前記アプリケーションソフトウェアを展開することであって、前記MPAは、複数の処理要素と、複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第1のハードウェアリソースは、前記複数の処理要素の少なくとも第1のサブセットを含むことと、
前記テストソフトウェアを、前記MPAの第2のハードウェアリソース上で展開することであって、前記第2のハードウェアリソースは、前記複数の処理要素の前記第1のサブセットとは異なる前記複数の処理要素の少なくとも第2のサブセットを含むことと、
前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行することと、
前記テストソフトウェアを前記第2のハードウェアリソース上で実行することであって、前記テストソフトウェアを実行するステップは、
前記第2のハードウェアリソースに含まれている第1の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第1のハードウェアリソース内でのダイレクトメモリアクセス(DMA)転送に関連する一つ以上のレジスタをポーリングすることと、
前記第1の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
とを含むことと、
を含む動作を実行させるプログラム命令を中に格納した、非一時的なコンピュータ可読メモリ媒体。
【請求項7】
前記動作は、少なくとも一つのプローブコマンドを含むように前記アプリケーションソフトウェアを修正することをさらに含み、前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行するステップは、前記少なくとも一つのプローブコマンドを実行することに応答して、プローブデータを生成することを含む、請求項6に記載の非一時的なコンピュータ可読メモリ媒体。
【請求項8】
前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行するステップは、
複数のDMAエンジンの第1のDMAエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
前記複数のDMAエンジンの第2のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
を含む、請求項7に記載の非一時的なコンピュータ可読メモリ媒体。
【請求項9】
前記テストソフトウェアを前記第2のハードウェアリソース上で実行するステップは、前記複数のDMAエンジンの第3のDMAエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項8に記載の非一時的なコンピュータ可読メモリ媒体。
【請求項10】
前記動作は、
前記第1のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義されたルートのセットに含まれる第1の一つ以上のルートを介してストリーミングすることと、
前記第2のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットに含まれる第2の一つ以上のルートを介してストリーミングすることと、
前記第3のDMAエンジンによって、前記プローブデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットから除外される第3の一つ以上のルートを介してストリーミングすることと、
をさらに含む、請求項9に記載の非一時的なコンピュータ可読メモリ媒体。
【請求項11】
命令を格納するように構成された一つ以上のメモリと、
前記一つ以上のメモリから命令を受け取り、およびシステムに、
アプリケーションソフトウェアを分析させるように、
前記アプリケーションソフトウェアを分析することの結果に少なくとも部分的に基づいて、テストソフトウェアを展開させるように、
前記アプリケーションソフトウェアを、多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で展開させるように、この場合、前記MPAは、複数の処理要素と、命令および/またはデータを格納する複数のメモリと、前記複数の処理要素を前記複数のメモリに通信可能に連結する相互接続ネットワークとを含み、前記第1のハードウェアリソースは、前記複数の処理要素の少なくとも第1のサブセットを含み、
前記テストソフトウェアを、前記MPAの第2のハードウェアリソース上で展開させるように、この場合、前記第2のハードウェアリソースは、前記複数の処理要素の前記第1のサブセットとは異なる、前記複数の処理要素の少なくとも第2のサブセットを含み、 前記アプリケーションソフトウェアを前記第1のハードウェアリソース上で実行させるように、および
前記テストソフトウェアを前記第2のハードウェアリソース上で実行させるように、この場合、前記テストソフトウェアの実行は、
前記第2のハードウェアリソースに含まれている第1の処理要素によって、前記アプリケーションソフトウェアに含まれる一つ以上のプログラムコマンドを実行することから生じる前記第1のハードウェアリソース内でのダイレクトメモリアクセス(DMA)転送に関連する一つ以上のレジスタをポーリングすることと、
前記第1の処理要素によって、前記一つ以上のレジスタから検索されたデータを、分析のための記憶場所へ送信すること、
とを含むように、
前記命令を実行させるように構成された、一つ以上のプロセッサと、
を備えるシステム。
【請求項12】
前記命令の実行はさらに、前記システムに、少なくとも一つのプローブコマンドを含むように前記アプリケーションソフトウェアを修正させ、前記第1のハードウェアリソース上での前記アプリケーションソフトウェアの実行は、前記少なくとも一つのプローブコマンドを実行することに応答したプローブデータの生成を含む、請求項11に記載のシステム。
【請求項13】
前記第1のハードウェアリソース上での前記アプリケーションソフトウェアの実行は、 複数のDMAエンジンの第1のDMAエンジンによって、前記アプリケーションソフトウェアおよび前記プローブデータを実行することから生じるデータを、前記複数のメモリのうちの特定のメモリにストリーミングすることと、
前記複数のDMAエンジンの第2のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記複数のメモリ内の対象の記憶場所にストリーミングすることと、
を含む、請求項12に記載のシステム。
【請求項14】
前記第2のハードウェアリソース上での前記テストソフトウェアの実行は、前記複数のDMAエンジンの第3のDMAエンジンによって、前記分析のための記憶場所にストリーミングすることを含む、請求項13に記載のシステム。
【請求項15】
前記命令の実行はさらに、前記システムに、
前記第1のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義されたルートのセットに含まれる第1の一つ以上のルートを介してストリーミングさせ、
前記第2のDMAエンジンによって、前記アプリケーションソフトウェアを実行することから生じるデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットに含まれる第2の一つ以上のルートを介してストリーミングさせ、
前記第3のDMAエンジンによって、前記プローブデータを、前記アプリケーションソフトウェアのために定義された前記ルートのセットから除外される第3の一つ以上のルートを介してストリーミングさせる、
請求項14に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明の分野は一般に、コンピュータ、デジタル信号プロセッサ(digital signal processor:DSP)及びこれらの埋込み型の例といったデジタル電子システムのための、ソフトウェア開発、自動化された試験及び分析に関し、より具体的には、多重プロセッサシステムのためのリアルタイム分析及び制御に関する。
【背景技術】
【0002】
新規のデジタル電子製品の開発には、ハードウェア及びその中のソフトウェアを検証するために、数多くの試験、測定、特徴決定が必要である。複雑なデジタル電子製品に関して、上記検証のコストは、開発プロジェクトの総コストのうち最も大きな部分を占めることもある。試験及び検証コストを削減するために、いくつかの方法又は技術が存在する。
【0003】
1つの方法はテスト容易化設計(design for test:DFT)であり、ここでは製品設計が、試験を簡略化する技術のための条件を含む。これは、製品及びその構成デバイスの内部状態の可制御性及び可観測性を上昇させる、試験点の条件を含む。試験点に関する潜在的な問題は、これら試験点の位置がシステム内へと固定されてしまい、最終製品において変更できなくなる場合があることである。別の問題としては、試験点からの生データのレートが、システムがデータを消費又は処理する性能を超えることがあり、従って試験を実施するための通常の速度より低速で製品を動作させなければならなくなる。
【0004】
試験及び検証のコストを削減する別の方法は、自動化された試験である。というのは、試験を実施するにあたって人間である操作者が不要であれば、単位時間あたりに実施できる試験の数を大幅に増やすことができ、これによって故障を捕捉できる蓋然性が上昇するためである。しかしながら、アプリケーションソフトウェアの開発中及び自動化された試験中に、プログラマの設計の増大及び短いサイクルでの(インタラクティブな)試験をサポートできると有益である。
【0005】
別のアプローチは、製品の通常の動作に対して無視できる程度の悪影響しか有さないように、製品の内部に試験機器を内蔵させることである。内蔵型試験機器(Built-In Test Instrumentation)は、高速で複雑な信号を投入及び回収する高性能プローブから、プローブ信号処理、統計及びグラフィカルディスプレイ等の分析能力まで、幅広いものであり得る。このアプローチの問題は、生データを最高速度で消費するための十分な処理リソースが欠乏していることである。
【0006】
別の方法は、内蔵型自己試験(built-in self-test:BIST)である。BISTは多数の自動内部試験を利用してよく、これら試験のそれぞれが二値パターン結果を生成し、これらを加算して累計を得る。全ての試験が終了すると、上記累計はシグニチャとなり、これを出力して、設計及びシミュレーション中に生成した既知の良好なシグニチャと比較してよい。BISTはより詳細な報告、例えば失敗した試験が存在する場合はいずれの試験が失敗したかの報告を生成することもできる。
【0007】
BIST及びBITIの両方を製品の寿命中に使用して、メンテナンス性を向上させてよい。これらの技術は同一のデバイスに対して併用してよい。
【0008】
上述の技術はそれぞれ、細部に対する相当な注意を必要とし、これらの細部を追跡するにはコンピュータが使用される。また各製品はその詳細において異なり、従って、各製品の確認の為に必要な試験、測定及び特性決定データを得られるように上記コンピュータをプログラムするには相当な努力が必要となり得る。
【0009】
これらの技術を使用することによる利益は通常、これらの技術を実装するためのコストを上回るものであるが、改善は可能であり、当該技術分野で改善が進められている。
【0010】
コストは様々な方法で削減でき、例えば各製品に合わせた試験システムを作成するために容易に組み合わせることができる、再使用可能なパラメータ化されたモジュールを、試験の設定及びプログラミングプロセスに利用できるようにすることによって、コストを削減できる。
【0011】
利益は様々な方法で増大させることができ、例えば試験動作をより高速で実施して、単位時間あたりに実施できる試験を大幅に増やし、これに伴ってアプリケーションの状態空間の範囲を増大させ、適切な動作を確認する(又は製品を顧客に届ける前にバグを発見する)ことにより、利益を増大させることができる。
【0012】
コンピュータ、デジタル信号プロセッサ(DSP)、並びに無線電話;政府サービス無線(government service radios);携帯電話、スマートフォン及びタブレットコンピュータといった消費者無線機器;携帯電話基地局装置;ビデオ処理及び放送装置;物体認識装置;ハイパースペクトル画像データ処理等の包囲設備内に埋め込まれるこれらのシステム等のデジタル電子システムは、1つ又は複数の多重プロセッサアレイ(multi-processor array:MPA)をますます利用するようになっている。MPAは、複数の処理素子(processing element:PE)、補助メモリ(supporting memory:SM)、高帯域相互接続ネットワーク(interconnect network:IN)としておおまかに定義できる。本明細書で使用される用語「処理素子(processing element)」は、プロセッサ若しくはCPU(中央演算処理装置)、マイクロプロセッサ又はプロセッサコアを指す。MPAの中の単語「アレイ(array)」は、円形次元(ループ又はリング)を含む1、2、3又はそれ以上の次元で利用可能な接続を備えるネットワークによって相互接続された、複数の計算ユニット(これらはそれぞれ処理及びメモリリソースを含む)を意味するものとして、最も広い意味で使用される。なお、次元が高いMPAをより低い次元の製造用媒体上にマッピングできる。例えば4次元(4D)超立方体の形状を有するIN内のMPAは、シリコン集積回路(ICを)チップの積層体上に、又は単一の2Dチップ上に、又は計算ユニットの1Dの線上にさえ、マッピングできる。次元が低いMPAをより高い次元の媒体にマッピングすることもできる。例えば計算ユニットの1Dの線を、ICチップの2D平面上に曲がりくねった形状で展開でき、又はチップの3D積層体へと巻くことができる。MPAは複数の種類の計算ユニットと、プロセッサ及びメモリが散在する構成とを含んでよい。広い意味でのMPAは、MPAの階層又は入れ子構成、特に相互接続されたICチップからなるMPAも含まれ、この場合ICがチップが1つ又は複数のMPAを含み、これらMPAもまた更に深い階層構造を有する。
【0013】
MPAは、ソフトウェア開発方法及びツールに対して新たな問題及び機会を提示する。MPAは数千ものPEにまで拡張できるため、アレイを操作するために大量のソフトウェアを管理する必要があり、またこれらソフトウェアを効率的に試験、デバッグ、再構成する必要がある。これには一般に、モジュール性、階層、適応性のあるモジュールの再使用、自動構築方法が必要となる。これらの着想は従来のソフトウェア開発システムにも見られるが、これらの着想は、性能要件に左右される異なる数のPE及び他のリソースに対して、又はリソース利用可能性若しくはアプリケーション要件に左右され得る異なる形状若しくはトポロジ要件に対して、静的及び/又は動的に適合できる汎用モジュールをサポートするような様式で開発ツールに組み込まれることはなかった。
【0014】
ソフトウェア開発プロジェクトは、開発チームによって与えられた要件に従って何らかの製品又はサービスを動作させるソフトウェアを生成するための、人間と機械の作業との組み合わせである。一般に、設計及び試験がより自動化されれば、生成されたソフトウェアに対してより多くの試験を行うことができ、より多くのバグを排除できるため、有益である。
【0015】
組み込みシステム用の従来技術のソフトウェア開発環境を図1に図示する。人間であるソフトウェアエンジニア及びプログラマ以外に、この開発環境には3つの主要な部分が存在し、これらは最終製品及びテストベンチであり、上記テストベンチは図示したようにワークステーションを含んでよいが、いくつかの従来技術の開発システムではワークステーションはテストベンチから離れているものとして考えることができる。
【0016】
最終製品の最低限の表現は、技術要件のリストである。テストベンチに関する最低限の要件は、試験中のデバイス(device under test:DUT)のためのテストパターン入力を生成するための手段と、DUTの出力を捕捉して既知の良好なパターンと比較するための方法である。DUTが最終製品に適合すればするほど、開発されるソフトウェアが最終製品において期待通りに動作する確信が高まる。
【0017】
ワークステーションに関する最低限の要件は、マスストレージの細部と、設計データのデータベースと、プロジェクトデータベースに対して読み書きを行う設計ツールの組(又はスイート)とを管理するオペレーティングシステム(operating system:OS)を備えるデスクトップ又はラップトップコンピュータである。2つ以上のプロジェクト並びに2つ以上のプロジェクトデータベース及びツールが存在してよく、これらの間でライブラリを共有することで、開発コストを下げることができる。
【0018】
一般に、コンピュータ及びDSPのためのメモリは、上部に高速なメモリを有し、低速であるが大容量のメモリを各段下部に有する階層として組織される。MPAでは、階層の上部の補助メモリが各PEの近傍に位置する。各補助メモリは、最適な命令又は最適なデータを保持するよう特殊化できる。特定のPEのための補助メモリは、そのPE専用のものであっても、又は他のPEと共用であってもよい。
【0019】
メモリ階層を更に下がると、典型的には、各PEに隣接する補助メモリの何倍も大きいビット容量を有する半導体同期SDRAMからなる、比較的大型の共有メモリが存在してもよい。メモリ階層を更に下がるとフラッシュメモリ、磁気ディスク、光学ディスクがある。
【0020】
上述のように、多重プロセッサアレイ(MPA)は、処理要素(PE)、補助メモリ(SM)、並びにPE及び/若しくはメモリ間の高帯域幅データ通信を支援するための一次相互接続ネットワーク(primary interconnection network:PIN、若しくは単にIN)を含む。図2、3には例示的なMPAが図示されており、これらについて以下に説明する。一般にPEは、入力データ及び出力データをバッファリングするためのレジスタ、命令処理ユニット(instruction processing unit:IPU)、データに対して演算及び論理関数を実行するための手段、並びにシステムのその他の部分との通信のための多数のスイッチ及びポートを備える。IPUはメモリから命令をフェッチし、これら命令を復号化して、データをPEに及びPEから移動させるため並びにデータに対して演算及び論理関数を実行するために適切な制御信号を設定する。大型MPAに適したPEは一般に、1つの大型MPAを含む1つのICチップに対してPEの数が多いという単純な理由で、汎用プロセッサ(general purpose processors:GPP)よりもエネルギ効率が一般に高いはずである。
【0021】
本出願において使用される用語MPAは、複数のプロセッサの比較的均一なアレイと、いわゆる「プラットフォームIC」チップ上に集積された汎用プロセッサ及び特殊化されたプロセッサの異種集団との両方を包含する。プラットフォームICチップは数個から多数のプロセッサを含んでよく、これらは典型的には共有メモリと相互接続され、場合によってはオンチップネットワークと相互接続される。MPAと「プラットフォームIC」チップとの間には違いがあってもなくてもよい。しかしながら「プラットフォームIC」チップは、特定の垂直的市場における特定の技術要件に対処するために市販されているものであってよい。
【0022】
例示的なMPAアーキテクチャは、特許文献1に開示されているHyperX(商標)アーキテクチャである。HyperX(商標)アーキテクチャの一実施形態では、広範なサイズの多重プロセッサアレイは単位セルベースのハードウェア組織(メッシュ)からなってよく、各セルはHyperSliceと呼ばれる。このハードウェア組織は、グリッド上に単位セルを配設し、隣接するセルを相互接続することによって形成できる。各HyperSliceは、1つ又は複数のデータメモリ及びルータ(DMR)、並びに1つ又は複数の処理要素(PE)を含んでよい。米国特許第7415594号では、DMRは動的設定可能通信(dynamically configurable communication:DCC)要素と呼ばれることもあり、PEは動的設定可能処理(dynamically configurable processing:DCP)要素と呼ばれることもある。DMRは隣接するPEに補助メモリを提供でき、また相互接続ネットワーク(IN)にルータ及びリンクを提供できる。
【0023】
ハードウェアファブリックは、HyperSliceを隣接させることによって生成でき、これにはHyperSliceを位置合わせして、正確な電気的接続を形成することが必要となる。このような接続は、DMRへのリンク、電源グリッドへの接続を含む。HyperSliceを複製し、これらを隣接させ、隣接によって接続する技術は、集積回路(integrated circuit:IC)チップ、特に相補型金属酸化膜半導体(complementary metal oxide semiconductor:CMOS)回路技術を用いて製作されるICの、よく知られている超大規模集積(very large scale integration:VLSI)である。このハードウェアファブリックは、独立して、かつ処理要素に対して透明に動作する一次IN(PIN)を有し、また任意の通信ネットワークトポロジをサポートするHyperSlice間の、リアルタイムでプログラム可能かつ適合可能な通信経路(ルート又はパスと呼ばれる場合もある)を通してオンデマンド帯域幅を提供できる。HyperSliceの調整グループは、ソフトウェア制御下で「オン・ザ・フライ」で形成及び再形成できる。関数を評価するために使用されるハードウェアの量を動的に変更できるこのような能力により、ハードウェアリソースの最適な応用が可能となり、これによって処理におけるボトルネックが緩和される。ハードウェアファブリックの縁部において、リンクは、メモリ階層の更に下にあるメモリのタイプに対して、又は集積回路(IC)チップの縁部のI/Oに対して特化された回路に接続される。
【0024】
HyperXハードウェアファブリックの相互接続されたDMRは、チップ内を横断する、及びチップ間の、最も近接した、局所的な、及び全体的な通信を提供できる。これらの通信モードはそれぞれ、DMRリソースを物理的に用いて、データの局所性及びソフトウェアアルゴリズムの要件に応じてデータ/メッセージを様々に送信できる。「クイックポート(Quick Port)」設備を設けることにより、プロセッサからいずれのネットワーク目的地への、データの1つ又は複数の語の低レイテンシ伝送をサポートできる。ブロック伝送に関して、メモリ及びルーティングファブリックを横断するデータの移動を管理するために、DMR内でダイレクトメモリアクセス(DMA)エンジンを利用可能としてよい。PE間の最近接通信に関して、共有メモリ及びレジスタの使用が、最も効率的なデータ移動方法となり得る。局所的及び全体的なデータ移動に関して、ルーティングファブリック(PIN)の使用が最も効率的な方法となり得る。通信経路(又はルート)は動的でも静的でもよい。動的ルートは、データ伝送のために設定され、伝送が完了すると、他のルート及びデータ伝送のためにPINリソースを活用できるよう切断してよい。静的リソースは、プログラム実行を通して所定の位置にあり続けることができ、主に優先度が高く重要な通信に使用される。通信経路の物理的位置及びこれら経路を横断するデータ伝送のタイミングは、ソフトウェアプログラム制御下にあってよい。いずれのセンダといずれのレシーバとの間の同時データ伝送をサポートするために多重通信経路が存在してよい。
【0025】
DMRのアーキテクチャにより、異なる相互交換可能なPEを、システムを特定の用途に対して最適化するために多重プロセッサファブリックにおいて使用できる。HyperX(商標)多重プロセッサシステムは、PE異種のPEによるアレイ又は同種のPEによるアレイを備えてよい。PEは従来のプロセッサであってよく、又はPEはプロセッサの従来の定義に適合していなくてもよい。PEは単に、特定の論理関数のための結線接続されたプロセッサとして機能する論理ゲートの集合であってよく、ここではより高い性能、より小さい面積及び/又はより低い電力のためにプログラム可能性が犠牲となっている。
【0026】
図2は、従来技術による例示的なHyperX(商標)システムの、処理要素(PE)及びデータメモリルータ(DMR)のネットワークを示す。PEは矩形のブロックとして図示され、DMRは円として図示されている。DMR間のルーティングパスは点線で図示されている。中実の三角形はオフメッシュ通信を示し、実線はDMR間のアクティブなデータ通信を示す。計算タスクはその数値による識別子で示され、これを実行するPE上に位置する。通信に使用されているデータ変数はその名称で示され、これを含むDMR上に位置する。図示した実施形態では、左上のPEはタスクID62のタスクに割り当てられ、このPEに隣接する各DMRを介して他のPE又はメモリと通信でき、上記各DMRは通信パス変数t、w、uで表されている。これもまた図示されているように、この実施形態では、アクティブな通信チャネルは、「x」で標識されている隣接するDMRを介して、71(例えば別のタスクID)で表されているPEを、オフメッシュ通信パス又はポートに接続する。
【0027】
図3は、従来技術による、1つのチップ上に実装された例示的な多重プロセッサシステムを示す。図示したように、このチップはオフチップデバイスとの通信のための複数のI/Oルータと、図2の例示的なシステムと同様の内部多重プロセッサファブリックとを含む。HyperX(商標)プロセッサアーキテクチャは、固有の多次元性を含んでよいが、物理的には平面実施形態に実装できる。このプロセッサアーキテクチャは高エネルギ効率特性を有してよく、また(大型のアレイに対して)基本的に対応可能であり、信頼性が高い。即ち低電力かつ信頼性の高い概念を提示する。プロセッサアーキテクチャが前例のない性能を達成できる態様は、最新式のプロセッサ、メモリネットワーク、柔軟なIOを含む。処理要素(PE)はフルフレッジドDSP/GPPであってよく、また、ハードウェアリソースの使用を同時に最大化しながらスループットを維持するために実行パイプラインを動的に拡張できる可変幅命令語命令セットアーキテクチャによって支持される、メモリ間(キャッシュレス)アーキテクチャに基づくものであってよい。
【0028】
従来技術によるDMRハードウェア構造の例を、図4により詳細に示し、ここでは中央データメモリ(data memory:DM)はルータを表す八角形のリングで囲まれている。なお、図示した八角形形状は単なる記号表現であり、実際の形状は異なっていてよく、例えば矩形であってよい。図示したように、DMRを取り囲むのは、他のDMR及びPEへのデータパスを表す多数の双方向矢印である。これらの双方向データパスは、各端部における実際の双方向トランシーバを用いて実装でき、又は反対方向に配向された単方向パスのペアとして実装できる。
【0029】
図4のルータとデータメモリとの間の単方向矢印は、メモリとルータとの間の単方向データパスを表す。これらの矢印の近傍の小さな正方形はDMAエンジン、即ちDMからの読み出しをサポートするDMAリーダ(DMA reader:DMAR)及び/又はDMへのデータ書き込みをサポートするDMAライタ(DMA writer:DMAW)を表す。DMARエンジンは、典型的には読み出しデータをリンクから別のDMRに送信するためにバッファによって増大させるための、メモリのためのアドレス信号を生成する。同様にDMAWエンジンは、リンクから受信した書き込みデータをバッファによって増大させるための、メモリのためのアドレス信号を生成する。各DMAエンジンはPEより大幅に小さく、使用電力が少なく、従ってこれらDMAエンジンは、メモリのブロックの読み出し及び書き込みへの使用に関して魅力的である。DMAエンジンは、DMメモリスペース内の関連する構成レジスタへのPEによる書き込みによって構成できる。特定のアドレスへの書き込みによりDMAがトリガされ、上記増大が開始される。DMAが複数のアドレスのブロックを通しての増大を終了すると、無制限にルーピングを継続するよう構成されていない限り、DMAは停止する。
【0030】
ソフトウェアは、コンピュータ又は他のプログラム記憶式デバイスを動作させるために必要な命令(プログラムコードとも呼ばれる)の集合である。ソフトウェアはその使用目的に応じて分類される。エンドユーザ用のコンピュータを特定の使用目的(ワードプロセッシング、インターネットサーフィン、ビデオ又は携帯電話信号処理等)のために動作させるソフトウェアは、アプリケーションソフトウェアと呼ばれることがある。アプリケーションソフトウェアは、人間であるプログラマが書いたソースプログラム及びスクリプトを含み、様々な中間コンパイル形式、及びランタイムソフトウェアと呼ばれる最終的な形式を対象デバイス(PE、マイクロプロセッサ又はCPU)によって実行できる。ランタイムソフトウェアはエミュレータによって実行することもでき、このエミュレータとは、デバッグ(エラー排除)を目的として、対象デバイスの内部状態に関して実際の対象デバイスよりも高い可視性を提供するよう設計されたデバイスである。
【0031】
開発ソフトウェア(ソフトウェア開発ツールのグループ又はスイート)は、アプリケーションソフトウェアを生成するために使用されるソフトウェアである。基本的な開発ツールとしては、従来技術によるMPAベースのシステムのための例示的なソフトウェア設計及び開発フローを示す図5に示すように、コンパイラ、アセンブラ、リンカが挙げられる。ユーザがソースコードを例えばC又はC++といった高級プログラム言語で書くためのエディタもまた、基本的な開発ツールとみなしてよい。人間であるエンジニア又はプログラマは典型的にはプログラムを設計し、これを、図5の「完全な設計」と記された文書で表される、高級プログラム言語のソースコードに翻訳する。このソースコードはプログラムエディタによって生成できる。「言語のコンパイル/アセンブリ」と記されたブロックでは、コンパイラを用いてソースコードをモジュール単位のアドレス再配置可能なオブジェクトコードに翻訳し、続いてアセンブラを用いて、モジュール単位の機械コードを生成し、最後にリンカを用いて、プログラム全体の実行可能なバイナリイメージを生成する。図示したように、これらのステージのいずれにおいて、及びこれらのステージの間に、最適化を実施してもよい。「設計を処理してチッププログラミングファイルを生成する」と記された最適化を含む、このようなコンパイル、アセンブリ、リンク(バイナリイメージ作成)プロセスは、「メイクファイル」内に記憶されたオペレーティングシステムへの命令によって自動化できる。プログラムを試験するために、一般にはバイナリイメージを対象デバイスのメモリにロードし(これは図5において、「チッププログラミング情報」を「プロセッサICチップ」に対して準備して実装することとして表されている)、実行する(即ち「プログラムを実行する」)。他の一般的なソフトウェアツールとしては、(対象PEにからバイナリイメージをロード、開始、休止、ダンプ、ディスアセンブルするための)デバッガ、サイクル精度シミュレータがある。サイクル精度シミュレータは、プロセッサの内部状態に関する完全な可視性を提供するものの、これらの速度は対象ハードウェアと比べてはるかに、例えば数桁も遅い。
【0032】
多重プロセッサシステムに関して、単一プロセッサシステムと比べて重要な追加のステップが存在する。これは、特定の処理タスク又はモジュールを特定の物理リソースに割り振ることであり、上記物理リソースはPE、補助メモリ、PEとシステムI/Oポートとの間の通信リソースである。通信リソースは、ルータ、ルータ間のリンク、ルータとリンクとが交互に連なったパス、補助メモリ、補助メモリとルータ(又はリンク)との間に介在するDMAエンジンを含んでよい。なお、共有ローカルメモリの割り振りは、PE及び通信リソースの割り振りに影響を及ぼし得、またその逆もあり得るため、リソースの割り振りはメモリリソースへのデータ変数の割り振りを含んでよい。図5では、この追加のステップを「リソース割り振り」(これを「物理的設計」と呼ぶ場合もある)と記したブロックで表す。フローのリソース割り振り部分は、配置及びルーティングツールを利用してよく、これらはタスクをアレイ内の特定のPEに割り当て、IN内の特定のポート及び通信経路(パス)を選択するために使用できる。なお、システム全体の物理的設計は全てを一度に実施する必要はなく、特にソフトウェア定義試験機器を、ソフトウェア開発後のいずれの時点(システムの実行中を含む)において後から追加してよい。しかしながらこのようにすると、試験機器を追加できるかどうかは、アプリケーションソフトウェア及び目標の信号へのアクセスによって使用されないチップ上の利用可能なリソースに左右されることになる。アプリケーションソフトウェアが密に配置されるとアクセスがブロックされる場合があり、又はチップのセキュリティ用特徴部分を使用することによりアクセスを故意にブロックできる。
【0033】
設計の各部分は、ランタイムソフトウェアの通常の実行中に、制御下で動的に変更できるものであってよい。従来のマイクロプロセッサは、プログラム実行中のメモリ割り振り及び割り振り解除をサポートしている。INリソースに関して、通信経路を設定及び切断するための機械コード命令を比較的少ないデータ語に符号化してよく、このようにして、多数の経路のための命令を、PRのための補助メモリ内に容易に記憶できる。従ってPE上のランタイムプログラムタスクは、必要に応じて動的に通信できるように経路を設定及び切断でき、これには、通信リソースを使用しないインターバル中に、これらのリソースを他のPEが利用できるという副次的な便益がある。I/Oポートは、I/Oポートに動的に接続される通信経路に応じて動的に割り振ってよい。PEに対するタスクの割り振りもまた、PEの命令メモリを新規のタスクで上書きできるオーバレイ機構によって、ランタイム中に変更できる。
【0034】
MPAリソース割り振りがランタイム中に変化している場合、性能が向上する可能性はあるが、性能の低下又はデッドロック状態を防止できるように上記変化を調整する必要もある。従ってシステムの最適化は、時間次元と、空間におけるリソース次元とを含み得る。更にシステムの最適化は、例えばランタイムレイテンシ、遅延、電力放散、データ処理依存性等のシステムの制約に影響され得る。よって上記システムの最適化は、多次元最適化であってよい。
【0035】
図6は、従来技術による例示的なソフトウェア設計データフローを更に詳細に示す。図示したように、一般にサードパーティ製システム開発ツールを用いて、例えばC、C++等の標準的な高級プログラム言語でプログラムを生成し、これをコンパイル、アセンブル、リンクして画像(実行可能なバイナリイメージ)を生成する。また図示したように、コンパイルの結果を更に利用して、対象ハードウェアに対してソフトウェアを最適化して良い。より具体的には、タスク抽出、多次元最適化(上述)、リソース割り当て/割り振りを、システムの制約及び例えば図示したようにHyperX(商標)ハードウェア製品である対象ハードウェア製品に基づいて実施してよい。図示したように、このプロセスは本質的に反復可能である。ソフトウェア開発ツールのスイートは、HyperX(商標)アーキテクチャデバイス用に開発されており、HyperX(商標)統合ソフトウェア開発環境(Integrated Software Development Environment:ISDE)製品に含まれている。
【0036】
少数のプロセスしか伴わない場合、物理的設計(物理的位置に対するアプリケーションソフトウェアタスクの割り当て及び通信経路の具体的なルーティング)は比較的単純であり、手動で実施可能である。それでもなお、各プロセッサの作業負荷は経時的に劇的に変動し得、従ってスループットを最大化するために、何らかの形態の動的割り振りが望ましくなり得る。しかしながら、多数のPEを有するMPAに関して、物理的設計プロセスは、手動でこれを行うと面倒であり、またエラーが発生しやすい。これらの問題に対処するために、タスク(プログラムコードのブロック)及び通信要件(各経路のソース及び目的地)を定義してリソースを自動的にタスクに割り振る(配置及びルーティングする)ための、多重プロセッサシステム用のソフトウェア開発ツールが製造されている。設計が大型であり、又は多くの反復するタスクを含む場合、セルの階層として表現すると比較的扱いやすいものとなり得る。階層としての記述は、ランタイムにおいて必要となる全てのタスク及び全ての通信経路のリストへと平坦化しなければならない場合があり、ランタイムの後、配置及びルーティングツールを使用して物理的設計を完成できる。階層の更なる強化をサポートする代替設計フローは、増加する配置及びルーティングをサポートすることもできる。
【0037】
階層構造の設定可能なセルという着想は、ハードウェア記述言語(Hardware Description Language:HDL)の領域で既に使用されている。階層設定可能性は、Verilog及びVHDLといった一般に使用されているHDLに組み込まれている。しかしながらこれらの方法は、論理ゲートに実装され、かつ通常は多重プロセッサアレイに利用されない設計の生成を対象としている。主要な差異は、各ドメインで使用される計算のモデルである。HDLモデルでは、全ての計算リソースは一般に、同時に実行されるよう初期設定されているが、順次実行されるように指定することもできる。対照的に、多重プロセッサモデルは限られた数の並列計算ストリームを想定しており、上記ストリームはそれぞれ順次実行モデルの結果として生じる。
【0038】
これらのHDLは、例えば固有若しくは共有メモリ空間、固有若しくは共有同期リソース、又はプロセッサ特定機械命令のセットといった、多重プロセッサアレイの固有の特性の表現を有さない。対照的に、多重プロセッサのためのソフトウェア言語はこれらの特徴の表現を含む。
【0039】
ソフトウェア言語の分野では最近、機能設定可能性が利用されている。しかしながら従来技術のソフトウェアプログラム言語は、(固定セル及び再設定可能セル両方の)プログラミングの再使用可能性、並びに階層分解による設計の複雑性の管理をサポートしていない。例えばC++において「テンプレート」として知られている構造体は、ある機能を特定の使用のために特化できる。しかしながら、パラメータ化の範囲は、その引数のデータタイプに限定され、計算の並列実装において変化させることができない。
【0040】
図7は、従来技術による、デジタルデバイスを試験するための一般的な従来のテストベンチ及び試験設備を示す。図示したように、試験中のデバイス(DUT)は開発ボードの中央に位置し、上記開発ボードは、電力と、左側のパターン生成器(pattern generator:PG)からDUTへ、そしてDUTから右側の論理アナライザ(logic analizer:LA)への高速で密な信号接続とを供給する。PGはデジタルメモリを含み、このデジタルメモリはコンピュータからロードでき、別個のバーストで、又は無限に反復するパターンとして、DUTへの送信を実施できる。LAは、DUTから受信したデータ語を記憶するためのメモリを含む。LAは、データがデータ内に特定のパターン(トリガ信号)を有して提示されるまでデータを記憶しないようプログラムでき、従って、大半が目標のデータではない大量のデータを収集するのではなく、特定のイベント後に目標のデータを記憶する。PCは、PG、LAを制御して結果をマスストレージに収集するために使用される。
【0041】
より密なIC製作技術による、極めて大幅に複雑なICデバイスの出現により、図8に示すように、より多くのメモリICチップ及びより高速なコンピュータ接続を、マスメモリ及びマイクロプロセッサを含む開発ボードに設置する傾向が生まれている。これらの非DUT ICチップを使用して、開発ボードとPCとの間で、標準USB及びイーサネット(登録商標)接続を介して大量のデータを移動させることができる。
【0042】
なお、図8のDUTは、試験入力データを受け取るために割り振られたある程度のオンチップリソース(「試験入力用リソース(resources for test inputs)」)、並びに出力データの収集及び処理を精査するためのある程度のリソース(「試験出力用リソース(resources for test outputs)」)と共に示されている。DUTリソースの大半は、アプリケーションの機能に割り振られている(「アプリケーション用リソース(resources for application)」)。全体的な試験制御、試験プログラミング、試験データ分析、試験結果表示及びマスストレージのために別個のコンピュータを使用する。コンピュータ及びマイクロプロセッサはますます高速化されているため、多くの場合、従来のパターン生成器及び論理アナライザは多くの条件下で除去できる。
【0043】
プログラマ設定可能なICチップの一部を、プローブとして又は同一のチップの別の部分を試験若しくは特性決定するための機器として使用するという着想が、文献に記載されている。例えば設定可能ICチップの1つのカテゴリとして、フィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA)がある。FPGAは典型的には開発ソフトウェアを使用して構成され、この開発ソフトウェアはHDLのプログラマ入力を得て機能を定義し、これを構成「ビットストリーム」にコンパイルし、この構成ビットストリームは、FPGAチップを構成するために特定のFPGAチップへの入力となる。構成を試験するために、デジタル試験信号を投入し、構成ビットストリームに組み込まれたプログラマ定義プローブによって収集してよい。
【0044】
非特許文献1では、オンチップマルチプレクサを使用して、データを論理アナライザへストリーミングする目的で、FPGAチップのアプリケーション構成における複数の異なる場所からデータを収集する。
【0045】
「この文書は、動的FPGAプローブの組み合わせを提示しており、これはFPGA内の信号グループを、FFTベースベクタ信号分析ソフトウェアパッケージを有する少数の物理パッケージパッドによる測定のために論理アナライザへとルーティングできる。この組み合わせにより、FPGA内部のデジタル信号におけるタイムドメイン、周波数スペクトル、変調品質を同時に測定できる。またこの組み合わせにより、時間のかかるFPGAの再設計を行う必要なく、信号分析のための様々な内部ネットを迅速に選択できる。」
【0046】
非特許文献2では、「合成機器(synthetic instrument)」即ちSIをFPGAのために設計している。
【0047】
「これにより、標的であるデジタル信号処理(digital signal processing:DSP)ベースの機器の複数のタスクを実行できる。この文書のテーマはベクタ信号分析であり、これにより、時間依存性振幅及び位相が入力時間信号から抽出される。…
【0048】
…ベクタ信号アナライザは、変調プロセスの多数の品質測定を提示できる。これらは、変調器の歪み、位相ノイズ、クロックジッタ、I-Q不均衡、シンボル間干渉等の望ましくない属性の推定を含む。この場合SIは、DSP無線レシーバの全てのタスクを実行し、観察された変調信号パラメータと、理想的な変調信号のパラメータとの間の小さな変動を報告する、ソフトウェア無線(software-defined radio:SDR)となることを求められる。様々な品質測定(例えばエラーのサイズ)は、通信システムの性能限界を定量化及び精査するにあたって価値を有する。」
【0049】
これらは、プログラムタスク、プロセッサ、IN経路設定及びメッセージ受け渡しといったMPAの特徴を指定するための構造体を一般に含まない論理ゲート指向性のハードウェア記述言語HDLでほとんどの場合設計されるFPGAの実装形態である。
【0050】
多数の処理要素(PE)、補助メモリ(SM)、高帯域幅一次相互接続ネットワーク(PIN)からなる多重プロセッサ(MPA)コンピュータシステムに関して、試験、デバッグ及び性能特性決定を目的として、高帯域幅信号をMPシステムに、及びMPシステムから通信する必要がある。
【0051】
MPAシステムのうちのある程度又は全ては、1つ又は複数のVLSI ICチップ上に配置してよく、これにより、試験/デバッグを目的とした外部信号の投入又は内部信号の収集の精査はより困難となる。これは内部状態の制御可能性及び可視性を低下させる。コンピュータシミュレーションにより、全ての内部状態及び信号を示すことができる。しかしながら、極めて低いエラーレートの条件下で動作するシステムに関して、統計的に有効な特性決定を得るためには、何百万ものダミー情報及びノイズの試験パケットをシステムに通過させる必要があり、従ってコンピュータシミュレーションには時間がかかり過ぎる。必要とされているのは、ハードウェア及びソフトウェアが、最終システム目標速度(リアルタイム)に近い速度で動作する、運用システムの試験及び特性決定である。
【0052】
必要な最小テストベンチ能力は、アプリケーションハードウェア/ソフトウェアのクリティカルポイントに投入される信号及びノイズの生成、ハードウェア及びソフトウェアのクリティカルポイントからの信号及びノイズの収集、これらの信号と既知の良好な信号との比較、これらの信号の処理(特性決定のタイプに応じて、単純な処理又は複雑な方法での処理)、目的の内部信号を送出するためのソフト精査のサポート、並びにストリーム信号の投入である。
【0053】
従って、多重プロセッサシステムのリアルタイム分析及び制御のための改良された技術及びツールが望まれている。
【先行技術文献】
【特許文献】
【0054】
【特許文献1】米国特許第7415594号
【非特許文献】
【0055】
【非特許文献1】Ferguson,S.;“Vector signal analysis of digital baseband and IF signals within an FPGA,”IEEE Autotestcon 2005 Digest of Papers,pp.402-407,Orlando,FL,26-29Sept.2005
【非特許文献2】Lowdermilk,R.W.;Harris,F.J.;“Vector Signal Analyzer Implemented as a Synthetic Instrument,”Instrumentation and Measurement,IEEE Transactions on,vol.58,no.2,pp.281-290,Feb.2009
【発明の概要】
【課題を解決するための手段】
【0056】
試験中のデバイス(DUT)を試験するためのシステム及び方法の様々な実施形態を提示する。ここでDUTは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク(IN)とを含む多重プロセッサアレイ(MPA)を含む。アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するMPAは、試験中のデバイス(DUT)であるか、又は試験中のデバイス(DUT)に含まれる。
【0057】
一実施形態では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むよう修正してよく、これにより修正されたアプリケーションソフトウェアが生成される。修正されたアプリケーションソフトウェア中の試験用コードは、少なくとも1つの副次的送信命令文を含んでよい。アプリケーションソフトウェアは、多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で実行されるよう、及び/又は上記第1のハードウェアリソースを使用するよう構成してよく、ここで試験用コードは、第1のハードウェアリソースのうちの少なくとも1つ上で実行されるように構成してよく、またMPAの1つ又は複数の第2のハードウェアリソースを使用するよう構成され、ここで上記1つ又は複数の第2のハードウェアリソースは、第1のハードウェアリソースとは異なり、かつアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するMPAは試験中のデバイス(DUT)を備える。
【0058】
MPA上で実行される修正されたアプリケーションソフトウェアは、入力データを受信してDUTを刺激し、入力データに基づいてDUT内で第1のデータを生成し、第1の送信命令文を実行して、上記修正されたアプリケーションソフトウェアが使用するために第1のデータを提供し、少なくとも1つの副次的送信命令文を実行することにより、第2のハードウェアリソースのうちの少なくとも1つを用いて、第1のデータの少なくともサブセットを、MPAのエッジのピンに供給してよい。
【0059】
少なくとも1つの副次的送信命令文によって供給される第1のデータの上記少なくともサブセットを受信でき、この第1のデータの上記少なくともサブセットはDUTの分析に使用できる。
【0060】
いくつかの実施形態では、第1のデータの少なくともサブセットをMPAのエッジのピンに供給するにあたって、少なくとも1つの副次的送信命令文は、第1のデータの上記少なくともサブセットをMPAのエッジのピンに供給するように、MPAの第1のダイレクトメモリアクセス(DMA)エンジンをプログラムしてよく、ここで第1のDMAエンジンは、(アプリケーションソフトウェアの実行には使用されない)第2のハードウェアリソースのうちの1つである。アプリケーションソフトウェアは、MPAの第1のメモリに第1のデータを記憶するよう構成してよく、ここで第1のメモリは、アプリケーションソフトウェアが使用する第1のハードウェアリソースのうちの1つであり、第2のハードウェアリソースのうちの1つである第1のDMAエンジンを含む複数のDMAエンジンが第1のメモリに関連付けられている。一実施形態では、第2のDMAエンジンは第1のメモリに関連付けられていてよく、ここで第2のDMAエンジンは、第1のメモリに第1のデータを記憶するためにアプリケーションソフトウェアが使用する第1のハードウェアリソースのうちの1つである。いくつかの実施形態では、第1のデータの上記少なくともサブセットをMPAのエッジのピンに供給するにあたって、少なくとも1つの副次的送信命令文は第1のデータをフィルタリングしてよく、これによって第1のデータの上記少なくともサブセットを生成する。
【0061】
いくつかの実施形態では、第1の送信命令文は、第1のハードウェアリソースの第1のプロセッサ要素上で実行されるよう構成してよく、少なくとも1つの副次的送信命令文は、第1のハードウェアリソースの上記第1のプロセッサ要素上で実行されるよう構成してよい。DUTは、MPA上でリアルタイムに最高動作速度で実行される、上記修正されたアプリケーションソフトウェアを備えてよい。いくつかの実施形態では、DUTは、DUTに連結された外部信号ソースからリアルタイムデータを受信して、DUTを刺激できる。
【0062】
一実施形態では、アプリケーションソフトウェアの修正は、アプリケーションソフトウェア内に第1の送信命令文を配置するためにアプリケーションソフトウェアを分析すること、及びアプリケーションソフトウェア内の第1の送信命令文の近傍に少なくとも1つの副次的送信命令文を自動的に挿入することを含んでよい。また更なる実施形態では、アプリケーションソフトウェアの修正は、アプリケーションソフトウェア内に複数の送信命令文を配置するためにアプリケーションソフトウェアを分析すること、及びアプリケーションソフトウェア内の各上記送信命令文の近傍に、対応する1つ又は複数の副次的送信命令文を自動的に挿入することを含んでよい。あるいは又は更に、1つ又は複数の副次的送信命令文を、アプリケーションソフトウェア内の複数の送信命令文それぞれの近傍に、(ユーザが)手動で挿入してよい。
【0063】
第1のデータは、MPAのINを通る第1のデータパスを介して、修正されたアプリケーションソフトウェアが使用できるよう供給してよく、また第1のデータの上記少なくともサブセットは、MPAのINを通る第2のデータパスを介して、MPAのエッジのピンに供給してよく、ここで第2のデータパスは第1のデータパスとは異なる。
【0064】
いくつかの実施形態では、上述の技術を、ソフトウェア定義テストベンチによって実装又は実行してよく、上記ソフトウェア定義テストベンチは、DUT性能に対する影響が無視できる程度である状態でDUTを分析できるよう構成してよい。
【0065】
別の実施形態では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むよう修正してよく、これにより修正されたアプリケーションソフトウェアが生成され、ここで、修正されたアプリケーションソフトウェア中の試験用コードは、少なくとも1つの副次的送信命令文を含み、ここで試験用コードは、MPAの1つ又は複数の第2の異なるリソースを使用するよう構成され、ここで上記1つ又は複数の第2の異なるリソースはアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するMPAは試験中のデバイス(DUT)を備える。
【0066】
MPA上で実行される修正されたアプリケーションソフトウェアは、入力データを受信してDUTを刺激し、入力データに基づいてDUT内で第1のデータを生成し、第1の送信命令文を実行して、上記修正されたアプリケーションソフトウェアが使用するために第1のデータを提供し、副次的送信命令文を実行することにより、MPAの1つ又は複数の第2のリソースのうちの少なくとも1つを用いて、第1のデータをMPAのエッジのピンに供給してよい。
【0067】
副次的送信命令文によって供給される第1のデータを受信でき、この第1のデータはDUTの分析に使用できる。
【0068】
更なる実施形態では、アプリケーションソフトウェアを実行する多重プロセッサアレイ(MPA)を備える試験中のデバイス(DUT)を試験するための方法は、試験することが求められているアプリケーションソフトウェアを分析することを含んでよく、ここで上記アプリケーションソフトウェアは、多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で展開されるよう構成され、MPAは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク(IN)とを含む。本方法は更に、アプリケーションソフトウェアで生成されたデータを分析のために複製するためにMPA上にハードウェアリソースを構成するよう実行可能な試験プログラムコードを生成すること、及びアプリケーションソフトウェアをMPAの第1のハードウェアリソース上で展開することを含んでよく、ここでアプリケーションソフトウェアを実行するMPAは、試験中のデバイス(DUT)を備える。入力データを供給してDUTを刺激してよく、ここでDUTは、アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するMPAを備える。試験プログラムコードを実行することにより、アプリケーションソフトウェアの実行に使用されていないハードウェアリソースのうちの少なくとも1つを用いて、第1のデータの少なくともサブセットを、MPAのエッジのピンに供給してよく、ここで第1のデータは、アプリケーションソフトウェアが入力データに応答して実行する送信命令文に応答して生成される。試験プログラムコードを実行することによって得られた第1のデータの上記少なくともサブセットを受信でき、この第1のデータの上記少なくともサブセットはDUTの分析に使用できる。
【0069】
好ましい実施形態に関する以下の詳細な説明を、添付の図面と組み合わせて考慮すると、本発明の更なる理解を得ることができる。
【図面の簡単な説明】
【0070】
図1図1は、従来技術による例示的な開発システムを示す。
図2図2は、従来技術による例示的な多重プロセッサアレイ(MPA)システムを示す。
図3図3は、従来技術による例示的な多重プロセッサアレイ(MPA)システムを示す。
図4図4は、従来技術による例示的な多重プロセッサアレイ(MPA)システムを示す。
図5図5は、従来技術によるMPAのためのソフトウェア開発フローを示すフローチャートである。
図6図6は、従来技術によるMPAのためのソフトウェア開発フローを示すフローチャートである。
図7図7は、従来技術によるテストベンチ及び試験設備を示す。
図8図8は、従来技術によるテストベンチ及び試験設備を示す。
図9図9は、一実施形態による、アプリケーションソフトウェアを実行するMPAを含むDUTを試験するためのシステムを示す。
図10図10は、一実施形態によるソフトウェア定義テストベンチを示す。
図11図11は、一実施形態による、多重プロセッサシステムのためのソフトウェアを開発するための方法のフローチャートである。
図12図12は、一実施形態による、アプリケーションソフトウェア内の副次的送信命令文を使用する、DUTを試験するための方法のフローチャートである。
図13図13は、一実施形態による、アプリケーションソフトウェア外部の試験用コードを使用する、DUTを試験するための方法のフローチャートである。
図14図14は、一実施形態による、プローブが使用できるようにデータストリームを分割するためのDMAエンジンの使用を示す。
図15図15は、一実施形態による、サンプリングのためのFIFO制御を有するプローブが使用できるようにデータストリームを分割するためのDMAエンジンの使用を示す。
図16図16は、一実施形態による、ソフトウェアインストルメンテーションのために使用されるリソースを有する多重プロセッサアレイを示す。
図17図17は、一実施形態による、MPAのデータメモリ及びルータ(DMR)要素を示す。
図18図18は、ソフトウェア無線のある実施形態のハイレベルブロック図である。
図19図19は、ソフトウェア無線の別の実施形態のハイレベルブロック図である。
図20図20は、印加された加法性ホワイトガウスノイズ(additive white Gaussian noise:AWGN)を特定及び/又は指示するための、例示的なAWGNユーザインタフェースを示す。
図21図21は、一実施形態による例示的な信号空間ダイヤグラムを示す。
図22図22は、一実施形態による、様々なパラメータ又は属性を構成及び/又は表示できるビデオソースビュー(GUI)を示す。
【発明を実施するための形態】
【0071】
本発明は様々な修正及び代替形態を許容するものであるが、その具体的な実施形態を例として図面に示し、また本明細書で詳細に説明する。しかしながら、上記具体的実施形態の図及び詳細な説明は、本明細書に開示する特定の形態に本発明を限定することを意図したものではなく、反対に、添付の請求項によって定義されるような本発明の精神及び範囲内にある全ての修正例、均等物及び代替例を包含することを意図したものであることを理解されたい。
【0072】
参照による援用
以下の特許は、その全体を参照することにより、本明細書においてその全体が完全に論述されているかのように、本明細書に援用されるものとする:
米国仮特許出願第61/724493号(2012年9月9日出願、発明の名称「Real Time Analysis and Control for a Multiprocessor System」);
米国特許第7415594号(2003年6月24日出願、発明の名称「Processing System With Interspersed Stall Propagating Processors And Communication Elements」、発明者Michael B.Doerr、William H.Hallidy、David A.Gibson、Craig M.Chase);
米国特許出願第13/274138号(2011年10月14日出願、発明の名称「Disabling Communication in a Multiprocessor System」、発明者Michael B.Doerr、Carl S.Dobbs、Michael B.Solka、Michael R Trocino、David A.Gibson)。
【0073】
用語
以下は、本出願で使用する用語の解説である。
【0074】
メモリ媒体:いずれの様々な種類のメモリデバイス又はストレージデバイス。用語「メモリ媒体」は、インストール媒体(例えばCD-ROM、フロッピー(登録商標)ディスク104若しくはテープデバイス);コンピュータシステムメモリ若しくはDRAM、DDR RAM、SRAM、EDO RAM、ラムバスRAM等のランダムアクセスメモリ;又は磁気メディア(例えばハードドライブ)、光学ストレージ若しくはROM、EPROM、FLASH等の不揮発性メモリ等を含むことを意図している。メモリ媒体はその他のタイプのメモリ又はその組み合わせも同様に含んでよい。更に、メモリ媒体は、プログラムを実行する第1のコンピュータ内に配置してよく、及び/又はインターネット等のネットワークを介して第1のコンピュータに接続された第2の異なるコンピュータ内に配置してよい。後者の場合、第2のコンピュータは第1のコンピュータに、実行のためのプログラム命令を提供してよい。用語「メモリ媒体」は、異なる位置、例えばネットワークを介して接続された異なるコンピュータ内にあってよい2つ以上のメモリ媒体を含んでよい。
【0075】
キャリヤ媒体:上述のようなメモリ媒体、バスやネットワークといった物理的な伝送媒体、及び/又は電気信号若しくは光信号等の信号を搬送するその他の物理的な伝送媒体。
【0076】
プログラマブルハードウェア要素:これは、プログラム可能な又は結線接続された相互接続を介して接続された複数のプログラマブル機能ブロックを備える、様々なハードウェアデバイスを含む。例としては、FPGA(フィールド プログラマブルゲートアレイ)、PLD(プログラマブルロジックデバイス)、FPOA(フィールドプログラマブルオブジェクトアレイ)及びCPLD(複合PLD)が挙げられる。プログラマブル機能ブロックは、細粒度(例えば組み合わせ論理又はルックアップテーブル)から粗粒度(演算処理装置又はプロセッサコア)に及ぶ範囲のものであってよい。プログラマブルハードウェア要素は「再設定可能論理」と呼んでもよい。
【0077】
特定用途向け集積回路(Application Specific Integrated Circuit:ASIC):この用語は、その通常使用される意味全てを有することが意図されている。用語「ASIC」は、汎用プログラマブルデバイスではなく、特定の用途に対してカスタマイズされた集積回路を含むことを意図したものであるが、ASICは基本単位としてプログラム可能なプロセッサコアを含んでよい。携帯電話のセル、MP3プレイヤーのチップ、その他多数の単一機能ICがASICの例である。ASICは通常、Verilog又はVHDLといったハードウェア記述言語で記述される。
【0078】
プログラム:用語「プログラム」は、その通常の意味全体を含むことを意図したものである。用語「プログラム」は:1)メモリに記憶させることができ、プロセッサが実行可能なソフトウェアプログラム;又は2)プログラマブルハードウェア要素を構成するために使用可能なハードウェア構成プログラムを含む。
【0079】
ソフトウェアプログラム:用語「ソフトウェアプログラム」は、その通常の意味全体を含むことを意図したものであり、いずれのタイプのプログラム命令、コード、スクリプト及び/若しくはデータ又はこれらの組み合わせを含み、これらはメモリ媒体に記憶でき、プロセッサによって実行できる。例示的なソフトウェアプログラムは:例えばC、C++、PASCAL、FORTRAN、COBOL、JAVA(登録商標)、アセンブリ言語等の命令型又は手続き型言語であるテキストベースプログラム言語で書かれたプログラム;グラフィカルプログラム(グラフィカルプログラム言語で書かれたプログラム);アセンブリ言語プログラム;機械言語にコンパイルされたプログラム;及びその他のタイプの実行可能なプログラムを含む。ソフトウェアプログラムは、何らかの方法で連携した2つ以上のソフトウェアプログラムを含んでよい。
【0080】
ハードウェア構成プログラム:プログラマブルハードウェア要素又はASICをプログラム又は構成するために使用できるプログラム(例えばネットリスト又はビットファイル)。
【0081】
コンピュータシステム:パーソナルコンピュータシステム(PC)、メインフレームコンピュータシステム、ワークステーション、ネットワーク家電、インターネット家電、パーソナルデジタルアシスタント(PDA)、グリッドコンピューティングシステム若しくはその他のデバイス又はデバイスの組み合わせを含む、様々なタイプの計算又は処理システムのいずれか。一般に、用語「コンピュータシステム」は、メモリ媒体からの命令を実行する少なくとも1つのプロセッサを有するいずれのデバイス(又は複数のデバイスの組み合わせ)を包含するものとして広く定義できる。
【0082】
自動的に(automatically):その動作又は操作を直接指定又は実施するユーザ入力を必要とせずに、コンピュータシステムが実施する動作又は操作(例えばコンピュータシステムが実行するソフトウェア)について用いる。従って用語「自動的に」は、ユーザが手動で実施又は指定する操作(ここでユーザが操作を直接実施するために入力を提供する)と対照的なものである。自動処理は、ユーザが提供する入力によって開始される場合があるが、これに続く「自動的に」実施される動作は、ユーザが指定するものではなく、即ち「手動で」実施される(ユーザが各動作の実施を指定する)ものではない。例えばユーザが、各フィールドを選択し、(例えば情報をタイピングすることによって、チェックボックスを選択することによって、無線選択によって等で)情報を指定する入力を提供することによって、電子フォームを埋める場合、仮にコンピュータシステムがユーザの動作に応答して上記フォームを更新しなければならないとしても、これは上記フォームを手動で埋めたことになる。このようなフォームはコンピュータシステムによって自動で埋めることができ、この場合コンピュータシステム(例えばコンピュータシステム上で実行されるソフトウェア)は、フォームのフィールドを分析して、フィールドへの回答を指定するいずれのユーザ入力を必要とせずにフォームを埋める。上述のように、ユーザはフォームを自動で埋める動作を発動する場合はあるが、実際にフォームを埋める動作には関わらない(例えばユーザはフィールドへの回答を手動で指定せず、回答は自動的に完了する)。本明細書は、ユーザが行う動作に応答して自動的に実施される操作の様々な例を提供する。
【0083】
開発プロセス:ある方法論に基づく開発のためのライフサイクルを指す。広義には、設計、実装、確認、展開、保守を通してユーザの要件及び制約に対処する方法を指す。
【0084】
概説
これより、試験インストルメンテーションがデータ処理デバイス(特に多重処理デバイス)及びこれらに関連するソフトウェア開発システム内に構築される、リアルタイム分析及び制御(real time analysis and control:RTAC)のためのシステムの様々な実施形態について説明する。RTACは、データ処理デバイスが製品アプリケーションを最高速度で実行している間に、保護されていないデバイスのいずれの内部状態にアクセス(読み出し又は書き込み)し、データ処理デバイスが製品アプリケーションを実行している間に、デバイス内の保護されていないいずれの場所にデジタル信号ストリームを接続し、デジタル信号ストリームを様々な標準的方法(間引き、補間、フィルタリング、ノイズ付加、パターン又は閾値に対するトリガ、フーリエ変換等)で処理し、試験信号を生成して比較を行って信号を処理し、自律的に高速で動作し、ソフトウェア部品(「ビュー(view)」と呼ばれる)を用いて比較的容易に設定できるように構成できる。
【0085】
ここで開示するRTACアプローチは、再使用可能かつカスタム設定可能なモジュールを備える開発ソフトウェアを含み、自律的に動作でき、従ってソフトウェア開発コストを削減でき、また適合可能な処理デバイスを使用する製品におけるアプリケーションソフトウェアの品質を改善できる。
【0086】
なお、ここで開示する技術は、特定のアレイサイズのMPAに関して特に有益であり得る。例えば例示的な一実施形態では、MPAは3つ以上のPEを含んでよい。他の例示的実施形態では、MPAのサイズ(アレイ内のPE、補助メモリ、関連する通信リソースの数)は何らかの所定の数以上であってよく、様々な異なる実施形態において、この数は例えば4、8、16、24、32、64等の所望の値を有してよい。より一般には、特定の用途又は使用法に応じて、MPA内のPEの数はある特定の下限を有してよく、この下限は必要に応じていずれの複数の値となるよう指定できる。
【0087】
リアルタイム制御
いくつかの実施形態では、リアルタイム制御(Real-Time Control:RTC)の基本的な考え方は、リンカが、ランタイムソフトウェアが使用する変数及びパラメータの、SM内での絶対位置を含むテーブルを生成するというものである。このリンカテーブルは、アプリケーションソフトウェアの動作中に特定のアドレスに対して個々の値を「ピーク(peek)」及び「ポーク(poke)」するために、例えばシリアルバスである二次相互接続ネットワークと共に使用してよく、これ以外の点で二次相互接続ネットワークに干渉することはない。MPAがそのハードウェア内に、一次相互接続ネットワーク(PIN)とは独立したシリアルバス等の二次相互接続ネットワーク(SIN)を有する場合、無干渉とすることもできる。SINは典型的には、高帯域幅PINよりも大幅に低い帯域幅を有し、従ってSINはアプリケーションソフトウェアによって使用されない。
【0088】
例示的なSINは、米国特許出願第13/274138号(発明の名称「Disabling Communication in a Multiprocessor System」)に開示されており、この特許出願は既に参照により本出願に援用されている。
【0089】
一実施形態では、対話式ソフトウェア開発環境は、リンカテーブルを維持する様々なツールを提供してよく、RTCツール(これはRTACツールの一部であってよい)は、「書き込み(値、アドレス)」を複数のSINコマンドの組に自動的に翻訳し、これらコマンドをPCから開発システムボードへ、続いてDUTへと通信し、ここでこれらSINコマンドの実行は、特定のアドレスの変数/パラメータに特定の値を書き込む。
【0090】
同様に、変数又はパラメータの値を読み出すために、リンカテーブルを使用してその位置及びアドレス情報を得てよい。RTCツールを呼び出して、又は使用して、「読み出し(アドレス)」をSINコマンドに翻訳し、このSINコマンドを続いてDUTへと通信してよい。実行時、内部の値を読み出し、PCと通信してこれを戻して表示してよい。スクリプトを用いて多数の変数/パラメータを変更してよいが、アレイを扱うために汎用スクリプトを開発してよい。
【0091】
リアルタイム分析
いくつかの実施形態では、リアルタイム分析(real‐time analysis:RTA)ツール(これはRTACツールの一部であってよい)を提供してよく、これは、ワークステーション、即ち例えばPC/ラップトップコンピュータ又は他のいずれのタイプの所望のコンピュータであるホストコンピュータ上で実行される全体制御プログラムを含み、これは、試験中のデバイス(DUT)及び最終的な用途に適切であるクロック速度でMPA上で動作するそのプリケーションソフトウェアを動作させるソフトウェア定義テストベンチ(SDTB)を管理する(及びいくつかの実施形態ではその一部と考えることもできる)。
【0092】
図9 DUTを試験するための例示的なシステム
図9は、一実施形態による、アプリケーションソフトウェアを実行するMPAを含むDUTを試験するためのシステムを示す。図示したように、この例示的実施形態では、このシステムは、ホストコンピュータ、開発システムとDUTを試験するために構成されたテストベンチとを試験設備と共に含む開発ボード、そしてこの特定の場合においてはプロセッサIC(集積回路)、並びに例えば論理アナライザ又はオシロスコープ及び外部信号ソース(例えばビデオカメラ)といった機器を含む。いくつかの実施形態では、ホストコンピュータ、開発ボード及び上記機器は、本記述の実施形態を実装できるソフトウェア定義テストベンチを構成できる。
【0093】
ソフトウェア定義テストベンチ(SDTB)は、DUTを刺激してそこからデータを収集するために、例えば1つ若しくは複数の試験ベクタ及び/又は信号ストリームといった(少なくともいくつかの)入力データを提供するよう構成してよいが、いくつかの実施形態では、入力データは、図9に示すように、場合によっては開発ボードを介してDUTに連結された外部信号ソースからのリアルタイム信号(例えばデータ)を含んでよい。SDTBは、DUTと同等の速さとなるよう、またDUTの性能に無視できる程度の影響しか及ぼさないよう設計してよい。SDTBは、DUTに刺激及び応答試験ベクタを供給するよう構成してよく、その動作に関するデータを収集する。SDTBは、精査された信号をサブサンプリングしてPCのデータ処理要件を低減するよう構成してよく、いくつかの実施形態では、合成機器及び模擬的RFアナログチャネル障害を含むように拡張できる。
【0094】
図10は、一実施形態による、アプリケーションソフトウェアを実行するMPAを含むDUTを試験するための例示的システムのハイレベル図である。図示したように、このシステムは少なくとも、ホストコンピュータがここで開示する新規の技術の少なくとも一部分を実装している点で図7の従来技術のシステムとは異なる。より具体的には、ホストコンピュータは、ここで開示する新規の方法の実施形態を実施するために実行できるプログラム命令と共に構成され、例えば、アプリケーションソフトウェア及び/又は外部試験用コードを、実行中にアプリケーションソフトウェアが生成したデータの少なくともサブセットを複製する(及び場合によってはフィルタリング又はその他の処理を行う)ように構成し、例えば通常使用中に、即ち試験/デバッグ環境又はコンテキストの外で、アプリケーションソフトウェアによって使用されないMPAのハードウェアリソースをプログラミングすることによるデバッグ又は分析のために、データ(の少なくともサブセット)をMPAの境界に搬送する。この複製及び/又はフィルタリング若しくはその他の処理を施されたデータをここでは「副次的データ(auxiliary data)」又は「副次的ストリームデータ(auxiliary stream data)」と呼んでよい。なお、様々な実施形態では、フィルタリングはデータのサンプリングを含んでよく、従って副次的データの量はオリジナルデータよりも少なくすることができる。別の例示的実施形態では、フィルタリングは、例えばデータを平均してオリジナルデータに対応するより低解像度のデータを生成することによる、データの削減を含んでよい。他のいずれの種類のフィルタリング(処理)を必要に応じて使用してよい。
【0095】
例示的な革新的特徴
上述のRTAシステムのコンセプトの1つの有用な特徴は、アプリケーションの性能に対して影響を無視できる程度にしか、又は全く及ぼすことなく、DTU内の高帯域幅データフローを精査できる点である。これは、ソフトウェア開発ツールのために開発されたソフトウェアプローブが、DUTに対してコード及び実行サイクルをごくわずかにしか(典型的には1%未満しか)追加しないことによって可能となる。アプリケーションソフトウェアは典型的には、全ての利用可能なMPAリソースを消費するわけではなく、またデータのブロックを処理するために割り振られた時間全てを消費するわけではないため、サイクル、電力放散及び/又はメモリの使用が1%増大してもほとんど感知できない。
【0096】
ソフトウェアプローブは少なくとも2つの作業を実施してよい。即ち、ストリームからのデータのブロックの少なくとも一部分の読み出し(及び場合によってはフィルタリング又はその他の処理)を複製し、そのデータをMPA上の、他の目的で使用されないバッファに書き込む。いくつかの実施形態ではPEがこれを行ってよいが、ハードウェアDMAエンジンがはるかに効率的であり(電力の放散が小さく)、従って他の実施形態では、可能な全ての場合においてDMAエンジンを使用してよい。
【0097】
高帯域幅データストリームにアクセスすることによる主要な問題は、タップにより生成された全てのデータをどのように処理するかである。いくつかの実施形態では、これらのデータを可能な限り迅速にフィルタリング及びサブサンプリングしてよい。従って一実施形態では、副次的ストリームデータバッファ又はプローブストリームへのアクセスを有するMPA上の他の目的で使用されないPEを、データをフィルタリング及びダウンサンプリングして、得られたデータを並列ポートへ、そして更にホストコンピュータへ送信するようにプログラミングしてよい。場合によっては、データストリームをタップするDMAエンジンによってサブサンプリングを完全に達成してよい。
【0098】
同一の又は別の、他の目的で使用されないPEによって、RTAシステムをサポートするためにオンチップで必要な他の試験制御機能を提供してよい。これらは、試験刺激として又はチャネル障害のために使用するための、合成信号及びノイズの生成を含んでよい。
【0099】
いくつかの実施形態では、ホストコンピュータは、例えば直交振幅変調(quadrature amplitude modulation:QAM)である異なる変調に関する信号空間ダイヤグラムをサポートするソフトウェアを含んでよく、入力される刺激は制御されるため、ソフトウェアはビットエラーレート、パケットエラーレート等を蓄積できる。いくつかの実施形態では、ソフトウェアは、ベクタ信号分析のために、特定の理想的な信号を実際の信号と比較するよう構成してよい。
【0100】
いくつかの実施形態では、ホストコンピュータは、実験の進行中にその実験を適合させるか又はその他の方法で修正して、実験をより効率的なものとすることができる。例えば高い信号対ノイズ比(signal‐to‐noise ratio:SNR)から低いSNRへのSNRのスイープは、高いSNRに関して低いパケットカウントで始まり、より低いSNRに関してパケットカウントがより高く変化し、信頼度要件を維持できる。
【0101】
なお、システムは完全にソフトウェア内で動作するため、刺激を印加でき、その結果を、DUTがMPAチップ上で動作するのと同等に迅速に蓄積できる。MPAが製品設計値より早いクロックを供給されている場合、上記結果は設計目標の「リアルタイム」よりも早く蓄積できる。
【0102】
例示的実施形態及び実装形態
これより、ここで開示する技術の様々な例示的実施形態及び実装形態について説明する。しかしながら、説明される特定の実施形態及び技術は、本発明をいずれの特定の形態、機能又は外観に限定するものではないことに留意されたい。例えばこれらの実施形態のうちのいくつかについては、具体的な用語、構文又は要素を用いて説明するが、記載される用語、構文又は特定の要素は例示のみを目的としたものであり、考察されている実施形態をいずれの特定の名称、構文、形態、構造又は外観のセットに限定することを意図したものではない。
【0103】
図11 ソフトウェア開発のための方法のフローチャート
図11は、一実施形態による、多重プロセッサシステム用のソフトウェアを開発するための例示的な方法のフローチャートである。より具体的には、図9は、フローにおいてプローブを挿入できる例示的な場所を示す。上述のように、ここで開示する技術はツールによって実装でき、このツール自体は多数のツール又はモジュールを含んでよい。いくつかの実施形態では、このツールはISDEから又はISDE内で発動してよく、他の実施形態ではこのツールはスタンドアロン型ツールとして動作してよい。いくつかの実施形態では、このツールは呼び出し可能な機能及び/若しくは定義された構造のツールキットとして、又はソフトウェアスイートとして実装してよい。
【0104】
図11に示すように、本方法は図5のフローチャートと同様に、(例えば高級プログラム言語での)ソフトウェアアプリケーションの完全な設計、及び「言語のコンパイル/アセンブリ」の受容を含んでよく、ここではコンパイラを用いてソースコードをモジュール単位のアドレス再配置可能なオブジェクトコードに翻訳し、続いてアセンブラを用いて、モジュール単位の機械コードを生成し、最後にリンカを用いて、プログラム全体の実行可能なバイナリイメージを生成する。これらのステージのいずれにおいて、及びこれらのステージの間に、最適化を実施してもよい。上述のように、「設計を処理してチッププログラミングファイルを生成する」と記された最適化を含む、このようなコンパイル、アセンブリ、リンク(バイナリイメージ作成)プロセスは、「メイクファイル」内に記憶されたオペレーティングシステムへの命令によって自動化してよい。プログラムを試験するには、アプリケーションプログラムを対象ハードウェア上で実行する又は動作させるために、一般にはバイナリイメージを対象デバイスのメモリにロードする(これは図11において、「チッププログラミング情報」を準備して実装することとして表されている)。上で示したように、プログラムは対象ハードウェア上で実行され、本方法はワークステーション(ホストコンピュータ)との通信を含む。また図示したように、本方法はテストハーネスとの通信、結果として得られたデータの処理、ワークステーション(ホストコンピュータ)上での又はワークステーション(ホストコンピュータ)における結果の表示を含んでよいが、いくつかの実施形態ではこれに加えて又はこれの代わりに、結果を後で閲覧するために、例えばローカルに又はネットワークを介してストレージデバイスに記憶してよい。
【0105】
図11に更に示すように、1つ又は複数のプローブを本方法の様々なポイントのいずれに挿入してよい。例えば様々な実施形態では、1つ又は複数のプローブを、特にリソース割り振りの前、リンキングの後及び/又は実行中に挿入してよい。様々な実施形態ではプローブを自動的に挿入してよく、又は以下で議論するように、例えばユーザ(例えば開発者若しくは試験者)によって手動で挿入してよいことに留意されたい。
【0106】
いくつかの実施形態では、ツールはソフトウェア定義テストベンチを制御するよう構成された制御プログラムを含んでよい。ソフトウェア定義テストベンチは、試験中のデバイス(DUT)及びDUT上で実行されるアプリケーションソフトウェアをリアルタイムに試験するよう構成してよく、ここでDUTは、複数の処理要素と、補助メモリと、上記複数の処理要素と上記補助メモリとを通信可能に連結する高帯域幅相互接続ネットワーク(IN)とを含む多重プロセッサアレイ(MPA)を含む。ソフトウェア定義テストベンチはまた、例えば試験ベクタ及び/又は信号ストリームである入力データを供給して、DUTを刺激し、DUTの刺激によって得られたデータを受信するよう構成してよい。更に又はあるいは、DUTは、DUTに連結された外部信号又はデータソースから、入力データ、即ち例えばビデオカメラからのリアルタイム信号を受信するよう構成してよい。
【0107】
更にソフトウェア定義テストベンチは、DUTがアプリケーションソフトウェアを実行している間に、DUT及びアプリケーションソフトウェアをリアルタイムに最高動作速度で分析(例えば試験)するよう構成してよい。いくつかの実施形態では、ソフトウェア定義テストベンチは、DUT及びアプリケーションソフトウェアの性能に全く影響を及ぼすことなく、DUT及びアプリケーションソフトウェアを分析するよう構成してよく、他の実施形態では、DUT及びアプリケーションソフトウェアの性能に対する影響はゼロではないものの無視できる程度であってよく、即ちユーザが検出できないほど小さいか、アプリケーションの動作に測定可能な影響がないほど小さいか、又は以下でより詳細に議論するように何らかの特定された許容誤差内であってよい。一実施形態では、MPAは、MPAの第1の部分を用いてソフトウェアアプリケーション(又はアプリケーションソフトウェア)を実行するよう構成してよく、またツールは、MPAの第2の部分に対する1つ又は複数のソフトウェアプローブを自動的に構成するよう構成してよい。DUTがアプリケーションソフトウェアを実行している間に、DUT及びアプリケーションソフトウェアを最高動作速度で分析するために、1つ又は複数のソフトウェアプローブは、分析又は制御のために、実行中にソフトウェアアプリケーションに対してデータの読み書きを行うよう構成してよい。更なる詳細を以下で提供する。
【0108】
リアルタイムデバッグ
いくつかの実施形態では、リアルタイムデバッグは、アプリケーションランタイムソフトウェアを実行しているハードウェアDUTに「デバッグプローブ」を挿入することによって実装してよく、これにより内部信号を監視する。理想的には、デバッグプローブは完全に非侵襲性であり、即ちユーザのアプリケーションソフトウェアの動作に対して一切の影響を及ぼさない。いくつかの状況ではこれが成立し得るが、ほとんどの状況では、上記影響は無視できる程度のものとなり、いくつかの状況では、プローブの挿入に十分なリソースが存在しない場合があるか、又はプローブの挿入に対するセキュリティ障壁が存在する場合がある。なお、用語「無視できる程度の影響(negligible effects)」、「リアルタイム(real time)」は、特定の応用分野又は考慮される使用法に応じて異なる許容誤差レベルを示してよい。例えばいくつかの実施形態では、これらの用語は、試験がDUT及び/又はアプリケーションの性能に1%未満の影響を及ぼす状態で実施されることを意味してよい。同様に他の様々な例示的実施形態では、許容誤差は、例えば指定された要件に対して0.1%未満、0.5%未満、1%未満、2%未満、3%未満、4%未満、5%未満等であってよい。より一般には、様々な異なる実施形態において、許容誤差(即ち「無視できる程度の(negligible)及び「リアルタイムに最高動作速度で(real time at full operational speed)」の意味)は、いずれの所望の値となるように適宜指定してよい。
【0109】
例示的な一実施形態では、プローブは、例えばPE、アプリケーションソフトウェアが使用しない通信リソースといったMPAハードウェアファブリック上で実行されるタスクとして実装してよい。プローブは所望のデータを、開発ボード及びソフトウェア開発ツールのためのホストマシンとして機能する接続されたPCへ、又は論理アナライザ等のデバイスへ、チップ外に送出してよい。ホストマシン上では、データをファイル内に配置し、グラフィック表示し、及び/又はスピーカ若しくはビデオモニタ等の取り付けられたデバイスに送出してよい。またホストマシンはDUTに試験信号入力データを高速で供給してよく、これが直接行われない場合は、DUTに隣接するか又はDUT近傍のSDRAMに入力データファイルを転送することによって行われる。いくつかの試験に関して、入力データはDUT上で生成されるが、他の場合においては外部信号生成器を使用してよい。
【0110】
デジタル信号に関するプローブは、多数の異なる方法で実装してよい。いくつかの実施形態では、プローブはサンプリング部分、データ処理部分、チップ出力部分を含んでよい。いくつかの実施形態では、MPAはデータをホストマシンに送信するために、データをパケットとして形成又はフォーマットしてよく、他の実施形態では、MPAはこの目的のためにデータを別のチップに送信してよい。
【0111】
副次的送信
プローブのサンプリング部分を実装するための1つの例示的な方法は、PEタスク内において、対象の信号に関する第1の「送信」命令文を探し、第1の送信の後に第2の(副次的)送信命令文を挿入することであり、この第2の(副次的)送信命令文は同一の信号に対するものであるが、関連する通信経路がDMRを異なる方向から出るようにし、この経路を自由経路に沿ってチップI/Oポートへと配向するものである。これら送信命令文を両方とも含むタスクを再コンパイルし、アプリケーションソフトウェアの残りの部分とリンクさせて、試験及び分析のための単一のタップを有するバイナリイメージを生成してよい。続いて、送信タスクが対象の信号のデータのブロックを送信するたびに、これは同一のデータのブロックをプローブにも送信する。これは、プローブが非侵襲性であるという要件に完全には適合しない。というのは、送信タスクは第2の送信を実行しなければならず、これはタスクを実行するためのサイクルを追加するからである。しかしながら、第2の送信が、アプリケーションソフトウェアが使用していないハードウェアリソースを利用する場合、上述のコストを緩和できる。例えば第2の(副次的)送信命令文がDMAエンジンを使用する場合、PEはDMA制御レジスタの書き込みに対して数PEクロックサイクル分しか遅延しないものとなり得、そしてPEはアプリケーションタスクと共に継続できる。通常これらの追加のサイクルは、タスクに割り振られた時間に比べて無視できる程度のものである。別の例として、いくつかの実施形態では、第2の又は副次的送信命令文は、オンチップネットワークを利用して、プローブデータをMPAのエッジに供給してよい。
【0112】
図12は、例示的な一実施形態による、副次的送信命令文を用いて試験中のデバイス(DUT)を試験するための方法のハイレベルフローチャートである。DUTは多重プロセッサアレイ(MPA)を含んでおり、MPAの様々な実施形態は上述した通りである。図12に示す方法は、特にこれまでに図示したコンピュータシステム又はデバイスのいずれと組み合わせて使用してよい。図示した例示的実施形態では、本方法は、その一部をソフトウェア定義テストベンチによって、またその一部をMPA上で実行される(修正された)アプリケーションソフトウェアによって実行され、これは図12において「ソフトウェア定義テストベンチ100」及び「修正されたアプリケーションソフトウェア200」で示した通りである。
【0113】
様々な実施形態では、図示した方法要素のいくつかは、同時に若しくは図示したものと異なる順序で実施してよく、又は省略してよい。また必要に応じて追加の方法要素を実施してもよい。図示したように、この方法は以下のように動作できる。
【0114】
まず1202では、試験することが求められているアプリケーションソフトウェアを、例えばメモリ媒体に記憶してよい。アプリケーションソフトウェアは、MPAの第1のハードウェアリソース上で実行されるよう展開可能となり得る。MPAは上述のように、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する相互接続ネットワーク(IN)とを含んでよい。
【0115】
1204では、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むように修正して、修正されたアプリケーションソフトウェアを生成してよい。修正されたアプリケーションソフトウェア内の試験用コードは、少なくとも1つの副次的送信命令文を含んでよい。
【0116】
いくつかの実施形態では、試験用コードはアプリケーションソフトウェア内に自動的に含まれてよく、即ち例えばソフトウェア定義テストベンチによってアプリケーションソフトウェア内に含める操作を発動又は実施する直接的なユーザ入力なしに、含まれてよい。例えばアプリケーションソフトウェア内に第1の送信を配置するためにアプリケーションソフトウェアを分析してよく、アプリケーションソフトウェア内の第1の送信命令文の近傍に副次的送信命令文を自動的に挿入してよい。更にいくつかの実施形態では、アプリケーションソフトウェア内に複数の送信命令文を配置するためにアプリケーションソフトウェアを分析してよく、プリケーションソフトウェア内の上記複数の送信命令文それぞれの近傍に、対応する1つ又は複数の副次的送信命令文を自動的に挿入してよい。よって試験用コードは、複数の副次的送信命令文を含んでよい。なおいくつかの実施形態では、アプリケーションソフトウェア内のどの送信命令文が目標の送信命令文であるかをユーザが選択又は指示してよく、これに従って副次的送信を自動的に挿入してよい。換言すると、ユーザは、どの送信命令文(又は目標の信号/データ)を精査すべきかを指定してよく、本方法又はツールは、選択又は指示された送信命令文それぞれの近傍に、それぞれ1つ又は複数の副次的送信を自動的に挿入してよい。
【0117】
他の実施形態では、試験用コードはユーザによって手動でアプリケーション内に含めてよく、例えばユーザは試験用コードをアプリケーションソフトウェアに、例えばエディタを介して、又はソフトウェア定義テストベンチ以外のプロセスによって、挿入してよい。更なる実施形態では、自動技術と手動技術との様々な組み合わせを利用してよい。例えばツールは送信命令文を自動的に発見又は配置してよく、ユーザは目標の送信命令文を指示又は選択して、これに従って副次的送信命令文を手動で挿入してよい。他の実施形態では、ユーザは送信命令文の配置を手動で決定してよく、またどの送信命令文が目標のものであるかを決定してよく、副次的送信を手動又は自動で挿入してよい。
【0118】
1206では、修正されたアプリケーションソフトウェアをMPAのハードウェアリソース上で展開してよい。この展開は、MPAの第1のハードウェアリソースを使用するためにアプリケーションソフトウェアを展開すること、及び試験コードを、第1のハードウェアリソースのうちの少なくとも1つにおいて実行され、かつMPAの1つ又は複数の第2のハードウェアリソースを使用するよう構成されるようにするために展開することを含んでよく、ここで第2のハードウェアリソースは第1のハードウェアリソースとは異なり、またアプリケーションソフトウェアによって使用されることはない。修正されたアプリケーションソフトウェアをリアルタイムに最高動作速度で実行するMPAは、試験中のデバイス(DUT)を備えてよく、即ちDUTを含むか、DUTであるか、又はDUTに含まれていてよい。
【0119】
いくつかの実施形態では、修正されたアプリケーションソフトウェアをMPAの第1のハードウェアリソース上で、例えばソフトウェア定義テストベンチによって自動的に展開してよい。他の実施形態では、修正されたアプリケーションソフトウェアをMPAの第1のハードウェアリソース上で、何らかの他の作因によって、例えばユーザが手動で、又はソフトウェア定義テストベンチ以外のプロセスによって、展開してよい。
【0120】
1208では、修正されたアプリケーションソフトウェアが入力データを受信して、DUTを刺激してよい。いくつかの実施形態では、入力データのうちの少なくともいくつかは、ソフトウェア定義テストベンチによって、例えばホストコンピュータによって供給されて、DUTを刺激してよい。例えばソフトウェア定義テストベンチは、DUT/アプリケーションソフトウェアのための入力データのセットを含む試験ベクタを供給してよく、またいずれの所望のタイプ及び数のデータ又は信号を含んでよい。
【0121】
更に又はあるいは、いくつかの実施形態では、DUTは、例えば開発ボードを介してDUTに連結された外部信号(データ)ソースから入力データを受信してよい。一実施形態では、外部信号ソースは、DUTを刺激するためのリアルタイム及び/又は実環境データを供給してよい。換言すると、DUTは、DUTに連結された外部信号ソースからリアルタイムデータを受信して、DUTを刺激してよい。外部信号ソースの例としては特に:ビデオカメラ;ルータ、モデム、ハブ等のネットワークデバイス;センサ;その他のシステムが挙げられるがこれらに限定されない。なお様々な実施形態では、必要に応じていずれのタイプの外部信号ソースを使用してよい。
【0122】
MPAは修正されたアプリケーションソフトウェアをリアルタイムに最高動作速度で実行してよい。換言すると、DUT/MPA及びアプリケーションソフトウェアは試験中であるものの、修正されたアプリケーションソフトウェアを通常動作中と同等の速度(又は事実上同等の速度)で実行してよい。上述のように、修正されたアプリケーションソフトウェアを「リアルタイムに最高動作速度で」実行するとは、修正されたアプリケーションソフトウェアを実行する際のシステムの性能が、通常動作中(例えば試験又はデバッグ中でない場合)のシステムの性能の何らかの特定の許容誤差内、例えば所望又は必要に応じて0.1%未満、0.5%未満、1%未満、2%未満、4%未満、5%未満等であることを意味する。より一般には、これもまた上述のように、許容誤差は、いずれの所望の値となるように適宜指定してよく、これによっていずれの特定のアプリケーションに対して「リアルタイムに最高動作速度で」を定義する。従ってここで開示する技術を使用して、アプリケーションソフトウェアを実行するDUTの性能を含むシステム性能に対して無視できる程度の影響しかない状態で、DUTを分析できる。
【0123】
1210では、第1のデータを、入力データに基づいて、修正されたアプリケーションソフトウェアによってDUT内で生成してよい。換言すると、入力データに応答して、MPA上で実行される修正されたアプリケーションソフトウェアは第1のデータ(いくつかの実施形態では信号と見做される場合もある)を生成してよい。いくつかの実施形態では、生成された第1のデータを、第1のデータを計算するMPAの処理要素内の、又は上記処理要素に隣接したローカルメモリ、例えば隣接するDMRのレジスタ又はメモリに記憶させてよい。
【0124】
第1のDMAエンジンを利用して第1のデータの少なくともサブセットを供給するいくつかの実施形態では、上記生成は、MPAの第2のメモリに第1のデータを記憶させることを含み、ここで第1のメモリはアプリケーションソフトウェアが使用する第1のハードウェアリソースのうちの1つであり、また1つ又は複数の第2のハードウェアリソースのうちの1つである第1のDMAエンジンを含む複数のDMAエンジンが第1のメモリに関連付けられている。更に一実施形態では、第2のDMAエンジンもまた第1のメモリに関連付けられてよく、ここで第2のDMAエンジンは、アプリケーションソフトウェアが使用する第1のハードウェアリソースのうちの1つである。
【0125】
1212では、修正されたアプリケーションソフトウェアは第1の送信命令文を実行してよく、ここで第1の送信命令文は、修正されたアプリケーションソフトウェアが使用するための第1のデータを提供する。換言すると、修正されたアプリケーションソフトウェアは第1の送信命令文を実行して、修正されたアプリケーションソフトウェアの何らかの他の部分又は機能に対して第1のデータを供給してよい。第1の送信命令文は、MPAの第1のハードウェアリソースのうちの1つにおいて実行してよい。
【0126】
1214では、修正されたアプリケーションソフトウェアは第1のハードウェアリソースのうちの1つにおいて副次的送信命令文を実行し、第2のハードウェアリソースのうちの少なくとも1つを用いて、第1のデータの少なくともサブセットをMPAのエッジのピンに供給してよい。例えば一実施形態では、(第1のデータの少なくともサブセットをMPAのエッジのピンに供給するための)副次的送信命令文の実行は、第1のデータの少なくともサブセットをMPAのエッジのピンに供給するようにMPAの第1のダイレクトメモリアクセス(DMA)エンジンをプログラムしてよく、ここで第1のDMAエンジンは、アプリケーションソフトウェアが使用しないMPAの1つ又は複数の第2のハードウェアリソースのうちの1つである。(第1のハードウェアリソースから)第1のDMAエンジンへの第1のデータのデータ伝送のこのようなオフロードは、データ伝送性能によって、実行される(修正された)アプリケーションソフトウェアの動作性能が(上述のような特定の許容誤差を超えて)劣化するのを防止できる。従って副次的送信命令文は、第2のハードウェアリソースのうちの1つ、例えば第1のDMAエンジンによってアプリケーションソフトウェアをそっと「タップ」し、これによって分析を目的として第1のデータのコピーを生成するよう動作してよい。
【0127】
一実施形態では、第1のデータは、MPAのINを通る第1のデータパスを介して、修正されたアプリケーションソフトウェアが使用できるよう供給してよく、また第1のデータは、MPAのINを通る第2のデータパスを介して、MPAのエッジのピンに供給してよく、ここで第2のデータパスは第1のデータパスとは異なる。
【0128】
1216では、副次的送信命令文が提供した第1のデータを、例えばソフトウェア定義テストベンチ(例えばホストコンピュータ)が、例えばMPAのエッジのピンを介して受信してよい。受信された第1のデータは、DUTの動作を分析するために、例えばアプリケーションソフトウェアを試験及びデバッグするために使用できる。
【0129】
上述のように、いくつかの実施形態では、上述の方法の様々な要素をソフトウェア定義テストベンチによって実施してよい。例えば例示的な一実施形態では、上述の修正及び受信をソフトウェア定義テストベンチが実施してよく、ここでソフトウェア定義テストベンチは、DUTの性能に対する影響が無視できる程度である状態で、DUTを試験する。
【0130】
上述の方法の重要な側面を若干異なる方法で説明すると、いくつかの実施形態では、メモリ媒体は、多重プロセッサアレイ(MPA)の第1のリソース上で展開されるよう、及び/又は上記第1のリソースを使用するよう構成されたアプリケーションソフトウェアを記憶してよく、ここでMPAは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク(IN)とを含む。メモリ媒体は、試験することが求められているアプリケーションソフトウェアを、試験用コードを含むように修正して、修正されたアプリケーションソフトウェアを生成するためにプロセッサが実行できる、プログラム命令を更に含んでよく、ここで修正されたアプリケーションソフトウェア内の試験用コードは、少なくとも1つの副次的送信命令文を含む。上述のように、試験用コードは、MPAの1つ又は複数の第2の異なるリソースを使用するよう構成してよく、ここで上記1つ又は複数の第2の異なるリソースはアプリケーションソフトウェアによって使用されず、またアプリケーションソフトウェアを実行するMPAは試験中のデバイス(DUT)を備える。
【0131】
MPA上で実行される修正されたアプリケーションソフトウェアは:入力データを受信してDUTを刺激し;入力データに基づいてDUT内で第1のデータを生成し;第1の送信命令文を実行して、修正されたアプリケーションソフトウェアが使用するための第1のデータを提供し;副次的送信命令文を実行して、第1のデータをMPAのエッジのピンに供給するようにMPAのダイレクトメモリアクセス(DMA)エンジンをプログラムするように構成してよく、ここでDMAエンジンは、MPAの1つ又は複数の第2のリソースのうちの1つである。プログラム命令は更に、DMAエンジンから得られる第1のデータを受信するために実行可能であってよく、ここで第1のデータはDUTを試験するために使用できる。
【0132】
上述の技術をアプリケーションソフトウェアの観点から考えると、メモリ媒体は、多重プロセッサアレイ(MPA)で実行可能なプログラム命令を記憶してよく、このプログラム命令はアプリケーションソフトウェアと、アプリケーションソフトウェアに挿入された試験用コードを含む。プログラム命令は:入力データを受信し;入力データに基づいて第1のデータを生成し;アプリケーションソフトウェアにおいて第1の送信命令文を実行して、アプリケーションソフトウェアが使用するための第1のデータを提供し;アプリケーションソフトウェアに挿入された試験用コードからの少なくとも1つの副次的送信命令文を実行して、第1のデータをMPAのエッジのピンに供給するようにMPAのダイレクトメモリアクセス(DMA)エンジンをプログラムするように、実行可能であってよい。これもまた上述のように、第1のDMAエンジンは、アプリケーションソフトウェアが使用しないMPAのハードウェアリソースであってよい。第1のデータはDUTを分析するために使用できる。
【0133】
上述の方法の実施形態は、アプリケーションソフトウェアに挿入された副次的送信命令文を利用して、MPA上の、他の目的で使用されない又はアイドル状態のDMAエンジンをプログラムし、実行されているアプリケーションソフトウェアから目標のデータ(又は信号)を抽出し、これを、システムの性能に有意な影響を与えることなく、MPAのエッジに供給する。このようなデータ又は信号を複製及び抽出するための他の技術も考えられ、これらを以下に説明する。
【0134】
外部試験用コード
図13は、例えば図12の副次的送信命令文の使用とは対照的に、MPAから目標のデータ又は信号を複製及び抽出するために、アプリケーションソフトウェアの外部の試験用コード(試験プログラムコードとも呼ばれる)を使用する、DUTを試験するための例示的な一実施形態による方法のハイレベルフローチャートである。図12の方法と同様に、DUTは多重プロセッサアレイ(MPA)を含んでおり、MPAの様々な実施形態は上述した通りである。図12に示す方法は、特にこれまでに図示したコンピュータシステム又はデバイスのいずれと組み合わせて使用してよい。様々な実施形態では、図示した方法要素は、同時に若しくは図示したものと異なる順序で実施してよく、又は省略してよい。また必要に応じて追加の方法要素を実施してもよい。図示したように、この方法は以下のように動作できる。
【0135】
まず1302では、試験することが求められているアプリケーションソフトウェアを分析してよい。アプリケーションソフトウェアは、多重プロセッサアレイ(MPA)の第1のハードウェアリソース上で展開されるよう構成してよい。図12の方法と同様に、MPAは、複数の処理要素と、複数のメモリと、上記複数の処理要素と上記複数のメモリとを通信可能に連結する高帯域幅相互接続ネットワーク(IN)とを含む。例えば一実施形態では、ソフトウェア定義テストベンチはアプリケーションソフトウェアを自動的に分析して、目標のデータ又は信号が生成される場所及び/又は時点を決定してよい。
【0136】
1304では、試験プログラムコードを生成してよく、これは、分析(例えば試験)を目的としてアプリケーションソフトウェア内に生成されたデータの少なくともサブセットを複製するようMPA上のハードウェアリソースを構成するために実行可能である。いくつかの実施形態では、試験プログラムコードの生成は自動であってよく、例えばコードを指定する直接的なユーザ入力なしに、ソフトウェア定義テストベンチによって実施してよい。他の実施形態では、ユーザは、例えばソフトウェア定義テストベンチのエディタ又はプログラム開発環境を介して、試験プログラムコードの少なくとも一部分を生成してよい。
【0137】
1306では、アプリケーションソフトウェアをMPAの第1のハードウェアリソース上で展開してよく、ここでアプリケーションソフトウェアを実行するMPAは試験中のデバイス(DUT)を備える。
【0138】
1308では、入力データを供給してDUTを刺激してよい。DUTは上述のように、アプリケーションソフトウェアをリアルタイムに最高動作速度で実行するMPAを備えてよい。上述の方法と同様に、いくつかの実施形態では、DUTは、DUTに連結された外部信号ソースからリアルタイムデータを例えば入力データとして受信して、DUTを刺激してよい。
【0139】
1310では、試験プログラムコードを実行して、アプリケーションソフトウェアの実行に使用されていないハードウェアを用いてMPAのエッジのピンに第1のデータの少なくともサブセットを供給してよい。第1のデータは、試験ベクタに応答してアプリケーションソフトウェアが実行した送信命令文に応答して生成してよい(又は生成されたものである)。いくつかの実施形態では、(第1のデータの少なくともサブセットをMPAのエッジのピンに供給するための)試験プログラムコードの実行は、第1のデータの少なくともサブセットをMPAのエッジのピンに供給するようにMPAの第1のダイレクトメモリアクセス(DMA)エンジンをプログラムしてよく、第1のDMAエンジンは、アプリケーションソフトウェアの実行に使用されていないMPAのハードウェアリソースであってよい。換言すると、実行中、アプリケーションソフトウェアは、入力データに応答して第1のデータを生成する送信命令文を実行してよく、その後試験プログラムを実行してよく、これは、第1のデータの少なくともサブセットのコピーをMPAのエッジのピンに伝送するように、DUTのDMAエンジンをプログラムする。
【0140】
上述のように様々な実施形態では、本方法は第1のデータのフィルタリング又はそれ以外の処理を含んでよい。例えば試験プログラムコード又は上記試験プログラムコードによってプログラム若しくは制御される(第2のハードウェアリソースの)ハードウェアリソースは、第1のデータ又はそのサブセットをフィルタリングしてよい。このフィルタリングはデータのサンプリングを含んでよく、従って副次的データの量はオリジナル(第1の)データよりも少なくすることができる。別の例示的実施形態では、フィルタリングは、例えばデータを平均してオリジナルデータに対応するより低解像度のデータを生成することによる、データの削減を含んでよい。平滑化、異常値の除去等を含む他のいずれの種類のフィルタリング(処理)を必要に応じて使用してよい。
【0141】
1312では、試験プログラムコードの実行によって得られた第1のデータの上記少なくともサブセットを、例えばソフトウェア定義テストベンチが受信してよい。第1のデータの上記少なくともサブセットは、DUTを分析するために使用できる。MPA及びDUTの様々な実施形態は、既に詳細に説明した通りである。
【0142】
いくつかの実施形態では、試験プログラムコードは、アプリケーションソフトウェアの実行に使用されないMPAの処理要素、例えば第1のデータが記憶されているメモリの近隣の処理要素上で実行してよい。他の実施形態では、試験プログラムコードは、MPAから分離した別個のコンピュータシステム、即ち外部コンピュータシステム上で実行してよい。上述のようにいくつかの実施形態では、試験プログラムコードは更に、データをフィルタリングするか、又は例えばサンプリング、削減といった他の処理を必要に応じて行うよう動作してよい。
【0143】
一実施形態では、試験プログラムコードは、第1のデータの上記少なくともサブセットを提供するために、MPA内のシリアルバス(又はその他の二次相互接続ネットワーク(SIN))を介してコマンドを提供してよい。例えば、上述のように第1のDMAを利用する実施形態では、第1のDMAエンジンは、MPAのシリアルバス(又はその他の二次相互接続ネットワーク(SIN))を介して、外部試験プログラムコード(又は試験用コード)によってプログラムしてよい。
【0144】
送信命令文によって生成された第1のデータは、MPAのINを通る第1のデータパスを介して、アプリケーションソフトウェアが使用できるよう供給してよく、また第1のデータの上記少なくともサブセットは、MPAのINを通る第2のデータパスを介して、例えばDMAエンジンによって、MPAのエッジのピンに供給してよく、ここで第2のデータパスは第1のデータパスとは異なる。
【0145】
いくつかの実施形態では、1302の分析及び1312の受信はソフトウェア定義テストベンチによって実施してよく、ここでソフトウェア定義テストベンチは、DUTの性能に対する影響が無視できる程度である状態でDUTを試験する。
【0146】
よって様々な実施形態では、ソフトウェア定義テストベンチ及びアプリケーションソフトウェアは連動して動作して、DUTがアプリケーションソフトウェアをリアルタイムに最高動作速度で実行している間に、(アプリケーションソフトウェアを含む)DUTを分析してよい。
【0147】
副次的(若しくは第2の)送信コマンド又は外部試験用コードがDMAエンジンを用いてデータ伝送を実行する場合、SM内のバッファからINを介してチップI/Oポートにデータのブロックを移動させるよう構成できる経路を設定してよい。データ伝送の初めのいくつかの語は、経路を設定するためのヘッダ情報であってよい。図14は例示的なシステムを示し、このシステムは、「DMAエンジン1」と記された第1のDMAエンジンにデータを送出し、第1のDMAエンジンはこのデータをメモリに伝送し、その後DMAエンジン2が(オリジナル)データを指定された標的に送出し、DMAエンジン3がこのデータのコピー、即ちここでは「プローブデータ」と呼ばれる副次的データを、例えば分析のために送出する。
【0148】
更にいくつかの実施形態では、データは、自由なDMRにおいてバッファリングすることにより、チップI/Oポートへの途上で処理してよく、ここで用語「自由な(free)」は、「アプリケーションソフトウェアを実行する必要がない」ことを意味する。自由なDMRの近傍の自由なPEは、このデータを処理(間引き又は圧縮等)するようプログラムしてよい。別の通信経路を設定して、データをチップI/Oポートへ、そしてホストマシンへ案内してよい。
【0149】
レジスタのポーリング
目標のデータ又は信号を複製/抽出するための、より侵襲性が低いがより複雑である別の方法は、近隣のPEを利用して、特定のDMA伝送と関連する複数のレジスタのセットをポーリングする。上記近隣のPEが伝送の開始を検出すると、上記PEは同一のデータを読み出してこれをチップから送出できる。これは非侵襲性の方法で実施できる。というのは、上記近隣のPEが最低の優先度を有し、従って上記アプリケーションソフトウェアの動作に一切干渉しないように、DMAレジスタ上に優先度を設定できるためである。従って、データを送信している間に、DMAエンジンの背後でプローブはゆっくりと継続されてよく、また時折、上記エンジンによって、又は同一のDMRにアクセスしているアプリケーション内の他の近隣のPEによって機能停止し得る。これにより、DMAエンジンが終了しアプリケーションの送信PEに通知を行ってから数サイクル後に、上記近隣のPEによるデータの読み出しを終了させる。その短いタイムウィンドウの間に、送信PEはデータの修正を始めることができる。しかしながら、DMA伝送のバースト間に比較的長いインターバルを有するのがより一般的であり、従って有効でないデータを読み出してしまう蓋然性は小さい。
【0150】
DMA‐FIFOの使用
更に非侵襲性のプローブを、いくつかのMPAが提供するオンボードDMA‐FIFO機能、例えばhx3100B HyperX[MPA]プロセッサチップのDMA‐FIFO能力を用いて実装してよい。このアプローチでは、図15に示すように、3つのDMAエンジンを先入れ先出し(first‐in first‐out:FIFO)制御ブロックに連結し、データのストリームを一次又はオリジナルデータストリームと、精査された又は副次的データストリームとに分割してよい。
【0151】
図示したように、この例示的実施形態では、データはDMAエンジン1を介してメモリへと送出され、DMAエンジン2はこのデータをメモリから指定された標的へと送出し、DMA3エンジンはプローブデータ、即ち副次的データを、例えば分析のために送出する。しかしながら、図14のアプローチとは対照的にこの実施形態では、FIFO制御要素又は構成部品は3つのDMAエンジン全ての間に介在し、これによってDMAエンジンの動作を調整して、データの損失又はデータの複製を防止できることに留意されたい。データフロー制御は期間中ずっと継続させてよく、従ってこれにより「ダブルバッファリング」という公知の技術が必要なくなる。
【0152】
プローブがアプリケーションと同時にMPAリソース(物理的設計)に割り振られた場合、これはアプリケーションの物理的レイアウトを混乱させ得、これによって異なる挙動がもたらされる場合があることに留意されたい。この異なる挙動は、2つの異なる様式で発生し得る。
【0153】
プローブが第1のタイプのものである場合(即ち挿入されたデバッグ送信を監視する場合)、追加のルーティングリソースにより、アプリケーション設計が、設計の性能を変化させ得る、そして最悪の場合には異なる挙動を引き起こし得る、異なるルートのセットを有してしまうことがある。第2に、プローブがDMAレジスタにアクセスすることによってDMA伝送を直接監視している場合、適切なDMAに物理的に隣接する必要があり得る。これはアプリケーション設計のレイアウトを混乱させ得る。最良の場合、プローブが使用するプロセッサは、アプリケーション設計に元々占有されていなかったものである。しかしながらこの場合でさえ、プローブは、他のDMRメモリのいずれかにアクセスした場合にアプリケーション設計を変化させてしまう場合があり、異なるパターンのローカルメモリ競合が引き起こされる。これは、これらDMRに対する優先度を変化させて、プローブが常に最低の優先度を有するようにすることによって対処できる。しかしながらこのように対処した場合でさえ、プローブはそのデータをチップから送信することを必要とし、従ってルーティングリソースを使用する必要があり、この場合もアプリケーション設計を潜在的に混乱させる。
【0154】
しかしながら以下で議論するように、プローブをオリジナル設計開発の後に挿入した場合には、設計の混乱に関するこれらの問題は全て回避できることに留意されたい。
【0155】
上述のルーティングの影響を回避するための1つの方法は、プローブを追加する前にアプリケーションルーティングをロックし(「フリーズさせ」)、プローブのルーティングに、未使用のルーティング区間を通過させるだけである。アプリケーション設計後にMPAに残るリソースに応じて、これは可能であったり不可能であったりする。
【0156】
MPAの例示的なDMR
図17は、一実施形態によるMPAのDMRの例示的実施形態を示す。上述のように、MPA内のDMRは、MPAの隣接する処理要素のためのローカルメモリ及びルーティングリソースを提供し、また実行中のアプリケーションソフトウェアへのデータ書き込み、上記アプリケーションソフトウェアからのデータ読み出し、上記アプリケーションソフトウェア内でのデータ読み出し及び書き込みのためのDMAエンジンを実装してよい。例えば図17の例示的なDMRは4ペアのDMRエンジンを含み、各ペアは、DMRの中央に示したデータメモリからデータを読み出すためのDMA読み出しエンジンと、上記データメモリにデータを書き込むためのDMA書き込みエンジンとを含み、各DMAエンジンは、「DMAW Engine」(DMA書き込みエンジン)、「DMAR Engine」(DMA 読み出しエンジン)と記されているDMR内の最も右側の2つの正方形が示すように、図面ではそれぞれ正方形で表されており、ここでDMA書き込みエンジンはデータ(図におけるWData)をデータメモリに書き込むよう動作し、DMA読み出しエンジンはデータ(図におけるRData)をデータメモリから読み出すよう動作する。
【0157】
上述のように、これらDMAエンジンのうちのいくつかを、実行中のアプリケーションソフトウェアが例えば上述の「第1のリソース」の一部として利用して、アプリケーションソフトウェアが使用できるようにデータの読み書きを行ってよく、その一方で他のDMAエンジンを、試験又はデバッグ用の試験用プログラムコードが例えば上述の「第2のリソース」の一部として使用してよい。
【0158】
図17に示すように、この例示的実施形態では、DMRの最も左のDMA読み出しエンジンは、本技術の実施形態に従ってプログラムされる。より具体的には、このDMA読み出しエンジンは、オリジナル(修正されていない)アプリケーションソフトウェアとは分離した別個の試験用コード、例えば副次的送信命令文又は外部試験用コードによってプログラムされる。従ってDMA読み出しエンジンは、データを複製して場合によってはフィルタリングし、(上述のように)(場合によってはフィルタリングされた)複製データをMPAのエッジのピンに送信するよう動作し、このリソースはMPAの「第2のリソース」のうちの1つであるため、その動作はシステム性能を犠牲にしない(何らかの特定の許容誤差範囲内である)。
【0159】
アプリケーション設計ポストリンクデバッグ精査
試験中のアプリケーションからソフトウェア通信プローブを連結解除すると有益であり得る。これを行う1つの動機は、アプリケーションのソースコードが利用可能ではなく、従って含まれている通信プローブによって再リンク(再構築)できないことである。しかしながらはるかに重要なことは、修正が、それがどれほど小さなものであろうと(即ちプローブ)アプリケーションに導入されることがないように、試験中のアプリケーションの完全な整合性を維持することである。これはまた、含まれているプローブを用いてアプリケーションを再構築(再リンク)する必要を省く(防ぐ)。
【0160】
HyperX(商標)デバイスにより、PEとDMRとの完全に独立した制御が可能となる。このような柔軟性により、ユーザは、ロードされた追加のPEが既に動作しているアプリケーションのPE及び関連するDMRメモリ空間を上書きしない限りにおいて、既にHyperXデバイス上で動作していてよいアプリケーションを中断させることなく、実行コードを用いて追加のPEをプログラム及び実行できる。これにより本質的に、複数のバイナリイメージを、これらのリソース利用が相互排他的である(即ちPE、DMRメモリ、ルーティングファブリック)限りにおいて、同時に(並列に)実行できる。異なるバイナリ(アプリケーション)のロード及び実行は、異なる時点で行うことができる。これらはSINを介してロードしてよく、SINは、1つ又は複数のアプリケーションが使用するPINルーティングファブリックとは完全に独立である。
【0161】
異なるバイナリイメージを異なる時点でロード及び実行でき、そしてこれらを同時に実行できるという柔軟性は、試験中のアプリケーションをプローブのバイナリイメージから連結解除して、試験中のアプリケーションからデータを抽出するのに役立つ。通信経路に接続されるプローブを生成するために、試験PEを、ソースDMRへのアクセスを有するよう、センダPEの隣に割り振ってよい。例えば図16に示す例示的実施形態では、アプリケーションソフトウェアは、MPAの中央のフリーハンドのループ内に包含されるリソースを使用し、これはループ内に、第1のPEの上のタスク71から第2のPE上のタスク72への経路を有する。Xと記されたDMRは、非アプリケーションPE上のタスク81からアクセス可能である。この試験PEは、DMR Xから出力ポートへ、又は処理用の別のPEへの経路を設定できる。
【0162】
この試験PEは、(試験中のアプリからの)オリジナルデータ送信伝送のDMA(状態)レジスタを連続的にポーリングするようプログラムしてよい。PEの試験/ポーリングによってDMAの状態が非アクティブ状態からアクティブ状態へと変化したことが検出される場合は常に、試験PEはオリジナルDMAレジスタ値(即ちTOTAL、WAIT、STRIDE)を複製して、同一のDMAレジスタ値で(同一のDMRの)別のDMAをプログラムしてよい。これは、プローブとして使用されることになる副次的DMA送信伝送を生成できる。試験中のアプリケーションは、プローブDMA伝送の確立によって停止、修正する必要はなく、また何ら影響を受けることはない。
【0163】
トリガ
論理アナライザ(LA)等の試験機器は、多数のバイナリデジタル信号をサンプリングしてこれらを高速メモリに記憶させることにより、デジタル信号をキャプチャする。その後、メモリのコンテンツを、バイナリ信号のセットとして、又は何らかの等価の数値としてスクリーン上に表示してよい。論理アナライザ(LA)のタイムベースは、トリがイベントにおいてストレージアドレスの一括処理を開始する。トリがイベントは、一次信号のサブセット内のバイナリ信号の、及び試験中のデバイス又はDUTに信号を供給するデジタルパターン生成器からの他のバイナリ信号の、特定のパターンであってよい。
【0164】
デバッグ用プローブの挿入
デバッグ用プローブを用いて、ユーザ設計の内部である信号を監視する(既に詳細に説明されている)。The MathWorks,Inc.が提供するSimulink(商標)は、デバッグ目的で使用される多数のブロックを提供する。特に内部信号のサンプリングのために複数のブロックが存在する。いくつかの実施形態では、これらの内蔵型Simulinkブロックを、HyperXハードウェア上で実現されることになる設計にデバッグ用プローブを挿入するために使用してよい。このようなブロックは、例えばC-コードを用いて翻訳でき、これによってデータのキャプチャ及びチップ外への送信を実装できる。トランスレータはまた、信号をホストマシンへルーティングしてこのデータを適切な様式で表示するために必要なインフラストラクチャを設定できる。
【0165】
デバッグ用プローブの多重化
デバッグに必要なプローブの数は、MPA上で利用可能なデータポートの数より多くなる場合が多い。これらの場合、データプローブは(帯域幅要件を低減するために必要である場合は)サブサンプリングしてよく、続いて複数のプローブからのデータパケットを統合して1つのデータストリームを形成してよく、このデータストリームはチップ上の単一のI/Oポートを使用できる。
【0166】
なお、信号を多重化する際、データの識別をホストマシンに通信してよい。これは多数の方法のいずれによって達成してよい。例えば、第1のパケットが第1のプローブに対応し、第2のパケットが第2のプローブに対応し、第3のパケットが第1のプローブに対応し、第4のパケットが第2のプローブに対応し…のようになるように、プローブデータパケットを、厳密に反復される順序で送信してよい。
【0167】
別のアプローチでは、プローブデータパケットを識別番号でタグ付けしてよく、これにより、ホストはパケットIDを読み出し、そのデータがどのプローブからのものであるかを知ることができる。
【0168】
通信経路設定(COMM)
これより、通信経路の設定及び切断のための例示的なプログラミングについて説明する。しかしながら、ここで説明する特定の実装形態は単なる例であり、考えられる実装形態をいずれの特定の形態、機能、名称又は外観に限定することを意図したものではないことに留意されたい。一般に1つ又は複数のPEは、DMAを用いてメモリから経路を通してデータを実際にポンピングする間に、上述の設定及び切断機能を実施してよい。またいくつかの実施形態では、メモリをバイパスする「クイックポート」を用いて、PEがデータを経路に直接ポンピングしてよい。
【0169】
通信パスの設定は一般に、ソフトウェアタスクをセンダPE命令メモリにロードしてそのタスクの実行を開始することを伴う。経路はセンダPEタスクのみによって設定できるが、目的地DMRにおいて受信機構が必要となり、そうでなければハードウェアはデータの前進移動を機能停止させる。適切な受信機構は、DMRの近傍のPE上の別のタスク、又はパスの到着ポートにおける準備されたDMAエンジンである。
【0170】
タスクは、例えばCである高級プログラム言語でプログラムしてよいが、いくつかの実施形態では、プログラミングの労力を軽減するために、例えば例えばMPX_構造体である様々な構造体を提供してよい。例えばMPX_Send、MPX_Recvは、送信及び受信機能を提供できる。データ伝送オプションパラメータは、伝送のタイプ及び実装形態のばらつきを制御できる。このようなMPX機能は、3つの一般的な通信方法:
・汎用:システムが最適な通信(memcpy、DMA伝送を用いたメッセージ受け渡し、又はクイックポート伝送)を選択する;
・DMA伝送:メッセージ受け渡し;及び
・クイックポート:PEがDMRクイックポートレジスタに書き込みを行う、単一語のメッセージ受け渡し(DMR内のデータメモリを使用せず、DMAを設定する必要がない)
をサポートしてよい。
【0171】
これらの一般的な通信方法の中で、実装形態の変形は、設計者に多くのオプションを提供する。以下は例示的実施形態である:
・ブロッキング:データがバッファから完全に送信されるまで送信PEの実行を停止; ・非ブロッキング:送信PEの実行を即座に継続;
・InitRoute:DMAルートを設定;
・EndRoute:DMAルートを切断(なお、非ブロッキング機能はルートを切断しない);
・Express(送信):ルートの設定又は切断を行わず、既に設定された明らかなルートに対して多数の高速のコールを可能とする;
・促進された機能:不変値レジスタを一度プリセットできるため、使用するコードが少ない;
・単一の二地点間通信;及び
・一対多(ファンアウト)及び多対一(ファンイン)通信。
【0172】
ある機能は、動作の完了までに回復しなければブロックされる。従って、送信機能に関して、完了(complete)とは、データがバッファから完全に送信されることを意味し、データはDMRを離れている。完了は必ずしも、受信用タスクによってデータが完全に受信されたことを意味しない。受信機能がブロックされると、データをDMR位置のメモリに書き込む必要があり得る。動作が完了した場合のみ、コール内で指定されたリソースを再使用でき、受信用PEが実行を継続できる。
【0173】
ある機能は、動作が完了するまでに回復した場合は非ブロック状態となる。データ伝送動作は必ずしも完了していないため、まだ送信されていないデータは、センダタスクによって誤って修正され得る。センダタスクは、完了信号を明確に待つこと、又はデータ伝送動作の状態を明確にポーリングすることによって、データのエラーを回避できる。
【0174】
通信経路は、例えば#define COMMID 99といった定数である特定のcommID値によって宣言してよい。
【0175】
続いて構造体MPX_Sendを使用してデータ伝送を実行できる。
【0176】
MPX_Send
MPX_Sendは、特定の数の要素(メモリ語の値)を別のタスクに伝送できる。通信手段は、1つ又は複数の伝送オプションのパラメータ、例えばMPX_CommOptions_tによって与えることができる。以下は、関数及び引数の種類を示す例示的な関数プロトタイプである。
int16_t MPX_Send (void *buf,
uint16_t numElts,
MPX_Datatype_t datatype,
MPX_Comm_t commID,
MPX_CommOptions_t transferOpt)
【0177】
以下は、この構造の様々な機能を特定する例示的なパラメータの表である。
【0178】
【表1】
【0179】
受信関数
MPX「送信及び受信機能」の説明において、汎用、DMA及びクイックポート伝送に関する上の説明を参照されたい。なお受信関数はルートを設定又は切断することはできない。
【0180】
【表2】
【0181】
制約
制約は、リソースの割り振りをガイドするために物理的設計段階中に使用できる形式である。制約を用いて例えばIN内の1つ又は複数の通信経路及び他の通信パラメータの形成をガイドする。制約を用いて特に、経路の重複を防止でき、経路に特定のリソースを使用させることができ、また立入禁止領域を確立できる。プローブの制約は、以下に定義する特定のタイプの制約である:
//デザインビューにおいてデータ精査の制約を生成する。
constraint create -type probe[-raw]
-name constraintname
-comm comm_id
-port{PARALLELPORT|PCIE}
[-sample‘{’offset stride count‘}’]
{viewname|viewpath}
【0182】
データプローブの例及びビュー
データプローブは、アプリケーションからISDE内のリアルタイム分析(RTA)ビューへのデータの抽出を促進できる。
【0183】
プローブは通信データをサンプリングして、分析のためにサンプルをチップ外に伝送してよい。ある設計からのデータは、サンプリングポイントを挿入するためにその設計を変化させることなく、サンプリングできる。データをオンチップでフィルタリングして、通信オーバヘッドを最小化してよい。
【0184】
サンプリングは設計の機能に影響を与えることはなく、タイミングに対する影響も最小であってよい。
【0185】
いくつかの実施形態では、リアルタイム分析(RTA)ツールは、サンプリングしたデータの分析に使用されるHyperX ISDE内のビューのセットとして実装してよい。
【0186】
プローブの生成
プローブは、構成プロセスのリソースマッピング段階中に生成してよい。例えば「C」コードであるソースコードに対する変更はない。
【0187】
プローブcommは、プローブのサンプリングしたデータを伝送するための、非ブロッキングcomm設定であってよい。RTAに送信される各パケットに必要なヘッダは、全てのプローブcommに自動的に追加できる。
【0188】
プローブcommは、タイプ「プローブ」の制約を生成することによって生成してよい。この制約は、精査の頻度を制御するためのサンプリング基準を含んでよい。
【0189】
上で参照したプローブcommに対して、暗黙のnon_overlapping_comm制約をシステムが提供してよい。非オーバラップ制約は、ある経路に割り当てられたリンク及びルータのいずれを別の経路と共有しようとするのを抑制するよう、リソース割り当てツールに指示する。
【0190】
実施例1
constraint create -type probe-name probe99\
-comm 99-port PARALLELPORT/work/top/topv
【0191】
この例は、probe99という名称のプローブcommを生成し、このcomm99は、データが精査された基準commである。
【0192】
実施例2
constraint create -type probe-name probe99\
-comm 99-port PARALLELPORT\
-sample{2 3 4}/work/top/topv
【0193】
これは、-sampleのオプションが、オフセット(2)、ストライド(3)、カウント(4)を指定することによって収集されるサンプルデータの量を制御していることを除いて、上述の実施例と同一である。例えば、comm99上で伝送される値を1,9,25,49,81,121,169,225,289…とすると、第1のプローブデータは25,121,289,529となる。第1の要素は25であるが、これはオフセットゼロが最初の要素であり、オフセット2における要素が25であるためである。ストライドが3であるため、次の要素は121である。最後にカウントが4であるため、更に2つの要素が収集され、このサンプルデータのセットが完成される。
【0194】
プローブcommは、データをチップ外に伝送できるようにIOportが配置されることを必要としてよい。
【0195】
実施例3
place ioport -location{11 9}/work/top/topv/probe99
【0196】
チップ間Commのためのプローブの生成
多重チップ設計では、プローブはグルーピングの前又は後に確立できる。設計のグルーピングは、設計の部品をグループに割り当て、得られたグループを特定のチップ上に配置されるように割り当てるプロセスである。プローブをグルーピングの後に確立する場合、「センダ側(sender side)」グループ名を使用してよい。
【0197】
実施例4
group create -name grpO-task/work/root/root/0
group bind-chip/clxlib/XHx/v/Ul grp0
constraint create-type probe\
-name probe273-port PARALLELPORT\
-comm/work/root/root/273 /work/root/root/grp0
【0198】
この例は、probe273という名称のプローブを生成する。これは、基準comm273からのデータを精査し、上記commはグループ「grp0」の一部である。
【0199】
リアルタイム分析-ビュー
リアルタイム分析(RTA)を使用して、製品アプリケーションの挙動及び性能を、HyperX(商標)ハードウェア上での動作中にリアルタイムに制御及び監視してよい。
【0200】
いくつかの実施形態では、RTAツールを、ハードウェアデバッガを動作させるISDE内のテストハーネスの一部として使用してよい。サンプルコードを、例えばインストール例ディレクトリ内に提供してよく、これにより、試験構成要素がアプリケーション及びISDEビューとどのようにインタフェース接続されるかを示す。
【0201】
以下の例示的実装形態は、無線用途の分析に焦点を当てたものである。
【0202】
3種類のビュー
例示的な一実施形態では、HyperX(商標)ハードウェア用のリアルタイム分析(RTA)ツールは、例えばHyperX(商標)リアルタイム分析パースペクティブにおいて6つのビューを含み、これらは3ペアのビューとして動作する。
【0203】
【表3】
【0204】
RTAビューを、HyperX(商標)リアルタイム分析パースペクティブにおいて使用してよい。
【0205】
ソフトウェア無線の例
図18に示すようにソフトウェア無線の例から始めるが、ここではパケットは、レシーバに連結されたトランスミッタへの入力として受信され、レシーバはパケットを出力し、トランスミッタ及びレシーバはそれぞれ1つ又は複数のPEを利用する。トランスミッタは固定サイズのパケットを受け取り、伝送のためにこれらを符号化し、これらをレシーバに送信し、これらはレシーバにおいて復号化される。実環境での応用では、トランスミッタからのデータはRF(無線周波数)トランスミッタ回路に送信され、レシーバに供給されるデータはRFレシーバ回路から来るものとなる。
【0206】
システムを試験するために、図19に示すようにテストハーネス構成要素をシステムに追加してよく、これらはそれぞれHyperX(商標)ハードウェア上で動作する。この例示的実施形態では、「パケット生成器」と記された試験データ生成器が追加されており、これは公知のコンテンツを有する試験パケットを生成し、これら入力パケットをトランスミッタに送信する。これもまた図示したように、チャネルの障害のためのAWGN(加法性ホワイトガウスノイズ)構成要素をトランスミッタとレシーバとの間に介在させる。この構成要素は、信号にノイズを付加することによって放送電波を介した伝送をエミュレートし、得られたノイズを含む信号をレシーバに送信する。最後に、「パケット比較器」と記されたパケット比較器がレシーバに連結されている。レシーバはノイズを含む信号を復号化し、復号化された信号をパケット比較器に送信して、パケット及びビットエラーレートを計数する。
【0207】
AWGN及び信号空間
いくつかの実施形態では、AWGNビューはHyperX(商標)加法性ホワイトガウスノイズ(AWGN)生成器構成要素を制御してよい。AWGN構成要素はエグザンプルコートを供給されてよく、また調整可能な量のノイズをトランスミッタの出力に付加するために使用してよい。
【0208】
一実施形態では、信号空間ダイヤグラムは、直交振幅変調(QAM)信号を復号化することの効果を示してよい。IQデータは、様々な表示形態の中でも特に信号空間プロット(散布図としても知られる)として、又は2D若しくは3Dヒートマップとして示してよい。
【0209】
図20は、一実施形態による、印加されるAWGNを特定及び/又は指示するための例示的なAWGNユーザインタフェースビューを示す。AWGNユーザインタフェースビューは、AWGN生成器構成要素にAWGN制御メッセージ(パケット)を送信してよい。パケットは、要求されるSNRと、推定された平均信号電力とを含んでよい。AWGN構成要素はトランスミッタの出力を、所定の平均電力を有するものとして処理してよい。AWGN構成要素は要求されるSNRを使用して、トランスミッタの出力に付加されることになるノイズの振幅を計算してよい。
【0210】
AWGNユーザインタフェースビューは、HyperX(商標)ハードウェアにパケットを周期的に送信して、AWGNノイズ設定を調整してよい。一実施形態では、AWGNは2つのモード、即ち固定(Fixed)モード及びスイープ(Sweep)モードで動作してよい。
【0211】
固定モードでは、1つのAWGN制御パケットを送信してよく、これは固定フィールドからのSNR値と、平均電力フィールドの値とを含む。
【0212】
スイープモードでは、AWGN制御パケットを周期的に送信してよい。図示したSecs/Incrスピナ制御は、アップデートとアップデートとの間の秒数を調整してよい。SNRは開始値から停止値までスイープしてよく、毎回増分値だけ増加してよい。第1のパケットはスイープフィールドにおいてSNR値を使用してよい。停止値を有するパケットを送信すると、スイープを開始値で再び始めることができる。
【0213】
なお、図示した実施形態では、底部の小さなグラフは、スイープの進行の指示を提供する。
【0214】
【表4】
【0215】
AWGN構成要素は、新規のデータブロックの到着だけでなく、制御パケットの到着にも応答してよいことに更に留意されたい。これは、到着ポートをラウンドロビン様式でポーリングすることによって達成できる。しかしながらポーリングはPEを連続的に動作させるため、電気的エネルギを放散させてしまう。一時停止するとPEの電力放散は動作中に比べて大幅に、何倍も低くなるため、PEを一時停止させて電気的エネルギを節約するための様々な方法が従来技術に存在する。PEの一時停止(待機状態又は単に「待機(waiting)」とも呼ぶ)は、PEの内部又は外部の特定のイベントに対して調整してよい。PEの一時停止は、PEのバイナリ命令の実行において待機するよう、ソフトウェアによって開始してよい。待機命令からの解除は、1つ又は複数のウェイクアップ信号に左右され得る。DMRは1つ又は複数のウェイクアップ信号を、近隣のPEのうちの1つ又は複数に送信してよく、そしてPEは全ての近隣のPEからウェイクアップ信号を受信してよい。ウェイクアップ信号は、DMR-PEインタフェースの一部であるもののPIN又はSINからは独立している物理的回路によって、DMRからPEへと通信してよい。DMRはマスクレジスタと呼ばれるレジスタを有し、これは、データトリガイベントの到着時にウェイクアップ信号を生成できるリンクポートを選択するよう構成してよい。追加のレジスタは、利用可能なポートのうちのいずれか1つがトリガされた場合に特定のPEに対するウェイクアップ信号が生成されるか、又は利用可能なポート全てがトリガされるまで上記ウェイクアップ信号が生成されないかを決定するよう構成してよい。これらのハードウェア機能の動作の例は、hx3100A集積回路製品のためのHyperX(商標)ユーザマニュアルに詳述されている。
【0216】
AWGN構成要素のための例示的なソースコードを、その動作の説明を付して以下に示す。これは、待機及びウェイクアップ信号送信のためのRTAコンテキストを提供する。なお、このAWGNコードは単なる例であり、性能、命令メモリサイズ、バッファサイズ、信号サンプル値のタイプ等を調整するために数多くの変形例があり得る。
【0217】
mpx_view awgnView(){
MPX_SetupWake(controlIn);//commID=controlInに対するウェイクアップ信号を有効とする
MPX_SetupWake(dataIn);//commID=dataInに対するウェイクアップ信号を有効とする
MPX_Recv(&control,sizeof(control),ΜΡΧ_IΝΤ,controlIn,MPX_NONBLOCKING);//制御パケットの受信を開始、ここでは完了を待たない
MPX_Recv(&data,2,MPX_INT,dataIn,MPX_NONBLOCKING);//データブロック(目標の信号)の受信を開始、ここでは完了を待たない
while(1){//無制限にループ
MPX_Wait();//いずれの利用可能なポートにおけるいずれの到着に対するウェイクアップ信号を待機
if(MPX_Rtest(controlIn)==DMA_DONE){//データブロックの受信の完了に対する試験
snr=control.snr;//パケットから現在のS/N比値を抽出 average_noise=computeAverageNoiseFromSignalPower(control.averageSignalPower);
MPX_Recv(&control,sizeof(control),MPX_INT,controlIn,MPX_NONBLOCKING);//別の制御パケットの受信を開始、ここでは完了を待たない

if(MPX_Rtest(dataIn)==DMA_DONE){//コントロールパケットの受信の完了に対する試験
addNoise(data,2);//データブロックに対するノイズ付加のための機能の呼び出し
MPX_Send(data,2,MPX_INT,dataOut,MPX_DMA);//データブロックをレシーバに送信
MPX_Recv(data,2,MPX_INT,dataIn,MPX_NONBLOCKING);//別のデータブロックの受信を開始


【0218】
この例示的実施形態では、関数awgnView()は、commID「controlIn」及び「dataIn」に関連するDMRポートからのウェイクアップ信号ソースを利用可能とすることから始まる。続いてこれは、「contol」という名称のメモリ内のバッファに制御パケットを受信するよう開始され、ここでMPX_Recv関数に対する引数は、バッファアドレス、パケットサイズ、パケット要素に関するデータタイプ(ここではMPX_INTは整数を指定)、commID、非ブロッキングモードを指定する。非ブロッキングモードとは、プログラム制御が、バッファがいっぱいになるまで待機することなく、次の命令文に即座に進むことを意味する。上記次の命令文は、「data」という名称のバッファ内にデータブロックを受信するよう開始され、これはcomm ID dataInからの、タイプを表す整数の2つの要素のみを含み、また非ブロッキングモードである。
【0219】
次の命令文はwhileループであり、これは、それぞれ試験によってゲート処理された2つの部分を包含するプログラムブロックに亘って無期限に動作する。第1の部分に関する試験(MPX_Rtest(controlIn)== DMA_DONE)は、controlInのためにウェイクアップ信号が受信されたことを確認するために実施される。commID contolInからのウェイクアップ信号が存在した場合、MPX_Rtest(controlIn)はDMA_DONE値に戻る。ウェイクアップ信号を受信すると、プログラムは平均ノイズの計算処理を行い、次に別の制御パケットの読み出しを開始する。そうでない場合、プログラム制御は第2の部分に関する試験(MPX_Rtest(dataIn)==DMA_DONE)へと移動する。この試験は、dataInのためのウェイクアップ信号が受信されている場合に真となり、その場合、プログラム制御は進行し、関数addNoise(data,2)を呼び出してデータバッファ内の値にノイズを付加する。続いて、DUT上で実行されるレシーバアプリケーションへの経路であるcommID dataOutを通した、DMRからノイズを付加したデータのMPX_Sendが実行される。この送信は、最後の命令文に進む前に確実に完了するようにブロッキングモードであり、上記最後の命令文は、commID dataInから別のデータブロックの受信を開始するための非ブロッキングモードでの受信である。そしてプログラム制御はwhile命令文、そして新規の制御パケット又は新規のデータブロックの到着までPEが待機するWait命令文までループして戻る。
【0220】
信号空間
図21は、一実施形態による例示的な信号空間ダイヤグラムである。信号空間ダイヤグラムは、直交振幅変調(QAM)信号を復号化することの効果を図式的に示してよい。IQデータは、信号空間プロット(散布図としても知られる)として、又は2D若しくは3Dヒートマップとして示してよい。図示したように、グラフのタイプの選択は、コンステレーションビューの底部のタブのセットによって実施できる。
【0221】
ビデオによる実施例
これより、ビデオソースが画像フレームをチップに送信する単純な例について説明する。図22は、例えばファイルの数(「ファイル」)、メッセージの数(「メッセージ」)、データレート(「バイトレート」)、フレームレート(「フレームレート」)といった様々なパラメータ又は属性を構成及び/又は表示できるビデオソースビュー(GUI)を示す。これもまた図22に示すように、画像のオーバレイを特定するためのフィールド、具体的にはこの例では「Overlay」である画像オーバレイテキストも提供される。
【0222】
この例示的実施形態では、各フレームはJPEG画像としてフォーマットされている。JPEGデータは:
1.ファイルからの読み出し;
2.画像への復号化;
3.ファイルに画像オーバレイテキストを書き込み;
4.画像をJPEGに再符号化;
5.画像をチップに送信
である。
【0223】
この実施形態では、1024語の固定サイズメッセージを用いて画像を送信する。従って最終的なJPEG画像は複数のメッセージに分割され得る。
【0224】
更なる実施形態では、特に更に複雑で密なMPAに関して、比較的複雑な機器を上述の技術によってプログラムして挿入してよい。このようなソフトウェアベースの機器は一般に「合成機器(SI)」と呼ばれ、特にスペクトラムアナライザ又はベクタ信号アナライザといった機器機能を実装してよい。
【0225】
例示的な便益
以下は、ここで開示した技術の可能な便益のリストであるが、ここに列挙した便益は単なる例であり、ここで開示した技術の実際の便益をいずれの特定の便益のセットに制限することを意図したものではないことに留意されたい:
ユーザが試験点を選択した場合の、プローブ及びオフチップ通信経路の自動的な設定; メモリ位置及び信号の自動的な精査;
変化する信号対ノイズ比に対して適合するための、ランタイムのインテリジェントな変動;
信号測定の帯域幅の上昇;
測定を行う速度の上昇;
測定データがチップを離れる前の、測定データのより良好な圧縮;
試験完了速度の上昇;
アプリケーションソフトウェアのより完全な試験及び特性決定;
必要な試験設備の数及びタイプの可能な限りの削減;並びに
オリジナル設計の動作、機能又は性能を観察が妨害しないこと。
【0226】
以上の実施形態についてはかなり詳細に説明してきたが、以上の開示を完全に理解すれば、当業者には多数の変形例及び修正例が明らかとなるであろう。以下の請求項は、このような変形例及び修正例の全てを包含するものとして理解されることを意図したものである。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
【手続補正書】
【提出日】2022-04-15
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
複数の試験パケットを生成するように構成されたパケット生成器と、
前記複数の試験パケットを用いて、出力信号を生成するように構成されたトランスミッタと、
変更された信号を生成するために、前記出力信号にノイズを付加するように構成されたノイズ生成器と、
前記変更された信号を用いて、複数の受信パケットを生成するように構成されたレシーバと、
前記複数の受信パケットに基づいて、エラーレートを決定するように構成されたパケット比較器と
を備える装置。