pipeline高端玩法—看下FlushNext的用法

看完了flush，再看下flushNext的用法

》flushNext

在Stage里，有關(guān)flushNext提供的API有：

defflushNext():Unit = flushNext(ConditionalContext.isTrue)

defflushNext(cond : Bool):Unit = internals.request.flushNext += cond

調(diào)用flushNext,最終會將flushNext的需求暫存到internals.request.flushNext中。

在Pipeline中，propagateRequirements函數(shù)中對于每一級Stage的處理：

varflushNext = stage.internals.request.flushNext.nonEmpty generate orR(stage.internals.request.flushNext)

如果flushNext不為空，則將所有條件或后得到flushNext電路對象。

在上面的這段描述中，針對驅(qū)動當(dāng)前Stage的Conntection處理，flushNext電路將會被存儲在clFlushNext(l)中。如果flushNext不為空(line:5),可以看到在line7:9行處理時，不管flush是存在，都會創(chuàng)建一個flush電路對象，也就意味著一般情況下flush，flushNext不需要同時使用。

而在line11:14中，以M2S為例，alwasContainsSlaveToken為True，會將flushNext清空。此時在line16:17時，僅會對驅(qū)動當(dāng)前Stage的Stage Master調(diào)動flushIt函數(shù)，也就意味著flushNext將會向前傳播，前級相當(dāng)于執(zhí)行flushIt。

clFlushNext的使用僅在Connection中使用到。還是以M2S為例，其處理邏輯為：

if(flushNext != null&& !flushPreserveInput) s.valid clearWhen(flushNext && s.ready)

在這里，如果flushNext不為空(flushPreserveInput默認(rèn)為true)，s.valid僅會在slave端ready和flushNext同時為高時才會清零。對比flush操作：

if (flush!= null&& !flushPreserveInput) s.valid clearWhen(flush)

也就意味著flushNext存在ready的情況下才具有意義。

》example

結(jié)合上面的分析，flushNext與flush的最大區(qū)別在于存在ready傳播的情況。這里先給出一個flsuhIt的例子：

這里是一個三級pipeline，最后一級調(diào)用flushIt操作，flushRoot參數(shù)傳遞為true。

采用下面的仿真代碼：

我們這里在index==5時將cond拉高一拍，data_out.ready拉低一拍。

仿真波形如下：

可以看到，由于這里流水線為3級，在index=5時執(zhí)行flush數(shù)據(jù)3，4，5不會從data_out有效輸出。

將flushRoot參數(shù)修改為false：

cond為高時data_out.valid仍然為高電平，下一個時鐘周期拉低。雖然此時ready為低電平，這個數(shù)據(jù)沒有被消耗，但其拉低時間不考慮ready信號的高低電平。

再將上面的代碼換成flushNext：

可以看到，雖然cond為高，但其仍會堅持將此時已經(jīng)傳播到stage2的3給穩(wěn)定傳輸出去，僅有4，5不會被data_out輸出。

審核編輯：劉清