JP7407192B2 - フィールド・プログラマブル・ゲート・アレイのためのコードを最適化する方法および装置 - Google Patents

Description

本出願は、２０１８年８月９日に出願されたポルトガル特許出願第２０１８１００００５４１６６号および２０１８年８月１４日に出願されたヨーロッパ特許出願第１８１８９０２２．９号の優先権および利益を主張する。

本発明は、ハードウェア・アクセラレータのためのコードを最適化する方法および装置に関する。

フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）が、ソフトウェア・アプリケーションの実行を加速するための一般的な解決策になりつつある。ハイレベル合成ツール（ＨＬＳ）の使用は、ソフトウェア開発者が、ＦＰＧＡベースのハードウェア・アクセラレータ上で使用するためのソフトウェア・コードを開発することができるようにするために、ソフトウェア開発者のための抽象度を提供することを目的としている。しかし、ソフトウェア・コードを再構築し、ディレクティブを効率的に使用する必要により、使用されるＨＬＳツールと、ソフトウェア・コードがその上で実行されるＦＰＧＡハードウェアの両方について習熟することが要求される。本明細書に記載の手法は、プログラム実行トレースから生成可能なアンフォールド・グラフ表現を、フォールドなどのグラフ・ベースの最適化とともに使用して、ＨＬＳツールに入力する適切なＣコードを生成する。本明細書に記載の手法は、通常であれば入力ソフトウェア・コードの手動再構築と適切なディレクティブの手動挿入の使用によってのみ実現可能な効率的なハードウェア実装形態を生成することができることを、実験が証明している。

ＦＰＧＡを使用して実装されるハードウェア・アクセラレータは、多くのシステムで必要とされるパフォーマンス向上および／またはエネルギー消費節減をもたらすことができる。最適化された場合、これらのＦＰＧＡベースのハードウェア・アクセラレータは、効率的なエネルギー消費と併せて、高いパフォーマンスが可能である［１］。

アプリケーションのカスタム・ハードウェア実装形態（特定用途向けアーキテクチャとも呼ばれる）は、ハードウェアが十分な資源を提供する限り、複数の独立した演算の並行実行を可能にする。この並行実行は、高い命令レベル並列性（ＩＬＰ）を有するアルゴリズムの実行を加速する。一定程度のＩＬＰを有するアルゴリズムを実行するようにハードウェアを設計するためには、現在の方法は様々な技能を必要とし、きわめて特異なプログラミング言語およびツールの理解を必要とする。効率的なハードウェアを記述することは多大な時間を要する。これらの側面は、ハードウェア・アクセラレータとしてのＦＰＧＡの使用と開発の障害となっている。

上記の問題に対処するために、ハイレベル合成（ＨＬＳ）の分野では、多くの努力がなされてきた。ＨＬＳツールは、Ｃ言語などのソフトウェア・プログラミング言語で知られている抽象度などの高抽象度を使用してプログラマがＦＰＧＡハードウェアを対象とすることを可能にする。このようなより高い抽象度の目的は、開発者がＦＰＧＡをより容易にプログラミングすることができるようにし、他の手法で必要とされる時間を要する作業なしに、より複雑なアプリケーションを扱うことができるようにすることである。しかし、ＨＬＳツールは抽象度を高めるが、ＨＬＳツールは依然としてプログラマがＦＰＧＡハードウェア上で最適化されたソリューションを実装するには、ある程度のハードウェアの専門知識を必要とする。ＨＬＳツールは、プログラミング言語（Ｃなど）に対応することはできるが、そのソフトウェア・コードの構造が、結果として生成されるハードウェアに大きな影響を与える［２］。さらに、ＨＬＳツールの典型的なものは、効率的な実装形態を生成するための追加のディレクティブまたは構成を必要とすることがある。従来技術のＨＬＳツールは、この場合はソフトウェア・プログラマである平均的な当業者が参入するには障壁がある。この参入障壁を低くすることによって、より多くのソフトウェア開発者が、アプリケーションを加速するため、および／または、有意なエルギー消費削減を達成するために、ＦＰＧＡベースのハードウェアの演算能力を使用することができるようになるであろう。

Ｃベースのプログラミング言語は、多くのＨＬＳツールの一般的な入力である［１］。Ｃプログラミング・モデルはＣＰＵに合わせて調整され、ハードウェアの並行性および可能なカスタマイズを考慮していないため、これらの従来技術のＨＬＳツールは、プログラマが構成またはディレクティブを提供することにより合成をガイドすることができるようにすることによって上記の限界を埋め合わせる。

ソフトウェア・コードの構造は生成されるハードウェアのパフォーマンスに大きな影響を与えることも知られている。このハードウェアは、ＦＰＧＡまたはＡＳＩＣとして実装可能である。したがって、従来技術では、通常、複雑なコード再構築を必要とし、ＨＬＳツールとコンパイラは、そのような最適化を提供することができず、それらの自動適用も保証しない場合がある。ＣベースのＨＬＳをより利用しやすくするために、入力ソフトウェア・コードを容易に再構築する方法が必要である。本明細書では、（例えばＦＰＧＡを使用して実装される）特殊用途向けハードウェアを対象とするように最適化されたＣコードを自動的に生成する手法について記載する。コードは、次に、ＦＰＧＡまたはＡＳＩＣを使用した電子回路を製造するために使用することができる。

従来技術
ソース間最適化は、ＨＬＳの分野における研究主題であった。例えば、Ｃｏｎｇら［５］は、コード再構築の問題について簡単に概説し、ソフトウェア開発者のためにコード再構築を容易にするためのフレームワークを提示している。Ｃａｒｄｏｓｏら［６］は、ユーザが、コード変換とディレクティブの挿入とを適用するために戦略をプログラムすることができるようにする手法を提示している。ＬｅｇＵｐ ＨＬＳツール［８］はまた、Ｃを入力として受け付け、ＨＬＳ最適化を実装するために修正ＬＬＶＭコンパイラ［９］によりコード再構築を実装する。

ストリーミング・ベースの計算を特に扱う手法も関連する。例えば、Ｍｅｎｃｅｒは、［７］において、ＡＳＣと呼ばれるＣベースの言語を使用する手法を提示している。ＡＳＣは、ハードウェアでデータ・ストリーミング・ベースの計算を実装するために設計された。Ｍａｘ Ｃｏｍｐｉｌｅｒ［１０］は、Ｊａｖａに基づくＭａｘＪという名称のプログラミング言語でデータフロー・グラフとして記述されたストリーミング計算を実装するためのＨＬＳツールである。［１１］では、著者らは、ＭａｘＪコンパイラの文脈でよりよいＦＰＧＡ実装形態を生成するためのデータ・フロー・グラフ（ＤＦＧ）最適化について論じている。本明細書の方法は、典型的なＣベースのＨＬＳツールのためのより使いやすいコードを提供するために、ソース間コード再構築に焦点を合わせているため、本明細書における手法は上記の研究とは異なる。本記載の方法は、ＬｅｇＵｐおよびＶｉｖａｄｏ ＨＬＳなどのＨＬＳツールのための有用なコード再構築を実現することができるため、別次元の研究とみることができる。ＭａｘＣｏｍｐｉｌｅｒ手法と比較すると、本記載の手法は、再構築されたＭａｘＪコードを提供するためにも使用可能ではあるが、その場合、この方法は、ＭａｘＪコード生成プログラムをバックエンドとして必要とすることになる。さらに、発明者らは、使用されるＤＦＧが、アプリケーションの元のコードをインストルメンテーションし、修正されたアプリケーションの実行によりグラフを得ることによって得られるため、この方法は他の入力プログラミング言語の文脈でも使用可能であることにも着目している。

コンパイラおよびＨＬＳツールの中間表現としてのグラフの使用は一般的である（例えば、Ｄａｎｉｅｌ Ｄ．Ｇａｊｓｋｉ， Ｎｉｋｉｌ Ｄ．Ｄｕｔｔ， Ａｌｌｅｎ Ｃ．－Ｈ．Ｗｕ， ａｎｄ Ｓｔｅｖｅ Ｙ．Ｌ．Ｌｉｎ． １９９２． Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ： Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｃｈｉｐ ａｎｄ Ｓｙｓｔｅｍ Ｄｅｓｉｇｎ． Ｋｌｕｗｅｒ Ａｃａｄｅｍｉｃ Ｐｕｂｌｉｓｈｅｒｓ， Ｎｏｒｗｅｌｌ， ＭＡ， ＵＳＡおよびＪｏａｏ Ｍ． Ｐ． Ｃａｒｄｏｓｏ， Ｐｅｄｒｏ Ｃ．Ｄｉｎｉｚ， Ｍａｒｋｕｓ Ｗｅｉｎｈａｒｄｔ， “Ｃｏｍｐｉｌｉｎｇ ｆｏｒ ｒｅｃｏｎｆｉｇｕｒａｂｌｅ ｃｏｍｐｕｔｉｎｇ： Ａ ｓｕｒｖｅｙ，” ＡＣＭ Ｃｏｍｐｕｔ． Ｓｕｒｖ． ４２（４）： １３：１－１３：６５（２０１０）を参照）。典型的には、入力ソース・コードの構造は制御データフロー・グラフ（ＣＤＦＧ）またはデータフロー・グラフ（ＤＦＧ）、あるいは両者の拡張版によって表され、次に、これらのグラフを使用してコード変換および最適化が適用される。

１つの典型的な事例は、例えばループ制御構造と、誘導変数の値を修正した部分グラフを再現することによって内部的に実装可能なループ・アンロールである。これは、ＨＬＳツールが最適化の一部を適用する典型的な方法である。それらのグラフは、割り当て、バインディングおよびスケジューリングを行うためにも使用される（ＨＬＳの３つの重要なタスク。例えば、Ｐｈｉｌｉｐｐｅ Ｃｏｕｓｓｙ， Ｄａｎｉｅｌ Ｄ． Ｇａｊｓｋｉ， Ｍｉｃｈａｅｌ Ｍｅｒｅｄｉｔｈ， Ａｎｄｒｅｓ Ｔａｋａｃｈ， “Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ，” ＩＥＥＥ Ｄｅｓｉｇｎ ＆ Ｔｅｓｔ ｏｆ Ｃｏｍｐｕｔｅｒｓ ２６（４）： ８－１７ （２００９） Ｊｏａｏ Ｍ． Ｐ． Ｃａｒｄｏｓｏ， Ｍａｒｋｕｓ Ｗｅｉｎｈａｒｄｔ， “Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ，” Ｃｈａｐｔｅｒ ２， ＦＰＧＡｓ ｆｏｒ Ｓｏｆｔｗａｒｅ Ｐｒｏｇｒａｍｍｅｒｓ ２０１６， Ｄｉｒｋ Ｋｏｃｈ， Ｆｒａｎｋ Ｈａｎｎｉｇ， Ｄａｎｉｅｌ Ｚｉｅｎｅｒ （ｅｄｓ．）， Ｓｐｒｉｎｇｅｒ ２０１６， ｐｐ． ２３－４７を参照）。この手法は、ソース間コンパイラでも使用される（木表現を使用するものもあれば、グラフ表現を使用するものもある）。これらのコンパイラでは、変換後のグラフは次に、最終コード（例えば、Ｃ間コンパイラにおけるＣコード）を生成する機能を果たすコード生成段階に入力される。

ＨＬＳツールは、効率的な実装形態を生成するために、追加のディレクティブまたは構成を必要とすることがある。ＨＬＳツールなどの従来技術の解決策は、きわめて複雑なコード再構築においては不満足なパフォーマンスを示す。実際、関連する高度な複雑さは、より効率的なハードウェアを生成するのに必要な程度の再構築を自動的に提供する既存のコード再構築ツールが存在しない実際の理由であり、ユーザが最適化を特定し、それらの一連の最適化を適用することが一般的である（例えば、Ｊｏａｏ Ｍ． Ｐ． Ｃａｒｄｏｓｏ， Ｊｏａｏ Ｔｅｉｘｅｉｒａ， Ｊｏｓｅ Ｃ． Ａｌｖｅｓ， Ｒｉｃａｒｄｏ Ｎｏｂｒｅ， Ｐｅｄｒｏ Ｃ．Ｄｉｎｉｚ， Ｊｏｓｅ Ｇａｂｒｉｅｌ Ｆ． Ｃｏｕｔｉｎｈｏ， Ｗａｙｎｅ Ｌｕｋ， “Ｓｐｅｃｉｆｙｉｎｇ Ｃｏｍｐｉｌｅｒ Ｓｔｒａｔｅｇｉｅｓ ｆｏｒ ＦＰＧＡ－ｂａｓｅｄ Ｓｙｓｔｅｍｓ，” ＦＣＣＭ ２０１２： １９２－１９９を参照）。

例えば、コンパイラ最適化の選択に基づいてコンパイラ最適化を適用するための順序は、それぞれ、フェーズ選択およびフェーズ順序と呼ばれ、従来のコンパイラ最適化の文脈（および、コード再構築に関してではない）においてであっても、設計空間探索（ＤＳＥ）方式を必要とし、他のより効率的な解決策が存在しないために機械学習技術の対象とされている（例えば、Ａｍｉｒ Ｈ． Ａｓｈｏｕｒｉ， Ｗｉｌｌｉａｍ Ｋｉｌｌｉａｎ， Ｊｏｈｎ Ｃａｖａｚｏｓ， Ｇｉａｎｌｕｃａ Ｐａｌｅｒｍｏ， Ｃｒｉｓｔｉｎａ Ｓｉｌｖａｎｏ， “Ａ Ｓｕｒｖｅｙ ｏｎ Ｃｏｍｐｉｌｅｒ Ａｕｔｏｔｕｎｉｎｇ ｕｓｉｎｇ Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ，” ＡＣＭ Ｃｏｍｐｕｔ． Ｓｕｒｖ． ５１（５）： ９６：１－９６：４２ （２０１９） ａｎｄ Ｚｈｅｎｇ Ｗａｎｇ， Ｍｉｃｈａｅｌ Ｆ． Ｐ． Ｏ’Ｂｏｙｌｅ， “Ｍａｃｈｉｎｅ Ｌｅａｒｎｉｎｇ ｉｎ Ｃｏｍｐｉｌｅｒ Ｏｐｔｉｍｉｚａｔｉｏｎ，” Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＩＥＥＥ １０６（１１）： １８７９－１９０１ （２０１８）．を参照）。この問題は、より深いコード再構築、および／または、ループと特定のパラメータ（例えばデータ依存関係および反復回数）とを必要とする再構築技術を考慮すると、さらに複雑である。

一部の従来技術の解決策は、この複雑なフェーズ選択およびフェーズ順序問題を、入力プログラムの構造とそれをグラフ（例えばＣＤＦＧ）で効率的に表すことから始めることによって解決することができる。しかし、これらの従来技術の解決策は、コンパイラにおける、特定のコード再構築を実現するための順序において必要となり得る特定の最適化の存在にきわめて大きく依存し、特定の最適化が存在しないことは、ツールがより高パフォーマンスのハードウェアを生成することを妨げ得る。

国際特許出願第ＷＯ２０１８／０７８４５１（Ｒｅｃｏｎｆｉｇｕｒｅ ｉｏ ｌｔｄ）は、複数のＦＰＧＡに対する並行非同期プログラムを特に加速する装置を教示しているが、この従来技術の装置は単一のＦＰＧＡに対するカーネルを加速しない。この装置は、特定の入力モデルであるＣＳＰを使用する。

Ａ．Ｌｏｔｆｉ ａｎｄ Ｒ． Ｋ． Ｇｕｐｔａ， “ＲｅＨＬＳ： Ｒｅｓｏｕｒｃｅ－Ａｗａｒｅ Ｐｒｏｇｒａｍ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｗｏｒｋｆｌｏｗ ｆｏｒ Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ，” ＤＯＩ １０．１１０９／ＩＣＣＤ．２０１７．９２は、ＨＬＳツールを使用したハードウェアの生成の結果として得られるハードウェア資源の削減の文脈でコード変換の使用を開示している。この文献は、オープン・ソースＬＬＶＭ中間表現ＩＲを使用した入力コードの表現の基本ブロックのために構築されたＤＦＧの使用を教示している。Ｌｏｔｆｉらで開示されている手法は、共有可能なハードウェア資源を特定し、それによってＦＧＰＡのために必要な設計面積を削減するために、ＤＦＧにおいて共通のパターンを検索する。ＨＬＳツールに入力される生成されたコードは、資源共有のために選択されたパターンを考慮し、ＨＬＳツールをガイドするためにＨＬＳディレクティブを使用する。

Ｌｏｔｆｉらに記載されている手法は、可能なハードウェア資源削減のために発明者らの発明で使用されるＤＦＧに適用可能な最適化の種類の一例である。このような最適化は、同じハードウェア資源、または、類似点に基づくデータ経路のマージのサポートを使用するハードウェア資源を使用した部分グラフの選択の実装を可能にする（例えば、Ｎ． Ｍｏｒｅａｎｏ， Ｅ． Ｂｏｒｉｎ， Ｃｉｄ ｄｅ Ｓｏｕｚａ ａｎｄ Ｇ． Ａｒａｕｊｏ， “Ｅｆｆｉｃｉｅｎｔ ｄａｔａ ｐａｔｈ ｍｅｒｇｉｎｇ ｆｏｒ ｐａｒｔｉａｌｌｙ ｒｅｃｏｎｆｉｇｕｒａｂｌｅ ａｒｃｈｉｔｅｃｔｕｒｅｓ，” ｉｎ ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ－Ａｉｄｅｄ Ｄｅｓｉｇｎ ｏｆ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ， ｖｏｌ． ２４， ｎｏ． ７， ｐｐ． ９６９－９８０， Ｊｕｌｙ ２００５． ｄｏｉ： １０．１１０９／ＴＣＡＤ．２００５．８５０８４４を参照）。

しかし、Ｌｏｔｆｉらは、メモリ転送を削減するための最適化方式について記載していない。Ｌｏｔｆｉらは、インストルメンテーション・コードも付加しない。

Ｏ． Ｒｅｉｃｈｅ， ｅｔ ａｌ， “Ｇｅｎｅｒａｔｉｎｇ ＦＰＧＡ－ｂａｓｅｄ ｉｍａｇｅ ｐｒｏｃｅｓｓｉｎｇ ａｃｃｅｌｅｒａｔｏｒｓ ｗｉｔｈ Ｈｉｐａｃｃ” ｄｏｉ： １０．１１０９／ＩＣＣＡＤ．２０１７．８２０３８９４は、画像処理のためのドメイン固有言語およびコンパイラである、Ｈｉｐａｃｃの使用を開示している。この文献は、ＤＳＬ（ドメイン固有言語）のプログラムが入力として使用され、次にそのＤＳＬコードがプログラミング言語に変換される手法の一例を開示している。変換されたコードは、コンパイラおよび／またはＨＬＳツールへの入力である。Ｒｅｉｃｈｅらの例では、Ｈｉｐａｃｃ ＤＳＬのプログラムを、ＣコードＣ／Ｃ＋＋およびＯｐｅｎＣＬコードに変換する例が開示されている。この変換プロセスでは、典型的なコンパイラ最適化（抽象構文木（ＡＳＴ）レベルで適用される）が、対象（例えばＦＰＧＡまたはＧＰＵ）に従って行われる。Ｒｅｉｃｈｅらは、Ｈｉｐａｃｃ ＤＳＬコードのインストルメンテーションによって、または内部ＡＳＴおよびデータ依存関係からＤＦＧを生成することによって生成可能なデータフロー・グラフのアンフォールドとフォールドについては記載していない。

Ｊ．Ｐ． Ｐｉｎｉｌｌａ ａｎｄ Ｓ． Ｊ． Ｅ． Ｗｉｌｔｏｎ， “Ｅｎｈａｎｃｅｄ ｓｏｕｒｃｅ－ｌｅｖｅｌ ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ ｆｏｒ ＦＰＧＡ ｉｎ－ｓｙｓｔｅｍ ｄｅｂｕｇ ｏｆ Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ ｄｅｓｉｇｎｓ，” ｄｏｉ：１０．１１０９／ＦＰＴ．２０１６．７９２９５１４は、ＨＬＳツールによって生成されたハードウェアの挙動を監視／検証するために、コードをインストルメンテーションする方法を教示している。この概念は、プログラムの挙動を監視するために、プログラムの入力コードにインストルメンテーション・コードを差し込むものである。差し込まれたインストルメンテーション・コードはＨＬＳツールに入力され、生成されるハードウェアは、入力された元のプログラムの挙動を実装するためのハードウェアと、プログラムの挙動を監視するための回路の両方を含む。言い換えると、Ｐｉｎｉｌｌａらのインストルメンテーション・コードは、生成されたハードウェアの挙動を実行時またはシミュレーション時に把握および／または検証するための監視点を提供する。類似の手法の別の例は、Ｊｏｓｈｕａ Ｓ．Ｍｏｎｓｏｎ ａｎｄ Ｂｒａｄ Ｌ． Ｈｕｔｃｈｉｎｇｓ． ２０１５． Ｕｓｉｎｇ Ｓｏｕｒｃｅ－Ｌｅｖｅｌ Ｔｒａｎｓｆｏｒｍａｔｉｏｎｓ ｔｏ Ｉｍｐｒｏｖｅ Ｈｉｇｈ－Ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ Ｄｅｂｕｇ ａｎｄ Ｖａｌｉｄａｔｉｏｎ ｏｎ ＦＰＧＡｓ． Ｉｎ Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ２０１５ ＡＣＭ／ＳＩＧＤＡ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ （ＦＰＧＡ ‘１５）． ＡＣＭ， Ｎｅｗ Ｙｏｒｋ， ＮＹ， ＵＳＡ， ５－８． ＤＯＩ： ｈｔｔｐｓ：／／ｄｏｉ．ｏｒｇ／１０．１１４５／２６８４７４６．２６８９０８７に示されているものである。

Ｙ．Ｕｇｕｅｎ， Ｆ．ｄｅ Ｄｉｎｅｃｈｉｎ ａｎｄ Ｓ． Ｄｅｒｒｉｅｎ， “Ｂｒｉｄｇｉｎｇ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ａｎｄ ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ａｒｉｔｈｍｅｔｉｃ： Ｔｈｅ ｃａｓｅ ｓｔｕｄｙ ｏｆ ｆｌｏａｔｉｎｇ－ｐｏｉｎｔ ｓｕｍｍａｔｉｏｎｓ，” ２０１７ ２７ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ （ＦＰＬ）， Ｇｈｅｎｔ， ２０１７， ｐｐ． １－８．ｄｏｉ： １０．２３９１９／ＦＰＬ．２０１７．８０５６７９２における研究は、浮動小数点データ・タイプと固定小数点データ・タイプとを使用した演算式を最適化するソース間コンパイラ手法、および特に総和リダクション・パターンを扱うことを提示している。この手法は、ＨＬＳツールのためのＣ／Ｃ＋＋コードを生成する。記載されているＵｇｕｅｎらの手法は、ＨＬＳツールに対するコードの生成をさらに強化するために組み込むことができる多くの可能な最適化のうちのもう１つの最適化である。Ｕｇｕｅｎらの最適化は、固定小数点データと浮動小数点データとを含む総和リダクション演算の存在に対して行われる。

Ｓ．Ｃｈｅｎｇ ａｎｄ Ｊ．Ｗａｗｒｚｙｎｅｋ，“Ａｒｃｈｉｔｅｃｔｕｒａｌ ｓｙｎｔｈｅｓｉｓ ｏｆ ｃｏｍｐｕｔａｔｉｏｎａｌ ｐｉｐｅｌｉｎｅｓ ｗｉｔｈ ｄｅｃｏｕｐｌｅｄ ｍｅｍｏｒｙ ａｃｃｅｓｓ，”２０１４ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｔｅｃｈｎｏｌｏｇｙ （ＦＰＴ）， Ｓｈａｎｇｈａｉ， ２０１４， ｐｐ． ８３－９０． ｄｏｉ： １０．１１０９／ＦＰＴ．２０１４．７０８２７５８における研究は、計算からのメモリ操作およびデータ・アクセスの分離を利用するパイプライン化実装形態を実現するために入力コードを再構築する手法を提示している。演算の種類に従って制御データ・フロー・グラフ（ＣＤＦＧ）の一部が部分グラフとしてクラスタ化され、次に、Ｃｈｅｎｇらは、部分グラフのそれぞれについてハードウェア・ユニットの分離実行を考慮したコードを生成することを教示している。再構築されたコードはＨＬＳツールに入力される。これは、ＨＬＳツールに対するコードの生成を向上させる多くの可能な最適化のうちのさらなる他の１つであり、この場合、（例えばメモリ・アクセスと計算との間の）挙動の分離と、その結果としてのより詳細度の粗いパイプライン方式の使用の増強とを考慮している。

本明細書は、ハードウェア・アクセラレータの最適化構成を生成する方法を提示する。この方法は、インストルメンテーション・コードが事前に付加されたアプリケーションの重要機能を実行することによって現在得られる（算術、論理、演算子レベル）の計算のデータフロー・グラフ（ＤＦＧ）表現に基づく。

本明細書は、入力プログラム・コードの構造に自動的に適用されると提供することができるコード再構築の方法を開示し、適用されるコンパイラ最適化（ならびに、そのパラメータおよびターゲット・コード要素の特定の値）の特定とそれらを適用する順序（また、通常はそれらの一部を複数回適用する）とを必要とすることになる。

インストルメンテーション・コードを自動的に差し込むことによって、本明細書で概説する方法は、異なる入力プログラミング言語を有し得る。一例として、Ｃコードが実施形態における入力として考慮された。しかし、本発明はＣには限定されない。

この方法は、フォールドおよびアンフォールド・グラフ操作と、グラフ自体の構造の変換とを使用した。この方法は、重要なアプリケーション・カーネルのコードを完全に再構築することができるフレームワークで実装された。このフレームワークは、フロントエンドとバックエンドの２段階からなる。フロントエンドは、元のバージョンにインストルメンテーション・コードを差し込むことによって実行トレースからＤＦＧを生成する。フレームワークのバックエンドは、ＤＦＧを自動的に再構築することができ、ＨＬＳにとって使いやすい方法でディレクティブが付加されたＣコードを生成する。

Ｘｉｌｉｎｘ ＦＰＧＡを対象とし、標準ソリューションのＶｉｖａｄｏ ＨＬＳを基準にしてベンチマーク評価する一実施形態を提示し、この方法により得られる関連の高速化を例示する。元のＣコードと比較すると、この方法によって生成されたＣコードは、元の未修正のＣコードよりパフォーマンスに優れており、大幅な高速化が達成される。実現されたＣコードは、手動で最適化された、ディレクティブが付加されたＣコードに匹敵し、ほとんどの場合はより優れている。元の未修正Ｃコードと比較すると、この手法は３０倍から１００倍高速の実装形態を実現する。Ｖｉｖａｄｏ ＨＬＳディレクティブを使用して最適化されたＣと比較すると、この手法は２倍から１５倍高速な実装形態を実現する。しかし、このフレームワークにより生成されたディレクティブを有するＣコードは、専門家によって適用された手動によるコード変換によって常に再現可能である。したがって、この手法は、ソフトウェア開発者が、Ｖｉｖａｄｏ ＨＬＳなどのＨＬＳの専門家の支援を必要とせずに、Ｃコードを入力として使用し、典型的なＨＬＳツールをバックエンドとして使用して、効率的なハードウェア・アクセラレータを対象とすることを可能にし得る。

本発明の方法および装置のコンパイルの流れを示す図である。

ドット積カーネルの場合のフロントエンドの出力を示す図である。

バックエンドを表す図を示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮したフィルタ・サブバンド・ベンチマークの場合のフロントエンドで生成されたＤＦＧを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した最初のステップ後のフィルタ・サブバンド・ベンチマークを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した２番目のステップ後のフィルタ・サブバンド・ベンチマーク共通演算部分グラフを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した２番目のステップ後の最初の出力のためのフィルタ・サブバンド・ベンチマーク固有演算部分グラフを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した２番目のステップ後の２番目の出力のためのフィルタ・サブバンド・ベンチマーク固有演算部分グラフを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した２番目のステップ後の３番目の出力のためのフィルタ・サブバンド・ベンチマーク固有演算部分グラフを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した４番目のステップ後のフィルタ・サブバンド・ベンチマーク非ループ・データフローを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した４番目のステップ後のフィルタ・サブバンド・ベンチマーク外側ループ・データフローを示す図である。

それぞれ４、３、１０２４および２に等しいＮｚ、Ｎｓ、ＮｍおよびＮｙを考慮した４番目のステップ後のフィルタ・サブバンド・ベンチマーク内側ループ・データフローを示す図である。

それぞれ５１２、３２、１０２４、６４および４に等しいＮｚ、Ｎｓ、Ｎｍ、Ｎｙおよびアンロール・ファクタを考慮した５番目のステップ後の演算的に最適化されたフィルタ・サブバンド・ベンチマーク内側ループ・データフローを示す図である。

それぞれ５１２、３２、１０２４、６４および４に等しいＮｚ、Ｎｓ、Ｎｍ、Ｎｙおよびアンロール・ファクタを考慮した６番目のステップ後のアンロールされたフィルタ・サブバンド・ベンチマーク内側ループ・データフローを示す図である。

フィルタ・サブバンド・ベンチマークの場合の高速化を示す図である。

ＨＬＳツールを対象とするＣコードを自動的に再構築する方法および装置１０を開示し、図１の概略図に示す。このコードは、ハードウェア・アクセラレータ２０の構成のために製造ユニットへの入力として使用可能である。ハードウェア・アクセラレータ２０は、プログラム可能な、ロジック・ゲートなどの複数の電子構成要素を含む。この装置は、プログラムの実行トレースをデータフロー・グラフ（ＤＦＧ）として生成することができるフロントエンド１１０を含む。ＤＦＧは次に、ハードウェア・アクセラレータ２０に渡すための出力プログラムを生成するために、バックエンド１３５で処理される。出力プログラムは、この非限定的な例では、ＨＬＳツールのためのＣのソフトウェア・コードを使用したソフトウェア・コードを含む。

ＤＦＧは、アプリケーションにおけるデータフローの優れた表現であり、アプリケーションにおける並列性などの特性を表すことがわかっている。これらの特性の特定は、ハードウェアの改良された実装形態を可能にする。フロントエンド１１０は、複数の異なる入力言語からのＤＦＧの生成を可能にする。このようにして、異なる言語のソフトウェア・プログラマがＣベースのＨＬＳツールを使用することを可能にする。本明細書では、バックエンド１３５と、バックエンド１３５がＤＦＧを操作し、分析して出力プログラムを自動的に生成する方法とについて説明する。フロントエンド１１０が生成するＤＦＧの種類と、それらを入力アプリケーション・ソース・コードから構築する手法についても説明する。

図１に、コード再構築を適用するための本開示の方法のコンパイルの流れを示す。第１のステップ１００で、フロントエンド１１０にＣコード１０５が入力される。フロントエンド１１０は、ステップ１１５でＣコード１０５を実行し、ステップ１２０で、Ｃコード１０５におけるアルゴリズムの実行トレースのＤＦＧ１２５を生成する。ＤＦＧ１２５は、ステップ１１５における元の実行からのすべての演算を含み、あらゆるデータ依存関係が強制的に維持される。グラフは、アルゴリズムの依存関係を記録するのみであり、Ｃコード１０５のアルゴリズムの実際の実行順序は記録しないことはわかるであろう。したがって、互いに並列に実行可能な演算は、ＤＦＧ１２５のグラフでは相互依存関係なしに現れる。したがって、データ依存関係は別個に記録する必要がある。

フロントエンド１１０は、多くの異なる入力に適合することが可能なため汎用的であり、Ｃコード入力のための実装形態に限定されず、他のソフトウェア言語にも容易に移植することができる。

バックエンド１３０への入力ＤＦＧ１２５について、ドット・グラフ記述言語において説明する。ドット・グラフ記述言語はＩＤと一連の属性とによって記述されるノードを有することが知られている。ノードの１つ１つがすべて少なくとも２つの属性を有する。属性のうちの第１の属性はラベルであり、属性の他方は種別である。ノードは３つの種別を有することができ、それらは定数と、変数と演算である。ラベルは、ノードの種別に応じて、変数の名前、定数の値、または演算の種類を格納する。変数が配列の場合、ノードはその配列へのアクセスのインデックスも含む。さらに、変数ノードは、変数の種類と、変数ノードがローカル変数であるか関数の入力であるかも属性として保持する。

本開示の最初の態様では、フロントエンド１１０は基本演算を使用するソフトウェア・コードのカーネルのみを扱う。変数の割り当ては、異なるノード間（例えば、定数型ノードから変数型ノードへの）の接続で表される。演算は、ノード種別演算によって表され、オペランドと結果とはそれぞれのノードによって表され、それに応じて接続される。本開示のこの態様では、ソフトウェア・コードにおけるカーネルの実行を表すＤＦＧ１２５は、ドット記述を実行時にファイルに書き出すものである。

インストルメンテーション・コード１１２（すなわち、実行されると、ＤＦＧの記述の部分を出力するコード）を元のＣコード１０５に差し込み、修正されたＣコードをコンパイルし、実行することによって、入力ＤＦＧが生成される。基本インストルメンテーション規則は、元のＣコード内の各命令文の前にインストルメンテーション・コードを付加することである。付加されたインストルメンテーション・コードは、ＤＦＧノードと、付随するＣ命令文の演算およびオペランドを表すエッジとを記述する。例えば、演算のない代入文の場合、付加されるインストルメンテーション・コード１１２は２つのノード、すなわち入力ノードと出力ノードを接続エッジともに備えるＤＦＧ部分を出力する。

ＤＦＧ１２４におけるノードの値は、現在の演算を記述する。一例を挙げてみる。Ｃコード１０５が、ａ＝ｂ＋ｃ、すなわち変数ａが変数ｂとｃにおける値の和の値をとるなどの命令文を含むとする。このインストルメンテーション・コードの実行は、変数ｃとｂとａのノードのそれぞれについてドット記述を生成し、これらのノードの属性として変数名（例えば、ａ、ｂまたはｃ）と、種類（例えば整数）と、左オペランドまたは右オペランドの項におけるそれぞれの識別情報とを含む。

別の例として、ノードがメモリ・アクセスをあら合わす場合があり得る。付加されるインストルメンテーション・コードはノードを変数として記述し、ラベルは明示的なメモリ・インデックスによるメモリにおけるアクセスである。

正しい依存関係を考慮する必要がある。図１のＣコード１０５によって表されるソフトウェア・コードの実行時に、変数は複数の値を有し得る。変数がとるすべての新しい値について、ＤＦＧ１２５におけるグラフに新たなノードが作成される。この方法および装置は、古くなった値ではなく、複数の値を有する変数の最新の値に対応するノードのＩＤを知ることができる必要もある。この依存関係を保証するために、インストルメンテーション・コード１１２は、最新の割り当てを反映するように変数名のリネームを使用する。例えば、インストルメンテーション・コード１１２は、変数名に割り当てを表す数字を付加する。そこで、コードが以下のシーケンスから開始する場合を想定する。
ａ＝ｂ；ｄ＝ａ＋ｃ；ａ＝ｄ＋ａ；
この方法および装置は、第１の演算にａ＿１、ｂ＿０というＩＤを使用する。この後に、第２の演算のｄ＿１、ａ＿１、ｃ＿０というＩＤと、最後の演算のａ＿２、ｄ＿１、ａ＿１というＩＤが続く。図２に、インストルメンテーション・コード１１２が付加されたドット積カーネルの実行の結果のＤＦＧ１２５を示す。

ＤＦＧ１２５は、追加のステップを回避するためと、大きなトレースとその後のＤＦＧコンパクト化とを出力する必要のない可能な将来のコンパクトなＤＦＧ表現を踏まえて、実行トレースを生成して次にトレースからＤＦＧ１２５を構築する代わりに、アプリケーションの実行から作成される。

次に、バックエンド１３５の構造とその実装形態について説明する。バックエンド１３５は、フロントエンド１１０によって生成されたＤＦＧ１２５の分析と最適化とを扱う、図３に記載された様々なステップを含む。適用される厳密な最適化は、グラフと構成１３０とに応じて異なる。

この方法および装置が適切な数のロード／ストア命令文を有する出力プログラムにおけるコードを明示的に生成するように、ハードウェア・アクセラレータ２０によって（例えば、利用可能なメモリ・ポートの数を使用して）サポートされる同時ロード／ストアの数をユーザが定義することができる。カーネルの入力および出力と、最適化オプションのうちの一部も設定される。最適化オプションは、配列分割またはループ・パイプライン化を含むが、これらには限定されない。バックエンド１３５はすべてのコード再構築、最適化を実装し、ＨＬＳツールのためのディレクティブを差し込むため、バックエンド１３５はこの方法および装置の最も重く、最も複雑な部分である。

バックエンド１３５は、図３に示すように別々の７ステップに分けられる。この方法は、ＤＦＧ１２５におけるグラフを刈り込むことから開始し、アプリケーション内およびＤＦＧ１２５に記録されている反復パターンを特定してグラフをコンパクトにする。その後、この方法は、データフローの改良された表現を得るために、そのコンパクトな記述を最適化する。グラフにおいて反復パターンをフォールドすることができる。反復パターンは複数回発生し得るため、これらの反復シーケンスを改善することによってアプリケーションの大部分を最適化することが可能である。

図３に示す最初の３つのステップ（すなわち、グラフ初期化ステップ３００と、出力分析ステップ３１０と、並列マッチング・ステップ３２０）は、グラフ処理と、反復パターンの特定とを扱う。その後の３つのステップ（ステップ３３０、３４０および３５０）は、データフローを最適化し、最後のステップ（ステップ３６０）はＨＬＳディレクティブが付加されたＣコードを生成する。

グラフ初期化の最初のステップ３００は、次の最適化の前に入力グラフを初期設定し、前処理し、分析するいくつかのステップのために設けられている。この最初のステップ３００は、ＤＦＧ１２５における不要なノードの刈り込みを含む。このステップ３００は、さらなるアルゴリズムの効率を向上させることができる。最初のステップ３００は、（ローカル配列をスカラー変数にすることができる場合は常に）入力コードからローカル配列も除去し、それによって、ＦＰＧＡにおいてＢＲＡＭ（Ｘｉｌｉｎｘ ＦＰＧＡにおいてブロックＲＡＭと呼ばれるオンチップＲＡＭ）を使用することを回避するためにそれらのローカル変数を複数の固有変数で実装する。

２番目のステップ３１０は、出力を分析し、次のステップ３２０のためにグラフを準備する。一態様では、初期グラフはきわめて大きい可能性があり、多くの方法でコンパクトにすることができる。この方法および装置は、異なる出力を生成するシーケンス間のパターンの存在を判断することによってグラフをコンパクト化する。カーネルが単一の出力を有する場合は、このステップ３１０と次のステップ３２０はスキップされる。

出力が配列である場合、この方法および装置はステップ３１０で、配列内の出力値のすべての１つ１つの出力値の個別データフローを特定する。次のステップ３２０に進む前に、この方法および装置は、出力上の共通の演算を、出力の１つ１つに固有の演算から分ける。したがって、複数の出力の場合、この方法および装置は、共通の演算のすべてを有するグラフを生成し、次に、それらの出力のそれぞれを生成する固有の演算を有するグラフのリストを生成する。３番目のステップ３２０は、前のステップ３１０で特定された別々のデータフローを比較する。このステップ３２０の目標は、これらの別々のデータフローのすべてを、単一のシーケンスによって表すことができるループとしてコンパクト化することである。このコンパクト化が成功した場合、グラフのサイズは大幅に縮小される。この単一のシーケンスは複数回反復されることになるため、グラフが最適化される場合、アプリケーション実行の大部分も最適化される。最適化されない場合、シーケンスが類似しているにもかかわらず、すべてのシーケンスを別々に最適化する必要が生じることになる。また、ループがなければ、結果のＣコードは過剰にアンフォールドされる可能性があり、その結果として（資源共有方式を考慮しても）実現不可能な実装形態となる可能性がある。このステップ３２０が成功した場合、この方法および装置は、ループを記述するグラフとなる共通の演算のグラフを有する。この階層的表現により、より複雑なコード構造の表現が可能になる。

図４を参照して、Ｎｙ、ＮｚおよびＮｓがそれぞれ２、４および３の場合のフィルタ・サブバンド・ベンチマーク（リスト１参照）のためのフロントエンドからの結果のＤＦＧを示す。リスト１のソース・コードと比較すると、ｙ値の計算とｓ配列の異なる結果とがわかる。第１のステップ３１０（不要ノードの刈り込み）を行った後の結果が図５に示されている。この新たなＤＦＧでは、変数情報はエッジに格納され、それによってよりコンパクトなグラフとなる。

リスト１ フィルタ・サブバンド・ソース・コード

図６、図７、図８および図９を参照して、前記で図５に示したＤＦＧの２番目のステップ３１０の分離の結果を示す。図７、図８および図９は、３つの出力のそれぞれについて固有である元のデータフローのセグメントを示す。図６は共通の演算を示す。元のデータフローと比較すると、これらのセグメントをすべて認めることができる。すべての出力についてｙ値が与えられ、したがってｙ値がすべての出力に共通であるため、この分離は、元のＤＦＧおよびリスト１のソース・コードと整合する。一方、これらのｙ値をｓ配列に適用したものは、出力のそれぞれに固有である。２番目のステップ３１０を、Ｎｙ、ＮｚおよびＮｓがそれぞれ６４、５１２および３２であるフィルタ・サブバンド・ベンチマークに適用すると、リスト１のコードになる。

２番目のステップ３１０の共通ノードと固有ノードとの分離は、３番目のステップ３２０の成功のために必要である。これらのデータフローが共通の演算を含む場合、データフローはプログラムにおいて１回実行されればよく、出力ごとに複数回実行される必要はないが、データフローは３番目のステップ３２０で通常通りにマッチングされることとなり、ループに含められることになる。例えば、リスト１に示すフィルタ・サブバンド・ベンチマークは、２つのネストされたループ・セットを含む。最初のループは、出力を計算するために２番目のループで値が使用されるｙベクトルを計算する。３番目のステップ３２０（並列マッチング）で、この方法および装置は固有出力シーケンスをマッチングし、その内側ループがアンロールされた２番目のループと類似したループを特定する。２番目のステップ３１０における共通ノードと固有ノードの分離がなければ、この方法および装置はｙ値の計算のマッチングも行うことになり、この方法はそれらの値を出力の１つ１つについて再度計算するループを生成することになる。そのような実装形態は、生成されたコードに基づく元の実装形態よりもはるかに劣ることになり、そのためこの分離はこの方法の一部として組み込まれている。

３番目のステップ３２０のマッチングを上記の例に適用すると、３つの別々のＤＦＧのマッチングに成功し（図７、図８および図９）、したがって３つのセグメントすべてを１つのループで実装することができ、ループの最初の反復回である図７によって示される。リスト３に、３番目のステップ３２０のマッチングを適用した結果のコードも示す。

リスト３ この方法の３番目のステップ３２０の後の、Ｎｚ、Ｎｓ、ＮｍおよびＮｙがそれぞれ５１２、３２、１０２４および６４に等しい実行を考慮したフィルタ・サブバンド

４番目のステップ（順次マッチング）の目的は、パイプライン化を実装することである。３番目のステップ３２０では、出力の並列化を扱っている。しかし、その後でも多くの最適化の見込みのある大きなグラフが依然として存在している。４番目のステップ３３０では、この方法および装置は、特定の基準を満たす潜在的な変数を特定し、この変数に沿ってグラフをパイプライン化する。一態様では、この方法は、より頻繁に書かれている変数のうちの１つを選択する。これは、最長のパイプラインの構築を試みる発見的方法である。次に、この方法および装置は、選択された変数のそれぞれの新たな値を生成するシーケンスをマッチングして、パイプライン化可能なループを特定する。マッピング・アルゴリズム・パイプラインは、前のステップで作成された、図６および図７に示すグラフ階層構造をたどる。パイプラインが前のループを中断させる場合、この方法および装置はこの４番目のステップ３３０ではループを優先する。４番目のステップ３３０は、結果のパイプラインを実装するようにグラフを再構築する。この４番目のステップ３３０は、グラフをさらにコンパクトにするとともにグラフの構造を改良するという利点を有する。

このステップの効果の一例は、フィルタ・サブバンド・ベンチマークへの適用である。リスト１における元のコードを分析すると、ｙ値が計算されるたびに、そのｙ値をただちに使用することができる一方で、他のｙ値が計算されることが明らかである。この関係は元のコードでは明示的ではなく、したがってＨＬＳツールはこの並列化の可能性を認識するのが困難である可能性がある。しかし、ＤＦＧ表現により、この並列化が特定しやすくなる。このベンチマークのグラフが４番目のステップ３３０に達すると、この方法および装置はベクトルｓに沿ってパイプライン化することを選択し、その結果、リスト２のコードとなる。

リスト２のアルゴリズムのこの修正された記述は、並列化を明確に顕在化して、この並列化を利用することができるパイプラインを実装する。

リスト２ この方法の４番目のステップ３３０後の、Ｎｚ、Ｎｓ、ＮｍおよびＮｙがそれぞれ５１２、３２、１０２４および６４に等しい実行を考慮したフィルタ・サブバンド

４番目のステップ３３０のパイプライン化をフィルタ・サブバンド・ベンチマークに適用することによって、この方法および装置は図１０、図１１、および図１２に示すＤＦＧを得る。グラフは、配列ｓに沿ってパイプライン化されている。図１１および図１２の部分グラフは、パイプライン化の外側ループと内側ループの単一反復回を表す。各反復回において、外側ループはｙ値を計算し、この値が次に内側ループで使用される。内側ループでは、各ｙがｓ配列のすべての出力を計算するために使用される。図１０の部分グラフは、パイプライン化をマッチングしなかったデータフローを示す。この場合、データフローはｓ配列の初期設定であった。

５番目のステップ３４０は、データフロー最適化を適用するためのステップである。一態様では、５番目のステップ３４０はメモリ・アクセスを最適化する。５番目のステップ３４０における最適化の非限定的一例は、メモリ再利用である。この方法および装置は、冗長なメモリ・アクセスがあるかを特定するために現在のループを分析する。この冗長性がパターンに従っている場合、この方法および装置はバッファを使用して、反復回間の値を格納し、それによってメモリ読み出しの回数を削減する。これにより、特定のアプリケーションのメモリ・ボトルネックを大幅に抑制することができる。このメモリ最適化は、３番目のステップ３２０と４番目のステップ３３０のループに適用することができる。３番目のステップ３２０におけるループが基準に合う場合、アクセスを最適化することによってデータフローが変化し、４番目のステップ３３０におけるパイプラインが実装されなくなるため、４番目のステップ３３０はスキップされ、この最適化が適用される。

選択可能な別の最適化は、メモリ・ボトルネックを軽減するための配列の完全分割である。前述の最適化は、値をバッファに格納することによってデータ再利用によりメモリ・アクセスを削減する。メモリ・ボトルネックを低減するもう１つの方法は、ＨＬＳツールによって提供される配列分割ディレクティブによるものである。この場合、この方法および装置は、ＤＦＧ全体を通して最終パスを行う。メモリへの別々の同時アクセスの数に基づいて、この方法および装置は、検出された同時メモリ・アクセスの最大数を単一のサイクルでスケジュールすることができるように、適切な配列分割ファクタを設定することができる。この最適化により資源使用を大幅に向上させることができる。これは、演算のより多くを並列に実行することができるように、第１に、ＢＲＡＭのうちのより多くのＢＲＡＭを使用することにより、第２にメモリ・ボトルネックを低減することによる。この最適化は、グラフの構造を変更せず、単に異なるディレクティブとするのみである。フィルタ・サブバンド関数に適用すると、この最適化はリスト４に含まれる配列分割ディレクティブを差し込む。

リスト４ この方法の５番目のステップ３４０と６番目のステップ３５０を完全に通過した後の、Ｎｚ、Ｎｓ、ＮｍおよびＮｙがそれぞれ５１２、３２、１０２４および６４に等しい実行を考慮したフィルタ・サブバンド

最適化の１つのタイプは、演算最適化に焦点を合わせる。このタイプの最適化の１つは、累積を部分和のシーケンスとして再構築する累積最適化である。バックエンドは、まず、累積チェーンを検出する。次に、バックエンドはそのチェーンを削除し、代わりに平衡木（より多くのＩＬＰを提供する）構造によって同じ計算を実装する。図１３に、図１４のチェーンと比較して平衡累積を示す。４つのシーケンス化された加算の代わりに、新たなデータフローは２つの並列加算の後にもう１つの加算が続く木からなる。平衡木の結果は次に、前の反復回からのｓ値と合計される。この方法および装置がリスト４のコードに見られる部分和を得るのは、このアンフォールドによるものである。

６番目のステップ３５０は、より多くのＩＬＰを顕在化させるために、この方法および装置が生成したループをアンフォールドする。このアンフォールドは、ループのデータフローを再現する一方、反復回間の依存関係が確実に維持されるようにすることによって、実装される。ループをアンフォールドすることによって、より多くの最適化が得られ、それによってこの６番目のステップ３５０の後に５番目のステップ３４０を行うことができる。この方法は、構成ファイル１３０で示されている同時ロード／ストアの数に基づいてループをアンフォールドする。６番目のステップ３５０が５番目のステップからＤＦＧを受け取り、アンロールするループがそれ以上なくなると、ＤＦＧは最終ステップに送られる。

図１４に、図１２に示すフィルタ・サブバンド・パイプライン・ループの内側ループのアンフォールドの結果を示す。バックエンドは、データフロー、この場合は加算と乗算を再現し、次に、反復回間の正しい依存関係を維持するようにデータフローを接続し、その結果、累積チェーンが得られる。エッジにおいて、メモリへの更新されたアクセスと、区別のために付加ラベルが付加されたコピーされた変数とが示されている。このアンフォールドされたデータフローは、上記の最適化を適用する５番目のステップ３４０に戻される。この方法がリスト４のコードに見られるアンフォールドされたコードを得るのは、このアンフォールドによる。この場合、外側ループは４倍にアンフォールドされている。

最後のステップ３６０は、ディレクティブを有する出力Ｃコードを書くことによってハードウェア・アクセラレータのためのプログラムを出力するために設けられている。この方法および装置は、生成されたＤＦＧ１２５が表すＣコードを書き出し、構成ファイル１３０で指定されている同時メモリ・アクセスの数に基づくメモリ分割などの必要なディレクティブを付加する。最後に、ステップ３７０で出力プログラムをハードウェア・アクセラレータに提供することができる。

別の実施形態では、この方法および装置は以下によって入力ＤＦＧを得ることもできる。
（ａ）アプリケーションが実行されるときに（ＧｒａｐｈＶｉｚのドットなど）ＤＦＧのテキスト表現を報告するインストルメンテーション・コードを備えたアプリケーションを実行する。
（ｂ）実行された命令を報告するインストルメンテーション・コードを備えるアプリケーションを実行し、次にソフトウェア・ツールが実行トレースからＤＦＧを構築することができる。
（ｃ）実行されたアセンブリ命令、バイトコード命令または中間表現命令を報告または監視する（これは、逆アセンブルおよびメモリ非曖昧化を含むことがある）。
（ｄ）ループを完全にアンロールすることができ、関数をインライン展開することができ、結果のコードのＤＦＧを生成するコンパイラ（入力データに依存する値を扱う場合、コンパイラは典型値、最小、平均および最大期待値に関する情報に依拠し得る）。

本明細書の方法および装置は、多様なコンピューティング・プラットフォームを対象とする場合の実行時間、電力およびエネルギー消費を改善する。ＦＰＧＡのためのＨＬＳツール（および特にＸｉｌｉｎｘ Ｖｉｖａｄｏ ＨＬＳツール）のためのコード再構築およびディレクティブ挿入に焦点を合わせた例を示したが、本発明は以下の文脈でも使用可能である。
（ａ）ディレクティブ出力に関して可能な修正を必要とするＦＰＧＡを対象とする他のＨＬＳツール（ＬｅｇＵｐなど）
（ｂ）ＡＳＩＣを対象とするＨＬＳツール
（ｃ）ＦＰＧＡを対象とするＯｐｅｎＣＬコードのコード生成
（ｄ）マルチコアおよび／またはＧＰＵを対象とするＯｐｅｎＣＬまたはＣＵＤＡのコード生成
（ｅ）場合によりＯｐｅｎＭＰおよびＯｐｅｎＡＣＣなどのディレクティブ駆動型プログラミング・モデルで拡張されたスレッド・ライブラリまたはＣコードを使用してマルチスレッド・コードを生成する、マルチコアＣＰＵおよび複数ＣＰＵを対象とするＣコード生成
（ｆ）ＳＩＭＤアーキテクチャのための適切なＣコード生成、および適切なベクトル化

実験結果
本節では、本明細書の方法および装置によって得られた最初の実験結果を示す。一連のベンチマークを使用した。すべてのベンチマークが、制御フローがきわめて少ない演算量の多いアルゴリズムからなり、ＤＳＰアルゴリズムを代表する。ベンチマークは、テキサス・インスツルメンツのＤＳＰＬＩＢ［３］、ＵＴＤＳＰ Ｂｅｎｃｈｍａｒｋ Ｓｕｉｔｅ［４］、またはＭＰＥＧアプリケーションからのものである。使用した最も単純なベンチマークは、ＤＳＰＬＩＢのドット積である。ＤＳＰＬＩＢの自己相関ベンチマークも使用している。１Ｄ ｆｉｒベンチマークは、Ｎ個のタップを有するＦＩＲ（有限インパルス応答）フィルタを実装する典型的なコードである。フィルタ・サブバンド・ベンチマークは、ＭＰＥＧアプリケーションのものである。２Ｄ Ｃｏｎｖｏｌｕｔｉｏｎが、最大のベンチマークであり、これは２Ｄ畳み込みを実行するカーネルである。この畳み込みは、ＵＴＤＳＰのソーベル・エッジ検出アプリケーションの一部である。

複数の最適化レベルについてのこの方法および装置の有効性を表１に示す。レベル０１は、ディレクティブまたはコード再構築を適用しない。レベル０２は、図３に示すすべてのステップを通過するが、５番目のステップ３４０の最適化を実装しない。レベル０３は、前記レベルに自動メモリ分割ディレクティブを追加する。レベル０４は、５番目のステップ３５０におけるメモリ最適化を追加する。レベル０５は、レベル０３に演算最適化を追加し、レベル０６はレベル０４に演算最適化を追加する。レベル０７とレベル０８は、それぞれレベル０５および０６に完全配列分割を適用する。

これらの最適化を考慮して生成されたＣコードの結果を、入力Ｃコードにわたって手動による最適化と比較する。Ｃコードのベースラインが表２に簡単に要約されている。ソフトウェア・プログラマがいくつかのきわめて基本的なディレクティブを使用することができるであろうというのは妥当な想定である。しかし、典型的なソフトウェア・プログラマがすべての種類のディレクティブに精通していると想定することはできない。したがって、この評価手法は、この方法の有効性を、異なるレベルのハードウェア設計知識について調査することを可能にしている。

３２ＧＢのＲＡＭを有するインテル・コアｉ７－７７００を備えたＰＣでＣコードをＶｉｖａｄｏ ＨＬＳ２０１７．４により、Ａｒｔｉｘ（ＴＭ）－７ＦＰＧＡ、８５Ｋロジック・セル（ｘｃ７ｚ０２０ｃｌｇ４８４１）を対象として合成し、速度と資源値とを得ている。２０ｎｓの制約を有するフィルタ・サブバンド・ベンチマーク以外は、ベンチマークのすべてが１０ｎｓの時間制約を有していた。ハードウェア実装形態の合計時間は、クロック周期とレイテンシとの乗算として計算される。高速化は、表２の実装形態の合計時間を異なる最適化レベルの結果の合計時間で割った結果である。

図１５に示すフィルタ・サブバンド・ベンチマークは、すべてのレベルにおいてこの方法および装置がＣ－ｈｉｇｈと比較しても高速化向上を示しているため、この方法および装置の態様を示すためのきわめてよい例である。図１５は、元のＣ実装形態（左軸）および最適化されたＣ－ｈｉｇｈ実装形態（右軸）と比較した高速化を示す。バーと点の上部に明確な値が示されている。バーは元のＣに関する高速化を示し、点はＣ－ｈｉｇｈを基準にした高速化を示す。ベンチマークにはループがなく、完全にアンフォールドされているためにレベル０１はほとんどのＩＬＰを顕在化させるため、レベル０１には大幅な高速化がある。しかし、その資源使用量は、使用されているＦＰＧＡの最大資源量を大幅に超える。

資源使用量を制限するために、この方法および装置はループにおけるデータフローをフォールドする。レベル０２でフォールドすることによって、この方法および装置は、Ｃ－ｈｉｇｈバージョンと比較して改善された結果を達成する。これは、リスト２に見られるように、アルゴリズムをより効率的に実行する、この方法および装置によって生成されたパイプラインによるものである。レベル０３において、高速化はＣ－ｈｉｇｈと比較して２．８１倍に向上している。レベル０４の最適化の結果、Ｃ－ｈｉｇｈと比較して２．５５倍の高速化となる。この高速化は、この方法および装置が反復回１回当たりのメモリ読み出しを半分にするデータによる。これは、この方法および装置が、メモリ読み出しの量を低減することによってパイプラインの開始値を下げることができるため、パイプラインに対する効果が大きい。最適化されたループは３番目のステップ３２０のループであり、したがって、４番目のステップ３３０の最適化は適用することができない。したがって、高速化はレベル０３よりは低い。この例では、得られた最大周波数は約５４．５Ｍｈｚであった。

レベル０５は、Ｃ－ｈｉｇｈと比較して３．２８倍の高速化を獲得する。これは、レベル０３における２．８１倍と比較して大幅な向上である。演算最適化は、実装形態のレイテンシまたは反復間隔には大きな影響を与えない。反復間隔は後続の反復回間の時間である。反復間隔が小さいほど、より多くの計算が並列で行われており、それによってレイテンシが低減し、クロック・サイクル数が減少していることを示している。しかし、累積チェーンを分割することによって、Ｖｉｖａｄｏ ＨＬＳはコードを異なる方式で合成する。従来は、チェーン化された加算を実行するために、Ｖｉｖａｄｏ ＨＬＳは、より効率的となるように互いにチェーン化されている加算器を適用していた。しかし、部分和により、Ｖｉｖａｄｏ ＨＬＳは加算を並列に合成する。このような加算器の実装は異なっており、したがって、その結果はより大幅な高速化につながるより低い頻度を有する。レベル０６において演算最適化を追加することにより、３．４３倍の高速化が得られる。以前には加算のすべての結果が出力ベクトルに保存されていたことにより、Ｖｉｖａｄｏ ＨＬＳは、すべての中間値をメモリに書き込む必要があったが、これは不要である。このチェーンを平衡化し、結果をローカル変数に記憶することによって、メモリ・アクセスにより生じる遅延が解消される。レベル０７は、メモリを分割することによってより多くのＩＬＰが可能であるため、Ｃ－ｈｉｇｈと比較して５．４９倍の高速化を獲得する。レベル０８は、高速化がきわめて大きいが、必要な資源が対象ＦＰＧＡのキャパシティをはるかに超えるため、含めていない。資源使用量に関しては、すべての実装形態が、より多くのＩＬＰを有するため、より多くの資源を使用する（表３参照）。しかし、出力コードがローカル配列を使用しなくなり、その代わりに値をレジスタに格納するため、これらの実装形態が使用するＢＲＡＭはより少ない。以前の方法では、Ｖｉｖａｄｏ ＨＬＳは２つの異なるループを扱っており、したがってＨＬＳツールは、新たなループを開始する前に最初のループで計算された値をメモリに記憶する必要があった。唯一の例外は、多くのＢＲＡＭを使用するレベル０４である。これは、この実装形態のコードがすべての加算の結果を出力ベクトルに格納するためである。したがって、パイプライン化を可能にするためには、ＨＬＳツールは、値が失われないように保証するために加算の結果を格納するための追加のＢＲＡＭをインスタンス化する必要がある。しかし、レベル０６において加算を分割することによって、Ｖｉｖａｄｏ ＨＬＳは出力ベクトルに最後にのみ格納する。したがって、ＨＬＳツールは追加のＢＲＡＭを必要とせず、その代わりにそれらをレジスタに保存する。

ドット積は、単純なカーネルである。最初の最適化レベルはよりよい結果にはつながらない。この方法および装置がメモリ分割を適用した後は、この方法および装置はＣ－ｈｉｇｈバージョンの速度に匹敵する（表４参照）。出力レベル０３は、入力の基本バージョンおよび中間バージョンよりもそれぞれ１６．８倍および５．６倍の高速化により高速である。メモリ冗長性がない場合、レベル０４は結果を変化させない。レベル０２の最大周波数は１５６ＭＨｚであり、レベル０３の最大周波数は１１２ＭＨｚであった。

１Ｄ ｆｉｒベンチマークは５番目のステップ３４０における最適化の効果を示す。レベル０２およびレベル０３において単にフォールドすることにより、Ｃ－ｈｉｇｈバージョンとほぼ同じ結果が得られた。これは、この方法が元のものと同じループを生成するためである。レベル０３の出力は、Ｃ－ｉｎｔｅｒと比較して１．８６倍しか向上しない。この方法および装置がレベル０４でアクセスを最適化すると、高速化はＣ－ｈｉｇｈバージョンと比較して１４．３９倍、Ｃ－ｉｎｔｅｒと比較して２６．７倍である。これは、すでに最適化されている実装形態の大幅な向上である。このＦＩＲベンチマークはＮ＝３２タップ（係数）を使用している。したがって、新たな出力を計算するために３２個の入力を必要とする。しかし、前の反復回から３１個の入力が再利用され、したがってこの最適化では新たな値は１つしか読み出されず、その結果、パフォーマンスが大幅に向上する。レベル０６の演算最適化は、０４と比較して高速化に効果がない。レベル０７の最適化は、０５の１倍と比較して８倍の高速化に達する大きな効果がある。これは、メモリ・ボトルネックを最小限にするメモリ分割による。レベル０８においてメモリを分割することにより、レベル０６の高速化はＣ－ｈｉｇｈと比較して１６．１８倍に上昇させる。この場合も、より多くのＩＬＰの顕在化により資源使用量が増大する（表５参照）。最も顕著な上昇は、より多くの値を格納するフリップ・フロップ（ＦＦ）と、より多くの並行乗算を行うＤＳＰ（デジタル・シグナル・プロセッシング）における上昇である。すべてのレベルについて、最大周波数は１１４ＭＨｚであった。表中のＬＵＴは、ルックアップ・テーブルを意味する。

自己相関は、きわめて興味深い結果を示すもう１つのカーネルである。自己相関は、大きい内側ループを有する小さい最も外側のループからなる。この方法は、レベル０２によって、Ｃ－ｈｉｇｈと比較して１．３倍、Ｃ－ｉｎｔｅｒと比較して２．７倍の向上を示す良好な結果を得ている。これは、外側ループのアンロール・ディレクティブがアンロールされたコードのループ融合を考慮しない最も内側のループによるものである。このディレクティブは、内側ループの複数の独立したコピーを生成する。手動アンフォールドは、これらを結合して単一のループとし、より多くのＩＬＰを顕在化させる。これは、多くの冗長メモリ使用がある自己相関アプリケーションにおいて多くの利点を有する。パイプラインが分割される場合、Ｖｉｖａｄｏ ＨＬＳは、カーネルにおける冗長アクセスを利用しないことになり、より多くのメモリ読み出しをスケジュールする。本明細書のＤＦＧ手法は、データフローを再現し、単一の内側ループを継続して有するだけでよいため、より良好なアンロールされたループの生成を可能にするため、この改良されたループ・アンロール能力はＤＦＧ手法の別の優位性も強調する。前述のように、このアプリケーションは多くの冗長記憶を有するため、このアプリケーションはレベル０４最適化の最良の対象である。この方法および装置がメモリ使用を最適化する場合、速度の大幅な向上が見られ、Ｃ－ｈｉｇｈの７．９倍速い。この速度の大幅な向上は、資源使用量の大幅な増加という代償を払って達成される（表６参照）。この増加は、３番目のステップ３２０のループにメモリ最適化を適用することにより、４番目のステップ３３０にフォールドがなくなり、それにより、結果のコードがさらに大きくアンロールされるためである。レベル０６における演算最適化は、レベル０４と比較して高速化を向上させない。レベル０８は、Ｃ－ｈｉｇｈと比較して４７．４９倍の高速化を達成し、これは他よりもはるかに大きい。これは、この方法が入力配列を完全に分割するためであり、レベル０６の自己相関ベンチマークの場合には、ループを開始する前に多くのサイクルがｓｄ値を読み出すことに使用されていた。単一のサイクルでこれらをすべて読み出すことは、出力に大きな影響を及ぼす。しかし、このレベルの分割が可能なのは、自己相関ベクトルが１７０個の整数値からなる小さい入力ベクトルであるためである。より大きなベクトルは、完全に分割することができない。レベル０８はレベル０６と比較して資源使用量を大幅に増加させない。すべてのレベルが最大周波数１３０ＭＨｚを得る。

２Ｄ Ｃｏｎｖｏｌｕｔｉｏｎベンチマークのための前述の事例の一部におけるように、レベル０２およびレベル０３は同じループを生成し、したがってＣ－ｈｉｇｈと比較して高速化はなく、Ｃ－ｉｎｔｅｒと比較すると１．６倍の高速化となる。３×３カーネルでは、次の画素に進むたびに、隣接９画素を読み取る必要がある。これらの画素のうちの６画素が前の画素の計算に使用されているため、必要な新たな値は３個のみである。

レベル０４のデータ再利用を適用することによって、Ｃ－ｈｉｇｈと比較して１．３６倍、Ｃ－ｉｎｔｅｒと比較して２．２５倍の高速化を達成する。この場合、メモリ・アクセスがより少ないため、内側ループのパイプラインについて実現される反復間隔は、６ではなく３である。この高速化は、メモリ再利用を追加することによってループの構造を変えるために、期待したほど大きくはない。２Ｄ畳み込みは、２Ｄ配列をたどるのに２つのネストされたループを使用する。元のコードには、外側ループと内側ループとの間に演算はなく、そのため元のコードは完全なループである。メモリ・アクセスを最適化することによって、内側ループに入る前にバッファにロードされ、それによって外側ループは完全なループではなくなる。従来、Ｖｉｖａｄｏ ＨＬＳはループを自動的に平坦化し、実行を最適化していた。完全なループがなければこれは不可能であり、期待されるほど向上しない。資源使用量は、Ｃ－ｈｉｇｈバージョンより少しだけ多い（表７参照）。２Ｄ畳み込みは、他のベンチマークよりもはるかに演算が多く、Ｖｉｖａｄｏ ＨＬＳによって完全にアンフォールドすることはできない。したがってレベル０１の結果はない。

レベル０６では、この高速化は、この高速化を演算最適化と組み合わせることによって向上する。この場合の差別化要因は、ループにおける除算の最適化である。除数はすべての反復回で共通であるため、この方法は逆数をループの外部で計算し、除算を逆数による乗算で代用する。ハードウェアにおいて乗算は除算よりも効率的であるため、これによりパイプライン深度が浅くなる。したがって、このレベルの高速化は１．６４倍である。レベル０５の結果は、データ再利用のない演算最適化は、単にループ平坦化のため、大きな効果がないことを示している。レベル０６と同様に、反復レイテンシは削減されるが、ループ平坦化に起因して実装形態には１つのループしかなく、パイプラインを開始する前にループ外部でやはり除算が実装される必要があるため、多くのステップを有する大きなパイプラインにおける反復レイテンシを削減しても大きな効果はない。ループ平坦化のないレベル０６では、ループ内でより小さいパイプラインが複数回実行されることになり、したがって、反復レイテンシの削減はより大きな効果がある。除算最適化のもう１つの利点は、除算最適化によって資源使用量が削減されることである（表７参照）。レベル０７およびレベル０８における配列の分割は、それぞれ２．９９倍および２．５倍の高速化を達成する。他の事例とは異なり、レベル０７は０８よりも良好な実装を有する。これは、この場合、Ｖｉｖａｄｏ ＨＬＳが２つの解決策を実装する方式に起因する。レベル０８は、０７よりも反復間隔がより小さく、深度がより浅いパイプラインを有する。０８の分割のパフォーマンスは実際にはよりよいが、Ｖｉｖａｄｏ ＨＬＳの実装は、内側ループが２倍にアンロールされ、Ｖｉｖａｄｏ ＨＬＳが最後の２つの乗算を単一の乗算器よりもより頻度の高い単一のユニットで実装するため、結果をより悪化させる。これは０７では起こらず、したがって頻度はより低く、それによってより高い高速化が得られる。レベル０７の場合、メモリ分割が適用されるが演算分割が適用されない場合、累積チェーンが実装の有効性を低下させるため高速化は２．２７倍に過ぎなくなる。したがって、単なるディレクティブによるメモリの分割の問題ではない。また、より多くのＩＬＰおよびより大幅な高速化を引き出すためにコードを再構築する必要もある。このベンチマークのすべての最適化レベルが１１４ＭＨｚの最大周波数を達成する。

すべてのＣコードが手動介入なしに完全にこの方法および装置によって生成され、提示されたその結果は、この手法、および特に本明細書の方法および装置の有用性を強力に証明している。

バックエンド１３５の実行時間を計測した。ほとんどのベンチマークについて実行時間は１秒と２秒の間であったが、例外として、２Ｄ Ｃｏｎｖｏｌｕｔｉｏｎベンチマークは最大のＤＦＧによるベンチマークでもあるため、平均して１１秒と１２秒の間であった。もう１つの例外は、５秒で実行される自己相関ベンチマークのレベル０４である。メモリ最適化により、４番目のステップ３３０のフォールドはなく、出力コード・ステップ３７０に大きなＤＦＧが入力される。最速のレベルは０２および０３であった。レベル０１は最適化を実装しないが、大きなＤＦＧを出力することで長い実行時間につながる。レベル０４の実行時間の増加は、最適化されたループの複雑さとサイズとに依存する。

バックエンドの実行時間に対するデータセット・サイズの影響、したがって入力ＤＦＧサイズの影響を分析するために、２Ｄ Ｃｏｎｖｏｌｕｔｉｏｎベンチマークの異なる入力サイズについてバックエンドの実行時間を計測した。計測のために選択された最適化レベルは０７であった。計測は、ステップ３６０におけるＣコードの生成に至るまでの、ステップ３１０からステップ３６０までの完了に必要な実行時間を含み、入力画像サイズが６４×６４、９６×９６、１２８×１２８、および１６０×１６０の場合である。９６×９６の入力サイズでは、バックエンドを実行するのに５０秒かかる。この入力サイズを１２８×１２８に増やすと、バックエンドを実行するのにほぼ２．８分かかる。１６０×１６０の入力サイズは、バックエンドで処理されるのに約７分を要する。反復回間でこの増加率が一定しているとすると、２５６×２５６の入力画像を処理するのに約２８分を要することになり、これは低めの画素解像度では長時間である。したがって、この手法の現在の実装形態は大きな入力トレースにはあまり拡張性がない。

すべてのステップについて所要時間を分析すると、大幅な増加の理由は２番目のステップ３１０を処理するのに要する時間であることが明らかである。３番目のステップ３２０が常に入力ＤＦＧを同じサイズにコンパクト化するため、４番目３３０から７番目のステップ３６０に要する時間は、入力サイズに応じて変化しない。３番目のステップ３２０は、より大きな入力でもあまり長い時間を要しない。これは、２番目のステップ３１０の処理が、３番目のステップ３２０のマッチングを効率的に適用することができるようにするためである。かなりの実行時間を要するのは２番目のステップ３１０である。９６×９６画素の出力画像は９２１６個の出力を有し、１２８×１２８は１６３８４個の出力を有し、すなわち約２倍の出力数である。上述のように、バックエンドは出力を生成するすべてのデータフローを分離する。それぞれを均一化し、次に共通ノードについて比較する。これは、１２８×１２８画像の場合、バックエンドが１６３８４本のデータフローを生成し、均一化し、比較することを意味する。バックエンドを加速し、この手法の拡張性をより高くする１つの方法は、２番目のステップ３１０のより効率的な実装であろう。例えば、２番目のステップ３１０は、出力のＤＦＧが生成されるときに共通ノードと固有ノードとを分離するように最適化することができる。

現在、この方法および装置は与えられた構成の速度の最適化を試みている。しかし、この方法および装置は、フォールドのレベルを上げるかまたは並行ロード／ストアの数を変更する以外には、資源使用量を扱う直接的な方法を提示しない。しかし、これらの間接的な方式は最適化を無用に制限する可能性がある。さらに、５番目のステップ３４０のデータ再利用などの一部の最適化は、高い資源使用量につながる可能性がある。したがって、資源使用量を制御するために２つの側面を考慮することができる。すなわち、（ａ）バックエンド最適化の選択と、（ｂ）ＨＬＳツールを制御するディレクティブの選択である。Ｖｉｖａｄｏ ＨＬＳの場合、資源使用量を最小限にする直接的な方式は、資源割り当てディレクティブによるものである。Ｖｉｖａｄｏ ＨＬＳは、資源数または特定の量の並行演算の制限を可能にする。例えば、ベンチマーク自己相関のレベル０４の場合の並行乗算の量を４０に制限することによって、結果の実装形態は、ＤＳＰを１６０個に対して４０個のみ使用するが、Ｃ－ｈｉｇｈに対する高速化は７．９１倍と比較して６．０９倍である。このように、４分の１の数のＤＳＰで、高速化は元の実装形態の７７％に低下するに過ぎない。この例は、高速化を大幅に犠牲にせずに資源を直接制限する単純な事例を示している。したがってバックエンド１３５に資源を制限するためのディレクティブを挿入するように指示するために潜在的により多くの構成が実装され得る。

本開示は、ソフトウェア・コードをハイレベル合成（ＨＬＳ）ツールにより適するように変換する手法を提示する。この手法は、インストルメンテーション・コードが事前に付加されたアプリケーションの重要機能を実行することによって現在得られる（算術、論理、演算子レベルの）計算のデータフロー・グラフ（ＤＦＧ）表現に基づく。この手法は、グラフ演算をフォールドおよびアンフォールドすることに主として依拠し、重要なアプリケーション・カーネルのコードを完全に再構築することができる方法で実装された。現在の研究ではＣコードが入力として考慮されているが、この手法は、適切なインストルメンテーション・コードの組み込みにより、異なる入力プログラミング言語に対処する可能性も有している。この方法のバックエンド１３５は、ＤＦＧを自動的に再構築することができ、ＨＬＳにとって使いやすい方式でディレクティブが付加されたＣコードを生成することができる。得られた結果はきわめて有望である。元のＣコードと比較すると、本開示の方法および装置によって生成されたＣコードは、元のＣコードよりパフォーマンスが優れ、大幅な高速化が達成される。実現されたＣコードは、手動で最適化された、ディレクティブが付加されたＣコードに匹敵し、ほとんどの場合、よりすぐれている。したがって、この手法は、ソフトウェア開発者が、典型的なＨＬＳツールをバックエンド１３５として使用し、ＨＬＳ専門家の支援を必要とせずに、効率的なハードウェア・アクセラレータを対象とすることを可能にし得る。

謝辞
ＩＮＥＳＣ ＴＥＣは、プロジェクト「ＴＥＣ４Ｇｒｏｗｔｈ －ＴＬ －ＳＭＩＬＥＳ－５ Ｐｅｒｖａｓｉｖｅ Ｉｎｔｅｌｌｉｇｅｎｃｅ， Ｅｎｈａｎｃｅｒｓ ａｎｄ Ｐｒｏｏｆｓ ｏｆ Ｃｏｎｃｅｐｔ ｗｉｔｈ Ｉｎｄｕｓｔｒｉａｌ Ｉｍｐａｃｔ」（ＮＯＲＴＥ－０１－０１４５－ＦＥＤＥＲ－０００２０）の下で、本研究の開発の過程で助成金を提供しており、また、プロジェクトＣＯＮＴＥＸＴＷＡ （ＰＯＣＩ－０１－０１４５－ＦＥＤＥＲ－０１６８８３）からの基金が使用され、両者は欧州地域開発基金によって資金提供されている。

参考文献
［０００１］Ｒ． Ｎａｎｅ， Ｖ． Ｍ． Ｓｉｍａ， Ｃ． Ｐｉｌａｔｏ， Ｊ． Ｃｈｏｉ， Ｂ． Ｆｏｒｔ， Ａ． Ｃａｎｉｓ， Ｙ． Ｔ． Ｃｈｅｎ， Ｈ． Ｈｓｉａｏ， Ｓ． Ｂｒｏｗｎ， Ｆ． Ｆｅｒｒａｎｄｉ， Ｊ． Ａｎｄｅｒｓｏｎ， ａｎｄ Ｋ． Ｂｅｒｔｅｌｓ． Ａ ｓｕｒｖｅｙ ａｎｄ ｅｖａｌｕａｔｉｏｎ ｏｆ ＦＰＧＡ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｔｏｏｌｓ． ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ－Ａｉｄｅｄ Ｄｅｓｉｇｎ ｏｆ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ， ３５ （１０）：１５９１－１６０４， Ｏｃｔ ２０１６．
［０００２］Ｊｏａｏ Ｍ． Ｐ． Ｃａｒｄｏｓｏ ａｎｄ Ｍａｒｋｕｓ Ｗｅｉｎｈａｒｄｔ． Ｈｉｇｈ－ｌｅｖｅｌ Ｓｙｎｔｈｅｓｉｓ， ｐａｇｅｓ ２３－４７． Ｓｐｒｉｎｇｅｒ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ， Ｃｈａｍ， ２０１６．
［０００３］Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔ， ＴＭＳ３２０Ｃ６０００ ＤＳＰ Ｌｉｂｒａｒｙ （ＤＳＰＬＩＢ）， ａｃｃｅｓｓｅｄ ｉｎ １６ Ｊｕｎｅ ２０１８． ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｔｉ．ｃｏｍ／ｔｏｏｌ／ｓｐｒｃ２６５
［０００４］Ｃｏｒｉｎａ Ｇ．Ｌｅｅ， １５ Ａｕｇ ２００２， ａｃｃｅｓｓｅｄ ｉｎ １６ Ｊｕｎｅ ２０１８． ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｅｅｃｇ．ｔｏｒｏｎｔｏ．ｅｄｕ／～ｃｏｒｉｎｎａ／ＤＳＰ／ｉｎｆｒａｓｔｒｕｃｔｕｒｅ／ＵＴＤＳＰ．ｔａｒ．ｇｚ
［０００５］Ｃｏｎｇ， Ｊａｓｏｎ Ｈｕａｎｇ， Ｍｕｈｕａｎ Ｐａｎ， Ｐｅｉｃｈｅｎ Ｗａｎｇ， Ｙｕｘｉｎ Ｚｈａｎｇ， Ｐｅｎｇ． （２０１６）． Ｓｏｕｒｃｅ－ｔｏ－Ｓｏｕｒｃｅ Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ ＨＬＳ， ｐａｇｅｓ １３７－１６３． Ｓｐｒｉｎｇｅｒ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ， Ｃｈａｍ， ２０１６．
［０００６］Ｊ． Ｍ． Ｐ． Ｃａｒｄｏｓｏ， Ｊ． Ｔｅｉｘｅｉｒａ， Ｊ． Ｃ． Ａｌｖｅｓ， Ｒ． Ｎｏｂｒｅ， Ｐ． Ｃ． Ｄｉｎｉｚ， Ｊ． Ｇ． Ｆ． Ｃｏｕｔｉｎｈｏ， ａｎｄ Ｗ． Ｌｕｋ． Ｓｐｅｃｉｆｙｉｎｇ ｃｏｍｐｉｌｅｒ ｓｔｒａｔｅｇｉｅｓ ｆｏｒ ＦＰＧＡ－ｂａｓｅｄ ｓｙｓｔｅｍｓ． Ｉｎ ２０１２ ＩＥＥＥ ２０ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｃｕｓｔｏｍ Ｃｏｍｐｕｔｉｎｇ Ｍａｃｈｉｎｅｓ， ｐａｇｅｓ １９２－１９９， Ａｐｒｉｌ ２０１２．
［０００７］Ｏ． Ｍｅｎｃｅｒ． ＡＳＣ： ａ ｓｔｒｅａｍ ｃｏｍｐｉｌｅｒ ｆｏｒ ｃｏｍｐｕｔｉｎｇ ｗｉｔｈ ＦＰＧＡｓ． ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ａｉｄｅｄ Ｄｅｓｉｇｎ ｏｆ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔｓ ａｎｄ Ｓｙｓｔｅｍｓ， ２５（９）：１６０３－１６１７， Ｓｅｐｔ ２００６．
［０００８］Ａｎｄｒｅｗ Ｃａｎｉｓ， Ｊｏｎｇｓｏｋ Ｃｈｏｉ， Ｍａｒｋ Ａｌｄｈａｍ， Ｖｉｃｔｏｒ Ｚｈａｎｇ， Ａｈｍｅｄ Ｋａｍｍｏｏｎａ， Ｔｏｍａｓｚ Ｃｚａｊｋｏｗｓｋｉ， Ｓｔｅｐｈｅｎ Ｄ． Ｂｒｏｗｎ， ａｎｄ Ｊａｓｏｎ Ｈ． Ａｎｄｅｒｓｏｎ． ＬｅｇＵＰ： Ａｎ ｏｐｅｎ－ｓｏｕｒｃｅ ｈｉｇｈ－ｌｅｖｅｌ ｓｙｎｔｈｅｓｉｓ ｔｏｏｌ ｆｏｒ ＦＰＧＡ ｂａｓｅｄ ｐｒｏｃｅｓｓｏｒ／ａｃｃｅｌｅｒａｔｏｒ ｓｙｓｔｅｍｓ． ＡＣＭ Ｔｒａｎｓ． Ｅｍｂｅｄ． Ｃｏｍｐｕｔ． Ｓｙｓｔ．， １３（２）：２４：１－２４：２７， Ｓｅｐ． ２０１３．
［０００９］ＬＬＶＭ． Ｔｈｅ ｌｌｖｍ ｃｏｍｐｉｌｅｒ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｐｒｏｊｅｃｔ， ２０１８． ＵＲＬ ｈｔｔｐｓ：／／ｌｌｖｍ．ｏｒｇ．
［００１０］Ｍａｘｅｌｅｒ Ｔｅｃｈｎｏｌｏｇｉｅｓ． Ｍａｘｃｏｍｐｉｌｅｒ ｗｈｉｔｅ ｐａｐｅｒ， ２０１７． ｈｔｔｐｓ：／／ｗｗｗ．ｍａｘｅｌｅｒ．ｃｏｍ／ ｍｅｄｉａ／ｄｏｃｕｍｅｎｔｓ／ＭａｘｅｌｅｒＷｈｉｔｅＰａｐｅｒＰｒｏｇｒａｍｍｉｎｇ．ｐｄｆ．
［００１１］Ｎ． Ｖｏｓｓ， Ｓ． Ｇｉｒｄｌｅｓｔｏｎｅ， Ｏ． Ｍｅｎｃｅｒ， ａｎｄ Ｇ． Ｇａｙｄａｄｊｉｅｖ． Ａｕｔｏｍａｔｅｄ ｄａｔａｆｌｏｗ ｇｒａｐｈ ｍｅｒｇｉｎｇ． Ｉｎ ２０１６ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｅｍｂｅｄｄｅｄ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ： Ａｒｃｈｉｔｅｃｔｕｒｅｓ， Ｍｏｄｅｌｉｎｇ ａｎｄ Ｓｉｍｕｌａｔｉｏｎ （ＳＡＭＯＳ１６）， ｐａｇｅｓ ２１９－２２６， Ｊｕｌｙ ２０１６．

Claims (10)

1. 装置に含まれるフィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）においてハードウェア・アクセラレータ（２０）の構成を生成する方法であって、
   前記ハードウェア・アクセラレータ（２０）上で実装されるアルゴリズムを記述するコードの複数の行を有し、かつ、前記コードの複数の行の前にインストルメンテーション・コード（１１２）が差し込まれたプログラム（１０５）を前記装置のフロントエンド（１１０）において実行（１１５）し、メモリにおいてアンフォールドされたデータフロー・グラフ（ＤＦＧ）を生成すること（１２５）と、
   生成された前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）を前記装置のバックエンド（１３５）に渡すことと、
   前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）における反復パターンを特定し、不要ノードの刈り込み（３１０）を行うことと、
   冗長メモリ・アクセスを特定して冗長メモリ・アクセスを削除すること、再利用値のバッファへの記憶を行うこと、または前記ハードウェア・アクセラレータ（２０）において利用可能な資源へのメモリ・アクセスを適応化することのうちの少なくとも１つによって、前記バックエンド（１３５）において前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）を最適化することと、
   前記最適化されたデータフロー・グラフ（ＤＦＧ）から出力プログラム（１４０）を出力（３６０）して、前記ハードウェア・アクセラレータ（２０）の構成を生成することとを含む方法。
2. 前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）の前記最適化は、前記特定された反復パターンを前記データフロー・グラフ（ＤＦＧ）内にフォールディングすることを含む、請求項１に記載の方法。
3. 不要ノードの前記刈り込み（３１０）は、ローカル配列をスカラー変数に変換することを含む、請求項１に記載の方法。
4. 出力された配列内の出力値の個別データフローを特定することと、出力上の共通の演算を、前記出力の１つ１つに固有の演算から分けて、それにより、前記共通の演算を有するグラフと、前記固有の演算を有するグラフのリストとを生成することをさらに含む、請求項１から３のいずれかに記載の方法。
5. 算術演算におけるステップの数を削減すること、または並行算術演算の数を増やすことのうちの少なくとも一方をさらに含む、請求項１から４のいずれか一項に記載の方法。
6. 前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）におけるパイプライン化を特定すること（３３０）をさらに含む、請求項１から５のいずれかに記載の方法。
7. 前記アンフォールドされたデータフロー・グラフ（ＤＦＧ）は複数のループを含み、前記方法は、前記データフロー・グラフ（ＤＦＧ）における前記複数のループのうちの１つまたは複数のループをアンフォールドすること（３５０）と、次に前記データフロー・グラフ（ＤＦＧ）の前記最適化を繰り返すこととをさらに含む、請求項１から６のいずれか一項に記載の方法。
8. ハードウェア・アクセラレータ（２０）の構成方法であって、
   請求項１から７のいずれか一項により前記ハードウェア・アクセラレータ（２０）の構成を、前記ハードウェア・アクセラレータ（２０）の前記構成を表す出力プログラム（１４０）の形態で生成することと、
   前記出力プログラム（１４０）を前記ハードウェア・アクセラレータ（２０）に提供し、それによって前記ハードウェア・アクセラレータ（２０）の構成を可能にすることとを含む方法。
9. 請求項１から７のいずれか一項に記載の方法を実装するように構成された装置。
10. 複数の電子構成要素を含むハードウェア・アクセラレータ（２０）であって、前記複数の電子構成要素は、請求項１から７のいずれか一項に記載の方法によって出力される出力プログラム（１４０）によってプログラムされる（３７０）、ハードウェア・アクセラレータ。
    

Images