Need help selecting a DSP - Page 1
Forum section: electronics / general

author: Pathfinder0311
author_rank: Newbie
timestamp: July 20, 2015, 06:03:26 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 20, 2015, 07:15:03 pm
content: The first question would be: what problem do you want to solve? What kind of performance do you need?

author: Pathfinder0311
author_rank: Newbie
timestamp: July 20, 2015, 10:40:52 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: July 20, 2015, 11:21:37 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: July 21, 2015, 05:43:53 am
content: Quote from: Howardlong on July 20, 2015, 11:21:37 pmBang 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 21, 2015, 06:10:08 am
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: July 21, 2015, 07:43:55 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: July 21, 2015, 07:47:38 am
content: Quote from: Pathfinder0311 on July 20, 2015, 06:03:26 pmI 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 thousandsAbout the budget, I think you'd better look at PIC32, they are very very cheap, with a good ratio performances/cost.Have a look.

author: legacy
author_rank: Super Contributor
timestamp: July 21, 2015, 08:04:12 am
content: Quote from: blueskull on July 21, 2015, 07:52:56 am50USD, which board ? I really want one.the ICE-1000 Emulator is a MUST, see its price listQuote from: blueskull on July 21, 2015, 07:52:56 amwell, serious development with CoNix

author: legacy
author_rank: Super Contributor
timestamp: July 21, 2015, 08:13:54 am
content: 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 eurook, these boards are more than enough, while the ADSP-BF592 EZ-KIT Lite is 190 eurofor 50 USD, are you talking about chinese clone ?edit: ok, posted before reading your answer. Understood.

author: Kalvin
author_rank: Super Contributor
timestamp: July 21, 2015, 08:28:59 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 21, 2015, 08:29:46 am
content: Quote from: Pathfinder0311 on July 20, 2015, 10:40:52 pmI'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.

author: Pathfinder0311
author_rank: Newbie
timestamp: July 21, 2015, 03:15:02 pm
content: Quote from: Howardlong on July 20, 2015, 11:21:37 pm@Howard LongI 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  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

author: Pathfinder0311
author_rank: Newbie
timestamp: July 21, 2015, 03:23:46 pm
content: Quote from: nctnico on July 21, 2015, 08:29:46 am@nctnicoRight 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"?

author: Howardlong
author_rank: Super Contributor
timestamp: July 21, 2015, 03:31:39 pm
content: Quote from: Pathfinder0311 on July 21, 2015, 03:15:02 pmThat'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.

author: diyaudio
author_rank: Frequent Contributor
timestamp: July 21, 2015, 03:48:14 pm
content: Quote from: coppice on July 21, 2015, 05:43:53 amQuoteSays 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 theADSP-SC58x and ADSP-2158x, silicon ships next year 2016 end of fall.QuoteFollow the Ti DSP series and see what they think about that statement., pretty interesting view, one which I share as well.

author: Marco
author_rank: Super Contributor
timestamp: July 21, 2015, 05:25:19 pm
content: Quote from: Howardlong on July 21, 2015, 03:31:39 pmOr 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

author: nctnico
author_rank: Super Contributor
timestamp: July 21, 2015, 06:01:55 pm
content: Quote from: Pathfinder0311 on July 21, 2015, 03:23:46 pmThe 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.

author: coppice
author_rank: Super Contributor
timestamp: July 22, 2015, 06:46:01 am
content: Quote from: Pathfinder0311 on July 21, 2015, 03:15:02 pmActually, 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.

author: nctnico
author_rank: Super Contributor
timestamp: July 22, 2015, 08:07:13 am
content: Quote from: Pathfinder0311 on July 21, 2015, 03:15:02 pmYou 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.

author: Kalvin
author_rank: Super Contributor
timestamp: July 22, 2015, 11:32:43 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 22, 2015, 06:22:07 pm
content: 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

author: Howardlong
author_rank: Super Contributor
timestamp: July 22, 2015, 09:09:20 pm
content: Quote from: poorchava on July 22, 2015, 06:22:07 pmIf 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.

author: legacy
author_rank: Super Contributor
timestamp: July 23, 2015, 10:04:53 pm
content: Quote from: nctnico on July 22, 2015, 08:07:13 amI agree, FPGAs require a lot of effort, knowledge and time.