Electronic – VHDL Test Bench Help – How to get testbench to output values instead of “unknown”

digital-logicvhdlvivado

I have the following two files, and I'm trying to test the first file. The first file is a simple ALU which handles a variety of functions depending on the value of a selection input. I've played with it on my FPGA and it seems to work as intended (though I haven't checked Overflow's functionality yet). I obviously have not tested every possible output by hand. I intend the testbench to test 4 inputs for each of my ALU functions. The FOR loop in the testbench tries to accomplish this.

Unfortunately, the testbench gives me unknowns for my inputs, and I'm unsure why. This is my first time writing a VHDL testbench, so I'm trying to determine what the error is and why it occurs since I would like to see what my testbench outputs look like.

VHDL FILE

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_signed.all;
use ieee.std_logic_arith.all;

entity ALU is
    port (  S, A, B : in std_logic_vector(3 downto 0);
            Zero, Negative, Carry, Overflow : out std_logic;
            segments : out std_logic_vector(6 downto 0);
            disp_right, disp_left, disp_midright, disp_midleft : out std_logic
        );
end ALU;


architecture behavioral of ALU is

signal sum : std_logic_vector(5 downto 0);

begin
    with S select
        sum     <=  "00"&A when "0000",
                    "00"&(not A) when "0001",
                    "00"&(A and B) when "0010",
                    "00"&(not (A and B)) when "0011",
                    "00"&(A or B) when "0100",
                    "00"&(not (A or B)) when "0101",
                    "00"&(A xor B) when "0110",
                    "00"&(not (A xor B)) when "0111",
                    ("00"&A + B) when "1000",
                    ("00"&A - B) when "1001",
                    '0'&A(3 downto 0)&'0' when "1010",
                    "000"&A(3 downto 1) when "1011",
                    "00"&A(3)&A(3 downto 1) when "1100",
                    "111111" when others;       


        Zero        <=  '1' when (sum = "00000") else '0';
        Negative    <=  '1' when (sum(3) = '1') else '0';
        Carry       <=  '1' when (sum(4) = '1') else '0';
        Overflow    <=   ( A(3) and B(3) ) xnor sum(4);

    with sum(4 downto 0) select
        segments    <=  "0000001" when "00000",--0  
                        "1001111" when "00001",--1
                        "0010010" when "00010",--2
                        "0000110" when "00011",--3
                        "1001100" when "00100",--4
                        "0100100" when "00101",--5
                        "0100000" when "00110",--6
                        "0001111" when "00111",--7
                        "0000000" when "01000",--8
                        "0000100" when "01001",--9
                        "0000010" when "01010",--A
                        "1100000" when "01011",--B
                        "0110001" when "01100",--C
                        "1000010" when "01101",--D
                        "0110000" when "01110",--E
                        "0111000" when "01111",--F
                        "1111111" when others;--misc




    disp_left <= '1';       -- turn the seven-segment display off                   
    disp_midleft <= '1';    -- turn the seven-segment display off 
    disp_midright <= '1';   -- turn the seven-segment display off
    disp_right <= '0';      -- turn the seven-segment display on

end behavioral;

TESTBENCH FILE:

library ieee;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_signed.all;
use ieee.std_logic_arith.all;

entity ALU_tb is
end ALU_tb;

architecture behavior of ALU_tb is
    component ALU is
        port (  S, A, B : in std_logic_vector(3 downto 0);
            Zero, Neg, Carry, Overflow : out std_logic;
            segments : out std_logic_vector(6 downto 0);
            disp_right, disp_left, disp_midright, disp_midleft : out std_logic);
    end component;

Signal A_tb, B_tb, S_tb : std_logic_vector(3 downto 0);
Signal Z_tb, N_tb, C_tb, O_tb : std_logic;
Signal seg_tb : std_logic_vector(6 downto 0);


begin

uut : ALU port map(
    A => A_tb, 
    B => B_tb, 
    S => S_tb,
    Zero => Z_tb, 
    Neg => N_tb, 
    Carry => C_tb, 
    Overflow => O_tb,--this is the letter "O" not a zero.
    segments => seg_tb
    );

    ALU_simulation : process
    begin
       --test loop checks 4 inputs for each select combination. There are 13 select combinations
       --not including the "when others" statement. 
       S_tb <= "0000";
       for i in 0 to 12 loop
           for j in 0 to 3 loop
               A_tb <= "0000";
               B_tb <= "0111";
               wait for 10 ns;
               A_tb <= A_tb + 1;
           end loop;
           wait for 10 ns;
           S_tb <= S_tb + 1;
       end loop;

    end process ALU_simulation;

end behavior;

Best Answer

I just copied your files and ran them is Xilinx ISE. They didn't compile:

Zero, Neg, Carry, Overflow : out std_logic;
Neg => N_tb,

You have Neg instead of Negative in those lines. Correcting those lines resulted in:

I'm rusty in VHDL and this IDE, but maybe thats the issue, and you tried to reload the simulation with an error or something?

You may have actually tried to run simulation on your 'uut' file, not on testbench file. That results in spawning a window with 'Uninitialised' inputs:

P.S.

Overflow => O_tb,--this is the letter "O" not a zero.
segments => seg_tb

Just don't use the O then, type something like ovf, like you did with seg ;)

Related Solutions

Xilinx and VHDL · Why is this INOUT port undefined

Bisg is an INPUT signal not an INOUT despite the fact that it has other uses (driving segment G on the top level).

To see this; reflect that NOTHING in your component actually drives BISG.

So your component is regarded as driving it with an undefined initial level; that is, 'U', and the combination of that 'U' with any external driving level is - as ISIM says - 'U'.

You have 2 options to fix it:

(1) make BISG an INPUT since you aren't driving it. This is the simplest and in this case correct.

(2) Drive BISG in your component with 'Z' - that is, remove the 'U' output from the component. 'Z' means "high impedance : i.e. don't fight whatever external source (your testbench) is driving the pin. This is typically done to allow 2-way communication on a signal. The two ends must agree (somehow) which end is allowed to drive the signal and the other end must drive 'Z'.

In your case, adding the line

BISG <= 'Z';

(after the "begin") to your component BCT should resolve the problem. (Yes, you are modifying the file labelled "do not modify", and the modification WILL disappear when you next compile the schematic to VHDL).

Then re-run the simulation and all should be well.

I do not know if there's a way to implement solution 2 in the schematic - and I don't care : these days the schematic approach is an utter waste of time. Your whole schematic comes down to (the original entity, and)

architecture HDL of BCT is
begin
   Bisg     <= 'Z';
   Bnisc    <= not Bisg;
   sf       <= not Bisg and not A;
   saisdise <= Bisg or not A;
   sb       <= '1';
end HDL;

And simplifies further if Bisg is an input...

Which do you think is faster to create, and easier to read?

EDIT : if you need an output to drive segment G, there's nothing wrong with a separate port G, driven directly from input B, as G <= B; or a wire on the schematic.

Test bench with IO file vhdl

No. Your testbench isn't correct.

You have two superfluous use clauses:

-- use ieee.numeric_std.all;
-- use ieee.std_logic_misc.all;

Your process tb_process should have wait; end loop; allowing the simulation to complete when you've finished processing input stimulus from my_input.txt.

About then you'll notice all your results in my_output.txt are all 0, which is caused by delta cycle delay in assignment to signal z_tb in entity my_and. Your process also has delayed assignments to x_tb and y_tb which need to be taken into account.

No signal update occurs during the execution of any process (and all signal updates occur within processes, concurrent statements are elaborated into process statements or process statements and block statements). Essentially you need to suspend the process before any of these assignments take effect.

The cure is one or more wait statements which will suspend execution. The following shows two, a wait for 5 ns; and a wait for 0 ns;. They can be collapsed in to one wait statement. The purpose is to show that you need at least a delta cycle delay following assignments to x_tb and y_tb taking effect for z_tb to be updated. If there were a delayed signal assignment for z (z_tb) in entity my_and that delay would also be added to the first wait statement.

tb_process:  
    process
        file my_input:  TEXT open READ_MODE is "my_input.txt";
        file my_output:  TEXT open WRITE_MODE is "my_output.txt";
        variable my_line:  LINE;
        variable my_input_line:  LINE;
        variable my_output_line:  LINE;
        variable x_bit:  bit;
        variable y_bit:  bit;
        variable z_bit:  bit;
    begin
        while not endfile(my_input) loop
            readline(my_input,my_line);
            read(my_line,x_bit);
            read(my_line,y_bit);
            x_tb <= to_stdulogic(x_bit) after 5 ns;
            y_tb <= to_stdulogic(y_bit) after 5 ns;
            wait for 5 ns;  -- added
            wait for 0 ns;  -- added
            z_bit := to_bit(z_tb);
            -- report "x_bit = " & bit'image(x_bit);
            -- report "y_bit = " & bit'image(y_bit);
            -- report "z_tb = "  & std_ulogic'image(z_tb);
            write(my_output_line,z_bit);
            writeline(my_output,my_output_line);
            -- wait for 10 ns;  -- removed
        end loop;
        wait;
    end process;

Note the wait for 10 ns; is commented out, it's not needed when your process has a linear model of time allowing signal assignments to take affect (has (an) other wait statement(s)).

The above modification to your process statement with a zero delay model for my_and gives:

more my_output.txt
0
0
0
1

Which is the expected output.

Notice the commented report statements which can be used to debug the process statement. If you don't have enough delay the first report for z_tb will show a 'U'.

Best Answer

Related Solutions

Xilinx and VHDL · Why is this INOUT port undefined

Test bench with IO file vhdl

Related Topic