Seth on Simulink

November 6th, 2009

Aarti recently posted about Variable Size Signals in Simulink. Han responded with this comment:

Aarti,
I would be interested in the effect on RTW generated code for variable size signals. Could you show some examples?
-Han

Here is Aarti's response.

Hi Han,

Thank you for your comment. In the case of a variable size signal, the generated code allocates the maximum possible size for the input/output variables.

This allows signal sizes to vary during execution (as opposed to being hard-coded after model compilation). The generated code also propagates signal sizes through the model and accordingly assign the required dimension to signals. The algorithm code only needs to operate on the portion of memory required (thus saving execution time).

The following model uses the Switch Block to change the size of its output signal.

The generated code looks like this:

  /* Switch: '/Switch' incorporates:
   *  Inport: '/In1'
   *  Inport: '/In2'
   *  Inport: '/In3'
   */
  if (In2 >= 0.0) {
    model_XDim = 1;
    X[0] = In1;
  } else {
    model_XDim = 5;
    for (tmp = 0; tmp < 5; tmp++) {
      X[tmp] = In3[tmp];
    }
  }

  /* Gain: '/Gain' */
  model_YDim = model_XDim;
  loop_ub = model_XDim - 1;
  for (tmp = 0; tmp <= loop_ub; tmp++) {
    Y[tmp] = 2.0 * X[tmp];
  }

In the generated code, notice how the variable model_Xdim has the lower and upper bound pre-allocated as 1 and 5, 5 being the width of the 3rd Inport block. Using these values, the loop_ub variable for the Switch block is calculated.

Thanks!

Aarti

Is this the code you expected? Leave a comment here and tell me about it.

01:48 UTC | Posted in Code Generation, Signals, What's new? | Permalink |

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.

4 Responses to “Generated Code for Variable Size Signals”

1. Han Geerligs replied on November 6th, 2009 at 12:38 UTC :
   

   Hi Aarti,

   thanks for providing the example!

   I was just wondering why the lines
   model_YDim = model_XDim;
   loop_ub = model_XDim - 1;
   for (tmp = 0; tmp <= loop_ub; tmp++) {
   Y[tmp] = 2.0 * X[tmp];
   }

   aren’t converted into
   for (tmp = 0; tmp <= model_Xdim-1; tmp++) {
   Y[tmp] = 2.0 * X[tmp];
   }

   This would be a special case of expression folding.

   I was wondering if this optimisation was considered at design/is planned for implementation?

   Han

2. Ashish Sadanandan replied on November 6th, 2009 at 18:24 UTC :
   

   Han,
   Sorry for butting in with a reply, but the modification to the for-loop you’ve suggested is really not an optimization IMHO. Even a moderately competent C compiler will generate identical code for the 2 versions since ‘model_Xdim’ is not being modified within the for-loop. However, if you have a really non-optimizing compiler, the code generated by your version would be very inefficient. So I feel its better to leave the implementation of that for-loop as it is.

   Ashish.

3. wei replied on November 7th, 2009 at 14:51 UTC :
   

   @Ashish, I agree with your observation on compiler optimization but fail to see why Han’s code would be less efficient than the original. Would you explain?

4. Ashish Sadanandan replied on November 8th, 2009 at 15:16 UTC :
   

   @wei, I was talking about the case where the compiler would perform the ‘model_Xdim-1′ operation each time through the loop before checking the exit condition.

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.