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);
}
}
