大原雄介の半導体業界こぼれ話

ローエンドMPUを追い立てるハイエンドMCU

 先月に続いて今月もMCUの話を。ただ今回はハイエンド向けの話である。ハイエンドの32bit MCU自身は急速にマーケットを広げており、一部ローエンドのLinuxベースのシステムのマーケットに食い込み始めている。

 たとえばちょっと前だと組み込み機器でGUIを作り込もうとするとGNOMEなりKDEなりを動かすのが普通で、そうなると最低限Linuxが動く環境が必要だったし、最近だとこれをAndroidでやる例が増えてきているが、こちらも最低限Androidが動く環境が必要である。もちろんLinuxといってもピンキリで、下は初代Rapberry PiでもLinuxが動くしGUIも利用できるから、これなら原価100ドル未満でGUIが提供できるが、使ったことがある方はお分かりの通り、ストレスなくサクサク動くとは言いがたいのが正直なところ。

 Raspberry Pi 4とかCM4クラスならだいぶマシになるが、価格は100ドルでは収まらない。Androidも同じで、液晶パネルは別にしても、そこそこに動く構成を用意しようとすると、やはり100ドル程度は覚悟する必要がある。GUIを付けるために100ドル+α(実際は液晶パネルなども必要だから、概ね200ドル程度)の原価上昇を覚悟する必要がある。

GUIの動作が現実的になってきたMCU

 ところがちょっと前から、フレームバッファを利用できるMCUという製品が市場に出て来た。一番最初かどうかは断言できないが、2012年2月に発表された「PIC32 MX1/MX2」はPMP(Paralle Master Port)と呼ばれる汎用のパラレルポートを搭載。ここにSDRAMを繋ぐことでフレームバッファとして動かすことが可能だった。

 もっともこれは「可能」というレベルで、どの程度現実的か? と言われると怪しいところで、それもあってMicrochip自身、外部にグラフィックコントローラ(Solomon Systech SSD1926/EPSON S1D13517)を接続することを推奨していた(図1)が、原始的なGUI(もどき)で良ければ2012年頃からMCUのみでのGUI構築は可能になっていた。

【図1】Microchipの2015年の日本語ブローシャ(“Microchip グラフィック/セグメントディスプレイソリューション”)より。一応PIC24F/PIC32から直接LCD出力も可能だった

 もう少し現実的というか、それなりにちゃんと動くという観点で見ると、(「ちゃんと」の定義があやふやなので筆者の主観ではあるが)、STMicroelectronicsが2014年に発表した「STM32F7」はかなり現実的になったように感じる。

 STMicroelectronicsは2013年に「Chrom-ART」という簡単な2DグラフィックアクセラレータをまずCortex-M4ベースの「STM32F4」シリーズに実装してリリースしており、これはグラフィックはそれなりに動くのだが、プロセッサがCortex-M4ということもあって全体的にはまだもっさり感がが否めないレベルだった。ところがコアをCortex-M7に交換したSTM32F7はこのあたりがだいぶ改善され(図2)、しかもその後に投入されたCortex-H7ではChrom-ARTが64bit Busで接続(STM32F4/STM32F7は32bitで接続)されたことでかなり現実的な速度でGUIが動くようになった。

【図2】昔Arm TechConの会場で貰ったSTM32F7の評価ボード。こういうシンプルなGUIであればかなりサクサク動くが、3Dっぽい表示とかをさせるとさすがに荷が重い

 ちなみにこれは先も書いたように2014年とかの話であり、その後NXPやルネサス、Infineonなどのメーカーも相次いで2Dのグラフィックアクセラレータ(それもChrom-ARTよりも充実した機能を搭載したものも少なくない)を搭載したMCUをリリースしており、最近は2.5D(疑似3D)のグラフィックを利用したGUIの構築がMCUベースで十分構築可能なレベルに達している。Qt for MCUの動作デモあたりをご覧いただければ、どの程度のものが可能か? がお分かりかと思う。

ハイエンドMCUがローエンドMPU以上の性能?

 別にGUI用途だけでなく、一部のNetwork機器(IoT向けルータとか)やデータ処理などの用途でも、昨今のハイエンドMCUはローエンドMPU以上の性能を発揮していたりする。まぁこれはハイエンドCPUの性能が上がったというだけでなく、ローエンドMPUの方もより低価格(=低性能)の方に広がってきた、ということも関係してはいると思うのだが、そんなわけで一部の領域ではMPUとMCUの性能がほぼオーバーラップする感じになっている。

 たとえばNXPの「i.MX RT 1060」は600MHz駆動のCortex-M7×1で、性能は1,284DMIPS・3,020CoreMarkとされる。一方でApplication ProcessorであるLayerscape 1012Aの場合、600MHz駆動ないし1GHz駆動のCortex-A53×1の構成だ。

 Cortex-A53の性能は2.3DMIPS/MHz、3.0CoreMark/MHzとなっており、ということは600MHzだと1,380DMIPS・1,800CoreMarkという結果に。Dhrystoneだと同等だが、CoreMarkだと明らかにLayerscape 1012Aの方が性能が低いことになる。

 なので要求性能がちょうど製品の狭間なに位置してしまう場合、MCUとMPUのどちらを使うか? と言えば、性能以外の要素で、ということになる。つまり要件的に仮想記憶が必要なOSを使う必要がある、あるいは周辺機器のドライバとかアプリケーションライブラリなどの関係でLinuxなどのOSを使う必要があるなどの場合にはMPUを使うのが妥当だし、より高い性能が求められる可能性があるのであればやはりMPUを使う方が無難だろう。逆にそういった縛りがない場合、あるいは価格への要求が厳しい場合はMCUを使うといった格好だ。

 これまでこのMCUのハイエンドコアと言えば、ArmのCortex-M7であった。Cortex-M7は6段のパイプラインを持つスーパースカラ(さすがにアウト・オブ・オーダーではなくインオーダー)構成で、デコードは2命令/サイクル、発行は整数4命令+FPUで最大5命令という構成である。

【図3】MACパイプラインはDSP命令の実行用である。ALUに関しては非対称構成で、利用頻度が高い、簡単な命令に関してのみALU #2 Pipelineが動く格好

 そのCortex-M7のCore Complexの概要がこちら(図4)。TCMもしくは命令/データキャッシュがほぼ必須になっているのは、元々Cortex-M7は最大1GHzぐらいまでの動作速度を想定しており、当然フラッシュからの読出しだと間に合わないから、手前にTCMなり命令キャッシュなりを入れないとウェイトが入りまくる、という事情によるものである。ただこのパイプラインとかCore Complexは、Cortex-A5/A7などのMPUに比べると、まだ比較的シンプルな部類に入る。

【図4】一応I-TCM及びCacheはオプション扱いになっているので、技術的に言えばどちらもなしで直接フラッシュからプログラムを読み出す(この場合、中央下段のAXI Masterの先にFlash ControllerなりSPI I/Fなりが繋がって、そこから読み出す格好になる)ことになるが、さすがにそういう実装は今のところ見かけたことがない

 さてそんなArmであるが、2020年2月にはCortex-M55を発表しており、これがArmv8.1Mでは最高速のコアとなっていたが、内部はシングルイシュー/インオーダーの比較的シンプルな構造(図5)。性能的にはArmの説明によればCortex-M33の10~20%高速な程度とされており、1.69DMIPS/MHz、4.4CoreMark/MHzとなっているため、仮に600MHz駆動だとしても1,014DMIPS・2,640CoreMarkという計算で、Cortex-M7には追い付かない程度であった。

【図5】とは言え、ALUとLoad/Storeは内部的に別の実行ユニットとして実装され、ただし同期して動くという構造。その意味ではDual IssueのIn-Orderという見方も出来る。

高性能なCortex-M85

 というわけで、ここまでが今回の枕。Armは2022年4月にCortex-M85を発表した。これはCortex-M7の後継となるハイエンドコアであり、性能は発表時のブログエントリによれば3DMIPS/MHz以上、6CoreMark/MHz以上とされており、600MHz駆動なら1,800DMIPS以上・3,600CoreMark以上という計算になるから、明らかにCortex-M7を上回る性能を発揮できることになる。

 公式にはパイプライン構造は明らかになっていないものの、3命令デコード/発行のスーパースカラ構成(さすがにインオーダーである)であることが明らかになっている。ちなみにその後公開されたTechnical Reference Manualで、

  • 内部はIFU(Instruction Fetch Unit)とDPU(Data Processing Unit)の2つに分割できる(もっとも“Tightly coupled”なんて表現があるので、別に分離できるというわけではないのだが)。
  • IFU+DPUのパイプライン段数は7(整数演算)/9~10(Vector/FPU)の
  • DPUの命令フェッチは64bit幅。ロード/ストアも64bit幅
  • 主要な整数演算は2命令/サイクルで実施。ロード/ストアも同時2命令発行可能

といった特徴が語られている。ここから考えるとCortex-M85の内部構造は構成図1のような形になっていると考えられる。Cortex-M7との違いは、ALUのパイプラインがLSU(ロード/ストアユニット)のパイプラインと対になって、これで1つの実行ユニットを成しているところだろうか? この辺はCortex-M55のパイプラインの仕組みを踏襲しているものと考えられる。

【構成図1】

 この結果としてCortex-M85のProcessor ComplexはCortex-M7と比較してかなり複雑なものに進化した(図6)。まずCortex-M7になく、Cortex-M85に加わった要素にPower Domainの考え方がある。Cortex-M85の場合

【図6】点線部はオプションなので、たとえば命令キャッシュ/データキャッシュ(図ではIRAM/DRAM)を省けば、その手前のICU/DCUとか、そもそもPDRAMS領域そのものが不要になるわけだが
  • PDCORE:コア部のPower Domain
  • PDEPU(Power Domain Extension Processing Unit):Heliumなどのアクセラレータ
  • PDRAMS:L1キャッシュのPower Domain
  • PDDEBUG:デバッグI/F用のPower Domain

というローカルのPower Domainがあり、それとは別にプロセッサコア全体のPower Domainがあるというもので、ユニットによって最適な動作電圧の調整を可能にするのに加え、Sleep/DeepSleep/Suspendなどにおいて細かくPower Domainを分割して限界まで省電力性を高められるように工夫することが可能になった。

 逆に言えば、MCUでありながらもCortex-M85はここまで細かく電源管理を要求されているということでもある。これとは別にコアあるいはPDEPUにはCDEというユニットが破線で示されているが、これはCustom Datapath Extensionで、これはカスタム命令拡張用のユニットのことである。

Cortex-M85はメモリ保護機能も充実。そこらの32bit MPUよりも複雑に

 もう1つ特徴的なのはMAU(Memory Authentication Unit)の存在だ。これはCortex-M7には存在しないユニットである。Cortex-M85は先ほどもちょっと書いたがArmv8.1Mの命令セットに対応するコアである。そしてCortex-M7のArmv7Mの命令セットとの最大の違いがセキュリティ対策である。Cortex-M7では単なるMPU(Memory Protection Unit)が搭載されていたが、Cortex-M85ではPMSA(Protected Memory System Architecture)に準拠したメモリ保護機能が追加されている。このPMSA準拠の保護機能を管理するのがMAUである。

 MAUというかPMSAは、Arm v8.x-A/v9-Aで実装されるMTE(Memory Tagging Extension)とかPointer Authentication、BTI(Branch Target Identifiers)などのセキュリティ拡張に近いもので、通常のMPUの機能である「ある特定のメモリ領域がアクセス不能/リードのみ可能/リード・ライト可能かの設定)に加え、TGU(TCM Gate Unit)とSAU(Secure Attribution Unit)を搭載する。TCMはスクラッチパッドのSRAM領域に対してMPUと同様のアクセス制御を行なうためのユニットである。そしてSAUはメモリ領域のSecure/Non-secureの管理を行なうためのユニットである。

 SAUではNon-secure/Secure and Non-secure Callable(読み書きはSecureでないと不可能だが、そこに置いたロジックの呼び出しはNon-secureから可能)/Secureの3つの状態を保持するもので、これをMPUあるいはSAUと組み合わせることで、Secure/Non-Secureなプログラムからのメモリアクセス制御が可能になる。

 ちなみにMPUとTGUが別々に設けられている理由は、図6からも分かる通り、メモリアクセスは図6左下のBIU(Bus Interface Unit)を通ってAXI5 I/F経由で行なわれるのに対し、TCMの方は中央上にあるTCU(TCM Control Unit)経由で接続されており、メモリとTCMが完全に別々の経路でLSUに接続されるためである。

 Cortex-M7だと、図4に示すようにTCM arbiter and interfaceとAXI Masterからの経路がまとめてプロセッサコアに入っているので、プロセッサコアからすると同一のI/Fの先にメモリとTCMがあることになり、なので別に分離する必要がなかったと言える。

 話を戻すと、このMAUを利用することで、PACBTI(Pointer Authentication and Branch Target Identification:ポインタ認証と分岐先確認)機能が利用できる。つまり、2018~2019年に大騒ぎになったSpectre/Meltdown的な攻撃をハードウェア的に防御できることになる。

IFUからは1回リクエストを出し、その結果が1回戻るだけだが、実際にはセキュリティ周りの対策のためにMAUは複数回LSUとやり取りをする。ただそうしたことはプログラマーからは見えない

 もちろんこれら以外にもCortex-M7からの相違点は多い。HeliumことMVE(M‑profile Vector Extension)への対応もその1つである。

 MVEは128bit幅のVectorというかSIMDエンジンだが、内部的にはこの128bitをまとめてハンドリングするのは無理なので、32bit幅のBeatという単位で処理を行なう。つまりMVEの128bitレジスタは、内部的には4 Beatとして管理される。

 このBeatをどうやって処理するかはコア依存になっているが、Cortex-M85の場合はFPUが半精度/単精度/倍精度に対応しているので、最大64bit幅が扱える。なので1サイクルあたり2 Beatを処理可能である。ただSIMDの場合、64bitの演算を行なうということは64bitのデータロードとデータセーブが毎サイクルあたり1回ずつ発生することになるわけだ。LSUはこれに対応しており、64bit幅のロード/ストアをデュアルイシューで実施可能になっている。これはCortex-M7の倍の帯域だ。

 また機能安全用途向けにLockStep動作用のI/Fも用意されている。MCU向けと言いつつ、Cortex-M85の内部構造は、そこらの32bit MPUよりも遥かに複雑なものになっているわけだ。

Cortex-M85の動作デモから、登場も真近か

 何でこんなCortex-M85の内部解説を突如始めたか? というと、今年(2023年)月にハノーバーで開催されたEmbedded Worldにおいて、ルネサスがCortex-M85搭載MCUの動作デモを実施したからだ。

 実はルネサスは2022年のEmbedded Worldでもやはり動作デモを行なっているが、この時は単にきちんと動作することが示されただけだが、今年の展示はPlumeraiの提供するAIベースの人物検出エンジンを、Cortex-M85のMVE上で動かすことで、13fps(Latency 73.3ms)で人物検出が可能という現実に近い動作デモを実施し、また2023年中に実際に製品投入を明言した点が昨年(2022年)と異なる。

 2022年にはこんなロードマップ(図8)が示されたが、今年はプレスリリース中に明確に「Cortex-M85プロセッサを搭載した新シリーズのRAマイコンを開発中で、2023年にリリース予定です」と記されており、今年中にはこのお化けMCUが実際に市場に投入されることになる。

【図8】この手のロードマップの常として“Coming Soon”が本当に“Soon”だったことはあまりない

 多分ほかのMCUベンダーも、多少の時間差はあるにせよCortex-M85搭載製品を投入してくるのは間違いないだろう。先月は8bit MCUがローエンドの32bit MCUに追われつつあるという話をご紹介したが、逆にハイエンドの32bit MCUはローエンドMPUのマーケットをどんどん浸食し始めている、というわけだ。多分長期的には32bitはほぼMCUに席巻され、MPUは64bitに移行してゆくと考えられる(ただ8bit MCUに比べれば、32bit MPUの寿命は長そうだが)。