what is the difference between the types std_logic and std_u

[parag_paul@hotmail.com]

I am working on finding out the nature of debug implementation on the
VHDL data types. Currently I am trying to see the force implementation
on various data types and the extent to which the simulators are
behaving correctly.
Can you please tell me the diff between the std_ulogic and std_logic
data types
-Parag

 

[KJ]

On Sep 21, 7:11 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

I am working on finding out the nature of debug implementation on the
VHDL data types. Currently I am trying to see the force implementation
on various data types and the extent to which the simulators are
behaving correctly.
Can you please tell me the diff between the std_ulogic and std_logic
data types
-Parag

std_logic is derived from std_ulogic. Specifically it is a 'resolved'
std_ulogic. In VHDL, if a data type (i.e. std_ulogic) does not have a
function defined for it called 'resolved' than if you have two or more
drivers for a signal, the compiler will complain. Example:

a <= '1';
a <= '1' or '0';

If signal 'a' is of type std_ulogic, then any compiler will
immediately flag this code as an error, you won't need to simulate to
find it (in fact the simulator won't even let you get started).

Since std_logic is defined to be a 'resolved' std_ulogic type in the
IEEE std_logic_1164 package, this implies that there is a function
called 'resolved' in that package that will decide what the final
outcome is when two or more drivers drive the same signal (and trust
me, such a function is there). It is not a compiler error, whether it
is a design error or not depends on the design itself. If signal 'a'
in the above example had been declared to be of type std_logic then
the compiler would not complain about this since std_logic types are
allowed to have multiple drivers (by virtue of the std_logic type
being defined to have a 'resolved' function).

It is permissable to define your own basic types and then derive yet
more types that are 'resolved' versions of the basic type if you want,
there is nothing magic there. If you peruse the source listing for
the IEEE std_logic_1164 package you can see for yourself what is
required. In practice though, being able to define your own resolved
types does not come up very often.

Kevin Jennings

 

[Paul Uiterlinden]

parag_paul@hotmail.com wrote:

I am working on finding out the nature of debug implementation on the
VHDL data types. Currently I am trying to see the force implementation
on various data types and the extent to which the simulators are
behaving correctly.
Can you please tell me the diff between the std_ulogic and std_logic
data types
-Parag

std_logic is a subtype from std_ulogic. What it adds is a resolution
function. So std_logic is a resolved type. A resolved type permits multiple
drivers on a signal. An unresolved type (like std_ulogic) does not permit
multiple drivers. This is detected during analysis and will result in an
error.

A driver for a signal exists for each process that has a signal assignment
on that signal. A common use of multiple drivers is a bus. To be really
usefull, only one driver should apply a strong value (e.g. '0' or '1')
while the others apply a weak value (amongst others 'L', 'H' and 'Z'). The
resolution function determines the actual value that will be assigning to
the signal. A strong value will win from a weak value. So if there are two
drivers driving '1' and 'Z', the resulting value will be '1'. A '0' and
a '1' will result in an 'X'. See the resolution table below for all other
combinations.

Given that std_logic is a subtype of std_ulogic, std_logic and std_ulogic
may be mixed without the need of any conversion.

Given furthermore that a multiple driver results in an error during
analysis, my advice is to use std_ulogic for all those cases where multiple
drivers are not needed. There are not drawbacks, only the bonus of getting
an early error message in the case that you inadvertently have created
multiple drivers. In stead of chasing an 'X' in simulation, you get a neat
error message during analysis.

Alas std_logic_vector and std_ulogic_vector are distinct types. So these
cannot be mixed freely. There my advice is to stick to std_logic_vector,
because it is commonly used in existing code.


Below are the relevant parts from the IEEE packages.

From package ieee.std_logic_1164:

-------------------------------------------------------------------
-- 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
);
-------------------------------------------------------------------
-- unconstrained array of std_ulogic for use with the resolution function
-------------------------------------------------------------------
TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;

-------------------------------------------------------------------
-- resolution function
-------------------------------------------------------------------
FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic;



From the package body ieee.std_logic_1164:

-------------------------------------------------------------------
-- resolution function
-------------------------------------------------------------------
CONSTANT resolution_table : stdlogic_table := (
-- ---------------------------------------------------------
-- | U X 0 1 Z W L H - | |
-- ---------------------------------------------------------
( 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U' ), -- | U |
( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ), -- | X |
( 'U', 'X', '0', 'X', '0', '0', '0', '0', 'X' ), -- | 0 |
( 'U', 'X', 'X', '1', '1', '1', '1', '1', 'X' ), -- | 1 |
( 'U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X' ), -- | Z |
( 'U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X' ), -- | W |
( 'U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X' ), -- | L |
( 'U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X' ), -- | H |
( 'U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X' ) -- | - |
);

FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic IS
VARIABLE result : std_ulogic := 'Z'; -- weakest state default
BEGIN
-- the test for a single driver is essential otherwise the
-- loop would return 'X' for a single driver of '-' and that
-- would conflict with the value of a single driver unresolved
-- signal.
IF (s'LENGTH = 1) THEN RETURN s(s'LOW);
ELSE
FOR i IN s'RANGE LOOP
result := resolution_table(result, s(i));
END LOOP;
END IF;
RETURN result;
END resolved;

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

 

On Sep 21, 4:11 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

I am working on finding out the nature of debug implementation on the
VHDL data types. Currently I am trying to see the force implementation
on various data types and the extent to which the simulators are
behaving correctly.
Can you please tell me the diff between the std_ulogic and std_logic
data types
-Parag

In std_logic_1164.vhdl:


-------------------------------------------------------------------
-- *** industry standard logic type ***

-------------------------------------------------------------------
SUBTYPE std_logic IS resolved std_ulogic;


Because it is a resolved type, it can have more than one driver.

That is why std_ulogic is preferred for synthesized code.

G.

 

[Andy Peters]

On Sep 21, 4:11 am, "parag_p...@hotmail.com" <parag_p...@hotmail.com>
wrote:

I am working on finding out the nature of debug implementation on the
VHDL data types. Currently I am trying to see the force implementation
on various data types and the extent to which the simulators are
behaving correctly.
Can you please tell me the diff between the std_ulogic and std_logic
data types

Every basic VHDL book has a section that discusses this very topic.

-a