Mutex Controller

Mutex

Thread Assignment Controller Lock Object Accessing Controller

arbiter_info

圖 25 The block diagram of Mutex Controller

34

圖 25與圖 26描述 Mutex Controller 的架構，當 2 個以上 JAIP 處理器同時發送 request 時，Arbiter 目的是優先挑選其中一個 request 使這些不同來源的 request 能循序被其他子 模組處理；arbitor_cmd_msg 為 Arbiter 輸出，格式如下：arbitor_cmd_msg[4:2]為 core ID(如 圖 20)，arbitor_cmd_msg[1:0]為 command ID(如表 1)，其儲存的值表示某個 JAIP 處理 器取得權限並且參考 command ID 欄位與 mutex_state 準備觸發 Thread Assignment Controller 或者 Lock Object Accessing Controller，當沒有任何 JAIP 處理器啟動 Mutex Controller 執行工作時，arbitor_cmd_msg 預設值是 11100

SEND lock_flag = ‘1’

[annotation 1]

圖 26 The state diagram of Mutex Controller [annotation 1]

根據圖 25的訊號，當 monEn_match_cmplt 為 true、

monEn_free_cmplt 為 true、monEx_cmplt 為 true、

new_TH_to_coreID 不等於 111 其中一個條件成立時，轉移到 下個狀態

[annotation 2]

判斷 DCC2JAIP_response_msg 的 Receiver core ID，檢查對應 JAIP 的 JAIP2DCC_delay_resMsg 數值

lock_flag 為 Arbiter 輸出訊號，其初始值為 0。Arbitor 會決定要優先處理哪個 request signal、lock_flag 由 0 轉為 1 並且 mutex_state 從 Idle 轉為 WAIT_FOR_RES，當 mutex_state

= TASK_CMPLT、 lock_flag 值回到 0 才允許從 JAIP 處理器讀取下一個 request 並且修 改 arbitor_cmd_msg；Arbiter_Info 只有當 arbitor_cmd_msg 不等於 111 時，根據不同 core ID 抓取對應 JAIP 處理器的 JAIP2DCC_info；mutex_state 表示目前 state controller 狀態並 且表示目前 Data Coherence Controller 各模組工作階段；new_TH_to_coreID 為 Thread Assignment Controller 工 作 完 成 後 輸 出 的 信 號 ， 其 數 值 代 表 的 意 義 如 同圖 20

35

DCC2JAIP_response_msg 的 Receiver core ID；monEn_match_cmplt、monEn_free_cmplt、

monEx_cmplt 為 Lock Object Accessing Controller 工 作 完 成 後 輸 出 的 信 號 ； JAIP2DCC_delay_resMsg (圖 26 的 annotation 2)為每一個 JAIP 的 ICCU 連接到 Mutex Controller 的信號，表示個別 JAIP 底下的 Thread Manager Unit 正在更新的 Thread Control Block (e.g. 增加 new thread 的執行資訊、Thread Controller 備份 previous thread 的執行資 訊)；Response Controller 負責傳送回應訊號 DCC2JAIP_response_msg 到各個 JAIP 處理 器的 ICCU。

以圖 10 為範例，當 thread t1 與 t2 分別透過 JAIP A 與 JAIP B 同時呼叫 synchronized method A2，此時由 ICCU 發送 request signal 到 Data Coherence Controller：此時 JAIP A 與 JAIP B 的 JAIP2DCC_cmd 同時不等於 0，mutex_state = Idle、由 Arbiter 判斷讓哪個 JAIP 的 JAIP2DCC_cmd 與 JAIP2DCC_info (圖 19) 分 別 寫 入 arbitor_cmd_msg 與 Arbiter_Info，同時設定 lock_flag 值為 1。假設 Arbiter 優先選擇 JAIP A 的 request，則其 他 JAIP 處理器的 request 必須等到之後 lock_flag 值為 0 且 mutex_state = Idle 時才有機會 將 request 與 data 寫入 arbitor_cmd_msg 與 Arbiter_Info。當 lock_flag 值為 1，mutex_state 從 Idle 到 WAIT_FOR_RES，在這個範例中 arbitor_cmd_msg 值傳入並且啟動 Lock Object Accessing Controller 執行工作。

而當 Thread Assignment Controller 或者 Lock Object Accessing Controller 工作完成後 各個電路回傳訊號(例如 monEn_match_cmplt、monEn_free_cmplt、new_TH_to_coreID) 到 state controller，mutex_state 值從 WAIT_FOR_RES 到 GEN_RES_MSG。當 mutex_state

= GEN_RES_MSG，產生回應訊號並且暫存到 Response Controller 的內部暫存器，其格 式與 DCC2JAIP_response_msg 相同；當 mutex_state 為 CHK_TCBLIST_RDY，此時檢 查 Response Controller 中用來儲存回應訊號的內部暫存器，檢查 Receiver core ID 與對應 JAIP 的 JAIP2DCC_delay_resMsg，如果 JAIP2DCC_delay_resMsg = 0 表示 Receiver core ID 對應的 JAIP 處理器其底下 Thread Controller Block 目前沒有被其他電路存取，則 mutex_state 進入 SEND_RES_MSG；否則 JAIP2DCC_delay_resMsg = 1，此 Thread Controller Block 目前已有其他電路更新其內容，Response Controller 必須延後將回應訊

36

息送給 DCC2JAIP_response_msg。當 mutex_state = SEND_RES_MSG，Response Controller 將回應訊息送給 DCC2JAIP_response_msg，傳到個別 JAIP 處理器的 ICCU。當 mutex_state

= TASK_CMPLT、lock_flag 值回到 0、mutex_state 值從 TASK_CMPLT 回到 Idle，此時 Arbiter 檢 查 其 他 JAIP 處 理 器 的 JAIP2DCC_cmd ， 如 果 其 他 JAIP 處 理 器 的 JAIP2DCC_cmd 不等於 111，則把 JAIP2DCC_cmd 寫入 arbitor_cmd_msg 其餘執行流程 相同，否則 arbitor_cmd_msg 被改為預設值。