Caller Saved

今回GameFSMを開発するにあたり、過去記事で開発したコール方式を踏襲しますが、今回はCaller Saved方式に変えてみたいと思います。これを図示すると、呼び出し側では、必ずリーフと思ってリターンレジスタにネクストステートを格納して共通シーケンスをコールします。BSVコードで書けば、コール先をtarget_state、戻り先ステートをnext_stateとして、

    return <= next_state;
    state <= target_state;

となります。

リーフシーケンス

呼ばれた側は、さらにサブ共通シーケンスをコールするかどうかは分かっているので、さらに呼ばない場合、つまりリーフシーケンスである場合は何もせずに

    state <= return;

を実行して戻ります。

非リーフシーケンス

他方、さらにサブ共通シーケンスの場合は、呼ばれた側ではまずリターンレジスタをプッシュします。

    return_stack[sp] <= return;
    sp <= sp + 1;

呼び出し元と同様に、サブ共通シーケンスをコールします。

    return <= next_state2;
    state <= sub_sequence;

戻る場合は、本来はリターンレジスタを回復してからそれをステートに入れるのですが、処理を簡略化して、

    state <= return_stack[sp - 1];
    sp <= sp - 1;

として戻ります。

最後に、前稿で実施したCaller Savedと今回実施予定のCallee Savedの方式の違いを図でまとめます。Caller Savedの利点は前述のとおり、呼ぶ側では同じシーケンスで良いことです。さらにreturnレジスタを壊すか壊さないかは自分の情報なので、判断し易いことが挙げられます。

前のブログ 次のブログ

mkConnection

BSVにはmkConnectionという機能があり、インターフェースの接続を効率的に行えます。

図240.1にmkConnectionによる信号の接続及び、BSVで言うメソッドとVerilogで言う信号端子の関係を示します。

Verilogで表すと、モジュールefsmの端子out_code[4:0]から出力した信号code[4:0]が、モジュールsfsmの端子in_code[4:0]に接続されるものとします。この接続を実現するのは上位でのmkConnectionメソッドです。

まず、出力側モジュールefsmの読み出しメソッドは、interfaceブロックにおいてout_code()メソッドで記述されます。メソッドのリターンタイプはCode_tです。BSVのメソッド名がそのままVerilogの端子名になります。

    interface EFSM_ifc;
        method Code_t out_code();

上位での接続のための識別子は、"モジュール名"+"."+"BSVメソッド名(=Verilog端子名)"となります。EFSMモジュールのインスタンス名をefsmとすると、以下のようになります。

    efsm.out_code

一方、入力側モジュールsfsmへの書き込みメソッドには副作用があるため、interfaceブロックにおいて、method Actionとします。書き込みとVerilog端子は少々複雑で、Verilog端子名は"BSVメソッド名_入力パラメータ"となります。

    interface SFSM_ifc;
        method Action in(Code_t code);

上位での接続のための識別子は出力側と同じく、"モジュール名"+"."+"BSVメソッド名"となります。Verilog端子名とは若干異なります。

    sfsm.in

ここでは分かりやすさのため、メソッド名をinとしましたが、重なることはできないため、現実的にはinXXXXのように、意味のあるメソッド名を付けることになります。最後に上位での接続を示します。

    import Connectable::*;

    mkConnection(efsm.out_code, sfsm.in);

inとoutのどちらを先に書いても文法的には問題ありませんが、回路図の記法の通例として左から右に信号の流れを書くため、左側に出力メソッド、右側に入力メソッドを書くルールとします。

Verilog端子名の制御

注意:端子名制御はVerilogのみに影響を与えるため、mkConnection等のBSVの世界では影響を与えません。

defaultのVerilog端子生成ルールはコントロールすることができ、

• 出力側の端子名をOUTPORTとしたい場合は(* result="OUTPORT" *)とインタフェースに記述します。
• 入力側の端子名をINPORTとしたい場合は(* prefix="" *)としてメソッド名を消去し、さらに(* port="INPORT" *)とインタフェースに記述します。

メソッド名は大文字で始まることが許されていないため、任意のポート名を付けるにはこの制御指示子を用います。例えば、出力インタフェース部に

    method Bool fifo_ren();

という出力インタフェースがある場合、

    (* result="FIFO_REN" *)
    method Bool fifo_ren();              // output terminal "fifo_ren" -> "FIFO_REN"

という指示を与えることで、生成されるverilogにはFIFO_RENという端子が生成されます。

    // value method fifo_ren
    output FIFO_REN;

また、入力インタフェース

    method Action rom(Data_t indata);

においては、メソッド名がromでアーギュメントがindataであるため、defaultでは端子名はrom_indataとなります。これに対して、

    (* prefix="" *)
    method Action rom((* port="INDATA" *) // input terminal "rom_indata" -> "INDATA"
       Data_t indata);

という指示を与えることで、生成されるverilogにはINDATAという端子が生成されます。

    // action method rom
    input  [7 : 0] INDATA;

最後にmethod名を生かしたい場合には次のようにします。例えば

    method ActionValue#(Bit#(8)) read(); // パラレル出力メソッド
    method Action write(Bit#(8) nodata); // パラレル入力メソッド

のようにread及びwriteというパラレル入出力が有った場合、readという出力インタフェースに対して生成されたverilogは以下のようにmethod名がそのまま端子名になります。

    // read                           O     8 reg
    // RDY_read                       O     1
    // EN_read                        I     1

反対にwriteという入力インタフェースに対してはmethod名を消去しなければmethod名と変数名の結合となります。または、上記のようにmethod名を消去すると入力変数名が生きることになります。

そこで、method名を生かすには一度method名を消去して再度method名をポートで定義することで対処します。

    (* prefix="" *) // delete write
    method Action write((* port="write" *) Bit#(8) nodata); // パラレル入力メソッド

これにより生成されたverilogのコメント部は以下のとおりです。

    // write                          I     8
    // RDY_write                      O     1
    // EN_write                       I     1

前のブログ 次のブログ

サウンドFSMの完成

ミキサーは4chある音源のミキシングを行います。ミキシングは符号無し8bit整数を16bitに符号拡張し、加算することで行います。サウンド平均化を試しましたが、かえって違和感が出るため、シンプルな加算としました。念のためにクリッピング処理を入れています。

完成したsound階層を図239.1に示します。

従来回路図234.2と比べてサウンドチャネルが4倍になっただけでなく、ミキサー回路を新設したため、かなり大きくなっています。表239.1に各モジュールの物量(LUT数)を示します。LUTは使用個数は4,216個であり、全容量70,560個中の5.98%でした。またBRAMは使用個数は39.5であり、全容量216中の18.3%でした。

ゲーム全体の各モジュールの物量を表239.1に示します。色付け部分が今回BSVで開発したモジュールです。

図239.2に全体のセルの配置図を示します。

例外動作

基本的に、サウンドエンジンはサウンド番号を受け、ROMに示されるサウンド長だけサウンドを演奏し、サウンド中に割込みが入る場合にはその割込みサウンドを演奏しますが、例外が2つあります。

• UFO飛行音 --- UFO飛行音ONでサウンドを演奏し、終了してもUFO飛行音OFFが来るまでは演奏し続ける。
• 自機増加音 --- 自機増加音演奏中に割込みが入ると聞こえなくなる場合がある。このため、自機増加音は優先サウンドとして扱い、他の割込みを受け付けない。

自機増加音は自弾発射音、自機爆発音と独立であるため、別チャネルとするほうが良いのですが、頻度が低いのと別チャネルにするとハードウエアが無駄のため、このような仕様としました。実験の結果、優先サウンドとしてもゲーム上特に問題はありませんでした。

前のブログ 次のブログ

サウンドFSMの作成(3)

FORMAT機能、DATA機能からコールされるREADCOUNT共通シーケンス及び、そこからコールされるREADMEM共通シーケンスを解説します。

       //  input:  romaddr
       //  output: (romaddr,...,romaddr+3) => dcount;
       //          romaddr + 4 => romaddr;
       //
       rule ruleREADCOUNT (state.func == READCOUNT);

          rule ruleS0 (state.step == S0);
             state.step <= S1;
             ret2 <= ret; // push to stack
             i <= 3;
             workd <= 0;
          endrule

          rule ruleS1 (state.step == S1);
             state <= State_t {cat:state.cat, func:READMEM, step:S0};
             ret <= State_t {cat:state.cat, func:READCOUNT, step:S2};
             worka <= romaddr + i;
          endrule

          rule ruleS2 (state.step == S2);
             if (i == 0) begin
                state <= ret2;
                dcount <= workd<<8 | extend(romdata);
                romaddr <= romaddr + 4;
             end else begin
                state.step <= S1;
                workd <= workd<<8 | extend(romdata);
                i <= i - 1;
             end
          endrule

      endrule // READCOUNT

図示すると、図238.1のようなステート遷移となり、リトルエンディアンで格納されている4バイトの数値を1バイトずつ4回取り出し、dcountにまとめる機能を持ちます。

次にREADMEMはROMから1バイト読み出す共通シーケンスです。当初はwireを用いても階層の上り下りでレイテンシがかかり、7サイクルとなりましたが、後述のmkConnectionを用いたことにより、RTLと同様の3サイクルの設計とすることができました。

上記のREADCOUNTから呼ばれる際はサイクル数は無関係ですが、サウンド再生中は正しいスループットで読み出す必要があるため、過去記事にもあるように、コール元が1サイクルとコール先(READMEM)が3サイクルの4サイクルで1バイトを読み出す前提で、FSMのクロック周波数=176.4KHzを決めています。

       // READ MEM
       //  input:  worka
       //  output: romdata;
       //
       rule ruleREADMEM (state.func == READMEM);

          rule ruleS0 (state.step == S0);
             addr <= worka;
             state.step <= S1;
          endrule

          rule ruleS1 (state.step == S1); // ROM address phase
             state.step <= S2;
          endrule

          rule ruleS2 (state.step == S2); // ROM data phase
             data <= romdata;
             state <= ret;
          endrule

        endrule // READMEM
 

前のブログ 次のブログ

サウンドFSMの作成(2)

階層化ステートマシンを解説します。基本的にBluespecにおいてはrule文のガードによりステートに入る条件を定義し、rule文の内部でステートの処理を定義します。そこで、ruleを構造化することで、ステートの構造化を実現します。具体的には以下のような構造となります。

    rule ruleSOUND (state.cat == SOUND);

       rule ruleFORMAT (state.func == FORMAT);

          rule ruleS0 (state.step == S0); 
             // call readcount();
             state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
             ret <= State_t {cat:SOUND, func:FORMAT, step:S1};
             case (code)
                'h1: romaddr <=     0 + 16;
                'h2: romaddr <=  4318 + 16;
                'h9: romaddr <= 13094 + 16;
             endcase
          endrule

          rule ruleS1 (state.step == S1);
             state <= State_t {cat:SOUND, func:DATA, step:S0};
             romaddr <= romaddr + extend(dcount);
          endrule

       endrule // FORMAT

ruleS0ではcodeによりROMアドレス先頭を決定します。wave formatの16バイト目からフォーマット長取得を行います。readcount()をコールしており、そのリターンはruleS1ステートです。readcount()ではdcount変数に4バイトの数値が得られます。

     rule ruleDATA (state.func == DATA);

         rule ruleS0 (state.step == S0);
             // call readcount();
             state <= State_t {cat:SOUND, func:READCOUNT, step:S0}; 
             ret <= State_t {cat:SOUND, func:DATA, step:S1};
             romaddr <= romaddr + 4; // skip "data"
         endrule

         rule ruleS1 (state.step == S1);
             state <= State_t {cat:SOUND, func:PLAY, step:S0}; 
             romaddr <= romaddr - 1;
         endrule

      endrule // DATA

dcountにデータ長が得られたので、実際のサウンドデータを出力するため、PLAYに移行します。

前のブログ 次のブログ

サウンドFSMの作成

waveフォーマット解析とデータ供給を実行する、メインのFSMの設計を行います。このような小さいFSMであっても階層設計を行います。その理由はソフトウェアと同じで、構造化のためです。最上位ステートは図236.1のようにINIT, SOUNDの2ステートとします。基本的にINITでは外部からサウンドコードが送信されてくるのを待ち、自分のコードであればSOUNDに遷移します。サウンド出力が終了すると、またINITに戻ります。

フラットなFSMではステート変数を整数で持ちますが、階層FSMでは構造体で持つことにします。階層は3階層で、上位2階層が意味のある機能を示し、最下層はステップとします。次に構造体の記述を示します。

    typedef struct {
           Category_t cat;
           Function_t func;
           Step_t step;
    } State_t deriving(Bits,Eq);

上位からカテゴリー、ファンクション、ステップと名付けました。最上位のカテゴリーは先の図のように、 INIT, SOUNDの2ステートからなります。

    typedef enum { INIT, SOUND } Category_t deriving(Bits,Eq);

INITでは中間階層である機能は特になく、2ステートを持ち、LRCLKと同期させます。これはFSMクロックがLRCLKよりも速いため、LRCLKと確率的に位相が合わなくなるためです。

SOUNDでは機能としてFORMAT, DATA, PLAY, READCOUNT, READMEMの5種を持ちます。それぞれの機能は、フォーマット解析、データ長取得、演奏です。さらにそこから呼ばれる共通シーケンス(サブルーチン)として、データ長読み出し、データ1バイト読み出しが存在します。

    typedef enum { FORMAT, DATA, PLAY, READCOUNT, READMEM } Function_t deriving(Bits,Eq);

同階層内にコール関係があり、DATAからREADCOUNTをコールします。さらにREADCOUNTからREADMEMをコールするので、リターンスタックは2段必要です。

最下層のステップの名前には特に意味が無く、シーケンシャルにステートを進めるだけです。シーケンシャルになる理由は、フォーマット解析やROMのデータ待ちなど様々です。

    typedef enum { S0, S1, S2, S3, S4, S5, S6 } Step_t deriving(Bits,Eq);

以上は宣言であり、実際のインスタンシエーションは以下のようにモジュール内部で行います。

    Reg#(State_t) state <- mkReg(State_t{cat:INIT,func:?,step:S0}),
         ret <- mkRegU,
         ret2 <- mkRegU;

ステート構造体stateと、さらに同じ構造を持つ2本のリターンレジスタret, ret2をインスタンスしています。

前のブログ 次のブログ

ROMの作成

図234.2に示したように、サウンドROMが存在するので、BSVで作成します。ROMは合成には使用しませんが、bsimシミュレーションのために、 ROMは書き込まないRAMとして実装します。RAMはBSVではRegFileライブラリを使用します。RegFileは実際には1W5RのマルチポートRAMですが、他のポートは使用しません。

    import RegFile::*;

最初にこの行によりライブラリRegFileを導入します。インスタンスは次の行で行います。同時にROMファイルの内容をロードします。

    typedef Bit#(15) Addr_t;
    typedef Bit#(8) Data_t;
    RegFile#(Addr_t, Data_t) rom <- mkRegFileLoad("sound_data/ch00.hex", 0, 18593);

以下にROMファイルの内容を示します。チャネル0のファイルは3つのサウンドを持つ、18,594バイトのファイルです。

    52
    49
    46
    46
    d6
    10
    :

サウンドの難しさ

映像とサウンドを一致させるには難しさがあります。

• ワンショット --- 映像のほうがサウンドよりも長いため、ひとつの映像事象において複数のサウンドが鳴ってしまう。例えば自弾がどこにも当たらずに飛行して壁で爆発するまでに、発射音が複数回鳴ってしまう。 図235.1 ワンショットNG
• プリエンプション --- 映像よりもサウンドのほうが長いため、2度目の映像事象にサウンドが鳴らない。例えばインベーダが非常に短い間隔で消滅した場合、2度目の消滅音が無視されてしまう。 図235.2 プリエンプションNG これらは一見矛盾するため、解決法を考える必要があります。状態ではなくエッジでサウンドを起動すれば解決できそうです。ただし、サウンド再生中に中断及び再実行可能にする必要があります。 図235.3 ワンショット 図235.4 プリエンプション さらに、ゲーム制御とサウンドのFSMでは動作周波数が30倍も異なり、ゲーム制御FSMからのサウンド指示間隔が短いと取りこぼす可能性があります。しかしながら、実験の結果取りこぼしを対策するためのサウンドキューよりも、リアルタイム性を優先したほうが良いことが分かりました。従って、当初FIFOジェネレータで作成したサウンドキューを廃止して1段のバッファとします。

前のブログ 次のブログ

スペースインベーダーのモジュールの入れ替え

過去にスペースインベーダーをRTLで開発しました。今回はBSVのトライアルとして既存のverilogモジュールの入れ替えを実施します。小さめのFSMであるサウンドFSMを入れ替えますが、合わせて仕様も高級なものにしようと思います。RTLで記述したときは、サウンドチャネルは1個で、優先度判定を行いサウンド割込みを行いました。今回は、サウンドチャネルを複数持って、サウンド重畳を行うことを考えます。そのため、複数の音を出し音量を平均化するような、サウンドミックス回路を新設します。

サウンドチャネルの決定

さて、音は以下の10種類ですが、同時発生を考えて、自機音、インベーダ音1, 2、UFO音の4チャネルとします。また、サウンド演奏中に割込みが入るため、プリエンプティブに設計する必要があります。

変更前後のブロック図

現状のRTL設計でのブロック図をVivadoで表示したものを図234.1に示します。

新仕様のブロック図は図234.2のようになります。色付けの部分が新規設計モジュールです。

前のブログ 次のブログ

ルール

大変便利なemacs verilog modeですが、最上位でうまく行かなかったので調査したところ、以下のようなことが分かりました。

中間階層で、下位モジュールインタフェースをパススルーして上位に上げる場合のルールは、

• /*AUTOINPUT*/及び/*AUTOOUTPUT*/

最上位(テストベンチのように)で、信号がその階層内で留まる場合のルールは、

• /*AUTOREGINPUT*/及び/*AUTOWIRE*/

と記述します。

ちなみに、 /*AUTOINPUT*/と/*AUTOREGINPUT*/が同時に存在する場合は /*AUTOINPUT*/が勝ち、/*AUTOOUTPUT*/と/*AUTOWIRE*/が同時に存在する場合は、/*AUTOWIRE*/が勝つようです。

実施結果

まず中間階層に相当する、原始のverilog fileを示します。下位モジュールの信号を上位に上げる場合なので、/*AUTOINPUT*/及び/*AUTOOUTPUT*/と記述し、さらにインターフェース部分には/*AUTOARG*/と記述します。

これに対してC-c C-aを実行すると、以下のように補完されます。

次にテストベンチ相当の、原始のverilog fileを示します。下位モジュールからの信号はこの階層内で留まるため、/*AUTOREGINPUT*/及び/*AUTOWIRE*/と記述します。

これに対してC-c C-aを実行すると、以下のように補完されます。

前のブログ 次のブログ

BSVによるテストベンチの記述

続いてテストベンチもBSVで記述していきます。シーケンシャルな記述が必要なので、自動FSMを利用します。以下にBSV(ファイル名Tb.bsv)を示します。テストベンチにクロックとリセットの記述が無いことに注意してください。

seqブロックの内部では、ソフトウェアと似ており、一行1クロックで順番に実行されます。内部的にはbscにより自動ステートマシンが生成され、一行ずつ順番に実行されます。

テストベンチファイル:Tb.bsv

import FibOne::*;
import StmtFSM::*;
    
(* synthesize *)
module mkTb();
    
   Fib_ifc fibo <- mkFibOne();
   int x = fibo.read();

   Stmt test = seq
      while (x < 10000)
         $display("%0d", x);
      $display("%0d", x);
      $finish;
   endseq;
    
   mkAutoFSM(test);
    
endmodule

コンパイルとBluesimシミュレーションの実行

このテストベンチをコンパイルし、シミュレーションを実行します。以下は下位モジュールが変更されていた場合ですが、自動的に下位モジュールもコンパイルされます。

$ **bsc -sim -u Tb.bsv**
checking package dependencies
compiling ./FibOne.bsv
code generation for mkFibOne starts
Elaborated module file created: mkFibOne.ba
compiling Tb.bsv
code generation for mkTb starts
Elaborated module file created: mkTb.ba
All packages are up to date.

bluesimシミュレーションを実行します。

$ bsc -sim -e mkTb -o mkTb.exec
Bluesim object created: mkTb.{h,o}
Bluesim object created: mkFibOne.{h,o}
Bluesim object created: model_mkTb.{h,o}
Simulation shared library created: mkTb.exec.so
Simulation executable created: mkTb.exec
$ ./mkTb.exec
          1
          1
          2
          3
          5
          8
         13
         21
         34
         55
         89
        144
        233
        377
        610
        987
       1597
       2584
       4181
       6765
      10946

Verilogテストベンチと同様の結果が得られました。

Verilogシミュレーションの実行

確認のため、verilogシミュレーションを実施してみます。BSVではクロックとリセットは書かなくてもシミュレーション時に補完されるのですが、verilogシミュレーション時には無いため、マニュアルで追加する必要があります。それらの記述は前稿のテストベンチを参考にします。

以下にテストベンチからverilogコードを生成し(ファイル名mkTb.v)ます。

$ bsc -verilog Tb.bsv
Verilog file created: mkTb.v

そのファイルにinclude文を追加します。場所は、initial begein endの間です。includeするファイルにはクロックとリセットの動作をverilogで記述します。その理由は、Bluesimの場合は外部から自動的にクロックとリセットが印加されるのに比べて、verilog simでは陽に与える必要があるからです。

テストベンチファイル:mkTb.v(部分)

    initial
    begin
      running = 1'h0;
      start_reg = 1'h0;
      start_reg_1 = 1'h0;
      state_can_overlap = 1'h0;
      state_fired = 1'h0;
      state_mkFSMstate = 3'h2;
      `include "initial.v"    <----ここ
    end

initial.vの中身を示します。クロックとリセットの記述がされています。

インクルードファイル:initial.v

       force RST_N = 1'b0;
       #30;
       force RST_N = 1'b1;
    end
       
    initial begin
       force CLK = 1'b0;
       forever begin
       #5 force CLK = ~CLK;
       end

修正したテストベンチmkTb.vとモジュールを合わせてverilogシミュレーションを行います。

$ bsc -verilog FibOne.bsv
Verilog file created: mkFibOne.v
$ iverilog mkTb.v mkFibOne.v -o mkFibOne.exev
mkTb.v:220: tgt-vvp sorry: procedural continuous assignments are not yet fully supported. The RHS of this assignment will only be evaluated once, at the time the assignment statement is executed.
$ ./mkFibOne.exev
          1
          1
          2
          3
          5
          8
         13
         21
         34
         55
         89
        144
        233
        377
        610
        987
       1597
       2584
       4181
       6765
      10946

前のブログ 次のブログ