在前面的系列文章中，已基本闡述了Pipeline中的用法，本篇做個總結，重點針各方法的優先級

》last Win

無論是SystemVerilog還是SpinalHDL,都有Last valid assignment wins的語法特征。如在SpinalHDL-Doc中所描述：

// Every clock cycle evaluation starts here
val paramIsFalse = false
val x, y = Bool() // Define two combinational signals
val result = UInt(8bits) // Define a combinational signal

result := 1
when(x) {
result := 2
when(y) {
result := 3
}
}
if(paramIsFalse) { // This assignment should win as it is last, but it was never elaborated
result := 4// into hardware due to the use of if() and it evaluating to false at the time
}

對應的真值表是：

那么在使用pipeline中，你可能會這么來寫：

when(cond1){
haltIt()
}
when(cond2){
spawnIt()
}

參照上面所述的Lastvalid assignment wins的語法特征，你可能認為spawnIt的優先級是高于haltIt的～

然而，并非如此。

Pipeline的構建并不是我們在直接構建，而是我們描述了流水線的規則之后交由Pipeline的build函數來搭建起整個的流水線結構。既然不是我們直接搭建電路，那么就要注意下在流水線構建過程中這些方法的優先級了。

回到Pipeline的組成結構：

Pipeline包含Stage和Connection兩大主體。在Pipeline的build構建中，分別對應了Internal Connection及InInterconnect Connection兩部分。

》Internal Connection中的優先級

來看下在Pipeline中關于Internal Connection的處理：

在之前的文章系列中已基本分析了每個小單元的用法(forks暫時不考慮)。對于每一級Stage，默認情況下Stage的output端口和input端口是直連的。而后自上到下對應的API處理分別是：

spawnIt

flushIt(root為true)

throwIt(root為true)

haltIt

按照Last valid assignment wins的原則，那么上面對應的API則是優先級從高到低的。

》Interconnect Connection中的優先級

這里還是以Pipeline中常用的M2S為例來看待Interconnect Connection中的處理方式：

這里我們要區分來看：

m.ready存在(對應前一級Stage的output.ready)

m.ready不存在

先來看m.ready不存在的場景。當m.ready不存在時，上面的處理流程牽涉到的API有：

flushIt(line30)

flushNext(line31)

按照Last valid assignment wins的原則，那么上面對應的API則是優先級從高到低的。

而當m.ready存在時，則牽涉到的API有：

throwIt(line19)

flushIt(line 30)

flushNext(line 31)

按照Last valid assignment wins的原則，那么上面對應的API則是優先級從高到低的。

》寫在最后

對于SpinalHDL Pipeline這個“勇者的游戲”系列，至此基本總結的差不多了。寫文章相比于看代碼還是要費事一些。對于Pipeline這個系列，最開始驅使我去研究來源于想對Cache的了解，看著dolu的代碼如看天書。不得不說Pipeline的這個設計簡直“驚為天人”！對于邏輯設計來講無非兩大核心：狀態機，流水線。在看Pipeline之前覺得這個Lib真抽象，真正看完分析后覺得真香，之前自己的設計簡直太Low了，這里簡直把高效描述電路發揮到了極致～

審核編輯：劉清