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

Can we enter this errata on the new bug tracking system?

Thanks
>X-Authentication-Warning: isvw3.cadence.com: iscan owned process doing -bs
>X-Authentication-Warning: server.eda.org: majordom set sender to
>owner-sv-bc@eda.org using -f
>X-Sender: fm@phenix.cadence.com
>X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
>Date: Fri, 25 Jun 2004 09:25:44 -0400
>To: Dave Rich <David.Rich@synopsys.com>
>From: Francoise Martinolle <fm@cadence.com>
>Subject: Re: [sv-bc] Clarify -- questions about enumeration types
>Cc: Steven Sharp <sharp@cadence.com>, sv-bc@eda.org
>X-Received: By mailgate.Cadence.COM as GAA19162 at Fri Jun 25 06:26:34 2004
>Sender: owner-sv-bc@eda.org
>X-pstn-levels: (S:99.90000/99.90000 R:95.9108 P:95.7665 M:100.0000
>C:90.9622 )
>X-Status: $$$$
>
>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 Thu Jul 8 07:59:40 2004