AccelProc in Communications

Accelerated Processing in Communications

The goal is to analyze accelerating processing in telecommunications. Any specific ways?. Lessons and trends are drawn.

Background

Because of the serial nature of the communication signal, and its speed ratio relative to CPU, the only realistic way to implement a communication function, was by designing a dedicated peripheral . This was the case in the 70s/80s (for instance UART, HDLC). With the dramatic increase in CPU raw speed (end 80s) it was possible to implement a  communication protocol in firmware [ref 1]. But by the 90s it was back to hardware and since that time, there had been an acceleration in communication bandwidth which renders software implementation impractical (so called "shannon gap"). Still we have seen over the years [ref 2] multiple attempts at so called "wire processor" but we feel is a bit of a white rabbit chase.   

Description

Traditionally communication (COM) is divided between infrastructure and terminal. In the middle stands the gateway. Obviously infrastructure (Base Station, DSLAM, VoIP Line cards, CMTS) require N times more processing power than a terminal.
Because, most COM processing is done in a dedicated hardware peripheral what is the scope for coprocessing? We answer this question by listing a few COM applications which use COP(s). Covered elsewhere are NPUs and Cell Phone platform coprocessing.
 

BTS

The cellular BTS, requires massive MIPS in  both Channel Coding (CC) , Chip Rate Modulation schemes (such as CDMA) and OFDM. These constitute the standard COPs:
- CC COPS: Viterbi, Turbo Codes [ref3]
- Chip Rate Processing: Rake receiver, De-spreader, Searcher [ref4]
- OFDM: FFTer  [TI website see C66x core apps].
And a special mention to the gutsy BAZIL which was made of a LSI/ZSP DSP and an "uncommitted array" of gates to implement the typical bit level algorithms.[ref 5].
We also worked on an architecture made of uncommitted COPS (linked through SRIO) and commanded by linked list in global memories. This is what we will call a high-end COP interface.

 

PHY

The point is that there are NOT that many ways to architect a PHY; the most flexible one is to use a cheap core (ARM7, 8051,cortex) and to connect with a light interface to hardware data paths. This can be considered de-facto coprocessing.
The problems starts when the data paths require more and more dsp. Most of all when the signal processing functions become adaptive and requires some light processing from the cheap core. Further as time progresses (and customer requests) the signal processing becomes less linear, more control oriented. Then the cheap cores and light interfaces very soon need more help (from a coprocessor to the coprocessor? why not?). 

Protocol Processor

Over the years many people attempted at the creation of a new type of processors: the PP. It was to be the equivalent of the DSP for Physical layer, the PP for Link Layer. Largely buried in the dustbin of history, still the PP should not be dismissed. The reason of its failure, has more to do with the advent of more complete solutions  such as PPP (Packet Protocol Processor), NPU (Networking Processing Unit) than the concept itself.
As a coprocessor the PP is a very useful building block, more likely to be loosely than tightly coupled. As far as reference goes all I have is a lot of NDAs [TBD].     

I/O Processor

This is the same story as above.  Many attempts for little results. As a matter of fact the classic reason for failure is speed. As the main CPU goes up the speed curve, the dedicated processor got left behind and becomes a point solution.However in a perspective of coprocessing the equation do not hold anymore. The host speed is pretty stable relative to the system workload. 
So an IOP can also be a pretty simple COP [ ref 6 Intel 8089] which can insulate the host CPU from real time communication events. The interface is another story.{ bandwidth and shared memory issues} 

References 

1. TI 320C20 DSP doing HDLC
2. Intel at Hot chips but when?
3. Nat Seshan " New Tms320C6416 Solves the DSP challenge", EPF June, 2001
4. A gatherer & all "A UMTS Baseband rx chip for infrastructure Apps" "TI TCI110 "  HC 2003
1. Most interesting example of TI using multiple ARM7 + hardware blocks (instead of a programmable DSP) to implement a communication function.   
2. The interface is standard mid-end (setup of contexts, parallel buses, dma)  
5. Neil Stollon "Bazil" EPF, June 2001
1. A heck of a paragdim shift. Still waiting after all these years
6. Robin Jigour "Data concentration techniques unload host computers" EDN March 4, 1981
1. Usage of 8089 IOP with a good description of interprocessor communication handled by linked message blocks
   

FURTHER : {TBD}