[comp.sys.transputer] DSP Processors and Transputers

cnbs30@vaxa.strath.ac.uk (03/17/91)

A number of companies are currently putting together TRAMS for
digital signal processing chips, such as the DSP 56000, and the
newer Motorola 96000, Zoran chips and so on ....

Why?

What can the transputer offer DSP?   DSP is fast mulitply
accumulate.  So are DSP algorithms.   Other than downlaod
the code through a serial link I don't see where the transputers
can offer their services to the DSP chips.   The parallelism that
the transputer can offer a DSP chip is really not the type
of parallelism that is inherent in DSP algorithms.  DSP is
most certainly not SIMD or MIMD "batch" type parallelism.  If say
a FIR filter were to be split between two, for arguments sake,
DSP 56000's then while the DSP chip hammers along at more than
10MOPs, could the transputer keep up.   I think the designers,
are barking up the wrong trees.  Other than Universities who
would buy these things.

TRAMS with DSPs are most definitely hybrids.  We all know what
happened to the boat-car.

I look forward to any views on DSP/transputer modules, especially ones
that contrast to mine.  I am willing to be convinced they are a good idea,
if someone can come up with faster algorithm implementation, and
more importantly, applications

...Buff Whelan

carroll@ssc-vax (Jeff Carroll) (03/20/91)

In article <1991Mar16.165208.10489@vaxa.strath.ac.uk> cnbs30@vaxa.strath.ac.uk writes:
>A number of companies are currently putting together TRAMS for
>digital signal processing chips, such as the DSP 56000, and the
>newer Motorola 96000, Zoran chips and so on ....

>Why?

	Because people want them, buy them, and use them.

>What can the transputer offer DSP?   DSP is fast mulitply
>accumulate.  So are DSP algorithms.   Other than downlaod

	This is a gross generalization which oversimplifies the actual case.
There is certainly more to DSP than FFTs.

>the code through a serial link I don't see where the transputers
>can offer their services to the DSP chips.   The parallelism that

	We have found the transputer network to be superior to the
PC-bus-attached DSP board as an engine for our large-scale DSP applications.
The reconfigurability of the transputer network, the simplicity of
interfacing TRAMS, and the pipeline architecture are real, quantifiable
advantages.

>the transputer can offer a DSP chip is really not the type
>of parallelism that is inherent in DSP algorithms.  DSP is
>most certainly not SIMD or MIMD "batch" type parallelism.  If say

	You apparently have some kind of concrete algorithm in mind
when you say "DSP is this" and "DSP is not that". What is it? If your
FFTs are large enough they are certainly compatible with domain 
decomposition. If you have a large number of small FFTs you can certainly 
use processor farms to do them. And it seems to me that the FFT is a
regular enough computation that it would work well on a SIMD box (which,
of course, a transputer network is not.)

	And if you're doing matrix decompositions, well, I have some
pretty good empirical evidence that a MIMD box *screams* on matrix
decompositions.

>a FIR filter were to be split between two, for arguments sake,
>DSP 56000's then while the DSP chip hammers along at more than
>10MOPs, could the transputer keep up.   I think the designers,

	A 20 MHz transputer is certainly capable of doing interesting things
with a 40k sample/sec byte stream coming out of a DSP.

>are barking up the wrong trees.  Other than Universities who
>would buy these things.

	Well, we've spent something like half a million dollars this
year on dual-processor TRAMs, and we're not a university. (That has to
be a strong candidate for the Understatement of the Year Award.)



-- 
Jeff Carroll
carroll@ssc-vax.boeing.com