[vhdl-200x-dta] RE: [vhdl-200x] Revised white paper on type genericity

Bhasker,

If you don't allow for instantiating a generic package within a declarative
part, then any type to be used as an actual type must be declared in an
external package. Let me illustrate.

Suppose you have a generic package for lists in a library called util:

  package lists is
    generic ( type T );

    type list;

  end package lists;

Within a process in an architecture, I declare some specific type for which
I also want lists. As my proposal currently stands, I would do it as
follows:

  library util;

  architecture a of e is
  begin

    test_bench_control : process is

      type my_type is ...

      package my_lists is new util.lists
        generic map ( my_type );
      use my_lists.all;

      variable v : list;

    begin
      ...
    end process test_bench_control;

    ...

  end architecture a;

If you remove the provision for instantiating a generic package in a
declarative part, you'd have to do the instantiation as a design unit. That
means the actual type needs to be visible at the point of instantiation, so
it would need to be pulled out into a separate package. The revised design
would be:

  package my_type_pkg is

    type my_type is ...

  end package my_type_pkg;

  --

  library util;

  package my_lists is new util.lists
    generic map ( work.my_type_pkg.my_type );

  --

  architecture a of e is
  begin

    test_bench_control : process is

      use work.my_type_pkg.all, work.my_lists.all;

      variable v : list;

    begin
      ...
    end process test_bench_control;

    ...

  end architecture a;

The effect is to break the modularity and information hiding of the design
by exposing the internal types of the process for all of the design to see.
It also makes the design more complex to maintain.

I think the benefits of allowing a generic package to be instantiated in a
declarative part are worth the effort in LRM smithing.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: owner-vhdl-200x-dta@eda.org
> [mailto:owner-vhdl-200x-dta@eda.org] On Behalf Of Jayaram Bhasker
> Sent: Wednesday, 21 April 2004 04:09
> To: Peter Ashenden; vhdl-200x-dta@eda.org
> Cc: vhdl-200x@eda.org
> Subject: [vhdl-200x-dta] RE: [vhdl-200x] Revised white paper 
> on type genericity
> 
> 
> Peter:
> 
> Re 2.1, I dont like the concept of instantiating a generic
> package as a declarative item. At beginning of section 2.1, 
> the generic package instantiation is defined to be 
> semantically equivalent to a normal package (and a design 
> unit). This is good. In current VHDL, just like you cannot 
> have a package declaration as a declarative item, I suggest 
> that we not support a generic package instantiation as a 
> declarative item. We should try to follow the normal package 
> rules, i.e. inclusion of a package (including a generic 
> package instantiation) is achieved by using the use clause.
> 
> regards,
> - bhasker
> 
> 
> -----Original Message-----
> From: Peter Ashenden [mailto:peter@ashenden.com.au]
> Sent: Sunday, April 18, 2004 11:56 PM
> To: vhdl-200x-dta@eda.org
> Cc: vhdl-200x@eda.org
> Subject: [vhdl-200x] Revised white paper on type genericity
> 
> 
> Folks,
> 
> Attached is a revised version of my earlier white paper
> proposing exensions to generics.  Changes are:
> 
> - simplification of generic types to be incomplete type definitions
> - allowing package instances in declarative parts
> - change to syntax of generic subprograms
> - removal of formal package generics
> 
> The idea is that this would be a relatively simple initial
> extension to VHDL to allow specification of things like 
> lists, queues and sparse arrays, such as have been requested 
> for verification and modeling enhancement.  The way in which 
> the extensions have been formulated leaves the way open for 
> further extensions for object-oriented classes and type reflection.
> 
> Steve wanted to discuss this at the telecon later this week.
> 
> Cheers,
> 
> PA
> 
> --
> Dr. Peter J. Ashenden                        peter@ashenden.com.au
> Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
> PO Box 640                                   Ph:  +61 8 8339 7532
> Stirling, SA 5152                            Fax: +61 8 8339 2616
> Australia                                    Mobile: +61 414 70 9106
>