#944 VHDL enum type declaration generates syntax errors

[Olof Kindgren]

The type declaration t generates the following error:

type.vhd:4: syntax error
type.vhd:4: error: Invalid module instantiation

library ieee;
use ieee.std_logic_1164.all;

entity e is
  port (
    clk : in  std_logic;
    rst : in  std_logic;
    q   : out std_logic);
end e;

architecture a of e is

  type t is (one, zero);

  signal r : std_logic;

begin

   q <= r;

   process(clk)
   begin
     if rising_edge(clk) then
       if rst = '1' then
         r <= '0';
       else
         r <= not r;
       end if;
     end if;
   end process;
end a;

[Martin Whitaker]

The problem here is that Icarus Verilog handles VHDL files by running a pre-processor that converts them to Verilog before running the main Verilog compiler. However, in many cases it will use SystemVerilog constructs to represent the VHDL behaviour. To get the compiler to accept SystemVerilog constructs, you need to add the appropriate "generation" option, e.g.

iverilog -g2009 test.vhd

It could be argued that the compiler driver should automatically add this option when compiling VHDL files, but this could lead to problems if someone wants to do mixed VHDL/Verilog simulation. I'll wait to see if the other Icarus developers have an opinion on this.

[Stephen Williams]

I think I was (and maybe still am) thinking that the the
`begin_keywords directive is the right way to handle this, but
that is not yet implemented in the core compiler. I'm thinking
that, because outside the VHDL code, the user should be able to
stick with whatever version of Verilog they want, and not be
compelled to deal with SystemVerilog just because some VHDL is
being mixed in.

A proper implementation of begin_keywords/end_keywords would
make this problem really easy to solve. That's my thinking.

On 12/09/2013 12:25 PM, Martin Whitaker wrote:

The problem here is that Icarus Verilog handles VHDL files by running a
pre-processor that converts them to Verilog before running the main
Verilog compiler. However, in many cases it will use SystemVerilog
constructs to represent the VHDL behaviour. To get the compiler to
accept SystemVerilog constructs, you need to add the appropriate
"generation" option, e.g.

iverilog -g2009 test.vhd

It could be argued that the compiler driver should automatically add
this option when compiling VHDL files, but this could lead to problems
if someone wants to do mixed VHDL/Verilog simulation. I'll wait to see
if the other Icarus developers have an opinion on this.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

[Cary R.]

I'm not certain begin_keywords will work since it only allows you to switch to older keyword versions and it does not change the actual functionality. I believe begin_keywords is currently handled correctly, though it may need to be updated to handle 1800-2012. I agree only the VHDL parsing should require the SystemVerilog flag. Maybe we can add a warning that a SystemVerilog flag is required until we figure out how to dynamically switch this in the compiler.

[Stephen Williams]

A great deal of SV functionality is triggered by keywords, and all
the stuff that is non-keyword different is forward compatible. But
point is taken, and we can easily add an Icarus Verilog specific
directive like begin_generation/end_generation that does more
precisely what we are after. It is 100% OK for vhdlpp to be aware
of Icarus Verilog specific stuff. It will eventually need that in
order to do some stuff I haven't got to yet, too.

On 12/11/2013 07:56 PM, Cary R. wrote:

I'm not certain begin_keywords will work since it only allows you to
switch to older keyword versions and it does not change the actual
functionality. I believe begin_keywords is currently handled correctly,
though it may need to be updated to handle 1800-2012. I agree only the
VHDL parsing should require the SystemVerilog flag. Maybe we can add a
warning that a SystemVerilog flag is required until we figure out how to
dynamically switch this in the compiler.

---

[bugs:#944] http://sourceforge.net/p/iverilog/bugs/944/ VHDL enum
type declaration generates syntax errors

Status: open
Labels: VHDL
Created: Mon Dec 09, 2013 03:14 PM UTC by Olof Kindgren
Last Updated: Mon Dec 09, 2013 10:31 PM UTC
Owner: nobody

The type declaration t generates the following error:

type.vhd:4: syntax error
type.vhd:4: error: Invalid module instantiation

library ieee;
use ieee.std_logic_1164.all;

entity e is
port (
clk : in std_logic;
rst : in std_logic;
q : out std_logic);
end e;

architecture a of e is

type t is (one, zero);

signal r : std_logic;

begin

q <= r;

process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
r <= '0';
else
r <= not r;
end if;
end if;
end process;
end a;

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/iverilog/bugs/944/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

[Cary R.]

I will defer to Steve regarding adding -g2009 when parsing VHDL files, but as a minimum we should report the flag is/may be needed. Also note that some patches Steve submitted over the weekend broke VHDL enumerations for some (all?) cases.

[Olof Kindgren]

Yep. You're both right. Running against git head from sometime late last week works fine with -g2009, but with today's head I'm getting

enum.vhd:18: error: Signal/variable one not found in this context.
enum.vhd:18: error: Signal/variable one not found in this context.
enum.vhd:5: error: Duplicate enumeration name one
enum.vhd:5: error: Duplicate enumeration name zero

[Stephen Williams]

Yes, I broke it. Or rather, it was broken and I managed to make
its inner broken-ness manifest. The problem is that the vhdlpp
step is generating intermediate SystemVerilog code that includes
duplicate definitions of the enumeration that the type uses.
The generated code should make better use of internal typedefs.

On 12/09/2013 02:31 PM, Olof Kindgren wrote:

Yep. You're both right. Running against git head from sometime late last
week works fine with -g2009, but with today's head I'm getting
enum.vhd:18: error: Signal/variable one not found in this context.
enum.vhd:18: error: Signal/variable one not found in this context.
enum.vhd:5: error: Duplicate enumeration name one
enum.vhd:5: error: Duplicate enumeration name zero

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

[Olof Kindgren]

This appears to be fixed now in the master branch

[Cary R.]

A test for this problem has been added to the test suite.