For engineers implementing DSP functions on FPGAs. This is a NEW Group that has just been created. It should take a few weeks before the group is big enough to become active. Please join!
As an FPGA designer, I find it very easy to design and code FPGAs of all sorts. Tweaking is extremely easy, and code is mostly portable from one brand to another. I have recently designed a C6713 DSP, and talk about learning curve!!! It is odd that the pins are multiplexed to certain functions and are unusable at times, and the Chip Support Libraries API are a pain in the butt (1108 pages!!) EMIF, HPI, MCASP, MCBSP, HWI, SWI, PRD, DSP/BIOS, FlashBurn, BootLoading, etc.. ARGGGHHHHHHHH.... It just seems that an FPGA design would've been so much easier to code and tweak. The only reason I selected the DSP was for the FFT processing, but now I realize all the FPGA manuf. are coming on board with their own DSP software built in or integrated... DSP Builder, Synplify DSP, etc.... Oh, don't get me started on why TI does not build in a FlashBurn utility of it's own?? At least with FPGA, there are programming tools built in. Can anyone convince me why the DSP is the proper choice for 8192 pt. FFT and other processing? I don't plan to ever use a DSP again... :) Holla
> Can anyone convince me why the DSP is the proper > choice for 8192 pt. > FFT and other processing? I don't plan to ever use > a DSP again... :) It's an economic decision: Cost versus performance. Many applications will run just fine on a DSP which costs an order of magnitude less than an FPGA. In consumer applications where every penny of hardware cost matters this is a big deal. Your employer doesn't care if the tools suck and it takes an extra 100 man-hours to get the thing working. On the other hand, in low volume applications the math is reversed. Labor, not hardware, is the dominant cost. Obviously, the point is moot of you need to do your 8K FFT in tens of microseconds. Only an FPGA will do. Hopefully your customers will be willing to pay the price for this increased performance. Hugh
Holla, I used the Spectrum Digital C6713 kit for our DSP Class. I chose it because there is a good book available on the Internet that has lots of programs for the C6713. We are now looking at the Opal Kelly Spartan 3 Starter Kit to teach the students how to program the FPGA. This is why I am interested in a DSP program for the FPGA. Often we let the students suffer the agony of older technology just so they can appreciate learning about the newer stuff. Prof. Daniel Cross-Cole Chair, NCM and NSA Programs DeVry University Crystal City Campus Arlington, VA 22202 703 414-4055
Howdie DSP vs. FGPA enthusiast,
I have been mostly working with DSP (with all the pain you mentioned :)) 8 years and surviving.
Infact I teach a DSP course at my university using the painful DSP 6713 you mentioned. Each
year of the course, I learn more!
So stir it up a bit, let me try to answer if I can convince you to use a DSP:
* Choice between the two is very dependent on the context of usage
* In case power is a bit of constraint, then DSP is preferred despite all the overhead of
pain in programming
* Besides the I/O stuff that you mentioned, DSPs are not so bad :)
* In case you do not have much of power constraints, like you want to do an FFT on an image
put on a security camera plugged on to a socket, then FPGA by all means is a wise choice.
* P+R on FPGA is stochastic!
* This sucks in a real time system, where you need to ensure that every place to try to
program it comes the same way
* Embedded Systems
* Well here, we also need that we lower power and very low overhead for reconfiguration (in
case of FPGA) and loading a new program (in case of a DSP).
* This makes the 'pain' often market-wise worthwhile :)
* We actually use our own internal DSP (not TI) for FFTs (including 8192 pt and other
cases)
Regarding your comment on lack of tools:
* Remember Proebsting's law: compiler advances double computer every 18 years!
* Also there are many more DSPs than there are FPGAs so don't expect much automation from
the DSP community!
Did I at least give you cases where you might use a DSP (ever?)?
Regards,
PraveenGreat responses everyone. Thank you, and keep them coming!! Is there a way to get this posted in our forum/message board? On 10/11/07, Hugh Shane <yahugh59@yahoo.com> wrote: > > > Can anyone convince me why the DSP is the proper > > choice for 8192 pt. > > FFT and other processing? I don't plan to ever use > > a DSP again... :) > > It's an economic decision: Cost versus performance. > > Many applications will run just fine on a DSP which > costs an order of magnitude less than an FPGA. In > consumer applications where every penny of hardware > cost matters this is a big deal. Your employer doesn't > care if the tools suck and it takes an extra 100 > man-hours to get the thing working. On the other hand, > in low volume applications the math is reversed. > Labor, not hardware, is the dominant cost. > > Obviously, the point is moot of you need to do your 8K > FFT in tens of microseconds. Only an FPGA will do. > Hopefully your customers will be willing to pay the > price for this increased performance. > > Hugh > > >