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
FPGA VS DSP - which & why?
Started by ●October 10, 2007
Reply by ●October 10, 20072007-10-10
> 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
> 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
Reply by ●October 10, 20072007-10-10
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
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
Reply by ●October 10, 20072007-10-10
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,
Praveen
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,
Praveen
Reply by ●October 10, 20072007-10-10
Great 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 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
>
>
>
Is there a way to get this posted in our forum/message board?
On 10/11/07, Hugh Shane 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
>
>
>
