ARM Cortex-M7に見る、今後のMCUの方向性

2014年9月にARMはCortex-M7を発表し、早速AtmelとFreescale、STMicroelectronicsがライセンスを受けたことを発表したのは既報の通り。加えて11月にはSpansionもライセンスを取得しており、恐らくすでにCortex-M4のライセンスを受けているメーカーのほとんどはこれに追従するのではないかと思われる。そのCortex-M7、内部構造が2014年に行われたARM TechConで発表されているので、これを紹介しつつ、今後のMCUの動向についてちょっと考察してみたいと思う。

内部構造

Cortex-M7そのものの命令セットはCortex-M4と完全に一緒である(Photo01)。恐らく次のARM v8Mが発表されるまで、これは変わりそうに無い。逆に言えば既存のCortex-M0～Cortex-M4のコードはそのまま完全に互換に動作することが保障されているわけでもあるが、ただし最適化に関してはちょっと話が面倒なことになりそうだ(これは後述)。

さて、そのCortex-M7の内部構造はこんな具合である(Photo02)。直接比較できる図ではないが、Cortex-M4と比較した場合に、このレベルでの大きな違いは、当初からCacheとTCMが(オプション扱いながら)用意されていることだ。こちらにもちょっとあるが、Cortex-M7プロセッサは5 CoreMark/MHzの性能とされており、なので90nm世代で200MHz、40nm世代で400MHz、28nm世代では800MHzを狙えるという見積もりになっており、何をどうやってもEmbedded Flashでは絶対に追いつかないし、QuadSPIの外部Flashでも間に合いそうにない。なので命令キャッシュに加え、L2としても利用できるTCMの利用はまぁ必然になるのは当然であろう。

さてそのパイプライン構造がこちら(Photo04)。ALU×2、Load/Store×1、MAC×1の4命令同時実行が可能で、さらにFPUがオプションで利用される。ただDec #2というかIssue unitはそこまでの命令幅はないと思われる。Cortex-M4の性能との比較で考えると、Issue unitは2命令の同時発行で、FPUが加わってもこれは変わらないものと思われる。これを3命令以上にしようとすると、命令Fetchの帯域もさることながらData Fetchの帯域も同時に増やさないとバランスが悪くなるし、一般論として3命令のIn-Order Superscalarがどこまで有効なのかは疑問で、そろそろOut-of-orderの実装が欲しくなるが、そこまでいくとMCUの枠をはみ出している気がする。バランスを考えれば2命令のIn-orderは悪くない選択だろう。

これに組み合わされるのがTCM(Photo05)である。TCMそのものはCortex-M世代でもオプションでは使えた(最初に登場したのはARM9の世代で、ARM926EJ-Sあたりが実装を始めた走りだったと記憶している)はずだが、Cortex-M7ではこれを積極的に実装に利用している。

Photo02を見直していただくと判るが、Instruction TCMはオプション扱いだが、Data TCMは標準装備扱いになっており、しかもわざわざTCM Arbitoration I/Fを標準装備しているあたりが従来と大きく異なるところだ。Instruction TCMがオプションなのは、Instruction Cacheを実装する方法も取れるからで、どちらを使うかはメーカーの好みで選べる事になる(両方実装するのは不可能ではないが、構造的には意味がなさそうだ)。TCMはメモリアドレス的にはAXI経由で接続される外部メモリと連続する空間にmappingできる(ので、アプリケーションから見るとどちらも同一の空間として扱える)が、外部I/Fは異なっており、専用のDMA Channelに繋がっているのが判る(Photo06)。

これはどういうケースかというと、そもそもTCMはSRAMなどと比べてもずっとエリアサイズが大きくなるので、あまり大容量にするのはコストへのインパクトが大きい。そこでTCMの容量はそこそこにしておき、外部に専用SRAMを装備してDMAで繋ぐ、といった逃げ方が考えられる。実際Data TCMが32bit Block×2の構成になっているのは、Dual Bank的な使い方を想定していると考えられる。あるBankをCPUがアクセスしている間に、もう片方のデータを外部SRAMに退避、あるいは外部SRAMからデータを取り込みといった使い方で、この際にはDMAで高速転送を掛けるという形だ。Instruction TCMの方は(Photo02にもちらっと出てきているが)、Flash Accelerator的な使い方が主になるだろう。

さてそれではキャッシュは? というとこんな感じ(Photo07)。サイズは最大64KBで、MCU向けとしては最大級ではあるが、下手なアプリケーションプロセッサ並みという性能を考えると、もう少し大きく取れても良い様な気もする。

ちなみにTCMとCacheの使い分けとしては、トータルとしてどれだけ大きなメモリ量を扱うか次第である。TCMの場合、その領域はNon-Cachableであり、かつ入れ替えなどのメカニズムは用意されない。だからこそアクセス時間が一定のものとして扱えるという話であるが、逆に言えばTCMの容量より大きいデータやプログラムを扱うのは著しく困難になる。キャッシュの場合は当然Hit/Missに応じてアクセス時間が変わる一方、かなり大きなプログラム/データであっても相応の効果が期待できる。つまるところはどっちを狙うかという話で、原理的に両立は難しい(というか、両方装備しても構わないけど無駄が多い)。なので後はアプリケーション要件(リアルタイム性を狙う製品か、アプリケーション性能を狙う製品か)に応じて構成を選ぶ形になる。

話を戻すと、D-CacheのControllerの方は、AXI Master以外にAHBのPeripheral Portも搭載されている(Photo08)。これは、大量のデータを扱う場合などに便利である。特にストリーミングデータを連続して処理、なんて場合にいちいちデバイス→メモリ→CPUコア→メモリなんて形でデータの移動を行っていると、こうしたデータの転送に要する時間が馬鹿にならない。ところがAHBP経由で直接データをD-Cacheに流し込み(この際にMemoryへのWritebackは行わない)、そのままMACユニットで処理、必要ならその結果を再びAHBP経由でデバイスに送り返すなんて事も可能であろう(この際もWritebackは行わない)。この動作は、あるメモリ領域をNon-shared cacheable memoryに指定しておくことで可能になるようだ。

AHBPの話をしたついでに、システム構成について説明しておく。最小構成のCortex-M7ベースMCUはこんな形で構成できる(Photo09)。とりあえず余分なものが一切入らない分、シンプルではある。周辺回路はこの場合、AHBP経由でぶら下がる形になる。ただ、これだとInstruction TCMの容量を超えるサイズのプログラムでは急速に性能が低下するというか、Flash Memoryのサイズを相当小さくしておかないと、TCMが占めるエリアサイズが肥大しかねない。そこでこれを超えそうな場合はFlash Acceleratorを外部に接続することで、性能の低下をなるべく抑える必要がある(Photo10)。逆に拡張性やアプリケーション性能を重視するのであれば、むしろPhoto11の様にAXIを使って多くの周辺回路やFlashなどを繋ぐようにしたほうが楽である。このあたりは各メーカーの判断によるわけだが、例えばSTMicroelectronicsの「STM32F7」の場合はPhoto11の方式を選んだ様だ(Photo12)。

もう一度コアに話を戻すと、設計時点で省電力に向けた設計もかなり盛り込まれている(Photo13)ほか、ECCの強化とLock Stepの対応が当初からなされているのは流石と言える(Photo14)。