Vi-ta [vee-tuh]

Critical Embedded Systems
are everywhere . . .

Become a leader in setting new directions!


only search VITA site

Asynchronous Bus / Metastability

By John Rynearson, Technical Director, VITA

Question? "I’ve heard that the VMEbus is an asynchronous bus? What is the difference between a synchronous bus and an asynchronous bus? What design considerations must I be aware of?"

The VMEbus is an asynchronous bus. The bus architecture uses a master/slave relationship that relies on handshakes to complete bus transactions. The master presents address and data and then invokes command lines that say here's the address and data. The responding slave decodes the address and reads the data, and then uses a data acknowledge signal (DTACK*) to signal that the data is captured. The advantage of such a scheme is that data transfer rates depend on the speed at which handshakes can progress. At any point in time there are certain delays associated with a specific logic family. As semiconductor technology advances, delays diminish, and hence the data transfer rate can increase on an asynchronous bus. Theoretically, the only limit for an asynchronous bus assuming zero transmitter and receiver delays is the propagation delay across the backplane.

Synchronous buses on the other hand contain a synchronizing clock that is used to validate each signal. When a synchronous bus is specified, the clock speed is set for all time. As technology progresses and internal chip delays decrease, synchronous buses remain locked at the same speed if interoperability between old and new products is to be maintained.

Noise on bus lines can affect both synchronous and asynchronous buses. Synchronous buses are affected by noise only when the clock occurs while asynchronous buses can mistake noise pulses at any time for valid handshake signals.

One important design consideration that all designers must content with is metastability. Synchronous bus designers must contend with metastability when attempting to synchronize signals with differing clock frequencies. Asynchronous bus designers must contend with metastability when events that drive bus transactions can occur asynchronously. Metastability arises in any flip flop when its setup time is violated. Meeting setup times is one of the criteria for a good synchronous design while setup times are routinely violated in asynchronous designs because the designer must deal with events that occur asynchronously.

When the setup time on a flip flop is violated its output will oscillate and its final state cannot be predicted. It may retain its present state or it may transition to a new state. The period of oscillation varies depending on the type of flip flop used and can range from nanoseconds to microseconds. Current TTL type flip flops and PAL based flip flops usually experience metastable oscillations in the range of 20-45 nanoseconds. When a flip flop experiences metastability, unintended effects can occur in downstream circuitry unless proper design techniques are used.

Since flip flops are employed to indicate the state of an event, it is important that the period of indeterminacy not affect downstream circuitry. For example, on the VMEbus, daisy chain lines handle bus grant signals. If a master wants the bus, it asserts its bus request line. The system controller upon successful arbitration will send the appropriate bus grant signal down the bus grant daisy chain. Masters that receive the bus grant signal and aren’t requesting the bus must send it on down the daisy chain. A master that receives the bus grant signal and is requesting the bus, must not propagate it on down the daisy chain.

Designers new to the VMEbus may mistakenly assume that a simple flip flop circuit can be used as shown in Figure 1. This circuit works fine assuming that only one master requests the bus at any one time. However, in a multimaster system, one or more masters may request the bus at any time. In fact, in such as system it would be common for one master further down the daisy chain to request the bus causing the system controller in slot 1 to issue a bus grant. Part way down the daisy chain another master may assert its bus request just as it receives the bus grant signal. If the setup time for the flip flop is violated, then the output signal BG3OUT* will oscillate causing the original requesting master to also receive the bus grant signal. Under these conditions both masters may think they have been granted the bus and both masters may proceed to put addresses on the bus with disastrous results.

Poorly designed bus requester
Figure 1 - Poorly Designed Bus Requester

The solution to this problem is to design the requester circuit assuming that the setup time on the flip flop will be routinely violated and that metastability will occur. One method would be to add an additional flip flop so that the BG3OUT* signal is double clocked. If a clock period of 50 ns is used then oscillations in the first flip flop will have ceased and the flip flop will have assumed one of two states before the result is clocked out onto the bus.

Such solutions are always simple to put into the design the first time around and much more difficult to patch onto a finished printed circuit board as most experienced design engineers have learned the hard way.

This page last updated: Sep 19, 1999

Reprinted from the VITA Journal with permission from VITA.

Return to the main VMEbus FAQ Page

Copyright © 1996-, VITA. All rights reserved.
VITA Copyright and Use Notice
VITA Privacy Policy


only search VITA site
Powered by Wild Apricot Membership Software