STD_LOGIC_VECTOR >> NATURAL ?

[aleksa]

DBUS : in STD_LOGIC_VECTOR (7 downto 0);

signal ADDRESS : natural range 0 to 9;




ADDRESS <= DBUS (3 downto 0);

What conversion function should I use here?


Using ISE 10.1

 

[Mark McDougall]

On Wed, 21 Jan 2009 13:55:11 -0800 (PST)

That depends. How exactly do you plan to reduce an 8 bit port (256
possible values) to an integer between 0-9 (10 posible values)?

Actually, he's reducing a 4-bit port (16 values) to 10 values.

Doesn't really change the question though...

This is my VHDL type conversion bible...
<http://dz.ee.ethz.ch/support/ic/hdl/vhdlsources.en.html>

Regards,

 

[Mark McDougall]

Actually, he's reducing ...

I shouldn't have assumed the OP is a "he"... sorry.

Regards,

 

[KJ]

DBUS : in STD_LOGIC_VECTOR (7 downto 0);

signal ADDRESS : natural range 0 to 9;

ADDRESS <= DBUS (3 downto 0);

What conversion function should I use here?

ADDRESS <= to_integer(unsigned(DBUS(3 downto 0)));

But unless you have complete control of DBUS and can insure that DBUS(3
downto 0) will never be "1010" thru "1111" then you'll likely get a
simulation error because the result of the conversion to integer will be 10
thru 15 which is outside of the defined range (but it will synthesize just
fine). If you can't guarantee that DBUS(3..0) won't do that then changing
the range of ADDRESS to be "natural range 0 to 15" will be your next change.
Either way, you'll get the exact same synthesis result because synthesis
doesn't give a hoot if your logic goes out of range at run time.

Kevin Jennings

 

[aleksa]

ADDRESS <= to_integer(unsigned(DBUS(3 downto 0)));

ISE's reply: "to_integer can not have such operands in this context".

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

use IEEE.numeric_std.ALL; -- tried both
--use IEEE.numeric_bit.ALL;

But unless you have complete control of DBUS and can insure that DBUS(3
downto 0) will never be "1010" thru "1111" then you'll likely get a
simulation error because the result of the conversion to integer will be 10
thru 15 which is outside of the defined range (but it will synthesize just
fine). If you can't guarantee that DBUS(3..0) won't do that then changing
the range of ADDRESS to be "natural range 0 to 15" will be your next change.
Either way, you'll get the exact same synthesis result because synthesis
doesn't give a hoot if your logic goes out of range at run time.

Kevin Jennings

I can insure that DBUS will be in the range 0 to 9.

 

[Tricky]

You should not use std_logic_arith and numeric_std in the same design.
They have conflicting definitions of signed and unsigned types, so
using both will confuse any compiler.

On a side note - why do Xilinx STILL bang on with std_logic_arith/
unsigned/signed, while other manufacturers seem to be able to keep up
with the times, and change all their literature?

 

[Martin Thompson]

ISE's reply: "to_integer can not have such operands in this context".

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

use IEEE.numeric_std.ALL; -- tried both
--use IEEE.numeric_bit.ALL;

Don't use std_logic_arith/unsigned. Especially if you have declared
numeric_std/bit as well. They "overlap".

You have to use one or the other - I would advise that you choose
numeric_std/bit as they are proper standard libraries.

Google "numeric std vs std_logic_arith" for gory details.

Cheers,
Martin

 

[Andy]

Either way, you'll get the exact same synthesis result because synthesis
doesn't give a hoot if your logic goes out of range at run time.

Kevin Jennings

The synthesis tool may not care, but it is also not bound by the
language to any specific behavior. Synthesis will generally implement
enough bits to handle the range specication of the natural signal (in
this case, four bits). However, if the assignment goes out of the
effective range of the number of bits implemented, the synthesis tool
is free to do whatever it wants. Since the most efficient
implementation is just to truncate, that is usually implemented. In
order to specify that the synthesis results must be truncated to the
implemented bits, a modulo operation is generally required prior to
assignment.

Technically, the synthesizer is free to do anything it wants for
asignements outside even the specified range (values 0 to 9 in this
case) since those cannot be performed within the bounds of the
language itself. This also means that comparisons on the contents
could be optimized. For instance, a comparison of Address = 9 need
only look at bits 0 and 3 if the range of Address is 0 to 9. It does
not matter what the other two bits are, since per the range
specification, they cannot be set if 0 and 3 are set. I have seen
similar optimizations using a natural counter with a range 0 to 5, but
I do not know whether the synthesis tool made the optimizations based
on a reachability analysis of the counter, or on just the range
specification.

Andy

 

[Nicolas Matringe]

Tricky a écrit :

You should not use std_logic_arith and numeric_std in the same design.
They have conflicting definitions of signed and unsigned types, so
using both will confuse any compiler.

I thought one of the VHDL commandments was something along the lines of
"Thou shalt not use std_logic_arith" ;-)

Nicolas

 

[Mike Treseler]

Tricky a écrit :

I thought one of the VHDL commandments was something along the lines of
"Thou shalt not use std_logic_arith" ;-)

But that is a venial sin,
if unsigned or signed types are actually used

"Thou shalt not use more than one math library."

is the one to carve in stone.

-- Mike Treseler