以下簡化的流程圖說明了SystemC模擬核心的操作流程。

首先，如前面“modules”中所討論的那樣進行詳細說明。 在elab過程中，構建SystemC模組並建立各種模擬引數。 這個elab階段之後是對sc_start（）的呼叫，它呼叫模擬核心。 此呼叫開始初始化階段。 需要啟動在elab期間定義的程序（例如，SC_THREAD程序）。 在初始化階段，所有程序最初都放在就緒池中。 定義：只要可以執行，程序就會準備就緒。

我們有時會說程序被放入準備執行的程序池中。 下圖描繪了程序和事件池。

然後，模擬進入評估階段。通過將它們指定為執行和呼叫，從就緒池中隨機地取出一個個程序。每個程序程一直執行，直到它完成（例如，通過return）或暫停（例如，呼叫wait（））。
在執行期間，程序可以呼叫立即事件通知（即，event.notify（））並且可能使一個或多個等待程序處於就緒狀態。如上圖中的E1-E4所示，還可以生成延遲或定時事件通知。已完成的程序將被丟棄。暫停的程序被放入等待池中。模擬繼續進行，直到沒有更多程序準備好執行。

此時，執行將退出上圖底部的評估氣泡，其中包含三種可能性之一：等待程序或零延遲時間，非零時間延遲或兩者都不存在的事件。

首先，可能存在等待SC_ZERO_TIME延遲（.notify（0））的程序或事件（稍後將討論）。這種延遲稱為deltacycle延遲。在這種情況下，具有零時間延遲的等待池程序被放回到就緒池中。源自延遲通知的零時間事件可能導致等待這些事件的程序也被放入就緒池中。如果已將任何程序移入就緒池，則會進行另一輪評估。

其次，可能存在稍後安排的等待非零時間延遲發生的程序或事件。在這種情況下，時間提前到指示的最近時間。等待該特定延遲的程序將被放入就緒池中。如果在此新時間發生事件，則等待該事件的程序將放入就緒池中。如果已將任何程序移入就緒池，則會進行另一輪評估。
第三，可能沒有延遲的過程或事件。由於就緒池中沒有程序，因此模擬只需返回sc_main並完成清理即可結束。無法在SystemC的當前定義中成功重新輸入sc_start。