numeric_std vs std_logic_arith/unsigned?

Howdy,

I've seen a few bits of advice floating around in post to avoid the use
of std_logic_* libraries and instead use the numeric_std library for
mathematical functions but I've not seen a "why" yet.  Is there a
particular reason why this is preferred?  I admit my use of
ieee.std_logic_arith, ieee.std_logic_unsigned may be due to "this has
always worked and why change when I'm in a hurry".  If there's a good
reason though, I can certainly make sure future development takes place
using ieee.numeric_std.

Best regards,
Mark Norton
-- 
==============================
Mark Norton < XXXX@XXXXX.COM >
Concept Development, Inc.
 http://www.**--****.com/ 

It is a real ieee standard that works well.

         -- Mike Treseler

 http://www.**--****.com/ +hideous+hack

The std_logic_* libraries were put out originally by (afair) Synopsys. 
They were not official IEEE standards (despite the library location).
Consequently, different vendors cooked up their own versions, & subtle 
differences got in.
numeric_std is a formal IEEE standard, guaranteed compatible - if you 
implement it at all, you must implement it the same way.

I read the group link Mike provided though I don't think I would have
known to search for "hideous hack" :-)

Anyhow, so I'm guessing for a counter whose count is exposed at the
entity level the preferred method would be something like this?  (mainly
note the conversion function when sending the count to the port.)

library IEEE;
use IEEE.std_logic_1164.all
use IEEE.numeric_std.all

entity
port (
	...
	count : out std_logic_vector(31 downto 0);
        ...
);

architecture

signal my_counter : unsigned(31 downto 0);

begin

process (clk)
begin
	if (clk'event and clk='1') then
		my_counter <= my_counter + 1;
	end if
end process;

count <= STD_LOGIC_VECTOR(my_counter);

end;

-- 
==============================
Mark Norton < XXXX@XXXXX.COM >
Concept Development, Inc.
 http://www.**--****.com/ 

I didn't know that either.
It just turned out to be the shortest path to the thread :)



Yes that's the basic idea. If this
were the top entity and I wanted to
be compatible with the .vho netlist file,
without a wrapper.

If you fix up a few semicolons and
add an entity name, it would even work.

But keep in mind that this conversion is
*only* needed for the *top* port assignments
if it is needed at all. As I am sure you know,
a counter is much better off described
as a one-liner in a process than it is
as an instanced component.


        -- Mike Treseler


PS: Sorry, I couldn't resist reformating
your counter without the signal:
______________________________________
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- Mike Treseler Tue May 16 10:44:50 2006
--  http://www.**--****.com/ ~mike_treseler/counter_std.pdf
entity counter_std is
    generic (len : natural := 32);
    port (
       clk   : in  std_ulogic;
       rst   : in  std_ulogic;
       count : out std_logic_vector(len-1 downto 0)
       );
end entity counter_std;
architecture synth of counter_std is
begin
    process (rst, clk) is
       variable counter_std_v : unsigned(count'range);
    begin
       if rst = '1' then
          counter_std_v := (count'range => '0');
       elsif rising_edge(clk) then
          counter_std_v := counter_std_v + 1;
       end if;
          count <= std_logic_vector(counter_std_v);
    end process;
end;

Well sure.  At any given moment, I might have two or three counters
running around, none of which would be exposed at the entity level port
list, unless it was part of the interface spec.  Rarely if ever does it
have its own process even.


No it's quite alright.  I know my coding style is pretty old-school to a
great degree, so I'm interesting in seeing more modern styles.  Main
points of departure I see are the usage of the variable versus the
signal, using rising_edge(clk), and using the generic.

These bring up another point, where does "rising_edge" come from?  It
looks like a function call, so I'm guessing it's in the IEEE packages
somewhere.  As the pseudo-code I wrote out showed, I usually use the old
standby "clk'event and clk='1'" for rising edge.

I typically don't use attributes all that much either, but with portable
functions and such I can see how I might get to like it.



-- 
==============================
Mark Norton < XXXX@XXXXX.COM >
Concept Development, Inc.
 http://www.**--****.com/ 

This is one of those coding styles that historically
did not compile on some tools.  Anyone know if it
compiles on:
    Xilinx, Quartus, Synplicity, Mentor,
    Synopsys, and Magma.

One of the lessons learned is that just because something
compiles on an FPGA synthesis tool does not mean that it
will compile on an ASIC synthesis tool.

 From a standards standpoint, this coding style is
supported by 1076.6-2004, but not by 1076.6-1999.

Cheers,
Jim

P.S.
In Accellera 1076-2006 outputs will be able to be read
(just like ADA-95 :)) and, hence, you will not need
the extra variable at all.





-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto: XXXX@XXXXX.COM 
SynthWorks Design Inc.            http://www.**--****.com/ 
1-503-590-4787

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

Yes.


If anyone has one of these,
please run my reference design
on it and tell me how it does.

Thanks.

         -- Mike Treseler

Having worked with customers where some use
std_logic_unsigned and some don't, I have never
had the luxury of considering it an evil hack.

As a result, when I see:
   library ieee;
   use ieee.std_logic_1164.all;
   use ieee.numeric_std.all;

I see std_logic_vector as a bit type that
contains 1's and 0's and no math.

On the other hand, when I see:
   library ieee;
   use ieee.std_logic_1164.all;
   use ieee.numeric_std.all;
   use ieee.std_logic_unsigned.all;

I see std_logic_vector as a bit type that
contains 1's and 0's and has unsigned math.


WRT std_logic_arith, I agree don't use it.
It has ambiguity issues and there is a better
standardized version.

Looking forward, other nice things will be
happening for numeric_std and locally static
expressions in the next revision of VHDL (to be
standardized by Accellera in July 2006 at DAC
and IEEE at a later date).

Cheers,
Jim






-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto: XXXX@XXXXX.COM 
SynthWorks Design Inc.            http://www.**--****.com/ 
1-503-590-4787

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

Not evil, hideous  :)


I agree that lots of designers use std_logic_unsigned
including some very influential ones at Xilinx.
This is a matter of style.
However, I would do a disservice to
to recommend this method to a new user
because it falls apart when signed math is added.


I agree.


Thank you for all your work on standards.

          -- Mike Treseler

Mike,

All the methodologies I have seen do signed math
using numeric_std.signed and prohibit the use of
std_logic_signed.  Supporting an overloading
of std_logic_vector that implemented anything other
than unsigned would be hideous.

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

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

Synopsys still bugs out on entity instantiations (as opposed to
component instantiations) inside generate statements... How long has
that been a part of vhdl, 13 years?

The last time I checked (~4 years back), they also did not support /
and mod by powers of 2 for numeric_std types either.

Why are the cheap fpga tools so much better at handling different, but
still legal, coding styles than the expensive asic tools?  

Andy

> Why are the cheap fpga tools so much better at handling different, but

Customers of 'cheap fpga tools' must be better about complaining or
sweet talking ;)

KJ