Summary: Re: too many functions?

Subject: Summary: Re: too many functions?
From: Jim Lewis (jim@SynthWorks.com)
Date: Tue Dec 17 2002 - 12:47:52 PST

John,
   Currently there are not any homographs in these packages.
As a result of the changes to the packages, there are
no homographs. So the overlap is not conflicting
functions.

    The overlap discussed in this thread is whether
every function that is defined for std_logic_vector
should also be defined for signed & unsigned.
Precedence says yes, logic operators are currently
implemented for signed and unsigned.

     Many of these overlapping functions are simpily
implemented by referencing std_logic_1164:

   -- Id: L.2
   function "and" (L, R: UNSIGNED) return UNSIGNED is
     variable RESULT: UNSIGNED(L'LENGTH-1 downto 0);
   begin
     RESULT := UNSIGNED(STD_LOGIC_VECTOR(L) and STD_LOGIC_VECTOR(R));
     return RESULT;
   end "and";

So, 1164 is already referenced by numeric_std.

    There is also some clean-up work that has been
proposed with respect to the std_match function since
some of the overloading really belongs in
std_logic_1164. We are arbitrating as to how to
deal with this situation. Currently there are two
proposals:

Proposal 1) Move the std_ulogic, std_logic_vector,
std_ulogic_vector versions of std_match to std_logic_1164
and change numeric_std and std_logic_1164 versions
simultaneously.

Many are not comfortable with this since they do not
feel we can actually finish both at the same time.

Also this would break any code that called std_match
as "numeric_std.std_match".

Proposal 2) Add a function named match to std_logic_1164
and numeric_std which has the same functionality as
std_match.

As an addendum, some want to implement std_match as
an alias to match (wind and weather permitting).

There was additional discussion regarding whether
match should be implemented for unsigned and signed.
Rob is concerned about "too many functions."
Others of us are excited about having a full set
of everything for unsigned and signed.

Cheers,
Jim

John Michael Williams wrote:
> Hi Jim.
>
> Why not add a USE... 1164 to .3 to access
> the functionality?
>
> I think that if there are multiple overlaps, the overlaps
> should be removed from both packages and
> separately packaged, so both Stds can reference them.
>
> 1164 is a standard, not a package, so I would agree with
> you to the extent that, in principle, any overlap was
> an error in the management in the standards content,
> not an error on the part of any particular WG.
>
> Likewise, though, if 1164 is a Std, and not just
> a package, it could normatively require that users
> USE .3 to be conforming.
>
> The problem here would be in version control: If a bug or
> update in .3 changed the wrong thing, it might either:
> (a) break the 1164 package or (b) conflict with users who
> were naming their own types in expectation they
> knew the names already taken by 1164.
>
> This last again is an argument in favor of spinning off
> all overlaps into a single, independent package.
>
> Both 1164 and .3 then could USE this package or not.
> This would put things under control; making 1164 bigger
> by copying stuff from elsewhere would make it more
> independent, but it would force a lot of
> inderdependencies among Stds (1164 & .3, at least)
> which should be avoided as a matter of good design.
> 

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

This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 13:05:53 PST