I don't know which kind of vhdl exception you are talking about.
Importing only the enumeration type in VHDL does not import automatically
the enumeration constants.
I ran the example below and I get an error for undeclared identifier for BLUE.
package my_types is
type my_enum is (BLUE, RED, YELLOW);
end my_types;
library ieee;
use ieee.std_logic_1164.all;
entity e is
port (clk: in std_logic);
end e;
use WORK.my_types.my_enum;
architecture a of e is
signal s : my_enum;
begin
p1: process (clk)
begin
s <= BLUE;
end process;
end a;
ncvhdl test.v
ncvhdl: xxxxxx (c) Copyright 1995-2004 Cadence Design Systems, DEBUG
s <= BLUE;
|
ncvhdl_p: *E,IDENTU (test.v,17|16): identifier (BLUE) is not declared [10.3].
Additionnally in VHDL enumeration literals are overloaded (unlike in SV),
the effect of this is that if you specify the import of an enumeration
literal that it overloaded, all of the enumeration literals of that name
will be be made visible. The context of their use will determine
which enum literal it is refering to. (See Jay example).
Francoise
'
At 07:49 PM 6/22/2004 -0400, Steven Sharp wrote:
>Dave,
>
>I think your answer resolved my question about structs nicely. Their field
>names don't need to be imported into the local scope when a struct type or
>variable gets imported, because a reference to them is regarded like a
>hierarchical reference into the subscope "inside" the struct. I should have
>realized that myself.
>
>So it appears that importing a name only imports that name itself, and
>that this does not cause a problem for structs.
>
>However, this still leaves the issue with enum literals. One would expect
>that importing an enum type would provide access to the enum literals also.
>It would be very inconvenient to have to import all of the literal names
>individually. From what you have said, VHDL makes a special exception for
>these.
>
>Steven Sharp
>sharp@cadence.com
Received on Wed Jun 23 14:10:11 2004
This archive was generated by hypermail 2.1.8 : Wed Jun 23 2004 - 14:10:15 PDT