Linux上でのJPEG表示

デバッグしてました。。。

前のエントリに書いた修正以外にも沢山。
fetch stageのステートマシンの遷移条件は以下のように修正。

デバッグ以外にも、motionJPEGへの対応のためSOSマーカーが出てくるまでFIFOデータを単に消費し続けるモードを追加しました。through_bitというレジスタでモードを変更します。

その他にも、デバッグ対策として、cache memory, huffval,maxcode,offset memory, 量子化テーブルをAHB越しにリードできるようにしました。

FPGAにISEを用いて合成、配置配線した結果は、、、　約1nsecのセットアップエラー！
しかし、温度マージンやトランジスタ製造マージンがあることを考えるとこれでも動作するとみました。
(最終的にはエラーは取らねばなりませんが、とりあえず実験です。)
特にセットアップ側は沢山の段数をワーストケースで足しこんでいっているためかなり大きめのレポートを出力していると予想しています。

これらの変更を行った後に、いつものごとく80x80のjpegを配列からモジュールに送るテストプログラム systest.exeを実行しました。
その結果は、崩れた画像が表示されます。。。。

途中まで正しく出ているので、最初の入り口のFIFOが溢れているのではないかと予想して、jpegモジュールに書き込む前にFIFOのready信号を読んで、readyになってから書き込むようにプログラムを変更して実行すると、、、、

出ました無事に80x80の画像が正しく表示されます。
以下のようにハフマンデコードモジュールをハードウェア化したためモジュール入り口のデータ量と出口のデータ量が数十倍(jpeg圧縮分)差があり、かつ、このボード上のシステムのバスが厳しいため出口にデータがたまり、入り口のFIFOのデータが中々処理できないことが予想されます。
(もしくは、ただ単に配列から読み取ってハフマンデコーダに書き込んでいるので、書き込みのペースが速すぎるだけかも)

ハードウェアはどうやら動作しているようなので、linux上で動かします。
linux上でdjpegを実行すると、、、、

やった！！！　ちゃんと絵が表示されました！
(画像のサイズはVGA)
しかし、それほど速くないぞ、、、、
試しにソフトウェアのみで表示させた場合と描画速度を比べてみました。
最初のwindsurfinの絵と小雪の絵がソフトウェア表示、その後のwindsurfinの絵がjpegモジュールハードウェアを使用した表示です。ソフトウェアは1ライン毎の表示で、ハードウェアを使用した場合はMCU単位の表示であることが分かります。

どうやら2〜3倍ぐらいにしかなってないな、、、、　
純粋なjpegモジュールハードウェアだけの性能はもっとはるかに高いはずなのでおそらくバスがいっぱいいっぱいなのではないか？
もしくはソフトウェアからの書き込みペースが遅いか。

まあ、バスの問題ならとりあえず性能がでないだけでハードとソフトの開発は進めることができるので、先に複数の画像を続けて出すためのソフトウェアの変更を行います。