Why ever use std_logic_vector intead of signed/unsigned?

[kevin.neilson]

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.

 

[Rob Gaddi]

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

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.

 

[Thomas Stanka]

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

 

[valtih1978]

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]

When you travel in a car with audio off, your intent is not clear. Do
you want to travel or just listen the music?

 

[Rob Gaddi]

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.

 

[kevin.neilson]

This metaphor makes no sense. Of course I travel to work in the same car that I shop in.

 

[Andy]

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

 

[rickman]

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.

 

[kevin.neilson]

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

 

[Rob Gaddi]

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

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.

 

[KJ]

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