[libre-riscv-dev] partitioned compare and mux

[Luke Kenneth Casson Leighton]

On Saturday, February 8, 2020, Michael Nolan <mtnolan2640 at gmail.com> wrote:

>
> So right now, as I understand it the adder works like this. Assume I
> want to add 3 3-bit partitions, with a partition mask of 0b10. With no
> carry in it looks like this (I added extra 0s on both ends)
>
> Mask:      1   0
> A:     0XXX0XXX1XXX0
> B:     0YYY0YYY0YYY0
>
> where X and Y are the data


when you say "as of now", once the zeros are added... yes.

see https://libre-riscv.org/3d_gpu/architecture/dynamic_simd/add/
because what you drew above is near identical, actually we should document
it there.

so let's say A is 0XXXPXXXPXXX0 where P means the appropriate inverted
partition bits, see below as to why...



> To add a carry in to both of the partitions, I think something like this
> would work:
>
> Mask:
> A:     0XXXCXXX1XXXC
> B      0YYYCYYY0YYYC
> effect   +1      +1
> out:   oZZZoZZZ0ZZZ0
>
> where X and Y are the inputs, C is the carry bit, Z is the result, and o
> is the carry out bits


... yes along these lines except (carrying in from above) i was thinking to
try (this may be wrong):

A = 0XXXPXXXPXXX0
B = 0YYYCYYYCYYYC

the duplication of C in A that you added has me confused.

oh it's to stop accidental propagation isn't it?  hmmm... well, see how you
get on.

i will edit the add simd wiki page to reflect this, if you could correct it?


> Adding the carry bits where I put them generates an extra +1 in the data
> to the left. Additionally, if there's a carry out in the partition to
> the right, it'll get propogated into that bit and stop, and can be
> extracted into a carry out register


yes, ripple propagate it from the  MSB of the partition back down to the
LSB of the partition, using one of those Mux chains. similar to RippleLSB
except it should *pass* the MSB down rather than set all bits.


>
> > i.e. the numbers attempting to be added had been divided up 8-16-8
> > (partition = 101) and yet the carry_in was set for a 16-16?  i.e. the
> > carry was not 0N0N?  that would be bad.
>
> Hmm, yes. I think ANDing it with the partition mask and an extra 1 would
> suffice...
>
> In the above example, if my partition mask is 10, ANDing the carry in
> with 101 would give a valid result.


ok great

l.



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