numeric_std vs std_logic_arith/unsigned?

M

Mark Norton

Guest
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 <markn@cdvinc.com>
Concept Development, Inc.
http://www.cdvinc.com
 
Mark Norton wrote:

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.
Click to expand...
It is a real ieee standard that works well.

-- Mike Treseler

http://groups.google.com/groups/search?q=std_logic_unsigned+hideous+hack
 
Mark Norton wrote:
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.

The std_logic_* libraries were put out originally by (afair) Synopsys.
Click to expand...
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.
 
David R Brooks wrote:
Mark Norton wrote:

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.

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.
Click to expand...
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 <markn@cdvinc.com>
Concept Development, Inc.
http://www.cdvinc.com
 
Mark Norton wrote:

I read the group link Mike provided though I don't think I would have
known to search for "hideous hack" :)
Click to expand...
I didn't know that either.
It just turned out to be the shortest path to the thread :)

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.)

count <= STD_LOGIC_VECTOR(my_counter);
Click to expand...
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://home.comcast.net/~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;
 
Mike Treseler wrote:
Mark Norton wrote:

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


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

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.)


count <= STD_LOGIC_VECTOR(my_counter);


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.
Click to expand...
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.

PS: Sorry, I couldn't resist reformating
your counter without the signal:
Click to expand...
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.

______________________________________
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- Mike Treseler Tue May 16 10:44:50 2006
-- http://home.comcast.net/~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;
Click to expand...

--
==============================
Mark Norton <markn@cdvinc.com>
Concept Development, Inc.
http://www.cdvinc.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.



library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- Mike Treseler Tue May 16 10:44:50 2006
-- http://home.comcast.net/~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;
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Jim Lewis wrote:
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,
Click to expand...
Yes.

Synopsys and Magma.
Click to expand...
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


Mark Norton wrote:

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.


It is a real ieee standard that works well.

-- Mike Treseler

http://groups.google.com/groups/search?q=std_logic_unsigned+hideous+hack
Click to expand...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Jim Lewis wrote:
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.
Click to expand...
Not evil, hideous :)

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.
Click to expand...
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.

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

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).
Click to expand...
Thank you for all your work on standards.

-- Mike Treseler
 
Mike,
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.
Click to expand...
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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.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
still legal, coding styles than the expensive asic tools?
Click to expand...
Customers of 'cheap fpga tools' must be better about complaining or
sweet talking ;)

KJ
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top