Guy and Seth on SimulinkMay 20th, 2010Applying a Scalar Algorithm to a VectorThis week, Seth Popinchalk is visiting MathWorks Japan. Today's post is from Guy Rouleau: One of my favorite situations in technical support goes like this: Someone asks "Is it possible to do something?" and I can answer "Yes, this has been implemented in the latest release." This happened this week when someone asked about applying a scalar algorithm to a vector signal, and I pointed them to the For Each Subsystem documentation. The question I received was: I implemented a subsystem using the J-K Flip-Flop block. Now I would like to use this subsystem on a vector of signals. How can I do this? Many blocks in Simulink support Scalar Expansion, but some, like the J-K Flip-Flop, do not. Let's look for example at the Simulink demo titled Modulo-4 Counter Using Flip-Flops.  In this demo, two J-K Flip-Flop blocks are used to implement a Modulo 4 counter. Combined with the D Latch and a few Logical Operators, this system generates a half clock cycle width pulse on every fourth clock pulses.  Before R2010a, the solution to vectorize this system was to separate the individual components of the vector and copy the subsystem multiple times. For small vectors it is not too bad, but for a vector of 1000 elements, it definitely becomes a problem.  In MATLAB R2010a, it is now possible to place the blocks to be expanded inside the For Each Subsystem and connect the vector directly to it.  The question I receive the most often about the For Each Subsystem is: How is it different from the For Iterator Subsystem. In my opinion, the main advantage is that inside the For Each Subsystem, each block that has states maintains separate sets of states for each element or subarray that it processes. The automatic decomposition and concatenation of the input and output signals also saves a lot of time. Now it's you turn Do you see how the For Each Subsystem could be useful in your application? 
15 Responses to “Applying a Scalar Algorithm to a Vector”Leave a Reply |
|
|||
|
These postings are the author's and don't necessarily represent the opinions of The MathWorks. |
Hi Guy,
Could you please post snippets of code generated from that implementation? I haven’t upgraded to R2010a so I can’t try it out myself just yet. Also, does the code generation obey the loop rolling threshold setting?
Regards,
Ashish.
Hi Ashish,
Thank you for the comments. I understand that code generation is important, so I will prepare another post showing how the code generated from the For Each Iterator subsystem look like. This should answer your questions.
Thanks
Guy
Does this block work with model reference blocks?
You said “In my opinion, the main advantage is that inside the For Each Subsystem, each block that has states maintains separate sets of states for each element or subarray that it processes.”
Is this true for all blocks, or just some blocks?
The reason I ask is that I once tried to use a Stateflow Chart in a For Iterator subsystem to act on a vector of signals. The vector width had to be configurable so demux/mux with multiple copies wasn’t an option. Eventually I used Stateflow as a flow-chart and managed state outside the chart.
Does the For Each Subsystem resolve this problem?
@Ashish: Please see this video to get an idea on the code reuse aspect of using For Each subsystems:
http://www.mathworks.com/products/demos/simulink/Simulink-Latest-Features-R2010a/new-simulink-component-based-modeling-features-in-r2010a.html
Currently the loop unrolling threshold does not apply to For Each subsystems.
@Allan: Yes, Model Reference is supported within a For Each subsystem.
@Bob,
It is possible to place a Stateflow chart inside a For Each subsystem. If you connect a vector of “N” elements to the chart, the model will behave like if you had N copies of the chart, each of them having its own set of states.
@Guy, Would you go over Stateflow chart in your next post on for each code gen? I’m curious how states are treated.
I have tried to include variable integer/fractional delay block to For Each Subsystem. But the system gives a message that the blocks are currently not supported. Have I missed out anything?
@CR, Unfortunately these blocks cannot be used inside the For Each subsystem in R2010a. More blocks and features should support the For Each Subsystem in future releases.
@Guy. Thanks for the clarification on For Each Subsytem. I have another question on subsystem, but this time it is the enabled subsytem. Basically I want to generat a pulsed chirp signal. The chirp block in SP blockset cannot do this directly.
I have two versions of implemetation: (1) Using sample based mode, the enabled subsystem (enabled by a pulse generator) contains the chirp block. (2) Using frame based mode, the chirp block output is multiplied by the pulse generator output.
The enabled subsystem can avoide unnecessary computation when the subsystem is disabled, but it is not as efficient as fram based processing. The frame based approach is more efficient (?) but it performs too many unnecesary computations (when pulse width is much less than pulse period). Is it possible to combine the advantages of two methods mentioned above without re-implementing the chirp block? (or a feature request for future release of chirp block?)
Based on experiments in 2010A, it appears that the For Each Subsystem cannot handle continuous time (sample time = 0) inputs, even when all of the blocks in the subsystem have an inherited sample time. Is that supposed to be the case? If so, can someone point me to the documentation that indicates this limitation. Has this been changed in 2010B?
Also, it seems to me that the subsystem (2010A) can only contain blocks with *discrete* states, continuous blocks are not allowed? Is that also a constraint on model references inside the subsystem, i.e., can the referenced model only have discrete states at inherited sample times?
Hi Paul,
You are right when mentionning that the For Each Subsystem does not support blocks with continuous sample time.
This is mentionned, with other limitations in the For Each subsystem documentation.
Note that you are not the first user asking for that. Our development team is working on that, but I don’t know when this will be ready.
Guy,
Can referenced models in a For Each Subsystem have continuous states, mixed sample times, etc?
Can you provide a link to the documentation that discusses this limitation? The doc page that I read (http://www.mathworks.com/help/toolbox/simulink/slref/foreachsubsystem.html) says “The For Each Subsystem block does not support: … Blocks with explicit discrete or continuous sample times inside the subsystem (The subsystem must be single rate.)” and it also says that the Sample Time of the subsystem is inherited. I took that to mean that if all of my blocks inside the subsystem had sample rate -1 (which I think is not explicit) and my inputs were SampleTime = 0 then all of stated requirements were met (unless SampleTime = 0 is not considered to be a “single rate”).
Thanks as always for your response.
Paul
Paul,
The doc page I had in mind about the For Each Subsystem limitations is the one you mention.
The limitation with sample times in the For Each Subsystem is that all the blocks inside the subsystem must take the sample time “Triggered” ([-1,-1] or Cyan color). This is why it is not possible to explicitly specify a sample time.
While an inherited discrete sample time can be equivalent to a triggered sample time (with proper trigger), an inherited continuous sample time cannot, because of minor time steps. This also applies to referenced models.
Maybe the documentation should split the “explicit discrete or continuous sample times” into two lines to make it clearer that the For Each Subsystem block does not support:
- Blocks with explicit discrete sample times inside the subsystem
- Blocks with continuous sample times inside the subsystem
In the For Each Subsystem, the closest you can get from continuous sample time is fixed in minor time steps. It will give you the variable-step property of a continuous signal, but the results will be different. Depending on your application this can be acceptable or not.
Are there limitations on the sample times inside a model referenced inside a For Each subsystem?