When should I use std_logic_vector and when should I use other data types?

Question

I'm new to VHDL and am having trouble figuring out which data types are appropriate to use where. If I understand correctly, for synthesis, all top level entity ports should be declared either std_logic_vector or std_logic and never any other type.

But std_logic_vector doesn't support arithmetics so how should I handle this?

My intuition tells me that I should simply use std_logic_vector at the top level and then convert this to and from integral data types when passing it to other entities. Is this correct?

And what integral data type (integer, unsigned, signed) should be used where? I understand the difference between signed and unsigned but when should I use integer?

Thermel

Answer 1

Use the data types that are most appropriate for your modeling purposes, including for ports. It is simply not true that synthesis requires that you should only use std_logic or std_logic_vector for ports. Don't believe those that tell you otherwise.

If you need bit vectors with arithmetic support, consider signed/unsigned from ieee.numeric_std. (In VHDL 2008, there is a standard package that adds arithmetic support to std_logic_vector, but I consider that evil.)

There may only be an issue at the very top-level after synthesis, when you want to simulate the synthesized net list. The port types of that net list may not match your top-level RTL interface. However, you can easily fix that when instantiating the gate level, by doing the proper conversions at that moment. That is the proper time for such low-level concerns - they should not influence your RTL modeling style.

Lama

So there is nothing wrong with just using integer either then? – Thermel

@Emil. That's right (constrained integer subtypes of course). However, integers have a (disturbing) 32-bit limit in practice, which means you may prefer unsigned/signed e.g. if you are concerned about parametrizability or consistency. – Lama

Nitpick (I know Jan knows this, but I'll point it out for completeness): integers are guaranteed by the standard to be "not quite 32-bits" - they go from -((231)-1) to +((231)-1). Many vendors do provide the full int32_t range, but it's not guaranteed :( – Anglice

Do you consider the VHDL 2008 standard package to be ...evil?! If so, why? – Pamilapammi

@Pamilapammi Jan is referring specifically to the numeric_std_unsigned package in VHDL-2008. This is widely considered to be evil for the same reasons that the old, non-standard std_logic_arith/signed/unsigned packages were considered to be evil. However, this topic has been hotly debated for decades and apparently enough people with enough influence managed to force it into VHDL-2008. – Unmake

Answer 2

I suggest to not use std_logic and std_logic_vector unless you try to model tristate signals - which I consider as kind of evil. Instead using std_ulogic and std_ulogic_vector that are not resolved. This has the advantage to detect multiple assignments to unresolved signals during compile. With resolved signals you would detect that mistake late in simulation or synthesis.

Drawback: This suggestion is not very common and using 3rd-party logic with std_logic might require some typecasts.

For arithmetic of std_ulogic_vector use std_numeric. It is then required to cast to either signed or unsigned before the operation and cast the result back to std_ulogic_vector. There is NO such thing as a standard ieee.std_ulogic_unsigned library for unresolved signals.

adder_result <= std_ulogic_vector( unsigned(operant1) + unsigned(operant2) ) ;
increment <= std_ulogic_vector( unsigned(operant) + 1 ) ;

The difference between integer,natural,positive on one side and the unsigned and signed on the other is the representation. Signed and unsigned are subtype of std_logic_vector and more like a bundle (or more precise array) of std_logic wires.

The integer types are rather a mathematical representation of a number. They are usually used more with generics, generate loops and array index. But sometimes synthesis can handle them for arithmetic units too.

Commune

Answer 3

In general the comment about using the appropriate type for modeling is correct (Jan Decaluwe). However there is one big gotcha with it. If you are doing mixed language development (combining VHDL, Verilog/System Verilog) you need to be careful at language boundaries. Some tools have significant restrictions on the types of signals used when crossing the language barriers.

I am currently looking at Vivado 2019 synthesis user guide (UG901) and it lists what types you can use at the crossing point. You need to look at your toolchain.

Ignominy

Vivado also has very poor type support in its IP packager. A reasonable workaround is to add a wrapper that just does the necessary type conversions to keep the tool happy. This way, you don't have to wreck all your code for the sake of Vivado - just one ugly (but self-contained) wrapper. – Unmake