Why ever use std_logic_vector intead of signed/unsigned?

Discussion in 'VHDL' started by kevin.neilson@xilinx.com, Feb 21, 2013.

  1. Guest

    I'm getting back into VHDL after a long absence, and I can't find an answerto this question. When would I ever use std_logic_vector? If I were starting a new design, with current tools, I could used 'signed' and 'unsigned', even for the ports, and use numeric_std, and everything is cleaner. Is there any situation in which std_logic_vector might be required? There mustbe, or it wouldn't still exist.
     
    , Feb 21, 2013
    #1
    1. Advertising

  2. Rob Gaddi Guest

    On Wed, 20 Feb 2013 16:42:53 -0800 (PST)
    wrote:

    > I'm getting back into VHDL after a long absence, and I can't find an answer to this question. When would I ever use std_logic_vector? If I were starting a new design, with current tools, I could used 'signed' and 'unsigned', even for the ports, and use numeric_std, and everything is cleaner. Is there any situation in which std_logic_vector might be required? There must be, or it wouldn't still exist.


    There are ZILLIONS of tools you'll use along the way that won't let you
    use anything but std_logic/std_logic_vector. Not the least of which
    being Xilinx CoreGen.

    More to the point, there's a conceptual difference there. Signed and
    unsigned represent numbers, things that have the concepts of addition
    and comparison, etc, defined. std_logic_vector represents arbitrary
    collections of bits, such as collections of flags, bytes in and out of a
    UART, etc.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Feb 21, 2013
    #2
    1. Advertising

  3. On 21 Feb., 01:42, wrote:
    > I'm getting back into VHDL after a long absence, and I can't find an answer to this question.  When would I ever use std_logic_vector?  If I were starting a new design, with current tools, I could used 'signed' and 'unsigned', even for the ports, and use numeric_std, and everything is cleaner. Is there any situation in which std_logic_vector might be required?  There must be, or it wouldn't still exist.


    Required might be the wrong word. But if your not talking about
    numbers, it is for me more intiuitive to use stl-vector.
    Assume you have a bus of control-signals going to different modules or
    external components e.g Chip_Sel(3 downto 0), using that as unsigned
    works, but makes it less intuitive. If you split this into two signals
    CS_left and CS_right with both beeing 2 bit width your not lost, but
    do things that are not intuitive for me when dealing with unsigned/
    signed.

    A more important point is that I'm still member of the std_ulogic
    faction, as this helps finding some problems in design during compile,
    instead of waiting till netlist to detect that you have two driver
    where you intended to have only one. As ulogic-fan I see ofc way more
    reasons to use vector instead of unsingned/signed.

    best regards Thomas
     
    Thomas Stanka, Feb 21, 2013
    #3
  4. valtih1978 Guest

    > More to the point, there's a conceptual difference there. Signed and
    > unsigned represent numbers, things that have the concepts of addition
    > and comparison, etc, defined. std_logic_vector represents arbitrary
    > collections of bits, such as collections of flags, bytes in and out of a
    > UART, etc.


    You cannot go to shopping with the same car you travel to work. There is
    a conceptual difference.

    You cannot travel to work in a car, equipped with audio system. There
    are a huge number of concepts related with music, radio and audio.
    Simple car is intended for transporting people. You cannot transport
    people in a car equipped with audio system. It can be done only when you
    need people to listen music in the transport.
     
    valtih1978, Feb 21, 2013
    #4
  5. valtih1978 Guest

    When you travel in a car with audio off, your intent is not clear. Do
    you want to travel or just listen the music?
     
    valtih1978, Feb 21, 2013
    #5
  6. Rob Gaddi Guest

    On Thu, 21 Feb 2013 20:09:17 +0200
    valtih1978 <> wrote:

    > > More to the point, there's a conceptual difference there. Signed and
    > > unsigned represent numbers, things that have the concepts of addition
    > > and comparison, etc, defined. std_logic_vector represents arbitrary
    > > collections of bits, such as collections of flags, bytes in and out of a
    > > UART, etc.

    >
    > You cannot go to shopping with the same car you travel to work. There is
    > a conceptual difference.
    >
    > You cannot travel to work in a car, equipped with audio system. There
    > are a huge number of concepts related with music, radio and audio.
    > Simple car is intended for transporting people. You cannot transport
    > people in a car equipped with audio system. It can be done only when you
    > need people to listen music in the transport.
    >


    If you don't like strong typing, write Verilog. The lack of
    mathematical operations defined on std_logic_vector means that it is a
    compile-time error to try to perform math on anything not explicitly
    defined as being signed or unsigned.

    It's the same as using range restricted integer subtypes, it allows
    your code to be more explicit about what is and is not going to happen,
    and what things do or do not mean. That's not for the tools' benefit,
    it's for the programmer's.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Feb 21, 2013
    #6
  7. Guest

    This metaphor makes no sense. Of course I travel to work in the same car that I shop in.
     
    , Feb 21, 2013
    #7
  8. Andy Guest

    On Feb 21, 12:19 pm, Rob Gaddi <>
    wrote:
    > If you don't like strong typing, write Verilog.


    Whoa! No need to use a broken, "hold my beer and watch this" excuse
    for a language like verilog! ;)

    If your tools support a smidgen of VHDL-2008, you can use
    ieee.numeric_std_unsigned, which conveys all of the arithmetic
    abilities of numeric_std_unsigned onto std_logic_vector. It's like the
    old std_logic_unsigned package, only standard and better.

    Also under VHDL-2008, std_logic_vector is a (resolved) subtype of
    std_ulogic_vector, so they can be assigned to, or associated with,
    each other without conversion. This makes it much easier to use SUL/
    SUV to catch multiple driver issues at compile time, just without the
    previous conversion hassle.

    If your tool vendor doesn't support at least this much of VHDL-2008
    yet, call them and tell them their competition does.

    There are LOTS of other very nice enhancements to VHDL in 2008, some
    of which are not yet well supported by the tools. Call and complain,
    and threaten to switch tools!

    Andy
     
    Andy, Feb 21, 2013
    #8
  9. rickman Guest

    On 2/21/2013 1:19 PM, Rob Gaddi wrote:
    > On Thu, 21 Feb 2013 20:09:17 +0200
    > valtih1978<> wrote:
    >
    >>> More to the point, there's a conceptual difference there. Signed and
    >>> unsigned represent numbers, things that have the concepts of addition
    >>> and comparison, etc, defined. std_logic_vector represents arbitrary
    >>> collections of bits, such as collections of flags, bytes in and out of a
    >>> UART, etc.

    >>
    >> You cannot go to shopping with the same car you travel to work. There is
    >> a conceptual difference.
    >>
    >> You cannot travel to work in a car, equipped with audio system. There
    >> are a huge number of concepts related with music, radio and audio.
    >> Simple car is intended for transporting people. You cannot transport
    >> people in a car equipped with audio system. It can be done only when you
    >> need people to listen music in the transport.
    >>

    >
    > If you don't like strong typing, write Verilog. The lack of
    > mathematical operations defined on std_logic_vector means that it is a
    > compile-time error to try to perform math on anything not explicitly
    > defined as being signed or unsigned.
    >
    > It's the same as using range restricted integer subtypes, it allows
    > your code to be more explicit about what is and is not going to happen,
    > and what things do or do not mean. That's not for the tools' benefit,
    > it's for the programmer's.


    I think you are over-thinking the value and purpose of strong typing.
    There is nothing about signed/unsigned types that should preclude the
    their use in interfaces to memories, multipliers, or any other device
    whether it is made by coregen or other tools. It is not an issue of the
    user wanting to do math on non-math items. The user is asking why can't
    he use the *appropriate* type of signal in an interface.

    I think the restriction of tools to using slv is just inertia. It
    works, so don't break it by improving it. The laws of unintended
    consequences are a harsh teacher.

    --

    Rick
     
    rickman, Feb 22, 2013
    #9
  10. Guest

    This is the idea I'm getting. I haven't gotten a good answer about why I should ever use slv, and I'm getting the idea it's only still around because of inertia. The responses seem to be:
    1. SLV is better *because* of its limitations. You *could* use signed/unsigned, but why, when you could use something that does even less?
    2. But wait: with the new 2008 libraries, SLV is about as good as signed/unsigned. (So why not just use signed/unsigned?)
    3. Other cores like CoreGen cores will use SLV, so you have to also in order to interface them. (This is valid, although I try to avoid CoreGen when possible, and I can always convert, possibly even in the instantiation with 2008.)
     
    , Feb 22, 2013
    #10
  11. Rob Gaddi Guest

    On Fri, 22 Feb 2013 08:40:36 -0800 (PST)
    wrote:

    > This is the idea I'm getting. I haven't gotten a good answer about why I should ever use slv, and I'm getting the idea it's only still around because of inertia. The responses seem to be:
    > 1. SLV is better *because* of its limitations. You *could* use signed/unsigned, but why, when you could use something that does even less?


    Exactly. When you pick up your electric screwdriver/drill, there's a
    selectable torque ring. When you're using it as a drill, you set the
    torque up to max because that's what you want it to do, apply as much
    torque as possible to break through. When you're driving #4
    machine screws into threaded sockets, you bring the torque way down so
    as to not strip the screw.

    The right tool for the job is based on what the job is. Signed,
    unsigned, and std_logic_vector are different, complimentary tools.
    They represent a 2's compliment number, an unsigned number, and an
    arbitrary collection of bits, respectively.

    When I need to pack a lot of data into a single vector to pipe it
    around I build both a record and a corresponding SLV, and use a set of
    functions such as:

    function TO_SLV(rec : t_pvme_request) return t_pvme_request_slv;
    function TO_REQUEST (slv : t_pvme_request_slv) return t_pvme_request;

    This can happen either because a code generation tool such as Qsys can
    only work with SLV, not records, or if I'm storing mixed data types in
    a single RAM, or sending different data types across the same internal
    memory bus, etc. And in some of these cases the tools are what force
    me to use SLV. But also, these bundled up records, which in their
    native form collect signed, unsigned, and std_logic fields, are by their
    nature SLV. The idea of running a carry chain up the entire thing
    makes no sense, nor is the bit order particularly meaningful.

    That same memory bus also has a byte enable vector, which is again
    really a collection of individual signals that has no numeric meaning,
    and hence truly by its nature an SLV.

    Whereas that same memory bus has an address, which is inherently a
    number that can be compared, incremented, etc. That the tools force me
    to also make that into an SLV is just them being lazy.

    > 2. But wait: with the new 2008 libraries, SLV is about as good as signed/unsigned. (So why not just use signed/unsigned?)
    > 3. Other cores like CoreGen cores will use SLV, so you have to also in order to interface them. (This is valid, although I try to avoid CoreGen when possible, and I can always convert, possibly even in the instantiation with 2008.)


    It's 2013, and every vendor's dual-port RAM inference template is still
    based on unprotected shared variables, which have been declared illegal
    since VHDL-2002. Complete VHDL-2008 support in synthesis tools is like
    my 401(k); I hope that it might be ready by the time I retire.

    --
    Rob Gaddi, Highland Technology -- www.highlandtechnology.com
    Email address domain is currently out of order. See above to fix.
     
    Rob Gaddi, Feb 22, 2013
    #11
  12. KJ Guest

    On Wednesday, February 20, 2013 7:42:53 PM UTC-5, wrote:
    > I'm getting back into VHDL after a long absence, and I can't find an answer
    > to this question. When would I ever use std_logic_vector? If I were starting
    > a new design, with current tools, I could used 'signed' and 'unsigned', even
    > for the ports, and use numeric_std, and everything is cleaner. Is there any
    > situation in which std_logic_vector might be required? There must be, or
    > it wouldn't still exist.


    If you're writing code that you would like to reuse in other unrelated designs where there is not necessarily a native format for the data is a good case. As an example, let's say you want to write code for your own FIFO or even just memory. The data that you store can be any collection-o-bits. From your perspective (i.e. the FIFO or memory), you have no idea if the user of your FIFO/memory is using it to store some numeric thing or a slv version of a record type or even just a random collection of signals. Your jobis to store that data.

    Similarly, if you have record types that are defined in your design (for example a register that is intended to be read/written by an external processor) then you will at some point need to convert this record type into a flattened collection of bits to represent the data bus that connects the external processor to your design. The type you choose for this conduit is arbitrary so whichever type you choose simply shows your preferred type for such a general purpose conduit. Yes you could choose unsigned, but there is nothing preferring that over std_logic_vector. Choosing signed would be questionable, but only because you can't rule out the possibility that the data going over that data bus at some time is a signed value. This data bus itself is a specific example of a reusable thing that again has an interfacebut the data that moves over that interface has no specific numerical meaning so choosing something that does have a numerical interpretation over a simple collection of bits brings to question 'Why?' (i.e. My application needs to store fixed point signed things, why can I only store unsigned things in your fifo?)

    If you don't write code for reuse, there probably isn't much reason to use std_logic_vector...but then again, maybe you should question why you don't ever reuse your code. Not everything can be reusable, but many things can.

    Kevin Jennings
     
    KJ, Feb 23, 2013
    #12
    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. Jeremy Pyle
    Replies:
    3
    Views:
    52,746
    Mike Treseler
    Jun 28, 2003
  2. Replies:
    7
    Views:
    8,735
    David Dorward
    Feb 9, 2006
  3. dave
    Replies:
    9
    Views:
    2,744
    Kevin Goodsell
    Aug 16, 2003
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,990
    Smokey Grindel
    Dec 2, 2006
  5. bhabs
    Replies:
    2
    Views:
    384
    Tad J McClellan
    Feb 13, 2008
Loading...

Share This Page