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

Peter,
In section 2 and 3, can we make the is keyword on packages
and subprograms (and entities) optional. Then we would have
better syntax consistency:

package_declaration ::=
   package identifier [is]
     [ formal_generic_clause ]
     package_declarative_part
   end [ package ] [ package_simple_name ] ;

In section 2.1, instancing packages
Let me restate a couple of things to make sure I understand:
   When instantiated as a design unit, an instanced
   package can be referenced like any other package.

Of the two below, which is right?
1.1 seems intuitive, 1.2 seems problematic.
   ??1.1 When instanced in a declarative part (entity,
   architecture/block, process, ...) the instanced
   package can only be made available in the immediate
   declarative part (or declarative parts within
   its scope - ie: if declared in an architecture the
   package is selectable a block within the architecture)

   ??1.2 When instanced in a declarative part (entity,
   architecture/block, process, ...) the instanced
   package is still a primary unit and is compiled into
   the same library as the design that contains it and
   can be referenced by other designs.

-- Potential enhancement request if it is not already this way --
When a package is instanced in the declarative part, the
package use clause seems repeative. This is best illustrated
in the example at the end (page 6/7):
   package test_pattern_tables is new work.lookup_tables
     generic map (
         element_type => test_pattern_type,
         key_type => string,
         key_of => test_id_of
      );

    -- the following use clause seems redundant.
    use test_pattern_tables.all;

Would it make sense that if a package is declared in a declarative part,
then a use clause to reference it is automatically implied.

-- Potential enhancement request if it is not already this way --
Furthermore, if the context design unit proposed in fast track
(FT16) is accepted, perhaps we could do a similar implied
reference for the package:

Context Chipper_Context is
   library std ; -- not needed?
     use std.standard.all ; -- not needed?
   library work ; -- not needed?
   library ieee ;
     use ieee.std_logic_1164.all;
     use ieee.numeric_std.all ;
     use std.textio.all ;

   package floatpkg is new ieee.genericfloatpkg
     generic map (
         numeric_type => real
      );

    -- use work.floatpkg.all ; -- implied

end;

In section 2.1, if I instantiate a package in a process,
can a procedure in the package access signals by side-effect
just like a procedure declared in a process can?
My thought is probably not, however, what if we took the
next step and port mapped signals and variables to
a package and instantiate the package in the process.
Now I think I will effectively get side-effect access in a
procedure.

In section 3, Subprograms, I prefer the v1 subprogram generic format
where:
subprogram specification ::=
  procedure designator
     [ generic ( generic_list ) ]
     [ [ parameter ] ( formal_parameter_list ) ]

  | [ pure | impure ] function designator
     [ generic ( generic_list ) ]
     [ [ parameter ] [ ( formal_parameter_list ) ] return type_mark

If we do this, I would prefer we use the key word port to parameter.

In section 3.1, the following seems to be missing:

   entity_declarative_item ::=
     . . .
     | generic_subprogram_instantiation

In section 4 and 5, why were package generics deleted?

   interface_declaration ::=
     . . .
     | interface_type_declaration
     | interface_subprogram_declaration
     | interface_package_declaration

   actual_designator ::=
     . . .
     | type_mark
     | subprogram_name
     | package_instance_name

Section 6:
An interface type declaration defines a formal generic type
that can denote any type. The generic unit can only
assume that operations available for all types are applicable,
namely, variable assignment, equality and inequality
operations.

I like the simplified format, but why limit the operators we
can use? It does seem to give us the ability to solve some
short term issues in the verification realm. This is not
a bad compromise answer/first step for fast track.

When going further, perhaps a good test case for usage of other
operators are the issues David Bishop is having with floating
point implementation and swapping the use of real (simulates fast)
vs. array (accurate in size).

Section 7:
In the example, in the procedure body of traverse, where does the
procedure action come from? It looks like it was a generic on the
interface to traverse and that perhaps it was accidentally removed
as the example on the bottom of page 6, top of page 7 seems to map
the subprogram.

procedure traverse ( table : in lookup_table ) is
begin
   if table = null then
     return;
   end if;
   traverse ( table.left_subtree );
   action ( table.element );
   traverse ( table.right_subtree );
end procedure traverse;

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~