Dumb VHDL Question -- Type Conversion

On 7/16/2010 8:07 PM, Tim Wescott wrote:
> How do I assign an integer value to 'signed' or 'unsigned' from the IEEE
> libraries?
>
> I'm having this difficulty with my test benches. Surely there's a set of
> library functions to do it, but I can't seem to figure out what they are!!
>

http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf

The information on types and conversions in Jim's paper is very good.

The recommendations for coding style (based on limitations of
synthesis tools) are a bit dated. Synth tools have come a long way in
7 years.

I recommend using integer for arithmetic if your data paths are less
than 32 bits. Mod has been well supported for quite a while (it was
then if you used decent FPGA tools), and is very handy for making sure
you don't have overflows (which do not go silently in the night in
simulation with integers). For example:

signal count: natural range 0 to max_count - 1;
...
count <= (count + 1 ) mod max_count; -- assume max_count = 2**n

will roll over automatically for both increment and decrement.

Also since count - 1 is completely legal for count = 0 (so long as you
don't try to store it back into count). Therefore, you can extract the
carry bit like so:

if count - 1 < 0 then -- carry bit set
  do_something;
  count <= max_count - 1; -- safe (BTW, constant arithmetic is free)
else
  count <= count - 1;
end if;

This also works with "if count + 1 >= max_count then".

Integer type arithmetic also automatically promotes natural - natural
=> integer (use mod to "resize" when necessary).

You might look into the new fixed point package, which also can be
used for arithmetic w/o fractional bits. It automatically promotes
result size to accomodate largest possible result. Unfortunately, it
does not promote ufixed - ufixed => sfixed.

His recomendations for resource sharing and separation of computation
from state logic are unnecessary now; code it so you know WHAT it is
doing, and let the tool figure out HOW to do it.

Andy

On Jul 19, 4:23=A0pm, Andy <jonesa...@comcast.net> wrote:

> I recommend using integer for arithmetic if your data paths are less
> than 32 bits. Mod has been well supported for quite a while (it was
> then if you used decent FPGA tools), and is very handy for making sure
> you don't have overflows (which do not go silently in the night in
> simulation with integers). For example:
>
> signal count: natural range 0 to max_count - 1;
> ...
> count <=3D (count + 1 ) mod max_count; -- assume max_count =3D 2**n
>
> will roll over automatically for both increment and decrement.

With modern (and by this I mean XST 10.1.3 supports!) the modulo need
not be a power-of-two.

-a

Hi Andy,
I thought I would wait to address your comments until after I checked
the
results in a couple of synthesis tools.  Too busy to spend too much
time
fooling around, but I finally got to it.

> The information on types and conversions in Jim's paper is very good.
>
> The recommendations for coding style (based on limitations of
> synthesis tools) are a bit dated. Synth tools have come a long way in
> 7 years.

The paper's focus is on using numeric_std.  Outside of showing how to
use
numeric_std and its overloading, there are only two recommendations
and I note you (Andy) object to both.
1)  Use integers primarily for literal values
2)  Separate arithmetic objects from statemachines.

It was pretty cool that the integer counters tested well in all of the
synthesis
tools I tried.   However, I note that unsigned integers are currently
limited  to 31 bits,
and signed integers are limited to 32 bits so from a coding
perspective, this integers
are not a complete solution.  Instead, Integers are great for counters
and small math
problems and for all else one has to use numeric_std (and hence the
relevancy of
the paper).  In addition, if one likes thinking in bits, this is much
easier to do with
signed and unsigned than with integers.

> His recommendations for resource sharing and separation of computation
> from state logic are unnecessary now; code it so you know WHAT it is
> doing, and let the tool figure out HOW to do it.
The second guideline, separate arithmetic objects from statemachines,
is based as
much on methodology as it is on historical tool issues.  From a
methodology
perspective, collecting all arithmetic objects into a separate process
and coding
them allows one to focus more on the anticipated hardware architecture/
structure.
This is important as it allows us to see the problem holistically and
potentially
implement an alternate, better hardware architecture.

When a chip is big and fast enough, relative to the problem we are
trying
to solve, we do not need to worry as much about hardware architecture/
structure,
but for many of us, I doubt that we are there yet.

Best,
Jim