RE: [vhdl-200x-ft] Question On Type Genericity

Yannick,

Re 1): In my modified example, I passed T'succ in as the actual function:

  c : entity work.counter(behavioral)
        generic map ( T, T'low, T'high, T'succ )
        port map ( ... );

My reasoning was that 'succ is defined to be of a function kind, so why not
treat it so in a general way?

Whether we would want to allow this or not is an open question. Currently,
the only places I can think of where a suprogram name can appear, denoting
the subprogram without calling it, are attribute specifications and group
declarations. In the case of attribute specifications, the name must be a
simple name, operator symbol or character literal, so an attribute name is
not allowed. In the case of a group declaration, the LRM explicitly
prohibits attribute names.

My inclination would be not to allow attribute names as actuals for
subprogram formals, since I think the expectation is that they be built into
the innards of a compiler, rather than being implemented as subprograms. If
that is the case, then you would need to define a helper function to
increment a value and pass that function as the actual.

Re 2): If I understand the intent of your example correctly, I don't think
you would specify enum_operation_type as a generic. Presumably there would
not be different types for specifying the collection of operations to be
performed. If that is so, then only the type for the input and output data
ports needs to be a generic. Also, since different arithmetic operators are
required depending on the data type, those operators would need to be
specified as formal subprograms. You could use a default specifier to allow
selection of the visible operator at point of instatiation. The example
would be written as:

  entity add_substract is
    generic ( type signal_type;
              function "+"(a, b : signal_type) return signal_type is <>;
              function "-"(a, b : signal_type) return signal_type is <>;
              function "<"(a, b : signal_type) return boolean is <> );
    port ( clk : in bit; operation : in enum_operation_type;
           data1_in : in signal_type; data2_in : in signal_type;
           data_out : out signal_type );
  end entity add_substract;

  -- signal_type can be integer,signed, unsigned ....
  -- enum_operation_type is a enum (add,sub,maxval,minval)

  architecture behavioral of add_substract is
  begin
    add_substract_behavior : process is
    begin
      wait until clk = '1';
      if operation = add then
        data_out <= data1_in + data2_in;
      elsif operation = sub then
        data_out <= data1_in - data2_in;
      elsif operation = maxval then
        if data1_in < data2_in then
          data_out <= data2_in;
        else
          data_out <= data1_in;
        end if;
      else -- operation = minval
        if data1_in < data2_in then
          data_out <= data1_in;
        else
          data_out <= data2_in;
        end if;
      end if;
    end process add_substract_behavior;
  end architecture behavioral;

The idea here is that when you instantiate the entity with an actual type,
you can also provide the specific "+", "-" and "<" operators for that type.
The "is <>" notation specifies that the default operator is the operator of
the given name that is visible at the point of instantiation. So in the
following instantiation:

  a : entity work.add_substract(behavioral)
    generic map ( signal_type => unsigned )
    port map ( ... );

the "+", "-" and "<" operators defined for unsigned that are visible are
used by default.

Re 3): In principle, entities and architectures that use generic types
should be synthesizable, provided the architecture bodies conform to other
synthesis guidelines. The information about actual types and actual
subprograms is globally static, and so is available for use by a synthesis
tool. Of course, whether synthesis tool vendors choose to support such
constructs is another questions. Also, the 1076.6 working group might
consider whether to include the features in a future revision of the
synthesis interoperability standard.

I hope this answers you questions.

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: yannick.grugni@philips.com [mailto:yannick.grugni@philips.com] 
Sent: Wednesday, 19 January 2005 21:02
To: Peter Ashenden
Cc: vhdl-200x-ft@eda.org
Subject: RE: [vhdl-200x-ft] Question On Type Genericity
Thanks for your explanation. 
I still have some questions: 
1) In the revised version of my example, you enter as generic a function
succ, do I need to write this function or can I pass the attribute 'succ at
instantition time : 
entity counter is 
   generic ( type count_type; low, high : count_type; 
                 function succ ( V : count_type ) return count_type ); 
2 ) How would you rewrite the following code : 
entity add_substract is 
   generic ( type signal_type, type enum_operation_type);
  port ( clk : in bit; operation : in enum_operation_type; data1_in : in
signal_type ; data2_in : in signal_type ; data_out : out signal_type ); 
end entity add_substract;   
-- signal_type can be integer,signed, unsigned .... 
-- enum_operation_type is a enum (add,sub,maxval,minval)
architecture behavioral of add_substract is 
begin 
  add_substract_behavior : process is 
     variable count : count_type := low; 
  begin 
      wait until clk = '1'; 
     if operation=add then 
           data_out <= data1_in +data2_in; 
      elsif operation=sub then 
          data_out <= data1_in - data2_in; 
     elsif operation = maxval then 
         if data1_in > data2_in then 
              data_out <= data1_in; 
         else 
              data_out <= data2_in; 
         end if; 
     else                   -- operation = minval 
         if data1_in < data2_in then 
              data_out <= data1_in; 
         else 
              data_out <= data2_in; 
         end if; 
      end if; 
  end process add_substract_behavior; 
end architecture behavioral; 
3) Will those 2 examples be only accepted by simulators or the intention is
also to have them supported by synthesis tools? 
Kind Regards,
Yannick
----------------------------------------------------------------------------
-----------------------------
Yannick Grugni                              Design Competence Center Leuven
VLSI Engineer                                       Interleuvenlaan 74-82
Tel: +(32)16.390.742                            3001 Leuven
yannick.grugni@philips.com           Belgium
----------------------------------------------------------------------------
------------------------------