1

Does anyone know how to calculate the sign of a number in carry-save format, i.e. with a virtual sum and virtual carry, without adding them together? A verilog example would be ideal. Thanks!

Tom Bell
  • 489
  • 2
  • 6
  • 15
  • 2
    From http://en.wikipedia.org/wiki/Carry-save_adder: "We still do not know whether the result of the addition is larger or smaller than a given number (for instance, we do not know whether it is positive or negative)." In other words, you'd still need a full-length ripple-carry adder combining the virtual sum and carry. For a better solution we would have to know more about the context. E.g. 'Montgomery multiplication' proposed in the same Wikipedia article may perform better, but only in specific situations. How about some details? – Ruud Helderman Dec 29 '13 at 22:54

1 Answers1

4

Unsigned version: Compare two numbers (my warmup):

Of course you have to go through some of the numbers, but just by starting from the most significant bit (I assume we talk about unsigned numbers). The algorithm is sort of a carry-save algorithm but backwards:

An example:

0001111010101 = the number to compare with
0000211002000 = the carry save number

start from top

0 = 0
0 = 0
0 = 0
1 > 0   - ops! keep the compare-number
0 = 2 - phew! (02 = 10)
1 = 1 
1 = 1 
0 = 0 
0 = 0
1 < 2 :: aha! Carry save number wins!

When we talk about signed numbers, you want to make sure that the most significant bit is set (and do not care about any other result), or rather eliminate the possibility that lower carry-sign bits influence on the result.

When you add two numbers the only possibility for them to change a bit higher than they are is that one of them is that they have more than one bit set at an individual bit. Hence, as soon as you find an occurenct where both of the bits are zero, you can be sure that you will have a positive (not overthrowing number).

An algorithm for the sign would be answering the question "can the sum of the lower bits change in carry and sign numbers change the bit i'm looking at right now?"

This would happen when there are two bits set in one position, it and the algorithm could terminate when both the carry and the sign-bit are 0:

       Sign bit
       v
Carry: 100010010000
Sign : 011101110000

would be treated: The sign bit is set. 6 bits below have a positive XOR. The fifth bits (from left) are both set. The sign will change. (can it change once again if the least significant bits are different? yes, as long as the XOR chain gives 1).

       Sign bit
       v
Carry: 000001111111
Sign : 011101111111

Here the sign bit are not set. The three following bits gives XOR=1, continue. The eight bit from left are both zero. The sign bit cannot be changed.

A very sketchy logic-gate implementation would therefore be:

THESIGN = false

loop through the numbers SIGNBIT, CARRYBIT from highest (sign) bits downwards:
    when  XOR(SIGNBIT, CARRYBIT) = 1, continue
    when  AND(SIGNBIT, CARRYBIT) = 1, flip THESIGN bit, continue
    when NAND(SIGNBIT, CARRYBIT) = 1, stop the evaluation, return THESIGN.
claj
  • 5,172
  • 2
  • 27
  • 30
  • Your first calculation is incorrect; on the 4th and 5th digit, 11 in binary is *not* equal to 02 in carry-save. You can tell by converting the two numbers to decimal: 0001111010101 = 981, 0000211002000 = 720; the carry save number is the lesser. As for your algorithm for the sign, I guess this could be a nice idea for a *serial* binary adder. In a regular (parallel) adder, there are no loops; you always have to keep in mind the worst-case scenario. And that still requires you to go through *all* bits; just like a (relatively slow) ripple-carry adder would. – Ruud Helderman Jan 05 '14 at 16:23
  • Thanks for pointing out the error in my carry-sign numbers, I will try to get how they work better. Regarding the serial adder you are correct but worst case is still quicker given you have just 1 bit sign + (log2 n bits) counter. The worst case will only happen in the distributions having exactly n bit set, ie 2^n combinations out of 2^(2*n) combinations. All other combinations will terminate earlier. worst case occurs in 1/2^n cases, the mean (given fully random numbers) is much less than that, 25% chance of termination per step, to be exact. Verilog is no ordinary CPU, every bit counts. – claj Jan 07 '14 at 13:17
  • (to assume the numbers are full random are a bit optimistic, though - if they have a logarithmic distribution, the termination of the algorithm is not 25% per step but increases per step). – claj Jan 07 '14 at 13:23
  • But at closer thought, the chance on terminating on random numbers are just 25%, the potential saving at randomly distributed bits are less than in my first comment. – claj Jan 19 '14 at 23:40