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

 

[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]

Clemens wrote:

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,


Nicolas Matringe schrieb:

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.

Why shouldn't the std_logic_arih anymore?

bye

martin

 

[Mike Treseler]

Martin Sauer wrote:

Why shouldn't the std_logic_arih anymore?

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

 

[rickman]

On Jul 8, 3:31 pm, Clemens <Clem...@hotmail.com> wrote:

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?

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

 

[Brian Drummond]

On Fri, 11 Jul 2008 21:50:01 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

On Jul 8, 3:31 pm, Clemens <Clem...@hotmail.com> wrote:
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?

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.

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

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.

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.

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.

- Brian

 

[rickman]

On Jul 12, 7:36 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

On Fri, 11 Jul 2008 21:50:01 -0700 (PDT), rickman <gnu...@gmail.com
wrote:

On Jul 8, 3:31 pm, Clemens <Clem...@hotmail.com> wrote:
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?

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.

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.

 

[Brian Drummond]

On Sun, 13 Jul 2008 06:04:34 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

On Jul 12, 7:36 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:
On Fri, 11 Jul 2008 21:50:01 -0700 (PDT), rickman <gnu...@gmail.com

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.

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

See below...
....

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???

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.

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.

Sorry my message wasn't clear.

- Brian

 

[rickman]

On Jul 13, 9:10 pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:

On Sun, 13 Jul 2008 06:04:34 -0700 (PDT), rickman <gnu...@gmail.com
wrote:

On Jul 12, 7:36 am, Brian Drummond <brian_drumm...@btconnect.com
wrote:
On Fri, 11 Jul 2008 21:50:01 -0700 (PDT), rickman <gnu...@gmail.com
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.

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

See below...

...

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???

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