Subject: Re: too many functions?
From: Rob Anderson (rob@reawebtech.com)
Date: Tue Dec 17 2002 - 13:26:34 PST
Hi Jim, comments below...
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.
1164 recommends std_logic_vector for vector ports and signals,
then says a designer can choose std_logic or std_ulogic for
scalar ports and signals. Numeric_std chose std_logic_vector
to conform to common usage.
I think non-resolved types can trip up casual
users, because they expect resolved behavior for a 9
value type with 'Z', 'H', 'L'.
Why challenge the casual users? They already think Verilog
is simpler.
>
> 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.
That is an interesting idea. I was wondering why the
interest in "all functions" for these types.
However we never intended numeric_std to be used in such
a general way. It is a specific encoding. Std_logic_vector
is more general. There are vector busses that are encoded
differently: one_hot, BCD, character, control busses and
busses of clocks. Neither signed nor unsigned would be
appropriate for these types of vector busses.
But I do think people should be encouraged to use signed and
unsigned vectors between components, it makes sense.
But then it implies people should be protected from
using the wrong operators on those types. So it still
doesn't make sense to put all possible operators and
functions in numeric_std.
Then we could promote the use of other subtypes of
std_logic_vector, and type checking would prevent people
from hooking up the wrong things.
Verilog is type-free, but they have had to add data types
like signed, and with zero foresight, the conversions
and file IO are very difficult. I think types are a valuable
part of VHDL, and we should try to do good things
with them.
> 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.
>
What exactly? Are they doing something for case statements?
>
> If you differentiate between a numeric and a non-numeric,
> you get into trouble sometimes when you write the testbench.
Let's be more specific, if you are writing an algorithm, and the
spec is written in terms of integer variables, you should
be able to use numeric_std. An example is a BIST algorithm.
> 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.
I have written BIST algorithms, they are specified in terms
of integers and there is no problem using numeric_std.
I just finished translating some FFT's from VHDL to Verilog,
even with Verilog 2000 I had trouble getting things right
because there is no type checking in Verilog, every function
"works" for everything. I don't find that helpful.
--Rob
>
> 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
>
>
>
>
This archive was generated by hypermail 2b28 : Tue Dec 17 2002 - 13:32:00 PST