There is unquestionably a strong link between the communications industry and the evolution of system-level IC design. It is not an identity: Systems-on-chip exist across pretty much the entire electronics application space. But much of the activity and many of the expeditions to the edge of the envelope have taken place in the service of communications. Sheer numbers of designs aside, there are technical reasons communications SoC devices continue to draw our interest. These issues have to do with the nature of the problems to be solved in communications.
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 receiv e 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 b lur 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 r eal 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.
Copyright © 2002 CMP Media LLC
5/1/02, Issue # 14155, page 4.