Guy and Seth on Simulink

July 7th, 2010

I was recently asked, "Do you have some kind of list or simple rules to get high performance generated code using Real-Time Workshop?" I put the question to my colleague (and first guest blogger) Tom Erkkinen, and he came up with the following.

1. Use ERT based targets
2. Use Code Generation Advisor, with efficiency as top priority
3. Inline parameters
4. For floating point, use single precision signals (if your application allows for it)
5. For fixed point, remove unnecessary saturation checks
6. Limit use of nonvirtual buses, except at model boundaries
7. Use reusable subsystems
8. Use TFL when ANSI-C is insufficient
9. Use state machines only when really needed, otherwise consider using truth tables
10. Consider using Simulink lookup tables, your legacy tables may not be as optimized

What are your tips?

Do you use generated code in production? Leave a comment with your tips for generating high-performance code here.

By Seth Popinchalk

01:22 UTC | Posted in Code Generation, Real-Time Workshop, Simulink Tips | Permalink | 3 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.

3 Responses to “10 Simple Rules for High-Performance Generated Code”

1. KMR replied on July 10th, 2010 at 16:41 UTC :
   

   Seth,

   No disrespect to either you or Tom, but as somebody who has developed several large time-critical autocoded applications, I confess I find this list pretty simplistic. In my experience, reducing unnecessary data copying is the biggest potential speedup, which I think is the point of item 6, but item 7 can increase data copying. And replacing state machine with truth tables may be possible for very simple logic flow, but I don’t see as realistic in a large system. Finally, I’d like to see some timing numbers on item 4: modern processors seldom have a significant slowdown on double computations vs float computations (unless you’re using the vector registers, which TMW doesn’t support to my knowledge except in some experimental table lookup code that isn’t readily available at this time).

   I guess what I’m really saying is that I’d like to see a more detailed version of each of these and what it’s really getting at.

2. Seth replied on July 12th, 2010 at 00:45 UTC :
   

   @KMR – The list was intended to be simple, and to stimulate conversation. So, thanks for that. I agree that more detailed explanation of each of these is in order. I’ll see what kind of simple examples we can pull together to further this discussion. Thanks for the feedback!

3. Klaas Gadeyne replied on July 13th, 2010 at 09:29 UTC :
   

   One interesting thing to note here seems to be the notion of a http://en.wikipedia.org/wiki/Platform-independent_model vs http://en.wikipedia.org/wiki/Platform-specific_model . To me, at first sight, it seems that at least more separation is needed for some of the above items. E.g. item 6: when rapid prototyping a model on a platform with a lot of resources, I might prefer to use nonvirtual buses (e.g. to improve code readability and ease debugging), whereas, for the final deployment on my embedded hardware, I’d like to use the virtual ones. However, I would like to have these platform choices separately from the model (or at least grouped in the RTW configuration dialog). Thoughts?

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.