9
\$\begingroup\$

Whats the difference between using:

ENTITY MyDemo is 
    PORT(X: IN STD_LOGIC; F: OUT STD_LOGIC );
END MyDemo; 

and

ENTITY MyDemo is 
    PORT(X: IN BIT; F: OUT BIT );
END MyDemo; 

What are the limitations of using BIT over STD_LOGIC and vice-versa? Are they completely interchange able? I understand that if I've define STD_LOGIC I can't use it with a BIT_Vector to access the elements in the array. But I can't seem to see the difference.

\$\endgroup\$
9
\$\begingroup\$

Bit is a predefined type and only can only have the value 0 or 1. The Bit type is an idealized value.

type Bit is ('0', '1');

std_logic is part of the std_logic_1164 package and provides more realistic modeling of signals within a digital system. It is capable of having nine different values. Typically within your code you will only use 0, 1, and Z (High-Z). But U (Uninitialized) and X (Unknown) are also very useful when modeling the system in a testbench.

    -------------------------------------------------------------------    
    -- logic state system  (unresolved)
    -------------------------------------------------------------------    
    TYPE std_ulogic IS ( 'U',  -- Uninitialized
                         'X',  -- Forcing  Unknown
                         '0',  -- Forcing  0
                         '1',  -- Forcing  1
                         'Z',  -- High Impedance   
                         'W',  -- Weak     Unknown
                         'L',  -- Weak     0       
                         'H',  -- Weak     1       
                         '-'   -- Don't care
                       );

--    attribute ENUM_ENCODING of std_ulogic : type is "U D 0 1 Z D 0 1 D";

    -------------------------------------------------------------------    
    -- *** industry standard logic type ***
    -------------------------------------------------------------------    
    SUBTYPE std_logic IS resolved std_ulogic;

The std_logic_1164 package also provides conversion functions to convert std_logic to Bit.

\$\endgroup\$
5
\$\begingroup\$

Most people use std_logic. That allows for u (undefined), x (unknown) and z (high impedance), which bit doesn't. While you may never tristate in a chip and therefore don't need z, u is useful for finding missing resets. x is useful for finding multiple drivers.

\$\endgroup\$
  • 7
    \$\begingroup\$ I think it's funny that you mention the usefulness of X for finding multiple drivers. std_logic is indeed the industry standard type for VHDL, but it is also on of the most misused feature of VHDL. std_logic is a resolved signal, which mean that a function is used to resolve the value of the signal in case of multiple drivers. But in the vast majority of cases multiple drivers is an error. By using an unresolved type such as std_ulogic this would be marked by the compiler as an error. \$\endgroup\$ – trondd Dec 20 '12 at 19:16
  • \$\begingroup\$ @trondd: Good point about std_ulogic. But keep in mind many cores will be written with std_logic so you will likely see some of it. \$\endgroup\$ – Brian Carlton Dec 20 '12 at 19:29
  • 1
    \$\begingroup\$ std_logic is indeed the most common type around; I'm just arguing that it's use is not according to the original intention: Modeling of multi-state signals. For internal designs we usually only consider 1 or 0 and a single driver. See electronics.stackexchange.com/questions/17524/… for a thorough discussion on the topic. \$\endgroup\$ – trondd Dec 24 '12 at 7:33
5
\$\begingroup\$

std_logic has a resolution function

Not only does std_logic have more useful states besides 1 and 0, it also has a resolution function defined.

A resolution function is a VHDL language concept. It is a function that is associated to a type, and it determines what happens when multiple values of that type are applied to a single signal. The syntax is:

SUBTYPE std_logic IS resolved std_ulogic;

where std_ulogic is the unresolved (and thus much less useful) version of std_logic.

In particular, this implies nice things like 0 and 1 leads to X:

library ieee;
use ieee.std_logic_1164.all;

entity std_logic_tb is
end std_logic_tb;

architecture behav of std_logic_tb is
    signal s0 : std_logic;
begin
    s0 <= '0';
    s0 <= '1';
    process
    begin
        wait for 1 ns;
        assert s0 = 'X';
        wait;
    end process;
end behav;

This makes intuitive sense, as we understand X to be the state where multiple incompatible values are applied to a single wire.

std_logic also knows how to resolve every other possible pair of input signals according to a table present on the LRM.

bit on the other hand, does not have a resolution function, and if we had used it on the above example, it would lead to a simulation error on GHDL 0.34.

The possible values of std_logic are a good choice because they are standardized by IEEE 1164 and deal with many common use cases.

\$\endgroup\$
0
\$\begingroup\$

std_logic is richer than bit, and should basically be used most of the time.

There is also the boolean type, which, like bit, has two values. It is the result type of comparisons, the type expected after an IF [bool] or a WHEN [bool], often used for selection constants : constant ENABLE_DEBUG_INTERFACE : boolean := true;

One place where bit can be preferred to std_logic is for large arrays, memories. On optimizing simulators, bit occupies less area in the simulator's memory than std_logic. And it may matter if your design instantiates one GB of RAM.

It can also be faster for very large designs, for example something automatically generated from post-synthesis gate-level netlist.

Of course, this performance aspect is not part of the language, and depends on the implementation of the VHDL simulator.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.