Is there a comprehensive comparison of ADI Audio DSPs to help choosing one for a product?

Hello Ferrograph,

The comparison you are asking about does not exist and is difficult. Part of it is the history here in the company. The SHARC and BLACKFIN lines are designed and supported by the DSP group. The SigmaDSP line is designed and supported by the audio group which has since been split up into consumer and automotive teams. Most of it is still in the consumer group which is where I am. 

The basic comparison is that the SigmaDSP is deigned for audio. It has many features internally what make it good and efficient for processing audio. SigmaStudio makes it easy to use. The stream based processing makes it dependable less susceptive to time based criteria like interrupts. However, they are nowhere near as flexible and programmable than the general purpose DSPs. Those you can program in C. the SigmaDSP you cannot. The tools are free for SigmaDSP making it low cost development. The SHARC and Blackfin are not free and if you need to do anything fancy you end up having to buy 3rd party extensions raising the cost of development. 

The SHARC and Blackfin have good security features. The SigmaDSP does not. 

Then the further comparison starts going down the road of what the application is. Some of it I already touched on above but I may have missed some others. 

So this is the crib notes version. You can always contact your local sales rep and they can often help you with the specifics of your application. 

Sometimes the choice is a no-brainer and often it can be 50/50 and come down to cost, development time, familiarity with the tools, etc. 

Thanks,

Dave T

A follow up question - something else I was looking for was latency ballparks of a typical system with external ADCs and DACs since my product need better ADC performance than the built in ones. Is there any line that is distinctly better for real-time processing?

A follow up question - something else I was looking for was latency ballparks of a typical system with external ADCs and DACs since my product need better ADC performance than the built in ones. Is there any line that is distinctly better for real-time processing?

Hello Ferrograph,

I will answer both of your recent questions together here. 

Security is certainly an issue. There have been some posts about it on the forum and understandably people have not gone into details on how they secure their products. Nobody is going to say "Hey! I figured out a good way of doing security and here is how I did it!" 

They also do not tell me which is good so I cannot accidentally report how it is done. So let me give you a few ideas and keep in mind that there is no such thing as a perfect security method. 

One way is to use a system controller to boot up the DSP. Most controllers have some basic code protection for their programs so this just piggy-backs onto the existing security. The obvious hole is this method is that anyone can "sniff" the SPI/I2C comms and capture the program. But then going to other things helps this. 

The other things are things like GPIO pins set in a certain way so it knows the correct hardware is there. Having the program have incorrect settings and channels muted so that after programming the controller has to send corrections to allow the program to work. Again, this can be sniffed. 

You can set a DC cell to a certain value. Then figure out a way to handshake between the controller and the DSP to allow it to function only if it has the correct value. Like the chip ID of the controller? This would have to be programmed custom into every product on the production line so this is a bit difficult. 

I suppose there are other ways you could encrypt data in the program that would only be fixed with the correct decoding. 

With the Sigma300/350 parts you can be more creative because it is able to write to its own registers. So you could have it disable itself or enable itself if it sees correct things in the system. It can also read from other parts so you can get creative with values stored in EEPROM or look for correct registers in other parts of the system. 

I suppose someone could implement runtime counters and things that test to see if the system is legit. 

On to the next topic. 

Since you are not settled on one particular part it makes it difficult.  Real-time processing is still a relative term. Latency of, let's say,... less than 10ms is usually fine for most real time systems. Certainly if it is under 2ms which is usually fairly easy to obtain since these DSPs are stream based not block based processors. The latency mostly resides in the converters and in the sample rate converters if used. The DSP cores all process the current sample during the current sample period and provides and output for every sample period. So the core has a latency of one sample. (of course if you have a delay or have an EQ there will be some phase shift but that exists in the analog world as well.) 

Depending on the DSP there are usually two or three samples for resyncing of the data internally for transfer from the serial port to the core etc. Then of course there is the one sample period to shift in and out of the serial port if you use an external converter. So the Sigma300/350 ends up with about a 6 or 7 sample period latency depending on the clocking modes. So it is really good. 

The converters have more latency and you will have to consult the datasheets for those. The ADAU1372 is a good low-latency codec but it is a trade off for out-of-band noise and aliasing performance. 

For users who are doing noise cancellation then it is a whole other world. Real-time really becomes "real time". For those systems a latency from analog to analog needs to be in microseconds and less than ten is great. So the ANC codec parts are what is needed. The ADAU1787, the ADAU1777, the ADAU1797, the ADAU1860 etc. Those parts have a fast DSP core that runs super fast and is a filter engine for low latency. 

Dave T

Dave, thanks for your time and the comprehensive answers above. Like myself I think many will find this information very helpful.

Thanks for the suggested parts relating to latency. I will look these up.

Thanks again for really great thorough answers!

Pete.