Class discussion notes

Difference between 'X' and 'Z'

• It's important to remember that every VHDL concurrent signal assignment statement is always driving the signal, not just at the moment when the value is assigned. If some driver is supplying an 'X', that will drive a tri-state bus (the standard STD_LOGIC_1164 bus resolution function) to 'X' even if there is a '1' or '0' supplied by another signal. The meaning of 'X' (and 'U' as well) are that the signal is being driven, but we don't know the value.

  By contrast, 'Z' and '0' or 'Z' and '1' always resolve to the known value, '0' or '1'. The VHDL driver supplies 'Z', but the meaning is that the real circuit driver output would be off.

Why use WHEN-ELSE statements instead of CASE statements

In Lab 1 there seems to be a temptation when supplying a vector of enable's from the decoder in Part 4 to use the enable vector as the selector variable. For EN(0 to N-1) this will generally produce a multiplexor circuit with 2**N inputs instead of N inputs feeding N AND gates. Even though some synthesis tools may allow you override this interpretation to get the circuit you want, it is not the most direct, simple, and easily understand way to describe the circuit you want.

The better solution is to describe each of the elements with a simple

	destination <= func_i WHEN enable_i ELSE 'Z';

This produces exactly the tri-state buffer you needed.

Bus resolution functions

It is not necessary to create a bus resolution function for Lab 1. There are bus resolution functions provided for STD_LOGIC and STD_LOGIC_VECTOR that do exactly what one would expect for a tri-state bus. (STD_ULOGIC and STD_ULOGIC_VECTOR do not have a bus resolution function associated with them.

Note that you do need a bus resolution function to realize the solution just described above, since all eight of the WHEN enable_i statements will drive the same destination. Assignments to that destination have to go through the bus resolution function. But it's available -- for free -- for exactly this purpose!

Why use multiple WHEN-ELSE statements instead of nested (prioritized) WHEN-ELSE statements

Several have attempted to collect all the enable's together into one large

	destination <= func_a WHEN enable_a ELSE
		func_b WHEN enable_b ELSE ...
		func_n WHEN enable_n ELSE 'Z';

However, this also produces a great deal more logic than intended, unless you use a special switch to the synthesis tool to tell it that the condition expressions are disjoint and prioritization is unnecessary. The natural outcome of this description will normally produce a prioritized enable circuit nearly as complex as the multiplexor described above. Use the multiple, un-nested WHEN statements instead.

Are concurrent statements behavioral or structural

Although some authors will argue otherwise, I claim that concurrent (also called dataflow statements are both behavioral and structural, as the figure above suggests.
• They are behavioral because they show intended function, and can have timing associated with them.

  However, they are not procedural. Functions, procedures, and the inside part of processes are procedural and convey behavioral information in a different way.

• They are also structural because they exist concurrently in space, just as structures do; and they have naturally implied structural realizations that require very little interpretation. For example, WHEN-ELSE implies a collection of AND gates, prioritized. WITH-SELECT implies a multiplexor (or sometimes a decoder). The signals connecting concurrent VHDL statements generate the structural interconnections normally associated with any other netlist description language. Concurrent VHDL signal assignment statement waveforms are expressions that translate in a straightforward way into combinational logic just like boolean expressions.

Rev. 9/21/95 B. Huey