小数点演算

さてYUV422をRGBに変換するためには、小数点演算が必要になるわけだけど、どうしようか?
R = 1.000Y + 1.402V
G = 1.000Y - 0.344U - 0.714V
B = 1.000Y + 1.772U
とりあえずあたい的には2の-9乗で固定小数点演算をすれば良いのかな?
だからへいきだと思うけど。
それとも2^9乗で512倍すればすればほとんど小数点部分は実数化が可能と考えても良いのか?
1.402*512=717.824=718
0.344*512=176.128=176
0.714*512=365.568=366
1.772*512=907.264=907
でも良いよな気はするけど。どうだろうか?
精度多少あげるためには単にシフト数を増やせば良いけど、それだと乗算回路の規模が大きくなるから実速度的にはどうなんだろうか?
spartan3eにある専用乗算回路は18bitまで対応してるからシフト数はむしろ17bitくらいした方が良いかもしんない、それで合計4つの小数点演算を一気に処理すればいいのかな?
たぶんその方が自分で乗算回路くむよりかは早いだろうし、リソースも節約できる。問題は速度だけど、実際面データはだいたい1pixel=40nsecくらいの間隔だからそれ以内に終われば申し分無いんだけどたぶん無理なのかもそれならとりあえず間に合う速度分のバッファをブロックRAMで確保するのが無難なのかもしれない。

それだと
YUVデータ受け取り→17bit左シフト→乗算回路→17bit右シフト→加算→RGB出力
という感じになるな。
今仕様を見てたら単純にbit数を制限すれば早くなるらしいので、必要なbit数に制限するのが無難なのかもしれない。
あっちょっと勘違い。17bitシフトしたらUとかVの方が足らなくなるのを忘れていたので、現実には10bitシフトが限界。
むしろ負の数も扱うから9bitの方が良いのか?うーんとりあえずためしてみないわからないかな。