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

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

[Jacob Lifshay]

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.

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?

Somewhat unrelated, I moved all the unused code out of the fpdiv
folder and into the unused folder

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

On Thursday, June 4, 2020, Jacob Lifshay <programmerjake@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.





>
> 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.



> Somewhat unrelated, I moved all the unused code out of the fpdiv
> folder and into the unused folder


ah good, ok.

 l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Jacob Lifshay]

On Wed, Jun 3, 2020 at 6:20 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> On Thursday, June 4, 2020, Jacob Lifshay <programmerjake@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. :)

> > 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?

Jacob

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/div/pipe_data.py;hb=HEAD

sorry, CompLogicalOpSubset.  unless carry-in, sticky overflow etc are
needed, which i don't think they are.

each subset grabs only the fields from the instruction decode
(Decode2Execute1Type) that the pipeline actually needs.

that subset is supposed to be dropped into ctx.op, see IntegerData class.
all ospec and ispec classes derive from IntegerData at the moment.

l.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

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

[Luke Kenneth Casson Leighton]

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

> On Wed, Jun 3, 2020 at 6:20 PM Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
> >
> > On Thursday, June 4, 2020, Jacob Lifshay <programmerjake@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
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev