To begin with, communications applications are inherently stream-oriented. Even though the data may be organized as packets or cells, the signals entering and leaving the system are analog streams. Hence some parts of the system-and, by inference, of the system-level IC-have to operate at a sufficiently high frequency to receive or transmit these analog signals. And the signals have to be accurately framed and passed through serial/parallel conversion. Trivial for 10-Mbit Ethernet, this becomes a very serious concern by OC-192, imposing decisions on the design team as fundamental as choice of materials and processes, and as detailed as choice of RLC extraction tools.

Less obvious is the mismatch between our register-transfer model of digital design-which was, after all, imposed by tool developers, not acclaimed as a good model of digital systems-and the demands of stream-oriented traffic. Our underlying methods of decomposing systems into blocks of RAM and processors, whether at the architectural level or in the synthesis process, creates a lot of additional work in modeling the system to make sure that throughput and latency requirements are met. Are the buffers big enough? How do you translate Mips and cache sizes into packets per second for a RISC core? How do you model the speed of table-lookup operations? The trade-offs blur across the boundaries of levels of abstraction, with, for instance, timing constraints for synthesis interacting with choice of FIFO depths at the architectural level and with floor planning.

Another fascinating issue comes up in verification. The successful communications SoC must be able to respond not only to valid inputs, but thanks to the laws of communications theory, to invalid ones as well. You dare not design the chip in the expectation of perfect channels. This changes the whole complexion of the verification problem, promoting random-stimulus approaches to a central role and stressing formal techniques to the breaking point. In some cases-such as voice-over-Internet Protocol, for instance-it also means there is no concrete definition of correctness. A design may be correct when human users like the sound they get, rather than when a particular transform has been executed exactly.

All of this would be interesting even if it were confined to the communications industry. But perhaps the real importance of the experience of communications design teams is that all these points are general issues in SoC design. Maybe they've shown up first in communications applications, but they are likely to be persistent. That makes the experience of communications engineers a case study we would all do well to inspect.

http://www.isdmag.com

Copyright 2002 CMP Media LLC
5/1/02, Issue # 14155, page 4.