[libre-riscv-dev] buffered pipeline

[Jacob Lifshay]

I was researching pipeline designs some more and my design is exactly
equivalent to Chisel's DecoupledIO except that my sendable is named valid
in Chisel and my accepting is named ready in Chisel.

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

I greatly prefer to use something other than stb or strobe for the name as
I find stb to be totally unintuitive and strobe to be somewhat unintuitive.
i'm perfectly fine switching to ready and valid; if chisel uses
ready/valid, it's widespread enough that I don't think anyone reading it
for the first time will have trouble understanding it.

On Thu, Mar 14, 2019, 18:39 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> ---
> 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.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>