Re: [vhdl-200x-ft] Question on Type and Package Generics

Peter,
I never did follow the need for the different
classes of the generic packages. It seems that
if I were to put a constraint on array_type as I
did below and someone were to pass in a constrained
type, then it would result in a compilation error
of the instantiated package.

Can you explain the need to constrain the generic
types this way and what it buys us?

Regards,
Jim

> Jim,
>
>
>>I have a question on instantiating packages.
>>If I create a generic package as follows:
>>package MuxPkg is
>> generic( type array_type) ;
>>
>> function Mux4 (
>> Sel : array_type(1 downto 0) ;
>> A : array_type ;
>> B : array_type ;
>> C : array_type ;
>> D : array_type
>> ) return array_type ;
>>end MuxPkg ;
>
>
> Actually, you wouldn't be able to apply an index constraint to the formal
> type, since you don't know that the actual will be an unconstrained array
> type. The actual could be any type. For example, if you instantiated the
> package with type BIT as the actual for array_type, applying an index
> constraint wouldn't make sense.
>
> In the proposal we're working with, we don't provide a way of adding
> information to the formal about the kind of type that can be supplied as an
> actual. So let's proceed with the example revised as:
>
> package MuxPkg is
> generic( type array_type) ;
>
> function Mux4 (
> Sel : bit_vector(1 downto 0);
> A : array_type ;
> B : array_type ;
> C : array_type ;
> D : array_type
> ) return array_type ;
> end MuxPkg ;
>
> package body MuxPkg is
>
> function Mux4 (
> Sel : bit_vector(1 downto 0);
> A : array_type ;
> B : array_type ;
> C : array_type ;
> D : array_type
> ) return array_type is
> begin
> case Sel is
> when "00" => return A ;
> when "01" => return B ;
> when "10" => return C ;
> when "11" => return D ;
> end case ;
> end function Mux4 ;
>
> end MuxPkg ;
>
>
>
>>To create an implementation for types std_logic_vector and
>>unsigned I do the following:
>>
>>Library ieee ;
>> Use ieee.std_logic_1164.all ;
>> Use ieee.numeric_std.all ;
>>Package MuxPkg_slv is new work.MuxPkg
>> Generic map (array_type => std_logic_vector) ;
>>
>>Library ieee ;
>> Use ieee.std_logic_1164.all ;
>> Use ieee.numeric_std.all ;
>>Package MuxPkg_unsigned is new work.MuxPkg
>> Generic map (array_type => unsigned) ;
>>
>>Finally the question:
>>When I instantiate a package,
>>1) do I need to reference the library and use clauses
>> prior to each instantiated package since I am creating
>> a primary unit and the context clause is consumed by the
>> primary unit,
>
>
> Almost correct. You need to make sure that the names referenced in the
> instantiation are visible at the point of reference. So you need to include
> the library clause in each of your two examples to ensure the name ieee is
> visible. If you want to use the simple names of the types in the
> instantiations, you can include the use clauses. Otherwise, you could omit
> the use clauses and do
>
> Library ieee;
> Package MuxPkg_slv is new work.MuxPkg
> Generic map (array_type => ieee.std_logic_1164.std_logic_vector) ;
>
> Library ieee ;
> Package MuxPkg_unsigned is new work.MuxPkg
> Generic map (array_type => ieee.numeric_std.unsigned) ;
>
>
>> -- or --
>>2) do I need only one reference to the library and use clauses
>> prior to the first package instantiation sufficient -
>> similar to instantiating components in an architecture
>
>
> No. BTW, your analogy with instantiating a component in an architecture is
> misleading. The library and use clauses in your example package
> instantiations are to make visible the names of the actual types, and have
> nothing to do with visibility of the generic package. In your examples, the
> generic package is visible by virtue of being prefixed with the library name
> Work, for which there is an implicit library clause.
>
> A more accurate analogy with instantiating a component in an architecture
> would be with the values used as generics for the component instances.
> Suppose you had a component C with generic G of type integer, and that you
> wanted three instances, associating G with three constants declared in three
> separate packages in different libraries. Then you'd need three library
> clauses before the architecture to make the library names visible, and you
> may wish to include three use clauses to make the constant names directly
> visible. Again, the library and use clauses here are to make the actuals
> visible, not the name of the instantated declaration.
>
>
>> -- or --
>>3) I don't need any package references before the generic
>> package and package references are only required to be
>> referenced at the point of usage.
>
>
> Correct. But the "-- or --" is not an exclusive or.
>
> 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
>
>
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~