Import and export Simulink

Both directions

Any subsystem — or the whole model — can be written out as a Simulink script, and a Simulink script can be read back in to build the equivalent ICore diagram. The mapping is not guesswork: each block declares its own entry in the Simulink catalog, naming the counterpart block and how each parameter translates.

Checked block by block, before every release

Every block bridged to Simulink has a testbench. The block is driven with a seeded random stimulus; the identical samples are run through the Simulink counterpart and through the block's own generated MATLAB, and the two outputs are compared sample by sample against a per-block tolerance.

A pass means the block's MATLAB code generation, its configuration handling and its catalog mapping all agree with Simulink for that configuration. It is a pre-release suite, not a demonstration: a block that drifts fails the release.

What the coverage looks like

Bridging is per family, and the block catalog states it per block rather than in a summary you would have to trust. In the control-systems families most blocks are bridged — discontinuities, matrix operations, model verification and the increment/decrement family are bridged in full. Machine-learning and robotics blocks are largely ICore-only, because there is no single Simulink counterpart to be equivalent to.

Each block's page in the documentation names its own Simulink entry, and that statement is checked against the block's code on every documentation build.

See also: Code export  ·  Python and MATLAB, both