Buses and Delays

There are additional property elements like buses and delays that are placed on top of connections. These property elements can be used to influence the behavior of the model.

Buses

If you create a connection between multiple output and multiple input ports, it is often necessary to specify the number of connections the single wire represents. This can be realized by the bus property element. The bus property is much like a delay in that it is placed directly over the multiple connection. Its single parameter Buswidth specifies the number of connections the single wire represents. Take a look at the following example.

The Map primitive represents a number of model instances of the same model component, in this example the MpyConstFloat primitive. Here, the bus width has to be three or the Map primitive will issue an error message. This is because there are three inputs to the Map primitive, so three instances of the MpyConstFloat primitive will be created. The three outputs from these three instances need somewhere to go.

To create a bus property element, use the  tool button to switch to the bus property creation mode. You can specify the bus width by the parameter Buswidth. To do this select the bus icon in the Model Editor Window. MLDesigner activates the Relation Properties plane in the property editor window. This property can be used to modify the bus width.

MLDesigner provides a number of primitive components that realize capabilities to model the conversion from single connections to bus connections and vise versa. For that purpose, you need the bus create and bus merge primitives from the HOF domain.

Delays

In several domains, delays can be placed on connections. A delay is not a primitive, but rather a property of the arc connecting two primitives. The interpretation of the delay in the dataflow domains (SDF, DDF, BDF) and most code generation domains is as an initial particle on the connection. An initial particle for the scalar data types is one whose value is zero. When the connection passes particles containing message type data, a delay on the connection will create an ”empty” message. Most often, the destination primitive of the connection must be able to interpret such ”empty” messages explicitly in context of the user-defined type because a ”zero” might have different meanings depending on the type. Any feedback loop in the SDF domain must have a delay, or the computation in the loop would not be able to begin. You can specify the number of delays.

Other domains (besides dataflow) also use delays, but the meaning can be quite different. See the chapters describing the domain.

There are two types of delays:

Non-initializable Delay

Initializable Delay

The Non-initializable delays are considered deprecated but are still available for backward compatibility. The syntax for the two is quite different and you should probably use just one type to prevent confusion.

The syntax for the initializable delays is that the arguments to the delay are the initial value themselves. There is no value in the argument that signifies the number of delay particles. Instead, a count of the number of values in the delay arguments is the number of delay particles that will be added to the buffer of the connection corresponding to the delay. These arguments are specified as a string and are parsed according to the data type associated to the connection. For example, an initializable delay with parameter 1 0 1 on a connection passing float particles will have a buffer with three initial particles. The three particles will have the values 1.0, 0.0, and 1.0 respectively. If the connection was working on complex particles instead, an error would be given since complex numbers must be specified using a pair of numbers. A proper argument list for the delay in that case would be (1,0) (0,0) (1,1). The shorthand for declaring multiple values in the argument list is valid, just as in the arraystate case. For example, an argument list of 2 [5] would specify five initial particles with value 2.

To use delays in MLDesigner, you must place a delay on top of the wire connecting two instances. The Non-initializable Delay icon is a white diamond with a green border. As seen above, the Initializable Delay uses an icon that is a green diamond with a white border and has an ”I” in the middle of the diamond to signify that it is initializable. To create a delay, use the respective tool button Add Non-initializable Delay or Add Initializable Delay to switch to the delay property creation mode. In this mode, every time you click in the model port, a delay property element, initializable or not, is created. You can specify the number of non-initializable delays and the expression of initializable delays. To do that, you must click on the top of the delay icon. MLDesigner activates the Delay Properties plane in the property editor window.