DSP vs. Microprocessor

What is the most fundamental difference between a DSP (processor) and a
Microprocessor? I could list out a few, but what core features make a
DSP a DSP? What makes a Microprocessor not capable of performing DSP
applications unless emulated by software?

dspguru_wannabe wrote:
> What is the most fundamental difference between a DSP (processor) and a
> Microprocessor? I could list out a few, but what core features make a
> DSP a DSP? 

The most fundamental difference that I see is a real full-blown MAC 
instruction that'll let you do a vector multiply (i.e. a FIR filter) at 
one clock cycle per tap.  Having said that, a uP with a cheesy MAC 
add-on that doesn't give you pieces of MAC (for one cycle per tap vector 
copies, etc.) may not qualify as a "DSP" in my book.

> What makes a Microprocessor not capable of performing DSP
> applications unless emulated by software?
> 
That us a null statement -- a general purpose DSP chip such as produced 
by TI, ADI and Freescale cannot perform DSP applications unless 
specifically instructed by software.  The only difference is that the 
most common DSP operations which are very compute-intensive on a 
microprocessor are supported by things like the MAC instructions (and 
the hardware to back it up).

The compare/contrast goes like this:

To perform a 16x16 MAC into a 32 bit accumulator on an 80186 takes (if 
my memory serves me correctly) 180 clock cycles per tap, with some 
setup, or a shade over 11us on a 16MHz part.  On an Analog Devices 
AD2101 it takes 1 (one) clock cycle per tap, with some setup.  This is 
only a difference in degree, but inasmuch as it's two orders of 
magnitude worth of degree I think we can draw a line between the two 
processors.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

dspguru_wannabe wrote:

> What is the most fundamental difference between a DSP (processor) and a
> Microprocessor? I could list out a few, but what core features make a
> DSP a DSP? What makes a Microprocessor not capable of performing DSP
> applications unless emulated by software?

You list the few you can think of and I'll augment the list. I won't
start from scratch.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Thanks for the answer.

Would you consider the followings as essential features of a DSP?

1. multiple access memory
2. Hardware looping support

Also, would you consider single-cycle multiplier (say 16x16 MUL in
32-bit architecture) an absolute must in a DSP chip?

dspguru_wannabe wrote:

> Thanks for the answer.
> 
> Would you consider the followings as essential features of a DSP?
> 
> 1. multiple access memory

Necessary for many single-cycle instructions.

> 2. Hardware looping support

Without it, some loops would take at least twice as long.

> Also, would you consider single-cycle multiplier (say 16x16 MUL in
> 32-bit architecture) an absolute must in a DSP chip?

No one feature is so important that without it one can say "this isn't a
DSP." In a 32-bit architecture, I would like a 32x32 multiply.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

dspguru_wannabe wrote:
> What is the most fundamental difference between a DSP (processor) and a
> Microprocessor? I could list out a few, but what core features make a
> DSP a DSP? What makes a Microprocessor not capable of performing DSP
> applications unless emulated by software?

People have listed a few specific features, which they consider key to a 
device being a real DSP. By those measures a number of famous DSPs would 
not have been DSPs. For example, not every DSP has offered a single 
cycle MAC. If I remember correctly, the first really commercially 
successful DSP - the TMS32010 - took two cycles. The single cycle 
measure is quite complex, anyway - answers in one cycle, or a new 
computation starts each cycle? Pipeline latency can make some very tight 
processing kernels a pain to implement, even though the device can do an 
average of one operation per clock.

I'd express things like this:

- If it sucks at bit banging and logic it isn't a general purpose 
processor. A lot of (especially earlier) DSPs have really sucked at 
these jobs, and the code for even the simplest logic surrounding the 
core DSP activities is a mess.

- If it sucks at polynomials it most certainly is no DSP.

- If it sucks at vectors it is no serious high performance computing 
engine. Note that a lot of vector processors have sucked rather badly at 
DSP, as their latency doing polynomials was bad.

Many DSPs now try to balance their polynomial and vector performance, 
especially the floating point ones.

Really, how you achieve high performance isn't that relevant and can be 
highly algorithm specific. For example, many DSPs have special features 
(which always seem to be poorly documented) that allow LMS to be greatly 
speeded up. The particular addressing features for LMS are hardly used 
anywhere else.

If you don't care about latency, does it really matter if you achieve 
your MAC performance through a single cycle MAC, or thousands of 1 bit 
processors each taking thousands of cycles per MAC. Some of the neatest 
early machines for signal processing did just that. See the Goodyear 
ASPRO for an example.

Regards,
Steve

I'd say the distinguishing characteristics of a DSP are as follows:

1)  Single-cycle MAC:  Many DSPs today can even do two MACs in a single 
cycle.
2)  Repeat single instruction and repeat block of instructions.
3)  Addressing Modes:  Capability to do hardware circular addressing and 
other post-increments/decrements in the same cycle as the instruction.
4)  Multiple memory accesses.  Often there are multiple buses available.

It really takes all 4 of the above characteristics to be able to implement a 
super-efficient FIR filter (i.e. a few setup cycles and then 1 cycle per 
tap)

Brad.

"dspguru_wannabe" <gogichen@gmail.com> wrote in message 
news:1104602593.082839.83060@c13g2000cwb.googlegroups.com...
> What is the most fundamental difference between a DSP (processor) and a
> Microprocessor? I could list out a few, but what core features make a
> DSP a DSP? What makes a Microprocessor not capable of performing DSP
> applications unless emulated by software?
> 

Yes, I consider them to be essential of a DSP. At least I wouldn't
expect a processor without them to be named a "DSP".

JaaC

Yes, I consider them to be essential of a DSP. At least I wouldn't
expect a processor without them to be named a "DSP".

JaaC

I'm more replying to the OP here, just using Jerry's responses as a
jumping-off point...

On Sat, 01 Jan 2005 22:06:25 -0500, Jerry Avins wrote:

> dspguru_wannabe wrote:
> 
>> Thanks for the answer.
>> 
>> Would you consider the followings as essential features of a DSP?
>> 
>> 1. multiple access memory
> 
> Necessary for many single-cycle instructions.

Although not exclusive to DSPs, in the modern context.  Most of the "big
time" workstation microprocessors, Pentia, Itanium, Athlons, PPCs, etc,
can sustain several memory ops/cycle from on-chip cache.

>> 2. Hardware looping support
> 
> Without it, some loops would take at least twice as long.

The same processors listed above use branch prediction to manage
zero-overhead loops without architecting it in the instruction set.  Some
"DSPs", such as the TI C6000 series manage without hardware "loop"
instructions by having enough spare VLIW instruction slots that the work
involved in a hardware loop mechanism can be expressed in "ordinary"
instructions.

>> Also, would you consider single-cycle multiplier (say 16x16 MUL in
>> 32-bit architecture) an absolute must in a DSP chip?
> 
> No one feature is so important that without it one can say "this isn't a
> DSP." In a 32-bit architecture, I would like a 32x32 multiply.

I'd say that it comes down to what you're using the chip for.  DSPs are
optimised for some specific algorithms, typically characterised by
"vector" operations of fairly simple sorts: real and complex matrix
multiplies of various sorts, and (in some contexts) special help for
things like "max()" to help with Viterbi.  The dynamic range of the
data and the precision of the calculations and (sometimes) the ease of
programmability determines issues like word-size and multiplier width,
and fixed-vs floating point.  The algorithms are well known, alhough there
are enough variations in applications and conditions to keep those of us
here occupied.  The reason that the hardware is typically optimized for
the algorithm is not (necessarily) because it's faster that way, but
because that allows you to solve the given (real time) problem with less
hardware and/or less power. People do DSP on 8-bit micros, when the
signals being processed are sufficiently slow or low-precision. People do
DSP on workstations and PCs when the signals are off-line, and they aren't
concerned about hard real-time constraints or power consumption. What we
call a "DSP" hits a sweet spot for "audio" frequency signals, because you
can run an algorithm of a few hundred to a few thousand instructions on
every sample, and that's useful.  What you need for video processing, or
software radio typically looks a bit different. FPGAs and other custom
circuits are used for some of those things, because the sample rates are
such that you can't apply enough conventional-processor instructions to
each.  Conversely, the amount of matrix multiplication involved in
compressed-audio decoding is actually pretty limited: much of the work is
bit-bashing, and so you find things like ARM cores getting a lot of that
action (in portable devices), even though they don't (or didn't
originally) have single-cycle multiplies or multi-word memory access.

DSP is typically a verb.  The noun "a DSP" is just whatever you need to
use to do the DSP that you need to do.

Cheers,

-- 
Andrew