Why the library "numeric_std" is preferred over "std_logic_arith" and others?

This article is based on an email conversion I had with one VHDL expert.If you browse through some forums about VHDL then you may see some suggestions such as , use "numeric_std" library instead of "std_logic_arith" and "std_logic_unsigned".I had this doubt before and here is what he(unfortunately i don't know his name) told me:

    std_logic_arith, etc. were packages written by Synopsis and included in their tools' version of the ieee library, without the approval of the ieee standardization body. The LRM (Language reference manual) reserves the ieee library for officially balloted and approved packages for the vhdl language.However, since the whole world started using synopsys first, and everyone had started writing code dependent upon std_logic_arith being in ieee, Synopsys refused to take it out of their implementation. And since other tools were usually forced to work seamlessly with code that worked with Synopsys, they followed suit. However, different vendors implemented the package slightly differently, with some problems in compatibility. Since there is no standard governing it, it is subject to change at any time. 

     So, the IEEE decided to write and approve a standard package for numerical operations on SL(std_logic) and BIT based vectors. Those packages are called numeric_std and numeric_bit. These are ieee standard packages, located in the official version of the ieee library, and their behavior is governed by the standard, so compatibility is assured.

  

    Numeric_std does not attempt to imply a numerical interpretation on SLV(std_logic_vector) , but rather defines related types UNSIGNED and SIGNED which have both numerical and bitwise interpretations (i.e.AND and OR are also defined for them). This avoids any confusion when needing to use both signed and unsigned arithmetic in the same body (std_logic_arith simply assumes all arithmetic is unsigned). Numeric_std defines arithmetic operations between various combinations of signed, unsigned and integer operands. In all cases(?) the size of the result is the same as the largest signed/unsigned operand. Over/underflows are truncated (rolled over). 

     The latest version of the vhdl standard does include a package similar in function to std_logic_arith, etc., named numeric_std_unsigned, which does define unsigned arithmetic on std_logic_vector operands. Unfortunately, I know of no tools that support it yet.

     Generally, if you can, create your entity interfaces using unsigned or signed (or even integer) if they are uniformly numerically interpreted. (i.e. a generic memory device may be able to store any kind of binary data, so SLV may make more sense there, but a digital filter has a specific definition of its input data in mind, and that can be coded by using the appropriate type on the port). Using the appropriate types on the ports makes it much easier to avoid conversions within the body.

For example, if you used an SLV input port, and you need to add one to it and output that on an SLV output port, you must convert it twice: 

output <= std_logic_vector(unsigned(input) + 1); 

This converts the SLV input to unsigned (so that + is defined for it), adds (integer) one to it (the result is unsigned too), then converts the result back to SLV for the output port.It would have been much easier if input and output had been declared unsigned (or signed) in the first place:  

output <= input + 1;

    At the same time you shouldn't get the idea that "don't use SLV at all".Some places SLV is better than UNSIGNED or SIGNED data type.For example, an ALU (Arithmetic and Logic Unit) that accepts signed or unsigned data (depending on the operation control) may always have a numeric interpretation of the data on its ports, but since we do not have a generic numeric signed and unsigned representation, SLV would still be appropriate for those ports.Other examples,where SLV is  a better option are any collection of bits that does not have a numeric meaning such as a vector of enable bits, etc...

 

Note :- In the earlier codes I have heavily dependent on SLV.But in the recent posts I have started using SIGNED and UNSIGNED data types more frequently.