Re: [sv-bc] SV_BC #26 - Enumerated Literals in Packages - Feedback Requested

Some ideas being attributed to me do not sound familiar. I *did* once
suggest that the scope operator might help with enum label references,
even though I acknowledge that it isn't a wonderful use for that syntax.

Clifford E. Cummings wrote:

> Brad's link points to an email by Greg Jaxon discussing passing types as
> parameters and asks:
>
> 1) if the passed type is a struct, can the fields of a passed type be
> referenced using mytype.field1 notation or not?

I cannot think of why one would ever need access into a struct *type*.
The '.' notation is used to access fields of an OBJECT of struct type,
but never of the type itself.

> 2) if the passed type is an enumerated type, can the enumerated literals
> be referenced directly?

I think (1) must have been a parallel construction in some argument by
analogy to support the idea that types that arrive via type parameters
don't change the namespace inside the receiving module.

> I thought the answer to both questions was yes, but Greg Jaxon suggests
> that in both cases, SV should be extended to reference passed type
> struct fields using the :: operator (mytype::field1) and passed enum
> type literals also be referenced using the :: operator (myenum::literal1).

I suggested the second. The first "mytype::field1" would be analgous,
but it doesn't mean anything. We already use structobj.field to access
fields of a struct object. We don't ever need to access the "fields" of
a struct type - unless this occurs in something like $typeof( structtype::field )
and in such cases I do prefer using the scope operator rather than the
field access operator.

Greg Jaxon

>
> I prefer to use the mytype.field1 and literal1 notation and leave :: for
> importing packages and package contents (just my preference).
>
> Steve thinks that we had agreed to not automatically import enum
> literals but emails from Francoise and Dave Rich (included in the bug
> description) tend to suggest other options:
>
> Date: Fri, 25 Jun 2004 09:25:44 -0400
> From: Francoise Martinolle <fm@cadence.com>
>
> Actually my opinion is now that enumeration literals should not be
> imported if only the enumeration type is imported. Only import p::*
> should make everything visible.
>
> My examples do not import everything with "import p::*"
>
> Reason: everywhere else in SystemVerilog package importation, the *
> importation does not really import anything until the specific package
> type, etc., is actually referenced.
>
> At 01:55 PM 6/24/2004 -0700, Dave Rich wrote:
>
> When importing 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.
>
> This is what my proposal does.
>
> Sorry I cannot be on the call to close this bug personally.
>
> Regards - Cliff
>
>
> At 06:39 PM 11/23/2004, Brad Pierce wrote:
>
>> As Dave wrote -- "label names should not get imported for both type
>> parameters and package imports". Also, we should still seriously
>> consider making the "right fix" for this issue --
>>
>> http://www.eda.org/sv-bc/hm/2041.html
>>
>> namely, enabling access to enum labels via their type name by extending
>> the scope resolution operator (my_colors::blue).
>>
>> -- Brad
>>
>>
>> -----Original Message-----
>> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
>> Steven Sharp
>> Sent: Tuesday, November 23, 2004 6:16 PM
>> To: sv-bc@eda.org; cliffc@sunburst-design.com
>> Subject: Re: [sv-bc] SV_BC #26 - Enumerated Literals in Packages -
>> Feedback Requested
>>
>>
>> Didn't we decide that importing an enum type did not automatically import
>> the enum literals? That seems to be the gist of the emails on this
>> erratum.
>>
>> Steven Sharp
>> sharp@cadence.com
>
>
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
>
>
>
Received on Mon Nov 29 11:21:00 2004