Guy on Simulink

Simulink & Model-Based Design

New Blocks in Simulink R2010a 25

Posted by Seth Popinchalk,

This is the time of year (in the northern hemisphere), where the ice and snow start to recede, the birds return, and the days start getting longer. It signals the arrival of ... a new release of MATLAB and Simulink! MATLAB R2010a is now available for download by licensed users from

Don't start with the release notes!

Instead of reading through the Simulink release notes, check out the Simulink 7.5 Latest Features page. It has most of the same information as the release notes, but it also includes links to a great presentation including highlights and screen shots from the release. There are links to videos that introduce some new features.

New Blocks

The rest of this post is dedicated to introducing you to a few new blocks in R2010a.

The Double Integrator blocks provides accurate simulation of velocity and position.

The Second Order Integrator block simplifies making accurate models of systems with limits. (Think of a ball hitting the ground: position stops at zero, and velocity immediately goes to zero also.)

Suare root blocks, signed square root and reciprocal square root.

These are different versions of the new Square Root Function block to perform square root, signed square root, and reciprocal square root operations.

Sin and Cos can be computed using the CORDIC approximation.

The Trigonometric Function block can now compute SIN and COS with the CORDIC approximation.

For Each subsystem enables simplified vectorization of scalar algorithms and provides  increased code reuse.

The For Each Subsystem makes it easy to take a scalar algorithm and apply it to a vector signal (or a vector algorithm and apply it to a matrix of signals, etc.). In the generated code, For Each Subsystems that have the same scalar algorithm but different dimension inputs can now share code.

Function call split block enables a single function call generator to execute multiple downstream blocks.

The Function Call Split blocks enable branching of function call lines. Now the same Function Call Initiator can execute multiple subsystems (eg: Function call generator, or Stateflow Chart.) This removes unnecessary rate transition blocks when there are data dependencies between two subsystems executed by the same initiator.

Multi Port switch with labels on the ports and the new Find block.

The Multiport Switch block now has labels on each of the ports to identify which values pass through that port. It also works with enumerated types. Now there is also a Find block, based on the popular MATLAB function. It will return the indices or subscripts of the non-zero elements of the vector/matrix signal at its input port. You can also return the values of those non-zero elements.

Now it's your turn

Read the release notes and tell me what new or enhanced feature of R2010a you are most interested in by leaving a comment here.

25 CommentsOldest to Newest

GG replied on : 1 of 25

Is it now possible, to use the data-store block (read and write too) with nested buses?
Concerning code generation this would allow to hold block-data inside compact structures for multiple instanced functions, etc.


Kaushik replied on : 2 of 25


We are working on adding non-virtual bus support to data store memory (along with read and write blocks). However, this will not be available in R2010a. If you have any specific use cases that you would like to share with us on this, please let us know.


XaL replied on : 3 of 25


I tried to search within the release notes, but the answer doesn’t seem to be included:
Is the Linux Simulink interface similar to the Windows one on the R2010a release? Does it include a model browser now?
You wrote last year (
“The current Simulink editors do have some limitations based on the platform you use. Our long term goal is to upgrade the editors so all features will work across all platforms. This is part of a major architectural upgrade that has been on-going for a few years. Thanks for letting us know that this is important to you.”
Is the major architectural upgrade over by now?
Thanks in advance

Seth replied on : 4 of 25

@XaL – Thank you for your good memory! The major architectural upgrade is still underway and involved many developers full time. Unfortunately, I don’t have a time-line for when this will be available.

wei replied on : 5 of 25

@seth, one feature I like to see is multi-port/datatype support for From/To-workspace block, like scope block.

Checker replied on : 6 of 25

@seth, Is it on your(mathworks) radar to provide the ability to use a stateflow library block inside another stateflow?

Michael replied on : 7 of 25

@Checker, You can place a Stateflow library chart inside of another Stateflow chart via the Simulink function object (as of R2008b). Would that solution work for your models?

Checker replied on : 8 of 25

@Michael, I am currently using the same methodology you mentioned (Stateflow- Simulink integration). It works, but its not as convenient as using directly a stateflow lib inside another stateflow ( U need to create ports, specifiy thier sizes …).

Paul J. replied on : 9 of 25

I checked out the new features and am a little disappointed that there is nothing new on model arguments for model referencing. Based on my understanding of how model arguments work, I have concerns about how effective the current approach is for models that have lots of nested model references.

Mike Tocci replied on : 10 of 25

@Paul J. – Can you give more details on what problems you think you will run into with model arguments? Also, what enhancements you’d like to see?


Paul J. replied on : 12 of 25


All of my comments are based on 2009a. My apologies if I’m not up to date.

Suppose I have a widget.mdl with 10 model arguments. Now supose I have 10 references to widget.mdl inside machine.mdl, and machine.mdl also has 10 model arguments that customize it. Now suppose I have a factory.mdl that has 10 refrences to machine.mdl.

So what are (some of) the issues:

By my count 1000 model argument values have to be defined when simulating a factory. This is true even if *none* of them are intended to override the default values defined in the model workspace of the machine and the widget.

The only way for factory.mdl to customize each widget in its machines is for the machine.mdl model arguments to include arguments that only exist to pass through to each widget. So each machine must have 110 model arguments. It may be feasible to simplify that list by capturing the arguments for each widget in 10 seperate arrays, but that only works if the widget.mdl arguments are compatible with each other, since we can’t use cell arrays or structs as model arguments. No matter what, some of these argument lists are going to get very long and unreadable.

Furthermore, the developer of factory.mdl needs to know how to set the argument values for each widget in its machines. In many cases, this higher level developer shouldn’t have to deal with this, unless they want to override what the machine developer did. Seems like this would break down very quickly; imagine how much knowledge is required to develop company.mdl that includes references to factory.mdl.

I have a few other concerns, but this is good for now. Am I off base on any of these? Have there been any changes in 2009b or 2010a that address these? I have a list of enhancements I’d like to see, but many wouldn’t make sense if anything I’ve said above is incorrect.

Thanks for your interest!

Paul J. replied on : 13 of 25


Thanks for pointing me to the doc for #1. I hadn’t checked the release notes for 2010a, only the Latest Features page. I’m surprised I didn’t see it mentioned there, I think it’s very signifigant.

#1 and #2 aren’t my only concerns, but probably the biggest.

Anyway, I’ll eventually upgrade to 2010a and play with the structures, which sounds like a significant upgrade.

Thanks again!!!


Mike Tocci replied on : 14 of 25

Hi Paul,

Thanks for the detailed response, it’s really helpful. From what I understand, you have two complaints for model arguments,

1. You can not use structures or cell arrays for a model argument. When the arguments have different types, this means you must pass in each argument separately, which can lead to very long argument lists.

2. Once a referenced model states it has model arguments, the parent model must pass in an override value, even if it really wants to use the default value.

For #1 there is some good news, in R2010a, we now support using structures as model arguments.

For issue #2, we don’t currently have a way of telling the referenced model to use the default value. The best workaround I can think of is to mask the Model block. In the mask, you could give the option of using the default value, but it would require more bookkeeping in the workspace to keep track of the defaults.

Let me know if this helps, or you need any more information.



Mike Tocci replied on : 15 of 25

@Paul – You’re right about the R2010a Latest Features page, there’s a short blurb about tunable structure parameters, but it doesn’t mention that this includes model arguments.

You can respond here if you have any other questions or concerns and I’ll try to get back to you.



Paul J. replied on : 16 of 25


With respect to structure parameters I’m confused as to what’s actually new. I’m still back on 2009a, and in this version (and previous ones too) I’ve been able to put numerical data into a struct and then dereference the fields in block parameter expressions. I could also send the entire struct into a masked subsystem dialog and then dereference it inside the subsystem blocks as needed. Have I been using an undocumented feature all this time?


Mike Tocci replied on : 17 of 25

Hi Paul,

1. The key addition is tunability, which in turn allows structure parameters to be model arguments. You’re right that you could do all you say in R2009a, but you couldn’t mark these variables as tunable, which particularly affects Real-Time Workshop code. I noticed that the release note I pointed you to is misleading about this, it should say that tunability is the new feature, I’ll check if this should be updated.

2. The easiest way to add struct variables to the model workspace is to create them in the base workspace and copy them over to the model workspace using the Model Explorer.


Paul J. replied on : 19 of 25


I’ve started to explore using structures as model reference arguments in 2010a and I’m running into some problems, even though it seems like the process should be very straightforward. The documentation is not very helpful in this area, IMHO.

So let me ask very basic questions:

1. Can a structure used as a model argument be a naked Matlab structure variable (just like one can used a scalar Matlab variable) or does it have to be encapsulated in the Value field of a Simulink.Parameter object?

2. Does the answer to 1 depend on the contents of the structure argument, such as whether or not the structure argument contains a field that is itself a structure or structure array?

3. For that matter, can a structure array be used as a parameter (the doc is silent on this question as far as I can tell)? Can a model argument be a structure array or have a field that is a structure array?


Paul J. replied on : 20 of 25

After some experimentation, it appears that I don’t have to use Simulink.Parameter objects, but it also seems that a model reference argument that is a structure is not allowed to contain a field that is itself a structure array. Is that a constraint on structure parameters in general?

Also, in looking through the documentation I came across the concept of Model Reference Variant. This seemed promising until I saw that a variant Model block can’t contain continuous states. Why is this constraint necessary when it’s not applicable to a non-variant Model block?

Mike Tocci replied on : 21 of 25

Hi Paul,

Thanks for pointing out these issues, here’s some more info:

1. I agree the doc section on Model Arguments needs to be updated to reflect the support for structures. I’ll see if this can be updated for 10b.

2. Your experiment is correct, you do not need a Simulink.Parameter to wrap a structure parameter.

3. Arrays of structures are not allowed in 10a. Structure parameters can be thought of as an analogue of bus signals, and arrays of buses are not currently allowed in Simulink.

4. I think the documentation for Model variants limitations may be incorrect, continuous states are allowed in variant models. They are only not allowed when using the preprocessor conditionals option when generating Real-Time Workshop code. I will double check this and let you know.


Mike Tocci replied on : 22 of 25

The documentation for Model variants limitations is not correct, there is no restriction on continuous states. This restriction only applies to one specific part of the Model variants feature, using preprocessor conditions in RTW code.

John Dzielski replied on : 23 of 25

I am trying to figure out how to pass a structure as an argument to a model reference block. This post suggests that it’s possible starting with r2010a. The links to the release notes and what seems to be an example in this post are broken. I called tech. support, but after several days haven’t gotten the answer. Can you point me to something that show me how to do this? I am working with r2010a.

Seth replied on : 25 of 25

@MikeT – Thanks for providing the direct link…

@John Dzielski – Happy New Year! I checked into the support case you mentioned, and it looks like we got back to you yesterday. We had a 4 day weekend at MathWorks, so our support team was off. Thanks for your patience and understanding!

Add A Comment

Your email address will not be published. Required fields are marked *


Preview: hide