VHDL Driver and Source concept

In the previous lesson we talk about the transaction. A transaction is a couple value/time that is scheduled on a signal.


The set of transactions for a signal is the driver of that signal.


In its turn, the driver is driven by the source of the signal.

The source of a signal is a

  • process that assigns values to the signal
  • connection of the signal to a port of type in, inout , or buffer.

A signal can have either a single source or multiple sources; therefore, one or more drivers.

In the case of more than one driver, the signal must be of a “resolved type” and a resolution function must be associated with it: this function must “resolve” the drivers into a single transaction.

It is illegal to have multiple drivers for a signal, which is not a resolved type, that is, a signal for which the bus resolution function is not defined.


Driver example

Here there are some examples of driver and source.

Example 1

signal a : integer;

-- ok: Single driver
process_driver : process(...)
 a <= 3 after 10 ns;
 a <= 4 after 20 ns;
end process process_driver;


This should clarify the concept: when we introduced the process statement, in the example we talk about driving the output port of the entity. In the driver definition, we stated that a process is a driver for the signal. In this case, the process is a driver for signal “a”. The statement is OK.

Example 2

-- ERROR: TWO driver
process_driver1 : process(...)

  a <= 3 after 10 ns;

end process process_driver1;
process_driver2 : process(...)
  a <= 4 after 20 ns;
end process process_driver2;

the assignment on signal “a” seems to be the same of previous one but two different processes execute the task. This is an example of multiple drivers: as we state, the process is a driver for the signal. This code is illegal since the signal “a” is a not resolved type.

In fact integer type is not resolved type as we will see going ahead. In this case, the simulator will rise a compile error. If “a” have a resolution function, the simulator will compile the code. The code syntax is correct but, in layout phase, the analyzer will rise a multiple drive error.

Example 3

-- ok: Single driver
architecture single_driver_a of ... is
  a <= 5 after 10 ns;
end single_driver_a;


This example is a concurrent assignment of signal “a” in the statement section. Also in this case, “a” has single driver. This situation is very similar to the Example 1.

Also in this example, “a” has two drivers that are represented by the two concurrent assignment.


-- ERROR: TWO driver
architecture multiple_driver_a of ... is
 a <= 4 after 10 ns;
 a <= 5 after 20 ns;
end multiple_driver_a;


Concurrent Assignment: Bad Driver Example

Let’s design a 4-way mux similar to the example seen in the previous lesson. In this case the mux selector is bit-vector that means is a bus of 2 bit instead of two different lines s0 and s1.

An incorrect way to describe the mux is:

entity mux4_driver is
  a       : in bit;
  b       : in bit;
  c       : in bit;
  d       : in bit;
  s       : in bit_vector(1 downto 0);
  e       : out bit);
end mux4_driver;

architecture mux4_driver_bad_a of mux4_driver is

  e <= a when (s = "00") else '0';
  e <= b when (s = "01") else '0';
  e <= c when (s = "10") else '0';
  e <= d when (s = "11") else '0';

end mux4_driver_bad_a;

It is clear that this implementation create 4 different drivers for output “e”. In this case, the simulator will rise a “multiple drive error” on signal “e” and stop compiling. Being more precise, the simulator stops because the type bit-vector is a no-resolved type. Having a multiple driver on a signal is not a syntax error.


Concurrent Assignment: Good Driver Example

Better and canonical implementation of a 4-way mux is:


architecture mux4_driver_good_a of mux4_driver is

  e <= a when (s = "00") else,
       b when (s = "01") else,
       c when (s = "10") else,

end mux4_driver_good_a;


In this case, only one driver is present for signal “e”. In fact, the conditional assignment is only one.

As rule of thumb, in a concurrent statement, each assignment is a driver for the assigned signal.

As we will see, this is not true in the sequential statement.


Previous – Next