特許 7542005 高位ソフトウェア・コードによって定義される演算を実行するためのハードウェア・デバイスを実現する方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-08-21

(45)【発行日】2024-08-29

(54)【発明の名称】高位ソフトウェア・コードによって定義される演算を実行するためのハードウェア・デバイスを実現する方法

(51)【国際特許分類】

   G06F 30/327 20200101AFI20240822BHJP

   G06F 30/343 20200101ALI20240822BHJP

【ＦＩ】

G06F30/327

G06F30/343

【請求項の数】 8

(21)【出願番号】P 2021563674

(86)(22)【出願日】2020-04-23

(65)【公表番号】

(43)【公表日】2022-06-29

(86)【国際出願番号】 IB2020053848

(87)【国際公開番号】W WO2020217201

(87)【国際公開日】2020-10-29

【審査請求日】2023-04-21

(31)【優先権主張番号】102019000006380

(32)【優先日】2019-04-26

(33)【優先権主張国・地域又は機関】IT

(73)【特許権者】

【識別番号】521467102

【氏名又は名称】フクセレラーテ エッセ．エッレ．エッレ．

(74)【代理人】

【識別番号】110000855

【氏名又は名称】弁理士法人浅村特許事務所

(72)【発明者】

【氏名】シラクサ、マルコ

(72)【発明者】

【氏名】ラボッツィ、マルコ

(72)【発明者】

【氏名】ディ トゥッチ、ロレンツォ

(72)【発明者】

【氏名】サンタンブロジオ、マルコ ドメニコ

(72)【発明者】

【氏名】ピッツァート、ファビオ

【審査官】合田 幸裕

(56)【参考文献】

【文献】特開２０１６－１７７４５４（ＪＰ，Ａ）

【文献】国際公開第２０１７／１３５２１９（ＷＯ，Ａ１）

【文献】国際公開第２００５／０７２０５４（ＷＯ，Ａ２）

【文献】Jieru Zhao et al.，COMBA: A Comprehensive Model-Based Analysis Framework for High Level Synthesis of Real Applications，2017 IEEE/ACM International Conference on Computer-Aided Design (ICCAD)，米国，IEEE，2017年11月13日，pages 430-437，<DOI: 10.1109/ICCAD.2017.8203809>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ３０／００ － ３０／３９８

ＩＥＥＥ Ｘｐｌｏｒｅ

ＪＳＴＰｌｕｓ（ＪＤｒｅａｍＩＩＩ）

(57)【特許請求の範囲】

【請求項1】

高位ソフトウェア・コードによって定義される演算を実行するためのハードウェア・デバイスを実現するコンピュータ実装された方法であって、
前記高位ソフトウェア・コードを、前記高位ソフトウェア・コードによって定義される同じ演算を実行するための、対応する低位ソフトウェア・コードにトランスレートするステップであって、前記低位ソフトウェア・コードが低位演算を定義する、ステップと、
前記低位ソフトウェア・コードを実行するために製造又は構成され得るハードウェア・デバイスのセットのうちの各ハードウェア・デバイスについて、以下の演算、すなわち
各低位演算（ｏｐ）について、及び前記ハードウェア・デバイスのハードウェア・リソース（ｒ）の各タイプについて、前記ハードウェア・デバイスを用いて前記低位演算（ｏｐ）を実装するために必要とされる前記タイプのハードウェア・リソースの使用量（ｕ_ｏｐ，ｒ）を評価することと、
前記低位演算のうちの各低位演算（ｏｐ）について、前記低位ソフトウェア・コード内の前記低位演算の実行時出現数（ｏ_ｏｐ）を評価することと、
前記ハードウェア・リソース（ｒ）の各タイプについて、前記タイプの対応する必要なハードウェア・リソースの数（ｃ_ｒ）を、前記低位演算（ｏｐ）の前記実行時出現数（ｏ_ｏｐ）とハードウェア・リソース（ｒ）の前記タイプの対応する前記使用量（ｕ_ｏｐ，ｒ）との積の、すべての前記低位演算にわたる和として計算することと、
前記ハードウェア・デバイスに対するスケール因子（ＳＦ）を、前記必要なハードウェア・リソースの数（ｃ_ｒ）と、前記ハードウェア・リソース（ｒ）の前記タイプの前記ハードウェア・デバイス内の利用可能なハードウェア・リソースの所定量との間の比の最大値として計算することと、
前記ハードウェア・デバイスのピーク性能値（Ｐ）を、前記低位演算の前記実行時出現数（ｏ_ｏｐ）と、前記ハードウェア・デバイスによって実行可能な１秒当たりの低位演算の数を定義するレート（ｆ）との積を前記スケール因子（ＳＦ）で除した値の、すべての前記低位演算にわたる和として計算することと、
を実行するステップと、
前記セットの各ハードウェア・デバイスについて計算されたそれぞれの前記ピーク性能値（Ｐ）に応じて、製造又は構成されるべき前記セットの前記ハードウェア・デバイスを選択するステップと、
前記高位ソフトウェア・コードを実行するための前記ハードウェア・デバイスを製造又は構成するステップと、
を含む、方法。

【請求項2】

前記セットの各ハードウェア・デバイスについて、
前記低位ソフトウェア・コードが実行されるときに前記ハードウェア・デバイスのメモリとの間で転送されるデータの全バイト数（ｔｂ）を評価するステップと、
前記低位ソフトウェア・コードの演算強度（ＣＩ）を、前記低位演算の前記実行時出現数（ｏ_ｏｐ）と、前記メモリとの間で転送されるデータの全バイト数（ｔｂ）との間の比の、すべての前記低位演算にわたる和として計算するステップと、
前記ハードウェア・デバイスの前記メモリとの間でデータを転送するための最大帯域幅（ｂｗ）を評価するステップと、
前記ハードウェア・デバイスのメモリ転送性能値（Ｐｍ）を、前記演算強度（ＣＩ）と前記最大帯域幅（ｂｗ）との積として計算するステップと、
前記セットの各ハードウェア・デバイスについて計算されたそれぞれの前記メモリ転送性能値（Ｐｍ）にも応じて、製造又は構成されるべき前記セットの前記ハードウェア・デバイスを選択するステップと、
を含む、請求項１に記載の方法。

【請求項3】

前記低位ソフトウェア・コードが、
ＬＬＶＭフロントエンド・コンパイラを用いて、前記高位ソフトウェア・コードを前記低位ソフトウェア・コードに変換することと、
前記実行時出現数（ｏ_ｏｐ）及び前記使用量（ｕ_ｏｐ，ｒ）を評価するためにＬＬＶＭコンパイラを用いて前記低位ソフトウェア・コードを処理することと、
によって生成される、請求項１又は２に記載の方法。

【請求項4】

前記低位演算のうちの各低位演算（ｏｐ）についてリソース評価アルゴリズムによって前記ハードウェア・デバイスのハードウェア・リソースの各タイプの前記使用量（ｕ_ｏｐ，ｒ）を評価するステップを更に含む、請求項１から３までのいずれか一項に記載の方法。

【請求項5】

ハードウェア・リソースの前記タイプがブロックＲＡＭ、ＤＳＰ、フリップ・フロップ、ルック・アップ・テーブル及びエリアである、請求項１から４までのいずれか一項に記載の方法。

【請求項6】

前記ハードウェア・デバイスがＦＰＧＡ上に構成され、又はＡＳＩＣとして製造され、前記方法が、満たされるべき前記ピーク性能値（Ｐ）及びメモリ転送性能値（Ｐｍ）に基づいて好適なＦＰＧＡ構成又はＡＳＩＣを識別するために前記低位ソフトウェア・コード上で設計空間探索アルゴリズムを実行するステップを含む、請求項２を引用する場合の請求項３から５のいずれか一項に記載の方法。

【請求項7】

前記ピーク性能値（Ｐ）が、前記低位ソフトウェア・コードの前記低位演算のうちの低位演算のサブセットにわたって計算される、請求項１から６までのいずれか一項に記載の方法。

【請求項8】

前記演算強度（ＣＩ）が、前記低位ソフトウェア・コードの前記低位演算のうちの低位演算のサブセットにわたって計算される、請求項２を引用する場合の請求項３から７のいずれか一項に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、アルゴリズムのハードウェア実装のための高位合成ツールに関し、より詳細には、高位ソフトウェア・コードによって定義される演算を実行するためのハードウェア・デバイスを実現する方法に関する。

【背景技術】

【0002】

高性能計算（ＨＰＣ：Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｍｐｕｔｉｎｇ）及びクラウドの両方との関係で、計算性能及びエネルギー効率のソリューションに対してますます増大する需要は、異種システムの採用に向かっている。市場で入手可能なハードウェア・アクセラレータのうち、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）は、一方で性能と電力効率の間の魅力的なトレードオフを提供し、他方でその再構成可能性の特徴による自由度の高いソリューションを提供する。その利益にもかかわらず、ＦＰＧＡ技術の広範な採用に対する主要な制限要因の１つは、プログラミング性におけるその複雑さである［１］。他方、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）は、更に高い開発及び設計時間と引き換えではあるが最良の電力性能プロファイルを提供するが、ＦＰＧＡに特有の再構成可能性の特徴を欠く。今日、ハードウェア記述言語（ＨＤＬ：Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）によるより従来的な開発に比べてハードウェア設計時間を着実に短縮するために、高位合成（ＨＬＳ：Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ）ツールが広く使用されている。設計者はアルゴリズムの高位表現（例えばＣ／Ｃ＋＋）から開始して、コードの特定の部分を参照するいくつかの最適化ディレクティブを指定することができる。このようなディレクティブは、プラグマの形態で与えられることが多く、対応するカーネルを実装するための高位アーキテクチャの選択を定義することが可能である。このアプローチは、得られる性能／設計時間比に関して極めて効果的であるが、ＨＬＳツールは最終設計を生成するために一定の長さの時間を依然として必要とする。更に、最終設計の性能は主として、最適化ディレクティブの最良のセットを選択する際のユーザの経験に依存する。

【0003】

この理由のため、ＨＬＳ最適化ディレクティブの設計空間探索（ＤＳＥ：Ｄｅｓｉｇｎ Ｓｐａｃｅ Ｅｘｐｌｏｒａｔｉｏｎ）を自動化するためのいくつかの研究が提案されており［２］～［５］、比較的短時間で最適なカーネル設計を達成するためのさまざまな方法を提案している。使用されている探索方法の品質にもかかわらず、このような研究はオフチップ・メモリとの間のメモリ転送を明示的に考慮せず、カーネル入出力がオンチップで完全にキャッシュ可能であることも仮定していない。結果として、カーネルが例えばＸｉｌｉｎｘのＳＤＡｃｃｅｌ設計フロー［６］におけるようなＡＸＩインタフェースを通じてオフチップのＤＤＲメモリと通信するとき、メモリ転送における非効率性が最適化ディレクティブの有効性を容易に脅かし得る。従って、カーネル自体を最適化する前に、現在の性能ボトルネックがどこに存在するかを識別することが重要である。ＨＬＳツールは、アルゴリズムのソフトウェア記述のいくつかのハードウェア実装を探索することを可能にするディレクティブを提供する。ＨＬＳディレクティブは計算量の観点からハードウェア設計を改善することが可能であるが、ほとんどの場合、メモリ転送の最適化は設計者によるコード再構造化を必要とする。この側面は、ＨＬＳディレクティブのみを目標とするＤＳＥアプローチの有効性を制限する。

【0004】

この関係で、ルーフライン・モデル（ｒｏｏｆｌｉｎｅ ｍｏｄｅｌ）［７］、［８］は、特定のアーキテクチャ上で動作する或る特定のアプリケーションの性能限界を分析するために使用可能である。この分析モデルにより、アルゴリズムがメモリ依存型であるかどうか、及び設計者がコンピュータ固有の最適化ディレクティブを調査する前にコードを再構造化しメモリ転送最適化を適用すべきかどうかを迅速に確認することが可能となる。

【0005】

以下、ＨＬＳディレクティブの自動化探索及びルーフライン・モデル分析による関連研究について概観する。

【0006】

Ａ．自動ＨＬＳコード最適化
文献におけるいくつかの研究は、異なる状況においてＨＬＳ最適化ディレクティブを効率的に探索するための方法を提案している［２］～［５］。詳細には、［４］は、ターゲット・コードから導出されるサンプル設計のセット上で予備的なＨＬＳを数回実行する。ＤＳＥを駆動するための分析線型モデルの基礎としてＨＬＳリソース及び性能報告が使用される。分析モデルは、アルゴリズムのループ階層性に関してパラメータ化され、アルゴリズム自体よりもむしろアプリケーションのカテゴリ化に対する評価を提供する。更に、ツールは基礎となるＨＬＳツールの実行に依拠し、ＨＬＳツールは、ターゲット・コードに従って、実行のために大量の時間を必要とする可能性がある。ＣＯＭＢＡ［２］及びＬｉｎ－Ａｎａｌｙｚｅｒ［３］のような他のアプローチは、外部のＨＬＳツールを必要としない。特に、Ｌｉｎ－Ａｎａｌｙｚｅｒは、プログラム・トレースから得られる動的データ依存性グラフを活用して、ＤＳＥによって必要とされるリソース及び性能評価を導出する。他方、ＣＯＭＢＡは、Ｃｌａｎｇフロントエンド［２０］から生成されるＬＬＶＭ［９］中間表現（ＩＲ：Ｉｎｔｅｒｍｅｄｉａｔｅ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）上で直接静的コード分析を実行する。ＣＯＭＢＡは、分析モデルを使用してリソース及び性能評価を加速し再帰的に計算するために、最上位関数の階層的なデータ・フロー・グラフ（ＤＦＧ：Ｄａｔａ－Ｆｌｏｗ Ｇｒａｐｈ）を構築する。［２］及び［３］の両方はＤＳＰ消費を考慮しているが、いくつかのシナリオで最も制約的なリソースとなり得るＬＵＴ使用量を評価していない。その上、両方のアプローチとも、コードの複雑さを大幅に低減する可能性のあるｉｎｓｔｃｏｍｂｉｎｅ及びｇｖｎ［１０］などの、ループ展開後に適用されるコード最適化の効果を考慮していない。従って、このようなアプローチは、カーネル・レイテンシを評価する際にかなり正確な結果を提供するにもかかわらず、リソース消費を過大評価する傾向がある。最後に、前の研究とは異なり、［５］はオフチップ・メモリ転送の影響を考慮している。それにもかかわらず、その作業セットがオンチップでキャッシュ可能なロード－計算－保存パラダイムを用いたアプリケーションに制限される。

【0007】

我々の研究では、組込み及びカスタムの両方のＬＬＶＭコンパイラ・パスを備えるプリプロセッシング最適化ステップにより強化されたＣＯＭＢＡの同じモデルベースのアプローチを採用する。このようにして、設計空間をより正確に探索し、ＣＯＭＢＡがリソース要件の過大評価により実現不可能とみなすソリューションを識別することができる。

【0008】

Ｂ．一般化されたルーフライン・モデル
ルーフライン・モデル［７］をＦＰＧＡベースのアーキテクチャに適応させるための最初の研究のうちの１つは［８］であり、そこで著者はＨＬＳツールの使用に依拠してルーフライン・モデルを構築するための方法を提案している。ループ展開によってもたらされる演算強度の増大を活用して、ＨＬＳツールにより、ユーザはいくつかの展開されたバージョンの性能及びリソース使用量を評定することができ、補間によりルーフライン・モデルが得られる。しかし、この研究は、演算強度及びピーク性能の両方の計算について自動化が欠けている。このような制限は［１１］によって対処され、これはＯｐｅｎＣＬカーネルに対するルーフライン・モデルを半自動的に構築するためのツールを提示している。ピーク帯域幅及びピーク性能が、加速すべき計算を考慮することなくターゲット・アーキテクチャ上のベンチマークを通じて計算される。それにもかかわらず、ＦＰＧＡ及びＡＳＩＣは、実行すべき計算に従ってハードウェア・アクセラレータを定義することが可能であるため、計算独立なピーク性能の仮定はアプローチの信頼性を低下させる。他方、［１２］では、ピーク性能が入力アルゴリズムも考慮して計算される。データシートで提供されるデータを組み合わせて、それらは２つの因子、すなわちカーネルによって要求される浮動小数点加算及び乗算の比と、それらの実装のために使用されるＤＳＰ及びＬＵＴリソースの比、に従っていくつかのピーク性能値を計算している。この研究は加速すべきアルゴリズムを部分的に考慮しているにもかかわらず、これらの２つの因子が提供するのはアルゴリズムの粗視化された分類のみである。その上、ユーザはＤＳＰ及びＬＵＴ使用量の比を手動で指定しなければならない。

【先行技術文献】

【非特許文献】

【0009】

【文献】Ｄ．Ｆ．Ｂａｃｏｎ、Ｒ．Ｍ．Ｒａｂｂａｈ、Ｓ．Ｓｈｕｋｌａ ｅｔ ａｌ．、「Ｆｐｇａ ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ ｔｈｅ ｍａｓｓｅｓ」、Ｃｏｍｍｕｎ．ＡＣＭ、ｖｏｌ．５６、ｎｏ．４、５６～６３頁、２０１３

【文献】Ｊ．Ｚｈａｏ、Ｌ．Ｆｅｎｇ、Ｓ．Ｓｉｎｈａ、Ｗ．Ｚｈａｎｇ、Ｙ．Ｌｉａｎｇ、ａｎｄ Ｂ．Ｈｅ、「Ｃｏｍｂａ： Ａ ｃｏｍｐｒｅｈｅｎｓｉｖｅ ｍｏｄｅｌ－ｂａｓｅｄ ａｎａｌｙｓｉｓ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｈｉｇｈ ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｏｆ ｒｅａｌ ａｐｐｌｉｃａｔｉｏｎｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ３６ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ－Ａｉｄｅｄ Ｄｅｓｉｇｎ． ＩＥＥＥ Ｐｒｅｓｓ、２０１７、４３０～４３７頁

【文献】Ｇ．Ｚｈｏｎｇ、Ａ．Ｐｒａｋａｓｈ、Ｙ．Ｌｉａｎｇ、Ｔ．Ｍｉｔｒａ、ａｎｄ Ｓ．Ｎｉａｒ、「Ｌｉｎ－ａｎａｌｙｚｅｒ： ａ ｈｉｇｈ－ｌｅｖｅｌ ｐｅｒｆｏｒｍａｎｃｅ ａｎａｌｙｓｉｓ ｔｏｏｌ ｆｏｒ ｆｐｇａ－ｂａｓｅｄ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ５３ｒｄ Ａｎｎｕａｌ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ． ＡＣＭ、２０１６、１３６頁

【文献】Ｇ．Ｚｈｏｎｇ、Ｖ．Ｖｅｎｋａｔａｒａｍａｎｉ、Ｙ．Ｌｉａｎｇ、Ｔ．Ｍｉｔｒａ、ａｎｄ Ｓ．Ｎｉａｒ、「Ｄｅｓｉｇｎ ｓｐａｃｅ ｅｘｐｌｏｒａｔｉｏｎ ｏｆ ｍｕｌｔｉｐｌｅ ｌｏｏｐｓ ｏｎ ｆｐｇａｓ ｕｓｉｎｇ ｈｉｇｈ ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ」、ｉｎ ２０１４ ＩＥＥＥ ３２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｄｅｓｉｇｎ （ＩＣＣＤ）、２０１４年１０月、４５６～４６３頁

【文献】Ｊ．Ｃｏｎｇ、Ｐ．Ｗｅｉ、Ｃ．Ｈ．Ｙｕ、ａｎｄ Ｐ．Ｚｈａｎｇ、「Ａｕｔｏｍａｔｅｄ ａｃｃｅｌｅｒａｔｏｒ ｇｅｎｅｒａｔｉｏｎ ａｎｄ ｏｐｔｉｍｉｚａｔｉｏｎ ｗｉｔｈ ｃｏｍｐｏｓａｂｌｅ， ｐａｒａｌｌｅｌ ａｎｄ ｐｉｐｅｌｉｎｅ ａｒｃｈｉｔｅｃｔｕｒｅ」、ｉｎ ２０１８ ５５ｔｈ ＡＣＭ／ＥＳＤＡ／ＩＥＥＥ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ （ＤＡＣ）． ＩＥＥＥ、２０１８、１～６頁

【文献】Ｌ．Ｗｉｒｂｅｌ、「Ｘｉｌｉｎｘ ｓｄａｃｃｅｌ： ａ ｕｎｉｆｉｅｄ ｄｅｖｅｌｏｐｍｅｎｔ ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ ｔｏｍｏｒｒｏｗ’ｓ ｄａｔａ ｃｅｎｔｅｒ」、Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ、Ｔｈｅ Ｌｉｎｌｅｙ Ｇｒｏｕｐ Ｉｎｃ、Ｔｅｃｈ． Ｒｅｐ．、２０１４

【文献】Ｓ．Ｗｉｌｌｉａｍｓ、Ａ．Ｗａｔｅｒｍａｎ、ａｎｄ Ｄ．Ｐａｔｔｅｒｓｏｎ、「Ｒｏｏｆｌｉｎｅ： Ａｎ ｉｎｓｉｇｈｔｆｕｌ ｖｉｓｕａｌ ｐｅｒｆｏｒｍａｎｃｅ ｍｏｄｅｌ ｆｏｒ ｍｕｌｔｉｃｏｒｅ ａｒｃｈｉｔｅｃｔｕｒｅｓ、」Ｃｏｍｍｕｎ．ＡＣＭ、ｖｏｌ．５２、ｎｏ．４、６５～７６頁、２００９年４月．［オンライン］．入手可能： ｈｔｔｐ：／／ｄｏｉ．ａｃｍ．ｏｒｇ／１０．１１４５／１４９８７６５．１４９８７８５

【文献】Ｂ．ｄａ Ｓｉｌｖａ、Ａ．Ｂｒａｅｋｅｎ、Ｅ．Ｈ．Ｄ’Ｈｏｌｌａｎｄｅｒ、ａｎｄ Ａ．Ｔｏｕｈａｆｉ、「Ｐｅｒｆｏｒｍａｎｃｅ ｍｏｄｅｌｉｎｇ ｆｏｒ ｆｐｇａｓ： Ｅｘｔｅｎｄｉｎｇ ｔｈｅ ｒｏｏｆｌｉｎｅ ｍｏｄｅｌ ｗｉｔｈ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｔｏｏｌｓ」、Ｉｎｔ．Ｊ．Ｒｅｃｏｎｆｉｇ．Ｃｏｍｐｕｔ．、ｖｏｌ．２０１３、７：７～７：７頁、２０１３年１月．［オンライン］．入手可能： ｈｔｔｐ：／／ｄｘ．ｄｏｉ．ｏｒｇ／１０．１１５５／２０１３／４２８０７８

【文献】Ｃ．Ｌａｔｔｎｅｒ ａｎｄ Ｖ．Ａｄｖｅ、「Ｌｌｖｍ： Ａ ｃｏｍｐｉｌａｔｉｏｎ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｌｉｆｅｌｏｎｇ ｐｒｏｇｒａｍ ａｎａｌｙｓｉｓ ＆ ｔｒａｎｓｆｏｒｍａｔｉｏｎ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｄｅ ｇｅｎｅｒａｔｉｏｎ ａｎｄ ｏｐｔｉｍｉｚａｔｉｏｎ： ｆｅｅｄｂａｃｋ－ｄｉｒｅｃｔｅｄ ａｎｄ ｒｕｎｔｉｍｅ ｏｐｔｉｍｉｚａｔｉｏｎ． ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ、２００４、７５頁

【文献】Ｃ．Ｌａｔｔｎｅｒ、「ＬＬＶＭ ａｎｄ Ｃｌａｎｇ： Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｍｐｉｌｅｒ Ｔｅｃｈｎｏｌｏｇｙ」、Ｉｎ Ｔｈｅ ＢＳＤ Ｃｏｎｆｅｒｅｎｃｅ、２００８年５月

【文献】Ｊ．Ｏｐｐｅｒｍａｎｎ、Ａ．Ｋｏｃｈ、Ｔ．Ｙｕ、ａｎｄ Ｏ．Ｓｉｎｎｅｎ、「Ｄｏｍａｉｎ－ｓｐｅｃｉｆｉｃ ｏｐｔｉｍｉｓａｔｉｏｎ ｆｏｒ ｔｈｅ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｏｆ ｃｅｌｌｍｌ－ｂａｓｅｄ ｓｉｍｕｌａｔｉｏｎ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ ２０１５ ２５ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ （ＦＰＬ）． ＩＥＥＥ、２０１５、１～７頁

【文献】Ｓ．Ｍｕｒａｌｉｄｈａｒａｎ、Ｋ．Ｏ’Ｂｒｉｅｎ、ａｎｄ Ｃ．Ｌａｌａｎｎｅ、「Ａ ｓｅｍｉ－ａｕｔｏｍａｔｅｄ ｔｏｏｌ ｆｌｏｗ ｆｏｒ ｒｏｏｆｌｉｎｅ ａｎａｙｌｓｉｓ ｏｆ ｏｐｅｎｃｌ ｋｅｒｎｅｌｓ ｏｎ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ Ｆｉｒｓｔ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｈｉｇｈ－ｐｅｒｆｏｒｍａｎｃｅ Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｃｏｍｐｕｔｉｎｇ （Ｈ２ＲＣ’１５）、２０１５

【文献】Ｊ．ｄｅ Ｆｉｎｅ Ｌｉｃｈｔ、Ｋ．Ｆ．Ｌａｒｓｅｎ、Ｔ．Ｈｏｅｆｌｅｒ、ａｎｄ Ｓ．Ｒａｍｏｓ、「Ｍｏｄｅｌｉｎｇ ａｎｄ ｉｍｐｌｅｍｅｎｔｉｎｇ ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｐｒｏｇｒａｍｓ ｏｎ ｆｐｇａ」、Ｍａｓｔｅｒ’ｓ ｔｈｅｓｉｓ、Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃｏｐｅｎｈａｇｅｎ、Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ、２０１６

【文献】ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＬＬＶＭ

【文献】ｈｔｔｐｓ：／／ｌｌｖｍ．ｏｒｇ／ＰｒｏｊｅｃｔｓＷｉｔｈＬＬＶＭ／

【文献】Ｘｉｌｉｎｘ Ｉｎｃ．、「Ｖｉｖａｄｏ ＨＬＳ」［オンライン］．入手可能： ｈｔｔｐｓ：／／ｗｗｗ．ｘｉｌｉｎｘ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｄｅｓｉｇｎ－ｔｏｏｌｓ／ｖｉｖａｄｏ／ｉｎｔｅｇｒａｔｉｏｎ／ｅｓｌ－ｄｅｓｉｇｎ．ｈｔｍｌ

【文献】Ｊ．Ｍ．Ｃｏｄｉｎａ、Ｊ．Ｌｌｏｓａ、ａｎｄ Ａ．Ｇｏｎｚａ’ｌｅｚ、「Ａ ｃｏｍｐａｒａｔｉｖｅ ｓｔｕｄｙ ｏｆ ｍｏｄｕｌｏ ｓｃｈｅｄｕｌｉｎｇ ｔｅｃｈｎｉｑｕｅｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １６ｔｈ ｉｎｔｅｒｎａｔｉｏｎａｌ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｕｐｅｒｃｏｍｐｕｔｉｎｇ． ＡＣＭ、２００２、９７～１０６頁

【文献】Ｌ．ｄｅ Ｓｏｕｚａ Ｒｏｓａ、Ｃ．Ｂｏｕｇａｎｉｓ、ａｎｄ Ｖ．Ｂｏｎａｔｏ、「Ｓｃａｌｉｎｇ ｕｐ ｍｏｄｕｌｏ ｓｃｈｅｄｕｌｉｎｇ ｆｏｒ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ」、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ ｏｆ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ、１～１頁、２０１８

【文献】Ｊ．Ｃｏｎｇ ａｎｄ Ｚ．Ｚｈａｎｇ、「Ａｎ ｅｆｆｉｃｉｅｎｔ ａｎｄ ｖｅｒｓａｔｉｌｅ ｓｃｈｅｄｕｌｉｎｇ ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ ｓｄｃ ｆｏｒｍｕｌａｔｉｏｎ」、ｉｎ ２００６ ４３ｒｄ ＡＣＭ／ＩＥＥＥ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ． ＩＥＥＥ、２００６、４３３～４３８頁

【文献】Ｌ．－Ｎ．Ｐｏｕｃｈｅｔ、「Ｐｏｌｙｂｅｎｃｈ： Ｔｈｅ ｐｏｌｙｈｅｄｒａｌ ｂｅｎｃｈｍａｒｋ ｓｕｉｔｅ」、ＵＲＬ： ｈｔｔｐ：／／ｗｗｗ． ｃｓ． ｕｃｌａ． ｅｄｕ／ｐｏｕｃｈｅｔ／ｓｏｆｔｗａｒｅ／ｐｏｌｙｂｅｎｃｈ、２０１２

【文献】Ｅ．Ｄｅｌ Ｓｏｚｚｏ、Ｍ．Ｒａｂｏｚｚｉ、Ｌ．Ｄｉ Ｔｕｃｃｉ、Ｄ．Ｓｃｉｕｔｏ、ａｎｄ Ｍ．Ｄ．Ｓａｎｔａｍｂｒｏｇｉｏ、「Ａ ｓｃａｌａｂｌｅ ｆｐｇａ ｄｅｓｉｇｎ ｆｏｒ ｃｌｏｕｄ ｎ－ｂｏｄｙ ｓｉｍｕｌａｔｉｏｎ」、ｉｎ ２０１８ ＩＥＥＥ ２９ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ Ｓｙｓｔｅｍｓ、Ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ Ｐｒｏｃｅｓｓｏｒｓ （ＡＳＡＰ）． ＩＥＥＥ、２０１８、１～８頁

【文献】Ｌ．Ｄｉ Ｔｕｃｃｉ、Ｋ．Ｏ’Ｂｒｉｅｎ、Ｍ．Ｂｌｏｔｔ、ａｎｄ Ｍ．Ｄ．Ｓａｎｔａｍｂｒｏｇｉｏ、「Ａｒｃｈｉｔｅｃｔｕｒａｌ ｏｐｔｉｍｉｚａｔｉｏｎｓ ｆｏｒ ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ａｎｄ ｅｎｅｒｇｙ ｅｆｆｉｃｉｅｎｔ ｓｍｉｔｈ－ｗａｔｅｒｍａｎ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｎ ｆｐｇａｓ ｕｓｉｎｇ ｏｐｅｎｃｌ」、ｉｎ Ｄｅｓｉｇｎ、Ａｕｔｏｍａｔｉｏｎ ＆ Ｔｅｓｔ ｉｎ Ｅｕｒｏｐｅ Ｃｏｎｆｅｒｅｎｃｅ ＆ Ｅｘｈｉｂｉｔｉｏｎ （ＤＡＴＥ）、２０１７． ＩＥＥＥ、２０１７、７１６～７２１頁

【発明の概要】

【発明が解決しようとする課題】

【0010】

上記の制限を克服するため、最大性能を満たすために実現されるハードウェア・デバイス、特にＦＰＧＡ上に構成され、又はＡＳＩＣとして製造されるハードウェア・デバイスを実現するように、高位ソフトウェア・コードによって定義される或る特定のアルゴリズムによって達成可能な最大性能を自動的に計算するための新規なアプローチを提案する。

【課題を解決するための手段】

【0011】

本開示による方法は添付の特許請求の範囲に規定され、高位ソフトウェア・コードを高位ソフトウェア・コードによって定義される同じ演算を実行するための低位演算を定義する対応する低位ソフトウェア・コードにトランスレートするステップと、次いで高位ソフトウェア・コードを実行するために製造又は構成され得るハードウェア・デバイスの少なくともピーク性能値Ｐを計算するために特定のパラメータを評価することと、それぞれのピーク性能値Ｐに応じて製造又は構成されるべきハードウェア・デバイスを選択することと、最後に高位ソフトウェア・コードを実行するために選択されたハードウェア・デバイスを製造又は構成することとに基づく。

【0012】

本開示の方法の一態様によれば、ソフトウェア・コードが実行されるときに前記ハードウェア・デバイスのメモリとの間で転送されるデータの全バイト数と、メモリとの間でデータを転送するための最大帯域幅が評価され、そして低位ソフトウェア・コードの演算強度が計算される。最後に、ハードウェア・デバイスのメモリ転送性能値が、演算強度と最大帯域幅との積として計算され、製造又は構成されるべきハードウェア・デバイスがメモリ転送性能値にも応じて選択される。

【0013】

一態様によれば、低位ソフトウェア・コードが、ＬＬＶＭフロントエンド・コンパイラ、例えばＣｌａｎｇフロントエンド・コンパイラ又はＦｌａｎｇフロントエンド・コンパイラ（ｈｔｔｐｓ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／ＬＬＶＭ、ｈｔｔｐｓ：／／ｌｌｖｍ．ｏｒｇ／ＰｒｏｊｅｃｔｓＷｉｔｈＬＬＶＭ／）を用いて、高位ソフトウェア・コードを低位ソフトウェア・コードに変換することによって、及び各演算の実行時出現数及びハードウェア・リソースの使用量を評価するためにＬＬＶＭコンパイラを用いて低位ソフトウェア・コードを処理することによって生成され、ハードウェア・リソースは、非限定的な例として、ブロックＲＡＭ、ＤＳＰ、フリップ・フロップ、ルック・アップ・テーブル及びエリアであってもよい。

【0014】

一態様によれば、ハードウェア・デバイスがＦＰＧＡ上に構成され、又はＡＳＩＣとして製造され、ハードウェア・デバイスが、満たされるべきピーク性能値及びメモリ転送性能値に基づいて好適なＦＰＧＡ構成又はＡＳＩＣを識別するために低位ソフトウェア・コード上で設計空間探索アルゴリズムを実行することによって実現される。

【図面の簡単な説明】

【0015】

【図1】本開示の方法の一態様を例示するブロック図である。

【図2】２つのＰｏｌｙＢｅｎｃｈテスト・ケース、すなわちａ）Ｇｅｓｕｍｍｖテスト・ケース、ｂ）Ｍｍテスト・ケース、に対してＤＳＥによって探索される設計のパレート図である。

【図3】Ｎ体アルゴリズムに対する最適化プロセスを表すルーフライン・モデルのグラフである。

【発明を実施するための形態】

【0016】

本開示は、高位ソフトウェア・コードによって定義される或る特定のアルゴリズムによって達成可能な最大性能を満たすために実現されるハードウェア・デバイス、特にＦＰＧＡ上に構成され、又はＡＳＩＣとして製造されるハードウェア・デバイスを実現するための方法を提供する。最適なＨＬＳベースのハードウェア実装の生成において設計者を支援するための包括的な方法も提供される。

【0017】

第１に、ターゲット・アルゴリズムの高位ソフトウェア・コード記述から開始する自動化されたルーフライン・モデル生成を提案する。本アプローチは、ターゲット関数の演算強度の高速な評定を可能にし、現在のＨＬＳ実装の主要なボトルネックを可視化して、どのようにそれを改善すべきかの指針を提供する。第２に、最適な実装を識別するために異なるＨＬＳディレクティブを迅速に評定するためのＤＳＥ方法を提示する。我々は、ＰｏｌｙＢｅｎｃｈテスト・スイートからのいくつかのベンチマークに対するＤＳＥを評定し、文献における従来の自動化されたソリューションと比較して１４．３６倍までの性能改善を達成した。最後に、我々はＮ体物理シミュレーション・アルゴリズムに対する全体的方法を検証し、特注の最新技術の実装に匹敵する結果を達成した。

【0018】

これらの動機の下で、ルーフライン・モデル分析を自動ＤＳＥと組み合わせて最適化ディレクティブの最適なセットを選択する包括的方法を提案する。この研究の新規な寄与は以下の通りである。
－ 設計者が性能ボトルネック及びオフチップ・メモリ転送最適化を評定し、与えられた目的関数に従ってハードウェア・デバイスのセット内で最も好適なハードウェア・デバイスを選択することを可能にするために役立つように、アルゴリズムの所与のターゲット・ハードウェア・デバイス（すなわち、ＦＰＧＡ又はＡＳＩＣ技術）及び高位ソフトウェア・コードに対するルーフライン・モデル分析を生成するための自動的アプローチ。
－ 加速されるべきアプリケーション及び基礎となるターゲット・ハードウェア・デバイスの両方を考慮するアプリケーション・ピーク性能限界を予測するための分析モデル。
－ きめ細かい評価によって推進され、利用可能なハードウェア・リソースの徹底的な活用を可能にするＨＬＳ最適化ディレクティブの自動化されたＤＳＥ。

【0019】

セクションＩは、提案される方法の概観を提供し、アプリケーション設計者がどのようにしてその方法から利益を得ることができるかを示す。セクションＩＩは、所与の高位ソフトウェア実装から性能及びリソース評価を得るための我々のアプローチを説明する。セクションＩＩＩは、ルーフライン・モデル分析を考察し、我々がその生成をどのように自動化し、ＦＰＧＡベースのアーキテクチャ又は所与のＡＳＩＣ技術にそれを適応させたかについて説明する。セクションＩＶは、最適なＨＬＳディレクティブの識別のためのＤＳＥを提示する。最後にセクションＶは、提案される方法を評定する。

【0020】

Ｉ．提案されるアプローチの概観
／／ ループ実行を展開及びパイプライン化する
ｖｏｉｄ ＿＿ｌｏｏｐ＿ｕｎｒｏｌｌ＿＿（）；
ｖｏｉｄ ＿＿ｌｏｏｐ＿ｕｎｒｏｌｌ＿ｐａｒｔｉａｌ＿＿（ｕｉｎｔ３２＿ｔ ｆａｃｔｏｒ）；
ｖｏｉｄ ＿＿ｌｏｏｐ＿ｐｉｐｅｌｉｎｅ＿＿（）；

／／ 特定の変数及び次元に対する配列分割を指定する
ｅｎｕｍ ｐ＿ｔｙｐｅ ｛ ＢＬＯＣＫ， ＣＯＭＰＬＥＴＥ， ＣＹＣＬＩＣ ｝；
ｖｏｉｄ ＿＿ａｒｒａｙ＿ｐａｒｔｉｔｉｏｎ＿＿（ｃｏｎｓｔ ｖｏｉｄ ＊ｖａｒｉａｂｌｅ， ｐ＿ｔｙｐｅ ｔｙｐｅ， ｕｉｎｔ３２＿ｔ ｆａｃｔｏｒ， ｕｉｎｔ３２＿ｔ ｄｉｍｅｎｓｉｏｎ）；

／／ 関数引数に対するＩ／Ｏインタフェースを指定する
ｖｏｉｄ ＿＿ａｘｉ＿ｍａｓｔｅｒ＿＿（ｖｏｉｄ ＊ａｒｇｕｍｅｎｔ， ｃｏｎｓｔ ｃｈａｒ ＊ｂｕｎｄｌｅ＿ｎａｍｅ）；

リスト出力１：特定の設計構成を指定するための最適化ディレクティブ

【0021】

我々の方法のさまざまなステップを図１に詳細に示す。本アプローチは、ターゲット・ハードウェアと、Ｖｉｖａｄｏ ＨＬＳ［１３］からのプラグマに類似した最適化プラグマで拡張された（Ｃ／Ｃ＋＋などの）ターゲット高位ソフトウェア・コードとを入力として取る。我々はリスト出力１でレポートされるフォーマットを有するＡＸＩプロトコル・インタフェースによってループ展開、ループ・パイプライン化、ループ平坦化、配列分割及びメモリ転送を指定するプラグマをサポートする。文献［２］における他のアプローチと同様に、我々は、ターゲット関数におけるすべてのループ限界が既知であることを要求する。これは、カーネル・レイテンシを評価するためにＤＳＥによって、及びピーク性能及び演算強度を自動的に導出するためにルーフライン・モデル生成によって必要とされる。

【0022】

我々の方法によって実行される第１のステップは、（Ｃ及びＣ＋＋などの）高位ソフトウェア入力コードからのＬＬＶＭ ＩＲの生成を含む。続いて、初期性能及びリソース評価を提供するためにＬＬＶＭ ＩＲを分析する。性能は、カーネル関数をスケジューリングしクリティカル・パスのレイテンシを計算することによって評価される一方、リソース使用量は、スケジュール内の演算のリソース利用を考慮して評価される。このフェーズをサポートするために、我々の方法は、性能及びリソース・モデリングのライブラリを特徴として備える。このライブラリは、本明細書の残りの部分では単にプロファイリング・ライブラリと呼ばれるが、相異なる周波数で合成された演算に対するターゲット・ハードウェアの実現に対して使用される合成ツールによって報告される性能（レイテンシ、タイミング）及び（ＢＲＡＭ、ＤＳＰ、ＦＦ、ＬＵＴ及びエリアなどの）リソース使用量の推定を含む。

【0023】

合成ツールの例は、ＦＰＧＡ構成の実現のためのＸｉｌｉｎｘによるＶｉｖａｄｏ ＨＬＳ／Ｖｉｖａｄｏ並びに所与の技術のＡＳＩＣを目的とするＭｅｎｔｏｒによるＣａｔａｐｕｌｔ ＨＬＳ及びＳｙｎｏｐｓｙｓによるＤｅｓｉｇｎ Ｃｏｍｐｉｌｅｒである。

【0024】

次のステップで、ワークフローはルーフライン・モデル分析を自動的に生成し、それをウェブベースのユーザ・インタフェースに可視化し、そこで性能限界、演算強度及び初期設計の評価性能が同じチャートに示される。この時点で、ユーザは、コードを再構造化し、ルーフライン・モデル分析によって識別されたメモリ・ボトルネックを克服しようと試みてもよく、又は最適化ディレクティブの自動化されたＤＳＥで続行してもよい。ＤＳＥが実行される場合、ＤＳＥによって生じた最良の実現可能な設計の評価性能がルーフライン・モデル・チャートに直接プロットされる。このようにして、ユーザは、ピーク性能又は帯域幅限界のいずれかによって制限される潜在的な達成可能な性能と、ＤＳＥによって導出されるソリューションの実際の性能との両方に関して、現在の設計構成の包括的なビューを有する。最後に、ユーザは、コードを修正するか、又は手動の最適化ディレクティブを指定する可能性も有する。結果として得られるコードは、ルーフライン・モデル分析及びＤＳＥが繰り返し実行される更なる反復のための基準バージョンとして使用可能である。全体として、提案される方法は、分析されるソリューションに固有の性能及びメモリ・ボトルネックを考慮しながら、ユーザが最適な設計に向けて反復的に収束することを可能にする。次のセクションでは、我々のアプローチのフェーズについて詳細に説明する。

【0025】

ＩＩ．性能及びリソース評価
このセクションでは、ターゲット・コードのＬＬＶＭ ＩＲに対して実行される軽量のリソース及び性能評価を提示する。全体的なプロセスは、評価の精度を改善するために必要とされる組込みＬＬＶＭパス及びカスタム・パスの両方に依拠する。特に、我々はＬＬＶＭからの標準のＯ１レベル最適化を適用することによって開始するが、これは商用の高位合成ツールにおいても一般的である。続いて、以下のカスタム・パス、すなわち、ｌｏｏｐ ｕｎｒｏｌｌｉｎｇ最適化ディレクティブによってマークされるループの展開、結合的演算子（ａｓｓｏｃｉａｔｉｖｅ ｏｐｅｒａｔｏｒ）のツリー・バランシング、一定メモリ・アクセスの分析及び伝播、型（タイプ）操作のための範囲分析、命令冗長性除去及び乗法－加法演算に対するリソース・マッピング、を適用する。更に、カスタム・パスの後にコードの品質を更に改善することができる（ｉｎｓｔｃｏｍｂｉｎｅ及びｇｖｎなどの）追加的な組込みＬＬＶＭパスを適用する。

【0026】

コード最適化の後、関数は、その全体的なレイテンシを評価するためにスケジューリングされる。本アプローチは、各基本ブロックの到着時刻を、そのプレデセサ（ｐｒｅｄｅｃｅｓｓｏｒ）の到着時刻及び基本ブロック自体のレイテンシを再帰的に考慮して計算する。プレデセサがループなどの複雑な構造である場合、そのレイテンシは、その基本ブロックに対するのと同じアプローチを再帰的に適用することによって計算される。カーネル関数のレイテンシは、関数が呼出しから戻る基本ブロックの到着時刻から取得される。更に、ループのレイテンシは、特定の最適化ディレクティブに従ってループ本体のレイテンシから取得される。ループ展開はコード変換として直接適用されるため、パイプライン化されたループとパイプライン化されていないループとを区別するだけでよい。パイプライン化が適用されていない場合、ループ・レイテンシは、反復レイテンシＩＬと反復数Ｎとの積として計算される。パイプライン化されたループについては、代わりに、ループ・レイテンシはＩＬ＋ＩＩ＊（Ｎ１）として計算される。但しＩＩはループの開始間隔である。我々は、探索を加速するため、時間のかかるモジュロ・スケジューリング・アルゴリズム［１４］～［１６］を実行することなく、最小開始間隔［１４］としてＩＩを近似する。我々は最小開始間隔［１４］をＭＩＩ＝ｍａｘ（ＲｅｃＭＩＩ，ＲｅｓＭＩＩ）として計算する。但し、ＲｅｃＭＩＩ及びＲｅｓＭＩＩは再帰制約最小開始間隔及びリソース制約最小開始間隔に対する寄与である。ＲｅｃＭＩＩは、アキュムレーションなどのループ伝搬依存性によって与えられる開始間隔に対する制約である。それはＲｅｃＭＩＩ＝ｍａｘ_ｉ［ｄｅｌａｙ_ｉ／ｄｉｓｔａｎｃｅ_ｉ］として計算される。但し、ｄｅｌａｙ_ｉはｉ番目の依存性の依存性経路に沿ったクロック・サイクル単位の遅延であり、ｄｉｓｔａｎｃｅ_ｉはループ反復を通るｉ番目の再帰の距離である。各依存性について考慮される経路は、宛先演算から出発しバック・エッジを通過してソース演算に至る経路である。ＲｅｓＭＩＩは、代わりに、制限された機能ユニットのリソース使用量に対する制約である。一般に、それはＲｅｓＭＩＩ＝ｍａｘ_ｉ［ｎｕｍＯｐｓ_ｉ／ｎｕｍＦＵｓ_ｉ］として計算される。但し、ｎｕｍＯｐｓ_ｉはループ内の型（タイプ）ｉの演算の数であり、ｎｕｍＦＵｓ_ｉは型（タイプ）ｉの利用可能な機能ユニットの数である。我々の場合、制約された演算はメモリにアクセスする演算であり、メモリは分割可能であるため、公式はＲｅｓＭＩＩ＝ｍａｘ_ｉ［ｎｕｍＡｃｃｓ_ｉ／ｎｕｍＰｏｒｔｓ_ｉ］と書き直すことができる。但し、ｎｕｍＡｃｃｓ_ｉはｉ番目の分割に対するアクセス数であり、ｎｕｍＰｏｒｔｓ_ｉはｉ番目の分割にアクセスするために利用可能なポートの数である。特定のループによって実行される反復の数Ｎは、ループ誘導変数に適用されるＬＬＶＭスカラー・エボリューション分析から得られるそのトリップ・カウントに等しい。しかし、パイプライン化されたループを含む完全にネストしたループに対するループ平坦化最適化を考慮するために、我々はループ反復の割当てを修正する。特に、パイプライン化された最も内側のループを有する完全なループ・ネストに対して、パイプライン化されたループによって実行される反復の数は、ループ・ネスト内のすべてのループのトリップ・カウントの積に等しいが、ループ・ネスト内の他のループには１に等しい反復数が割り当てられる。このアプローチにより、ループ平坦化が実行されるときに生じる単一ループへのループ・ネストの崩壊をエミュレートする。

【0027】

ループに対して適用される最適化とは別に、単一反復のレイテンシは、ヘッダ・ブロックがプレデセサを持たないとみなして、そのラッチ・ブロックの到着時刻から得られる。最後に、単一の基本ブロックのレイテンシは、命令チェイン化を含むリソース制約リスト・スケジューリング・アルゴリズムの適応ＡＬＡＰバージョンを用いて計算される。このアルゴリズムは、同じクロック・サイクル内の同じメモリ・ポートにアクセスする命令に制約を課する。これは、各分割について１つのキューをインスタンス化することによってモデル化される分割された配列へのアクセスと、外部ＡＸＩインタフェースへのアクセスとを考慮する。各キューは、それがモデル化する分割を識別する（ｂａｓｅＡｄｄｒ，ｉｄ_１，ｉｄ_２，．．．，ｉｄ_ｎ－１）に等しいインデックスを有する。但し、ｂａｓｅＡｄｄｒは、アクセスされるｎ次元配列のベース・アドレスであり、ｉｄ_ｉは各次元ｉに関連する分割インデックスである。各次元ｉに対するインデックスｉｎｄｅｘ_ｉへのメモリ・アクセスが与えられると、アクセスされる対応するキューは次のように決定される。
－ ｉｄ_ｉ＝［ｉｎｄｅｘ_ｉ／［ｓｉｚｅ_ｉ／ｆ_ｉ］］、ブロック分割の場合
－ ｉｄ_ｉ＝（ｉｎｄｅｘ_ｉ）ｍｏｄ（ｆ_ｉ）、周期的分割の場合
－ ｉｄ_ｉ＝ｉｎｄｅｘ_ｉ、完全な分割の場合
但し、ｓｉｚｅ_ｉは次元ｉのサイズであり、ｆ_ｉは次元ｉの分割因子である。カーネルがスケジューリングされると、ターゲット・ハードウェアに固有の各リソース型（リソースタイプ）に対する全体的なリソース消費が評価される。我々のモデルでは、２^{［ｌｏｇ２（ｐａｒｔｉｔｉｏｎＳｉｚｅ／ｃａｐａｃｉｔｙ）］}＊ｐａｒｔｉｔｉｏｎｓに等しい、或る配列を割り当てるためのＢＲＡＭバンクの量を考慮する。但し、ｐａｒｔｉｔｉｏｎＳｉｚｅは各分割のビット単位のサイズであり、ｃａｐａｃｉｔｙはＢＲＡＭバンクの容量であり、ｐａｒｔｉｔｉｏｎｓは配列を構成する分割の総数である。演算子によって与えられるリソース消費は、異なるクロック・サイクルで計算を開始する同じ演算子のインスタンス間で共有するリソースを考慮しながら、プロファイリング・ライブラリから取られる。最後に、リソース共有によって導入される多重化及びルーティング・ロジックによるＬＵＴ及びＦＦ使用量もモデル化する。リソース評価に関するより詳細な記述は以下の通りである。

【0028】

１）式：或るアルゴリズムを構成する式のインスタンスは、ＤＳＰ、ＦＦ及びＬＵＴなどのリソースを消費し得る。異なるクロック・サイクルで実行される共有可能な演算子は再使用可能であり、リソースを節約するが、ルーティング複雑性を増加させる。この理由のため、少なくとも１つのＤＳＰ（通常は極めて重要なリソースである）及びレイテンシが１以上の複雑な演算を利用するだけの２つの式の共有を許容する。我々は共有可能な演算子を完全にパイプライン化されているとみなすため、或る基本ブロック内で単一の演算子によって必要とされるインスタンスの数は、同じクロック・サイクル内でそれらの計算を開始する或る演算子のインスタンスの最大数に依存する。このデータを、再使用が適用されない場合にインスタンス化される演算子の数と組み合わせることにより、或る演算子の再使用レートを計算することが可能となる。共有不可能な演算子によって必要とされるインスタンスの数は、代わりに、アプリケーションによって使用されるその型（タイプ）の演算子の数だけに依存する。アプリケーションによって必要とされるインスタンスの数が得られると、この量を、プロファイリング・ライブラリによって与えられる単一のインスタンスの評価されたリソース使用量と乗算する。

【0029】

２）部分的結果の保存：複数のクロック・サイクルにわたる計算の部分的結果はレジスタ（ＦＦ）に保存される。従って、結果が更なる計算のために保存されなければならないために命令をチェイン化することができないことを考慮して、ＦＦ使用量を評価する。単一の命令のＦＦ使用量は、演算のビット幅に対するこれらの命令の量を乗算することで計算することができ、その演算子の再使用因子で重み付けされ得る。

【0030】

３）共有リソースのルーティング：リソースの共有は、インスタンスに右オペランドを供給するためのマルチプレクサの使用を必要とする。マルチプレクサはＬＵＴを用いて実装されるため、各オペランドについて再使用因子によって与えられる入力数を有するマルチプレクサが使用されると仮定して、我々は所与の入力数を有するマルチプレクサを実装するために必要とされるＬＵＴの数を計算し、その結果各インスタンスに対するＬＵＴ使用量を計算することができる。

【0031】

ＩＩＩ．自動化されたルーフライン・モデル分析
このセクションでは、古典的なルーフライン・モデル［７］をＦＰＧＡ／ＡＳＩＣにどのように適応させるか、並びに所与のコード及びターゲット・デバイスから開始してルーフライン・モデルをどのように自動的に計算するかについて説明する。ＣＰＵに対する古典的なルーフライン・モデルでは、ピーク帯域幅及びピーク性能の両方がアーキテクチャに依存する一方、演算強度はアルゴリズムの特性である。しかし、ＦＰＧＡ又はＡＳＩＣを考慮する際に、加速すべきターゲット計算とは独立にピーク性能を提供することは正確でない。実際、異なる演算は、ハードウェアにおけるそれらの実装のために異なるリソース消費を要求する。よって、並列に構成され得る処理要素の数、従ってピーク性能は、実行すべき演算に強く依存する。この理由のため、我々は、アルゴリズム及びターゲットのＦＰＧＡ又はＡＳＩＣ技術の両方を説明するピーク性能を計算するための方法を提案する。更に、ルーフライン・モデルの計算は、高位ソフトウェア・コードのＩＲ上で動作するカスタムＬＬＶＭパスによって自動化される。

【0032】

（ＣＰＵのように）固定したアーキテクチャはアーキテクチャ自体と相関する性能メトリック（例えば、毎秒１０億回の浮動小数点演算（ＧＦＬＯＰｓ：Ｇｉｇａ ＦＬｏａｔｉｎｇ－ｐｏｉｎｔ ＯＰｅｒａｔｉｏｎｓ ｐｅｒ ｓｅｃｏｎｄ））を有するにもかかわらず、（ＦＰＧＡのように）再構成可能なアーキテクチャ又はＡＳＩＣは、（合成されるとアルゴリズム自体がターゲット・アーキテクチャを定義するため）合成されるべきアルゴリズムにそれらの性能メトリックをより良好に関係づける。例えば、画像処理アルゴリズムを考えると、意味のある性能メトリックは、ハードウェア実装を用いて実行される１秒当たりの処理画像数であり得る。この理由のため、ユーザは好ましい性能メトリックを次の２つのフォーマットで指定することが可能である。
－ 測定されるべき演算のセットを定義する（ＧＦＬＯＰｓなど）。
－ 結果が生成されるコードの場所に、スループット・メトリック（結果／ｓ）をこのように定義するカスタム・ディレクティブを挿入する。

【0033】

実際には、スループット・メトリックは、計算を担う命令の次にカスタム・ディレクティブ＿ｒｅｓｕｌｔ＿ｇｅｎｅｒａｔｉｏｎ＿（）（ｃｕｓｔｏｍ ｄｉｒｅｃｔｉｖｅ ＿ｒｅｓｕｌｔ＿ｇｅｎｅｒａｔｉｏｎ＿（））を挿入して指定される。関数呼出し（ｌｌｖｍ：：ＣａｌｌＩｎｓｔ命令）については呼び出される関数の名前であることが仮定されるにもかかわらず、我々は、演算子（ｏｐｅｒａｔｏｒ）（又は単にｏｐ）として、単一のＬＬＶＭ命令（ａｄｄ、ｆｍｕｌ、．．．）を識別する文字列を意図する。性能メトリックのフォーマットとは無関係に、ユーザにより対象とされる演算子のサブセットを定義する必要がある。従って、我々はまずコードを構成する演算子のセットＯＰを定義し、ユーザにより対象とされる演算子のセットをＳＯＰ⊆ＯＰと名づける。第１のフォーマットが考慮される場合、ユーザは測定したい演算子のセットＳＯＰを直接定義する。第２のフォーマットが考慮される場合、セットＳＯＰ＝｛ｏｐ_ｒ｝である。但し、ｏｐ_ｒはスループットを指定するために必要とされる関数呼出し＿ｒｅｓｕｌｔ＿ｇｅｎｅｒａｔｉｏｎ＿（）（ｆｕｎｃｔｉｏｎ ｃａｌｌ ＿ｒｅｓｕｌｔ＿ｇｅｎｅｒａｔｉｏｎ＿（））を識別する単一の演算子である。アルゴリズムを実装して、そのインデックスがセットＯＰの要素である（ｍａｐ）データ構造体ＯＰ_ｍａｐを定義し、インデックス付けされた項目は、静的コード分析によって計算されるアルゴリズム実行中の関連するインデックス演算子の実行数である。ＬＬＶＭフレームワークによってコードを分析してＯＰｍａｐを埋める。詳細には、分析はｋｅｒｎｅｌｆｕｎｃｔｉｏｎのＬＬＶＭ ＩＲから開始し、各基本ブロックｂｂを経由し、更に基本ブロックｂｂは含まれる各命令ｉを経由する。

【0034】

各基本ブロックｂｂ∈ｋｅｒｎｅｌｆｕｎｃｔｉｏｎについて、分析は、その基本ブロックが存在するループ・ネストを考慮して、その基本ブロックが実行される回数ｅ_ｂｂを計算する。ループ限界はコンパイル時に既知であると推定されるため、リスト出力２を用いてｅ_ｂｂを計算することができる。

【0035】

ｕｎｓｉｇｎｅｄ ｌｏｎｇ ｌｏｎｇ ｃｏｍｐｕｔｅＥｘｅｃｕｔｉｏｎＴｉｍｅｓ（ｌｌｖｍ：：ＢａｓｉｃＢｌｏｃｋ ＊ｂｂ） ｛
ｌｌｖｍ：：ＬｏｏｐＩｎｆｏ ＊ＬＩ ＝ ＆ｇｅｔＡｎａｌｙｓｉｓ＜ｌｌｖｍ：：ＬｏｏｐＩｎｆｏＷｒａｐｐｅｒＰａｓｓ＞（）．ｇｅｔＬｏｏｐＩｎｆｏ（）；
ｌｌｖｍ：：ＳｃａｌａｒＥｖｏｌｕｔｉｏｎ ＊ＳＥ ＝ ＆ｇｅｔＡｎａｌｙｓｉｓ＜ｌｌｖｍ：：ＳｃａｌａｒＥｖｏｌｕｔｉｏｎＷｒａｐｐｅｒＰａｓｓ＞（）．ｇｅｔＳＥ（）；

ｕｎｓｉｇｎｅｄ ｌｏｎｇ ｌｏｎｇ ｅｘｅｃｕｔｉｏｎＴｉｍｅｓ ＝ １；

ｌｌｖｍ：：Ｌｏｏｐ ＊ｐａｒｅｎｔＬｏｏｐ ＝ ＬＩ－＞ｇｅｔＬｏｏｐＦｏｒ（ｂｂ）；

ｗｈｉｌｅ （ｐａｒｅｎｔＬｏｏｐ ！＝ ｎｕｌｌｐｔｒ） ｛
ｅｘｅｃｕｔｉｏｎＴｉｍｅｓ ＊＝ ＳＥ－＞ｇｅｔＳｍａｌｌＣｏｎｓｔａｎｔＴｒｉｐＣｏｕｎｔ（ｐａｒｅｎｔＬｏｏｐ）；
ｐａｒｅｎｔＬｏｏｐ ＝ ｐａｒｅｎｔＬｏｏｐ－＞ｇｅｔＰａｒｅｎｔＬｏｏｐ（）；
｝

ｒｅｔｕｒｎ ｅｘｅｃｕｔｉｏｎＴｉｍｅｓ；

リスト出力２：或る基本ブロックｂｂが実行される回数を計算するために必要とされるｃｏｍｐｕｔｅＥｘｅｃｕｔｉｏｎＴｉｍｅｓ関数のＣ＋＋コード

【0036】

各命令ｉ∈ｂｂについて、分析は
－ （前述のように）関連する演算子ｏｐ_ｉを計算し、
－ 演算子ｏｐ_ｉが既にＯＰ_ｍａｐ内の何らかの値のインデックスであるかどうかをチェックする。
－ もしそうなら、インデックス付けされた値をｅ_ｂｂだけ増加させ（但し、ｂｂはその命令を含む基本ブロックである）、
－ さもなければ、インデックス付けされた値をｅ_ｂｂで初期化して、インデックスｏｐ_ｉをＯＰ_ｍａｐに挿入する（但し、ｂｂはその命令を含む基本ブロックである）。

【0037】

同様にして、ＡＸＩマスタ／スレーブ・インタフェース（しかしこれに限定されない）にマップされる関数引数へのメモリ・アクセスの総数もカウントし、アクセスされる全バイト数ｔｂを導出する。ユーザは、関数ｆにディレクティブ＿ａｘｉ＿ｍａｓｔｅｒ＿（ａｒｇ，ｂｕｎｄｌｅ）を挿入して、関数ｆの或る特定の引数ａｒｇがＡＸＩマスタ／スレーブ・インタフェースにマップされることを指定する。ベース・アドレスがＡＸＩマスタ／スレーブ・インタフェースにマップされる或る特定の引数に対応するすべてのｌｌｖｍ：：ＬｏａｄＩｎｓｔ及びｌｌｖｍ：：ＳｔｏｒｅＩｎｓｔを考慮して、転送されるバイト数を計算する。特に、変数ｔｂをゼロに初期化し、各基本ブロックｂｂ∈ｋｅｒｎｅｌｆｕｎｃｔｉｏｎについて、分析は、基本ブロックが存在するループ・ネストを考慮して、基本ブロックが実行される回数ｅ_ｂｂを計算する。ループ限界がコンパイル時に既知であることを仮定しているため、リスト出力２を用いてｅ_ｂｂを計算することができる。各命令ｉ∈ｂｂについて、分析は
－ 命令ｉがｌｌｖｍ：：ＬｏａｄＩｎｓｔ又はｌｌｖｍ：：ＳｔｏｒｅＩｎｓｔ演算であるかどうかをチェックする。
－ もしそうなら、ベース・アドレスが関数ｆの関数引数ａｒｇ_１かどうかをチェックする。
－ もしそうなら、ここでは重要でないバンドルの値を考慮することなく、＿ａｘｉ＿ｍａｓｔｅｒ＿（ａｒｇ，ｂｕｎｄｌｅ）の形の関数呼出し命令がｆ内に存在するかどうかをチェックする。
－ もしそうなら、ロード及び保存される型（タイプ）を考慮して命令ｉのロード又は保存されるバイト数ｔｂ_ｉを取得し、ｔｂの値をｔｂ_ｉの因子だけ増加させる。

【0038】

分析後のｔｂの値は、カーネル実行中のオフチップ・メモリ転送との間で転送される全バイト数を表す。ｏ_ｏｐ及びｔｂが計算されると、次のように演算強度を自動的に計算することができる。

【数1】

【0039】

ピーク性能の評価は、アルゴリズムの演算の間のデータ依存性のないターゲット・ハードウェア上でアルゴリズムの理想的なハードウェア実装を仮定することによって計算される。各演算（例えば浮動小数点加算）に対して、ハードウェア上に物理的に実装される対応する演算子（例えば浮動小数点加算器）を関連付ける。完全にパイプライン化され、ターゲット・クロック周波数ｆで動作する演算子を考える。従って、各クロック・サイクルにおいて、演算子は有効な結果を生成することができる。プロファイリング・ライブラリ内で、ターゲット・ハードウェア、特に所与のＦＰＧＡ又はＡＳＩＣ技術上で、或る特定の周波数で（オフラインで）合成されたいくつかの演算子の性能及びリソース使用量の評価を収集する。詳細には、各ターゲット・ハードウェア及び周波数について、考慮されているターゲット周波数及びターゲット・ハードウェアに従ってフレームワークにライブラリの正しいインスタンスをロードさせるために、コード内に現れるいくつかの演算子に関連付けられたプロファイリング・ライブラリのインスタンスをビルドして、各演算子についてレイテンシ（演算子が完了するために要求されるクロック・サイクル）、タイミング（演算子の最も遅い段階が完了するために要求される最大組合せ時間）及び演算子を実装するために必要とされる（ＢＲＡＭ、ＤＳＰ、ＦＦ、ＬＵＴ及びエリアのような）リソースの量を提供する。プロファイリング・ライブラリをビルドして、ＨＬＳツール（我々の方法の最終設計を最終的に生成するために使用されるものと同じ）によってライブラリを構成するそれぞれの単一の命令を合成する。特に、ａ＝ｆ（ｏｐ_１，ｏｐ_２，．．．，ｏｐ_ｎ）の形の或る特定の命令が与えられる場合、必要とされる評価を提供するために、ＨＬＳツールによって更に合成されるカーネルをビルドするためのテンプレート関数に依拠する。

【0040】

このテンプレートは、合成されるべき命令並びに命令自体の入力及び出力の型（タイプ）（他のパラメータはここでは重要でない）が与えられた場合に、カーネル関数のインスタンスを実装するためのＰｙｔｈｏｎ関数を表すリスト出力３内の文字列カーネルである。

【0041】

ｄｅｆ ｗｒｉｔｅＣｐｐＫｅｒｎｅｌ（ｉＴｙｐｅ， ｏＴｙｐｅ， ｉｎｓｔｒｕｃｔｉｏｎ， ｐｒｏｊｅｃｔＲｏｏｔＰａｔｈ， ｓｏｌｕｔｉｏｎＮｕｍｂｅｒ＝１）：
ｋｅｒｎｅｌ ＝ ”””
＃ｉｎｃｌｕｄｅ ”ａｐ＿ｉｎｔ．ｈ”
＃ｉｎｃｌｕｄｅ ”ａｐ＿ｆｉｘｅｄ．ｈ”
＃ｄｅｆｉｎｅ ｉＴｙｐｅ ””” ＋ ｉＴｙｐｅ ＋ ”””
＃ｄｅｆｉｎｅ ｏＴｙｐｅ ””” ＋ ｏＴｙｐｅ ＋ ”””

ｏＴｙｐｅ ｉｎｎｅｒＫｅｒｎｅｌ（ｉＴｙｐｅ ｖ１， ｉＴｙｐｅ ｖ２） ｛
＃ｐｒａｇｍａ ＨＬＳ ＩＮＬＩＮＥ ｏｆｆ

ｒｅｔｕｒｎ ””” ＋ ｉｎｓｔｒｕｃｔｉｏｎ ＋ ”””；
｝

ｖｏｉｄ ｋｅｒｎｅｌ（ｉＴｙｐｅ ＊ｘ， ｉＴｙｐｅ ＊ｙ， ｏＴｙｐｅ ＊ｚ） ｛

＃ｐｒａｇｍａ ＨＬＳ ＩＮＴＥＲＦＡＣＥ ｓ＿ａｘｉｌｉｔｅ ｐｏｒｔ＝ｘ
＃ｐｒａｇｍａ ＨＬＳ ＩＮＴＥＲＦＡＣＥ ｓ＿ａｘｉｌｉｔｅ ｐｏｒｔ＝ｙ
＃ｐｒａｇｍａ ＨＬＳ ＩＮＴＥＲＦＡＣＥ ｓ＿ａｘｉｌｉｔｅ ｐｏｒｔ＝ｚ
＃ｐｒａｇｍａ ＨＬＳ ＩＮＴＥＲＦＡＣＥ ｓ＿ａｘｉｌｉｔｅ ｐｏｒｔ＝ｒｅｔｕｒｎ

＊ｚ ＝ ｉｎｎｅｒＫｅｒｎｅｌ（＊ｘ，＊ｙ）；

”””

ｆ ＝ ｏｐｅｎ（ｐｒｏｊｅｃｔＲｏｏｔＰａｔｈ ＋ ’／ｋｅｒｎｅｌ．ｃｐｐ’， ’ｗ’）
ｆ．ｗｒｉｔｅ（ｋｅｒｎｅｌ）
ｆ．ｃｌｏｓｅ（）

ｒｅｔｕｒｎ

リスト出力３：プロファイリングされるべき単一の命令からなる単純なＣ＋＋ ＨＬＳカーネルを生成するためのｗｒｉｔｅＣｐｐＫｅｒｎｅｌ Ｐｙｔｈｏｎ関数

【0042】

カーネルが合成されると、ツールは、対象となる命令の必要とされるリソース、レイテンシ及びタイミングを報告する。従って、現在の設定に対応するターゲット周波数及びアーキテクチャを有するプロファイリング・ライブラリがロードされると、ツールはピーク性能の計算を開始することができる。理想的には、ターゲット・ハードウェア上への最大性能を有する実装は、対応する演算カウントｏ_ｏｐと同じ回数だけ各演算子をインスタンス化する必要がある。このような実装は、各リソース型ｒ∈Ｒ＝｛ＢＲＡＭ，ＤＳＰ，ＦＦ，ＬＵＴ，エリア｝について次のようなｃｒ個のリソースを必要とする。

【数2】

但し、ｕ_ｏｐ，ｒは、ロードされたばかりのプロファイリング・ライブラリによって提供される演算子ｏｐ∈ＯＰによって必要とされる型ｒ∈Ｒのリソースの量である。必要とされるリソースはハードウェア・リソース利用可能性を大幅に超過する可能性が非常に高い。従って、ターゲットＦＰＧＡ又は所与のＡＳＩＣのリソース制約（最大エリアなど）の範囲内に収まるために必要とされるリソース低減の量を考慮するために次のスケール因子（ファクター）を計算する。

【数3】

但し、ａｖ_ｒは、ターゲット・ハードウェア上で利用可能な型ｒ∈Ｒのリソースの量である。設計において実装される型ｏｐ∈ＯＰの演算子ｉ_ｏｐの実際の数は、理想的な実装と比較して次のように因子（ファクター）ＳＦ倍にスケーリングされる。

【数4】

そして、ピーク性能限界（１秒当たりの演算の総数に関して）が次のように計算される。

【数5】

【0043】

公式は、各演算子がクロック・サイクルごとに有用な結果を生成することができること（パイプライン化された演算子）、及び演算子が決してアイドルでないこと（データ依存性なし）を考慮している。最後に、ルーフライン・モデル・チャート内で、ルーティング輻輳及びタイミング・クロージャの問題を考慮するために、経験的にＰの８０％をピーク性能とみなす。ピーク帯域幅限界に関しては、ターゲットＦＰＧＡに対するマイクロベンチマークのセットを実行し、又は所与のオフチップ・メモリ及びメモリ相互接続を用いてＡＳＩＣを目的としたときに帯域幅評価を考慮する。マイクロベンチマーク又は評価は、アクセラレータとオフチップ・メモリとの間の通信インタフェースに対する異なる構成を考慮して実行される。特に、使用されるＤＭＡチャネルの数、ＡＸＩインタフェースのビット幅及びバースト長のいくつかの組合せを考慮する。このようにして、所与のコードに対するＨＬＳインタフェースの構成に従って、適切なピーク帯域幅限界を導出することができる。最後に、ハードウェア・デバイスのメモリとの間でデータを転送するための所与のピーク帯域幅（ｂｗ）から、メモリ転送性能限界をＰｍ＝ｂｗ＊ＣＩとして計算することができる。

【0044】

ＩＶ．設計空間探索
いくつかのハードウェア設計構成が、対応して次のディレクティブ構成を選択するために最適化ディレクティブの或る特定のセットによって提供される性能をセクションＩＩに記載したアプローチによって評価して、反復的に探索される。反復全体を通じて、ディレクティブ構成はスタックに保存されるため、或る特定の構成がリソース制約により実現不可能な場合、利用可能なリソースを超過することになった対応するループは完全最適化済みとしてマークされ、後続の最適化については考慮されない。その後、探索は前の実現可能な構成にバックトラックし、コード内の他のループに対する他の最適化機会を探索することを継続する。

【0045】

各反復は次のように実行される。
－ 分析すべきＬＬＶＭ ＩＲ内に最適化ディレクティブを挿入する。
－ 現在の構成の性能及びリソース使用量を評価する。
－ 次の反復において適用するべき最適化ディレクティブを選択する。

【0046】

調査すべき次の構成の選択は、ループ最適化（ループ展開、パイプライン化及び平坦化を通じて）及びローカル・メモリ最適化（配列分割を通じて）を切り替えるコントローラによって実行される。ループ最適化に関して、各ステップで、最も内側のループｌが識別されるまで関数本体又はループに含まれるより高いレイテンシを有するループを再帰的に訪れる。ループｌがまだパイプライン化されていない場合、まずそれをパイプライン化することを試みる。この選択は、ループをパイプライン化することがその展開ほどにはリソース使用量を増大させないため、構成を実現可能に且つ分析をより高速に保つという事実に依拠している。しかし、ｌが既にパイプライン化されている場合、ＤＳＥは、そのループを更に展開することによってより高い性能を達成しようと試みる。ループｌのあらゆる後続の展開最適化は、ループのトリップ・カウントを割り切る次に高い展開因子を選択することによってなされる。

【0047】

あらゆるループ最適化の後に、グローバル・メモリ最適化が続く。実際、ループをパイプライン化又は展開した後、性能が今度は利用可能なメモリ・ポートの数によって制約される可能性がある。このステップにおいて、関数内の各配列ａ及び配列ａの各次元ｄについて、次元ｄにアクセスするために使用される異なるオフセットの数ｋを収集する。その後、次元ｄを因子ｋで分割する。分割内に生じる衝突の数をシミュレートすることによって、サイクリック及びブロック分割の間で選択が行われる。分割当たりの衝突の最大数を最小化する分割型が選択される。次元ｄ内の要素の数に等しい因子ｋでブロック又はサイクリックのいずれかの分割が適用される場合、完全な分割が自動的に実行されることに注意されたい。最後に、探索はループ最適化ステップを続行し、ループがすべて完全に展開されるか、又は完全最適化済みとマークされるかのいずれかの理由でもはや探索すべきループがないときに終了する。

【0048】

Ｖ．実験的評定
ＰｏｌｙＢｅｎｃｈテスト・スイート［１７］上でＨＬＳ最適化ディレクティブに対する我々のＤＳＥを評定し、Ｎ体物理シミュレーションのケース・スタディに対する方法全体を検証する。実験は、Ｉｎｔｅｌ Ｘｅｏｎ Ｅ５－２６８０ ｖ２上で実行される一方、リソース及び性能評価比較のための基準としてＶｉｖａｄｏ ＨＬＳ ２０１８．２を使用する。

【0049】

Ａ．ＰｏｌｙＢｅｎｃｈテスト・スイート
ＰｏｌｙＢｅｎｃｈテスト・スイート［１７］は、異なるループ・ネストを有するいくつかのカーネルを含むベンチマークのコレクションである。これらのベンチマークを通じて、我々の結果を［２］と比較して、我々のアプローチのＤＳＥ効率及び評価精度を評定する。［２］の設定を再現するため、１００ＭＨｚで動作するＸｉｌｉｎｘ Ｖｉｒｔｅｘ－７ ＸＣ７Ｖ２０００Ｔ－ＦＬＧ１９２５ ＦＰＧＡデバイスを対象とする。更に、［２］のレイテンシ及びエリア結果が、彼らの研究で報告された最適な最適化ディレクティブを適用しＶｉｖａｄｏ ＨＬＳ ２０１８．２を実行することによって得られた。

【0050】

表Ｉは、ＤＳＥによって達成された結果を要約する。

【表1】

【0051】

特に、異なるテスト・ケース上での我々のＤＳＥの実行時間について、同じＤＳＥアプローチであるが性能及びリソース評価についてＶｉｖａｄｏ ＨＬＳに依拠するＤＳＥアプローチを実行するために必要とされる実行時間と比較して報告する。表は、ソリューション空間（所与のベンチマークに対する最適化ディレクティブの可能な組合せ）のサイズ及び我々のＤＳＥが最終ソリューションに収束するために必要とされる設計数を報告している。理解されるように、我々のＤＳＥは、同じ最終構成を達成しながら、ＨＬＳベースのソリューションに比べて１／８から１／２８の時間しか必要としない。更に、ＤＳＥは、より大きい設計空間から少数の興味深い最適化構成を効果的に探索する。

【0052】

表Ｉは、ベースラインの最適化されていないＨＬＳ実装に関する改善及びカーネル・レイテンシ全体における短縮に関して［２］によって達成された結果も報告している。更に、表は、我々の最終設計及び［２］からの設計の両方のエリア利用率（最も制約的なリソースを考慮して計算される）を示している。全体として、［２］によって見出された最適構成と比べて７．５３倍の平均レイテンシ短縮が１分未満で達成されているのを観察することができる。改善された結果の主な理由は、リソース及び性能評価フェーズ中に適用された追加的なコード変換並びにＤＳＥコントローラによって採用されたポリシーに由来する。［２］及び我々のＤＳＥは利用可能なリソースを超過することにつながる最適化を探索しないため、我々の正確な予測は探索をあまりに早く停止することを防ぎ、平均でデバイス・エリアの６５．８３％を活用するソリューションに向かって探索を推進し、これは［２］よりも２．０３倍高い。他方、ループ最適化及び配列分割最適化を切り替えることにより、ＤＳＥコントローラは、配列アクセスに従って分割の因子（ファクター）及び型（タイプ）を微調整することが可能である。

【0053】

表ＩＩは、我々のＤＳＥによって見出された最適構成を報告し、ループ最適化が適用された一貫性のある配列分割を我々の方法がどのように識別するかを例示している。

【表2】

【0054】

図２は、２つのテスト・ケース、Ｇｅｓｕｍｍｖ及びＭｍのレイテンシ及びエリア使用量に関してＤＳＥプロセスを記載している。これらのテスト・ケースは収束するために必要なＤＳＥ反復数がそれぞれ最小及び最大であったため、これらのテスト・ケースに注目する。第１のテスト・ケース（Ｇｅｓｕｍｍｖ）は、性能において１．９０％及びリソース使用量において１．２４％の予測誤差で設計空間を探索するのに対して、第２のテスト・ケース（Ｍｍ）は、性能において４．０８％及びリソース使用量において５．６０％の予測誤差を提供する。それぞれのグラフについて、すべての設計を補間して得られた曲線は、ＤＳＥコントローラがループ・パイプライン化（急峻な特性）及びループ展開（線型の特性）をどのように切り替えるかを示し、エリア利用率がそれぞれ７５．５６％及び８０％に収束している。

【0055】

Ｂ．Ｎ体シミュレーション・テスト・ケース
全体的な方法を検証するため、宇宙物理学領域からの実際のアプリケーションであるＮ体物理シミュレーションを考察する。我々は、アルゴリズムの基本的なメモリ限界実装から最適化プロセスを開始し、我々の方法によって、［１８］に匹敵する性能を有するが自動化されたアプローチに従う最終バージョンを達成した。このテスト・ケースの場合、ターゲット設計周波数を１２６ＭＨｚとして、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（ＡＷＳ）上のＸｉｌｉｎｘ Ｖｉｒｔｅｘ ＵｌｔｒａＳｃａｌｅ＋ ＶＵ９Ｐ ＦＰＧＡボードを対象とする。

【0056】

最適化プロセスを開始する前に、スループット・メトリックを指定する必要がある。このステップは、対象となる結果（このケースでは本体比較）が生成されるコード内にカスタム・ディレクティブを挿入することによって実行される。次に、我々の方法によってアルゴリズムのプレーン・バージョンを分析し、図３にすべてのステップを報告している。プロットされたルーフライン分析は、初期設計がメモリ依存型であることを明確に可視化している（図３における緑色の点線）。実際、チャートは、２．１５ｅ－２ペア／Ｂの演算強度を報告し、これはリッジ点の１．３５ペア／Ｂよりも十分に低い。更に、我々の方法は、初期実装について、２．５２ｅ＋６ペア／ｓの性能（図３における緑色の点線上の赤色の三角形）を評価している。しかし、現在の演算強度及び利用可能なメモリ帯域幅（１個のＤＤＲポートで１４．５ＧＢ／ｓ）に対して、ルーフライン・モデルは、メモリ転送に対する限界（［８］［１１］［１９］で広範に議論されているピーク帯域幅のベンチマーク・ベースの評価の精度）により３．１２ｅ＋８ペア／ｓの達成可能性能を報告している。これは、ＤＳＥは３．１２ｅ＋８ペア／ｓよりも低い性能を有する設計のみを見出すことができることを意味し、この性能は、計算限界エリアで到達され得る１．５７ｅ＋１０ペア／ｓの評価ピーク性能よりも明らかに低い。この理由により、リッジ点を超えるために演算強度を改善することを試みる。特に、演算強度を増大させるためにローカル・メモリにおいてデータをキャッシュすることを考慮する。計算の前にローカル・メモリにデータをコピーするための初期フェーズ及び計算の後にデータをホストにコピーするための最終フェーズを追加してカーネルを書き直す。

【0057】

アルゴリズムのキャッシュされたバージョンを分析すると、ＢＲＡＭリソース制約が満たされ、演算強度は６．７７ｅ＋２ペア／Ｂ（図３における青色の点線）に増大し、計算限界エリアに達することが確認される。ルーフライン・モデルに従って、新しい方の実装を用いて、性能がピーク性能（１．５７ｅ＋１０ペア／ｓ）によって制限される設計を見出すことが期待される。自動化されたＤＳＥを実行することによって、評価性能が１．５１ｅ＋１０ペア／ｓ（図３における青色の点線上の赤色の三角形）でエリア使用量が７５．５７％の最適設計が得られ、これは評価性能が理論限界よりも３．７％低いだけのソリューションである。更に、最終設計に対する評価は、０．０００２９８％のレイテンシ評価誤差を報告する。最後に、得られた設計をオンボードで試験し、１．２０７ｅ＋１０ペア／ｓを測定したが、これはメモリ転送オーバーヘッドによるＤＳＥ及びＶｉｖａｄｏ ＨＬＳ評価の両者よりも約２０％低い。最新技術における実装に関して、［１８］における研究は、適合された実装で１．３４４１ｅ＋１０ペア／ｓを達成しているが、我々は性能において８．９８％だけの損失で自動化された探索から得られるソリューションを提供する。

【0058】

本開示は、ターゲット性能要求を満たすＡＳＩＣハードウェア実装又はＦＰＧＡ構成を実現するために高位ソフトウェア・コードの最適化のための包括的な方法を提供する。開示されるアプローチは、所与のセットの中から候補のＦＰＧＡ又はＡＳＩＣ技術を識別すること及びアプリケーションがメモリ又は計算依存型であるかどうかを迅速に識別することを可能にする、ＦＰＧＡ／ＡＳＩＣに対するルーフライン・モデル分析の自動生成と、ＨＬＳ最適化ディレクティブの最適セットの識別のための自動化されたＤＳＥとを組み合わせる。ＤＳＥ効率が、ＰｏｌｙＢｅｎｃｈテスト・スイート上で評定され、これは文献におけるソリューションよりも性能が優れており、カーネル・レイテンシにおいて１４．３６倍までの短縮を達成する。更に、全体的方法が宇宙物理学領域からの実際のアプリケーションに対して検証され、最新技術における特注の実装に匹敵する性能を有するソリューションが得られた。

【0059】

参考文献
［１］Ｄ．Ｆ．Ｂａｃｏｎ、Ｒ．Ｍ．Ｒａｂｂａｈ、Ｓ．Ｓｈｕｋｌａ ｅｔ ａｌ．、「Ｆｐｇａ ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ ｔｈｅ ｍａｓｓｅｓ」、Ｃｏｍｍｕｎ．ＡＣＭ、ｖｏｌ．５６、ｎｏ．４、５６～６３頁、２０１３
［２］Ｊ．Ｚｈａｏ、Ｌ．Ｆｅｎｇ、Ｓ．Ｓｉｎｈａ、Ｗ．Ｚｈａｎｇ、Ｙ．Ｌｉａｎｇ、ａｎｄ Ｂ．Ｈｅ、「Ｃｏｍｂａ： Ａ ｃｏｍｐｒｅｈｅｎｓｉｖｅ ｍｏｄｅｌ－ｂａｓｅｄ ａｎａｌｙｓｉｓ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｈｉｇｈ ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｏｆ ｒｅａｌ ａｐｐｌｉｃａｔｉｏｎｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ３６ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ－Ａｉｄｅｄ Ｄｅｓｉｇｎ． ＩＥＥＥ Ｐｒｅｓｓ、２０１７、４３０～４３７頁
［３］Ｇ．Ｚｈｏｎｇ、Ａ．Ｐｒａｋａｓｈ、Ｙ．Ｌｉａｎｇ、Ｔ．Ｍｉｔｒａ、ａｎｄ Ｓ．Ｎｉａｒ、「Ｌｉｎ－ａｎａｌｙｚｅｒ： ａ ｈｉｇｈ－ｌｅｖｅｌ ｐｅｒｆｏｒｍａｎｃｅ ａｎａｌｙｓｉｓ ｔｏｏｌ ｆｏｒ ｆｐｇａ－ｂａｓｅｄ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ５３ｒｄ Ａｎｎｕａｌ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ． ＡＣＭ、２０１６、１３６頁
［４］Ｇ．Ｚｈｏｎｇ、Ｖ．Ｖｅｎｋａｔａｒａｍａｎｉ、Ｙ．Ｌｉａｎｇ、Ｔ．Ｍｉｔｒａ、ａｎｄ Ｓ．Ｎｉａｒ、「Ｄｅｓｉｇｎ ｓｐａｃｅ ｅｘｐｌｏｒａｔｉｏｎ ｏｆ ｍｕｌｔｉｐｌｅ ｌｏｏｐｓ ｏｎ ｆｐｇａｓ ｕｓｉｎｇ ｈｉｇｈ ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ」、ｉｎ ２０１４ ＩＥＥＥ ３２ｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ Ｄｅｓｉｇｎ （ＩＣＣＤ）、２０１４年１０月、４５６～４６３頁
［５］Ｊ．Ｃｏｎｇ、Ｐ．Ｗｅｉ、Ｃ．Ｈ．Ｙｕ、ａｎｄ Ｐ．Ｚｈａｎｇ、「Ａｕｔｏｍａｔｅｄ ａｃｃｅｌｅｒａｔｏｒ ｇｅｎｅｒａｔｉｏｎ ａｎｄ ｏｐｔｉｍｉｚａｔｉｏｎ ｗｉｔｈ ｃｏｍｐｏｓａｂｌｅ， ｐａｒａｌｌｅｌ ａｎｄ ｐｉｐｅｌｉｎｅ ａｒｃｈｉｔｅｃｔｕｒｅ」、ｉｎ ２０１８ ５５ｔｈ ＡＣＭ／ＥＳＤＡ／ＩＥＥＥ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ （ＤＡＣ）． ＩＥＥＥ、２０１８、１～６頁
［６］Ｌ．Ｗｉｒｂｅｌ、「Ｘｉｌｉｎｘ ｓｄａｃｃｅｌ： ａ ｕｎｉｆｉｅｄ ｄｅｖｅｌｏｐｍｅｎｔ ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ ｔｏｍｏｒｒｏｗ’ｓ ｄａｔａ ｃｅｎｔｅｒ」、Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ、Ｔｈｅ Ｌｉｎｌｅｙ Ｇｒｏｕｐ Ｉｎｃ、Ｔｅｃｈ． Ｒｅｐ．、２０１４
［７］Ｓ．Ｗｉｌｌｉａｍｓ、Ａ．Ｗａｔｅｒｍａｎ、ａｎｄ Ｄ．Ｐａｔｔｅｒｓｏｎ、「Ｒｏｏｆｌｉｎｅ： Ａｎ ｉｎｓｉｇｈｔｆｕｌ ｖｉｓｕａｌ ｐｅｒｆｏｒｍａｎｃｅ ｍｏｄｅｌ ｆｏｒ ｍｕｌｔｉｃｏｒｅ ａｒｃｈｉｔｅｃｔｕｒｅｓ、」Ｃｏｍｍｕｎ．ＡＣＭ、ｖｏｌ．５２、ｎｏ．４、６５～７６頁、２００９年４月．［オンライン］．入手可能： ｈｔｔｐ：／／ｄｏｉ．ａｃｍ．ｏｒｇ／１０．１１４５／１４９８７６５．１４９８７８５
［８］Ｂ．ｄａ Ｓｉｌｖａ、Ａ．Ｂｒａｅｋｅｎ、Ｅ．Ｈ．Ｄ’Ｈｏｌｌａｎｄｅｒ、ａｎｄ Ａ．Ｔｏｕｈａｆｉ、「Ｐｅｒｆｏｒｍａｎｃｅ ｍｏｄｅｌｉｎｇ ｆｏｒ ｆｐｇａｓ： Ｅｘｔｅｎｄｉｎｇ ｔｈｅ ｒｏｏｆｌｉｎｅ ｍｏｄｅｌ ｗｉｔｈ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｔｏｏｌｓ」、Ｉｎｔ．Ｊ．Ｒｅｃｏｎｆｉｇ．Ｃｏｍｐｕｔ．、ｖｏｌ．２０１３、７：７～７：７頁、２０１３年１月．［オンライン］．入手可能： ｈｔｔｐ：／／ｄｘ．ｄｏｉ．ｏｒｇ／１０．１１５５／２０１３／４２８０７８
［９］Ｃ．Ｌａｔｔｎｅｒ ａｎｄ Ｖ．Ａｄｖｅ、「Ｌｌｖｍ： Ａ ｃｏｍｐｉｌａｔｉｏｎ ｆｒａｍｅｗｏｒｋ ｆｏｒ ｌｉｆｅｌｏｎｇ ｐｒｏｇｒａｍ ａｎａｌｙｓｉｓ ＆ ｔｒａｎｓｆｏｒｍａｔｉｏｎ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｏｄｅ ｇｅｎｅｒａｔｉｏｎ ａｎｄ ｏｐｔｉｍｉｚａｔｉｏｎ： ｆｅｅｄｂａｃｋ－ｄｉｒｅｃｔｅｄ ａｎｄ ｒｕｎｔｉｍｅ ｏｐｔｉｍｉｚａｔｉｏｎ． ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｓｏｃｉｅｔｙ、２００４、７５頁
［１０］Ｊ．Ｏｐｐｅｒｍａｎｎ、Ａ．Ｋｏｃｈ、Ｔ．Ｙｕ、ａｎｄ Ｏ．Ｓｉｎｎｅｎ、「Ｄｏｍａｉｎ－ｓｐｅｃｉｆｉｃ ｏｐｔｉｍｉｓａｔｉｏｎ ｆｏｒ ｔｈｅ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｏｆ ｃｅｌｌｍｌ－ｂａｓｅｄ ｓｉｍｕｌａｔｉｏｎ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ ２０１５ ２５ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ （ＦＰＬ）． ＩＥＥＥ、２０１５、１～７頁
［１１］Ｓ．Ｍｕｒａｌｉｄｈａｒａｎ、Ｋ．Ｏ’Ｂｒｉｅｎ、ａｎｄ Ｃ．Ｌａｌａｎｎｅ、「Ａ ｓｅｍｉ－ａｕｔｏｍａｔｅｄ ｔｏｏｌ ｆｌｏｗ ｆｏｒ ｒｏｏｆｌｉｎｅ ａｎａｙｌｓｉｓ ｏｆ ｏｐｅｎｃｌ ｋｅｒｎｅｌｓ ｏｎ ａｃｃｅｌｅｒａｔｏｒｓ」、ｉｎ Ｆｉｒｓｔ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｈｅｔｅｒｏｇｅｎｅｏｕｓ Ｈｉｇｈ－ｐｅｒｆｏｒｍａｎｃｅ Ｒｅｃｏｎｆｉｇｕｒａｂｌｅ Ｃｏｍｐｕｔｉｎｇ （Ｈ２ＲＣ’１５）、２０１５
［１２］Ｊ．ｄｅ Ｆｉｎｅ Ｌｉｃｈｔ、Ｋ．Ｆ．Ｌａｒｓｅｎ、Ｔ．Ｈｏｅｆｌｅｒ、ａｎｄ Ｓ．Ｒａｍｏｓ、「Ｍｏｄｅｌｉｎｇ ａｎｄ ｉｍｐｌｅｍｅｎｔｉｎｇ ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ｐｒｏｇｒａｍｓ ｏｎ ｆｐｇａ」、Ｍａｓｔｅｒ’ｓ ｔｈｅｓｉｓ、Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｃｏｐｅｎｈａｇｅｎ、Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ、２０１６
［１３］Ｘｉｌｉｎｘ Ｉｎｃ．、「Ｖｉｖａｄｏ ＨＬＳ」［オンライン］．入手可能： ｈｔｔｐｓ：／／ｗｗｗ．ｘｉｌｉｎｘ．ｃｏｍ／ｐｒｏｄｕｃｔｓ／ｄｅｓｉｇｎ－ｔｏｏｌｓ／ｖｉｖａｄｏ／ｉｎｔｅｇｒａｔｉｏｎ／ｅｓｌ－ｄｅｓｉｇｎ．ｈｔｍｌ
［１４］Ｊ．Ｍ．Ｃｏｄｉｎａ、Ｊ．Ｌｌｏｓａ、ａｎｄ Ａ．Ｇｏｎｚａ’ｌｅｚ、「Ａ ｃｏｍｐａｒａｔｉｖｅ ｓｔｕｄｙ ｏｆ ｍｏｄｕｌｏ ｓｃｈｅｄｕｌｉｎｇ ｔｅｃｈｎｉｑｕｅｓ」、ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １６ｔｈ ｉｎｔｅｒｎａｔｉｏｎａｌ ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｓｕｐｅｒｃｏｍｐｕｔｉｎｇ． ＡＣＭ、２００２、９７～１０６頁
［１５］Ｌ．ｄｅ Ｓｏｕｚａ Ｒｏｓａ、Ｃ．Ｂｏｕｇａｎｉｓ、ａｎｄ Ｖ．Ｂｏｎａｔｏ、「Ｓｃａｌｉｎｇ ｕｐ ｍｏｄｕｌｏ ｓｃｈｅｄｕｌｉｎｇ ｆｏｒ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ」、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ ｏｆ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ、１～１頁、２０１８
［１６］Ｊ．Ｃｏｎｇ ａｎｄ Ｚ．Ｚｈａｎｇ、「Ａｎ ｅｆｆｉｃｉｅｎｔ ａｎｄ ｖｅｒｓａｔｉｌｅ ｓｃｈｅｄｕｌｉｎｇ ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ ｓｄｃ ｆｏｒｍｕｌａｔｉｏｎ」、ｉｎ ２００６ ４３ｒｄ ＡＣＭ／ＩＥＥＥ Ｄｅｓｉｇｎ Ａｕｔｏｍａｔｉｏｎ Ｃｏｎｆｅｒｅｎｃｅ． ＩＥＥＥ、２００６、４３３～４３８頁
［１７］Ｌ．－Ｎ．Ｐｏｕｃｈｅｔ、「Ｐｏｌｙｂｅｎｃｈ： Ｔｈｅ ｐｏｌｙｈｅｄｒａｌ ｂｅｎｃｈｍａｒｋ ｓｕｉｔｅ」、ＵＲＬ： ｈｔｔｐ：／／ｗｗｗ． ｃｓ． ｕｃｌａ． ｅｄｕ／ｐｏｕｃｈｅｔ／ｓｏｆｔｗａｒｅ／ｐｏｌｙｂｅｎｃｈ、２０１２
［１８］Ｅ．Ｄｅｌ Ｓｏｚｚｏ、Ｍ．Ｒａｂｏｚｚｉ、Ｌ．Ｄｉ Ｔｕｃｃｉ、Ｄ．Ｓｃｉｕｔｏ、ａｎｄ Ｍ．Ｄ．Ｓａｎｔａｍｂｒｏｇｉｏ、「Ａ ｓｃａｌａｂｌｅ ｆｐｇａ ｄｅｓｉｇｎ ｆｏｒ ｃｌｏｕｄ ｎ－ｂｏｄｙ ｓｉｍｕｌａｔｉｏｎ」、ｉｎ ２０１８ ＩＥＥＥ ２９ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ Ｓｙｓｔｅｍｓ、Ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ Ｐｒｏｃｅｓｓｏｒｓ （ＡＳＡＰ）． ＩＥＥＥ、２０１８、１～８頁
［１９］Ｌ．Ｄｉ Ｔｕｃｃｉ、Ｋ．Ｏ’Ｂｒｉｅｎ、Ｍ．Ｂｌｏｔｔ、ａｎｄ Ｍ．Ｄ．Ｓａｎｔａｍｂｒｏｇｉｏ、「Ａｒｃｈｉｔｅｃｔｕｒａｌ ｏｐｔｉｍｉｚａｔｉｏｎｓ ｆｏｒ ｈｉｇｈ ｐｅｒｆｏｒｍａｎｃｅ ａｎｄ ｅｎｅｒｇｙ ｅｆｆｉｃｉｅｎｔ ｓｍｉｔｈ－ｗａｔｅｒｍａｎ ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ｏｎ ｆｐｇａｓ ｕｓｉｎｇ ｏｐｅｎｃｌ」、ｉｎ Ｄｅｓｉｇｎ、Ａｕｔｏｍａｔｉｏｎ ＆ Ｔｅｓｔ ｉｎ Ｅｕｒｏｐｅ Ｃｏｎｆｅｒｅｎｃｅ ＆ Ｅｘｈｉｂｉｔｉｏｎ （ＤＡＴＥ）、２０１７． ＩＥＥＥ、２０１７、７１６～７２１頁
［２０］Ｃ．Ｌａｔｔｎｅｒ、「ＬＬＶＭ ａｎｄ Ｃｌａｎｇ： Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｍｐｉｌｅｒ Ｔｅｃｈｎｏｌｏｇｙ」、Ｉｎ Ｔｈｅ ＢＳＤ Ｃｏｎｆｅｒｅｎｃｅ、２００８年５月

【図1】

【図2】

【図3】