Need help selecting a DSP

[Pathfinder0311]

Hello everyone,

I'm having a hard time selecting either a Blackfin, Sharc, PIC32, or Arm for DSP work. Could you please offer your opinion as to which one(s) you prefer and why? Price is important (don't forget the software!). My price ceiling would be $200 for a development board + software. Lastly, expansive DSP libraries are a necessity!

Thank you so much.

[nctnico]

The first question would be: what problem do you want to solve? What kind of performance do you need?

[Pathfinder0311]

My application involves sonar direction finding from a single source. The source is a 30kHz sine wave. The approach to solving this problem is to use an array of 4 hydrophones arranged in a circle with a diameter strictly less than 1/2 lambda. The time delay is then calculated for input channels 2,3, and 4 using chan1 as the reference. This is accomplished by using the cross-correlation function. But before cross-correlation can occur, a digital bandpass filter is applied to filter out all but the 30kHz sine wave.

I will need to have a sampling frequency much greater than 30kHz to reduce the estimated azimuth error to less than 5% of true. DSP libraries containing FFT, digital filters, and cross-correlation are a must. Ideally, I would like the capability to sample the 4 channels simultaneously instead of sequentially. High performance is desired for near real-time processing.

[Howardlong]

Not being a hydrophone expert, what would the sampling frequency need to be for 5% azimuth error, and how many ADC bits?

Do you know if you need fixed point or floating point?

Do you have a power budget?

Is the end result to be a high or low volume product, or it it just for a proof of concept/academic project?

In general floating point is easier than fixed point to deal with in software for DSP, but it is more expensive in silicon, power consumption and sometimes speed.

Much as I hate Matlab, IMHO your best bet would be to get some algorithms up and running first either in Matlab or otherwise, say Octave and then program up some real C on a PC first with your own simulated or batch driven, reproducible data offline, then you will have a feel for the amount of processing is going to be required. Only then would I choose the target device.

[coppice]

Much as I hate Matlab, IMHO your best bet would be to get some algorithms up and running first either in Matlab or otherwise, say Octave and then program up some real C on a PC first with your own simulated or batch driven, reproducible data offline, then you will have a feel for the amount of processing is going to be required. Only then would I choose the target device.

Bang on target. For almost any algorithm development the first choice should be a PC. A few things need such enormous speed that a PC is not an option. The latency using a PC will not allow you to develop control loops. For pretty much anything else digitising the signals and getting them into a PC is the way to go. Once you have your algorithms more or less settled you will know the MIPS you need, and then you can start looking at serious target hardware.

From the scatter gun list of Blackfin, Sharc, PIC32, or ARM it looks like the OP has no clear idea of how many MIPS will be needed right now. That said, Blackfin and Sharc are pretty much obsolete. ARMs are available from very slow to pretty fast, have excellent eco-systems around them, and lots of competition. In most cases somewhere between an M0 and a quad core A57 will do your job quite nicely. If you need more speed than that you probably need to look at FPGAs.

[poorchava]

ARMs (at least microcontroller cores) suck at DSP bigtime, especially if there are relatively simple operations to be done on relatively large set of data. That because they don't have and hardware support for implementing loops and code overhead for looping if pretty bad. What is 1 cycle MAC good for if going to the next loop iteration takes 9 cycles or something like that. Plus most ARMs (if nor all) have a single ALU only and single data bus. Also, the ALU has no direct connection to memory as it is on some dedicated architectures. 32-bit SIMD on microcontrollers if nice, but has quite limited usage if you're aiming at any sensible system resolution.

Actually, not being a fan (to say the least) of Microchip micrcontrollers, their dsPIC33 series is pretty neat. Runs at up to 70MIPS, 16bit. Can execute up to 8 instructions per cycle IIRC, which kind of alleviates the problem with architecture beign 2clk/instruction. Those chips have DSP engine with hardware multiplier, barrel shifter, they support saturating and rounding logic in hardware, have two specialized memory regions for DSP instructions, support fie hardware looping etc. On the downside the built-in memory it rather modest in comparison to mid- and high-end CM4 microcontrollers.

dsPICs are not on par with BF, TMS320 and such, but they are relatively cheap, so you might find out, that if you have - say - 3 channels of data to process, it's cheaper to implement individual dsPIC on every channel rather than a single full-blown DSP.

[Howardlong]

I agree that Cortex M doesn't really offer a true alternative to DSPs: alhough the M4 does have some instructions which aid DSP development, there is little else archtecturally. dsPIC is not a parallel archtecture, the 70MIPS is just that on the dsPIC33E series, it's just that some instructions have autoincrement on pointers and there is a zero overhead loop for single instructions for example, but practically speaking being able to do 8 ops in one instruction cycle is pushing it, that is the exception rather than the rule. In fact in one application which was heavily FFT intensive, I chose a PIC32 over a dsPIC about six years ago because the PIC32 was about 60% faster than the dsPIC in my application.

I would struggle nowadays to justify using a dsPIC33 over Cortex M4, not least due to the dsPIC fundamentally being only 16 bit. I don't have any Blackfin experience, but the TI DSPs in e C6000 range are very serious in comparison to M4 and dsPIC not least in their use of VLIW enabling true parallel execution.

[legacy]

My price ceiling would be $200 for a development board + software

I am afraid the Blackfin is out of your budget: just the ICE cable costs 150 USD, an eval board is ~200USD, plus VisualDSP++ which costs thousands
About the budget, I think you'd better look at PIC32, they are very very cheap, with a good ratio performances/cost.

Have a look.

[legacy]

Go get a BF592 for below 50 bucks

50USD, which board ? I really want one.
the ICE-1000 Emulator is a MUST, see its price list

and start coding with gcc

well, serious development with CoNix 

[legacy]

I recently got a 584-ADZS-BF537EZLITE, it's now priced 350 euro (Mauser)
My boss ordered ADZS-BF561-EZLITE, it is now priced 500 euro

ok, these boards are more than enough, while the ADSP-BF592 EZ-KIT Lite is 190 euro
 
for 50 USD, are you talking about chinese clone ?

edit: ok, posted before reading your answer. Understood.

[Kalvin]

Texas Instruments has some inexpensive 32-bit fixed-point and floating point MCUs, too. See their Piccolo and Delfino MCU-series for further info. They offer inexpensive Launchpad evaluation boards and the Code Composer Studio can be downloaded for free.

Like the others have already pointed out, you should first work with Octave or Matlab. After you have figured out what you need to do, you should implement the algorithm in C and run it in PC using simulated stimulus. There you can verify you algorithm works as expected. As you have the algorithm already implemented in C, it should be quite easy to port it to the target hardware. Of course, there a things like optimization etc. stuff which may be target architecture or compiler dependent. Here, you possibly can still use the simulated stimulus in order to verify your algorithm running on the target hardware (it doesn't have to run in real-time). Finally, you make your algorithm running in real-time using real signals. Using step-by-step development, it is much easier to figure out where the things stopped working.

[nctnico]

My application involves sonar direction finding from a single source. The source is a 30kHz sine wave. The approach to solving this problem is to use an array of 4 hydrophones arranged in a circle with a diameter strictly less than 1/2 lambda. The time delay is then calculated for input channels 2,3, and 4 using chan1 as the reference. This is accomplished by using the cross-correlation function. But before cross-correlation can occur, a digital bandpass filter is applied to filter out all but the 30kHz sine wave.

I will need to have a sampling frequency much greater than 30kHz to reduce the estimated azimuth error to less than 5% of true. DSP libraries containing FFT, digital filters, and cross-correlation are a must. Ideally, I would like the capability to sample the 4 channels simultaneously instead of sequentially. High performance is desired for near real-time processing.

I'd solve this problem differently. Because you only use one frequency and are interested in the time domain you can filter the signal in hardware (simple LC filter) and use sub-sampling. A while ago I developed an ultrasonic object detector with frequencies up to 48kHz. In that design I sampled at around 12 to 15kHz to have at least a couple of cycles of the pulse being send. Sampling several channels at 15kHz or lower is definitely in the realm of a low cost ARM microcontroller. Once you have sampled the signal you can upsample it to whatever resolution you need to determine the time domain relation between the signals (taking into account the delay between multiplexing the analog inputs).

I also strongly agree with Coppice: build the routines first using Matlab or C on a PC (just use floating point). If that works (don't forget to test signal overflow situations) you'll have a benchmark for the embedded application. That way you don't have to figure out whether the algorithm is the problem or there is another problem in the hardware/software. Even with the best hardware debugger it is a 1000 times easier to debug a PC application and process/analyse test sets with data.

@Poorchave: last time I looked many ARM controllers support SIMD (single instruction multiple data) instructions for optimising signal processing loops.

[Pathfinder0311]

Not being a hydrophone expert, what would the sampling frequency need to be for 5% azimuth error, and how many ADC bits?

Do you know if you need fixed point or floating point?

Do you have a power budget?

Is the end result to be a high or low volume product, or it it just for a proof of concept/academic project?

In general floating point is easier than fixed point to deal with in software for DSP, but it is more expensive in silicon, power consumption and sometimes speed.

Much as I hate Matlab, IMHO your best bet would be to get some algorithms up and running first either in Matlab or otherwise, say Octave and then program up some real C on a PC first with your own simulated or batch driven, reproducible data offline, then you will have a feel for the amount of processing is going to be required. Only then would I choose the target device.

@Howard Long
I don't quite know what frequency I will be sampling at. I have already started developing the algorithms in MatLab even before I made this post. Preliminary results show 32*30e3 = 980 [kHz] but this could be wrong due to rounding of very small numbers. I do want to scale the values of the variables such that the magnitude range between the largest number and the smallest number are closer together to avoid potential rounding error. I do however think that 1024 samples per frame will be a good candidate. Floating point is a must as far as I can tell.

Another option I'm down for is to use an FPGA. I already see independent loops for each channel so parallelism is applicable. I also want to note that it seems DSPs are being phased out for FPGAs.

This is project is for senior design so its a one time thing.

I have to ask you Howard, why don't you like MatLab? I think its better than sliced bread 

[Pathfinder0311]

My application involves sonar direction finding from a single source. The source is a 30kHz sine wave. The approach to solving this problem is to use an array of 4 hydrophones arranged in a circle with a diameter strictly less than 1/2 lambda. The time delay is then calculated for input channels 2,3, and 4 using chan1 as the reference. This is accomplished by using the cross-correlation function. But before cross-correlation can occur, a digital bandpass filter is applied to filter out all but the 30kHz sine wave.

I will need to have a sampling frequency much greater than 30kHz to reduce the estimated azimuth error to less than 5% of true. DSP libraries containing FFT, digital filters, and cross-correlation are a must. Ideally, I would like the capability to sample the 4 channels simultaneously instead of sequentially. High performance is desired for near real-time processing.

I'd solve this problem differently. Because you only use one frequency and are interested in the time domain you can filter the signal in hardware (simple LC filter) and use sub-sampling. A while ago I developed an ultrasonic object detector with frequencies up to 48kHz. In that design I sampled at around 12 to 15kHz to have at least a couple of cycles of the pulse being send. Sampling several channels at 15kHz or lower is definitely in the realm of a low cost ARM microcontroller. Once you have sampled the signal you can upsample it to whatever resolution you need to determine the time domain relation between the signals (taking into account the delay between multiplexing the analog inputs).

I also strongly agree with Coppice: build the routines first using Matlab or C on a PC (just use floating point). If that works (don't forget to test signal overflow situations) you'll have a benchmark for the embedded application. That way you don't have to figure out whether the algorithm is the problem or there is another problem in the hardware/software. Even with the best hardware debugger it is a 1000 times easier to debug a PC application and process/analyse test sets with data.

@Poorchave: last time I looked many ARM controllers support SIMD (single instruction multiple data) instructions for optimising signal processing loops.

@nctnico
Right on! The program will be built and debugged one layer at a time like an onion.

What are you referring to when you say "...test signal overflow situations"?

[Howardlong]

I have to ask you Howard, why don't you like MatLab? I think its better than sliced bread 

That's easy. For SME's, and I'd wager quite a number of larger outfits, the price is simply not justified. Their pricing is about an order of magnitude out of kilter before I'd consider it. My use is sporadic: I use Octave maybe two or three times each year for algorithm development, but that's it, probably over a total of one or maybe two days maximum. If you're in academia, it's cheap as chips of course.

Back to the question, doing FFT on 1MSa/s in floating point pretty much dictates that you need a proper DSP.

[diyaudio]

Much as I hate Matlab, IMHO your best bet would be to get some algorithms up and running first either in Matlab or otherwise, say Octave and then program up some real C on a PC first with your own simulated or batch driven, reproducible data offline, then you will have a feel for the amount of processing is going to be required. Only then would I choose the target device.

Bang on target. For almost any algorithm development the first choice should be a PC. A few things need such enormous speed that a PC is not an option. The latency using a PC will not allow you to develop control loops. For pretty much anything else digitising the signals and getting them into a PC is the way to go. Once you have your algorithms more or less settled you will know the MIPS you need, and then you can start looking at serious target hardware.

From the scatter gun list of Blackfin, Sharc, PIC32, or ARM it looks like the OP has no clear idea of how many MIPS will be needed right now. That said, Blackfin and Sharc are pretty much obsolete. ARMs are available from very slow to pretty fast, have excellent eco-systems around them, and lots of competition. In most cases somewhere between an M0 and a quad core A57 will do your job quite nicely. If you need more speed than that you probably need to look at FPGAs.

That said, Blackfin and Sharc are pretty much obsolete.

Says who?

A few weeks ago the most anticipated SHARC processor range was made public, with an arsenal of peripherals, both running dual SHARC cores, and one of them with an optional A5 ARM core.

Have a look at the
ADSP-SC58x and ADSP-2158x, silicon ships next year 2016 end of fall.

Another option I'm down for is to use an FPGA. I already see independent loops for each channel so parallelism is applicable. I also want to note that it seems DSPs are being phased out for FPGAs.

Follow the Ti DSP series and see what they think about that statement., pretty interesting view, one which I share as well.
 

[Marco]

Back to the question, doing FFT on 1MSa/s in floating point pretty much dictates that you need a proper DSP.

Or in other words, not a Blackfin either ...

Pathfinder : do you really need to do FFTs at all? Even without doing any detection at all you already have a <40 ppm error estimate of the fundamental frequency of the emitter (ie. the difference between the frequency of two crystal oscillators). Even if you need a significantly better estimate, you should be able to search around this frequency with a couple of single frequency component transforms ... far cheaper than a complete FFT. After that you can just multiply the signals with a sine and a cosine at the fundamental to find the phases for the different hydrophones.

Together with analogue bandpass filtering + subsampling you might be able to do this on a PIC

[nctnico]

What are you referring to when you say "...test signal overflow situations"?

The signal going into the ADC may not always be what you expect. Sometimes filters or algorithms can overflow and start to ring or (worse) oscillate.

[coppice]

Another option I'm down for is to use an FPGA. I already see independent loops for each channel so parallelism is applicable. I also want to note that it seems DSPs are being phased out for FPGAs.

Actually, the trend seems to be the other way at the moment. I've seen a number of things, like high end medical applications, which migrated from DSPs to FPGAs, and are now moving back to DSPs. I am not clear about the reasons.

[nctnico]

Another option I'm down for is to use an FPGA. I already see independent loops for each channel so parallelism is applicable. I also want to note that it seems DSPs are being phased out for FPGAs.

This is project is for senior design so its a one time thing.

You mean it is like a final project for a university graduation? In that case I'd definitely stay away from FPGAs and high end DSPs. Show you are smart and use sub-sampling + simple hardware. An elegant solution will get you more points than an uber-complicated one. The problem you are dealing with is one of the rare cases where you deal with pure sine waves so you can use all kinds of neat tricks (like aliasing) without having to think about deforming the signal.

[Kalvin]

How real-time this application is, other than sampling the four hydrophones? And how many samples are needed to be able to compute the cross correlation in order to resolve the signal source direction ie. how long sample buffer is needed in order to be able to compute the cross correlation? If the application doesn't require absolute real-time, the system could capture sufficient number of samples in a buffer and then compute the cross correlation. Or, the system could have two sample buffers: One for collecting the new samples (using DMA) and the other one being processed.

[poorchava]

You can do it on some higher speed (like 100MHz +) Cortex-M4 and achieve operation that human eye will perceive as real-time. I have done a very similar thing (DSP wise, application is completely different). Use memory-speed tradeoff, to precompute what you can and store it in flash.

Sent from my HTC One M8s using Tapatalk

[Howardlong]

You can do it on some higher speed (like 100MHz +) Cortex-M4 and achieve operation that human eye will perceive as real-time. I have done a very similar thing (DSP wise, application is completely different). Use memory-speed tradeoff, to precompute what you can and store it in flash.

Sent from my HTC One M8s using Tapatalk

If 1Msa/s FFT is needed across 4 channels, I'd find it difficult to see how that would work of M4F unless that's almost all you're doing. I accept that I may be misinterpreting the OP's project though.

I do like the idea of a hybrid design in the pursuit of the most cost effective solution, that shows real engineering prowess. Engineering is not just about design and technical excellence, it's also about compromise.

[legacy]

I'd definitely stay away from FPGAs

I agree, FPGAs require a lot of effort, knowledge and time.