Re: [sv-bc] Clarify -- questions about enumeration types

Actually my opinion is now that enumeration literals should not be imported
if only the enumeration type is imported. Greg Jaxon provided a good
argument for this.
Only import p::* should make everything visible.

we don't have overloaded enumeration literals in SV and if I take the
example I used earlier and add another package with an enumeration type
which enumeration literals overlap. I
would have a conflict as soon as I try to use both types because I am
bringing 2 enumeration literals of the same name.

package p;
typedef enum color = {red, blue, yellow, green};
endpackage
package q;
typedef enum mood= {happy, blue, sad, angry};
endpackage

module m;
import p::color;
import q::mood; // error
color r;
initial
r = blue;
endmodule

At 01:55 PM 6/24/2004 -0700, Dave Rich wrote:
>Yes, you are correct. I misread the VHDL LRM. Enumerated labels are
>treated as overloaded function names who return types are the enmerated
>type. Very different than SV. When you import an enumerated label from a
>package in VHDL, the exception was that the name does not collide with an
>already exposed name in the local scope, because the names are overloaded.
>
>In any case, the question remains: When inporting an enumerated type from
>a package in SV, should all the enumerated labels be imported also?
>So far, the prevailing opinion is that yes they should be imported.
>
>Dave
>
>
>Francoise Martinolle wrote:
>
>>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
>>
>>
>
>--
>--
>David.Rich@Synopsys.com
>Technical Marketing Consultant and/or
>Principal Product Engineer
>http://www.SystemVerilog.org
>tele: 650-584-4026
>cell: 510-589-2625
>
>
Received on Fri Jun 25 06:25:57 2004