[libre-riscv-dev] pipeline sync issues
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Apr 12 07:42:39 BST 2019
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):
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"
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
.... *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 /
pipeline.py is supposed to hide even that, transparently, by
dynamically working out the ospec and ispec depending on the runtime
> 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 :)
More information about the libre-riscv-dev