A PCI-to-DSP Bridge for High-Performance DSP Systems Barry Field, Spectrum Signal Processing Inc., Canada: icspat.com
A PCI-to-DSP Bridge for High-Performance DSP Systems Barry Field, ASIC Design Engineer Spectrum Signal Processing Burnaby, BC, Canada Introduction Spurred by the ever-increasing demands of real-time signal-processing applications such as speaker-independent voice recognition, digital radio and multi-dimensional graphics processing, DSP system designers are turning to the PCI bus as a way to meet their high bandwidth I/O requirements. Interfacing to the PCI bus, however, is not a trivial task: in order to guarantee reliability at high speeds, the PCI protocol imposes strict signaling rules and tight timing requirements on bus interface chips. Rather than undertake the task of designing their own interface to the PCI bus, most board designers utilize the abundance of cheap interface silicon made available by PCI's predominance in the desktop market. Unfortunately, these interface chips still require a significant amount of glue logic and design effort to incorporate them into DSP architectures, simply because they were never intended to interface to DSPs. High-performance DSP systems require a PCI-to-DSP (PDSP) bridge designed to accommodate the unique requirements of digital signal processors and the algorithms that they implement. PCI The PCI (Peripheral Component Interconnect) Local Bus was originally developed to service PC expansion cards, meet the high-bandwidth requirements of PC graphics, and replace existing limited bus architectures. In its most common form, the PCI bus is implemented as a synchronous 32-bit/33 MHz multiplexed address/data bus. Hooks have been provided for extension of the standard to 64 bits, and eventually, to 66 MHz. Data transactions are performed by linear bursting. The first phase of a burst contains the address and command (read or write), with subsequent phases containing data. Because data transactions can occur on back-to-back clock cycles, the PCI bus is capable of transferring data at a rate of 132 Mbytes/s (at 32 bits and 33 MHz). PCI is also self-configuring - every PCI interface chip is required to implement configuration registers that provide auto-initialization information for host software. Arbitration on the PCI bus is access-oriented (not time-slice) and provides low-latency guarantees for real-time devices. A central resource arbitrates among the PCI bus agents, allowing multi-master peer-to-peer communication. A PCI "master" is defined as any bus agent that initiates a transaction. It follows that a PCI "slave" is any agent that is the target of a transaction initiated by a PCI Master. Finally, because the PCI protocol was defined with the goal of establishing an industry standard local bus architecture, it is processor-independent. PDSP Bridge The goal of any bus interface chip is transparent integration of the buses on either side of the IC. A well-designed bridge will
========================
Higher Data Throughput over POTS Stephane Gagne, Spectrum Signal Processing Inc., Canada: icspat.com
Abstract This paper presents an improved V.42bis en-coding scheme which is fully compatible with the standard V.42bis decoders. Moreover, we give an optimal algorithm for an underspecified section of the standard and suggest some exten-sions to further improve the performance, in terms of compression ratio. 1. Introduction While attempting to get higher data rates over plain old telephone systems (POTS), engineers have devised more and more complex modulation/demodulation tech-niques. Not so long ago, we thought 28800/33600bps (V.34/V.34+) to be the best rate we could ever achieve; only to be sur-prised with the introduction of a new 56000bps technique. Given the current sampling achieved by the POTS, we are un-likely to see this number increase much (if at all). How are we then, to provide higher throughput for low cost systems? .It is time to revisit some of the other aspects of the current modem technology. Part of the solution might come from data compression. No major breakthroughs were made in the field of lossless data compres-sion since before the introduction of V.42bis[1]. (Though there has been some innovative approaches such as that of Bur-rows and Wheeler[3]). We could, nevertheless, find a number of ways to increase the compression rate. Some of them consuming many more MIPS 1 than V.42bis or having some weaknesses 2 not found in the latter. Processing power, though of concern, should not be the main 1 Million instructions per second. 2 See [2] for a review on the topic.problem here; it has been seven years since the V.42bis recommendation has been pub-lished. As for weaknesses, they would re-quire a significant study (on a case by case basis); but the gain in compression for the general case might be worth them. What might prevent these other techniques from being adopted is the rather modest gain obtained versus the troublesome and time consuming process of going through a new standard ratification. As we shall demon-strate, there is still a way to make some pro-gress nevertheless. N.B. For the sake of conciseness, we assume the reader is familiar with V.42bis and com-pression techniques in general. [1], [4] and [5] might be useful, either to refresh your memory or become acquainted with the above topics. 2. Current V.42bis standard Current V.42bis implementations can distin-guish themselves in two respects 3 : ú Heuristic for deciding when to switch from transparent mode to compres-sion mode and vice versa. ú Heuristic for deciding when to discard the transmission diction-ary. As Thomborson[2] noted, modems with a better compression ratio will use a better heuristic. This now proves to be true more than ever before. Most people are now us-ing their modem to access the Internet. To do so, they need to run a PPP 4 stack on their host. Several connections are thus being 3 Notwithstanding the dictionary size and the maximum string length. 4 Point-to-Point Protocol; Alternatively SLIP can be used.Higher data throughput over POTS St‚phane Gagn‚ Spectrum Signal Processing Inc. Burnaby, British Columbia, Canada e-mail: Stephane_Gagne@SpectrumSignal.com |