[libre-riscv-dev] [Bug 267] The efficiency of adder/subtractor

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Tue Apr 7 12:48:38 BST 2020


--- Comment #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jock Tanner from comment #4)
> (In reply to Luke Kenneth Casson Leighton from comment #3)
> > if you can put some links here as to what you're comparing (descriptions,
> > tutorials, gate-level diagrams) i can get up to speed and follow the
> > conversation.
> I mostly rely on a college textbook by David & Sarah Harris, named “Digital
> Design and Computer Architecture”. I read it only in Russian though. The
> book has a very detailed explanation of carry-lookahead adder, with truth
> tables and schematics.

interesting.  well, what we will be relying on is yosys "synth" command
turning things from high-level "we want an N-bit adder" into low-level
"these 4-bit adders and etc. etc. get created".

we are pretty much trusting yosys "synth" to have the optimal state-of-the-art
latest industry-recognised "thing".

> Very roughly speaking, N-bit ripple-carry adder takes a*N transistors and
> b*N time for calculation, while straight-out carry-lookahead adder takes a^N
> transistors and b time. AFAIK in practical ALU design they always make a
> compromise between the two. And I just wonder what kind of compromise could
> be suitable for *reconfigurable*, high-speed ALU.

i honestly have no idea! :)

the basic units will actually be a 64+8-bit add (yes 72 bit).


see the comment description there of how it works

the "partitions" are done via the insertion of those "extra bits".

those "extra bits" will be set to 0 to create a partition, and "1"
to get a roll-over.

so we're not *actually* "partitioning" into completely separate 8-bit adders.

therefore i would hazard a guess that the (underlying 72-bit) adders are
properly optimised by yosys "synth" command to give a decent fast adder,
thus giving us the "best of both worlds".

in other words, a quick analysis leads me to believe that what we're using
is *not* adversely impacted just because it's a partitioned adder.

it has the *functionality* of a partitioned adder but is in fact a 72-bit
"straight" (normal) add.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-riscv-dev mailing list