conv_integer for unsigned value

[Clemens]

Hi

Normally I always used the function conv_integer to convert a
std_logic_vector into an integer. However, now I have a signal
defined as follows:

signal test : unsigned(31 downto 0);

I wanna use a slice of test for a 4-bit table look-up and I tried
it like this

lookup(conv_integer(test(3 downto 0)));

which doesnt work

However, the following codeexample would be compiled:

lookup(conv_integer(std_logic_vector(test(3 downto 0))));

Anyone can tell me how to do that without this extra converting step to
std_logic_vector?

Many thanks,
Clemens

 

[Nicolas Matringe]

Clemens a écrit :

Hi

Normally I always used the function conv_integer to convert a
std_logic_vector into an integer.

Stop using std_logic_arith etc packages, use numeric_std instead.
Do maths with signed or unsigned vectors and use to_integer conversion
function.

Nicolas

 

[KJ]

Hi

Normally I always used the function conv_integer to convert a
std_logic_vector into an integer.

Poor choice (but not an uncommon one). Use numeric_std instead and the
to_integer() function.

use ieee.numeric_std.all;

However, now I have a signal
defined as follows:

signal test : unsigned(31 downto 0);

I wanna use a slice of test for a 4-bit table look-up and I tried
it like this

lookup(conv_integer(test(3 downto 0)));

which doesnt work

However, the following codeexample would be compiled:

lookup(conv_integer(std_logic_vector(test(3 downto 0))));

Anyone can tell me how to do that without this extra converting step to
std_logic_vector?

lookup(to_integer(test(3 downto 0)));

Kevin Jennings

 

[Clemens]

Poor choice (but not an uncommon one). Use numeric_std instead and the
to_integer() function.

Yes but the thing is that my model is not so bad working with the
std_logic lib. So I havent really the intention to rewrite the whole
stuff, can maybe someone point out if its also possible to solve my
problem in another way?

 

[Mike Treseler]

Yes but the thing is that my model is not so bad working with the
std_logic lib.

Until you tried to do some math.

So I havent really the intention to rewrite the whole stuff,

Not a rewrite, just some global search and replace.
Post here if you have problems.

Here's some references:
http://www.vhdl.org/rassp/vhdl/guidelines/vhdlqrc.pdf
http://www.vhdl.org/rassp/vhdl/guidelines/1164qrc.pdf
http://www.cs.umbc.edu/help/VHDL/packages/numeric_std.vhd
http://mysite.verizon.net/miketreseler/

-- Mike Treseler

 

[Martin Sauer]

Hi,

Clemens a écrit :

Stop using std_logic_arith etc packages, use numeric_std instead.
Do maths with signed or unsigned vectors and use to_integer conversion
function.

Why shouldn't the std_logic_arih anymore?

bye

martin

 

[Mike Treseler]

Why shouldn't the std_logic_arih anymore?

http://groups.google.com/groups/search?q=frequently+used+numeric_std+vec+casts

 

[rickman]

Yes but the thing is that my model is not so bad working with the
std_logic lib. So I havent really the intention to rewrite the whole
stuff, can maybe someone point out if its also possible to solve my
problem in another way?

I recently started using std_numeric signed and unsigned in place of
std_logic_vector and I haven't looked back. I read somewhere that is
is recommended to use SLV for I/O, but I'm not even sure why that
would be. Maybe just for compatibility with other IP or test
benches.

Since SLV and unsigned/signed are closely related, they tend to be
very similar and you just need to use the appropriate conversion
routines defined in std_numeric. Otherwise no rewriting is required.

Rick

 

[rickman]

Not for compatibility with testbenches; they work fine with numeric_std.

See below...

Weakly yes for compatibility with IP; though IMO the best way to handle
most IP is a simple wrapper around it to do things like convert port
types. This helps preserve portability in case you want to switch
between brand X IP, somebody else's IP, and a behavioural description.

If you add a wrapper, then you are not using it in the top level...

Main reason is at the top level of a design; after synthesis (and P&R),
all your ports will have been replaced by SLV equivalents. So, if you
ever need post-synthesis simulation, you have to drop a netlist with SLV
ports into your testbench.

Testbench... haven't I heard that term somewhere before???

You could hide it in a wrapper function, but the tools usually make it
easy to switch between source and gate level netlist; this only works
with SLV ports, and I haven't found fighting the tools to do the job
properly to be worth it in these cases.

Yes, adding wrappers to provide compatibility with testbenches is not
desirable.

 

[rickman]

yes... but the issue isn't compatibility with the testbench; it's
compatibility with the post-synth, or post-P&R, version of the same
entity.

The entity only needs to be the same as the post-synth version because
they use the *same* test bench!

If you have no need of that (e.g. when the testbench is for a component,
as in unit testing, as opposed to the top level design) there is no
disadvantage to numeric_std (or indeed integer, or record type) ports.

We are only talking about the top level design, remember? Although I
guess some people might try to implement I/O from modules... if that
is even possible.

Rick