独立系のプロセッサー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ベンダーの売上をはるかに超えるコストが掛かるだろう。
もちろんそうしたツールまで自社で提供するという選択肢も技術的にはありえるが、現実問題としては不可能だろう。猛烈なソフトウェア開発の手間とコストがかかるからだ。
この連載の記事
-
第801回
PC
光インターコネクトで信号伝送の高速化を狙うインテル Hot Chips 2024で注目を浴びたオモシロCPU -
第800回
PC
プロセッサーから直接イーサネット信号を出せるBroadcomのCPO Hot Chips 2024で注目を浴びたオモシロCPU -
第799回
PC
世界最速に躍り出たスパコンEl Capitanはどうやって性能を改善したのか? 周波数は変えずにあるものを落とす -
第798回
PC
日本が開発したAIプロセッサーMN-Core 2 Hot Chips 2024で注目を浴びたオモシロCPU -
第797回
PC
わずか2年で完成させた韓国FuriosaAIのAIアクセラレーターRNGD Hot Chips 2024で注目を浴びたオモシロCPU -
第796回
PC
Metaが自社開発したAI推論用アクセラレーターMTIA v2 Hot Chips 2024で注目を浴びたオモシロCPU -
第795回
デジタル
AI性能を引き上げるInstinct MI325XとPensando Salina 400/Pollara 400がサーバーにインパクトをもたらす AMD CPUロードマップ -
第794回
デジタル
第5世代EPYCはMRDIMMをサポートしている? AMD CPUロードマップ -
第793回
PC
5nmの限界に早くもたどり着いてしまったWSE-3 Hot Chips 2024で注目を浴びたオモシロCPU -
第792回
PC
大型言語モデルに全振りしたSambaNovaのAIプロセッサーSC40L Hot Chips 2024で注目を浴びたオモシロCPU -
第791回
PC
妙に性能のバランスが悪いマイクロソフトのAI特化型チップMaia 100 Hot Chips 2024で注目を浴びたオモシロCPU - この連載の一覧へ