[libre-riscv-dev] using a stage chain in a stage

[Luke Kenneth Casson Leighton]

On Thursday, June 4, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:

> On Wed, Jun 3, 2020 at 6:20 PM Luke Kenneth Casson Leighton
> <lkcl at lkcl.net> wrote:
> >
> > On Thursday, June 4, 2020, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> >
> > > I'm trying to build the div pipe, however, the ispec and ospec need to
> > > be different than the currently existing code since that is FP
> > > specific, there needs to be additional io signals that are not
> > > included in all the FP*Data classes. Additionally, I don't want to
> > > just overwrite the existing FPDiv pipe code since I'm not planning on
> > > adding FP div support right away, and the code needs to be refactored
> > > somewhat since the FPdiv pipe code is currently generic over being
> > > 16/32/64-bit at compile-time and the new code will need to be able to
> > > dynamically switch between them at runtime, once FP is added again.
> >
> >
> > ah we're not doing dynamic partitioning.  we are doing 64 bit only,
> > standard POWER9 and will refactor later.
>
> I'd assume, once we add FP support again, you want to support more
> than just fp64, fp32 and fp16 would be nice too even if not
> dynamically partitioned. :)


:)

the problem comes when the dynamic repartitioning hits mantissa and
exponents that *change* in bitsize.

believe it or not, IBM actually do this in their POWER9 core.  paritioned
FP.

Michael and i looked at this and it means statically allocating the largest
size of mantissa and exponent signals then ignoring *parts* of those bits
depending on the exponent sizes etc. dynamically.

it all got horribly complicated for shift and we left it for now.




>
> > > Luke, or whoever's available, can you give me an example of a
> > > combinatorial stage chain that is used inside a single stage without
> > > being wired as the inputs and outputs, along with getting all the
> > > pipekls stuff connected properly?
> >
> >
> > i placed a cookie cut version here already:
> >
> >
> > https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/
> div/pipeline.py;hb=HEAD
> >
> > ctx will automatically pick up the context, which contains op, which is
> the
> > operand data structure.  you should stick with CompALUSubset for now.
>
> Ok, so I guess the idea is to not use the ieee754.fpdiv code for now
> and just write a whole bunch of new code that uses
> ieee754.div_rem_sqrt_rsqrt?


yes exactly.

l.



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