VME-PCI bridge adds 2eSST functionality to VME bus
VME-PCI bridge adds 2eSST functionality to VME bus
By Robert Negre, Vice President, Product Development and Marketing, Serge Tissot,Product Development Manager, Thales Computers SA, Toulon, France, EE Times
January 17, 2003 (11:28 a.m. EST)
During the past two years, a great deal of speculation has swirled around the direction VME architecture development should take. Although newer standards, such as CompactPCI and industrial-grade Ethernet, have evolved in the last 10 years to potentially supplant VMEbus, the extensive installed base, developer experience and continued applicability of the VME standards argue strongly for its continued use. To maintain a robust presence in the marketplace, however, it is essential that VME be able to accommodate higher bandwidth capability.
The most widely discussed potential upgrade to VMEbus is the VME320 standard, introduced by Arizona Digital Inc. in 1997. VME320 employs a new bus protocol known as 2eSST, for 2 Edge Synchronous Source Transfer, to deliver speeds of 320 Mbytes/second or higher. A draft standard, known as VITA 1.5 (from the VMEbus International Trade Association), currently defines 2eSST for use within VME systems.
Ou r evaluations have demonstrated that a 2eSST implementation, provided through a new PCI-to-VME bus bridge interface design called Alma2e, can provide a significant increase in transfer bandwidth when used in a high-end computing node.
The high bandwidth of 2eSST transfers, combined with the broadcast capability of the Alma2e interface design, provides system integrators with great flexibility in designing efficient computing and I/O architectures. In many cases, these capabilities may save the cost of specialized, dedicated I/O channels within small configurations. Further, the Alma 2e architecture reuses and capitalizes on that of the Alma64, a proven design that facilitated a very smooth test phase, resulting in high measured performances.
The incorporation of 2eSST capability provides the VME platform with tremendous additional bandwidth, and should help extend the popularity and market strength of VME well into the future, especially so, considering that future board designs that target sustained VME throughputs of 180 Mbytes/second and 240 Mbytes/s are expected to be available during 2003.
The 2eSST protocol is based on the asynchronous 2eVME protocol. The address broadcast phase in 2eSST is identical to that of 2eVME. However, 2eSST becomes a source synchronous protocol during the data phase, with no acknowledgement required from the data recipient. For that reason, 2eSST performance is in theory limited only by the skew between data transmitter and data recipient.
Like 2eVME, 2eSST uses incident wave switching to minimize skew and ensure fast switching. When combined with the data phase source synchronous protocol, this provides a theoretical bandwidth of 320 Mbytes/s, although the maxim sustainable bandwidth is probably slightly less when the initial setup time of each transfer is taken into account.
The new bridge interface, Alma2e, is based on Alma64, the bridge interface originally developed in 1995 with the participation of IBM Corp. Among other things, the earlier implementation incorporated VME64 master and slave operation (compliant with VME64 ANSI/VITA 1-1994); MBLT D64, D32/D16/D08; A32/A24/A16 transfer support; 2-channel DMA control; VMEbus arbitration; interrupt handling and mailbox interrupt support; 8 VME slave windows and 32-bit, 33-MHz PCI operation.
More to work with
In addition to providing support for 2eSST transfers and 2eSST broadcasts and allowing 2eSST writes to multiple VME slaves, the new bridge interface offers 2 Kbytes of data FIFO in each direction, with programmable thresholds; 64 VME addressing; and an additional eight VME slave windows.
Alma2e uses a dedicated setting of the internal direct memory access (DMA) controller to initiate 2eSST transfers over the VMEbus as a VME master or slave (no 2eSST transfers over the VMEbus are generated as a result of a PCI slave operation).
In Address Phase 1 (the first data strobe, or DS0 assertion), the Alma2e uses an address modifier encoding of 0x20 for 2eSST transfers. Table 1 lists the extended address modifier codes used for Alma2e VME master or slave operation.
Address Phase 2 (DS0 deassertion) includes cycle count and the transfer rate. The Alma2e uses either a block size programmed in the DMA controller (divided by 2 because of the 2 edges), or a smaller value for the cycle count.
In operation as a 2eSST data source, the Alma2e generates one of three transfer rate codes (SST160, SST267 or SST320) using its DMA_CHN_RATE register setting. 2eSST timings are user-programmed in the register VME3ESST_CTL. The actual timings should correspond to rates less than or equal to the rate code, with setup and hold times greater than or equal to 2eSST requirements. In operation as a 2eSST data receiver, the Alma2e accepts SST160, SST267 and SST320 transfer rates. However, to accommodate specific system timing needs, it is possible t o program the Alma2e not to accept SST320 transfers. In this case, a slave error would be generated upon detection of a transfer rate of SST320 during Address Phase 3.
During Address Phase 3 (DS0 reassertion), if a broadcast 2eSST operation has been selected, the geographical address of the slaves targeted by the broadcast is indicated by VME addresses A21 to A1. During the broadcast operation, the master responds to its own cycles with DTACK, and participating slaves receive the transmitted data. Any slaves not ready to accept full broadcast operation assert RETRY during Address Phase 3 to request a restart of the transfer.
To evaluate the capabilities of the new SST/VME/PCI bridge interface, a high-end signal-processing computer node was used, the V4G4c. Designed for high-end signal processing in a 6U form factor, it incorporates four 500-MHz Motorola PowerPC 7410 (G4) processors with AltiVec vector processing units. It has been designed to accommodate the signal processing requirements inv olved in sonar, radar and medical imaging applications.
The V4G4c implements the traditional 5V VME buffers. Because of this, 2eSST transfers are limited to standard VME backplanes that have six or fewer slots, which prevents signal reflection on 2eSST clocks. The draft VITA 1.5 standard for 2eSST calls for system integrators to check signal integrity for heavily loaded backplanes. This requires the system's VME64 or VME64x backplanes and boards to allow for monotonic rising and falling bus signals through the threshold region of the receiver (rule 3.2 in VITA standard 1.5).
The V4G4c also uses a 32-bit/33-MHz PCI bus. When combined with the 6-slot limitation imposed by the use of 5-volt VME buffers, the probable maximum bandwidth of 2eSST transfers on the V4G4c is 120 Mbytes/s. However, the Alma2e in 2eSST mode supports multicasting over up to eight addressing windows; this can multiply the overall bandwidth severalfold (figure 2). The Alma2e interface bridge is supported at the operating sy stem level through drivers available under VxWorks, LynxOS and Linux. Future computing nodes that include a 64-bit/66-MHz PCI interface to the Alma2e, as well as enhanced VME transceivers (Texas Instruments model SN74VMEH22501), will allow the use of the full 2eSST bandwidth across all 21 slots in a VME64x backplane. In fact, the use of the Alma2e bridge in a PowerPC I/O board that incorporates a 64-bit/66-MHz PCI interface has already been validated.
The validation of 2eSST operation in the V4G4c involved first exercising the operations alone, followed by exercising 2eSST operations under operating system activities, with multiple simultaneous transfers, and with both 2eSST and standard VME cycles. Validation studies demonstrated successful data integrity checks at all 2eSST rates, and the 2eSST performance matched expected theoretical transfer rates.
Although the transfer rate calculated during the burst phase of 2eSST transfers was 254 Mbytes/sec, when the time spent in the three initial address phases for a write transfer (a total of 600 ns) is factored in, the effective rate is closer to 240 Mbytes/s. In a read transfer, the time spent in the initial phases is slightly longer (about one second) because the Alma2e first needs to read the data from the PCI, yielding a slightly lower effective rate.
Copyright © 2003 CMP Media, LLC | Privacy Statement