約 2,865,184 件
https://w.atwiki.jp/bambooflow/pages/135.html
クロックカウンタを作る ここでは、クロックカウンタを作成することで、モジュール作成、プロセスの作成等について説明する。 クロックカウンタを作るサンプル コンパイル/実行実行結果 モデル説明階層構造 クロックカウンタ・入出力信号 ソースコード内容ClcokCounter.h ClockCounter.cpp main.cpp サンプル clock_counter.tgz main.cpp ClockCounter.h ClockCounter.cpp Makefile コンパイル/実行 $ make == コンパイル $ ./run.x == シミュレーション実行 実行結果 SystemC 2.2.0 --- Jun 28 2008 10 19 12 Copyright (c) 1996-2006 by all Contributors ALL RIGHTS RESERVED Note VCD trace timescale unit is set by user to 1.000000e-09 sec. 0 s CntOut = 0 10 ns CntOut = 1 60 ns CntOut = 6 195 ns CntOut = 20 232 ns CntOut = 24 732 ns CntOut = 74 実行すると10nsごとにCntOutが1加算されている。 クロックは、10nsの周期となっている。 モデル説明 階層構造 sc_main |=== clockCounter(ClockCounter) クロックカウンタ・入出力信号 方向 型 信号名 説明 input bool clk クロック入力 output unsigned int CntOut クロックカウント値出力 ソースコード内容 ClcokCounter.h #ifndef __CLOCK_COUNTER_H #define __CLOCK_COUNTER_H #include systemc.h SC_MODULE( ClockCounter ) { //-- ports ----------------------------------------------------// sc_in_clk clk; sc_out unsigned int CntOut; //-- signals --------------------------------------------------// //-- variables ------------------------------------------------// //-- process functions ----------------------------------------// void main_thread(); //-- functions ------------------------------------------------// // constructor SC_HAS_PROCESS( ClockCounter ); ClockCounter( sc_module_name ); }; #endif /* __CLOCK_COUNTER_H */ "#include systemc.h "でSystemCライブラリのヘッダをインクルード SC_MODULEにてClockCounterモジュールを定義 クロック信号clkを入力ポートとして定義 クロックカウント値を出力するためのCntOut信号を出力ポートとして定義 プロセス間数となるmain_proc関数を定義 コンストラクタを定義プロセスを持つモジュールのためSC_HAS_PROCESSを定義 ClockCounter.cpp #include "ClockCounter.h" // constructor ClockCounter ClockCounter( sc_module_name name ) sc_module( name ) , clk( "clk" ) , CntOut( "CntOut" ) { // process setting SC_THREAD( main_thread ); //sensitive clk.pos(); } void ClockCounter main_thread() { unsigned int cnt = 0; CntOut.write( 0 ); while (true) { //wait(); wait( clk.posedge_event() ); ++cnt; CntOut.write( cnt ); } } コンストラクタ記述内SC_MODULEによりsc_moduleを継承するので、sc_moduleの初期化を記述 main_proc関数をSC_THREADに指定 プロセス関数main_proc記述内クロックカウント値を保持する変数cntを用意、初期値ゼロに設定 CntOut信号の出力を初期値ゼロに設定 無限ループ*while(true))を記述wait関数によりクロックの立上りを待つ カウント値のインクリメントしたらCntOutへ出力 main.cpp #include systemc.h #include "ClockCounter.h" int sc_main( int argc, char* argv[] ) { ClockCounter *clockCounter; // signals sc_clock clk( "clk", 10.0, SC_NS ); sc_signal unsigned int CntOut; // module instance binding clockCounter = new ClockCounter( "ClockCounter" ); sc_assert( clockCounter ); clockCounter- clk( clk ); clockCounter- CntOut( CntOut ); ///////////////////////////////////////////////////////////////////////// // vcd dump sc_trace_file *trace_f; trace_f = sc_create_vcd_trace_file( "systemc" ); // 出力フェイル名を指定する sc_assert( trace_f ); trace_f- set_time_unit( 1.0, SC_NS ); sc_trace( trace_f, clk, "clk" ); sc_trace( trace_f, CntOut, "CntOut" ); ///////////////////////////////////////////////////////////////////////// // initialize sc_start( SC_ZERO_TIME ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; // simulation sc_start( 10.0, SC_NS ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; sc_start( 50.0, SC_NS ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; sc_start( 135.0, SC_NS ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; sc_start( 37.0, SC_NS ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; sc_start( 500.0, SC_NS ); cout sc_time_stamp() " " "CntOut = " CntOut.read() endl; ///////////////////////////////////////////////////////////////////////// delete clockCounter; sc_close_vcd_trace_file( trace_f ); return 0; } systemc.hヘッダファイルをインクルード ClockCounter.hヘッダファイルをインクルード メイン関数としてsc_mainを使用 sc_clockによりクロックを作成、周期は10nsに設定 CntOut信号を受け取るsc_signalを用意 ClockCounterをインスタンスする clockCounterのclk,CntOut信号を接続 波形出力設定, ファイルはVCD形式,clk,CntOut信号を出力対象とする シミュレーション実行sc_start(SC_ZERO_TIME)ですべてのプロセスで最初のwaitまで実行 sc_start実行後、CntOut信号出力を表示、10nsごとに1カウント去れていることを確認
https://w.atwiki.jp/bambooflow/pages/65.html
SystemCコンパイルのためのGNU-Makefile書き方メモ 書き方なんてひとそれぞれですが、以外とMakefile書くのも面倒なのでメモ書きします． コンパイルするときは、ここからコピペで使用すればOK. SystemCコンパイルのためのGNU-Makefile書き方メモ単純なコンパイル方法 シンプルなMakefile Makefile.defsを利用するMakefile.defs Makefile 作業ディレクトリ構成 お気に入りMakefileメモ 単純なコンパイル方法 test.cpp1つをコンパイルする方法。 $ g++ -I/usr/local/systemc-2.2/include -c test.cpp $ g++ -I/usr/local/systemc-2.2/lib-linux -lsystemc -lm -o run.x test.o シンプルなMakefile メイクファイルは以下のように用意する。 CC = g++ SYSTEMC = /usr/local/systemc-2.1 INCDIR = -I. -I$(SYSTEMC)/include LIBDIR = -L. -L$(SYSTEMC)/lib-linux LIBS = -lsystemc -lm CFLAGS = -O2 -Wall TARGET = run.x SRCS = adder.cpp tb.cpp main.cpp OBJS = $(SRCS .cpp=.o) all $(TARGET) $(TARGET) $(OBJS) $(CC) -o $@ $(LIBDIR) $(LIBS) $(OBJS) .cpp.o $(CC) $(CFLAGS) $(INCDIR) -c $ clean @rm -f *.o $(TARGET) 環境等で変更が必要なのは、"SYSTEMC"のライブラリの場所指定と、"SRCS"のコンパイルするファイル指定の箇所。 Makefile.defsを利用する メイクファイルからMakefile.defsをインクルードして使う方法がある。 Makefile.defは展開したsystemc-2.2.0.tgzの以下にある。 systemc-2.2.0/examples/sysc/Makefile.defs これを利用すればメイクファイルの共通した記述を省略できる。 Makefile.defs Makefile.defsは以下のようになっている。 Makefile.defs SYSTEMC = /usr/local/systemc-2.2 INCDIR = -I. -I$(SYSTEMC)/include LIBDIR = -L. -L$(SYSTEMC)/lib-$(TARGET_ARCH) LIBS = -lsystemc -lm $(EXTRA_LIBS) EXE = $(MODULE).x .SUFFIXES .cc .cpp .o .x $(EXE) $(OBJS) $(SYSTEMC)/lib-$(TARGET_ARCH)/libsystemc.a $(CC) $(CFLAGS) $(INCDIR) $(LIBDIR) -o $@ $(OBJS) $(LIBS) 2 1 | c++filt .cpp.o $(CC) $(CFLAGS) $(INCDIR) -c $ .cc.o $(CC) $(CFLAGS) $(INCDIR) -c $ clean rm -f $(OBJS) *~ $(EXE) core ultraclean clean rm -f Makefile.deps Makefile.deps # $(CC) $(CFLAGS) $(INCDIR) -M $(SRCS) Makefile.deps #include Makefile.deps 環境等で変更が必要なのは、"SYSTEMC"のライブラリの場所指定。 Makefile 追加するメイクファイルは以下のようにする。 Makefile(例) CC = g++ CFLAGS = -Wall -g EXTRA_LIBS = -O2 TARGET_ARCH = linux # target name MODULE = run SRCS = test.cpp OBJS = $(SRCS .cc=.o) include ../Makefile.defs 作業ディレクトリ構成 作業ディレクトリは以下のようになる。 Sysc/ |-- Makefile.defs # 共通して使う |-- sample01 | |-- Makefile # sample01用に作成 | |-- test.cpp |-- sample02 | |-- Makefile # sample02用に作成 | |-- test.cpp `-- sample03 ・・・ お気に入りMakefileメモ とりあえず、コンパイルしたい場合は、下記のMakefileで十分かと。 make all を実行すると、$(wildcard *.cpp)によりmakeを実行したディレクトリ上の.cppファイルを探してコンパイルします。 コンパイルが完了すると、TARGET名であるrun.x実行ファイルができあがります。 オブジェクトファイル(.o)はobjsディレクトリに生成されるようにしました。 そのほうがすっきりするので。 ###################################################################### # SystemC Makefile ###################################################################### CXX = g++ TARGET = run.x OBJDIR = objs # coverage option #GCOV_OPT = -coverage # Source File SRCS = $(wildcard *.cpp) OBJS = $(SRCS .cpp=.o) OBJS = $(addprefix $(OBJDIR)/,$(OBJS)) ###################################################################### # SystemC setting SYSTEMC = /usr/local/systemc-2.2.0 SYSC_INC = -I. -I$(SYSTEMC)/include SYSC_LIB = -L. -L$(SYSTEMC)/lib-linux -lsystemc ###################################################################### # Compile option setting CXXFLAGS = -O2 -Wall CXXFLAGS += $(GCOV_OPT) CXXFLAGS += $(SYSC_INC) CXXLIBS = -lm CXXLIBS += $(SYSC_LIB) ###################################################################### # Compile setting all $(TARGET) $(TARGET) $(OBJS) $(CXX) $(GCOV_OPT) -o $@ $^ $(CXXLIBS) $(OBJDIR)/%.o %.cpp @[ -d $(OBJDIR) ] || mkdir -p $(OBJDIR) $(CXX) -c $(CXXFLAGS) -o $@ $ clean rm -f *~ $(OBJDIR)/*.o $(TARGET) 昔は、.cpp.o を使うようでしたが、最近では%.o %.cppを使うみたいです。 あと、カバレッジのオプションを付けてみました．(-coverage) 実行する際は、最適化オプション(-O)ははずしたほうがよいです。 古いコンパイラだとだと、-fprofile-arcs -ftest-coverageでしょうか。 gcov xxx.gcda 以上
https://w.atwiki.jp/bambooflow/pages/126.html
Visual C++ 2008 Express EditionへのSystemCライブラリ インストール Windows XPでのVisual C++ 2008 Expres EditionへのSystemCインストールをしてみた。 プロジェクトファイルは(バージョンは違うが)すでに用意されているのでそれを使う。 Visual C++ 2008 Express EditionへのSystemCライブラリ インストールSystemC2.2インストールフォルダ展開 プロジェクトファイル実行 プロジェクトファイルの設定・確認 コンパイル(ビルド) インストール 設定のまとめ SystemC2.2インストール フォルダ展開 C \にsystemc-2.2.0フォルダを展開。 プロジェクトファイル実行 C \systemc-2.2.0\mscv71\SystemCフォルダへ移動して、SystemC.vcprjをダブルクリック。 変換ウィザードが実行されるので、次へをクリック。 変換前にバックアップを作成するで、次へをクリック。 完了をクリック。 閉じるをクリック。 準備完了。 プロジェクトファイルの設定・確認 メニューのプロジェクトからプロパティを選択。 全般、構成の種類が"スタティック ライブラリ(.lib)"であることを確認。 出力ディレクトリ、中間ディレクトリは"Debug"であることを確認。 デバッグ、特に設定無し。 C/C++の全般、追加インクルードディレクトリの設定が"../../src"となっていることを確認。 64ビット移植への対応は"いいえ"であることを確認。 C/C++の最適化、特に設定無し。 最適化は今回、"無効(/Od)"としたが、最適化してもよい。 C/C++のプリプロセッサ、プロセッサの定義で"WIN32;_DEBUG;_LIB;SC_INCLUDE_FX"となっていることを確認。 C/C++のコード生成、簡易リビルドを行うは"いいえ"を選択。 ランタイムライブラリは"マルチスレッド デバッグ(/MTd)"であることを確認。 C/C++の言語、ランタイム型情報を有効にするは"はい"であることを確認。 C/C++のプリコンパイル済みヘッダー、プリコンパイル済みヘッダの作成/使用は"プリコンパイル済みヘッダーを使用しない"であることを確認。 C/C++の出力ファイル、特に設定無し。 C/C++のブラウザ情報、特に設定無し。 C/C++の詳細、指定の警告を無効にするは、"4224;4996"と変更。(しなくてもコンパイルはできるが警告メッセージがうるさい) C/C++のコマンド ライン、設定が正しいかどうか、もう一度確認。 ライブラリアンの全般、出力ファイルが"$(OutDir)/SystemC.lib"となっていることを確認。 コンパイル(ビルド) メニューのビルドからソリューションのビルドを選択して、コンパイル開始。( F7 でもOK) コンパイルが正常に終了したことを確認。 C \systemc-2.2.0\mvc71\SystemC\Debugフォルダ下にSystemC.libが生成されていることを確認。 これで、コンパイル完了。 今回は、とりあえずSystemCが実行できればいいかな程度の設定。 最適化とかはおこのみで。 インストール 設定のまとめ 以下のプロパティ設定を確認する。 全般、構成の種類が"スタティック ライブラリ(.lib)"であることを確認。 出力ディレクトリ、中間ディレクトリは"Debug"であることを確認。 C/C++の全般、追加インクルードディレクトリの設定が"../../src"となっていることを確認。 C/C++のプリプロセッサ、プロセッサの定義で"WIN32;_DEBUG;_LIB;SC_INCLUDE_FX"となっていることを確認。 C/C++のコード生成、簡易リビルドを行うは"いいえ"を選択。 C/C++のコード生成、ランタイムライブラリは"マルチスレッド デバッグ(/MTd)"であることを確認。 C/C++の言語、ランタイム型情報を有効にするは"はい"であることを確認。 C/C++の詳細、指定の警告を無効にするは、"4224;4996"と変更。(しなくてもコンパイルはできるが警告メッセージがうるさい) ライブラリアンの全般、出力ファイルが"$(OutDir)/SystemC.lib"となっていることを確認。 テストプログラム、HelloWorldのコンパイル・実行へ
https://w.atwiki.jp/bambooflow/pages/121.html
SystemCの抽象度(抽象レベル) SystemCの抽象度(抽象レベル)TLM標準化団体ごとの抽象レベル定義OSCIが提唱する抽象レベル OCP-IPが提唱する抽象レベル GreenSocsが提唱する抽象レベル STARCが提唱する抽象レベル その他の抽象レベル TLM標準化団体ごとの抽象レベル定義 OSCIが提唱する抽象レベル PV(Programmers View) PVT(Programmers View with Timing) CC(Cycle Callable) OCP-IPが提唱する抽象レベル OCP/TL3(OCP Transaction Level 3) OCP/TL2(OCP Transaction Level 2) OCP/TL1(OCP Transaction Level 1) OCP/TL0(OCP Transaction Level 0) GreenSocsが提唱する抽象レベル PV(Programmers View) PVT(Programmers View with Timing) CC(Cycle Callable) RTL(Register Transfer Level) STARCが提唱する抽象レベル UTTR(Un-timed Transaction) ATTR(Approximately-timed Transaction) ATBP(Approxymately-timed Bus-Phase) CABC(Cycle-accurate Bus-Cycle) CABS(Cycle-accurate Bus-Signal) データの粒度とタイミング精度から抽象レベルを分類する。 その他の抽象レベル UTF(Untimed Functional)モデル TF(Timed Functional)モデル BCA(Bus Cycle Accurate)モデル CA(Cycle Accurate)モデル
https://w.atwiki.jp/bambooflow/pages/166.html
SystemCのレポート処理 SystemCのレポート処理レポート使いかた１ー簡単な例 レポート使いかた２ー練習用すべてのメッセージを画面出力させたくないとき リファレンスsc_report_handlersc_actions sc_report メッセージの分類(レベル)一覧 メッセージ動作一覧デフォルトの動作 メッセージ表示用マクロ その他 SystemCのV2.1からレポート出力処理を簡単に制御するためのエラーレポートシステムが標準化されています。 エラーメッセージやトラッキングレポートなど発生元の特定し、デバッグを容易にすることは不可欠です。 メッセージには、Information、Warning、Error、Fatalの4つの種類があるようです。 この4つのメッセージについて出力方法を指定したり、動作を指定したりすることができます。 画面出力やログ出力を簡単に切り替えることができます。 簡単にメモ書きを残します。 レポート使いかた１ー簡単な例 以下に簡単な例を紹介。 サンプル #include systemc.h const char* sim_name = "test"; // メッセージID名 int sc_main( int argc, char* argv[] ) { sc_report_handler set_log_file_name("sample_run.log"); // ログファイル設定 sc_report_handler stop_after( SC_ERROR, 100 ); // シミュレーション終了指定 sc_report_handler set_actions( sim_name, SC_INFO, SC_DISPLAY | SC_LOG ); // 動作指定 SC_REPORT_INFO( sim_name, "sample report1" ); sc_start( 100, SC_NS ); SC_REPORT_INFO( sim_name, "sample report2" ); return 0; } set_log_file_nameはメッセージを出力するレポートファイル名を指定します。 どこで、そのメッセージが出力されているかのグループ分けのために使用します。 とりあえずはファイル名やモジュール名等を指定するとよいかもしれません。 stop_afterはレポート情報の回数からシミュレーションを停止するタイミングを指定することができます。stop_after( SC_ERROR, 100 )は「ERROR(エラー)」レベルのメッセージの数(SC_REPORT_ERRORの実行回数)が100回となったらシミュレーションを停止させます。ゼロに設定するとdisableです。 今回のサンプルでは意味ないです。 set_actionsはメッセージ処理に対する動作を設定することができます。et_actions( sim_name, SC_INFO, SC_DISPLAY | SC_LOG )は、「INFO(情報)」レベルのメッセージを画面出力とファイル出力に設定しています。 画面表示 Info test sample report1 Info test sample report2 標準出力(std cout)にレポートを出力するにはset_actionsでSC_DISPLAYを設定します。 レポートファイル出力(sample_run.log) 0 s Info test sample report2 100 ns Info test sample report2 ファイルに出力するには、set_log_file_nameにて出力ファイル名を設定して、かつ、set_actionsにてSC_LOGを設定します。 ファイルへの出力には経過時間も記録されるみたいです。 デフォルトの動作はすべてのメッセージレベルはログ出力となっているので、ログファイル指定するだけで出力されるはずです。 レポート使いかた２ー練習用 いろいろ試してみました。 以下にサンプルコードを載せます。実際に使うときはもっときれいに書きたいものです。 このサンプルは、レポート処理の動作を見るために作ったものです。 モジュールはMOD1とMOD2があります。 モジュールはそれぞれスレッドを持っていて、定期的にメッセージを出力させています。 メッセージの制御は、sc_mainで行います。 はじめの状態は、単にデフォルト設定のままで、ログファイル("sample_run.log")出力するだけです。 コメントアウトされているsc_actionsやsc_stop_afterを有効にすることでメッセージ制御が行えます。 サンプルコード(sample_report02.cpp) #include systemc.h const char* id_name1 = "ID_1"; const char* id_name2 = "ID_2"; SC_MODULE( MOD1 ) { SC_CTOR( MOD1 ) { SC_THREAD( thread ); } void thread() { int cnt = 0; while (true) { ++cnt; wait( 10, SC_NS ); if (cnt%80==0) SC_REPORT_FATAL( id_name1, "sample Fatal1" ); else if (cnt%50==0) SC_REPORT_ERROR( id_name1, "sample Error1" ); else if (cnt%30==0) SC_REPORT_WARNING( id_name1, "sample Warning1" ); else if (cnt%10==0) SC_REPORT_INFO( id_name1, "sample Info1" ); } } }; SC_MODULE( MOD2 ) { SC_CTOR( MOD2 ) { SC_THREAD( thread ); } void thread() { int cnt = 0; while (true) { ++cnt; wait( 15, SC_NS ); if (cnt%100==0) SC_REPORT_FATAL( id_name2, "sample Fatal1" ); else if (cnt%70==0) SC_REPORT_ERROR( id_name2, "sample Error1" ); else if (cnt%40==0) SC_REPORT_WARNING( id_name2, "sample Warning1" ); else if (cnt%20==0) SC_REPORT_INFO( id_name2, "sample Info1" ); } } }; int sc_main( int argc, char* argv[] ) { MOD1 mod1("mod1"); MOD2 mod2("mod2"); // 以下、メッセージの制御 sc_report_handler set_log_file_name("sample_run.log"); //sc_report_handler set_actions( SC_ERROR, SC_DISPLAY | SC_LOG | SC_CACHE_REPORT ); //sc_report_handler set_actions( SC_FATAL, SC_DISPLAY | SC_LOG | SC_CACHE_REPORT ); //sc_report_handler suppress( SC_THROW ); //sc_report_handler stop_after( SC_FATAL, 10 ); //sc_report_handler set_actions( SC_INFO, SC_DISPLAY | SC_LOG ); //sc_report_handler stop_after( SC_FATAL, 10 ); //sc_report_handler stop_after( SC_ERROR, 10 ); //sc_report_handler set_actions( id_name1, SC_WARNING, SC_LOG | SC_CACHE_REPORT ); // シミュレーション実行 sc_start( 1., SC_MS ); // シミュレーション終了後の処理 cout endl; cout " ****** end-time = " sc_time_stamp() " ******" endl; cout endl; sc_report *rp = sc_report_handler get_cached_report(); if (rp) { cout "--- Cache Messgage ---" endl; cout rp- get_msg() endl; cout "--- Cache Messgage end ---" endl; } cout endl; cout "--- " id_name1 " ---" endl; cout " Info count = " sc_report_handler get_count( id_name1, SC_INFO ) endl; cout " Warning count = " sc_report_handler get_count( id_name1, SC_WARNING ) endl; cout " Error count = " sc_report_handler get_count( id_name1, SC_ERROR ) endl; cout " Fatal count = " sc_report_handler get_count( id_name1, SC_FATAL ) endl; cout "--- " id_name2 " ---" endl; cout " Info count = " sc_report_handler get_count( id_name2, SC_INFO ) endl; cout " Warning count = " sc_report_handler get_count( id_name2, SC_WARNING ) endl; cout " Error count = " sc_report_handler get_count( id_name2, SC_ERROR ) endl; cout " Fatal count = " sc_report_handler get_count( id_name2, SC_FATAL ) endl; cout "--- TOTAL ---" endl; cout " Info count = " sc_report_handler get_count( SC_INFO ) endl; cout " Warning count = " sc_report_handler get_count( SC_WARNING ) endl; cout " Error count = " sc_report_handler get_count( SC_ERROR ) endl; cout " Fatal count = " sc_report_handler get_count( SC_FATAL ) endl; return 0; } 画面出力例 ・・・ Error ID_1 sample Error1 In file report_sample02.cpp 15 In process mod1.thread @ 500 ns ****** end-time = 500 ns ****** --- Cache Messgage --- sample Error1 --- Cache Messgage end --- --- ID_1 --- Info count = 3 Warning count = 1 Error count = 1 Fatal count = 0 --- ID_2 --- Info count = 1 Warning count = 0 Error count = 0 Fatal count = 0 --- TOTAL --- Info count = 4 Warning count = 1 Error count = 1 Fatal count = 0 デフォルトのレポートの動作では、エラーメッセージが表示されると、throwへとばされて、シミュレーションが終了してしまいます。 通常ならば、エラーが出力された時点でシミュレーションが止まっても問題ないと思いますが、継続して実行したい場合もあります。 その時は、以下のような設定をします。 sc_report_handler set_actions( SC_ERROR, SC_DISPLAY | SC_LOG | SC_CACHE_REPORT ); // SC_THROWをはずす SC_ERRORの動作をデフォルト設定から上書きします。 ためしに設定を有効にして実行してみます。 実行結果 ・・・ Fatal ID_1 sample Fatal1 In file report_sample02.cpp 15 In process mod1.thread @ 800 ns アボートしました 今度は、Fatalメッセージが出力されると同時に、アボートしてしまいました。 これは、Fatalのデフォルト設定にSC_ABORTが設定されているためです。 先ほどのERROR同様に、SC_ABORTをはずして設定を上書きすれば止まらなくなります。 sc_report_handler set_actions( SC_ERROR, SC_DISPLAY | SC_LOG | SC_CACHE_REPORT ); // SC_ABORTをはずす 設定して、実行するとシミュレーションは1ms(sc_startに設定した時間)経過して止まると思います。 今度は、FATALメッセージが10回表示されたら、シミュレーションを終了するようにします。 設定は以下を追加します。 sc_report_handler stop_after( SC_FATAL, 10 ); 設定して実行すると、TOTALのFatal count値が10でシミュレーションが終了すると思います。 stop_afterは、IDを指定することもできます。 sc_report_handler stop_after( id_name2, SC_FATAL, 10 ); // id_name2="ID_2" 上記の設定にして実行すると、ID_2のFATALメッセージが10回表示された時点でシミュレーションが終了すると思います。 すべてのメッセージを画面出力させたくないとき すべてのメッセージを画面出力させたくないときは、以下を設定します。 sc_report_handler suppress( SC_DISPLAY ); 解除するときは、suppress()を実行すればよいようです。 逆に強制的に画面出力させるときは、force( SC_DISPLAY )とすればよいようです。 リファレンス sc_report_handler 次を参照してください。 sc_report_handler sc_actions メッセージに対して動作を指定することができます。 static sc_actions set_actions( sc_severity, sc_actions = SC_UNSPECIFIED ); メッセージレベルごとに動作を指定します。 static sc_actions set_actions( const char* msg_type, sc_actions = SC_UNSPECIFIED ); IDごとに動作を指定します。 static sc_actions set_actions( const char* msg_type, sc_severity, sc_actions = SC_UNSPECIFIED ); メッセージレベルとIDごとに動作を指定します。 sc_report 次を参照してください。 sc_report メッセージの分類(レベル)一覧 メッセージには以下のような種類があります。 sc_severity SC_INFO 情報出力 SC_WARNING 警告、問題かもしれないことを知らせる SC_ERROR 重大な問題 SC_FATAL 致命的な問題、デフォルトではシミュレーションを終了 メッセージ動作一覧 メッセージのレベルごとに動作を指定することができます。 enum SC_UNSPECIFIED SC_DO_NOTHING 何もしない SC_THROW レポートとの内容に対応するC++の例外を発生。 SC_LOG レポートをログに出力する。通常はディスク上のファイルへ出力。 SC_DISPLAY レポートを画面出。 SC_INTERRUPT シミュレーションを一時停止。sc_interrupt_hereをよぶ。 SC_CACHE_REPORT レポートのコピーを保存。get_cached_repot()より後に取得できる。 SC_STOP sc_stop()をよぶ。 SC_ABORT sc_abort()をよぶ。 デフォルトの動作 デフォルトの動作は次のように設定されているようです。 SC_DEFAULT_INFO_ACTIONS (SC_LOG | SC_DISPLAY) SC_DEFAULT_WARNING_ACTIONS (SC_LOG | SC_DISPLAY) SC_DEFAULT_ERROR_ACTIONS (SC_LOG | SC_CACHE_REPORT | SC_THROW) SC_DEFAULT_FATAL_ACTIONS (SC_LOG | SC_DISPLAY | SC_CACHE_REPORT | SC_ABORT) 全てのメッセージは(ログファイル名が設定されていれば)ファイル出力します。 FATAL時、シミュレーションはアボートします。 メッセージ表示用マクロ SC_REPORT_INFO(id,msg) 情報メッセージに使用 SC_REPORT_WARNING(id,msg) ワーニングメッセージに使用 SC_REPORT_ERROR(id,msg) エラーメッセージに使用 SC_REPORT_FATAL(id,msg) 致命的エラーメッセージに使用 sc_assert(expr) アサート、assertのかわりに使用 sc_assertは以下のようにdefine定義されています。 #define sc_assert(expr) \ ((void) ((expr) ? 0 (SC_REPORT_FATAL( SC_ID_ASSERTION_FAILED_ , #expr ), 0))) その他 SystemCのログファイルからVCDファイルを生成するツールを作ってみました。 てきとうなので、うまくうごかなかったらごめんなさい。 sysclog2vcd.pl 使いかた % ./sysclog2vcd.pl ログファイル名 % gtkwave sysclog.vcd 以上
https://w.atwiki.jp/bambooflow/pages/168.html
イベント イベント(sc_event)はスレッド間の同期をとるために非常に役立ちます。 ここでは、イベント(sc_event)の使い方についてメモします。 イベント sc_eventの使い方簡単なsc_event使用例 2つのスレッドがお互いに同期をとる記述例 誤った使い方 まとめ リファレンス sc_eventの使い方 簡単なsc_event使用例 以下にもっとも簡単なsc_eventの使い方を記述します。 #include systemc.h SC_MODULE( TOP ) { sc_event e0; // イベント準備 SC_CTOR( TOP ) { SC_THREAD( thread0 ); SC_THREAD( thread1 ); } // イベントを通知するスレッド void thread0() { cout "--- thread0 start ---" endl; while (true) { wait( 10, SC_NS ); e0.notify(); // イベント通知 } } // イベントを受け取るスレッド void thread1() { cout "--- thread1 start ---" endl; while (true) { wait( e0 ); // イベント待ち cout sc_time_stamp() " thread1" endl; } } }; int sc_main( int argc, char* argv[] ) { TOP top( "top" ); sc_start( 100, SC_NS ); return 0; } 実行結果 --- thread0 start --- --- thread1 start --- 10 ns thread1 20 ns thread1 30 ns thread1 40 ns thread1 50 ns thread1 60 ns thread1 70 ns thread1 80 ns thread1 90 ns thread1 とりあえずsc_eventの動作確認するだけなので、なんの面白みもないです。 あえて言うなら、こんな処理で2つスレッドを用意するのは無駄です。 説明のためにあえて2つのスレッドを用意しました。 イベントの用途は、基本はプロセス間の同期です。 記述を見ていきます。 まず、TOPモジュールのメンバ変数として、イベントe0を用意しています。 sc_evnet e0; thread0とthread1はSC_THREAD指定してwhile(true)文により無限ループとなっています。 thread0では、イベントを通知(発行)しています。 e0.notify(); thread1では、イベントを待っています。 wait( e0 ); イベントを受け取ると、ウェイト状態が解除され、waitの後述部分が処理されます。 後述は、ここでは単に標準出力(cout)させてます。 ようは、thread1の動作開始をthread0から操作しているようなイメージです。 今回はnotify()の引数はなにも与えていませんが、時間を指定することもできます。 たとえば、次のように記述できます。 e0.notify( 5, SC_NS ); このように記述すると、notifyが実行されてから5[ns]後にイベントが通知されることになります。 注意 プロセス間のタイミングを取るために通常の変数(boolやint)を使うのは誤りです。 プロセス間のタイミングでは、必ずsc_eventもしくはチャネル(sc_signal やsc_buffer )を使わないといけません。 そうしないと、シミュレーション誤動作の原因となります。 2つのスレッドがお互いに同期をとる記述例 #include systemc.h SC_MODULE( TOP ) { sc_event e0; // イベント宣言 sc_event e1; // イベント宣言 SC_CTOR( TOP ) { SC_THREAD( thread0 ); SC_THREAD( thread1 ); } void thread0() { cout "--- thread0 start ---" endl; wait( SC_ZERO_TIME ); while (true) { e0.notify(); // イベント通知 wait( e1 ); // イベントを待つ cout sc_time_stamp() " thread0" endl; wait( 10, SC_NS ); } } void thread1() { cout "--- thread1 start ---" endl; while (true) { wait( e0 ); // イベントを待つ cout sc_time_stamp() " thread1" endl; wait( 10, SC_NS ); e1.notify(); // イベント通知 } } }; int sc_main( int argc, char* argv[] ) { TOP top( "top" ); sc_start( 100, SC_NS ); return 0; } 実行結果 --- thread0 start --- --- thread1 start --- 0 s thread1 10 ns thread0 20 ns thread1 30 ns thread0 40 ns thread1 50 ns thread0 60 ns thread1 70 ns thread0 80 ns thread1 90 ns thread0 実行結果をみると、thread0とthread1が交互に動作していることがわかります。 thread0は、イベント通知→イベント待ち→標準出力→wait(10ns)、 thread1は、イベント待ち→標準出力→wait(10ns)→イベント通知、 の順番となっています。 ここで、1点注目してほしいのは、thread0のwhile(true)文の前で、waitを1回呼んでいることです。 wait( SC_ZERO_TIME ); これは、必要です。 なぜならば、イベントの発生を知るためにはそのイベントを常に監視していなければならない、というルールがあるからです。 もし、このwait記述がないと正しく動作してくれません。でも動作することもあります。あいまいです。 それは、最初の動作時にthread0のe0.notify()とthread1のwait(e0)のどちらが先に実行されるかがあいまいだからです。 thread1のwait(e0)が先に実行されれば所望の動作しますが、thread0のe0.notify()が先に実行されてしまうと、イベント発行を見逃してしまうことになります。 誤った使い方 1つのスレッド内で使おうとした例 次の記述は明らかに誤りです。 SC_MODULE( TOP ) { sc_event m_evnt; SC_CTOR( TOP ) { SC_THREAD( thread0 ); } void thread0 { while (true) { m_evnt.notify(); /* ... */ wait( m_evnt ); } } }; m_evnt.notify()にてイベントを発行していますが、それを受けるwaitの位置がおかしいです。 本来であれば別プロセスにwaitを用意しなければいけません。 まとめ イベントは、2つのプロセスの同期をとるためのもの。 ルールとして、イベントは常に監視しなければ、イベント発行を見逃してしまう。 リファレンス sc_evnet
https://w.atwiki.jp/bambooflow/pages/62.html
ビットアクセス ビット結合 4ビット幅の変数を4つ結合する場合 sc_uint 4 a, b, c, d; sc_uint 16 z; z = ( a, b, c, d ); ビット選択 16ビット幅のを4ビットごと分割する例 sc_uint 16 a; sc_uint 4 w, x, y, z; w = a.range( 15, 12 ); x = a.range( 11, 8 ); y = a.range( 7, 4 ); z = a.range( 3, 0 ); または、 sc_uint 16 a; sc_uint 4 w, x, y, z; ( w, x, y, z ) = a; 1ビット拡張 SystemCでビット拡張はない？みたいなので、ちょっと亜流な例 sc_uint 1 flg; sc_uint 16 z, a; z = a ^ (sc_uint 16 )( (sc_int 1 )flg );
https://w.atwiki.jp/bambooflow/pages/169.html
インドのCircuitSutra、STARC「TLモデリングガイド」準拠のデモモデルをWebで公開、したらしい -- (管理者) 2009-04-23 06 46 46 OSCI TLM 2.0のSystemC TLMキットを米OCP-IPが提供開始、らしい -- (管理者) 2009-05-05 08 40 52 OSCI本家に”TLM-2.0 in Action”がアップされた。 -- (管理者) 2009-05-07 23 46 46 Cadence IES8.2がTLM2.0に対応。 -- (管理者) 2009-05-28 07 16 19 SystemC Japan 2009は2009年7月10日。 -- (管理者) 2009-05-28 07 17 30
https://w.atwiki.jp/bambooflow/pages/132.html
SystemC Visual C++ Express Edition Visual C++ Express Editionでの実行の仕方とかをここにメモ書きとしてまとめる。 HelloWorldインストール
https://w.atwiki.jp/systemc/pages/15.html
systemc-amsのインストール SystemC-amsには、1.0.1と2.0 Betaがある。Fraunhoferのホームページでダウンロードできる。 g++-4.9でコンパイルするにあたって、特にソースコードを編集する必要はない。SystemC-2.3.1との組み合わせで問題なく動作する。 64ビットCPU上のcygwinで使用する場合は、SystemC-2.3.1のインストール時にアーキテクチャをcygwin64と認識するのに対し、amsのcygwinへのインストールでは32ビットと64ビットを区別しないので、下記の修正をconfigure.acに行うと良い。 TARGET_ARCH="cygwin" EXTRA_CXXFLAGS="-I$SYSC_INC_PREFIX" と書かれている行を case "$target_cpu" in x86_64 | amd64) TARGET_ARCH="cygwin64" EXTRA_CXXFLAGS="-I$SYSC_INC_PREFIX -m64" ;; i*86) TARGET_ARCH="cygwin" EXTRA_CXXFLAGS="-I$SYSC_INC_PREFIX" ;; *) AC_MSG_ERROR("sorry... compiler not supported.") ;; esac に置き換える。 （2012年の記述） Fraunhoferのホームページからダウンロードしてきたsystemc-ams-1.0BETA2.tgzを展開する。 tar xvfz systemc-ams-1.0BETA2.tgz 展開されたsystemc-ams-1.0BETA1ディレクトリへ移動する。 cd systemc-ams-1.0BETA2 自分の環境に合わせて環境変数を設定する。 export SYSTEMC_HOME=/usr/local/systemc-2.2 g++-4.3を使用する場合は、configure.acファイルの中の EXTRA_CXXFLAGS="-I$SYSC_INC_PREFIX" と書かれたすべての行あるいは自分の使用するターゲットの行を EXTRA_CXXFLAGS="-isystem $SYSC_INC_PREFIX" に置き換える。 コンパイル環境を構築する。 ./configure コンパイルを行う。 make ライブラリを作成する。 make install 2015-05-06 20 40 19 (Wed) -