COMPLETION OF A PROTOTYPE ATM CELL-STREAM SPLITTER FOR AN EXPERIMENTAL MULTI-MEDIA TERMINAL. S. Liew and K. M. Adams

Transcription

1 COMPLETION OF A PROTOTYPE ATM CELL-STREAM SPLITTER FOR AN EXPERIMENTAL MULTI-MEDIA TERMINAL S. Liew and K. M. Adams Department of Electrical and Electronic Engineering University of Melbourne, Parkville Victoria 3052, Australia Abstract In this paper, we report the completion of a prototype hardware ATM (Asynchronous Transfer Mode) cell-stream splitter for a multi-media workstation. It describes some of the experiences encountered while designing and testing the splitter s interface to the workstation s system bus. A summary of the test procedures is given, including a report on the recent demonstration of the prototype multi-media terminal. 1 OVERVIEW OF THE ATM CELL-STREAM SPLITTER The cell-stream splitter was conceived as a solution to minimise traffic on the system bus (SBus) of a Sun workstation (SPARCstation 1+) when it is functioning as a multi-media terminal. A broad description of the the overall project is given by G. Armitage elsewhere in the proceedings of MCAT 93 [1]. The development and description of the terminal and splitter have already been presented in past papers and reports [2, 3, 4, 5, 6]. Therefore, only an overview of the splitter will be given here. The basic architecture of the splitter is shown in Figure 1. At this stage, the splitter uses as the transmission link, i.e. ATM cells are transmitted while framed inside packets. This is because at the start of the project, a fibre ATM link was not available and it was more convenient to use the link already present. However, the is transparent to the layers and functional modules above the splitter s ATM- interface. Thus, the hardware is geared towards handling information as 53-byte units (as defined for ATM cells). The splitter has two ports: a main port for multi-media traffic, and a video port which serves as a dedicated interface to a video codec and packetiser system. D/S-Cells Main Controller (Main Port) XC3030 V-Cells Cell Merger Cell Extractor SBus XC4005 Buffer A Buffer B Buffer C Buffer D XC3042 Link to Video LSI Logic L64853 SBus Interface Controller L64853 D Channel (8-bit) Interface Logic and Register Figure 1 Video Port Interface Logic XC3030 Controller (Video Port) As packets (containing video, data or signalling cells) are received by the main port s controller, their 14-byte headers are stripped off by the Cell Extractor. As each cell is extracted from the packet, part of the VPI/VCI is checked to determine the type of information present

2 If a video cell (V-cell) is detected, it is written into Buffer D. The V-cells are then framed into packets again and sent to the video codec through the splitter s video port. Data and signalling cells (D/S-cells) are written into Buffer B and then sent to the SBus. For data transmission at the main port, D/S-cells from the SBus and V-cells from the codec are framed into packets by the Cell Merger before being sent out. Cells from the SBus are put into Buffer A first, while those from the codec are placed in Buffer C, before being read by the Cell Merger. The four FIFO (first-in, first out) buffers are each made up of a dual-port RAM and control logic. Using this cell-stream splitting concept, the SBus is relieved from most of the multi-media traffic, i.e. V-cells. At the other end of the video link, the packetiser and codec system extracts the V-cells from the packets and processes them. The video bit-stream is then decoded into PAL video, which is then fed into a RasterOps TC/PIP frame buffer card (plugged on the SBus) so that the video image can be displayed in a window on the workstation monitor. The codec also takes a video signal and encodes it into a digital bit-stream for transmission. Main PCB SBus Card Main Port Controllers Cell Extractor Cell Merger Buffers C & D Video Port Interface Logic Signal Buffers Video Port Buffers A & B L64853 Interface Logic L64853 Controller FCode ID PROM SBus Figure 2 The splitter is physically divided into three printed circuit boards (PCBs), as represented in Figure 2. The SBus card consists of interface control logic, Buffer A and Buffer B. The main splitter PCB holds the rest of the functional blocks, and primarily uses 3 Xilinx XC3000 family FPGA s (Field Programmable Gate Arrays) to implement most of the control logic. Two SEEQ 8003 and 8023A chip-sets are used as controllers. The third PCB is used to buffer signals between the other two boards. 2 FUNCTIONAL DESCRIPTION OF THE SPLITTER S SBus INTERFACE CARD SBus LSI Logic L64853 SBus DMA Controller Xilinx XC4005PG156 (Control Logic for Buffers and D Channel Interface) Buffer A RAM Buffer B RAM To Cell Merger From Cell Extractor FCode ID PROM Xilinx Chip's Configuration EPROM Figure 3 The purpose of the splitter s SBus interface card is to facilitate the transfer of cells between the SPARCstation SBus and the main splitter board. Figure 3 shows the major components and data flow on the card. An LSI Logic L64853 SBus DMA Controller is used to handle the SBus transfer protocols and provide an 8-bit port (D channel) to the buffers. However, the L64853 is used only as an SBus slave device, so that data transfers are performed using - 2 -

3 programmed I/O instead of DMA. A Xilinx XC4005PG156-6 FPGA is used to implement the control logic for the two FIFO buffers, the D channel interface logic, and an 8-bit control/status register (CSR). The FCode ID PROM stores firmware code which declares the card s name and attributes to the system kernel. It is read via the L64853 during system resets. For incoming D/S-cells, the input control logic of Buffer B ensures that only complete cells are written into the buffer s RAM. If it has less than 53 address spaces left after a cell had been written, it will not allow the next incoming cell to be written. At the end of each cell, the Cell Extractor will assert an EOC (end-of-cell) strobe which indicates to Buffer B that the current byte being written is the last byte in the cell. This strobe causes an SIC (start of incoming cell) pointer to increment so that the cell can be read from the buffer s output port. If Buffer B is initially empty, the EOC strobe for the first incoming cell will cause the output control logic to detect the presence of the cell and send an interrupt signal to the L64853, which will in turn generate an SBus interrupt. A device driver routine will then proceed to read the cells from Buffer B s output via the L64853 and put them on a queue in memory to await further processing. After each cell is read, the 8-bit CSR is checked to determine if there is another cell to be read. This procedure is repeated until no cells are left. When D/S-cells need to be sent out, the SBus device driver first causes the CPU to read the 8- bit CSR to determine if there is space for at least one cell in Buffer A. If so, a loop of 53 8-bit write cycles will be performed. This is followed by a write to the 8-bit CSR to toggle an EOC bit, which causes Buffer A s SIC pointer to increment. As a result, the output logic detects the presence of the cell and asserts an output ready signal. The Cell Merger detects this ready signal and proceeds to read the data until there are no more left, i.e. when the ready signal becomes unasserted again. As cells are framed into packets, an EOF (end-of-frame) signal will be asserted at the end of each packet to cause the SOP (start of outgoing packet) pointers in Buffer A (and C) to increment. The use of an SOP pointer stems from the need for re-transmission if collisions occur on the. Once the SOP pointer is incremented, the RAM locations which held the recently transmitted cells can then be allowed to be overwritten. Otherwise, if a re-transmission is required, the cells are read again by reloading the output address counter with the SOP register value. The 8-bit CSR enables the device driver software to perform basic control and status read operations. It can be used to clear the buffers (individually), increment Buffer A s SIC pointer, discard the current cell being written into Buffer A, and read the status of Buffer A s input port and Buffer B s output port. The SunOS STREAMS based device driver written for the SBus card is named the BNI (broadband network interface) driver. 3 ADDITIONAL FEATURES 3.1 Dealing with Cell Misalignment in Buffer B - Causes and Solutions Buffer B resets The BNI driver s read-side control ensures that Buffer B is flushed (by writing a certain bit in the 8-bit CSR High) whenever the message queue becomes full or when no memory can be allocated for further messages. While the driver was being tested, it was found that these flushes would occasionally leave residual bytes in the buffer. This is because there is a possibility that the Cell Extractor is still in the midst of writing a cell when the buffer is being cleared, i.e. when its address counters and registers are being reset). Thus, the former part of a cell may be cleared while the latter part is written into the RAM afterwards. This will cause subsequent incoming cells to be misaligned if no additional measures are taken. Initially, an attempt was made to solve the problem in software but it was somewhat ineffective

4 To solve this problem, the assertion of the internal reset signal during Buffer B flushes will cause the input address counter to be disabled. Thus, if Buffer B is flushed while a cell is being written, the former part of the cell is cleared while the rest of the cell will be written to a null location since the input address is not incremented (normally, the address is incremented after each write cycle). When the EOC signal is asserted at the end of the discarded cell, the input address counter is enabled again so that the next cell can be written into the buffer memory. However, if no cell is being written when the buffer flush occurred, the input counter will not remain disabled until the next EOC signal is asserted - otherwise, this will cause the next cell to be lost. Therefore, a time-out counter is included so that if no write cycles are detected immediately after flushing the buffer, a signal will be asserted to re-enable the input address counter. The algorithm for this mechanism is shown in Figure 4. rmal operation Flush Buffer B Input counter disabled Any write activity after flushing? Input counter disabled Re-enable input counter End of cell? Figure ARP packets It was also observed that some unidentified data would occasionally make its way into Buffer B in an apparently random but infrequent manner. If valid cells came in after that, they would be misaligned because these unwanted data came in groups of less than 53 bytes. When the contents were examined and traffic on the was monitored, we discovered that these bytes belonged to ARP packets sent by workstations on the network. ARP (Address Resolution Protocol) is used to dynamically map between Internet Protocol (IP) and 10 Mb/s addresses, and caches IP-to- address mappings. When an interface on the network requests a mapping for an address not in the cache, ARP will broadcast a message on the network requesting the address mapping. The destination address (0xffffff) of the broadcast packets ensures that every controller on the network receives them. These packets contain 28 or 46 bytes of payload. This condition was overlooked during the design of the main splitter PCB. The Cell Extractor has a mod-53 counter (for cell-delineation) which resets after reaching terminal count or when a data discard is signalled by the main port controller during reception. The counter is also responsible for generating the EOC strobe. Therefore, if a packet with 46 bytes is received, followed by a valid cell, the EOC strobe will be asserted after writing the first 7 bytes of the valid cell. Since the device driver reads data using loops of 53 read cycles, subsequent cells will be misaligned. Buffer wait/ready Data arriving? Write data; End of cell? Byte write time-out (1600 ns)? Signal "buffer not ready" status Figure 5 Restore input pointer (discard "short cell") To solve this problem, additional time-out logic is used to detect incoming data units which fall short of 53 bytes. When a data unit is extracted from an incoming packet, it is written into the buffer at a constant rate of one byte every 600 ns. Therefore, if the write cycles stop after 46 bytes, the inactivity is detected by the time-out counter and a byte-count error signal is asserted. The invalid bytes are then cleared by setting the input address count to where it was before the data came into Buffer B, i.e. the SIC value. At this time, the buffer input ready signal is also - 4 -

5 unasserted so that the Cell Extractor will not attempt any write cycles. This process is shown in Figure 5. A necessary change was made to the mod-53 counter (by changing the FPGA configuration) so that it also resets whenever the controller signals an end-of-frame at the end of each incoming packet. Therefore, having reset the mod-53 counter at the end of an incoming ARP packet, the next incoming cell can be delineated correctly. 3.2 Ensuring an Unhindered Flow of V-Cells If Buffer B became full and consequently unasserted its input ready signal, the Cell Extractor would cease writing to Buffer B. When this happened, we discovered that the Cell Extractor was designed such that V-cells also could not be written into Buffer D if subsequent packets containing V-cells arrived. Thus, the Cell Extractor would cause the unnecessary loss of video cells if Buffer B becomes full and was not serviced or cleared. Therefore, the buffer s input control logic was modified so that the input ready signal will not be unasserted in the event of a Buffer B full condition. Instead, when there is less than 53 empty addresses left after writing a cell, the buffer s input address counter will be disabled. If more D/S-cells come in, this effectively allows the Cell Extractor to write them into a certain address acting as a null location in the RAM. When buffer space is available again, the input counter will again be enabled so that cells can be written into the RAM. If space is made available again while a cell is being written to the null location, the logic will ensure that the whole cell is discarded before enabling the input counter (to prevent cell misalignment). Buffer D is hardly ever overflowed by V-cells because they are efficiently sent out from the video port. Thus, there was no need to modify Buffer D s input control logic. However, Buffer B overflows should be avoided in the first place because D/S-cells generally contain information of higher priority. In practice, this will depend much upon the flow control protocols implemented in the higher protocol layers. 4 SUMMARY OF PRELIMINARY TESTS The following test strategy and steps were performed as the prototype was nearing completion: (a) The splitter s Cell Merger was tested to see if it would read data coming from Buffer A. This was done by constructing a simple logic circuit to cause the Cell Merger to read data from an imaginary Buffer A output port. (b) The splitter s SBus card was manually tested in an SBus slot, using the Sun Open Boot PROM Toolkit in the Sun-Compatible Monitor mode (the SunOS operating system was halted). Simple data accesses were performed on the FIFO buffers (A and B), the FCode ID PROM, the 8-bit CSR, and the L64853 s internal control/status register. (c) The SPARCstation was rebooted so that the splitter s SBus card could be tested with the SunOS running. A test driver called Slot [8] was written and loaded into the system kernel to test data accesses to the registers and data ports on the SBus card. In (b), the tests were initially done with the card plugged in an SBus expansion box (which provides additional slots for the SBus) and the results seemed satisfactory. However, after the reboot, it was found that the card failed to gain an entry in the SPARCstation s device tree (which stores the device name and its attributes). When plugged directly in an original SBus slot, the card successfully gained an entry in the device tree and was then tested using the Slot driver. This suggested that there was a failure in reading the FCode PROM due to the SBus expansion box hardware. In our experience, we had tried three different brands of SBus expansion accessories and none of them were found to provide full SBus functionality

6 (d) Finally, the BNI driver was loaded so that proper data transfers on the network via the splitter SBus card could be tested. The ATM/AAL (ATM Adaptation Layer) module was also loaded and matched to the driver s upper-level STREAMS interface to perform the tests. The general conclusion was that cell transmission and reception across the SBus proved successful and were carried out at satisfactory speeds [8]. Through these troubleshooting stages, we discovered the bugs described in Section 3 and were thus able to eradicate them. Other minor changes were also made as a result of these tests, and setbacks like that of the SBus expansion accessories were found. From what the tests revealed at each stage, the splitter could be refined to become a reasonably reliable prototype. 5 SYSTEM DEMONSTRATION AND OBSERVATIONS Having completed the splitter for the multi-media terminal, system trials could be run in conjunction with the video codec and packetiser project at Telecom Research Laboratories, Melbourne. The purpose was to bring the different parts of the project together to work in an integrated fashion. The various components forming the integrated multi-media terminal and their relationship to each other are shown in Figure 6, and they include: The hardware cell-stream splitter and its SBus interface card. The STREAMS BNI driver for the splitter s SBus card. The software implementation of the AALs (types 3/4 and 5) and the ATM layer [9, 10]. The TCP/IP layer link to the AALs. The signalling and management for establishing and terminating links. The X11 suite of utilities developed for multi-user editing and drawing. The video codec/packetiser connected to the dedicated links for video traffic. The RasterOps TC/PIP card for displaying video on the SPARCstation. Multi-user Shared Workspace Conference Tool Applications Serial Line SPARCstation Main Transport AAL/ATM BNI Windowing System SBus Secondary Workstation Monitor RasterOps PAL Video Video & Packetiser Video Camera & Microphone Figure 6 Specifically, the equipment used in the demonstration involved: Two SPARCstation 1+ workstations on which the multi-media terminals are based on. A SPARCstation 1 acting as a software emulated cell switch node

7 A SPARCstation IPC functioning as the NFS file-server for the other machines and as a third user terminal without video support. Two sets of hardware splitters and SBus cards. Two CLI Rembrandt video codecs. Two packetisers which interfaces between each codec and the ATM-over- network. Two RasterOps cards to display the video output from each codec on a window. Multi-media Terminal 1 SPARCstation 1 Multi-media Terminal 2 SPARCstation 1+ (Cell Switch) SPARCstation 1+ Figure 7 The trial system was set up in stages. The first set-up involved interfacing all the relevant ports on the same network as shown in Figure 7. The purpose was to verify that all the ports are functioning, especially while they are all on the same network and all the ATM-over- packets can be monitored. Firstly, the codecs packetisers were set up so that a direct virtual connection was made between them, creating a two-point video/audio communications link. Having found the video transmission and reception by the packetisers to be satisfactory, the cell switch was set to route particular pairs of VPI/VCI s, while video cells from the codecs/packetisers were given VPI/VCI s necessary for two-way traffic through the switch. The set-up was again tested by sending cells from one codec to the video port of the associated splitter. Having traversed through the splitter, the cells are sent out through the main port to the cell switch. At the cell switch, their VPI/VCI s were switched and the cells were then sent to the main port of the other splitter. Finally, they were sent out from the video port of the second splitter to the second video codec and packetiser. After having achieved one-way video communication, traffic was made to travel in the other direction simultaneously and was proven successful as well. Even with all the ports on the same network, hardly any degradation of performance was felt on the. Multi-media Terminal 1 SPARCstation 1 Multi-media Terminal 2 SPARCstation 1+ (Cell Switch) SPARCstation 1+ Figure 8 Finally, the set-up was changed to that which was intended, as in Figure 8. In this case, the components making up each multi-media terminal become integrated as depicted by the shaded areas. With this configuration, traffic on the dedicated video links could not be monitored by the workstations on the main ATM-over- network. At first, the virtual connections through the switch were manually established. After that, the signalling protocol developed by G. Armitage [11] was used to establish on-demand 384 kbit/s video connections through the cell switch node. During these trials, we successfully demonstrated two-point video conferencing using ATM over the. There was a general sense that the connections were quite cumbersome and there were occasional faults on one of the splitter-tocodec links. The multi-user shared workspace X11-based utilities (e.g. xfig, xedit, - 7 -

8 xdbx) developed by F. Wilson [12] were also demonstrated, albeit separately. Due to bugs in the X11 and the RasterOps software, the video conference had to operate separately under Sunview. However, the bugs have since been fixed and the system can now function in an integrated fashion. Nevertheless, the demonstration proved that the hardware and software we developed for the prototype multi-media terminal can be put to work in practice. 7 FUTURE WORK Having completed and tested the first prototype, future work is geared towards the improvement, integration and increased functionality of the hardware. The continual development of hardware support for the multi-media terminal will depend very much on FPGA technology for its flexibility and ease of implementation. Xilinx has now released FPGA s that can run at system clock speeds in the excess of 100 MHz (the XC3100 family), while high densities can be provided by the XC4000 family (up to 20,000 gates). Therefore, there is considerable potential to improve the performance of the splitter and achieve high integration. A single high density XC4000 family chip should be able to implement most of the splitter s control logic. A fibre optic interface will be implemented in the future to provide a true high-speed ATM link instead of the present ATM-over- scheme. The control logic of the Cell Extractor and Cell Merger may thus be simplified with respect to this change. However, the complexity of the Cell Extractor need to be increased because it will need to distinguish between V-cells and D/S-cells by reading VPI/VCI s which are normally dynamically assigned for each call connection. As a temporary measure, the current splitter reads two bits in the VPI/VCI using predefined values to distinguish between V-cells and D/S-cells. Work on implementing the ATM layer and the AAL in hardware (or at least part of it) has also commenced. If it is combined with the splitter logic, it is unlikely that all the hardware can be fitted on a single SBus card. With such an implementation, the SBus card will likely carry essential interface logic mainly. DMA data transfers on the SBus should also be implemented to increase transfer speed (especially when the splitter is receiving data). However, it is worth noting that this may not work with cards plugged in slots provided by third-party SBus expansion accessories. With these developments, the SBus interface logic will need to be quite different from that at present and the device driver will need to be re-written as well. Furthermore, the interface to the packetiser at the video codec may also be eliminated eventually. The packetiser is a separate piece of hardware interfaced to the the video codec. Thus, the eventual integration of the packetiser, splitter, and AAL/ATM layer modules for the SPARCstation is a desirable goal for the future. 8 CONCLUSION The experiences and results gained from the design of the dedicated hardware ATM cell-stream splitter, together with the development of the multi-media terminal, have proven to be rewarding and promising. The application of FPGA technology has been crucial to the development of the hardware, in providing flexibility in logic implementation and refinement. With regard to the splitter s SBus card, the progressive stages of tests were useful in identifying areas that needed improvement. It has also given opportunity for the multi-user utilities and ATM/AAL modules to use the splitter instead of the workstation s interface as a communications port. The achievement of two-point video conferencing was very encouraging and demonstrated the usefulness of the splitter. With the ability to integrate the multi-user shared workspace utilities with video, the feasibility of the overall terminal concept is now proven and we therefore conclude that there is much potential for further development

9 9 ACKNOWLEDGMENT This work was carried out as part of Telecom Research Laboratories contract no REFERENCES [1] G. J. Armitage and K. M. Adams, Creating a Multimedia Terminal, with ATM over the Desktop LAN, Proc. 3rd Australian Multi-media Communications, Applications and Technology Workshop, Univ. of Wollongong (NSW), July [2] K. M. Adams, K. E. Forward, An Experimental Broadband Integrated Services Terminal - System Overview, Proc. Australian Video Communications Workshop, Melbourne, July 1990, p [3] G. J. Armitage, K. M. Adams, Architecture of a Multimedia Desktop Workstation, Proc. Australian Video Communications Workshop, Melbourne, July 1990, p [4] K. K. L. Wong, K. M. Adams, Hardware Realization of an ATM Cell in a B- ISDN Terminal, Proc. Australian Video Communications Workshop, Melbourne, July 1990, p [5] S. Liew, K. M. Adams, Hardware Design Aspects in Implementing ATM Functions in a Multi-media Workstation, Proc. 2nd Australian Multi-media Communications, Applications and Technology Workshop, Melbourne, July 1992, p [6] K. K. L. Wong, Design of a Hardware ATM Cell for a B-ISDN Terminal, M. Eng. Sc. Thesis, December 1990, Univ. of Melbourne, Victoria. [7] S. Liew, The Design of an Interface Between a Hardware ATM Cell-stream and the System Bus of an Experimental B-ISDN Terminal, M. Eng. Sc. Thesis, December 1992, Univ. of Melbourne, Victoria. [8] K. Jenkin, Development and Specification of the Broadband Network Interface (BNI) Driver, Research and Development of an Experimental Broadband Integrated Services Terminal, Telecom Research Contract 7064, Stage 7 Progress Report, April 1993, Melbourne. [9] G. J. Armitage, K. M. Adams, Prototyping an ATM Adaptation Layer in a Multi-media Terminal, Int. J. of Digital and Analog Communication Systems, Vol. 6,. 1, Jan- Mar 1993, p.3-14, John Wiley & Sons. [10] G. J. Armitage, K. M. Adams, Implementing an ATM Adaptation Layer in a Multimedia Terminal, Proc. Australian Broadband Switching Switching and Services Symposium 91, Sydney, July 1991, p [11] G. J. Armitage, K. M. Adams, Towards Shared ATM Fibres, a Pseudo Metasignalling Protocol, and ATM LANs, Proc. Australian Broadband Switching Switching and Services Symposium 92, Melbourne, July 1992, p [12] F. Wilson, K. M. Adams, A Strategy for Multi-media Software Development in a Multi-user Environment, Proc. 2nd Australian Multi-media Communications, Applications and Technology Workshop, Melbourne, July 1992, p