Subject: Re: too many functions?
From: John Michael Williams (jwill@AstraGate.net)
Date: Tue Dec 17 2002 - 12:07:42 PST
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.
--
John
jwill@AstraGate.net
John Michael Williams
Jim Lewis wrote:
>
> Rob,
>
> > Illogical. The fact "it" is in 1164 does not imply "it"
> > should be in numeric_std.
>
> I disagree with this. The following gives a basis as to why.
>
> A while back, I proposed that we change the base type of
> unsigned and signed to std_ulogic since most of this is done
> in a point to point fashion. If you want tristate, type
> caste to std_logic_vector. My perspective is that nothing
> should be a based on a tristate type unless it is really a
> tristate.
>
> Resolution: Original package design intentionally picked
> std_logic for a number of reasons. The course is set and
> at this point we cannot change it (without potentially
> disrupting those who already use the pacakge). Although,
> I would rather have std_ulogic, I support the rationale
> of the resolution.
>
> I would like to make a similar agrument for supporting
> all std_logic_1164 functions in numeric_std. Currently
> numeric_std supports all logic operators and std_match.
> The package is already going in this direction.
> With the exception of the match function, we have pretty
> much agreed to add the new things to numeric_std that are
> either in std_logic_1164 or are slated to be in
> std_logic_1164.
>
> If we do this, I could visualize using a methodology that
> only uses the types std_logic, unsigned, and signed.
> Granted, some synthesis tool vendors would have to update
> their netlist generators to understand the simple
> relationship between unsigned, signed, and std_logic_vector.
>
> Keep in mind, I support the notion that we should be
> supporting an unsigned numeric package for std_logic_vector.
> With respect to supporting unsigned numeric comparisons
> for std_logic_vector, I think ISAC is very close to
> fixing the LRM to allow this.
>
> If you differentiate between a numeric and a non-numeric,
> you get into trouble sometimes when you write the testbench.
> Consider Address. Clearly Address is just a group of bits.
> However, when I write a testbench that wants to drive some
> values to test a RAM, then I want to do something algorithmic
> and numeric to this address (such as increment). It causes
> problems when my type does not support this notion.
>
> Cheers,
> Jim
>
> Rob Anderson wrote:
> > Comments below:
> >
> > David Bishop wrote:
> >
> >> Rob Anderson wrote:
> >>
> >>> John Wrote:
> >>>
> >>> > >If there is a logic-state meaning, 1164 should
> >>> > > add the function; if there is a computational
> >>> > > meaning, numeric-std.
> >>>
> >>> Then David B. wrote:
> >>>
> >>> >
> >>> > Agreed. Unfortunately this got overlooked when 1164 was originally
> >>> > published.
> >>> >
> >>> > The new "match" functions in 1076.3 (numeric_std) would only
> >>> > be for the "signed" and "unsigned" types.
> >>>
> >>> This question is not answered:
> >>>
> >>> "match" does not have a computational meaning, so why
> >>> are we adding it to numeric_std?
> >>>
> >>
> >> "match" for the "signed" and "unsigned" types have to be in the
> >> numeric_std package because that is where the "signed" and
> >> "unsigned" types are defined. You can't put there anywhere
> >> else unless you create yet another package.
> >
> >
> >
> > Clear, but beside the point.
> >
> >
> >>
> >> For completeness, if you can match a "std_logic_vector" should
> >> you not be able to match an "unsigned"?
> >
> >
> >
> > Illogical. The fact "it" is in 1164 does not imply "it"
> > should be in numeric_std.
> >
> > There are lots of functions in 1164 that are not in numeric_std.
> >
> > "not be able to match an "unsigned"?
> >
> > UGH! I don't think you should be able to "XOR" two real numbers
> > either. VHDL has types to protect against bad code.
> >
> >
> >>
> >> Yes, you will have to do a "to_x01" on it before you can actually
> >> perform any numeric fuctions on it.
> >>
> >
> >
> > You mean to_01. to_x01 isn't in this package either. To_01 was added
> > to account for default behavior of all metavalues in these types.
> > A metavalue in any location causes the whole array to be set to one
> > value. The reasoning was that it was incorrect to handle individual
> > bit positions for these types.
> > b
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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 - 12:20:28 PST