SDメモリカードプレイヤー機能の実装9

ようやくデバッグに入りました。

いきなり大きく変更すると収拾がつかなくなるおそれがあるので、とりあえず16bit/44.1kHzのwaveファイルの再生を目指すことにします。
また、ハード処理化するのはSDメモリカードからもwaveデータの読出しのみで、SDメモリコマンドおよびレスポンス処理は、ソフト処理のままとして変更量を抑えた状態です。FATドライバ等は、最終的にもソフト処理のままで考えています。

しかし、いきなり厳しい状況のようです。問題ないようならなるべくハード化をする部分を減らしたいところですが、強力なハードアシストが必要そうです。

一応ソフト処理については、waveデータの読出し処理フローも正常に走るようになったようですが、そこで処理時間を見てみると、16bit/44.1kHzでさえ、最長許容処理時間の6～7倍かかっています。
今のところ、クラスタの切替時のデータ読出しはソフト処理としているため、クラスタ切替時は最長許容処理時間を200倍以上超えています。

これでは、SDメモリコマンドおよびレスポンス処理をハード化しても、24bit/192kHz、384kHzとするのは厳しい可能性が高そうです。


NiosII/eは、ライセンスフリーで使用できるソフトコアのプロセッサですが、インストラクションキャッシュもデータキャッシュも使用できません。またFPGA内蔵メモリは、cycloneIVではさほど大きくないため、すべてを内蔵メモリ化するのは多分厳しいためSDRAM上にプログラムを置かざるを得ないと想定されます。

NiosII/ｆにすれば、インストラクションキャッシュもデータキャッシュが使え、さらにCPUクロックを現在の20MHzの4倍の80MHz程度にすれば、16bit/44.1kHzならすべてソフト処理とすることも可能かもしれません。というか、サンプルプログラムがあるのですからいけるはずです。
しかしライセンス料はたしか\10万弱/年しますので、....使えません。


処理時間が長いのは、下記が主要因と考えられます。

1. 　プログラムおよび各種変数が存在するSDRAMアクセスが遅い
2. 　FATドライバ、SDメモリドライバが結構処理があり、また　SDメモリのリードでmainから6段も関数コールされている。クラスタ切替ではさらに深く7段
3. 　３．オリジナルもデータ転送は、一度SDメモリから読み出したデータをさらにmemcpyで転送している
4. CPUクロック周波数　20MHz

逆に改善策としては、

1. CPUクロックUP　40MHz～80MHz
2. クラスタの切替時のデータ読出しのハード処理化
3. SDメモリコマンドおよびレスポンス処理のハード処理化
4. 変数領域、スタック領域などのFPGA内臓メモリ化
5. プログラム領域のFPGA内蔵メモリ化
6. FATドライバプログラムの最適化（クラスタチェーンの内臓メモリキャッシュ化、不要な処理の削除等）
7. 関数の統合（スタック段数削減）

あたりが候補となり、先ずは、１.２、あたりと続いて3.を適用して、16bit/44.1kHzの動作の確立させ、ハイビットレートをカバーしていこうと思います。

*5/5　最長許容処理時間をクラスタ切替無し時6～7倍　クラスタ切替時200倍以上修正しました