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

》flushNext

在Stage里，有關flushNext提供的API有：

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

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

調用flushNext,最終會將flushNext的需求暫存到internals.request.flushNext中。

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

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

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

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

而在line11:14中，以M2S為例，alwasContainsSlaveToken為True，會將flushNext清空。此時在line16:17時，僅會對驅動當前Stage的Stage Master調動flushIt函數，也就意味著flushNext將會向前傳播，前級相當于執行flushIt。

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

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

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

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

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

》example

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

這里是一個三級pipeline，最后一級調用flushIt操作，flushRoot參數傳遞為true。

采用下面的仿真代碼：

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

仿真波形如下：

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

將flushRoot參數修改為false：

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

再將上面的代碼換成flushNext：

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

審核編輯：劉清