SoC eyes VoIP appliances

SoC eyes VoIP appliances
By Doug Chisholm, Chief Consulting Engineer, Tality Corp.,San Jose, Calif.,, EE Times
October 4, 2001 (4:07 p.m. EST)
URL: http://www.eetimes.com/story/OEG20011004S0109

As the growth in consumer electronics shifts from the PC to wireless devices, the next killer app could well be the porting of voice communications to the Internet. Although users could experience some degradation in voice quality carried over the Internet Protocol compared with cell phones and land lines, the growing frustration with excessive roaming charges for users on the move could easily outweigh those concerns. The added benefit of voice capabilities concurrent with data transmission would also enable wireless shoppers to interact with vendors through PDAs, helping to overcome the limitations to mobile commerce inherent in small screens.

In a highly competitive market where appliances are to be sold to cost-conscious consumers, every opportunity for cost savings must be exploited. Our solution is to create a complete system-on-a-chip (SoC) to achieve a significant cost reduction in the bill of materials and to ensure a streamlined manufactur ing cycle.

The most obvious savings can be gained by greater integration into a single-chip SoC. But it would be too risky to further integrate the analog functions, such as the codecs, into the same SoC. Available embedded RISC and DSP cores, however, can be used to meet the requirements of the vocoder, modem, voice packetization and Internet Protocol software. These requirements include computational performance, code size and data size.

It was also important to analyze the buffering requirements for the voice-over-Internet Protocol (VoIP) device. For example 30 milliseconds (240 samples) of uncompressed speech can be stored in 480 bytes of memory. But excessive buffering will introduce latencies.

One of the bonus features of an Internet appliance is that it is amenable to upgrades via the Web. For this reason, it is important that the hardware design offer a flexible, glueless memory interface, serial interfaces and the usual microcontroller peripherals required by a typical embedded system. < P> It is widely accepted that intellectual-property (IP) reuse is fundamental to SoC design. Commercial issues such as cost, availability, time-to-market and risk reduction dictate that reusing IP in developing a new device is critical to a successful design project. For these reasons, this VoIP appliance design project would integrate the many forms of intellectual property — software IP, hard-silicon cores and soft-silicon IP. This intellectual property would be sourced from third parties, the design client and in-house. While the advantages of reuse far outweigh the disadvantages, each type and source of IP presents different challenges.

Soft-silicon IP is subject to feature creep and is also subject to manipulation by the ASIC design flow such as synthesis, scan and clock insertion. Such operations essentially flatten the IP's potential, negating the benefits of the reuse. It is essential that the reused IP be robust enough to withstand integration.

The case with hard IP such as RISC and D SP cores is more clear-cut and offers several advantages. Cores can be reused without modification and sometimes offer efficient simulation models. At the same time, however, it is essential that they be supplied with sufficient design views for timing, simulation and physical-layout tools.

It is also widely accepted that starting software development and integration after the receipt of silicon prototypes is a luxury. This approach increases time-to-market and is foolhardy because any fundamental software/hardware integration problem will be caught late in the design cycle and cause even greater delay.

For these reasons we advocate a hardware and software co-development approach. Hardware/software co-development not only reduces project time scales but also validates the system architecture — in particular, real-time software behavior. For this particular VoIP device, we propose using a 0.35-micron three-layer-metal CMOS chip. An uncached ARM7TDMI using this technology will run at 40 MHz.

The Mips (millions of instructions/second) requirement for the application software is less than the headline performance of the ARM processor, so it is possible to balance the processor frequency with the memory bandwidth. The selection of a lower operating frequency of about 24 MHz would allow the CPU to execute from 60-nanosecond DRAM. The memory interface would be designed to support different widths of external memory (thus reducing chip count and cost) and a variety of flash, SRAM and DRAM devices.

The computational nature of G.723.1 and V.34 lend themselves to implementation on DSP cores with single-cycle multiply-accumulate operations. The Oak DSP core has a typical operating frequency of 40 MHz in 0.35-micron technology. Thus, the DSP software would require two Oak cores to deliver the necessary Mips performance.

The hardware architecture should be designed to reflect the natural partitioning of the software. This allows the modem software to execute on one DSP and the vocoder software on a nother, identical DSP. However, the required DSP performance will not tolerate wait states, so it is necessary to integrate large program and data RAMs. It would also be possible to deeply embed the DSP cores, lowering both chip count and pin count. Deeply embedding the Oak cores, however, would make testing and debugging the system more difficult.

The most important feature of a multiprocessor system is the communication between the processors. For this VoIP system the necessary bandwidth between the ARM and Oak processors would be relatively low. For this reason, communications between the processors can be provided by means of dual-port-mailboxes. These mailboxes can be built from logic semaphores and dual-port-RAM. The semaphores could be configured to support multiple channels and be implemented to be interrupt-driven or polled.

The mailbox is more powerful than a simple FIFO and could support three modes of operation: transparent code or data download, asymmetrical data exchange and interactive message passing. The mailboxes could also facilitate debug between the Oak and the ARM processors.

On power-up, the ARM could boot from a serial line or from external flash. During power-up the ARM would be designed to download the initial code and data to the Oak subsystems. During a telephone call, voice data would be transferred between the processors by means of the mailbox.

The most complex and time-consuming task of SoC development is probably functional verification. The most obvious approach to functional verification is to execute the application on the hardware model. This can be prohibitive, however, in terms of both simulation time and the availability of the software that is being co-developed. Instead it is better to write a verification test suite and testbench. The verification test bench must be incrementally constructed from a model of the SoC and its environment that includes both memory models and emulation of external communication devices and events.

When designing a CPU-ba sed SoC, tests can be written in software and made self-checking. External devices can be programmable, memory-mapped peripherals. For example, serial messages can be read back from parallel devices and vice versa. Care must be taken, however, because this technique is susceptible to common-mode failures.

Such a testbench can be re-used for both register-transfer- and gate-level simulation. Test patterns can be captured at RTL and replayed at gate level for dynamic timing closure. Other forms of tests may also be applied such as those "canned" patterns typically supplied with hard intellectual property.

The software-development tool chain can also be reused when writing the self-checking test suite. These tests can be written in C or assembler and are about as complex as device drivers. We've found that it is quicker and easier to write and debug tests that exercise particular functions or features rather than test a complete application. Synthetic tests can also be written to emulate the bandwidth and latency behavior of the SoC.

The testbench can also be used to generate log files for regression testing during the development cycle. However, despite the advent of tools for code coverage, functional verification is still more of an art form than a science.

Our experience has shown that it is possible to design a single SoC for a single-user VoIP application. In the future this technology can be readily integrated into new Internet appliance products such as PDAs.