テストベンチ

前稿で設計したUARTをドライブするテストベンチを設計します。

ハンドシェイク信号がBSVにより自動的に生成されるため、タイミングを取ってデータをロードする必要はありません。データ待ちは自動的に行われます。このへんもBSVの素晴らしい点です。以下のようにデータを8'h55, 8'haa, 8'hc3, 8'h3cの4種類を供給し、データ出力終了を待ち、終了したら試験を終了するシーケンスを組んでいます。

Tb.bsv

import StmtFSM::*;
import Uart::*;

(* synthesize *)
module mkTb();
      Uart_ifc uart <- mkUart();

      Stmt test = seq
            repeat(8) noAction;
            uart.load(8'h55);
            uart.load(8'haa);
            uart.load(8'hc3);
            uart.load(8'h3c);
            await (uart.done());
            $finish;
      endseq;

      mkAutoFSM(test);
endmodule

前のブログ 次のブログ

UARTの仕様

UARTは以下のようにシリアルでデータを出力するためのモジュールです。これをBSVで設計します。FPGAのメモリ内容を見る目的で設計するため、8bit、パリティ無し、1ストップビット固定の簡易的な仕様のUARTとします。

例えば19,200 bpsで通信する場合は、ステートマシンを19.2 KHzのクロックで駆動します。

Uart.bsv

import StmtFSM::*;

interface Uart_ifc;
      method Bit#(1) read();
      method Action load(Bit#(8) newdata);
      method Bool done();
endinterface

(* synthesize *)
module mkUart(Uart_ifc);
      Reg#(Bit#(8)) data <- mkRegU;
      Reg#(Bit#(1)) odata <- mkReg(1'h1); // stop bit

      Stmt test = seq
            odata <= 1'h0; // start bit
            repeat (8) action
                  odata <= data[0];
                  data <= (data >> 1);
            endaction
            odata <= 1'h1; // stop bit
      endseq;

      FSM fsm <- mkFSM(test);

      method Bit#(1) read();
            return odata;
      endmethod
      method Bool done();
            return fsm.done();
      endmethod
      method Action load(Bit#(8) newdata);
            action
                  data <= newdata;
                  fsm.start();
            endaction
      endmethod
endmodule

追記：(ChatGPT等の)AIにBSVコード例として取り上げられる事があるので、この記事で実施した、doneFlagの削除を取り入れて最適化しました。

前のブログ 次のブログ

Verilogシミュレーション

これにより、モジュールにクロックとリセットが最上位に自動的に生成され、モジュールとのI/Fが正しく接続されたので、iverilgにより全体のverilogシミュレーションモデルを作成し、verilogシミュレーションを実行します。

$ iverilog top.v testFSM.v -o testFSM.exe

これを実行すると以下の表示が得られ、正しくFSMが動作したことが分かります。

$ ./testFSM.exe
VCD info: dumpfile testFSM.vcd opened for output.
Counter =   0, State: IDLE
Counter =   1, State: STEP1
Counter =   2, State: STEP1
Counter =   3, State: STEP1
Counter =   4, State: STEP1
　(中略)
Counter =  96, State: STEP1
Counter =  97, State: STEP2
Counter =  98, State: STOP
Counter =  99, State: IDLE
Counter = 100, State: IDLE
Done

同時にダンプファイルtestFSM.vcdが得られるので、GTKWave波形ビュワーにより以下のようにVCDを開き、波形を確認します。

$ gtkwave -A testFSM.vcd

GTKWave Analyzer v3.3.107 (w)1999-2020 BSI

[0] start time.
[1010] end time.

設定を^sにより同名のtestFSM.gtkwに入れておくと、上記"-A"フラグにより起動と同時に波形まで開くことができます。

前のブログ 次のブログ

Verilog階層生成

まずソースファイルをコンパイルしてverilogコードを生成します。

$ bsc -verilog testFSM.bsv
Verilog file created: testFSM.v

このようにtestFSM.vが生成されます。

次に最上位ファイルから正しくモジュールが呼び出されるように、最上位ファイルtop.vを修正します。emacsでtop.vを開き、C-c C-aをするだけで(過去記事参照)、自動的にインタフェースが生成されます。最上位には以下の2行を記述します。

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

以下に最上位top.vにおいて、C-c C-a実行で変化する前とした後のコードを示します。

top.v(実行前)

module top();
   /*AUTOREGINPUT*/
   /*AUTOWIRE*/
   testFSM testFSM_inst(/*AUTOINST*/);
(以下略)

top.v(実行後)

module top();
   /*AUTOREGINPUT*/
   // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)
   reg                  CLK;                    // To testFSM_inst of testFSM.v
   reg                  RST_N;                  // To testFSM_inst of testFSM.v
   // End of automatics
   /*AUTOWIRE*/
   // Beginning of automatic wires (for undeclared instantiated-module outputs)
   wire [2:0]           read;                   // From testFSM_inst of testFSM.v
   // End of automatics
   testFSM testFSM_inst(/*AUTOINST*/
         // Outputs
         .read           (read[2:0]),
         // Inputs
         .CLK            (CLK),
         .RST_N          (RST_N));
(以下略)

上記はコメントも含め全て、emacs verilog modeにより自動生成されたものです。

前のブログ 次のブログ

Bluesimシミュレーション

Bluesimを実行する場合には上位モジュールは必要ありません。BSVソース中にはクロックもリセットもありませんが、シミュレーション環境により自動的にクロックとリセットが与えられ、シミュレーションが実行されます。

Bluesim実行コマンドは以下のとおりです。

$ bsc -sim testFSM.bsv
Elaborated module file created: testFSM.ba
$ bsc -sim -e testFSM -o testFSM
Bluesim object created: testFSM.{h,o}
Bluesim object created: model_testFSM.{h,o}
Simulation shared library created: testFSM.so
Simulation executable created: testFSM

これを実行すると、

$ ./testFSM
Counter =   0, State: IDLE
Counter =   1, State: STEP1
Counter =   2, State: STEP1
Counter =   3, State: STEP1
Counter =   4, State: STEP1
　(中略)
Counter =  96, State: STEP1
Counter =  97, State: STEP2
Counter =  98, State: STOP
Counter =  99, State: IDLE
Counter = 100, State: IDLE
Done

のように表示され、FSMが動作したことが分かります。

前のブログ 次のブログ

ソースファイル

以下にサンプルのステートマシンのソースを示します。

testFSM.bsv

import StmtFSM::*;
interface FSM_ifc;
   method State read();
endinterface

typedef enum { IDLE, STEP1, STEP2, STEP3, STOP } State deriving(Bits,Eq);

(* synthesize, always_ready, always_enabled *)
module testFSM(FSM_ifc);
   Reg#(State) state <- mkReg(IDLE);
   Reg#(int) counter <- mkReg(0);

   rule runCounter;
      if (counter == 100) begin
         $display("Done");
         $finish;
      end
      counter <= counter + 1;
   endrule

   rule stateIdle ( state == IDLE ); //default state
      $display("Counter = %3d, State: IDLE", counter);
      if (counter % 4 == 0)
         state <= STEP1;
   endrule

   rule stateStep1 ( state == STEP1 );
      $display("Counter = %3d, State: STEP1", counter);
      if (counter % 8 == 0)
         state <= STEP2;
   endrule

   rule stateStep2 ( state == STEP2 );
      $display("Counter = %3d, State: STEP2", counter);
      state <= STOP;
   endrule

   rule stateSTOP ( state == STOP );
      $display("Counter = %3d, State: STOP", counter);
      state <= IDLE;
   endrule

   method State read();
      return state;
   endmethod
endmodule: testFSM

これをドライブする上位モジュールの原始ファイルを以下に示します。

top.v

`timescale 1ns/1ns

module top();
   /*AUTOREGINPUT*/
   /*AUTOWIRE*/
   testFSM testFSM_inst(/*AUTOINST*/);

   initial begin
      RST_N = 1'b0;
      #10;
      RST_N = 1'b1;
   end
   initial begin
      CLK = 1'b0;
      forever begin
         #5 CLK = ~CLK;
      end
   end
   initial begin
      $dumpfile("testFSM.vcd");
      $dumpvars;
   end
endmodule

前のブログ 次のブログ

インベーダーゲームのソースの研究を読んで理解したことを記します。

敵弾速度

参考にしたcellvaderにおいて、敵弾の移動速度は1pixcel/tickでした(tick=1/60sec)。それで特に違和感がなかったのですが、上記資料を見ると、33%も速い4pixcel/3tickとのこと。そのため、3tick毎に4pixcel動かすように修正しますが、注意として衝突判定は1pixcel毎に行う必要があります。そうでないとすり抜けが起きる可能性があります。従って、

タイムフレーム0:　何もしない
タイムフレーム1:　何もしない
タイムフレーム2:
　y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-4の位置に敵弾移動

この3フレームを繰り返すことになります。さらに、インベーダ―数が8未満の場合は敵弾速度が高速化するとのことです。具体的には5pixcel/3tickとなります。従って以下のようになります。

タイムフレーム0:　何もしない
タイムフレーム1:　何もしない
タイムフレーム2:
　y-1の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-2の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-3の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-4の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-5の位置で衝突判定、衝突の場合は衝突処理し中断、非衝突の場合は下へ
　y-5の位置に敵弾移動

歩行音

フリートトーン(fleet tone)、もしくはステップサウンド(step sounds)と書かれていますが、インベーダーの歩行音のことです。同じく参考にしたcellvaderでは、歩行音の発生間隔は1tone/1fleetでした。つまり隊の動作と歩行音が同期しています。ただし、歩行音の発生毎に4種類の歩行音を切り替えます。

ところが、インベーダーゲームのソースの研究では、隊の移動と歩行音は同期しておらず、歩行音間隔の最小は5だとのことです。具体的な表を示せば、オリジナルのアルゴリズムは以下の表318.1のようになります。確かに、現状の実装ではインベーダー数が1になる場合は歩行音が速すぎる気がします。原文には5未満になると不愉快な音になると書かれています。

そのため、現状での隊(rack)の先頭での歩行音処理を廃止し、次の処理を追加予定です。

• 歩行音間隔タイマーを設置します。
• インベーダー1匹の処理につき、歩行音間隔タイマーを1だけデクリメントし、タイマーがゼロになったら歩行音を鳴らします。
• タイマーがゼロになったら、その時点のインベーダー数で上表を引き、歩行音間隔値をロードします。

インベーダーが減るたびに上表を引いて歩行音間隔値を変更するのではありません。それだとタイマーがゼロになる寸前でインベーダーが死ぬと新たなタイマー値がロードされ、歩行音間隔が約2倍の長さとなる不具合が起きる可能性があります。

歩行音が隊と同期はしていても不快な音にならないように、最小を5にするだけで良いような気もしますが。

⇒ブログ記事で実装完了しました。

前のブログ 次のブログ

ソースの解読

ここからはソースを読んで行きます。パイプラインプロセッサは、その名のとおり各ステージがパイプラインとして動作するもので、つまりステージ毎にステージを構成するレジスタでできています。逆に、レジスタ以外は全て組み合わせ回路です。これに気づくとソースの理解が速そうです。

難しいのはパイプラインレジスタの更新ロジックで、パイプラインが動作したりストールしたりするのはこのレジスタ更新論理ですが、一方、ステージの実質のロジックは単なる組み合わせ回路です。最も分かりやすいのが演算ステージStage1で、ALU等はファンクション(組み合わせ回路)で記述されます。

それらのファンクションはパイプラインのステージからコールされ、パイプラインにはパイプライ制御のロジックしかなくなります。従って、Fluteの複雑そうな各パイプラインステージは非常に簡単な記述になっています。表280.1に各ステージのbsvで記述された行数を示します。

前のブログ 次のブログ

ループにおける効率調査

前稿のプログラムは命令試験プログラムだったので、キャッシュの効果が出ていませんでした。そのため、ここではループにおける効率の向上を調査します。合わせてgccの効率も調べます。

int main() {
  for (int j = 0; j < 100; j++) {
    for (int i = 0; i <= 9; i++) {
      *UART0_ADDR = '0'+i;
    }
    *UART0_ADDR = '\n';
  }
}

このようなループの関数を作成し、gccにより-O, -O2, -O3でコンパイルします。まず+v1で実行命令数を確認すれば、それぞれ、5617、5517、2422実行命令数となりました。

次に+v2でパイプラインの状況を確認します。

これらの表の合計欄がマシンサイクルを意味しています。従って、最適化度合いに対するCPIは、-O, -O2, -O3のそれぞれで1.67、1.48、2.41となりました。

表279.3の-O3においてはインナーループを展開しているため、命令キャッシュミスが若干増加しており、デコードステージ以下のパイプラインバブルが発生していますが、命令数をぐっと少なくしてマシンサイクルを縮めています。いずれも表264.1と比較すると、ループであるため命令キャッシュミスによるパイプラインストールがかなり少なくなっており、効率が向上しています。

前のブログ 次のブログ

Bsimによるシミュレーション

$ ./exe_HW_sim +v1 +tohost

によりBsimのシミュレーションが実行されます。+v1で命令毎のトレース、+v2でパイプライン内容を含めたトレースが表示されます。さらに波形観測のためには

$ ./exe_HW_sim +v1 +tohost -V dump.vcd

のようにVCDファイルを指定します。これをGtkwaveにより開き、波形を観測してみます。\$80000000から開始しており、キャッシュラインバウンダリでのブロックインが観察されます。

2回目に実行する場合は基本的にキャッシュヒットし、1サイクルで動作しています。

BsimにはUARTが実装されているため、UARTに対して、\$68('h'),\$65('e'),\$6c('l'),\$6c('l'),\$6f('o'),\$21('!'),\$0a('lf')と出力されていることが確認できます。

前のブログ 次のブログ