Seth on Simulink
April 3rd, 2008
Advanced Maneuvers using Mux and Demux
Last week I started a discussion of mux and bus signals. Our mental model of the mux signal is a vector. The Mux and Demux Blocks can do more than just combine and break apart the elements of a vector. This week I want to go a level deeper and talk about the advanced maneuvers using Mux/Demux Blocks.
Mux Blocks as specifications
The first thing I want to show you is how to use the Mux Block to specify additional information about the signal dimensions at its ports. Instead of just putting the number of ports, you can specify the width of each signal line connected to the Mux Block.
This helps if you want to add a little more information to your model and include specifications at the Mux Block ports. When a signal is connected to the Mux Block and it has the wrong width, an error is thrown when the model is compiled.
Error in port widths or dimensions. Invalid dimension has been specified for input port 3 of 'model/System/Mux'.
Source blocks and ports can also supply this type of dimension information. I recommend that you specify dimensions on those source and port elements also, rather than just relying on the Mux Block. Information like dimensions should be included in interface and source blocks. For example, here is where you would add dimension information in the Inport dialog:
Demux Specifications
The mux is nice to have, but the Demux Block puts this concept to good use for selecting out subsets of your signal. When specifying the number of outputs as a vector of widths, you can pull out blocks of elements from your vector into subvectors.
Here is an example of the Demux Block breaking a vector of 8 elements into new signals of widths 1, 5 and 2.
Going back to our mental model of the mux signal as a vector, I only use this technique if it is logical to represent my signal this way. In this model, peeling off each chunk of signals makes the diagram flow very nicely. This replaces the need to demux all elements of the signal and then mux the subset of the signal into a vector.
Mux and Demux Blocks also work with special signal types
Another use of Mux and Demux Blocks involves the special function call signal type. Before I talk about what mux and demux do, let us review the basics of function calls.
A short introduction to function calls
A function call system is similar to a triggered system except that instead of executing based on the value of a signal they execute immediately when called by the function call initiator. I have seen function call systems used to simulate asynchronous behavior or to schedule the execution of a component independent of other components. Function calls are critical when designing your own scheduler for an embedded system.
Function Call Generators (1 below), Stateflow(2), and S-functions are the most common function call initiators. Model Reference Blocks(3) and Function call subsystems (4) are two examples of functions that can be called.
Function calls and Mux Blocks
When you have a single function call initiator, and a single system to be called, the connection is simply from initiator to the system being called. When you have multiple function call initiators, the Mux block is used to join the function calls together. (Blocks can only have one function call port.)
Function calls and Demux Blocks
When a single initiator needs to call multiple systems, the Demux Block allows you to split the signal. This is a very important semantic role for the Demux Block because function call signals are not allowed to branch like normal signals. Function call signals determine the execution order of the blocks they are connected to. If a function call was to branch, which destination system would be executed first? The Demux Block specifies the order of execution based on the port number that the signal is connected to. Port numbers are always counted from top to bottom, or left to right. Here is an example:
In this example, the function call initiator Task1 will execute Sys1, Sys2 and Sys3 in that order. I don’t know about you, but when I look at that picture I feel an aesthetic desire to uncross the lines going to Sys1 and Sys2. My urge is to reconnect the first and second outport from the Demux in order to uncross the signals, like this:
This would fundamentally change the behavior of the system. The order of execution would then be Sys2, Sys1, and then Sys3. The Demux Block is an important part of function call semantics, and semantics trump aesthetics.
What do you think?
You may have started reading this post with the expectation to learn all about Mux and Demux, but you also got my elevator speech about function calls. Did you know about this use for Mux and Demux? What is new or different in your mental model for these blocks? Leave a comment and tell me about it.
Posted by Seth Popinchalk
4:00 pm |
Posted in Signals |
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.
Leave a Reply
|
Hi Seth,
firstly, kudos for your blog. Nice to read about mental models, as this is the way I face Simulink.
Some remarks/questions:
* is any unification of vectors and buses foreseen? One might consider buses as “hierarchical named grouped vectors”
* I checked on the “bus selection mode”: it is possible to feed one scalar into a demux with bus selection mode=on. According to the documentation it should not be possible. Is this by design or accidentally?
* are there any plans to break compatibility between buses and vecors, as enabled by the bus selection mode?
* I would be interested in more explanation on virtal/nonvirtual buses. Is this in the pipeline for your blog?
A little off-topic: I am also interested into the relation between asynchronous rate transitions (various setups for this), the simulation of it and the code generation for it. Any plans to blog on this?
Seth,
I’d be interested in more discussion on when it’s a good idea, or a requirement, to specify the dimension and/or sample time of Inports either at the root level or in subsystems. Also, more discussion, with examples, on the use of function call subsystems would be interesting.
Thanks,
Paul
@Hans Geerligs - Your questions about bus signals are right on target, and each deserves a good post to help frame the discussion. My next post will be about bus objects and nonvirtual bus signals. Regarding unification of vectors and buses, the changes to bus signals over the past few releases have actually moved away from unifying the concepts. It turns out that there are too many edge cases that really complicate mixing of these concepts. I am planning to post about the Concatenate Block, and I hope to include some of the history behind mux and bus to give some clarification.
Rate transitions are a big topic. I plan blog on this. Thank you for the great suggestions.
@Paul J. - Specifying dimensions is a must for root level inports. The Model Advisor incluses “Check root model Inport block specification” which reports this message:
I see specifying root Inport information as being good modeling style. For subsystems, it is optional, but it really depends on how you are treating the subsystem. If the subsystem is a utility from your library and it is designed to handle any width vector input, it makes sense to leave the size inherited (-1). When the subsystem is a functional unit (atomic subsystem) and you can define it’s interface, I think this is the time to include dimensions and even type information. If you are only using subsystems to group blocks, and simplify your model (virtual subsystems), specifying sizes is unnecessary.
Function call subsystems are going to be a future blog topic. Thanks for adding your voice to the community!
hi seth,
i am interested in learning how TeX format can be used in the “documentation” tab of a subsystem. it does not seem to work and i have been told that functionality is not available now, but it sure would be great to add that in.
Thank you for your hints on mux and demux blocks and function calls. Concerning function call subsystems there is one problem I´m struggling with. You can´t use function call subsystems or triggered subsystems for multirate systems. Instead of this you have to use if-action or switch subsystems.