ロードマップでわかる！当世プロセッサー事情

第745回

ソフトウェアの壁が独立系プロセッサー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ベンダーの売上をはるかに超えるコストが掛かるだろう。

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