Why did the filter parameter order change ?

Beni Question

Mar 1, 2018 00:00

Hi,

In SS 3.15 Build 2 Rev 1721 a new algorithm for the double precision filters is used.

I checked how this will affect the parameters and found that the order of the parameters in RAM has changed.

The older version had the order A2 A1 B2 B1 B0.

The new version has the parameter order B2 B1 B0 A2 A1.

Now i have to maintain two methods for the parameter loading in my uC, far more worse is that old and new filters can not be mixed in the design. This of course can not be handled properly.

Why did AD do this ? This seems not to make much sense.

If i want to add one filter to an existing old design, all old filters (up to several hundred) have to be changed. And of course the uC code has to be changed as well.

My questions are:

Is there a way to use/add old (obsolte) algorithms in a new design to maintain code compatibility?

How can i distinguish between the algorithms ?

Where can i access the old algorithm ?

What happens if old and new algorithms are mixed in one design (one dsp)?

Any suggestions appreciated

Best regards

Bernd

sigma studio

filter parameter

version control

Report

ADIApproved Reply

Mar 1, 2018 00:00

Hi Bernd:

Are you comparing the 144x family of IC with the 145x family of ICs?

the reason for us ADI to reorder algorithms, in many cases is to make best use of our SIMD instructions and optimize code. Doing so uses less instructions.

We do obsolete algorithms so that when user open older schematics, they get the same exact results except in the case of bugs needed to be fixed.

Hope this helps.

Miguel

Report

Beni Reply

Mar 2, 2018 00:00

Hi Miguel,

Thanks for your answer.

We are using both DSP's in existing products and also in one case both families in one product.

The code of the newer AD1452 was derived from the ADAU1442.

Now i have several products with AD1452 with filters with the older parameter order.

Since they are all running well i don't want to touch them to change to the new filter form since it seems a big change.

Best regards

Bernd

Report

ADIApproved Reply

Mar 2, 2018 00:00

Hi Bernd:

I understand, and we sorry about the extra work Our intention was to provide the most compact (optimized) code possible on either DSP and for this, we needed to modify the coefficient ordering. We also introduced a concept of indirect parameter addressing that allows changes in the schematic without uC changes (when everything is written with this premise). Simply right click on the DSP and you will find the "Indirect Parameter Address". If properly used, it's a very powerful tool to allow changes without affecting the code. A problem similar to what you are experiencing.

Best regards

Miguel

Report

Beni Reply

May 29, 2018 00:00

Hi Miguel,

I came back to your proposal of the "Indirect Parameter Address" today.

As i see it it is very similar to the safeload mechanism with an additional register for the individual parameter addresses.

But I am just not certain about the advantage. If i have to know all the parameter addresses i will be able to load them in the safeload register directly in the right order and have the same result. Maybe i am missing some thing.

Please do you have some additional information about this feature ? Unfortunately i did not find anything.

Best regards

Bernd

Report

ADIApproved Reply

May 30, 2018 00:00

Hi Bernd:

the benefit:

When you change the schematic, after the selection of those run time parameters that change in your system. You don't have to recompile your uC code with further schematic changes as indirect parameter addresses will not change.

This is of course with the understanding the the entire program to download doesn't get compiled with your uC and instead points to a location from the EEPROM to view it's size to then download it. If the DSP program is compiled with your uC code, then there are little benefits to using the indirect parameter window as you are forced to recompile. The only benefit perhaps would that memories for your selected parameters remain in the same location, regardless of your audio signal flow (SigmaStudio schematic)

Let me know if this is clear.

Miguel

Report

Beni Reply

Jun 19, 2018 00:00

Hi Miguel,

it sounds good in principle. In a real project i will have to adjust this "Indirect parameter address" for every changable parameter. Say >200 biquads for a kind of mixing console. If i will forget even one single, the principle will not work.

Is this correct ?

I have to think about it. Now i do it by generating new address tables which works quite fast.

Anyway thanks for the explanation.

Best regards

Bernd

Report