月別アーカイブ: 2015年5月

i2sコントローラ改造とDAC基板

このi2sコントローラの構成は、再生部のみですが前回のブログにブロック図を書き起こして掲載しました。

バスにぶら下がる構造のこの手のデバイスは、大抵が、バス経由(ARMの場合はAXIバス)でメインメモリ内のデータをそのデバイス内のFIFOに突っ込めるだけ突っ込んでおいて、データの抜き出し側で一定速で読み出すという方式になっています。この場合、FIFOにはバスのクロックに同期してデータを書き込み、読み出しはオーディオのクロック(22.5792/24.576MHz)に同期して行う、という事になります。

PC用のPCIバスに挿して使用するサウンドカードは、カード上のコントローラがマスタとなり、(自身で主導権を握って)メインメモリからデータを引っ張ってくるものがほとんどで、CPUはデータ転送に関わらないで済むように設計されています。それが合理的な考え方で、その分CPUが他の仕事に専念できるからです。CPUはファイルからオーディオデータを読み込み、必要に応じて各種デコードなどを行ってメモリ上に置いておく、という動作のみが必要になります。

それに対し、このi2sコントローラはマスタになるタイプではなく、あくまでもスレーブデバイスですから、メインメモリのデータは、他者に転送してもらわなければなりません。

通常はその役割をCPUが負うことになり、何もしなければデータ転送だけでCPUが忙しくなってしまうことになります。CPUは、FIFOが空いている限り(FIFOの状況を逐一チェックしながら、満杯でなくなれば)データをメモリから読んでFIFOに書き込むというプロセスを繰り返します。

これではまずいので、そこに登場するのがDMA(ダイレクト・メモリ・アクセス)コントローラ、略してDMACということになります。

あらかじめデータの転送元アドレスと転送先を設定しておけば、i2sコントローラから転送要求が伝わるたびに(1発パルスを受け取るたびに)、メモリからFIFOにデータを自動的に転送するようになっていて、CPUに替わってデータ転送の仕事を行ってくれるのがこのDMACということになります。

i2sコントローラは、自身のFIFOが満杯でない限り転送要求のパルスをDMACへ繰り返し出力します。これは簡単なロジック回路だけ構成することが可能で、こういう仕組みによって、i2sコントローラがマスタにならなくてもCPU負荷を上げることなくデータ転送を行うことができるようにしています。

どちらかというと、二昔前のISAバスのサウンドカードに近い動作方式ですが、ISAバスは1度に16bitのデータしか転送できないのに対してこちら(AXIバス)は32bit分転送できますし、バスのクロックに至っては、ISAバスが数MHzなのに対し、このi2sでは100MHzにしており、PCIバス比では3倍のクロック速度になっています。という事で性能的には段違いといえます。

さて、このi2sコントローラの回路とデバイスドライバを少し改変して上の図のようなDAC基板をつなげるようにしたいと思います。本来、発振器はZYBOのような基板上にあるのが筋だと言う感じもしますが、DAC基板側に置くことになります。

時間を見て、先ずはPCMだけでも192kHzまで普通に対応できるように進めようと思います。

つづく、かな?

I2S controller on ZYBO

前回の記事ではUSDA基板をZYBOにつないでALSA経由で再生実験をしました。

ZYBOの中心となるZYNQというSoCチップは、「PS」 部と「PL」部とからなり、「PS」部にはSoCチップには必須?の汎用外部バス(USBやLAN)などがすでにハードマクロで作りこまれています。「PL」部は現状のFPGAと同様に、設計者が実現したい機能をロジック回路として自由に作りこむことができるようになっています。

ですから、ARM社のAXIバス(ZYNQもご他聞に漏れずARMのSoCです)に繋がる様にI2Sのインターフェース回路を設計すれば、ドライバーソフトも用意する必要はありますが、OSから制御することができるものを作り込めるのです。Linuxを使ってALSA経由で動かせればソフト開発の負荷は下がるでしょう・・・。

ところで、ご存知のアナログデバイス社は、自社の販売するオーディオコーデックなどのデバイスを接続してもらうことを期待して?、VHDLというハードウェア記述言語でコーディングされたI2Sコントローラーの設計データを公開しています。

これを、ZYNQの製造メーカーであるXilinxの開発ツールを使って「PL」部に組み込むことで、容易にI2SコントローラーとARM(CPU)をつなげることができます。

ただし、最初から設計データがあるとは言っても、やはりあらかじめ論理シミュレーションをして動作の様子等を調査しておかないと自信を持って大本につなぐことはできません。

そこで、再生部分のみではありますが、ソースコードを読み、実際にVHDLシミュレータにかけて動作を調べるといったリバースエンジニアリングをしました。その過程でレジスタマップも書き起こしてしまいます。アナログデバイス社から同時に公開されているデバイスドライバーのソースコードの読み込みも、レジスタマップを理解するための助けになります。

オリジナルの設計ではどうやら96kHzまでの対応に限定されますが、ALSA経由でこのモジュールを動かすことができました。次のステップとして、このI2Sコントローラーを192kHz対応に改造し、マスタークロック(今現在でも外には出ています)関係を、22.5792/24.576MHz系で発振器を切り替えて使用できるような構成に変更しようと考えています。

USDA基板の時と同様に、aplayを使っての再生まで確認できました(上記のブートメッセージは再生前です・・・)。

2個の発振器の載ったDAC基板、例によって人気のない?PCM1792Aあたりを搭載し、DSD再生も可能なようにしようかなと思案中です。

I2Sコントローラ、デバイスドライバともに改変が必要になりますが、やろうと思えばできてしまうのが、このZYNQのようなデバイスの面白いところです。

以下、5/26追記:

ZYBOのシステムのデフォルト・コンフィグレーションではオーディオ系のシステムクロックが12.288MHzに設定されています。これは元々が50MHzの水晶発振クロックから、何回かPLLででっち上げられたクロックで、実は周波数も正確な12.288MHzではなく、ある程度偏差のあるクロックです。こういったSoCがらみの基板でオーディオクロックを得るためにはありがちな仕組みではありますが・・・。

少し脱線しましたが、このオーディオ用の大元のクロックを24.576MHzに設定すれば、I2Sコントーラのロジック回路も、そしてデバイスドライバーも変更することなく192kHzまで対応できるような気がしています。デバイスドライバのソースを読んでいたらそのような気がしてきました。

追って確かめてみようと思います。