Seth on SimulinkApril 29th, 2008Nonvirtual Bus SignalsMost Simulink users have a good idea of what a bus signal is but I have found people are not as clear about what distinguishes virtual and nonvirtual buses. We have discussed bus signals in recent posts, and we are now ready to answer blog reader Han Geerligs request for “more explanation on virtal/nonvirtual buses.” What is a nonvirtual bus? Here are the two types of bus signals, virtual and nonvirtual.
To make a bus nonvirtual, provide a bus object and check the “Output as nonvirtual bus” check box in the Bus Creator dialog. You can review how to make a bus object with the example provided in this previous post.
The big difference between virtual and nonvirtual buses is how Simulink treats memory allocation. A virtual bus does not allocate specific memory for the bus, whereas nonvirtual bus signals represent memory. In a previous post, we saw that when you update your diagram (Ctrl-D), the virtual buses disappear and what remains are connections between the actual source and the destination block. The memory allocated for those signals is not contiguous. Using a nonvirtual bus specifies the creation of a structure, which resides in contiguous memory. At first, this concept was foreign to me because I generally had not thought about memory allocation in Simulink. To better illustrate this concept I will compare two models, simplebusdemo_vir.mdl and simplebusdemo_nv.mdl. (Bus objects are in simplebusdemo_nv_busobjects.mat.)
Both use bus objects to specify the interface to the ReusableFcn subsystem, but simplebusdemo_nv has a nonvirtual bus crossing the boundary. Here is my mental picture of memory being allocated for the virtual bus example.
The first and fifth inport have type double inputs, with one and two elements respectively represented in red. The second inport has three elements of int16, represented in green. The third inport is one element of type uint32 represented by orange, and the fourth inport is one element of type single represented by blue. The bus creators and bus signals are all virtual blocks, so there is no memory associated with those blocks or their ports. The inports for the nonvirtual bus example have the same pattern of memory allocation, but now we have to add in the memory for the nonvirtual bus. Here is the way I picture it.
The output of the bus creator is a scalar element of main_bus type as defined by the bus object. The bus object is the definition, and the nonvirtual bus is an instance of a structure with that definition. I often see confusion between bus objects and instances defined by bus objects. They are not the same thing. The bus object is a definition of an interface. Your model may contain many instances that share that same interface definition. Nonvirtual bus signals and efficiency As you can see from the above picture, the nonvirtual bus has added memory to the model. In this case, that memory consists of copies of the memory defined at the inports. I have often heard the rumor that bus signals result in many unnecessary copies. This is not completely accurate. Nonvirtual bus signals can result in additional copies, but from the Simulink engine perspective, this is the specification. Another way to build this model would be to remove the five inports and replace them with a single inport, which outputs a main_bus type. Then it would look like this.
Notice, when you specify a bus object on an inport, the icon changes to show that a bus object defines that interface. When do you need a nonvirtual bus? The only places you need nonvirtual buses are at the boundaries in your model when you want to define the interface as a structure. Some examples of these boundaries are Stateflow charts and model reference blocks. At the interface between systems, virtual buses are as a collection of individual elements, with each passing separately to the system. The nonvirtual bus forces the memory to be a contiguous structure passed into the system. Nonvirtual buses show up in other places in models where they are not required by semantics. Most often the reason it is done is to control the signal memory allocation in the generate code. Virtual versus nonvirtual buses To summarize,
I think these concepts still require further illustration by looking at the generated code. You can get a sneak peak if you want to download the models and build the code yourself, or, tune in next week when I post about bus signals in the generated code. Now it’s your turn Do you ever picture the memory allocated in your Simulink model? Did I describe the reason you use nonvirtual bus signals? Are there other reasons I didn’t consider? Post a comment and share your thoughts. 5 Responses to “Nonvirtual Bus Signals”Leave a Reply |
|
|||
|
These postings are the author's and don't necessarily represent the opinions of The MathWorks. |
Hi Seth,
very nice post with clear illustrations, thanks!
I always wondered how to export a block with a bus as input to an own library. The inherited signal names always changed to “???” as soon as I cut a block of a model and pasted it into a library. The answer seems to be to use nonvirtual buses.
Regards
Markus
Hi Seth,
here are two suggestions for your blog:
If-then-else constructions are a bit awkward in Simulink. You need an if-block, at least two if-action-blocks and finally a merge block, not to mention the many data and control lines one has to draw. And as far as I know, if you do not have an else-branch, for the signal flow you still need to provide an else-action-block essentially consiting of nothing else a direct feedthrough.
I guess the Simulink developers have thought about making this a little bit more compact and easier. What were the reason to leave it as it is now?
Another thing where I need some clarification is the use of for-loops. Maybe you can give some examples how to use them.
Yours
Markus
@Markus - Thanks for the comments.
Regarding using bus signals in libraries… The signal name information for the bus selectors comes from the diagram, and the inport of a subsystem doesn’t have that information when it is in the library. The way to modify the library block is to temporarily disable the link, make your changes to the block, and then re-enable the link. At this point you have to select to propagate the changes you made back to the library.
Regarding the if-then-else construct, I can see from your description that you think it is awkward to use so many blocks to represent the if-action construct. Conditionally executed systems and iterator systems will be great topics for future posts. Thanks for the suggestions.
Well, it’s not about the articel.
I simply could not find where to report bugs of Simulink so I’m posting it here.
I built a model on Simulink 6.3 and when I used it in r2007a and r2007b I found out it work improperly because the “mux” block behaves differently - it builds the vector in a reversed way than what it did in Simulink 6.3
I could not find it as a known issue.
Is there any solution for this problem (I want my model to work on all these versions)
I don’t know of any such change in behavior. Please submit a service request to investigate this. From the support link on the front page, you can find the view and report bugs link near the bottom left. This will require you to log in. From there, find the link to Report and new bug. Technical support will investigate the issue for you.