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

SoC技術論　リファレンスボードを参考に最後の調整

新規SoCはトライ＆エラーの繰り返し
ただし既存SoCでは商品競争力に欠ける

　ドキュメントの改定や回路の改定は、生産後も延々と続くことになる。これは当然モデルに関してもいえる。本来あるべきモデルを最初にきちんと完成させ、あとはそれに従って粛々と論理設計→物理設計を進める、という開発が一番手戻りが少ない。

　だが実際には、論理設計からもう一度モデルの修正をかけたり、物理設計から手戻りすることも往々にしてありえる。当然この場合、顧客に提供するモデルも修正の必要がある。

　顧客は頭を掻きむしりながら新しいモデルをシミュレーターにインストールし、これまで作ってきたソフトウェア、あるいは自分達で作り上げたモデルがそのまま通るかどうかの確認をしながら必要に応じて修正することになる。

　こうした作業は、いわゆる「枯れたSoC」を使う限りまず発生しない。枯れた、というのは量産出荷からだいぶ時間が過ぎ、すでに搭載製品も多く出荷され、きちんと動くことと、ドキュメントやソフトウェアが正しいことが検証されている、という意味である。

スマホの定番CPUといえばQualcommの「Snapdragon」がまず挙げられる

　問題は、そうした「枯れたSoC」は商品競争力が失われつつあることだ。PCなら新しいCPUを入手したらそれを既存のCPUと差し替えるだけですぐに出荷できる。ところがスマホやタブレットの場合、SoCを入手してから出荷するまで早くて半年、普通は1年程度を要する。つまり「今が旬のSoCを入手して作り始めてたら遅い」というのが、PCとの大きな違いである。

　これはソフトウェアについても同じだ。スマートフォンのベンダーは、SoCを選択する時点でどんなソフトウェア構成にするかを決める。必要なソフトウェアのうち、どの程度はBSP（ボード・サポート・パッケージ）やSoCベンダー提供のものに頼り、どの程度を自分達で作るかを決めるわけだ。それに沿って自分達で作るものは設計に入る。

　一方、SoCベンダーからのものはそれを動かすためのシミュレーターやリファレンスボードを用意して待つわけだが、中には「いくらまってもSoCベンダーからBSPが来ない」「BSPが来たけど動かない」「修正依頼を出しても対応してくれない」などのよくありがちな話が発生する。

　こうした状況にある場合、SoCベンダーのソフトウェア部隊も多忙になっていて、全然手が廻らないことが多い。そうした場合、結局自分たちでLinuxを移植して、できるところを先に進めることになる。例えばターゲットOSをKitkatと決めれば、それがBSPベースのものであろうと、自分たちで移植したものであろうと、Kitkatそのものに違いはないため、アプリケーションの開発はその上で可能になる。

　中には、SoCベンダーと守秘義務契約を結んだ上で、本来非公開であるソースをSoCベンダーから出させ、それを元にデバッグを行なったり、自分たちで修正用パッチを作ってSoCベンダーに戻す事例もある。

　こうしたSoCベンダーとスマートフォンベンダーの協業は、スマートフォンベンダーの量産出荷までの間延々と続く。問題は、こうした協業がスマートフォンベンダーの数だけ発生するため、SoCベンダーの方はこれが一段落するまで延々と振り回されることだ。

　Alpha Customerという形で特定のベンダーに絞り込むのは、数を絞り込まないとSoCベンダー側の対策が間に合わないから、という側面もあるのは事実である。