|
VHDL Tutorial |
Resolved signals and ports in VHDL | ||
|
Introduction Fundamental concepts Modelling concepts Elements of behaviour Elements of structure Analysis elaboration Lexical elements Identifiers Numbers 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 Procedures Procedure parameters Signal parameters Default values Unconstrained array parameter Functions 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 signals 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;
begin 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, );
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 begin behavior : process is
begin synch <= '0' after Tdelay_synch;
ready to start operation synch <= 'Z' after Tdelay_synch; wait until synch = 'H'; proceed with operation end process behavior;
An outline of a behavioral architecture body for a bus module, showing use of the synchronization con-
|
