2020」がスタートした。TechConからDevSummitへの切り替えは2019年のうちに発表になっていたが、今年はCOVID-19の影響もあり完全オンラインに切り替わっての開催である。SystemReady」(Photo02,03)を取り上げたい。Arm」でもう少し細かい説明が出てきた(Photo04)。Photo04:SystemReadyで定義される6種類のCertification。上の4つは排他(どれか1つ)だが、下の2つはオプションである。Processing」というセッションの方が判りやすかった(Photo05)ので、こちらの資料を基にちょっと説明したい。10なりLinuxのディストリビューション各種なりをインストールできるし、なんならサーバー向けOSでもインストールできる。これはOSのインストーラがそれぞれの構成にあわせて最適なものを自動でインストールする......訳ではなく、要するにx86であればUEFIだったりACPIだったりといった、ハードウェアの差異を吸収して同一のAPIでハードウェアにアクセスするための仕組みが整っており、なのでOSはUEFIなりACPIにアクセスするという形でインプリメントされているから問題が起きないという話なだけである。ところがArmの場合、こうした共通のAPI層にあたるものが存在しない。これがCortex-MだとCMSISがあって、これである程度の互換性は保てている(ミドルウェアとかRTOSの動作にはCMSISがあれば十分)訳だが、Cortex-Aにはこれにあたるものが存在しない。Architecture)が発表され、これを利用することでいくつかのOSが比較的スムーズに移植作業が行われる様になったとはいえ、まだx86の域には遠い。これをもっと改善して、本当に移植作業無しでOSとかミドルウェアが動くような環境を整えよう、というのが今回のSystemReadyとなる。SystemReadyはPhoto06の様に6種類からなる。Device、etc......)を定めている。これに追補の形で提供されるのが先ほども話が出てきたSBSAで、これはサーバー向けの拡張仕様という扱いだ。Photo06:SBSAも引き続き使われる、というかSystemReadyの要素の1つになった。recipeにESBBRが無いのがなぞ。Requirements)で、この中でACPIとかUEFIといった、システムのブートに必要な要素を定義している。このBBRには「recipe」という、用途に応じた要件分けが行われており、要件に応じてSBBR/ESBBR/EBBR/LBBRの4種類が定められている。SRを立ち上げたかったのだろう。SRの環境で動作するとしている。Photo06の下の2つは全体に対するオプションである。BootとFirmwareのUpdateをカバーする仕様で、Pre-siliconは実際にSoCを製造する「前に」シミュレータなどで動作の検証が完了している事を示す。このSystemReadyを利用することで、SoCベンダー:製品のターゲットに応じてBSAおよびBBRをインプリメントし、Certificationを取得することで、OSの移植とか動作確認などの作業から解放されることになる。エンドユーザー:Certified製品を購入してシステムを組めば、そのままOSをすぐにインストールして利用できる。Server的に利用することも可能になる。Arm:Certificationによる収入が期待できるし、より広範にArmベースSoCをサーバーマーケットに使ってもらえるという、全員がWin-Winとなる関係が期待できるという話だ。実際NXPはすでにこのSystemReady-SRに基づく製品として同社のLX2160AにSBBRとSBSAの対応を行ったが、作業は非常に簡単だったとのことだった(Photo07)。Photo07:対応状況。Windowsはあんまり考えてないのだろうが。クラウドだけでなく、本格的にサーバーマーケットに進出するためのネックを、また1つ潰し終わったというのが今回のArmの発表であった。2020※本記事は掲載時点の情報であり、最新のものとは異なる場合があります。2020このカテゴリーについてインテルや東芝といった半導体メーカーや、CPU、メモリなどの半導体デバイスに関わる情報、市場トレンドといったホットなニュースを毎日更新。注目のIoTや自動運転など、半導体の適用範囲の拡大とともに成長が続く半導体業界の話題を詳細な説明付きで紹介します。Corporation。