{"id":12,"date":"2008-04-29T23:00:42","date_gmt":"2008-04-30T04:00:42","guid":{"rendered":"https:\/\/blogs.mathworks.com\/seth\/2008\/04\/29\/nonvirtual-bus-signals\/"},"modified":"2008-04-29T23:32:46","modified_gmt":"2008-04-30T04:32:46","slug":"nonvirtual-bus-signals","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2008\/04\/29\/nonvirtual-bus-signals\/","title":{"rendered":"Nonvirtual Bus Signals"},"content":{"rendered":"

Most Simulink users have a good idea of what a bus signal is\r\nbut I have found people are not as clear about what distinguishes virtual and\r\nnonvirtual buses. We have discussed bus signals in recent posts, and we are\r\nnow ready to answer blog reader Han\r\nGeerligs request<\/a> for \u201cmore explanation on virtal\/nonvirtual buses.\u201d <\/p>\r\n\r\n

What is a nonvirtual bus?<\/strong><\/p>\r\n\r\n

Here are the two types of bus signals, virtual and\r\nnonvirtual.<\/p>\r\n\r\n

\"Virtual<\/p>\r\n\r\n

To make a bus nonvirtual, provide a bus object and check the\r\n\u201cOutput as nonvirtual bus\u201d check box in the Bus Creator dialog. You can review\r\nhow to make a bus object with the example provided in this\r\nprevious post<\/a>.<\/p>\r\n\r\n

\"Nonvirtual<\/p>\r\n\r\n

The big difference between virtual and nonvirtual buses is\r\nhow Simulink treats memory allocation. A virtual bus does not allocate specific\r\nmemory for the bus, whereas nonvirtual bus signals represent memory.<\/p>\r\n\r\n

In a previous\r\npost<\/a>, we saw that when you update your diagram (Ctrl-D), the virtual buses\r\ndisappear and what remains are connections between the actual source and the\r\ndestination block. The memory allocated for those signals is not contiguous. \r\n Using a nonvirtual bus specifies the creation of a structure, which resides in\r\ncontiguous memory.<\/p>\r\n\r\n

At first, this concept was foreign to me because I generally\r\nhad not thought about memory allocation in Simulink. To better illustrate this\r\nconcept I will compare two models, simplebusdemo_vir.mdl<\/a> and simplebusdemo_nv.mdl<\/a>. (Bus objects are in simplebusdemo_nv_busobjects.mat<\/a>.)\r\n<\/p>\r\n\r\n

\"Simple<\/p>\r\n\r\n

\"Simple<\/p>\r\n\r\n

Both use bus objects to specify the interface to the\r\nReusableFcn subsystem, but simplebusdemo_nv has a nonvirtual bus crossing the\r\nboundary. Here is my mental picture of memory being allocated for the virtual bus\r\nexample.<\/p>\r\n\r\n

\"Memory<\/p>\r\n\r\n

The first and fifth inport have type double<\/tt> inputs, with one and two elements respectively\r\nrepresented in red. The second inport has three elements of int16<\/tt>, represented in green. The\r\nthird inport is one element of type uint32<\/tt>\r\nrepresented by orange, and the fourth inport is one element of type single<\/tt> represented by blue. The bus\r\ncreators and bus signals are all virtual blocks, so there is no memory\r\nassociated with those blocks or their ports.<\/p>\r\n\r\n

The inports for the nonvirtual bus example have the same\r\npattern of memory allocation, but now we have to add in the memory for the\r\nnonvirtual bus. Here is the way I picture it.<\/p>\r\n\r\n

\"Memory<\/p>\r\n\r\n

The output of the bus creator is a scalar element of main_bus<\/tt> type as defined by the bus\r\nobject. The bus object is the definition, and the nonvirtual bus is an\r\ninstance of a structure with that definition. I often see confusion between\r\nbus objects and instances defined by bus objects. They are not the same\r\nthing. The bus object is a definition of an interface. Your model may\r\ncontain many instances that share that same interface definition.<\/p>\r\n\r\n

Nonvirtual bus signals and efficiency<\/strong><\/p>\r\n\r\n

As you can see from the above picture, the nonvirtual bus\r\nhas added memory to the model. In this case, that memory consists of copies of\r\nthe memory defined at the inports. I have often heard the rumor that bus\r\nsignals result in many unnecessary copies. This is not completely accurate. \r\nNonvirtual bus signals can<\/em> result in additional copies, but from the\r\nSimulink engine perspective, this is the specification. Another way to build\r\nthis model would be to remove the five inports and replace them with a single inport,\r\nwhich outputs a main_bus<\/tt> type. \r\nThen it would look like this.<\/p>\r\n\r\n

\"Memory<\/p>\r\n\r\n

Notice, when you specify a bus object on an inport, the icon\r\nchanges to show that a bus object defines that interface.<\/p>\r\n\r\n

When do you need a nonvirtual bus?<\/strong><\/p>\r\n\r\n

The only places you need<\/em> nonvirtual buses are at the\r\nboundaries in your model when you want to define the interface as a structure. \r\nSome examples of these boundaries are Stateflow charts and model reference\r\nblocks. At the interface between systems, virtual buses are as a collection of\r\nindividual elements, with each passing separately to the system. The\r\nnonvirtual bus forces the memory to be a contiguous structure passed into the\r\nsystem.<\/p>\r\n\r\n

Nonvirtual buses show up in other places in models where\r\nthey are not required by semantics. Most often the reason it is done is to\r\ncontrol the signal memory allocation in the generate code.<\/p>\r\n\r\n

Virtual versus nonvirtual buses<\/strong><\/p>\r\n\r\n

To summarize,\r\n