インテル® oneAPI™
ハイレベルFPGA開発
メニュー
oneAPIはあなたにふさわしいか？
oneAPI™は、特にAltera FPGA上でハードウェア・アクセラレータを開発するための、より高速で簡単な方法として、すでにご存知かもしれません。しかし、すべてのアプリケーションが適しているわけではなく、多くの場合、ベースライン性能を確立するために初期開発が必要になります。
では、何から始めればいいのか？
あなたのアプリケーションはoneAPI™の恩恵を受けられますか？
当社のエンタープライズクラスのアクセラレータカードを使用することは素晴らしい選択です。oneAPIをサポートするカードは以下の通りです。
oneAPIの詳細をお知りになりたいですか？ oneAPIの詳細」セクションにジャンプしてください。
ハードウェアのご購入やご質問はこちらへ。 購入先とお問い合わせのセクションに移動します。
高性能ハイレベルツールの歴史
ハイレベルFPGAツールの提供で数十年の経験を持つ当社は、お客様が当初から必要としているもの、すなわちF-maxのような主要な性能指標をデザイン上で評価するための高速なオンランプを知っています。そのため、当社の標準アクセラレータ・サポート・パッケージ（ASP）は、ハイパフォーマンス・コンピューティング向けに最適化されています。oneAPIをサポートするBittWare アクセラレータ・カードを出発点として選択する主な利点は以下のとおりです：
- F-Maxのような重要業績評価指標を優先的に知る。
- 大きなシリコン・リソースのフットプリントから始めることは避け、カスタマイズによって必要な機能だけを追加する。
- 配備可能なエンタープライズクラスのハードウェアから始めるので、配備を進めても変更する必要はない。
oneAPIを使った2次元FFTのデモ
このソフトウェア指向のツールフローで、より速く開発し、コードを再利用する。
HBM2を搭載した520N-MXカードの2D FFTデモで、oneAPIの利用をご検討ください。ページ下部のコードダウンロードをリクエストしてください！
oneAPI開発用推奨カード
最新のツールをサポートし、ASP(HPC重視)で、高性能Altera FPGAを搭載しているので、oneAPIにはこれらのカードをお勧めします。
他のBittWare 。
Altera Agilex デバイスを搭載した当社のアクセラレータ・カードは、すべてoneAPIサポートの候補です。しかし、推奨カードを選択しないことで、パフォーマンスを評価するためのASPを構築することさえ、重要な開発プロジェクトとなります。
そのため、HPCに最適化されたASPが用意されているこれらのカードから始めることをお勧めします。ボリュームデプロイメントのための他のプラットフォームについては、ご相談に応じます。
近日発売アジレックス™ Mシリーズ
oneAPIアプリケーションにHBM2メモリのパワーが必要ですか？当社のIA-860mは、oneAPI開発用の推奨カードに追加される予定です。準備ができ次第、更新いたしますので、ご連絡ください。
アクセラレータ・サポート・パッケージ（ASP）
oneAPI用語では、ASP（以前はボードサポートパッケージまたはBSPと呼ばれていました）は、SYCLコードとカードのハードウェアを橋渡しする内側のリングです。ASPは、機能を有効にし、oneAPIがチップ上の物理的な位置（フロアプラン）を定義し、特定のアクセラレータの範囲内で性能の可能性を定義する要素です。
ご存知でしたか？
パフォーマンスはASP特有
The Accelerator Support Package (ASP) plays a big role in performance.
ASP（ボード・ベンダー固有の oneAPI 実装）は、oneAPI コードがチップ・レベルとカード・レベルの両方でハードウェア・リソースとどのようにインターフェイスするかを定義します。性能の高低、シリコン・リソースの使用量の多寡、利用可能なI/O機能など、多くの変数があります。
適切なFPGAを選択するのと同様に、ボードベンダーを考慮することも重要です。そのため、BittWare 、高性能なoneAPI ASP開発を基本として、必要な機能のみを追加することに重点を置いています。低性能の（おそらくはより多くの機能を持つ）ASPから始めると、oneAPIが実際にどのように機能するかを覆い隠し、理想的な結果を得られない可能性があります。
BittWare ASP
カスタマイズ設計
顧客は必要に応じてより多くの機能をカスタマイズすることができる。
当社のASPが提供する以上の機能が必要な場合は、有効化可能な追加I/Oを備えたエンタープライズクラスのハードウェアをすでに使用しています。これらのリソースをoneAPIで有効にすることは、お客様のチームで行うこともできますし、より多くのカスタマイズ・オプションについてご相談いただくこともできます。
ASPのカスタマイズが必要ですか？
プロジェクトのニーズに合ったカスタマイズASPのお見積もりやご提案については、お気軽にお問い合わせください。
これらの用語の関係は？
OFS、FIM、AFU、ASP
関連用語OFS、FIM、AFU ASPの連携について
oneAPI、Open FPGA Stack (OFS)、FPGA Interface Manager (FIM)、Accelerator Functional Unit (AFU)などに関連する用語を聞いたことがあるかもしれません。これらはアクセラレータ・サポート・パッケージ（ASP）とどのような関係があるのでしょうか？ボード・サポート・パッケージ (BSP) への参照を目にすることがあるのはなぜですか?
OFSは最上位のコンポーネントですが、1つのAPIでOFSが提供するすべてのものが構成されると考えないことが重要です。そのような実装では、リソース効率が悪く、保守が困難になります。OFSは幅広い機能のライブラリであり、特定のoneAPI実装はそのサブセットを提供するものと考えた方がよいでしょう。
このため、さまざまな「OFS対応」ボードを比較したところで、どのような機能、性能、リソースが実装 されているかについてはあまりわからない。 ASP（以前はBSPと呼ばれていた）がどのように実装されているかをさらに掘り下げる必要がある。
次の "レベルダウン "はFIM（FPGA Interface Manager）で構成される。これは、FPGA自体の機能を含むハードウェア機能とoneAPIソフトウェアとの特定のインターフェイスを定義します。FIMはOFSベースのシェルと考えることができます。RTLプログラミング・リソースがあれば、FIMから機能を追加/削除できます。
FIMの "内部 "で動作するのはAFUで、アクセラレーション を提供する実際のアルゴリズムまたは処理ユニットである。これはユーザー・アプリケーション空間と考えることができ、ソフトウェア・ツールを使って開発するが、ハードウェアのインスタンス化の利点もある。
最後に、ASPはこれらのコンポーネントをまとめます。ハードウェア・インターフェースと、それらがoneAPIコードとどのように相互作用するか、さらに開発用のQuartus のようなホスト・ソフトウェア・ツールです。BSP（ボード・サポート・パッケージ）とoneAPIへの言及が見られますが、これはASPの類似用語です。ASPを考える最良の方法は、FIM（ユーザーアプリケーションのAFUエリアを持つ）をoneAPIのターゲットに変えるコンポーネントとして考えることです。
概要：スタート
次のステップは？開発から配備までの典型的な流れは？
評価
質の高いASPで適切なカードを選ぶ。
oneAPI "と宣伝されているすべてのカードが評価に適しているとは限りません。私たちは、Altera F-Series、I-Series、そして間もなく登場するM-SeriesAgilex FPGAを搭載したカードにASPを実装することにしました。推奨アクセラレーター・ボード・リストをチェックし、何が最適か議論する用意がある。
基本を身につける。
ハードウェアを手にしたら、Altera Quartus デザイン・ソフトウェア（別売）、oneAPI ツールを使用します。BittWare では、アクセラレーター・ボード購入の一部として、デベロッパー・サイトをご案内しています。
開発
oneAPIでより速く開発しよう。
ネイティブRTL開発に慣れている場合、oneAPIはフルコンパイルの実行を削減するため、歓迎すべき改善となるでしょう。テストベンチのエミュレーションとレポートのおかげで、これらのステップは数秒から数分で完了します。フル・コンパイルに移れば、Vtuneを使ってプロジェクトをさらに洗練させることができます。
デプロイ
BittWare 、アクセラレーターから始めた人には朗報だ。
BittWare アクセラレータから始めることで、開発で使用しているのと同じカードでデプロイできます！お客様のニーズに応じて、ボリューム要件についてご相談ください。
oneAPI™についてもっと知る
oneAPIとは？
oneAPIは、業界を超えたオープンな標準ベースの統一プログラミングモデルで、アプリケーションの高速化、生産性の向上、イノベーションの促進を実現するために、アクセラレータアーキテクチャに共通の開発者体験を提供します。oneAPI業界イニシアチブでは、oneAPI仕様とエコシステム全体での互換性のあるoneAPI実装に関するコラボレーションを奨励しています。
図書館
oneAPIは、計算とデータを多用するドメイン向けのライブラリを提供します。ディープラーニング、サイエンティフィックコンピューティング、ビデオ分析、メディア処理などが含まれます。
ハードウェア抽象化レイヤー
仕様
oneAPI仕様は、既存の開発者向けプログラミングモデルを拡張し、多様なハードウェアスルー言語、ライブラリAPIセット、および低レベルのハードウェアインタフェースを可能にし、クロスアーキテクチャプログラミングをサポートします。互換性を促進し、開発者の生産性とイノベーションを可能にするため、oneAPI仕様は業界標準を基に構築され、オープンでクロスプラットフォームな開発者スタックを提供します。
プログラミングの課題
マルチアーキテクチャー対応
今日の HPC 環境では、ワークロードを実行するために、CPU、GPU、FPGA、および特殊なアクセラレータなど、複数のハードウェアアーキテクチャが利用可能です。すべてのワークロードに最適な単一のアーキテクチャはないため、アーキテクチャを組み合わせて使用することで、多くのシナリオで最高のパフォーマンスを発揮することができます。しかし、このようなアーキテクチャの多様性は、いくつかの課題にもつながっています：
それぞれのアーキテクチャには、別々のプログラミングモデルやツールチェインが必要です：
- 必要なトレーニングおよびライセンス - コンパイラ、IDE、デバッガ、分析/監視ツール、デプロイツール - アーキテクチャごと
- クロスアーキテクチャのソースコードのデバッグ、監視、保守に挑戦する。
- 独自のIPやアーキテクチャにまたがる統合が困難で、コードの再利用ができない。
ソフトウェア開発の複雑さは、アーキテクチャの選択の自由を制限する。
- 参入障壁を克服するための技術的専門知識に必要な単発的な投資
oneAPIがお手伝いできること
OneAPIは、多様なアーキテクチャの開発を簡素化する統一プログラミングモデルを提供します。oneAPIプログラミングモデルでは、開発者は同じ言語とライブラリを使って異なるハードウェア・プラットフォームをターゲットにすることができ、同じセットのデバッグおよび性能分析ツールを使って異なるプラットフォーム上でコードを開発し最適化できます。
プラットフォームやハードウェア・アーキテクチャを問わず同じ言語を使用することで、ソースコードの再利用が容易になります。たとえ、異なるハードウェア・アーキテクチャに移行する際にプラットフォーム固有の最適化が必要であっても、コードの翻訳は必要ありません。また、共通の言語とツールセットを使用することで、新しい開発者のトレーニングが早くなり、デバッグが早くなり、生産性が向上します。
- エミュレーションと レポートによるパフォーマンスチューニングとタイミングクロージャー
- VTune™ Profilerによるランタイム解析
- マクロ、プラグマ、ヘッダなど、組み込みの言語機能で実装された複雑なハードウェア・パターン
- アーキテクチャやベンダーを超えたコードの再利用
- 既存の高性能言語と互換性がある
- 使い慣れたシーケンシャルプログラミング言語の活用：立ち上げと デバッグ時間の改善
- IDEの統合：Eclipse、VS、VS Code
データパラレル C++
標準ベースのクロスアーキテクチャ言語
oneAPI言語は、並列プログラミングの生産性を高めるために設計された高水準言語であるData Parallel C++で、幅広い互換性のためにC++言語をベースとしています。DPC++はプロプライエタリな言語ではなく、オープンな業界横断的イニシアチブによって開発が進められています。
CPUやアクセラレータを問わず、妥協のない並列プログラミングの生産性と性能を提供するための言語です：
- 特定のアクセラレータのためのカスタムチューニングを可能にしながら、ハードウェアターゲット間でコードの再利用を可能にします。
- 単一アーキテクチャの独自言語に代わる、オープンな業界横断型言語
C++をベースにしています：
- CおよびC++の一般的で馴染みのあるコンストラクトを使用し、C++の生産性を向上させます。
- Khronos GroupのSYCL*を搭載し、データ並列処理とヘテロジニアスプログラミングをサポートします。
言語拡張を推進するコミュニティプロジェクト
- データ並列プログラミングを簡略化する拡張機能
- 進化し続けるためのオープンな共同開発
oneAPI用FPGA開発フロー
DPC++のコードを、そのコードで指定されたハードウェア・アーキテクチャを実装するタイミングクローズのFPGAデザインに変換するために必要なバックエンドのコンパイル処理には、何時間もかかることがあります。そのため、FPGAの開発フローは、フルコンパイルの実行を最小限に抑えるように調整されています。
- 最初のステップは機能検証で、テストベンチを使ってコードが正しいかどうかをチェックします。これは、開発プラットフォーム上のエミュレーション（FPGAをターゲットにしたコードをCPU上でコンパイル・実行すること）を使って行われます。これにより、バグが発見され、修正する必要がある場合のターンアラウンドタイムを大幅に短縮することができます。そのためには、標準的なCPUデバッガ（Intel® Distribution for GDBなど）を使用することができます。
- 機能検証が完了すると、コンパイラが生成するレポートを通じて静的性能解析が行われます。レポートには、デザインにおけるメモリ、パフォーマンス、データフローのボトルネックを特定するために必要なすべての情報と、ボトルネックを解決するための最適化手法の提案が含まれています。また、ターゲットFPGAにおけるデザインの面積とタイミングの見積もりも提供されます。
- 静的解析の結果が満足のいくものであった場合、フルコンパイルが行われます。コンパイラーは、生成されたハードウェアに要求に応じてプロファイリング・ロジックを挿入できます。プロファイリング・ロジックは、メモリとパイプ・アクセスの動的プロファイリング・データを生成し、後にVtuneパフォーマンス・アナライザーが他の方法では発見できないデータパターン依存のボトルネックを特定するために使用することができます。
価格や詳細についてご興味のある方は、こちらをご覧ください。
当社のテクニカルセールスチームは、在庫状況や構成情報を提供したり、技術的な質問に答えたりする準備ができています。
