1

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;
Cheiron
  • 3,620
  • 4
  • 32
  • 63
  • Nope, I do not. Another curious thing is that if I change to parity_error_out := even, the undefined thing does not happen anymore. – Cheiron Mar 23 '16 at 18:50
  • What's you GHDL version and backend? Is the time til the red zone dependent on the input data? Is the red value `U` or `X`? – Paebbels Mar 23 '16 at 19:12
  • Does the error still occur when you place the process in a new architecture and apply the stimuli to it? – Martin Zabel Mar 23 '16 at 20:05
  • The value is `X`. The GHDL version is 0.34dev, the backend is GCC. I do not understand the question about the red zone. Also: it seems to be related to the generic/case combo. – Cheiron Mar 23 '16 at 20:17
  • I will try my best. The backend was GNAT, btw. My bad. – Cheiron Mar 23 '16 at 20:42
  • I had removed barrel_data_in, barrel_enable, parity_test and parity_ref from the process sensitivity list (only used inside elsif rising_edge(clk)). See [parity_thing.vhdl](https://www.dropbox.com/s/tlz38swbcwx3lgq/parity_thing.vhdl?dl=1). –  Mar 23 '16 at 22:16
  • Your code does not hit it in my versions also. It is a bit of a pain, because it only gets triggered when the variable inside the case is a generic (signal or const will not work), but not every case with a generic will hit it. I am still trying to figure out how to get the sample concise. – Cheiron Mar 23 '16 at 23:44
  • I tried parity_bit_in_type as a generic with (default) values from 0 to 4 both as an unconstrained and a constrained natural, none of those caused the problem (0.33 llvm). –  Mar 24 '16 at 02:16
  • I just added the full code that causes problems. Changing the slightest things makes the issue not happen anymore. GHDL 0.31 from the Ubuntu repo's has the issue (https://launchpad.net/~pgavin/+archive/ubuntu/ghdl), as has the AUR dev edition (https://aur.archlinux.org/packages/ghdl-gcc-git/) – Cheiron Mar 24 '16 at 10:35
  • You're going to need to provide a [Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve), what's missing is a testbench providing stimuli reproducing the error. [My results vary](http://i.stack.imgur.com/KCnJ2.png) without changing so much as a space in your code and using your generics, ghdl-0.33 llvm). A reproducible [issue](https://github.com/tgingold/ghdl/issues) would be required for a bug fix. See [parity_test_thing.vhdl](https://www.dropbox.com/s/kwohi0jh5gbfmai/parity_test_thing.vhdl?dl=1). –  Mar 25 '16 at 01:08
  • There is a new example in my post which shows the same behaviour on both my setups. – Cheiron Mar 25 '16 at 09:54

1 Answers1

0

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.

Cheiron
  • 3,620
  • 4
  • 32
  • 63