ソフトウェアの壁が独立系プロセッサーIPベンダーを困らせる RISC-Vプロセッサー遍歴

独立系のプロセッサーIPベンダーに 立ちはだかるソフトウェア提供の壁

　今回のRISC-Vプロセッサー遍歴は前回の続きから。なぜ独立系のプロセッサーIPベンダーはソフトウェアエコシステムの発展に期待したか？　というと、それぞれのベンダーが最低限のソフトウェアを提供するような環境では、市場に限界があるからだ。

　具体的に言えば、自動車や航空機、医療・産業などの要求水準が高い市場には、そのままでは販売ができない。もちろん自動車といってもピンキリであって、例えばカーオーディオ(すでに死語な気がするが)向けのコントローラーや「昔の」カーナビ向けなどであればまだ可能性があるが、パワーステアリング用のコントローラー向けには絶対に採用されない。

　カーオーディオや「昔の」カーナビであれば、それが壊れたからといって運転に直接的な支障が出るわけではないし、それが壊れることで人が死んだりはしない。こうした用途であれば、車載向けの信頼性規格であるAEC-Q100(環境ストレスや加速寿命、パーツアセンブリ保全、ダイレベル信頼性などいくつかのテスト項目があり、それぞれ細かくテスト項目が決まっている)を満たせば採用できるし、この際にAEC-Q100を取得するのはプロセッサーIPベンダーではなく、そのIPを使ってASICを起こす顧客の側であるから、こうした用途向けには採用されてきていた。

　ただし当たり前であるが、こうしたASICは単価が安いので、プロセッサーIPベンダーに入る売上もそれほど大きなものではない。前回書いたようにこうした独立系プロセッサーIPベンダーは価格の安さを売りにしているのは間違いないが、それは顧客の販売するASICコストそのものが安いからである。

　ところが安全性に対しての要求の高いところ、それこそ自動車や航空機などの操縦系統、大規模プラントなどに使われる安全性が要求される制御系統、医療機器の中でも生命に直結するようなもの(例えば薬液の注入の制御など)などは、高い安全性が要求されるがゆえに、コストも当然それなりに跳ね上がる。こうしたコストの高い用途に使われるASIC向けであれば、プロセッサーIPの価格も相応に引き上げ可能になる。売上を伸ばそうとしたら、こうした安全規格に対応できるものを提供しないといけない。

　ここに立ちはだかるのがソフトウェアの壁である。安全規格に準拠するためには、単にプロセッサーそのものが故障しない、エラーを起こさないというハードウェア的な配慮だけでは不十分で、「そのうえで動作するソフトウェアでもバグを起こさない」ことまで配慮しなければいけない。要するにプロセッサーが完璧でも、その上で動くソフトがバグだらけだったら、安全上問題だからだ。

　このために、バグを生成しにくい、そしてバグを早期に発見、除去につなげられるようなソフトウェア開発ツールが要求される。自動車ではMISRA(Motor Industry Software Reliability Association)という団体が策定した、プログラムの記述規約であるMISRA-Cや、構造的にバグを生成しないことが証明されている開発ツール(MBD:Model-Based Designと呼ばれるものがこの代表例である)、記述したソフトウェアを静的に検証するツールやCD/CI(Continuous Integration／Continuous Delivery)と呼ばれる開発環境がこうした目的で利用されるわけだが、こうしたツール類が動かないと安全性が求められる用途にプロセッサーIPを販売できない。

　ちなみにこうしたツール類はまとめて一社で提供されているわけではなく、さまざまな会社が提供しているものを組み合わせて使う、というやり方が一般的である。もちろんOSがバグられても困るので、こうした安全規格に対応した専用のOSがRTOSメーカーなどから提供されている。ということは、そうした専用のOSに自社のプロセッサーIPをサポートしてもらう必要がある。

　ということは、こうしたツール類やOSを提供しているメーカーを巻き込んで、自社のプロセッサーIPの対応をしてもらわないといけないことになるが、当然これはコストがかさむ。ツールメーカーの側としても、新アーキテクチャーを継続的にサポートするためには相応のコストが掛かるので、そのアーキテクチャをサポートすることで伸びる売上がそれに見合ったものでない限りは、サポートを嫌がる。

　したがって、コストをプロセッサーIPベンダー側で負担するなどの方策が必要になってしまう。これを数社に対して行なうだけで、弱小のプロセッサーIPベンダーの売上をはるかに超えるコストが掛かるだろう。

　もちろんそうしたツールまで自社で提供するという選択肢も技術的にはありえるが、現実問題としては不可能だろう。猛烈なソフトウェア開発の手間とコストがかかるからだ。

ソフトウェアエコシステムが発展すると 新しい分野に参入できる可能性が増える

　こうしたことが理由で、これまで独立系プロセッサーIPベンダーは(ごく少数の例外を除き)安全性の高い分野への参入ができず、低価格のプロセッサーIPを提供するに留まっていた。

　ところがRISC-Vが来たことでこの構図が変わると考えたわけだ。先に挙げたツールベンダーがRISC-Vに対応してさえくれれば、RISC-Vコアもそこで利用できることになるからだ。もちろんベンダーの側はアーキテクチャー対応でなく個別のコアごとに対応というかサポートを行なうのが普通なので、ちゃんと自社のプロセッサーIP上でそれらのツールが正常動作することを(ツールベンダーと共同で)確認する必要がある。

　こうしたコストは掛かるものの、それは新規アーキテクチャーへの対応を一から行なうよりははるかに安価で済む。端的に言えば、あるツールベンダーに「弊社のプロセッサーIPは×××社に採用されると見込まれるので、サポートを行なっていただくと×××社とその下受けの△△△社や□□□社、さらにその下の○○○社や※※※社などでも御社のツールを利用する可能性が高いです」という話を持ち込めばいいわけだ。こうした顧客が見込めるのであれば、ツールベンダーとしても積極的に対応する理由になり得る。

　実際のところ、SiFive、Andes Technology、Cortus、CodasipといったRISC-VプロセッサーIPメーカーが2020年あたりから相次いで自動車向けのIPソリューションを提供し始めたというのがこの傍証である。いずれも自動車向けの機能安全規格であるISO26262 ASIL-BやASIL-D対応(ASIL-Bは目標故障率が1億時間あたり1回未満、ASIL-Dは10億時間あたり1回未満)に対応したものである。

　もちろんこうした低故障性を実現するためには、それなりの回路技術が必要になるので誰でも作れるわけではないが、それよりも難しかったのはそのプロセッサーIPをサポートするOSやハイパーバイザー、ツール類のサポートであり、この目途が立ったからこそより高価格で売れる自動車向けのプロセッサーIPを手掛け始めたのである。

　ちなみにこうした安全規格は産業・航空機・医療など分野別にそれぞれ別に定められている。例えば自動車向けのプロセッサーIPをそのまま産業用に販売することはできず、別途安全規格の認定取得(例えば産業用ならISO/IEC61508がこれに相当する)を取得する必要がある。

　ただISO26262とIEC61508がまったく異なる要件か？　というとそうでもなく、ハードウェア的には同一でもそれほど問題はなく、異なる規格に対応するための書類が膨大に必要、という程度の話である。だから自動車向けにきちんと動作するプロセッサーIPが完成したら、次はそれを異なる分野に持っていくという横展開も可能である。

　「可能である」という表現なのは、実際には自動車/産業/航空宇宙/医療などでは分野別にプレイヤーも違えばユーザーのニーズも異なり、しかも専属のサポートチーム(FAE:Field Application Engineer)を要求されるので、かなりの大企業でもないと複数分野向けに展開しきれないという現状があるからで、各社ともに自社の体力を睨みながら少しづつ展開先を増やす、という感じになっているが、これはRISC-Vとは関係ない話である。

　いずれにせよ、独自ISAを捨ててRISC-Vを採用することで、こうした新しい分野に参入できる可能性が増えたというのがわかるだろう。こうした独立系のプロセッサーIPベンダーが前のめりだった理由がこれである。

ある程度技術力と資本力のあるメーカーにとって RISC-Vは技術力の蓄積とコスト削減の両方を図れる

　もう1つ前のめりだったグループが、NVIDIAやMicrosemi、Western Digitalなどだった。これらの企業はすでにASIC(Microsemiの場合はFPGA)を自社で製造、販売しているベンダーである。

　一例としてWestern Digitalの場合を説明すると、同社はHDD用のコントローラーを自社で開発・生産しているし、2018年頃になるとHDDに加えてフラッシュ・ストレージも増えてきている(2016年4月にSanDiskを買収、同社のフラッシュ・ストレージ製品を傘下に加えたため)。

　さて、昔はストレージ(HDD/フラッシュを含むすべて)はある意味単純であり、単に高速にアクセスできれば良かったのだが、2018年頃になると目的別のストレージ階層が必要になってきた。

　この頃には、例えばクラウド向けにホット・ストレージ(容量は小さいがアクセス頻度が多く、高速アクセスできるもの)とコールド・ストレージ(容量は大きいがアクセス頻度が低く、アクセスに時間がかかるもの)と、その中間のウォーム・ストレージといった階層を設けようなど、特定の目的に向けたストレージ(これはその後、コンピュート・ストレージと呼ばれる、データ処理機能を持つストレージにつながっていく)を作ろうといった具合に、さまざまなニーズが想定されるようになってきた。

　こうなるとコントローラーに求めらえる要求も変わってくることになる。

Western Digitalが2018年6月に行なったRISC-Vに関する説明会の資料より。ストレージに対するニーズが多彩化したことで、それに合わせてコントローラーも多彩化される必要が出てきた

　下の画像はストレージというよりも一般的な話であるが、例えばコンピュート・ストレージでこうした用途に必要なプロセッサーを求めようとすると、すでに汎用品では追いつかないということになる。

機械学習はコンピュート・ストレージとは縁遠そうであるが、分析やセキュリティ検出などはストレージ側である程度前処理をしておくことで処理性能の向上が図れそうな分野である

　もともとWestern DigitalはCPU IPを他社(SynopsysのARCプロセッサー)から購入して自社のコントローラーに採用していたが、今後さらに性能を拡充していくとなると、それに応じた性能の拡充が必要である。さらに言えば、高性能化するにあたって汎用コアだけでなく専用アクセラレーターを追加し、これをコアから高速にアクセスするといった拡張性がある方が好ましい。

　もちろんARCコアにも命令拡張機能はあるが、どのみちアクセラレーターを自社開発するのであれば、それをサポートする命令は自分たちで開発する必要があるので、別にARCでなくRISC-Vであってもまったく困らない。もちろんRISC-Vをモノにするには開発費が余分にかかるが、その代わり自社で開発できればライセンス費もロイヤリティもかからないので、ある程度の数量が出れば割安になる。

一点だけ突っ込んでおけば、16bitには未対応だと思う。いや縮小命令セットの話をしているのかもしれないが

　もっと重要なのは、技術力があるメーカーにとっては、自社でCPUを作るという貴重な機会が生まれることになる。エンジニアの育成にもつながるし、自社にもノウハウが溜まる。先端のアプリケーションプロセッサー向けという話であれば、例えばSamsungが開発コストの高騰に耐えきれずにExynos M7の開発を中止したように、けっこうなコストがかかる話になるが、Western Digitalが狙っているのはもう少し組み込み寄りのプロセッサーであって、そこまでコストがかからない。こうした用途向けにRISC-Vを採用することで、以下のメリットがある。

• 基本的な命令はRISC-Vを踏襲することで、設計の手間を省ける
• 拡張命令を自由に追加できる
• 基本命令がRISC-Vのままなので、既存のRISC-V対応のソフトウェアはそのまま稼働し、あとは拡張命令部分だけ追加対応すればいい
• 実装の方法に制限はない。また参考になる実装(Rocket、Boom)も存在する

　実際Western Digitalは2018年にはまずSweRV EH1と呼ばれるIn-Order/2-wayで8段パイプラインのコアを開発、これに続きSweRV EL2/EH2を2019年に開発している。

2019年ごろ公開されたWestern Digitalのロードマップ

　SweRV EL2/EH2は、EH1の改良版となるイン・オーダーのコアだが、EH2の方はSMTに対応するなど、少しづつ機能を向上させている。このSweRV EH1/EL2/EH2はChips Allianceとの共同開発なのもあり、オープンソースでGitHubに公開されているが、より性能を向上させたSweRV EHX3を2021年のRISC-V Summitで発表している。こちらはCortex-R82と同程度の性能とされており、ストレージ・ワークロード向けに最適化されたコアとなっている。

　NVIDIAも同様で、詳細は明らかにしていないがGPUの内部制御用に独自のRISC-Vコアを開発している。同じことを考えたImagination TechnologiesはやはりRISC-Vコアの開発を手がけるが、それが行き過ぎて(?)Catapultと呼ばれる独自のRISC-VコアのIPライセンスまで始めてしまった。

　ある程度技術力と資本力のあるメーカーにとっては、RISC-Vは技術力の蓄積とコスト削減の両方を図れる選択肢であり、これが前のめりになった理由になっている。