<?xml version="1.0"?>
<api>
  <query-continue>
    <allpages gapfrom="Simulink Supported Blocks" />
  </query-continue>
  <query>
    <pages>
      <page pageid="19" ns="0" title="Semantic Meta-model">
        <revisions>
          <rev xml:space="preserve">More description to be added soon...

See the [[Complete Semantic Meta-model]] 

== Top Level ==
[[File:SmmTopLevel.png|850px]]

== Types == 
[[File:SmmTypes.png|750px]]

== Expressions ==
[[File:SmmExpression.png|800px]]</rev>
        </revisions>
      </page>
      <page pageid="22" ns="0" title="Simulink Supported Block Details">
        <revisions>
          <rev xml:space="preserve">[[Main Page]] &gt;&gt; [[Simulink Supported Blocks]] &gt;&gt; Supported Block Details

----

== Subsystems ==
[[File:Simulink_SupportedBlocksSubsystems.jpg]]

* Top-level subsystems (model or library) have to be set to &quot;atomic&quot;.
* Atomic subsystems should be preferred over non-atomic. Non-atomic sub-systems have no corresponding element in source code (because the Simulink engine can freely decide to execute contained blocks inside or outside the sub-system context. As a result the model-transformation layer has to resolve the non-atomic sub-systems by eliminating them and adding all the contained blocks to the next higher context. 
* There is some support for masked subsystems. But in general the use of masked systems and parameters is discouraged. Basically, from an implementation perspective mask parameters represent additional procedure inputs (like Inports), but they are hidden. Also, while fixed &quot;early-binding&quot; settings (type and dimension) can be enforced on Inports, the same is not possible for mask parameters.
* Merge blocks have to be used on all outputs of Action sub-systems. The design has to ensure that one of the Merge inputs is active under any circumstances. (Simulink is a little more tolerant)

== Stateflow ==

== Math == 
[[File:Simulink_SupportedBlocksMath.jpg]]

== Discrete ==
[[File:Simulink_SupportedBlocksDiscrete.jpg]]

* Discrete-time Integrator
** The following integration methods are supported: Integrator Forward and Backward Euler and Integrator Trapezoidal (Accumulator not supported)
** Reset input has to be scalar
** State port and Saturation port not supported
** Simplified initialization not supported

== Logical &amp; Bit == 
[[File:Simulink_SupportedBlocksLogicalBit.jpg]]

== Signal Routing == 
[[File:Simulink_SupportedBlocksSignalRouting.jpg]]

* The MultiportSwitch does not support the two-input usage as a selector, indexing into an array. Please use the Selector block instead
* The code generated from the MultiportSwitch will rely on a utility function (in GBL_Saturation.c, located in the Sources folder of the distribution) to guard the selecing input 
* Both the Switch and MultiportSwitch currently support only the switching of basic (and enumerated) types, not bus types 
* From/Goto block are useful tools to structure a complex design which would otherwise have many crossing signal lines. But, From/Goto blocks can only be used with a local scope. They are basically non-functional, simply hiding a signal line from view. From/Goto blocks with global scope would have to be represented by global variables. Such a concept is not supported by design, as this would open alternative data paths to the current paradigm that data flow across hierarchy levels will follow an equivalent procedure call hierarchy.
* Data Store Memory, Read and Write
** Local scope only (same rationale as Goto/From, see above)
** Currently only basic type support

== Lookup ==
[[File:Simulink_SupportedBlocksLookup.jpg]]
 
The lookup, interpolation and interpolation using pre-lookup blocks will result in generated code that uses utility functions located in GBL_Interpolation.c (provided in the Sources folder of the distribution)

== Sinks &amp; Sources ==
[[File:Simulink_SupportedBlocksSinksSources.jpg]]

* For all Inports at top-level (model as well as library system) data type and dimension have to be set to fixed values at generation time. Simulinks ability to determine a model's types and dimensions at run-time does not translate into source code. Furthermore, since library systems are intended to result in truly reusable pieces of source code, all instances of a library system have to use the same fixed interface.

== Misc ==
[[File:Simulink_SupportedBlocksMisc.jpg|450px]]

The code generated from the Saturation block will rely on utility functions in GBL_Saturation.c, which is located in the Sources folder

----

[[Main Page]] &gt;&gt; [[Simulink Supported Blocks]] &gt;&gt; Supported Block Details
'''Bold text'''</rev>
        </revisions>
      </page>
    </pages>
  </query>
</api>