BittWare
オンデマンドウェビナー

(マーカス)

FPGAを使用した高性能コンピュートアクセラレーション 、インテルのoneAPIを取り上げたウェビナーにご参加いただきありがとうございます。まず、プレゼンターとその内容を簡単にご紹介します。

BittWare彼はNallatech社でFPGAエンジニアとしてキャリアをスタートさせ、現在はBittWare のマーケティングVPを務めている。FPGAがHPCにどのようにフィットするか、さらにBittWare カードとoneAPIのサポートについて説明する。      

次に、IntelのDavid Clarke氏からお話を伺います。彼はテクニカル・セールスのスペシャリストで、FPGAのパワーをより活用するためのインテルのエコシステム、ソフトウェア、プラットフォームについて、特にソフトウェア主導の開発フローをより簡単に導入するための概要を説明する。

続いてマウリツィオ・パオリーニが、インテルがoneAPIを導入する理由を説明する。彼は、Altera で20年以上の経験を持つフィールド・アプリケーション・エンジニアで、インテルによるAltera 買収後、クラウドとエンタープライズアクセラレーション に注力するようになった。彼は、oneAPIがどのようにプログラミングの課題を解決し、複数のアーキテクチャにまたがるアクセラレーション 。         

最後に、BittWare の主席システムエンジニア、リチャード・チェンバレン氏から話を聞く。リチャード氏は、BittWareのFPGAカード用にOpenCLでオリジナルの2D FFTデモを作成し、現在はoneAPIに移植している。

なお、2D FFTコードは、リクエストに応じて、BittWare ウェブサイトのリソースセクションで入手できる。

さて、ライブの時間帯にこの番組をご覧になっている方は、メイン・プレゼンテーションの後、パネリストとの質疑応答セッションの準備をされることをお勧めします。今すぐ、あるいは質疑応答中に質問をしたい場合は、質問パネルを探し、質問をタイプしてください。

さて、クレイグ・ペトリによるHPCの概要から始めよう。

(クレイグ)

オーケー、ありがとうマーカス。

BittWare をご存じない方のために説明すると、当社はモレックスが行った2つの買収から生まれた会社です。

1つ目は2016年のナラテック・グループで、カリフォルニアと英国に拠点がある。2つ目は2018年のBittWare 、ニューハンプシャー州コンコードに本社を置く。両社は2018年中に合併し、BittWare 、モレックス・カンパニーと改称された。

私たちは、さまざまな市場において30年にわたるFPGAの専門知識を有しています。当社はインテル・パートナー・アライアンス・プログラムの一員であり、過去20年にわたり、あらゆる世代のAltera 、インテルFPGAを搭載したハイエンドFPGAアクセラレータを開発してきました。

その他に強調すべきユニークなセールスポイントは、私たちが自社製造とグローバル・ロジスティクスを持つ大手モレックス・グループの一員であるという事実です。

具体的には、データコム・スペシャリティ・ソリューション・グループ（DSS）の一部門です。

これにより、FPGAの専門知識と高度な製品をモレックスのグローバルブランドの規模とリーチと組み合わせることができます。

BittWare そのため、エンタープライズクラスの認定、検証、ライフサイクル、サポート要件に対応できるFPGAカードおよびシステム製品サプライヤとしては、クリティカルマスを有する唯一の存在となっている。

BittWare は多くのインテル FPGA デバイスをサポートしている。しかし、このテクニカル・ワークショップでは、BittWare の2つの主力製品に焦点を当てる。

1つ目は520シリーズで、インテルのStratix 10 GX、NX、MXをサポートしている。

16GBのオンパッケージHBM2メモリーを搭載したMXバージョンは、oneAPIを使用する本日のデモで対象とするカードだ。

PCI Express Gen 3の16レーン、16ギガバイトのHBM2メモリ、さらにI/Oパイプのサポートを誇り、QSFP28ネットワークポートを介した低レイテンシー、高帯域幅、決定論的なカード間シリアル接続を使用して、アプリケーションを拡張することができます。

BittWare 、520シリーズのOpenCLプログラマブル・アクセラレータは、パブリックドメインの2台のスーパーコンピュータへの導入に成功している。

詳しくは以下の記事やビデオをご覧いただきたい。

私たちがターゲットとする2つ目の製品は、インテルAgilex FPGAを搭載した新しいフラッグシップ・アクセラレータです。

BittWare IA-840fは、インテルが現在販売しているFPGAの中で最大のAgilex 。最初のユニットは7月に出荷予定。

初期のツールフローは、VHHLとVerilogをベースにしています。しかし、今年後半にはoneAPIのサポートを導入する予定です。

IA-840fは、520Nシリーズと同じエンタープライズクラスのDNAを共有しています。しかし、Agilex P-TileハードIPを介したPCIe Gen 4 x16レーンのサポートを含め、すべての主要インターフェイスを改良しました。IA-840fはGPUサイズのPCIeカードで、アクティブ、パッシブ、さらに液冷のオプションがあります。GPUを搭載するほぼすべてのサーバーおよびエッジプラットフォームと互換性があります。

BittWareのFPGAアクセラレーション製品は、コンピュート、ネットワーク、ストレージ、センサー処理という4つの主要アプリケーション分野に対応するよう設計されており、データセンター、クラウドインフラ、エッジ・オブ・ネットワークの各領域にまたがっている。

これらのアプリケーション分野のワークロードに対するFPGAの価値提案は強力であり、年々強化されています。多くの顧客が、総所有コストを削減しながら性能を強化するために、AIや機械学習推論技術を採用しています。

ここでは、インテルベースのFPGAアクセラレータ（BittWare ）で高速化可能な、計算集約的なワークロードについて紹介したい。

具体的には、OpenCLやこの場合はoneAPIのような高レベルのツールを使用しているものだ。

そのために、BittWare のウェブサイトを活用する。このウェブサイトには、主要なアプリケーション分野ごとに専用のランディングページが用意されている。

各ページには、顧客ケーススタディ、ホワイトペーパー、リファレンスデザイン、ビデオなど、豊富な情報が掲載されている。

では、まずコンピュート・ランディング・ページに飛び込んでみましょう。ここをクリックします。

そのため、当社の経験では、FPGAを使用して高性能コンピューティング・ワークロードを高速化するお客様は、ほとんどの場合、ヘテロジニアス・プラットフォームを構築しています。これは、協調して動作する補完的な技術の組み合わせを特徴とするプラットフォームです。例えば、x86（CPUベース）、GPGPU、SmartNICなどです。

FPGAはアプリケーション全体の性能に貢献するだけでなく、ワークロードの柔軟性やエネルギー効率の高い動作も実現する。

FPGA 技術にあまり馴染みのない人や、ソフトウェア指向のバックグラウンドを持つ人にとって、自分のアプリケーションにFPGAアクセラレーション が役立つかどうかを判断するのは非常に困難なことです。

私たちがこのランディングページで試みたのは、お客さまがその決断を下すためのガイダンスを提供することです。

ここにはたくさんのコンテンツがある。

ウェビナー終了後、時間があれば、ランディング・ページとコンテンツをもっと詳しくご覧になることをお勧めします。

アプリケーションの特性を明確に絞り込める顧客にとっては、アプリケーションにFPGAを使用すべきかどうかを迅速に判断することが可能です。

FPGAが適しているアプリケーション特性を5つに絞った。

したがって、これらの特性の1つまたは複数に当てはまる場合は、FPGAの使用をさらに詳しく検討する必要があるでしょう。

つまり、同時にいくつもの計算を行うことができる。つまり、同時にいくつもの計算を行うことができる。

FPGAは、粒度とデバイスの並列性を考えると、そこに適している。

もうひとつは、メモリのアクセスパターンがキャッシュに優しくない場合だ。マイクロプロセッサーやGPGPUを使用する場合、それらのメモリー階層は固定されている。一方、FPGAは完全にカスタム化されたメモリ階層を構築できる。そのため、アプリケーションが非標準的なものを必要とする場合は、FPGAの方が良い選択肢となる。

3つ目の特性は、CPUやGPGPUでネイティブにサポートされていないデータ型を使用する場合だ。

だから、プログラミングや倍精度浮動小数点を使うアプリケーションを使うのであれば、その種の問題を解決するためにGPGPUを使うべきだろう。

一方、ビット・レベル、パターン・マッチング、ある種の特殊な整数演算、あるいは超越単精度浮動小数点などの低レベルの演算を行うのであれば、FPGAは検討すべき有力な候補となる。

アプリケーションに低レイテンシーや決定論的動作が必要な場合、FPGAは理想的な候補となる。

ここに挙げた5つ目のユースケースは、顧客が何らかの外部I/Oへのインターフェースを必要としているケースだ。それは様々な形や大きさがあります。イーサネットやNVMeのようなプロトコルや業界標準も含まれます。

FPGAは、カスタム・インターフェイスや独自のインターフェイスで通信することもできます。このような状況では、FPGAピンのほとんどがプロトコルに依存しないため、FPGA I/Oは高度にカスタマイズ可能です。そのため、FPGAはそのような状況において非常に優れた候補となります。

わかりました。それではデビッドとマウリツィオに、インテル社とoneAPIツールの紹介をお願いしたいと思います。デビッド、どうぞ。

 (デビッド)

ありがとうクレイグ。デビッド・クラークです。私はインテルのテクノロジー・セールス・スペシャリストで、FPGAアクセラレーション をクラウドとエンタープライズに推進する責任者です。

インテルは、金融サービス産業、人工知能、機械学習、科学研究、高性能コンピュートなど、エッジからデータセンターまでの多くの市場において、コンピュートとデータ処理に長い歴史を持っている。

伝統的にCPUの血統で知られるインテルは、FPGAを技術として活用するためにAltera 。

高性能コンピュート市場では、CPUだけでなく、FPGAもそのユニークな利点のために採用されています。例えば、ディープ・パイプライン・コンピュート、リアルタイム・インラインの低レイテンシ決定論的処理、あるいは高度に並列化された数学関数（アクセラレーション ）など、ワットあたりのTCOを向上させることができます。

しかし、新技術を市場に導入するのは難しく、3つの基準のいずれかに左右される：

• 新技術は、現在の標準的な技術では解決できない問題に対する唯一の解決策である。
• その恩恵は非常に大きく、リソースの投資や雇用、再トレーニングは許容される。
• 小さな段階的利益は、それが非常に、非常に簡単に達成できる場合に魅力的である。

これまでFPGAは、RTL専門言語や専門リソースを使用した開発フローが必要であったため、特定のアプリケーションや市場でしか利用できない技術でした。

最終的な目標は、FPGA自体の知識を必要としない開発フローを通じて、クラウドやエンタープライズでFPGAの利点を活用できるようにすることです。FPGAの開発フローは、投資や再トレーニングなしに、すでに社内にあるリソースがFPGAをターゲットにすることを可能にします。基本的に、ソフトウェア・エンジニアがハードウェアを設計できるようにすることで、FPGAは開発者、パートナー、システム・インテグレーター、そして従来とは異なるFPGA市場やアプリケーションにまたがる顧客が利用できる技術となる。

インテルとBittWare のようなパートナーのエコシステムは、インテル oneAPI の出現と相まって、FPGA 非ユーザーが FPGA を採用し、コンピュート課題を解決し、ゲームを変えるアクセラレーション を提供する FPGA のユニークな能力を活用することを可能にする方法論を提供します。

もっと詳しくお知りになりたい方は、インテルのアクセラレーション スペシャリスト・エンジニアの一人であるマウリツィオにお譲りしましょう。ありがとうございました。

(マウリツィオ）

デビッド、ありがとう。なぜインテルはoneAPIを導入するのですか？

今日のHPC環境では、ワークロードを実行するためにいくつかのハードウェア・アーキテクチャが利用可能です：CPU、GPU、FPGA、そして特殊アクセラレータです。アーキテクチャの多様性を推し進める背景には、ワークロードの多様性があります。すべてのワークロードに最適な単一のアーキテクチャはないため、あらゆる可能性のあるシナリオでパフォーマンスを最大化するには、アーキテクチャのミックスが必要です。

しかし、異種アーキテクチャーの使用には大きな負担が伴う。まず、データ中心のハードウェアは、それぞれ異なる言語やツールを使ってプログラミングする必要がある。つまり、異なるプラットフォーム用に別々のコードベースを維持する必要があり、プラットフォーム間でコードを再利用することは不可能になる。その上、各プラットフォームには、コードをコンパイル、分析、デバッグするための独自のツール・セットが付属している。

つまり、各プラットフォーム向けにソフトウェアを開発するには個別の投資が必要で、その作業を別のアーキテクチャ向けに再利用することはほとんどできない。

oneAPIはこの問題を解決するために設計された。統一されたプログラミング・モデルを提供することで、多様なアーキテクチャでの開発を簡素化します。

oneAPIプログラミング・モデルにより、開発者は同じ言語とライブラリを使用して異なるハードウェア・プラットフォームをターゲットとすることができ、同じデバッグ・パフォーマンス解析ツール・セットを使用して異なるプラットフォーム上でコードを開発し最適化することができます。例えば、Vtuneプロファイラを通じて、ホストとアクセラレータ間のランタイムデータを取得することができます。

プラットフォームやハードウェア・アーキテクチャを超えて同じ言語を使用することで、ソースコードの再利用が容易になる。コードを異なるプラットフォームに移行する際に、プラットフォーム固有の最適化が必要であったとしても、コードの翻訳はもう必要ありません。また、共通の言語とツールのセットを使用することで、新人開発者のトレーニングが早くなり、デバッグが速くなり、最終的には生産性が向上します。

oneAPI言語はData Parallel C++である。これは、並列プログラミングの生産性を高めるために設計された高水準言語で、幅広い互換性のためにC++言語をベースにしている。

DPC++はプロプライエタリな言語ではありません。その開発は、オープンな業界横断イニシアチブによって推進されている。その出発点は、業界コンソーシアムKhronos Groupの下で開発されているSYCLです；

言語の強化は、インテルが積極的に貢献しているコミュニティ・プロジェクトによって推進されており、拡張機能を通じて言語のギャップに対応しています。

インテル oneAPI 製品には、LLVM コンパイラー・テクノロジーに基づき、インテルのコンパイラー開発における長年の経験を活用した DPC++ コンパイラーが含まれています。

また、CUDAからDPC++への変換を支援するソースコード間互換ツールも含まれています。

現在、FPGA用にコードをコンパイルする際の主な問題の1つはコンパイル時間です。DPC++コードを、そのコードで指定されたハードウェア・アーキテクチャを実装するタイミング・クローズドFPGA設計に変換するために必要なバックエンドのコンパイル・プロセスは、完了までに数時間かかることがあります。そのため、FPGA開発フローは、完全なコンパイル実行を最小限に抑えるように調整されています。

このスライドはFPGAの開発フローを示しています。 

フローの最初のステップは機能検証で、テストベンチを使ってコードが正しいかどうかをチェックする。これは、FPGAをターゲットとするコードがコンパイルされ、CPU上で実行される開発プラットフォーム上のエミュレーションを使用して行われる。これにより、バグが発見され、修正する必要がある場合のターンアラウンドタイムが大幅に短縮される。そのためには、標準的なCPUデバッガ（Intel Distribution for GDBなど）を使用できる。

機能検証が完了すると、コンパイラが生成するレポートを通じて静的性能解析が実行されます。レポートには、デザインのメモリ、データ・フロー、その他の性能ボトルネックを特定するために必要なすべての情報と、当該ボトルネックを解決するための最適化手法の提案が含まれます。さらに、ターゲットFPGAに対するデザインの面積とタイミングの見積もりも提供します。

静的解析の結果が満足のいくものであった場合にのみ、完全なコンパイルが可能となる。コンパイラーは、生成されたハードウェアにリクエスト・プロファイリング・ロジックを挿入できることに注意してください。プロファイリング・ロジックは、メモリーおよびパイプ・アクセスのダイナミック・プロファイリング・データを生成し、Vtuneパフォーマンス・アナライザーで使用することで、他の方法では発見できないデータ・パターン依存のボトルネックを特定できます。

FPGA上でoneAPIを使い始めるには、3つのコンポーネントが必要です：

• インテル oneAPI ベース・ツールキット
• oneAPIベースツールキット用インテルFPGAアドオン
• 使用するカードのボード・サポート・パッケージ（BSP）。

oneAPIコンポーネントはインテルのサイトからダウンロードでき、BSPはカードベンダーから提供される。

FPGA上のoneAPIについてもっと知りたい人のために、たくさんのリソースが用意されています。まず、Intel oneAPI DPC++の仕様は、Intel oneAPI Programming GuideとIntel oneAPI DPC++ FPGA Optimization Guideを含むIntelのウェブサイトに掲載されています。

チュートリアルの豊富なセットは、Githubサイトからダウンロードすることができ、言語のいくつかの機能をカバーし、oneAPIツールチェーンで使用できるコードスニペットと一緒に提供されています。

また、金融、データベース、アクセラレーション 、圧縮など、いくつかの重点分野のための本格的なリファレンス・デザイン、高性能。

最後に、インテルが提供するトレーニング。これらはインストラクターによる終日および半日のトレーニングで、さまざまなGEOで予定されている。

インテルはまた、自分のペースで学習し、管理された環境でコードを弄れるように、インテルのDevクラウド上のJupyterラボに接続するJupyterノートブックモジュールも提供している。

最後に、シュプリンガーのウェブサイトからPDF形式で無料ダウンロード、またはペーパーバックで購入できる本がある。

そして次はリチャードだ。

(リチャード)

この FFT 2D ケーススタディは、BittWare 520N-MX アクセラレーターカードを対象としています。520N-MXはPCIeボードで、インテルのStratix 10 MX FPGAと統合HBM2メモリを搭載しています。HBM2の高帯域幅により、メモリ・バインド・アプリケーションのアクセラレーション 。このプレゼンテーションでは、オンチップHBMメモリとoneAPIツールフローを使用して、2D FFTのパフォーマンスを最大化する方法を説明します。

このユースケースには、2D FFTが選ばれた。特に、大規模な2D FFTは、ローカルFPGAメモリに収まらないため、計算がHBM帯域幅に依存せざるを得ないように選択された。

このプレゼンテーションでは、HBMメモリのアクセスパターンを可能な限り効率的に最適化する方法を説明します。

Stratix 10 MXには16個のHBMメモリが搭載され、それぞれ2個の疑似ポートがあり、すべて独立してアドレス指定が可能である。デバイスの上部に16バンク、下部に16バンクのメモリがあります。各ポートの最大帯域幅は12.8 GB/sで、ここで使用したスピードグレード-2のデバイスでは、理論上の合計性能は409 GB/sとなります。

2D FFTは、画像の行に対する一連の1D FFTと、それに続く画像の列に対する1D FFTを使用して計算することができます。

変換を生成するには、原画像に対して2回のパスが必要である。すべてのSDRAMメモリは、メモリアクセスが連続しないと性能が低下します。行アドレッシングから列アドレッシングに移行する場合、コーナーターンと呼ばれることもありますが、SDRAMメモリ内の行をジャンプする必要があり、全体的なパフォーマンスが低下します。

コーナーターンがパフォーマンスに与える影響を測定するため、簡単なテスト・アプリケーションを作成した。

このグラフは、この2D FFTの例で観察されたデータアクセスパターンについて、バーストサイズが平均読み取り/書き込み帯域幅に及ぼす影響を示しています。このグラフは、単一のHBM擬似チャネルの性能を表しています。

考えられるメモリ構成は2つあり、それぞれにメリットがある。同じHBMに読み書きすることで、1つのFFTを一括して実装することができますが、全体的なパフォーマンスには若干のコストがかかります。これは青い線で表されています。

あるいは、赤線で示したように、入力と出力のHBMバンクを別々に使用することで、帯域幅は大幅に向上しますが、利用可能な帯域幅を完全に利用するには、複数の2D FFTのバッチ処理またはパイプライン処理が必要になります。

この例では、512バイトのバーストサイズが選択されている。これは、中間結果のキャッシュに必要なローカルFPGAメモリが少なくて済む一方で、ほぼ最適なパフォーマンスが得られるためである。

2D FFTの例は、もともとIntel FPGA OpenCLコンパイラを使ってプログラムされたもので、このデモのためにoneAPIに移植された。カーネルコードは、最適化プラグインの基本的な変更のみで、2つのソフトウェアフロー間で大きな変更はありませんでした。パイプライン化と並列化技術も変わりません。

DPC++はSYCLをベースに構築されており、ホストとカーネルのバイナリに2つの異なるフローを使用するのではなく、ホストとカーネルのコードの分離を推測するためにSYCLコンストラクトを使用します。ホスト・コードとカーネル・コードを異なるコンパイラでコンパイルする代わりに、単一のコンパイルが実行されます。

OpenCLのもう1つの変更点は、FATバイナリの作成で、FPGAイメージが実行ファイルに含まれるようになった。

以下のセクションでは、このアプリケーション・ポートで使用されているDPC++およびSYCLコンストラクトのいくつかを簡単に説明します。

デバイス（FPGA、CPU、GPUのいずれか）は、アプリケーションに特定のアクセラレータ・タイプへのハンドルを与えるセレクタを介してアクセスされる。このハンドルは、SYCLがターゲット・デバイスとの通信に使用するキューを作成するために使用されます。

このコード例では、FPGAハードウェアまたはデバイスのエミュレーションのいずれかをターゲットにする方法を説明します。FPGA用のコンパイルには何時間もかかることがあるため、エミュレーションは重要です。

DPC++では、SYCLバッファとアクセッサを使用して、ホストとカーネルの両方のアプリケーションからアクセス可能なメモリを記述します。このコード例では、配列からバッファ型にデータをコピーし、そのバッファ型にSYCLアクセサ型を使ってアクセスします。

バッファの位置は、アクセサー・プロパティを通じて提供される。ここでは、バッファー位置プロパティを使用して、HBMメモリ0/32を指しています。プロパティIDは、デバイスのボード・サポート・パッケージで各メモリ・バンクが表示される順番を参照しています。

キューは、ホスト・プログラムを1つのデバイスに接続する。生成されたハンドルを使用して、SYCLタスク（この場合はシングル・タスク・カーネル）をキューに投入することができる。ここはまた、インターフェース固有の属性を追加できる場所でもある。

この設計では、入力データを複数のHBMメモリ上にストライピングし、各HBMインターフェースに専用の1次元FFTを配置します。これにより、FPGAの演算とメモリ帯域幅のバランスがうまく取れている。各FFTは完全にパイプライン化され、ピーク・スループットは約40GFlops/secとなるように設計されている。

1D FFTの出力はローカル・バッファに置かれる。ここに十分なデータ行を格納することで、HBMに十分な大きさのバーストを生成し、良好なスループットを維持することができます。この簡略化されたアニメーションは、この設計でコーナーターンが実際にどのように達成されるかを示しています。ローカル・オンチップ・メモリに一時的に格納された8行のデータが、HBMに書き戻す際に8ワードのバーストを可能にするためにどのように使用されるかを示しています。実際には、16個のFFTが並列に実行され、64行の結果がバッファリングされます。

複数の1次元FFTの出力は、第2ステージのために転置する必要がある。これは画像全体に対して行うのではなく、メインパイプラインの一部として実行されます。各FFTからの出力は、他のすべてのHBMバンクに書き込まれなければならない。この場合、各出力バッファからすべてのHBMメモリに複数回アクセスする必要があり、パイプラインにバブルが発生してパフォーマンスが低下します。アクセスはリニアなので、FPGAの豊富なレジスタを利用して専用のシフト・レジスタを作成することができます。

これは、FPGAレジスタのみを使用して完全にパイプライン化されたスライディング・ウィンドウを作成するコード例に示されています。各列の出力は、クロック・サイクルに1回だけ各HBM上で更新を作成するために遅延されます。最後に、このプロセス全体が再び繰り返され、最終的な画像は元の画像と同じ向きで複数のHBMにまたがってストライピングされます。

コードをDPC++に移植した後、最初にすべきことは、コードが機能的に正しいかどうかをテストすることだ。

インテルとBittWare のサンプルはすべて、エミュレーション用にビルドすることができ、カーネル・コードをローカル・プロセッサ上で実行することができます。2D FFTの例では、make fpga_emu（FPGAエミュレーションの場合は "EMU"）とタイプするだけです。エミュレーション実行ファイルを実行すれば、設計の機能を数秒で検証できます。

入力画像と変換画像を表示するためにPythonを使用した2D FFTの出力例です。デザインの機能が検証されたら、次のタスクはパイプラインの効率とリソースの使用量をチェックすることです。

これはFPGAをターゲットにして行われるが、最初のデザイン解析が完了すると一時停止する。レポートを作成するには、"make report "と入力します。これには数分かかるので、以前に実行したものをここに示す。

まず、カーネルのパイプライン化が成功したかどうかをチェックする。開始間隔が1、つまり完全にパイプライン化されたカーネルを探している。次に、必要なリソースをチェックする。問題がなければ、FPGA用にコンパイルします。これには数時間かかる。

FPGAバイナリを含む新しい実行ファイルが作成されます。この実行ファイルを実行すると、FPGA上でFFTカーネルを実行するのにかかった時間を見ることができる。

VtuneでFPGAカーネルのプロファイリングを有効にするには、oneAPI FPGA実行ファイルを-XSプロファイルでコンパイルするだけです。これにより、FPGAデザインにパフォーマンス・カウンターが自動的に追加され、アプリケーション実行後にVtuneが統計情報を取得できるようになります。

FPGA のプ ロ フ ァ イ ルを作成す る には、CPU/FPGA Interaction オプシ ョ ン を選択 し て正 し いア ク セ ラ レー タ ー コ ン フ ィ ギ ュ レーシ ョ ン を選択 し ます。FPGA デザ イ ン を含むホ ス ト の実行バイナ リ を選択 し 、 その実行バイナ リ を起動 し ます。こ れに よ り デザ イ ンが実行 さ れ、 ホ ス ト お よ びFPGA か ら プ ロ フ ァ イ ル情報が収集 さ れます。

サマリー・ページでは、アプリケーションの全体的なタイマーと、FPGAカーネルの実行にかかる時間の概算を見ることができる。

プラットフォームを選択すると、オフロードされたFPGAカーネルがアプリケーションのプロファイルにどのように適合するかを示すイベントのスケジュールが表示されます。

FPGAを拡大すると、FPGAカーネルのすべての内部および外部メモリ・インターフェースのプロファイル情報が表示されます。これにより、カーネルと外部メモリとの相互作用に関する重要な情報が得られます。メモリ プロファイルのいずれかにカーソルを合わせると、グローバル メモリ バンド幅、ストア数、カーネルがデータ不足に陥る頻度、占有率、カーネルがデータを処理している時間の割合、アイドル時間（カーネルが何もしていない時間の割合）に関する情報が表示されます。

これらのレポートから、どのメモリーアクセスにさらなる注意が必要かを素早く特定することができる。

ここでのアプローチは、このアルゴリズムに有効な多くの実装のひとつである。これが、最近のFPGA開発においてハイレベル・ツールが非常に重要である理由だと私は考えている。

インテルのoneAPI設計フローでは、さまざまな設計を迅速に試すことができるため、ソフトウェア・エンジニアは、FPGAにコードをオフロードした場合のパフォーマンスへの影響を迅速に評価することができます。

(マーカス)

さてと。リチャード、oneAPIのデモをありがとう。Q＆Aの準備をしているマーカスです。

BittWare 、HBM2搭載の520N-MXのようなカードでoneAPIをサポートできることを嬉しく思います。先ほどリチャードがお見せした2D FFTのデモについて、より詳しい情報をお知りになりたい方は、BittWare のウェブサイトにホワイトペーパーがありますので、そちらをリソースセクションでご覧ください。

ホワイトペーパーには、このデモのソースコードを入手するためのリクエストフォームもある。

ご質問のある方は、すでに何件か質問が来ていますが、パネリストに質問がある方は、質問アイコンかテキストパネルがあるはずですので、そこに質問を入力してください。パネリストが音声で返答します。

では、ここで質疑応答の画面に移ります。よろしいですね。クレイグ、私の質疑応答画面を見て、私の...を聞くことができますか？

(クレイグ)

できるさ。

(マーカス)

わかった。では、最初の質問です。