FPGARelated.com
Forums

Active-HDL Throws Error

Started by Rick C October 19, 2020
My code is assigning an incremented unsigned value to an aggregate so the s=
um and carry can be extracted without duplicating logic or excessive lines =
of code (VHDL can be verbose we all know).  But it seems this one usage mak=
es the Active-HDL simulator complain.  I'm adding an integer 1 to the unsig=
ned counter value after being resized to be 1 bit larger to match the left =
hand side aggregate.  I'll post the code below. =20

It seems the combination of using the left hand aggregate, resized unsigned=
 and the addition/subtraction of an integer is what causes a problem.  I wo=
uld report this to Aldec, but I'm pretty sure they don't have a way to repo=
rt bugs if you are not a customer with a current maintenance contract. =20

-- Test synthesis of counters and carry out flags
library ieee;
use ieee.NUMERIC_STD.all;
use ieee.std_logic_1164.all;
-- use work.Common.all;

entity VHDL_test is
  generic(
	CLK_HZ : REAL :=3D 33.554432E6 );
  port(
    -- Clk			: in  std_logic :=3D '1';
    Cnt_En		: in  std_logic :=3D '1';
	Test_Out_a	: out std_logic;
	Carry_Out_a	: out std_logic
  );
end VHDL_test;

architecture TB_ARCH of VHDL_test is
  constant Clock_Half_Period : time :=3D 500 ms / CLK_HZ;  -- 14901 ps;
  constant Cntr_Width : positive :=3D 8;
  constant Cntr_Modulus : positive :=3D 2**Cntr_Width;
  constant One_slv : unsigned(Cntr_Width downto 0) :=3D "000000001";
  signal Clk : std_logic :=3D '1';
  signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) :=3D (other=
s =3D> '0');
begin

  Clk_gen: Clk <=3D not Clk after Clock_Half_Period; -- comment out for syn=
th

  -- (Carry_Out_a, nxt_cnt_a) <=3D RESIZE(Count_a, nxt_cnt_a'length + 1) - =
One_slv;
  (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1;

  test_ag: process (Clk) is
  begin
  	if rising_edge(Clk) then
	  Test_Out_a <=3D Carry_Out_a;
      if (Cnt_En OR not Carry_Out_a) then
	  	Count_a  <=3D nxt_cnt_a;
	  end if;
	end if;
  end process test_ag;

end TB_ARCH;  -- VHDL_test


--=20

  Rick C.

  - Get 1,500 miles of free Supercharging
  - Tesla referral code - https://ts.la/richard11209
On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote:
> My code is assigning an incremented unsigned value to an aggregate so the=
sum and carry can be extracted without duplicating logic or excessive line= s of code (VHDL can be verbose we all know). But it seems this one usage m= akes the Active-HDL simulator complain. I'm adding an integer 1 to the uns= igned counter value after being resized to be 1 bit larger to match the lef= t hand side aggregate. I'll post the code below. =20
>=20 > It seems the combination of using the left hand aggregate, resized unsign=
ed and the addition/subtraction of an integer is what causes a problem. I = would report this to Aldec, but I'm pretty sure they don't have a way to re= port bugs if you are not a customer with a current maintenance contract. = =20
>=20 > -- Test synthesis of counters and carry out flags > library ieee; > use ieee.NUMERIC_STD.all; > use ieee.std_logic_1164.all; > -- use work.Common.all; >=20 > entity VHDL_test is > generic( > CLK_HZ : REAL :=3D 33.554432E6 ); > port( > -- Clk : in std_logic :=3D '1'; > Cnt_En : in std_logic :=3D '1'; > Test_Out_a : out std_logic; > Carry_Out_a : out std_logic > ); > end VHDL_test; >=20 > architecture TB_ARCH of VHDL_test is > constant Clock_Half_Period : time :=3D 500 ms / CLK_HZ; -- 14901 ps; > constant Cntr_Width : positive :=3D 8; > constant Cntr_Modulus : positive :=3D 2**Cntr_Width; > constant One_slv : unsigned(Cntr_Width downto 0) :=3D "000000001"; > signal Clk : std_logic :=3D '1'; > signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) :=3D (oth=
ers =3D> '0');
> begin >=20 > Clk_gen: Clk <=3D not Clk after Clock_Half_Period; -- comment out for s=
ynth
>=20 > -- (Carry_Out_a, nxt_cnt_a) <=3D RESIZE(Count_a, nxt_cnt_a'length + 1) =
- One_slv;
> (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1; >=20 > test_ag: process (Clk) is > begin > if rising_edge(Clk) then > Test_Out_a <=3D Carry_Out_a; > if (Cnt_En OR not Carry_Out_a) then > Count_a <=3D nxt_cnt_a; > end if; > end if; > end process test_ag; >=20 > end TB_ARCH; -- VHDL_test
I tried to report this both to Aldec and to Lattice (the company who provid= ed the "free" software). Neither one has a means of reporting bugs unless = you have an active maintenance account. I've sent both an email. Don't kn= ow if they will ever get back to me or accept my report of the bug. =20 While searching I found a post from 2000 when Aldec had their new Verilog t= ool out. They were paying a bounty for bug reports. I think they let you = use the software for free to find bugs and if you found 10 you got a lifeti= me subscription to the tool. Not sure what you got for lesser quantities.= =20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
On Monday, October 19, 2020 at 10:39:28 PM UTC-6, gnuarm.del...@gmail.com w=
rote:
> On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote:=20 > > My code is assigning an incremented unsigned value to an aggregate so t=
he sum and carry can be extracted without duplicating logic or excessive li= nes of code (VHDL can be verbose we all know). But it seems this one usage = makes the Active-HDL simulator complain. I'm adding an integer 1 to the uns= igned counter value after being resized to be 1 bit larger to match the lef= t hand side aggregate. I'll post the code below.=20
> >=20 > > It seems the combination of using the left hand aggregate, resized unsi=
gned and the addition/subtraction of an integer is what causes a problem. I= would report this to Aldec, but I'm pretty sure they don't have a way to r= eport bugs if you are not a customer with a current maintenance contract.= =20
> >=20 > > -- Test synthesis of counters and carry out flags=20 > > library ieee;=20 > > use ieee.NUMERIC_STD.all;=20 > > use ieee.std_logic_1164.all;=20 > > -- use work.Common.all;=20 > >=20 > > entity VHDL_test is=20 > > generic(=20 > > CLK_HZ : REAL :=3D 33.554432E6 );=20 > > port(=20 > > -- Clk : in std_logic :=3D '1';=20 > > Cnt_En : in std_logic :=3D '1';=20 > > Test_Out_a : out std_logic;=20 > > Carry_Out_a : out std_logic=20 > > );=20 > > end VHDL_test;=20 > >=20 > > architecture TB_ARCH of VHDL_test is=20 > > constant Clock_Half_Period : time :=3D 500 ms / CLK_HZ; -- 14901 ps;=20 > > constant Cntr_Width : positive :=3D 8;=20 > > constant Cntr_Modulus : positive :=3D 2**Cntr_Width;=20 > > constant One_slv : unsigned(Cntr_Width downto 0) :=3D "000000001";=20 > > signal Clk : std_logic :=3D '1';=20 > > signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) :=3D (oth=
ers =3D> '0');=20
> > begin=20 > >=20 > > Clk_gen: Clk <=3D not Clk after Clock_Half_Period; -- comment out for s=
ynth=20
> >=20 > > -- (Carry_Out_a, nxt_cnt_a) <=3D RESIZE(Count_a, nxt_cnt_a'length + 1) =
- One_slv;=20
> > (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1;=20 > >=20 > > test_ag: process (Clk) is=20 > > begin=20 > > if rising_edge(Clk) then=20 > > Test_Out_a <=3D Carry_Out_a;=20 > > if (Cnt_En OR not Carry_Out_a) then=20 > > Count_a <=3D nxt_cnt_a;=20 > > end if;=20 > > end if;=20 > > end process test_ag;=20 > >=20 > > end TB_ARCH; -- VHDL_test > I tried to report this both to Aldec and to Lattice (the company who prov=
ided the "free" software). Neither one has a means of reporting bugs unless= you have an active maintenance account. I've sent both an email. Don't kno= w if they will ever get back to me or accept my report of the bug.=20
>=20 > While searching I found a post from 2000 when Aldec had their new Verilog=
tool out. They were paying a bounty for bug reports. I think they let you = use the software for free to find bugs and if you found 10 you got a lifeti= me subscription to the tool. Not sure what you got for lesser quantities.= =20
>=20 > --=20 >=20 > Rick C.=20 >=20 > + Get 1,000 miles of free Supercharging=20 > + Tesla referral code - https://ts.la/richard11209
Aldec very frequently does not parse legal HDL until it's simplified to its= lowest form. I'd try Questa or VCS.
On 20/10/2020 18:58, Kevin Neilson wrote:
> On Monday, October 19, 2020 at 10:39:28 PM UTC-6, gnuarm.del...@gmail.com wrote: >> On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote:
..
>>> >>> end TB_ARCH; -- VHDL_test >> I tried to report this both to Aldec and to Lattice (the company who provided the "free" software). Neither one has a means of reporting bugs unless you have an active maintenance account. I've sent both an email. Don't know if they will ever get back to me or accept my report of the bug. >> >> While searching I found a post from 2000 when Aldec had their new Verilog tool out. They were paying a bounty for bug reports. I think they let you use the software for free to find bugs and if you found 10 you got a lifetime subscription to the tool. Not sure what you got for lesser quantities. >> >> -- >> >> Rick C. >> >> + Get 1,000 miles of free Supercharging >> + Tesla referral code - https://ts.la/richard11209 > > Aldec very frequently does not parse legal HDL until it's simplified to its lowest form.
I don't think that is the case. I know that in the past XST used to allow illegal VHDL constructs which resulted in Leonardo Spectrum adding a special "XST" switch to stop users complaining but there is no advantage in Aldec having a doggy parser. Also most EDA vendors use the same commercial parsers from Verific. The problem is that most free/student versions are older releases (Mentor does the same, OEM=2019.1, latest=2020.3). So I wouldn't be surprised if this bug has already been fixed in the latest release (I am sure somebody with a commercial license can confirm this). Aldec is pretty good when it comes to VHDL support. Logging this bug however will not help Rick as it will probably take a year for the bug to be fixed and for the free version to get the update. So I would use the simple concatenation syntax which I actually find much easier to read, as they say "KISS", Hans www.ht-lab.com
On Tuesday, October 20, 2020 at 2:44:53 PM UTC-4, HT-Lab wrote:
> On 20/10/2020 18:58, Kevin Neilson wrote: > > On Monday, October 19, 2020 at 10:39:28 PM UTC-6, gnuarm.del...@gmail.c=
om wrote:
> >> On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote: > .. > >>> > >>> end TB_ARCH; -- VHDL_test > >> I tried to report this both to Aldec and to Lattice (the company who p=
rovided the "free" software). Neither one has a means of reporting bugs unl= ess you have an active maintenance account. I've sent both an email. Don't = know if they will ever get back to me or accept my report of the bug.
> >> > >> While searching I found a post from 2000 when Aldec had their new Veri=
log tool out. They were paying a bounty for bug reports. I think they let y= ou use the software for free to find bugs and if you found 10 you got a lif= etime subscription to the tool. Not sure what you got for lesser quantities= .
> >> > >> --=20 > >> > >> Rick C. > >> > >> + Get 1,000 miles of free Supercharging > >> + Tesla referral code - https://ts.la/richard11209 > >=20 > > Aldec very frequently does not parse legal HDL until it's simplified to=
its lowest form. =20
>=20 > I don't think that is the case. >=20 > I know that in the past XST used to allow illegal VHDL constructs which=
=20
> resulted in Leonardo Spectrum adding a special "XST" switch to stop=20 > users complaining but there is no advantage in Aldec having a doggy=20 > parser. Also most EDA vendors use the same commercial parsers from Verifi=
c.
>=20 > The problem is that most free/student versions are older releases=20 > (Mentor does the same, OEM=3D2019.1, latest=3D2020.3). So I wouldn't be=
=20
> surprised if this bug has already been fixed in the latest release (I am=
=20
> sure somebody with a commercial license can confirm this).
I would point out that this is not a compiler error, but a run time error. = I think that is significantly different, i.e. not exactly a parser error m= ost likely.=20
> Aldec is pretty good when it comes to VHDL support. >=20 > Logging this bug however will not help Rick as it will probably take a=20 > year for the bug to be fixed and for the free version to get the update.=
=20
> So I would use the simple concatenation syntax which I actually find=20 > much easier to read, as they say "KISS",
I've already gone with the simpler and shorter right hand side (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1; -- works Modifying any of three things makes it work. Obviously removing the left h= and aggregate works. Replacing the RESIZE as above makes it work. Changin= g the integer literal with an unsigned constant makes it work. In fact, my= constant definition can likely be replaced with a "1" and retain the RESIZ= E, but that's so much more typing than above.=20 I'm trying to report it to Aldec so it can be fixed. They have turned me d= own saying I need to contact Lattice. The way they worded it, I think Latt= ice might be paying them a set price with no updates without paying a lump = sum again. They said, "For the ActiveHDL in the Lattice tools you have to = contact Lattice. Although we provide Lattice with the simulator, we don't h= ave access to it once it is in their tools suite." That's a strange way to= put it, "don't have access".=20 Lattice has not turned me down, but it's a lot of work to get past the guar= d dogs. =20 I'm curious to know if this is fixed in full licensed versions of the simul= ator.=20 --=20 Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
HT-Lab <hans64@htminuslab.com> writes:

> The problem is that most free/student versions are older releases > (Mentor does the same, OEM=2019.1, latest=2020.3). So I wouldn't be > surprised if this bug has already been fixed in the latest release (I > am sure somebody with a commercial license can confirm this).
Actually I downloaded what Intel provides for free today and it's Modelsim 2020.2. But it seems to me that for a long time it was a few Modelsim 10.x, a few years old at least. Rick's example seems to work with that Modelsim, in ghdl too although ghdl doesn't claim full VHDL 2008 compatibility. Don't have an Aldec license unfortunately.
On 20/10/2020 20:01, Rick C wrote:
> On Tuesday, October 20, 2020 at 2:44:53 PM UTC-4, HT-Lab wrote: >> On 20/10/2020 18:58, Kevin Neilson wrote: >>> On Monday, October 19, 2020 at 10:39:28 PM UTC-6, gnuarm.del...@gmail.com wrote: >>>> On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote: >> .. >>>>> >>>>> end TB_ARCH; -- VHDL_test >>>> I tried to report this both to Aldec and to Lattice (the company who provided the "free" software). Neither one has a means of reporting bugs unless you have an active maintenance account. I've sent both an email. Don't know if they will ever get back to me or accept my report of the bug. >>>> >>>> While searching I found a post from 2000 when Aldec had their new Verilog tool out. They were paying a bounty for bug reports. I think they let you use the software for free to find bugs and if you found 10 you got a lifetime subscription to the tool. Not sure what you got for lesser quantities. >>>> >>>> -- >>>> >>>> Rick C. >>>> >>>> + Get 1,000 miles of free Supercharging >>>> + Tesla referral code - https://ts.la/richard11209 >>> >>> Aldec very frequently does not parse legal HDL until it's simplified to its lowest form. >> >> I don't think that is the case. >> >> I know that in the past XST used to allow illegal VHDL constructs which >> resulted in Leonardo Spectrum adding a special "XST" switch to stop >> users complaining but there is no advantage in Aldec having a doggy >> parser. Also most EDA vendors use the same commercial parsers from Verific. >> >> The problem is that most free/student versions are older releases >> (Mentor does the same, OEM=2019.1, latest=2020.3). So I wouldn't be >> surprised if this bug has already been fixed in the latest release (I am >> sure somebody with a commercial license can confirm this). > > I would point out that this is not a compiler error, but a run time error. I think that is significantly different, i.e. not exactly a parser error most likely. > > >> Aldec is pretty good when it comes to VHDL support. >> >> Logging this bug however will not help Rick as it will probably take a >> year for the bug to be fixed and for the free version to get the update. >> So I would use the simple concatenation syntax which I actually find >> much easier to read, as they say "KISS", > > I've already gone with the simpler and shorter right hand side > > (Carry_Out_a, nxt_cnt_a) <= ("0" & Count_a) - 1; -- works > > Modifying any of three things makes it work. Obviously removing the left hand aggregate works. Replacing the RESIZE as above makes it work. Changing the integer literal with an unsigned constant makes it work. In fact, my constant definition can likely be replaced with a "1" and retain the RESIZE, but that's so much more typing than above. > > I'm trying to report it to Aldec so it can be fixed. They have turned me down saying I need to contact Lattice. The way they worded it, I think Lattice might be paying them a set price with no updates without paying a lump sum again. They said, "For the ActiveHDL in the Lattice tools you have to contact Lattice. Although we provide Lattice with the simulator, we don't have access to it once it is in their tools suite." That's a strange way to put it, "don't have access". > > Lattice has not turned me down, but it's a lot of work to get past the guard dogs. > > I'm curious to know if this is fixed in full licensed versions of the simulator. >
It isn't any different - I have a fully paid up in-maintenance Aldec HDL license. A different thing: I moved the line you quote above out of the process this afternoon and the simulator choked with a clash between Gowin's PLL behavioural and something - ran out of delta time iterations at 0ps ! I haven't sorted it out yet - came home for tea instead. MK
On Tuesday, October 20, 2020 at 3:07:34 PM UTC-4, Anssi Saari wrote:
> HT-Lab <hans64@htminuslab.com> writes: > > > The problem is that most free/student versions are older releases > > (Mentor does the same, OEM=2019.1, latest=2020.3). So I wouldn't be > > surprised if this bug has already been fixed in the latest release (I > > am sure somebody with a commercial license can confirm this). > > Actually I downloaded what Intel provides for free today and it's > Modelsim 2020.2. But it seems to me that for a long time it was a few > Modelsim 10.x, a few years old at least. > > Rick's example seems to work with that Modelsim, in ghdl too although > ghdl doesn't claim full VHDL 2008 compatibility. > > Don't have an Aldec license unfortunately.
Someone else reported that ghdl did not work. But that seems to be an issue with ghdl not supporting all the useful features of VHDL-2008. ghdl -a --std=08 VHDL_test.vhVHDL_test.vhd:26:17:error: can't match 'nxt_cnt_a' with type std_ulogic VHDL_test.vhd:26:17:error: target is not a signal name Maybe your version of ghdl has additional features implemented. Maybe I'll try the Intel tools. I'm used to Active-HDL, but there's not so much difference. -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
On Tuesday, October 20, 2020 at 3:10:55 PM UTC-4, Michael Kellett wrote:
> On 20/10/2020 20:01, Rick C wrote: > > On Tuesday, October 20, 2020 at 2:44:53 PM UTC-4, HT-Lab wrote: > >> On 20/10/2020 18:58, Kevin Neilson wrote: > >>> On Monday, October 19, 2020 at 10:39:28 PM UTC-6, gnuarm.del...@gmail=
.com wrote:
> >>>> On Monday, October 19, 2020 at 6:03:08 PM UTC-4, Rick C wrote: > >> .. > >>>>> > >>>>> end TB_ARCH; -- VHDL_test > >>>> I tried to report this both to Aldec and to Lattice (the company who=
provided the "free" software). Neither one has a means of reporting bugs u= nless you have an active maintenance account. I've sent both an email. Don'= t know if they will ever get back to me or accept my report of the bug.
> >>>> > >>>> While searching I found a post from 2000 when Aldec had their new Ve=
rilog tool out. They were paying a bounty for bug reports. I think they let= you use the software for free to find bugs and if you found 10 you got a l= ifetime subscription to the tool. Not sure what you got for lesser quantiti= es.
> >>>> > >>>> --=20 > >>>> > >>>> Rick C. > >>>> > >>>> + Get 1,000 miles of free Supercharging > >>>> + Tesla referral code - https://ts.la/richard11209 > >>> > >>> Aldec very frequently does not parse legal HDL until it's simplified =
to its lowest form.
> >> > >> I don't think that is the case. > >> > >> I know that in the past XST used to allow illegal VHDL constructs whic=
h
> >> resulted in Leonardo Spectrum adding a special "XST" switch to stop > >> users complaining but there is no advantage in Aldec having a doggy > >> parser. Also most EDA vendors use the same commercial parsers from Ver=
ific.
> >> > >> The problem is that most free/student versions are older releases > >> (Mentor does the same, OEM=3D2019.1, latest=3D2020.3). So I wouldn't b=
e
> >> surprised if this bug has already been fixed in the latest release (I =
am
> >> sure somebody with a commercial license can confirm this). > >=20 > > I would point out that this is not a compiler error, but a run time err=
or. I think that is significantly different, i.e. not exactly a parser err= or most likely.
> >=20 > >=20 > >> Aldec is pretty good when it comes to VHDL support. > >> > >> Logging this bug however will not help Rick as it will probably take a > >> year for the bug to be fixed and for the free version to get the updat=
e.
> >> So I would use the simple concatenation syntax which I actually find > >> much easier to read, as they say "KISS", > >=20 > > I've already gone with the simpler and shorter right hand side > >=20 > > (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1; -- works > >=20 > > Modifying any of three things makes it work. Obviously removing the le=
ft hand aggregate works. Replacing the RESIZE as above makes it work. Cha= nging the integer literal with an unsigned constant makes it work. In fact= , my constant definition can likely be replaced with a "1" and retain the R= ESIZE, but that's so much more typing than above.
> >=20 > > I'm trying to report it to Aldec so it can be fixed. They have turned =
me down saying I need to contact Lattice. The way they worded it, I think = Lattice might be paying them a set price with no updates without paying a l= ump sum again. They said, "For the ActiveHDL in the Lattice tools you have= to contact Lattice. Although we provide Lattice with the simulator, we don= 't have access to it once it is in their tools suite." That's a strange wa= y to put it, "don't have access".
> >=20 > > Lattice has not turned me down, but it's a lot of work to get past the =
guard dogs.
> >=20 > > I'm curious to know if this is fixed in full licensed versions of the s=
imulator.
> >=20 > It isn't any different - I have a fully paid up in-maintenance Aldec HDL=
=20
> license. >=20 > A different thing: > I moved the line you quote above out of the process this afternoon and=20 > the simulator choked with a clash between Gowin's PLL behavioural and=20 > something - ran out of delta time iterations at 0ps ! >=20 > I haven't sorted it out yet - came home for tea instead.
Not sure which line you are referring to. The line with the error is a con= current statement and not in a process. Here are the three cases I've test= ed so far.=20 (Carry_Out_a, nxt_cnt_a) <=3D RESIZE(Count_a, nxt_cnt_a'length + 1) - 1; = -- fails -- (Carry_Out_a, nxt_cnt_a) <=3D RESIZE(Count_a, nxt_cnt_a'length + 1) - = One_slv; -- works -- (Carry_Out_a, nxt_cnt_a) <=3D ("0" & Count_a) - 1; -- works I'm not sure what PLL you are referring to. I assume an unrelated matter. = I need to use a block RAM in the Gowin part and they recommend instantiati= on of their proprietary, module generated code. I don't know how to stimul= ate that. Maybe I can use RTL for simulation and their code for synthesis.= =20 --=20 Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
Rick C <gnuarm.deletethisbit@gmail.com> writes:

> Someone else reported that ghdl did not work. But that seems to be an > issue with ghdl not supporting all the useful features of VHDL-2008. > > ghdl -a --std=08 VHDL_test.vhVHDL_test.vhd:26:17:error: can't match 'nxt_cnt_a' with type std_ulogic > VHDL_test.vhd:26:17:error: target is not a signal name > > Maybe your version of ghdl has additional features implemented.
Maybe, it's the latest release version 0.37 from last February so not exactly new.