Subject: Re: std_logic_1164: CP-010 and numeric_std:Rob_P1
From: John Michael Williams (jwill@AstraGate.net)
Date: Mon Dec 09 2002 - 11:34:44 PST
Hi Steve.
I agree.
There is a concern about breaking existing code
by changing names. This is a real concern, but it
actually is about minimal, because a simple name change
can be fixed by a fairly straightforward string
substitution in the source code.
Renaming of existing functions just has to be announced
adequately, maybe by a maintenance comment in the
packages?
A real headache is when formal parameters or
types are changed; name changes are relatively
innocuous.
--
John
jwill@AstraGate.net
John Michael Williams
Stephen Bailey wrote:
>
> All,
>
> To add my opinion to this discussion:
>
> I agree with the view that the match function (should) work on
> std_[u]logic[_vector], therefore, it should be defined in 1164. I see no
> value in having identical subprograms in std_logic_1164 and numeric_std that
> differ only by name (match vs. std_match). If anything, having different
> names for identical routines creates confusion (although this is a
> relatively minor consideration).
>
> My recommendation for resolving this is:
>
> 1. Define the subprograms in std_logic_1164. Name them match. (No value
> added for typing 4 additional characters plus it avoids potential homograph
> with std_match alias below.)
> 2. Modify numeric_std to replace the now duplicate subprograms with aliases
> to the subprograms in 1164. This will provide backward compatibility for
> any code specifying "numeric_std.std_match". It also allows the numeric_std
> package to be updated independent of 1164 (as long as 1164 is standardized
> first or concurrently).
>
> -Steve Bailey
>
> > The problem with _moving_ the std_match functions from numeric_std to
> > std_logic_1164 is that models that refer to numeric_std.std_match
> > (either with selected names or via a use clause) would break.
> >
> > The problem with _copying_ the functions to std_logic_1164 is that you
> > would then have homographs in the two packages, and models that use (in
> > the use clause sense) both packages and refer to std_match would break.
> >
> > Hence my proposal to call the functions in std_logic_1164 match instead
> > of std_match. You could add match as an alias for std_match in
> > numeric_std if you want consistency of naming across the packages for
> > new models.
> >
> > Cheers,
> >
> > PA
> >
> >
> > On Sat, 2002-12-07 at 13:01, Jim Lewis wrote:
> > > CP-010 Analyzed Add match functions like numeric_std.std_match
> > > http://www.eda.org/vhdl-std-logic/proposals/CP-010-match-functions.txt
> > >
> > > In numeric_std, it was proposed in proposal Rob_P1/P2
> > > (http://www.eda.org/vhdlsynth/pilot/hm/0026.html), that
> > > the std_match functions for std_ulogic, std_logic_vector, and
> > > std_ulogic_vector be moved to std_logic_1164.
> > >
> > > This would satisify CP-010 and Rob_P2. Is this a move that
> > > everyone would support? Otherwise, CP-010 proposes adding a match
> > > function to std_logic_1164. This means that we should add a
> > > match function to numeric_std. There is more meaning to a
> > > function when it is globally used.
> > >
> > > Cheers,
> > > Jim
> > >
> > > --
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > 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
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > --
> > 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
> >
This archive was generated by hypermail 2b28 : Mon Dec 09 2002 - 11:36:02 PST