[libre-riscv-dev] partitioned compare and mux

[Michael Nolan]

Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes:

> On Fri, Feb 7, 2020 at 10:30 PM Jacob Lifshay
> <programmerjake at gmail.com> wrote:
>>
>> On Fri, Feb 7, 2020, 14:23 Luke Kenneth Casson Leighton
>> <lkcl at lkcl.net>
>> wrote:
>>
>> > ... damn, you're right.  yes.  we'll need to have the ability to
>> > drop-in multiple extra carry bits in at various points.
>> >
>> > oh wait: i know.  yes, if you look at the way that the partitioning
>> > works, extended-A is set up to have the partition points (inverted)
>> > inserted in, however B very deliberately has *zeros* inserted in.
>> > if
>> > instead the "carry_in" is inserted into those points (the
>> > carry_in[0]
>> > still has to be added in as a "pre-LSB") then that solves that one.
>>
>>
>> we need to make sure that carry isn't accidentally propagated from the
>> previous partition,
>
> yes, this bit is where i get confused: this last bit is the one that
> needs to become the carry-out... yes, as well as not accidentally
> propagated.

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

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

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

>> also, if a particular partition is merged with the
>> previous partition, the carry in needs to be masked off to avoid
>> accidentally adding a carry when there was none.
>
> ok so one of the conditions would be that the carry_in is only
> relevant at the beginning of the partition.  i'm tempted to suggest
> that if a carry bit _is_ set in the middle of a partition, it would be
> a hardware-fault.
>
> 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.

--Michael