VHDL Tutorial

Resolved signals and ports in VHDL
Fundamental concepts
Modelling concepts
Elements of behaviour
Elements of structure
Analysis elaboration
Lexical elements
Characters and strings 
Syntax descriptions
Constants and variables
Scalar type
Integer types
Floating point types
Time type
Enumeration types
Character types
Boolean type 
Bits type
Standard logic
Sequential statements
Case statements
Loop and exit statements
Assertion statements
Array types & array operations
Architecture bodies
Entity declarations
Behavioral descriptions 
Wait statements
Delta delays
Process statements
Conditional signal assignment 
Selected signal assigment
Structural descriptions
Library and library clauses
Procedure parameters
Signal parameters
Default values
Unconstrained array parameter
Package declarations and bodies
Subprograms in package
Use clauses
Resolved signals and subtypes
Resolved signals and ports

Parameterizing behavior
Parameterizing structure

Resolved Signals and Ports


In the previous discussion of resolved signals, we have limited ourselves to the simple case where a number of sources drive a signal.   Any input port connected to the re- solved signal gets the final resolved value as the port value.   We now look in more detail at the case of a port of mode inout being connected to a resolved signal.   The value  seen  by  the  input  side  of  such  a  port  is  the  final  value  of  the  resolved  signal connected to the port.   An inout port models a connection in which the driver con- tributes to the associated signal’s value, and the input side of the component senses the actual signal rather than using the driving value.


Want To have highly paid VLSI jobs ?? then you may contact at

Contact : webmaster@freehost7com



Some asynchronous bus protocols use a distributed synchronization mecha- nism based on a wired-and control signal.   This is a single signal driven by each module using active-low open-collector or open-drain drivers and pulled up by the bus terminator If a number of modules on the bus need to wait until all are ready to proceed with some operation, they use the control signal as follows.  Ini- tially, all modules drive the signal to the ‘0’ state.  When each is ready to proceed,

it turns off its driver (‘Z’) and monitors the control signal.  So long as any module

is not yet ready, the signal remains at ‘0’ When all modules are ready, the bus terminator pulls the signal up to the ‘1’ state.   All modules sense this change and proceed with the operation.

Figure 7-1 shows an entity declaration for a bus module that has a port of the unresolved type std_ulogic for connection to such a synchronization control sig- nal.   The architecture body for a system comprising several such modules is also outlined.  The control signal is pulled up by a concurrent signal assignment state- ment, which acts as a source with a constant driving value of ‘H’.  This is a value having a weak strength, which is overridden by any other source that drives ‘0’.

It can pull the signal high only when all other sources drive ‘Z’.




library ieee;  use ieee.std_logic_1164.all;

entity bus_module is

port ( synch : inout std_ulogic;  … );

end entity bus_module;

–– ––– –––– ––– –––– –––– ––– –––– ––– –––– ––– –––– –––– ––– ––––

architecture top_level of bus_based_system is signal synch_control : std_logic;



synch_control_pull_up : synch_control <= 'H';

bus_module_1 : entity work.bus_module(behavioral)

port map ( synch => synch_control, … );

bus_module_2 : entity work.bus_module(behavioral)

port map ( synch => synch_control, … );


end architecture top_level;


An entity declaration for a bus module that uses a wired-and synchronization signal, and an archi-

tecture body that instantiates the entity, connecting the synchronization port to a resolved signal.


Figure 7-2  shows  an  outline  of  a  behavioral  architecture  body  for  the  bus module.  Each instance initially drives its synchronization port with ‘0’.  This value

is passed up through the port and used as the contribution to the resolved signal from the entity instance.  When an instance is ready to proceed with its operation,

it changes its driving value to ‘Z’, modeling an open-collector or open-drain driver being turned off.  The process then suspends until the value seen on the synchro- nization port changes to ‘H’.  If other instances are still driving ‘0’, their contribu- tions  dominate,  and  the  value  of  the  signal  stays  ‘0’.   When  all  other  instances eventually change their contributions to ‘Z’, the value ‘H’ contributed by the pull- up statement dominates, and the value of the signal changes to ‘H’.  This value is passed back down through the ports of each instance, and the processes all re- sume.




architecture behavioral of bus_module is


behavior : process is



synch <= '0'  after Tdelay_synch;


– – ready to start operation

synch <= 'Z' after Tdelay_synch;

wait until synch = 'H';

– – proceed with operation

end process behavior;

end architecture behavioral;


An outline of a behavioral architecture body for a bus module, showing use of the synchronization con-

trol port.