AIアクセラレーター¶

はじめに¶

一部のSF32デバイスは、対応するニューラルネットワーク演算をオフロードする AIアクセラレーターを備えています。SDKではNNACCと呼ばれ、クラウドサービスに依存せずデバイス上で推論するエッジAIに利用できます。レイテンシ、CPU占有時間、エネルギーが減るかどうかは、モデル、メモリー配置、ソフトウェア実装、製品全体の負荷によって変わります。

ウェアラブル機器、健康モニタリング機器、スマートディスプレイ、音声対応アクセサリー、センサーフュージョン、小型AIoT製品などが用途の候補です。バッテリー駆動の機器ではBluetooth、グラフィックス、音声、センシング、ユーザー操作が同時に動くことがあります。対応演算をハードウェアに任せると他のタスクにCPU時間を回せる可能性がありますが、応答性や省エネルギー効果は実測で確認します。

利用できるAI機能は、具体的なSF32デバイスとSDKの対応状況によって異なります。モデルの構成やメモリー配置を決める前に、対象チップのデータシート、リファレンスマニュアル、SDKドキュメントを必ず確認してください。

以下に示すCMSIS-NN演算の説明とデバイスごとのNNACC数は、SiFli-SDK v2.5.1のドキュメントに基づいています。同バージョンのNNACCガイドにはSF32LB55x/56x/58xのリソースが記載されていますが、SF32LB52xまたはSF32LB57xへの搭載は確認できません。記載がないことを非搭載の根拠にしないでください。アドレスウィンドウの検査、完了待ちの動作、GC032Aの設定は同バージョンのHALまたはドライバーのソースから確認した内容であり、すべてのチップリビジョンやSDKバージョンに共通する保証ではありません。参照したNNACCガイドとサンプルからは、モデル全体の変換ツールや計算グラフランタイム、自動CPUフォールバックの提供、すべての品番・ボードでのカメラ取り込み対応までは確認できません。設計を確定する前に、正確なSDKリビジョンと構成、チップリビジョン、ランタイム、ボードで確認してください。

このページでは、選定したSF32デバイスでローカルAI機能を実現できるか、また推論処理をセンサー、CPU、メモリー、アクセラレーターにどう分担させるかを説明します。モデルの統合とデプロイ手順については、先にAI概要を参照してください。

オンデバイスAIが重要な理由¶

多くの組み込み製品では、生データをスマートフォンやクラウドサービスへ常時送信せずに、状況に応じた処理を行う必要があります。オンデバイスAIには、次のような利点があります。

• レイテンシを低減できる可能性があります。端末内で推論すればスマートフォンやクラウドとの往復を避けられますが、センサー入力から判断までの全体レイテンシは製品上で測定してください。
• プライバシーを向上できます。生の生体情報、音声、モーションデータをローカルに保持できるためです。
• 無線トラフィックを削減できます。イベントや要約のみを送信すればよいためです。
• オフラインでも動作を継続できます。ネットワークに接続していなくても主要機能を維持できるためです。
• 精度と検出範囲が同等で、同じ使用時間における機能全体のエネルギーが減る場合に限り、平均消費電力を抑えられます。オフロードに伴う負荷も含めて比較してください。

ウェアラブルやAIoT機器では、こうした利点が製品機能に直結します。たとえば時計は、ジェスチャーや活動状態の分類、健康信号の監視、簡単な音声トリガーの認識、センサーデータの処理を行いながら、ディスプレイ、Bluetooth、アプリケーションプロセッサーの応答性を保てます。

これらの効果には条件があります。ローカル処理で無線通信量が減るのは、製品が生データを送らない場合です。プライバシー保護には、適切な保存方法、アクセス制御、送信データの保護も必要です。以下の用途は設計の候補であり、SDKに対応モデルがすべて用意されているという意味ではありません。

SF32システムにおける位置づけ¶

SF32におけるエッジAIの処理は、概ね次のように進みます。

センサー／オーディオ／カメラ
        │
        ▼
前処理
  - フィルタリング
  - フレーミング
  - 正規化
  - 特徴抽出
        │
        ▼
ファームウェア／推論ランタイム
  - モデルグラフの制御
  - NNACC対応の演算
  - その他の演算は、実装がある場合にCPUで実行
        │
        ▼
後処理
  - しきい値処理
  - 平滑化
  - イベント検出
  - アプリケーションの判断
        │
        ▼
アプリケーション、UI、Bluetooth、またはストレージ

アクセラレーターはAI処理全体の一要素にすぎません。実際の製品では、データの取得とバッファリング、前処理、推論のスケジューリング、後処理、アプリケーション側の判断も必要です。推論を単独の関数呼び出しとして扱うのではなく、メモリー階層や利用可能なアクセラレーターを踏まえて処理全体を設計することが、性能向上につながります。

AIアクセラレーターが行うこと¶

多くのニューラルネットワーク処理では、同じ数値演算が何千回、何百万回も繰り返されます。代表例は、畳み込み、行列乗算、ベクトル演算、活性化関数、プーリング、その他の固定小数点演算カーネルなどです。AIアクセラレーターは、選択したカーネルを汎用CPUより高い電力効率で実行できます。

これらはニューラルネットワークで使われる計算の例であり、SF32 NNACCの対応演算一覧ではありません。SiFli SDK v2.5.1のNNACCガイドには、チャネルごとに処理する畳み込み（depthwise convolution）を含む、3種類のCMSIS-NN q7畳み込み関数の高速化が記載されており、NNACC対応のCMSIS-NN実装はCMSIS-NNのARM DSP実装より8倍高速とされています。この数値のベンチマーク条件はガイドに記載されていないため、ベンダー公表の比較値として扱い、モデル全体のレイテンシや消費エネルギーが改善する保証とは見なさないでください。モデルの各演算子と数値形式が選択した実装に対応するか確認してください。行列乗算、活性化関数、プーリングがそれぞれ独立して高速化されるとは限りません。SDKにはアクセラレーターを直接制御するHAL APIもありますが、どちらのインターフェースにもモデル全体の変換ツールや計算グラフのランタイムが含まれるとは限りません。ファームウェアまたは別途選択した推論ランタイムが各層を管理し、バッファーを扱う必要があります。CPUにフォールバックする場合は、未対応の演算子の実装も必要です。

SF32デバイスのメモリー容量と帯域幅には限りがあるため、まずは小型の組み込みモデルを検討してください。対象となる品番でのNNACCの有無と演算子の対応範囲を確認し、処理全体のメモリー使用量、レイテンシ、エネルギーを測定してください。シリーズ名だけで対応状況を判断しないでください。

代表的なAI処理には次のものがあります。

• キーワードスポッティングまたは簡単な音声イベント検出。
• 加速度計とジャイロスコープのデータからのジェスチャー認識。
• 活動分類と動作状態検出。
• ウェアラブルおよび健康モニタリング機器向けのセンサーフュージョン。
• センサーとアルゴリズムのサポートに応じた生体信号解析。
• カメラ入力に対応したデバイスでの簡易な画像分類（カメラベースの分類を含む）。
• 異常検出とローカルイベントフィルタリング。

CPU、アクセラレーター、メモリーの役割¶

基本的な考え方は、CPUが処理全体を制御し、アクセラレーターが一部の計算負荷の高い演算を担うことです。

アクセラレーターはCPUの代わりにはならず、任意のモデルを単独で実行するものでもありません。ファームウェアは入力の準備、対応演算の設定、完了待ち、結果処理、アプリケーション制御を担います。非対応の演算をCPUで実行できるのは、選択したランタイムやアプリケーションにその実装がある場合だけです。実装がなければモデルを組み込めないことがあります。ハードウェアが存在するだけでは、自動的なCPUフォールバックは保証されません。

デバイスファミリーにおける位置づけ¶

ファミリー全体の性能順位ではなく、演算子の対応状況、メモリー予算、製品全体の負荷からデバイスを選びます。SDK v2.5.1のガイドには、SF32LB55xとSF32LB56xのHCPUサブシステムにそれぞれ一つ、SF32LB58xのHCPUとLCPUサブシステムにそれぞれ一つのNNACCが記載されています。これは選定材料であり、モデル全体の高速化や消費エネルギー削減を保証するものではありません。具体的な型番と構成について、利用可能な資源、アクセスできるメモリー、ソフトウェアの対応を確認してください。

この表は製品選定ガイドであり、データシートの代替ではありません。正確なアクセラレーターの利用可否、サポートされる演算子、メモリー制限、SDKツールは、選択した型番について検証する必要があります。

モデル開発フロー¶

組み込みAIの一般的な開発手順は次のとおりです。

1. 実際の利用環境を反映したデータを使い、開発用PCでモデルを学習するか、既存モデルを選びます。
2. モデルの選定、プルーニング、量子化、アーキテクチャの変更などにより、組み込みシステムの制約に合わせます。
3. 推論ランタイムとモデル表現を選択または実装し、演算子の対応範囲と数値形式が選択したSDKカーネルと互換か確認します。NNACC HALにモデル全体の変換ツールが含まれるとは限りません。
4. 変換と量子化の後、数値精度を検証します。
5. 前処理、推論、後処理をファームウェアに統合します。
6. 実際のハードウェア上でレイテンシ、メモリー使用量、電力、精度をプロファイルします。
7. Bluetooth、表示、音声、センサーが並行動作する実際の負荷で試験し、対象の低消費電力状態への移行と復帰も確認します。

最も一般的な誤りは、ニューラルネットワークのみを最適化し、パイプラインの残りの部分を無視することです。多くの組み込み製品では、前処理、メモリー移動、センサータイミング、後処理がアクセラレーター自体と同じくらい重要になり得ます。

量子化とモデルサイズ¶

マイクロコントローラー向けAIでは、通常、コンパクトなモデルと効率的な数値形式を使います。8ビット整数などに量子化すると、浮動小数点モデルに比べてメモリー使用量、必要なメモリー帯域幅、演算コストを抑えられます。

8ビットのモデルならNNACCに対応するとは限りません。SDK v2.5.1のHAL設定はint8_tバッファーとbias_shift / out_shiftフィールドを使用します。これだけでは、任意のゼロ点、チャネル別スケール、すべての現行int8演算への対応は確認できません。実際のカーネル実装に対してテンソル配置、符号の扱い、シフト、バイアス表現を確認し、代表的な入力と境界値を使ってソフトウェアの参照結果と比較してください。

量子化には次のような利点と注意点があります。

• 効率を大幅に改善できます。
• モデルサイズとテンソルメモリーを削減できます。
• 学習やキャリブレーションが不十分だと、精度が低下する可能性があります。
• 一部の演算子は、アクセラレーターや実行環境で効率よく実行できない場合があります。

製品に組み込む前に、変換後のモデル精度とシステム性能の両方を測定してください。PC上の学習環境で良好に動作したモデルでも、量子化後や、センサーノイズを含む実データと組み込み側の前処理を用いた場合には、結果が異なることがあります。

メモリーと帯域幅に関する考慮事項¶

モデル自体が小さく見えても、AI処理には多くのメモリーが必要な場合があります。システムでは、次のデータを保持する領域を確保してください。

• モデルの重み。
• 入力テンソル。
• 中間活性化バッファー。
• 出力テンソル。
• 音声フレーム、センサーのデータ窓、カメラ画像。
• 前処理および後処理バッファー。
• 同時に使われるUI、Bluetooth、アプリケーションのデータ。

対象デバイスの内蔵SRAM、Flash、PSRAM、キャッシュ構成に合わせ、頻繁にアクセスするテンソルや中間バッファーをCPUとアクセラレーターの両方が効率よくアクセスできる場所に置きます。モデルサイズだけでなく、外部ストレージ、作業バッファー、コピーを合わせて必要量とコストを見積もります。

まず、選択したNNACCが各バッファーにアクセスできるか確認します。外部FlashやPSRAMに置くだけで直接使用できるとは限らず、作業バッファーへのコピーが必要な場合があります。コピー時間、作業RAM、エネルギーも予算に含めてください。SDK v2.5.1のHAL実装は検査するバッファーサイズを4バイト単位に切り上げ、開始アドレスと検査上の終了アドレスが異なる1 MiB（1,048,576バイト）のアドレス領域に属する場合に拒否します。入力とバイアスも同じ領域に置く必要があります。終了アドレスが次の領域の境界と一致する場合も検査に通りません。実際の検査条件に合わせてメモリーを割り当て、次の演算を開始する前にエラー戻り値を処理してください。

CPUがDMAやNNACCとバッファーを共有する場合、各転送・演算中はアクセス権を一つの処理主体に限定します。ハードウェアが読む前に、CPUが書いた入力をキャッシュからメモリーへ書き戻します。出力先のキャッシュラインは書き込み前にSDKの規則に従って処理し、CPUのダーティラインが後から結果を上書きしないようにします。ハードウェアの完了を確認した後、CPU側の古いキャッシュを無効化してから出力を読みます。処理範囲はキャッシュライン単位にそろえ、使用中の無関係なデータと同じラインを共有しないでください。出力後に古いキャッシュを書き戻すと結果を壊すことがあります。書き戻しと無効化は別の操作です。

オーディオ、センサー、カメラのパイプライン¶

AIアクセラレーターだけで処理が完結することはほとんどありません。通常はセンサー、音声、カメラの処理フローに組み込まれます。

オーディオと音声¶

音声や音響イベントの検出には、マイク入力、DMAバッファリング、フレーム分割、フィルタリング、特徴抽出、推論、検出結果の平滑化などが含まれます。NNACCは対応するニューラルネットワーク演算を実行し、残りの計算グラフはファームウェアや選択したランタイムが処理します。CPUや音声サブシステムはサンプルと特徴量を管理します。モデルと検証済みのソフトウェア実装は別途必要です。

一般的な例には次のものがあります。

• キーワード検出。
• ソフトウェアが対応する場合のウェイクワード検出。
• 音環境や音声イベントの分類。
• 音声活動検出。

モーションとセンサーフュージョン¶

ウェアラブル製品では、加速度センサー、ジャイロスコープ、心拍センサー、SpO2センサー、ECGフロントエンド回路などからデータを取得します。AIを使えば、動作状態、ジェスチャー、活動パターン、健康関連信号の特徴を分類できます。

必要な検出範囲とレイテンシが許す場合は、サンプルをまとめて処理し、割り込みを利用します。適切なバックグラウンド処理をユーザーがプログラム可能な低消費電力プロセッサーに移すと、アプリケーションCPUの復帰回数を減らせる場合があります。ただし比較には、そのプロセッサーの動作、センサー取得、復帰のコストも含めます。対象イベントの検出に必要なセンシングを停止しないでください。

カメラと画像入力¶

カメラ入力は、具体的なチップ、パッケージ、ボード、取得ドライバーに依存します。SDK v2.5.1のGC032Aセンサードライバーは、センサー出力を8ビットDVPまたは2ビットSPIに設定しますが、どのSF32デバイスでも両方の入力経路が使えることを示すものではありません。カメラを選ぶ前に、ピン、ペリフェラルまたはPTMによる取得への対応、センサーのタイミング、ドライバーを確認します。画像処理は音声や動作検出より大きなフレームバッファーと帯域を必要とすることが多いものの、実際の解像度と取得頻度で比較してください。

フレームの縮小、関心領域の処理、フレームレートの低下、組み込み向けモデルなどを検討します。取得後にファームウェアで切り出しても、モデル入力が小さくなるだけで、カメラ転送量や取得バッファーが減るとは限りません。それらを減らすには、センサー側での切り出しや取得量の削減が必要な場合があります。

タスク実行の計画と電力管理¶

AI処理は、システム全体の動作を踏まえて実行タイミングを決める必要があります。ウェアラブル製品では、消費電力やレイテンシの目標を守りながら、Bluetooth接続の維持、画面更新、音声取得、センサー読み取り、推論を並行して行う場合があります。

タスクを効率よく実行するには、次の点に留意してください。

• 検出範囲、見逃しのリスク、レイテンシ要件に応じて、周期的な推論またはイベントで開始する推論を選びます。
• 割り込みやイベントで処理を開始できる場合は、ポーリングを避けます。
• レイテンシ要件が許す範囲で、センサーのサンプルをまとめて処理します。
• 信頼できる検出に必要な入力窓を確保しつつ、入力から判断結果までのレイテンシを制限します。
• AI処理と画面更新、Bluetooth動作のタイミングを調整します。
• 完了の確認、バッファーの引き渡し、必要な電力管理ロックの解除後に、CPUとアクセラレーターを許可された低消費電力状態に戻します。必要なセンシングや他の未完了処理は継続します。

推論のレイテンシだけでなく、実測した電源電力（電源電圧×電流）を時間積分して、機能全体のエネルギーを測定します。センサー取得、前処理、コピー、アクセラレーター処理、CPUフォールバック、後処理、アイドル期間を含めてください。実行時間の短縮で動作中のエネルギーが減っても、早くスリープできるとは限りません。効果は他のシステム負荷にも依存します。推論頻度を下げる前に、検出範囲と精度が同等であることを確認します。

SDK v2.5.1のブロッキングHAL開始関数はポーリングで完了を待ち、明示的なタイムアウトを持ちません。割り込み方式には正しいIRQハンドラーと完了通知が必要です。開始時のエラーを確認し、アプリケーション側の待ち時間を制限して、バッファー再利用や電力管理ロック解除前の復旧手順を定めてください。

精度・レイテンシ・消費電力のバランス¶

組み込みAIでは、精度、レイテンシ、消費電力のバランスを取る必要があります。

適切なバランスは製品によって異なります。ジェスチャー検出では、消費電力を抑えられるなら多少の遅れを許容できる場合があります。音声トリガーには素早い応答が必要ですが、誤検出による不要な起動は避けなければなりません。健康モニタリングでは、即時の分類よりも判定の安定性や長時間のバッテリー駆動を優先する場合があります。

実践的な設計ガイダンス¶

SF32を使ったAI製品を計画するときは、モデルの選定より先に、製品に必要な動作を整理してください。

• デバイスがローカルで下さなければならない判断は何か。
• どのセンサーが入力データを提供するか。
• 推論はどのくらいの頻度で実行する必要があるか。
• 許容できるレイテンシはどの程度か。
• モデルの重みとテンソルの最大メモリー予算はどれくらいか。
• モデルは精度を大きく失わずに量子化できるか。
• 選択したチップとSDKで加速される演算はどれか。
• Bluetooth、ディスプレイ、オーディオ、推論が同時にアクティブなときに何が起こるか。
• 実際の製品データでモデルの精度をどのように検証するか。
• 必要な場合、フィールドでファームウェアがどのようにモデルを更新または置き換えるか。

組み込みAI製品を成功させるには、コンパクトなモデル、適切なデータ収集、ハードウェアに合わせたメモリー配置、実際の製品負荷を想定した性能測定、不要な起動を抑える電力管理を組み合わせることが重要です。

一般的なユースケース¶

対応演算子と実測したシステム予算が合う場合、接続機能を持つバッテリー駆動製品で小型モデルをローカル実行する候補として、SF32のAIアクセラレーターを検討できます。

• スマートウォッチ、リストバンド、手持ち機器でのジェスチャー認識。
• フィットネスおよび健康製品のための活動分類。
• オーディオアクセサリーのための音声イベントまたはキーワード検出。
• ウェアラブル向けセンサーフュージョンアルゴリズム。
• センサーとソフトウェアがサポートする場合の生体信号解析。
• スマートデバイスのためのローカル異常検出。
• カメラ入力に対応したデバイスでの簡単な画像分類、またはカメラ入力をきっかけとするイベント。
• 使用状況に応じて動作を変えるHMI。

要点のまとめ¶

• NNACCは対応演算をオフロードし、CPU占有時間を減らせます。レイテンシとエネルギーへの効果は機能全体で検証します。
• これは、センサー、オーディオまたはカメラ入力、前処理、メモリー移動、後処理、アプリケーションロジックも含む完全なパイプラインの一部です。
• SDK v2.5.1にはSF32LB55x、SF32LB56x、SF32LB58xのNNACC資源が記載されていますが、SF32LB52xまたはSF32LB57xへの搭載は確認できません。ファミリー名だけで対応の有無を判断せず、型番と負荷を確認してください。
• 実際の性能は、モデルサイズ、量子化、サポートされる演算子、メモリー配置、キャッシュ処理、DMA挙動、SDKランタイムサポートに依存します。
• ローカル推論は応答性、オフライン動作、プライバシー、無線通信量の目標を満たすために役立ちます。アクセラレーターがあるだけでは、これらの効果は保証されません。

最終更新: 2026-10-19