How to design a simple Adder with separate carry and borrow flags?

Question

I am implementing a simple adder. However, I have a need for a bit of a unique twist.

What I'm implementing is a "roll over" feature across a Code Segment(CS) register and an Instruction Pointer(IP) register. So, when you do a relative jump by +20, and IP is 254, IP will end up rolling over to 18, and CS will end up incrementing by 1.

This part is easy, the hard part is the opposite direction. Detecting a borrow for when, say the jump is -20 and IP is at 0, it needs to decrement CS by 1 and make IP roll-under to 236.

So far my code is

entity carryover is 
  port(
    DataIn: in std_logic_vector(7 downto 0);
    SegmentIn: in std_logic_vector(7 downto 0);
    Addend: in std_logic_vector(7 downto 0); --How much to increase DataIn by (as a signed number). Believe it or not, that's the actual word for what we need.
    DataOut: out std_logic_vector(7 downto 0);
    SegmentOut: out std_logic_vector(7 downto 0);
   );
end carryover;

architecture Behavioral of carryover is
  signal temp: std_logic_vector(8 downto 0);
begin
  --treat as unsigned because it doesn't actually matter for addition and just make carry and borrow correct
  temp <= std_logic_vector(unsigned("0" & DataIn) + (unsigned)Addend);
  DataOut <= temp(7 downto 0);
  SegmentOut <= unsigned(SegmentIn) + 1 when (not temp(8)) and (not Addend(7) 

end Behavioral;

But I can't figure out how to detect borrows. Is there a clean way to do this?

Update

My new code is this:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use work.tinycpu.all;

entity carryover is 
  port(
    EnableCarry: in std_logic; --When disabled, SegmentIn goes to SegmentOut
    DataIn: in std_logic_vector(7 downto 0);
    SegmentIn: in std_logic_vector(7 downto 0);
    Addend: in std_logic_vector(7 downto 0); --How much to increase DataIn by (as a signed number). Believe it or not, that's the actual word for what we need.
    DataOut: out std_logic_vector(7 downto 0);
    SegmentOut: out std_logic_vector(7 downto 0)
--    Debug: out std_logic_vector(8 downto 0)
   );
end carryover;

architecture Behavioral of carryover is
  signal temp: std_logic_vector(8 downto 0);
begin
  --treat as unsigned because it doesn't actually matter for addition and just make carry and borrow correct
  process(DataIn, SegmentIn,Addend, EnableCarry)
  begin
    temp <= std_logic_vector(signed('0' & DataIn) + signed(Addend(7) & Addend)); 
    if (EnableCarry and ((not Addend(7)) and (DataIn(7)) and temp(8)))='1' then 
      SegmentOut <= std_logic_vector(unsigned(SegmentIn)+1);
    elsif (EnableCarry and (Addend(7) and (not DataIn(7)) and temp(8)))='1' then 
      SegmentOut <= std_logic_vector(unsigned(SegmentIn)-1);
    else
      SegmentOut <= SegmentIn;
    end if;
  end process;
  --Debug <= Temp;
  DataOut <= temp(7 downto 0);
end Behavioral;

Addition of signed numbers works as planned, and Temp is always the correct result now, yet SegmentOut is always equal to SegmentIn. I don't understand why because for SegmentIn + 1, I actually hand-computed the inputs for Addend=0x04, DataIn=0xFE, SegmentIn=0x00, and CarryEnable=1 and the if statement equals out to (1 and ((not 0) and 1 and 1))='1' and yet, SegmentOut never changes. Does anyone see a problem with how this is implemented?

When you say "clean" do you mean bitwise checks? Also if you plan on having negative jumps you will probably want to switch to signed arithmetic to ensure the interpreter understands both addition and subtraction might occur. I believe this would be pretty straightforward with if statements but I don't think that is the "clean" solution you are looking for. — Paul Seeb, May 07 '12 at 18:49

Aleh Douhi · Accepted Answer · 2012-05-08T08:50:00.447

0

Overflow occurs when summands sign bits are equal but not equal to sum sing bit:

A = + 12, B = + 4.            A = + 4, B = – 12
А = 0.1100                    A = 0.0100
В = 0.0100                    B = 1.0100
    ------                        ------   
C   1.0000                    C   1.1000
As = Bs, Cs = 1 – overflow    As != Bs - not overflow.

As DateIn is always positive, overflow can occur only with carry (for both positive numbers). So you should change your statement to (and probably unite these two somehow):

SegmentOut <= unsigned(SegmentIn) + 1 when (not Addend(7) and temp(7)); 
SegmentOut <= unsigned(SegmentIn) - 1 when (Addend(7) and temp(7));

Here is a Truth table:

Addend(7) DataIn(7) temp(7)| Carry Borrow
0         0         0      | 0     0
0         0         1      | 1     0
1         0         0      | 0     0
1         0         1      | 0     1

EDIT: as Paul Seeb said:

SegmentOut <= unsigned(signed(SegmentIn) + signed(Addend(7) & Addend(7) & Addend(7) & Addend(7) & Addend(7) & Addend(7) & Addend(7) & "1")) when (temp(7) and CarryFlag);

edited May 08 '12 at 08:50

answered May 07 '12 at 18:36

Aleh Douhi

1,958
1
14
13

1

You can "unite" the two statements into a single adder/subtractor by using signed arithmetic and changing whether you are adding 1 or negative 1 and converting the answer to an unsigned value. – Paul Seeb May 07 '12 at 18:55
@PaulSeeb thanks. Edited my answer. But why should we use signed arithmetic? I don't get it. – Aleh Douhi May 07 '12 at 19:33
I used a slightly adapted version of your code (shouldn't you have been using temp(8) instead of temp(7)? ), but SegmentOut still never changes. Please see the update to me question – Earlz May 08 '12 at 01:16
Nevermind I ended up figuring out that my test code was wrong 0x10 + (-12) instead of 0x10 +(-0x12) :) The only thing that makes this worse than a stupid mistake is I've done this multiple times in my career – Earlz May 08 '12 at 06:32
@Earlz you should analyze sum sign but not carry from sign bit. `temp(8)` - is a carry, `temp(7)` is a sign. Your code works because you test 0x10 and -0x12, but if you try e.g. 0x7F and 0x7F it will not. – Aleh Douhi May 08 '12 at 08:32
@Earlz also you have wrong `and DataIn(7)` in your code. It will always equal to `0`. You should remove `and (DataIn(7))` and `and (not DataIn(7))` from your `if` and `elsif` statements at all :) – Aleh Douhi May 08 '12 at 08:47
@AlehDouhi Using signed arithmatic will implement an adder/subtractor on the board rather than a simple adder circuit. The adder/subtractor can do both while the adder can obviously only add. Depending on the size of the bits going in, the synthesizer might just implement the entire adder/subtractor as a LUT. This can be useful when you need to conserve chip resources. Its worth looking at the post synthesis maps to determine how the board has actually made the components you have coded – Paul Seeb May 08 '12 at 13:20
@PaulSeeb I suppose that all the numbers are presented as two's complement, so just a simple adder is what you need in this case (add and subtract actions are performed by simple add). See http://en.wikipedia.org/wiki/Two's_complement – Aleh Douhi May 08 '12 at 14:01
@AlehDouhi Could you site the resource that says all inputs to adders are passed as twos compliment? I was under the impression that this conversion only happens for signed arithmatic which is why I was suggesting it. – Paul Seeb May 08 '12 at 14:21
@PaulSeeb I made this conclusion from `make carry and borrow correct`. – Aleh Douhi May 08 '12 at 15:07
@Aleh Douhi I see I didn't see that he was passing the values as twos compliment and dealing with it himself. – Paul Seeb May 08 '12 at 19:22
@PaulSeeb: Splitting the cases may be helpful in cases where one must take additional action when a page crossing occurs (e.g. on the 6502, the first fetch after a branch is the address following it; the second fetch combines the old MSB of the address with a computed LSB; a third fetch if necessary combines an updated MSB with the computed LSB [if the old MSB was correct, the third step is skipped]. – supercat Nov 18 '13 at 21:43

How to design a simple Adder with separate carry and borrow flags?

1 Answers1