Q3VHDL

(a) Event-Driven Simulation

Event-driven simulation is the fundamental simulation execution model used by VHDL simulators, in which the simulator only recomputes and updates a signal's value at specific points in simulated time when an 'event' occurs - an event being any change in the value of a signal that a process is sensitive to. Rather than continuously re-evaluating every process in the design at every possible instant (which would be enormously wasteful of computation), the event-driven simulator maintains a scheduled event queue and only wakes up (executes) a given process when one of the signals in that process's sensitivity list actually changes value, dramatically improving simulation performance for large designs where most signals remain unchanged during most simulation time steps. For example, a process sensitive to a clock signal only executes at clock edges, remaining dormant during the rest of each clock period, exactly reflecting how a real synchronous digital circuit only updates its registered state at clock transitions.

(b) Data Types

VHDL is a strongly-typed language, meaning every signal, variable, and constant must be declared with an explicit data type, and the language provides several categories of built-in and user-definable data types. Scalar types include BIT (a two-valued type, '0' or '1'), STD_LOGIC (from the IEEE std_logic_1164 package, a nine-valued type including '0', '1', 'Z' for high-impedance, 'U' for uninitialized, and others, better modeling real hardware behavior than the simpler BIT type), BOOLEAN, INTEGER, and REAL. Composite types include arrays (such as STD_LOGIC_VECTOR, an indexed array of STD_LOGIC values used to represent multi-bit buses) and records (grouping multiple named fields of potentially different types into a single composite value). User-defined enumeration types (such as declaring a custom type with named states like IDLE, RUN, STOP for a finite state machine) are also widely used and are one of VHDL's most powerful features for writing clear, self-documenting state-machine code.

(c) Signals versus Variables

Signals represent actual physical wires or registers in the modeled hardware and are declared at the architecture level (visible throughout an entire architecture, or globally if declared in a package); a signal assignment does not take effect immediately but is scheduled to update after a delay (a delta delay if no explicit delay is specified), meaning multiple signal assignments to the same signal within a single process execution do not overwrite each other sequentially - only the last scheduled assignment actually takes effect when the process suspends. Variables, by contrast, are declared only within a process (or subprogram) and are local to that process; a variable assignment takes effect immediately, with the new value available for use in the very next statement within the same process execution, exactly like a variable in an ordinary sequential programming language. For example, using a variable as a running accumulator within a for-loop inside a process correctly accumulates a sum across loop iterations, whereas attempting the same accumulation using a signal within a single process would fail to work as intended, since all the signal assignments would only take effect after the process completes, with only the final assignment actually being applied.

(d) Packages

package my_pkg is
    constant DATA_WIDTH : integer := 8;
    type state_type is (IDLE, RUN, DONE);
    function max_val (a, b : integer) return integer;
end package my_pkg;

package body my_pkg is
    function max_val (a, b : integer) return integer is
    begin
        if a > b then return a; else return b; end if;
    end function;
end package body my_pkg;

A package is a VHDL construct used to collect and share commonly-used declarations - constants, data types, function and procedure definitions, and component declarations - across multiple design units (entities/architectures), avoiding the need to repeat identical declarations in every file that needs them. A package consists of a package declaration (specifying what is visible/available to units that use the package, as shown in the example above defining a shared constant, an enumeration type, and a function signature) and, if needed, a package body (providing the actual implementation of any functions or procedures declared in the package). Any design unit that needs to use the package's contents includes a 'use work.my_pkg.all;' clause, making the standard IEEE std_logic_1164 and numeric_std packages themselves prime examples of this mechanism - virtually every VHDL design relies on such standard packages for its basic data types and arithmetic operations, illustrating how central the package construct is to practical, maintainable VHDL design.

The choice between STD_LOGIC and plain BIT also has direct practical consequences for how realistically a simulation models real hardware behavior. Because STD_LOGIC includes values such as 'Z' (high impedance, used for tri-state bus outputs) and 'U'/'X' (uninitialized or unknown), a simulation using STD_LOGIC signals can correctly reveal design bugs that a BIT-based simulation would silently hide - for instance, reading an output port before it has ever been driven will show as 'U' in STD_LOGIC (immediately flagging a potential initialization bug to the designer), whereas the same scenario using BIT would simply default to '0', masking the fact that the signal was never actually assigned a meaningful value by any driver in the design. This is one of the principal reasons virtually all modern, practical VHDL designs use STD_LOGIC (and STD_LOGIC_VECTOR) from the IEEE std_logic_1164 package rather than the language's native BIT type, despite BIT being simpler and requiring no additional library.

The signal-versus-variable distinction also has direct implications for synthesizability and readability. Variables are especially useful for describing sequential, step-by-step computations within a single clock cycle - such as a multi-stage combinational computation broken into intermediate steps, or a loop-based accumulation as in the earlier example - because each variable assignment is immediately visible to the next statement in program order, closely matching how a designer might mentally reason through a multi-step calculation. Signals, in contrast, more naturally and directly represent the actual registers and wires that will exist in the final synthesized hardware, which is why many style guides recommend using variables primarily for local, intermediate computations inside a process and reserving signals for values that must be visible outside the process or that represent an actual physical register whose value must persist and be observable across clock cycles.

It is also worth noting that event-driven simulation and the signal-versus-variable distinction are directly linked: because a signal assignment only takes effect after a delta delay (as part of the event-driven simulator's scheduled event queue), any process that reads a signal immediately after assigning to it within the same process execution will still see the signal's old value, whereas reading a variable immediately after assigning to it sees the new value right away - this is one of the most common sources of confusion for VHDL beginners transitioning from ordinary sequential programming languages, and correctly understanding the event-driven, delta-delay-based signal update model is essential to correctly predicting simulation behavior in any process mixing signal and variable assignments.