[libre-riscv-dev] buffered pipeline

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Mar 15, 2019 at 12:58 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Thu, Mar 14, 2019, 17:48 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> >
> > On Thu, Mar 14, 2019 at 6:20 PM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > If that is still too much, we can change the simple stage so it deasserts
> > > input.accepting when output.accepting is deasserted even if it is empty
> > at
> > > the moment. that would change the simple stage so the *.accepting signals
> > > are directly connected together.
> >
> >  yes, i think this would work.
>
> I do prefer the current system since it fills bubbles in the pipeline when
> a later stage stalls, increasing pipeline utilization.

 did you notice that dan's example does exactly the same thing?

the difference is that it conforms to a very important additional
design criteria which is that the STB signal travels *with* the data,
on the same clock.  this is an extremely important design criteria
that ensures that such stages may be chained together to any arbitrary
length.

it turns out that it's the protocol used in AXI4 as well as many other places.

> >   i'd also like to see what happens when
> > a stage itself determines that it has to stall.  for example, the
> > FPDiv will have several pipeline stages that don't stall, and one that
> > will loop for anything up to 50 cycles.
> >
> I'll build a few demo pipelines to show how it would work.

 do make them as unit tests.  that's the other purpose of unit tests:
to be working examples.

> I could add a StallIsolatorStage that isolates the stalling behavior and is
> a 0-cycle passthrough when not stalling and a single cycle delay when
> stalling as previously discussed.

 that would be very interesting to see.

> I'd also build a integer divider that stalls as a stalling demo, though it
> might be more productive to build a simple stalling load/store unit.

 agreed, LD/ST would be better, as it's an area not yet explored, and
we need it.

l.