組み込み向けプラットフォームの真価：「DaVinci」の設計環境を試す（2/3 ページ）

[Robert Cravotta，EDN]

DaVinciとOMAPの比較

　DaVinciとOMAPにはいくつかの類似点がある。1つは、どちらもARMコアとTI社のDSPコアを組み合わせたヘテロジニアスプロセッシングアーキテクチャを採用している点である。また両者とも、標準API（application programming interface）をサポートし、各コアはコードの開発と実行をカプセル化して隔離している。どちらのチップファミリにおいても、アプリケーションソフトを開発するプログラマはARMコアを対象とした使い慣れたツールを利用することができ、DSPに熟知していなくても、統合されたDSPコアの能力をうまく引き出すことが可能である。同様にDSPのプログラマも、ARMコアについて学習することなく、使い慣れたDSPコア用のツールを使用することができる。DaVinciとOMAPはいずれも、TI社のソフトウエア開発ツール「eXpressDSP」互換のアルゴリズムを採用している。また、ARMコードをマスターとし、DSPコードをスレーブまたはコプロセッサとして扱うことができる実行モデルをサポートしている。

　相違点はOMAPプラットフォームが携帯電話機を対象としているのに対し、DaVinciはデジタル映像および音声の処理を主なターゲットとしている点である。また、DaVinciはソフトウエア開発サポートの面で、OMAPよりもかなり進展していることがうかがえる。両者はターゲットとする用途が異なるため、それぞれのプラットフォームが内蔵するDSPコアも違う。OMAPは電力効率の良い「C55x DSPコア」を採用しているのに対し、DaVinciはより高性能な「C64x DSPコア」を使う。また、OMAPは「ARM925コア」を使用しているのに対し、DaVinciは「ARM926コア」を用いる。両者のチップはそれぞれがターゲットとする用途に適した異なる周辺機能群を集積する。例えばDaVinciは、ビデオ信号処理用のサブシステム、シリアルインターフェース、メモリーやデータストレージ用のインターフェースなどの機能を内蔵している（図1）。

図1　TI社のDaVinciプラットフォーム　DaVinciプラットフォームは、2つのプロセッサコアやビデオ信号処理用サブシステム、外部メモリー/データストレージ用インターフェース、シリアルインターフェースなど多くの機能を搭載している。

　DaVinciプラットフォームは、TI社がOMAPシステムの事業を通じて得られた技術上およびビジネス上の知識や経験を生かして開発されている。例えば、DaVinciプラットフォームでは、「xDAIS（eXpressDSP algorithm interoperability standard）」に基づいたインターフェースが、xDMまたはxDAIS-xDM（xDAIS for digital media）インターフェースで拡張されている。このインターフェースは、DaVinciまたはOMAPシステムにおける各プログラマの役割、つまりARMとDSPの信号処理の役割に影響を与える。

　インターフェースは、アプリケーションソフトのプログラマが、DSPコアに搭載されたアルゴリズムをロード、アンロードしたりするための機構である。その一方で、xDMの重要な役割は、多種多様なアルゴリズム、ソースコード、ベンダーにわたるマルチメディアコーデックに対応したプラグアンドプレイアーキテクチャを実現することだ。各種のマルチメディアコーデックに対し、共通のステータスとパラメータを定義することにより、プログラム全体のソースコードを変更することなく、異なるコーデックに置き換えることを可能とする。つまり、変更が必要なのは、コーデックのソースコードのみとなる。

　xDMでは、映像、画像、音声、オーディオの4種類のコーデックに対する統一されたAPI集合を定義し、xDAIS仕様に追加する。xDMの8つの汎用インターフェースは、4種類のコーデックに対するエンコーダとデコーダから成る。またxDMは、メタデータ解析、ファイル形式、カスタム処理などの要求に対応する拡張機能もサポートしている。xDMのAPIには、xDAISが定義する関数セットにprocess（）およびcontrol（）の2つの新しい関数が追加されている。xDAISとxDMコンポーネントにおけるインターフェース関数の呼び出し順序は似ているが、xDMではalgControl（）メソッドが削除されている点だけが異なる。xDAISアルゴリズムをxDMアルゴリズムと一緒に使用すると、xDMのcontrol（）メソッドがalgControl（）メソッドの代わりに処理を行う。

　OMAP製品とは異なり、DaVinci評価モジュール製品にはハードウエア化されたDSP/コーデックの3つの組み合わせが含まれており、開発者が自由に使えるようになっている。ハードウエア化されたコーデックを提供することにより、製品に使いたいコーデックが実装される前に、開発者がシステムの機能をモジュール上で評価することができるようにしている。評価モジュールには、カメラ、液晶パネル、赤外線リモコン、スピーカ、ハードディスクドライブ（HDD）などのキットが含まれている（図2）。そのHDDには実行可能なデモソフトがインストールされており、システムのエンコード/デコード、ネットワーク機能が直ちに利用できるようになっている。

図2　DaVinci評価モジュール　DaVinci評価モジュールには、カメラ、液晶パネル、赤外線リモコン、スピーカ、HDDが含まれ、デモや開発のためのソフトウエアが添付されている。

　DaVinciとOMAPの両プラットフォームを使った製品で異なる点がもう1つある。DaVinciプラットフォームでは、ARMコア用に開発されたリソースが直ちに利用できる。DaVinci評価モジュールには、開発ツールとドキュメントが整備されているからで、すぐに作業を開始しデモが行える。こうした対応ができた理由の1つは、TI社が開発環境をLinuxに限定したためである。DSPコア用の開発ツールは、統合開発環境「Code Composer Studio」に含まれる。TI社は、DaVinciを使った製品開発をサポートするため、2006年9月に2つのツールを出荷した。前出のeXpressDSPは、開発者がxDMコーデックをチップに統合する際の支援を行う。それまでは、システム設計者はそのほとんどを手作業で行っていた。もう1つの新しいツールである「TMS320 DM644x SoC Analyzer」は、ARMコアおよびDSPコアの両方のデータを、同一の時間軸上でキャプチャして表示する。これにより、システムの相互作用、負荷分散の状況、データ処理のスループットにおけるボトルネックなど、問題点の分析と特定が行える。

　筆者は今回の記事執筆に当たり、DaVinciに関するセミナーを受講した。セミナーの前半では、システムを構成する要素と各周辺機能の概要が示され、ビデオ信号処理用サブシステムのコーディング例がいくつか提示された。ここでは、DaVinci Framework APIと、アプリケーション、信号処理、コーデックエンジン、サードパーティ製ソフトウエアの各処理層の中でも上位レベルについて学んだ。また、各プログラミング層をサポートする、自社製/サードパーティ製の開発ツールについても説明があった。セミナーの後半では、TI社から認定されたソフトウエアプロバイダによる発表が行われた。

　DaVinci評価モジュールが手元に送られてきたのはセミナーを受講してから数週間後のことである。モジュールの全コンポーネントを接続し、デモを正しく動作させるまでの作業は簡単だった。デモをすぐに動作させることができたのは、すべてのソフトウエアがHDDにインストールされていたことが大きい。最も良かった点は、作業を始める前に各コンポーネントとインターフェースの接続が適切に行えて、正しく動作することを確認できたことだ。

　準備作業を終えようとしたとき、思わぬ問題にぶつかった。クロスプラットフォーム環境での開発は何度も経験しているし、この実践プロジェクトではLinuxをターゲットに開発を行うことも認識していた。しかし、Linux環境で開発作業をしなければならないことは知らなかった。Windows環境で作業が行えるものだと思い込んでいたのだ。評価モジュールのすべての初期ツールはLinux環境でしか動作しない。開発ツールは米MontaVista Software社から提供されていたため、Linux以外のホスト環境をサポートするかどうか同社のウェブサイトを確認したところ、Linux、Solaris、Windows環境をサポートしていることが分かった。

　TI社のサポートスタッフからは、DaVinci用のツールはLinux環境しかサポートしないといわれた。筆者はLinuxが嫌いだというわけではないが、自分のコンピュータに同OSをインストールしたくはなかった。Linuxをインストールしたくない理由はむしろ、プロジェクト自体とはあまり関係のない部分で時間と労力を費やしたくなかったからである。ホストシステムでLinuxを使用し続ける予定はなく、ホストコンピュータのOSについてもう一度学習し直す時間もなかったからだ。

　結果的に、TI社のサポート部門から、「Red Hat Linux」を送付してもらい、このプロジェクトでのライセンス使用を認めてもらった。このため筆者は「VMware Player」を使って自分のコンピュータでLinuxアプリケーションをエミュレートすることができた。これにより、手作業で自分のコンピュータをデュアルブート設定にする手間が省け、早くプロジェクトに取りかかることができた。

　Windows環境である自分のコンピュータで、データファイルやアプリケーションソフトを検索する方法は分かっている。アプリケーションソフトは、ほぼ筆者の予想通りに動作した。この種のアプリケーションソフトがどのように動作するかは長年の経験から理解している。Linuxアプリケーションのエミュレーションは難しい作業ではなかったが、その動作はWindows環境でのそれとは異なる点があった。例えば、添付のAdobe Acrobatドキュメントを参照するのに、同梱されていた「Gnome Ghostview」を使用したが、このブラウザで簡単なテキスト検索を行う方法は結局最後まで分からなかった。インターネットで別のブラウザを探すという手もあったが、完璧に動作するブラウザがすでに手元にあるため、そこまでする気にはなれなかった。

　先述したように、この評価モジュールがLinux環境しかサポートしないのは、DaVinci用のツールチームが、評価モジュールの完成と同時にツールを提供しようと考えたためである。評価モジュールを早期に導入するユーザーの多くは、Linuxをホスト環境として使用した経験があり、LinuxをターゲットとするだろうとTI社は考えた。このため、TI社のツールグループはLinux以外のOSのサポートは、次の段階でよいと判断したのだ。

　今回の実践プロジェクトでは、エンコード、デコード、ネットワークのデモを行うためのプログラムコードを利用して、簡単なテレビ電話を開発する計画であった。最初の問題は、筆者がDaVinci評価モジュールを1つしか持っていなかったため、デモが双方向でリアルタイムには実行できないということである。最初の実行でシステムの片方の動作をシミュレーションし、次の実行でもう片方の動作をシミュレーションしなければならない。TI社から1つの評価モジュールを入手することさえ至難の業で、新たなモジュールを入手する時間はなかった。

　もう1つの問題は、モジュールに添付されていたエンコード/デコード用のサンプルソフトは、音声または映像データのいずれかを処理するもので、両方の処理はできなかった。また、両者を同期させる方法も明示されていなかった。TI社のツール担当グループとの会話から、同社が音声と映像の同期などの機能に対する支援としてメディア処理ライブラリ「GStreamer」を枠組みとして考えていることは知っていた。GStreamerは通常のライブラリよりも上位のレベルに位置する。今回のプロジェクトの後半は、テレビ電話のデモを活用してインドのIttiam社と共同で開発を行った。

　今回のプロジェクトでは、米Green Hills Software（GHS）社のDaVinci向けデバッグプローブ「Probe」および統合開発環境「Multi」も試用してみた。ProbeはDaVinciに接続してハードウエアをデバッグするための機器である。一方のMultiは、通常はWindows、Linux、Solaris、HP-UXホストシステム上での開発をサポートしているが、今回のプロジェクトでは、これらのツールをLinux環境でのみ使用した。Multiは、アプリケーション、DSP、システムの各プログラミング層の要求をサポートする。Probeを併用することにより、MultiでARMコアおよびDSPコアの両方の動作を視覚化することができる。また、Linuxカーネルの状態表示もサポートしている。デバッグ情報をオンにしてLinuxカーネルイメージを作成し、GHS社のdblinkツールを用いて、GCC（GNU compiler collection）が生成するdwarfデバッグ情報をMultiが理解できるデバッグ形式に変換することにより、Linuxカーネルの内部を直接トレースすることができた。

　Multiでは、デバッグを行うプロセスを別ウィンドウに分離できる。その際、各ウィンドウが異なる背景色で表示される。この機能は、コード実行を停止させる、プロセスコンテキストブレークポイントを使う場合に便利である。ブレークポイントが設定されたコード行が指定プロセスの一部として実行されている場合のみ利用できる。プロセッサコアを停止した後、命令を前方向および後ろ方向にステップ実行することを可能とする「Time Machine」機能も使ってみた。GHS社は最近、Time Machineに「常時オン」機能を追加した。これにより、開発者はイベントを取得するためにいちいちProbeをオンにする必要がなくなるなど、ツールはより便利になり操作性が向上した。