ADAU 1452 Multirate instruction cycles and program overrun

Hello Alex,

Thanks for your post. It brings up a subject of overrun trapping that I really have needed to post about but have not had the time until now.

But first, to answer your questions about the cycle usage report with multirate projects and I will also add projects with block processing. 

As you pointed out, the usage is separated by each sampling rate thread and the block processing thread.The total cycles shown are the cycles used by the code in that rate but the percentage is the percentage of usage of MIPS in the core rate. So they all should not add up to greater than 100%. The report does not provide a total of all threads at the bottom. I suppose this is an oversight. For instance, in my little test project the 96k fs thread uses 357 cycles and the 48k fs thread uses 315 cycles. But half of the 48k code is run in each 96k frame so the usage is half. The report says 96k uses 12% and 48k uses 6% even though they use almost the same amount of MIPS. 

For the Block processing the total amount of MIPS used is divided by the block size. In my example the block size was 64 so this means it is split up into 64 small chunks of code and fully executes every 64 frames. So the 3,371 cycles is divided by 64 which is only 2% of the MIPS used in each frame. 

So in short, use the percentage to give you an idea. If you need a more accurate number then you have to look at the cycle count and do a bit of math. Sorry about that. 

Now on to the overrun trapping. 

I initiated and pushed for this from within the company and the programmers took a little while but finally was able to implement it and they did a great job. It was in the 4.3 release but one small detail was not there but it is fully implemented in Rev 4.4 of SigmaStudio.

For single rate programs it is easy, it keeps up with the program execution and if the program does not complete when the interrupt at the end of the frame hits then it will trigger the error on the next frame. 

With multirate and block processing, it keeps track of each thread separately so if any thread somehow stays too long in a loop and runs past the end of that thread then it will report an overrun for that thread. A thread can overrun and not trigger the main thread's overrun. However, it would depend on how much it overran of course and the number of available unused MIPS in the main thread. 

Step 1, Enable the overrun trapping:

Right click on the DSP icon in the Hardware Config page and select "Advanced Framework Configuration"

Then this window will appear:

Select the option to monitor the overrun errors. 

To see the results when the DSP is running the program you go to the Register Controls tab. There is a tab at the far right called "Framework". This is what you will see when you are running a single rate project.

You can click on "READ" as often as you like and it will display if there has been any errors. The errors are sticky so you do not miss any single frame overrun. Once it has tripped you should clear it to see if it sets again quickly or if it takes a lot of time. It might provide a clue as to what is causing the issue. 

What also happens is that the Software Panic Value 0 register will be stuffed with a value. Normally, it is zero. It will also set the Software Panic Flag in the panic manager. So if you are using the panic manager this can be included when monitoring the health of the DSP.

Note that it also gives you some statistics for the number of cycles used and the number of free cycles. The only issue is that it is not possible to provide the cycle statistics with a multirate thread. I am actually not certain if it still is good for block processing with a single sample rate. I expect it is because it is able to predict the number of cycles needed per sample period but I will ask the programmers.

So if you have a multirate project. Each thread will be reported separately. Here is what it will look like:

You will see each sample rate reported and the block reported.

Hopefully, this will be handy for you.

Dave T 

Hello Alex,

Thanks for your post. It brings up a subject of overrun trapping that I really have needed to post about but have not had the time until now.

But first, to answer your questions about the cycle usage report with multirate projects and I will also add projects with block processing. 

As you pointed out, the usage is separated by each sampling rate thread and the block processing thread.The total cycles shown are the cycles used by the code in that rate but the percentage is the percentage of usage of MIPS in the core rate. So they all should not add up to greater than 100%. The report does not provide a total of all threads at the bottom. I suppose this is an oversight. For instance, in my little test project the 96k fs thread uses 357 cycles and the 48k fs thread uses 315 cycles. But half of the 48k code is run in each 96k frame so the usage is half. The report says 96k uses 12% and 48k uses 6% even though they use almost the same amount of MIPS. 

For the Block processing the total amount of MIPS used is divided by the block size. In my example the block size was 64 so this means it is split up into 64 small chunks of code and fully executes every 64 frames. So the 3,371 cycles is divided by 64 which is only 2% of the MIPS used in each frame. 

So in short, use the percentage to give you an idea. If you need a more accurate number then you have to look at the cycle count and do a bit of math. Sorry about that. 

Now on to the overrun trapping. 

I initiated and pushed for this from within the company and the programmers took a little while but finally was able to implement it and they did a great job. It was in the 4.3 release but one small detail was not there but it is fully implemented in Rev 4.4 of SigmaStudio.

For single rate programs it is easy, it keeps up with the program execution and if the program does not complete when the interrupt at the end of the frame hits then it will trigger the error on the next frame. 

With multirate and block processing, it keeps track of each thread separately so if any thread somehow stays too long in a loop and runs past the end of that thread then it will report an overrun for that thread. A thread can overrun and not trigger the main thread's overrun. However, it would depend on how much it overran of course and the number of available unused MIPS in the main thread. 

Step 1, Enable the overrun trapping:

Right click on the DSP icon in the Hardware Config page and select "Advanced Framework Configuration"

Then this window will appear:

Select the option to monitor the overrun errors. 

To see the results when the DSP is running the program you go to the Register Controls tab. There is a tab at the far right called "Framework". This is what you will see when you are running a single rate project.

You can click on "READ" as often as you like and it will display if there has been any errors. The errors are sticky so you do not miss any single frame overrun. Once it has tripped you should clear it to see if it sets again quickly or if it takes a lot of time. It might provide a clue as to what is causing the issue. 

What also happens is that the Software Panic Value 0 register will be stuffed with a value. Normally, it is zero. It will also set the Software Panic Flag in the panic manager. So if you are using the panic manager this can be included when monitoring the health of the DSP.

Note that it also gives you some statistics for the number of cycles used and the number of free cycles. The only issue is that it is not possible to provide the cycle statistics with a multirate thread. I am actually not certain if it still is good for block processing with a single sample rate. I expect it is because it is able to predict the number of cycles needed per sample period but I will ask the programmers.

So if you have a multirate project. Each thread will be reported separately. Here is what it will look like:

You will see each sample rate reported and the block reported.

Hopefully, this will be handy for you.

Dave T 

Hi Dave,

That works just as you've described, thanks.

However, it does consume 19 cycles in each thread.

Alex

Hello Alex,

Yes it does. That is the tradeoff but with 6,144 cycles at 48kHz it should not cause issue but for the largest programs. In that case you need the monitoring. 

Dave T