RE: [Fwd: Re: IR2058 & subtypes, packages, ..]

Folks,

I think that, had Jim declared aliases rather than subtypes in the package,
he would have been ok. For aliases  of a type or subtype, you also get
aliases for the predefined operators of the type of subtype.

Looking at our changes to semantics of use clauses, it appears we did not
quite say what we wanted. The changed text is:

If the suffix of the selected name is a type mark, then the following
declarations are identified:

-- The declaration of the type or subtype denoted by the type mark

-- If the type or subtype is a enumeration type, the enumeration literals
   of the base type

-- If the type or subtype is a physical type, the units of the base type

-- The implicit declarations of predefined operations for the type that
   are not hidden by homographs explicitly declared immediately within
   the package denoted by the prefix of the selected name

-- The declarations of homographs, explicitly declared immediately within
   the package denoted by the prefix of the selected name, that hide
   implicit declarations of predefined operations for the type.

If the suffix is the reserved word all, then the selected name identifies
all declarations that are contained within the package or library denoted by
the prefix of the selected name.


In Jim's example, there are no declarations of the predefined operations or
homographs thereof in the package, so the declarations from the original
packages don't come along for the ride. However, had he declared a subtype T
of an enumeration type or a physical type and said use work.mytypes.T, the
enumeration literals or units would have come along, since we don't specify
that only those declared in the package are identified. Is that what we
intended?

Moreover, with the use clause referring to work.mytypes.all and mytypes
declaring a subtype of an enumeration or physical type declared in a
separate package, the enumeration literals or units would not be identified,
since they're not declared in the used package. Again, is that what we
intended?

Cheers,

PA

--
Dr. Peter J. Ashenden                peter@ashenden.com.au
Ashenden Designs Pty. Ltd.           www.ashenden.com.au
PO Box 640                           VoIP: 0871270078@sip.internode.on.net
Stirling, SA 5152                    Phone (mobile):  +61 414 709 106
Australia 
-----Original Message-----
From: owner-isac@eda.org [mailto:owner-isac@eda.org] On Behalf Of Chuck
Swart
Sent: Friday, 13 January 2006 07:24
To: isac@eda.org
Subject: [Fwd: Re: IR2058 & subtypes, packages, ..]


ISACer's
I'm forwarding a response to Jim Lewis which concerns IR2058.

We might want to look at this. There may be unintended consequences
(or lack of intended consequences) in IR2058.

Chuck Swart

-------- Original Message -------- Subject: Re: IR2058 & subtypes, packages,
..
Date: Thu, 12 Jan 2006 12:51:22 -0800
From: Chuck Swart <cswart@model.com>
To: Jim Lewis <Jim@SynthWorks.com>
References: <43C5D956.7090600@SynthWorks.com>



We might want to discuss this at tonight's ISAC meeting, but
my reading of IR2058 is that when the subtype becomes visible, then the
predefined operators become visible. However, its not clear to me that
declaring a subtype in a new package imports the overloaded operators from
the original package.

Chuck Swart


Jim Lewis wrote:

> Chuck,
> I have been working on interfaces.  As such, I have
> been trying to get a feel for the difference between
> classes, packages, and subtypes.
>
> I wrote the little program at the bottom.  Currently with
> the second library ieee and use clauses commented out,
> this will fail to compile because operators and literal
> values are not visible.
>
> With IR2058 are the package references that are commented
> out still required?
> I am toying with interfaces being an extension to a
> record.  The extension also makes a record like a class.
> I will be publishing the white paper soon, so you will see
> it.  It really annoys me that SystemVerilog has structures,
> classes, and interfaces.  It would seem nice if all of
> these could be one fairly straight forward feature - even
> better if it could be a simple extension of one with which
> we are already familiar with.
>
> Cheers,
> Jim
>
>
> library ieee ;
> use ieee.std_logic_1164.all ;
> use ieee.numeric_std.all ;
> package my_types is
>     subtype sl is std_logic ;
>     subtype slv is std_logic_vector ;
>     subtype uv is unsigned ;
>     subtype sv is signed ;
> end package my_types ;
>
>
> -- library ieee ;
> --   use ieee.std_logic_1164.all ;
> --   use ieee.numeric_std.all ;
>
> use work.my_types.all ;
> entity test_my_types is
> end entity test_my_types ;
> architecture test of test_my_types is
>
>   signal Y, A, B : uv(7 downto 0) ;
>
> begin
>   Y <= A + B ;
>
>   test_proc : process
>   begin
>     A <= X"00" ;
>     B <= X"00" ;
>     wait for 40 ns ;
>
>     for i in 1 to 8 loop
>       A <= A(6 downto 0) & '1' ;
>       B <= X"00" ;
>       wait for 40 ns ;
>
>       for j in 1 to 8 loop
>         B <= B(6 downto 0) & '1' ;
>         wait for 40 ns ;
>       end loop ;
>     end loop ;
>     report "Done" severity failure ;
>   end process ;
> end test ;
>
>
>