First impressions and dynamic topologies for the ADAU1452

Hello Jerome,

There are no plans for a ADAU145x Hardware Reference Manual. The large 180-page datasheet is more of a combined data sheet and user's manual, most of the programmable registers are described in the "Control Registers" section of the datasheet.

The ADAU145x is a 32-bit quad-MAC SIMD DSP core, but the instruction set details are not documented in the datasheet (or user manual) and there is no standalone assembler or C compiler tool-chain for the product. In order to program the ADAU145x the audio DSP core, developers can only use SigmaStudio. However, SigmaStudio should be sufficient for both the "non-expert" and "expert" DSP Programmer to develop their proprietary algorithms. If a particular DSP block is not available, you can define your own DSP filter structure with the "Basic DSP" operations:

"Now, the first thing I tried to do is a standard IIR filter. I saw that FIR is supported, but, to my surprise, there is no IIR block!"

In addition to the FIR filter support, IIR filter blocks are also available within the SigmaStudio tools as Second Order, First Order, Lookup, Crossover, etc. If you need a higher order IIR filter structure, again, you can use the "Basic DSP" functions to design your own.

"Speaking about sampling rates, this DSP was intended to be used within a system using a non standard sampling rate (between 128-130kS/s). Much to my surprise, there is no way to set a custom sampling rate..."

The ADAU1452 was designed primarily to support many industry standard audio sample rates between 8 kHz and 192 kHz, and many industry standard sample rates can be generated using a 12.288 MHz or 11.2896 MHz XTALIN or MCLK source. However, the ADAU1452 allows for 4 input and 4 output clock domains on the I2S/TDM ports, and you can use the fractional Clock Generators to generate many frequencies between 128 to 130 kHz from either of these XTALIN/MCLK frequencies.

"The website is a mess; this chip is not even in the SigmaDSP page list! You have to make a search to find it!"

I agree with you on the fact that the ADAU1452 should be included in our SigmaDSP Audio Processor product page table. I will put a request in for our web developers to add this product into the table.

-JT

Hello JT,

Good answer, and it appears to be your first on the forum. Welcome aboard! Here's a few points in addition to what you detailed:

SigmaStudio's export framework can automate parameter addresses within a microcontroller program, see:

How do I create the microcontroller code to interface to my SigmaDSP?

The ADAU1452 is relatively new, so its toolbox is not as complete as that of lesser SigmaDSPs. Each SigmaStudio release adds more blocks. When fully stocked, likely its toolbox will do even more than that for the ADAU144x.

Best regards,

Bob

Thanks for the warm welcome Bob! Yes, my first post to the forum.

-JT

Hi Jerome:

Indeed the part is relatively new and we are in the process of improving/enahancing the library. To avoid the need for fixing addresses we provide a way to generate uC code that indirectly address parameters (through a name). In terms of filter usage, we do provide ways to utilize resources dynamically without a need to process filters all the time. Please look at the index selectable multiple filter. If you could share your application perhaps we could provide further support. If you perfer that we don't post in the forum and contact you directly we could also do that.

Please comment.

Miguel

Hello,

As English is not my original language, it is possible that there is a lack of nuance in my sentences.

Anyway, the answers here looks much more like workarounds than real elegant solutions.

The data-sheet contains only input/output part and registers. Obviously, if all programming parts are removed, no one wonders why it is only 176 pages. We are far from regular DSP data-sheets with hundreds of page only for overall aspect, not counting optimization aspects, hardware implementations and so on. Sorry, but the data-sheet of the evaluation board is not what I call a data-sheet.

IIR filters are not reduced to simple biquads. Factorizing high degree IIR into biquads is not a trivial task, especially finding the good combination that minimizes the round-off errors. And I wonder how to make this inside Sigmastudio in an efficient way. Higher order IIR with the basic DSP blocks ? Seriously... So why there is FIR block if they could be made with basic DSP blocks too. Why there is any "high level" blocks at all if anything could be made with basic DSP tools. I have a even better idea : why don't provide processor instruction blocks ? Where is the notion of "highly optimized blocks" if now filtering has to be used with standard calculus ? Is the resulting code will be optimized, especially if memory is scarce ? Is the accuracy and roundoff traps will be similar than a good IIR block ? IIR algorithm is so close to FIR, I hope that it will appear one day.

Why don't give tools to write blocks ? I saw that ADI is afraid to see its know-how stolen (I wonder how other library providers do), but I don't see any problem to offer the opportunity to users to create open source block added to proprietary ADI ones.

Now, the parameter location... One can propose any (more or less) automated way to generate header files, but why should I have to recompile controller code each time something changes inside the DSP that is not related to the parameters ? Is the SigmaStudio compiler guarantees that the locations will be kept if topology changes or if a new element is added ?

I saw that I can do anything with clocks from the hardware side (the data sheet is good here - I wonder why max frequency is 294.912MHz; will it explode at 294.913Mhz ?). I have a master clock which is used by other devices, so I have a fixed 25Mhz one for the DSP and the sampling rate is imposed by peripherals. Now, that is not the problem. Where in SigmaStudio I can assign the actual sampling rate when a block needs it to do its job ? Why there is not simply an edit box where I can put my sampling rate ? Is it too extravagant ?

Now, for me the weakest point is the hard-coded topology and all the limitations it implies. Using splitters, signal conditions or whatever are poor workarounds because useless code could be executed for nothing. The closest I could find are the multiplexers, but is the number of channels of a multiplexer is a parameter ? And, similarly, is the number of filters in the lookup filtering is a parameter ? In this case where are located the parameters of each filter ? One can make more and more blocks, but the limitations will remain the same. The best example of this is the 3 way crossover. A nice piece of work indeed. But how can I add 1db Tchebychev filters, a 6th order Bessel (while the Butterworth equivalent exists) or even a FIR ? How can I make a product that is different from my neighbor ? Rewriting with simple blocks a similar tool would be incredibly tedious (if it could fit in memory at all) !

In fact, it frustrating. Because this chips seems to be handcuffed by the tool. Humans are clever and always find a way to find a convoluted workaround. But this is the antithesis of the simplicity that is the raison d'être of this product at the first place. This is why I see here a bad marketing positioning (I'm pretty sure that the small amount of memory is a strategy to impose a "highly optimized blocks paradigm" where any DSP in this price range have multi-megabits of memory).

I'll continue to investigate (I paid for !) but every single aspect of what I needed for my project falls into a difficulty somewhere where it would be straightforward to handle with a standard DSP framework (programmatically speaking). Yes, it is frustrating.

Jerome.

Hi Jerome:

I understand your frustrations. But here are some clarifications. For IIR filters in fixed point the implementations that lowers quantization noise most are indeed simple biquads. Matlab could help you factorize your higher order filters if needed. Futhermore, when using simultenous biquads in different channels optimizations have been made to reduce the MIPS requirements, with methods like this we are able to calculate full biquads in very few instructions. For example the best case can produce 1 biquad in 1.5 cycles.

Our libraries are indeed optimized. Nowhere do we mention that using basic blocks would produce highly optimized code. Using simple blocks is (as you say) a current workaround while the library continues to grow. For example, our FIR filter peform 4 multiplications and 4 additions in a single instruction making this DSP a great FIR processor.

On the microcontroller generation, By doing some clever uC code you could indeed use the files to address parameter by reference without the need to recompile your code. When you add components though, you will need to recompile and unfortunately for this processor there is no built in MALLOC and/or stack that would allow you to generate dynamic programs and dynamic memory allocations. Keep in mind that this is NOT a general purpose DSP and the architecture is indeeed limited in this regard.

On the place to modify the sampling rate, when you right click input blocks, those provide a simple edit box to modify your sampling rate similar to what you describe.

Clearly you have time to point your frustrations and the deficiencies you find, perhaps by sharing you application and use cases we can be more proactive in helping you achieve what you need. If you think this is exposing your project or IP, perhaps you prefer that we contact you directly. In doing so, we can share the reasons for the decisions made and perhaps the discussion would help both of our interests.

Thank you and best regards

Miguel

This is mainly semantic game.

IIR is exactly the same kind of calculus than FIR, it's only a buffer manipulation with previous results used with arriving samples. This is trivial. Why would I use this complicated workarounds to do that. Do you mean that the current FIR implementation is not the one with the lowest quantization noise ? Because I could use bi-quads with the right coefficients to make a FIR too.

Some clever Uc code trying to guess parameter locations by reference. Sure. Totally compatible with the simplicity principle of this product. I wonder how this could be done.

By some clever tricks, I can do dynamic arrangements of blocks without malloc or stack too. I'm pretty sure that some clever people can create a block with dynamic structures.

The hardware has limitations, fair enough. That is something I accept with no problem (even if I can not prevent myself to think that it is a marketing decision, not a technical one - there is no reason to do a full featured DSP with only signal inputs/outputs like this one). What makes me reticent is that these limitations are not documented at all. Nowhere is clearly said that there is no way to program this DSP with a compiler and a language. It is even worse, because words like "compiler" are cited everywhere within the SigmaDesign product, which add more ambiguity. If I knew that, I would have thought twice.

If I have to change sampling rate manually for all blocks, I wonder what the sampling rate combo box is for. But, let's be honest, it is a detail I can live with.

My application is extremely simple : multi channel active filter. And this DSP is not adapted for that because of the hard coded topology. As I use arbitrary amplitude and phase IIR filters (not FIR), I see no simple solution. The order is unknown at runtime (it is measured and stored with a measurement system managed by the micro-controller, so Matlab ? No way !), the number of channels too. It's a pity, because this system removes a lot of effort for all peripheral stuff, like acquisition, restitution, input/output selection and so on (this is why I immediately wanted to get one). It looked great, really great ! But everything is hard coded, even the number of channels of the blocks. This is a huge limitation.

MiniDsp products uses SigmaDSP chips, and this product looks like a toy precisely because the hard-coding is visible even in the device software application. This is exactly the example of product I want to avoid to make.

Finally, my main reproach is that these limitations are not clearly documented. Marketing fairy tales don't work with engineers.I do think that ADI made a product mistake here.

Anyway, I'll continue to work with it and find a solution if I can. But it won't be not as elegant as I'm used to. Even FIR length is not a parameter...

J.

Hi Jerome,

I think Miguel answered most of your questions. Regarding your DSP system clock question:

"I saw that I can do anything with clocks from the hardware side (the data sheet is good here - I wonder why max frequency is 294.912MHz; will it explode at 294.913Mhz ?). "

Since the ADAU145x is primarily an "audio signal processor", the 294.912 MHz was selected as the maximum frequency primarily because it is an exact multiple of common clock oscillators used to generate common audio sample rates (48/96/192 kHz).

For example: 12.288 MHz and 24.576 quartz crystal oscillators are common for audio designs. 12.288 MHz x 24 = 294.912 MHz, and 24.576 MHz x 12 = 294.912 MHz. Table 25 in the datasheet shows how to set up the PLL to get you exactly or close to this maximum frequency using a wide range of crystal oscillator frequencies.

We do not test/characterize the ADAU145x beyond 294.912 MHz Core Clock. It might not explode above that frequency, but (insert standard ADI datasheet disclaimer here)...

-JT

HI Jerome:

Hope your product is doing good. If you need ADI to contact you directly to clarify some of your current understanding, please let us know. We can follow this conversation through email and / or we can setup a conference call.

Miguel

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin