TRX-305のDSPファームウェアに関しては、ブート問題が私の手を離れたため、しばらくはDSP用フレームワークの事だけを考えればよくなりました。これでようやく落ち着いて設計出来ます。
これからしばらく私自身の考察をかねて、FPGAとDSPがやりとりするデータについて書いていきます。おおむね書き終わる頃には解決しなければいけない問題と、ソフトウェアの構造もはっきりするでしょう。プログラムもデータも、その構造は解決すべき問題の構造に従ったものになるからです。
データの流れとサンプリング・レート
大まかなデータの流れを下に図示します。
TRX-305では、FPGAが受信信号のIF信号をディジタル形式でDSPに流し込みます。そして、DSPがこれを復調した後にAF信号としてFPGAに出力します。
この流れの中でキーとなるのはAFのサンプリング・レートです。このレートはおおよそ31kHzとなっており、DSPの中では全ての処理がこれに同期して行われます。
一方で、RX IFのサンプリング・レートは多少面倒です。というのは、RX IFには二つのモードがあるからです。
AM、SSB、CWなどに使われる「非ワイドFMモード」では、RX IF上のサンプリング・レートは31kHzです。一方、「ワイドFMモード」では、RX IF上のサンプリング・レートは248kHzです。つまり、AFを基準とすると、RX IFのサンプリング・レートは1倍速、8倍速の二つがあって、モードにより切り替わるのです。
切り替わりのタイミングは、RX IFに重畳して送り込まれるコマンドによって知らされますが、DSPはこれを事前に知ることが出来ません。切り替わると同時に知らされるからです。ビットクロックと同期クロックがFPGAから与えられるため、回線のクロックの切り替わりに頭を悩ませる必要はありませんが、内部のDMAとソフトウェアの同期、そうしてもちろん復調ソフトウェアはこの動的な切り替えに完全に対応する必要があります。
今回つくるフレームワークの目標は、この切り替えの検出と対応を復調アルゴリズムから隠してしまうことです。後に詳細を検討しますが、このような「ギアチェンジ」が入るシステムでは、フレームワークは一筋縄ではいきません。慎重なアプローチが必要になります。
AFのおおざっぱなデータ構造と物理層
上記のようにRX IFデータはAFを基準としてサンプリング・レートが1倍速・8倍速と変化します。以下ではこの基準となるAFについて少し掘り下げてみます。
AFはワイドFM、非ワイドFM時のRX IFデータに対する基準として取り扱うことが出来ます。すなわち、両者ともAFに対して位相同期しています。位相遅れの量は保証されていませんが、電源を入れている間は位相遅れが一定であることが保証されています。これは微妙な周波数ずれに対応するSRCを入れなくて済むと言うことですから、複雑なシステムに取り組まなければならない立場から見ると、ほっと息をつきたくなる点と言えます。
AFはRX IFのモードにかかわらず同じ構造のデータをDSPからFPGAに返します。以下、その構造を見てみましょう。
AFの基本データ長は8の倍数ではありません。SPORT0上では31bitです。これはTRX305の中心がDSPではなく、FPGAであるからと考えていいでしょう。DSP側ではこれを8の倍数bitにパックして使用しますのでソフトウェア側は意識する必要はありません。しかし、フレームワークを作る上で物理層を流れるデータが8の倍数になっていないことは強く意識する必要があります。
AFデータは15ビットのステレオ・データが32bit整数にパックされた形をしています（DSP内部での話）。これが31bitワードとしてSPORT0のプライマリ・チャンネルから送られていきます。セカンダリ・チャンネルからは別のデータが送出されますが、これは今回利用しません。プライマリ・チャンネルに送出するデータを完全なダミーにするか、ある程度意味を持たせるかは後で考えます。
RX IFのおおざっぱなデータ構造と物理層（ワイドＦＭモード）
ワイドFMモードのRX IFデータは、FPGAによってAFのサンプリング周波数の8倍でサンプリングされます。
サンプリングされたデータはFPGAからDSPに送り出され、DSPで受信後にIQデータが32bitデータワードにパックされ、さらにもう32ビットにコントロール・データがパックされます。このうち、IQデータはSPORT0のプライマリ・チャンネルから受信し、コントロール・データはSPORT0のセカンダリ・チャンネルから受信します。いずれも、SPORT上では30bitワードとしてFPGAから送られてきます（31bitではない）。
この結果、SPORT0 プライマリ・チャンネル上でAFデータが1ワード送信される間に、SPORT0 プライマリ・チャンネル上でワイドFMモードのデータが8ワード受信されます。
RX IFのおおざっぱなデータ構造と物理層（非ワイドＦＭモード）
非ワイドＦＭモードでは、サンプリング周波数が落ちてAFのそれと同じになる代わりに、データ構造が複雑化します。
データ構造の詳細はここでは書きませんが、IQデータとコントロール・データを含むと、全部で4ワード（1ワード32bit）が1サンプルを構成します。このため、1サンプルの間にプライマリ・チャンネル、セカンダリ・チャンネルのいずれにも2ワードがFPGAから送られてきます。当然、偶数番目のワードと奇数番目のワードを取り違えることは許されませんので、FPGAはそれぞれのワードの下位ビットに識別フラグを埋め込んでいます。フレームワーク・ソフトウェアはこのフラグを正しく抽出、解釈、削除して正しいデータを処理アルゴリズムに渡す必要があります。
ワイドFM、非ワイドFMモードの切り替え
上で説明したように、FPGAからの入力信号にはFMモードとワイド・FMモードがあります。この二つのモードはユーザーによる受信モード切替を受けて切り替わります。DSPには切り替わりが発生した時点で初めて通知されます。具体的にはIQデータに埋め込まれたフラグを確認することで、DSPはワイド・FMモードとそれ以外のモードの切り替えを知ります。
二つのモードのデータの速度が異なることから、DSPはその違いを吸収しなければなりません。SPORTの1チャンネル上を流れるデータは次のようになります。
- 非ワイドFMモードでは、AF 1サンプルあたり、RX IF 8サンプル。SPORT上では8ワード
- ワイドFMモードでは、AF 1サンプルあたり、RX IF 1サンプル。SPORT上では2ワード。
1サンプルのデータを復調するために、片や16ワード、片や4ワードのデータ受信を行います。これは、頭の痛い問題を引き起こします。
送受信では割り込みや関数呼び出しオーバーヘッドを減らすためにDMA転送を使います。単位時間当たりの割り込み数を減らしたければ、DMAバッファ長を大きくします。仮に、4サンプル（約120uS）毎の割り込みを許容すると、データ転送量の大きなワイドFMモードが基準になるため、プライマリとセカンダリ併せて64ワード分のバッファが必要になります。実際にはこの程度ならばBlackfin DSPであっても問題にはなりません。
しかしながら、バッファサイズは遅延に影響します。遅延を考えるときにはデータ転送量の小さな非ワイドFMモードが基準になります。上と同じく64ワードのバッファを使うと、おおよそ0.5mSの遅延が発生することになります。
通常のAMやFMなら遅延は問題になりません、しかし、TRX-305はトランシーバーであり、CWモードを持っています。もし、CWのサイドトーンを受信機を通して作るのであれば、遅延について真剣に考えなければなりません。実際には0.5mS程度であれば、それがトリプル・バッファ・アルゴリズムによってさらに大きくなっても問題にはならないでしょう。しかし、割り込みオーバーヘッドを減らすためにさらにバッファを増やすようならば、慎重に遅延を評価した方がいいでしょう。
この点は後で再度検討することにします。
考えるべき事はたくさんある
TRX-305のオリジナルDSPファームウェアはアセンブラで書いてあります。しかしながら、このプロジェクトでは取っつきやすくするためにフレームワークをC言語で記述します。
この受信機は途中でデータ転送速度が変る設計になっており、高級言語に見合った生産性と見通しの良さを確保しつつDSPの速度を殺さないようにするには慎重な設計が必要です。