「SystemReady」でx86を全方位追撃するArm、高性能組み込み機器向けもカバーArm最新動向報告(12)(1/3 ページ)

Armが開催した年次イベント「Arm DevSummit 2020」の発表内容をピックアップする形で同社の最新動向について報告する本連載。今回は、「Cortex-A」ベースマシンのPC化を目指す「Project Cassini」と、それを具体化した「SystemReady」について紹介する。

» 2021年01月12日 11時00分 公開
[大原雄介MONOist]

 Armが開催した年次イベント「Arm DevSummit 2020」の発表内容をピックアップする形で同社の最新動向について報告する本連載。今回は、前回の冒頭で少し触れた「Project Cassini」と、これに基づく「SystemReady」の話をご紹介したい。

⇒連載「Arm最新動向報告」バックナンバー

「Project Cassini」が目指すCortex-AベースマシンのPC化

 Project Cassiniそのものは2019年開催の「Arm TechCon 2019」で発表された(図1)。

図1 図1 「Project Cassini」は、「Arm TechCon 2019」2日目のDrew Henry氏(SVP&GM of Infrastructure)の基調講演の中で言及された。が、Henry氏の説明は実質このスライド1枚(クリックで拡大)

 内容というか目的はもうこの図1の中に集約されているわけだが、ArmのBlueprintでの説明によれば「『AI Edge(エッジAI)』を活用するアプリケーション導入を成功させるためには、性能と消費電力の要件を幅広くカバーする、さまざまなソリューションを提供することがカギとなる。1つのベンダーのソリューションだけでこれを賄うのは不可能であり、またAI EdgeではAIを軸にしていることは当然として、クラウドネイティブであり、仮想化(VM化ないしコンテナ化)に対応、マルチテナントをサポートすることも必要とされる。当然ながらセキュアである必要もある」と説明している。

 言いたいことはごもっともなのだが、Armとしてはこうした要件をベンダー(つまり同社のIPなりライセンスなりを購入してチップを製造するメーカー)に任せておけないと考えたようだ。任せておけない、というよりも、相互運用性やそれぞれの品質、ソフトウェアサポートなどを考えた場合、Armが音頭をとって標準的なプラットフォームを立ち上げ、これをベンダーが利用してチップを作って提供する、というスタイルが適切と考えたようだ。かくして2019年にProject Cassiniという名称でこの標準化作業が開始された格好だ。

 その成果として2020年に発表されたのが「Arm SystemReady(以下、SystemReady)」である。ただ一足飛びにSystemReadyに行く前に、まずはProject Cassiniについてもう少し説明しておく必要があるだろう。

 Project Cassiniの範囲は、もともとAI Edgeという抽象的な表現であったが、現在はエッジデバイス(これも表現が微妙だが、端的に言えば「Cortex-A」を搭載するデバイスならOKという話になっている)からクラウドサービスまでが対応範囲となっている(図2)。

図2 図2 「Project Cassini」や「SystemReady」が対応する下限という意味では、Raspberry Piクラス(実は「Raspberry Pi 4 Model B」はSystemReadyに対応している)から上であり、「Cortex-M」デバイスに関しては対象外である(クリックで拡大)

 こうした幅広いデバイスに対して、セキュリティに配慮しつつ広範なAPIを提供し、これらを利用するソフトウェアエコシステムを構築することで、ODM/OEM/エンドユーザーにメリットが出る形での環境を提供するのが、Project Cassiniの目的だとしている(図3)。

図3 図3 “but allow for & celebrate hardware diviersity”という一文がなかなか興味深い。ガチガチに仕様を固めてしまえば実装は(相対的に)楽になるが、そうした柔軟性に欠けるアプローチは取らない、としていることになるからだ(クリックで拡大)

 これをもう少し分かりやすく言えば「Cortex-AベースのマシンのPC化」ということである。PCは、ご存じのようにAMDとIntelが争ってプロセッサを提供し、グラフィックスもAMDとNVIDIA、最近はここにIntelも加わり、三つどもえの争いになりつつある。ストレージだって複数ベンダーが提供しているし、メモリも同様だ。OSはWindowsが支配的ではあるが、Linux系ディストリビューションも幾つか存在する。

 にもかかわらず、ソフトウェア開発者からすれば(高度な最適化をする場合はともかくとして、ちゃんと動けばよいというだけなら)プログラムの開発は難しくないし、ユーザーもAMDかIntelかということを意識しなくても利用できる。これは核になる部分の標準化(例えばUEFIやACPIに準拠していればOSがブートできる)がきちんと済んでいるからであり、Armはこうしたことを目指している、と考えればよい。

 このProject Cassiniを構築する3つの柱が、SystemReadyとPSA/PARSEC、それとソフトウェアエコシステムである(図4)。

図4 図4 「SystemReady」はあくまでもハードウェアとファームウェアの仕様を定めたものである。もっとも、その中にセキュリティ要件も当然含まれるのでPSA/PARSECときれいに切り離せるわけではないのだが(クリックで拡大)

 ここで言うPARSECというのは(クラウドゲームのPARSEC ではなく)、Platform AbstRaction for SECurityの略である。こちらに関しては次回もう少し詳細な説明をするので今回は割愛するとして、このProject Cassiniに対応した(つまりSystemReadyに対応したハードウェアで、PSA/PARSECに対応したセキュリティ要件を満たす)ソフトウェアエコシステムパートナーもこの1年で急激に増えた(図5)。

図5 図5 2020年12月末にサポート終了が発表された「CentOS」までシレっと入っている辺りが何とも。「CentOS Stream」でもサポートされるのだろうか?(クリックで拡大)

 これによって、シリコンパートナー(半導体メーカー)やODM/OEM、ISV/OSV、システムインテグレーター、そしてエンドユーザーまで全てが幸せになれる、というのがProject CassiniのメリットだとArmは主張する(図6)。

図6 図6 現状のArmというか「Cortex-A」のシステムは、Androidベースではこれがほぼ実現されているが、逆に言えばAndroidが前提になるわけで、もっと汎用的に、というのがこの目的ということになる(クリックで拡大)
       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.