[libre-riscv-dev] 1R1W regfiles

[Jacob Lifshay]

Assuming the VPU load doesn't require 8/16-bit matrix support, the Vulkan
driver doesn't require anything smaller than 32-bit matrices so I think we
could just trap and emulate or split into several micro-ops for non-aligned
8 and 16-bit remapping and just have the compiler avoid non-aligned
8/16-bit operations.

We could share a single multi-stage byte crossbar for load gather/store
scatter and for vector swizzle.

This allows us to treat everything as if it is processed in 32-bit or
larger chunks with either muxing in the old bytes internally in the alu for
forwarding or we could specify that SV muxes in zeros/ones on unused
sub-register elements.


On Wed, Dec 19, 2018, 23:06 Luke Kenneth Casson Leighton <lkcl at lkcl.net
wrote:

> so there's 2 levels of crossbars/multiplexers:
>
> * 4-in 4-out 32-bit from the Hi-odd / Lo-odd / Hi-even / Lo-even banks
> * 4-in 4-out *8*-bit wide for elwidths down to 8 bit
>
> and the idea is:
>
> * pairs of 32-bit Function Units are required to process (store)
> src1/src2 64-bit operands
> * pairs of 8-bit Function Units are also required to process 16-bit
> operands
>
> however... the routing required for *both* 4-in 4-out 32-bit *and* 4-4
> 8-bit is completely insane.
>
> so i had (another) idea: we're going to deploy xBitManip anyway...
> so.. um... why not have the xBitManip ALUs do the actual crossbar
> pre-processing at the 8-bit level?
>
> the only thing is: we will absolutely need operand forwarding, for
> that to work.  the reason: the src1/src2 32-bit-wide data that comes
> out of the regfile banks will be supposed to come in to the *EIGHT
> BIT* Function Unit area, *NOT* the 32-bit Function Unit area, but the
> xBitManip ALUs will be in the *32-bit* FU area.
>
> in some ways it may be easier to have a micro-code operation here, but
> it is absolutely absolutely essential that, unlike "standard"
> processing which normally goes into the register file, the output
> *must* not do so.
>
> or.... perhaps.... hmmmm.... we make the xBitManip ALU actually part
> of the 8-bit Function Units, not the 32-bit ones!
>
> l.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>