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

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=267

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

https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_mul_add/adder.py;h=e1849b4d25fc5ec4fc4473cc02b32f49dd5912b2;hb=77f150cff440bed025e2487b6f0fcda9f529290b#l108

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.