Subject: RE: CP-007 - comments on Jim's suggestions
From: Bailey, Stephen (SBailey@model.com)
Date: Mon Aug 18 2003 - 22:47:42 PDT
All,
On decimal radix:
What is the issue here? Binary, octal, hex, decimal? What difference does it make what the radix is. They are ALL numeric values!
Second, on padding/stripping to round out hex, octal and decimal values:
Why not provide signed versions of the routines to cover sign-extension when needed? The padding/stripping seems to me to be very useful.
Instead of dropping functionality in these situations, we should be resolving the problem by adding functionality as that is how the users benefit. And, the cost to implementors is virtually nothing.
Am I missing some other deep, dark problem with decimal radix and padding/stripping?
-Steve Bailey
> -----Original Message-----
> From: Jim Lewis [mailto:Jim@synthworks.com]
> Sent: Monday, August 18, 2003 8:35 PM
> To: Jayaram Bhasker
> Cc: Peter Ashenden; vhdl-std-logic@eda.org
> Subject: Re: CP-007 - comments on Jim's suggestions
>
>
> 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-4787
>
> Expert VHDL Training for Hardware Design and Verification
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
This archive was generated by hypermail 2b28 : Mon Aug 18 2003 - 22:51:16 PDT