VHDL is a compound acronym for VHSIC (Very High Speed Integrated Circuit) HDL (Hardware Description Language). As a Hardware Description Language, it is primarily used to describe or model circuits. VHDL is an ideal language for describing circuits since it offers language constructs that easily describe both concurrent and sequential behavior along with an execution model that removes ambiguity introduced when modeling concurrent behavior.

VHDL is typically interpreted in two different contexts: for simulation and for synthesis. When interpreted for synthesis, code is converted (synthesized) to the equivalent hardware elements that are modeled. Only a subset of the VHDL is typically available for use during synthesis, and supported language constructs are not standardized; it is a function of the synthesis engine used and the target hardware device. When VHDL is interpreted for simulation, all language constructs are available for modeling the behavior of hardware.

Prior VHDL 1993, two concurrent processes could communicate only with signals. Thanks to the simulation semantics of the language that updates signals only between simulation steps, the result of a simulation was deterministic: it did not depend on the order chosen by the simulation scheduler to execute the processes.

[In fact, this is not 100% true. Processes could also communicate using file input/output. But if a designer was compromising the determinism by using files, it could not really be a mistake.]

The language was thus safe. Except on purpose, it was almost impossible to design non-deterministic VHDL models.

VHDL 1993 introduced shared variables and designing non-deterministic VHDL models became very easy.

VHDL 2000 introduced protected types and the constraint that shared variables must be of protected type.

In VHDL, protected types are what resemble most the concept of objects in Object Oriented (OO) languages. They implement the encapsulation of data structures and their methods. They also guarantee the exclusive and atomic access to their data members. This does not completely prevent non-determinism but, at least, adds exclusiveness and atomicity to the shared variables.

Protected types are very useful when designing high level VHDL models intended for simulation only. They have several very good properties of OO languages. Using them frequently makes the code more readable, maintainable and reusable.

Notes:

• Some simulation tool chains, by default, only issue warnings when a shared variable is not of a protected type.
• Some synthesis tools do not support protected types.
• Some synthesis tools have a limited support of shared variables.
• One could think that shared variables are not usable to model hardware and shall be reserved for code instrumentation without side effects. But the VHDL patterns advised by several EDA vendors to model the memory plane of multi-ports Random Access Memories (RAM) use shared variables. So, yes, shared variables can be synthesizable in certain circumstances.

The use of resolved types should be reserved to situations where the intention is really to model a hardware wire (or set of wires) driven by more than one hardware circuit. A typical case where it is needed is the bi-directional data bus of a memory: when the memory is written it is the writing device that drives the bus while when the memory is read it is the memory that drives the bus.

Using resolved types in other situations, while a frequently encountered practice, is a bad idea because it suppresses very useful compilation errors when unwanted multiple drive situations are accidentally created.

The ieee.numeric_std package declares the signed and unsigned vector types and overloads the arithmetic operators on them. These types are frequently used when arithmetic and bit-wise operations are needed on the same data. The signed and unsigned types are resolved. Prior VHDL2008, using ieee.numeric_std and its types thus implied that accidental multiple drive situations would not raise compilation errors. VHDL2008 adds new type declarations to ieee.numeric_std: unresolved_signed and unresolved_unsigned (aliases u_signed and u_unsigned). These new types should be preferred in all cases where multiple drive situations are not desired.