[libre-riscv-dev] pipeline sync issues

[Luke Kenneth Casson Leighton]

On Fri, Apr 12, 2019 at 6:46 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> Yeah. What you are calling Stage I was calling CombStage and what you were
> calling Pipeline is most similar to what I was calling Stage. I had missed
> that you want all Stage instances to be entirely combinatorial.

 it's not so much that i "want" them to be, it's that if they aren't,
they can't be safely combinatorially chained to produce a valid result
in a single clock cycle.

 i use this... "rule", if you will, to daisy-chain between two and
*four* combinatorial blocks together inside the floating-point add
code.  four... "stages" are combined in a four-long combinatorial
chain here (line 40):

 https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/fpcommon/normtopack.py;h=14814669c857a4d9d9579c725ccac9d742d68d29;hb=fb8d2e66c4b263207d9990bdc542c46d6b37d48e#l40

so that's four "stages" (combinatorial data processing blocks) -
Normalisation, Rouding, Corrections and Packing - that are squeezed
through a "Control Handler" (synchronous ready/valid block, derived
from ControlBase), end result is a single-clock pipeline "stage"
(named FPNormToPack).

the advantage of this approach is that if it's determined that there
is too great a gate delay, all that's needed is: split those
daisy-chains into shorter ones, throw the shorter bits at another
derivative of ControlBase, and the overall pipeline goes up by one
cycle...

.... *with very little coding effort*.

unfortunately, it's not quite that simple (that's what pipeline.py is
supposed to be for), it's necessary to determine and change the
ispec/ospec, as part of any given (hypothetical) split /
extension-to-overall-pipeline-length.

pipeline.py is supposed to hide even that, transparently, by
dynamically working out the ospec and ispec depending on the runtime
connections.


> In my proposal, I'm thinking of switching the Stage/Pipeline naming to a
> new naming scheme, to avoid confusion coming from semantics already
> attached to those names.

 yes.  i started switching to "Control Handling" and "Data Processing"
a few days ago.  i left in the name "Stage" unfortunately.

> class BreakReadyChainStage:
> >     """A pipeline stage that delays by zero clock cycles and has
> >     ``pred.ready_out`` be the output of a flip-flop.
> >   """
> >
> > this is untrue.  buffer_full is set synchronously, and ready_out is
> > assigned to ~buffer_full combinatorially.  THEREFORE READY_OUT IS
> > SYNCHRONOUS.
> >
> Yeah, ready_out is synchronous. However, when ready_in and ready_out are
> both set, then BreakReadyChainStage delays the data going through it by 0
> clock cycles (I didn't write all the qualifications). RegStage is designed
> to delay by 1 cycle when ready_in and ready_out are set. Both of them delay
> data indefinitely while ready_in is not set.

 it had occurred to me that there may be time-related [unnecessary]
delays associated with BreakReadyChainStage which mean that it works
yet is sub-obtimal.  dan gisselquist warned of this as possibility
that is common in many efforts to design valid/ready (WE/WRITEABLE +
RE/READABLE) pipeline signalling.

> >
> > can you please acknowledge that you do - or do not - understand this?
> >
> Yeah, makes sense.

 ok cool. whew :)