numeric_std vias std_logic_unsigned

[Hubble]

Hi all,

although our project developed a standards paper at the project start
stating the usable VHDL packages which was delivered to all designers,
several (most) designers used

ieee.std_logic_unsigned.all

for their arithmetic instead of ieee.numeric_std.all which was defined
in the project standards. According to the VHDL Faq
(http://tech-www.informatik.uni-hamburg.de/vhdl/doc/faq/FAQ1.html), the
ieee.std_logic_unsigned is

a) non standard and differently implemented by various vendors (FAQ1,
Section 4.8.1)
b) leads to a "=" resolution conflict (FAQ1, section 4.2.20), which is
ignored by some tools.

Modelsim users have to use the -explicit compiler option to direct vcom
to use the explicit declaration in ieee.std_logic_unsigned.all.

There is a great opposition here against numeric_std, namely because
the need for type conversion when incrementing a std_logic_vector
use ieee.std_logic_unsigned.all;
...
std_logic_vector sv(7 downto 0);
...
s<=sv+1;

via
use ieee.numeric_std_all;
...
std_logic_vector sv(7 downto 0);
...
s<=std_logic_vector(unsigned(sv)+1);

which is considered unreadable. Although I am not completely against
changing to ieee.std_logic_unsigned, I would strongly recommend leaving
ieee.number_std.all.

Any suggestions.

Hubble.

 

[Ben Jones]

There is a great opposition here against numeric_std, namely because
the need for type conversion when incrementing a std_logic_vector

s<=std_logic_vector(unsigned(sv)+1);

which is considered unreadable.

Because it *is* unreadable, because that's not how it's supposed to be used.
If sv contains unsigned data then:

signal s, sv: unsigned(7 downto 0);
....
s <= sv + 1;

If you use the numeric_std signed and unsigned types properly, you will only
have to do type conversion when actually converting between types.

If you use the stupid std_logic_unsigned package, then what happens if you
want to do both signed and unsigned arithmetic in your module? You can't,
because including std_logic_unsigned.all and std_logic_signed.all will cause
a million clashes and s <= sv + 1 becomes ambiguous.

-Ben-

 

[Mike Treseler]

Hubble wrote:

although our project developed a standards paper at the project start
stating the usable VHDL packages which was delivered to all designers,
several (most) designers used

ieee.std_logic_unsigned.all

for their arithmetic instead of ieee.numeric_std.all

To fix up such code, global search and replace
all instances of std_logic_vector with unsigned then
run a sim compile to check find and fix any existing type
conversions.

-- Mike Treseler

 

[Jim Lewis]

Hubble,
First rule:
Don't change your things if they have been tested and work
unless it breaks something else.

Does anyone use std_logic_arith?
Mixing std_logic_arith with numeric_std can be problematic,
but is only problematic if you use types unsigned or signed
on your entity interfaces. If all your entity interfaces
use std_logic/std_logic_vector, life is good.

My package usage rules dissent from the opinion presented by
others here. My rule of thumb is very simple:

1) Use numeric_std for all math
Types signed and unsigned are documentation about the
operations being done on the object.

2) I sometimes use std_logic_unsigned for things that are
not math or commonly understood as unsigned:
Incrementers/Decrementers
Testbench algorithms applied to unsigned objects

3) Never use std_logic_signed
If you need signed, you are doing math, so use type signed
and the package numeric_std.


As you can tell, for some, the use of std_logic_unsigned is a
religous thing. You don't have to use it, however, I would
not change a working design to get rid of it.
For incrementers, you can simply use unsigned and life is good.
For testbenches, you can use unsigned for the testbench type
of the algorithm and do the conversion at the interface to the
design (in the port map).

A little irony, numeric_std and std_logic_unsigned work well
together, however, std_logic_arith and std_logic_unsigned
have some rare overloading issues with multiple operator expressions
(parentheses required to have an issue):

Y_slv <= (A_unsigned + B_unsigned) + (C_unsigned + D_unsigned) ;

a) non standard and differently implemented by various vendors (FAQ1,
Section 4.8.1)
All I see anymore is the version of these packages from Synopsys.

Anyone see anything different? Perhaps the FAQ needs updating.
Particularly for std_logic_unsigned.

b) leads to a "=" resolution conflict (FAQ1, section 4.2.20), which is
ignored by some tools.
This is a gray area in the LRM that is being corrected in the

next version so that explicit operators overload implicit operators.
This corresponds to most vendors implementation of this.
In addition, as of ModelSim rev 5.8 (old), the explicit flag is on
by default.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~