GTKW Unable to block on application (GHDL macos)

Question

I am able to successfully analyze and run a simple VHDL counter in GHDL on macos, but when launching GTKW, the use of a generic causes problems.

The error message is

Unable to block on application (GetProcessPID() returned 184467095516)

Any ideas what this means or what gives rise to this error? (Couldn't find anything Googling it)

It seems to be connected to this line

 signal count: unsigned (G_NBITS-1 downto 0)

From this code segment

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

entity counter_simple is
generic(
       G_NBITS : integer range 1 to 32 := 3
     );
port(
    clk : in std_logic;
    reset_n : in std_logic;
    --count_out : out std_logic_vector(G_NBITS-1 downto 0)
    count_out : out std_logic_vector(2 downto 0)
  );
end;

architecture rtl of counter_simple is

--signal count: unsigned (G_NBITS-1 downto 0)
-- ABOVE LINE CRASHES gtkwave
-- Unable to block on application (GetProcessPID() returned 184467095516)

-- so instead:
signal count: unsigned (2 downto 0);


begin

 counting : process (clk, reset_n)
 begin

 if (reset_n = '0') then
   count <= (others => '0');

 elsif rising_edge(clk) then
      count <= count +1;

 end if;
 end process;

--count_out <= std_logic_vector(count(G_NBITS-1 downto 0));
count_out <= std_logic_vector(count(2 downto 0));

end rtl;

Printing the counter with report, in a testbench (around this counter) is fine in both cases, i.e. in both cases the counter runs 0..7.

So the simulation runs but there appears to be something offensive in the .ghw file.

Answer 1

I haven't had much luck with answers here, but I did read-up on the .ghw file that is output by GHDL, and it is a custom format readable by GTKW.

I tried an alternative format, vcd, and that seems to be fine:

Instead of the default

  ghdl -r counter_simple_tb --stop-time=10ns --wave=counter_simple.ghw

Use VCD

  ghdl -r counter_simple_tb --stop-time=10ns --vcd=counter_simple.vcd

(Note: you have to use the --vcd switch. Filename extension alone is not enough)

As a workaround this will do.

Hopefully this helps others stuck on this too.

It's of course possible that all this has been fixed in the meantime, as the macos binary for GHDL (v 0.29, 32bit) is quite a few versions behind the latest (v 1.0)

$ ghdl -v
GHDL 0.29 (20100109) [Sokcho edition]

and I am running it on a 64bit machine.