Model-Based Design Toolbox (MBDT)中的主题 Re: MBDT blocks for measuring Idle Time or ProcessorLoad

MBDT blocks for measuring Idle Time or ProcessorLoad

chrisc1 — Tue, 23 Jun 2020 16:13:28 GMT

Is there any documentation page that explains how to place a block in MBDT that measures Idle Time or Processor Load?

I can see this article(s) https://community.nxp.com/thread/471486 ; https://community.nxp.com/thread/328304 ; https://community.nxp.com/thread/51447

but that doesn’t give many details for a Simulink implementation. I looked for an Idle Counter block but have not seen one so far. However I can see a Profiler block so I am thinking that I could use that if all of my code (for the moment) runs in a single task.

I'm aiming to check how hard I’m pushing the processor with what I’ve implemented so far, and how much difference I can make by slowing down the task. :-) Generally I try to stay within 75% ProcLoad.

Re: MBDT blocks for measuring Idle Time or ProcessorLoad

constantinrazva — Tue, 23 Jun 2020 16:35:49 GMT

Hello chrisc@rmlgroup.com ,

We do not have a block that can tell you the CPU load, but I can think of ways in which you could achieve that.

Lets look at how an application generated by our toolbox looks like (main parts in regards with execution time):

We have the following:

Step – a function called periodically, with a frequency controlled by the Discrete Step value set in the model
Interrupts – asynchronous events that can be further grouped into 2 categories:
- Events that occur at a known period – e.g. a LPIT block that is used to trigger the Fast loop system for motor control applications – the important part is that you control the frequency at which this event occurs
- Events that have an unknown period – e.g. receiving a message via UART/SPI/I2C/etc. – this is something that you have no control over, it can happen any time
Initialization – this is an important part of the application, but for CPU load it is of no importance
IDLE – this is the time period in which the Step function finished execution and awaits to be re-triggered and you have no ISR to execute (no such events were generated)

Looking at these, I see 2 options:

Either calculate the IDLE time between 2 events that trigger the Step function to be executed
Either calculate the time you spend in Step + time spent in ISRs, all before a 2^nd start of the Step function

For the 1^st option, it’s harder to implement just in Simulink, so lets explore the 2^nd option.

To get the CPU Load, we’ll calculate it like this:

CPU Load = Step Load + ISR Load

For this, we’ll start with the Step time – you can use the profiler block, put it into the top model and you’ll get the total execution time of the Step function. This is easy enough:

Step load = step execution time / discrete step value

Now onto the ISRs – this is where it gets a bit more complicated. I have grouped them into 2 categories (see above) for the following reason: even if we can calculate the execution time using the same Profiler blocks, we do not know the frequency of all events – for those controlled by the LPIT blocks, we can do the same as for the Step; but for the other, we can’t include them into our calculation.

I’m thinking that these kind of events tend to have small ISRs, so if we’re not aiming for perfect accuracy for the CPU load calculation, it should be close enough without taking them into account. If we do this, we end up with the following:

ISRn Load = ISRn execution time / ISRn period

To get ISR total Load we just sum every ISRn Load.

Basically you end up having to put 1 profiler block in the main loop (top model) + 1 profiler block per ISR. At the end, you can get these values in FreeMASTER and use them to get an approximation for CPU Load.

Let’s take an example:

We have set the following:

discrete time: 1s (so step will be triggered every 1s)

step execution time: 0.2s (code for step takes 200ms to execute)

ISR1 freq: 0.2s (we trigger a subsystem using LPIT block every 200ms)

ISR execution time: 0.1s (that subsystem takes 100ms to finish it’s execution)

Note: in this example ISR1 has higher priority than step

Time     -            Function starting execution
0.0        -            ISR1
0.1        -            Step
0.2        -            ISR1
0.3        -            Step
0.4        -            ISR1
0.5        -            IDLE
0.6        -            ISR1
0.7        -            IDLE
0.8        -            ISR1
0.9        -            IDLE

1.0 – the whole process starts repeating

Here we can see the following:

ISR1 execution time = 5 x 0.1s = 0.5s
step execution time = 1 x 0.2s = 0.2s
idle = 3 x 0.1s = 0.3s

So CPU load is 70%. Now lets test out the formula I proposed earlier:

Step load = 0.2 / 0.1 = 0.2 = 20%
ISR load = ISR1 load = 0.1 / 0.2 = 0.5 = 50%
CPU Load = Step load + ISR load = 20% + 50% = 70%

Note: the profiler block returns a value in ticks – those are ticks at a 40MHz 20MHz (edited) frequency – you can use this information to convert from ticks to execution time (both for the main loop and other ISRs).

Note2: you must select a different index for each profiler block (option available in the mask) – otherwise the values will just overwrite one another.

I hope I made things clear about how you could get the CPU load with our toolbox and FreeMASTER.

Kind regards,

Razvan.

Re: MBDT blocks for measuring Idle Time or ProcessorLoad

chrisc1 — Thu, 25 Jun 2020 09:15:11 GMT

Thank you constantinrazvan.chivu

In a previous post How do I use the Profiler Function correctly? you mention a ratio of SPLL/4.

If this is the case, then the value I see displayed in FreeMaster of 135690 should be used in such calculation (I think):

135690 ticks / 80 MHz / 4 = 424 microseconds

My whole model is running at 0.005 seconds, so I'm not sure if this would indicate a very approximate processor load of 8.5% or if I need to carry out a further calculation to obtain that value. As mentioned above, at the moment I only really wish to check from one build to another that I don't add anything that has a big slow-down kind of impact.

Much appreciated the help, thank you.

Chris

Re: MBDT blocks for measuring Idle Time or ProcessorLoad

constantinrazva — Mon, 29 Jun 2020 08:37:25 GMT

Hello chrisc@rmlgroup.com,

On that thread you linked I was right about the frequency of the profiler – it is indeed 20MHz, as it is SPLL divided by 4, but I have made an error regarding to the calculations.

If you have 135690 profiler ticks (clock frequency being 20MHz), you’ll get 135690 / 20000000 = 0.00678s = 6.78ms.

I will have to take a look at where in the model you are putting the profiler block, as it can’t take 6ms to execute a task that is called upon every 5ms – either the application is not running correctly, either the number is calculating something else – but I tend to think that you are using the block correctly, and it just can’t fit into the 5ms window you want to use.

I will correct the other thread (which you linked) – I talked so much about core ticks vs profiler clock ticks and how to convert from one into another that I ended up confusing myself on how you should calculate the absolute execution time.

To make it clear, you should get the number returned by the profiler block (that has frequency of 20MHz) and divide it to this exact frequency to get the result expressed into seconds.

Execution time = profiler ticks / 20 000 000

You can also convert from profiler ticks to core ticks by multiplying this number by 4.

Core ticks = profiler ticks x 4

The period will remain the same, but now you’ll have the following:

Execution time = (profiler ticks x 4) / (20MHz x 4)

As you can see, as both the nominator and the denominator have been multiplied by the same constant, if you simplify this, you’ll end up with the first formula.

Hope this clears things up a bit – just to be sure, you can send me the model or explain where you put the profiler block in regards to the model, just to make sure the number we are seeing is representing what we think it is. You could also send a picture where you just take out other blocks that you don’t want to share – I’m interested only in how you measure the time.

Kind regards,

Razvan.