[libre-riscv-dev] partitioned compare and mux
mtnolan2640 at gmail.com
Sat Feb 8 01:42:21 GMT 2020
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>
>> > ... 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
>> > 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
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
where X and Y are the data
To add a carry in to both of the partitions, I think something like this
effect +1 +1
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
In the above example, if my partition mask is 10, ANDing the carry in
with 101 would give a valid result.
More information about the libre-riscv-dev