Outputting Don’t Care States in Hardware Simulation: A Practical Guide

In digital logic design, leveraging “Don’t Care” conditions is crucial for optimizing logic functions. Techniques like Karnaugh maps and the Quine–McCluskey algorithm highlight how “Don’t Care” states can simplify circuits, leading to more efficient hardware implementations. Consider a register file: when the write_enable signal is inactive ('0'), the write_address and write_data inputs become irrelevant. Assigning “Don’t Care” values to these signals in such scenarios provides synthesis tools with greater flexibility for optimization, particularly in the logic driving these signals, rather than within the register file itself.

But how do you effectively specify these “Don’t Care” values in VHDL during hardware simulation programming to unlock these optimization opportunities? Several approaches might seem viable, each with potential advantages and disadvantages. Let’s explore common methods and their implications.

Methods for Specifying “Don’t Care” in VHDL

1. Leaving Signals Unassigned

One seemingly straightforward approach is to simply leave signals unassigned under “Don’t Care” conditions.

Pros:

• Simplicity: It’s conceptually simple – if the value doesn’t matter, don’t assign it.
• Potential for Synthesis Inference: In some cases, synthesis tools might infer “Don’t Care” behavior from unassigned signals.

Cons:

• Simulation Issues: In many simulators, unassigned signals can default to ‘U’ (Uninitialized), which might propagate unexpectedly and not accurately represent “Don’t Care”. Furthermore, as the original article mentions, defining constants of record types often requires full specification, making it impossible to leave fields unassigned in such cases.
• Synthesis Tool Dependency: Relying on synthesis tools to infer “Don’t Care” is not always reliable or portable across different tools. It’s better to be explicit.

2. Using '-' (Don’t Care from std_logic_1164)

The std_logic_1164 package in VHDL defines '-- Don't care' as a valid logic value for std_ulogic and std_logic types. This seems like the most semantically accurate way to represent a “Don’t Care” state explicitly.

Pros:

• Semantic Correctness: '-' is specifically defined for “Don’t Care,” making the intent clear in both simulation and synthesis.
• Explicit “Don’t Care”: It directly tells both simulators and synthesis tools that the value at this point is irrelevant and can be optimized.
• VHDL Standard Value: As part of the std_logic_1164 standard, it’s universally recognized within the VHDL ecosystem.

Cons:

• Limited Real-world Usage (Historically): Despite its semantic correctness, the original article notes that '-' is not frequently encountered in common VHDL codebases (outside of VHDL-2008 case?). This might be due to historical reasons or developer habits. However, its explicit nature makes it a strong candidate for best practice.

3. Using 'X' (Forcing Unknown)

Simulators like Modelsim often use 'X' to display undefined or indeterminate signal values. While 'X' represents “forcing unknown” or “conflicting values” in the std_logic_1164 standard, it might be tempting to use it to represent “Don’t Care”.

Pros:

• Simulation Visibility: 'X' is easily visible in simulation waveforms, highlighting potentially unconstrained signals.

Cons:

• Semantic Misinterpretation: 'X' semantically means “unknown” or “conflicting,” not specifically “Don’t Care.” Synthesis tools might misinterpret an explicit 'X' assignment.
• Not Intended for “Don’t Care”: The primary purpose of 'X' is to indicate errors or unresolved logic levels, not to guide optimization.
• Potential for Synthesis Issues: Synthesis tools are likely to treat 'X' as an actual unknown value, potentially leading to pessimistic or incorrect optimizations, or even synthesis errors in some cases.

Code Example and Expected Synthesis Behavior

The following VHDL code snippet, adapted from the original article, illustrates the use of '-' to specify “Don’t Care” values:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

package mytypes is
    type control_signals_t is record
        write_enable  : std_logic;
        write_address : std_ulogic_vector(3 downto 0);
        read_address  : std_ulogic_vector(3 downto 0);
    end record;

    -- All members of this constant must be fully specified.
    -- So it's not possible to simply not assign a value.
    constant CONTROL_NOP : control_signals_t := (
        write_enable  => '0',
        write_address => (others => '-'),
        read_address  => (others => '-')
    );
end package;

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library cfx;
use cfx.mytypes.all;

entity control_unit is
    port (
        instruction : in  std_ulogic_vector(15 downto 0);
        write_data  : out std_ulogic_vector(15 downto 0);
        ctrl        : out control_signals_t
    );
end entity;

architecture rtl of control_unit is
begin
    decode_instruction : process (instruction) is
    begin
        -- Set sensible default values that do nothing.
        -- Especially all "write_enable" signals should be '0'.
        -- Everything else is mostly irrelevant (don't care).
        ctrl <= CONTROL_NOP;

        if instruction(15 downto 12) = "1100" then
            -- Load 8 bit of data into the register file
            ctrl.write_enable  <= '1';
            ctrl.write_address <= instruction(11 downto 8);
        elsif instruction(15 downto 12) = "1101" then
            -- Load 4 bit of data into register file
            ctrl.write_enable  <= '1';
            ctrl.write_address <= instruction(3 downto 0);
        end if;
    end process;

    write_data <= (others => '0'); -- Example output
end architecture;

In this example, ctrl <= CONTROL_NOP; initializes the control signals with '-' for write_address and read_address when write_enable is '0'. As the original author anticipated, with '-' interpreted as “Don’t Care,” synthesis tools should ideally optimize the logic driving control.reg_write_address. If '-' is correctly recognized, a 2-input multiplexer might suffice, selecting between instruction(11 downto 8) and instruction(3 downto 0). However, if initialized with (others => '0'), a less optimized 3-input multiplexer could be generated, as the ‘0’ default would be considered a relevant state.

Best Practices and Recommendations

For explicitly specifying “Don’t Care” states in VHDL for optimal synthesis and clear simulation intent, using '-' (the Don’t Care value from std_logic_1164) is the recommended best practice.

• Clarity and Intent: It unambiguously communicates “Don’t Care” to both simulation and synthesis tools.
• Semantic Accuracy: It aligns with the defined meaning of “Don’t Care” in digital logic design.
• Optimization Potential: It provides synthesis tools with the intended freedom to optimize logic based on “Don’t Care” conditions.

While leaving signals unassigned or using 'X' might seem like options, they carry semantic ambiguities and potential for misinterpretation by synthesis tools. Adopting '-' for “Don’t Care” promotes robust, optimized, and semantically correct VHDL code for hardware simulation and synthesis programming.