》多路一出的場景

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

這其實(shí)也是之前微信群里面群友問的一個(gè)類似的場景。在一些應(yīng)用里，來自上游的數(shù)據(jù)或者任務(wù)分發(fā)給多個(gè)Kernel來進(jìn)行執(zhí)行處理(如多個(gè)報(bào)文解析模塊)。針對每個(gè)任務(wù)，其具體的執(zhí)行時(shí)間會有差異(比如在網(wǎng)絡(luò)報(bào)文頭解析中，不同層協(xié)議所需要的時(shí)鐘周期數(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將會導(dǎo)致Dispatcher的阻塞。那么針對這種場景，顯然是下游Kernel誰空閑將任務(wù)分發(fā)給誰更合適。 》StreamFragmentRoundRobinDispatcher

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

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

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

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

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

審核編輯：劉清