基于RR的多路分發(fā)調(diào)用

》多路一出的場景

在SpinalHDL代碼中,StreamArbiter提供了完善的多入一出的調(diào)度機制。里面可能應(yīng)用的較多的是Round Robin調(diào)度。在之前的文章《你知道如何做多端口仲裁么》中詳細講述了Round Robin調(diào)度思想。然而還有一類應(yīng)用場景就是針對一入多出的情況：

這其實也是之前微信群里面群友問的一個類似的場景。在一些應(yīng)用里，來自上游的數(shù)據(jù)或者任務(wù)分發(fā)給多個Kernel來進行執(zhí)行處理(如多個報文解析模塊)。針對每個任務(wù)，其具體的執(zhí)行時間會有差異(比如在網(wǎng)絡(luò)報文頭解析中，不同層協(xié)議所需要的時鐘周期數(shù)并不相同)。那么為了盡可能避免Kernel空閑，顯然如果采用簡單的順序分發(fā)至Kernel1～kerneln會存在潛在的Kernel空閑。比如(假定n=3)：

Task1——>Kernel1；100 Clock Cycle

Task2——>Kernel2；50 Clock Cycle

Task3——>Kernel3；10 Clock Cycle

Task4——>Kernel1；10 Clock Cycle

顯然，這里如果將Task4分發(fā)至Kernel1將會導致Dispatcher的阻塞。那么針對這種場景，顯然是下游Kernel誰空閑將任務(wù)分發(fā)給誰更合適。 》StreamFragmentRoundRobinDispatcher

不同于StreamArbiter所針對的多入一出的誰有任務(wù)調(diào)度誰的RR調(diào)度，這里是一種一入多出的誰空閑任務(wù)給誰的RR調(diào)度，即Dispatcher By Round。如果你看過之前上面的文章，那么這里可以很容易做實現(xiàn)。考慮到真實的應(yīng)用場景，這里僅針對Stream Fragment形式的調(diào)度實現(xiàn)：

相比于StreamArbiter中采用多路輸入信號的valid信號作為調(diào)度請求request相反，這里(Line:19)采用多路輸出端口的ready信號作為roundRobin的request請求，從而實現(xiàn)誰空閑把任務(wù)給誰。

如之前前文所說，Round Robin其實是一種優(yōu)先級位置變化的最低優(yōu)先級調(diào)度，故這里(Line:19)通過mask_locked的循環(huán)左移來實現(xiàn)優(yōu)先級排序。故這里在初始化時將mask_locked的最高位初始化為1。

這里采用mask_route來標識對應(yīng)的端口仲裁結(jié)果。對于一幀F(xiàn)ragment Stream流，其首拍時由于仲裁結(jié)果還未鎖定，故采用mask_arbited來充當仲裁標示，而在隨后報文鎖定后采用mask_locked來執(zhí)行(確保一幀任務(wù)的調(diào)度不會被下游ready信號的變化所影響。如果下游端口能一幀完整報文之間不會拉低ready那么這里還可以進一步進行優(yōu)化)。

對于多Kernel處理結(jié)果需要保序輸出的場景，這里提供了port_sel_oh信號來輸出指示當前報文送至哪個端口。使用時可能需要再例化一個FIFO作為保序結(jié)果存儲，此時在例化該模塊連接port_in端口時可能需要一個continueWhen將保序Fifo的push.ready考慮進去。在port_in.firstFire時將port_sel_oh寫入保序Fifo。

審核編輯：劉清