公開日：2026年03月09日
| 更新日：2026年03月11日

SoC製品の技術記事のサムネイル。BGA半導体チップをイメージ。シンプルなデザイン。複数提案して2。

初めてのSoC製品導入：押さえておきたい基礎知識

ライター：daisuke ariga
プロセッサー

はじめに

近年、様々な機器が高度化、高機能化していく中で、制御を担うCPUの性能も著しく向上しています。
その為、次世代製品の開発に向けてMCUによる制御から、より高機能なSoCを採用するお客様が増えています。
しかし、SoCを用いた製品開発や評価において、具体的に何から始めるべきか迷われる方もいらっしゃいます。

本記事では、SoC製品の評価や開発に必要となる主要な技術的ポイントと関連用語について解説します。

SoCとは

SoCはSystem on Chipの略称です。
その名の通り、特定のシステムに必要な機能を1つの半導体チップにまとめたデバイスです。
MCU(Microcontroller Unit)との違いは、汎用用途ではなく（MCUも一部用途向けは存在します）
特定の用途(アプリケーション)向けに開発されたデバイスである点です。

産業/通信、民生、車載等、SoCの対応用途は多岐にわたりますので、
デバイス選定の際には、用途に沿ったデバイス/シリーズを選定する必要が有ります。

MCU制御との相違点

続いてMCUによる制御との主な相違点を説明します。

①内蔵Flashメモリの有無

MCU(Micro controller Unit)には、プログラム格納用の不揮発性メモリ(Flash)を内蔵していることが一般的です。
電源投入後、MCU内蔵の不揮発性メモリからCPUが直接プログラムを実行する仕組みになっています。
一方で、多くのSoC(System on Chip)は内蔵の不揮発性メモリを持たず、外部の不揮発性メモリに予め
プログラムを配置しておき、電源投入後のブートシーケンスで高速な実行メモリ(DDR等)にプログラムを展開し、実行します。

■プログラム実行メモリの違い

②OS(Operating System)の有無

近年ではMCU制御においてもOSを使用するケースが多く在りますが、
小規模なシステムや長期的に運用されている装置等では、依然Non-OSでの制御が行われています。
一方でSoCを用いた制御では、複数機能に跨る大規模なシステムとなる事が多く、OSの実装は必須と考えられています。

■OS有無による制御イメージ

OS(Operating System)の役割と選択

OSの役割

SoC制御でOSを使用する際の、主な役割を解説します。

①タスク管理

組み込みOSの最も基本的な役割で、複数の処理(タスク)を効率よく動かす為の管理を行います。
SoCシステムでは複数機能を同時に実行する場合の優先度管理、タスク切り替え、状態監視(実行、Wait、終了)
といった複雑な管理が求められる為、OSがその役割を担います。

②ハードウェア制御の抽象化（OS経由のデバイスドライバ制御）

SoCが持つ機能は多く、各機能の制御ソフトを1から作るのは、非常に手間が掛かります。
各機能に対応したソフトウェア(デバイスドライバ)をOS経由で制御する事により、アプリケーションコード内の
ハードウェア依存コードを削減し、移植性を高めると共に機能を扱い易くします。

③リアルタイム性の確保（必要に応じて）

重要な通信やモータ制御など、処理「時間」や実行タイミングの管理が重要になるアプリケーションには、
各タスクを決められた時間内に処理し、遅延の少ない動作を実現するためにRTOS(RealTimeOS)が導入されます。

④その他

他にもメモリリソースの管理やメモリ保護、セキュリティ機能の実装など、必要に応じて様々な処理を行います。

以上の様な役割をOSが担ってくれる事で、
ユーザは製品のアプリケーションソフトウェアの開発に注力する事が出来ます。

OSの選択

使用するOSの選択は、用途やシステム要件により異なりますが、
一般的に広く利用されているのOSの一つに「Linux OS」が有ります。
LinuxはOSS(オープンソース)OSであり、カーネルが無償提供されている為、評価開始時の費用を抑えることが出来ます。

検討例としては、LinuxOSをベースに評価を開始し、システム側で必要となる機能や、品質/サポートに応じて、
Linuxをそのまま使用して量産するケース、Linux＋他OSを併用するケース、他のOSへ切り替えるケース、
Linuxは使用せずシステムに応じたOS選択を行う、といった様々なケースが考えられます。

■OS導入の流れ

リファレンスボード(評価ボード)の選択

続いてリファレンスボードの選択について説明します。
SoC製品も各社からリファレンスボード(評価ボード)が準備されています。

選定時の注意点としては、SoCのリファレンスボードは多くの場合、
そのSoCがターゲットとしている用途(アプリーケーション)向けに開発されています。
その為デバイス選定の段階で、準備されているリファレンスボードの仕様を確認し、
システム評価に必要なInterface(コネクタ等含む)が実装されているか、拡張性の有無などの確認を行います。

また、SoC周辺では高周波設計が必要となる場合が多い為、
メーカからリファレンスボードの回路図、高速IFのレイアウト、クロック/電源設計などの技術情報が
どの程度提供されているか、といった確認も重要となります。

BSP（Board Support Package）の利用

続いて、BSP（Board Support Package）について説明します。

BSPとはリファレンスボードを動作させる為の基盤となるソフトウェアパッケージです。
SoCのブート(起動)、OS連携動作、機能制御といった一連のフローにおいて、
ベースとなるソフトウェアのパッケージです。

これを用いる事で、リファレンスボードでの評価を行う際、
SoCの機能を制御するドライバソフトを、OSと組み合わせて実行できるようになります。

提供の方法や対応OS、サポート形式等はメーカにより異なりますが、
ベーシックなBSPとして、汎用OSであるLinux＋リファレンスボードの組み合わせを想定し提供しているケースが多いです。
また、SoCがターゲットとしている用途に応じてAndroidやRTOS、その他OS向けのBSPが提供されている場合も有ります。

■Application、OS、BSPのレイヤイメージ（Linuxの例）

評価環境の構築/実行

ここから一例としてLinuxBSPをベースとした評価ボード環境の立ち上げに必要なポイントを説明します。

Linux環境のビルド

近年、SoCメーカで用意している組込みLinux用のBSPは、
YoctoProjectのレイヤ（レシピの集合）として提供されていることが多く、
提供されたままの形ではリファレンスボードに使用する事が出来ません。

また、リファレンスボードで使用する為にはPC上でLinux環境を構築し、ビルドを実施する必要が有ります。
ビルドに用いるPC環境は一般的にUbuntuPCが推奨されています。

[YoctoProjectのレイヤ]
主に組み込み用のLinuxシステムを構築するためのレシピや設定を機能毎にまとめた物。
SoCメーカのBSPもこのレイヤとして提供される事が一般的です。

[UbuntuPC]
Linux ベースの OS「Ubuntu」を搭載した開発用PCです。
YoctoProjectなどの組込みLinuxをビルドするホスト環境として広く利用されています。

用意したUbuntuPCをホストとして、メーカから提供されたBSPのLinux環境をビルドする事で、
リファレンスボード用の、カーネルイメージ、デバイスツリーファイル、ルートファイルシステムなどを生成します。

また、Linux BSPの入手先は、GitHub上に公開されている事が一般的です。

[GitHub]
ソフトウェア開発やプロジェクト管理に特化したWebサービス。
Gitと呼ばれるバージョン管理システムを基盤として、ソフトウェアなどを保存・共有・公開に利用されている。

■BSP入手～ビルド実行イメージ

起動(ブート)方法の検討

続いて、前項で生成したイメージファイルを、PCからリファレンスボードに転送し、起動(ブート)する方式を選択します。
選択できるブート方式はリファレンスボードやSoCの仕様にも依存しますので適切な方法を選択します。

一般的には、以下のようなブート方法から選択/検討を行います。

[メモリブート]
評価ボード上の不揮発性メモリに書き込み、そこから読み込み起動する方法

[ネットワークブート]
PC上からEthernet等のネットワーク経由で読み込み、起動する方法

■メモリブートイメージ図

・SerialFlashMemory　・NAND Flash　・SD/eMMC
といったリファレンスボード上のメモリにイメージファイルを書き込み、そこから起動(ブート)を行います。

■ネットワークブートイメージ図

イメージファイルを生成したPCとリファレンスボードをEthernetケーブルで接続し、
Ethernet経由で起動(ブート)を行います。

ブートプログラムの役割

検討したブート方法に応じて、評価ボード上のDipSW等で起動設定等を行い、
評価ボード電源を投入するとSoCのブートシーケンスが起動します。

この際、重要な役割を担うのがブートプログラムです。
ブートプログラムは、SoCを起動する為のプログラムで、大まかには、以下の様な順番で実行されていきます。

※以下に示す例はメモリブートの一例です。
（SoCのブート仕様等により異なる場合が有ります）

①SoCの内蔵ROM(※)に格納されている最初のブートプログラム(stage1)が起動します。

[役割]
最低限のSoCハードウェア設定を行い、
次ステージ(stage2)のプログラム(Initial Program Loader)を内蔵RAMに転送します。

※多くのSoCは内部に起動用の内蔵ROMが有り、ブートプログラム(stage1)が内蔵されています。

■Boot ROM Programの実行

②Stage2のInitial Program Loaderが内蔵RAM上で実行されます。

[役割]
DDRメモリの初期化や周辺機能設定をStage2で行い、KernelImage(OS)やU-Boot(Stage3)プログラムを
外部FlashからDDRメモリに転送します。

③転送されたStage3のプログラム(U-boot)がDDRメモリ上で実行されます。

[役割]
OS(Kernel)の起動～アプリケーション実行を行います。

このようにOS/アプリケーションを起動するまでの間、
SoCのブートシーケンスはいくつかの階層(stage)に分かれて実行されていきます。

必要に応じてセキュリティ設定やプログラムの検証といった作業もこれらのブートシーケンスで実施されます。
ブート仕様や実装方法はSoCメーカやデバイスによって異なる場合が有る為、
詳細についてはSoCベンダから提供される仕様書や、StartUpガイド等をご参考ください。

[U-Boot]
Linux組み込みシステムで汎用的に使用される目的で提供されているオープンソースのブートローダー。
Linuxカーネルを起動と準備(転送や設定)、コンソール機能等を持つ。

コンソールプログラムの利用

上記のブートシーケンスを構築する中で、OS起動前に、

・SoCの機能設定が正常か
・SoC周辺のメモリ操作を行いたい

といった場合に必要となるコンソール機能を持つソフトも提供されています。

一般的には先ほどStage3で登場したU-bootと呼ばれるオープンソースブートローダに
含まれるコンソール機能や、各SoCベンダから提供されるコンソール機能ツールを用いる場合も有ります。
SoCが正常にブートしない場合の簡易デバッグ等にも用いられるツールです。

まとめ

如何でしたでしょうか。
SoC製品導入に必要な用語やPointの解説をさせて頂きました。
SoCの検討StepやMCU製品との違いのイメージをご理解頂けたのではないかと思います。
ご検討の一助となれば幸いです。

今後も製品の高機能化や複数機能の集約が進んでいく中でSoC製品の導入を検討する場面は増えていくと
想定されます。弊社では製品選定から開発支援までトータルに技術サポートを行っておりますので、
是非お問合せ下さい。

エコシステム、パートナー

SoCの導入にあたっては、様々なパートナ企業様による開発サポート体制が提供されています。
・商用OSの提供やインテグレーション、特定の機能に特化した開発支援ツール、ソフトウェア提供
・開発環境立ち上げからPOC開発サポート
・ユーザシステムに応じたアプリケーション開発支援

等々、パートナ支援を活用した開発を実施されているお客様も多くいらっしゃいます。
弊社からのご紹介も可能ですので、併せてご検討ください。

Renesasの車載SoCラインナップ

Renesasでは自動運転、ADAS、コックピット等の幅広いアプリケーションに向けたSoCとして、
「R-Carファミリ」をラインナップしております。
お客様向けの評価ボード等もご準備しておりますので是非ご検討下さい。

R-Car自動車用SoC (System-on-Chip) | Renesas ルネサス

お問合せはこちら