Drivers on Signals

Question: I'm trying to understand some VHDL code written by a colleague which uses the word register in a signal declaration. Looking up the VHDL syntax, I found that a signal can be declared as a register or a bus. I have never seen this before. What does this mean, and ought I to use it when describing registers and busses?

Answer: Let's start with the conclusion! You should not be declaring all your registers and busses as register and bus. Why? Well, first I will give a concise technical definition of what a VHDL register and bus actually is, then I will explain what it's all about. So, take a deep breath before you read the next paragraph, and don't panic!

A VHDL signal declared using one of the keywords register or bus is known as a guarded signal. A guarded signal can have its drivers disconnected from its resolution function. When all the drivers are disconnected, the resolution function for a register is not called, whereas the resolution function for a bus is called with a zero length array (ie. no driving values).

Well, what was that all about? What is this subtle distinction between calling a function with no values, and not calling it at all? Why were the names register and bus chosen? Is this of use to man or beast?

Let's start at the beginning (or quite near the beginning, anyway). When a VHDL signal is assigned in a process, that process has a driver for that signal. VHDL drivers are invisible, but they are similar in concept to active drivers in digital logic circuits. A signal assigned in more than one process has therefore more than one driver, and such a signal must possess a resolution function, whose job is to resolve conflicts between drivers. A resolution function is a VHDL function which is called with a one dimensional array of values, one value per driver, each time an event occurs on the signal (VHDL gurus will know this to be a simplification of the truth, but I think it will suffice). The resolution function provides a simulation model of the behaviour of wired logic, such as the behaviour of a tristate bus or a wired and function, and returns the value seen by any process reading the signal (called the effective value, in VHDL jargon).

So much for resolution functions. Now, what about guarded signals? The drivers of a guarded signal can be individually disconnected from the resolution function, under the control of the processes assigning the signal. A driver is disconnected by assigning it the value null within a process. The value of a disconnected driver is invisible to the resolution function, which is only passed the values of the connected drivers. Thus, the resolution function uses only a subset of the drivers when calculating the effective value of the signal.

Where is all this technical mumbo jumbo leading too? Let's look first at bus. A guarded signal of the kind bus was intended to be used to describe tristate busses in VHDL (Oh! You guessed!), but has not been widely used for this (or any other) purpose in practice. Disconnection is used to model the high impedance state of the tristate driver, and when all the drivers are disconnected, the resolution function is called with no driving values and is free to chose a floating value for the bus. In practice, the IEEE 1164 standard data types (such as Std_logic) are used instead of bus. Such types include an explicit 'Z' value, so there is no need for guarded signals and disconnected drivers.

Now for register. When all the drivers are disconnected, the resolution function is not called, so the guarded signal keeps its current value. Has the penny dropped yet? The register will register the current value until it's changed by connecting a driver, and is thus a rather abstract way of modelling a hardware register with multiple sources of data. Under normal operation, no more than one driver would be connected at once, and a driver would only remain connected long enough to register the new value.

Register signals have not been used much in practice, they do not belong to the de facto standard synthesizable subset of VHDL, and there is no particular reason to start using them now. However, they do open the way to a major VHDL "paradigm shift". So, just for a moment let's look at how things might have been if VHDL synthesis and analysis tools had embraced register.

Using register, it becomes possible to decribe the behaviour of a single piece of hardware using multiple processes, not structural decomposition as we're all used to, but pure functional decomposition. For example, take a simple D-type flipflop with asynchronous reset. Using the de facto standard VHDL style, one would write:

  process (Reset, Clock) -- 2 actions in one process
  begin
    if Reset = '0' then
      Q <= '0';
    elsif Rising_edge(Clock) then -- Or equivalent
      Q <= D;
    end if;
  end process;

Using register, one could write:

-- inside an architecture body
  signal Q: STD_LOGIC register; -- Guarded signal
begin
  process (Reset) -- This process does just the reset
  begin
    if Reset = '0' then
      Q <= '0';
    else 
      Q <= null; -- Explicit disconnection
    end if;
  end process;

  process (Clock'Stable) -- This process does the clocking
  -- Clock'Stable is here to disconnect the driver
  -- in the delta after the clock edge
  begin
    if Rising_edge(Clock) then
      Q <= D; -- Connect the driver in the delta when Clock rises
    else
      Q <= null; -- Explicit disconnection
    end if;
  end process;
end; -- end of architecure body

The first destination oriented assignment style is relatively compact. In contrast, the second source oriented assignment style using guarded signals is verbose, inefficient for simulation (because of the need for resolution), and harder to debug because an error in the value of Q could be caused by one of several processes. So, it's probably best to avoid using this alternative style anyway!

Finally, you might wonder what guarded signals have got to do with guarded blocks, guarded assignments, and the disconnect syntax. Well, those other statements cause implicit disconnection of guarded signals using concurrent assignments, but that's another story!

VHDL FAQ
Doulos Training Courses
Back to “Your VHDL Problems Answered” Index

Doulos Home Page

We welcome your e-mail comments. Please contact us at: webmaster@doulos.co.uk