ゼファーネットのロゴ

生成的データ インテリジェンス

AI

すべてではない: ヘテロジニアス マルチプロセッサ設計ツール

プラトン再発行
プラトン再発行

日付：

閲覧数： 128

マルチコアの異種システムの設計、実装、プログラミングはより一般的になってきており、多くの場合ソフトウェア ワークロードによって推進されますが、プロセッサ、相互接続、およびメモリの最適化に役立つツールはバラバラです。

過去数年間にわたって、特定のソフトウェア セットに最適化された単一プロセッサの定義と実装を支援するツールが数多く登場しました。 Cadence や Synopsys などの企業は何十年もの間、独自のアーキテクチャ用の社内ツールを持っていましたが、RISC-V はそのようなツールのための新しいオープンな市場を生み出しました。 利用可能なオプションが幅広く、それらをサポートするために必要なエコシステムがあるため、導入率は急速に高まっています。

しかし、設計に複数のプロセッサーまたは異種コンピューティング環境が含まれるとすぐに、ツールは利用できなくなります。 メモリ サブシステムや通信ネットワークを考慮しながらソフトウェアを分割したり、プロセッサを最適化したりするのに役立つツールは不足しています。 システム内のデータフローを分析できるツールにもギャップがあります。 これらのタスクの一部を実行できるツールはいくつかありますが、すべてを実行できるツールはなく、複数のツールを組み合わせてタスクを実行するフローもありません。

マルチコアが登場するとすぐに、多くの疑問が生じます。 「RISC-V マルチコアの熱狂が起こっています」と、マーケティング担当副社長の Frank Schirmeister 氏は述べています。 アルテリスIP。 「通常、同様の方法で拡張します。 複数のクラスターがある可能性があります。 クラスター内には複数のコンピューティング ユニットがあり、コンピューティングとトランスポートを共同最適化する場合があります。 アプリケーション アクセラレータをクラスターに関連付けるか、各コアに接続するかを決定できます。 各プロセッサは、Codasip の CodAL や Synopsys の LISATek/NML などを使用して、高度に最適化されたアプリケーション固有命令プロセッサ (ASIP) にすることができます。 高位合成を使用してアプリケーション アクセラレータを構築できます。」

不足しているもの
フローの一部の基本的な部分は単純に存在しません。また、その他の部分は必要なほどシームレスに連携しません。 しかし、ある程度の進歩は見られます。

「設計方法論にギャップがある場合、常に自動化が進んでいない従来の RTL 設計アプローチが使用される可能性があります」と、CTO の Zdeněk Přikryl 氏は述べています。 コダシップ。 「プロセッサ設計自動化ツールがさらに発展するにつれて、ギャップが埋められ、完全なハードウェア/ソフトウェアの共同設計手法が出現することが期待できます。」

流れには大きなギャップが残ります。 「同種マルチコアの場合でも、自動並列化ツールに勝るものはありません。異種マルチコア システムの場合はなおさらです」と、仮想プロトタイピング担当主任エンジニアの Tim Kogel 氏は述べています。 シノプシス。 「人々は適切なデータモデルを見つけるのに苦労しています。 NVIDIA は CUDA フランチャイズに巨額の投資を行っており、これに対処するためにあらゆる種類のプログラミング モデルを開発しています。 まだやらなければならないことがたくさんあります。 今日私が見たのは、さまざまなサブシステムに対して個別のツール チェーンがあるということです。 たとえば、ニューラル ネットワーク用の機械学習コンパイラ ツール チェーンと、CPU 用の従来のコンパイラ ツール チェーンがあり、それらをつなぎ合わせるのは少し手間がかかります。」

制限が設けられると、解決策が得られる可能性が高くなります。 「アクセラレータをプロセッサに緊密に統合できる RISC-V の機能は、Linux でサポートする必要がある異種混合の範囲を減らすため、大きな利点です」と Bluespec の CEO、Charlie Hauck は述べています。 「アクセラレータによって実装される異質性の範囲を制限することなく、これを行うことができます。 これにより、異種マルチプロセッシング環境でドメイン固有のプロセッサをサポートするために必要なツール変更の範囲が最小限に抑えられます。 これには、実装と検証に移る前に仕様を洗練するための高速アーキテクチャ探索のためのサイクル近似システムレベルの C/SystemC モデリングが含まれます。」

ソフトウェア主導型にするためには、そこから始めてハードウェアに至るまで作業を進める必要があります。 「モデルベースのシステム エンジニアリングでは、ソフトウェア、ハードウェア、物理といった複数の領域にまたがる全体的な機能から始めています」と、同社の設計検証テクノロジー戦略ディレクターのニール・ハンド氏は述べています。 Siemens Digital Industries Software。 「彼らは取り組みを開始するにつれて、ハードウェアとソフトウェアの分割、つまり各プロセッサに何が組み込まれているかに注目しています。 そして一般に、彼らは最も効率的な方法でジョブを実行するプロセッサを使用したいと考えています。 単一のモノリシック プロセッサ上でアルゴリズムを実行できれば、おそらくそうするでしょう。 要件を満たしていない場合は、それを剥がして、どの機能に独自の組み込みコアまたは独自のアクセラレータがあるかを決定する方法が必要です。」

しかし、何らかの形式のネットワークを間に置くとすぐに、通信のオーバーヘッドを分析する必要があります。 「フローには機能するサブセットがあります」と Arteris の Schirmeister 氏は言います。 「たとえば、私たちのツールスイートでは、NoC 自体の分析に役立つモデルを吐き出します。 イニシエータが 10 個、ターゲットが 15 個ある場合、必要なスイッチの数がわかります。 これらが私の優先事項です。 アーキテクチャ分析を行ってから、コンテキストの中でそれを理解します。 次に、それを Platform Architect などにエクスポートします。 これらの関係は確立されていますが、より大きな問題は、それらが切り離されていることです。 たとえ技術的なフローがあったとしても、アーキテクチャのフィードバックに基づいてこれらすべての分析を最適化するために効率的に対話する個人またはチームの能力は非常に分散されています。」

そして、彼らは常に正しい質問をしているとは限りません。 シーメンスのカタパルト HLS チームのプログラム ディレクターであるラッセル・クライン氏は、「ネットワークオンチップ企業の製品を見ると、彼らは依然として世界をあらゆるタスクを実行できるようにしたいシステムとして見ています」と述べています。 「彼らは、移動する必要があるデータ、待ち時間、必要な帯域幅を調べます。 しかし、彼らはこのメモリを「この計算領域のここ」に配置する可能性を考慮していません。 そうすれば、データを移動したり、相互接続を使用したりする必要はなくなります。 データのグループを必要な場所に隔離し、それらをコンピューティング要素でグループ化すると、通信を最小限に抑えることができます。 インメモリコンピューティングについてはどうですか? 相互接続を検討するときは、こうした種類のことを考慮する必要があります。 インターコネクトから外すことができ、そもそも移動する必要さえないのは次のうちどれですか? その問題を理解し、解決策を提案できるツールが私たちにはないと思います。」

さらに多くのことが必要です。 「探索、分割、および共同設計機能のクラスが存在しており、今日では強引に突破することができます」とシーメンスのハンド氏は言います。 「しかし、それ以上に必要なものがある。 「目標は達成できましたか?」という質問に答えるのに役立つ機能がたくさんあります。 しかし、トップダウン フローの課題の XNUMX つは、測定と推定を行うことができる必要があり、そのためにはモデルが必要であり、パフォーマンス情報が必要であり、システムのオーバーヘッドを理解するためのソフトウェアが必要であることです。システムのトレードオフ。 それは解決するのが本当に難しい問題です。 NoC がある場合、共有メモリがある場合、または共有メモリがない場合、これらは全体的なパフォーマンスに大きな影響を与えます。 そして、残念ながら、それをソフトウェア コンテナ内で抽象化することはできません。」

ソフトウェアの準備状況
利用可能なハードウェアへのソフトウェアの最適なマッピングを見つけたり、ソフトウェアに最も適切なハードウェア アーキテクチャを定義したりするには、広範な分析機能が必要です。

「派手なハードウェア機能を備えた複雑なチップがある場合、ソフトウェア開発者はそれをどのように利用するのでしょうか? そこに最大の課題があるのです」とシノプシスのコーゲル氏は言う。 「多くの人が AI 用のハードウェアを開発していますが、戦場は ML コンパイラーです。 美しいアクセラレータ ハードウェアを設計することはできますが、コンパイラがそれを効率的に利用できない場合、そのハードウェアは使用されない可能性が高くなります。 それは解決すべき大きな問題だ。」

現在、それらの環境は分散されています。 「その分析を可能にするソフトウェア環境を持つことは貴重です」と、Tensilica Xtensa プロセッサ IP の製品マーケティング グループ ディレクターである George Wall 氏は述べています。 ケイデンス。 「しかし、それはおそらく複数のソフトウェア環境です。 おそらく、プロセッサ ベンダーの開発ツールを使用して SystemC モデルを搭載した ISS など、非常にプロセッサ中心の環境を検討することができるでしょう。 そしておそらく、仮想プラットフォームにはより高いレベルの部分があるでしょう。」

RISC-V でさえ、完全な自由が利用される場合、ソフトウェア エコシステムを維持するのに苦労しています。 「ソフトウェアの複雑さを制御するには、命令セットのバリアントを標準化する必要があります」とコーゲル氏は言います。 「整数と浮動小数点、および命令の各セットには、一般的なインフラストラクチャの利点を活用するために使用する必要がある事前定義されたセットがあります。 したがって、完全にオープンにする代わりに、標準プロファイルが定義されます。 しかし、それらを使用しないことを選択した場合、それはあなた自身の責任です。」

プロファイルはハードウェアを制限して、ソフトウェア エコシステムを簡素化します。 「RISC-V ソフトウェア エコシステムはその準備を進めています」と Codasip の Přikryl 氏は言います。 「私たちはプロファイルとプラットフォームに特化したさまざまなグループを持っており、ベースラインとして何が期待されるのか、そしてドメイン固有の機能がどのように使用されるのかをうまくまとめています。 これを導入すれば、ソフトウェア スタックのさまざまな部分をどのように処理すべきかが明確になるため、ソフトウェア エコシステムは順調に成長することができます。」

異質性が関与すると、物事はより明確になりません。 「異種システムにハイパーバイザーを配置する人が増えています」と、シーメンスの組み込みソフトウェアの製品管理責任者、ジェフ・ハンコックは言います。 「確かに、アプリケーション コアではシングル スレッドと考えることができますが、自動車では、たとえばハイパーバイザーやクアッド A53 などで Linux や Android Auto を実行しています。 そして、同じチップ上に Autostar を実行している R コアがあります。 したがって、複数のコアをすべて備えた単一の SoC 上でも、実際には異種タイプの環境を実行していることになります。」

ドメイン固有のソリューションが作成されています。 「自動車分野では、Arm の SOAFEE イニシアチブが見られます」とコーゲル氏は言います。 「これは、クラウド ネイティブ開発からデプロイメントまでシームレスに行える方法でソフトウェア開発を形式化し、Docker と仮想化で物事をカプセル化しようとする試みです。 このレベルで何かを生み出すには、このような複数の企業による取り組みが必要です。」

しかし、ソフトウェアは変わらなければなりません。 「ラップトップに XNUMX 個の Intel コアが搭載されていても、携帯電話に XNUMX 個のコアが搭載されていても、プログラミング モデルはシングル スレッド アプリケーションです」とシーメンスのクライン氏は述べています。 「そしてそれが制限要因です。 ソフトウェア担当者が単一のコアでプログラムすることを要求し、プロセッサ上にあるのは私たちだけであるという幻想を要求する限り、それを乗り越えられるまで、私たちは努力し続ける必要があるでしょう。より大きなプロセッサを構築し、そのモデル内で処理を高速化します。 そのモデルを破るとすぐに、あらゆる種類の本当に素晴らしいことが起こります。 しかし、それはハードウェア技術の問題ではありません。 それはソフトウェア、文化の問題です。」

単一のスレッドを複数のコアに分割する試みが行われてきました。 「これらのシステムを構築するアーキテクトは、物事をどのように分解して並行して実行できるかを考え出しています」と、創設者兼 CEO の Simon Davidmann 氏は言います。 Imperasソフトウェア。 「アプリケーションは C の XNUMX つのスレッドではありません。それは何かを行うのが非常に難しいからです。 C コードの並列化に魔法はありません。」

任意のソフトウェアを取得して、それを任意のハードウェアにターゲットにできることは、聖杯です。 データ フロー モデルを導出できるのはその XNUMX ステップにすぎませんが、これは一般的なケースでは解決するのが非常に難しい問題です。

「もともとより適切なデータ モデルがあるため、ML フレームワークでは機能します」とコーゲル氏は言います。 「TensorFlow には、C や C++ コードの任意の部分よりもはるかに優れた方法で定義された固有の並列処理とデータ依存関係があります。 現在、人々はトレースを使用し、仮想プラットフォームまたはターゲット ハードウェア上で実行されているアプリケーションからこれらの依存関係を再設計して、実際の依存関係を抽出しようとしていることがわかります。 静的または動的コード分析に基づいてこれを自動的に行うのは難しい問題です。 私たちはこの方向の試みを見てきましたが、これはまだ研究課題です。 それが解決できれば大きな利益が得られるでしょう。」

問題は常にデータの依存関係でした。 「ニューラル ネットワークの特徴の XNUMX つは、ニューラル ネットワークが規則的な構造を持ち、恥ずかしいほど並列しているということです」とクライン氏は言います。 「そこには非常に多くの並列処理があるため、データの依存関係を導入することなく、さまざまなアクセラレータで何を分割できるかを理解することがはるかに簡単になります。 私たちが汎用ソフトウェア、一般化されたアルゴリズムに移行している今でも、これはまだ誰も解いていない難題です。 誰かが書いた C プログラムを、コンピューター上でそのプログラムだけがシングルスレッド アプリケーションになると錯覚しながら、どうやってそれを複数の小さな CPU に移動できるのでしょうか? それはまだ本当に難しい問題です。 そして繰り返しになりますが、ソフトウェア コミュニティはそこに移行することによる潜在的なメリットを受け入れていないようです。」

この問題はすべてのアプリケーション分野に存在します。 「AI/ML 内のほとんどの設計チームと IP ベンダーは、ルール XNUMX、つまりワークロードに見合った処理能力を提供することに重点を置いています」と、同社の最高マーケティング責任者の Steve Roddy 氏は述べています。 二次。 「しかし、彼らはルール XNUMX 番目、つまりアプリケーション ソフトウェア開発者に負担をかけないことを無視しています。 ほとんどの ML ソリューションは、グラフ処理の一部を従来の CPU または DSP からオフロードしていますが、ML グラフのワークロード全体をオフロードしているわけではありません。 これにより、ソフトウェア開発者の生活はさらに複雑になります。」

変化は難しい。 「私たちはそこに到達したいと思っています」とケイデンスの壁は言います。 「ソフトウェア開発環境をアーキテクチャから完全に切り離すことは、非常に困難な問題です。 たとえ OpenMP のようなものを利用したとしても、常にある程度のアーキテクチャ上の依存関係が存在することになります。」

テーブルの上にはたくさんのものが残っています。 「パフォーマンスと効率、そしてハードウェアを設計し、それを壁の向こう側に放り投げたり、別の会社に売ってソフトウェアを書いたりするときに、システムの全体的な能力の点で何を残すかは非常に大きいです。」とクライン氏は言う。 「能力、効率、パフォーマンスの大幅な損失が発生します。 必要な人材が座って、ハードウェア上で実行されるソフトウェアのアーキテクチャを考えながらハードウェアを設計している組織を私はほとんど知りません。 彼らがほぼ常に焦点を当てているのは、シングルスレッド アプリケーションを実行するハードウェアを設計し、それをその型に適合させようとすることです。 それが崩れ始めているのかもしれない。」

それにはチームが必要です。 「問題を理解するにはチームの努力が必要です」とシルマイスター氏は言います。 「これには何人かのアーキテクトが必要で、信じられないほど複雑な作業です。 同時に、システムの複雑さは急速に増大しています。 これが実際に機能するためにツールが十分に接続される時代が近づいています。 ツールを縦につなげて、ある程度の流れはできています。 アーキテクチャ最適化ツールがいくつかあります。 もちろん、すべてを実行できる人材はいません。これは教育の問題です。 しかし、それを機械学習や AI と組み合わせれば、有意義なバリエーションを経るサイクルに余裕があれば、チャンスはあります。」

まとめ
過去 25 年間、人々はハードウェアとソフトウェアを包括できるシステムレベルのツールの可能性に注目してきました。 両方を最適化し、一方を他方にマッピングできることには明らかな利点がありますが、ソフトウェアの生産性の問題を克服するには決して十分ではありませんでした。 より早く市場に投入することは、より高速に動作する製品、より少ない電力消費、またはより安価な製品よりも重要です。 業界の多くの人は変化は避けられないと考えていますが、彼らは長い間間違っていました。

スポット画像

最新のインテリジェンス

スポット画像

著作権 @ 2024 Plato Technologies Inc.