Posts Tagged with "Design"

既に発行済みのブログであっても適宜修正・追加することがあります。
We may make changes and additions to blogs already published.

BSVの設計トライアル(4)

posted by sakurai on April 10, 2020 #237

サウンド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バイトの数値が得られます。

図%%.1
図237.1 FORMAT機能ステート遷移図

dcountにフォーマット長が得られたので、次にデータ長を取得します。
 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に移行します。

図%%.2
図237.2 DATA機能ステート遷移図

PLAYにおいては4倍のインターポレーションを行うため、4回同じデータを出力します。

左矢前のブログ 次のブログ右矢

BSVの設計トライアル(3)

posted by sakurai on April 9, 2020 #236

サウンドFSMの作成

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

図%%.1
図236.1 最上位ステート

フラットな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バイト読み出しが存在します。

図%%.2
図236.2 SOUND階層内ステート

第2階層であるファンクション変数の定義です。
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をインスタンスしています。


左矢前のブログ 次のブログ右矢

BSVの設計トライアル(2)

posted by sakurai on April 8, 2020 #235

ROMの作成

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

import RegFile::*;

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

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

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

52
49
46
46
d6
10
:

サウンドの難しさ

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

  • ワンショット --- 映像のほうがサウンドよりも長いため、ひとつの映像事象において複数のサウンドが鳴ってしまう。例えば自弾がどこにも当たらずに飛行して壁で爆発するまでに、発射音が複数回鳴ってしまう。
    図%%.1
    図235.1 ワンショットNG

  • プリエンプション --- 映像よりもサウンドのほうが長いため、2度目の映像事象にサウンドが鳴らない。例えばインベーダが非常に短い間隔で消滅した場合、2度目の消滅音が無視されてしまう。
    図%%.2
    図235.2 プリエンプションNG

    これらは一見矛盾するため、解決法を考える必要があります。状態ではなくエッジでサウンドを起動すれば解決できそうです。ただし、サウンド再生中に中断及び再実行可能にする必要があります。
    図%%.3
    図235.3 ワンショット

    図%%.4
    図235.4 プリエンプション

    さらに、ゲーム制御とサウンドのFSMでは動作周波数が30倍も異なり、ゲーム制御FSMからのサウンド指示間隔が短いと取りこぼす可能性があります。しかしながら、実験の結果取りこぼしを対策するためのサウンドキューよりも、リアルタイム性を優先したほうが良いことが分かりました。従って、当初FIFOジェネレータで作成したサウンドキューを廃止して1段のバッファとします。
    図%%.5

図235.5 ゲーム制御FSMとサウンドFSMの相互作用

左矢前のブログ 次のブログ右矢

BSVの設計トライアル

posted by sakurai on April 7, 2020 #234

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

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

サウンドチャネルの決定

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

表234.1 音データとサウンドチャネルの関係
サウンドの説明 CODE番号 サウンドチャネル バイト数 先頭オフセット+16
ON OFF
自機弾発射音 1 自機音チャネル(#0) 4,318 0 + 16
自機爆発音 2 8,776 4,318 + 16
自機増加音 9 5,500 13,094 + 16
インベーダ爆発音 3 インベーダ音チャネル(#1) 4,622 0 + 16
インベーダ歩行音1 4 インベーダ音チャネル(#2) 1,266 0 + 16
インベーダ歩行音2 5 1,570 1,266 + 16
インベーダ歩行音3 6 1,570 2,836 + 16
インベーダ歩行音4 7 2,180 4,406 + 16
UFO爆発音 8 UFO音チャネル(#3) 25,968 0 + 16
UFO飛行音 10 16 + 10 1,846 25,968 + 16

変更前後のブロック図

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

図%%.1
図234.1 現サウンドシステムブロック図

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

図%%.2
図234.2 新サウンドシステムブロック図


左矢前のブログ 次のブログ右矢

Emacs Verilog Mode

posted by sakurai on April 6, 2020 #233

ルール

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

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

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

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

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

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

実施結果

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

図%%.1
図233.1 中間階層原始ファイル

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

図%%.2
図233.2 中間階層補完後ファイル

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

図%%.3
図233.3 最上位原始ファイル

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

図%%.4
図233.4 最上位補完後ファイル


左矢前のブログ 次のブログ右矢

BSV(Bluespec SystemVerilog)(5)

posted by sakurai on April 3, 2020 #232

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

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

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

import FibOne::*;
import StmtFSM::*;

(* synthesize *)
module mkTb();

   Fib_ifc fibo <- mkFibOne();
   int x = fibo.read();

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

   mkAutoFSM(test);

endmodule

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

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

\$ bsc -sim -u mkTb.bsv
checking package dependencies
compiling ./FibOne.bsv
code generation for mkFibOne starts
Elaborated module file created: mkFibOne.ba
compiling mkTb.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
Bluesim object created: mkTb.{h,o}
Bluesim object created: mkFibOne.{h,o}
Bluesim object created: model_mkTb.{h,o}
Simulation shared library created: mkTb.so
Simulation executable created: mkTb
\$ ./mkTb
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)、追加したクロックとリセットの部分のみの記述を示します。

initial begin
(略)
   force RST_N = 1'b0;
   #100;
   force RST_N = 1'b1;
end

initial begin
   force CLK = 1'b0;
   forever begin
   #10 force CLK = ~CLK;
end

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

\$ bsc -verilog FibOne.bsv
Verilog file created: mkFibOne.v
\$ iverilog mkTb.v mkFibOne.v -o mkFibOne
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
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946


左矢前のブログ 次のブログ右矢

BSV(Bluespec SystemVerilog)(4)

posted by sakurai on April 1, 2020 #231

モジュールインタフェースの引出し

Vivadoにより合成をかける場合に、前稿のモジュールmkFibOneのようにインタフェース信号が無いと最適化され、全てのロジックが削除されてしまいます。従って、mkFibOneモジュールにインタフェースを設ける修正を行います。合わせて、テストベンチのような記述がモジュール内に混入されていたものを分離し、テストベンチに移します。

BSVではモジュールとインタフェースは明確に分離されています。修正したファイル(ファイル名FibOne.bsv)を示します。\$displayや\$finishはテストベンチへ移しました。

interface Fib_ifc;
   method int read();
endinterface

(* synthesize, always_ready, always_enabled *)
module mkFibOne(Fib_ifc);
   Reg#(int) this_fib <- mkReg(0);
   Reg#(int) next_fib <- mkReg(1);

   rule fib;
      this_fib <= next_fib;
      next_fib <= this_fib + next_fib;  // note that this uses stale this_fib
   endrule: fib

   method int read();
      return this_fib;
   endmethod

endmodule: mkFibOne

ここで、

   Reg#(int) this_fib <- mkReg(0);

これは前稿で2行になっていたレジスタのインスタンシエーションの省略記法で、

Interface_type identifier <- module_name;

という文法を持ちます。この意味は、「Interface_typeの型を持つインタフェースを提供するモジュールmodule_nameをインスタンス化し、インタフェースのハンドルidentifierを取得する」ということです。

Verilogの生成

BSVプログラムに対して、bscによりverilog生成を実行すれば、合成されたverilog(ファイル名mkFibOne.v)は以下のようになります。

//
// Generated by Bluespec Compiler (build 38534dc)
//
// On Wed Mar 25 09:12:14 JST 2020
//
//
// Ports:
// Name                         I/O  size props
// read                           O    32 reg
// CLK                            I     1 clock
// RST_N                          I     1 reset
//
// No combinational paths from inputs to outputs
//
//

`ifdef BSV_ASSIGNMENT_DELAY
`else
  `define BSV_ASSIGNMENT_DELAY
`endif

`ifdef BSV_POSITIVE_RESET
  `define BSV_RESET_VALUE 1'b1
  `define BSV_RESET_EDGE posedge
`else
  `define BSV_RESET_VALUE 1'b0
  `define BSV_RESET_EDGE negedge
`endif

module mkFibOne(CLK,
        RST_N,

        read);
  input  CLK;
  input  RST_N;

  // value method read
  output [31 : 0] read;

  // signals for module outputs
  wire [31 : 0] read;

  // register next_fib
  reg [31 : 0] next_fib;
  wire [31 : 0] next_fib$D_IN;
  wire next_fib$EN;

  // register this_fib
  reg [31 : 0] this_fib;
  wire [31 : 0] this_fib$D_IN;
  wire this_fib$EN;

  // value method read
  assign read = this_fib ;

  // register next_fib
  assign next_fib$D_IN = this_fib + next_fib ;
  assign next_fib$EN = 1'd1 ;

  // register this_fib
  assign this_fib$D_IN = next_fib ;
  assign this_fib$EN = 1'd1 ;

  // handling of inlined registers

  always@(posedge CLK)
  begin
    if (RST_N == `BSV_RESET_VALUE)
      begin
        next_fib <= `BSV_ASSIGNMENT_DELAY 32'd1;
    this_fib <= `BSV_ASSIGNMENT_DELAY 32'd0;
      end
    else
      begin
        if (next_fib$EN) next_fib <= `BSV_ASSIGNMENT_DELAY next_fib$D_IN;
    if (this_fib$EN) this_fib <= `BSV_ASSIGNMENT_DELAY this_fib$D_IN;
      end
  end

  // synopsys translate_off
  `ifdef BSV_NO_INITIAL_BLOCKS
  `else // not BSV_NO_INITIAL_BLOCKS
  initial
  begin
    next_fib = 32'hAAAAAAAA;
    this_fib = 32'hAAAAAAAA;
  end
  `endif // BSV_NO_INITIAL_BLOCKS
  // synopsys translate_on
endmodule  // mkFibOne

修正したVerilogテストベンチtbmkFibOne.vを以下に示します。前稿ではクロックとリセットを下位モジュールに供給するだけだったのを、データ表示とシミュレーションの停止機能をモジュールから移動しています。

`timescale 1ns/1ps

module tb_mkFibOne;
   /*AUTOREGINPUT*/
   // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)
   reg          CLK;            // To mkFibOne of mkFibOne.v
   reg          RST_N;          // To mkFibOne of mkFibOne.v
   // End of automatics
   /*AUTOWIRE*/
   // Beginning of automatic wires (for undeclared instantiated-module outputs)
   wire [31:0]      read;           // From mkFibOne of mkFibOne.v
   // End of automatics
   mkFibOne mkFibOne (/*AUTOINST*/
              // Outputs
              .read     (read[31:0]),
              // Inputs
              .CLK      (CLK),
              .RST_N        (RST_N));

   initial begin
      RST_N = 1'b0;
      #100;
      RST_N = 1'b1;
      forever begin
       if (CLK) $display("%d", read);
       if (read > 10000) $finish;
       #10;
      end
   end

   initial begin
      CLK = 1'b0;
      forever begin
     #10  CLK = ~CLK;
      end
   end

   initial begin
      $dumpfile("tbmkFibOne.vcd");
      $dumpvars(0,mkFibOne);
   end

endmodule 

Verilogシミュレーション

準備ができたので、iverilogによるverilogシミュレーションを実行します。

\$ iverilog tbmkFibOne.v mkFibOne.v -o mkFibOne
\$ ./mkFibOne
VCD info: dumpfile tbmkFibOne.vcd opened for output.
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946

前稿と同様の結果になりました。

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

VivadoのIPインテグレータにより、生成されたverilogを取り込み、IPインテグレータ上で最上位のテストベンチを作成します。先に作成したテストベンチ(ファイル名tbmkFibOne.v)はシミュレーション用で合成できないため、IPインテグレータで上位を作成します。図の左からZynqのPS部、クロックリセット生成、対象回路となっています。

図%%.1
図231.1 IP Integratorの回路図

vivado上でbehaviorシミュレーションを実施した結果です。iverilogの結果と同一になっています。

図%%.2
図231.2 Vivadoによる波形


左矢前のブログ 次のブログ右矢

BSV(Bluespec SystemVerilog)(3)

posted by sakurai on March 31, 2020 #230

BSV(Bluespec SystemVerilog)によるシミュレーション

bscとは、Bluespecが最近オープンソース化したコンパイラです。詳しくは、ここを見てください。

いろいろと調整した結果、bscがインストールできました。早速、以下のようなフィボナッチモジュール(ファイル名FibOne.bsv)をコンパイルしてみます。これは、フィボナッチ数列を発生するモジュールで、前の値に次の値を加算することを繰り返すものです。

(* synthesize *)
module mkFibOne();
   // register containing the current Fibonacci value
   Reg#(int) this_fib();              // interface instantiation
   mkReg#(0) this_fib_inst(this_fib); // module instantiation
   // register containing the next Fibonacci value
   Reg#(int) next_fib();
   mkReg#(1) next_fib_inst(next_fib);

   rule fib;  // predicate condition always true, so omitted
      this_fib <= next_fib;
      next_fib <= this_fib + next_fib;  // note that this uses stale this_fib
      $display("%0d", this_fib);
      if ( this_fib > 10000 ) $finish(0) ;
  endrule: fib
endmodule: mkFibOne

モジュール内にテストベンチのような\$displayや\$finishの記述があるので、これだけでテストが可能です(が、モジュール設計としては良くないので、後で外します)。

BSVプログラムの説明

以下の部分は、現在の値this_fibと次の値next_fibを保持するレジスタのインスタンスです。

   // register containing the current Fibonacci value
   Reg#(int) this_fib();              // interface instantiation
   mkReg#(0) this_fib_inst(this_fib); // module instantiation
   // register containing the next Fibonacci value
   Reg#(int) next_fib();
   mkReg#(1) next_fib_inst(next_fib);

次のように、ruleブロックにアルゴリズム計算ルールを記述します。

      this_fib <= next_fib;
      next_fib <= this_fib + next_fib;  // note that this uses stale this_fib

コメントにも書いているように、this_fibとnext_fibは同時に変更されるので、それぞれ、直前の値を読み込み、同時に値を更新します。

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

コンパイル及びシミュレーションモデル生成(リンク)の2段階で行います。太字が入力部分です。

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

mkFibOneというbluesimのシミュレーションモデルが生成されたので実行します。

\$ ./mkFibOne
0
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946

Verlogの生成

次に、確認のためにverilogシミュレーションを実行します。まずbscにより、モジュールを合成可能なVerilogコードにコンパイルします。

\$ bsc -verilog FibOne.bsv
Verilog file created: mkFibOne.v

生成されたファイル名はモジュール名+".v"(mkFibOne.v)となります。

//
// Generated by Bluespec Compiler (build 38534dc)
//
// On Mon Mar 23 06:33:47 JST 2020
//
//
// Ports:
// Name                         I/O  size props
// CLK                            I     1 clock
// RST_N                          I     1 reset
//
// No combinational paths from inputs to outputs
//
//

`ifdef BSV_ASSIGNMENT_DELAY
`else
  `define BSV_ASSIGNMENT_DELAY
`endif

`ifdef BSV_POSITIVE_RESET
  `define BSV_RESET_VALUE 1'b1
  `define BSV_RESET_EDGE posedge
`else
  `define BSV_RESET_VALUE 1'b0
  `define BSV_RESET_EDGE negedge
`endif

module mkFibOne(CLK,
        RST_N);
  input  CLK;
  input  RST_N;

  // register next_fib_inst
  reg [31 : 0] next_fib_inst;
  wire [31 : 0] next_fib_inst$D_IN;
  wire next_fib_inst$EN;

  // register this_fib_inst
  reg [31 : 0] this_fib_inst;
  wire [31 : 0] this_fib_inst$D_IN;
  wire this_fib_inst$EN;

  // register next_fib_inst
  assign next_fib_inst$D_IN = this_fib_inst + next_fib_inst ;
  assign next_fib_inst$EN = 1'd1 ;

  // register this_fib_inst
  assign this_fib_inst$D_IN = next_fib_inst ;
  assign this_fib_inst$EN = 1'd1 ;

  // handling of inlined registers

  always@(posedge CLK)
  begin
    if (RST_N == `BSV_RESET_VALUE)
      begin
        next_fib_inst <= `BSV_ASSIGNMENT_DELAY 32'd1;
    this_fib_inst <= `BSV_ASSIGNMENT_DELAY 32'd0;
      end
    else
      begin
        if (next_fib_inst$EN)
      next_fib_inst <= `BSV_ASSIGNMENT_DELAY next_fib_inst$D_IN;
    if (this_fib_inst$EN)
      this_fib_inst <= `BSV_ASSIGNMENT_DELAY this_fib_inst$D_IN;
      end
  end

  // synopsys translate_off
  `ifdef BSV_NO_INITIAL_BLOCKS
  `else // not BSV_NO_INITIAL_BLOCKS
  initial
  begin
    next_fib_inst = 32'hAAAAAAAA;
    this_fib_inst = 32'hAAAAAAAA;
  end
  `endif // BSV_NO_INITIAL_BLOCKS
  // synopsys translate_on

  // handling of system tasks

  // synopsys translate_off
  always@(negedge CLK)
  begin
    #0;
    if (RST_N != `BSV_RESET_VALUE) $display("%0d", $signed(this_fib_inst));
    if (RST_N != `BSV_RESET_VALUE)
      if ((this_fib_inst ^ 32'h80000000) > 32'h80002710) $finish(32'd0);
  end
  // synopsys translate_on
endmodule  // mkFibOne

テストベンチの作成

bluesimは暗黙のクロックやリセットが動作するため、テストベンチ無しでもシミュレーションが実行できました。一方verilogではそのような機能は無いので以下のようなテストベンチ(ファイル名tbmkFibOne.v)を用意します。

テストベンチ中の/*AUTO〇〇*/という記述は、emacsのverilog modeによるインスタンスやポートの自動生成の機能です。C-c C-aにより、面倒なポートリストやインスタンス部分が自動生成できます。テストベンチでは、モジュールへの入力用に/*AUTOREGINPUT*/と、モジュールからの出力用に/*AUTOWIRE*/を指定しておきます。

`timescale 1ns/1ps

module tb_mkFibOne;
   /*AUTOREGINPUT*/
   // Beginning of automatic reg inputs (for undeclared instantiated-module inputs)
   reg          CLK;            // To mkFibOne of mkFibOne.v
   reg          RST_N;          // To mkFibOne of mkFibOne.v
   // End of automatics
   /*AUTOWIRE*/
   mkFibOne mkFibOne (/*AUTOINST*/
              // Inputs
              .CLK      (CLK),
              .RST_N        (RST_N));

   initial begin
      RST_N = 1'b0;
      #100;
      RST_N = 1'b1;
   end

   initial begin
      CLK = 1'b0;
      forever begin
     #10;
     CLK = ~CLK;
      end
   end

   initial begin
      $dumpfile("tbmkFibOne.vcd");
      $dumpvars(0,mkFibOne);
   end

endmodule 

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

iverilogによりシミュレーションを実行すると、同じ結果となりました。なお、実行コマンドは同じmkFibOneですが、bscが生成したものとiverilogが生成したものでは全く内容が違っています。

\$ iverilog tbmkFibOne.v mkFibOne.v -o mkFibOne
\$ ./mkFibOne
VCD info: dumpfile tbmkFibOne.vcd opened for output.
0
1
1
2
3
5
8
13
21
34
55
89
144
233
377
610
987
1597
2584
4181
6765
10946

verilogシミュレーションで生成したVCDファイルを波形ビュワーにかけた図です。

図%%.1
図230.1 GTKWaveによる波形


左矢前のブログ 次のブログ右矢

BSV(Bluespec SystemVerilog)(2)

posted by sakurai on March 30, 2020 #229

BSV(Bluespec SystemVerilog)の解説

詳細はこちら(魚拓)

図229.1のような、3つのプロセスがレジスタx, yを更新する回路を設計することを考えます。この回路には、次のルール1から3までの、3つの仕様があります。

  • ルール1: cond2がアサートされると、プロセス2が起動しy--します。
  • ルール2: プロセス2が起動しないとき、かつcond1がアサートされると、プロセス1が起動しy++し、かつ同時にx--します。
  • ルール3: プロセス1が起動しないとき、かつcond0がアサートされると、プロセス0が起動しx++します。

補足するとルール2の場合、プロセス1が起動するときy++, x--は同時に起きるアトミックな演算です。つまり、プロセス1によるx--のみ、またはy++のみの実行は仕様違反となります。

図%%.1
図229.1 3つの並行プロセスにより書き換えられる2つのレジスタx, y

Verilogではステートに注目して記述します。
always @ (posedge CLK) begin
    if (cond2)
        y <= y - 1;
    else if (cond1) begin
        y <= y + 1;
        x <= x - 1;
    end else if (cond0)
        x <= x + 1;
end

このように記述したくなりますが、これだとcond2のアサート時にはxは書き換えられません。cond2アサートかつcond0アサートの場合は、ルール1とルール3が有効となるため、y--かつx++となるべきです。バグの原因は、優先順位(競合関係)が直接無いプロセス2と0に優先順位を持ち込んだことと考えて、alwaysの中を以下のように修正します。

    if (cond2)
        y <= y - 1;
    else if (cond1) begin
        y <= y + 1;

    if (cond1) begin
        x <= x - 1;
    end else if (cond0)
        x <= x + 1;

すると、今度は、プロセス1がプロセス0に勝ち、かつプロセス2に負けた時に、アトミック性が成立しません。ルール2が半分だけ実行されてしまいます。実はプロセス2と1は無関係ではなく、プロセス1を経由して関係が有ったのです。

ひとつの考え方としては、ハードでは並行に条件判定をするので、if else if 等とせずに、3本のif文を並べます。さらに外部信号cond1,2,3,でレジスタ更新を行うのではなく、プロセスの起動信号に注目します。具体的には、プロセス2の起動はcond2であるから、

cond2

がプロセス2の起動条件です。プロセス1の起動は、そうではなく(!cond2)、かつ、cond1であるから、

!cond2 && cond1

がプロセス1の起動条件です。プロセスの起動は、そうではなく(!(!cond2 && cond1))、かつ、cond0であるから、

!(!cond2 && cond1) && cond0

がプロセス0の起動条件です。これらより、以下の記述が得られます。

    if (cond2)
        y <= y - 1;

    if (!cond2 && cond1) begin
        y <= y + 1;
        x <= x - 1;
    end 

    if (!(!cond2 && cond1) && cond0))
        x <= x + 1;

verilogでは優先順位を信号の条件で表すことで、複雑になっています。後からプロセスの優先順位が変わると、ハードコードされた条件文の修正が大変なことになります。

一方、VSBでは、レジスタの更新ルールがそのまま記述できます。

rule proc0 (cond0);
    x <= x + 1;
endrule

rule proc1 (cond1);
    y <= y + 1;
    x <= x - 1;
endrule

rule proc2 (cond2);
    y <= y - 1;
endrule
(* descending_urgency = “proc2, proc1, proc0” *)

プロセスの優先順位と信号の条件が分離されているため、プロセスの優先順位が変わっても、コメントの修正のみでコードの修正はありません。

プロセスが3つ程度だとそれほど有難みがわかりませんが、これにプロセス3を一つ追加して、4つの優先順位を付けると、図229.2の赤字の修正のように、非常に複雑になります。

図%%.2
図229.2 4つの並行プロセスにより書き換えられる2つのレジスタx, y


左矢前のブログ 次のブログ右矢

BSV(Bluespec SystemVerilog)

posted by sakurai on March 12, 2020 #220

BSV(Bluespec SystemVerilog)の注意点

Verilogコードで以下のような回路を設計することを考えます。

reg [31:0] burst_count, dest_burst_size ;
reg        burst_in_progress ;
...
always @(posedge clk)    // burst_in_progress_stop 
begin
   if (burst_in_progress && (burst_count==dest_burst_size))
       burst_in_progress <= False;
   ...
end 

always @(posedge clk)    // burst_count;
begin  
   burst_count <= burst_in_progress ? burst_count+1 : 0;
   ...
end

2個の同期FFグループがあり、最初のFFでは、バースト転送中信号を作成しています。初期状態が不定ですが、なんらかの信号によりburst_in_progressがtrue(=バースト転送中)を示した後は、基本的にバーストを継続します。バーストカウントが規定されたサイズだけ転送したら、バースト転送中をfalseにしてバースト転送を停止させます。

次のFFグループはバーストカウントを計算するFFであり、バースト転送中がtrueの時は1クロック毎に+1だけカウントし、バースト転送中がfalseになったらカウントを0にします。

図220.1に、このverilogコードを図示します。

図%%.1
図220.1 verilogコードの図化

FF間でお互いの情報を使用していますが、クロック同期なので問題の無い回路です。

このコードはBSVでは以下のようになりそうです。

Reg#(Data_t) dest_burst_size <- mkReg (32'h0) ;
Reg#(Data_t) burst_count     <- mkReg (0) ;
Reg#(Bool) burst_in_progress  <-  mkReg (False) ;

rule burst_in_progress_stop (burst_in_progress && (burst_count==dest_burst_size));
   burst_in_progress <= False;
   ...
endrule

rule burst_counting ;
   burst_count <= burst_in_progress ? burst_count + 1 : 0;
   ...
endrule

ところが、これは最初のruleにおいてburst_countがreadされ、burst_in_progressがwriteされます。一方、2番目のruleにおいて、burst_in_progressがreadされ、burst_countがwriteされます。ruleをスキャンする順番により競合が起きます。

これは、ルールが同時に発火するのではないため、順番によって結果が異なるためです。これを避けるには、一つのruleの中に入れれば良いとのことです。このようにすれば変更の同時性が保証されるため、正しく直前のデータを参照することになります。

Reg#(Data_t) dest_burst_size <- mkReg (32'h0) ;
Reg#(Data_t) burst_count     <- mkReg (0) ;
Reg#(Bool) burst_in_progress  <- mkReg (False) ;

rule burst_in_progress_stop (burst_in_progress) ;
   burst_in_progress <= burst_count != dest_burst_size ;
   burst_count <= (burst_count != dest_burst_size)  ? burst_count+1 : 0;      
   ...
endrule

左矢前のブログ 次のブログ右矢


ページ: