Active-HDL Throws Error...

R

Rick C

Guest
My code is assigning an incremented unsigned value to an aggregate so the sum 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 makes the Active-HDL simulator complain. I\'m adding an integer 1 to the unsigned counter value after being resized to be 1 bit larger to match the left hand side aggregate. I\'ll post the code below.

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 would report this to Aldec, but I\'m pretty sure they don\'t have a way to report bugs if you are not a customer with a current maintenance contract.

-- 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 := 33.554432E6 );
port(
-- Clk : in std_logic := \'1\';
Cnt_En : in std_logic := \'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 := 500 ms / CLK_HZ; -- 14901 ps;
constant Cntr_Width : positive := 8;
constant Cntr_Modulus : positive := 2**Cntr_Width;
constant One_slv : unsigned(Cntr_Width downto 0) := \"000000001\";
signal Clk : std_logic := \'1\';
signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) := (others => \'0\');
begin

Clk_gen: Clk <= not Clk after Clock_Half_Period; -- comment out for synth

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

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

end TB_ARCH; -- VHDL_test


--

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 lines 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 unsigned counter value after being resized to be 1 bit larger to match the left hand side aggregate. I\'ll post the code below.

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 would report this to Aldec, but I\'m pretty sure they don\'t have a way to report bugs if you are not a customer with a current maintenance contract.

-- 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 := 33.554432E6 );
port(
-- Clk : in std_logic := \'1\';
Cnt_En : in std_logic := \'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 := 500 ms / CLK_HZ; -- 14901 ps;
constant Cntr_Width : positive := 8;
constant Cntr_Modulus : positive := 2**Cntr_Width;
constant One_slv : unsigned(Cntr_Width downto 0) := \"000000001\";
signal Clk : std_logic := \'1\';
signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) := (others => \'0\');
begin

Clk_gen: Clk <= not Clk after Clock_Half_Period; -- comment out for synth

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

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

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
 
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:
My code is assigning an incremented unsigned value to an aggregate so the sum 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 makes the Active-HDL simulator complain. I\'m adding an integer 1 to the unsigned counter value after being resized to be 1 bit larger to match the left hand side aggregate. I\'ll post the code below.

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 would report this to Aldec, but I\'m pretty sure they don\'t have a way to report bugs if you are not a customer with a current maintenance contract.

-- 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 := 33.554432E6 );
port(
-- Clk : in std_logic := \'1\';
Cnt_En : in std_logic := \'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 := 500 ms / CLK_HZ; -- 14901 ps;
constant Cntr_Width : positive := 8;
constant Cntr_Modulus : positive := 2**Cntr_Width;
constant One_slv : unsigned(Cntr_Width downto 0) := \"000000001\";
signal Clk : std_logic := \'1\';
signal Count_a, nxt_cnt_a : unsigned(Cntr_Width - 1 downto 0) := (others => \'0\');
begin

Clk_gen: Clk <= not Clk after Clock_Half_Period; -- comment out for synth

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

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

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\'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.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.

--

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 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.

Not sure which line you are referring to. The line with the error is a concurrent statement and not in a process. Here are the three cases I\'ve tested so far.

(Carry_Out_a, nxt_cnt_a) <= RESIZE(Count_a, nxt_cnt_a\'length + 1) - 1; -- fails
-- (Carry_Out_a, nxt_cnt_a) <= RESIZE(Count_a, nxt_cnt_a\'length + 1) - One_slv; -- works
-- (Carry_Out_a, nxt_cnt_a) <= (\"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 instantiation of their proprietary, module generated code. I don\'t know how to stimulate that. Maybe I can use RTL for simulation and their code for synthesis.

--

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.
 
On Wednesday, October 21, 2020 at 11:35:57 AM UTC-4, Anssi Saari wrote:
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.

That guy reported updating ghdl and the aggregate then working ok. Thanks for your info.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209
 
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.

I agree, but I was replying to Kevin\'s post where he mentioned not
parsing legal code,

Hans
www.ht-lab.com
 
On 20/10/2020 20:07, 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.

Thanks, that is good news and I should have checked this before posting.
I am on Quartus 18.1 and assumed Modelsim would still be on the 2019
series.
Rick\'s example seems to work with that Modelsim, in ghdl too although
ghdl doesn\'t claim full VHDL 2008 compatibility.

GHDL is an amazing piece of software and kudos to the developers. It is
a shame they picked ADA as more young programmers (i.e. student with
lots of spare time) are familiar with Python, C, Julia?, Go? ... I lost
track, still impressive free software,

Hans
www.ht-lab.com


Don\'t have an Aldec license unfortunately.
 
On Wednesday, October 21, 2020 at 3:08:05 PM UTC-4, HT-Lab wrote:
On 20/10/2020 20:07, 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.

Thanks, that is good news and I should have checked this before posting.
I am on Quartus 18.1 and assumed Modelsim would still be on the 2019
series.

Rick\'s example seems to work with that Modelsim, in ghdl too although
ghdl doesn\'t claim full VHDL 2008 compatibility.

GHDL is an amazing piece of software and kudos to the developers. It is
a shame they picked ADA as more young programmers (i.e. student with
lots of spare time) are familiar with Python, C, Julia?, Go? ... I lost
track, still impressive free software,

I thought I might give ghdl a try, but I\'m not clear on how to run it. They don\'t have an idiot\'s guide so I\'m sure I totally messing it up. To start with I copied the folder ghdl from the zip file ghdl-0.37-mingw64-llvm.zip to C:\\Program Files Then in the bin subdir I see two exe files, ghdl1-llvm.exe and ghdl.exe. Which is used?

Then I tried running by clicking on them, but I suspect that produces a command line window that immediately goes away because I didn\'t have any command line parameters. I don\'t see any sign of the window though, just a mouse cursor blink and the Windows Explorer window blinks. I get this same behavior with a UI simulation executable. I tried turning off the AVS but to no avail.

I take it I need to put together a batch file to run ghdl?

It seems like it would be a good idea to use a vendor independent simulator, but I\'m not big on steep learning curves.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209
 
On 21/10/2020 21:23, Rick C wrote:
On Wednesday, October 21, 2020 at 3:08:05 PM UTC-4, HT-Lab wrote:
On 20/10/2020 20:07, Anssi Saari wrote:
HT-Lab <hans64@htminuslab.com> writes:
...
GHDL is an amazing piece of software and kudos to the developers. It is
a shame they picked ADA as more young programmers (i.e. student with
lots of spare time) are familiar with Python, C, Julia?, Go? ... I lost
track, still impressive free software,

I thought I might give ghdl a try, but I\'m not clear on how to run it. They don\'t have an idiot\'s guide so I\'m sure I totally messing it up. To start with I copied the folder ghdl from the zip file ghdl-0.37-mingw64-llvm.zip to C:\\Program Files Then in the bin subdir I see two exe files, ghdl1-llvm.exe and ghdl.exe. Which is used?

Then I tried running by clicking on them, but I suspect that produces a command line window that immediately goes away because I didn\'t have any command line parameters. I don\'t see any sign of the window though, just a mouse cursor blink and the Windows Explorer window blinks. I get this same behavior with a UI simulation executable. I tried turning off the AVS but to no avail.

I take it I need to put together a batch file to run ghdl?

Yes, this is the command sequence I used a few years ago for one my designs:

ghdl -a --ieee=synopsys -fexplicit dut.vhd
ghdl -a --ieee=synopsys -fexplicit testbench.vhd
ghdl -e --ieee=synopsys -fexplicit testbench
../testbench.vhd --stop-time=200ms --ieee-asserts=disable --vcd=my.vcd

I was quite impressed it worked first time out of the box. However, I
quickly went back to Modelsim as a good debugging environment is so
important. This is probably the reason why I still don\'t like Vivado. It
has most bells and whistles but I find it too cumbersome to use.

Good luck,

Hans
www.ht-lab.com

It seems like it would be a good idea to use a vendor independent simulator, but I\'m not big on steep learning curves.
 

Welcome to EDABoard.com

Sponsor

Back
Top