Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Spectrum Signal Processing (SSPI) -- Ignore unavailable to you. Want to Upgrade?

To: pat mudge who wrote (440)	1/4/1998 7:59:00 PM
From: Galirayo	Read Replies (3) \| Respond to of 4400

Multi-Channel Data Communications on Fixed-Point DSP Architectures Stuart Harker, Arda Erol, Spectrum Signal Processing Inc., Canada: icspat.com Abstract This paper will discuss some of the require-ments and issues surrounding the implementa-tion of multi-channel communications on fixed-point architectures. Topics include: spawning, task switching synchronization, and MIPS and memory constraints. The impact of multi-tasking and load-balancing will be examined, as well as, advantages and disadvantages of the Texas Instruments TMS320C6x architecture. Introduction Current high density multi-channel data communications solutions rely on an array of discrete DSP devices, each handling a single data stream. As more powerful DSP architec-tures, such as the TMS320C62xx, become avail-able, multi-channel communications solutions on a single DSP device become possible. To allow developers to create effective solu-tions, robust architectures need to be supported. At the heart of a multi-channel design is the DSP Real-Time Operating System (RTOS). The DSP RTOS ensures real-time deliverables, re-entrancy of algorithms, and efficient resource usage. The DSP hardware architecture and DSP software structure also impact the overall system performance. The system elements to be considered in the multi-channel system can be broken into exter-nal and internal components. The internal con-siderations of the RTOS, namely, spawning, task switching, synchronization, MIPS, and memory management will be addressed after the external elements, such as the signaling bus environment and the DSP platform.Signal Computing System Architectural Overview The move from a single pump design to a multi-channel implementation, requires a num-ber of additional hardware and software compo-nents to multiplex and distribute the communi-cation data stream. Multi-channel CT (Computer Telephony) systems are usually set up to interface with a number of T1 lines on the PSTN. A T1 line consists of 24 DS0 channels multiplexed into 125 ms frames. These lines are handled by a line interface card (see Figure 1), and are sent onto a communications bus, such as SCbus 1 or MVIP 2 . Hardware definition and software control of these buses are handled by SCSA, the Signal Computing System Architecture. The SCSA consists of openly defined, modular hardware and software computer ele-ments. These include multi-vendor/multi-resource application components, a specialized Time Division Multiplexed (TDM) bus, high-level, APIs (Application Programming Inter-faces) and lower-level hardware SPIs (Service Provider Interfaces). It can be divided into the SCSA Hardware Model and the SCSA Teleph-ony Applications Objects (TAO) Frameworks. 1 Copyright 1994 Dialogic Corporation 2 Copyright 1994 GO-MVIP Inc.Multi-channel Data Communications on Fixed-Point Architectures Stuart Harker Spectrum Signal Processing Inc. Burnaby, British Columbia, Canada email: Stuart_Harker@spectrumsignal.com

To: pat mudge who wrote (440)	1/4/1998 8:20:00 PM
From: Galirayo	Read Replies (2) \| Respond to of 4400

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

To: pat mudge who wrote (440)	1/4/1998 8:29:00 PM
From: Galirayo	Respond to of 4400

Interfacing a DSP-Based Multi-Purpose Telephony and Audio System to a Digital PBX Clement Wong, Spectrum Signal Processing Inc., Canada: icspat.com INTERFACING A DSP-BASED MULTI-PURPOSE TELEPHONY AND AUDIO SYSTEM TO A DIGITAL PBX Clement Wong Spectrum Signal Processing Inc. Burnaby, British Columbia, Canada Introduction This paper presents a hardware/software system that interfaces a Mwave DSP-based multi-purpose telephony and audio card to a NorTel digital PBX 1 with an ISDN-like data stream. The hardware addresses the issues of how to convert the PBX's digital data stream into a form that is understandable by the DSP and its output devices. If this conversion process was done on the DSP, it would occupy MIPs and memory that can be used for other tasks. The DSP itself is responsible for controlling data flow throughout the hardware, to process the signal and control data, and to communicate telephony and audio data between the host and the PBX. This system uses a software architecture that balances the processing load between the DSP and host. The DSP software deals with time critical tasks which include processing input data, outputting data to the appropriate ports, and interfacing with the host. Configuration and control of peripherals is a non-time critical task of the DSP. On the host, the software architecture allows higher-level applications to interface to the hardware through simple function calls. This allows programmers without an intimate knowledge of the hardware to design an application that utilizes the features that this system provides. For this system, Spectrum Signal Processing (SSP) and NorTel worked together to design a hardware and software platform to realize a fully integrated computer telephony system. IBM Mwave provided a major portion of the DSP and Host software as well as the reference hardware design for the Mwave DSP chipset. 1 Private Branch Exchange General Overview of the Mwave System The IBM Mwave system integrates the Mwave DSP with a software architecture that allows the hardware to contain a minimum number of memory chips; consequently, lowering the cost of producing the hardware. Being geared for multi-media applications, IBM has designed ports within the Mwave DSP that interfaces to telephony and audio hardware. IBM provides the BIOS code for these ports along with proprietary software for a v.34 modem, audio functionality, and UART emulation. Figure 1 illustrates the software architecture of the Mwave system. Mwave Application Mwave Device Drivers Mwave Manager Mwave Operating System Mwave DSP Tasks Application Programming Interface Host Code DSP Code Figure 1. Mwave Software Architecture The Mwave Device Drivers interpret calls from the Mwave Application program and make the correct Mwave Manager calls to control the DSP. The Mwave Manager provides a hardware independent interface to the Mwave Device Drivers, but contains ahardware specific component with direct links to the DSP. This component has the capability of accessing data memory, unloading and loading tasks, and performing other DSP resource management tasks. Programmers can modify this hardware specific component for compatibility with different variations on the Mwave hardware reference design. The Mwave OS is responsible for scheduling the various tasks that may run concurrently on the DSP at any given time. Finally, the Mwave Hardware Tasks perform the fax, v.34 modem, and audio functionality. One of the major features of this system is the use of the host PC. Unlike other modems that require non-volatile memory to store modem software, the Mwave system stores all of its modem software and data on the Host PC's hard drive. When the user starts the Mwave system, it will only load the OS and its associated hardware BIOS tasks onto the DSP. Only when the user initiates a modem call or a fax call does the Mwave Manager load the appropriate DSP tasks. In contrast, typical "off-the-shelf" modems already have all of its modem software loaded even if the user has not initiated a modem call. By utilizing the relatively large storage space afforded by the host PC's hard disk, the cost of manufacturing a Mwave-based hardware design is more cost effective due to the use of less memory chips. The System Hardware Architecture For this system, the major challenge to SSP hardware designers was interfacing the Mwave DSP to a digital PBX. The hardware design contains several major blocks: the NorTel chipset, a SSP custom ASIC, the Mwave DSP, audio hardware, and a MVIP 2 interface. Figure 2 presents a high-level view of the hardware architecture used to interface with the PBX. Data from the PBX first passes through the NorTel chipset, proceeds to the SSP ASIC, and then arrives at the DSP. 2 Multi-Vendor Integration Protocol. A standard used in the computer telephony field to provide a method of communication between two platforms from different vendors. See www.mvip.org for more information.NorTel's chipset directly interfaces to the PBX and a telephone set. Due to the multi-channel characteristic of the ISDN-like data stream, each channel can contain different data. For example, channel B1 3 could contain modem data and B2 H.320 4 videoconferencing data. The SSP ASIC designed for this system solves the problem of how to route the data to the appropriate hardware blocks. The tasks in the DSP processes this data based on commands from host applications. Mwave DSP Audio Hardware SSP Slot Router ASIC MVIP Interface NorTel PBX Interface Chipset Videoconferencing Hardware NorTel PBX NorTel Telephone Set Figure 2. Hardware System Block Diagram This SSP ASIC can be thought of as a railyard and the DSP as the controller responsible for routing the trains to different destinations based on higher level information. Therefore, the DSP, based on information from higher level host applications, controls the SSP ASIC to route data to the correct peripherals. The SSP ASIC also serves as a gateway to controlling the NorTel chipset. Additionally, the SSP ASIC processes the ISDN-like data stream from the NorTel chipset into a form understood by the hardware components on this system. Initially, SSP considered performing these "bit-bashing" operations on the DSP. Unfortunately, there are not enough MIPs, data storage, and instruction storage on the DSP to perform the "bit-bashing" task in addition to the BIOS, modem, and audio tasks. As a result, SSP designed the ASIC to include bit-level manipulation of the ISDN-like data stream. 3 ISDN data is typically divided up into different timeslots. For example, an ISDN data stream can be described as being 2B+D. This means it contain 2 B-channels for streaming raw data and 1 D-channel for streaming control data. Refer to [3]. 4 An ITU-T videoconferencing recommendation. Refer to [2]. Figure 2 shows a MVIP interface for communication with videoconferencing hardware. The MVIP interface on the hardware affords this system the flexibility to interface to other systems compliant with the MVIP standard. The System Software Architecture As mentioned in the hardware description, the most significant difference between the reference design provided by IBM and SSP's PBX-based system was digital telephony versus analog telephony. This presented a challenge to the SSP software engineers because the PBX-based system required modifications to the telephony BIOS. Additionally, requirements stated that the host software must be TAPI-compliant 5 . As a result, a software layer was written by SSP to interface with the NorTel written TAPI-compliant software layer . Figure 3 illustrates the modified software architecture required to interface with a digital PBX. In Figure 3, the SSP layer was written to communicate to the NorTel written TAPI-compliant layer. The SSP software layer provided a generic interface to NorTel for controlling the hardware. In this way, NorTel did not require any knowledge specific to interfacing with the Mwave DSP; consequently, enabling NorTel to focus on their TAPI application and SSP to focus on the lower level software layers. At the other end, the SSP software layer interfaces with the SSP modified Mwave Manager. As mentioned in the Mwave section of this paper, the Mwave Manager contains a hardware specific component along with the hardware independent API. SSP modified the hardware specific component for compatibility with this system's hardware platform. 5 Telephony Application Interface. An API defined by Microsoft allowing TAPI-compliant application to command hardware such as modems and audio hardware.NorTel TAPI Compliant Device Driver SSP Modified Mwave Manager Mwave Operating System SSP & Mwave DSP Tasks SSP/NorTel Defined Application Programming Interface Mwave Device Drivers SSP DSP Services Layer Host Code DSP Code TAPI Compliant Application Figure 3. System Software Architecture As an example to illustrate the software architecture, suppose a user initiates a v.34 modem call through a TAPI-compliant modem application. When this happens, the NorTel software layer detects the event and makes the appropriate calls to the SSP software layer. In turn, the SSP software layer issues the appropriate Manager calls to load the DSP tasks required for a v.34 modem connection. At the DSP level, to interface Mwave's DSP software to a digital PBX, SSP re-configured the front-end of Mwave's analog telephony BIOS. Figure 4 presents a block diagram illustrating the DSP tasks written to ensure that the existing Mwave telephony software can be kept intact even for a digital telephone line. SSP Slot Router ASIC NorTel PBX Interface BIOS MuLaw Encoder and Decoder Task Rate Converter Task Mwave Analog Telephony BIOS Hardware DSP Other Telephony Related Tasks Figure 4. Telephony BIOS Modification for Interfacing to a Digital PBX The SSP PBX telephony BIOS designed to interface with the SSP ASIC divides the ISDN-like data stream into B-channels and D-channels 6 . Processing of the B-channels depends on commands from the high-level host application. For example, commands issued by an audio application causes the loading of DSP tasks responsible for processing audio data and streaming it to the audio codec. On the other hand, the PBX telephony BIOS streams D-channel data to the NorTel software layers for interpretation. After interpreting these commands, the NorTel software makes the appropriate calls to the SSP software layer. Mwave's analog telephony BIOS expects unencoded telephony data sampled at 9600Hz. The NorTel PBX samples analog telephony data at 8000Hz and performs mulaw encoding and decoding. Because of this, SSP wrote the rate converter 7 and mulaw encoder/decoder shown in Figure 4. As well, because Mwave's telephony BIOS no longer directly interfaces with the hardware, its front-end was re-configured to interface with DSP tasks rather than a hardware I/O data buffer. Because this new software architecture interfaces a modified analog telephony software architecture to a digital PBX, it caused some problems with the modem's echo canceller. The v.34 and v.32bis modem's echo canceller has been designed by Mwave to expect a specific echo round-trip delay. Because the new DSP tasks increased the echo 6 D-channel data usually contains commands to perform functions like bringing a telephone set off hook or DTMF dialing. 7 The rate converter uses a polyphase filter. Refer to [1].round-trip delay, the v.34 and v.32bis modem malfunctioned. To decrease the echo round-trip delay back to an acceptable value, SSP integrated the rate converter and the mulaw encoder/decoder into the PBX telephony BIOS and then increased the frequency at which the OS schedules the BIOS task. Conclusions To interface to a digital PBX, SSP designed a hardware system containing several major blocks: the NorTel chipset, a SSP custom ASIC, the Mwave DSP, audio hardware, and a MVIP interface. The major functions of the SSP custom ASIC include routing data to the hardware components, controlling the NorTel chipset, and performing the bit-level manipulation of the ISDN-like data stream. Although the DSP could have performed the "bit-bashing", its resources were more effectively utilized for the various telephony and audio DSP tasks. After modifying and adding to the existing Mwave software architecture, SSP was able to design a software system that allows a TAPI-compliant application to utilize the features of the Mwave DSP. SSP modified Mwave's analog telephony BIOS to interface to a digital PBX through SSP's PBX telephony BIOS, rate converter, and mulaw encoder/decoder tasks. On the host, SSP added a software layer to communicate to NorTel's TAPI-compliant software layer. At the other end, the SSP software layer interfaces to the existing Mwave architecture; consequently, allowing NorTel to concentrate on their TAPI application without having to become intimate with the Mwave software architecture. In summary, this system represents a Mwave DSP-based computer telephony solution that allows the user to interface to a digital PBX through a desktop personal computer with full fax/modem, voicemail, videoconferencing, and various audio capabilities. This is particularly advantageous in companies with a digital PBX-based telephone system. References [1] Crochiere R.E. and R.R. Rabiner. 1983. Multirate Digital Signal Processing. Englewood Cliffs, New Jersey: Prentice-Hall, Inc. [2] ITU-T Recommendation H.320. March, 1993. [3] Stallings W. 1995. ISDN and Broadband ISDN with Frame Relay and ATM, Third Edition. Englewood Cliffs, New Jersey: Prentice-Hall, Inc. [4] Intermetrics, Inc. 1993. Mwave Developer's Toolkit: Application Developer's Guide.

To: pat mudge who wrote (440)	1/4/1998 8:41:00 PM
From: Galirayo	Respond to of 4400

Efficient Resource Management and MIPS Breakdown of a V.34 Modem Software Implementation Helen Dorbolo, Spectrum Signal Processing Inc., Canada: icspat.com Pat, All of these files have Cool Diagrams that I can't copy over to SI. You may want to get copies from SSPIF. Ray Introduction Utilization of digital signal processors to imple-ment fax and modem datapumps in software has been an instrumental development in reducing cost and providing a flexible platform for future upgrades. To remain competitive in the modem market, designers must implement high performance communication algorithms in a cost effective manner. The accommodation of the V.34 stan-dard, (and following V.34+) necessitates ob-taining the most out of conventional DSPs. To this end, designers must aim at reducing the MIPS usage, and the overall memory require-ments of the system. Because of the limited amount of internal RAM on most low-cost DSP chips, and the increasing complexity of modem algorithms, it is becoming difficult to fit all the code for intensive real-time applications within the internal memory of the DSP itself. Also, in the interest of code mainte-nance, upgradability, and shortening the design cycle, it is more effective to have parts of the code in a high-level language. However, the re-sulting assembly code (using a cross-compiler) would not be ideally optimized, and therefore may not fit in internal memory. To run this code from external memory would require expensive external RAM (with low access time) in order to keep the MIPS usage low. An alternative cost effective solution is to use the DMA capabilities of the DSP to load seg-ments of the code into internal RAM before they are required to be executed. In this way it is pos-sible to store part of the code on [low speed] external RAM or ROM. This paper presents the implementation of a V.34 modem algorithm organized to accommo-date efficient use of memory overlay. The mo-dem has fax capability and also implements the older standards to resume compatibility with older modems; but we will discuss the V.34 case since it is the bottleneck with respect to MIPS consumption and code size. Hardware Overview The block diagram of the hardware is shown in Figure 1. The DSP itself includes instruction and data RAM, a UART core, voice and telephony CODEC interfaces, PCMCIA and ISA inter-faces, and DMA controllers. The external mem-ory is comprised of 128k X 16 ROM, and 32k x 16 SRAM. The core is a 16 bit, fixed-point DSP, running at 50MHz, with a full Harvard archi-tecture. Of special interest to the DSP programmer is the instruction DMA controller on the DSP. It is used to copy blocks of instruction code from external into internal RAM. Until the copy has been completed the instructions will execute from external RAM. Once the copy has been completed any instruction fetches within the range of address of the given block will be exe-cuted from internal RAM instead of external. This process effectively converts the copied code block from external multiple wait state memory to internal zero wait state memory. Although the DMA controller operates transpar-ently to the software, if the DSP core and the DMA controller are accessing external memory simultaneously both processes will be slowed down, possibly resulting in a MIPS overflow. In this case it becomes necessary to make the DSP wait till the DMA transfer is complete.Efficient Resource Management and MIPS Breakdown of a V.34 Modem Software Implementation Helen Dorbolo Spectrum Signal Processing Inc. Burnaby, British Columbia, Canada email: helen_dorbolo@spectrumsignal.com DSP Core IRAM Read and Write Paths External Memory Interface SRAM 32k x 16 ROM 128k x 16 PCMCIA and ISA Interfaces Config Registers DMA Controller 16550 UART Logic CODEC Interface 2 CODEC Interface 1 Telephony CODEC Voice CODEC DSP Boundary 16550 on Host (standalone)Host Bus CACHE Data RAM 2 Port RAM Figure 1. DSP Architecture Software Architecture To reduce system costs, slow external ROM de-vices were chosen to store all of the modem/fax code. The complication that arises is that the DSP requires excessive wait states to access 16 bit data from the ROM. In addition, the DSP core instructions are 32 bits wide, and approxi-mately three instructions are required to piece together the two 16 bit sections. Therefore the total access time per instruction from ROM is even greater than data. This latency makes exe-cuting code from the ROM impossible for all but the most non-time-critical modules. The bulk of the datapump code is written in as-sembly language. For the purposes of the algo-rithm flow the datapump code is divided into two distinct segments: Analog (V.34 core), and Digital. The analog code block performs the following functions on the transmit side: modulation, near and far end echo estimation, non-linear encod-ing, and adaptive pre-emphasis. It performs the following functions on the receive side: de-modulation, equalization, timing recovery rou-tines, retrain and rate re-negotiation detection. Servicing the interrupt routine is considered part of the analog datapump. The interrupt routine reads from and writes data to the codec, removes the estimated echo, and performs the Hilbert transform on the received data. It also estimates the echo canceller coefficients during hand-shaking. The digital code block performs the following functions on the transmit side: scrambling, trellis encoding, shell mapping, framing, constellation shaping, and pre-coding. It performs the fol-lowing functions on the receive side: descram-bling, Viterbi decoding, de-shell mapping, and inverse pre-coding. For an in-depth discussion of the details of the V.34 algorithm the reader is referred to [1]. The datapump MIPS usage was measured during a 4800b/s connection at 3200 baud. The break-down is as follows: Code Block MIPS Usage Digital Receive 11.7 Digital Transmit 6.5 Analog Receive 5.6 Analog Transmit 4.3 Interrupt Service Routine 1.6 The modem uses the V.42bis and MNP5 1 proto-cols for data compression; for error correction the V.42 and MNP2-4 standards are used. The bulk of this code is written in C and cross-compiled to run on the DSP. As mentioned earlier, running the code from external ROM is not feasible because of exces-sive wait states. Because the internal 0 wait state RAM is far smaller than the ROM, blocks of code must be transferred to internal RAM when they need to be executed. To make efficient use of the internal instruction memory the code must be structured into fixed sized blocks of related functions. The compo-nents of each block are determined beforehand by carefully studying the different states of the algorithm. Each block is given a unique block number. The DMA controller will transfer in one block per call. The algorithm is structured into unique states where each state of the modem is characterized by the blocks of code which must reside in in- 1 MNP is a trademark of MicrocomDSP Core IRAM Read and Write Paths External Memory Interface SRAM 32k x 16 ROM 128k x 16 PCMCIA and ISA Interfaces Config Registers DMA Controller 16550 UART Logic CODEC Interface 2 CODEC Interface 1 Telephony CODEC Voice CODEC DSP Boundary 16550 on Host (standalone)Host Bus CACHE Data RAM 2 Port RAM Figure 1. DSP Architecture Software Architecture To reduce system costs, slow external ROM de-vices were chosen to store all of the modem/fax code. The complication that arises is that the DSP requires excessive wait states to access 16 bit data from the ROM. In addition, the DSP core instructions are 32 bits wide, and approxi-mately three instructions are required to piece together the two 16 bit sections. Therefore the total access time per instruction from ROM is even greater than data. This latency makes exe-cuting code from the ROM impossible for all but the most non-time-critical modules. The bulk of the datapump code is written in as-sembly language. For the purposes of the algo-rithm flow the datapump code is divided into two distinct segments: Analog (V.34 core), and Digital. The analog code block performs the following functions on the transmit side: modulation, near and far end echo estimation, non-linear encod-ing, and adaptive pre-emphasis. It performs the following functions on the receive side: de-modulation, equalization, timing recovery rou-tines, retrain and rate re-negotiation detection. Servicing the interrupt routine is considered part of the analog datapump. The interrupt routine reads from and writes data to the codec, removes the estimated echo, and performs the Hilbert transform on the received data. It also estimates the echo canceller coefficients during hand-shaking. The digital code block performs the following functions on the transmit side: scrambling, trellis encoding, shell mapping, framing, constellation shaping, and pre-coding. It performs the fol-lowing functions on the receive side: descram-bling, Viterbi decoding, de-shell mapping, and inverse pre-coding. For an in-depth discussion of the details of the V.34 algorithm the reader is referred to [1]. The datapump MIPS usage was measured during a 4800b/s connection at 3200 baud. The break-down is as follows: Code Block MIPS Usage Digital Receive 11.7 Digital Transmit 6.5 Analog Receive 5.6 Analog Transmit 4.3 Interrupt Service Routine 1.6 The modem uses the V.42bis and MNP5 1 proto-cols for data compression; for error correction the V.42 and MNP2-4 standards are used. The bulk of this code is written in C and cross-compiled to run on the DSP. As mentioned earlier, running the code from external ROM is not feasible because of exces-sive wait states. Because the internal 0 wait state RAM is far smaller than the ROM, blocks of code must be transferred to internal RAM when they need to be executed. To make efficient use of the internal instruction memory the code must be structured into fixed sized blocks of related functions. The compo-nents of each block are determined beforehand by carefully studying the different states of the algorithm. Each block is given a unique block number. The DMA controller will transfer in one block per call. The algorithm is structured into unique states where each state of the modem is characterized by the blocks of code which must reside in in- 1 MNP is a trademark of Microcomdatapump handshake has been completed if ei-ther modem detects a significant change in the line conditions. The response time must be within the tens of milliseconds. The difficulty arises because these states require the handshaking code to run from internal mem-ory. Therefore the handshaking code must be loaded in, overwriting the data compres-sion/ error correction code. After the retrain or rate re-negotiation is complete, the data com-pression/ error correction code must be reloaded. The procedure will be explained in more detail below. V.34 Retrain: Before starting the retrain, the block numbers of the last three blocks of internal RAM are saved in a buffer. The retrain preamble includes a si-lence period of 75ñ5ms. During this time the handshaking code (for the V.34 Initialization state) is loaded in internal memory. After retrain is complete, just as at the end of handshaking, code for the last three blocks of internal RAM must be loaded in according to the block numbers that have been saved. The prob-lem in this situation is that the datapump will start to make calls to error correction/data com-pression code immediately after retrain is com-plete. This could cause a MIPS overflow since this code is still in external ROM and will need to be transferred into internal memory. To avoid this situation, after completion of the retrain the function pointers for the error correction/data compression code will be reset to alias functions which will do nothing. After the DMA is com-plete the function pointers will be reset; this process is transparent to the datapump. The data packets sent and received during the DMA time will have to be resent by both sides, and this will lower the throughput, however this will not be significant compared with the total loss of throughput resulting from the retrain. V.34 Rate Re-negotiation This state is similar to the retrain state above, except that instead of starting from the first handshaking state, the modem will enter the last handshaking state, V.34 QAM Handshake.Summary In this paper we have discussed an implementa-tion of the V.34 modem which reduces the amount of internal RAM required on the DSP. This is done by using low speed external ROM to store the fax/modem code, and taking advan-tage of the DMA capability of the DSP to load blocks of code into internal memory as they are required by the algorithm. This requires thor-ough understanding of the modem algorithm flow and careful planning for the modem state transitions. Another advantage of this implementation is that it reduces code optimization time since only the most resource intensive state (which in this case is V.34 + V.42 +V.42bis) will be optimized to fit in the internal RAM. The other cases (which includes older modem standards) will not have to be optimized as much because while they are not used they are not taking space on valuable internal RAM. References [1] ITU-T Recommendation V.34, September 1994.