知財求人 - 知財ポータルサイト「IP Force」
特許7449963ヘテロジニアス処理システムのためのデータフローグラフプログラミング環境
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-03-06
(45)【発行日】2024-03-14
(54)【発明の名称】ヘテロジニアス処理システムのためのデータフローグラフプログラミング環境
(51)【国際特許分類】
G06F 15/82 20060101AFI20240307BHJP
G06F 15/80 20060101ALI20240307BHJP
G06F 15/78 20060101ALI20240307BHJP
G06F 15/173 20060101ALI20240307BHJP
G06F 8/41 20180101ALI20240307BHJP
G06F 8/34 20180101ALI20240307BHJP
【ＦＩ】
G06F15/82 630Z
G06F15/80
G06F15/78 530
G06F15/78 560
G06F15/173 665D
G06F15/173 680
G06F8/41
G06F8/34
【請求項の数】
15
(21)【出願番号】P 2021569564
(86)(22)【出願日】2020-03-31
(65)【公表番号】
(43)【公表日】2022-08-10
(86)【国際出願番号】 US2020026031
(87)【国際公開番号】W WO2020236318
(87)【国際公開日】2020-11-26
【審査請求日】2023-03-06
(31)【優先権主張番号】16/420,831
(32)【優先日】2019-05-23
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】591025439
【氏名又は名称】ザイリンクス インコーポレイテッド
【氏名又は名称原語表記】ＸＩＬＩＮＸ ＩＮＣＯＲＰＯＲＡＴＥＤ
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】グプタ，シャイル・アディティア
(72)【発明者】
【氏名】ベイリス，サミュエル・アール
(72)【発明者】
【氏名】カタイル，ビノッド・ケイ
(72)【発明者】
【氏名】ウィッティヒ，ラルフ・デー
(72)【発明者】
【氏名】ジェイムズ－ロックスビー，フィリップ・ビィ
(72)【発明者】
【氏名】サストリー，アケッラ
【審査官】坂庭 剛史
(56)【参考文献】
【文献】特表２０１８－５０７４４９（ＪＰ，Ａ）
【文献】特開２０１２－２４８１１４（ＪＰ，Ａ）
【文献】国際公開第２０１１／０９６０１６（ＷＯ，Ａ１）
【文献】DUBACH, Christophe et al.，Compiling a High-level Language for GPUs，PLDI'12: Proceedings of the 33rd ACM SIGPLAN Conference on Programming Language Design and Implementation，米国，ACM [online]，2012年06月11日，Volume 47, Issue 6，pp.1-11，https://dl.acm.org/doi/pdf/10.1145/2345156.2254066
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １５／８２
Ｇ０６Ｆ １５／８０
Ｇ０６Ｆ １５／７８
Ｇ０６Ｆ １５／１７３
Ｇ０６Ｆ ８／４１
Ｇ０６Ｆ ８／３４
(57)【特許請求の範囲】
【請求項1】
コンピュータによって実行される方法であって、オブジェクト指向ソースコードとしてデータフローグラフを定義するためのヘテロジニアスなプログラミング環境を提供するステップと、
前記ヘテロジニアスなプログラミング環境において生成されたグラフソースコードを受信するステップであって、前記グラフソースコードは、複数のカーネルおよび複数の通信リンクを定義し、前記複数の通信リンクの各々は、前記データフローグラフを形成するために前記複数のカーネルのそれぞれの対を結合する、受信するステップと、
ヘテロジニアス処理システムにおいて前記データフローグラフを実施するために前記グラフソースコードをコンパイルするステップであって、前記グラフソースコードをコンパイルするステップは、
前記グラフソースコードにおける前記複数のカーネルの前記定義に基づいて前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップと、
前記グラフソースコードで定義された前記複数の通信リンクに通信タイプを割り当てるステップと、
前記複数の通信リンクを使用して前記複数のカーネル間でデータを転送するための同期技術を選択するステップと、を含み、
前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップは、
第１のカーネルおよび第２のカーネルが、前記グラフソースコードによって定義された前記複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、
前記第１のカーネルを前記ヘテロジニアス処理システム内の第１のデータ処理エンジン（ＤＰＥ）に割り当てるステップと、
前記第２のカーネルを、前記ヘテロジニアス処理システム内の第２のＤＰＥに割り当てるステップと、を含む、方法。
【請求項2】
前記第２のＤＰＥは、前記第１のＤＰＥに直接隣接する、請求項１に記載の方法。
【請求項3】
前記第１のＤＰＥおよび第２のＤＰＥは両方とも共有メモリモジュールへの直接接続を有し、前記方法は、前記第１のカーネルと前記第２のカーネルとの間でデータを転送するために、前記共有メモリモジュール内にダブルバッファを割り当てるステップを含む、請求項２に記載の方法。
【請求項4】
前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップは、第１のカーネルおよび第２のカーネルが、前記グラフソースコードによって定義された前記複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、
前記第１のカーネルを前記ヘテロジニアス処理システム内の第１のＤＰＥに割り当てるステップと、
前記第２のカーネルを前記ヘテロジニアス処理システム内のプログラマブルロジックに割り当てるステップと、
前記第１のカーネルにデータを転送するために相互接続を使用して直接メモリアクセス（ＤＭＡ）を実行するように前記第２のカーネルを構成するステップと、を含み、
前記相互接続は、前記第１のＤＰＥを含むＤＰＥのアレイを互いにおよびプログラマブルロジックに相互接続する、請求項１に記載の方法。
【請求項5】
前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップは、第１のカーネルおよび第２のカーネルが、前記グラフソースコードによって定義された前記複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、
第１および第２のカーネルが第１のコアのサイクルバジェット以下の結合サイクル数を有すると決定したことに応答して、前記第１および第２のカーネルを前記ヘテロジニアス処理システム内のＤＰＥのアレイ内の前記第１のコアにクラスタリングするステップと、
前記第１のカーネルと第２のカーネルとの間でデータを転送するためにメモリモジュール内にバッファを割り当てるステップと、を含み、
前記メモリモジュールは前記第１のコアへの直接接続を有する、請求項１に記載の方法。
【請求項6】
前記通信タイプを前記複数の通信リンクに割り当てるステップは、前記グラフソースコードにおける前記複数の通信リンクの前記定義に基づいて、前記複数の通信リンクの各々についてデータを送信するためにストリーミングおよびウィンドウ処理のうちの１つを使用するかどうかを選択するステップを含む、請求項１に記載の方法。
【請求項7】
ウィンドウ処理は、受信したデータを事前定義されたまたはパラメータ化されたブロックサイズを有する個々のウィンドウに分割するステップであって、前記個々のウィンドウを受信するように構成された前記複数のカーネルの各々は、前記受信したウィンドウを処理する前に、呼び出しごとにウィンドウを受信するまで待機する、分割するステップを含み、ウィンドウ処理を実行する前記通信リンクの少なくとも１つについて、前記個々のウィンドウは、前記個々のウィンドウを受信する前記複数のカーネルの受信カーネルがその状態を維持するように、最初に以前に送信されたウィンドウの端部と重複するデータを有する、請求項６に記載の方法。
【請求項8】
前記同期技術を選択するステップは、前記複数の通信リンクのうちの第１の通信リンクに割り当てられたダブルバッファを識別するステップと、
前記複数の通信リンクのうちの前記第１の通信リンクに対応する第１のカーネルおよび第２のカーネルが前記ダブルバッファに並列にアクセスできるようにロックプロトコルを構成するステップと、を含む、請求項１に記載の方法。
【請求項9】
前記データフローグラフを実行するように前記ヘテロジニアス処理システムを構成する前記グラフソースコードをコンパイルすることに基づいてビットストリームおよびバイナリコードを送信するステップと、制御プログラムを使用して前記ヘテロジニアス処理システムにおける前記データフローグラフの実行を制御するステップと、をさらに含む、
請求項１に記載の方法。
【請求項10】
前記ヘテロジニアス処理システムは、第１のチップおよび第２のチップを含み、前記複数のカーネルは前記第１のチップに割り当てられ、前記グラフソースコードは第２の複数のカーネルを定義し、前記グラフソースコードをコンパイルするステップは、前記第２の複数のカーネルを前記第２のチップに割り当てるステップを含み、前記第２のチップに割り当てられた前記第２の複数のカーネルは、前記第１のチップに割り当てられた前記複数のカーネルと通信するように構成される、請求項１に記載の方法。
【請求項11】
前記グラフソースコードは、前記ヘテロジニアス処理システムを形成するＳｏＣのハードウェア設計から独立しており、各々が異なるハードウェア設計を有する複数の異なるタイプのＳｏＣ上にコンパイラによって実装することができる、請求項１に記載の方法。
【請求項12】
前記ヘテロジニアス処理システムは、プログラマブルロジックおよびデータ処理エンジン（ＤＰＥ）のアレイを備え、前記複数のカーネルのうちの少なくとも１つは前記プログラマブルロジックに割り当てられ、前記複数のカーネルのうちの少なくとも１つは前記ＤＰＥのうちの１つに割り当てられる、請求項１に記載の方法。
【請求項13】
サブグラフを前記データフローグラフにカプセル化するステップであって、前記サブグラフは前記グラフソースコードとは別個のグラフクラスによって定義される、カプセル化するステップと、前記データフローグラフおよび前記サブグラフに制約を追加する制約付きグラフを生成するステップであって、前記制約付きグラフは前記データフローグラフのためのラッパーとして機能する、生成するステップと、をさらに含む、請求項１に記載の方法。
【請求項14】
前記複数のカーネルの各々は、前記複数のカーネルの各々が前記データフローグラフ内の別のカーネルと通信することを可能にするための少なくとも１つのポートを含み、前記データフローグラフにおいて、前記複数の通信リンクの各々は、第１のカーネル上の第１のポートを第２のカーネル上の第２のポートに結合する、請求項１に記載の方法。
【請求項15】
ホストであって、プロセッサと、
メモリとを備え、前記メモリは、
オブジェクト指向ソースコードとしてデータフローグラフを定義するためのヘテロジニアスなプログラミング環境と、
前記ヘテロジニアスなプログラミング環境において生成されたグラフソースコードであって、前記グラフソースコードは、複数のカーネルおよび複数の通信リンクを定義し、前記複数の通信リンクの各々は、前記データフローグラフを形成するために前記複数のカーネルのそれぞれの対を結合する、グラフソースコードと、
ヘテロジニアス処理システムにおいて前記データフローグラフを実施するために前記グラフソースコードをコンパイルするように構成された、前記プロセッサ上で動作するコンパイラであって、前記グラフソースコードをコンパイルするステップは、
前記グラフソースコードにおける前記複数のカーネルの前記定義に基づいて前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップと、
前記グラフソースコードで定義された前記複数の通信リンクに通信タイプを割り当てるステップと、
前記複数の通信リンクを使用して前記複数のカーネル間でデータを転送するための同期技術を選択するステップと、を含む、コンパイラと、を格納し、
前記複数のカーネルを前記ヘテロジニアス処理システムに割り当てるステップは、
第１のカーネルおよび第２のカーネルが、前記グラフソースコードによって定義された前記複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、
前記第１のカーネルを前記ヘテロジニアス処理システム内の第１のデータ処理エンジン（ＤＰＥ）に割り当てるステップと、
前記第２のカーネルを、前記ヘテロジニアス処理システム内の第２のＤＰＥに割り当てるステップと、を含む、ホスト。
【発明の詳細な説明】
【技術分野】
【0001】
技術分野
本開示の例は、一般に、プログラマブルかつソフトウェア構成可能にハード化されたハードウェア要素の混合を含むシステムにおいてデータフローグラフを生成するためにオブジェクト指向プログラミングコードを使用することに関する。
本開示の例は、一般に、プログラマブルかつソフトウェア構成可能にハード化されたハードウェア要素の混合を含むシステムにおいてデータフローグラフを生成するためにオブジェクト指向プログラミングコードを使用することに関する。
【背景技術】
【0002】
背景技術
システムオンチップ（ＳｏＣ）は、プログラマブルロジック（例えば、プログラマブルファブリック）と、処理コアまたはエンジンなどのソフトウェア構成可能なハードウェア化ロジックとの混合を含むことができる。典型的には、ユーザは、ユーザ機能を実行するためのソフトウェア構成可能なハードウェア化ロジックを構成するためのプログラマブルなバイナリコードを構成するためのビットストリームにコンパイルすることができるプログラムを書き込むために、プログラマブルかつソフトウェア構成可能なハードウェア化ロジック（およびそれらが通信する方法）を詳細に理解しなければならない。しかし、プログラマブルロジックとハードウェア化ロジックとが混在するＳｏＣ用のプログラムを記述するためにハードウェア記述言語（ＨＤＬ）またはオープンコンピューティング言語（ＯｐｅｎＣＬ）を使用することは面倒であり、並列化することは困難である。データ並列度およびスレッド並列度はまた、プロセッサのアレイ上での計算を表現するために使用されるが、これらの技法は、異なるインターフェースを有するヘテロジニアス計算を表現する必要があるプログラマブルロジックに自然には拡張されない。
システムオンチップ（ＳｏＣ）は、プログラマブルロジック（例えば、プログラマブルファブリック）と、処理コアまたはエンジンなどのソフトウェア構成可能なハードウェア化ロジックとの混合を含むことができる。典型的には、ユーザは、ユーザ機能を実行するためのソフトウェア構成可能なハードウェア化ロジックを構成するためのプログラマブルなバイナリコードを構成するためのビットストリームにコンパイルすることができるプログラムを書き込むために、プログラマブルかつソフトウェア構成可能なハードウェア化ロジック（およびそれらが通信する方法）を詳細に理解しなければならない。しかし、プログラマブルロジックとハードウェア化ロジックとが混在するＳｏＣ用のプログラムを記述するためにハードウェア記述言語（ＨＤＬ）またはオープンコンピューティング言語（ＯｐｅｎＣＬ）を使用することは面倒であり、並列化することは困難である。データ並列度およびスレッド並列度はまた、プロセッサのアレイ上での計算を表現するために使用されるが、これらの技法は、異なるインターフェースを有するヘテロジニアス計算を表現する必要があるプログラマブルロジックに自然には拡張されない。
【発明の概要】
【課題を解決するための手段】
【0003】
発明の概要
ヘテロジニアス処理システム上でデータフローグラフを実装するための技術を説明する。一例は、グラフソースコードを受信するステップを含む方法であり、グラフソースコードは、複数のカーネルおよび複数の通信リンクを定義し、複数の通信リンクの各々は、複数のカーネルのそれぞれの対を結合してデータフローグラフを形成する。方法はまた、ヘテロジニアス処理システム内のシステム上でデータフローグラフを実装するためにグラフソースコードをコンパイルするステップを含む。グラフソースコードをコンパイルするステップは、複数のカーネルをヘテロジニアス処理システム内のプログラマブルロジックおよびデータ処理エンジン（ＤＰＥ）のアレイに割り当てるステップと、通信タイプを複数の通信リンクに割り当てるステップと、複数の通信リンクを使用して複数のカーネル間でデータを転送するための同期技術を選択するステップとを含む。
ヘテロジニアス処理システム上でデータフローグラフを実装するための技術を説明する。一例は、グラフソースコードを受信するステップを含む方法であり、グラフソースコードは、複数のカーネルおよび複数の通信リンクを定義し、複数の通信リンクの各々は、複数のカーネルのそれぞれの対を結合してデータフローグラフを形成する。方法はまた、ヘテロジニアス処理システム内のシステム上でデータフローグラフを実装するためにグラフソースコードをコンパイルするステップを含む。グラフソースコードをコンパイルするステップは、複数のカーネルをヘテロジニアス処理システム内のプログラマブルロジックおよびデータ処理エンジン（ＤＰＥ）のアレイに割り当てるステップと、通信タイプを複数の通信リンクに割り当てるステップと、複数の通信リンクを使用して複数のカーネル間でデータを転送するための同期技術を選択するステップとを含む。
【0004】
いくつかの実施形態では、複数のカーネルをヘテロジニアス処理システムに割り当てるステップは、第１のカーネルおよび第２のカーネルが、グラフソースコードによって定義された複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、第１のカーネルをヘテロジニアス処理システム内の第１のデータ処理エンジン（ＤＰＥ）に割り当てるステップと、第２のカーネルを、第１のＤＰＥに直接隣接するヘテロジニアス処理システム内の第２のＤＰＥに割り当てるステップとを含む。
【0005】
いくつかの実施形態では、第１のＤＰＥおよび第２のＤＰＥは両方とも共有メモリモジュールへの直接接続を有し、方法は、第１のカーネルと第２のカーネルとの間でデータを転送するために、共有メモリモジュール内にダブルバッファを割り当てるステップを含む。
【0006】
いくつかの実施形態では、複数のカーネルをヘテロジニアス処理システムに割り当てるステップは、第１のカーネルおよび第２のカーネルが、グラフソースコードによって定義された複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、第１のカーネルをヘテロジニアス処理システム内の第１のＤＰＥに割り当てるステップと、第２のカーネルをヘテロジニアス処理システム内のプログラマブルロジックに割り当てるステップと、第１のカーネルにデータを転送するために相互接続を使用して直接メモリアクセス（ＤＭＡ）を実行するように第２のカーネルを構成するステップと、を含み、相互接続は、第１のＤＰＥを含むＤＰＥのアレイを互いにおよびプログラマブルロジックに相互接続する。
【0007】
いくつかの実施形態では、複数のカーネルをヘテロジニアス処理システムに割り当てるステップは、第１のカーネルおよび第２のカーネルが、グラフソースコードによって定義された複数の通信リンクのうちの第１の通信リンクによって通信可能に結合されていることを識別するステップと、第１および第２のカーネルが第１のコアのサイクルバジェット以下の結合サイクル数を有すると決定したことに応答して、第１および第２のカーネルをヘテロジニアス処理システム内のＤＰＥのアレイ内の第１のコアにクラスタリングするステップと、第１のカーネルと第２のカーネルとの間でデータを転送するためにメモリモジュール内にバッファを割り当てるステップとを含み、メモリモジュールは第１のコアへの直接接続を有する。
【0008】
いくつかの実施形態では、通信タイプを複数の通信リンクに割り当てるステップは、グラフソースコードにおける複数の通信リンクの定義に基づいて、複数の通信リンクの各々についてデータを送信するためにストリーミングおよびウィンドウ処理のうちの１つを使用するかどうかを選択するステップを含む。
【0009】
いくつかの実施形態では、ウィンドウ処理は、受信したデータを事前定義されたまたはパラメータ化されたブロックサイズを有する個々のウィンドウに分割することを含み、個々のウィンドウを受信するように構成された複数のカーネルの各々は、受信したウィンドウを処理する前に、呼び出しごとにウィンドウを受信するまで待機する。さらに、ウィンドウ処理を実行する通信リンクの少なくとも１つについて、個々のウィンドウは、個々のウィンドウを受信する複数のカーネルの受信カーネルがその状態を維持するように、最初に以前に送信されたウィンドウの端部と重複するデータを有する。
【0010】
いくつかの実施形態では、同期技術を選択するステップは、複数の通信リンクのうちの第１の通信リンクに割り当てられたダブルバッファを識別するステップと、複数の通信リンクのうちの第１の通信リンクに対応する第１のカーネルおよび第２のカーネルがダブルバッファに並列にアクセスできるようにロックプロトコルを構成するステップとを含む。
【0011】
いくつかの実施形態では、方法は、データフローグラフを実行するようにヘテロジニアス処理システムを構成するグラフソースコードをコンパイルすることに基づいてビットストリームおよびバイナリコードを送信するステップと、制御プログラムを使用してヘテロジニアス処理システムにおけるデータフローグラフの実行を制御するステップとを含む。
【0012】
いくつかの実施形態において、ヘテロジニアス処理システムは、第１のチップおよび第２のチップを含み、複数のカーネルは第１のチップに割り当てられ、グラフソースコードは第２の複数のカーネルを定義し、グラフソースコードをコンパイルするステップは、第２の複数のカーネルを第２のチップに割り当てるステップを含み、第２のチップに割り当てられた第２の複数のカーネルは、第１のチップに割り当てられた複数のカーネルと通信するように構成される。
【0013】
いくつかの実施形態では、グラフソースコードは、ヘテロジニアス処理システムを形成するＳｏＣのハードウェア設計から独立しており、各々が異なるハードウェア設計を有する複数の異なるタイプのＳｏＣ上にコンパイラによって実装することができる。
【0014】
いくつかの実施形態では、ヘテロジニアス処理システムは、プログラマブルロジックおよびＤＰＥのアレイを備え、複数のカーネルのうちの少なくとも１つはプログラマブルロジックに割り当てられ、複数のカーネルのうちの少なくとも１つはＤＰＥのうちの１つに割り当てられる。
【0015】
いくつかの実施形態では、方法は、サブグラフをデータフローグラフにカプセル化するステップであって、サブグラフはグラフソースコードとは別個のグラフクラスによって定義される、カプセル化するステップと、データフローグラフおよびサブグラフに制約を追加する制約付きグラフを生成するステップであって、制約付きグラフはデータフローグラフのためのラッパーとして機能する、生成するステップと、を含む。
【0016】
いくつかの実施形態では、複数のカーネルの各々は、複数のカーネルの各々がデータフローグラフ内の別のカーネルと通信することを可能にするための少なくとも１つのポートを含み、データフローグラフにおいて、複数の通信リンクの各々は、第１のカーネル上の第１のポートを第２のカーネル上の第２のポートに結合する。
【0017】
本明細書で説明される一例は、プロセッサと、複数のカーネルおよび複数の通信リンクを定義するグラフソースコードであって、複数の通信リンクの各々は複数のカーネルのそれぞれの対を結合してデータフローグラフを形成する、グラフソースコードと、ヘテロジニアス処理システムにおいてデータフローグラフを実装するためにグラフソースコードをコンパイルするように構成されたコンパイラとを含むホストである。グラフソースコードをコンパイルするステップは、複数のカーネルをヘテロジニアス処理システム内のプログラマブルロジックおよびＤＰＥのアレイに割り当てるステップと、通信タイプを複数の通信リンクに割り当てるステップと、複数の通信リンクを使用して複数のカーネル間でデータを転送するための同期技術を選択するステップとを含む。
【0018】
図面の簡単な説明
上記の特徴が詳細に理解され得るように、上記で簡潔に要約したものより具体的な説明は、例示的な実装を参照することによって得ることができ、そのいくつかは添付の図面に示されている。しかしながら、添付の図面は、典型的な例示的な実装のみを示しており、したがってその範囲を限定するものと見なされるべきではないことに留意されたい。
上記の特徴が詳細に理解され得るように、上記で簡潔に要約したものより具体的な説明は、例示的な実装を参照することによって得ることができ、そのいくつかは添付の図面に示されている。しかしながら、添付の図面は、典型的な例示的な実装のみを示しており、したがってその範囲を限定するものと見なされるべきではないことに留意されたい。
【図面の簡単な説明】
【0019】
【図1】一例による、データ処理エンジンアレイを含むＳｏＣのブロック図である。
【図2】一例による、データ処理エンジンアレイ内のデータ処理エンジンのブロック図である。
【図3A】一例による、ＤＰＥアレイ内の複数のＤＰＥによって共有されるメモリモジュールを示す。
【図3B】一例による、ＤＰＥアレイ内の複数のＤＰＥによって共有されるメモリモジュールを示す。
【図5】一例による、プログラマブルおよび非プログラマブルロジックを有するＳｏＣ上でデータフローグラフを実装するためにソースコードをコンパイルするためのフローチャートである。
【図6】一例による、データフローグラフを定義するためのグラフソースコードである。
【図8】一例による、データフローグラフにおいてカーネルを定義するためのカーネルソースコードである。
【図11】一例による、カーネル間でデータを送信するときに使用されるオーバーラップウィンドウを示す。
【図12】一例による、データフローグラフのための制御プログラムを定義する制御ソースコードである。
【図13】一例による、制約を使用してデータフローグラフを実装するためにソースコードをコンパイルするためのフローチャートである。
【図14】一例による、ユーザ定義の制約を使用して実装されたグラフオブジェクトを有するＤＰＥアレイである。
【図15】一例による、継承可能な抽象インターフェース１５０５である。
【図16】一例による、複数のサブグラフを有するデータフローグラフである。
【図17】一例による、制約付きデータフローグラフである。
【図18】一例による、複数のソースからの制約をマージするための制約処理フローである。
【図19】一例による、ＳｏＣ上でデータフローグラフを実装するためのコンピューティングシステムのブロック図である。
【図20A】例による、ＳｏＣ上のデータフローグラフの実行を制御するための制御アプリケーションプログラムインターフェースを示す。
【図20B】例による、ＳｏＣ上のデータフローグラフの実行を制御するための制御アプリケーションプログラムインターフェースを示す。
【図21】一例による、データ処理エンジンアレイを異なる領域に論理的に分割することを示す。
【図22A】一例による、データフローグラフの実行を動的に変更することを示す。
【図22B】一例による、データフローグラフの実行を動的に変更することを示す。
【図23A】例によるトリガされたパラメータを示す。
【図23B】例による非同期パラメータを示す。
【発明を実施するための形態】
【0020】
理解を容易にするために、可能であれば、図に共通する同一の要素を示すために同一の参照番号が使用されている。一例の要素は、他の例に有益に組み込むことができると考えられる。
【0021】
発明を実施するための形態
様々な特徴を、図面を参照して以下に説明する。図面は縮尺通りに描かれていてもいなくてもよく、同様の構造または機能の要素は図面全体を通して同様の参照番号で表されていることに留意されたい。図面は、特徴の説明を容易にすることのみを意図していることに留意されたい。それらは、網羅的な説明として、または特許請求の範囲に対する限定として意図されていない。さらに、図示された例は、示されたすべての態様または利点を有する必要はない。特定の例に関連して説明される態様または利点は、必ずしもその例に限定されず、そのように示されていなくても、またはそのように明示的に説明されていなくても、任意の他の例で実施することができる。
様々な特徴を、図面を参照して以下に説明する。図面は縮尺通りに描かれていてもいなくてもよく、同様の構造または機能の要素は図面全体を通して同様の参照番号で表されていることに留意されたい。図面は、特徴の説明を容易にすることのみを意図していることに留意されたい。それらは、網羅的な説明として、または特許請求の範囲に対する限定として意図されていない。さらに、図示された例は、示されたすべての態様または利点を有する必要はない。特定の例に関連して説明される態様または利点は、必ずしもその例に限定されず、そのように示されていなくても、またはそのように明示的に説明されていなくても、任意の他の例で実施することができる。
【0022】
本明細書の例は、カーネルおよびそれらのカーネル間の通信リンクを定義するためのソースコードを使用してデータフローグラフを生成するための技術を説明する。一実施形態では、グラフは、エッジ（例えば、カーネル間の通信リンク）によって通信可能に結合されたノード（例えば、カーネル）を使用して形成される。コンパイラは、ソースコードをビットストリームおよびバイナリコードに変換し、これは、グラフを実行するためにＳｏＣのヘテロジニアス処理システムにおいてプログラマブルロジックおよびソフトウェア構成可能なハードウェア化ロジックを構成する。ヘテロジニアス処理システム内のプログラマブルかつソフトウェア構成可能にハード化されたハードウェアを詳細に理解することをプログラマに要求するのではなく、コンパイラは、ソースコードで表されたグラフを使用して、どのカーネルをプログラマブルロジックブロックに割り当て、どのカーネルをハードウェア化ロジックブロックに割り当てるかを決定することができる。さらに、コンパイラは、グラフソースコードで提供されるパラメータを使用して、カーネル間の通信リンクを確立するための特定の通信技法（例えば、共有メモリ、ウィンドウ処理、ダイレクトメモリアクセス（ＤＭＡ）など）を選択することができる。さらに、コンパイラは、同期が通信リンクで使用されるべきかどうかを自動的に判定し、プログラマからの入力なしに、すなわちプログラマがグラフソースコード内で同期の詳細を提供することなく、その同期をセットアップすることができる。したがって、プログラマは、ＳｏＣのプログラマブルかつハード化されたハードウェアを使用してデータフローグラフを実装する方法を理解することなく、（ソースコードを使用して）データフローグラフを高レベルで表現することができる。結果として、グラフソースコードは、特定のＳｏＣのハードウェア設計から独立しており、各々が異なるハードウェア設計を有する複数の異なるタイプのＳｏＣ上に（コンパイラを使用して）実装することができる。
【0023】
図１は、一例による、データ処理エンジン（ＤＰＥ）アレイ１０５を含むＳｏＣ１００のブロック図である。ＤＰＥアレイ１０５は、ＳｏＣ１００内にグリッド、クラスタ、または市松模様で配置され得る複数のＤＰＥ１１０を含む。図１は、ＤＰＥ１１０を行および列を有する２Ｄアレイに配置することを示しているが、実施形態はこの配置に限定されない。さらに、アレイ１０５は、任意のサイズとすることができ、ＤＰＥ１１０によって形成された任意の数の行および列を有することができる。
【0024】
一実施形態では、ＤＰＥ１１０は同一である。すなわち、ＤＰＥ１１０（タイルまたはブロックとも呼ばれる）の各々は、同じハードウェア構成要素または回路を有することができる。さらに、本明細書の実施形態は、ＤＰＥ１１０に限定されない。代わりに、ＳｏＣ１００は、任意の種類の処理要素のアレイを含むことができ、例えば、ＤＰＥ１１０は、デジタル信号処理エンジン、暗号化エンジン、前方誤り訂正（ＦＥＣ）エンジン、または１つまたは複数の特殊なタスクを実行するための他の特殊なハードウェアであり得る。
【0025】
図１では、アレイ１０５は、すべて同じタイプ（例えば、均一アレイ）のＤＰＥ１１０を含む。しかしながら、別の実施形態では、アレイ１０５は、異なるタイプのエンジンを含むことができる。例えば、アレイ１０５は、デジタル信号処理エンジン、暗号化エンジン、グラフィック処理エンジンなどを含むことができる。アレイ１０５が同種であるかヘテロジニアスであるかにかかわらず、ＤＰＥ１１０は、以下でより詳細に説明するように、ＤＰＥ１１０がデータを直接転送することを可能にするＤＰＥ１１０間の直接接続を含むことができる。
【0026】
一実施形態では、ＤＰＥ１１０は、ソフトウェア構成可能にハードウェア化されたロジックから形成、すなわちハード化される。そうすることの利点の１つは、ＤＰＥ１１０内にハードウェア要素を形成するためにプログラマブルロジックを使用することと比較して、ＤＰＥ１１０がＳｏＣ１００内で占有するスペースが少なくなり得ることである。すなわち、プログラムメモリ、命令フェッチ／デコードユニット、固定小数点ベクトルユニット、浮動小数点ベクトルユニット、算術論理演算ユニット（ＡＬＵ）、乗算アキュムレータ（ＭＡＣ）などのＤＰＥ１１０内のハードウェア要素を形成するためにハードウェア化ロジック回路を使用することにより、ＳｏＣ１００内のアレイ１０５のフットプリントを大幅に削減することができる。ＤＰＥ１１０はハード化されてもよいが、これはＤＰＥ１１０がプログラマブルでないことを意味しない。すなわち、ＤＰＥ１１０は、ＳｏＣ１００の電源投入時または再起動時に、異なる機能またはタスクを実行するように構成することができる。
【0027】
ＤＰＥアレイ１０５はまた、ＤＰＥ１１０とＳｏＣ１００内の他のハードウェア構成要素との間の通信インターフェースとして機能するＳｏＣインターフェースブロック１１５（シムとも呼ばれる）を含む。この例では、ＳｏＣ１００は、ＳｏＣインターフェースブロック１１５に通信可能に結合されたネットワークオンチップ（ＮｏＣ）１２０を含む。図示されていないが、ＮｏＣ１２０は、ＳｏＣ１００内の様々な構成要素が互いに通信することを可能にするために、ＳｏＣ１００全体にわたって延在し得る。例えば、一物理的実装では、ＤＰＥアレイ１０５は、ＳｏＣ１００を形成する集積回路の右上部分に配置されてもよい。しかしそれにもかかわらず、アレイ１０５は、ＮｏＣ１２０を使用して、例えば、ＳｏＣ１００全体の異なる位置に配置され得るプログラマブルロジック（ＰＬ）１２５、プロセッササブシステム（ＰＳ）１３０、または入力／出力（Ｉ／Ｏ）１３５と通信することができる。
【0028】
ＤＰＥ１１０とＮｏＣ１２０との間のインターフェースを提供することに加えて、ＳｏＣインターフェースブロック１１５は、ＰＬ１２５内の通信ファブリックに直接接続を提供することもできる。この例では、データフローグラフ内のカーネルの一部が実行のためにＤＰＥ１１０に割り当てられ、他のカーネルがＰＬ１２５に割り当てられるため、ＰＬ１２５およびＤＰＥ１１０はヘテロジニアス処理システムを形成する。図１はＳｏＣ内のヘテロジニアス処理システムを示しているが、他の例では、ヘテロジニアス処理システムは複数のデバイスまたはチップを含むことができる。例えば、ヘテロジニアス処理システムは、同じタイプまたは異なるタイプの２つのＦＰＧＡまたは他の特殊化されたアクセラレータチップを含むことができる。さらに、ヘテロジニアス処理システムは、２つの通信可能に結合されたＳｏＣを含むことができる。
【0029】
これはプログラマにとって管理が困難であり得るが、それは、ヘテロジニアスまたは異なる処理コアに配置されたカーネル間の通信は、ＮｏＣ１２０、ＳｏＣインターフェースブロック１１５、ならびにアレイ１０５内のＤＰＥ１１０間の通信リンク（図２に示す）などの図１に示す様々な通信インターフェースを使用することを含むことができるからである。
【0030】
一実施形態では、ＳｏＣインターフェースブロック１１５は、ＤＰＥ１１０をＮｏＣ１２０およびＳｏＣ１００内のアレイ１０５の近くに配置されたＰＬ１２５に通信可能に結合するための別個のハードウェア構成要素を含む。一実施形態では、ＳｏＣインターフェースブロック１１５は、ＰＬ１２５用のファブリックに直接データをストリーミングすることができる。例えば、ＰＬ１２５は、ＳｏＣインターフェースブロック１１５がＮｏＣ１２０を使用せずにデータをストリーミングし、そこからデータを受信することができるＦＰＧＡファブリックを含むことができる。すなわち、本明細書で説明される回路スイッチングおよびパケットスイッチングは、ＤＰＥ１１０をＳｏＣインターフェースブロック１１５に、またＳｏＣ１００内の他のハードウェア化ブロックに通信可能に結合するために使用することができる。別の例では、ＳｏＣインターフェースブロック１１５は、ＤＰＥ１１０とは異なるダイに実装されてもよい。さらに別の例では、ＤＰＥアレイ１０５および少なくとも１つのサブシステムは同じダイに実装されてもよく、他のサブシステムおよび／または他のＤＰＥアレイは他のダイに実装される。さらに、ＤＰＥアレイ１０５内のＤＰＥ１１０に関して本明細書で説明されるストリーミング相互接続およびルーティングは、ＳｏＣインターフェースブロック１１５を介してルーティングされるデータにも適用することができる。
【0031】
図１はＰＬ１２５の１つのブロックを示しているが、ＳｏＣ１００は、ＳｏＣ１００内の異なる位置に配置することができるＰＬ１２５の複数のブロック（構成ロジックブロックとも呼ばれる）を含むことができる。例えば、ＳｏＣ１００は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を形成するハードウェア要素を含み得る。しかしながら、他の実施形態では、ＳｏＣ１００は、いかなるＰＬ１２５も含まなくてもよく、例えば、ＳｏＣ１００はＡＳＩＣである。
【0032】
図２は、一例による、図１に示すＤＰＥアレイ１０５内のＤＰＥ１１０のブロック図である。ＤＰＥ１１０は、相互接続２０５、コア２１０、およびメモリモジュール２３０を含む。相互接続２０５は、コア２１０およびメモリモジュール２３０からアレイ１０５内の異なるコアへのデータの転送を可能にする。すなわち、各ＤＰＥ１１０内の相互接続２０５は、データをＤＰＥ１１０のアレイ内の北および南（例えば、上下）ならびに東および西（例えば、左右）に転送できるように互いに接続することができる。
【0033】
図１に戻って参照すると、一実施形態では、アレイ１０５の上段のＤＰＥ１１０は、下段のＤＰＥ１１０の相互接続２０５に依存して、ＳｏＣインターフェースブロック１１５と通信する。例えば、ＳｏＣインターフェースブロック１１５にデータを送信するために、上段のＤＰＥ１１０内のコア２１０は、その相互接続２０５にデータを送信し、その相互接続は、下段のＤＰＥ１１０内の相互接続２０５に通信可能に結合されている。下段の相互接続２０５は、ＳｏＣインターフェースブロック１１５に接続されている。上段のＤＰＥ１１０を対象としたデータが最初にＳｏＣインターフェースブロック１１５から下段の相互接続２０５に送信され、次にターゲットＤＰＥ１１０である上段の相互接続２０５に送信される場合、プロセスは逆にされてもよい。このようにして、上段のＤＰＥ１１０は、下段のＤＰＥ１１０内の相互接続２０５に依存して、ＳｏＣインターフェースブロック１１５との間でデータを送受信することができる。
【0034】
一実施形態では、相互接続２０５は、相互接続２０５を介してデータがどのようにルーティングされるかをユーザが決定することを可能にする構成可能なスイッチングネットワークを含む。一実施形態では、パケットルーティングネットワークとは異なり、相互接続２０５は、ストリーミングポイントツーポイント接続を形成することができる。すなわち、相互接続２０５内のストリーミング接続およびストリーミング相互接続（図２には図示せず）は、コア２１０およびメモリモジュール２３０から隣接ＤＰＥ１１０またはＳｏＣインターフェースブロック１１５へのルートを形成することができる。構成されると、コア２１０およびメモリモジュール２３０は、これらのルートに沿ってストリーミングデータを送受信することができる。一実施形態では、相互接続２０５は、高度拡張インターフェース（ＡＸＩ）４ストリーミングプロトコルを使用して構成される。
【0035】
ストリーミングネットワークを形成することに加えて、相互接続２０５は、ＤＰＥ１１０内のハードウェア要素をプログラミングまたは構成するための別個のネットワークを含むことができる。図示されていないが、相互接続２０５は、ストリーミングネットワーク、コア２１０、およびメモリモジュール２３０の機能を変更または設定するＤＰＥ１１０内の構成レジスタの値を設定するために使用される異なる接続およびスイッチ要素を含むメモリマップド相互接続を含むことができる。
【0036】
一実施形態では、相互接続２０５内のストリーミング相互接続（またはネットワーク）は、本明細書では回路スイッチングおよびパケットスイッチングと呼ばれる２つの異なる動作モードをサポートする。一実施形態では、これらのモードの両方は、同じストリーミングプロトコル、例えばＡＸＩストリーミングプロトコルの一部であるか、またはそれと互換性がある。回路スイッチングは、ソースＤＰＥ１１０と１つまたは複数の宛先ＤＰＥ１１０との間の予約されたポイントツーポイント通信経路に依存する。一実施形態では、相互接続２０５内で回路スイッチングを行うときに使用されるポイントツーポイント通信経路は、（それらのストリームが回路スイッチングされるかパケットスイッチングされるかにかかわらず）他のストリームと共有されない。しかしながら、パケットスイッチングを使用して２つ以上のＤＰＥ１１０間でストリーミングデータを送信する場合、同一の物理的な配線を他のロジックストリームと共有することができる。
【0037】
コア２１０は、デジタル信号を処理するためのハードウェア要素を含むことができる。例えば、コア２１０は、無線通信、レーダ、ベクトル演算、機械学習アプリケーションなどに関連する信号を処理するために使用することができる。このように、コア２１０は、プログラムメモリ、命令フェッチ／復号ユニット、固定小数点ベクトルユニット、浮動小数点ベクトルユニット、算術論理演算ユニット（ＡＬＵ）、乗算アキュムレータ（ＭＡＣ）などを含むことができる。しかしながら、上述したように、本開示はＤＰＥ１１０に限定されない。コア２１０内のハードウェア要素は、エンジンタイプに応じて変化し得る。すなわち、デジタル信号処理エンジン、暗号化エンジン、またはＦＥＣのコアは異なっていてもよい。
【0038】
メモリモジュール２３０は、ダイレクトメモリアクセス（ＤＭＡ）エンジン２１５、メモリバンク２２０、およびハードウェア同期回路（ＨＳＣ）２２５または他のタイプのハードウェア同期ブロックを含む。一実施形態では、ＤＭＡエンジン２１５は、相互接続２０５によるデータの受信および相互接続２０５へのデータの送信を可能にする。すなわち、ＤＭＡエンジン２１５を使用して、ＳｏＣインターフェースブロックまたはアレイ内の他のＤＰＥ１１０から相互接続２０５を介して受信されたデータを使用して、メモリバンク２２０に対するＤＭＡ読み出しおよび書き込みを実行することができる。
【0039】
メモリバンク２２０は、任意の数の物理メモリ要素（例えば、ＳＲＡＭ）を含むことができる。例えば、メモリモジュール２３０は、４、８、１６、３２個などの異なるメモリバンク２２０を含むことができる。この実施形態では、コア２１０は、メモリバンク２２０への直接接続２３５を有する。言い換えれば、コア２１０は、相互接続２０５を使用せずに、メモリバンク２２０にデータを書き込み、またはメモリバンク２２０からデータを読み出すことができる。すなわち、直接接続２３５は、相互接続２０５とは別個であってもよい。一実施形態では、直接接続２３５内の１つまたは複数のワイヤは、コア２１０を、メモリバンク２２０に結合されるメモリモジュール２３０内のメモリインターフェースに通信可能に結合する。
【0040】
一実施形態では、メモリモジュール２３０はまた、隣接ＤＰＥ１１０内のコアへの直接接続２４０を有する。言い換えると、アレイ内の隣接ＤＰＥは、それらの相互接続または図２に示す相互接続２０５に依存することなく、直接隣接接続２４０を使用してメモリバンク２２０からデータを読み出し、またはメモリバンク２２０にデータを書き込むことができる。ＨＳＣ２２５は、メモリバンク２２０へのアクセスを管理または保護するために使用することができる。一実施形態では、コア２１０または隣接ＤＰＥ内のコアがメモリバンク２２０からデータを読み出し、またはメモリバンク２２０にデータを書き込むことができる前に、ＨＳＣ２２５は、メモリバンク２２０の割り当てられた部分（「バッファ」と呼ばれる）にロックを提供する。すなわち、コア２１０がデータを書き込みたいとき、ＨＳＣ２２５は、メモリバンク２２０（または複数のメモリバンク２２０）の一部をコア２１０に割り当てるロックをコア２１０に提供する。書き込みが完了すると、ＨＳＣ２２５はロックを解除することができ、これにより隣接ＤＰＥ内のコアがデータを読み出すことができる。
【0041】
コア２１０および隣接ＤＰＥ１１０内のコアはメモリモジュール２３０に直接アクセスすることができるので、メモリバンク２２０は、ＤＰＥ１１０間の共有メモリと見なすことができる。すなわち、隣接ＤＰＥは、メモリバンク２２０と同じＤＰＥ１１０内にあるコア２１０と同様の方法でメモリバンク２２０に直接アクセスすることができる。したがって、コア２１０が隣接ＤＰＥ内のコアにデータを送信したい場合、コア２１０はメモリバンク２２０にデータを書き込むことができる。次いで、隣接ＤＰＥは、メモリバンク２２０からデータを取り出し、データの処理を開始することができる。このようにして、隣接ＤＰＥ１１０内のコアは、相互接続２０５を使用するときに導入される余分なレイテンシを回避しながら、ＨＳＣ２２５を使用してデータを転送することができる。対照的に、コア２１０がアレイ内の非隣接ＤＰＥ（すなわち、メモリモジュール２３０への直接接続２４０のないＤＰＥ）にデータを転送したい場合、コア２１０は、相互接続２０５を使用してターゲットＤＰＥのメモリモジュールにデータをルーティングするが、これは、相互接続２０５を使用するレイテンシが追加されるため、およびデータが共有メモリモジュールから読み取られるのではなくターゲットＤＰＥのメモリモジュールにコピーされるため、完了するのに時間がかかる場合がある。
【0042】
メモリモジュール２３０を共有することに加えて、コア２１０は、コア間通信リンク（図示せず）を使用して隣接ＤＰＥ１１０内のコア２１０に直接接続することができる。すなわち、共有メモリモジュール２３０または相互接続２０５のいずれかを使用する代わりに、コア２１０は、メモリモジュール２３０にデータを記憶することなく、または相互接続２０５（バッファまたは他のキューを有することができる）を使用することなく、アレイ内の別のコアにデータを直接送信することができる。例えば、コア間通信リンクを使用した通信は、相互接続２０５または共有メモリを使用してデータを送信する（データを書き込むためにコアを必要とし、次いでデータを読み取るために別のコアを必要とする）よりも少ないレイテンシを使用する（または高帯域幅を有する）ことができ、これにより、より費用効果の高い通信を提供することができる。一実施形態では、コア間通信リンクは、１つのクロックサイクルで２つのコア２１０間でデータを送信することができる。一実施形態では、データは、コア２１０の外部のいかなるメモリ要素にも記憶されることなく、リンク上のコア間で送信される。一実施形態では、コア２１０は、クロックサイクルごとにリンクを使用して隣接コアにデータワードまたはベクトルを送信することができるが、これは要件ではない。
【0043】
一実施形態では、通信リンクは、コア２１０が隣接コアにデータをストリーミングすることを可能にするストリーミングデータリンクである。さらに、コア２１０は、アレイ内の異なるコアに拡張することができる任意の数の通信リンクを含むことができる。この例では、ＤＰＥ１１０は、コア２１０の左右（東および西）および上下（北または南）にあるアレイ内のＤＰＥに位置するコアへのそれぞれのコア間通信リンクを有する。しかしながら、他の実施形態では、図２に示すＤＰＥ１１０内のコア２１０はまた、コア２１０から対角線上に配置されたコアへのコア間通信リンクを有してもよい。さらに、コア２１０がアレイの底部周辺または縁部に配置されている場合、コアは、コア２１０の左、右、および底部のコアのみへのコア間通信リンクを有することができる。
【0044】
しかしながら、コア２１０によって生成されたデータの宛先が隣接コアまたはＤＰＥである場合、メモリモジュール２３０内の共有メモリまたはコア間通信リンクを使用することが可能であり得る。例えば、データが非隣接ＤＰＥ（すなわち、ＤＰＥ１１０が直接隣接接続２４０またはコア間通信リンクを有しない任意のＤＰＥ）に向けられている場合、コア２１０は、ＤＰＥ内の相互接続２０５を使用してデータを適切な宛先にルーティングする。上述したように、ＤＰＥ１１０内の相互接続２０５は、ＳｏＣが起動されて、動作中にコア２１０がデータを送信する非隣接ＤＰＥへのポイントツーポイントストリーミング接続を確立するときに構成することができる。
【0045】
図３Ａ～図３Ｂは、一例による、ＤＰＥアレイ内の複数のＤＰＥ１１０によって共有されるメモリモジュール２３０Ａを示す。図示のように、メモリモジュール２３０Ａは、４つのコア、すなわちコア２１０Ａ～２１０Ｄへの直接接続を有する。メモリモジュール２３０Ａは、コア２１０Ａと同じＤＰＥ（すなわち、ＤＰＥ１１０Ａ）内にある。したがって、直接接続２３５はエンジン内接続である。ただし、メモリモジュール２３０Ａは、コア２１０Ｂ～２１０Ｄとは異なるＤＰＥ内にある。このように、直接隣接接続２４０Ａ～２４０Ｃはエンジン間接続であり、これは、これらの接続２４０がアレイ内のＤＰＥ１１０間のインターフェースにまたがるためである。明確にするために、各ＤＰＥ１１０内の相互接続は省略されている。
【0046】
図３Ａにおいて、ＤＰＥ１１０Ａ内のメモリモジュール２３０Ａは、コア２１０Ａの右に配置されている。ＤＰＥ１１０Ａの右に位置する（すなわち、ＤＰＥ１１０Ａの東にある）ＤＰＥ１１０Ｄについても同様である。したがって、ＤＰＥ１１０Ｄ内のコア２１０Ｄは、メモリモジュール２３０Ａに直接隣接し、これにより、メモリモジュール２３０Ｄがコア２１０Ｄの左に配置された場合、すなわちメモリモジュール２３０Ｄがメモリモジュール２３０Ａとコア２１０Ｄとの間に配置された場合よりも、メモリモジュール２３０Ａとコア２１０Ｄとの間に直接隣接接続２４０Ｂを確立することが容易になる。
【0047】
ＤＰＥ１１０Ａおよび１１０Ｄと異なり、ＤＰＥ１１０Ｂおよび１１０Ｃ内では、メモリモジュール２３０Ｂおよび２３０Ｃの右にコア２１０Ｂおよび２１０Ｃが配置されている。これにより、コア２１０Ｂおよび２１０Ｃは、メモリモジュール２３０Ａの真上および真下に配置される（すなわち、コア２１０Ｂおよび２１０Ｃは、メモリモジュール２３０Ａの北および南である）。これにより、コア２１０Ｂおよび２１０Ｃをメモリモジュール２３０Ｂおよび２３０Ｃの左に配置した場合よりも、共有メモリモジュール２３０Ａとコア２１０Ｂおよび２１０Ｃとの直接隣接接続２４０Ａおよび２４０Ｃを容易に確立することができる。図３Ａに示す構成を使用して、メモリモジュール２３０Ａは、同じＤＰＥおよび隣接ＤＰＥに位置するコア２１０Ａ～２１０Ｄへの直接接続２３５および２４０を有し、これは、メモリモジュール２３０ＡがＤＰＥ１１０Ａ～１１０Ｄのための共有メモリであることを意味する。図３Ａは、４つのコア２１０間でメモリモジュール２３０Ａを共有することを示しているが、他の実施形態では、メモリモジュール２３０Ａは、より多いまたはより少ないコアによって共有されてもよい。例えば、メモリモジュール２３０Ａはまた、ＤＰＥ１１０Ａに対して対角線上に配置された隣接ＤＰＥへの直接接続を有してもよい。
【0048】
図３Ａに示すＤＰＥ１１０の配置は、隣接コア２１０からメモリモジュール２３０Ａへの直接接続を提供するためのＤＰＥ１１０の適切な配置の一例にすぎない。図３Ｂでは、異なる行のＤＰＥ１１０が互い違いになっている。すなわち、同一列のＤＰＥ１１０を整列させる代わりに、ＤＰＥ１１０をオフセットさせる。この構成では、コア２１０Ｂおよび２１０Ｃは、（図３Ａに示されているものとは異なり）メモリモジュール２３０Ｂおよび２３０Ｃの左に配置され、ＤＰＥ１１０Ｂおよび１１０ＣをＤＰＥ１１０Ａに対して右にシフトすることによって、依然として共有メモリモジュール２３０Ａの真上および真下にある。したがって、メモリモジュール２３０Ａがコア２１０Ａ～２１０Ｄによって共有されることを可能にするために、直接接続２４０Ａ～２４０ＣをＳｏＣに形成することができる。
【0049】
さらに、図３Ａおよび図３Ｂには示されていないが、メモリモジュール２３０Ｂ～２３０Ｄはまた、共有メモリモジュールであってもよい。例えば、メモリモジュール２３０Ｄは、ＤＰＥ１１０Ｄの上、下、および右（すなわち、北、南、および東）に配置されたＤＰＥ内のコアへの直接接続を有することができる。このように、メモリモジュール２３０Ｄは、隣接ＤＰＥのコアと共有することができる。しかしながら、アレイの縁部または周辺に配置されたＤＰＥ内のメモリモジュール２３０は、より少ない数のコアによって共有されてもよい（または全く共有されなくてもよい）。
【0050】
図４は、一例による、図１に示すＳｏＣ１００上でデータフローグラフ４４０を実装するためのコンピューティングシステム４００のブロック図である。システム４００は、プロセッサ４１０およびメモリ４１５を含むホスト４０５（例えば、ホストコンピューティングシステム）を含む。プロセッサ４１０は、各々が任意の数の処理コアを含むことができる任意の数の処理要素を表す。メモリ４１５は、揮発性および不揮発性メモリ要素を含むことができる。さらに、メモリ４１５は、同じ装置（例えば、サーバ）内に配置することができ、またはコンピューティングシステム４００（例えば、クラウドコンピューティング環境）にわたって分散させることができる。
【0051】
メモリ４１５は、グラフソースコード４２０、カーネルソースコード４２５、制御ソースコード４３０を生成するためのヘテロジニアスプログラミング環境４１７を含む。メモリ４１５はまた、コンパイラ４３５を含む。グラフソースコード４２０は、様々な種類のオブジェクト指向プログラミング言語（例えば、Ｃ＋＋、Ｐｙｔｈｏｎ、Ｊａｖａｓｃｒｉｐｔ（登録商標）、Ｓｗｉｆｔ、Ｇｏ、ＬａｂＶｉｅｗ、またはＳｉｍｕｌｉｎｋ）で記述することができる。一般に、グラフソースコード４２０は、通信リンク（例えば、エッジ）を介して接続されるカーネル（例えば、ノード）を定義する。カーネルと通信リンクとの組み合わせは、グラフ４４０を形成する。
【0052】
ソースコード４２０を使用してデータフローグラフ４４０を定義するためのヘテロジニアスプログラミング環境４１７を提供することの１つの利点は、ヘテロジニアス処理システム上でデータフローグラフをコンパイルする異なる態様を、ヘテロジニアスプログラミング環境４１７で直接表現および制御できることである。プログラマは、並列定義（例えば、グラフ）から始めることができ、次にこれをコンパイラ４３５がＳｏＣ１００のハードウェアに実装する。グラフ４４０は、データがノード（例えば、カーネル）間で連続的なパイプライン方式で流れることを可能にする。ノードは、その入力におけるデータが利用可能になるとすぐに処理を開始し、そうでなければストールする。さらに、グラフ４４０は、計算およびデータフローをＳｏＣ１００内のＤＰＥ１１０およびプログラマブルロジック１２５にマッピングするための大きな自由度をプログラマに提供する。
【0053】
様々なタイプのデータフローグラフを使用することができるが、一実施形態では、グラフソースコード４２０によって確立されるグラフ４４０のセマンティクスは、ＳｏＣ１００のヘテロジニアスアーキテクチャ（プログラマブルブロックとハードウェア化ブロックの両方を含む）に適用される決定論的並列計算のための計算モデルを提供するカーンプロセスネットワークの一般理論に基づいている。さらに、グラフソースコード４２０は、グラフ４４０内のノード間の通信レイテンシに対して耐性があり、結果として、複数のスーパーロジック領域および複数のＳｏＣデバイス（例えば、複数のＦＰＧＡ）にマッピングするグラフに自然に拡張する。例えば、グラフソースコード４２０は、コンパイラが第１のチップ（例えば、ＳｏＣ、ＦＰＧＡなど）に割り当てる第１の複数のカーネルと、コンパイラが第２のチップに割り当てる第２の複数のカーネルとを含むことができる。第１および第２の複数のカーネルは、同じデータフローグラフの一部とすることができ、したがって、第１および第２のチップ上で実行されるときに互いに通信することができる。
【0054】
ソースコード４２０を使用してデータフローグラフを定義することの別の利点は、対照的に、シーケンシャルプログラムが制御フローおよび計算の順序を固定することである。データフローグラフを使用する場合、入力に対する予測可能かつ再現可能な応答が競合状態なしで得られる。デッドロックのリスクがあるが、これは、各ノードまたはカーネルに割り当てられた記憶装置を管理することによって解決または緩和することができる。
【0055】
カーネルソースコード４２５は、様々なタイプのオブジェクト指向プログラミング言語で記述することができる。カーネルソースコード４２５は、データフローグラフ４４０内の特定のカーネルまたはノードの属性を定義する。一実施形態では、カーネルソースコード４２５は、グラフソースコード４２０内の各カーネルの動作を定義する。
【0056】
制御ソースコード４３０は、様々なタイプのオブジェクト指向プログラミング言語で記述することができる。一実施形態では、制御ソースコード４３０は制御プログラムを定義し、これは実行されると、ＳｏＣ１００上に実装されるときにグラフ４４０の実行を制御する。例えば、制御ソースコード４３０は、グラフ４４０をいつ実行するか、グラフ４４０を実行する反復回数、およびグラフ４４０の実行をいつ停止するかを制御することができる。制御ソースコード４３０から生成された制御プログラムは、ホスト４０５上（例えば、データセンタのソリューション）またはＳｏＣ１００内（例えば、ＰＳ１３０）で実行することができる。
【0057】
コンパイラ４３５は、ソースコード４２０、４２５、４３０をコンパイルすることができるソフトウェアアプリケーションである。例えば、グラフソースコード４２０（および図４に示されていない他のライブラリ）を使用して、コンパイラ４３５は、以下でより詳細に説明するＳｏＣ１００上に実装することができるグラフ４４０を生成することができる。一実施形態では、グラフ４４０は、ＳｏＣ１００内のプログラマブルロジックを構成するビットストリーム４４５（例えば、ＰＬ１２５、ＮｏＣ１２０、ＳｏＣインターフェースブロック１１５、およびＩ／Ｏ１３５）と、ＳｏＣ１００内のソフトウェア構成可能なハードウェア化ロジック（例えば、ＤＰＥ１１０およびＰＳ１３０）を構成するバイナリコード４４７（多くのターゲットコマンドを含むことができる）とを含む。ビットストリーム４４５およびバイナリコード４４７は、メモリバスを介してＳｏＣ１００に送信され、グラフ４４０を実行するようにＳｏＣ１００を構成することができる。
【0058】
図５は、一例による、プログラマブルロジックおよびソフトウェア構成可能なハードウェア化ロジックを有するＳｏＣ上でデータフローグラフを実装するためにソースコードをコンパイルするための方法５００のフローチャートである。ブロック５０１において、ホストは、データフローグラフをオブジェクト指向ソースコード（例えば、Ｃ＋＋、Ｐｙｔｈｏｎ、Ｊａｖａｓｃｒｉｐｔ（登録商標）、Ｓｗｉｆｔ、Ｇｏ、ＬａｂＶｉｅｗ、またはＳｉｍｕｌｉｎｋ）として定義するためのヘテロジニアスなプログラミング環境を提供する。すなわち、プログラマは、ヘテロジニアスプログラミング環境（図６でより詳細に説明されている）を使用して、データフローグラフを定義するソースコードを生成する。ブロック５０５において、コンパイラは、カーネルおよびカーネル間の通信リンクを定義するデータフローグラフを確立するソースコードを受信する。一実施形態では、コンパイラによって受信されたソースコードは、グラフソースコードを含む。
【0059】
【0060】
図６は、一例による、データフローグラフを定義するためのグラフソースコード４２０である。すなわち、図６は、プログラマがデータフローグラフを確立するための複数のカーネルおよび通信リンクを定義することを可能にするヘテロジニアスプログラミング環境で生成されたグラフソースコード４２０の一例である。ソースコード４２０は、ソースコード４２０内にデータフローグラフを定義するために使用することができる１つまたは複数のライブラリを参照することができる名前空間「Ｎａｍｅｓｐａｃｅ Ａ」を使用する。一実施形態では、グラフソースコード４２０は、プログラマがカーネル６０５および通信リンク６２０を使用して構築するヘテロジニアスプログラミング環境においてデータ構造を確立することを考えることができる。
【0061】
この例では、グラフソースコード４２０は、ａ、ｂ、ｃ、ｄ、ｅ、ｆの６つのカーネル６０５を含む。カーネル６０５は、クラス「ｒａｄｉｏ」内で定義される。図６は、無線機能を実行するためのソースコード４２０を示しているが、上述したように、本明細書に記載の技術は、レーダ、ベクトル演算、機械学習アプリケーションなどの複数の異なる機能に使用することができる。
【0062】
ソースコード４２０は、カーネル６０５の各々によって実行される機能または動作を定義するラッパー６１０Ａ～６１０Ｆを含む。ラッパー６１０は、対応するＣ＋＋関数（例えば、ｐｏｌａｒｃｌｉｐ、ｆｅｅｄｂａｃｋ、ｅｑｕａｌｉｚｅｒ、ｆｉｒ＿ｔａｐ１１、ｆｉｒ＿ｔａｐ７、およびｓｃａｌｅ）を呼び出す機構を作成する。すなわち、ラッパー６１０は、プログラマが別のＣ＋＋ライブラリの一部であり得る例示的な関数を使用してカーネルを定義することを可能にする。この例では、カーネル６０５は単一の命令ではなく複数の関数呼び出しである。一実施形態では、カーネル６０５は、カーネル６０５がそのすべてのトリガ入力からデータを受信したときにのみ実行し、非ブロッキング方式で実行して、下流のカーネル６０５に送信することができる出力を生成する。カーネルはまた、アクセスされたときにストリームデータが存在しない場合、ストリーム入力に対する実行中にブロックすることができる。
【0063】
ラッパー６１０を使用して関数呼び出しとしてカーネルを抽象化することの１つの利点は、そうすることが、プログラマがＤＰＥまたはプログラマブルロジック上で実行されるべきカーネルを同じ均一なフレームワークで表現できることを意味することである。プログラマはカーネル６０５を様々に記述するが、カーネル６０５は同じ方法でパッケージ化され、同じフレームワークで表現することができる。プログラマは、ＤＰＥに割り当てられたカーネルをＰＬファブリックに割り当てられたカーネルと統合することを気にする必要がない。ここで、プログラマは、グラフソースコード４２０内の通信リンク６２０のタイプを選択または指示し、それらのタイプの通信リンク６２０を使用するカーネル６０５間のすべての同期は、コンパイラによって処理される。
【0064】
ソースコード４２０はまた、コンパイラがソースコード４２０で定義されたオブジェクト（例えば、カーネル６０５および通信リンク６２０）をＳｏＣ内のハードウェアにどのようにマッピングするかを制限する命令を含む制約６１５を含む。この例では、制約６１５は、カーネルａおよびカーネルｆをＤＰＥに割り当てるのではなく、ＳｏＣ内のファブリック（例えば、プログラマブルロジック）に割り当てるようにコンパイラに命令する。以下に説明する理由から、カーネルａおよびカーネルｆをＤＰＥではなくファブリックに割り当てることにより、性能を向上させることができる。したがって、グラフソースコード４２０は、プログラマがカーネル６０５をＳｏＣ内のハードウェアに割り当てることを必要としない（したがって、プログラマはＳｏＣの基礎となるハードウェアアーキテクチャを理解する必要がない）が、プログラマに提供される名前空間は、プログラマがそうすることが性能を向上させることを知っている場合、制約６１５を使用してコンパイラにカーネル６０５のうちの１つまたはすべてを割り当てる方法を命令することを可能にする。
【0065】
通信リンク６２０は、カーネル６０５間でデータがどのように通信されるかを定義する。例えば、通信リンク６２０Ａは、ストリーミングデータを６４バイト長のウィンドウデータに変換することを示す。さらに、各ウィンドウは、８バイトのオーバーラップを伴って送信される。しかしながら、通信リンク６２０Ｂの場合、長さ３２バイトのウィンドウ処理データは、いかなるオーバーラップデータもなしにカーネルｂとカーネルｃとの間で送信される。ウィンドウ処理データ（およびウィンドウの重ね合わせ）の詳細については、以下でより詳細に説明する。
【0066】
さらに、各通信リンク６２０は、アップストリームカーネル上のどのポートがダウンストリームカーネル上のどのポートに接続されるかを定義する。例えば、リンク６２０Ａにおいて、カーネルａの出力ポートａ．ｏｕｔ［０］は、カーネルｂの入力ポートｂ．ｉｎ［０］に結合される。各カーネルは、複数の入力ポートおよび複数の出力ポートを有することができる。例えば、通信リンク６２０Ｄでは、カーネルｄの第１の出力ポートｄ．ｏｕｔ［１］が入力ポートｅ．ｉｎ［０］に結合される。また、通信リンク６２０Ｆでは、カーネルｄの第２の出力ポートｄ．ｏｕｔ［０］が入力ポートｆ．ｉｎ［０］に結合される。
【0067】
グラフソースコード４２０がカーネル６０５を同じ均一なフレームワークで表現できるように抽象化する方法と同様に、ソースコード４２０は、通信リンク６２０上の同期をプログラマから抽象化（または非表示化）することができる。以下でより詳細に説明するように、コンパイラは、カーネル６０５がファブリック内にあるかＤＰＥアレイ内にあるか、またはカーネル６０５がＤＰＥアレイ内で隣接しているかどうかに基づいて、カーネル６０５間でデータを送信するための最適な通信技術を選択することができる。
【0068】
一実施形態では、グラフソースコード４２０内にカーネル６０５、ラッパー６１０、制約６１５、および通信リンク６２０を定義する能力は、プログラマがデータフローグラフを実装するオブジェクト指向ソースコードを生成することを可能にするヘテロジニアスプログラミング環境によって提供される（および名前空間内のライブラリによってサポートされる）ツールである。
【0069】
図７は、一例による、図６のソースコード４２０によって定義されたデータフローグラフ４４０を示す。すなわち、グラフ４４０は、グラフソースコード４２０によって定義されたグラフのグラフィック表現である。図示のように、グラフ４４０は、通信リンク６２０Ａ～６２０Ｅを使用して通信可能に結合された６つのカーネルａ～ｆを含む。さらに、グラフ４４０は、カーネルａにデータを転送する入力７０５と、カーネルｆの出力からデータを受信する出力７１０とを含む。入力７０５で受信されたデータは、例えば、ホスト上で実行されているアプリケーション、無線送受信機、カメラによって、またはファイルもしくはデータベースから提供することができる。出力７１０は、グラフ４４０によって処理されたデータをホストまたはファイルもしくはデータベースに送信することができる。
【0070】
図７は、カーネル（例えば、ノード）がそれぞれの入力ポートおよび出力ポートにおいてリンク６２０によって結合されているグラフ４４０の概略図である。すなわち、図７は、リンク６２０Ａ～６２０Ｆを使用したカーネルａ～ｆ間のデータフローを示しているが、カーネルが実行されるハードウェア実装または使用されている特定のタイプの通信リンク６２０、例えば、共有メモリ、ＮｏＣ、ＤＭＡなどを示していない。それにもかかわらず、プログラマは、図７に示す抽象図でグラフ４４０を設計することができ、次いで、コンパイラは、ＳｏＣのハードウェアにカーネルａ～ｆおよび通信リンク６２０を実装することができる。
【0071】
図８は、一例による、データフローグラフにおいてカーネルを定義するためのカーネルソースコード４２５である。一実施形態では、図６のソースコード内のラッパー６１０は、カーネルによって定義された関数の引数がポートとしてアクセスされることを可能にする。図８において、カーネルソースコード４２５は、入力データへのポインタ（すなわち、＊ｉｎｐｕｔｗ）および出力データへのポインタ（＊ｏｕｔｐｕｔｗ）を指定する引数８０５を含む。上記のように２つのカーネルがリンクによって通信可能に結合される場合、コンパイラは、カーネルが呼び出されるときにカーネル（またはカーネルによって呼び出される関数）に供給されるデータメモリを割り当てることができる。一実施形態では、カーネルは、アプリケーションプログラミングインターフェース（ＡＰＩ）を使用して引数８０５によって提供される入力データに対して動作する。
【0072】
図８において、カーネルソースコード４２５は、入力データが出力される前に入力データを処理するためのウィンドウＡＰＩを含む。例えば、ｗｉｎｄｏｗ＿ｒｅａｄｉｎｃｒは、ポインタｉｎｐｕｔｗを使用して次のウィンドウを読み出すＡＰＩである。ここでは一般にｓｂｕｆｆを使用して数学的演算を実行するものとして示されている動作が実行されると、別のＡＰＩを使用して、処理されたデータ、例えばｗｉｎｄｏｗ＿ｗｒｉｔｅｉｎｃｒを出力することができる。
【0073】
一実施形態では、プログラマは、グラフソースコードで定義された各カーネルについてカーネルソースコードを生成する。しかしながら、グラフソースコードが同じカーネルの複数のインスタンスを有する場合、これらの複数のインスタンスは、同じカーネルソースコードを使用して定義することができる。
【0074】
方法５００に戻ると、ブロック５１０において、コンパイラはソースコード（例えば、グラフ、カーネル、および制御ソースコード）をコンパイルする。説明を容易にするために、このコンパイルは少なくとも３つのサブブロックに分割される。ブロック５１５において、コンパイラは、ＳｏＣ内のＤＰＥおよびプログラマブルロジックにカーネルを割り当てる。コンパイラは、ソースコードにおいてプログラマによって提供される制約（例えば、図６の制約６１５）を使用することができるが、制約がない場合、グラフソースコード内のカーネルをＳｏＣ内のＤＰＥおよびプログラマブルロジックに割り当てることができる。
【0075】
一実施形態では、コンパイラは、グラフを評価して、ＳｏＣ内のハードウェアにカーネルをどのように割り当てるかを決定する。例えば、２つのカーネルがグラフ内で互いに通信可能に結合されている場合、コンパイラは、ＤＰＥ間の共有メモリなどのより高速な通信プロトコルを利用するために、ＤＰＥアレイ内の隣接ＤＰＥにカーネルを割り当てることができる。さらに、コンパイラは、複数のカーネルを同じＤＰＥに割り当てることができるかどうかを判定するために、各カーネルによって使用されるサイクル数および時間の割合を決定することができる。
【0076】
図９は、一例による、図７のデータフローグラフ４４０を実装する概略図である。図９は、カーネルａ～ｆならびに通信リンク６２０を示す。さらに、図９は、ＳｏＣにおいてカーネルが割り当てられるハードウェアを示す。図示のように、カーネルａおよびカーネルｆはＰＬ１２５に配置され、カーネルｂおよびカーネルｃはＤＰＥ１１０Ａに実装され、カーネルｄおよびカーネルｅはＤＰＥ１１０Ｂに実装される。
【0077】
一実施形態では、コンパイラは、グラフソースコードに提供された制約に基づいて、カーネルａおよびカーネルｆをＰＬ１２５に配置することを選択した。しかしながら、別の実施形態では、コンパイラは、これらのカーネルを入力／出力カーネルとして認識している可能性があり、これはＤＰＥではなくプログラマブルロジックに実装するのにより適している可能性がある。
【0078】
コンパイラは、各カーネルのサイクル数の推定された割合を使用して、またはプログラマからの制約に応答して、カーネルｂおよびカーネルｃを同じＤＰＥ１１０Ａに割り当てることができる。これは、一般にクラスタリングと呼ばれる。例えば、カーネルｂがＤＰＥ１１０Ａのサイクル数の４０％のみを使用し、カーネルｃがサイクル数の５５％のみを使用する場合、コンパイラはそれらを同じＤＰＥ１１０Ａに配置することができる。別の例では、プログラマは、制約を使用して、カーネルｂおよびカーネルｃを同じＤＰＥ１１０Ａに配置するようにコンパイラに命令することができる。そのようにして、プログラマはグラフを並列化されたデータ構造として記述するが、プログラマはカーネルの推定サイクル数を使用して、カーネルのいくつかを強制的にシーケンシャルにする、すなわち同じＤＰＥに割り当てることができる。すなわち、各ＤＰＥは一度に１つのタスクのみを実行することができる（すなわち、平行化されていない）ので、２つの異なるカーネルを同じＤＰＥに配置することは、カーネルがそれら自体のＤＰＥに割り当てられるシナリオではなく、カーネルのうちの１つのみが一度に実行することができることを意味する。しかしながら、このクラスタリングは、依然として全体のサイクル数を満たす。
【0079】
方法５００に戻ると、ブロック５２０において、コンパイラは、カーネル間の接続をストリーミングまたはウィンドウ処理に割り当てる。一実施形態では、これらの接続は、グラフソースコードに定義された通信リンクによって制御される。すなわち、プログラマは、各カーネル対の間でデータをどのように渡すべきかを示すことができる。別の例では、コンパイラは、相互接続２０５を介してメモリバンク２２０から別のＤＰＥ１１０にウィンドウデータを転送するために、あるＤＰＥ１１０のメモリモジュール２３０内のＤＭＡエンジン２１５を割り当てる。さらに別の例では、コンパイラは、相互接続２０５上のストリームチャネルおよび受信コア２１０または受信ＤＭＡエンジン２１５上のストリームチャネルを割り当てる。
【0080】
ブロック５２５において、コンパイラは、カーネル間でデータを転送するための同期技術を選択する。これは図９に示されており、通信リンク６２０Ａ～６２０Ｆ（この例では、ウィンドウ処理を使用する）は、カーネル間でデータを送信するためにダブルバッファ９０５またはシングルバッファ９１０のいずれかを含む。カーネルａとカーネルｂとの間のリンク６２０Ａおよびカーネルｄとカーネルｆとの間のリンク６２０Ｆの場合のように、カーネルが異なる（またはヘテロジニアスの）処理コア（例えば、ＤＰＥ１１０に対するＰＬ１２５）上にある場合、コンパイラはダブルバッファ９０５を割り当てる。さらに、カーネルｃとカーネルｄとの間のリンク６２０Ｃおよびカーネルｅとカーネルｂとの間のリンク６２０Ｅの場合のように、カーネルが異なるＤＰＥ上にある場合、コンパイラは再びダブルバッファ９０５を使用する。しかしながら、カーネルｂとカーネルｃとの間のリンク６２０Ｂおよびカーネルｄとカーネルｅとの間のリンク６２０Ｄの場合のように、同じＤＰＥ上のカーネル間でデータを転送するために、コンパイラはシングルバッファ９１０を割り当てることができる。後述するように、シングルバッファリングは、ダブルバッファリングよりも低いレイテンシを提供することができる。
【0081】
コンパイラはまた、ダブルまたはシングルバッファリングを実行するときにカーネル間の同期を処理する。例えば、ダブルバッファリングを実行するとき、コンパイラは、シングルバッファリングを実行するときに必要とされない可能性があるダブルバッファ９０５にアクセスするためのロックプロトコルを確立することができる（例えば、カーネルが同じＤＰＥ１１０上にある場合）。別の例では、コンパイラは、ダブルバッファ９０５に対してピンポン同期技術を選択することができる。いずれの場合でも、プログラマによってソースコード内に提供されたパラメータを使用して、コンパイラによって同期を確立することができる。
【0082】
方法５００に戻ると、ブロック５１０において、コンパイラは、コンパイルされたソースコードを使用してデータフローグラフを実行するようにＳｏＣを構成するためのビットストリームおよび／またはバイナリコード（例えば、一連のメモリマップドストアトランザクション）を送信する。すなわち、ＳｏＣは、ビットストリーム／バイナリコードを受信し、次いで、コンパイラによって規定されたハードウェア要素を使用してグラフを実行することができる。コンパイラは、各カーネルがＳｏＣ内のどこに配置されるべきか、それらのカーネル間の通信リンクのタイプ、および通信リンクによって使用される同期を決定することができる。
【0083】
図１０は、一例による、ＳｏＣにおいて図７のデータフローグラフを実装するハードウェア図１０００である。すなわち、ハードウェア図１０００は、図７に示すデータフローグラフを実装するために使用されるＳｏＣの一部を示す。この例では、図７は、ＰＬ１２５と、５つのコア２１０および５つのメモリモジュール２３０を含むＤＰＥアレイ内のＤＰＥの少なくとも一部とを含むＳｏＣの一部を示す。
【0084】
カーネルａおよびカーネルｆは、ＰＬ１２５内の構成可能ロジックブロック（ＣＬＢ）を使用して形成される。カーネルａは、相互接続２０５を介してメモリモジュール２３０Ａに通信可能に結合される。図示されていないが、カーネルａとメモリモジュール２３０Ａとの間のこの通信リンクはまた、ＤＰＥアレイ内のコア２１０がＳｏＣ内の他のハードウェアモジュール（例えば、ＰＬ１２５）と通信することを可能にするＮｏＣおよびＳｏＣインターフェースブロックを含むことができる。この実施形態では、カーネルａは、メモリモジュール２３０Ａ内のＤＭＡエンジン２１５Ａにデータを送信し、メモリモジュール２３０Ａは、受信したデータをメモリバンク２２０Ａ内のダブルバッファ９０５Ａに格納する。したがって、コンパイラは、メモリバンク２２０Ａにダブルバッファ９０５Ａを割り当てることによって、図９に示す通信リンク６２０Ａを実装することを決定した。ＤＭＡ書き込みを使用して、カーネルａは、コア２１０Ｂにホストされるカーネルｂによってアクセスされ得るデータをダブルバッファ９０５Ａに格納することができる。
【0085】
この例では、ダブルバッファ９０５Ａには、メモリバンク２２０Ａ内の４つのバンクが割り当てられている。一実施形態では、各メモリバンクは１２８バイトを保持し、これはダブルバッファ９０５Ａの合計サイズが５１２バイトであることを意味する。しかしながら、コンパイラは、カーネルａおよびカーネルｂの予想される必要性に応じて、より多くのメモリバンクまたはより少ないメモリバンクをダブルバッファ９０５Ａに割り当てることができる。カーネルａは、カーネルｂがバッファ９０５Ａ内の他の２つのメモリバンク２２０Ａからデータを読み出している間に、ダブルバッファ９０５Ａ内の２つのメモリバンク２２０Ａにデータを書き込むことができる。一実施形態では、コンパイラは、カーネルが同じメモリバンク対にアクセスしようとしないように、カーネルａとカーネルｂとの間にピンポン同期プロトコルを確立する。上述したように、コンパイラは、グラフソースコード内のこれらのカーネル間で行われるべき通信のタイプ（例えば、ウィンドウ処理またはストリーミング）をプログラマが示すだけで、ＰＬ１２５上のカーネルａがコア２１０Ｂ上のカーネルｂと通信できるように同期プロトコルを処理することができる。
【0086】
一実施形態では、カーネルｂをホストするコア２１０Ｂがメモリモジュール２３０Ａに直接隣接するため、カーネルｂは、（カーネルａとは異なり）相互接続２０５を使用する必要なく、ダブルバッファ９０５Ａに直接アクセスすることができる。したがって、ダブルバッファ９０５Ａおよびカーネルｂをハードウェア要素に割り当てるとき、コンパイラは、互いに直接隣接するメモリモジュール２３０Ａおよびコア２１０Ｂを選択し、その結果、カーネルｂは、コア２１０Ｂとメモリモジュール２３０Ａとの間の直接接続を使用することができ、これは相互接続２０５を使用するよりも高いスループットを有する。
【0087】
カーネルｂおよびｃは、図９に示すように同じコア２１０Ｂにホストされるまたは割り当てられるため、コンパイラは、シングルバッファ９１０Ａを隣接するメモリモジュール２３０に割り当てることを試みる。この場合、コンパイラはシングルバッファ９１０Ａをメモリモジュール２３０Ｃに割り当てたが、隣接するメモリモジュール、例えばモジュール２３０Ａまたは２３０Ｂのいずれかを使用することができた。コンパイラは、モジュール２３０Ａまたは２３０Ｂではなくメモリモジュール２３０Ｃを選択していてもよく、その場合、これらのメモリモジュールは、アレイ内のさらに北のコアによって使用される、より多くの利用可能な空間を有する（図示せず）。理由にかかわらず、カーネルｂおよびｃは、コア２１０Ｂとメモリモジュール２３０Ｃとの間の直接接続を使用して、シングルバッファ９１０Ａとの間でデータを転送することができる。カーネルｂおよびｃは同じコア２１０Ｂに割り当てられ、その結果、並列ではなく順次実行されるため、カーネルのうちの１つのみが任意の所与の時間にコア２１０Ｂによって実行されているため、ダブルバッファではなくシングルバッファ９１０Ａで十分である。この例では、シングルバッファ９１０Ａは、メモリバンク２２０Ｃの２つのバンクを含むが、コンパイラは、カーネルｂおよびｃの予想される必要性に応じて、より多くのバンクまたはより少ないバンクを割り当てることができる。
【0088】
カーネルｃとカーネルｄとの間のコア間通信リンク（図９では通信リンク６２０Ｃとして示されている）の場合、コンパイラは、メモリモジュール２３０Ｂ内のメモリバンク２２０Ｂにダブルバッファ９０５Ｂを割り当てる。上記のように、コンパイラは、カーネルｃおよびｄのためのピンポン同期プロトコルを確立して、ダブルバッファ９０５Ｂ内のメモリバンク２２０Ｂの２つのそれぞれの対を同時に書き込みおよび読み出すことができる。さらに、カーネルｃをホストするコア２１０Ｂとカーネルｄをホストするコア２１０Ｃの両方に隣接するメモリモジュール２３０Ｂを使用することにより、コンパイラは、ダブルバッファ９０５Ｂ内のデータを読み出して格納するために、これらのコア２１０Ｂ～２１０Ｃがメモリモジュール２３０Ｂに対して有する直接接続を利用する。
【0089】
カーネルｄとカーネルｅとの間のコア内通信リンク（図９では通信リンク６２０Ｄとして示されている）の場合、コンパイラはシングルバッファ９１０Ｂをメモリモジュール２３０Ｃに割り当てる。カーネルｂとカーネルｃとの間の通信リンクと同様に、カーネルｄおよびｅがコア２１０Ｃ上で順次実行されるため、シングルバッファ９１０Ｂで十分である。
【0090】
カーネルｅとカーネルｂとの間のコア間通信リンク（図９では通信リンク６２０Ｅとして示されている）の場合、コンパイラは、シングルバッファ９１０Ａおよび９１０Ｂによって使用されていないメモリモジュール２３０Ｃ内の残りの４つのメモリバンク２２０Ｃにダブルバッファ９０５Ｄを割り当てる。コンパイラは、ダブルバッファ９０５Ｄにアクセスするためのカーネルｂとｅとの間の同期プロトコルを再び確立することができる。
【0091】
カーネルが異なるタイプの処理コア（例えば、ＰＬ１２５およびコア２１０Ｃを含むＤＰＥ）にホストされるカーネルｄとｆとの間のヘテロジニアス通信リンク（図９では通信リンク６２０Ｆとして示されている）の場合、コンパイラは、メモリモジュール２３０Ｄ内のメモリバンク２２０Ｄにダブルバッファ９０５Ｃを割り当てる。カーネルｄは、コア２１０Ｃとメモリモジュール２３０Ｄとの間の直接接続を使用して、ダブルバッファ９０５Ｃにアクセスすることができる。しかしながら、カーネルｆはコア２１０のうちの１つではなくＰＬ１２５にホストされるので、カーネルｆは、ＤＭＡエンジン２１５Ｄおよび相互接続（ならびに図示されていないＮｏＣおよびＳｏＣインターフェースバッファ）を使用してダブルバッファ９０５Ｃにアクセスすることができる。コンパイラは、カーネルｄとカーネルｆとの間に同期プロトコルを再度確立して、カーネルがダブルバッファ９０５Ｃに並列にアクセスすることを可能にすることができる。
【0092】
図１０は、同じコア２１０内または同じメモリモジュールへの直接接続を有するコア２１０内のいずれかで互いに通信するＤＰＥアレイ内にカーネルを配置することを示しているが、他の実施形態では、コンパイラは、同じメモリモジュール２３０への直接接続を有さないコアに２つのカーネルを配置することができる。すなわち、コンパイラは、グラフ内で直接通信する２つのカーネルを２つの非隣接コア２１０に割り当てることができる。その場合、コンパイラは、カーネル間で通信するために、共有メモリを使用するのではなく、（ＰＬ１２５に位置するカーネルと同様に）相互接続２０５を使用してＤＭＡ読み出し／書き込みまたはストリーミング接続を実行するようにカーネルを構成することができる。
【0093】
このようにして、コンパイラは、ヘテロジニアスシステム内のどこにカーネルを配置するかを決定し、カーネル間の通信リンクのタイプ（ダブルバッファ、シングルバッファ、ウィンドウ処理、またはストリーミング）を決定し、ソースコード内でプログラマによって定義されたパラメータ（例えば、通信リンクを定義するパラメータ）を使用してカーネル間の同期プロトコルを確立することができる。しかしながら、上述したように、プログラマがＳｏＣ上のソースコードで定義されたグラフを実装するための最適解を事前に知っている場合、プログラマは制約を使用して最適化命令をコンパイラに提供することができる。
【0094】
図１１は、一例による、カーネル間でデータを送信するときに使用されるオーバーラップウィンドウ１１００を示す。一実施形態では、オーバーラップウィンドウ１１００は、１つのカーネル（例えば、図１０のカーネルａ）で受信されたストリーミングデータから形成されてもよく、次いで、データがチャンクアップされて、図１１に示すオーバーラップウィンドウ１１００を生成する。別の例では、カーネルは、上流のカーネルからオーバーラップウィンドウを受信し、次いで、オーバーラップウィンドウを下流のカーネルに送信することができる。一実施形態では、ウィンドウ１１００Ａは、ダブルバッファ９０５Ａ～９０５Ｄのうちの１つに格納され、ウィンドウ１１００Ｂは、ピンポン同期のために他方のバッファにある。次に、コンパイラは、カーネルの次の呼び出しの前に、オーバーラップ１１０５が一方のバッファから他方のバッファにコピーされることを保証する役割を担う。
【0095】
オーバーラップウィンドウ１１００は、いくつかの実施形態では有用であるが、他の実施形態では有用ではない場合がある。例えば、オーバーラップウィンドウ１１００は無線ドメインにおいて有用でありうるので、ＳｏＣは、異なるウィンドウを実行する間、カーネルの状態を維持することができる。一実施形態では、コアがカーネルの実行を終了した後、カーネルに関連付けられたレジスタはクリアされ、したがってカーネルの状態は失われる。しかしながら、オーバーラップ１１０５内のデータが同じであるオーバーラップ１１０５をウィンドウ１１００Ａと１１００Ｂとの間に設けることによって、カーネルは、その後、カーネルがウィンドウ１１００Ｂ内の新しいデータを処理し始めるときに、ウィンドウ１１００Ａの処理を終了した状態を回復することができる。言い換えると、（ウィンドウ１１００Ａ内の最後のサンプルを含む）ウィンドウ１１００Ｂ内のオーバーラップ１１０５を処理することによって、カーネルは、ウィンドウ１１００Ａの処理の終わりにあった状態を回復する。次いで、カーネルは、ウィンドウ１１００Ａ内になかったウィンドウ１１００Ｂ内の新しいデータの処理を開始することができる。したがって、ウィンドウ１１００Ｂのブロックサイズ１１１０は、前のウィンドウ１１００Ａになかった、カーネルによって処理されている新しいデータを示す。このようにして、グラフは、受信データを処理するために（ストリーミングデータに対してカーネルにおけるストールを低減することができる）ウィンドウ１１００を使用することができるが、オーバーラップ１１０５を使用することによって無限ストリーム錯覚を依然として維持することができる。
【0096】
カーネル間の通信リンクが（ストリーミングではなく）ウィンドウを使用する場合、一実施形態では、受信側カーネルは、そのすべての入力からデータのウィンドウ１１００が受信されるまでデータを処理せず、これによりデータの処理が非ブロッキングになる。データのすべてのウィンドウ１１００が受信されると、カーネルは、さらなるデータのためにストールされることなくデータを処理し、ウィンドウを下流のカーネルに出力する。例えば、図９のカーネルｄは、通信リンク６２０Ｆおよび６２０Ｄをそれぞれ使用して、カーネルｆおよびｅの両方に並列にデータのウィンドウ１１００を出力する。カーネルｄがカーネルｆおよびｅに出力するデータのウィンドウ１１００は、同じデータであってもよいし、異なるデータであってもよい。
【0097】
別の実施形態では、ユーザは、すべてのウィンドウが受信されるかまたはすべてのデータの出力準備ができるまで待つのではなく、入力データを受信するかまたはデータを出力するときを決定するようにカーネルをプログラムすることができる。例えば、図６に戻って参照すると、通信リンク６２０Ｅは非同期であり、カーネルｂを定義するソースコードは、カーネルｅからデータをいつ受信するかを決定する。
【0098】
方法５００に戻ると、制御プログラムは、ＳｏＣ上のデータフローグラフの実行を制御する。すなわち、図１０に示すように、カーネルおよび通信リンクが様々なハードウェア構成要素に割り当てられて構成されると、制御プログラムは、グラフの実行を制御するための命令をＳｏＣに提供することができる。上述したように、制御プログラムは、ホストコンピューティングシステム（好ましくはデータセンタ内にあり得る）上で、またはＳｏＣのＰＳ内で実行することができる。一実施形態では、制御プログラムは、制御ソースコードを使用してコンパイルされる。
【0099】
図１２は、一例による、データフローグラフのための制御プログラムを定義する制御ソースコード４３０である。ソースコード４３０は、データがどのようにしてグラフに読み込まれ、グラフから読み出されるべきかをコンパイラに示す接続１２０５を提供する。メインクラスは、グラフを初期化し（例えば、ｉｎｉｔ（））、グラフを実行し（例えば、ｒｕｎ（））、グラフを終了する（例えば、ｅｎｄ（））ための制御ＡＰＩを含む。例えば、プログラマは、制御ソースコード４３０を使用して、グラフが停止する前に実行すべき反復回数を示すことができる。これは、デバッグ目的に有用であり得る。しかしながら、他の例では、制御プログラムは、アプリケーションに応じてグラフを無期限に動作させることができる。これらの制御ＡＰＩについては、後でより詳細に説明する。
【0100】
一実施形態では、プログラマは、メモリモジュールのサイズを超える大きなルックアップテーブル（ＬＵＴ）を必要とする場合がある。コンパイラがＤＰＥアレイ内のメモリモジュールのいずれにとっても大きすぎる大型ＬＵＴを識別すると、コンパイラはＬＵＴを複数のメモリモジュールに分散させることができる。コンパイラは、ＬＵＴをアレイに直接割り当てることができる。プログラマは、ＬＵＴを静的データおよびアレイパラメータとして宣言し、静的データおよびアレイパラメータをカーネルに接続することができる。コンパイラは、ＬＵＴを（係数表と同様に）カーネルへの内部データとして扱う。ＬＵＴのこの宣言はグラフ内にあり、グラフ構成要素として割り当てられる。一実施形態では、大型ＬＵＴはダブルバッファされず、一度に１つのカーネルによってのみアクセス可能である。
【0101】
一実施形態では、カーネルは、ＤＰＥ内のコアからのストリームに対して直接読み出し／書き込みをすることができる。カーネルのソースコードでは、ストリームを関数パラメータとして宣言することができる。データがコア内のストリーミングポートで利用できない場合、カーネルはストールする可能性がある（したがって、ロック機構を必要としない）。これは、ストリーム自体のハードウェアによって実装される要素同期による要素であるが、入力データが利用できないためにコアがストールする可能性があり、バンク上にメモリ競合があり、または出力バッファが一杯になっている。
【0102】
一実施形態では、カーネルが任意のオンコアが提供できるサイクル数よりも多くのサイクル数を必要とする場合、カーネルはコア間で分割され、細分化されたカーネルを接続するためにカスケードストリームが使用される。ソースコードにおいて、プログラマは、カスケードを形成するために一緒にチェーン化された複数のカーネルを表現する。全体的な計算は、チェーン全体の累積和である。コンパイラは、カスケードされたカーネルの計算を複数のコアに分散させる。コアは、コア内のレジスタ内のサイクル蓄積、すなわち、コア内の内部レジスタを使用し、メモリモジュールを使用しないでサイクルを実行する。このように、コアは、メモリモジュールをバッファ（例えば、上記のシングルバッファおよびダブルバッファ）として使用することなく、レジスタ間通信を使用してチェーンを実行することができる。一実施形態では、プログラマが複数のカーネルをチェーン化してカスケードを形成するのではなく、コンパイラ（または他の何らかのソフトウェアアプリケーション）は、カーネルがコア間で分割されてカスケードを形成するこの変換を実行することができる。
【0103】
制約
図１３は、一例による、制約を使用してデータフローグラフを実装するためにソースコードをコンパイルするための方法１３００のフローチャートである。ブロック１３０５において、コンパイラは、データフローグラフを確立するソースコード内のユーザ定義制約を識別する。例えば、図６を参照すると、プログラマは、制約６１５をグラフソースコード４２０に追加することができる。しかしながら、他の実施形態では、プログラマは、カーネルのソースコードに制約を課す。さらに他の実施形態では、プログラマは、別個のファイルに制約を定義することができる。グラフソースコードは、データフローグラフを実装するときにコンパイラが制約を識別できるように、ファイルを参照またはリンクすることができる。
図１３は、一例による、制約を使用してデータフローグラフを実装するためにソースコードをコンパイルするための方法１３００のフローチャートである。ブロック１３０５において、コンパイラは、データフローグラフを確立するソースコード内のユーザ定義制約を識別する。例えば、図６を参照すると、プログラマは、制約６１５をグラフソースコード４２０に追加することができる。しかしながら、他の実施形態では、プログラマは、カーネルのソースコードに制約を課す。さらに他の実施形態では、プログラマは、別個のファイルに制約を定義することができる。グラフソースコードは、データフローグラフを実装するときにコンパイラが制約を識別できるように、ファイルを参照またはリンクすることができる。
【0104】
ユーザ定義制約は、ＳｏＣ上での実装のためにソースコードをコンパイルするときにコンパイラではなくプログラマによって生成されるため、外部制約である。一実施形態では、プログラマによって提供される外部制約の数は、コンパイラのインテリジェンスに応じて異なり得る。コンパイラが、データフローグラフの十分に最適化された実装をもたらす内部制約を有する場合、プログラマは、制約をほとんど提供しないことを選択することができる。したがって、コンパイラの機能は、プログラマが使用することを決定する外部制約の数に影響を与える可能性がある。コンパイラのより新しいよりインテリジェントなバージョンが利用可能になるにつれて、プログラマが提供する制約はより少なくなる。
【0105】
制約の種類は様々であり得る。さらに、プログラマが提供する制約の数は、プログラマがＳｏＣ内の基礎となるハードウェアをどれだけ理解しているかに相関し得る。プログラマがＳｏＣのハードウェアについてほとんど知らない場合、制約がデータフローグラフの全体的な性能（例えば、グラフのサイクル時間またはレイテンシなどのデータフローグラフの所望の性能）を規定する可能性がある。プログラマがＳｏＣ内のいくつかの基本的なハードウェア構成（例えば、ＤＰＥ、ＰＬ、通信リンクのタイプなど）を理解している場合、プログラマはこれらの特定のグラフオブジェクトに対する制約を提供することもできる。したがって、一部の制約はハードウェアに依存せず（グラフ全体に影響を及ぼす性能制約など）、他の制約はハードウェアを認識し、データフローグラフ内の特定のグラフオブジェクト（またはグラフオブジェクトのグループ）に影響を及ぼす。
【0106】
ハードウェア認識制約の一例として、プログラマは、ＤＰＥアレイのどこに特定のカーネルを配置すべきか（例えば、カーネル位置制約）を規定することができる。あるいは、プログラマは、２つのカーネル間の位置関係を規定することができる（例えば、２つのカーネルは、同じコアでホストされるか、または隣接コアでホストされるべきである）。別の例では、制約は、ＤＰＥアレイのどこに通信リンク用の特定のバッファ（またはカーネル用のポート）を配置すべきかを規定することができる。バッファの位置要件は、絶対アドレスもしくはメモリバンク、または別のバッファもしくはカーネル、またはカーネルが実行するプロセッサに関連付けられたスタックに対する相対位置であり得る。別のタイプの制約は、特定のカーネルをホストするコアに隣接するメモリモジュール内に特定のバッファが配置されるべきかどうかを示すことができる。別のタイプの制約は、全体としてデータフローグラフに適用することができる。これらのタイプの制約を使用して、プログラマは、コンパイラがグラフオブジェクト（例えば、カーネル、ポート、通信リンクなど）をＳｏＣに配置する方法を制御することができる。
【0107】
プログラマはまた、ハードウェアに依存しない可能性がある性能制約を提供することができる。例えば、プログラマは、グラフのレイテンシが特定の処理サイクル数未満であることを望む場合がある。コンパイラは、グラフの実装をテストして、それが性能制約を満たすかどうかを判定し、満たさない場合、制約が満たされるまでグラフを再構成することができる。例えば、コンパイラは、以前に２つのカーネルが同じコア上の同じ場所に配置されていた場合、それらを２つの異なるコアに分割するか、またはバッファを共有メモリモジュールに移動して、カーネルがＤＰＥアレイ内の相互接続を使用する必要なくデータに直接アクセスできるようにすることができる。
【0108】
別の実施形態では、制約は、コア／ポート／ＦＩＦＯ／メモリモジュールの利用または好ましいＦＩＦＯ深さを定義することができる。コンパイラは、グラフの実装をテストして、それが性能制約を満たすかどうかを判定し、満たさない場合、グラフを再構成することができる。性能制約により、コンパイラは、制約が満たされているかどうかを判定するためにグラフをテストすることが多いので、これらの制約は、導出制約とも呼ばれ得る。
【0109】
ブロック１３１０において、コンパイラは、制約内の一意の名前を使用して制約に対応するグラフオブジェクトを識別する。この例では、各グラフオブジェクト（例えば、各カーネル、通信リンク、ポートなど）に一意の名前を割り当てることができる。制約をフォーマットするとき、プログラマは一意の名前を使用して、制約が適用されるグラフオブジェクトをコンパイラに通知することができる。
【0110】
一実施形態では、プログラマは、インデックス内の各グラフオブジェクトに一意の名前を提供することができる。そうするとインデックスは、コンパイラにアクセス可能となり得る。別の実施形態では、コンパイラは、グラフオブジェクトに一意の名前を割り当てる。例えば、コンパイラは、グラフ内のすべてのグラフオブジェクトの階層ツリーを形成し、ツリーをルートからリーフまでトラバースすることによってオブジェクトに一意の名前を割り当てることができる。階層ツリーはまた、プログラマが一意の名前を使用して特定のオブジェクトに制約を割り当てることができるように、プログラマにアクセス可能である。
【0111】
ブロック１３１５において、コンパイラは、ソースコードをコンパイルするときに制約を満たすようにグラフオブジェクトを構成する。制約に従ってグラフオブジェクトを配置する様々な例が図１４に示されている。
【0112】
図１４は、一例による、ユーザ定義の制約を使用して実装されたグラフオブジェクトを有するＤＰＥアレイ１０５である。この例では、グラフオブジェクトは、カーネルａ～ｄおよびバッファ９０５を含む。一実施形態では、コンパイラは、プログラマによって提供される位置制約に応答して、カーネルａをコア２１０Ｈに配置する。例えば、プログラマは、コア２１０に割り当てられた一意のアドレス１４０５を使用して、カーネルａをコア２１０Ｈに配置するようにコンパイラに命令することができる。すなわち、制約は、カーネルａをコア２１０Ｈに配置するようにコンパイラに命令するコア２１０Ｈのアドレス１４０５（すなわち、２，１）を含んでもよい。
【0113】
図１４はまた、カーネルｂおよびｄが同じコア２１０Ｅ上にコロケートされるべきであることを示すコロケーション制約１４１５を示す。プログラマは、ソースコード内の制約をフォーマットして、コンパイラがカーネルｂおよびｄの両方を（例えば、そのアドレス１，１を使用して）コア２１０Ｅに配置することを要求することができるが、別の実施形態では、制約は、コンパイラにカーネルｂおよびｄをホストするための最良のコア２１０をそれ自体で識別する自由を与える特定のコアを規定しなくてもよい。
【0114】
図１４はまた、カーネルｃおよびカーネルｂを隣接コア、すなわちコア２１０Ｄおよび２１０Ｅに配置するようにコンパイラに命令する相対位置制約１４１０を示す。ここでも、プログラマは、ＤＰＥアレイ１０５内のコア２１０のうちのどの２つがカーネルｃおよびｂをホストすべきかを示すように制約をフォーマットすることができるが、別の実施形態では、コンパイラは、可用性などの他のメトリックに基づいて使用するコア２１０を選択する自由を有する。
【0115】
さらに、図１４は、プログラマによって提供される制約に従ってバッファ９０５を配置することを示す。一実施形態では、プログラマは、例えばタイルのアドレス（０，１）を使用して、バッファ９０５がメモリモジュール２３０Ｂに配置されるべきであるという制約を規定する。あるいは、制約は、アレイ１０５内のメモリモジュールの絶対位置を提供せず、代わりに、バッファ９０５が、カーネルｄに対応するコアによって直接アクセスされ得るメモリモジュール２３０内に配置されることを規定することができる。そうすることにより、コンパイラは、可用性などのメトリックを使用してバッファを実装するために、コア２１０Ｅを取り囲む４つのメモリモジュール２３０のうちの１つを選択する自由を得る。別の実施形態では、制約（例えば、カーネルのセットのスタック／予約メモリは同じメモリグループにマッピングされる）によって、複数のバッファが同じメモリグループにマッピングされてもよい。
【0116】
図１４は、ＤＰＥアレイ１０５内にグラフオブジェクトを配置するために使用できるいくつかの位置制約を示しているだけである。上述したように、プログラマは、プログラマの好みに従ってグラフをカスタマイズするために使用できる、図１４に示されていない他の外部制約を提供することができる（またはコンパイラは他の導出制約を識別することができる）。さらなる制約タイプは、ある地点から別の地点へデータを伝送するために経路がとるべきルーティングリソース、データ経路が回路スイッチングされるべきかパケットスイッチングされるべきか、およびデータ経路上にどれだけの遅延が挿入されるべきかを含むことができる。いくつかの制約は、コンパイラがコンパイル済みコードを生成するときにより良い決定を行うのを助けることができる。メモリ競合を回避するためのバッファ間配置制約などの他の制約は、ＳｏＣの性能を改善することができる。
【0117】
方法１３００に戻ると、ブロック１３２０において、コンパイラは、制約に従ってＳｏＣのヘテロジニアス処理システムにおいてデータフローグラフを実装する。上述したように、コンパイラは、データフローグラフを実行するためにＳｏＣ内のヘテロジニアス処理システムを構成するビットストリームおよびバイナリコードを生成することができる。
【0118】
一実施形態では、データフローグラフは、複数のＳｏＣ（例えば、複数のＦＰＧＡ）にわたって拡張することができる。その場合、グラフソースコードは、第１のＳｏＣのヘテロジニアス処理システムにおいて第１のグラフオブジェクトを構成するために使用される第１の制約と、第２のＳｏＣのヘテロジニアス処理システムにおいて第２のグラフオブジェクトを構成するために使用される第２の制約とを含み得る。
【0119】
図１５は、一例による、継承可能な抽象インターフェース１５０５である。抽象インターフェース１５０５は、この例では、ポート１５１５を含むフィルタチェーン１５１０のためのインターフェースを定義する。インターフェース１５０５は、様々な方法でプログラマによって実装できるソフトウェアクラスによって定義することができる。例えば、フィルタチェーン１５２０は、抽象インターフェース１５０５を継承し、カーネルａおよびｂを含む。対照的に、フィルタチェーン１５２５はまた、抽象インターフェース１５０５を継承するが、カーネルａ、ｂ、およびｃを含む。例えば、フィルタチェーン１５２５は、フィルタチェーン１５２０よりも細かい処理を必要とする場合がある。抽象インターフェース１５０５は、オブジェクト指向プログラミング言語を使用して定義することができるため、インターフェース１５０５を継承し、異なる実装に使用することができる。
【0120】
図１６は、一例による、複数のサブグラフ１５０５を有するデータフローグラフ１６００である。図１６は、データフローグラフ１６００のソースコードがサブグラフの２つのインスタンス、すなわちサブグラフ１５０５Ａおよび１５０５Ｂを含むという点で図１５とは異なる。すなわち、サブグラフ１５０５を一度定義することができ、そのサブグラフ１５０５の複数のインスタンスをグラフ１６００に挿入することができる。例えば、グラフ１６００によって定義されるレシーバチェーンは、図１５の一方のチャネルシステムではなく２つのチャネルシステムに対応するため、サブグラフ１５０５によって定義されるフィルタのうちの２つを使用することができる。このようにして、サブグラフ１５０５は、（例えば、それ自体のファイル内の）グラフソースコードから別々に定義され、次いで任意の回数インスタンス化され得る。
【0121】
図１６では、カーネルｂは、サブグラフ１５０５Ａにデータウィンドウを送信するための第１のポート１５１０Ｂと、サブグラフ１５０５Ｂにデータウィンドウを送信するための第２のポート１５１０Ａとを含むように修正される。これは、ソースコードにおいてプログラマによって定義することができる。
【0122】
図１７は、一例による制約付きデータフローグラフ１７００である。図１７は、サブグラフ１５０５の複数のインスタンスを含む、図１６に示すグラフ１６００を含む。しかしながら、グラフ１６００は制約付きデータフローグラフ１７００内に含まれる。一実施形態では、制約付きグラフ１７００は、ロジック設計に制約を追加するラッパーグラフである。すなわち、（ポート１７０５を使用してアクセス可能な）制約付きグラフ１７００内にグラフ１６００をカプセル化することによって、プログラマは、グラフ１６００の実行に全体的な制約を追加することができる。さらに、コンパイラは、制約付きグラフ１７００から制約を自動的に伝播させ、それによってグラフ１６００を異なる実装に変換することができ、その後、別のデータフローグラフにインスタンス化することができる。
【0123】
図１８は、一例による、複数のソースからの制約をマージするための制約処理フロー１８００である。フロー１８００は、上述の制約タイプのいずれかを含むことができる制約１８１０を含むグラフソースコード１８０５を含む。さらに、フロー１８００は、上述の制約タイプのいずれかを同様に含むことができる他のソースからの制約１８１５を含む。これらの後者の制約は、ｊａｖａｓｃｒｉｐｔ（登録商標） ｏｂｊｅｃｔ ｎｏｔａｔｉｏｎ（ＪＳＯＮ）ファイルフォーマット、ＴＣＬファイルフォーマットで、またはグラフィカルユーザインターフェース（ＧＵＩ）を使用して定義することができる。したがって、他のソースからの制約１８１５は、ソースコード１８０５内に埋め込まれず、別個のファイルである。
【0124】
制約処理１８２０の間、コンパイラは、ソースコード１８０５内の制約１８１０を他のソースからの制約１８１５とマージする。一実施形態では、（定義されているかどうかにかかわらず）制約は、コンパイラの内部データ構造とマージできるようにフォーマットを有する。一実施形態では、プログラマは各サブグラフの制約を別々に指定することができ、コンパイラはこれらの制約の読み取りと、ソースコード１８０５によって定義された親グラフプログラムとのマージとを処理することができる。
【0125】
分割器、マッピング器、およびルータなどの制約クライアント１８２５は、マージされた制約を受信し、解１８３０が制約を満たすことを保証する。すなわち、制約クライアント１８２５は、ＳｏＣにおけるデータフローグラフの実装が、ソースコード１８０５に埋め込まれた制約１８１０ならびに他のソースからの制約１８１５を満たすことを保証する。
【0126】
制御ＡＰＩ
図１９は、一例による、ＳｏＣ上でデータフローグラフを実装するためのコンピューティングシステム１９００のブロック図である。コンピューティングシステム１９００は、ここでは詳細に説明しない図４で上述したものと同じ構成要素の多くを含む。しかしながら、図１９は、コンピューティングシステム１９００が、図４に示すコンピューティングシステム内にあってもなくてもよい制御ＡＰＩ１９０５を含むという点で、図４とは異なる。図示のように、制御ＡＰＩ１９０５は、制御ソースコード４３０内に配置される。
図１９は、一例による、ＳｏＣ上でデータフローグラフを実装するためのコンピューティングシステム１９００のブロック図である。コンピューティングシステム１９００は、ここでは詳細に説明しない図４で上述したものと同じ構成要素の多くを含む。しかしながら、図１９は、コンピューティングシステム１９００が、図４に示すコンピューティングシステム内にあってもなくてもよい制御ＡＰＩ１９０５を含むという点で、図４とは異なる。図示のように、制御ＡＰＩ１９０５は、制御ソースコード４３０内に配置される。
【0127】
一般に、プログラマは、制御ＡＰＩ１９０５を使用して、ＳｏＣ１００でのデータフローグラフ４４０の実行を制御するパラメータを変更することができる。すなわち、本明細書の実施形態は、ＡＰＩ１９０５および対応する方法を使用して、制御ソースコード４３０からコンパイルされたローカル制御プログラムを介して、またはＰＳ自体で制御ソースコードを実行することによって、ＳｏＣ１００のヘテロジニアス処理システム上で実行されるユーザアプリケーション（例えば、データフローグラフ４４０）を制御、対話、および少なくとも部分的に再構成する。制御ＡＰＩ１９０５を使用して、ユーザは、そのようなリモート実行グラフをローカルオブジェクトとして直接操作し、それらに対する制御操作（例えば、グラフをロードおよび初期化する、適応制御のためのパラメータを動的に調整する、アプリケーションパラメータ、システム状態、およびイベントを監視する、プラットフォームの分散メモリ境界にわたってデータを読み書きするための動作をスケジューリングする、サブシステムの実行ライフサイクルを制御する、新たなサブシステムのためにコンピューティングリソースを部分的に再構成するため）を実行することができる。
【0128】
例えば、ＳｏＣ１００内のカーネルまたは他のグラフオブジェクトは、これらのオブジェクトの動作を制御する利得またはフィルタ係数などのパラメータを有することができる。これらのパラメータは、ホスト上で実行される制御プログラムまたはＳｏＣ自体を使用して動的に制御することができる。コンパイラ４３５は、パラメータを変更するように制御プログラムを構成することができ、これは、プログラマが（ソースコードを使用して）高レベルでＡＰＩ１９０５を表現することができる一方で、コンパイラ４３５が、レジスタの構成、ルートの識別、グラフオブジェクトの位置の識別などのパラメータを調整するためのハードウェア詳細を処理することを意味する。
【0129】
有利には、コンパイラ４３５は、ＡＰＩ１９０５が所望の機能を実行することができるように、ＳｏＣ１００内のドライバ１９１０、レジスタ、および他のハードウェアを構成することができる。例えば、ドライバ１９１０は、ＤＭＡを実行してＳｏＣ１００内のＤＤＲメモリ内のデータを、データフローグラフ４４０内のカーネルを実行するＤＰＥ１１０のうちの１つに読み出すために使用され得る。ドライバ１９１０はＰＳ１３０の一部として示されているが、他の実施形態では、ドライバ１９１０は、ＰＬ１２５内のコントローラを使用して、またはネットワークを使用してリモートコントローラからＳｏＣ１００に送信される制御信号を介して実装することができる。
【0130】
制御ＡＰＩ１９０５がないと、プログラマはドライバ１９１０を直接構成しなければならず、これによりプログラマは、カーネルの位置（例えば、ホストＤＰＥ）ならびにカーネルに到達するためのルートを知る必要があり得る。代わりに、コンパイラ４３５は、制御ソースコード４３０内の対応するＡＰＩ１９０５の検出に応答してドライバ１９１０を構成することができる。すなわち、ＡＰＩ１９０５を定義するとき、プログラマは単にグラフオブジェクト（例えば、特定のカーネルまたはカーネルポート）を識別し、コンパイラ４３５は残り、例えば、ＤＭＡを実行するようにドライバ１９１０を構成し、レジスタをプログラムすることができる。
【0131】
図２０Ａおよび図２０Ｂは、例による、ＳｏＣ上のデータフローグラフの実行を制御するための制御ＡＰＩを示す。図２０Ａは、データフローグラフの動作を制御するために使用できる制御ＡＰＩ１９０５のリストを示す。図２０Ａは、各ＡＰＩ１９０５の隣にその目的を説明するコメントを含む。例えば、ｇｒａｐｈ（）ＡＰＩは、空のデータフローグラフクラスコンストラクタを定義する。すべてのユーザ定義グラフは、このクラスの拡張である。
【0132】
ｉｎｉｔ（）ＡＰＩはデータフローグラフを初期化し、ｒｕｎ（）ＡＰＩはグラフを実行し、ｗａｉｔ（）ＡＰＩはグラフが前の実行を完了するまで待機するか、またはいくつかのサイクルを待機してからグラフを一時停止し、ｒｅｓｕｍｅ（）ＡＰＩは一時停止後にグラフを再開し、ｅｎｄ（）ＡＰＩは最後の実行が完了するのを待ってからＤＰＥを無効化する。したがって、これらのＡＰＩ１９０５を使用して、プログラマは、グラフがいつ動作を開始するか、動作する長さ、およびグラフの終了を制御することができる。
【0133】
ｕｐｄａｔｅ（）ＡＰＩは、プログラマが（例えば、ｉｎｐｕｔ＿ｐｏｒｔ＆ｐポインタを使用して）グラフオブジェクトを指定することによってデータフローグラフ内のランタイムパラメータを更新することを可能にする。提供された情報を使用して、コンパイラは、後述するトリガを使用して更新を実行するようにＳｏＣ内のハードウェアを構成することができる。
【0134】
ｒｅａｄ（）ＡＰＩを使用して、プログラマは、実行中のデータフローグラフからランタイムパラメータを読み出すことができる。これは、動的データ依存決定に基づいてグラフ実行を制御するのに特に有用である。
【0135】
図２０Ｂは、プログラミングモデルの一部であり得る他の制御ＡＰＩ１９０５を示す。図２０Ｂは、ＳｏＣ内のＤＰＥアレイとＤＤＲメモリとの間でデータを移動させるための特別なＡＰＩを有するグローバルメモリ入力／出力（ＧＭＩＯ）クラスを含む。例えば、ｉｎｉｔ（）ＡＰＩは、ＤＤＲメモリ内に存在するメモリアドレスのセットを提供することによってＧＭＩＯオブジェクトを初期化する。ｇｍ２ｍｅ＿ｎｂ（）ＡＰＩは、シム内のＤＭＡレジスタを使用して、グローバルメモリからＤＰＥアレイにデータを転送することができる。一実施形態では、コンパイラは、ＧＭＩＯクラス内でＡＰＩ１９０５を実行するようにシム内のレジスタを構成する。さらに、これらのＡＰＩ１９０５は、（制御プログラムをホストすることができる）ＰＳがＧＭＩＯ読み出しおよび書き込みと同時に他の機能を実行することができることを意味する非ブロッキングコマンドである。一実施形態では、ＧＭＩＯ ＡＰＩは、ＳｏＣがＤＤＲメモリの同じセットを使用してデータをＤＰＥアレイに転送し、アレイからデータを読み出すことを可能にする。すなわち、プログラマは、ＧＭＩＯ ＡＰＩを使用して、ＤＤＲメモリからＤＰＥアレイにデータを読み出し、次いで、ＤＰＥアレイはデータを処理し、処理されたデータを同じＤＤＲメモリに格納することができる。
【0136】
図２０Ｂはまた、ＰＬとＤＰＥアレイとの間でデータを移動するためのＡＰＩを有するプログラマブルロジック入力／出力（ＰＬＩＯ）クラスを含む。ＰＬＩＯ ＡＰＩは、データがＤＰＥアレイと入力／出力ファイルとの間で転送されるシミュレーション環境にのみ使用され得るため、ＧＭＩＯ ＡＰＩよりも単純である。
【0137】
図２０Ｂはまた、特定のグラフオブジェクト（例えば、ＧＭＩＯポートの特定のカーネル）の性能を監視するため、またはイベント追跡を実行するためのＡＰＩを有するイベントクラスを有する。イベントＡＰＩは、プログラマが特定のハードウェアイベントを追跡し、ハードウェアイベントの発生をカウントし、総性能メトリックを測定することを可能にする。一例では、プログラマは、データフローグラフの入力および出力を追跡することによってグラフのレイテンシを測定することができる。例えば、ＡＰＩに応答して、コンパイラは、第１のデータがデータフローグラフに入力されてからデータフローグラフによって第１のデータが出力されるまでの間の処理サイクル数をカウントする性能カウンタを確立することができる。別の例では、プログラマは、ＤＰＥ内で実行されるグラフのスループットを測定することができる。コンパイラは、サイクル数およびグラフ実行のいくつかの反復中に生成されたデータ項目の数をカウントするための性能カウンタを確立することができる。
【0138】
図２１は、一例による、ＤＰＥアレイ１０５を異なる領域に論理的に分割することを示す。この実施形態では、トップ領域２１０５は、ＤＰＥアレイ１０５全体およびそのＤＰＥ１１０を含む。ＲＣ領域２１１０は、ＤＰＥアレイ１０５内の列のサブセットを含む。領域２１１５Ａおよび２１１５Ｂは、ＲＣ領域２１１０内のサブ領域を画定する。このようにして、ＤＰＥアレイ１０５は、領域の階層に分割され得る。この例では、ＲＣ領域２１１０はトップ領域２１０５のサブ領域であり、領域２１１５Ａおよび２１１５Ｂは、ＲＣ領域２１１０内に含まれるサブ領域である。
【0139】
上述したＡＰＩおよび制約を使用して、プログラマは、アレイ１０５内の異なる領域に異なるデータフローグラフを割り当てることができる。例えば、複数のデータフローグラフは、時刻に応じて異なる数のアンテナを使用してデータを受信することができる無線送受信機から取得されたデジタルデータを処理することができる。アンテナに対応するデータフローグラフを無効化または有効化するために、プログラマは、配置制約を使用して各データフローグラフを別個のＲＣ領域２１１０に配置することができ、その結果、特定のアンテナに対応するプロセス制御を選択的に有効化および無効化することができる。したがって、異なる領域に異なるデータフローグラフを配置することによりプログラマ制御が提供され、その結果、異なる領域で動作するデータフローグラフに影響を与えることなく、１つのデータフローグラフを有効化または無効化することができる。一実施形態では、プログラマは、クラスＲＣＧｒａｐｈから導出された複数の論理的に独立したコンテナグラフを提供し、それらに複数のデータフローグラフを割り当てる。次に、コンパイラは、各データフローグラフを独立して制御できるように、各コンテナグラフの特定のハードウェア領域を決定する。
【0140】
別の実施形態では、プログラマは、上述の制御ＡＰＩを使用して、単一のコンテナグラフ内に複数の代替グラフを確立することができる。代替グラフは、同じロジックコンテナグラフを共有し、したがって同じハードウェア領域を共有するデータフローグラフである。コンテナグラフの代替グラフの数が１より大きい場合、これは、異なるデータフローグラフが同じハードウェア領域を共有するが、異なる時間に実行されることを意味する。一実施形態では、コンテナグラフおよび特定の領域への代替データフローグラフの割り当ては、コンパイラによってＳｏＣに提供されるパッケージバイナリで定義される。
【0141】
図２２Ａは、一例による、データフローグラフの実行を動的に変更することを示す。すなわち、図２２Ａは、グラフ２２００がデータをどのように処理するかを変更するためにデータフローグラフ２２００を動的に再構成する（例えば、ランタイムパラメータを変更する）ために１つまたは複数の制御ＡＰＩを使用することを示す。この再構成は、基礎となるハードウェアを変更することなく行うことができる。すなわち、ＳｏＣが初期化された後、データフローグラフ２２００は、ハードウェアを再構成する必要なく、オンザフライで異なる状態間で切り替わることができる。
【0142】
データフローグラフ２２００は、専用ＬＴＥ２０チャネル２２０５、専用ＬＴＥ１０チャネル２２１５、およびランタイムパラメータ２２２０を使用してＬＴＥ２０チャネルとＬＴＥ１０チャネルとの間で選択的に変更することができる再構成可能チャネル２２１０を含む処理方式を示す。例えば、チャネル２２１０をＬＴＥ２０チャネルとして構成するために、パラメータ２２２０は、ハーフバンドフィルタから受信されたデータを出力するようにｍｕｘ２２３０を制御する。制御ＡＰＩは、ｍｕｘ２２３０がハーフバンドフィルタおよび遅延アライメントブロックによって出力されたデータを無視し、その結果チャネル２２１０がＬＴＥ１０チャネル２２１５と同様のデータを処理するようにパラメータ２２２０を変更することができる。
【0143】
一実施形態では、データフローグラフ２２００内の複数の再構成可能な選択肢を、ＳｏＣ内の同じ領域に割り当てることができる。これを図２２Ｂに示す。例えば、グラフ２２５０は、ＳｏＣ内のトップ領域２２５５に割り当てられてもよい。あるいは、グラフ２２００内の異なるチャネルは、異なる領域に割り当てられてもよい。この例では、ｍｕｘ２２３０を含む再構成可能チャネル２２１０を有するのではなく、グラフ２２５０は、再構成可能コンテナＲＣ領域２２６０のための２つの選択肢を用いて構築される。一方の選択肢Ａｌｔ０２２６５はＬＴＥ２０チャネルであり、他方の選択肢Ａｌｔ１２２７０は、ミキサ２２７５と共に２つのＬＴＥ１０チャネルを保持する。Ａｌｔ０２２６５の固定ＬＴＥ２０チャネルは、２つのＬＴＥ１０チャネルが割り当てられている１つまたは複数の領域とは別個に、ＳｏＣ内のそれ自体の領域に割り当てることができるか、またはトップ領域２２５５の一部とすることができる。したがって、ＲＣ領域２２６０がＬＴＥ２０チャネルとして機能すべきとき、制御ＡＰＩは、（他の領域に配置された専用ＬＴＥ２０チャネルに影響を与えることなく）グラフＡｌｔ０ ２２６５をロードするように領域を再構成することができる。しかしながら、ＲＣ領域２２６０が２つのＬＴＥ１０チャネルとして機能すべきである場合、制御ＡＰＩは、代替グラフＡｌｔ１ ２２７０をロードするように領域を再構成することができる。そうすることで、ｍｕｘ２２３０などのチャネル２２１０を動的に再構成するために使用される図２２Ａに示される回路が回避され、２つの選択肢のために同じＤＰＥリソースが再使用される（これによりグラフ２２００がＳｏＣで使用する空間の量を減らすことができる）が、通常、ｍｕｘ２２３０のパラメータ２２２０を制御するよりも、ＬＴＥ２０の実施形態とＬＴＥ１０の実施形態との間の領域でハードウェアを再構成する方が多くの時間がかかる。
【0144】
図２３Ａは、例によるトリガされたパラメータを示し、図２３Ｂは、例による非同期パラメータを示す。例えば、ストリーミングデータに対応するウィンドウおよびストリームとは異なり、パラメータを使用して、非ストリーミングデータを使用するデータフローグラフの実行を制御することができる。一実施形態では、プログラマは、カーネル実行の開始時に同期トリガを使用して、データフローグラフ内のパラメータを変更する。別の実施形態では、パラメータの変更は、カーネルの実行と非同期に行うことができる。一実施形態では、制御プログラム（ＰＳ上で実行されているかホスト上で実行されているかにかかわらず）は、トリガされたまたは非同期のパラメータの変更を開始する。別の実施形態では、プログラマブルロジックは、トリガされたまたは非同期のパラメータの変更を開始する。トリガを使用して変更することができるパラメータの例は、関数またはメソッド呼び出しにおけるパラメータ、またはウィンドウのサイズの変更を含む。
【0145】
図２３Ａは、対応する機能が呼び出されるたびにカーネルが新しいパラメータを待機するトリガされたパラメータを示す。結果として、カーネルは、制御プログラム２３０５がトリガされたパラメータを提供するまで実行しない。例えば、制御プログラム２３０５はパラメータのｐｉｎｇバッファへの書き込みトランザクション２３１５Ａを生成し、これはカーネル２３１０を実行するＤＰＥによって受信される。これに応答して、カーネル２３１０は、実行ブロック２３２５Ａの間にデータを処理する。同時に、制御プログラム２３０５は、時間ブロック２３２０の間に他の活動を自由に実行することができる。すなわち、制御プログラム２３０５は、トリガされたパラメータ値を（非ブロッキングである）ｐｉｎｇバッファに送信し、次いで、時間ブロック２３２０の間に他のタスクを実行することができる。
【0146】
特に、カーネル２３１０が実行ブロック２３２５Ａを終了すると、そのデータがその入力で利用可能であっても、すぐにそれ以上のデータを処理し始めない。代わりに、カーネル２３１０は、実行ブロック２３２５Ｂを実行するために、（書き込みトランザクション２３１５Ａと同じ値または異なる値を有することができる）トリガされたパラメータを含む第２の書き込みトランザクション２３１５Ｂを受信するまでｐｏｎｇバッファで待機する。実行ブロック２３２５Ｂを終了すると、カーネル２３１０は、実行ブロック２３２５Ｃを開始するために、書き込みトランザクション２３１５Ｃでトリガされたパラメータを受信するまで再び待機する。このようにして、トリガされたパラメータは、各実行ブロックの前に制御プログラム２３０５が更新されたパラメータをカーネル２３１０に送信することを可能にする。
【0147】
図２３Ｂは、カーネル２３１０が以前に受信されたパラメータを使用して実行する非同期パラメータを示す。図示のように、制御プログラム２３０５は、実行ブロック２３２５Ｄ中にデータを処理するときに使用するために、カーネル２３１０の更新されたパラメータを含む書き込みトランザクション２３１５Ｄをｐｉｎｇバッファに送信する。同時に、制御プログラム２３０５は、図２３Ａのように時間ブロック２３２０の間に他の活動を実行することができる。しかしながら、図２３Ａとは異なり、実行ブロック２３２５Ｄが完了すると、カーネル２３１０は、実行ブロック２３２５Ｅおよび２３２５Ｆの間にすぐにデータの処理を開始することができる。カーネル２３１０が制御プログラム２３０５から新しいパラメータを受信していないので、カーネル２３１０は、実行ブロック２３２５Ｄの間の同じパラメータを使用して、実行ブロック２３２５Ｅおよび２３２５Ｆの間に入力データを処理する。
【0148】
実行ブロック２３２５Ｅの間、制御プログラム２３０５は、カーネル２３１０の更新されたパラメータを含む新しい書き込みトランザクション２３１５Ｅをｐｏｎｇバッファに送信する。更新されたパラメータ値は、書き込みトランザクション２３１５Ｅの完了後にカーネル２３１０によって使用するために利用可能である。したがって、カーネル２３１０が実行ブロック２３２５Ｇを開始すると、カーネル２３１０は更新されたパラメータ（ブロック２３２５Ｄ～２３２５Ｆの間に使用されるパラメータの値とは異なり得る）を使用する。このように、カーネル２３１０は、制御プログラム２３０５が更新されたパラメータをカーネル２３１０に送信するまで、同じパラメータを使用して継続的に実行することができる。
【0149】
一実施形態では、カーネルが呼び出されると、コンパイラは、カーネルが受信データの処理を開始する前にすべてのデータが利用可能であり、かつデータウィンドウを出力する前にすべてのデータの送信準備ができていることを保証するロック基準を作成する。しかしながら、非同期通信の場合、グラフはこれらのチェックのいずれも行う必要はなく、ユーザは、読み出す入力ウィンドウを取得するとき、または書き込むウィンドウを出力するときに使用される基準を定義するＡＰＩを作成することができる。言い換えると、ユーザによって提供される基準は、カーネルが同期する時点を定義する。例えば、図６では、カーネルｅからカーネルｂへの接続は非同期である。したがって、カーネルｅはウィンドウを準備することができ、次いで、カーネルｂは、カーネルｂと同期する前に最初の数フレームをスキップすべきかどうかを（ＡＰＩでユーザによって提供される基準を使用して）決定する。すなわち、ユーザによって提供された基準を使用してウィンドウをいつ受信または出力するかを決定することは、それぞれカーネルｂおよびｅ次第である。
【0150】
上記では、本開示で提示される実施形態が参照される。しかしながら、本開示の範囲は、特定の記載された実施形態に限定されない。代わりに、記載された特徴および要素の任意の組み合わせは、異なる実施形態に関連するかどうかにかかわらず、想定される実施形態を実装および実施することが想定される。さらに、本明細書に開示された実施形態は、他の可能な解決策または従来技術を超える利点を達成することができるが、所与の実施形態によって特定の利点が達成されるかどうかは、本開示の範囲を限定するものではない。したがって、前述の態様、特徴、実施形態および利点は単なる例示であり、特許請求の範囲に明示的に記載されている場合を除いて、添付の特許請求の範囲の要素または限定とは見なされない。
【0151】
当業者には理解されるように、本明細書に開示される実施形態は、システム、方法、またはコンピュータプログラム製品として具現化され得る。したがって、態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または本明細書ではすべて一般に「回路」、「モジュール」、または「システム」と呼ばれ得るソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形態をとることができる。さらに、態様は、コンピュータ可読プログラムコードが具現化された１つまたは複数のコンピュータ可読媒体に具現化されたコンピュータプログラム製品の形態をとることができる。
【0152】
１つまたは複数のコンピュータ可読媒体の任意の組み合わせを利用することができる。コンピュータ可読媒体は、コンピュータ可読信号媒体またはコンピュータ可読記憶媒体であってもよい。コンピュータ可読記憶媒体は、例えば、電子、磁気、光学、電磁気、赤外線、もしくは半導体のシステム、装置、またはデバイス、もしくはこれらの任意の適切な組み合わせであってもよいが、これらに限定されない。コンピュータ可読記憶媒体のより具体的な例（非網羅的なリスト）は、１つまたは複数の配線を有する電気的接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ－ＲＯＭ）、光記憶装置、磁気記憶装置、またはこれらの任意の適切な組み合わせを含む。本明細書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、またはデバイスによって、もしくはそれに関連して使用するためのプログラムを含むか、または記憶することができる任意の有形媒体である。
【0153】
コンピュータ可読信号媒体は、例えばベースバンドにおいて、または搬送波の一部として、コンピュータ可読プログラムコードが内部に具現化された伝搬データ信号を含むことができる。そのような伝搬信号は、電磁気、光学、またはそれらの任意の適切な組み合わせを含むがこれらに限定されない様々な形態のいずれかをとることができる。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、またはデバイスによって、もしくはそれらと関連して使用するためのプログラムを通信、伝搬、または輸送することができる任意のコンピュータ可読媒体であってもよい。
【0154】
コンピュータ可読媒体上に具現化されたプログラムコードは、無線、有線、光ファイバケーブル、ＲＦなど、またはこれらの任意の適切な組み合わせを含むがこれらに限定されない任意の適切な媒体を使用して送信され得る。
【0155】
本開示の態様のための動作を実行するためのコンピュータプログラムコードは、Ｊａｖａ（登録商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで記述することができる。プログラムコードは、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、スタンドアロンソフトウェアパッケージとして、部分的にユーザのコンピュータ上で、部分的にリモートコンピュータ上で、または完全にリモートコンピュータもしくはサーバ上で実行することができる。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを介してユーザのコンピュータに接続されてもよく、または（例えば、インターネットサービスプロバイダを使用してインターネットを介して）外部コンピュータに接続されてもよい。
【0156】
本開示の態様は、本開示に提示された実施形態による方法、装置（システム）、およびコンピュータプログラム製品のフローチャート図および／またはブロック図を参照して以下に説明される。フローチャート図および／またはブロック図の各ブロック、ならびにフローチャート図および／またはブロック図のブロックの組み合わせは、コンピュータプログラム命令によって実施され得ることが理解されよう。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、または他のプログラマブルデータ処理装置のプロセッサに提供されて機械を生成することができ、その結果、コンピュータまたは他のプログラマブルデータ処理装置のプロセッサを介して実行する命令は、フローチャートおよび／またはブロック図の１つまたは複数のブロックで指定された機能／動作を実施するための手段を作成する。
【0157】
これらのコンピュータプログラム命令はまた、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイスに特定の方法で機能するように指示することができるコンピュータ可読媒体に記憶されてもよく、その結果、コンピュータ可読媒体に記憶された命令は、フローチャートおよび／またはブロック図の１つまたは複数のブロックで指定された機能／動作を実施する命令を含む製品を製造する。
【0158】
コンピュータプログラム命令はまた、コンピュータ、他のプログラマブル装置、または他のデバイス上で一連の動作ステップを実行させてコンピュータ実施プロセスを生成するために、コンピュータ、他のプログラマブルデータ処理装置、または他のデバイスにロードされてもよく、その結果、コンピュータ、または他のプログラマブル装置上で実行する命令は、フローチャートおよび／またはブロック図の１つまたは複数のブロックで指定された機能／動作を実施するためのプロセスを提供する。
【0159】
図のフローチャートおよびブロック図は、本発明の様々な例によるシステム、方法、およびコンピュータプログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関して、フローチャートまたはブロック図の各ブロックは、指定されたロジック機能を実施するための１つまたは複数の実行可能命令を含むモジュール、セグメント、または命令の一部を表すことができる。いくつかの代替実施態様では、ブロックに記載された機能は、図に記載された順序とは異なる順序で行われてもよい。例えば、連続して示される２つのブロックは、実際には、実質的に同時に実行されてもよく、またはブロックは、関連する機能に応じて、時には逆の順序で実行されてもよい。また、ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図のブロックの組み合わせは、指定された機能または動作を実行するか、専用ハードウェアとコンピュータ命令の組み合わせを実行する、専用ハードウェアベースのシステムによって実装されてもよいことに留意されたい。
【0160】
上記は特定の例を対象としているが、その基本的な範囲から逸脱することなく他のおよびさらなる例を考案することができ、その範囲は以下の特許請求の範囲によって決定される。
【図1】
【図2】
【図3A】
【図3B】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20A】
【図20B】
【図21】
【図22A】
【図22B】
【図23A】
【図23B】