[libre-riscv-dev] using a stage chain in a stage
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Jun 4 02:37:55 BST 2020
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>
> > > 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
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/
> > ctx will automatically pick up the context, which contains op, which is
> > 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
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
More information about the libre-riscv-dev