Dumb VHDL Question -- Type Conversion

T

Tim Wescott

Guest
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!!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
On 7/16/2010 12: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!!
I'm assuming you're talking about numeric_std?

TO_SIGNED(intval, width) and TO_UNSIGNED(intval, width)

--
Rob Gaddi, Highland Technology
Email address is currently out of order
 
On 07/16/2010 12:18 PM, Rob Gaddi wrote:
On 7/16/2010 12: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!!


I'm assuming you're talking about numeric_std?

TO_SIGNED(intval, width) and TO_UNSIGNED(intval, width)

That worked. I seem to have a collision between libraries in my Xilinx ISE:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

gets me a flood of errors, although I seem to be able to comment out the
std_logic_arith.

I lack a good language/library reference*, or I'm stupidly not looking
in the right place, else I'd be able to answer my questions by myself.

* By definition -- because a good reference would answer the question.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
"Tim Wescott" <tim@seemywebsite.com> wrote in message
news:jKednaQFZYsOVN3RnZ2dnUVZ_jGdnZ2d@web-ster.com...
I seem to have a collision between libraries in my Xilinx ISE:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

gets me a flood of errors, although I seem to be able to comment out the
std_logic_arith.
These two libs should never be used together. The former is a standard
library, which should be used in new code, and the latter is a legacy
Synopsys library which might be required when working with the existing
code.

/Mikhail
 
On 07/16/2010 02:24 PM, MM wrote:
"Tim Wescott"<tim@seemywebsite.com> wrote in message
news:jKednaQFZYsOVN3RnZ2dnUVZ_jGdnZ2d@web-ster.com...
I seem to have a collision between libraries in my Xilinx ISE:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

gets me a flood of errors, although I seem to be able to comment out the
std_logic_arith.


These two libs should never be used together. The former is a standard
library, which should be used in new code, and the latter is a legacy
Synopsys library which might be required when working with the existing
code.
Ah, Xilinx -- the latter is what Xilinx sticks in as boilerplate when
you get lazy and tell it to just make you a test bench from a file.

Thanks for the tip.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
On Jul 16, 3:01 pm, Tim Wescott <t...@seemywebsite.com> wrote:
On 07/16/2010 02:24 PM, MM wrote:





"Tim Wescott"<t...@seemywebsite.com>  wrote in message
news:jKednaQFZYsOVN3RnZ2dnUVZ_jGdnZ2d@web-ster.com...
I seem to have a collision between libraries in my Xilinx ISE:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

gets me a flood of errors, although I seem to be able to comment out the
std_logic_arith.

These two libs should never be used together. The former is a standard
library, which should be used in new code, and the latter is a legacy
Synopsys library which might be required when working with the existing
code.

Ah, Xilinx -- the latter is what Xilinx sticks in as boilerplate when
you get lazy and tell it to just make you a test bench from a file.

Thanks for the tip.

--

Tim Wescott
Wescott Design Serviceshttp://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details athttp://www.wescottdesign.com/actfes/actfes.html- Hide quoted text -

- Show quoted text -
It used to frustrate me no end the way ISE plugged in the wrong
library, until I found the script that does it and CHANGED it. Look
under Xilinx=>ISE=>data=>projnav=>scripts and modify file
"dpm_sourceTasks.tcl" to your liking. TCL syntax is fairly basic in
the area you'll want to change.
delete:
puts $hFile "use IEEE.STD_LOGIC_ARITH.ALL;"
puts $hFile "use IEEE.STD_LOGIC_UNSIGNED.ALL;"
add:
puts $hFile "use ieee.numeric_std.all;"

Customize to add your own name, company header, etc.
Hopefully they haven't changed the framework in version 12.

HTH,
John
 
Hi Tim,

a good quick reference is the "Qualis Ref Card":
http://www.google.de/url?sa=t&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fwww.vhdl.org%2Frassp%2Fvhdl%2Fguidelines%2Fvhdlqrc.pdf&rct=j&q=qualis%20vhdl%20refcard&ei=qX1BTIHIN9ecOODYraQN&usg=AFQjCNFjtNN-k9EA-H4S1K1CZrW58cNRrQ

or just type "qualis vhdl refcard" into the market hegemonial browser if the link
above is bent over 17 lines. It's the first hit (at leas it was for me)

Other references I use:
- VHDL Spec from IEEE
- Ashendon's Book

Or what I usually do, power up the Aldec activeHDL simulator (you can get a free
version from the Lattice website) and click on the Library manager. If you select
the IEEE libraries and go to the "Package Contents" window you get the prototypes
for all functions and procedures.

This might of course work in modelsim too, I haven't tried.

Regards,
Charles
 
Hi again Tim,

sorry, the reference card you are probably really looking for is under

http://www.google.de/url?sa=t&source=web&cd=1&ved=0CBwQFjAA&url=http%3A%2F%2Fwww.vhdl.org%2Frassp%2Fvhdl%2Fguidelines%2F1164qrc.pdf&ei=_oBBTN7hKo2iOM6i7fAM&usg=AFQjCNHBm6d324gTZ40kvAWp6Lq0nB_5BQ

(or "qualis packages refcard" in the previously mentioned hegemonial search engine)

Charles
 
On Fri, 16 Jul 2010 14:06:00 -0700, Tim Wescott wrote:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

gets me a flood of errors, although I seem to be able to comment out the
std_logic_arith.
Right. The two packages are somewhat similar. For example they
both define types SIGNED and UNSIGNED, and they both define "+"
operators for those types.

In VHDL, if you "use .all" some packages and more than
one of the packages defines the same identifier, then
the identifier is hidden to spare you the embarrassment
of not knowing which one is being used.

You can still reach it. For example, given your two
USE clauses, you could do

signal S8: SIGNED(7 downto 0); -- Error, SIGNED is hidden
signal S8: ieee.numeric_std.SIGNED(7 downto 0); -- OK

and, indeed,

S8 <= S8 + 1; -- ERROR: "+" operator definition is hidden
S8 <= ieee.numeric_std."+"(S8, 1); -- OK

but I suspect you would agree with me that neither of
these is a terribly good idea.

It's nice that JustJohn showed us how to defeat the silly
Xilinx default use clauses - thanks for the tip!
--
Jonathan Bromley
 
On Jul 16, 5:03 pm, JustJohn <justjohna...@gmail.com> wrote:
On Jul 16, 3:01 pm, Tim Wescott <t...@seemywebsite.com> wrote:





On 07/16/2010 02:24 PM, MM wrote:

"Tim Wescott"<t...@seemywebsite.com>  wrote in message
news:jKednaQFZYsOVN3RnZ2dnUVZ_jGdnZ2d@web-ster.com...
I seem to have a collision between libraries in my Xilinx ISE:

declaring both of the following:

USE ieee.numeric_std.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;

These two libs should never be used together. The former is a standard
library, which should be used in new code, and the latter is a legacy
Synopsys library which might be required when working with the existing
code.

Ah, Xilinx -- the latter is what Xilinx sticks in as boilerplate when
you get lazy and tell it to just make you a test bench from a file.

Thanks for the tip.

Tim Wescott
Wescott Design Serviceshttp://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details athttp://www.wescottdesign.com/actfes/actfes.html-Hide quoted text -

- Show quoted text -

It used to frustrate me no end the way ISE plugged in the wrong
library, until I found the script that does it and CHANGED it. Look
under Xilinx=>ISE=>data=>projnav=>scripts and modify file
"dpm_sourceTasks.tcl" to your liking. TCL syntax is fairly basic in
the area you'll want to change.
delete:
  puts $hFile "use IEEE.STD_LOGIC_ARITH.ALL;"
  puts $hFile "use IEEE.STD_LOGIC_UNSIGNED.ALL;"
add:
  puts $hFile "use ieee.numeric_std.all;"

Customize to add your own name, company header, etc.
Hopefully they haven't changed the framework in version 12.

HTH,
John- Hide quoted text -

- Show quoted text -
Umm, the tcl file I listed above is for regular vhdl modules. For
testbenches, the tcl'er is:
Xilinx->ver->ISE->data->testbnch2.tcl
 
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 pm, 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 <= (count + 1 ) mod max_count; -- assume max_count = 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
 

Welcome to EDABoard.com

Sponsor

Back
Top