Subject: [Fwd: from ["Robert J Myers"
-----Forwarded Message-----
One comment about the string substitution -- as long as it is
The issue that I foresee is that of someone who has to pick up a design
Case in point: Mentor's supplying an Arithmetic library a few years ago.
Regards,
Robert J. Myers
|---------+----------------------------------->
Hi Steve.
I agree.
There is a concern about breaking existing code
Renaming of existing functions just has to be announced
A real headache is when formal parameters or
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 - 15:55:09 PST
From: Peter Ashenden (peter@ashenden.com.au)
Date: Mon Dec 09 2002 - 15:46:28 PST
adequately documented somewhere, then there may not be
a problem with doing it this way.
a few years down the road and finds that there are problems when
trying to use the latest tools to compile/simulate/synthesize without any
information about the change(s) occurring. They may or may not know
how to resolve the issues that pop up.
The original designer for one FPGA did use a "Library Arithmetic;" call
out
that was handled with the Leonardo synthesis tool as well as Modelsim
version at the time the design was done. When I had to revise the code
recently, using the latest Modelsim suite for simulation checkout, I had to
fix
references to make the design work. I've updated the design database
to reflect the current library selections being supported by Mentor.
However,
I'm not sure what a novice to using VHDL would have done (not sure if
Mentor documented anywhere as to the dropping of the Arithmetic library).
Bob
Technical Consultant -- EE/PDC Process and Tools
Raytheon Systems Company
2501 W. University Drive M/S 8020
McKinney, TX 75071
(972) 952-4352
| | John Michael Williams |
| | <jwill@AstraGate.net> |
| | Sent by: |
| | owner-vhdl-std-logic@ser|
| | ver.eda.org |
| | |
| | |
| | 12/09/2002 01:34 PM |
| | |
|---------+----------------------------------->
>--------------------------------------------------------------------------------------------------------|
| |
| To: Std_Logic 1164 <vhdl-std-logic@server.eda.org> |
| cc: "Numeric_Std 1076.3" <vhdlsynth@server.eda.org> |
| Subject: Re: std_logic_1164: CP-010 and numeric_std:Rob_P1 |
>--------------------------------------------------------------------------------------------------------|
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.
adequately, maybe by a maintenance comment in the
packages?
types are changed; name changes are relatively
innocuous.
--
John
jwill@AstraGate.net
John Michael Williams