[libre-riscv-dev] Vulkanizing

[Jacob Lifshay]

On Tue, Feb 18, 2020, 23:58 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Wednesday, February 19, 2020, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > On Tue, Feb 18, 2020, 23:20 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > On Wednesday, February 19, 2020, Jacob Lifshay <
> programmerjake at gmail.com
> > >
> > > wrote:
> > >
> > > > On Tue, Feb 18, 2020, 22:49 Luke Kenneth Casson Leighton <
> > lkcl at lkcl.net>
> > > > wrote:
> > > >
> > > > > On Wednesday, February 19, 2020, Jacob Lifshay <
> > > programmerjake at gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > That is 8 flops/core/cycle of fp32, 16 for fp16, and, depending
> > > > > > on how we implement it, either 2 or 4 flops/core/cycle of fp64.
> > > > >
> > > > > 2 because ... no 4 if you count FMAC as 2, and we can do 2 per
> clock
> > @
> > > 64
> > > > > bit.
> > > > >
> > > > > the odd ALU will do 2FMAC FLOPS @ 64 bit, the even likewise.
> > > > >
> > > >
> > > > The idea was that we could have the 128-bit ALU do 2xfp64 or, since
> > fp64
> > > is
> > > > much less important and takes lots of area, just 1xfp64.
> > >
> >
> > it could work by having just one half support fp64, the other half could
> > still run 2xf32 or other combinations.
>
>
> that gets messy because the Function Units are designed to hold 32 bit data
> ready for 32 bit operations.
>
> the way 64 bit works is to have 2 neighbouring 32 bit Function Units
> "temporarily synchronise" to handle a 64 bit op.
>
> one FU holds 32 HI
>
> the other holds 32 LO.
>
> the partition gate is opened to make a 64 bit op, and job done.
>
> 32 HI result goes into HI regfile lane, 32 LO result goes into LO regfile
> lane.
>
>
>
> to do 64 bit on a 32 bit partition will be a frickin nuisance.
>

Actually, what I had meant was to support only the following two 128-bit
alu modes (ignoring 8 and 16-bit):

| 32 | 32 | 32 | 32 |
| 64 ---- | 32 | 32 |

Not: | 64 | 32 | 32 | 32 |

Jacob