Guy and Seth on Simulink

October 17th, 2011

Do you generate code to be executed on a multi-core processor? Wouldn't it be cool if you could decide which part of the model will execute on which core?

Modeling Concurrent Execution

This week, my friends Teresa and Tunc, will be introducing a new feature in R2011b designed especially for this: Modeling Concurrent Execution.

Teresa: Before we start, I need to make one thing clear: Modeling Concurrent Execution is not a feature to take advantage of your multi-core processor to speed up desktop simulations. If your goal is to speed up desktop simulation, I recommend looking at the documentation section Improving Simulation Performance and Accuracy and at posts in the Performance Category of this blog

Tunc: That’s right. Modeling Concurrent Execution is about controlling the execution of the code generated from a model on real-time rapid-prototyping and HIL targets, such as xPC Target.

Teresa: How much speedup can you expect for rapid prototyping with concurrent execution?

Tunc: That really depends on how much concurrency is available in the model. We have seen examples of models sped up by a factor 2 when using three cores. If your model can be partitioned into several tasks, the speedup could be significant.

How does that work?

Guy: I want an example! How can I do that with the model shown above? What do I need to do?

Tunc: To begin, you need to partition your model using Model Reference blocks. As explained in the Design Considerations section of the documentation, the top level of the model may only include model blocks and virtual connectivity blocks.

Guy: Here is my partitioned model. I did the partitioning based on the functionalities in the model. I have 4 components and the model seems to respect the constraints for a top level model, what's next?

Tunc: Now you need create a Concurrent Execution Configuration Set for all the model involved. This can be done using the Simulink.SoftwareTarget.concurrentExecution function, or from the Model Explorer:

Teresa: Once this is done, go to the configuration parameters of the top model, check the box saying This is the top of the model hierarchy and click on the Configure Tasks and Map Blocks To Tasks button.

Tunc: In the Concurrent Execution configuration parameters dialog box, you can define tasks and map blocks to each of these tasks. Let's begin by creating 2 tasks since your processor has 2 cores:

Guy: Based on my knowledge of the algorithms present in this model, I think the image processing component contains at least half of the computations. To divide things evenly, I will use one core for image processing and do the rest on the other core:

Teresa: Notice that in the model, color annotations have been added to show which task the blocks are mapped to. Also, you can see a "z^-1" showing that a delay is introduced to ensure data integrity in the communication between tasks.

Guy: Nice, so now I can click the build button and run that in real-time on my multicore xPC Target machine!

How does this scale up?

Teresa: This is easy for a simple model like this, but it could be complex with more blocks and tasks. What approach do you recommend to partition a more complicated model?

Tunc: It is an iterative process that requires refining the partitioning, based on how well it’s performing on target. It requires profiling analysis. To get started, though, Simulink is able to create the smallest partitioning schedule using automatic analysis of rates. You can click the Get Default Configuration button, and it will set up an initial mapping based on the tasks’ rates.

Teresa: I like that. So, I would go from this initial mapping and refine it?

Tunc: Exactly.

Now it's your turn

This was just a simple example to illustrate the basic functionality of this feature. I recommend going through Configuring Models for Targets with Multicore Processors to learn all the possibilities!

Are you excited by this feature? Leave us a comment here.

By Guy Rouleau

16:37 UTC | Posted in Code Generation, Guest Blogger, Model Reference, Model-Based Design, Modeling, Rapid Prototyping | Permalink | 2 Comments »

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Generating Code for Real-Time Multicore Systems”

1. Zhi Han replied on October 17th, 2011 at 20:58 UTC :
   

   Congratulations! It is great to see the new Simulink feature become a reality.

   I do have a question on the post, though. If speed up is not the objective, what is the ‘ultimate’ goal of modeling concurrent systems. I imagine the following story: someone has designed a model for a control system, and he needs to look into which micro-controller to deploy it to. He can choose a single-core controller, as well as a multi-core controller. Is this feature aimed to help him to analyze ‘what is the difference’ with concurrent architecture so as to evaluate which hardware platform to go with?

2. Teresa Hubscher-Younger replied on October 18th, 2011 at 18:00 UTC :
   

   Speedup or acceleration on your computer for running Simulink is not the objective of this feature. However, you are correct to point out that the end goal is to have speed-up on the final target. This feature should help with the story you outlined above where somebody is trying to look at different architectures and partioning for deployment on a multi-core target.

Leave a Reply

<pre class="code">
a = magic(3);
sum(a)
</pre>

These postings are the author's and don't necessarily represent the opinions of The MathWorks.