大原雄介の半導体業界こぼれ話
8bit MCUの夕暮れ
2023年2月28日 06:16
今月のお題は、前から業界では言われていた話であるが、改めて整理してみたら本当にそうだったなぁ、という話。そもそもちょっと前から、MCU業界でも「これからは32bitの時代だよね」などという話は出ていたのだが、このコロナ渦の中で本当に8bitのMCU(Micro Controller Unit)のマーケットが夕暮れ状態に陥り、しかも加速しているようだ。
8bit MCUの定義とは?
ある製品がMCUかMPU(Micro Processor Unit)か、というのは端的に言えば「外部にメモリそのほかの周辺回路なしで動くか否か」という話で、MCUは大体においてCPUコアそのものに加えてSRAM(プログラム稼働/データ保存用)とフラッシュメモリ(ほとんどはプログラム格納用だが、たまにデータ保存用もある)、周辺回路、クロック、周辺I/O、どうかするとPMICまで搭載しており、本当に電源だけ供給すれば単体で動作する。MPUは基本外部にメモリを搭載して、そこをプログラム格納領域として使う格好になる。
もっともこの定義だと、例えばScratchPad領域のSRAMはどうするんだ(たまにここにコードを置けるものがあったりするので厄介である)とか、オンパッケージで64GB HBM2eを搭載し、外部DRAMなしでも動くXeon MAXはMCUなのか？という話もあって、完全ではない。
別の定義としては、MMU(Memory Management Unit)が動くのがMPU、MPU(Memory Protection Unit)が動くor(最近はあまりないが)そもそもメモリ管理ユニットがないのがMCU、という分類もある。要するに仮想記憶が動くか否かである。
これ、昨今の32bit～64bit全盛の状況では割と説得力がある判断基準ではあるのだが、4/8/16bitだとMPUにもMMUが搭載されていないケースが多かったので、完全な基準とは言いがたい。実際、コアは一緒で周辺構成でMPUとMCUの両方が用意された例もあるので、割と恣意的な判断でMPUかMCUが決まると思っても間違いではない。
さて、トレンドで言えばさすがにもう8/16bitのMPUは市場に存在せず、ここは全量MCUと考えて間違いない。32bitが混在しており、MCUとMPUの両方がある。64bitはまだMCUは非常に少なく(ないわけではない)、ほとんどがMPUである。その意味ではタイトルの「8bit MCU」は冗長であって、「8bitの夕暮れでいいじゃん」と言われればその通りなのだが、まぁそこはおいておくとして。次の問題は8bitって何よ? という話である。
そもそも8bit CPUの定義(あるいは16bitでも32bitでも何でもいいのだが)は何か? というと、これも歴史的には色々揉めた話である。昔はアドレスバスとデータバスのサイズで決まるなんて話があって、「んじゃデータバスは8bitだがアドレスバスは16bitのIntel 8080は16bitなのか?」、「んじゃデータバスは8bitだがアドレスバスは16bitのIntel 8088は8bitなのか?」なのか的な論争もあった。MC68000は32bitなのか16bitなのかとか、SuperHシリーズは32bitなのか16bitなのか、なんて話もあった。
筆者的に言えば「全命令で扱える最大のデータ型のサイズが8bitなら8bit CPU」である。一部の命令で例外的に大きいデータ型を扱えてもダメである。それが通れば昨今のx64プロセッサは全部512bit CPUになってしまうからだ。
歴史的に8bit CPUとして扱われているZ80にしても、一応16bitのLoad/Store命令とか算術演算命令は存在するが、それはアドレスの扱いに必要なものに限られており、例えば算術演算命令の中でもAND/OR/XORといった論理演算は8bitしかないといった具合だ。
ちなみにルネサスエレクトロニクスはRL78という8/16bit MCUを現在もラインナップしている。現行品の場合、8bitと扱われるもの(RL78G10/G1M/G1N:S1コア)と16bitと扱われるもの(それ以外:S2/S3コア)が混在しており、大きな違いは16bitの乗除算命令を搭載するか否かだったりする。
8bit MCUの新製品
話がそれたが、そんなわけで今回お話するのは、データの方は8bit演算のみのMCUに絡む話である。実を言うと、8bit MCUそのものは現在も出荷が続いており、どうかすると新製品すら出ている。
例えば今月(2023年2月)も台湾Holtek Semiconductorは同社独自の8bit RISCコアを積んだ「BH66F2560」とか「BH67F2476」を発表している。もっともHoltekの8bit MCUを搭載した製品は汎用向けというよりもASSPに近い存在なので、別だと言われるかもしれないが、もう少し汎用という意味では、昨年4月にMicrochipは「AVR DD」と「PIC16」の新製品を発表している。なので製品レベルで言えばまだ僅かながら増えているし、過去に発表された製品もまだ数多く継続出荷されており、今すぐ製品が市場から消えるというわけではない。
しかしながら8bitのCPUコアそのものは、ここ暫く新しいものが出ていない。商用でなくても良いのであれば、昨年8月にご紹介したOpen Source Silicon Initiativeを利用した「NoobsASIC」みたいなものが存在するが、商用向けで言えば皆無である。
2015年にSilicon Labsが「EFM8」という8bit MCUシリーズを発表したが、実はコアそのものはそれ以前から同社が持っていたCIP-51というパイプライン構造の8051互換コアで、単に同社が買収したEnergyMicroの「EFM」シリーズという32bit MCUのラインナップの延長にあるような型番を付けたというにすぎない。
筆者が把握している限りで一番最近の新コアは、2014年にポーランドのDCD(Digital Core Design)が創業15周年を記念してリリースしたPIC16互換の「DRPIC1655X」とMC68HC11K互換の「D68HC11K」、それと8051互換の「DT8051」の3つである。
いずれもIPの形ではあるが、命令セットはそれぞれPIC16/MC68HC11/8051互換で、ただし内部は独自のパイプライン構造になっており、DRPIC1655Xなど0.35μmプロセスで800MHzの動作が可能という触れ込みであった(実際には周辺が追い付かないのでもう少し微細化したプロセスにするか、0.35μmのままなら動作周波数を落とさないと厳しいとは思うが)。
ちなみに8051コアで言えば、2012年2月に(当時はIXYS Corporationの子会社だった)Zilogが、突如「Z8051」なるコアを発表している。この発表のプレスリリースには「ZilogはZ80/Z8/Z16といったコアを35年以上にわたって供給してきたが、同様に8051コアも同じくらい長く使われてきた。なのでZilogがZ8051を発表するのは、ごく自然なことである」という頭が湧いてるのか? と思うような文言が踊っているのだが、これもデータシートを見ると「M8051 Core」とか書いてある(図1)ので、どこからか8051コアのIPを入手したのだろう。余談だが、既にこのZ8051は完全にディスコンの扱いになっている。
Zilogはほかに旧Samsung Semiconductorの4/8bit MCUもラインナップしているが、これは2013年に親会社のIXYS CorporationがSamsungの4/8bit MCUのビジネスを丸ごと買収して、それを押し付けられた格好であり、そういう意味でも新コアとは言いがたい。特にS3ファミリはZ80互換のコアなので、まぁ今更という感じである。
ちなみに米CASTは2015年2月のEmbedded Worldで8051互換の超高速IP Coreである「S80251XC3」を発表しているが、これは8051とバイナリ互換な16bitの80251の互換CPUなので、ちょっと今回の枠からは外れる気がする。
8bit MCUが出てこない理由
話を戻すと、そんなわけで8bit MCUは製品こそまだ継続してリリースされているものの、アーキテクチャ的には2010年台前半でもう刷新が終わってしまっており、恐らくこの後新しいアーキテクチャが出る可能性は極めて低い。
これには2つの側面がある。1つは、もう新アーキテクチャを開発するためのコストが、それで得られる成果に見合わないという話だ。もちろん昨今の64bitプロセッサに比べれば、8bit MCUのコアの開発は低コストである。
実際、その気になれば1～2人でアーキテクチャは製造できる。Arduino Uno(やその前身のArduino Duemilanove、さらにその前身であるArduino Diecimilaなど)で広く使われたAtmelの「AVR8」コアは、元々はμRISCという名称でノルウェー工科大のAlf-Egil Bogen氏とVegard Wollan氏の2人の卒業論文の題材として開発されたものだ。これをAtmelに持ち込んだ結果、「Alf and Vegard's RISC」ということでAVRという名称が付いた。
ただプロセッサを作るのは簡単でも、そこで動くプログラムを書くための環境づくりには猛烈な手間と人手がかかる。アセンブラとリンカだけ用意すれば済むというものではなく、Cやらなにやらの移植やデバッグ環境、統合開発環境、ライブラリ、ミドルウェア、OSなどを全部揃えようとすると、相当なコストになるだろう(根拠のない大雑把な見積もりだが、CPUコアの開発の10倍では効かないと思う。最低でも100倍位は掛かりそうだ)。そのコストをかけて新アーキテクチャを世に送り出したとして、そのコストを回収できるほど売れるのか? というと、間違いなくNoである。
もう1つはMCUに起因する制限である。「んじゃ8051のアーキテクチャを使いつつ、スーパースカラとアウトオブオーダー入れて数GHzで動くコアを作るぞ」とか言っても、既存の8051のアプリケーションがインオーダー/シングルイシューのパイプライン構造を前提にアプリケーションを記述しているから、そもそもスーパースカラで処理できる余地があまりないし、アウトオブオーダーにしても性能向上は殆ど望めず、むしろ処理完了までの処理サイクルが正確に計算できなくなることを嫌がられるだろう。
そもそもMCUの場合プログラムコードはNORフラッシュに置くのが一般的であり、800MHz駆動のCortex-M7コアですらフラッシュからの読出しが間に合わないのでキャッシュを併用しないとWaitが入りまくることを考えると、32bitのCortex-M7とかCortex-R52とかはデュアルイシューにする意味はなくもないが、8bit MCUでデュアルイシューは完全に無駄である。
ついでに言えば、NORフラッシュを利用する関係で、先端プロセスを使いにくい。SamsungはArmと組んで28nm FD-SOI上にMRAMとMCUコアを搭載したMusca-A1を2019年に発表したが、未だに量産品には採用されておらず、その意味ではどんなに頑張ってもTSMCのN16あたりが微細化の限界である。動作周波数はそのN16上で動くNORフラッシュの動作速度が律速段階になるわけで、現実問題として動作周波数は数百MHzのオーダーが上限になる。それであれば既にある8051のIPで十分、というわけだ。
市場のニーズと実装コストのジレンマ
ところが市場のニーズは、より高性能化や高機能化に向けて深化している。昔はMCUはあくまでも機器の中の閉じた制御用であって、外部と通信なんて基本的に考えなくても良かった。ところが最近はコネクテッドデバイスが急速に増え始めており、TCP/IPのフルスタックを用意しろとは言わないものの、USARTを使ったシリアル通信程度では明らかに不十分で、何らかのネットワークが求められるケースが多い。
あるいはMCU自身へのセキュリティのニーズも増えており、Secure Enclaveにしろとか、ファームウェアの保護機能とか暗号化通信に対応するためのセキュアキーストレージやTRNG(真性乱数生成器)とは言わないまでも、PRNG(疑似乱数生成器)程度は最低でも要求される。
もうちょっと複雑なことをする機器の場合は、ファームウェアのOTAアップデート機能が「いざ」という時のために要求されることが増えてきた。製品発売後に例えば脆弱性が発見されたとしても、OTAアップデートがないと物理的に回収なり交換が必要になってしまうためだ。
こういう具合に色々機能が増えてくると、当然ながらコードサイズは大きくなるし、加えてアップデートに対応するためにフラッシュの容量も増える。ネットワークスタックを乗せるためにはSRAMの容量も相応に必要である。したがって、もはやMCUのダイサイズに占めるCPUコアの割合はかなり小さくなっている。
MCUに必要な回路規模だが、DCDの「DRPIC1655X」の場合は4,800ゲートほど。一方Armの「Cortex-M0」だと12,000～25,000ゲート(回路構成次第)程度。台湾Andes Technologiesの「N22」コア(RV32)も15,800ゲートほどで実装できる。つまり8bitコアに10,000ゲートほど追加するだけで、32bitコアにできるわけだ。そしてまた、こうした機能を8bitの演算だけでやろうとすると非常に不効率である。こうなってくると、8bit MCUが逆に不効率になる。
そもそも何でこれまで8bit MCUが広く使われてきたたか? というと、回路規模が小さく(=省コスト)、なのでフル稼働させても消費電力が低く抑えられる(=省パワー)点がメリットとされてきたわけだ。ところが昨今では必要なメモリ容量が大きくなったことで、8bitでも32bitでも言うほど回路規模は変わらなくなり、省コストのメリットが前ほど顕著ではなくなった。
そしてネットワークとかセキュリティなどの処理を全部自前で賄う場合、32bit MCUよりも長時間コアがフルに駆動させられることになり、結果として省電力性のメリットも少ない(か、下手をすると8bitの方が消費電力が大きい)状況に陥り始めている。今、新製品が出ている8bit MCUというのは、こうした制約があまり関係ない製品に限られる。
例えば冒頭に出てきたHoltekのBH66F25609(パルスオキシメータ用MCU)は、SRAM 1KB/フラッシュ32KB/データ用EEPROM 1KBに過ぎないし、ネットワーク対応とかはもちろんなし。セキュリティ機能もない、本当に低価格なパルスオキシメータ向けなので成立するわけだ。
余談だが、8bitに加えて16bit MCUもほぼ同じ状況にある。元々16bit MCUは8bitと32bitの中間的な位置付けの製品であったが、32bitのローエンドが8bitを置き換える勢いで急速に伸びた結果、8bitのみならず16bitの居場所もなくしてしまった、と考えれば良いだろう。それでもまだルネサスエレクトロニクスのRL78シリーズとかTIのMSP430のように頑張っているベンダーはあるのだが、MicrochipのPIC24シリーズはかなり厳しい感じだ。
想像より早く32bitに移行されるMCU
さて、枕はこの程度にしておいて本題。そんなわけで緩やかに8bit(や16bit)MCUのマーケットは縮小傾向にあった。「縮小」といっても組み込み向けだから、非常に息が長い。要するに新規デザインにはもう8/16bitではなく32bitを使おう、という風潮が次第に強くなっていた。
「次第に強くなっていた」という程度なのが組み込み業界の特徴である。要するに新製品に要求される機能が全く新しいもので、既存の設計の延長ではまず実現できないなんて場合はともかく、既存の設計の手直しとかで済むのであれば、その設計を踏襲した方が確実に開発できることになる。
信頼性に関しても、既存の製品ファミリーである程度クセとか故障率とかを把握できていれば、もちろん最終的にはきちんと検証を行なうにしても、既存の製品の派生型を使う方が確実性が高い。なので新製品に8/16bit MCUが使われなくなる日が来るのはまだ10～20年先、と筆者は考えていた。
この見通しが吹っ飛ばされたのは、コロナ禍による半導体不足である。要するに8bit MCUが手に入らなくなってきたのだ。昨年11月にSourcengineが出したQ4 2022 Lead Time Reportを見る限り、もうここ暫くは8/16bit MCUの調達にはかなり長期のリードタイムが必要になっており、それが解消できる見込みは少ない。ということは、8/16bit MCUを使っている限りは、製品の製造のリードタイムがこれだけ必要ということになる。要するに製品の出荷ができないわけだ。「しょうがないね」で待てればいいのだが、普通は無理である。となると、流通在庫でも何でもいいから手に入るものを使って製造するしかない。
こうなると8/16bit MCUは非常に不利である。そもそもメモリ量が少ないから、それぞれのアーキテクチャに最適化する形でコードを書いていたし、RTOSを乗せるのも厳しいからベアメタルで使うのが普通だった。こうしたソフトウェアをほかのMCUに移植するのは非常に大変であるというか、移植と言うよりも新たに開発に近い。しかも、今手に入るMCUが今後も入手可能とは限らない。
昨今、ArmやRISC-VのMCUが急激に台頭してきたのは、複数のメーカーが同じアーキテクチャに基づく製品を出しているので、メーカー間での乗り換えが相対的に楽(周辺回路とかメモリマップなどは変更するにしても、CPUコアのアーキテクチャは共通)という点が大きい。そして周辺回路やメモリマップなどのハードウェアの差異を吸収するには、HAL(Hardware Abstraction Layer)を挟んで抽象化してしまうのが一番楽である。このために提供されているのがArmのCMSISとかRISC-Vの「RVM-CSI」のような抽象化レイヤーであり、さらににRTOSを組み合わせる事でこの辺をアプリケーション非依存に近いところまで持ってゆくことが可能である。こうした方策が、8/16bitでは存在しない。
この結果として、これまでだと既存の8/16bit MCUの延長で対応していた新規製品開発が、急速に32bit MCUに鞍替えしつつある。結果、上で10～20年先と考えていた「新製品に8/16bit MCUが使われなくなる日」が、予想よりかなり前倒しになりそうな雰囲気が漂っている。
Arduinoプロジェクトにしても、もちろん既存のArudino Unoを始めとする8bit AVRベースのキットは提供しているが、最近同プロジェクトが力を入れているのは32bitのSAMD21を搭載したMKRファミリーであって、次第に8bitから32bitへの移行が目立ち始めている。
時代の流れで、いずれは8/16bitも市場から払底してゆくのは仕方ないとは思っていたが、ここまでその流れが加速するとは思っていなかった、というのがここ暫くの筆者の偽らざる感想である。