[libre-riscv-dev] buffered pipeline

Luke Kenneth Casson Leighton lkcl at lkcl.net
Tue Mar 19 11:06:54 GMT 2019


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

On Tue, Mar 19, 2019 at 7:54 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Tue, Mar 19, 2019, 00:38 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > btw just a heads-up, i'm going to need a multi-in, multi-out
> > (crossbar'd) variant of the pipeline, which can be specified to take
> > an array of inputs and an array of outputs.
>
> so, you mean it has multiple ready/valid inputs

 with associated data on each, plus a selection strategy

>  and multiple ready/valid  outputs?

 and associated output paths, plus an identification method as to
where the output is to be routed

> Do you want it to wait for all inputs/outputs or run when any are ready?

 it will be up to the selection strategy (passed in as a class/module)
to decide what proceeds and when.

answer: a hybrid of both, however the hybrid may be done by having
multi-bit "ready" signals that must be all 1s before allowing to
proceed.

i already implemented that in FPGetSyncOpsMod, as a Reservation
Station (Function Unit input latches) has to have an *array* of input
operands... however, agaaaain, it does only one data
passthrough/release every 2 clock cycles....

 i believe that the multi-bit ready signal could be used to
raise/lower the RecvControl i_ready flag.

 the reason for multiple outputs is because the IEEE754 FPU pipeline
may split out special cases early (zero+zero, inf+inf, zero+nan,
nan+nan) etc. etc. which has the interesting side-effect of generating
*two* possible output values on every clock.

 this may or may not be a good idea, as it would mean that the
receiving output latch array has to be dual-ported, to cope.

l.



More information about the libre-riscv-dev mailing list