VoIP Design Tests Out 'GOLDEN EAR'

For IP phone silicon, a cost-competitive, single-chip solution contains the analog codec, DSP, CPU, Ethernet physical layers (PHYs) and IP phone peripherals such as USB, IrDA, a keyboard interface and UART. This high level of integration represents all of the silicon collateral required to build an IP phone and results in a low-cost bill of materials for the system supplier.

Voice quality can only be accomplished on an IP network if the voice packets are given priority processing. This can be accomplished in a number of ways. IEEE has standardized a method for guaranteeing priority to voice packets on a data network through 802.1p/q. This standard defines a tag field in the Ethernet frame that can be used to identify a frame according to its priority. In this manner, the IP phone silicon can detect if a frame is a voice frame and can pass this information on for priority processing.

The processor and memory requirements for an IP phone are directly related to the functional sophistication of the intended device. Because the DSP is used for voice processing and implementing the key echo cancellation algorithm, the selection of a processor and its memory system is related to the number and type of voice compression algorithms (i.e., G.711, G.723.1, G.729), as well as the conferencing capabilities supported. The number of machine instructions per second and amount of memory required for the DSP will be determined by these software requirements. Similarly for the CPU or general-purpose controller, software requirements for call signaling and control and needed support for standards such as H.323, SIP and MGCP/H.248 all affect the selection of the main processing element and its memory system.

The overall quality of any IP phone is judged on many criteria, some objective and some subjective. Metrics such as processor speed translate directly into millions of instructions per second, which in turn translate into the ability to accommodate more applications that enhance the system supplier's value-added proposition. The loudness of a speakerphone is also a quality metric that can be objectively measured in terms of output power and distortion. However, experience with IP phone customers has revealed that metrics such as voice quality are more difficult to measure and could be considered more important than the functional capabilities or loudness of the speakerphone.

Frequently, system suppliers test their IP phones using a golden ear This is literally a person or persons who determine if the voice quality is good enough. Voice quality can be tracked back to how the silicon handled setting priorities of voice over data and to the software in terms of how it digitized and compressed the signal and minimized latency of voice packets. Yet the golden ear ultimately determines if the system design is acceptable.

These technical requirements, combined with the anticipated high-volume market for IP phones, all point to SoC as the basis for an optimum solution. For the silicon designer, of course, SoC is the ultimate challenge. What's more, the SoC design task depends heavily on in-depth verification processes to provide "known-good" hardware for the software debugging process. Heavy use of verification in SoC design is a key ingredient to reducing the time and cost of achieving final silicon. Verification of an IP phone SoC consists of many steps, each increasing the confidence of first-pass silicon success.

Subblock verification
The complexity of an SoC design requires a divide-and-conquer approach to successfully verify the functionality of the final device. Therefore, a highly integrated silicon solution for an IP phone requires exhaustive block-level verification before top-level integration takes place. Becaus e simulation times are shorter at the block level than at the full-chip level, the designer should create many test cases to improve test coverage of the block. Commercial computer-aided design simulation tools have emerged that facilitate block-level verification.

To verify the functionality of the block, the SoC design process begins with creation of block-level simulation environments with appropriate drivers and monitors to mimic final integration. The block-level simulation environment must emulate the functional behavior of the final full chip and, in some cases, the system for which the silicon is destined. The block-level simulation environment consists of a group of drivers and monitors attached to the block for system emulation. The block drivers generate the correct stimulus for the desired test case; the block monitors keep track of the block output.

In designs that require many block-level tests, some designers develop automated test environments that assist in running the test suite wit h minimal human intervention. These automated test environments can also be designed to be self-checking so that at the completion of a test, a pass or fail is indicated by the test program. Of course, generating these automatic test environments can be rather time-consuming. It is usually done only at the block level if a large number of tests need to run on the block many times.

Block verification also involves verifying the function of each block against the relevant standards (i.e., IEEE 802.3, USB1.1). For an IP phone, several blocks within the SoC device will interface to system components that need to conform to well-defined standards. For example, the Ethernet subsystem needs to interface to an Ethernet network, the performance of which is dictated by IEEE 802.3. For block-level verification requiring conformance to standards, standards-compliant drivers and monitors need to be used. To facilitate this, many EDA tool suppliers have developed a portfolio of drivers and monitors that conform to pop ular standards such as IEEE 802.3 and USB. These verification tests can also deliver preliminary performance information.

The SoC design process should include a test plan used to guide verification of any given block. This test plan will cover all of the normal test cases associated with the function of the block. For example, to verify an Ethernet switch, tests should evaluate the block for all possible switching combinations. The plan will also cover cases that stress the block to force corner and error conditions. Unique and/or error conditions can be created easily at the block level.

By contrast, at the full-chip level the same condition may be impossible to create in simulation. Furthermore, error and corner case testing at the block level is common practice in SoC verification. This is because of the difficulty of creating true-to-life simulation environments, the impossibility of exhaustively predicting those test cases that will break the silicon in the real system and the run-times associa ted with long test cases.

The block-level test plan will usually contain some element of random testing, especially when verifying complex blocks. In the specific case of an IP phone, SoC random testing is beneficial for wringing out the Ethernet subsystem and its large number of possible data and control paths. In this example, random testing at the block level helps to determine if there are any circuit dependencies on data content and/or data packet length.

Full-chip verification
The full-chip IP phone SoC design team will create a test plan aimed at verifying the functionality of the full chip after all of the blocks have been integrated. This test plan will consist of tests aimed at evaluating critical data and control paths. For example, end-to-end data flow from Ethernet to voice codec and back will be verified. In addition to checking these critical paths, tests are developed to evaluate the integrity of the integration.

In addition to critical data and control paths, the full- chip verification process must include a simulation environment encompassing drivers/monitors and interface models (i.e., memories) to mimic system implementation. As is the case with block-level simulation, the full-chip design team must create a simulation environment for the SoC. This is more challenging because the simulation environment must emulate the system into which the IP phone SoC will be placed. Models for memories (flash, SDRAM), as well as drivers and monitors for other interfaces, should be incorporated into the testbench.

Automation is critical to full-chip SoC verification because of the large number of factors to be considered and the potential for a huge number of permutations and combinations of affects. The effect of any changes to the full-chip register-transfer-level or gate-level netlist can be quickly assessed by running a full set of regression tests. This is important for ensuring the quality of the design going into layout, because it gives the silicon designer confidence tha t he understands the effects of any changes he has made during block-level testing. For example, it is possible to intentionally make a change to the DMA controller that could have an unintended effect on the USB interface design. Regression testing that includes many USB and DMA tests may uncover any errors or problems with the intended design change.

An important requirement in the design of the IP phone is that the SoC contain both a voice processing engine (DSP) and a control processor (CPU). Hence, verification of the SoC requires simulating with dual embedded processors. This is accomplished in a series of stages with the intention of effectively and efficiently verifying both the hardware and software. At a high level of abstraction using models for the processors and the other silicon blocks, co-simulation of the software and hardware enables the CPU and DSP software to be developed effectively.

For efficient simulation of the SoC hardware, it is not necessary to run the actual CPU or DSP cod e, which for silicon verification produces an unnecessary overhead. Rather, the simulation environment for a dual-processor SoC requires the incorporation of behavioral models for the processors with code that permits configuration and setup of both processors. The verification environment must support the ability of the CPU to download boot code from either flash or SDRAM.

For CPUs that contain internal cache, running the code from internal cache also needs to be accommodated so that this path may be fully exercised. The boot code must provide setup and configuration information for the test. For the DSP, the code that is downloaded will configure the DSP and its subsystem for the test.

Depending on the level of integration, the IP phone SoC could contain a voice codec and Ethernet PHY(s). These are analog circuits that at the block level are verified using traditional transistor-level simulation techniques. At the full-chip l evel, the simulation environment uses behavioral models for these circuits to reduce simulation times and to maximize gathering of useful information. These models are incorporated into the simulation environment with wrappers that exactly match the pinout of the analog block.

Complexity issues
The nature of the VoIP application creates several complexity issues for SoC design. One involves the embedded Ethernet switch, a second-generation performance improvement on VoIP devices that were based on an Ethernet bridge. An Ethernet switch has two basic architectures: cut-through and store-and-forward. Cut-through switches require the hardware to make a switching decision in real-time as data packets are received. This is a costly hardware solution, usually associated with high-performance enterprise systems.

In contrast, a store-and-forward switch stores the entire packet in memory before making a switching decision. Although this is less-costly from a hardware perspective, it imposes some re strictions on bus bandwidth and delay parameters. In an IP phone SoC device that incorporates a switch as part of its Ethernet subsystem, the logical architecture for the switch is store-and-forward. This is due primarily to cost. The performance issues associated with a store-and-forward architecture can be overcome through design.

The Ethernet switch also has to handle setting priorities for voice packets. If 802.1p/q is supported, then the switch needs to strip out the tag field from the frame to determine its priority classification. On the transmit end, the switch likewise needs to insert an appropriate tag field in the frame so the remote end can handle the frame in accordance with its priority.

A second concern in an IP phone SoC design is system bus bandwidth-the system bus may be shared by several agents, such as the CPU, USB master, direct memory access controller and Ethernet switch. A store-and-forward architecture for the Ethernet switch affects the system bus bandwidth available to othe r agents on the bus. Other Ethernet subsystems that include an Ethernet repeater are not encumbered by the bus overhead associated with storing each frame into memory before processing. To ensure adequate bandwidth is available when using a switch, the SoC can be designed with a priority-based arbitration circuit with programmable agent priorities. In this manner, the IP phone system designer can tune the algorithm to meet the needs of the system.

One area where the design process for an SoC device may be different from complex ICs is in the testability features to help system test and debug. The complexity associated with an IP phone SoC and its software dependencies affects the ability to verify all interdependencies fully before making silicon. The real proof of functionality comes during system test and debug. The SoC designer, however, can facilitate system test and debug dramatically by embedding test circuits in the design to gain access to critical signals. The more integrated the IP phone soluti on, the more important test and debug features become in the design, because many critical interfaces are buried within the silicon. For an IP phone SoC device, access to the internals of the voice codec, DSP, DSP-to-CPU interface and Ethernet switch will influence the degree to which system test and debug can be accomplished effectively and rapidly.

Static-timing analysis is a standard task in any IC design. Such analysis can identify paths deep in the design that may be only marginally meeting or in some cases failing timing requirements. With this information, effective feedback can be given to the place and route engineers to improve the layout. Timing can also be verified through post-layout timing simulations. Timing is extracted from the physical layout and annotated onto the gate-level netlist before simulation.

IC processing corners can be validated to ensure the design is robust enough to be manufactured with high yield during the expected variation in the fabrication line. With a highly in tegrated SoC design, using an IP phone that may incorporate a mixture of hard and soft analog and digital macrocells, timing verification can validate the quality of the physical floor plan or provide valuable feedback toward its improvement.

The designer's ultimate goal-first-pass silicon success-can be accomplished only by paying careful attention to a comprehensive verification strategy. With complex SoC design this means taking a divide-and-conquer approach to verification, starting with block-level functional verification followed by full-chip functional and timing verification.

In the final stages of IC design, though, it is customary to conduct a final set of audits to provide evidence of design robustness. The combination of verification and proper audits will guarantee that the design is sound from a functional as well as a manufacturing point of view.

---

Sherre M. Staves is technical manager of voice-over-Internet Protocol IC design and John Harrington is director of silicon pro duct development at Agere Systems (Allentown, Pa.). Staves holds BSEE and MSEE degrees from Drexel University while Harrington earned a BSEE degree from Rensselaer Polytechnic Institute and an MSEE from Stanford University.

http://www.isdmag.com