独立系のプロセッサー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ベンダーの売上をはるかに超えるコストが掛かるだろう。
もちろんそうしたツールまで自社で提供するという選択肢も技術的にはありえるが、現実問題としては不可能だろう。猛烈なソフトウェア開発の手間とコストがかかるからだ。
![](/https/ascii.jp/img/blank.gif)
この連載の記事
-
第811回
PC
Panther Lakeを2025年後半、Nova Lakeを2026年に投入 インテル CPUロードマップ -
第810回
PC
2nmプロセスのN2がTSMCで今年量産開始 IEDM 2024レポート -
第809回
PC
銅配線をルテニウム配線に変えると抵抗を25%削減できる IEDM 2024レポート -
第808回
PC
酸化ハフニウム(HfO2)でフィンをカバーすると性能が改善、TMD半導体の実現に近づく IEDM 2024レポート -
第807回
PC
Core Ultra 200H/U/Sをあえて組み込み向けに投入するのはあの強敵に対抗するため インテル CPUロードマップ -
第806回
PC
トランジスタ最先端! RibbonFETに最適なゲート長とフィン厚が判明 IEDM 2024レポート -
第805回
PC
1万5000以上のチップレットを数分で構築する新技法SLTは従来比で100倍以上早い! IEDM 2024レポート -
第804回
PC
AI向けシステムの課題は電力とメモリーの膨大な消費量 IEDM 2024レポート -
第803回
PC
トランジスタの当面の目標は電圧を0.3V未満に抑えつつ動作効率を5倍以上に引き上げること IEDM 2024レポート -
第802回
PC
16年間に渡り不可欠な存在であったISA Bus 消え去ったI/F史 -
第801回
PC
光インターコネクトで信号伝送の高速化を狙うインテル Hot Chips 2024で注目を浴びたオモシロCPU - この連載の一覧へ