what is the difference between the types std_logic and std_ulogic

P

parag_paul

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
 
K

KJ

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
 
P

Paul Uiterlinden

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;
 
G

ghelbig

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.
 
A

Andy Peters

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
 
Joined
Feb 25, 2010
Messages
38
Reaction score
0
hope this helps..
vhdlguru.blogspot.com/2010/03/what-is-difference-between-stdlogic-and.html
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,754
Messages
2,569,522
Members
44,995
Latest member
PinupduzSap

Latest Threads

Top