DSPマイコン

ひところからDSPマイコンという言葉が聞かれるようになりました。DSPとしても使えるマイコンであったり、マイコンとしても使えるDSPであったりします。以下、このコウモリみたいな分野の製品について考えてみましょう。

DSPとマイコンの違い

DSPにせよ、マイクロ・コンピュータにせよProgram stored Automatic Digital Computerであることに変わりはありません。木で鼻をくくったような言い方をすればどちらもできそこない（失礼）のチューリング・マシンですから実行できるアルゴリズムにそれほど大きな違いがあるはずはないのです。また、周波数を比べると両者の間にそれほどの差があるわけではありません（下の表）。

「Pentium4はもうすぐ3GHzだよ」と、おっしゃる方。このサイトは組み込みプロセッサの話題を取り扱っていますのであしからずご了承ください。

動作周波数がほぼ同じなので両者にはそれほど差はないように見えます。そういうわけで両者の機能を兼用できないかという考えが出てきます。

マイコンの立場

最近は普通の遅い制御だけじゃなくてJPEG、MPEG Audio、MPEG Videoなどのメディア信号処理が増えてきた。DSPやASICで実現するお客さんが多いが、このままだとマイコンにかけられるコストがどんどん下がるばかり。いっそこういった機能をマイコン側に飲み込んだらどうだ。付加価値として販売価格を上げることができるし、競合他社に対する強みにもなる。

DSPの立場

いつまでたってもマイコンのおまけだとコスト圧力から逃れられない。ハイエンドだけに売ってもおいしくない。周波数があがって余力もでてきたので、いっそマイコンの機能を取り込んだらどうだ。付加価値として販売価格を上げることができるし、競合他社に対する強みにもなる。

とまぁメーカーとしてはこの市場を熱い視線で見ているわけです。DSPを売っている会社は比較的販売価格を高くしていますから、マイコン・メーカーから見るとうらやましいですし、DSPメーカーにしてみればマイコン・メーカーが握っている広大な市場がうらやましくあります。ところで問題は両者の融合が簡単かどうかです。まさか糊で張り合わせるわけにも行かないでしょう。まずは両者の違いから見てみましょう。そうすれば融合可能かどうかわかります。比較対照のDSPは古典的なDSPの例です。

（多分に恣意的な表ですが）こうしてみると、マイコンはC/C++言語を効率よく実行することを主眼に開発されており、DSPはFIRに代表されるMAC演算を効率よく実行することを主眼に開発されていることがわかります。両者の融合が一筋縄では進まないことは自明です。新規にアーキテクチャーを起こすのならばともかく、過去のアーキテクチャーを延長したDSPマイコンの場合はかなり歪が大きいであろうことが予想されます。

DSPマイコンが直面するハードル

さてADSP-2191は古典的なDSPであるADSP-218xを改良して、DSPマイコン的な用途をすこしだけ狙った設計になっています。

• 2つあったアドレス空間を1つに統合した
• データ・レジスタとアドレス・レジスタの長さを16ビットにそろえた
• データ・レジスタの自由度を高めた
• リンケージ命令を導入した
• ペリフェラルを強化してUART、SPI、汎用タイマー、GPIOを導入した

こういった改良はC/C++言語への対応と汎用マイコン的な用途を強く指向したものです。ではこれでADSP-2191をDSPマイコンと呼んでいいかというと躊躇してしまいます。最大の問題はアドレッシングです。ADSP-2191はワード単位のデータ・アクセスしかできません。これは現在流通しているマイコン用ソフトウェアを移植する上で大きな足かせとなります。最近は大規模なミドルウェアが多数流通していますが、多くはアクセス単位がバイトサイズであると仮定して設計されています。そのため、ワード単位のアクセスしかできないADSP-2191にプログラムを移植するとなるとそれなりのハードルの高さを意識せざるをえません。

一方でマイコンに信号処理を追加するアプローチを考えてみると、これも相当に難しいといえます。例えばMACユニットを追加するにしても、これを活用するには1サイクル毎に途切れなく2つのオペランドをロードしなければなりませんし、ループ命令も必要です。SH3-DSPはかなりがんばっており、この二つの条件をクリアしています。しかし、過去のCPUを拡張した代償として

• DSP用のレジスタがそれほどない
• モジュロー・アクセスが弱い
• モードを多用している
• ハード・ウェアループをオーバーヘッド無しに入れ子にできない

といった制限があります。これらは致命的な欠点とは言いがたいので、最高性能を狙わない拡張であるのならそこそこ使えるといったところです。

このように過去のアーキテクチャーの延長としてのDSPマイコンは、資産を引きずっているだけに綺麗な形での両対応は難しいという問題があります。ただどちらかというとDSPをマイコン化するよりもマイコンをDSP化するほうが楽なように見えます。古典的なDSPにはワード・アクセスという足かせがついており、これがある限りC言語で書かれた膨大な資産のうちかなりの部分は移植に苦労することになります。また、そもそもDSPは命令のビットフィールドに冗長部が少なく、大規模な拡張は困難です。一方、RISCマイコンは32ビット命令であればスカスカというのが普通であり、かなり大胆な命令拡張を行えます。しかし、デュアル・ロード、MAC命令、モジュロー・アクセス、ハードウェア・ループなどの実装は本来のRISCマイコンの単純さを損ねかねません。

DSPマイコンはメーカーの思惑とは裏腹に、よほど成功したマイコンを元にしない限り1から設計するほうがいいのかもしれません。

1+1≠2

さて、アマチュアにとっては綺麗に作れるかどうかが最重要関心事です。が、やっぱりプロは違う目で見るでしょう。

開発部長

なに？CPUとDSPをワンチップにできる？開発ツールも一つで済むのか。いいねぇ。実装面積も減るしコストも減るな。よし、検討しよう！

プログラマ

え？制御処理と信号処理を同じプロセッサでやるの？ITRON走るのかなぁ。ITRONの上でハード・リアルタイム処理できるのかなぁ。デバッグ面倒そうだなぁ…。

と、いう会話がなされているかどうか。マイコンの仕事とDSPの仕事をいっしょにさせたときに開発効率が維持できるかどうかがDSPマイコンの命運を決めると考えられます。もっとも、どれだけプログラマをこき使えるかで決まるとも言えます :-P

⇒次は畳み込み演算二態