Why ever use std_logic_vector intead of signed/unsigned?

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.

 

[Rob Gaddi]

On Wed, 20 Feb 2013 16:42:53 -0800 (PST)
kevin.neilson@xilinx.com 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.

 

[Thomas Stanka]

On 21 Feb., 01:42, kevin.neil...@xilinx.com 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

 

[Brian Drummond]

On Wed, 20 Feb 2013 16:42:53 -0800, kevin.neilson 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.

For numeric data, I fully agree. I'm at the point where I'd use it for a
top level address bus port, and if I ever needed gate level sim I'd
provide a wrapper to the SLV ports on the gate level model.

For (probably or possibly) non-numeric data, I disagree. For a databus or
an instruction, which would usually be a bag-o-bits, I'd use
std_logic_vector. The fact that it stands out as an oddity in a sea of
unsigned or synthesisable integer code makes the design intent clear.

- Brian

 

[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]

On Thu, 21 Feb 2013 20:09:17 +0200
valtih1978 <do@not.email.me> 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.

 

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

 

[Andy]

On Feb 21, 12:19 pm, Rob Gaddi <rga...@technologyhighland.invalid>
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

 

[rickman]

On 2/21/2013 1:19 PM, Rob Gaddi wrote:

On Thu, 21 Feb 2013 20:09:17 +0200
valtih1978<do@not.email.me> 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

 

[Rob Gaddi]

On Fri, 22 Feb 2013 08:40:36 -0800 (PST)
kevin.neilson@xilinx.com 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.

 

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

 

[KJ]

On Wednesday, February 20, 2013 7:42:53 PM UTC-5, kevin....@xilinx.com 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 job is 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 interface but 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

 

This is one of the most nonsensical things I've ever heard.

 

[glen herrmannsfeldt]

kevin.m.neilson@gmail.com wrote:

> This is one of the most nonsensical things I've ever heard.

Is this supposed to be a question?

OK, my news reader cuts of the subject line. If you put something
in the subject line related to the question, also put it in the message.

For most uses, you want a specific width.

A better question is why std_logic instead of bit.

(And why does std_logic have to be so long, and have a _ in it.)

-- glen

 

[KJ]

On Tuesday, August 18, 2015 at 3:06:02 PM UTC-4, glen herrmannsfeldt wrote:

kev....neilson@gmail.... wrote:

This is one of the most nonsensical things I've ever heard.

Is this supposed to be a question?

OK, my news reader cuts of the subject line. If you put something
in the subject line related to the question, also put it in the message.

It was a question (asked and answered) back in Feb 2013 when the thread was first started...no idea what today's post is supposed to be about.

KJ

 

[glen herrmannsfeldt]

KJ <kkjennings@sbcglobal.net> wrote:

(snip, I wrote)

OK, my news reader cuts of the subject line. If you put something
in the subject line related to the question, also put it in the message.

It was a question (asked and answered) back in Feb 2013 when the
thread was first started...no idea what today's post is supposed
to be about.

As I mostly write for synthesis, and not simulation, I have wondered
why use std_logic instead of bit. My newsreader cut of the subject
until I did the reply, when I saw the whole subject.

It does sometimes bother me that VHDL makes the conversion between
bit_vector and unsigned so complicated. (Compared to verilog.)

-- glen

 

[rickman]

On 8/18/2015 4:21 PM, glen herrmannsfeldt wrote:

KJ <kkjennings@sbcglobal.net> wrote:

(snip, I wrote)
OK, my news reader cuts of the subject line. If you put something
in the subject line related to the question, also put it in the message.

It was a question (asked and answered) back in Feb 2013 when the
thread was first started...no idea what today's post is supposed
to be about.

As I mostly write for synthesis, and not simulation, I have wondered
why use std_logic instead of bit. My newsreader cut of the subject
until I did the reply, when I saw the whole subject.

It does sometimes bother me that VHDL makes the conversion between
bit_vector and unsigned so complicated. (Compared to verilog.)

VHDL lets you make it a simple function call. You just need to create
the function.

--

Rick

 

[Andy]

On Tuesday, August 18, 2015 at 3:21:56 PM UTC-5, glen herrmannsfeldt wrote:

It does sometimes bother me that VHDL makes the conversion between
bit_vector and unsigned so complicated. (Compared to verilog.)

-- glen

Use numeric_bit or numeric_bit_unsigned packages from the IEEE library.

The latter defines arithmetic operators and conversions to/from integer for bit_vector.

The former defines signed/unsigned types as unconstrained arrays of bit, closely related (and easily converted) to bit_vector, along with to/from integer conversion and arithmetic operators.

All standard IEEE HVDL since 2008.

Andy

 

[rickman]

On 2/22/2013 11:40 AM, kevin.neilson@xilinx.com 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?
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.)

I don't really understand your questions. Why do you care what others
think of the various types? I can assure you that there is no "intent"
to the types other than what they *can* be used for. I have discussed
similar issues with some of the people who worked on the VHDL standard
and they aren't thinking of all the details of how you will want to use
the language. Their intent was to give a framework within which you can
do *lots* of things with minimal limitations but lots of protection.

--

Rick