0

So I've been working on some homework for my VHDL course and I can't seem to understand this problem. The point here is to create the adder/subtractor of an ALU that works both on 2's complement and unsigned 32-bit buses, which is why I have a condition called sub_mode ( A - B = A + !B + 1 ) which will also be the carry-in when activated. The rest of the different inputs and outputs are pretty self-explanatory. My problem is with the testbenching of such component where, even though carry_temp and r_temp have been initialized in declaration section of the architecture, end up showing up undefined. I have guessed that it is due to the for loop within the process screwing everything up. Would that be an accurate guess? And if yes, is it possible to proceed to add two bit buses together without having to fully create an n-bit adder made from n 1-bit adder components?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity add_sub is
port(
    a        : in  std_logic_vector(31 downto 0);
    b        : in  std_logic_vector(31 downto 0);
    sub_mode : in  std_logic;
    carry    : out std_logic;
    zero     : out std_logic;
    r        : out std_logic_vector(31 downto 0)
);
end add_sub;

architecture synth of add_sub is

signal cond_inv : std_logic_vector(31 downto 0);
signal carry_temp : std_logic_vector(32 downto 0) := (others => '0');
signal r_temp : std_logic_vector(31 downto 0) := (others => '0');

begin           
behave : process(a,b,sub_mode)
begin 
    if sub_mode = '1' then 
        cond_inv <= b xor x"ffffffff";
    else
        cond_inv <= b;
    end if; 
    carry_temp(0) <= sub_mode;
    for i in 0 to 31 loop
        r_temp(i) <= a(i) xor cond_inv(i) xor carry_temp(i);
        
        carry_temp(i+1) <= 
            (a(i) and cond_inv(i)) or
            (a(i) and carry_temp(i)) or
            (cond_inv(i)and carry_temp(i));
    end loop;
    if r_temp = x"00000000" then 
        zero <= '1';
    else 
        zero <= '0';
    end if;
    r <= r_temp;
    carry <= carry_temp(32);
end process behave;
end synth;
Thomas Monchal
  • 1
  • 1
  • `carry_temp` and `r_temp` are both assigned from inputs. Are you sure you initialised those values in the testbench? Nothing to do with the look. Each bit will be assigned individually. – Tricky Sep 30 '20 at 21:28
  • IEEE Std 1076-2008 14.7.3.4 Signal update "A *net* is a collection of drivers, signals (including ports and implicit signals), conversion functions, and resolution functions that, taken together, determine the effective and driving values of every signal on the net." Where are the drivers? 14.7.5.2 Initialization "The initialization phase consists of the following steps: ... f) For each nonpostponed process P in the model, the following actions occur in the indicated order: 1) The process executes until it suspends." Initialization will frequently overcome the default initial values. –  Oct 01 '20 at 00:23
  • Also see 11.3 Process statement and 10.2 Wait statement to properly construct the sensitivity list of the `behave` process. Provide a [mcve]. –  Oct 01 '20 at 00:33
  • If you are going to write this code in a single process, then any temporary that you need updated immediately needs to be a variable. – Jim Lewis Oct 01 '20 at 06:08
  • Why not loose the loop and carry_temp and simply write, (Carry_temp, r_temp) := ('0' & A) + cond_inv + carry_in(0) ; – Jim Lewis Oct 01 '20 at 06:11
  • This would be trivial to fix with a usable simulator. Find the drivers for a bad signal, find the one which is unknown, trace it back. – EML Oct 01 '20 at 06:50
  • With a simple testbench to drive inputs and fixing the sensitivity list [your adder/subtractor works](https://i.stack.imgur.com/0tS4J.jpg). Help your readers reproduce the problem. –  Oct 01 '20 at 08:40

0 Answers0