verilog subtraction does not yield carry out - verilog

Question

I want to design an ALU to perform some operations on two 8bits register ( A , B ) and in order to detect carry_out, I defined a 9bits register as temp and put the results of operation on A,b in that register.
The MSb of that temp register is used as carry out.
Here is a part of my code:
module ALU(input signed [7:0] A, input [7:0] B, input carry_in, input [2:0] acode, output reg [7:0] R, output zero, output reg carry_out);
reg [8:0] temp;
reg [15:0] temp2;
always #(A, B, acode) begin
case(is_shift)
1'b0: begin
case(acode)
3'b000: temp = A + B;
3'b010: temp = A - B;
endcase
R = temp[7:0];
carry_out = temp[8];
Given A = 11100101 and B = 11000111, here is the log:
//addition
A: 11100101 , B: 11000111
acode: 000
R: 10101100
zero: 0, carry_out: 1
//subtraction
A: 11100101 , B: 11000111
acode: 010
R: 00011110
zero: 0, carry_out: 0
In both cases, the 9th bit of temp should be 1 and it's right in the addition case but in the subtraction case, the subtraction is right but the 9th bit of temp is not set to 1.
what is the problem here?
By the way: The effect of declaration of a register as signed is only in shifting and extending, yes? So this problem is not because of A being signed and B being unsigned , right?

Answer 1

The effect of declaration of a register as signed is only in shifting and extending
No, it effects all arithmetic. Although usually if you combine any unsigned or part select bus then it will default back to unsigned arithmetic.
You can not really have one input signed and one not, twos complement arithmetic will simply not work. You at least have to sign extend the signed value and insert a 0 MSB on to the unsigned, making sure it will be evaluated as positive.
Your first example is:
1110 0101 // -27
1100 0111 // -57
1 1010 1100 // -84 (-27 -57)
Second example (subtraction)
1110 0101 // -27
0011 1001 // +57
1 0001 1110 // 30 (ignoring MSB) -226 Including MSB
But note that the output is 1 bit wider, RTL does not give you access to the carry, but rather an extra sum, therefore the inputs are sign extended.
1 1110 0101 // -27
1 1100 0111 // -57
1 1010 1100 // -84
1 1110 0101 // -27
0 0011 1001 // +57
0 0001 1110 // 30
Note in the correctly sign extended subtraction the MSB is 0
But for your addition with the second value unsigned you need a 0 to show it is a positive number, and you will have bit growth of 1 bit:
1 1 1110 0101 // -27
0 0 1100 0111 // 199
0 0 1010 1100 // 172 (-27+199)
Here the extended bit (not a carry) is 0. not 1 as you predicted.