[Technology Report]
Advanced VLIW Architectures Unleash Raw DSP Horsepower
A new wave of DSPs boasts a tenfold improvement in signal processing while slashing power to a new low.
Speaking of ADI's newest TigerSHARC (see "Extreme Levels of Parallelism Escalate DSP Horsepower," electronic design, Nov. 22, 1999, p. 71), the TS001 is the first implementation of this static superscalar core with VLIW benefits. With its unique ability to process 8-, 16-, and 32-bit fixed- and floating-point operations from a single engine, this highly integrated chip is targeting telecom-infrastructure applications. On board the TigerSHARC core, it integrates 6 Mbits of SRAM, four bidirectional link ports at 150-Mbyte/s transfer rates per port, a 64-bit external port with a 600-Mbyte/s data movement rate, 14 DMA channels, and 128 registers.
"Historically, programmers were constrained to one data type. Now, with the TS001, algorithms can be written in different formats to achieve the best tradeoff of speed and accuracy," says product line manager Gerry McGuire. "It provides the right combination of memory, throughput, and DSP horsepower to enable optimal system performance."
System applications may require even more processing. In that case, the links permit the designer to connect TS001 DSPs in multiprocessing configurations. ADI adds that the TigerSHARC architecture is compiler-friendly. Also, it's supported by an efficient C compiler that can deliver nearly 70% efficiency compared to hand-assembled code.
Capable of executing 1.2 billion 16-bit fixed-point MACs/s or 300 million 32-bit floating-point MACs/s, the TS001 is implemented in 0.25-µm CMOS. The initial version runs at a 150-MHz clock speed. While the core operates at 2.5 V, the I/Os are tailored for a 3.3-V supply. Faster versions running up to 250 MHz are in the works. Sampling now, the 150-MHz TS001 should go into production by year's end.
Also in this race to deliver solutions to basestation sockets, modem banks, and Internet telephony is Motorola Inc. Exploiting the 16-bit compiler-friendly SC140 DSP core, built by StarCore of Atlanta, Ga., Motorola Inc. has readied the MSC8101 network processor. The first implementation of the SC140 core, StarCore's SC140 is the result of a joint development effort between Lucent Technologies' Microelectronics Group and Motorola's Semiconductor Sector.
Similarly, Lucent Technologies also is preparing solutions derived from the SC140 core. As of press time, though, details of Lucent's derivation of the SC140 were unavailable.
Researchers at Lucent's Bell Labs have constructed a scalable bus-based platform for multiprocessing on the same chip. To evaluate this approach, four 100-MHz processing elements (PEs) and a global resource controller are connected to a 32-bit address and a 128-bit data split-transaction bus to perform 1.6 billion 16-bit MACs/s.
Employing system expertise and existing intellectual properties (IPs), Motorola has wrapped this highly parallel and scalable core with unique peripherals and functions. These include a communications processor module (CPM), an enhanced filter coprocessor (EFC), a PowerPC bus interface, a memory extension port, 512 kbits of SRAM, a 16-channel DMA engine, a serial interface unit, a programmable interrupt controller, and an emulation controller (Fig. 2).
The CPM, a RISC protocol-processing engine, supports direct connection to high-speed packetized backbone networks. At the same time, the EFC performs filtering tasks like echo cancellation. "The EFC coprocessor provides an additional 300 million MACs on top of the core's 1200 million MACs at a 300-MHz clock," explains Dave Baczewski, strategic marketing manager for Motorola's Wireless Systems Group. "Thanks to on-chip CPM and SRAM, the MSC8101's protocol algorithms can be dynamically updated to stay abreast with evolving standards and user needs." Benchmarks generated for Viterbi decoder and control code indicate the SC140's superior execution speed and program memory use (see the table).
Designed for wireless and wireline infrastructure equipment, the SC140 was fabricated in the company's HiperMOS (HiP-6) process. This procedure boasts 0.13-µm CMOS feature sizes and copper interconnects. Of the total 500-mW dissipation, the SC140 core consumes half of that used at a 1.5-V supply. Like these other designs, the I/Os operate at a 3.3-V supply. Motorola plans to sample the MSC8101 in the third quarter of this year, with production slated for the second quarter of 2001. It will be packaged in a 332-ball pad BGA.
Other versions of the MSC8101 are in the works for emerging applications. Motorola's roadmap calls for higher-speed models based on HiP-7 or 0.1-to 0.08-µm geometries. At these sizes, the core will run at 1.2 V and further cut power usage.
Development support includes an optimized C compiler that maximizes the use of parallelism and takes full advantage of the SC140's multiple execution units. In effect, it closes the gap between a high-level language compiler and hand-coded assembly language. Internal benchmarks on an enhanced full-rate vocoder for GSM indicates that the C compiler for the SC140 demonstrates high cycle performance and code density. Recently, Embedded Power Corp. unveiled a real-time operating system, known as the RTXC, for the SC140-based solutions.
According to Motorola, this compiler also will simplify migration from other architectures like the 16-bit fixed-point 56300 family. Fundamentally, the SC140 is a variable-length execution set (VLES) with explicitly parallel-instruction computing (EPIC). "It combines the best of both VLIW and superscalar architectures," explains Scott Beach, development engineer at StarCore.
While high-end DSPs are migrating toward C, the older 16-bit fixed-point generations like the 56300 continue to bank on assembly code. To further streamline existing assembly language routines, The MathWorks Inc. and Motorola have jointly developed the DSP Developer's Kit. This tool lets users verify the behavior of assembly language routines. By inserting such programs into The MathWorks' MATLAB and Simulink system-level environments, engineers can validate, modify, and test their assembly code while catching coding errors up front. They also can verify the operation of the software on cycle-accurate 56300 and 56600 simulators.
Reprints
