OneStageの変更

OneStageとはGameFSMとSoundFSMのインタフェースを行うモジュールです。元々FIFOだったのですが、FIFOの段数だけサウンドがレコードされていき、遅延して演奏されるようになったので、リアルタイム性のため1段のFIFO(=One Stage FIFO)としました。

前回Verilogで設計したものを今回BSVに移植します。ロジック的には大したことのないモジュールでVerilogで書いても工数はあまり変わりません。

図504.1にステート遷移図を示します。1段のキューを模擬する動作であり、

• emptyかつwriteの場合は!empty (=full)に遷移します。
• !empty (=full)かつreadの場合はemptyに遷移します。

通常、GameFSMが書き込むことにより!emptyとなった場合は、演奏途中でもemptyを見ているため、SoundFSMはすぐに読み出します。すぐにreadを返すためまたemptyとなります。

例外は自機増加音で、プリエンプション禁止であるため、!emptyとなってもreadが返りません。従って演奏が終わるまで!emptyのままとなります。出力側はemptyを見ているため、この場合は出力が待たされ取りこぼしが防止されます。

BSVでの記述

これはステートマシンなので、以前に示したように、

• ステートベース設計
• シーケンスベース設計

の2通りの設計手法があります。自動FSMによるシーケンスベース設計も可能ですが、あまりにも簡単なステートマシンなので、ステート遷移のルールを直に記述します。ren信号はread enableの意味です。

図504.1をBSVのルール文で書くと

rule rule_write (in_wen && in_empty);
   in_empty <= False;
endrule
rule rule_read ((in_ren0 || in_ren1 || in_ren2 || in_ren3) && !in_empty);
   in_empty <= True;
endrule

となります。

• write_enable (in_wen)はキューへの書き込みのためのGameFSMからの出力です。
• read_enable (in_ren0～3)はキューからの引き取りのためのSoundFSMからの出力ですが、SoundFSMが4種類あるので、4つの信号となります。

別々のルールにおいて、同一資源であるin_emptyに書き込むのが若干気になります。スケジューリング時点でエラーが出るかもしれないと思いましたが、出ませんでした。これは、2つのルールがそれぞれemtpyと!emptyでガードされており、ルールに重なりが無いので、同一リソースへのライトハザードが起きないためでしょう。

前のブログ 次のブログ