YCbCr-RGB変換モジュールRTL システム検証 番外

とりあえず、modelsimを動かして内部の波形を見ます。
その際にシステム検証するプログラムを　yccrgb_test()　のみにしてmodelsimを実行しました。
すると、、、35分ぐらいで実行完了です。行数制限のせいで、GHDLよりはるかに遅いですが、それでもなんとか我慢できるぐらいの時間におさまりました。
いろいろ内部波形を見ることができます。

図はYCbCr-RGB変換モジュールのFIFO回りの信号を表示しています。
FIFO write信号が定期的にアクティブになっています。これが、yccrgb_test() の中でポインタアクセスしている部分に相当します。単純に配列データをループでポインタを使って書き込んでいるだけですが、これだけのクロック数を費やしています。16個データが溜まったため、右側でバーストライトが起きています。こちらはハードウェアによるバーストライトなので、16個メモリに書き込むのもあっという間に終わっています。

ハードウェアを使用しないIJGライブラリにおいて、YCbCr-RGB変換は単なる変換配列へのアクセスです。その際にはCacheへのアクセスでかなりの部分がまかなわれると想像できます。そして実際にメモリに書き込むのは、Cache書き換えのタイミングでライン分がバーストライトされますので、あっという間です。
こう考えると、今のYCbCr-RGBモジュールのみの状態では、あまり高速化されないのではないかなーという気がします。また、linux動作ですので、データの書き込みはデバイスドライバであり、アプリケーションからカーネルへのコンテキストスイッチも発生します。
これらを考えるとへたしたらフレームレートは落ちてしまうかもしれません。

まあとりあえず、想定の範囲内です。

ソフトウェアでは同じポインタアクセスの一行であってもハードウェア上でどれだけのクロックが費やされているかは状況によるので最終的には実際に動かさないとなんとも言えません。ハフマン符号化で圧縮されたデータをモジュールにバーストで書き込み、その後ハードウェアで処理が終わったらメモリにバーストライトだとかなりの高速化ができることも予想できます。
ここらへんの利害損得がシステム設計のプロなら簡単に想像がつくのでしょうけど、今の私には想像することが難しいですね。

いずれにしろ、ソフトとハード両方が連携をし始めました。なんとなくシステム開発っぽい感じになってきました。