[libre-riscv-dev] pipeline sync issues

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Apr 16 10:18:09 BST 2019

On Tue, Apr 16, 2019 at 7:21 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> I looked at the Queue class in Chisel's standard library, and it has a
> ready/valid interface exactly equivalent to what I had written for the
> ready/valid Stage API,

 hmm, i wonder if Queue has the same characteristics as nmigen SyncFIFO?

> except that Chisel uses the name "bits" instead of
> "data" and Chisel splits the ready/valid interface into two types:
> DecoupledIO and IrrevocableIO.


 that's interesting.

> From what I can tell by reading the code, Queue with entries=1, pipe=true,
> and flow=false is logically equivalent to RegStage and Queue with
> entries=1, pipe=false, and flow=true is logically equivalent to
> BreakReadyChainStage.

 ... without the possibility of multiple queueing (buffering), which
use of SyncFIFO does provide.  however (see below), SyncFIFO can't do

 we need the possibility for both (multiple and zero queueing).  some
situations, buffering (FIFO-queueing) is costly and unnecessary.

> I am translating Queue to nmigen to verify that
> equivalence by comparing the Verilog output.

 excellent idea... can you commit the converted-code somewhere to examine?

> IrrevocableIO is different from DecoupledIO in that it gives the following
> guarantee (quoted from docs):
>     A concrete subclass of ReadyValidIO that promises to not change
>     the value of 'bits' after a cycle where 'valid' is high and 'ready' is
> low.
>     Additionally, once 'valid' is raised it will never be lowered until
> after
>     'ready' has also been raised

 which would be achieved indirectly by the use of SyncFIFO with a
2-entry queue (the first entry being write-through).

 one thing that SyncFIFO does *not* have however - because it uses a
Memory - is the ability to have only one queue in the queue [and that
entry being write-through].

 so this starts to make a little bit of sense (only a little bit!)


More information about the libre-riscv-dev mailing list