雑誌無償購読申込み 最新号 バックナンバー 広告資料請求 EDN Japanについて お問合せ
雑誌無償購読申し込み
メールニュースレター登録
登録内容変更
アナログ IC/ディスクリート
電源/電池/コントローラー
PLD / メモリー
組み込みシステム
コンピュータ&ボード
EDA/IP/CAE/ソフトウェア
電子部品
計測器
ディスプレイ
デジタル家電
通信・ネットワーク
カーエレクトロニクス/産業機器
EDN Japan 記事検索
検索方法の詳細
雑誌無償購読申込み ニュースレター登録 この記事に対する感想/ご意見
2006.4
組み込みプロセッサにまつわる取捨選択
――組み込みシステムに最適な処理技術の組み合わせとは

Robert Cravotta
Advertisement
 組み込みシステム設計に最適なプロセッサを選ぼうとするとき、今日では数多くの選択肢がある。マイクロプロセッサやマイクロコントローラ、DSP(digital-signal processors)の他に、米Analog Devices社、独Infineon社、米Microchip社、米Freescale社などから数種の統合マイクロプロセッサも提供されている*1)。これらソフトウエア・プログラマブル・デバイスは、マイクロコントローラとDSPの機能を組み合わせ、1つの命令エンジンで制御と信号処理を行う統合プロセッサ・アーキテクチャに基づいている。最近では、新しいシリコンチップや、より成熟したツールを使用することで、プログラマブル・ロジックを信号処理アルゴリズムのカスタムアクセラレータとして効果的に利用できるようになっている*2)*3)
 デジタル信号処理機能を組み込んだエレクトロニクス製品の増加に伴い、競合する半導体企業から様々な主張や予測が聞かれるようになった。その主張の1つは、計算負荷の大きいアプリケーションの場合、デジタル信号処理にはDSPよりもFPGAの方が適しており、FPGA内にプロセッサコアを追加すればDSPを使用せずに済むというものである。同様に、シグナル処理を必要とするアプリケーションについては、統合されたデジタル信号処理拡張機能を組み込んだマイクロプロセッサ・アーキテクチャでDSPを置き換えられるという主張もある。
 これらの主張は、ハイエンドの領域ではFPGAが、ローエンドの領域ではDSP機能を内蔵したマイクロプロセッサがDSPの領域を侵食しつつあることを示唆している。しかし、組み込みシステム設計においては、DSPをFPGAや統合マイクロプロセッサで置き換えることは、8ビットのプロセッサを32ビットのプロセッサで置き換えようとすることに等しい。言い換えれば、組み込みシステム設計には依然としてDSPが使用されているし、8ビットあるいは4ビットのプロセッサでさえまだ消滅してはいない。事実、半導体ベンダーはここ1、2年の間に、「競争と交替」から「共存と補完」を目指すスタンスにシフトしつつある。この変化はDSPとFPGAのサプライヤに最も顕著に見られる。
 半導体ベンダーがこの流れをはっきり認識するまでには時間がかかったが、ユーザーには早い段階でこの流れが見えていた。設計上の制約条件にはそれぞれに最適なプロセッサアーキテクチャがある。大量生産される民生機器向けアプリケーションでは、絶えず新しい機能を搭載しながら多機能を1つのエンドシステムで提供しなくてはならないため、設計には多様なトポロジで組み合わされた複数のプロセッサ・アーキテクチャが利用されつつある。競争関係から補完関係へのシフトによって今後期待されることは、複数の処理技術を同時にサポートできる開発ツールやデバッグツールが提供されることだ。
 異なるプロセッサ・アーキテクチャを1つの設計に混在させることで、開発者はシステムにかかるコスト、消費電力、設計の複雑さを低減し、製品化までの時間を短縮できる。また、保守が容易になるため、繰り返し派生する設計サイクルにおける開発期間も短縮できる。なぜなら、プロセッサ・アーキテクチャごとの特長を活かして、処理要件を効率的に満たせるからだ (別掲記事「プロセッサ・アーキテクチャの特長」を参照)。


ちょうど良い所を狙う

 汎用マイクロプロセッサには、コストと電力効率のトレードオフがあるものの、あらゆるプロセッサ・アーキテクチャの中で最高の柔軟性と処理パフォーマンスを実現している。マイクロプロセッサは、予期せぬ処理動作が発生したときにも最大限の処理パフォーマンスを達成し、複雑な回路で予測不能な変化が起きても対応できる。この複雑な回路には、深いパイプライン、複数レベルのオンチップ/オフチップキャッシュメモリー、分岐予測ロジック、多重命令発行エンジン、アウトオブオーダー実行、投機実行を用いるスーパースカラーアーキテクチャが採用されていることもある。
 最高レベルの柔軟性を維持するため、マイクロプロセッサは実世界との接続に外部のメモリー、デバイス、コントローラを使用する。そのため、大規模で複雑なOS(operating system)を実行することもできる上、従来のソフトウエアを再利用することにより成熟した開発ツールインフラのサポートを受けることもできる。マイクロプロセッサ搭載システムは、コストや電力消費量、システムサイズよりも開発サイクルの短縮を優先した高速プロトタイピングとPOC(proof of concept:機能検証)に向いている。このことは、DARPA(defense advanced research products agency:高等研究計画局)主催のGrand Challengeに参加したチームが車載用に選択した多くのプロセッサを見ても明らかだ*4)
 汎用マイクロプロセッサの特長は、同じプロセッサリソースで異種の処理スレッドを実行、管理、マルチタスキングする場合など、処理動作と負荷の不確実性が高いシステムをサポートできることだ。デスクトップ型パソコンやノート型パソコンは、こうしたシステムの典型例である。マイクロプロセッサの柔軟性により、これらのシステムはユーザーインターフェースと高レベルなアプリケーションコードの開発を容易にサポートできる。
 市場には多種多様なマイクロプロセッサが出回っている。一般的なマイクロプロセッサ・アーキテクチャとしてはx86、ARM、MIPS、PowerPCがあり、これらのアーキテクチャは数多くのサプライヤにサポートされている。一方、マイクロコントローラにも多数のアーキテクチャがあり、様々なデバイスに組み込まれている(マイクロコントローラのサプライヤに提供されているデバイスについては*5)を参照のこと。
 マイクロコントローラは、マイクロプロセッサのような柔軟性と高い処理性能を犠牲にする代わりに、コストと電力効率を追求した特殊なプロセッサである。ターゲットアプリケーションのニーズに合わせ、オンチップリソースを最大限に活用できる1つのデバイスコンフィギュレーションを実現することで、これを可能にしている。各デバイスにはプロセッサコアの他、オンチップメモリー、タイマー、I/Oライン、ペリフェラル、デバイスコントローラが組み込まれている。オンチップペリフェラルには、A-Dコンバータ、D-Aコンバータ、PWMの他、I2C、SPI、UARTなどのシリアル通信インターフェースなどがある。一般にマイクロコントローラは、マイクロプロセッサに比べるとはるかに少ない外部コンポーネントで動作する、自己完結型の処理・制御システムと言える。
 マイクロコントローラのサプライヤは、処理パフォーマンス、統合ペリフェラル群、オンチップメモリー、メモリー管理、パッケージングオプション、電力管理、開発サポートなどで特長を出すことによって製品の差異化を図っている。1つのマイクロコントローラファミリは、多くの類似した派生的コンフィギュレーションで構成されていることが多く、設計者は処理量やオンチップリソースのサポートに応じた価格のものを選ぶことができる。マイクロコントローラは、ターゲットの組み込みシステムアプリケーションに合わせてボードスペース、コードサイズ、電力損失を最適化しているため、柔軟性では汎用マイクロプロセッサに劣るが、コスト効果は高い。
 マイクロコントローラとマイクロプロセッサのもう1つの違いは、リアルタイム処理の制約条件を満たすために設計者が利用できるリソースの抽象化のレベルにある。一般にマイクロプロセッサを使用する設計者は、機能が豊富なOSに依存してペリフェラルリソースの抽象化と管理を行うが、マイクロコントローラを使用する設計者は、オンチップペリフェラルとコントローラリソースに直接アクセスするか、よく使われている汎用のRTOSを使用する。RTOSは、マイクロプロセッサのOSに比べると機能が少ないため、決定的なシステム動作をより効果的にサポートできる。
 マイクロコントローラが得意とする領域は、遅延許容幅が少ないマシン制御やモーター制御など、外部の実世界イベントに対してリアルタイムに応答しなくてはならないシステムである。マイクロコントローラは、高速で頻繁に発生する、優先度に基づくコンテキストスイッチに対応している。多くのマイクロコントローラには、システムが数クロックサイクル内で外部イベントを検知して応答し、リアルタイム制御アプリケーションに適した、小さく予測可能な応答ウィンドウを提供できるよう、特殊なハードウエア割り込み処理が採用されている。この高速で決定的な割り込み応答機能に比べると、OSを介して割り込み処理を行うこともあるマイクロプロセッサの割り込みシステムは遅く、予測不能である。
 マルチプロセッサにはマイクロプロセッサにない利点がある。複数の8ビットデバイスで構成される小さなマイクロコントローラは、あらゆるプロセッサの中でも消費電力が最も少ない。これらのデバイスは、電流損失が非常に少ないディープスリープモードに対応しており、外部イベントや経過時間に基づいてウェークアップできる。この機能は、電力消費量が大きくアイドル時間が長いシステムにおいて、ヘルスモニタリングやシステム起動シーケンスといった周期的タスクの処理を実行するのに理想的である。
 マイクロコントローラと同様、DSPもまた、マイクロプロセッサのような柔軟性と汎用処理パフォーマンスを犠牲にして、コストと電力効率を追求した特殊なプロセッサである。しかし、DSPがマイクロコントローラと異なるのは、データストリームに対する連続的かつ大量の計算処理をリアルタイムでサポートするためにオンチップリソースを最大限に利用して、マルチタスキングやコンテキストスイッチには重点を置いていない点である。
 DSPは小数形式をサポートしており、配列、循環バッファ、ビット反転アルゴリズムに特殊なアドレス生成を使用する。DSPの多重バスとメモリー構造は、単一サイクルMAC(積和演算)の実行をサポートする同時メモリー処理を可能にしている。DSPのレジスタは、メモリーアクセスを最小限に抑え、ゼロ・オーバヘッド・ルーピングを実現する。DSPの特殊な構造により、演算ユニットには常に新しいリアルタイムデータが供給される。DSPアーキテクチャの構造は、ターゲットアプリケーションによっても異なる(DSPのサプライヤおよび供給されているデバイスについては、*6)を参照のこと)。
 DSPのサプライヤは、持続可能な計算パフォーマンス、コード密度、電力消費量、開発サポートによって差異化をはかっている。マイクロプロセッサやマイクロコントローラの場合とは異なり、信号処理開発者は信号処理アプリケーションにおける計算効率とコンテキストスイッチ量の低減を重視しているため、RTOSのサポートはほとんど、あるいはまったく必要としない。今日のDSPアーキテクチャには、ほとんどの信号処理コードを効率的にコンパイルできる直交命令セットアーキテクチャが採用されている。
 DSPの特長は、最低限のコストと電力で高い演算性能を持続できることだ。制御が難しく計算負荷の高いアルゴリズムを除き、上位領域は徐々にFPGAと重なりつつある。VoIP(voice over internet protocol)は、FPGAのみの実装ではうまく機能しない、計算負荷の高いアルゴリズムの一例である。なぜなら、ドメイン固有のVoIPデータ圧縮方式には演算制御状態と決定実行が多すぎるからだ。VoIPのケースでは、アルゴリズムがよりコスト効果の高いソフトウエアとして実装される。下位領域は、制御とシグナル処理の構造を1つの命令エンジンに結合した統合アーキテクチャをベースとするプロセッサと重なる。
 統合プロセッサ・アーキテクチャは、マイクロプロセッサよりも、マイクロコントローラとDSPに近い。1つの命令エンジンで、マイクロコントローラ・アーキテクチャを拡張して信号処理機能を追加したものか、制御ロジックを処理する回路をDSPアーキテクチャに組み込んだものである。統合プロセッサ・アーキテクチャではRTOSがサポートされていることが多い。制御と演算処理という異なる動作をつなげる特別な回路を組み込む必要があるため、最適化と特殊化の面ではマイクロコントローラやDSPほどでもない。同じ命令エンジンで制御と信号処理を行うため、2つのプロセッサ間の共有データを密結合させるのは容易であろう。
 統合プロセッサ・アーキテクチャは、制御要件あるいは信号処理要件がそれほど厳しくないシステムに適している。2つの異なるプロセッサを使用する必要がないため、システムBOM(bill of materials:部品表)を低減できる。統合プロセッサをマルチプロセッサ設計で使用する利点は、開発にかかる労力を最小限に抑えられることだ。プロセッサの役割を制御と信号処理に分ける場合でも各プロセッサの設計者は同じツールを使用することになるため、一方のプロセッサ向けに開発されたコードを他方のプロセッサに移植できる可能性がある。


アルゴリズムを回路に自動変換

 低コスト、低消費電力で高い処理パフォーマンスを実現するもう1つの方法として、特定用途向けのハードウエアアクセラレータとコプロセッサを利用する方法がある。このようなアクセラレータは、FPGAで実行可能な個別のデバイスまたはIP(知的財産)として入手できる。アクセラレータが量産アプリケーションに有用であることが実証されれば、プロセッサのサプライヤが自社製品にアクセラレータを統合することも考えられる。たとえば、米Texas Instruments社製のDSPには、Viterbiデコード用のハードウエアアクセラレータが組み込まれている。ライセンス可能なアクセラレータや統合アクセラレータがたやすく入手できるようになれば、アクセラレータ自体は設計の差異化要因にならない。アクセラレータの価値は、計算負荷を軽減して差異化要因となる機能をシステムに追加したり、システムのコストや消費電力を低減したりできる機会をもたらすことにある。
 2005年は、ハードウエア実装でアルゴリズムの実行速度を上げるための設計支援ツールが数多く発売された*2)*3)。これらのツールを使用すれば、設計者はより簡単にカスタムアクセラレータや命令セット拡張を開発できる。アクセラレーション機能は一般に入手できるものではなく、アクセラレーションIPのように今すぐ商品化できるものでもないため、カスタムアクセラレータを開発できることは大きな差異化要因となり得る。
 ほとんどの場合、これらのツールはFPGAへのソフトウエア/ハードウエア実装をターゲットにしている。モデルやソースコード、そしてCriticalblueの場合はオブジェクトコードをハードウエア実装する際の変換方法は数多くあり、業界関係者は今後数年、この部分での処理パフォーマンスの向上に多くのエネルギーを費やすことになるだろう。これらの実装には固定機能のRTLブロックを使うものや、ツールを使ってパフォーマンスを最適化できるプロセッサブロックを使うものもある。
 米Stretch社のコンパイラツールは、プロセッサコアと、プログラマブルファブリック(プログラム可能な回路)を1つのデバイスに統合したプロセッサデバイスをターゲットにしている点で他のツールと異なる。同社のコンパイラツールの1つの目的は、設計者が実装よりもアルゴリズムと機能に焦点を当てて開発できるようプログラマブルロジックを抽象化することである。プロセッサコアとFPGAを統合した混在プロセッサの復活が期待され、それに伴ってソフトウエアからハードウエアへの変換を自動化するツールが登場する可能性が高い。
 高性能民生機器向けアプリケーションでは、アクセラレータまたはコプロセッサを組み込んだFPGAを、ホストプロセッサまたはDSPにリンクさせるのが一般的になりつつある。FPGAの価格が下落しているため、設計者は負荷の大きい計算をFPGAに肩代わりさせることで全体の設計コストと消費電力量を減らせる他、それほどパワフルでないホストプロセッサまたはDSPを使用することができる。FPGAの高い並列処理能力を利用できるアプリケーションでは、全体の電力消費量を大幅に低減できる。 特に、FPGAによる実装で、システムが高性能プロセッサを使用する場合よりもはるかに低いクロックレートを使用できる場合には有効だ。
 ホストプロセッサまたはDSPのコプロセッサとして使用されるFPGAの特長は、高度な並列処理を要するアルゴリズムや、厳しいタイミング条件に合わせてパイプライン処理できるアルゴリズムである。しかしコストと消費電力の面から見ると、特に複雑な制御構造を必要とするシステムでは、ホストプロセッサやDSPを完全にFPGAに置き換えることは効率的とは言えない。FPGAのサプライヤはこのことを認識し、FPGAで動作する独自開発のプロセッサコアを提供している。FPGAベンダーから提供されているツールは、標準的なペリフェラルを組み合わせたプロセッサコアの設定をサポートしているほか、カスタムアクセラレータとプロセッサコアとの緩結合また密結合をサポートしている。つまり、これらのツールを使用すれば、設計者は少量のSoC(system on chip)の代わりとしてFPGAを利用しやすくなるのだ。


立ちふさがる課題

 これらのプロセッサアーキテクチャをチップ内に混在させなくてはならない設計者にとっては依然として課題が残っている。混在処理設計をサポートするツールの課題は、プログラミングモデルをどのように維持し、設計者にどのようにして並列処理を活用させるかということだ。混在処理設計を採用し、それをサポートするツールを使用する場合には、開発チームの高い生産性を維持することが重要である。設計チームが、特定のプロセッサ・アーキテクチャに対応した開発ツールに関する知識が乏しいことを理由に、そのアーキテクチャを候補から外すことは珍しいことではない。
 一企業の既存のコードには、膨大な量のエンジニアリングと設計に関する教訓が詰まっている。設計チームがアプリケーションコードを一から書き直したいと思わないかぎり、利用可能な並列処理を活かすためには従来のコードを再分割する努力が必要である。しかし、努力してもクリーンかつ自然に分割できるとは限らない。再分割がうまくいかないと、データ構造の実装もうまくいかない。データ構造が自然かつ明瞭にアプリケーション要件を表していなければ、面倒なコーディングとデバッグの作業が発生する。
 混在処理設計を採用した上で既存のコードを使用する開発者の生産性を維持する鍵は、より成熟したコンパイラ制御技術にある。コンパイラによってシステムリソースのすべてを可視化できないかぎり、リソースの割り当てと利用については保守的な仮定を立てるしかない。コンパイラのパフォーマンスを向上させ、従来のコードから最善の結果を得られるよう、コンパイラに使用される規則と仮定を開発者が自在に設定できる新しいスキルがそのうち出現するだろう。
 このトレンドは、特定の垂直市場向けデバイスを提供し続けているプロセッササプライヤにも見られる。これらのデバイスにも、ターゲットアプリケーションに適したプロセッサリソース群、ハードウエアアクセラレータ、プログラマブル・ロジックが組み込まれるようになるだろうが、ターゲットになるのは量産アプリケーションのみだろう。
 その他のアプリケーションでは、設計者は自分で処理オプションを組み合わせる必要がある。分散マルチプロセッサトポロジを使用することで処理パフォーマンスを向上できることが明らかになりつつある。今日のツールベンダーの課題は、タスクをうまくカプセル化して、混在プロセッサコンフィギュレーションのサポートを実現する方法を生み出すことである。
 
プロセッサ・アーキテクチャの特長

 アーキテクチャにはそれぞれ得意とする処理の特長が異なる(図A)。すべての対応領域に他の対応領域と重なり合う部分を持たせることで、考え得る処理シナリオのすべてをカバーしている。したがって、カバーされていない領域があれば、そこには他の特定のアーキテクチャが存在すると想定できる。処理要件が厳しく、演算負荷の大きいアプリケーションが増えるにしたがい、統合され、混在する処理トポロジがあちこちに見られるようになるだろう。
 ソフトウエアの複雑さをどのように評価するかについて、本記事では処理に関する4つの評価基準を取り上げている。計算負荷は、アプリケーションが一定時間内で実行しなくてはならない反復計算の数を評価するものだ。この方法では、計算の制御処理を見ることによって、マルチステートアルゴリズムが純粋にハードウエア実装するには大きすぎるかどうかを把握できる。本記事では、これら2つの基準をプロセッサの特長をマッピングする主軸として使用している。
 アプリケーション処理は計算負荷に相当する。しかし、コードが一貫して予想どおりに反復されることはない。アプリケーション処理は並列実装に向かないコードである。最後は、システムの応答要件を基準にする方法である。中でも最も関係があるのはリアルタイムシステムの応答要件である。この方法は、たいていはオペレーティングシステムまたはキャッシュの使用が原因となる、プログラムの実行タイミングの不確実さが、どのようなときにアプリケーションの応答要件を超えるのかを把握するのに役立つ。また、マイクロコントローラが適する主なアプリケーション要件を特定することもできる。
図A 処理アーキテクチャの得意領域が互いに補い合ってアプリケーションの処理要件を満たしていることを示した概念上のマッピング (協力:米Stretch社CEO、Gary Banta氏)
▲本文へ戻る

用語解説 / 会社情報
*1)
"Control and Signal processing : Car one processor do it all ? EDN, March 7, 2002, pg 63.
▲本文へ戻る
*2)
"EDN hans-on project : Accelerate your performance" EDN, Nov 11, 2004, pg 50.
▲本文へ戻る
*3)
"EDN hans-on project, part2 : Automate your acceleration" EDN, Dec 7, 2004.
▲本文へ戻る
*4)
"Operating alone" EDN, Dec 5, 2005, pg 49.
▲本文へ戻る
*5)
"The 32nd annual Microprocessor Directory : Charting your cource" EDN, Aug 4, 2005, pg 57.
▲本文へ戻る
*6)
“用途に最適なDSPを選ぶ”EDN 2005年9月号, pp.77-88
▲本文へ戻る

雑誌無償購読申込み ニュースレター登録 この記事に対する感想/ご意見
Reed Electronics Group
Electronic BUSINESS Japan | Design News Japan | Semiconductor INTERNATIONAL | DETAIL JAPAN
EDN Japanについて | 広告掲載について | サイトマップ | お問合せ
 Copyright (C) 2000-2007 Reed Business Information Japan K.K. 
個人情報に関する方針 | 著作権・リンクについて | 会社情報