写真：PC Watch

　慶応義塾大学の天野英晴教授と言えば勿論コンピュータ業界では大変に著名なお方である(ふんが先生という名前の方が、ひょっとすると有名かもしれない)のだが、今年3月末に遂に退職なさられた。これにあたっての最終講義が公開されており、実にふんが先生らしいものであった。 【画像】【図2】現在ホストがx86から少しづつArmに置き換わり始めているのはご存じの通りで、ここにRISC-Vも割って入りたい、という意向を示している勢力(例:TenstorrentのJim Keller氏)も居られるが、まぁ時間はかかるだろう 　で、次からのスライドはまさにその最終講義で示されたものであるが、ISAの進化の中でRISC-Vについて、洗練された命令セットとモジュール型というアドバンテージがある一方で、「儲からない」という欠点を未だに克服できないことを指摘している(図1)。 ■ クライアントでは儲からないRISC-Vだが、コントローラ内蔵CPUコアとしては魅力的 　アクセラレータ向けにRISC-Vが使われるというのは単にコストの問題であって、別にArmであっても構わない。というか、ちょっと前に開発され、現在量産されているアクセラレータの多くはArmベースだ。その前はPowerPCとかMIPSとかが使われていたから、技術的な問題でRISC-Vでなければならないというわけではない。 　このため純粋に問題は価格で、もちろん開発期間短縮のために外部からIPを購入すれば、ライセンスなりロイヤリティは掛かる(これはどのベンダーからIPを購入するかで変わってくるが、まぁ概してArmよりは安い)が、そもそもアクセラレータを自分で作ろうという会社であれば、RISC-Vコアを開発するのはそう難しいことではないし、世の中には無償のRISC-Vコアもある(一番ポピュラーなのがRocketだが、ほかにも無償で提供され、商用利用も可能なコアはいくつもある)から、これらを利用して自分でCPUコアを作ることのハードルは、かなり低いと言える。 　強いて言うなら、これまでこうしたアクセラレータ用のコントローラでは、外部からCPU IPを購入する以外に「自分で独自に作る」という選択肢があったが、最近はほぼそれが消えつつある。理由はソフトウェアのサポートである。 　自社のコントローラ専用といっても、最低限コンパイラなりアセンブラとデバッガは必要だし、なんならプロファイラも必要になるかもしれない。ベアメタルで使うならOSやライブラリの類は不要だろうが、昨今はなかなかそうも言ってられない。コンパイラやアセンブラ、デバッガあたりはgcc/gasとgdbを移植する「だけ」で済むが、これだってやったことがないと結構大変だし、この上RTOSなりLinuxなりを動かそうとかし始めると、さらにエンジニアリングコストが掛かる。 　RISC-Vにすればこのあたりが全部既に存在しているわけで、そのソフトウェア移植のコストがまるまる削減できることになる。よほどの理由がない限り、もうRISC-Vを使わないという選択肢は存在しないだろう。図2は要するにそういう話である。 　今後もx86とArm、RISC-Vは当面共存しそうだというのが現在の先生の見立て(図3)で、筆者もこれは同意である。最近ArmというかQualcommは積極的にPCクライアントのマーケットに攻略を掛けているが、個人的にはQualcommのSoCにしか対応してできない(たとえばMediaTekとかSamsungとかのSoCは未対応)というあたりで、選択肢が極めて限られることになる。 　もちろんこれはWindows on Armに関してQualcommがかなりのソフトウェア開発にリソースを投入しているから実現できたという話で、他社も同等以上のソフトウェア開発リソースを投入しないと稼働は難しいと思われる。そのコストを掛けるだけのマーケットがあるかどうか? という辺りが、大問題になりそうである。 　結果、引き続きクライアント向けはまだx86がずっと残るだろうし、サーバーもクラウド向けで採用事例が増えつつあるが、まだ汎用に関しては圧倒的にx86の方が強い。x86と互角の勝負に至るまでにはまだ10年ぐらいは掛かりそうな気がするし、その頃にはRISC-Vベースのサーバーがひたひたと背後に迫ってそうではある。 　組み込み向けはこれまでx86ベースのSBC(Single Board Computer)で実装していたものがどんどんArmに置き換えられつつあり、また画面(KIOSKのようなHMIを持つもの以外に、デジタルサイネージの類も含む)を必要とするものもAndroidベースになりつつあるなど、明らかにArmの浸食が進んでいる。ただここにRISC-Vも乱入しつつあるわけで、先生の言う通り「じり貧の可能性」は捨てられないといったところだろうか。 ■ RISC-Vがみつけた新たな金城湯池とは? 　さて今回の話題は、そんなRISC-Vにおける金城湯池がもう1個増えた、という話である。 　それは何か? というと、FPGAのコントローラである。FPGAはご存じのように、LUT(Look-up Table)を2次元マトリックス的に並べ、それぞれのLUTの設定とLUT同士の接続をプログラム(bitstream)で変更できるようにすることで、任意の回路を構築できるというものである。 　ただLUTというのは要するにSRAMであり、1bit分のLUTを構築するのに最低でも6個程度のトランジスタが必要である。実際、FPGAに使われるのは4入力/4出力とか6入力/6出力のものになるので、利用するトランジスタの数はさらに多くなる。 　もちろん「自由に回路を変更でき、何なら後から現場で修正することも可能」というFPGAのメリットは、そのトランジスタ数の浪費という欠点を埋めてお釣りが来る類のものであり、それもあって急速に普及したわけだ。 　ただ、FPGAが当初は小規模なグルーロジック、要するにちょっとしたI/Fの変換とか、ちょっとした機能の追加などに使われている時には別にそれでも良かったのだが、プロセスの微細化に伴い、同じダイサイズで大量のトランジスタを利用できるようになる=LUTの数が増えると、相対的にゆとりが出てくるので、ちょっとしたコントローラを仕込みたいという欲が出てくる。 　そこでFPGAベンダー各社は、FPGAの上で動く小さなMCUのIPを提供し始めるようになった。具体的には以下のようなものがある。 □Xilinx 　32bitコアの「MicroBlaze」を2002年から提供開始(図4)。MicroBlazeはアーキテクチャ的にはDLXと呼ばれる、Stanford MIPSをベースに構築された、大学の教材ともなったものをベースに構築されている。 　当初は3ステージのMCU向けのコアのみが提供されたが、後に5ステージのリアルタイムコントローラ向けと8ステージのアプリケーションプロセッサ向けのコアも追加されている。2009年にはLinux KernelのソースツリーにMicroBlazeのサポートが追加された。また2004年には8bitの「PicoBlaze」の提供も始めている(図5)。 □Altera 　2001年にまず16bitの「Nios Embedded Processor」のIPの提供を開始、その後に32bit化した「Nios-II」をリリースしている。こちらもやはりRISCベースであるが、構成の幅が非常に幅が広いのが特徴で、パイプラインなしだと、Niosとさして変わらないリソースで稼働する(さすがに性能もそれなりだが)(図6)。 □Lattice 　まず最初に8bitの「LatticeMico8」をリリース(図7)。ついで2006年に「LatticeMico32」(図8)が投入される。最小構成で2,400LUT程度となるので、「Mico8」と比較するとだいぶ大型化してはいるが、6ステージパイプライン構成の32bit MCUとしてはコンパクトな方である。 　このMico32はオープンソースとして提供される(Mico8はクローズドソースだった)ほか、「Wishborn」と呼ばれるI/Fが利用可能で、このWishborn互換の周辺回路を利用することで、かなり複雑な構成を採ることも可能になっている。 □Actel 　2007年に8051ベースの「Core8051s」、および独自アーキテクチャの」CoreABC」の2つを提供開始した。もともと同社は「ProASIC Plus」シリーズのFPGAに、「Core8051」というハードコアを提供してきたが、これをFPGAのLUT上に移植したのがCore8051sであり、同社のFusion FPGA上でも動作可能となっている。 　一方CoreABCはバス幅までカスタマイズ可能な独自CPU IPで、こちらは最小で241LUTと極めて小さいので、IGLOO FPGA上でも稼働するものとなっている。 といった具合だ。またAtmelは2007年にMetal Programmable Logic Gate(FPGAと異なり配線層をユーザーがカスタマイズして製造する、セミカスタムASIC)にARM9コアを実装したCAP(Customizable Atmel Microcontrollers)なる製品をリリースしている。 　このマーケットを狙い、Armは2007年にCortex-M1を発表したが、あまり使われたという話は聞かない。今から思えばARMのこの発表で、Actelはともかく、Xilinxの「Virtex」とかAlteraの「Stratix」というのはハイエンドFPGAで、MCUは要らないというか、アプリケーションプロセッサが求められており、Cortex-M1では力不足だった(そしてSpartanとかCycloneにはCortex-M1は大きすぎた)のが理由かと思われる。 　ただその後、FPGAは急速にその容量を増やすとともに、これまで「ASIC or ASSP+FPGA」という構成を「FPGA単体」でこなす、という方向性にシフトし始める。ふんが先生の言う「闇落ち」に通じる道である。こうなるとMCUではなくアプリケーションプロセッサが必要ということになる。 　Xilinxは2002年に「Virtex-II Pro」シリーズで「PowerPC 405」を搭載。2006年の「Virtex-5 FXT」では「PowerPC 440」に置き換えるが、その後継となる2011年の「Zynq」では「Cortex-A9」に変更。以後、Cortex-AとCortex-Rコアを搭載するSoC FPGAシリーズをラインナップし、最新のVersalシリーズもこれに倣っている。 　Alteraも2011年にCortex-A9を搭載する「Arria V」と「Cyclone V」をリリース、現在のハイエンドである「Agilex」にも引き継がれている。 　ちょっと違う方向に行ったのがActelだ。Microchipによる買収後、同社のFusion FPGAはCortex-M3を統合したものとなった。Latticeは引き続き低容量FPGAのマーケットに留まったため、こうしたアプリケーション統合という話にはなっていない。要するに、MCUはソフトCPU IPを使って対応し、アプリケーションプロセッサはハードコアIPを実装、というのが2017年頃までのトレンドになっていたわけだ。そしてそのソフトコアIPを使ったMCUマーケットは、各社独自のものを使っており、互換性は皆無だった。 　この動向が変わり始めたのは、RISC-Vが登場したタイミングである。最初に飛びついたのはMicrochipであり、SiFiveから「E31」コアの提供を受け、これを「MI-V」というソフトコアIPとして提供を開始する。そして「SmartFusion」の後継製品として投入された「PolarFire」には、ハードコアのRISC-Vを実装するようになった。 　さすがにIGLOOクラスにはMI-Vであっても実装は不可能なので、こうした小容量に関しては切り捨てざるを得なかったのだろうが。 　次がLatticeで、「Lattice Propel」と呼ばれる新しい開発環境の上でソフトコアのRISC-Vの提供を2021年からスタートしている。同じ2021年、IntelはNIOS-IIの後継としてRISC-V対応のNIOS V/mの提供を開始した(こちらでもちょっと触れている)。最後に残ったのがXilinxであるが、こちらも2023年11月に「MicroBlaze V」というRISC-V対応ソフトコアの提供を開始した。 　つい最近だが、FPGAのスタートアップである米Efinixは4月8日に「Titanium Ti375」という製品を発表した。こちらは35K～1M LUTで、他社で言えばミドルレンジ～ハイエンドの下の方といった位置付けだが、アプリケーションプロセッサとして1GHz以上で駆動される4コアのRISC-Vコアを実装しているそうだ。 　要するに、いつの間にかFPGA向けのMCUのマーケットは100% RISC-Vベースになり、さらにアプリケーションプロセッサのマーケットにも次第に進出しつつあるということである(MicrochipのPolarFireもMMU付きRV64GCコア×4と、Monitor用のRV64IMACコアから構成されていて、これは明らかにアプリケーションプロセッサ向けである)。マーケットとしてはそんなに大きくないのかもしれないが、マーケットを完全に押さえたという意味では、新たな金城湯池を獲得したと言って良いのかもしれない。