差異處

這裏顯示兩個版本的差異處。

--- techdoc:esl:systemc_delta_cycle [2015/02/28 16:36]
jay 建立
+++ techdoc:esl:systemc_delta_cycle [2015/03/19 08:54] (目前版本)
jay
@@ 行 1: / 行 1: @@
 ====== Delta Cycle in SystemC ======
+----
 SystemC 提供了一組 C/C++ 的 Library 讓設計者可以使用 C/C++ 的語法來描述硬體；
@@ 行 32: / 行 33: @@
 在循序執行的 C/C++ 環境下，不會因為 SystemC Process 執行順序的不同，造成不同的程式行為。
-接下來我們使用兩條 SC_THREAD 來進行說明，完整的 Source Code 可由此下載。
+----
+接下來我們使用兩條 SC_THREAD 來進行說明，完整的 Source Code 可由此{{:techdoc:esl:systemc_delta_cycle:example.tar.gz|下載}}。
 首先我們建立四個 Data Type 為 uint32_t 的 sc_signal，如下圖：
+{{:techdoc:esl:systemc_delta_cycle:reg_sc_signal.jpg?nolink|}}
+----
 另外我們建立兩條 SC_THREAD，如下圖：
+{{:techdoc:esl:systemc_delta_cycle:sc_thread.jpg?nolink|}}
 a_thread 在每一個 Cycle 會對 a_value 的值累加 5，同時將目前 b_value 的值複製到 b_value_copy 中。
@@ 行 46: / 行 51: @@
 b_thread 在每一個 Cycle 會對 b_value 的值累加 3，同時將目前 a_value 的值複製到 a_value_copy 中。
+{{:techdoc:esl:systemc_delta_cycle:process_sc_signal.jpg?nolink|}}
 模擬的結果如下：
+{{:techdoc:esl:systemc_delta_cycle:wf_sc_signal.jpg?nolink|}}
 我們可以觀察到，不管 SystemC Kernel 的 Scheduler 先讓 a_thread 或 b_thread 先執行，
@@ 行 57: / 行 62: @@
 這就是因為 SystemC 的 Channel 提供了 Evaluate-Update 的特性。
+----
 接下來我們另外做一個小實驗，
@@ 行 64: / 行 71: @@
 所以我們將原本四個 sc_signal<uint32_t> 型態的變數改成 Native C/C++ 的 uint32_t 型態。
+{{:techdoc:esl:systemc_delta_cycle:reg_native_c.jpg?nolink|}}
 a_thread 和 b_thread 中的存取也改成正常 Native C/C++ 的寫法。
+{{:techdoc:esl:systemc_delta_cycle:process_native_c.jpg?nolink|}}
 模擬的結果如下：
+{{:techdoc:esl:systemc_delta_cycle:wf_native_c.jpg?nolink|}}
 我們會發現 Native C/C++ Data Type 的變數並不具備 Evaluate-Update 的特性。
@@ 行 84: / 行 91: @@
 但是上述的情況下，沒有使用 SystemC Channel 會讓程式的行為和預期的不同。
-References
+===== References =====
 [1] SystemC: From The Ground Up (Second Edition) , David C. Black and Jack Donovan, Springr, 2010.

計算機架構與系統實驗室

使用者工具

網站工具

差異處

頁面工具