I asked Gemini to teach me about the VHDL resolved signals. What you read below is the result.

Mastering Resolved Signals in VHDL: A Comprehensive Guide for Digital Design

1. Introduction to Signals in VHDL

The Fundamental Role of Signals in Hardware Description

In VHDL, signals serve as the foundational elements for representing physical wires and interconnections within a digital circuit. They are paramount in describing hardware behavior because, unlike variables, signals inherently possess a time dimension. This means that their values are not updated instantaneously but rather after a specified delay, which can be a default delta delay (an infinitesimal simulation time step) or an explicitly defined inertial or transport delay.¹ This characteristic is vital for accurately modeling the concurrent and time-dependent nature of real-world hardware operations.

VHDL, as a Hardware Description Language (HDL), is specifically engineered to model digital systems across a spectrum of abstraction levels. This ranges from intricate gate-level details, representing individual logic gates, to broader system-level functionalities, encompassing entire subsystems or even complete architectures.² The overarching objective of employing VHDL in digital design is to achieve maximum design reliability throughout the development cycle while simultaneously minimizing development costs and the time to market.

A crucial distinction in VHDL is between signals and variables. Variables, unlike signals, are updated immediately within a sequential process and do not possess a direct hardware equivalent.⁵ Consequently, they are generally not suitable for representing physical connections that carry state over time. Misusing variables for hardware representation can lead to discrepancies between simulation results and the actual synthesized hardware, a common source of design errors.

The Concept of Multiple Drivers and the Need for Resolution

A common and essential scenario in complex digital systems involves a single physical wire or bus being driven by multiple sources or components. For instance, a data bus within a computer architecture is typically a shared resource, enabling various devices such as the Central Processing Unit (CPU), memory modules, or peripheral devices to write data onto it at different times.⁷

When multiple drivers attempt to assign a value to the same signal simultaneously, a fundamental conflict arises. Without a predefined and explicit mechanism to handle such situations, a VHDL simulator would be unable to definitively determine the signal’s final value. This ambiguity would lead to unpredictable behavior during simulation or, more commonly, result in a compilation or simulation error, halting the design process.⁹

This is precisely the problem that “resolved signals” are designed to address. They provide a formal and explicit method to define how conflicting values originating from multiple sources are combined or “resolved” into a single, unambiguous value for the signal. This mechanism is indispensable for accurately modeling complex physical interactions inherent in digital hardware, such as bus contention or the behavior of tri-state logic.⁷

The ability of VHDL to model concurrent hardware operations, where multiple components frequently connect to a single line, inherently requires a mechanism to manage these multi-driver scenarios. Without signal resolution, VHDL would either be overly restrictive, allowing only single drivers unlike real-world buses, or it would produce undefined simulation behavior for common hardware constructs. The concept of resolution functions directly bridges this gap, enabling VHDL to model complex physical interactions like bus contention or tri-state logic in a predictable and defined manner. This crucial feature ensures that the design intent for shared resources is clearly captured and accurately simulated, aligning the abstract VHDL model with the physical reality of interconnected digital circuits.

Furthermore, the strict error generation that occurs when an unresolved signal has multiple drivers is a critical feature of VHDL. This is not merely a syntax error; it signifies a fundamental design flaw that the language helps to identify and flag early in the development cycle. The VHDL type system, through its clear distinction between resolved and unresolved types, compels designers to explicitly consider and define hardware behavior that would otherwise be ambiguous or problematic in physical implementation. This proactive detection mechanism is a core benefit of using resolved types where multiple drivers are intentionally designed, or conversely, using unresolved types to prevent unintended multi-driver scenarios. It functions as a built-in design rule checker, promoting the creation of more robust and predictable hardware designs.

2. Understanding Resolved vs. Unresolved Signals

Formal Definition of Resolution Functions and Resolved Signals

A resolution function in VHDL is a specialized type of pure function. Its fundamental purpose is to precisely define how values originating from multiple concurrent drivers are combined into a single, composite value for a given signal. To serve this role, the function must adhere to specific structural rules: it must accept a single input parameter, which must be an unconstrained one-dimensional array of the signal’s base type, and it must return a single value of that same base type.⁷

A signal is formally designated as “resolved” if its declared type or subtype has an associated resolution function. When such a signal is driven by multiple sources simultaneously, this resolution function is automatically invoked by the VHDL simulator. The function then computes the signal’s effective value at that particular simulation time, ensuring a deterministic outcome despite multiple inputs.⁷

Conversely, if a signal’s type is “unresolved” (meaning no resolution function is explicitly associated with it), any attempt to assign values to it from multiple drivers will result in a compilation or simulation error. This strict behavior is a deliberate design choice within VHDL, as it helps designers proactively identify and rectify unintended conflicts in their hardware descriptions.¹⁰

The std_ulogic (Unresolved) and std_logic (Resolved) Types from IEEE.std_logic_1164

The IEEE.std_logic_1164 package is an internationally recognized IEEE standard that significantly extends VHDL’s inherent BIT type. It provides a comprehensive multi-value logic system, which is essential for accurately modeling the complexities and nuances of real-world digital hardware.¹⁸

Within this widely used package, std_ulogic is defined as an unresolved 9-valued logic type. Its values go beyond the simplistic ‘0’ and ‘1’ to represent various real-world digital states, providing a more granular and realistic representation of signal conditions:

• ‘U’: Uninitialized – The signal’s value is unknown because it has not yet been driven.
• ‘X’: Forcing Unknown – A strong conflict exists (ee.g., a ‘0’ and a ‘1’ are simultaneously driving the signal), resulting in an unpredictable or indeterminate state.
• ‘0’: Forcing 0 – A strong driver is pulling the signal to a logic low.
• ‘1’: Forcing 1 – A strong driver is pulling the signal to a logic high.
• ‘Z’: High Impedance – The signal is not being actively driven by any source, effectively disconnected.
• ‘W’: Weak Unknown – A weak conflict exists, similar to ‘X’ but with less driving strength.
• ‘L’: Weak 0 – A weak driver is pulling the signal to a logic low (e.g., a pull-down resistor).
• ‘H’: Weak 1 – A weak driver is pulling the signal to a logic high (e.g., a pull-up resistor).
• ‘-': Don’t care – The signal’s value is irrelevant for the current operation or condition.
  
  ⁷

Table 1: std_ulogic Values and Their Meanings

std_logic is a resolved subtype of std_ulogic. It is explicitly defined within the std_logic_1164 package with the resolved function automatically associated with it. This means that any signal declared using the std_logic subtype will automatically employ this resolved function to determine its final value whenever multiple drivers are present.⁷ It is important to note that the basic VHDL

BIT and BIT_VECTOR types, which are part of the standard VHDL package, are not resolved and are therefore unsuitable for modeling multiple-source buses.⁸

This table provides a quick reference for the 9-valued logic system of std_ulogic, which forms the fundamental basis for std_logic. Understanding these distinct values is critical for comprehending how resolution functions operate and how different signal states interact. It directly addresses the proper use of resolved signals by laying out the essential building blocks of the resolved type system. Without this foundational knowledge, interpreting the complex resolution tables, such as the one used by std_logic, would be challenging.

Why std_logic is the Industry Standard for Multi-Valued Logic

The inherent capability of std_logic and its vector counterpart, std_logic_vector, to handle multiple drivers and accurately model complex bus behaviors, including the crucial high-impedance (‘Z’) state, has solidified their position as the de facto industrial standard types in VHDL design.⁸ This multi-valued logic system allows for a more accurate representation of real-world electrical characteristics than simple binary logic.

Beyond their resolution capabilities, the std_logic_1164 package further enhances its utility by providing a rich set of logical operators (e.g., AND, OR, XOR) and conversion functions. These additional features streamline the design process and facilitate interoperability between different components and design methodologies, contributing significantly to its widespread adoption in the digital design community.¹⁸

Behavior of Unresolved Types with Multiple Drivers (Simulation Errors)

A significant advantage of consistently employing unresolved types, such as std_ulogic, throughout a design is their ability to proactively identify design flaws. This approach ensures that any accidental multiple drivers attempting to assign a value to a single signal will immediately result in a compilation or simulation error.¹⁰ This proactive error detection mechanism is invaluable as it helps to pinpoint and prevent potential design issues, such as unintended short circuits or bus contention, early in the design process, before they manifest as costly hardware failures.

When a std_ulogic signal is driven by more than one source, the VHDL tool will explicitly flag an error, clearly indicating a conflict that the designer must manually address. The resolution typically involves either restructuring the design to ensure only one driver is active at any given time or, if multiple drivers are truly intended, explicitly changing the signal to a resolved type and implementing the appropriate resolution logic.¹⁰

The fact that unresolved types generate errors when faced with multiple drivers is a deliberate design choice within VHDL, serving as a robust safety mechanism. This implies a clear design philosophy: unless a designer explicitly defines how multiple drivers should resolve their values, VHDL treats such a scenario as an error. This acts as a critical safety net during both design and simulation, effectively catching unintended bus contention or short circuits. Without this feature, such issues might be silently masked by a default resolution or lead to unpredictable behavior in the physical hardware. This design choice compels the designer to be highly intentional about managing multi-driver scenarios.

A notable evolution in VHDL, particularly with the VHDL-2008 standard, is the improved interoperability between resolved (std_logic) and unresolved (std_ulogic) types. In VHDL-2008, std_logic is defined as a subtype of std_ulogic.¹⁶ This enhancement significantly reduces the need for explicit type conversions when connecting components that utilize these related logic types, thereby streamlining the design process and reducing the amount of boilerplate code. This is especially beneficial when integrating pre-existing Intellectual Property (IP) cores into a larger design. This improvement reflects a broader trend towards greater flexibility and reduced verbosity in modern VHDL, making the language more user-friendly and efficient for complex designs.

3. How Standard Resolution Functions Work (e.g., std_logic)

Detailed Explanation of the resolved Function and its resolution_table

The resolved function, which is an integral part of the IEEE.std_logic_1164 package, forms the core of std_logic’s ability to handle multiple drivers. This function is designed to take an unconstrained std_ulogic_vector as its input, representing all the individual values currently driving a particular signal. Its output is a single std_ulogic value, which is the result of resolving these multiple inputs.⁷

The resolved function typically operates by utilizing a resolution_table. This table is a constant, two-dimensional array of std_ulogic values, indexed by two std_ulogic inputs. The table comprehensively defines the logical outcome for every possible combination of two input values. The function processes the input vector by iterating through its elements, progressively resolving values by looking up the result in this predefined table. This iterative process ensures that all contributing drivers are accounted for in determining the final signal value.⁷

A critical aspect of the resolved function’s implementation is a preliminary check for a single driver (s’LENGTH = 1). If the function detects that only one source is driving the signal, it directly returns that single value. This check is essential to prevent unintended resolution effects; for example, if a single driver assigns a ‘-’ (Don’t care) value, without this check, the iterative resolution process might incorrectly resolve it to an ‘X’ (Unknown) state. The resolution process typically initializes an internal variable to a weakest state default, commonly ‘Z’ (High Impedance), before applying the iterative resolution logic based on the resolution_table.⁸

Illustrative Examples of Value Resolution

The resolution_table within the resolved function precisely defines the outcome of various conflicts and combinations of signal values. Here are some illustrative examples of how values resolve:

• ‘0’ and ‘1’ resolving to ‘X’ (Forcing Unknown): This outcome signifies a strong conflict, akin to a short circuit in physical hardware where a strong low and a strong high are simultaneously applied. The result is an indeterminate and undesirable state.¹⁰
• ‘0’ and ‘Z’ (High Impedance) resolving to ‘0’: This indicates that a strong ‘0’ driver successfully overrides a high-impedance state, pulling the bus low. Similarly, ‘1’ and ‘Z’ resolve to ‘1’.⁸
• ‘L’ (Weak 0) and ‘H’ (Weak 1) resolving to ‘X’: This demonstrates a conflict between weak drivers, resulting in an unknown state due to their balanced but opposing influences.⁸
• Any value combined with ‘U’ (Uninitialized) typically results in ‘U’: This propagates the uninitialized state, indicating that the signal’s history is not yet defined.⁸
• Any value combined with ‘X’ (Forcing Unknown) typically results in ‘X’ (unless combined with ‘U’): This ensures that once an unknown or conflicted state is introduced, it tends to propagate through the system, reflecting the uncertainty.⁸

This detailed resolution mechanism enables the accurate modeling of complex bus behaviors, such as wired-AND, wired-OR, or tri-state logic, where different signal strengths and states interact in a defined manner.⁸

Table 2: Simplified std_logic Resolution Table (Output for Input1 vs. Input2)

This table is essential for understanding the practical application of std_logic resolution. While the full resolution table is extensive, this simplified version highlights key interactions, such as those between strong and weak drivers, conflicts, and the high-impedance state. It visually demonstrates the core logic of the resolved function, which can often seem abstract to new users. This directly illustrates the expected behavior of std_logic in multi-driver scenarios, providing a clear reference for proper usage.

The rich set of values provided by the std_logic type, particularly ‘Z’ (High Impedance) and ‘X’ (Forcing Unknown), are fundamental to its utility in modeling buses.⁸ The ‘Z’ state allows multiple devices to effectively disconnect from a bus, enabling other devices to drive it without contention. The ‘X’ state is crucial for representing true conflicts, such as when a ‘0’ and a ‘1’ are simultaneously driven, which would result in a short circuit in physical hardware.²¹ The resolution function’s sophisticated handling of these states is what makes

std_logic uniquely suitable for simulating, and to some extent, synthesizing complex bus behaviors, where a simpler ‘0’/‘1’ logic would be entirely insufficient. This capability underscores the practical power of multi-valued logic in VHDL.

A foundational principle of VHDL is that resolution functions must be pure.⁷ A pure function’s output depends exclusively on its input parameters, ensuring deterministic and predictable behavior. This characteristic is critical for hardware description, as the outcome of a signal resolution must be entirely predictable and repeatable, precisely mirroring the behavior of a physical circuit. If resolution functions were impure (e.g., if their output depended on internal state or global variables), the behavior would be non-deterministic, rendering simulation results unreliable and making synthesis into physical hardware impossible. This requirement reinforces a core tenet of VHDL for hardware design: predictability and determinism are paramount for reliable hardware implementation.

4. Implementing Custom Resolved Types

Step-by-Step Guide to Defining a User-Defined Resolved Signal

While std_logic is the ubiquitous industry standard, VHDL provides the flexibility for designers to define their own custom resolved types. This capability is particularly useful for specialized bus protocols that might have unique resolution logic, or for modeling custom signal behaviors not perfectly captured by the std_logic standard.⁸

The process of defining a user-defined resolved signal involves four key steps: ¹⁴

1. Declare the signal’s base type: This initial step involves defining the fundamental enumerated or composite type that the signal will carry. This type represents the set of values the signal can assume.
   VHDL
   type MY_BASE_TYPE is (VAL1, VAL2, VAL3); – Example: an enumerated type \

2. Declare the pure resolution function: This function is the heart of the custom resolution. It must be declared as pure to ensure deterministic behavior. The function’s signature must specify that it takes a single input parameter, which is an unconstrained array of MY_BASE_TYPE, and returns a single value of MY_BASE_TYPE. An auxiliary array type is typically defined for this purpose.
   VHDL
   type MY_BASE_TYPE_VECTOR is array (natural range <>) of MY_BASE_TYPE;
   function MY_RESOLUTION_FUNC (DATA: MY_BASE_TYPE_VECTOR) return MY_BASE_TYPE;
   
   The function body, implementing the custom resolution logic, will be defined later, usually in a package body.⁷

3. Declare the resolved signal’s subtype: This crucial step associates the newly defined base type with the custom resolution function. This subtype is what will be used to declare the actual signals that require resolution.
   VHDL
   subtype MY_RESOLVED_SUBTYPE is MY_RESOLUTION_FUNC MY_BASE_TYPE;
   
   This declaration tells the VHDL simulator to automatically invoke MY_RESOLUTION_FUNC whenever a signal of MY_RESOLVED_SUBTYPE has multiple drivers.¹³

4. Declare resolved signals as resolved subtypes: Finally, signals that are intended to have multiple drivers and utilize the custom resolution logic are declared using the newly defined resolved subtype.
   VHDL
   signal my_custom_bus_signal: MY_RESOLVED_SUBTYPE;
   
   Any concurrent assignments to my_custom_bus_signal from different sources will now be resolved by MY_RESOLUTION_FUNC.¹⁴

Practical Example: A wired_AND Resolution Function

A common scenario where a custom resolution function is beneficial is in modeling a wired_AND bus. In such a bus, the overall value is ‘0’ if any single driver pulls it low, and it only transitions to ‘1’ if all active drivers are ‘1’ (or in a high-impedance state).¹⁴

Here is an example implementation of a wired_AND resolution function within a VHDL package, followed by its usage in an architecture: ¹⁴

VHDL

– Package Declaration (e.g., my_bus_logic.vhd)
library IEEE;
use IEEE.std_logic_1164.all;

package MY_BUS_LOGIC is
– Declare the resolution function
function wired_and_func (input : std_logic_vector) return std_logic;
– Declare the resolved subtype, associating it with the function
subtype WIRED_AND_LOGIC is wired_and_func std_logic;
end package MY_BUS_LOGIC;

– Package Body (e.g., my_bus_logic_body.vhd)
package body MY_BUS_LOGIC is
function wired_and_func (input : std_logic_vector) return std_logic is
variable result : std_logic := ‘1’; – Initialize to ‘1’ for AND logic
begin
– If only one driver, return its value directly
if input’length = 1 then
return input(input’low);
else
– Iterate through all drivers and perform the wired-AND operation
for i in input’range loop
result := result and input(i);
end loop;
end if;
return result;
end function wired_and_func;
end package body MY_BUS_LOGIC;

– Usage in an Architecture (e.g., my_design.vhd)
library IEEE;
use IEEE.std_logic_1164.all;
use work.MY_BUS_LOGIC.all; – Import your custom package

entity MyDesign is
port (
driver_a : in std_logic;
driver_b : in std_logic;
driver_c : in std_logic;
shared_bus_out : out WIRED_AND_LOGIC – Output port declared with custom resolved subtype
);
end entity MyDesign;

architecture Behavioral of MyDesign is
– Internal signal of the custom resolved type, allowing multiple drivers
signal internal_shared_bus : WIRED_AND_LOGIC;
begin
– Multiple concurrent drivers for the internal_shared_bus
internal_shared_bus <= driver_a;
internal_shared_bus <= driver_b;
internal_shared_bus <= driver_c;

– Assign the resolved internal signal to the output port
shared_bus_out <= internal_shared_bus;
end architecture Behavioral; \

In the wired_and_func, the initialization of the result variable to ‘1’ is crucial for achieving the correct wired_AND behavior. If it were initialized to ‘0’, the output would erroneously always be ‘0’ unless all inputs were ‘1’, which would not reflect the desired logic.²¹

The demonstration of defining custom resolved types and functions within a VHDL package illustrates a critical VHDL best practice.²⁵ This approach enables the abstraction of complex resolution logic, making it highly reusable across multiple modules and even different projects. Instead of requiring designers to rewrite the resolution function or explicitly apply it in every instance, defining a subtype simplifies signal declarations and significantly improves code readability and maintainability. This exemplifies how VHDL’s language features inherently support modular and scalable hardware design methodologies.

Custom resolution functions provide designers with the capability to model specific physical behaviors that might not be fully captured by std_logic’s default resolution. For instance, some specialized bus standards might incorporate unique resolution rules, or certain analog-like interactions may need to be simplified into digital states. By offering the flexibility to define arbitrary resolution functions (while adhering to the pure function constraint), VHDL facilitates a higher fidelity simulation of complex hardware interactions. This remains true even if the exact synthesis of such arbitrary functions into physical hardware is limited, as will be discussed in a later section. This capability highlights VHDL’s strength as a description language, extending beyond its role as merely a synthesis language.

5. Practical Applications and Use Cases

Modeling Shared External Buses (e.g., Data Buses, Tri-State I/O)

The primary and most prevalent application of resolved signals in VHDL is the accurate modeling of external shared buses. These include common interfaces such as a microprocessor’s data bus or address bus, where multiple physical devices (e.g., CPU, memory, various peripherals) are designed to drive the same set of wires.⁸

A key enabling technology for shared buses is tri-state logic. When a device is not actively driving the bus, its output enters a high-impedance (‘Z’) state. This effectively disconnects the device from the bus, allowing other devices to drive the bus without electrical contention.²⁰ Resolved types like

std_logic are indispensable in this context because they inherently understand and correctly resolve the ‘Z’ state. This capability is crucial for accurate simulation of tri-state bus behavior, reflecting how signals behave in real hardware.

For external buses, it is absolutely critical to implement an arbitration scheme that ensures only one device is actively driving the bus (i.e., asserting a ‘0’ or ‘1’ value) at any given time, with all other potential drivers in the ‘Z’ state. Failure to enforce this rule can lead to bus contention, which manifests as a short circuit in physical hardware. In VHDL simulation, such contention would typically result in an ‘X’ (unknown) or ‘U’ (uninitialized) state on the bus, indicating an electrical conflict.²⁰

Simulating Bidirectional I/O Pins

Bidirectional I/O pins, which are common in external interfaces for microcontrollers, FPGAs, and other digital integrated circuits, represent another prime use case for resolved signals. A single physical pin needs to function dynamically as both an input and an output, depending on the system’s operational mode.¹⁰

In VHDL, this bidirectional behavior is typically modeled using an inout port declared with a resolved type, most commonly std_logic. When the system needs to drive data out of the pin, it assigns a ‘0’ or ‘1’ to the corresponding internal driver for that port. Conversely, when the system needs to receive data from the pin (i.e., use it as an input), it assigns ‘Z’ to its internal driver for that pin. This assignment effectively places the internal driver in a high-impedance state, allowing an external source to drive the value onto the pin, which can then be read by the VHDL entity.²¹

Here is a common example of a tri-state buffer for a vector of signals, often used to implement bidirectional I/O for a data bus: ²³

VHDL

– Assuming N is a generic or constant defining the vector width
– In an entity/architecture declaration section:
signal Y : std_logic_vector(N downto 0); – The bidirectional signal/port
signal A : std_logic_vector(N downto 0); – Data to drive out of the port
signal EN : std_logic_vector(N downto 0); – Enable signal for each bit of the tri-state buffer

– Using a generate statement for bit-wise tri-state control
tristate_gen : for i in Y’range generate
begin
– Each bit Y(i) is driven by A(i) when EN(i) is ‘1’, otherwise it’s in high-impedance (‘Z’)
Y(i) <= A(i) when EN(i) = ‘1’ else ‘Z’;
end generate tristate_gen; \

This generate statement efficiently creates multiple parallel tri-state buffers, one for each bit of the vector, effectively modeling a tri-state vector. This allows for fine-grained control over which bits are actively driven and which are in a high-impedance state.²³

The fact that resolved signals are particularly important for modeling buses and simulating bidirectional I/Os suggests that these specific domains are where their inherent complexity is most justified. This observation naturally leads to a question: if resolved signals are so powerful and versatile, why are they not universally employed throughout all VHDL designs? The answer lies in various trade-offs, particularly concerning hardware synthesis, which will be elaborated upon in the subsequent sections. This foreshadows the discussion on best practices and alternatives, indicating that while resolved signals are excellent for specific external interfaces, they might not represent the optimal choice for internal logic within an FPGA or ASIC.

A critical operational implication for multi-driver systems is the necessity for modules to “cooperate” to prevent short circuits when driving a shared signal.²¹ While resolved signals effectively

define the outcome of conflicts (e.g., ‘0’ and ‘1’ resolving to ‘X’), they do not inherently prevent these conflicts from occurring. The designer remains fully responsible for implementing a higher-level arbitration scheme—such as ensuring that only one driver is active at a time, or establishing a defined priority system—to guarantee that the bus behaves as intended and avoids undesirable ‘X’ states in the synthesized hardware. This highlights that resolution functions serve primarily as a modeling tool to describe electrical behavior, rather than a comprehensive design solution for contention management, which must be addressed by explicit control logic (e.g., bus arbiters).

6. Synthesis Implications and Pitfalls

General Synthesizability of Multiple Drivers (Often Discouraged Internally)

While VHDL’s resolved signals permit the modeling of multiple drivers for simulation purposes, the use of internal tri-state buses (i.e., signals within the FPGA or ASIC fabric that can enter a ‘Z’ state) is generally discouraged for hardware synthesis. This is a critical distinction between simulation and actual hardware implementation.¹⁰

Inside a typical FPGA or ASIC, there are generally no true tri-state signals available for internal routing, except for the dedicated I/O pins that interface with the external world. When a designer attempts to describe internal logic using tri-state behavior (e.g., by assigning ‘Z’ to an internal signal), synthesis tools will translate this into equivalent combinatorial logic, most commonly an array of multiplexers (MUXes). This conversion can lead to an increase in logic area utilization and potentially slower timing performance compared to designs that explicitly use MUXes from the outset.²¹

It is also important to differentiate between signal assignments within a single sequential process and assignments from multiple concurrent processes. If a signal is assigned multiple times within the same sequential process, VHDL’s semantics dictate that the last assignment in the sequence “wins” and determines the signal’s value. However, if a signal is assigned concurrently from two different processes (or concurrent statements), it constitutes a conflict unless the signal’s type is explicitly resolved.¹⁰

Limitations of Custom Resolution Functions for Synthesis

Synthesis tools exhibit significant limitations when it comes to supporting custom resolution functions. Most commercial tools only support a very specific and limited subset of resolution logic, typically restricted to simple wired AND, wired OR, and three-state functions.⁴

Arbitrary resolution functions—those implementing complex logic beyond basic AND/OR/tri-state behavior—are generally not supported for direct synthesis into hardware. In such cases, the VHDL function body, while parsed for correct syntax, is often ignored by the synthesizer during hardware generation.¹⁴ This fundamental difference means that a custom resolution function that simulates perfectly and accurately reflects complex logical interactions might not synthesize correctly, efficiently, or even at all into physical hardware.⁴

For the limited set of synthesizable resolution functions (like wired AND/OR/three-state), synthesis tools frequently rely on special directives (e.g., synopsys resolution_method wired_and) embedded in the VHDL code rather than interpreting the VHDL function body itself. These directives explicitly instruct the synthesis tool on how to infer the desired hardware behavior. This implies that the VHDL code for the resolution function primarily serves for simulation purposes, while the directive guides the synthesis tool in generating the hardware.¹⁴

Potential Simulation-Synthesis Mismatches and Debugging Challenges

A significant pitfall in using resolved signals, particularly with custom resolution logic or internal tri-states, is the potential for simulation results (pre-synthesis behavioral simulation) to diverge from post-synthesis (RTL or gate-level) simulation results. This mismatch occurs if the resolution function’s behavior used by the simulator does not precisely align with the hardware inferred by the synthesizer based on directives or its internal interpretation.¹⁴

Debugging issues stemming from internal tri-states can be exceptionally challenging due to this inherent disparity between how VHDL models tri-state behavior and how it is physically implemented in FPGA or ASIC fabric. The fundamental mismatch between the behavioral RTL description and the resulting netlist complicates fault isolation and verification.³⁰ Synthesis tools are designed to issue warnings if they detect potential behavioral differences or if undesirable hardware structures like latches are inferred unintentionally. These warnings should never be ignored; they are critical indicators of potential problems and should be thoroughly investigated.³⁷

The repeated emphasis on the limitations of synthesis, especially concerning arbitrary resolution logic and internal tri-states, highlights a core concept in hardware description languages: VHDL is fundamentally a description language, not merely a programming language. What can be accurately described and simulated in VHDL (e.g., highly complex or arbitrary resolution logic) is not necessarily what can be directly synthesized into efficient physical hardware. The aspect where the function body is ignored by the synthesizer for certain constructs is a stark illustration of this. This underscores a critical learning point for designers: always consider the underlying hardware implications when writing VHDL, particularly when targeting synthesis.

The explicit statements that internal tri-states are generally replaced by multiplexers during synthesis have direct and significant implications for hardware performance and area.²¹ Multiplexers, while functional, consume more logic gates and routing resources than a direct wire, which can lead to an increase in chip area and a greater propagation delay. This causal relationship—where a tri-state model in VHDL leads to mux inference, which then impacts performance and area—is a primary reason why internal tri-states are generally discouraged. It compels the designer to consider the physical realization of their design and its associated costs, beyond just the logical behavior.

Furthermore, the “fundamental mismatch between simulation and synthesis” and the resulting difficulties in debugging when using internal tri-states indicate a significant downstream impact on the design flow.³⁰ If the simulated behavior does not precisely match the synthesized hardware, debugging becomes exponentially more challenging, leading to substantial waste of valuable design time. This reinforces that “proper” usage of VHDL extends beyond mere syntax; it encompasses writing code that is predictable and debuggable throughout the entire design and verification process.

Common VHDL Coding Errors Related to Signal Assignments

Several common VHDL coding errors can arise, particularly concerning signal assignments, which can impact both simulation accuracy and synthesizability:

• Multiple Assignments in Concurrent Section: If a signal is assigned multiple times in the concurrent section of an architecture (outside of a process) and it is not a resolved signal, this constitutes an error. VHDL requires concurrent assignments to non-resolved signals to be unique.³¹
• Unintentional Latch Inference: A frequent pitfall is inadvertently inferring latches. This occurs when a signal or variable is not assigned a value in all possible branches of an if statement or a case statement. If the intention is not to create a latch (which is generally undesirable in synchronous designs), then the signal or variable must be explicitly assigned a value in every possible branch.³³
• Incomplete Sensitivity Lists: For processes that describe combinatorial logic, failing to include all right-hand-side signals in the process’s sensitivity list can lead to simulation-synthesis mismatches. The simulator might not re-evaluate the process when an input changes, leading to incorrect behavior compared to the synthesized hardware.³⁷

7. Best Practices and Alternatives for Internal Buses

When to Use Resolved Signals

Resolved signals are an indispensable feature of VHDL for accurately modeling external interfaces, particularly those involving shared buses. In these scenarios, multiple physical devices can drive the same line, and the concept of a high-impedance (‘Z’) state is critical for proper operation.⁸ Examples include parallel data buses, and serial interfaces like I2C or SPI when operating in a multi-drop configuration.

They are also highly useful for accurately simulating bidirectional I/O pins, where the direction of data flow dynamically changes. The resolved nature of types like std_logic allows for a clear and concise description of how a single pin can act as both an input and an output.¹⁰

Furthermore, for specific bus protocols that inherently define their own resolution logic (e.g., wired-AND or wired-OR logic, where the bus behavior is a logical AND or OR of all active drivers), resolved types provide a direct and clear way to model this behavior in VHDL, ensuring simulation accuracy.¹⁴

When to Prefer Alternatives Like Multiplexers for Internal Bus Arbitration

For internal buses within the confines of an FPGA or ASIC fabric, it is almost universally preferable to utilize explicit multiplexers (MUXes) rather than relying on internal tri-state logic inferred from resolved signals. This recommendation stems from several critical hardware implications.²¹

FPGAs, for instance, do not possess true internal tri-state buffers for general routing. Instead, when tri-state behavior is described for an internal signal, the synthesis tools will implement this functionality using MUXes. This implicit conversion can lead to less optimal area utilization, increased propagation delays, and higher power consumption compared to designs where MUX structures are explicitly coded and optimized by the designer.²¹

Explicit MUXes contribute significantly to clearer design intent, making the code easier to understand, manage, and debug. This direct approach generally results in more predictable and often better optimized synthesized hardware, as the synthesis tool has a clearer path to implementation.²¹

For scenarios involving bus arbitration for internal shared resources (such as common memory blocks or shared peripherals), the best practice is to explicitly design bus arbiters. These arbiters are responsible for granting access to the shared resource to only one master at a time and typically employ MUXes to select the active master’s data or control signals to be placed on the shared bus.⁴⁰

Comparison: Tri-state vs. Multiplexer for Internal FPGA/ASIC Buses

Understanding the trade-offs between using inferred internal tri-state logic and explicit multiplexers is crucial for optimizing digital designs.

Table 3: Comparison: Internal Bus Implementation (Multiplexer vs. Tri-state)

This table provides a direct, side-by-side comparison of the two primary approaches for implementing shared buses. It distills the complex trade-offs into an easily digestible format, highlighting the practical implications for hardware design. This comparison is critical for guiding designers on when not to use internal tri-states and why, directly addressing the proper use of resolved signals in a practical design context.

The repeated warnings against internal tri-states leading to the inference of MUXes highlight a common “hidden” hardware implication.²¹ Designers might write seemingly simple VHDL code, but the synthesis tool, in its effort to implement the specified behavior, may create complex and potentially suboptimal MUX trees. This is a crucial understanding for proper VHDL usage: it is essential to comprehend what hardware your code

implies, not just what it explicitly states.

The inherent difficulty in debugging internal tri-states further reinforces a broader best practice: the importance of writing debuggable VHDL.³⁰ Complex, implicit hardware structures make it significantly harder to trace signals and understand behavior during both simulation and on the actual hardware. This emphasizes that effective VHDL design encompasses not only functionality and synthesizability but also maintainability and efficient verification, which are critical aspects of professional hardware development.

General VHDL Coding Best Practices for Robust and Synthesizable Designs

Beyond the specific considerations for resolved signals, adhering to general VHDL coding best practices is crucial for developing robust, synthesizable, and maintainable digital designs:

• Meaningful Names: Use clear, descriptive names for entities, architectures, signals, and processes (e.g., i_xyz for inputs, o_xyz for outputs). This greatly improves code readability and understanding.⁵
• Packages: Leverage VHDL packages to group related declarations (types, functions, components) and promote code reusability and maintainability across larger codebases.²⁵
• Generics: Utilize generics to create configurable and reusable design blocks, allowing for flexible specification of parameters like bus widths or memory depths.²⁵
• Explicit Port Mapping: Always use explicit port mapping when instantiating components. This makes connections clear and less prone to errors compared to positional mapping.⁵
• Avoid Latches: Prevent unintentional latch inference by ensuring that all signals and variables are assigned a value in every possible branch of if or case statements. Latches can introduce unpredictable behavior and timing issues in synchronous designs.³³
• No Clock Gating: Instead of gating clocks (which can lead to clock skew and timing problems), use enable signals to control data flow to registers. This provides better control and more reliable synchronous behavior.⁵
• Synchronous Design: Favor synchronous design principles, utilizing edge-triggered flip-flops for most internal logic. This simplifies timing analysis and improves design reliability.³³
• Signal vs. Variable Usage: Clearly understand the distinction: signals represent physical hardware connections and are updated after a delay, while variables are for immediate calculations within a process and should not be used to carry state between clock cycles.⁵
• Use std_logic for I/O: std_logic and std_logic_vector are the standard types for I/O ports. For internal arithmetic operations, use unsigned or signed types from IEEE.numeric_std.⁵
• Complete Sensitivity Lists: Ensure that all signals read within a combinatorial process are included in its sensitivity list. An incomplete list can lead to simulation mismatches and incorrect hardware inference.³⁷
• Avoid wait Statements for Synthesis: For synthesizable code, avoid wait statements, except for the wait until clock’event and clock = ‘1’ construct at the beginning of a clocked process. Other forms of wait are generally not synthesizable.³³
• Modular Design: Break down complex logic, such as Finite State Machines (FSMs), into smaller, manageable, and testable sections. This improves design clarity and facilitates concurrent development.⁵
• Rethink Poor Code: If synthesis tools struggle to meet timing or area goals, or generate excessive warnings, it is often more effective to rewrite the VHDL code with a clearer hardware intent rather than forcing tool optimizations.³³

8. Debugging Resolved Signal Issues

Strategies for Identifying and Resolving Issues Related to Resolved Signals in Simulation

Debugging VHDL designs, especially those involving resolved signals, requires systematic approaches to identify and rectify issues.

• Waveform Viewer (Logic Analyzer): The most effective and common method for debugging VHDL simulations is to utilize a waveform viewer (e.g., ModelSim, Questa, GTKWave). This tool allows designers to “dump” the simulation trace, providing a cycle-by-cycle visualization of signal values over time. Critically, these viewers can display the full range of std_ulogic states, including ‘U’ (Uninitialized), ‘X’ (Forcing Unknown), and ‘Z’ (High Impedance), which are essential for diagnosing resolution problems and bus contention.³⁹
• Print Statements (TEXTIO): For initial debugging or to inspect signal values at specific points within procedural code, TEXTIO functions like writeline can be used to print signal values to the simulator console. While less comprehensive than waveform viewers, this can be a quick way to check expected values at certain execution points.³⁹
• Robust Testbenches: A well-designed and comprehensive testbench is indispensable for verifying VHDL designs. It provides controlled input stimuli and allows for automated comparison of actual outputs against expected outputs. This helps to pinpoint precisely where resolution logic might be behaving unexpectedly or where bus contention is occurring.³⁹
• Complete Sensitivity Lists: During simulation, ensure that all processes describing combinatorial logic have complete sensitivity lists. If a signal on the right-hand side of an assignment within a process is not included in the sensitivity list, the simulator might not re-evaluate the process when that signal changes, leading to incorrect simulation behavior that could mask underlying issues or create mismatches with synthesized hardware.³⁷
• Optimization Settings: When debugging, it is often advisable to temporarily turn off optimization settings in the VHDL simulator. This ensures that internal variables within processes are not optimized away and that signals can be forced or read, providing a more transparent view of the design’s internal state.³⁸

Understanding Synthesis Warnings and Error Messages

Synthesis tools provide invaluable feedback through warnings and error messages. Understanding and addressing these messages is paramount for successful hardware implementation.

• “Nonresolved signal has multiple sources” Error: This is a direct and critical error message indicating that an unresolved signal is being driven by more than one source. This is an illegal condition in VHDL. The immediate solution is either to restructure the design to guarantee that only one driver is active at any given time, or, if multiple drivers are indeed intended, to change the signal’s type to a resolved type (e.g., std_logic).¹⁰
• Warnings About Latches: Synthesis tools frequently issue warnings when latches are inferred unintentionally. This typically occurs if a signal or variable is not assigned a value in all possible branches of a conditional statement (e.g., an if-else or case statement). Latches are generally undesirable in synchronous designs as they can lead to unpredictable behavior, race conditions, and timing issues. These warnings must be addressed by ensuring all paths assign a value.³³
• Synthesis-Specific Warnings: Pay close attention to all warnings generated by the synthesis tool, even if the compilation process completes without outright errors. These warnings often highlight potential discrepancies between the simulated behavior and the expected synthesized hardware, or indicate non-optimal implementations that could impact performance or area.³⁷
• Error #8: Multiple Assignments in the Concurrent Section: This specific error indicates that a signal is being assigned values multiple times concurrently (outside of a process) when it is not a resolved signal. This violates VHDL’s rules for concurrent signal assignments.³¹

The fact that unresolved types generate explicit errors when multiple drivers are present serves as a proactive debugging mechanism built directly into the VHDL language.¹⁰ Instead of silently resolving to an ‘X’ or ‘U’ state, which can be difficult to trace and diagnose within a large waveform, the tool explicitly flags the underlying design flaw. This implies that the choice of signal type—using

std_ulogic when a single driver is intended, or std_logic when multiple drivers are explicitly desired and managed—is itself a fundamental debugging strategy, guiding the designer toward more robust and predictable code.

The consistent advice to “take warnings seriously” and to “understand each warning as it occurs” reinforces a crucial debugging philosophy.³⁷ Warnings are not merely informational noise; they are the synthesis tool’s way of communicating that the VHDL code might not translate to hardware as expected, or that there are potential issues that could lead to functional or performance problems. Ignoring these warnings, particularly in the context of resolved signals where simulation/synthesis mismatches are common, is a recipe for encountering hard-to-find bugs in the final hardware. This emphasizes the iterative nature of HDL design and the critical importance of actively engaging with and responding to feedback from design tools.

9. Conclusion

Resolved signals are a powerful and fundamental feature within VHDL, providing the necessary mechanisms to accurately model complex digital hardware interactions. Their proper utilization is key to developing robust and predictable designs.

Summary of Key Takeaways for Proper Usage of Resolved Signals

• Modeling Shared Resources: Resolved signals are indispensable for accurately modeling shared resources with multiple drivers, particularly external buses and bidirectional I/O pins. They achieve this by defining how conflicting values from multiple sources are combined into a single, unambiguous value.
• Industry Standard: The std_logic type from the IEEE.std_logic_1164 package has become the de facto industry standard. This is primarily due to its built-in resolution function (resolved) and its comprehensive 9-valued logic system, which effectively handles critical states such as high-impedance (‘Z’) and unknown (‘X’).
• Custom Resolution Functions: While VHDL allows for the implementation of custom resolution functions for specialized bus behaviors, their synthesizability is generally limited. Most synthesis tools only support basic wired-AND, wired-OR, or three-state logic, often requiring specific synthesis tool directives rather than relying on the VHDL function body itself.
• Internal vs. External Buses: For internal FPGA/ASIC logic, explicit multiplexers (MUXes) are generally preferred over inferred tri-state logic (which arises from using resolved signals for internal buses). This preference is driven by the desire for better control over area, timing, and power consumption, as well as improved debuggability.

Final Recommendations for Effective VHDL Design

To effectively leverage VHDL and ensure robust, synthesizable designs, designers should adopt the following recommendations:

• Be Intentional in Signal Type Choice: Explicitly decide whether a signal requires resolution. If multiple drivers are not intended for a signal, use unresolved types (like std_ulogic) to proactively catch errors early in the design cycle. Conversely, if multiple drivers are intended, use resolved types (like std_logic) and ensure that proper arbitration logic is meticulously designed and implemented to manage contention. This intentional approach to signal typing is not merely a syntactic choice but a fundamental architectural decision that profoundly impacts hardware performance, area, and debuggability.
• Always Think Hardware: It is crucial to constantly consider how your VHDL code will translate into physical gates and interconnections on the target hardware. What might simulate perfectly in a behavioral model may not synthesize optimally, or even at all, into a physical circuit. VHDL is a descriptive language, and understanding its hardware implications is paramount.
• Prioritize Clarity and Maintainability: Employ VHDL’s features to enhance code clarity and maintainability. This includes using packages for modularity, generics for reusability, and meaningful names for all design elements. Avoid implicit logic that can lead to unexpected synthesis results or make debugging efforts significantly more challenging.
• Heed Warnings Seriously: Treat all synthesis warnings as critical clues. They are invaluable indicators of potential issues or non-optimal hardware implementations. Ignoring them can lead to hard-to-find bugs in the final hardware, emphasizing the importance of active engagement with tool feedback.
• Leverage Simulation Comprehensively: Utilize comprehensive testbenches and waveform viewers to thoroughly verify the behavior of all signals, especially resolved signals. Given the potential for simulation-synthesis mismatches, rigorous simulation is essential to validate the design’s functionality before committing to hardware.

Beyond merely describing hardware for synthesis, VHDL code, particularly when adhering to these best practices and clearly indicating design intent (e.g., using std_logic for external buses, employing explicit MUXes for internal arbitration), evolves into a powerful communication tool. It effectively conveys the design’s behavior and architectural choices to other engineers, to verification teams, and implicitly to the synthesis tools themselves. This underscores the human element in HDL design and highlights the long-term benefits of producing clear, robust, and well-documented code for complex digital systems.

Works cited

1. Lesson four: VHDL signals - PLDWorld.com, accessed July 9, 2025, http://www.pldworld.com/_hdl/1/www.ireste.fr/fdl/vcl/lesd/les_4.htm
2. VHDL Tutorial, accessed July 9, 2025, https://course.ccs.neu.edu/cs3650/ssl/TEXT-CD/Content/Tutorials/VHDL/vhdl-tutorial.pdf
3. FREE RANGE VHDL, accessed July 9, 2025, https://faculty-web.msoe.edu/johnsontimoj/EE3921/files3921/Book_FreeRangeVHDL.pdf
4. VHDL Language Reference - Altium, accessed July 9, 2025, https://valhalla.altium.com/Learning-Guides/TR0114%20VHDL%20Language%20Reference.pdf
5. VHDL Best Practices, accessed July 9, 2025, https://faculty-web.msoe.edu/johnsontimoj/Common/FILES/vhdl_best_practices.pdf
6. VHDL: Why is output delayed so much? - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/28484456/vhdl-why-is-output-delayed-so-much
7. VHDL Resolution and Signatures - UMBC, accessed July 9, 2025, https://portal.cs.umbc.edu/help/VHDL/misc.html
8. Resolution Function - VHDL - Peter F, accessed July 9, 2025, https://peterfab.com/ref/vhdl/vhdl_renerta/mobile/source/vhd00058.htm
9. Chapter 15: Resolved Signals | GlobalSpec, accessed July 9, 2025, https://www.globalspec.com/reference/26692/203279/chapter-15-resolved-signals
10. Help!! : r/VHDL - Reddit, accessed July 9, 2025, https://www.reddit.com/r/VHDL/comments/gwdv6x/help/
11. Resolved Signals - ResearchGate, accessed July 9, 2025, https://www.researchgate.net/publication/301187953_Resolved_Signals
12. Assign signal in many processes - vhdl - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/54269172/assign-signal-in-many-processes
13. VHDL Online Help - Resolution Function - vhdl.renerta.com - Peter F, accessed July 9, 2025, https://peterfab.com/ref/vhdl/vhdl_renerta/source/vhd00058.htm
14. Resolution Functions, accessed July 9, 2025, http://www1.pldworld.com/@xilinx/html/technote/TOOL/MANUAL/21i_doc/data/fndtn/vhd/vhd2_5.htm
15. VHDL Reference Guide - Functions, accessed July 9, 2025, https://ics.uci.edu/~jmoorkan/vhdlref/function.html
16. Resolved vs. Unresolved standard logic, and when to get away with using each, accessed July 9, 2025, https://groups.google.com/g/comp.lang.vhdl/c/3VK4ydnMn5w
17. Unresolved types — hdl-modules documentation, accessed July 9, 2025, https://hdl-modules.com/unresolved_types.html
18. Std_logic_1164 Package - HDL Works, accessed July 9, 2025, https://www.hdlworks.com/hdl_corner/vhdl_ref/VHDLContents/StdLogic1164.htm
19. VHDL - Std_Logic_1164 Package - Peter F, accessed July 9, 2025, https://peterfab.com/ref/vhdl/vhdl_renerta/mobile/source/vhd00068.htm
20. Three State Devices, IC74x541, IC74x245 and VHDL Programming - VLSI Design, accessed July 9, 2025, http://vlsi-design-engineers.blogspot.com/2015/09/three-state-devices-ic74x541-ic74x245.html
21. fpga - Using signal in different modules vhdl - Electrical Engineering …, accessed July 9, 2025, https://electronics.stackexchange.com/questions/55984/using-signal-in-different-modules-vhdl
22. How does a wired AND/OR bus work? - Electrical Engineering Stack Exchange, accessed July 9, 2025, https://electronics.stackexchange.com/questions/14327/how-does-a-wired-and-or-bus-work
23. How do I implement a tri-state buffer for a vector in VHDL …, accessed July 9, 2025, https://electronics.stackexchange.com/questions/178874/how-do-i-implement-a-tri-state-buffer-for-a-vector-in-vhdl
24. 9.4. User-defined types - YouTube, accessed July 9, 2025, https://www.youtube.com/watch?v=0k9J0NF7lgA
25. Any general tips to write cleaner or more understandable VHDL code : r/FPGA - Reddit, accessed July 9, 2025, https://www.reddit.com/r/FPGA/comments/1b1k1n7/any_general_tips_to_write_cleaner_or_more/
26. Three-state logic - Wikipedia, accessed July 9, 2025, https://en.wikipedia.org/wiki/Three-state_logic
27. VHDL - Registers on bidirectional data bus - Adaptive Support - AMD, accessed July 9, 2025, https://adaptivesupport.amd.com/s/question/0D52E00006hpO6GSAU/vhdl-registers-on-bidirectional-data-bus?language=en_US
28. Synthesisable TristateSignal - MyHDL, accessed July 9, 2025, https://discourse.myhdl.org/t/synthesisable-tristatesignal/216
29. Which is better bus style tri-state or mux ? | Forum for Electronics, accessed July 9, 2025, https://www.edaboard.com/threads/which-is-better-bus-style-tri-state-or-mux.3990/
30. Internal tri-states : r/FPGA - Reddit, accessed July 9, 2025, https://www.reddit.com/r/FPGA/comments/49fzv2/internal_tristates/
31. Top 10 Common VHDL Coding Errors and How to Fix Them - FPGATEK, accessed July 9, 2025, https://fpgatek.com/vhdl-coding-errors/
32. Using functions in VHDL for synthesis - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/29037842/using-functions-in-vhdl-for-synthesis
33. VHDL GUIDELINES FOR SYNTHESIS, accessed July 9, 2025, http://web02.gonzaga.edu/faculty/talarico/ee406/20162017/VHDL/vhdl-for-synthesis.pdf
34. Synthesis from VHDL Outline General assumptions, accessed July 9, 2025, https://fileadmin.cs.lth.se/cs/Education/EDAN15/Lectures/Lecture4.pdf
35. VHDL Reference Manual, accessed July 9, 2025, https://staff.fysik.su.se/~silver/digsyst/vhdl_ref.pdf
36. VHDL Simulation vs. Synthesis, accessed July 9, 2025, https://people.sabanciuniv.edu/erkays/el310/SimSyn_03.pdf
37. state machine - VHDL - synthesis results is not the same as behavioral - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/34694224/vhdl-synthesis-results-is-not-the-same-as-behavioral
38. The Golden Rules of Debugging - Doulos, accessed July 9, 2025, https://www.doulos.com/knowhow/fpga/the-golden-rules-of-debugging/
39. Debugging VHDL: How to? - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/5468602/debugging-vhdl-how-to
40. VHDL 4 to 1 MUX (Multiplexer) - Invent Logics, accessed July 9, 2025, https://allaboutfpga.com/vhdl-4-to-1-mux-multiplexer/
41. VHDL: muxes between 11 buses 8 bits wide output - Stack Overflow, accessed July 9, 2025, https://stackoverflow.com/questions/40657489/vhdl-muxes-between-11-buses-8-bits-wide-output
42. VHDL arbiter - Hackster.io, accessed July 9, 2025, https://www.hackster.io/chclau/vhdl-arbiter-225c8a
43. VHDL Implementation of PCI Bus Arbiter Using Arbitration Algorithms - ResearchGate, accessed July 9, 2025, https://www.researchgate.net/publication/221225865_VHDL_Implementation_of_PCI_Bus_Arbiter_Using_Arbitration_Algorithms