ところで先ほど受け渡しのコードが自動生成される、という話があったが、実際にはCPUとFPGA Fabricの間には複数のI/Fと複数の受け渡し方法があり、どういう組み合わせを取るかで帯域やLatencyが変わってくる。Photo10は実際にその組み合わせによってLatencyがどう変化するか、を示したものである。既存のZynq-7000の場合、General-Purpose Port、High-Performance Port、ACPという3種類のI/OがCPUとFPGA Fabricの間に用意されており、しかもこれをCPU側で扱う方法が5種類も存在するから、「どれを選べば良いか」の判断は難しい。だからといって、いちいちベンチマークをやっているといつまでたっても設計が終わらないので、これまでは勘と経験で決めていたが、SDSoCではこれを自動的に選択し、必要ならパフォーマンスプロファイルも取得して最適な方法を選んでくれるとしている。

Photo10:一番遅いのはGeneral-puroise Portsピン経由でFIFOを使った受け渡しをする方法で、一番高速なのがHP(High-performance Port)経由で単純なDMAを使う方法となる。性能差はここだけで16倍にも達しており、適切な受け渡し方法を選択することが重要であるとわかる

もちろん、どんなロジックでも簡単にFPGAに移植できるとは限らない。特に数値演算に関しては、DSPを生のまま使うと固定小数点演算になってしまい、一方CPUでは普通浮動小数点演算だから、これを高速に扱うのは大変に難しい。そこでいくつかの代表的なものに関してはLibraryがXilinxあるいはサードパーティから提供されており、また必要ならユーザーが自分で追加することも出来る(Photo11)。例えばBLASとか線形代数では浮動小数点演算が必須だが、先に書いたとおりXilinxの場合DSPは固定小数点のみである。ではLogic CellだけでFPUユニットを構成するのか? というとそうではなく、DSPにLogic Cellを組み合わせて、単精度/倍精度の浮動小数点を扱えるように拡張したものをライブラリとして用意しており、これを利用することで処理の高速化が図れるのだそうだ。

Photo11:自分でライブラリを追加することも可能である。これは例えば企業の場合、自身の研究所開発したIPを自分のライブラリとして追加するなんて使い方を想定しているそうだ

すでに市販されているZynqに対応した主要な開発プラットフォーム上ではSDSoCが利用可能であり(Photo12)、SDSoCのEarly Accessも開始されているそうだ(Photo13)。

Photo12:既存のZynqの開発プラットフォームはほぼサポートされる模様

Photo13:すでに国内でも数社がアーリーアクセスでSDSoCの試用を開始しているとの事だった

このSDSoC、正式な発売は2015年8月頃を予定しているそうで、価格はまだ未定だが一から全部そろえても数十万のオーダーとの事。基本的にはVivadoの機能をフルに使う形でインプリメントされており、なので価格の大半はVivado代ということになる。逆にすでにVivadoのSystem Editionを導入されている場合には、SDSoCのPlug-inを追加するだけなので、ぐんとお安くなる(数万円のオーダーだとか)という話であった。

ちなみに質疑応答でもう少し面白い話があったので、こちらもご紹介しておく。まずIDEについて。現在のSDSoCはXilinxが提供するIDE上で動く事になるが、既存のZynqなどのユーザーはARM側のプログラミングについてはARMのDS-5など、すでに別の開発環境を利用しているケースが少なくない。こうした他の開発環境とのMigrationについては、将来的には考えているが今の時点でのMigrationは出来ないという話だった。

またFPGAへの処理のオフローディングであるが、これはRTLベースで記述されるもので、例えばSDAccelの様にOpenCLを経由したりはしないとの事。また、特にZynq MPSoCの世代ではCPUとFPGA以外にGPGPUとして使えるGPUも統合されるが、これを使うようなオフローディングの機能は提供しないとの事だった。その理由は? というと「GPUを使うよりもFPGAで実行したほうがより効率的だからだ」(Durdan氏)(Photo14)との事だった。

Photo14:SDAccelそのものが、「GPUを使うよりもFPGAで実行したほうがOpenCLでは性能が高くなるし、その際にSDAccelを使えばプログラミングの難易度がGPU並みに軽減される」というコンセプトの製品であり、それを考えればGPUを使う必要性は無いということか

また開発の生産性に関しては、SDSoCの環境下ではそもそもハードウェアの仕様が決まってくる(デバイスに関しては、あとはZynq/Zynq MPSoCのどれを使うか、という選択のみがあるだけ)から、早期にソフトウェア開発が始められるし、またPhoto08に示すようにConnectivityを自動生成でき、かつその性能のチューニングも容易なので、全体としての開発期間が短縮できるという話があった(Photo15)。ただこれにも増して、そもそもほとんどの現場では自身でFPGAを扱えないから、外部にFPGAを含むボードの開発を依託し、完成したものをベースにS/Wを含むシステム開発を始めるといったケースが少なくなかったが、SDSoCを使えば極端な話としてFPGAを知っている開発者がまったく居ない現場でもFPGAを使える、というメリットがあり、これは大きな生産性の向上に繋がるという説明もあった。

Photo15:ただこの図に関しては、そもそもS/WとH/Wが同時に開発を始められないという問題に対応するために、Virtual PlatformとかEmulationなどが随分充実している昨今では、かならずしもここまでもギャップは無い気がする。ただそうした仮想プラットフォームは相応に高価であり、そうしたものを導入できないような現場ではこの位の差は出るのかもしれない

またSDSoCでは原則としてFPGAの内部は完全に遮蔽される。なので、「この部分はFPGAのSRAMのここに保管したい」とか「このブロックはDSPで処理したい」とかいうものがあっても、それを直接C/C++のコードで記述することはできず、先に書いたライブラリを介して行う必要があり、このためにはRTLのプログラミングが必須である。要するにSDSoCは、FPGAを完全にブラックボックス化するツールであるといえる。

ということで、SDSoCについて簡単にご紹介をした。個人的にどう思うかといえば、XilinxがZynqやZynq MPSoCを拡販してゆく現場においては、非常に有力なツールであろうと思う。これを利用すれば既存のEmbedded Application向けに、汎用CPUと同程度の消費電力枠で、かつ汎用CPUでは実現しえない性能を提供できる可能性が確かに存在する。

その一方で、本当にFPGAを扱えるエンジニアが1人も居ない状態で、新規にZynq+SDSoCを導入する現場がどこまであるか? といわれるとそれはちょっと「?」マークである。なにしろこのところ、特に中華系(台湾・香港・中国)のFabless SoCベンダが恐ろしいほどの低価格で標準的なCortex-A系SoCを提供してくれるから、相対的にZynqやZynq MPSoCは高価格である。それにZynqではLogic Cellの数やI/Oなどは選べるが、CPUコアそのものの数や動作周波数などは決めうちであり、選択肢が豊富とは言いがたい。しかも開発環境は(フルスペックのFPGA開発環境とかに比べれば)かなり安いが、Cortex-A向けの開発環境にはさらに安い(ほとんど無償に近い)ものもあるから、評価ボード代を含む初期コストは無視できるほど安い、というものでもない。もちろん、例えばARMのDS-5なんかもUltimate版だと1ライセンスで数十万だから、これと同等という言い方も出来るのだが。

あと少し気になったのは、MPSoCで開発を行う場合、ソフトウェアエンジニアがVivadoのLicenseを使える状態になっていないといけないが、通常はFPGAデザイナーがVivadoのLicenseを使う形にインストールされているのが普通であり、このあたりライセンスというか運用面でちょっと面倒なことになりそうである。

つまるところ、どこまで性能改善を判りやすく開発者に示すことが出来るか、というあたりが今後の普及の鍵であろう。まずは既存のVivadoを利用している企業で、なにかしらのプロジェクトに採用されるという形で少しずつ利用されてゆく形態になるのではないかと思う。FPGAの使い方としてはかなり贅沢、というかLogic Cellなどの利用効率やデバイスとしての絶対性能の観点から見ればかなり無駄な使い方になる可能性も否めないが、それよりもソフトウェア開発効率の改善を重視した、新しいアプローチといえるだろう。