[libre-riscv-dev] partitioned compare and mux

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri Feb 7 22:23:00 GMT 2020


(hi michael i got half way through this and realised it's more
complicated than it seems)

On Fri, Feb 7, 2020 at 9:17 PM Michael Nolan <mtnolan2640 at gmail.com> wrote:
>
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> writes:
> >>
> >> My point is that subtract and negate are kind-of special cases of
> >> addition, it seems better to generalize all the way to add with
> >> carry-in/out and then build a PartitionedAddSub built around the
> >> extended PartitionedAdder that does the carry-in (with it optional for
> >> borrow-in)
>
> I agree, this makes more sense than a separate subtractor. I need to
> check this for POWER, but I remember the PowerPC has a true carry bit,

POWER === PowerPC.

> so a subtract with borrow is exactly the same as an add with carry,
> except that the B (actually A, because it only has a "subtract from")
> input is inverted.

ok.

> >
> >
> > we're going to need this for Power, they have carry in and out
> >
> > so would that make sense to be just two bits extra, one at the LSB, one at
> > the MSB?
> >
> > the A being Cat(0, actual_a, carryin) err maybe the other way round
> > (carryin, actual_a, 0)
> >
> > and the B being (0, actual_b, 0)
> >
> > then the output is result[1:-2] and the carryout us result[-1]
> >
> > something like that?
> >
>
> Are these extra bits on the input?

given that verilog (and anything else) doesn't have "add with carry",
then yes.  one extra bit at the beginning of the input, and one extra
zero at the end (above the MSB) of A and B in order to make sure that
the last bit of the result is created.

> Carry_in is going to need to get
> propagated (or not, depending on the partition bits) to each partiton of
> the adder in order to do subtraction properly.

rrright.  okaay, so we actually need (for when we do PowerISA) a
*separate* vector of "carry_in" bits.  this will be the same width and
the exact same thing as the "mask".  output will also be a vector of
"carry_out" bits.  but let's not get concerned with that right now.

> It makes sense to me to
> have it as a separate input bit (or bit vector if we wanted to be fancy
> I guess).

yes... however this is the low-level function (the actual adder /
subtractor) you're thinking of the high-level API (PowerISA) which is
out of scope for current discussion: i only mentioned it in passing
*because* PowerISA has carry-in and carry-out.

> I think it should be possible to exploit the existing mechanism for
> carries in the partition to generate the carry in signal, by setting the
> extra bits A and B when the partition is closed. This would generate a
> carry into the next bit.

... 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.

don't know about carry_out, though.

> > ok so a selectable Const from the constructor, you mean?  do we need a
> > "dynamic" add/sub or is it enough to have something that generates optimal
> > static code
>
> Optimal static code I think would be ok, yosys can optimize out the
> unused inputs and gates

cool.

it got a little more complicated (above) though.

l.



More information about the libre-riscv-dev mailing list