[libre-riscv-dev] multi-in. multi-out pipeline

[Luke Kenneth Casson Leighton]

On Mon, Mar 25, 2019 at 7:19 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Mon, Mar 25, 2019, 11:31 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > got it!  amazing, actually worked.  complicated as hell, and made the
> > *Pipeline code look like a dog's dinner, stirred with a stick.
> >
> > so i have an idea: create a separate (combinatorial) "not-a-pipeline"
> > that would be put *in between* pipeline stages, as
> > just-another-pipeline, conforming to the same valid/ready/data API.
> >
> that's exactly what I did in CombStage.

 i believe this may be slightly different: i *think* what you're
proposing is to create a multi-in *stage* class, whereas i'm proposing
a multi-in *pipe* class.

 also, in the Stage design that i'm proposing as a [flexible] API
[with *seven* distinct different ways in which it can be used, not
just the one limited variant in src/pipeline.py which is restricted to
Record], the Stage is *not* given access to the ready/valid signals of
the prev/next pipeline instance that it is a member of: ready/valid
handling is the *pipeline's* responsibility.

 earlier i considered a multi-in *stage*, however i realised that with
the complete separation of data (contained within the "Stage") and the
management / flow *of* the data (by the Pipeline class), it would not
be possible to have a multi-in [multiplexing] *stage*, because a
multiplexing stage would require multiple ready/valid signals, one per
set of input data, as it's not just the data that gets re-routed, it's
the ready/valid signals as well.

so this is why i initially bashed the Pipeline API into submission by
turning the ready/valid PrevControl into an array.  and, having done
so, and at least gotten it to work, i'm really not happy with the
results.

however now that the unit test works, it's possible to start morphing
the code, and use the unit test to make absolutely sure that the code
continues to work.

i'd definitely like to return BufferedPipeline and UnbufferedPipeline
back to their original non-array versions, and to try creating a full
combinatorial-only multi-input Pipeline class.

turning UnbufferedPipeline into a multi-input variant really was an
absolute pig: i had to add an m.d.sync copy of the multiplexer id to
get it to work, because it turns out that the mid has to keep in
lock-step with the data as it's sync'd.

doing the same thing with BufferedPipeline is not an attractive
proposition.  creating a multi-in Stage is not possible with this
API... so one option left to try.

l.