Subject: Re: CP-007 - comments on Jim's suggestions
From: Jim Lewis (Jim@synthworks.com)
Date: Mon Aug 18 2003 - 19:34:57 PDT
Peter, Bhasker, and all,
OOPS, I thought I sent this already. Thanks for the
reminder.
------ Start of Executive Summary ------
Your assumptions about what I was thinking are accurate.
I see compelling reasons that we should gravitate toward
having a numeric sense of std_logic_vector.
The heart of the problem seems to be what is the appropriate
type for an object and who gets to determine it. From the
standpoint of an RTL designer, an object is either non-numeric,
unsigned, or signed. However, from the standpoint of a
Verification engineer, almost everything is either unsigned or
signed. There is either nothing or very little that is
non-numeric.
We need to have a solution that works for both parties.
Textio is only used in testbenches as it is not portable
in synthesis.
Detailed discussion follows. Some discussion is mixed in
with the text.
------ End of Executive Summary ------
Currently being only able to work with hexidecimal values
that are a factor of four is unnecessarily difficult.
However, to do anything different, you need to make some
assumptions about the object.
The problem I have run into is that it is quite natural
to end up with a number of things that are technically
not numeric, that we would like to be able to print in
hexidecimal. For one of my projects, I had a 21 bit address
bus. To use the hwrite function as it stands, I had to do:
hwrite(wbuf, "000" & Addr) ;
To use hread, I had to create a variable that was 3 bits
bigger:
variable vAddr : std_logic_vector(23 downto 0) ;
hread(rbuf, vAddr) ;
Addr <= vAddr(Addr'range) ;
It sure would be nice to be able to reduce the complexity
of reading and writing by allowing one to "0" pad the
upper bits of a write if they are not there. And to throw
out the extra bits in a hread (I am not too concerned
whether they are 0 or not).
If hwrite and hread are implemented in std_logic_textio,
or whatever else it gets called, then we have to live with
the implementation. There is no way to re-overload them
without creating a replacement package.
I agree, to do what I want does in some sense obligate
one to take a numeric understanding of std_logic_vector.
This is probably a good thing. The wide spread use of
the package std_logic_unsigned seems to indicate that
many in industry would like to have this type of
functionality.
Like most, for RTL designs, I can get by without a
package like std_logic_unsigned/numeric_std_unsigned.
However, for testbenches, I find it quite necessary.
Again back to address bus, in a testbench it is quite
reasonable to expect to do something numerically
algorithmic to an address bus. To do this with
std_logic_vector without std_logic_unsigned, leads to
type conversion gymnastics.
My opinion is that designers have a compelling need to
have a numeric understanding of std_logic_vector
(and perhaps bit_vector also). In fact, in 1076.3,
there is a proposal to create an unsigned math package
for std_logic_vector (tenatively numeric_std_unsigned).
Perhaps rather than proliferating the number of packages
we have in the language, we should build an unsigned
numeric sense of std_logic_vector into std_logic_1164.
Then we would not have a need to think about how to
implement hwrite and hread.
Jayaram Bhasker wrote:
> I agree with Peter's rationale. We should not assume any decimal interpretation
> for std_logic vectors.
>
> - bhasker
>
>
>
> -----Original Message-----
> From: Peter Ashenden [mailto:peter@ashenden.com.au]
> Sent: Wednesday, July 09, 2003 4:45 PM
> To: vhdl-std-logic@eda.org
> Subject: CP-007 - comments on Jim's suggestions
>
>
> Folks,
>
> When I posted CP-007 proposing std_logic_textio, Jim suggested some
> extensions. To summarize, he suggested
>
> (1) adding decimal read and write procedures (DREAD, DWRITE);
>
> (2) for write procedures, allowing vector lengths other than multiple of 4
> for HWRITE and multiple of 3 for OWRITE, assuming zero padding on the left;
>
> (3) for read procedures, allowing reading characters denoting extra bits
> beyond the length of the vector, and ignoring extra bits on the left if they
> are all zeros.
>
> The rational for (1) is completeness and utility. The rationale for (2) and
> (3) is to provide for vectors that aren't multiples of 4 (hex) or 3 (octal)
> in length.
>
> Jim, please correct me if I have mangled your proposal and rationale.
This is accurate.
> Seems to me, however, that there is an implicit assumption in these
> extensions, namely, that the vectors represent binary-coded integers. If
> that assumption is true, then doing decimal I/O, padding with zeros and
> ignoring leading zeros makes sense. If the assumption is false, doing these
> things doesn't make sense.
Ignoring leading zeros is Peter's extension (which I agree with).
This would turn what I proposed originally into a numeric interpretation.
The original proposal (which in principle I still agree with, although
I like Peter's better) was to just ignore leading bits on an hread.
In this case, it would be a non-numeric interpretation.
> Since 1164 doesn't make assumptions about what bit vectors represent,
> perhaps we should rethink Jim's extensions. I might be more appropriate to
> roll them into textio for numeric_bit and numeric_std, where numeric
> interpretation of vectors is assumed. In that case, sensible behavior for
> zero/sign extension can be provided.
There is a numeric_std_textio package planned for types signed and
unsigned. To use this with std_logic_vector would put users back
into type converion bliss. This is not really what I would like.
Alternatively we could end up having one std_logic_vector textio
package for non-numeric printing and a separate one for numeric
printing. Yikes.
>
> Comments?
The problem seems to be is what is the appropriate type for an
object and who gets to determine it. From the standpoint of
an RTL designer, an object is either non-numeric, unsigned, or
signed. However, from the standpoint of a Verification engineer,
everything is either unsigned or signed. There is no or very
little that is non-numeric.
The fall back of course is to require that all array data
objects be either unsigned or signed and forget about
std_logic_vector.
Textio is only used in testbenches as it is not portable
in synthesis. As a result, for this issue, I would rather
error in favor of the verification engineer.
Cheers,
Jim
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Mon Aug 18 2003 - 19:38:13 PDT