SystemCとNSL

OSCIの標準コンパイラ（というよりクラスライブラリ）が無料で使えるので、ソフトウェアとの連携があるverificationでは、SystemCはよい選択肢の一つです。
ただ、残念な言語仕様のおかげで、これを０から書くのはハードウェア設計者にはとても大変です。
VerificationにおけるSystemCの便利さをハードウェア設計者に「簡単に」提供したいと思って、NSLは、SystemCへの合成をサポートしています。
今日は、しっかりと時間を取って、家に引きこもり、SystemCを意識させないで、SystemCを用いるVerficationのパッケージを作っていました。

このパッケージを含むLiveCygwinはIP ARCHからダウンロードできます。

実は、パッケージ作成しながら、いろいろと合成されるSystemCの記述も調整したので、この方法をサポートするNSL COREは、20110305版以降となります。（上記、LiveCygwinには導入済み）

たとえば、このパッケージの中の一つの例題ですが、下のようなNSLコードを tut2.nslという名前で用意します。

パッケージにはMakefileが入っているので、

make T=tut2 scsim

とすると、NSLをコンパイルし、SystemCに変換したものをコンパイルしてくれます。
これを、
./tut2_sim 10000
として、10μSまでシミュレーションすると、

Hello World: value = 100, count = 100
count = 101
count = 102
bye: count = 103
SystemC: simulation stopped by user.

となります。たったこれだけです。
同じようなことを行う合成可能なハードをSystemCで記述しようとすると、とっても大変で、お勧めしません。もちろん、_display なんてのは合成対象ではありませんが、NSLの記述はハードウェアの裏づけを持ったシーケンス回路を生成しているので、1クロックずつ仕事をするようなハードウェアを書くのは、この例題とほとんど同じ記述で可能です。

魔法はMakefileの中にあるというのもあんまりなんで、少し種明かし。

Makefileでは、nsl2scの呼び出しとg++の呼び出しを行っています。
nsl2scでNSLをSystemCに変換し、それをg++でコンパイルしているというわけです。
OSCIで要求されるsc_mainもnsl2scが自動生成していますので、凝ったことをしたければ、自動生成したSystemCのメインルーチンに手を入れることができます。
ここで示したような、テキストベースのシミュレーションでは、メインルーチンを見る必要もないはずです。

Makefileを使わずに、自助努力をしようとすると、長いおまじないが必要です。
今回は、次のようにコンパイルしています。

nsl2sc tut2.nsl -scsim2 -target tut2 -split
g++ -I/usr/local/systemc-2.2.0/include -L/usr/local/systemc-2.2.0/lib-cygwin tut2_sim.cpp -lsystemc -o tut2_sim.exe


今回の例題NSLは、次のコードです。

declare tut2 simulation { }



module tut2 {

    reg count[8] = 0;

    wire value[8];

    func_self  start(value);



    count++;

    if(count==100) start(count);



    func start seq {

        _display("Hello World: value = %d, count = %d", value, count);

        _display("count = %d", count);

        _display("count = %d", count);

        _finish("bye: count = %d", count);

    }

}