[libre-riscv-dev] pipeline sync issues

[Jacob Lifshay]

On Thu, Apr 11, 2019 at 8:52 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> basically, Control Blocks *MUST* be Synchronous, and Data Blocks
>
*MUST* be Combinatorial.
>
Ok. In the design I created, it works just fine to have ready, valid, and
data to be some combination of synchronous and combinational, the interface
contract is that ready, valid, and data have to be stable and correct right
before each clock edge and there can't be any combinatorial-only loops.
Other than those two requirements, ignoring stuff like propagation delays
and setup/hold times, the stages can have any arbritrary combination of
whatever flip-flops and gates (and other stuff, but that's uncommon) that
create the proper outputs. This is what allows stages/Pipelines like
RegStage that have the outputs be a combinatorial function of inputs and
internal flip-flops.

>
> so this is why StageChain exists: it performs a *BYPASS* of
> ready/valid signalling *ENTIRELY* as that is the *ONLY* way to not
> have sync introduced anywhere into the processing chain.
>
> it's taken me a while to understand that.  that's the key message that
> i've been trying to get across to you for several weeks, i just only
> understood it subconsciously so couldn't state it as clearly and
> simply.
>
Now that I understand what your assumptions are, it makes more sense.

> What I think will work best is to just not support adding additional data
> > signals to Stage interfaces,
>
>  it would not make sense to add additional signals to Stages,
> particularly after they're in "use".  that would be dangerous, and
> should never be done.
>
>  you must mean something else, can you clarify?
>
I had meant not supporting adding additional signals to Record-like classes
after they've been used in a way that iterates through all signals in those
classes. One of those uses is to use them in a Stage interface.

>
> > and then a FIFO can just be another stage with
> > ready/valid signalling, just like RegStage and BreakReadyChainStage.
>
>  i've already got FIFOControl working, including with "incoming"
> processing capability.  so the data, as it comes into the FIFOControl
> rather than going directly into the FIFO din (memory block), goes
> through the Stage.process() function.
>
>  the output of that conforms to stage.ospec(), is run through
> flatten(), and the (one) Signal of width total equal to the entire
> (recursive) RecordObject format is assigned to the Memory read port of
> the FIFO.
>
>  the upshot of that is that the Stage may be a *COMBINATORIAL* block
> conforming to the Stage API *INCLUDING A StageChain*.
>
>  the end result is the possibility to daisy-chain combinatorial stages
> (data processing blocks) together, and still have them buffered by a
> FIFO.
>
ok.

>
> > I'm
> > quite sure that ready/valid signalling can emulate with no additional
> > circuitry all of Global CE, Traveling CE, strobe/busy, and the other
> > pipeline control schemes except maybe for the strobe/ack scheme that
> > requires 2 cycles for every data element (which can be emulated by using
> > some adaptors). I'm writing in my new proposal how restricted cases of
> > ready/valid are logically identical to the other schemes.
>
>  i believe you may be correct about Global CE and Travelling CE, as
> long as it's possible to assign ready/valid to Const(0) or Const(1) as
> appropriate.  that _will_ mean critically relying on the optimiser of
> yosys, which i am not confident about (not enough experience with).
>
I checked the list of optimizations, and, as long as yosys's flatten
command is run (part of the standard synthesis script), yosys can optimize
out unused and constant signals.

>
> STB/ACK i've not properly analysed.
>
I know that ready/valid supports a superset of the operations stb/ack
supports, however, stb/ack will need some logic gates and flip-flops to
communicate with ready/valid signalling.

>
> > I think that the FIFO class may be designed for crossing clock domains
> and
> > therefore has extra delay for synchronization.
>
>  you're confusing four classes together (see the docstrings in lib/fifo.py)
>
Ok. I hadn't actually checked.

Jacob