[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.

 https://chisel.eecs.berkeley.edu/api/3.0.1/chisel3/util/DecoupledIO.html

 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
zero-queue-entries.

 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!)

l.



More information about the libre-riscv-dev mailing list