本文將接著分享sequencer的相關知識，對于sequencer的仲裁特性有幾種可選，UVM_SEQ_ARB_FIFO ；UVM_SEQ_ARB_WEIGHTED；UVM_SEQ_ARB_RANDOM ；UVM_SEQ_ARB_STRICT_FIFO等。出其中三種需要特別區分外其它的模式可以滿足絕大多數的仲裁需求。

sequencer的仲裁特性及應用

在之前我們就談到了，uvm_sequencer類自建了仲裁機制用來保證多個sequence同時掛載到sequencer時，可以按照規則允許特定的sequence中的item優先通過。在實際使用中，我們可以通過uvm_sequencer：：set_arbitration（UVM_SEQ_ARB_TYPE val）來設置仲裁模式。這里的仲裁模式UVM_SEQ_ARB_TYPE有下面幾種值可以選擇：

UVM_SEQ_ARB_FIFO ：默認模式。來自于sequences的發送請求，按照FIFO先進先出的方式被依次授權，和優先級沒有關系。

UVM_SEQ_ARB_WEIGHTED：不同sequence的發送請求，將按照它們的優先級被隨機授權。

UVM_SEQ_ARB_RANDOM ：不同的請求會被隨機授權，而無視它們的抵達順序和優先級。

UVM_SEQ_ARB_STRICT_FIFO：不同的請求，會按照它們的優先級以及抵達順序來依次授權，因此與優先級和抵達時間都有關。

UVM_SEQ_ARB_STRICT_RANDOM：不同的請求，會按照它們最高的優先級被隨機授權，與抵達時間無關。

UVM_SEQ_ARB_USER：用戶可以自仲裁機制方法user_priority_arbitration（）來裁定哪個sequence的請求優先被授權。

在上面的仲裁模式中，與priority有關的模式有UVM_SEQ_ARB_WEIGHTED、UVM_SEQ_ARB_STRICT_FIFO和UVM_SEQ_ARB_STRICT_RANDOM。這三種模式的區別在于，UVM_SEQ_ARB_WEIGHTED的授權會落到各個優先級的請求上面，而UVM_SEQ_ARB_STRICT_RANDOM則只會將授權隨機安排到最高優先級的請求上面，UVM_SEQ_ARB_STRICT_FIFO則不會隨機授權，而是嚴格按照優先級以及抵達順序來依次授權。沒有特別要的要求，則用戶不需要再額外自定義授權算法，因此使用UVM_SEQ_ARB_USER這一模式的情況不多見，其它的模式可以滿足絕大多數的仲裁需求。

鑒于sequence在傳送的優先級可以影響sequencer的仲裁授權，我們有必要結合sequencer的仲裁模式選擇和sequence發送的優先級參數設置給出一段例碼。通過這段例碼，希望讀者可以掌握如何設置仲裁模式和優先級的傳遞。

輸出結果：

上面的例碼中，seq1、seq2、seq3在同一時刻發起傳送請求，通過`uvm_do_prio_with的宏，在發送sequence時可以傳遞優先級參數。由于將seq1與seq2設置為同樣的高優先級，而seq3設置為較低的優先級，這樣在隨后的UVM_SEQ_ARB_STRICT_FIFO仲裁模式下，可以從輸出結果看到，按照優先級高低和傳送請求時間順序，先將seq1和seq2中的item發送完畢，隨后將seq3發送完。

除了在上面的sequence遵循仲裁機制，將自身的item發送完才結束自身的正常模式以外，在一些特殊情形下，有一些sequence需要有更高的權限取得sequencer的授權來訪問driver。 例如需要響應中斷的情形下，用于處理中斷的sequence應該有更高的權限來獲得sequencer的授權。為此，uvm_sequencer提供了兩種鎖定機制，分別可以通過lock（）和grab（）方法實現。這兩種方法的區別在于：

lock（）與unlock（）這一對方法可以為sequence提供排外的訪問權限，但前提條件是，該sequence首先需要按照sequencer的仲裁機制獲得授權。而一旦sequence獲得授權，則無需擔心權限被收回，只有該sequence主動unlock它的sequencer主動解鎖，才可以釋放這一鎖定的權限。lock（）是一種阻塞的任務，只有獲得了權限，它才會返回。

grab（）與ungrab（）也可以為sequence提供排外的訪問權限，而且它只需要在sequencer下一次授權周期時就可以無條件地獲得授權。與lock方法相比，grab方法無視同一時刻內發起傳送請求的其它sequence，而唯一可以阻止它的只有已經預先獲得授權的其它lock或者grab的sequence。

這里需要注意的是，由于“解鈴還須系鈴人”，如果sequence使用了lock（）或者grab（）方法，必須在sequence結束前調用unlock（）或者ungrab（）方法來釋放權限，否則sequencer會進入死鎖狀態而無法繼續為其余sequence授權。下面的給出一段例碼，用來展示如何使用上述的方法實現鎖定的sequence傳送方式。

輸出結果：

結合例碼和輸出結果，我們從中可以發現如下幾點：

對于locks，在10ns時，它跟其它幾個sequence一同向sequencer發起請求，按照仲裁模式，sequencer先后授權給seq1、seq2、seq3，最后才授權的locks。而locks在獲得授權之后，就可以一直享有權限，而無需擔心權限被sequencer收回。直到在locks結束前，用戶需要通過unlock（）方法返還權限。

對于grabs，盡管他在20ns時就發起了請求權限（實際上seq1、seq2、seq3也在同一時刻發起了權限請求），而由于權限已經被locks占用，所以它也無權收回權限。因此只有當locks在40ns結束時，grabs才可以在sequencer沒有被鎖定權限的狀態下獲得權限，而grabs獲得權限是無視同一時刻發起請求的其它sequence的。同樣地，在grabs結束前，也應當通過ungrab（）方法釋放權限，防止sequencer的死鎖行為。

至此，我們就將sequence/item發送的方法和宏，以及sequence與sequencer之間的仲裁和授權請求方式為讀者介紹完畢。