ADAU1452 DM0 delay issue
There is a problem in the way sigmastudio allocate DM0 memory for DM0 delays. Here is an example schematic:
It's a simple DM0 delay and a simple DM1 delay.
Here is the modified and commented compiler_output.log:
ADAU145X Assembler, Analog Devices Inc.
Version: 3.13.1,1065 (built 5/2/2016)
##### Summary #####
DM0 RAM used: 19238 (of 20480)
DM1 RAM used: 19208 (of 20480)
##### DM1 Allocation Summary #####
ModuloMemoryRegions: Addr: Modulo: Length:
_DEFAULT_MODULO_1 0x0 1 19204
Address: Module: Param:
0x0 Link0/Link0_SHIFTREG3 =0x00000000
0x1 Link1/Link1_SHIFTREG5 =0x00000000
0x2 Link2/Link2_SHIFTREG7 =0x00000000
0x3 ADAU145XAssignableDelayAlg2 buff0 [19201] =0x00000000, ... // DM1 delay buffer
0x4B04 __DM1_PADDING__ __DM1_PADDING__ [4] =0x00000000,0x00000000,0x00000000,0x00000000
##### Exported C for DM1 #####
#define DM1_DATA_ADDR_IC_1 43780 // start address of DM1 memory
#define DM1_DATA_SIZE_IC_1 16 // 16bytes
ADI_REG_TYPE Param_Data_IC_1[PARAM_SIZE_IC_1] = {...}; // 4x4bytes
That is the standard case. There are 3things allocated. The DM1 delay is allocated last. As it is a delay, no need to initialize its values. The C array is only 16bytes long.
##### DM0 Allocation Summary #####
ModuloMemoryRegions: Addr: Modulo: Length:
_DEFAULT_MODULO_0 0x10 1 19204 // I don't know what Modulo means here. Default 1 memory?
_STACK_MODULO_ 0x0 0 16
Address: Module: Param:
0x0 __STACK__ __STACK__ [16] =0x00000000, ...
0x10 ADAU145XAssignableDelayAlg1 buff0 [19201] =0x00000000, ... // DM0 delay buffer
// This shouldn't be there but at the end of DM0 Allocation!
// If you use a DM0 delay, it changes the SafeLoad addresses!
0x4B14 MP1_DM0 [4] =0x00000010,0x00000010,0x00004B04,0x00000000
0x4B18 MP1_DM1 [4] =0x00000000,0x00000000,0x00004B04,0x00000000
0x4B1C __SafeLoad_Module__ data_SafeLoad [5] =0x00000000,0x00000000,0x00000000,0x00000000,0x00000000
0x4B21 __SafeLoad_Module__ address_SafeLoad =0x00000000
0x4B22 __SafeLoad_Module__ num_SafeLoad =0x00000000
0x4B23 ADAU145XAssignableDelayAlg1 delay =0x00000000 // DM0 delay (amount of delay used)
0x4B24 ADAU145XAssignableDelayAlg2 delay =0x00000000 // DM1 delay (amount of delay used)
// ADAU145XAssignableDelayAlg1 buff0 should come here instead
0x4B25 __DM0_PADDING__ __DM0_PADDING__ [4] =0x00000000,0x00000000,0x00000000,0x00000000
##### Exported C for DM0 #####
#define PARAM_ADDR_IC_1 0 // start address of DM0 memory
#define PARAM_SIZE_IC_1 76964 // 4x10bytes + 4x19.2kbytes(DM0 delay) + 4x31bytes from the beginning of DM0 memory
ADI_REG_TYPE DM1_DATA_Data_IC_1[DM1_DATA_SIZE_IC_1] = {...};
If you use a DM0 delay:
- The Safeload addresses change.
- A 19.2ksamples DM0 delay, leads to a >4x19.2kbytes DM0 memory initialization.
If you use a DM1 delay:
- The Safeload addresses don't change.
- The impact of the DM1 delay on the DM1 memory initialization is negligible.
If you do not initialize the DM0 delay memory, it works fine. But you have to manually process the generated files to do that. In this example you could easily get the application working only using the DM0 C array "from 0x4B14 until the end". So it's a 84bytes reduced array instead of the 77kbytes generated array.
Since using DM0 delays also change the Safeload addresses, I think it would be a great improvement that sigmastudio allocate the delay at the end of DM0 allocation, and remove the delay's buffers from DM0 memory initialization.
Best regards,
Simon
Audio Signal Processors
adau1452
adau1452 dm0 delay issue memory bug
SigmaDSP Audio Processors
Hi Miguel,
Thank you for your answer. I have a better understanding of the way the memory is working now
(note that the new voltage controlled delay algorithm for ADAU145X from SigmaStudio 3.13.1 beta, also have the DM0 allocation issue).
While using the USBi to program the ADAU145X, there is no problem at all with the actual allocation method.
Of course if we use DM0 delays the safeload addresses are changing, and the DM0 SPI-load could take some times, but it isn't even noticeable. So everyone who only use USBi (and I guess that's >90% of the users) won't be impacted.
I personally use a 8bits MCU master to load the code into the DSP, and then command it. Like every small MCU, mine has a very limited amount of FLASH (31.5kB) and RAM (2kB). I couldn't send the program, DM1 and DM0 arrays in 3blocks due to RAM limitation, so I wrote a RAM friendly 128bytes buffer SPI send function. Things went worse when I couldn't store the exported DM0 array, because it was waaay too large (in fact, larger than my 16bit address pointer ). As I previously successfully used DM1 delays, I did some researches to find that the problem was inside the DM0 memory allocation. So I tried to remove the leading-zeroes from the DM0 exported array and it worked. So with a few C macros, it is easily acheivable.
For the safeload, I guess it's not a big effort to seek in files for the right safeload address to use.
My project is working 100% with the tweaked files, so I don't need a fix at all cost.
I have no idea of the difficulty of the DM0 allocation change, and the effect that it would have on older ADAU145X projects.
From my point of view, it looks like it's possible to copy the method used in DM1 allocation into the DM0 allocation, and the backward compatibility is achieved by opening the old project and pressing the link-compile button , but that may be more complicated than that!
It would be a great future improvement to have a MCU-user friendly allocation method for DM0 delays, but it can wait.
Best regards,
Simon
Hi Simon:
Modulo memory is rotating memory and since it rotates quickly there is no explicit need to initialize it (it however is good practice).
I agree that Safeload should be placed first and fixed. The tool should try to preserve it's memory location to avoid the need to move addresses every time there is a new delay line added to the schematic. The problem we face at the moment is how to best maintain backwards compatibility. Any preference?
We'll further discuss this issue but chances are that existing schematic will continue to work the way they currently do and once we find a good approach future schematics will have a different ordering mechanism.
Please comment.
In any case, it seems like you have things under control at the moment and you are looking for future improvements. Is this true?
Thank you for your feedback.
Miguel
Hi Miguel,
i would prefer a constant or fixed Safeload address. It is a nuissance that after every minor change you have to manually check the safeload address and to alter the tables if it has changed.
So: YES fix the Safeload address,
Best regards
Bernd
Modulo memory is rotating memory and since it rotates quickly there is no explicit need to initialize it (it however is good practice).
Actually it's initialized by the program when it starts.
I agree that Safeload should be placed first and fixed.
Safeload isn't the only problem, the same applies to every memory location you might want to safeload to. It would be nice in general to have control over where the linker places parameters, e.g. to group all biquads together so you can treat them as one array in your software. This would also mean you no longer need to recompile your control application after every minor change in SigmaStudio.
As long as any relevant stuff moves around, having SafeLoad in a fixed location doesn't really have any added value I think. (Its location however does very badly need to be added to the export data, a point with has been raised in another recent thread.)
The problem we face at the moment is how to best maintain backwards compatibility.
Right now you can make absolutely no assumptions on where SigmaStudio places things, so there's not really any backward compatibility you can break. I did a quick search across a directory with projects and got:
$ grep -h data_SafeLoad proj/*/ParamAddress.dat
__SafeLoad_Module__.data_SafeLoad 20
__SafeLoad_Module__.data_SafeLoad 24
__SafeLoad_Module__.data_SafeLoad 20
__SafeLoad_Module__.data_SafeLoad 68
__SafeLoad_Module__.data_SafeLoad 68
__SafeLoad_Module__.data_SafeLoad 92
__SafeLoad_Module__.data_SafeLoad 88
__SafeLoad_Module__.data_SafeLoad 20
__SafeLoad_Module__.data_SafeLoad 24
__SafeLoad_Module__.data_SafeLoad 20
__SafeLoad_Module__.data_SafeLoad 72
Please log in to reply.