Creativo

The signed and unsigned types in VHDL are bit vectors, just like the std_logic_vector type. The difference is that while the std_logic_vector is great for implementing data buses, it’s useless for performing arithmetic operations.

If you try to add any number to a std_logic_vector type, ModelSim will produce the compilation error: No feasible entries for infix operator +”. This is because the compiler doesn’t know how to interpret this collection of bits that the vector is.

This blog post is part of the Basic VHDL Tutorials series.

We must declare our vector as signed or unsigned for the compiler to treat it as a number.

The the syntax for declaring signed and unsigned signals is:
signal <name> : signed(<N-bits> downto 0) := <initial_value>;
signal <name> : unsigned(<N-bits> downto 0) := <initial_value>;

Just like with std_logic_vector, the ranges can be to or downto any range. But declaring signals with other ranges than downto 0 is so uncommon, that spending any more time on the subject would only serve to confuse us. The initial value is optional, by default it’s 'U' for all bits.

We have already been using the integer type for arithmetic operations in previous tutorials. So why do we need the signed and unsigned types? For most, digital designers like to have more control of how many bits a signal actually uses.

Also, signed and unsigned values wrap around, while the simulator will throw a run-time error if an integer is incremented beyond bounds. Finally, signed and unsigned can have other values like 'U' and 'X', while integers can only have number values. These meta-values can help us discovering errors in our design.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity T12_SignedUnsignedTb is
end entity;

architecture sim of T12_SignedUnsignedTb is

signal UnsCnt : unsigned(7 downto 0) := (others => '0');
signal SigCnt : signed(7 downto 0) := (others => '0');

signal Uns4 : unsigned(3 downto 0) := "1000";
signal Sig4 : signed(3 downto 0) := "1000";

signal Uns8 : unsigned(7 downto 0) := (others => '0');
signal Sig8 : signed(7 downto 0) := (others => '0');

begin

process is
begin

wait for 10 ns;

-- Wrapping counter
UnsCnt <= UnsCnt + 1;
SigCnt <= SigCnt + 1;

-- Adding signals
Uns8 <= Uns8 + Uns4;
Sig8 <= Sig8 + Sig4;

end process;
end architecture;

The radix of all signals in the waveform are set to hexadecimal so that we can compare them equally.

In the wrapping counter example, we see that the signed and unsigned signals behave exactly the same way. Both UnsCnt and SigCnt start at 0, and are incremented one-by-one up to FF. Hex FF (decimal 255) is the largest value our 8-bit signals can hold. Therefore, the next increment wraps both of them back to 0.

We created the two 4-bit signals Uns4 and Sig4, and gave them both an initial value of 1000”. We can see from the waveform that they are both just hex 8 (binary 1000).

The last two 8-bit signals we created were Uns8 and Sig8. We can see from the waveform that their initial values are 0, as one would expect. But from there, they behave differently! Apparently, signed and unsigned types made a difference when adding two signals of different lengths.

This is because of something known as sign extension. Adding positive or negative numbers stored in vectors of equal length, is the same operation in digital logic. This is because of how two’s complement works. If the vectors are of different lengths, the shortest vector will have to be extended.

The unsigned 4-bit binary number 1000” is decimal 8, while the signed 4-bit number 1000” is decimal -8. The 1” at the left-most place of the signed number indicates that this is a negative number. Therefore, the two 4-bit signals are sign extended differently by the compiler.

This is a visualization of how sign extension creates the differing values for the Uns8 and Sig8 signals:

• Signals of signed and unsigned type are vectors that can be used in arithmetic operations
• Signals of signed and unsigned type will overflow silently
• Sign extension may create differing results for signed and unsigned types

The std_logic_vector type can be used for creating signal buses in VHDL. The std_logic is the most commonly used type in VHDL, and the std_logic_vector is the array version of it.

While the std_logic is great for modeling the value that can be carried by a single wire, it’s not very practical for implementing collections of wires going to or from components. The std_logic_vector is a composite type, which means that it’s a collection of subelements. Signals or variables of the std_logic_vector type can contain an arbitrary number of std_logic elements.

This blog post is part of the Basic VHDL Tutorials series.

The syntax for declaring std_logic_vector signals is:
signal <name> : std_logic_vector(<lsb> to <msb>) := <initial_value>;
or
signal <name> : std_logic_vector(<msb> downto <lsb>) := <initial_value>;
where <name> is an arbitrary name for the signal and <initial_value> is an optional initial value. The <lsb> is the index of the least significant bit, and <msb> is the index of the most significant bit.

The to or downto specifies the direction of the range of the bus, basically its endianess. Although both work equally well, it’s most common for VHDL designer to declare vectors using downto. Therefore, I recommend that you always use downto when you declaring bit vectors to avoid confusion.

The VHDL code for declaring a vector signal that can hold a byte:
signal MySlv : std_logic_vector(7 downto 0);

The VHDL code for declaring a vector signal that can hold one bit:
signal MySlv : std_logic_vector(0 downto 0);

The VHDL code for declaring a vector signal that can hold zero bits (an empty range):
signal MySlv : std_logic_vector(-1 downto 0);

library ieee;
use ieee.std_logic_1164.all;

entity T11_StdLogicVectorTb is
end entity;

architecture sim of T11_StdLogicVectorTb is

signal Slv1 : std_logic_vector(7 downto 0);
signal Slv2 : std_logic_vector(7 downto 0) := (others => '0');
signal Slv3 : std_logic_vector(7 downto 0) := (others => '1');
signal Slv4 : std_logic_vector(7 downto 0) := x"AA";
signal Slv5 : std_logic_vector(0 to 7) := "10101010";
signal Slv6 : std_logic_vector(7 downto 0) := "00000001";

begin

-- Shift register
process is
begin

wait for 10 ns;

for i in Slv6'left downto Slv6'right + 1 loop
Slv6(i) <= Slv6(i-1);
end loop;

Slv6(Slv6'right) <= Slv6(Slv6'left);

end process;

end architecture;

In this exercise we declared six std_logic_vector buses, each eight bits long (one byte).

Signal Slv1 was declared without a initial value. The bus is seen having the value XX in the waveform screenshot. This is because the value that is displayed on the bus is in hexadecimals, and XX indicates a non-hex value. But when we expanded the bus in the waveform, we could see that the individual bits were indeed U’s.

Signal Slv2 was declared using an initial value of all 0’s. Instead of specifying the exact value for each bit, we used (other => '0') in place of the initial value. This is known as an aggregate assignment. The important part is that it will set all bits in the vector to whatever you specify, no matter how long it is.

Signal Slv3 was declared using an aggregate assignment to give all bits the initial value of 1. We can see FF displayed on this signal in the waveform, which is hex for eight 1’s.

Signal Slv4 was declared with an initial value specified in hex, AA. Each hex digit is 4 bits long, therefore we must supply two digits (AA) for our vector which is 8 bits long.

Signal Slv5 declares exactly the same initial value as Slv4, but now we specified it as the binary value 10101010. We can see from the waveform that both signals have the hex value AA.

Signal Slv6 was declared with an initial value of all zeros, except for the rightmost bit which was '1'. We used a process to create a shift register from this signal. The shift register, as the name implies, shifts the contents of the vector one place to the left every 10 nanoseconds.

Our process wakes up every 10 ns, and the For-Loop shifts all bits in the vector one place to the left. The final bit is shifted back into the first index by the Slv6(Slv6'right) <= Slv6(Slv6'left); statement. In the waveform we can see the '1' ripple through the vector.

This is a visualization of how the '1' propagates through our shift register:

By using the 'left' and 'right attributes, we made our code more generic. If we change the width of Sig6, the process will still work. It’s good design practice to use attributes where you can instead of hardcoding values.

You may be wondering if there are more attributes that you can use, and there are. I won’t be talking more about them in this tutorial series, because I consider them to be advanced VHDL features.

N-bit vectors should be declared using std_logic_vector(N-1 downto 0)
A vector can be assigned as a whole or bits within it can be accessed individually
All bits in a vector can be zeroed by using the aggregate assignment (others => '0')
Code can be made more generic by using attributes like 'left and 'right

از attribute برای تغییر پارامتر ها در کد استفاده میشود.

ارزش بیت ها در کد متفاوت است MSB و LSB

چطوری از STD_logic  استفاده کنیم.

The most common type used in VHDL is the std_logic. Think of this type as a single bit, the digital information carried by a single physical wire. The std_logic gives us a more fine-grained control over the resources in our design than the integer type, which we have been using in the previous tutorials.

Normally, we want a wire in a digital interface to have either the value '1' or '0'. These two values are the only values that a bit, a binary digit, can have. But in reality, a physical digital signal can be in a number of states, which the std_logic type does a good job emulating. Therefore it is the most frequently used type in VHDL.

The std_logic type can have the following values:

This may seem like a lot of different states for a type that is supposed to model a single binary value. Don’t worry, we won’t be using all these types in this tutorial series. We will be using '1' and '0' of course. And we will also be seeing 'U' and 'X', which will help us spot errors in our design. The other values are advanced VHDL features which can be used for things like modeling communication with for example I2C devices, or for creating tri-state buses.

If several processes are trying to write different values to a signal, we say that it has multiple drivers. If a std_logic signal has multiple drivers, it won’t be a compilation or run-time error, at least not in the simulator. That is because std_logic is a resolved type, meaning that its value will be determined by a resolution function.

The value of a std_logic signal with two drivers will be determined based on this resolution table:

The waveform window in ModelSim after we pressed run, and zoomed in on the timeline:

The waveform with the cursor placed on the other part of the repeating signal cycleThe waveform with the cursor placed on the other part of the repeating signal cycle:

The exercise demonstrated how the resolution function of VHDL works with the std_logic type. When working with digital logic it’s often more practical to study the timeline in a waveform rather than using printouts. Therefore we used the ModelSim waveform to check the signal values in this exercise.

The first process and Signal1 is only used for changing the value that the third process is driving on Signal2 and Signal3.

The second process, Driver A, will try to drive a 'Z' onto Signal2, and a '0' onto Signal3 constantly.

The third process, Driver B, will alternate between driving '1' and 'Z' onto both Signal2 and Signal3.

We see in the waveform screenshots that Signal1 is changing between '0' and '1', because there is only one process trying to drive this signal. We can also see that the multiple driver signals are resolved according to the resolution table posted in the VHDL code comments:

• std_logic is the most common type used to hold a single bit value in VHDL
• Think of a std_logic signal as a physical wire in our digital design
• If multiple processes try to drive a std_logic signal, its value is determined by a resolution table

library ieee;
use ieee.std_logic_1164.all;

entity T10_StdLogicTb is
end entity;

architecture sim of T10_StdLogicTb is

signal Signal1 : std_logic := '0';
signal Signal2 : std_logic;
signal Signal3 : std_logic;

begin

process is
begin

wait for 10 ns;
Signal1 <= not Signal1;

end process;

-- Driver A
process is
begin

Signal2 <= 'Z';
Signal3 <= '0';
wait;

end process;

-- Driver B
process(Signal1) is
begin

if Signal1 = '0' then
Signal2 <= 'Z';
Signal3 <= 'Z';
else
Signal2 <= '1';
Signal3 <= '1';
end if;

end process;


end architecture;