6 制御系マルチコア・ハードウェアの特徴とユースケース

6.1 背景

近年、組込み装置における高性能化、高集積化を背景にソフトウェアの規模が急速に増大している。2010年時点においても、スマートフォンに搭載される一般的なソフトウェアの規模は1200万ラインを超えており、高級車を対象とした車載ソフトウェアでは約8倍の総計1億ラインを超える規模となっている。2020年での推定は高級車1台に搭載されるソフトウェア規模は3億ライン程度の見通しである。

図 1: ソフトウェア規模のトレンド

このような大量のコードを実行するには、マイクロプロセッサ(MPU)の能力を非常に高める必要がある。一方で、MPU1つの処理能力は、物理的な限界から、数GHz程度の周波数からの伸びは非常に小さいのが現状である。このため、大量のコードを実行するためには、MPUを複数同時に動作させるマルチプロセッサ構成、あるいは1つのMPUのパッケージ内に複数の演算装置(Core:コア)を搭載したマルチコア構成のMPUが必要となる。また、組込み装置は設置場所、形状等の問題から、1つの基板上に配置可能なMPUパッケージの数量が限定されることもあり、特にマルチコアMPUへの期待が大きい。

更に、組込み制御システムでは高いリアルタイム性(ハード・リアルタイム)が要求されることもあり、MPUの動作方式についても一般的なPC等に搭載されるMPUのように、整理され体系化された統一的な構造がとれず、各用途に合わせたハードウェア構成を採用するケースが多い。このため、組込み制御システム向けのマルチコアMPUにおいては、ソフトウェアの構築あたり、ハードウェアが持つ特徴をよく捉えて設計しなければならず、従来のソフトウェア設計スキルより、より広範な知識が必要となる。

本ドキュメントではそういった組込み特有の制約が多い中で、制御マイコンにおけるマルチコア・アーキテクチャの代表的構成、マルチコア支援機能、高いリアルタイム性を維持するためのハードウェアの仕組みと、それらを前提としたユースケースについて解説する。

6.2 制御システムにおけるマルチコアユースケース

組込み制御向けのマルチコアが想定する代表的なユースケースとして、次の3つの課題を解決するアーキテクチャが考えられる。

  • 制御アプリケーションの高性能化 (負荷分散型)
  • 複数のアプリケーションの組合せ・統合 (機能統合型)
  • 機能安全への対応 (機能分離型・時間分離型)

それぞれの課題に応じて適切な構成があり、システム全体の目的として複数の課題に対応する場合には、組み合わせた形のアーキテクチャが採用されるケースも存在する。

図 2: 制御システムにおけるマルチコア・ユースケース

6.2.1 アーキテクチャ・パタン1: 負荷分散型

負荷分散型は、単一の機能の実行時間性能を向上させるために、本来1つのソフトウェアとして動作するコードを分割し、並列に実行することで、実行時間(レイテンシ)を減少させることを目的とする。

本方式は、複数のコアを利用することで並列に動作させた分だけ、最終的な実行完了時刻が早まる(レイテンシが短縮される)。一方で、並列動作をさせる過程で、分割した処理間での通信や、同期待ちなどの分割前のソフトウェアでは生じなかったオーバーヘッドが生じる。このオーバーヘッドが、処理を並列化したことによる短縮された時間に見合わない場合は、性能向上が得られず、場合によっては劣化してしまうことがある。

図 3 に示すように1つのソフトウェアが複数のコアにまたがるように配置し、またそのプログラムを管理するOSもマルチコアに対応したOSを用いるのが理想である。独立した複数のOS上(あるいはOSレス)に構築することも可能だが、その際は並行動作するプログラムの権限や実行の管理はすべてユーザが行う必要があり、難易度が高い。

図 3: 負荷分散型マルチコア

本方式の特徴と必要とされる技術を示す。

  • 利点
    • マルチコア化による実行時間性能の向上
  • 欠点
    • 並列化に適したソフトウェア構成でない場合、性能が期待通り向上しない
    • バスや共有メモリを介したデータ交換のオーバーヘッドが生じる
  • 必要とされる技術要素
    • 並列化の粒度 : アプリケーション以下
    • ソフトウェアの並列化支援ツール
    • マルチコア OS
    • 高速な共有メモリ
    • 高速な CPU 間イベント通信

この方式では、複数のコア間では同一の性質、権限を持ったソフトウェアが動作し密接に関わり合うため、特に高性能を追求する場合は、ハードウェアが持つバスや共有メモリの機能・構成について熟慮する必要がある。

ソフトウェア構築にあたっては、マルチコアOSの機能支援や、ハードウェアが用意する拘束なCPU間イベント通信の機能を積極的に利用することで、ミスや設計負担を減少させることができる。また、単一のソフトウェアを並列動作可能な形に分割することは非常に困難であり、コードの構文や構造から自動的に並列化する支援ツールを利用することも視野にいれたい。

6.2.2 アーキテクチャ・パタン2: 機能統合型

機能統合型は、複数の独立したシステム(または機能)を1つのマルチコアに集積し、BOMコストを低減、またはパッケージの設置面積を縮小することが目的である。

本方式はもともと異なるMPUで実行していたシステムをそれぞれのコアに搭載し、複数の機能を1つのMPUで実現するものである。それぞれのコアに搭載されたシステムは基本的に独立して動作し、干渉を最小限に保つ必要がある。

図 4 に示すように、それぞれのコアには、それぞれシングルコア用のOSが搭載され、あたかも独立したMPUであるかのように動作する。協調動作が必要な場合は、システム内の共有資源を用いて通信を行うが、ソフトウェアの概念上は複数のMPUに分かれていた場合と同様に取り扱う。

図 4: 機能統合型マルチコア

本方式の特徴と必要とされる技術を示す。

  • 利点
    • 部品点数削減によるBOMコストの低減
    • パッケージの設置面積をマルチプロセッサ構成より低減
    • 通信路がMPU内部で閉じるため、通信レイテンシがマルチプロセッサ構成より小さく、効率的な協調動作が可能
  • 欠点
    • バスや共有資源の競合による性能劣化(干渉)が発生するため、マルチプロセッサ構成よりも取り扱いが難しい
    • 統合により共通化された部品、共有資源などの故障により、同時に障害が起きるケースがある(共通故障)
  • 必要とされる技術要素
    • 並列化の粒度 : アプリケーション単位
    • 仮想化技術/ハイパーバイザ
    • OS 間通信フレームワーク
    • メモリ・周辺装置のパーティショニング技術
    • 干渉の少ないバス・システム

この方式では、異なるコアに搭載したソフトウェア・システム間の独立性の保証や、干渉の低減について強く注意する必要がある。このため、バスや共有資源の分離性や、性能の干渉などについて一定の保護(パーティショニング)がハードウェア的に施されている場合がある。

またソフトウェア側も共有する資源が存在する場合には、その利用方法などに一定のマナーを課すことや、性能低下に対する許容範囲などを事前に検討が必要となり、これをサポートするための仮想化技術や、統合前と透過に通信が行えるような通信フレームワーク技術tなどが、OSやハイパーバイザと呼ばれる管理プログラムによって提供されるべきである。

6.2.3 アーキテクチャ・パタン3: 機能分離型・時間分離型

機能分離型・時間分離型は、 1.2.2 の機能統合型と構成は似ているが、それぞれのコアに割り当てられたソフトウェアが必ずしも独立したシステムではなく、時に協調や監視といった密接な関係で動作する状況が存在する。機能分離はソフトウェアの実行結果への影響、時間分離はソフトウェアの実行時間への影響を示す。

図 5 に示すように、異なるコアで安全水準が異なるソフトウェア(QM,ASIL)を動作させ、高い安全水準を持つソフトウェアの動作が、低い水準のソフトウェアにより阻害されることを防止する。そのためにハードウェア機能と、その上で動作するソフトウェアの開発手法を組み合わせて、システムの安全性を保つことを保証する。

図 5: 機能分離型・時間分離型マルチコア

本方式の特徴と必要とされる技術を示す。

  • 利点
    • 異なる性質のソフトウェア間の干渉が低減可能
    • OSを含めて分離することで、個々のOSは機能最小限のコンパクトな実装が可能となる
  • 欠点
    • バスや共有資源を介したデータ交換などの際に、安全水準を保つための追加手順が必要となる
    • 分離を保つ管理プログラムとして品質の高いハイパーバイザ・プログラムが必須であり、このハイパーバイザ処理によるオーバーヘッドが生じる可能性がある。
  • 必要とされる技術要素
    • 並列化の粒度 アプリ単位 or アプリ以下
    • 仮想化技術/ハイパーバイザ
    • 共有メモリ
    • メモリ・周辺装置の分離技術
    • 帯域分離が可能なバス・システム

この方式では、機能統合型では必須ではなかった保護(パーティショニング)が必須となる。システムの目的は安全水準に従って、保護すべきソフトウェアの動作を正常に保つことを第一義として、性能を目的として条件を緩和することは許容されない。一方でソフトウェアが定められた時間で所定の処理を完了させることも、安全性の要求に含まれるため、マルチコアで動作した場合の干渉等の予測可能性も非常に高いレベルで要求される。

6.3 制御系マルチコア・ハードウェア

本章では組込み制御システム向けのマルチコアMPUにおいて採用されるハードウェア要素技術について紹介し、それぞれの役割、特徴点を説明する。これらは前述したユースケースを成立させる上で必要な要素技術である。

6.3.1 マルチコアの種類

マルチコアMPUの大きな種別を把握する方法として、コアの構成とその利用分野ついて紹介する。

マルチコアの種類は、構造から「対称型マルチコア」「非対称型マルチコア」、応用から「制御系マルチコア」「情報系マルチコア」に分けられる。それぞれの詳細は本章の各節で述べる。

6.3.1.1 対称型マルチコア(ホモジニアス)

同一性能のコアを複数搭載したマルチコアMPUは、対称型マルチコア(ホモジニアス・マルチコア)と呼ばれる。すべてのコアが同性能のため、ソフトウェアの配置を変更した際にも同一の実行時間で動作することが期待され、ソフトウェアを分割配置する際に結果が予測しやすい。このため汎用的な目的で利用されるMPUや、大規模な処理を行う多並列処理を行うMPUで採用されることが多い。

図 6: 対称型マルチコア(ホモジニアス)

6.3.1.2 非対称型マルチコア(ヘテロジニアス)

異なる性能のコアを搭載したマルチコアMPUは、非対称型マルチコア(ヘテロジニアス・マルチコア)と呼ばれる。対称型マルチコアと異なり、性能が異なるコアが搭載されているため、ソフトウェアを分割し配置した場合に、配置先のコアに応じて分割したソフトウェアごとの性能が変動する。このため、ソフトウェアの配置最適化の検討時に難易度が上昇する。しかし、使用用途が明確であり、各コアに配置するソフトウェアの要求する性能に大きく差がある場合、コアの計算能力が無駄にならない利点がある。

例えば、組込み用途ではメインの計算処理を行うソフトウェアと、比較的軽量なシステムを保全する処理(システム制御)を行うソフトウェアに分割される場合などに、処理性能の高いコアにメイン処理、低いコアにシステム制御処理を割り当てることで、最適な動作が可能となる。これにより全体の消費電力の低減や、待機状態での電力消費を最小化が実現できる。

また、非対称型の場合は性能だけでなく、命令セットアーキテクチャなどから異なるコアを採用する場合がある。

図 7: 非対称型マルチコア(ヘテロジニアス)

6.3.1.3 制御系マルチコアの代表構成(MCU:マイクロコントローラ)

システムの目的に応じて、最適なマルチコア構成は変化する。組込み制御システムにおいては、基板の設置場所の容積や熱容量の制約があり、マルチコアが要求されるケースにおいても、200 MHz~400 MHz 程度の処理性能を持つコアを2コア~4コア程度集積する場合が多い。

制御系の処理は多数の並列性を抽出しにくい性質であると共に、画像処理のような同一処理内容で大量の並列実行が可能なデータ並列性が少なく、様々な内容の処理を細かく小さく実行するタスク並列性が中心である。これらの処理量が異なる処理を、ある程度まとめて少数のコアに配置していくにあたり、非対称マルチコアでは最適な構成の探索が非常に困難となる。

このような背景により、用途がはっきりしているという印象の制御系マイコンにおいては非対称型マルチコアよりも対称型マルチコアが主流である。もちろん、一部の特定用途の処理などを行う補助的なコアが搭載されることもあるが、通常のプログラミング空間からは分離されている場合が多く、ここでは除外して考える。

図 8: 代表的な制御系マルチコア構成

6.3.1.4 情報系マルチコアの代表構成(SoC:システム・オン・チップ)

組込み機器向けであっても、大規模なSoCチップを用いた情報系処理を担うMPUも存在する。本ドキュメントでは主に制御系を対象としているが、ここでは簡単に情報系処理におけるマルチコアについても簡単に言及する。

情報系マルチコアでは、対称型マルチコアと非対称型マルチコアが組み合わせられるケースが多い。大規模なデータ並列性の存在するメインの処理群を高性能(1GHz超,4コア以上)の対称型マルチコア部分で行い、それ以外の雑多な機器メンテナンスを行う入出力の処理を比較的低性能(数100MHz)のコアで行う形が一般的である。

図 9: 代表的な情報系マルチコア構成

6.3.2 メモリ構成

マルチコアにおいてメモリ構成は最も重要とも言える要素である。メモリはコアに配置したプログラムの実行時間、コア間のデータ共有のための通信時間に関わり、メモリへの操作を効率化することがマルチコアでのトータル性能を向上させる際に最も影響の大きいパラメータとなる。

あるコアから見たメモリ操作に関わるパラメータとして、重要なものは以下の3つである。これは組込みマルチコアコンソーシアムが提唱するハードウェア抽象記述 SHIM1 に規定されたメモリ表現とも一致する。

  • アクセシビリティ
  • レイテンシ
  • ピッチ

アクセシビリティは、いずれのメモリがどのコアからアクセスが可能かを示す。協調動作をする際には各コアが同じメモリにアクセスが可能でなくてはならないが、組込み制御システムにおいては特定のコアからのみアクセスが可能なローカル・メモリが定義されている場合がある。

レイテンシは、コアが当該メモリにアクセスした際にデータが返却されるまでの時間を示す。ピッチは、連続で要求を発行した際に、返却されるデータ間の間隔を示す。詳細はSHIMドキュメントを参照のこと。

バス・システムを介したメモリへのアクセスが常に1つの要求のみを受付け、データが返却されるまで他の要求を実行しない場合(ブロッキング・アクセス)、レイテンシとピッチの値は等しくなる。これに対して最初のデータが返却されるまでの間に、後続の要求の処理がある程度進み、最初のデータが返却された後に、短い間隔で次のデータが返却されるような場合(ノンブロッキング・アクセス)、ピッチの値はレイテンシより小さくなる。

このように、SHIMにおけるメモリ表現はバス・システムを含むメモリ操作に関わるハードウェア機能を隠蔽し、比較的取り扱いの簡単なパラメータで表現可能としている。本章では、このSHIMのメモリ表現で説明できる粒度で、マルチコア・ハードウェアへの理解を深めるため、いくつかの特徴的な構成や機能について紹介する。

6.3.2.1 TCM: Tightly coupled memory

各コアが高速に利用できるメモリとして、コア近傍に持つ小容量のデータ・メモリをTCM(Tightly coupled memory)と呼ぶ。コアが局所的に保持するメモリという意味でLocal Memoryと呼ばれることもある。

図 10: TCM: Tightly coupled memory

カップリングされたコアのみが高速に実行できるため、そのコアに割り当てられたソフトウェアのスタック・メモリや、プライベートなデータを配置するために用いるのが一般的である。通常は、このメモリへの操作はコアにとってはペナルティ(待ち時間等)のない形でデザインされる。このため、非常に実行時間の予測性が高いのも特長の一つである。

カップリングされたコア以外からのアクセスは、ハードウェアのポリシによって許可する場合と禁止する場合がある。禁止する理由は、他コアからの干渉を防ぎ、予測性や安全性を高めるためである。アクセスを許可する場合も、他コアからのアクセスには余分なレイテンシが生じる。

TCMを共有メモリとして利用する場合は、主に単方向通信の場合である。通常、送信コアから受信コアのTCMに向かって書込みが行われる。一般的には書込みは結果を待たずに後続の処理が実行できるため、レイテンシの大きなメモリへ行ってもペナルティが顕在化することは少なく、読込みは結果を必要とする処理が後続に控えているため、可能な限り速やかに完了できることが望ましいからである。

6.3.2.2 等距離共有メモリ

等距離共有メモリは、最も一般的な形態の共有メモリである。すべてのコアから同じレイテンシでアクセスできるため、ソフトウェアをどのコアに配置しても性能が大きく変動せず、非常に使い勝手の良い共有メモリである。

図 11: 等距離共有メモリ

一方で、等距離であることを維持するために、コア数が増えた場合にレイテンシが増加しがちであり、大規模なマルチコアで頻繁な共有を行うケースでは、性能のボトルネックを生じさせやすい。

6.3.2.3 非等距離共有メモリ

非等距離共有メモリは、コア毎にアクセスする際のレイテンシが異なる共有メモリである。等距離共有メモリと異なり、近傍のコアに対しての性能が高く、コア数が増えた場合にも性能が劣化しにくい。反面、ソフトウェアの配置はレイテンシが異なるグループに移動した場合には変動してしまうため、やや難しくなる。

図 12: 非等距離共有メモリ

 1.3.2.1 のTCMは非等距離共有メモリの一種だが、同じレイテンシを持つグループのコアが存在しない特殊例となる。非等距離共有メモリは、 1.3.3 で説明するクラスタ構造にも密接に関わる。

6.3.3 クラスタ構造

大規模なマルチコアの場合、一部のコアをグループ化して取り扱うクラスタ構造(サブシステム、アイランドなどとも呼ばれることがある)を取る場合がある。その際、 1.3.2.1,  1.3.2.3 で説明した各種メモリ構成を組合わせて、図 13 のような構造を取ることが多い。

図 13: 代表的なクラスタ構造例

各コアにTCMを搭載しプライベートな処理は原則的にTCM上で行うことで高速性を保ちながら、クラスタごとに非等距離共有メモリを持つ。これにより、クラスタ内でのソフトウェアから見ると、比較的取り扱いやすい等距離共有メモリが存在するように見えるため、負荷分散等の検討が容易になる。

これによる利点として、

  • クラスタ毎に回路レイアウトを行うことで、共有メモリのアクセス性能や周波数性能等の引き上げが容易
  • クラスタ毎に独立したハードウェア構成であり、互いに鑑賞しないソフトウェア群の性能保証や安全性を保ちやすい
  • 電力管理などハードウェア資源の階層的な管理単位としても利用できる

などが挙げられる。

図 14: クラスタ構造の利点:相互干渉の低減
図 15: クラスタ構造の利点:性能引き上げ

この例では4コアと少数のマルチコア構成であるが、8コア、16コアとコアが増加するに従ってクラスタ構造のメリットは大きくなる。また、更に外側に大容量の等距離共有メモリ(DRAMなど)を配置することもSoCなどでは行われることが多い。 また、少数コアでのクラスタ構成としては、車載システムなど安全性が重要なシステムでは実際に採用されるケースもある。

6.3.4 メモリ・インターフェース

マルチコアを用いる際、必ず発生するのが共有メモリへのアクセス競合である。複数のコアが同時に同じメモリを使うことで、メモリアクセスを順番に行うために性能が著しく劣化することがある。

この問題に対してハードウェアではメモリ・インターフェースにも工夫を凝らしている。これらの仕組みはメモリ・アクセスのレイテンシやピッチの期待値(平均値)として現れてくるものである。

6.3.4.1 メモリ・バンク

メモリ・バンクはメモリの内部を、連続したアドレスの範囲で区切って並行的にアクセスを可能とする。

図 16の例では 2 MiB のメモリを 1 MiB 毎に区切って2 バンクの構成をとってものである。それぞれ上位、下位の範囲で並行してアクセスが可能であり、それぞれ別のコアが利用するようにプログラムを構成することで、メモリ衝突によるペナルティを排除できる。

図 16: メモリ・バンク

メモリ・バンクはコンパイラ(リンカ)の設定によって、意識的に制御しメモリの競合を回避できるため、ソフトウェア設計時にメモリ・バンクの構成を考慮して検討を行うことが重要となる。

6.3.4.2 メモリ・サブバンク

メモリ・サブバンクはメモリの内部を一定のアドレス毎にスキップしたデータを1組としてバンクとし、オフセットの異なるデータ同士は異なるメモリとして並行アクセス可能とする。

図 17の(1)の構造例では、16 B の範囲を4 B毎にサブバンクとしている。すなわち、アドレス0x0, 0x10, 0x20, 0x30…の各4バイトをサブバンク0、アドレス0x4, 0x14, 0x24, 0x34…をサブバンク1のようにグルーピングしている。これにより比較的近傍の範囲のデータ(例えばコア間の共有データなど)へ、複数のコアが同時にアクセスした際にもペナルティが生じない可能性が確率的に高まる。

図 17: メモリ・サブバンク

図 17の(2)の動作例では、それぞれのコアが同じオフセットアドレスにアクセスを行った際にもサブバンクよってペナルティを除去できる。

この仕組みは、ソフトウェアではあまり意識する必要はないが、平均的なアクセス性能に大きく貢献する。

6.3.5 プロセッサ間割込み/イベント・フラグ

マルチコアを利用する際に、複数のコアでの協調動作が必要となる。データの共有は共有メモリを介して行うが、ソフトウェアによっては処理がある状態に至ったことを相手に伝えるためのイベント通知の必要が生じる。

マルチコア向けハードウェアでは、通知の形態によって大別して次の2種類の通知方法をサポートする。

  • プロセッサ間割り込み
  • プロセッサ間イベント・フラグ

それぞれ特性が異なるため、システムが要求する動作条件に従って選択する。また、マルチコアOSが本機能を用いてメッセージ通信機能などを提供することもあり、この場合は、より高機能な通信APIが提供される。

6.3.5.1 プロセッサ間割り込み

プロセッサ間割込みはシングルコアMPUでも備えている割込みをマルチコアMPU向けにMPU内部のコアで相互に割込み要求を行えるようにする機能である。通常、プロセッサ間の処理起動を目的として、Remote Procedure Call(RPC)を実現する手段として用いる。

図 18のように、左の要求側コアからソフトウェア操作によって要求レジスタ(IRQ)を操作することで、通知先のコアに割込み要求がなされる。割込みは通常の割込みコントローラに接続され、他の割込みと同様にマスクや要求取下げなどの管理を受信側が任意に行うことが可能である。

図 18: プロセッサ間割込み

プロセッサ間割込みは対象コアの処理状態を変化させるため強制力・即時性がある反面、要求されたコアの処理中断を引き起こし、システム全体の処理能力の低下やリアルタイム性の減少を引き起こす場合がある。ただし受信側は割込みのマスクが可能であり、真にクリティカルな状況では中断を拒否できる。

マルチコア向けの機能としては、1操作で複数のコアに同時に割込み通知を行う同報通知や、要求回数をカウントするような仕組みを備える場合がある。

6.3.5.2 プロセッサ間イベント・フラグ

プロセッサ間イベント・フラグはプロセッサ間割込みとは異なり、割込みを介さずにイベントの有無を受信側に伝える仕組みである。

図 19のように、基本的にはプロセッサ間割込みと同様の構成だが、要求レジスタ(Snd)から接続される先は割込みコントローラではなく、ただの機能レジスタとなっている。このため、受信側の処理が中断されることはなく、受信側のプログラム進行に合わせて都合の良いタイミングでイベントの有無が確認できる。

図 19: プロセッサ間イベント・フラグ

この手順のみであれば共有メモリ上でも同等のことが行えるが、プロセッサ間イベント・フラグの特有の価値として補助的な機能が備わっていることが多い。例えば、イベント・フラグのセットに応じて、受信側のコアがスリープ状態などであった場合に起床可能であるなど、システム制御面での付加価値がある。

また、共有メモリを介すると他コアのプログラムの動作次第でイベントの通知にかかるレイテンシが変動してしまう。これらを避けて一定の時間での通知完了を確定できる点が強みとなる。

6.3.6 排他制御用レジスタ (Mutex register)

プロセッサ間で複数の共有データの組(セット)を相互に参照・更新する場合、複数の共有データ間での一貫性を保持するために、互いに現在、参照中または更新中であることを把握するための手順が必要となる。通常、このMutex(MUTual EXclusion)と呼ばれる手順を実現するためには共有メモリを介してやり取りを行うが、ハードウェアによっては専用の機能レジスタを備えている場合がある。

Mutexを構成する場合、鍵となるデータ(ロック変数)を互いにアクセスし、空き状態であれば利用状態に更新した後、共有データ本体を操作する。利用状態であれば、空き状態になるまで何度も繰り返し確認(ポーリング)し、空き状態になるのを待ち続ける。この過程で、頻繁にロック変数へのアクセスが発生することで、本来行うべき処理とは無関係なアクセスが頻出することとなる。これはシステムのバス資源を無駄に消費し、システム全体の性能を低下させるが、一方で各コアの処理のレイテンシ短縮のみを考えると、全力でロック変数にアクセスすることは必要な処理である。従って、マルチコア・システムはこのロック変数への頻繁なアクセスと、それによるシステム性能の劣化防止を両立する必要がある。

排他制御用レジスタと呼ばれる機能レジスタは、共有メモリが接続されているメイン・バス・システムから独立した各コアに直結したパスで接続された小さな共有メモリ(レジスタ)である。これにより、どんなに各コアが鍵にアクセスを行ったとしても、メインとなるバス・システムには一切の影響を与えないことを実現している。

図 20: 排他制御用レジスタ

排他制御用レジスタは、アクセス経路以外は特長を持たないただのレジスタであり、時に1ビットではなく複数ビットの語長を持つ場合がある。ソフトウェアはこれらのビットを使い、意味をもたせることで単純なmutexだけでなく、バリア同期やCounting semaphoreなどを実現することができる。

6.3.7 同期化処理

共有メモリを介してコア間でメッセージのやりとりを行う際に、あるコアから書き込んだ値を確実に別のコアに伝える必要が生じる場合がある。これを実現するために、同期化処理が必要となる。

共有データに書込み命令を実行後Mutexを解放し、受信側コアが操作可能にするといった手順を考えた場合、共有メモリ上にデータを書込みした後に何もせずにMutexを解放すると、受信側が読出す前に共有メモリへの書込みが終わっていることが保証できない可能性がある。

近年のMPUでは処理性能の向上のために、書込み命令を実行しても実際に共有メモリへの書込みが終わる前に、後続の命令を実行する。これは、都度書込みの完了を待っているとアクセス先によっては書込み命令の実行に長い時間がかかり、性能が低下する可能性があるからである。

このため、図 21のようにコア1によるWrite (B)の結果が共有データに書かれる前にコア2がMutexを獲得し、更新前のAという値を読み出してしまうことが起こりうる。これは共有データを低速な等距離共有メモリに配置し、Mutexを排他制御レジスタに配置した場合などに起きる可能性がある。

図 21: 同期化処理

これに対して、ハードウェアは一定の同期化処理を定義しており、その手順をソフトウェア的に実行することで、先行する書込みが完了することを保証可能としている。ただし、この手順はハードウェアのバス構成やコアの機能と密接に関わっており、ハードウェア毎に手順が大きく異なる。

ハードウェア・マニュアルには「同期化処理」「完了保証」などのワードで注記されている場合が多いため、ハードウェア・マニュアルをよく確認する必要がある。多くの場合は、特定の命令実行、特定のレジスタアクセス、同じメモリからの読み出しといった操作の組み合わせで実現される。

また、この種の問題はロック変数と共有データを同じメモリに配置すると解消することが多いが、前述したメモリ・バンクや特殊なメモリ領域などもあるため、十分な確認が必要となる。

6.3.8 マルチコア用ハードウェア機能の有用性

本章で述べた各ハードウェアに機能について、 1.2章のユースケース毎に有用性とSHIMでの対応状況を表 1にまとめた。

表 1: マルチコア用ハードウェア機能の有用性とSHIM対応状況
機能 負荷分散型 機能統合型 機能分離型 時間分離型 SHIM 対応状況
対称型マルチコア Excellent Good Good Yes
非対称型マルチコア Poor Fair Fair Yes
TCM Good Good Good Yes
等距離共有メモリ Excellent Fair Fair Yes
非等距離共有メモリ Poor Good Good Yes
クラスタ構造 Poor Excellent Excellent Yes
メモリ・バンク Poor Good Good Yes
メモリ・サブバンク Good Good Good Yes 注
プロセッサ間割込み Fair Good Good Yes
プロセッサ間イベント・フラグ Good Good Good Yes
排他制御用レジスタ Excellent Fair Fair Yes
同期化処理 Excellent Excellent Excellent No

注: 間接的にはアクセス時間のパラメータに反映される

負荷分散型はあるタスクを分割した際の実行レイテンシが最も重要となる。また、元は密接な関わりのある一機能を分割するため通信が頻繁に発生するため、特に低レイテンシな通信が必要である。処理分割の際にどのような分割方法がいいかを入念に検討する必要があり、ソフトウェアの配置が容易になる対称性も重要となる。

機能統合、機能分離・時間分離では、処理間の影響を低減する仕組みが有用である。通信頻度は低めで、機能毎に分けるためそれぞれの処理量はまちまちであるため、事前に処理量が推定できる場合は、非対称型マルチコアが有効に活用できる局面も多い。

また、ハードウェアがこれらの機能を備えているかどうかについては、組込みマルチコアコンソーシアムが提案したSHIM仕様に基づいて確認が可能である。メモリ・サブバンクに関しては機能的には直接表現されず、アクセス性能の数値に反映されて表現する形となる。

この中で唯一SHIMにより表現できていないのは、同期化処理についてであるが、これは同期化処理の対象範囲や手順などが画一的に取り扱えず、標準的な仕様で表現しにくいことが原因である。しかしながら、マルチコアを扱う上で重要な要素となるため、対応方法を継続して検討する。

6.4 車載制御向けマルチコアの実例

本章では実際のマルチコア・デバイスの仕様として、ここまで説明したハードウェア機能がどのような形で搭載されており、またその意図はどのようなところにあるか、ルネサス エレクトロニクス社のデバイスを例にあげて紹介する。

6.4.1 製品: Renesas RH850シリーズのマルチコア機能

ルネサス エレクトロニクス社製のRH850シリーズは、車載システム向けの高性能・高信頼性を両立したマルチコア・マイクロコントローラを発売している。

 1.3章で説明したハードウェア機能のRH850/E2x-FCC2での対応状況は、表 2のようになっている。

表 2: RH850シリーズ製品でのマルチコア機能対応状況
マルチコア機能 対応状況
対称型マルチコア Yes (6コア:同一性能コア)
非対称型マルチコア No
TCM Yes
等距離共有メモリ Yes (クラスタ内)
非等距離共有メモリ Yes (クラスタ間)
クラスタ構造 Yes (3クラスタ)
メモリ・バンク Yes
メモリ・サブバンク Yes
プロセッサ間割込み Yes
プロセッサ間イベント・フラグ Yes 注
排他制御用レジスタ Yes
同期化処理 Yes

注: プロセッサ間割込みの要求フラグで代用可

RH850は車載制御システムの特性に合わせて、高性能・高信頼を目的としたマイクロコントローラ(MCU)である。 1.2章で挙げた3つのユースケースのいずれにも対応できるクラスタ構成の対称型マルチコアを採用している。

  • 車両内の設置場所の制約から複数の機能を統合する要求がある: 機能統合型
  • 車載安全基準(ASIL)へ対応したソフトウェア構成が必須: 機能分離・時間分離
  • 制御処理の高性能化が求められる: 負荷分散

制御処理の高性能化については、制御処理自体はあまり並列性が高くなく、2~3並列程度の異なる処理を実行することが求められる。一部のデータ並列処理(行列演算など)は、各コアに搭載しているSIMD演算器により、対応するという方針である。

図 22 にRH850マルチコア・デバイスの構成概要とその特長を示す。同一性能のCPUコアを2つずつクラスタ化し3つのクラスタを備えており、それぞれのコアにTCM(LRAM)、クラスタ毎に共有メモリ(Cluster RAM)を配置している。Cluster RAMは、クラスタ内では等距離メモリとして2つのコアでの制御処理の再配置を容易にし、クラスタ間では非等距離メモリとして、機能間の比較的低速なデータ通信に利用する。また、プログラムを供給する命令メモリはクラスタ毎にFlash ROMを個別に備えることでクラスタ間の影響を排除している。

図 22: RH850マルチコア・デバイスの特長

この構成の意図は、負荷分散として単機能を分割する際にはクラスタ内の2コアを利用し、複数の機能の統合ではクラスタを分けることで干渉の少ない、安全基準を満たしたFreedom from interferenceの実現が容易に可能であるように考えられたものである。

図 23: RH850マルチコアの狙い

6.5 制御系ソフトウェアの並列化とツール

本章では制御系ソフトウェアをマルチコアに適用するに当たり、並列化のための考え方と、並列化を支援するツールについて簡単に説明する。

6.5.1 制御系ソフトウェア並列化の粒度

制御ソフトウェアの並列化を行う場合、その並列性をどのような箇所から見つけ出すかによって、並列化ソフトウェアの性質が異なってくる。ここでは、主にソフトウェアを分割する際に着目する粒度について解説する。

一般的な制御ソフトウェアは、より大きな粒度から考えると次の3つのレベルで整理することができる。

  • アプリケーション・レベル(機能レベル)
  • タスク・レベル(スレッド・レベル)
  • コード・レベル
図 24: 並列化の粒度

これらのレベル毎に並列化で取り扱う単位が異なり、それぞれに必要な考え方や支援ツールが異なってくる。また、ユースケースごとに当てはめやすい方式が異なるため、システムの目的に合わせて適切に選択する必要がある。表 3 にユースケースとそれぞれの並列化粒度の適性についてまとめた。

表 3: 並列化の粒度とユースケース
並列化の粒度 負荷分散 機能統合 機能分離 時間分離
アプリケーション・レベル No Yes Yes
タスク・レベル Yes No Yes
コード・レベル Yes No No

各節ではそれぞれの粒度で並列化を行う際の考え方、特長、注意点等を述べる。

6.5.1.1 アプリケーション・レベル(機能レベル)

アプリケーション・レベルは設計者が意図する大きな単位での機能を構成するソフトウェア群をひとかたまりとして、複数の機能を並列に配置する考え方となる。すなわち、ソフトウェアが持つ誰が見ても明らかな意味的な並列性である機能/目的の違いを基準に並列に配置する。

最も単純な形としては、1つのコアを1つの機能に割り当てることである。この場合、ソフトウェアの配置は非常に容易だが、一方で機能ごとに負荷が不均等であるケースが多く、コアによっては性能が不足したり、逆に余剰が大きく遊んでしまう可能性がある。このため、利用効率をあげることが難しい。

ただし設計自体は単純で、設計者の意図を反映しながら、OSやハイパーバイザなどのアプリケーション管理機構を持ったプラットフォームに乗せていくことで、比較的容易に実現できる。

  • 必要となる支援ツール
    • ハイパーバイザ (仮想化)
    • マルチタスクOS

6.5.1.2 タスク・レベル(スレッド・レベル)

リアルタイムOSのタスクにあたる粒度でソフトウェアを分割する方式である。タスクは小規模な機能であれば、タスクひとつがそのまま単一の機能となる場合もあるが、機能内の役割に応じて複数のタスクに分割する場合もある。これらのタスクは動作のタイミングが異なったり、概念的には同時にアクティブとなるような性質のものが存在する。タスク・レベルの並列化とは、それらの同時に実行可能なタスクに着目して並列に動作させる考え方である。

制御系ソフトウェアではある機能を実現するのに、複数の入出力装置を取り扱い、またそれと並行して制御方針を定める定周期のメイン処理が存在するような構成が取られることが多い。この時、それぞれ入出力装置の都合に合わせて起動されるプログラム(機器からの割込みや、サンプリング周波数に依存した定周期で起動)と、常に一定周期で実行されるメイン処理とを並列に動作させることで、全体の処理能力の向上が図れる。

OSを利用するソフトウェアであれば、事前にある程度タスクへの分割はなされていることから並列化自身は容易であるが、動作タイミングを含めた関係性を考慮して、効果的な配置を行うことは難しい。また、タスク間に処理順序が必要な場合には、適切な手法で排他制御を構築する必要があり、その結果としてタスク間の動作関係が変動するなど、実際に動作させてみないと最終性能が予測しにくい。

このように動作関係の定義・検証や、並列化の効果測定のために、タスク配置支援ツールや解析系ツールが必要となる。

  • 必要となる支援ツール
    • マルチタスクOS
    • タスク配置支援ツール
    • タスク動作解析ツール

6.5.1.3 コード・レベル

ソフトウェアのコードに記述された処理構造から並列化を行う方式である。例えば、関数や基本ブロックに相当する一連の処理群、またはループ構造からくるデータ並列性などを活用する。

コードから並列性を抽出するために、変数などの利用関係を明確にする必要があり、コードの詳細解析が必要となる。また、組込みソフトウェアなどでコンパクトな実装を目指した結果、変数などが再利用される場合、本来の処理構造としては依存関係がなかったにも関わらず、文脈による依存が発生してしまい、並列実行を阻害するケースが生じる場合がある。

またデータ並列については、ループの添字毎に依存がないことを利用する必要があるが、制御処理は通常、配列の添字を連続的に処理していくようなわかりやすいデータ並列性が少ないため、不適であることが多い。

このように既存のコードから並列性を抽出するのは、特殊なスキルや理解力が必要となり、手動で実施するのはコストが高い。このため、並列化コンパイラなどのコード解析と自動並列化を備えた支援ツールなどの利用が望ましい。

また、コードを出力する前段階の制御処理の論理構造を扱うようなモデリング言語をベースに並列化することも一つの方法である。これは前述の文脈による依存関係が存在しない、純粋なデータ依存のみが表現されている可能性が高いからである・

  • 必要となる支援ツール
    • 並列化コンパイラ
    • コード解析ツール
    • モデルベース並列化ツール

6.5.2 マルチコア支援ツール

 1.5.1 で説明した並列化手法を実現するために利用できるマルチコア支援ツールについて列挙する。本章では各ツールの詳細については割愛する。

  • タスク・レベル設計支援
    • TA Tool Suite (Timing Architect)
    • T1 (GLIWA)
    • SymTA/S Symta vision)
    • Task Analyzer (Renesas Electronics)
図 25: Task Analyzer
  • 並列コンパイラ
    • OSCARTech® Compiler (Oscar Technology)
    • SLX Tool Suite (Silexica)
図 26: OSCARTech® Compiler
  • モデルベース並列化
    • eMBP (eSOL)
    • Embedded Target for RH850 Multicore (Renesas Electornics)
図 27: eMBP

6.6 その他の制御系マルチコア技術

6.6.1 冗長構成(ロックステップ)

マルチコアの一種としてロックステップ構成のMPUが存在する。ロックステップ構成のマルチコアは、複数のコアに同じ計算をさせ結果を比較し、片方が誤った場合を検出し、異常発生を速やかに検出するため、 特に高信頼が必要な分野で用いられる。

図 28では2つのコアは同時、あるいは数クロックずらした状態で同一の入力を用いて動作する。したがって、出力は完全に一致するはずであり、相違がある場合はどちらかが動作を誤った状態であり、システムは速やかに安全な状態へと制御する必要が生じる。通常、演算器を二重化し、メモリ等はECCなどで冗長性を高めることで高信頼を担保する。

図 28: ロックステップ構成

このように同一動作を行わせることで、速やかに故障を検出できるが、2コア構成の場合は誤りがあったかどうかのみ検出可能であり、誤りを訂正して継続して実行することはできない。これは2つのCPUのいずれかが故障はしているが、どちらが故障しているかまでは区別がつかないためである。故障後も継続実行を行うには、3つ以上のCPUを動作させる必要がある。

図 29: 2コア・ロックステップと3コア・ロックステップ

ロックステップ構成は非常にコストが高いため、通常のマルチコアとしても使えるモードとロックステップ動作を行うモードを実行時に切替え可能なMPUも存在する。

また、ロックステップ構成はソフトウェアから見た場合、単一のコアとしてしか見えないため、プログラミング上はマルチコアとして扱うものではない。

6.7 今後の制御マルチコアとEMCの活動

本ドキュメントで説明したマルチコア・ハードウェアについては、今後ますます採用するデバイス・ベンダが増えていくことが予想される。短期的にも、下記のような観点でマルチコアへのニーズが高いと感じられる。

  • エッジ・コンピューティングへのDeep Learningの適用
  • 制御アルゴリズムの非線形化と最適化アルゴリズムの採用
  • 車載機器のセントラル・コンピューティング化(機能統合)

これに伴って従来の設計に加えて、並列化への対応が求められるようになり、ソフトウェア設計はより難易度が上がっていくであろう。しかしながら、マルチコアを取り巻くツール環境や情報整備はまだまだ不十分である。組込み向けデバイスのユーザーズマニュアルを見ても、ソフトウェア設計の観点から見て、マルチコアとして必要な情報は綺麗に整備されておらず、ハードウェア・ソフトウェアの双方に造詣の深い技術者が数千ページあるマニュアルの様々な箇所から、必要な情報の断片をピックアップせねばならない。また、ソフトウェアの並列化も自動並列化ツールや、並列化した結果の確認、検証などを設計の上流で簡易に行えるようなツールが普及しているとは言えない。

このような局面において

  • マルチコア・ハードウェア仕様を正確に把握する仕組み
  • マルチコア設計手法の一般化、ツール支援

がますます重要になるであろう。

組込みマルチコアコンソーシアムでは、この課題に対して 図 30 に示す3つの委員会を以て対策を講じ、広くオープンに周知することで、日本におけるマルチコア活用の推進を行っていく計画である。

図 30: 組込みマルチコアコンソーシアムの活動

  1. https://standards.ieee.org/standard/2804-2019.html↩︎