IDCTハードウェア概要3

ハードウェア全体構成とIDCTアルゴリズムが確認できたので、以前と同じようにデータパスのビット幅を決定するのですが、ここでは、DesignWave誌 2008年1月号の記事で説明されている通りにビット幅を決定します。
ただし、２箇所だけ説明が納得できない部分がありました。
IDCT係数と入力値を計算する部分で、「符号付小数23ビットＸ符号付整数12ビットの結果が符号付整数13ビット+小数22ビット」になっています。小数のビット幅が減っていることが理解できないことと、IDCT係数の絶対値は、0.5以下であることから、符号付整数12ビット+小数23ビットとしました。2段目のIDCT係数乗算のところも同様です。

まず、一段目のハードウェアのビット幅は以下のようになります。

次に二段目のハードウェアのビット幅は以下のようになります。

このようなビット幅で正しく演算できるか確かめるために、以前と同様にハードウェアと同じビット演算を行うCのソースコードを記述して絵を確認します。また、この時、入出力データをファイルに書き出し、RTL設計のテストパターンとします。

まず、簡単なプログラムを用いて、係数テーブルに相当するビットデータを定義します。
固定少数点ですので、int型になっています。このままでは、非常に大きな値となりますが、以下丸めや切捨て等のビット演算をC言語で直接記述することにより、最終的には正しい値符号付8ビットのデータが得られるはずです。

上位ビットを切り捨てる関数と、指定ビットで丸めを行いそれより小さな桁を切り捨てる関数を準備します。ここで、乗算結果が32ビットを超える箇所がありますので、long long型に対応した関数も準備しています。

これらの関数を使用して、前回アルゴリズムを確認するために記述したコードの構造をそのままに、ビット演算をするようにしました。
一段目のIDCTは以下のようになります。

二段目のIDCTは以下のようになります。

実際は、...................の部分に全部で64回の演算相当が記述されています。

そして、このコードをコンパイルすると、無事に綺麗な絵が出力されました（とは言っても、きちんと出力されるまでに、相当てこずりました、、、、）。
ここで、入出力のビット列をファイルに出力して、テストパターンを生成します。

さあ、これで、RTL設計突入かと思って、念のため出力データをIJGの出力データと比較したのですが、結構な誤差が乗っています。大きなところでは、整数値4ぐらい差があるところがある。見た目は非常に綺麗なのですが、大きな画像をそれぞれ画面に並べて出力して左右をじっと見比べると、ほんの少しだけ、画面がちがうような気がする。しかし、同じですと言われれば信じてしまうぐらいですが。

誤差はそれほど発生しないようになっているはずなので、何がおかしいのか調べましたが、なんと、前回コーディングしたdouble型のIDCTとは出力が同じであることが分かりました。
よって、前回の部分から誤差が入っていることになります。しかし、単純なアルゴリズムをdouble型で記述しただけなので、そこまで大きな誤差が入っているとは考えずらいのですが。。。。

いろいろ考察しましたが、結局分からず。殆ど判別できない綺麗な絵が出ているので、ほうっておいて次に進むことにします。
しかし、今回DesignWave誌の記事を読み直して、演算が連なっていく部分の誤差の考え方も間違っていたことが分かりました。以前のYCbCr-RGB変換モジュールのビット幅考察に間違いがあるかもしれません。

動画が動いたら、すべてもう一度考察しなおすつもりです。