RE: [sv-bc] questions about enumeration types

I'm traveling and don't have access to a VHDL LRM, but I also recall
that the enumeration values are treated in many ways like function calls
with a return type that is the enumeration type. This is necessary so
that if 2 enumerations are visible, function overloading rules can be
used and make both symbols visible.

Excuse the hacked syntax below but for example:

  package Color is

        type Primary is (RED, BLUE, YELLOW);
  end package Color;

  package Emotion is
 
      type Mood is (HAPPY, SAD, BLUE, MOROSE, GLEEFUL, ANGRY, JEALOUS);

  end package Emotion;

   use Color.all;
   use Emotion.all;
   ...
   variable Monday : Mood := BLUE;
   variable Shirt : Color := BLUE;

Without overloading rules these symbols wouldn't be visible.

Jay

===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Dave Rich
> Sent: Tuesday, June 22, 2004 12:56 AM
> To: Steven Sharp
> Cc: Francoise Martinolle; sv-bc@eda.org
> Subject: Re: [sv-bc] questions about enumeration types
>
>
> My interpretation is that "import p::name;" brings a package defined
> "name" into the local namespace, making it an alias for "p::name".
> Therefore "name.subname" would be a valid reference to the
> subscope of
> "p::name,subname". I see the the VHDL LRM makes an exception for
> enumerated labels; the SV LRM should have done the same.
>
> An intermediate typenames should not be imported without an explicit
> statement. For example
>
>
> package p;
>
> typedef struct {int A} A_t
>
> typedef struct {A_t B} B_t;
>
> B_t B_s;
>
> typedef B_t C_t;
>
> endpackage
>
> module top;
>
> import p::B_s;
>
> initial
> B_s.B.A = 1; //legal
>
> import p::C_t;
>
> B_t foo; // illegal -name not imported
> A_t bar; // illegal - name not imported
>
> typedef byte B_t; // legal - no name conflict
>
> endmodule
>
>
>
>
> Steven Sharp wrote:
>
> >A couple more questions I left out...
> >
> >If you import a struct type name, it seems pretty clear you
> want to import
> >the names of the struct fields implicitly too. Otherwise
> you wouldn't be
> >able to reference them without importing them explicitly. This seems
> >necessary if you import a type name that is a typedef for a
> struct type
> >also. Does this mean that you import the name of the type
> it is an alias
> >for?
> >
> >And if one of the struct fields is a struct, then accessing
> its subfields
> >would require importing that struct type implicitly. Should
> those names
> >be imported also? And are only the field names imported, or
> is the type
> >name imported also?
> >
> >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 Tue Jun 22 00:20:56 2004