Resolution Functions
Resolution Functions
John Morris
Chung-Ang University The University of Auckland
where the blue signal line has more than one driver attached to it? (eg its a bus) How do we set up our model so that the simulator knows the rules? ie which signal overrides the others or how the signals combine together
Contending drivers
Remember that VHDL knows nothing about the IEEE 1164 rules To VHDL, the only primitive operations are those of a normal programming language
addition, subtraction, etc assignment It does distinguish between signal and variable assignment, but only with respect to the timing of assignment of new values!
ieee.std_logic_1164 is NOT part of the VHDL standard So when two std_logic values are applied to the same signal (ie wire), a VHDL simulator has to know that
1 overrides Z, U, X, H, L, 1 and 0 lead to X etc
Unresolved signals
std_ulogic is an unresolved type It is an error to define a model in which two drivers can set the value of an unresolved signal because there is no resolution function associated with the signal that can be invoked to determine which driver overrides the other It is defined simply:
TYPE std_ulogic IS (U,X,0,1,Z,W,L,H,-);
ie it is an enumerated type with possible values: U, This says nothing about the behaviour of std_ulogic signals
Their behaviour is encoded in the functions (and, or, ) that take std_ulogic arguments
Unresolved signals
On the other hand, std_logic is an resolved type
It is defined:
(see maxplus2\vhdl93\ieee\std1164.vhd)
SUBTYPE std_logic IS resolved std_ulogic; Note that there is a function definition just preceding this type:
Resolution functions
Any resolved signal (ie one that may be driven by two sources) is defined by a type that has a resolution function associated with it A resolved type is a subtype
It can resolve a conflict of multiple instances of the parent type
The name of the resolution function immediately precedes the name of the type being resolved FUNCTION resolved( s: std_ulogic_vector ) The resolution functions RETURN std_ulogic; argument is a vector of elements of the type being resolved SUBTYPE std_logic IS resolved std_ulogic;
The simulator will place the actual values to be resolved in this vector and call the resolution function eg with 3 drivers for a std_logic signal, the argument to resolved might be (Z, H, 1) which should return 1
return value is the parent type It will determine which of the values of the parent type result when the vector of signal values is applied
You will need to define a resolved integer types if your model has a bus with multiple drivers in it
You will need to have a convention for disconnecting a driver, eg setting a driver to emit 0 when its not driving the bus (where you would drive a Z with std_logic)
You can also explicitly disconnect a driver with VHDLs DISCONNECT statement
Resolution functions
2. You may have defined an abstract type You (correctly) dont want to be bothered with implementation details yet Your bus is a collection of signals (address, data, command, etc); you have a type for each one; so the bus itself is defined as a VHDL RECORD The synthesizer will eventually convert it to logic for you! Again you will need a resolution function 3.
Simulation speed
std_ulogic does not have a resolution function associated with it it should use less simulation time (ie run faster) than std_logic With std_logic, the simulator may end up checking for (or calling) the resolution function for every assignment std_ulogic is recommended wherever possible It may save simulation time std_logic is a subtype, so it is possible to convert between them whenever necessary res_signal <= std_logic(unres_signal);