Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!topaz!pyrnj!mirror!datacube!shep
From: shep@datacube.UUCP
Newsgroups: net.arch
Subject: DSP56200 and FIR filter performance
Message-ID: <3200006@datacube>
Date: Wed, 6-Aug-86 19:04:00 EDT
Article-I.D.: datacube.3200006
Posted: Wed Aug  6 19:04:00 1986
Date-Received: Sat, 9-Aug-86 08:54:19 EDT
Lines: 22
Nf-ID: #N:datacube:3200006:000:1194
Nf-From: datacube.UUCP!shep    Aug  6 19:04:00 1986


Thanks for the post of the DSP56200. It is good to be able to read of
new DSP chip architectures here in net.arch. I assume that the DSP56200
is designed as a peripheral for the 56000.

Table 1, listing the DSP56200 "performance figures" did not make any
sense: It seems for a FIR filter application with, say, 32 taps,
the maximum sampling frequency DECREASES as you add chips. This doesn't
make any sense. Can anyone explain or correct? A more convenient way
I've found to express the compute power of a FIR filter chip/board/system
is to express the performance in time/point . This allows filter aperture
and sample rate to vary whilst the hardware remains fixed:

For example: We recently designed a VMEbus module that performs a 64 point
FIR filter on a 10 MHz sample train in one or two dimensions. By expressing
the board's performance simply as 1.56 nS/point, it is a simple matter
to trade off aperture vs. sample rate conceptually. Of course, there are
often underlying issues that must also be taken into consideration;
but this gets you close!

Shep Siegel                    UUCP: [ihnp4 | mirror]!datacube!shep
Datacube Inc.; 4 Dearborn Rd.; Peabody, Ma. 01960;     617 535 6644