By John Rynearson, Technical Director, VITA
The VMEbus backplane provides the transport media for electrical signals between modules. As originally defined a VME backplane can contain up to 21 slots. Why was 21 slots selected? Because if you space connectors at 0.8 inch you can just get 21 slots into a chassis which will fit into a 19 inch rack. Backplanes can contain less than 21 slots and sizes such as 5, 7, 9, 12, and 15 slots are popular. For really small systems even 3 slot backplanes can be used.
The VMEbus defines an asynchronous backplane protocol which uses handshaking signals rather than a clock to transfer data. Since the backplane is viewed as a transmission line, certain time delays are defined to assure that signals reach a known state before they are deemed valid. These time delays were determined by taking into account a fully load 21 slot backplane and characteristics of specific TTL logic available when the VMEbus was developed in the early 1980s.
These delays have stood the test of time and have provided reliable operation for VMEbus systems in a variety of configurations and applications.
At the January 1997 Real Time Computer show in Santa Clara, CA. a revolutionary announcement was made. Drew Berding, Arizona Digital, displayed a 21 slot VMEbus backplane that could transfer data at a 320 Mbyte/second data rate. His demonstration was even more dramatic because one of the modules was on a standard extender board. Scope traces showed the signals to be very clean even though signals were running from slot 1 to slot 21 and then through an extender board in a fully loaded system.
Much speculation ensued as to how the backplane was constructed. While many ideas were put forth, the method employed by Drew was both elegant and straight forward. A standard backplane trace goes from slot 1 to slot 2 to slot 3 and so on through slot 21. In the VME320 backplane each slot trace is wired directly to slot 11 in a basic star configuration. So that a signal from slot 1 to slot 2 goes from slot 1 to slot 11 and then back to slot 2. Wiring the backplane in this manner changes the backplane signal characteristics dramatically. Instead of looking like a transmission line, the VME320 backplane looks like a lumped capacitance. As a result signal lines are cleaner, noise is reduced, and data transfer rates can be effectively increased.
While Drew's announcement created a lot of interest from users, it also caused the VMEbus community to revisit the original assumptions for backplane design and to see what other design changes could be made to enhance backplane performance.
At the March 1998 VSO meeting in Geneva, Switzerland, Andreas Lenkisch, Trenew, presented research he had done to enhance backplane performance in a paper titled "VME Breaks Performance Barrier Again - 1000 Mbytes/s Range Possible". In the paper he noted that a reduction in trace impedance improved signal waveforms and might allow higher speed transfers in a traditional stitched backplane.
In May Bob Sullivan, Hybricon, presented work he had to done showing the possiblity of moving data at 560 Mbytes/sec with existing ABTE ETL transceivers. Hybricon's approach was to use diode terminations and a modified bus topology to increase the effective impedance of the backplane.
The battle of the backplanes continued at the July VSO meeting where Andreas Lenkisch, Trenew, presented additional results to the approach he proposed in March and Drew Berding, Arizona Digital, compared the various approaches and presented arguments regarding the advantages of the star backplane approach.
Drew's original announcement in January a year before has unleased new research into backplane characteristics and has spurred many companies to relook at the way backplanes are built.
To take advantage of these new backplane technologies, the VITA Standards Organization (VSO) set up a task group early in 1997 to begin work on a new protocol. The task group decided to specify a synchronous protocol that would provide data transfer rates of 320 Mbytes/second and greater.
The 2eSST protocol, is based on the asynchronous 2eVME protocol. The main exception to this is that during its data phases, 2eSST is a source synchronous protocol. No acknowledgment is expected from the receiver of the data. Hence, the theoretical performance of 2eSST is limited only by the skew between receiver and transmitter of data. Like 2eVME it uses incident wave switching to guarantee fast switching times and minimize skew. The result is a protocol that as currently defined doubles the theoretical bandwidth of VME to 320Mbytes/sec. The protocol can be broken into three main phases: address broadcast, data phase and termination.
The address broadcast phase for 2eSST is identical to the address broadcast phase for 2eVME. However, the data phase is synchronous rather than asynchronous.
Traditional VME utilizes a handshake protocol whereby data strobes (DS1* and DS0*) are acknowledged by DTACK* which then allows the data strobes to be removed which in turn allows the DTACK* to be removed. Once DTACK* is deasserted, a new cycle can begin.
Traditional VME protocol requires four delays through the drivers, backplane and receivers plus the settling time of the backplane. 2eVME protocol improves upon this by using both edges of DS1*, DS0*, and DTACK* to qualify data. Throughput is doubled, but performance is still limited by the requirement for acknowledgment from the receiver of data.
In contrast, after the address phase, the 2eSST protocol sends the data and strobe and does not wait for any acknowledgments. Therefore, data can be sent at much higher bandwidth. Both edges of the strobe are used: falling edge for odd data beats and rising edge for even data beats.
Over time the VMEbus has evolved to meet new requirements. With the announcement in January 1997 of higher performance backplanes, a new wave of VME performance improvements has begun that will allow users to meet the demanding data applications of the 21st century.
This page last updated: Sep 19, 1999
Reprinted from the VITA Journal with permission from VITA.
Return to the main VMEbus FAQ Page