トランジスタ技術誌の2006年10月号にdsPICの紹介記事が現れました。blogのほうにもコメントをいただいた上、少し感心があったのでマイクロチップ・テクノロジー・ジャパンのドキュメント・ページからdsPIC30の和文ドキュメントをダウンロードして、調べてみました。
dsPIC30のデータ幅は、16bitです。データを格納するためのX空間は16ビット幅のメモリを持っており、1サイクルで1ワードのアクセスが可能です。アドレス空間はバイト単位です。
また、命令幅は24bitです。データを格納するためのY空間は、24bit幅のメモリを持っており、1サイクルで1命令をフェッチ可能です。
さて、命令幅とデータ幅が異なるというのは、16bit DSPではそれほど不思議ではありません。ADSP-2191もデータ16bit, 命令24bitでした。しかし、こういった構成とバイトアクセスの間の折り合いをつけるとなると話しは別です。古典的な設計のDSPではあっさりとバイトアクセスを放棄し、ワードアクセスとしていました。
また、データと命令の折り合いも頭をひねるところです。たとえば、ADSP-2106xや2116xではこの折り合いのためにかなり複雑な機能を導入しており、プログラマの負担が大きくなっています。ADSP-219xではムーアの法則を信じたのか、あっさり24bit命令のうち上位8bitのデータ・アクセスを放棄しています。
dsPICの場合、ADSP-219x同様24bit命令メモリのうち、上位8bitは専用命令を使わない限りデータアクセスができません。これはアーキテクトの割りきりでしょう。個性が強く出ているのはバイト・アクセス部分です。
命令メモリをデータとしてアクセスする場合、バイト・アクセスが可能です。ただし、バイト・アクセス可能なのは24bitのうち、下位16ビットです。上位8bitはデータ・アドレス空間にマップされません。ここまではいいです。面白いのは命令を実行するとき、PCの値が2ずつ増えていくことです。つまりPCは命令幅を2byteと認識していることになります。
一見、これは奇妙です。3バイト命令をバイト空間にマップするならば
のがまっとうな方法に思えます。なぜそうしなかったのでしょうか。おそらくそれは命令空間とデータ空間でアドレスをあわせるためです。
命令とデータの空間が分かれたDSPでは、デュアル・アクセスを低コストで実現するために、どうしても命令空間のをもう一つのデータ空間とする設計になります。たとえばADSP-219xがそれです。これらのDSPの場合、命令空間のオブジェクトをデータと見るか、命令と見るかで同じアドレスであると便利です。実際ADSP-219xはそのようなアーキテクチャになっています。
上の節で説明した「命令フェッチからは2バイト長命令に見える」という話は、ここに落ちてきます。dsPICのアーキテクトも命令空間のデータのアドレスをプログラマに単純に見せるためのうアーキテクチャを選んだということです。この場合、データとアドレスを同じ空間に見せるならば、便宜上PCの値を2インクリメントすることで3バイト長命令を読み続けるというアーキテクチャにせざるを得ません。
汎用プロセッサ・ユーザーから見ると、奇怪極まりないことと思いますが、DSP屋からみると「わかってるな〜」とニヤニヤしてしまいます。
ちなみにBlackfinの場合、命令長が32ですのでこのような問題は発生しません。では219xやdsPICもそのようにすればいいように思えますが、そうはいきません。命令長を伸ばすとメモリ消費が増えるのです。したがってそれにつりあうだけの性能向上が求められます。Blackfinの場合、ビデオ、通信用演算命令の搭載やデュアルMAC命令による性能向上でその分の対価を支払っていると考えられます。219xやdsPICは性能よりコストを重視したアーキテクチャといえるでしょう。
さて、自作電子工作の立場からdsPICを見るとどうでしょうか。ざっと見た感じ、このプロセッサはモーターやサーボの制御を目指しているように見えます。コアがよく練られていることから、そういったアプリケーションであれば同クロックのARMやSHの数倍の性能は出しそうです。扱いやすいパッケージが多いことから、モーターやサーボではよく使われるようになるかもしれません。私はPICで模型飛行機の動力モーター制御をしている方を見かけた事がありますが、そういった方には福音でしょう。
もうひとつ、オーディオ・インターフェースを実装していることも見逃せません。これについてよいニュースと悪いニュースがあります。
まずは良いニュースから。このインターフェースはI2SおよびAC-linkに対応しています。したがって、オーディオコーデックやAC97コーデックを直結し、レジスタをちょいちょいと設定するだけで使えます。
次に悪いニュースです。このインターフェースはDMAを持っていません。8byteの2重バッファを送受共に持っていますが、16bitを超えるオーディオ・データの場合これは2ワード分でしかありません。つまり、L,Rデータを収めると一杯になるため、事実上サンプル・バイ・サンプルで割込みが発生します。48KHzサンプル時にdsPICが使えるサイクル数が1サンプルあたり600サイクル程度であることを考えると
といういずれかを強いられます。
したがって、高度の処理は行えません。また、外付けSDRAMもありませんので大遅延も無理です。一方で、以前作ったADuC7026によるシンセサイザー程度ならば、dsPIC30F4013 + AC97コーデックでより高機能、より良い音を実現できそうです。
このプロセッサはBlackfinのようにRTOS上で信号処理を行うのではなく、単一の割り込み待ちやポーリング・ループでひたすら信号処理をするアプリケーションにむいていると言えます。PICらしいですね。
最後に気になるのは開発ツールです。これについては調べていません。はてさてC言語で信号処理の開発ができるや否や。