3
\$\begingroup\$

I'm finding difficulties choosing an adequate processor solution for my application from my null experience with DSP:

  • 8ch 24-bit @11025Hz I2S TDM Input
  • Beamforming + ASNR
  • MSS Multi-source selection
  • DRC Dynamic Range Compession
  • Frequency domain analysis (Real FFT)
  • 5 seconds STFT
  • Peak Finding
  • Comparison algorithms
  • Connectivity (Bluetooth @ Low Transfer Rate, just notifications)

Application parameters

I'm considering both a design which includes a Host MCU or just the DSP.

So far I'm looking at SigmaDSP processors:

  • Pros: Provided I2S TDM interface, arithmetic blog for beamforming, cost
  • Cons: Buggy and limmited Graphical Programming Interface (no c programming), only Radix-2 Complex FFT and 50% overlap analysis window are available, lack of documentation for sending a signal via SPI to Host Controller

I'm also considering SHARC processors, which I find overkill for my application (no codecs, no output, single input port, etc.):

  • Pros: C programming flexibility, no need of Host Controller, provided I2S TDM interface
  • Cons: Lack of experience with DSP programming, cost of processor, development kits, emulators and software

My questions are:

  1. How to determine required system sources (memory, clock frequency, etc)?
  2. Any guidance/recommendations/other families/brands I should look?

Hardware I'm using...
2x Mic Array: https://www.notwired.co/ProductDetail/NWAUDICS52000-NotWired-CO/605574/?ProdId=605574&
I2S TDM to USB: https://www.minidsp.com/products/usb-audio-interface/usbstreamer

Thank you so much, Pedro

\$\endgroup\$

closed as off-topic by ThreePhaseEel, PeterJ, laptop2d, Daniel Grillo, Sparky256 Dec 22 '17 at 3:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Hi Pedro, your original title was "what to buy", and that's off-topic. However, your question is a totally different one: "What specs are relevant", and that is a very good and on-topic question, so I changed the title of your question! \$\endgroup\$ – Marcus Müller Dec 16 '17 at 14:47
  • \$\begingroup\$ However, it's not really clear what your sampling rates, algorithmic complexities etc are. From what you say , it sounds like you're dealing with audio sample rates (I2S input) and a rather benign amount of overall data(bluetooth), and don't have significant latency restriction at all (bluetooth). So, I'm not even sure I'd recommend a DSP at all – just use a bog-normale PC or raspberry pi or anything, somehow connect your I2S sensors, and write as much C on a proper operating system as you want. \$\endgroup\$ – Marcus Müller Dec 16 '17 at 14:50
  • \$\begingroup\$ Hi Marcus, thank you for the change on the title. I've added more detailed specifications on my application. Microphone Array Board uses I2S TDM format, which is not provided on most MCUs or single-board computers such as raspberry pi. Custom drivers could be developed but this is obviously not an option (high development cost). I do need a DSP. \$\endgroup\$ – Pedro Martinez Lopez Dec 16 '17 at 15:04
  • \$\begingroup\$ hm, I don't know, I2S is really pretty common. But you might be right, the additional lane with channel information might not be available on just any single-board computer. I'd probably just go and get a cheap FPGA (Ice40), and design a quick TDM-to-SPI converter. Note that TDM is not really a standard! So, be very sure that your source can talk to your processor, really. \$\endgroup\$ – Marcus Müller Dec 16 '17 at 15:11
  • \$\begingroup\$ (other than that, if the TDM standard used is really just I2S where consecutive frames just mean different channels, well, use bog-normal I2S hardware, and many single-board computers do have I2S, and pick these channels apart in software) \$\endgroup\$ – Marcus Müller Dec 16 '17 at 15:13
3
\$\begingroup\$

There are no magic formulas. However, for a very rough start, find the number of multiply-accumulates (MACs) you need to do per second. That gives you a lower bound on instruction speed.

To do that, you need to first decide on some parameters:

  1. The sample rate of each signal.

  2. The number of signals you will apply convolutions to.

  3. The width of each convolution in samples.

The total MACs per second is the product of all these. Figure any competent DSP can do a MAC every cycle once it gets going on a convolution. Of course there will be extra cycles to start and end each convolution, control overhead, communicating with elsewhere, etc. You might, for example, start out by reserving 25% of the processor cycles to other than MACs.

Often these processors come in a family of related devices. One strategy is to prototype with the biggest bestest, then scale down to just what you find you actually need in the production version. The extra headroom also allows you to do what-if tests in the prototype, add code that might aid in debugging or verification, etc. It can be very useful to have significant extra headroom in the first prototype.

\$\endgroup\$
  • \$\begingroup\$ Thank you for your asnwer @Olin Lathrop, specially for the strategy recommendation, which shows experience in the topic. I'll probably use ADZS-SC584-EZLITE which is applicable to multiple parts as you described. I'm still concerned though about community support on a relatively new 5th generation of SHARC processors. Also, CCES Embedded Studio is not free, which will be a constrain after the 1-year license. Finally I need to check whether if a TDM compatible serial port is available in the board, since many times ports are already used for other ADC/DAC codecs. \$\endgroup\$ – Pedro Martinez Lopez Dec 17 '17 at 19:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.