Subject: Re: match functions
From: John Michael Williams (jwill@AstraGate.net)
Date: Fri Dec 13 2002 - 09:53:33 PST
Hi Dave.
All these functions are built on the basic VHDL,
which depends on good analyzers for portability, not on
pre-composed packages. Packages are secondary
products. They are a trickle-down from VHDL.
Instead of putting a lot of miscellaneous
stuff into packages, why not issue some sort of
standardized collection of VHDL routines:
edge-detectors, matchers, adders, etc?
The user would then include the standard
routine in their code any way they wanted. If
it worked for them, then it would work if
ported to any other environment with a working
analyzer/elaborator.
Why is so much effort going into fixed,
multifunctional packages,
rather than individual functionalities?
Why should a highly specialized "match" function be
standardized? What about "rising_edge"? What
is the actual added value, in view of the existing
complexity and presumed skill of designers?
If these things are going to be standardized, they
should maybe be standardized individually, not
in one "winner-takes-all", complicated, unusably
bulky melange. This I think is a serious issue.
Standards development should know where to stop,
and user confusion (not to mention WG indecision)
is a good place, in my opinion.
--
John
jwill@AstraGate.net
John Michael Williams
David Bishop wrote:
>
> John Michael Williams wrote:
> >
> > Hi Dave.
> >
> > Thanks for the explanation.
> >
> > I can see the problem is trivial to someone knowing
> > all this, but, where should a user go to see what
> > his or her "match" function did? You already have
> > at least two different packages (the final
> > two assignments in your example below); what if
> > yet another group decides they want a "match"
> > function, too?
>
> There you see the basic problem. If I already include
> "numeric_std" then you have a match function called
> "std_match". IF you only include std_logic_1164 (which
> is the logical place for such a function) you don't have
> one.
>
> Both functions will work identically (1164 can just copy
> my table out of 1076.3) and it won't matter which one they
> look at.
>
> I.E. it was done for historical purposes.
>
> > It indeed appears that the present (and historical)
> > rationale is that if the word "match"
> > is determined to mean quite different things
> > (comparing logic states seems totally different
> > from numerical values, to me), then two different
> > words are be used. So, presently, it's just a
> > small matter to be worked-around.
>
> >From a software or hardware point of view? That's the
> basic issue here. "logically" the "=" is the correct
> representation, "electronically" std_match or match is.
>
> > Would it make sense to define a new package, maybe
> > "compare_functions", to contain all definitions
> > of "match"? This might include the std_match
> > functions currently in .3? Maybe renamed to "match"?
>
> We already have "std_logic_1164" and "numeric_std". In my
> opinion, that is already two too many packages.
>
> Please, lets not add another one unless we really have to.
>
> > Future new arithmetic types or new logic states
> > would just mean adding more overloads.
>
> Yes, this is exactly how and why the "numeric_std" package was
> originally designed.
>
> > I see the start of a breakdown in the current
> > numeric/logical categorization, which may cause
> > hardship for users in the future.
>
> That's why I'm on this SIG, and being active. I have a major in hardware
> design and a minor in software design, plus years of experience doing
> both in the industry. Besides, I have to live with what is decided
> here.
>
> --
> David W. Bishop dbishop@vhdl.org
This archive was generated by hypermail 2b28 : Fri Dec 13 2002 - 09:55:00 PST