10月19日より、今年もオンラインの形で「Arm Dev Summit」が始まったが、その初日にArmはCortex-M向けに3つの発表を行った。この内容を簡単にご紹介したい。

今回発表になったのは、

  • Arm Total Solutions for IoT:Arm Corestoneと後述するArm Virtual Hardware Targetを核とした、Cortex-Mベースのシステム開発のトータルパッケージ
  • Arm Virtual Hardware Target:実IPを利用して、クラウド上でソフトウェア開発やシステム検証が行える仮想環境
  • Project Centauri:要するにProject CassiniのCortex-M版

の3つである。

ちょっと順序が変わるが、まずArm Virtual Hardware Targetから紹介したい。

最終設計と同じIPを稼働できる仮想環境「Virtual Hardware Target」

SoC開発にあたり、ある程度はシミュレータなりエミュレータなりでカバーできるとしても、本格的なシステム開発を行うためにはターゲットとなるハードウェアが無いと難しい、というのは多分システム開発を手掛けた(or巻き込まれた)人ならお分かりかと思う。

このため、昔だとSoCの設計がある程度進んだ段階で、FPGAがてんこ盛りになったプロトタイプボードにSoCを載せ、周辺回路の検証や、そのプロトタイプボードを使ってのシステム開発などを行ったりしていた訳だが、プロトタイプボードでは複数のFPGAにシステムを分割する関係で最終的な設計と必ずしも内部が一致しない問題であったり、動作タイミングが異なるとか、これはこれで色々と課題があった。

Armが今回提供するのは、最終設計と同じIPをそのまま仮想的に稼働させられるVirtual Hardware Targetである(Photo01)。

  • Arm

    Photo01:RTLベースのIPをそのまま稼働させられるという話なので、例えばユーザーが開発したIPなどもRTLベースで流し込みできるような気もするが、このあたりは確認していない

少なくともArmから提供されるIPは、そのままこのVirtual Hardware Target上でそのまま稼働させることが可能である。しかもこのVirtual Hardware TargetはAmazon EC2上で稼働するので、従来よりも早くソフトウェア開発に取り掛かることが出来る。

もちろんSoCにおいても、いわば回路エミュレーションを実施することが出来る訳で、例えば周辺回路との通信の検証などを早期から実施できることになる。これにより、従来の開発スタイル(Photo02)と比較して2年程度開発期間を短縮できる(Photo03)、というのがArmの説明である。

  • Arm

    Photo02:従来の開発スタイル。Silicon PartnerがまずSoCを開発。これをODMが開発ボードに仕立てると共にBSP(Board Support Package)を開発。これを利用してOEMベンダーが最終製品を作るという流れだ

  • Arm

    Photo03:Virtual Hardware Targetを利用した場合、IP選択が終わった段階ですでにOEMはシステム開発に取り掛かれることになる。またSilicon PartnerがSoCデザインに掛かっている段階でODMもボードデザインをスタートできるため、トータルとして2年程度短縮できる可能性がある、という話である

開発期間の短縮は、そのまま早期のコスト回収にも繋がる訳で、これもメーカーにとってはうれしい話となる。

ちなみにこのVirtual Hardware Targetの利用料は無料となっている。もちろんAmazon EC2上で稼働させるとEC2の利用料は掛かることになるが、必ずしもEC2でなくオンプレミスのサーバ上でも稼働させられるという話であった。

実を言えばこうしたVirtual Platformは必ずしもArmが初めて提供という訳でなく、例えばImperasはだいぶ前からVirtual Platformを提供している。2017年にはOVP(Open Virtual Platform)を提供しており、当時でも50種類を超えるArmのProcessor IPに対応していた。

ただImperasのソリューションは(一部無償のものもあるが)基本的には有償であり、またArmのIPをそのまま流し込んで使うという訳にはいかなかった。ところが今回の場合、例えばAFA(Arm Flexible Access)の契約を結んでいるユーザーの場合、AFAのサイトから周辺IPを含めてダウンロードし、そのままこのVirtual Hardware Targetに周辺IPごと登録してしまえば、それだけで仮想的にSoCが稼働するという、恐ろしく手間が削減できる仕様になっている。

もちろんここで動くと言っても実際には物理設計などが絡んでくるから、どこのファウンドリのどのプロセスを使うか、で性能が一致しない可能性などは常にあるのだが、それを踏まえてもまだ、今回のVirtual Hardware Targetの提供がCortex-Mベースのシステム開発の期間とコスト削減に繋がる可能性が大きい事は間違いない。

特定ニーズの開発を効率化する「Total Solutions for IoT」

このVirtual Hardware Targetと組み合わせる事で効果的なソリューションとなっているものが、「Arm Total Solutions for IoT」である。もともとCortex-Mに関しては、POP IPが提供されていない(あるのかもしれないが少なくとも筆者はこれまで公式にアナウンスされたものは聞いたことが無い)。その代わりに、特定のプロセスに向けたPhysical IPのライブラリやCorstoneが提供されている(Photo04)。

  • Arm

    Photo04:要するに差別化要因にはならないけれど、無いと困るものは全部まとめてArmから提供する、という形だ

Corstoneはこちらなどにもあるが、CPUやNPUだけでなく周辺IPまで統合した形で提供される、いわばシステムIPである。

2018年に提供開始されてから結構広く利用されているわけだが、Corstoneは言わば汎用向けというか、MCUをベースとしたSoC向けのファンダメンタルであり、そのSoCがどういう用途に向けたものか、までは踏み込んだ形ではなかった。

今回Total Solutions for IoTではここから一歩踏み込んだ形での提供となる(Photo05)。

  • Arm

    Photo05:ユースケースに応じた構成を、Corstoneをベースに提供する、という形になる

現時点ではまずキーワード認識向けにCorstone-300をベースとしたものが提供されるが、今後はPhoto06の様に様々な構成が提供されてゆく形だ。そしてそのすべてが、Virtual Hardware Targetで動作する事になる。ちなみにCorstoneもAFA経由でも提供されてゆくという話であった。

  • Arm

    Photo06:当然ながらOlympusとかZaphodといった将来のProcessor IPやPolaris/Kochabなどの将来のCorstoneの詳細は、今回は説明されないままである

ソフトウェアに関するエコシステム「Project Centauri」

このTotal Solutions for IoTを支えるもう1つの要素が、「Project Centauri」である。先に「Project CassiniのCortex-M版」という言い方で説明したが、Project CassiniそのものはServer(つまりNeoverse)向けに、SystemReadyなどと併せてソリューションを提供するためのイニシアチブである。

多分このスライドが一番判りやすいと思うが、NeoverseをベースにServerを提供するにあたり、ハードウェアやファームウェアはSystemReadyを、セキュリティ周りはPARSECを、そしてその上で動くソフトウェアについてはCloud Native Stackをそれぞれ利用する事で、開発期間を短く抑えながら高品質なシステムを結果的に低開発コストで実現できる、という取り組みである。

Project Centauri(Photo07)は同様に、ハードウェアはCoestone+Open-CMSIS Packで、セキュリティはPSA CertifiedやTF-M(Trusted Firmware-M)で提供するとともに、同様にソフトウェアに関してエコシステムから提供を促すことで迅速にソリューションを構築できるようにする、というものだ。

  • Arm

    Photo07:Open-CMSIS-PackはArmとNXP/STMicroによる共同開発のCMSIS対応ファームウェアである

この場合、エコシステムの協力が必要な訳だが、これに関しては現在こんなパートナー企業が名乗りを上げている(Photo08)。

  • Arm

    Photo08:これ全部がソフトウェアパートナーという訳ではないが(sondrelはSoC構築ソリューションベンダーである)、これらのメーカーから今後Project Centauriに対応する形でソリューションが提供されてゆく予定だ

なんというか、ArmによるMCU向けの囲い込み戦略の第2弾といった感じであるが(第1弾はAFA)、気になるのはVirtual Hardware Targetのサポートする範囲である。Total Solutions for IoTというかProject Centauriの基本的な発想は、SystemReadyやProject Cassiniと同じく「差別化要因にならない部分はArmからまとめて提供するので、SIPは差別化要因の設計や実装に専念できる」というものだが、その差別化に繋がるハードウェア部分に関してまでVirtual Hardware Targetが利用できるのかどうか、現時点でははっきりしない。

またCortex-A向けと異なり、Cortex-M向けは製造のターゲットがかなり広い範囲(130nm～22nmあたりまでで、しかもファウンドリもかなり多い。自社Fabで製造するメーカーも当然ある)にバラつくとみられる訳で、これがどこまでカバーできるのか、もはっきりしない。このあたりの詳細が出てきたら、また改めてレポートしたいと思う。