Re: too many functions?

Subject: Re: too many functions?
From: Jim Lewis (jim@synthworks.com)
Date: Tue Dec 17 2002 - 09:38:32 PST

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 - 09:53:16 PST