8 |
BSVによるサウンドFSMの再設計 (8) |
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でガードされており、ルールに重なりが無いので、同一リソースへのライトハザードが起きないためでしょう。
Leave a Comment