Search code examples
vhdlflip-flopghdlgtkwave

signal drops to undefined while all related signals are defined


I am writing a process that has to look for every incoming bit, keep track of wether or not the total amout of ones received is 1 and, when the time comes has to compare the value to a reference value. The process is the following:

parity_tester : process(clk, sub_rst, barrel_data_in, barrel_enable, parity_test, parity_ref)
        variable last_known_enable      : boolean := false;
        variable last_known_data        : STD_LOGIC := '0';
        variable parity_error_out       : STD_LOGIC := '0';
        variable parity_ref_reg         : STD_LOGIC := '0';
        variable even                   : STD_LOGIC := '1';
    begin
        if sub_rst then
            last_known_enable   := false;
            last_known_data     := '0';
            parity_error_out    := '0';
            even                := '1';
        elsif rising_edge(clk) then
            if barrel_enable then
                last_known_enable   := true;
                last_known_data     :=  barrel_data_in;
            else
                if last_known_enable then
                    last_known_enable := false;
                    if last_known_data = '1' then
                        even := not even;
                    end if;
                end if;
            end if;

            if parity_test then
                case parity_bit_in_type is
                    when 0 =>
                        parity_error_out := even xnor parity_ref;
                    when 1 =>
                        parity_error_out := even xor parity_ref;
                    when 2 =>
                        parity_error_out := parity_ref;
                    when 3 =>
                        parity_error_out := not parity_ref;
                    when others =>
                        parity_error_out := '1';
                end case;
            end if;
        end if;
        parity_error <= parity_error_out;
    end process;

Here I run into a problem: all signals as defined in the process sensitivity list are defined, but according to GHDL (the simulator) the value changes to undefined whenever parity_test goes to true: Signals What am I doing wrong?

I removed what was here because when I changed to my laptop, the error changed: its about the case switch. I still do not get why. parity_bit_in_type is a generic Natural with a range (0 to 3). If I take out the statement I need (0 in this case) and remove the case thingy, everything works as expected. WebPack ISE does not seem to complain about it, so it starts to feel like a bug in GHDL.

GHDL versioning:

/Downloads/ghdl-gcc-git » ghdl --version
GHDL 0.34dev (20151126) [Dunoon edition]
 Compiled with GNAT Version: 5.3.0
 mcode code generator
Written by Tristan Gingold.

Copyright (C) 2003 - 2015 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

A minimal example which shows the same behaviour

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity uart_receiv_parity is
    generic (
        parity_bit_in_type      : Natural range 0 to 3
    );
    port (
        rst                     : in    boolean;
        clk                     : in    STD_LOGIC;
        parity_error            : out   STD_LOGIC  -- Signals that the parity check has failed, is zero if there was none
    );
end entity;

architecture Behavioral of uart_receiv_parity is
begin
    parity_tester : process(clk, rst)
        variable parity_error_out       : STD_LOGIC := '0';
    begin
        if rst then
            parity_error_out    := '0';
        elsif rising_edge(clk) then
            case parity_bit_in_type is
                when 0 =>
                    parity_error_out := '1';
                when 1 =>
                    parity_error_out := '0';
                when 2 =>
                    parity_error_out := '1';
                when 3 =>
                    parity_error_out := '0';
                when others =>
                    parity_error_out := '1';
            end case;
        end if;
        parity_error <= parity_error_out;
    end process;
end Behavioral;

Solution

  • So, it was my fault after all: in the testbench the signal was driven from two sources. Therefore a '1' resulted in the signal being driven by both a '1' and a '0', leading to an 'x'. When the signal was supposed to be '0', the output was actally zero.