Re: FEC paper, implementation

[Phil Karn <karn@unix.ka9q.ampr.org>]

>That is a reason why I like the idea of implementing it on a DSP4 or
>another external processor.
>Even if the FEC would not fully load the host, we might like to use the
>CPU on the host for other purposes.

I know of more than one system with both a DSP and a general purpose
CPU where the designers are now trying to move functions from the DSP
to the general purpose CPU because the DSP is overloaded. HAL's Clover
II board, for example.

DSPs are best reserved for the functions for which they are optimized,
namely the multiply-accumulate operations of FIR filtering and
correlation. For general purpose computing, which includes sequential
decoding and probably Viterbi decoding, a general purpose CPU is both
faster and cheaper. Consider the clock speeds: 66 MHz 486s are now
very widespread, but the typical clock on a AD2115 DSP sound card is
only 16 MHz. And if a single 486 isn't enough, you can always buy
more.

If the PowerPC ever takes off, we'll be able to punt conventional DSPs
altogether. The PowerPC floating point unit can stage one
multiply-accumulate per clock, which to me qualifies it as a DSP.

>Well, I have suggested it to be used on telephone (V.34) modems instead
>of the strange solutions the modem manufacturers are now moving to (like
>"enhanced serial ports" and the use of the parallel printer port).  Such
>solutions are a problem when the host is not a PC, and/or when a lot of
>modems have to be connected.  An ethernet connection offers good scalability
>at low initial cost (an ethernet controller is less expensive than a
>multiport RS232 card these days)

Amen! These are already starting to appear as small standalone IP
routers, with either modems or ISDN interfaces. But it will probably
take a while for these to become as widespread as RS-232 modems.

Phil