データパスのビット長（２）

以下のようにデータパスのビット幅の構造が決まりました。

このビット構造で正しいかどうかホスト側のXwindows上のプログラムを変更して確認します。
IJGの中のjdcolor.cというファイルの中でこのYCC-RGB変換が実現されています。

もちろん、ソフトウェアでの実現ですから、決まったビット幅の演算が行われています。
係数を掛ける乗算はあらかじめ配列に入れておき、配列要素の位置指定で実現しています（高速化のため）。その他、整数演算で計算できるような工夫がなされています（FPUを使用しないため）。

この部分を前回決めたビット幅の演算であっているかどうか確認するソースコードに変更します。

少し分かりにくいですが、すべてINTのサイズ（３２ビット）で演算していますが、上位ビットを捨てる場合は、左シフトを行って上位ビットを外にはずしてから右シフトを行っています。
乗算については、小数ではなく、整数と考えて乗算を行います。
乗算後の小数部分をすてる処理は右シフトをおこなった後に左シフトを行っています。
ビットを０に固定する部分はビットの論理演算です。

C言語では、右シフトが論理シフトになるか算術シフトになるかの定義が無く、処理系依存となります。私はGCCを使っていますので、算術シフトとなっています。また、ビット論理演算の戻り値は符号なしデータとなるようですので、再び符号付INTに戻しています。

このような記述をしたことにより、これから設計するハードウェアと同じ出力が得られることになります。
そして、motionJPEG再生ソフトウェア全体をコンパイルして動画を再生すると、少しFPSは悪くなりますが、問題なくきれいな動画が再生されました。
よって、前回決定した丸めやビットの切捨てを行ってもきれいな動画が出力されることが確認できました。

さらに、この書き換えた部分の前後に入力ビット列をファイルに書き出す関数と出力ビット列をファイルに書き出す関数を追加します。この状態で非常に小さなJPEGをプログラムに与えて表示させると、RTLを検証するための入力パターンと出力パターンファイルができあがります。
この時に１６ビット出力のファイルとその二回分をまとめて３２ビット出力するファイル両方つくります。
前者がデータパス部分の検証ファイルとなり、後者がYCC-RGBモジュール全体の検証ファイルとなります。

という訳で次はデータパス部分のRTL記述です。
（ここが私には少しハードルがあります。。。）

しかし、今後データパスの設計が続く（DCT）ことを考えると、文字列を受け取って演算するようなデータパスを表すようなCの関数をきっちり作りこんでおいた方が良い気もするなー。。。。。。