Tech と Culture

テクノロジーとカルチャー

データパス演算誤差

以下の5つについて調べました。

(1)IJG ソフトウェアIDCT intバージョン
(2)IJG ソフトウェアIDCT floatバージョン
(3)ハードウェアアルゴリズム確認ソフト
(4)ハードウェアビット幅エミュレーションソフト
(5)RTL

まず、前回以降で(3)のバグが見つかりましたので修正しました。
その結果、、、、、
(2)と(3)の出力値が一致しました。この二つは演算ビット幅が非常に大きいです。一致をみたのはどちらも誤差が非常に小さいからだと考えられます。良い傾向です。
(1)と(2)の出力値には、ある程度の誤差が発生しています。現在設計しているRTLにおいても演算幅32bitを超えている部分が存在するため、intでは誤差がどうしても発生するためです。
(4)と(5)の出力値が一致しました。RTLにバグが混入している可能性が非常に小さくなりました。
そして、、、、
(5)と(2)の出力値を比較すると、±1の誤差が時々発生しています。(非常にまれに±2の誤差があります。)
よくよく参考にしたDesignWaveの記事を読みますと、そもそも誤差を真の値と比較して±1に収めるためのビット幅を計算してあります。非常にまれに発生する±2の誤差も真の値との誤差がどれぐらいなのか分かりません。一応これを許容範囲であると判断して、DCT部分はこれでフィックスさせます。
±1の誤差を許さない(±0.5未満に抑える)データパスビット幅について考察しても良いのですが、ほぼ人間の目で判別不可能なことと、日曜工作なので誤差を減らすよりも早く動画が見たいというのが理由です。また多くのjpegアプリケーションにおいて、IJGのint型が用いられており、これよりもRTLの方が真の値との誤差が小さいであろうことからこれでOKにしました。


という訳で、次にハフマンデコーダの設計に入ります。
ハフマンデコーダ自体は大したアルゴリズムではありません。
しかし、どのようにソフトウェアとハードウェアの切り口を分けるかを決めるのは非常に難しいです。そしてこの部分の設計によって性能も大きく変わる可能性が高いです。

IJGのハフマンデコーダ部分のソースコードは非常に読みづらいです。。。。。。。
まずは頑張ってここを解読しなければ。