NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/dec/7118

Internet Message Format | 1993-01-25 | 4.1 KB

Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!forney.berkeley.edu!jbuck
From: [e-mail] (Joe Buck)
Newsgroups: comp.sys.dec
Subject: Re: "Are DSP Chips Obsolete?" (was re: Alpha fft performance)
Date: 26 Jan 1993 00:12:20 GMT
Organization: U. C. Berkeley
Lines: 73
Message-ID: <1k1vl4$[e-mail]>
References: <[e-mail]> <1jn4dn$[e-mail]> <[e-mail]>
NNTP-Posting-Host: forney.berkeley.edu


In article <1jn4dn$[e-mail]> [e-mail] writes:
>>If you're after getting the job done with products that are available
>>today, contact Motorola, Texas Instruments, Analog Devices, or any of
>>a half dozen other companies who understand the DSP market and don't
>>go around publishing poorly conceived papers like "Are DSP Chips Obsolete?".

In article <[e-mail]> [e-mail] (Malcolm Slaney)
writes:
>I think you're being a bit harsh on the paper.  It's hard to argue with their
>numbers.

Perhaps, since you're not following up my original post, it's not clear
what I am arguing with.

If someone asks me whether they should add a board with a DSP on it to
make their workstation a better number cruncher, the answer is "probably
not -- better to do the math in your RISC CPU -- it's just as fast most
of the time."  In this narrow sense I agree with the paper.

>I think that the DEC paper shows two things.  1) You don't have to use a DSP
>chip to get fast multiplies any more and 2) as SGI and NeXT have discovered,
>DSP chips don't have much work to do in a workstation.

I agree with both of these (although with the second one to a limited
extent: if the workstation has an attached modem, that modem has either
a DSP or an ASIC that has a DSP core to do the modem algorithm).

The problem with the paper starts with the title and goes on from there.
The authors made no attempt to determine what DSP chips are currently
being used for.  Do you really think that NeXT was a major consumer of
Motorola 56000's (or that similar applications were)?  They are mainly
used in embedded real-time applications.  The authors make a number of
blatantly wrong statements about such applications (some of the ones
about modems were particularly embarrassing).

>Is there anything inherently power hungry and expensive on the current
>RISC chips?  The RISC chips that I'm familiar with do 64 and 80 bit IEEE
>floating point.  That's one item that embedded RISC chips can do away with.
>Virtual memory support is another.  Are caches that much more power hungry
>than large on-chip memory?  What else is left?  A 32 bit IEEE floating point
>multiply has to be the same cost.

Here's the deal: if you plan to do a paper saying "Are XYZ's obsolete?"
it serves you well to do a marketing survey to find out just what XYZ's
are used for in industry, and also to find out a bit about exactly what
distinguishes XYZ's from whatever you propose to replace them with.

Imbedded DSP applications don't have virtual memory; they don't have cache
(well, some have small instruction caches); they often have very tight
memory requirements (say, 8K-64K for the whole system).  In a number
of the largest volume applications, "low power" means the whole thing
(CPU, memory, A/D, D/A, etc) is all on one chip.  The cost tradeoffs
are very different, meaning that the optimal instruction set is different;
a load-store architecture isn't the best choice when the algorithm is more
heavily memory-bound.  The bottleneck in most DSP algorithms is not how
fast a multiply is.  It is a memory bottleneck: moving large amounts of
data through the CPU.  As a result, most modern DSPs can do three memory
operations at the same time to separate memory banks, each on a separate
address bus.

>Still hoping that someday I don't have to program my DSP algorithms in
>assembly language....

I agree -- even C/C++ is too low-level.  I'd rather draw a dataflow
graph and have it automatically partitioned among several processors
to optimize throughput and minimize interprocessor communication cost.
We're (the Ptolemy group at UCB) working on it...



--
Joe Buck    [e-mail]