numeric_std vs std_logic_arith/unsigned?

Discussion in 'VHDL' started by Mark Norton, May 15, 2006.

  1. Mark Norton

    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 <>
    Concept Development, Inc.
    http://www.cdvinc.com
     
    Mark Norton, May 15, 2006
    #1
    1. Advertising

  2. Mike Treseler, May 15, 2006
    #2
    1. Advertising

  3. 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.
     
    David R Brooks, May 16, 2006
    #3
  4. Mark Norton

    Mark Norton Guest

    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.


    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 <>
    Concept Development, Inc.
    http://www.cdvinc.com
     
    Mark Norton, May 16, 2006
    #4
  5. 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.


    -- 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, May 16, 2006
    #5
  6. Mark Norton

    Mark Norton Guest

    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.


    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:


    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;



    --
    ==============================
    Mark Norton <>
    Concept Development, Inc.
    http://www.cdvinc.com
     
    Mark Norton, May 16, 2006
    #6
  7. Mark Norton

    Jim Lewis Guest

    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;



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

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, May 16, 2006
    #7
  8. 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,


    Yes.

    > Synopsys and Magma.


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

    Thanks.

    -- Mike Treseler
     
    Mike Treseler, May 16, 2006
    #8
  9. Mark Norton

    Jim Lewis Guest

    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



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

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, May 17, 2006
    #9
  10. 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.


    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.


    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.


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


    Thank you for all your work on standards.

    -- Mike Treseler
     
    Mike Treseler, May 17, 2006
    #10
  11. Mark Norton

    Jim Lewis Guest

    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.


    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:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, May 17, 2006
    #11
  12. Mark Norton

    Andy Guest

    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
     
    Andy, May 17, 2006
    #12
  13. Mark Norton

    KJ Guest

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


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

    KJ
     
    KJ, May 17, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ALuPin

    std_logic_arith / numeric_std

    ALuPin, Apr 6, 2004, in forum: VHDL
    Replies:
    5
    Views:
    11,260
    Tim Hubberstey
    Apr 8, 2004
  2. Toby
    Replies:
    4
    Views:
    1,846
    Mike Treseler
    Sep 7, 2005
  3. Tricky
    Replies:
    0
    Views:
    613
    Tricky
    Oct 17, 2008
  4. pozz
    Replies:
    12
    Views:
    795
    Tim Rentsch
    Mar 20, 2011
  5. rman123

    Numeric_std unsigned issues?

    rman123, Mar 28, 2011, in forum: VHDL
    Replies:
    2
    Views:
    1,447
    rman123
    Mar 30, 2011
Loading...

Share This Page