約 4,756,368 件
https://w.atwiki.jp/systemc/pages/20.html
SystemC-AMSの紹介 SystemC-AMSは、Embedded Analog/Mixed-Signal(E-AMS) systemを取り扱う。デジタルの領域を扱うSystemCにアナログの領域を扱う手段を追加している。次のような目的で使われることを想定している。 実行可能仕様書 (Executable specification) 仮想試作 (Virtual prototyping) アーキテクチャ探索 (Architecture exploration) 実装検証 (Integration validation) SystemC-AMSのアナログシステムのモデル化の方法には次の3通りが用意されている。 Timed Data Flow (TDF) 離散時間の非線形な表現が可能。時間軸と周波数軸の処理を別々に定義する。 Linear Signal Flow (LSF) 連続時間の線形な数式を扱う。 Electrical Linear Network (ELN) 線形なふるまいをする部品（抵抗、コンデンサ、コイルなど）で回路を表現する。 TDFのモジュールはユーザが定義するが、LSFとELNでは用意されたモジュールを利用する前提になっている。これらのモジュールを含む上位階層はsc_moduleである。時間軸解析と小信号(周波数)解析を行うことができる。SPICEのような非線形解析はできない。 SystemC-AMS名前空間 TDFのモジュール LSFのモジュール ELNのモジュール 小信号(周波数)解析 時間軸解析 2012-02-15 18 47 06 (Wed) -
https://w.atwiki.jp/systemc/pages/27.html
高位合成 高位合成の定義は、学会でも業界でもきちんと定まっていないように思える。ここでは、高位合成（High Level Synthesis）は、RTL（Register Transfer Level）からの論理合成よりも抽象度の高い記述から自動的に論理回路を生成することと定義する。 入力がC言語などのプログラム言語であっても、HDL（Hardware Discription Language）で表現できるような内容のものしか受け付けないものが高位合成として市販されている場合もあるので、ユーザとしてはツールの機能をしっかり確認する必要がある。 動作合成 また、高位合成と同様な場面で使われる動作合成（Behavioral Synthesis）を、データパスに対するスケジューリングとリソースシェアリング（複雑な演算を時分割して演算器とレジスタを共用する）を自動生成する機能と定義する。 SystemCの高位合成ツールに望まれる機能 SystemCを用いた高位合成には、下記の機能が望まれる。 動作合成 インタフェース合成 関数型かオブジェクト指向による表現の抽象化 並列処理、処理タイミング、モジュール化、外部端子を表現する手段 高位の記述とは データパスの記述であれば、スケジューリングとリソースシェアリングを行う前の動作合成される記述が高位合成用の記述と考えられる。高位合成の価値はそれだけではないので、データパスのない制御系の記述で考えてみる。 汎用性の高い記述 動作の目的を明確にする。具体的な実装については、別の場所で定義する。 信号で進めと合図する。 signal.show(sign_go); 具体的な記述 動作を表現する。しかし、これでもまだ具体的な実装については、別の場所で定義する。 信号を青にする。 signal.set(color_blue); 詳細な記述 実装をそのまま記述する。ここまで記述するのであれば、高位合成は必要ない。 信号の青色灯を点灯する。黄色灯と赤色灯を消す。 signal.blue = true; signal.yellow = false; signal.red = false; 参考 動作合成 http //techon.nikkeibp.co.jp/article/WORD/20090107/163727/ SystemC推奨設計メソドロジ 合成編 http //jeita-edatc.com/users_lib/SystemC_DM_for_synthesis_080428.pdf SystemC Synthesizable Subset 1.3 draft Synthesis Working Group of Open SystemC Initiative 2014-02-11 13 14 07 (Tue) -
https://w.atwiki.jp/systemc/pages/16.html
SystemCのコンパイルを試す。 下記の記述がhello.cppにあるとすれば、 #include systemc using namespace sc_core; using namespace sc_dt; using namespace std; int sc_main(int argc, char **argv){ cout "Hello" endl; return 0; } g++ -o hello.x hello.cpp -I/usr/local/systemc-2.2/include -L/usr/local/systemc-2.2/lib-linux -lsystemc のようにコンパイルすることで、実行ファイルhello.xを作成することができる。/usr/local/systemc-2.2の部分は、SystemCをインストールしたディレクトリを記述する。lib-linuxの記述は、OSに合わせて変更する。 無事エラーなく作成できたら ./hello.xで実行しよう。 Hello と表示される。 SystemCのライブラリを使用するときに読み込むヘッダファイルは、systemcである。名前空間はsc_coreとsc_dtの2つが用意されている。dtは、data typeの略と思われ、sc_intなどのSystemCのデータ型が定義されている。SystemCのライブラリ中でmain()文が定義されているので、SystemCの記述はそのmain()文から呼び出されるsc_main()が最上位の記述となる。
https://w.atwiki.jp/systemc/pages/12.html
SystemC-2.3.1のインストール Accelleraのホームページからダウンロードする。特に修正しなくてもg++-4.9でコンパイル可能。修正以外の手順は2.2.0と同じ。 cygwin用は、configureするときに --enable-pthreadsのオプションが必要。 g++-4でのSystemC-2.2.0のインストール g++-4.9でコンパイルしようとするとエラーになる。エラー箇所（src/sysc/datatypes/bit/sc_bit_proxies.h）のmutableを消すとコンパイル可能ではあるが、他のバグもあるようなので、SystemC-2.3.1を使用するのがお勧め。 （ここから、2012年の記述） OSCIのホームページからダウンロードしてきたsystemc-2.2.0.tgzを展開する。 tar xvfz systemc-2.2.0.tgz 展開されたsystemc-2.2.0ディレクトリへ移動する。 cd systemc-2.2.0 src/sysc/utils/sc_utils_ids.cppの62行目に次の2行を加える。 #include cstdlib #include cstring src/sysc/kernel/sc_constants.hの中のSC_DEFAULT_STACK_SIZEは大きくした方が良い。0x50000くらいがお勧め。 作業用のobjdirディレクトリを作成する。 mkdir objdir objdirディレクトリへ移動する。 cd objdir CXX環境変数を設定した方が良いかもしれない。 export CXX=g++ コンパイル環境を構築する。 ../configure もし、環境を指定したい場合は、 ../configure --help で確認する。次のようにインストール場所を指定する場合が多い。 ../configure --prefix=/usr/local/systemc-2.2 インストール場所は、あらかじめ作成しておくこと。 コンパイルを行う。 make ライブラリなどをインストールする。 make install 2015-05-06 20 39 52 (Wed) -
https://w.atwiki.jp/systemc/pages/21.html
SystemC-AMSライブラリのキーワードはsca_で始まる。マクロはSCA_で始まる。 AMSの基本的なクラスは名前空間sca_coreにある。 トレースやデータ型のようなユーティリティクラスは名前空間sca_utilにある。 モデル化の手法ごとに名前空間(namespace)が用意されている。 モデル化の手法 名前空間 TDF sca_tdf LSF sca_lsf ELN sca_eln モデル化手法にかかわらず同等なクラスがある場合は、名前空間で区別される。 たとえば、TDF用のモジュールのクラスはsca_tdf sca_moduleである。 2012-01-30 21 04 15 (Mon)
https://w.atwiki.jp/bambooflow/pages/142.html
SystemCのモジュール定義について(SC_MODULE) SystemCのモジュール定義について(SC_MODULE)モジュール構文SC_MODULEマクロを使わないモジュールの構文 モジュールの構成部品モジュール SC_MODULE SC_MODULEクラスのコンストラクタ SC_CTOR 実行の単位 プロセス(SC_METHOD, SC_THREAD, SC_CTHREAD) モジュール複製の回避 マクロ定義SC_MODULEのマクロ定義 SC_CTORのマクロ定義 SC_HAS_PROCESSのマクロ定義 モジュール構文 SystemCの基本的なモジュール定義はつぎのようになる。 C++があまりよくわからない人は、とりあえずこういうものなんだ、と思っておけばよいかと。 #include systemc.h SC_MODULE( ModuleName ) { // ポート宣言(sc_port, sc_in, sc_out等) // メンバ・チャネル(sc_signal, sc_buffer等) // メンバ・データ(int, char, unsigned long等) // プロセス・メソッド(プロセス) // ヘルパ・メソッド // コンストラクタ SC_CTOR( ModuleName ) // 初期化 { // サブモジュールのインスタンス // サブもジュールの信号接続 // プロセス登録 // 静的センシティビティ設定 // ユーザ定義の各種設定 } // デストラクタ ~ModuleName() { } }; SC_MODULEマクロを使わないモジュールの構文 C++をわかっている人にとってはこちらの書き方の方がわかりやすいかもしれない。 #include systemc.h class ModuleName public sc_module { public SC_HAS_PROCESS( ModuleName ); // コンストラクタ ModuleName( sc_module_name m_name ) sc_module( m_name ) { } }; SC_HAS_PROCESSはモジュール(のコンストラクタ)内でプロセス登録をしている場合は必ず必要になる。コンストラクタをSC_CTORマクロで記述している場合は、このSC_HAS_PROCESSの記述は必要ない。 もし、プロセス登録がないモジュールでもSC_HAS_PROCESSが宣言されていたからといってエラーになることはないので、とりあえず書いておくことをお薦めする。 SC_HAS_PROCESSは単なるtypedefのマクロにすぎない。 モジュールの構成部品 モジュール SC_MODULE SystemCでハードウェアの１つの機能を記述するためのデザインの最小単位はSC_MODULEである。 Verilog-HDLでいうところのmoduleにあたる。 とにもかくにもこのSC_MODULEを作らなければ始まらない。 SC_MODULEはマクロで、C++のクラスを宣言することになる。 SC_MODULEでは以下の要素を構築する。 ポート(sc_port, sc_in, sc_out等) メンバ・チャネル(sc_signal, sc_buffer等) メンバ・データ(int, char, unsigned long等) コンストラクタ(SC_CTOR) デストラクタ プロセス・メソッド(プロセス) ヘルパ・メソッド SC_MODULEクラスのコンストラクタ SC_CTOR SC_MODULEのコンストラクタはSC_CTORというマクロが用意されている。 SC_MODULEのコンストラクタではSystemC特有の以下の処理を行う。 サブデザインの初期化/アロケーション サブデザインの接続(bind) SystemCカーネルへのプロセス登録(SC_METHOD, SC_THREAD, SC_CTHREAD) 静的センシティビティの設定(sensitive, reset_signal_is等) ユーザ定義の各種設定 実行の単位 プロセス(SC_METHOD, SC_THREAD, SC_CTHREAD) ハードウェアを表現するためにSystemCでは並列処理を表現することができる。 並列処理は関数が単位となる。 SystemCでは、並列処理に設定した関数のことをプロセスと呼ぶ。 プロセスの登録はSC_MODULEのコンストラクタで行う必要がある。それ以外では行わない。 SC_THREADのプロセス登録の例は次のとおり。 SC_MODULE( Model ){ ・・・ void func_thread(); // constructor SC_CTOR( Model ) { SC_THREAD( func_thread ); } }; モジュール複製の回避 モジュール複製は望ましくない。 たいていは暗黙のルールでモジュールのコピーはしないもの。 コピーコンストラクタと代入演算子関数をprivateで定義することでモジュールのコピーを許さないようにできる。 次にその記述を示す。 SC_MODULE( MyModel ) { SC_CTOR( MyModel ) { } private MyModel( const MyModel ) {} // コピーコンストラクタの禁止 MyModel operator=( const MyModel ) { return *this; } // 代入演算の禁止 }; こうすることで、万一モジュールの複製をしようとしても、コンパイル時にエラーとして怒られる。 マクロ定義 SC_MODULEのマクロ定義 SC_MODULEはsc_module.hで以下のように宣言されている。 #define SC_MODULE(user_module_name) \ struct user_module_name sc_core sc_module SC_CTORのマクロ定義 SC_MODULEのコンストラクタであるSC_CTORはsc_module.hで次のように定義されている。 #define SC_CTOR(user_module_name) \ typedef user_module_name SC_CURRENT_USER_MODULE; \ user_module_name( sc_core sc_module_name ) SC_HAS_PROCESSのマクロ定義 SC_HAS_PROCESSはsc_module.hで次のように定義されている。 #define SC_HAS_PROCESS(user_module_name) \ typedef user_module_name SC_CURRENT_USER_MODULE
https://w.atwiki.jp/bambooflow/pages/145.html
SystemCとは SystemCとはSystemCとは? SystemCが持つ機能 SystemCの利点 SystemCの欠点 SystemCの使い道 SystemCを扱うにあたっての要求スキル SystemCとは? SystemCは、1999年9月に発足した組織OSCI(Open SystemC Initiative)により規格化された、新しいハードウェアモデリング言語である。OSCIから無償でSystemCライブラリが提供されている。 SystemCは、標準のC++で実装されたクラスライブラリで、C++記述によるハードウェア設計の構築を提供する。SystemCを利用できるのは、ハードウェアとソフトウェアにおけるの企画・提案から実装までの設計と検証の期間である。つまり、実際にハードウェアを設計する前段階の作業で利用することができる。 SystemCは高速なシステムレベルC++モデルの開発と交換を可能とするプラットフォームを提供する。 これはシステムレベルツールの開発のためのプラットフォームも提供する。 簡単に言うと、C++のコンパイラを使ってハードウェア記述が可能で検証もできてしまう優れもの。 ただし、SystemCを記述したからといって、それを直接ハードウェアにできるというわけではない。あくまでもハードウェアの代替となる検証用どまり。 ただ、高位合成ツール(SystemC→RTL)が徐々に実用化されつつあるところ。 先はまだわからない。 SystemCが持つ機能 C++でハードウェアを記述するために、SystemCライブラリは次のような特徴的な機能を持つ。 時間モデル ビット・データ型(sc_bv , sc_uint , sc_fixed, etc.) モジュールの記述(SC_MODULE) チャネル/ポート(プリミティブ・チャネル、階層チャネル、インターフェース) 並列動作環境(プロセス) 波形シミュレーション環境(VCD etc.) SystemCの利点 ライブラリが無償で提供されている C++ベースであるため、検証環境が容易に構築できる(GCCもしくはVC++コンパイラ) ソフトウェア/ハードウェア協調検証が比較的容易にできる あらゆる抽象度(TLMからRTLまで)が記述可能 SystemCの欠点 C++の基本的な知識とSystemC固有の記述を覚えなくてはならず、スタートまで若干ハードルがある プロセス間のタイミングでクセがあり悩まされる 記述の自由度が高すぎて、モデルの統一化がなされていない SystemCの使い道 SW/HW協調検証 高位合成(動作合成) 並列分散処理モデル etc. SystemCを扱うにあたっての要求スキル C,C++の知識があり、クラスの概念やテンプレートがわかる(協調検証モデル作成) Verilog-HDL等のハードウェア記述等に興味があり精通している(高位合成)
https://w.atwiki.jp/bambooflow/pages/53.html
SystemC なんとなく覚書き。 勉強のためにメモを残しているだけなので、間違いやテキトウな表現が大いにあります。賢いひとは参考にしないでください。 願わくばSystemCがもっと普及することを。 SystemCを始めるSystemCとは インストール(Linux,Cygwin,VC++EE) HelloWorld - 始めの一歩 Makefileの書き方 クロックカウンタを作る - モジュール定義を覚える 並列処理について - 並列処理動作を体感する Visual C++2008 Express Editionでの使用方法について SystemCの基本的な機能SystemCの基本データタイプ固定小数点 ユーザデータタイプ モジュール プロセス動的プロセスについて チャネルsc_clockクロック信号 sc_fifoチャネル 未分類検証環境モデル構成(テンプレート) SystemCのコアとなるクラス定義一覧 エラボレーション・フェーズ RTL記述 デバッグ 遅延モデル サンプル ビットアクセス 検証波形トレース レポート処理について SCV ↓まだまだ、勉強不足でわからないことだらけ。 間違いもあると思うので注意のほど。 TLM-2.0TLM-2.0について TLM-2.0クラス ジェネリック・ペイロード b_transportについて ブロッキング・インターフェースLTモデル Interconnect(ブロッキングI/F LTモデル) その他SystemC関連の歴史 コーディングスタイル(自分用) 用語集 参考ページ SystemCDoxygenマニュアル 関連サーチ Doxygenマニュアル 参考のためDoxygenを使ってみた。なかなか便利かも。 SystemC ver 2.1.v1 SystemC ver 2.2 TLM-1.0 TLM-2.0 Draft2 TLM-2.0 SCV-1.0p2 注意 packageとqtのフォルダは含めていない。 関連サーチ #bf
https://w.atwiki.jp/bambooflow/pages/110.html
SystemCによるRTL記述 SystemCによるRTL記述Verilog-HDLとSystemC記述の対比一覧 RTLから抽象度をあげるには Verilog-HDLとSystemC記述の対比一覧 SystemCでは、はば広い抽象度で記述できる。 RTL記述も可能。 Verilog-HDL記述は、SystemCでは、以下のように(RTL)記述できる。 Verilog-HDL記述 SystemCでは 備考 module M;～endmodule SC_MODULE(M) {～}; モジュール定義 input [7 0] in_data; sc_in 8 in_data; 入力信号 output [15 0] out_data; sc_out 16 out_data; 出力信号 reg [31 0] tmp_reg; sc_uint 32 tmp_reg;もしくはsc_signal sc_uint 32 tmp_reg; 1つのプロセス内ならデータ型プロセス間通信ならsc_signal を使う wire [31 0] mm2mn_data; sc_signal 32 mm2mn_data; モジュール間信号接続 always @ (posedge(clk))begin～end SC_METHOD(method);sensitive clk.pos();void method() {～} FF推定 always @ (a or b)begin～end SC_METHOD(method);sensitive a b;void method() {～} 組み合わせ initial begin～end SC_THREAD(thread);void thread() {～} assign文 なし methodの組み合わせで表現 # 10 //ns wait(10,SC_NS) 遅延 @(posedge(clk)) wait(); クロック立ち上がりを待つ parameter width=5; const unsigned width=5; x[m n] x.range(m,n) ビットアクセス {x, y} (x, y) 連節 ただし、SystemCでRTL記述をしても、あまり利点がない。 シミュレーション速度は逆にSystemCのほうが遅くなるかもしれない。 RTLから抽象度をあげるには 以下の点を実施すると抽象度があがっていくはず。 SC_METHODからSC_THREADを使用する クロック信号を使わない プロセス関数を少なくする waitの数を少なくする ステートマシンを記述しない 入出力信号をsc_fifo等を使用する(関数でデータの受け渡しをする) 抽象度をあげることで、SW協調モデルとして利用性が高くなる。 SW協調モデルに求められるのは、タイミング精度はそこそこで、シミュレーション速度が優先。TLMレベル。
https://w.atwiki.jp/bambooflow/pages/124.html
SystemCのデバッグ SystemCのデバッグ信号接続(バインド)の失敗について マクロ定義 sc_mainの初期表示 時間表示 モジュール名の表示 プロセス表示 sc_assertの使用 sc_reportレポートの種類 使用例 sc_report_handler モジュール内のレポート記述SC_REPORT_INFO SC_REPORT_WARNING SC_REPORT_ERROR使用例 SC_REPORT_FATAL使用例 信号接続(バインド)の失敗について コンパイルは通ったが、シミュレーションしようと実行したら、次のようなエラーが出た。 Error (E109) complete binding failed port not bound port mod.port_1 (sc_in) In file ../../../../src/sysc/communication/sc_port.cpp 265 原因は、sc_in もしくはsc_out の接続ミス。 次のようなとき、このエラーが出力される。 sc_main.cpp #include systemc.h #include "mod.h" int sc_main(int argc, char* argv[]) { sc_signal unsigned int sig_a; sc_signal unsigned int sig_b; sc_signal unsigned int sig_c; mod mod0( "mod0" ); mod0.a( sig_a ); //mod0.a( sig_b ); // 接続していない mod0.a( sig_c ); sc_start( 10, SC_US ); return 0; } mod.h SC_MODULE( mod ) { sc_in unsigned int a; sc_in unsigned int b; sc_in unsigned int c; ・・・ }; 今回の場合は、modモジュールのbというsc_in ポートに対して、チャネル(sc_signal )が接続されていないことが原因。 modで信号の宣言が上から順に"a", "b", "c""となっているが、エラーで"port not bound port mod.port_1 "と表示されていたら、上から数えて2番目の信号”b”が接続ミスだとわかる。 もし、"mod.port0"と表示されたら、1番目の信号"a"が接続ミスだとわかる。 シミュレーション開始前にあるエラボレーションのフェースで信号の接続等の確認を行う。 sc_in 、sc_out を宣言したら、宙ぶらりんにしないこと。かならず、sc_signal もしくはsc_buffer と接続すること。 マクロ定義 Ver2.1 SYSTEMC_VERSION = 20050714 SC_RELEASE_STRING = "2.1.v1" SC_API_VERSION_STRING sc_api_version_2_1_0 Ver2.2 SYSTEMC_VERSION = 20070314 sc_mainの初期表示 sc_version() = SystemC 2.1.v1 --- May 18 2008 17 13 45 sc_copyright()= Copyright (c) 1996-2005 by all Contributors ALL RIGHTS RESERVED 時間表示 #include systemc.h #include iomanip #ifndef DEBUG_TIME #define DEBUG_TIME std setw(8) std right sc_time_stamp() "(" std dec std setw(6) sc_delta_count() ") " #endif 使用例 cout DEBUG_TIME "example output time" endl; 表示 0 s( 0) example output time モジュール名の表示 printf("%s\n", this- name()); // 階層構造を含むオブジェクト名 printf("%s\n", this- basename()); // 自オブジェクト名のみ プロセス表示 #ifndef DEBUG_PROCESS #if SYSTEMC_VERSION = 20060606 // Sysc v2.2 #define DEBUG_TIME sc_get_current_process_handle().name() " " this- name() " " #else #define DEBUG_PROCESS sc_get_curr_process_handle()- name() " " this- name() " " #endif #endif 使用例 cout DEBUG_PROCESS" "example output process" endl; 表示 TOP0.DUT0.thread_proc TOP.DUT0 example output process sc_assertの使用 ・・・ TopModule top = new TopModule( "top" ); sc_assert( top ); // topがNULLだと異常終了となる ・・・ 異常終了の表示例 Fatal (F4) assertion failed top In file main.cpp 14 アボートしました sc_report レポートの種類 sc_severityエラーレベルは以下の４つ。 重大度 説明 SC_INFO 情報出力 SC_WARNING 警告、問題である可能性がある SC_ERROR 重大な問題 SC_FATAL 致命的な問題でシミュレーションを終了 sc_reportによりアクセスする 使用例 try { ... SC_REPORT_ERROR("msg_type", "msg"); ... } catch ( sc_report e ) { std cout "Caught " e.what() std endl; } sc_report_handler sc_report_handler モジュール内のレポート記述 SC_REPORT_INFO SC_REPORT_WARNING SC_REPORT_ERROR使用例 std ostringstream msg; // log message msg.str (""); msg " Not supported yet."; SC_REPORT_ERROR(filename, __FUNCTION__, msg.str()); SC_REPORT_FATAL使用例 SC_REPORT_FATAL( "TLM2", "not supported." );