SystemC によるテストベンチ の履歴(No.11)

自動変数として作成する†

上でやっているように、

LANG:cpp
Vbin2bcd top("top");

とすれば、そのスコープ内のみで有効な自動変数としてインスタンスが作成されます。 このインスタンスはスコープを抜けると自動的に破棄されます。

コンストラクタに与えている "top" がインスタンス名になります。

この場合、インスタンスのメンバーへのアクセスは top.foo のように行います。

new で作成してポインタ変数に代入する†

ヒープ領域にインスタンスを確保するには new を使います。 new した結果はポインタが返るので、ポインタが他の変数に値を保持します。

LANG:cpp
Vbin2bcd *top = new Vbin2bcd("top");

ポインタ変数がスコープを抜けても、 new で作成したインスタンスは自動的には削除されないので、 必要なくなった時点で delete を使って明示的に破棄する必要があります。

LANG:cpp
delete top;

コンストラクタに与えている "top" がインスタンス名になります。

この場合、インスタンスのメンバーへのアクセスは top->foo のように行います。

どちらがいい？†

上の例では自動変数としたほうが楽チンと思ってそうしてますが、 SystemC の世界でどちらが一般的かはまだこれから勉強するところです。

もしかするとモジュールインスタンスのサイズが大きくなる場合に備えて、 テストベンチではヒープに確保するほうが良いのかも知れません。 あまり大きな変数をスタックに取ると、スタックあふれが起きる可能性がありますので・・・

変数をヒープに取りつつ、delete のし忘れをなくすには、 std::auto_ptr なんかをうまく使うことになるんですかね。

クロック線について†

クロック線を簡単に定義するため、sc_clock というクラスが用意されています。

このインスタンスは、sc_signal<bool> と同じ１ビットの信号線ですが、 コンストラクタで指定された周期で自動的にクロックを刻みます。

LANG:cpp
sc_clock clk("clk", 10, SC_NS);

コンストラクタへの引数は、

• "clk" : クロックソースのインスタンス名
• 10 : クロック周期
• SC_NS : クロック周期の単位 (SC_NS は ns, SC_US は us を意味します)

となっています。

このほかにもオプションの引数を渡すことでデューティー比などを変更できるそうです。

注意点†

ちょっとだけ注意が必要なのは、 assign で定数が割り当てられた wire であっても、 その値は初めて sc_start が呼ばれるまで決定されないことです。

LANG:verilog
module test ( output wire [15:0] output_value );
    assign output_value = 1234;
endmodule // test

に対して、テストベンチを

LANG:cpp
#include "Vtest.h"

int sc_main(int argc, char **argv)
{
  Verilated::commandArgs(argc, argv);

  Vtest test("top");

  sc_signal<uint32_t> output_value;

  test.output_value(output_value);

  cout << "sc_start 前 : " << output_value << endl;
  sc_start(0, SC_NS);
  cout << "sc_start 後 : " << output_value << endl;

  exit(0);
}

とすると、結果は

LANG:console
             SystemC 2.2.0 --- Oct 29 2010 15:47:29
        Copyright (c) 1996-2006 by all Contributors
                    ALL RIGHTS RESERVED
sc_start 前 : 0
sc_start 後 : 1234

となります。

ヘッダファイルの慣用句†

#ifndef / #define / #endif は dff.h を多重インクルードしても 問題が起きないようにする慣用句です。

モジュールの宣言†

モジュールを表すクラスを宣言するには、SC_MODULE マクロを用います。

正確にはクラスではなく構造体 (struct) として宣言されるので、 デフォルトのアクセス指定子は public です。したがって、 わざわざ private を指定しない限り、宣言されたすべてのメンバーは 外からアクセス可能になります。

入出力ピンの定義†

入出力ピンの定義には、上で見た sc_signal の代わりに sc_in / sc_out / sc_inout を使います。

コンストラクタ†

モジュールのコンストラクタは SC_CTOR マクロを使って定義します。 コンストラクタでは下位モジュールなど、モジュールクラスのメンバーを初期化するとともに （ここでは初期化の必要なメンバーはありません）、 verilog における always 等を実現するためにイベントリストの構築を行います。

always を記述するには、

1. 中身をメンバ関数として定義し (上では assign() 関数)、
2. モジュールのコンストラクタにおいて
3. センシティビティリストと共に SC_METHOD マクロを使ってイベントリストに登録します

sensitive†

SC_METHOD の次にある sensitive がセンシティビティリストの定義です。

動作としては、sensitive に追加したイベントが起きると、 SC_METHOD で指定したメソッドが呼び出される、という仕掛けです。

上記のように .pos() や .neg() を付けたエッジ検出の他に、

LANG:cpp
sensitive << clk;

のように書けば、両エッジを検出することもできます。 また、

LANG:cpp
sensitive << sig1 << sig2.pos();

のように、複数個の信号を並べることができます。 あるいは、

LANG:cpp
sensitive << sig1;
sensitive << sig2.pos(); 

のように２つの分に分けて書いても同じ意味になります。

sensitive << clk としておいて、assign() の中で
if (clk.posedge()) dout = din; と書いても上記と同じ動作になるようですが、 メソッドが呼び出されてから判別するよりも、 始めから sensitive << clk.pos() とした方がシミュレーションは速くなると思います。

sensitive 指定は直前の SC_METHOD に対して有効なので、 １つのコンストラクタの中で複数の SC_METHOD とセンシティビティリストを 登録することができます。

LANG:cpp
SC_METHOD(method1);
  sensitive << sig1 << sig2.pos();
SC_METHOD(method2);
  sensitive << sig3;
  sensitive << sig4.pos();
SC_METHOD(method3);
  sensitive << sig5;

assign() の定義†

dff.cpp では、dff.h で宣言した assign() 関数を定義します。 （C/C++ では「宣言」と「定義」は専門用語として使い分けられていて、 実体を伴わずインターフェースだけを記述する「宣言」と、 実体を記述する「定義」という使い方になります。）

宣言(実体なし)：

LANG:cpp
void assign();

定義(実体あり)：

LANG:cpp
void dff::assign()
{ ... }

メンバー関数の定義では、その関数がどのクラスのメンバーであるかを指定するため、 関数名の前に :: で区切ってクラス名を記述します。

コメントの重要性†

気になるのは、上記のように .h と .cpp ファイルを分けてしまうと、 センシティビティリストとメソッド内容とが視覚的に離れてしまう点です。

あまり気は乗らないのですが、上記のように dff::assign() の定義付近にコメントとしてセンシティビティリストを 書いておくと、後から読みやすいかもしれません。 ( // sensitive << clk.pos() のコメント)

＃気が乗らない理由は、こういうコメントと、実際のコンストラクタ中の
＃記述とが食い違うと、非常に見つけにくいバグになってしまうためです。

assign() の定義をインラインで書いてしまう†

一方、C++ ではメンバ関数の宣言中に定義も書いてしまうこともできて、

dff.h

LANG:cpp
#ifndef __DFF_H
#define __DFF_H

#include "systemc.h"

SC_MODULE(dff) {
    sc_in <bool> clk;
    sc_in <bool> din;
    sc_out<bool> dout;
 
    // sensitive << clk.pos()
    void assign() {
       dout = din;
    }
 
    SC_CTOR(dff) {
        SC_METHOD(assign);
          sensitive << clk.pos();
    }

};

#endif // __DFF_H

これならセンシティビティリストと中身は少なくとも１つのファイルの中で見渡せます。 この場合、dff.cpp の中身は #include "dff.h" のみでOKです。

C++ の文法的には、これだと assign() 関数をインライン関数として宣言することになります。 実際には SC_METHOD で assign の関数ポインタを使うことになるので、 動作が食い違うのですが、g++ では問題なくコンパイルできるようでした。

ただ、この形だと、assign() 内を編集すると、 dff.h をインクルードするすべての .cpp ファイルをコンパイルしなおさなければなりません。 これは大きな負担となるため、 規模の大きなプロジェクトでは、やはりメソッド定義を .cpp に切り出しておくほうがよいのだと思います。

値の代入†

LANG:cpp
dout.write( din.read() );

の部分は、

LANG:cpp
dout = din;

と書いても同じ動作になるのですが、read / write を使う書き方が推奨されているそうです。

というのも、verilog と異なり C++ では通常 dout = din の形は変数内容の書き換えを表すもので、 信号線から信号線への値の受け渡しを想起しないためです。

ちょっと面倒なので、

LANG:cpp
dout.write( din );

でもいいように思うのですが、.read() の必要な理由は後で出てくるのかもしれません。

assign で書くには†

no_ff.v

LANG:verilog
module no_ff (
    input  wire din,
    output reg  dout
);
    assign dout = din;
endmodule

ならば、

no_ff.h

LANG:cpp
#ifndef __NO_FF_H
#define __NO_FF_H
#include "systemc.h"

SC_MODULE(no_ff) {
  sc_in <bool> din;
  sc_out<bool> dout;

  sc_signal<bool> din_copy;

  SC_CTOR(dff)
  {
    din(din_copy);
    dout(din_copy);
  }
};
#endif // __NO_FF_H

となるのでしょうか？

ちょっと面倒ですね。

LANG:cpp
dout(din);  // エラーになる

ではうまくいきませんでした。

コンパイル方法†

上記 SystemC コード dff.c をコンパイルしてオブジェクトファイル dff.o を得るには、

LANG:console
g++ -c -I$SYSTEMC/include dff.cpp

とします。

注意点†

最後に、C++ の初心者の方が１回ははまるミスとして、 SC_MODULE(dff) { }; のブロックの後ろにある ; を忘れてしまうというものがあります。

通常 C++ では } の後ろに ; が必要になることはそれほど多くなくて、 例外と言えるのが、この型定義の後の ; になります。

これは、SC_MODULE(dff) { } a_variable_of_dff_type; の形で、 dff 型の変数を定義できるという C++ の文法のせいなのですが、 この間違いは犯しやすいというだけでなく、 コンパイルエラーが出たときにその理由を探しにくいという点でも 犯罪的です。

どうなるかというと、dff.cpp で include された後のコードにおいて、 SC_MODULE(dff) { } void dff::assign() { } の形が現れるため、 エラーは dff.h ではなく dff.cpp の void dff::assign() の行に現れることになります。

LANG:console
$ g++ -c -I$SYSTEMC/include dff.cpp
dff.cpp:4: error: new types may not be defined in a return type
dff.cpp:4: note: (perhaps a semicolon is missing after the definition of ?dff?)
dff.cpp:4: error: two or more data types in declaration of ?assign?

あら、最近の g++ は親切ですね。ちゃんと dff の定義が悪いことを指摘してくれています。

インクルードファイルが複数あるときは、 次のインクルードファイルの先頭でエラーになったりもしますので、 その際は、直前のインクルードファイルの末尾を見直すという ひらめきが重要になります。