RX IFのバッファとアライメント

By 酔漢 - Last updated: 金曜日, 2月 6, 2015 - Save & Share - Leave a Comment

前回大まかに説明したように、RX IFのデータはなかなか複雑です。

こういったデータをリアルタイムに扱いながら一台の受信機として成立させるために、いくつかあらかじめ考えておくべき事があります。

入力データと出力データの同期関係について

すでに説明したことですが、RX IFとAFは一つ一つのデータの流れる速度こそ違いますが、大局的には同期して流れていることに注意が必要です。途中で速度変化があるとは言え、両者の間にジッターは存在しません。

これは、突き詰めるとRX IFのデータを処理途中で棄ててはいけないし、追加してもいけないと言うことです。「何を当たり前なことを」と思うかも知れません。確かに当たり前です。入り口と出口の速度が同じなら、データを棄ててしまったり追加することでデータ過不足が発生します。雑音を避けたければデータ数を変えてはいけません。

ところが、以下に説明するようにTRX-305のRX-IF処理では、データを棄てなければならない、あるいは追加しなければならない場面が出てきます。

非ワイドFMモードの考察

非ワイドFMモードでデータを棄てる、あるいは追加する必要があるか考えてみます。

非ワイドFMモードでは1サンプル辺り4DSPワードのデータが送られてきます。これらは二つのチャンネル(SPORT0のプライマリおよびセカンダリ・チャンネル)に分割されますので、結果的にチャンネル辺り2ワードのデータが送られてきます。

これを模式化すると、チャンネル中のデータはABAB…という風に二つのデータが交互に現れます。当然、AとBを取り違えるなどと言うことは許されません。しかし、それではどこでAとBをより分ければいいのでしょうか。

残念ながらBlackfinのSPORTペリフェラルでAとBをより分ける方法はありません。TRX-305ではAもBも等しく1ワードとして扱われ、物理回線上では同じようにフレーム同期信号を与えられます。この結果、SPORTはAとBを区別することなく読み込みます。結果的にSPORTと接続されているDMAを使用すると、DMAバッファの先頭がAであるかBであるかは、確率1/2です。

ということで、非ワイドFMモードのデータを常に”AB”というペアでDMAバッファに先頭から格納する方法はないとわかります。

では、これは問題になるでしょうか。

幸い、私が理解している範囲ではこれは問題になりません。AおよびBは、受信データのIQのようなペアではありません。片方が受信データで、片方はFPGA経由でSH2マイコンから送られてくる制御命令です。したがって、これらはペアで扱う必要はありません。両者の処理は別々ですので、どちらがDMAバッファの先頭にあるか関係なく、両方とも処理してしまえば結構です。

ワイドFMモードの考察

一方、ワイドFMモードでは話がこれほど単純ではありません。

ワイドFMモードでは、AFサンプルあたり8回のIFサンプルが行われ、それぞれがIQデータとなってDSPに送られてきます。このモードではBlackfinのSPORTを流れるデータは同じチャンネルならば常に型が一定です。言い換えると、非ワイドFMモードのように型がABAB…と揺れる事はありません。型としてはAAAA…のように均質です。従って非ワイドFMモードの時のようにどちらのデータか気にする必要はありません。しかしながら、このモードには別の問題があります。

ワイドFMモードは「サンプル周波数が8倍」という性質から、常に8サンプルのデータをひとまとまりとして扱うことになります。これは数学的な要請ではなく、「RX IFの8サンプルがAFの1サンプルに対応する」以上、RX IF 8サンプルを処理してAF 1サンプルを出力するアルゴリズムが自然なのです。

この8サンプルまとめて処理するという点がいくつかの面倒をもちこみます。

まず、逃げられない問題として「DMAのバッファ境界がAFサンプルの境界と一致しない」という問題があります。ワイドFMと非ワイドFMの切り替えはAFサンプルの境界と同期して行われます。ところが、DMAバッファの境界位置はRX SPORTの開始位置によって決まります。AFとRX IFはフレーム同期信号を共有しておらず、おまけにADSP-BF533にはRX SPORTとTX SPORTを同時に開始する方法がないため、RX DMAの境界がAFサンプル境界と一致するという保証はありません(後述する例外あり)。

このため、DMAバッファ上で途中から非ワイドFMモード→ワイドFMモード切り替えが発生します。結局、DMAバッファの上でそのままワイドFMモードの信号処理をすることはできず、いったんプログラムによってFIFO上に信号を蓄積し、8サンプルたまる毎に処理する必要があります。

さらに、ワイドFMモードについては「途中から始まった場合どうするのか」という問題があります。TRX-305がワイドFMモード状態でDSPのプログラムが実行開始した場合、SPORTがDMAを使ってメモリに書き込むデータは最初からワイドFMモードのRX-IFです。これはそのまま8サンプル毎に復調にかければかまいません。ところが、非ワイドFMモードに遷移すると問題が起きます。

というのは、途中から実行を始めているため、非ワイドFMモードに遷移する際、バッファにちょうど8サンプルたまっているとは限らないのです。

残りのサンプルについては、おそらく「端数サンプルは棄てる」か、あるいは「0データを追加してバッファを8サンプルに水増しする」のが一番合理的です。しかし、こうした場合AFデータとRX-IFのデータの間の時間関係にジッタが発生してしまいます。このジッタは1度しか発生しませんし、その幅も最大1サンプルです。しかしながら、確実に揺らぎが発生することに間違いはありません。

「ワイドFMモードからは始まらない」と仮定する手もありますが、他のシステムへの流用の可能性などを考えれば、筋のいい方法とは言えません。無理の無い限り、フレームワークは汎用性を持つべきです。

ジッタの吸収が必要

今回はTRX-305のDSPがRX-IF信号を処理する際のバッファの取り扱いについて考察しました。この通信機のDSPでは方式から必然的にジッタの吸収をソフトウェアで行う必要があります。ジッタの発生は一度だけですが、発生するのは間違いないので対策は必要です。

さて、このようなジッタがどのような構成でも発生するかというとそんなことはありません。TRX-305のように、非ワイドFMとワイドFMでAF 1サンプル辺りのRX-IFデータ量が変るシステムであっても、ジッタから逃げることが出来ます。両方式で、同じデータ量を常に送ればいいのです。

非ワイドFM時に、データの後ろにゼロパディングする事を考えてください。こうすると両モードでデータ転送量を同じに出来ます。同じにしてもワイドFM時の途中から始まる問題は解決しませんが、これはBlackfin SPORTの「マルチ・チャンネル・モード」を使えば解決します。マルチ・チャンネル・モードは単一のフレーム同期信号によって複数ワードのデータを一挙に送る方法です。TRX-305であれば、16ワードを一括して送ることが出来ます。

この方式はDMA開始が常に第一ワードからになるため、上のような「途中から転送が始まる」問題は発生しません。常にAF信号と同期した位置からRX-IF転送を始めることが出来ます。

残念ながらTRX-305はこうなっていませんし、今からこのDSPプログラムのためにFPGAを書き換えるのも妙な話です。従って、当プロジェクトはこのままジッタを飲み込む形で進むことにします。

Posted in TRX-305 • • Top Of Page

Write a comment